The React-Native Setup (Ubuntu 16.04)

Well, last weekend I decided that I was going to mess around a bit with React Native. (In a previous post, I said I wasn't going to dip into any JS frameworks until I was more comfortable with JS itself. After having heard several people say that learning React will make you a better JS developer, I thought, 'Hey. Two birds? One stone? Why not?') Starting a new task means setting up for a new task. And my goodness, was this a pain in the what's-it to set up. Not sure if I was just doing things wrong or if it's genuinely difficult to get things up and running in my environment. In this post, I'm going to talk about what all I had to do to get going. Hopefully, it'll be useful for someone else -- even if it's just for future-me.

Just the Facts

If you just want a quick list of the sites on which I found all the information I'm going to be discussing, here you go:

• Facebook's 'Getting Started' Page - I went here first.
• That site sends you to The Android Developer Site to install Android Studio. From there, you're sent:
• To the actual link to download Android Studio to...well, to download Android Studio.
• JDK 1.8 or higher. Use WebUpd8 PPA: Install Oracle Java 8 in Ubuntu or Linux Mint via PPA Repository [JDK8]
• Recommended (by Fb 'Getting Started') install: Watchman
• Recommended (by Fb 'Getting Started') install: The Gradle Daemon
• This discussion at AskUbuntu.com: Unable to locate package lib32bz2-1.0

The Headache

NB: If you're going to follow along here, read the post completely first, as there are a few commands I discuss in the course of talking about the Headache which you should not actually bother running.

So, first thing's first. Head on over to Facebook's Getting Started page (linked above). As long as you've got Node (4 or higher) installed, you're good. There's an installer on the Node Website. Or, if you want to use nvm, go to creationix's Github page, and follow the instructions to install nvm. Then, in your console, nvm list-remote to see available versions. Then nvm install XXX, where XXX is the version number you want to install. The version of npm that will be installed with node will likely not be up-to-date. So, you'll want to do npm install -g npm@latest.

NB:

• npm i... is the same as npm install.

• npm i -S is the same as npm install --save

• npm i -D is the same as npm install --save-dev

Install the React Native CLI (Command-Line Interface) by running npm i -g react-native-cli.

Next, you want to head on over to grab Android Studio. The install instructions here are fairly straightforward. But this is where I got tripped up, I think. Before mucking about with Android Studio, make sure javac -version in your terminal returns >1.8 (a version number greater than 1.8). There's a video that demonstrates the install process on the Android Studio site. Unzip Android Studio - I put it straight into my Downloads folder. So there's an android-studio folder inside my Downloads folder. In your console, sudo mv android-studio /usr/local.

Next, in your terminal, export PATH=$PATH: -- for me it was export PATH=$PATH:/home/my_user/android-studio/bin. This makes it so that you can start Android Studio by typing studio.sh in your terminal (rather than having to type the whole path). The install wizard will guide you through the setup. You may need to install additional versions of the SDK depending on your development needs. I also had to install additional versions of the Build Tools. These options are available by opening Android Studio, going to Configure > SDK Manager > Launch Standalone SDK Manager. From here, the available packages are clearly displayed.

At this point, the instructions on the Android Studio website have a note.

It says "If you are running a 64-bit version of Ubuntu, you need to install some 32-bit libraries with the following command:..." After which it gives a command: sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 lib32stdc++6. I run this command and more than one of these packages is not located in my repository. Thankfully, there's a discussion over at AskUbuntu in which Bilal says a bunch of stuff, then

sudo dpkg --add-architecture i386

sudo apt-get update

sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 libstdc++6:i386...

...

The key for me was that the package lib32bz2-1.0 is in fact no longer called lib32bz2-1.0, but rather libbz2-1.0:i386. So! sudo apt install libbz2-1.0:i386.

After this, download Watchman and configure The Gradle Daemon by entering in your terminal: touch ~/.gradle/gradle.properties && echo "org.gradle.daemon=true" >> ~/.gradle/gradle.properties

Now, the magic can begin. Nagivate to your project folder, in your terminal: react-native init SuperCoolProject which will create a new folder called SuperCoolProject.

Then cd into that SuperCoolProject. Then, react-native run-android. Here, I got loads of errors.

The various things I tried and/or had to do to get going properly were the following:

1) Run react-native start if the packager doesn't start automatically when you run react-native run-android.

2) Add a file called local.properties to the android folder inside your project folder. Its contents should be a key, sdk.dir whose value is the path to your SDK (probably something like /home/user/Android/Sdk). So, sdk.dir=/home/user/Android/Sdk.

3) I also added /home/user/Android/Sdk, /home/user/Android/Sdk/tools, and /home/user/Android/Sdk/platform-tools to my __PATH__. I suspect the latter two might have been redundant, but I'm not certain. I added them all. One day I'll remove them one by one and see! Or, you know, you could just tell me.

4) This was really important: (but only if you're debugging on an actual phone. If you're using an emulator, this isn't necessary.) Run adb reverse tcp:8081 tcp:8081 in your terminal before running react-native run-android.

Finally, I connected my phone. Ran react-native run-android and voila!. There's Welcome to React Native on my phone's screen. I edited index.android.js, shook the phone to bring up the menu, hit Reload, and Bob's your uncle. The menu also offers Live- and Hot-Reloading so that you don't have to manually reload each time you make a change.

That's all

Well, I don't know if this will prove useful for anyone. But if nothing else, I can come back to it again later when I inevitably have to do it all over again.

Update

Since originally writing this post (though, I didn't post the post, so you wouldn't know anything about that), I installed the development build of android studio. You can change which build you're using in the Android Studio options/configuration. Running the dev version of Android Studio, I added a couple of emulators so that my project could be tested more extensively than just on my physical device. Once the emulators are setup -- give them simple names (e.g. Nexus6P) -- you can start them from a terminal with the command emulator @Nexus6P. You can see a list of what emulators you have installed with emulator -list-avds. Once the emulator is running, in another terminal react-native start, and in yet another terminal, react-native run android. And now Bob's your uncle.

Please feel free to contact me via twitter if you'd like to discuss anything I talk about in this post. Please feel free especially if I've gotten something wrong or done something in an inefficient way.

Transformative Experiences: Opting for Rationality or Authenticity

Originally appeared in Issue 71 of The Philosopher’s Magazine

Because I have a deformity of the spine, just before I turned 15, my parents took me to an orthopedic doctor for what was supposed to be a routine visit. After reviewing several X-Rays, my doctor had bad news. The curvature of my spine had progressed dramatically since last I had been X-Rayed. He recommended yet another spinal surgery to stop it from getting worse. We were faced with a decision -- we could operate, during one of the most difficult and formative years of my life, or delay and risk my spine curving into my lungs, causing further disability, pain, and, likely, death. How could we make this decision, neither of whose options were, at the time, quite imaginable to us?

At the time, my doctor gave me all kinds of information to try to help me make my decision -- statistics on his success rates performing the surgery, a detailed recovery regimen, possible side-effects of the surgery, potential problems during recovery, etc. I couldn’t imagine what it would be like to be further disabled, nor could I imagine what it would be like to recover from such a major surgery at that point in my life.

Normally, it seems that when we have a decision to make, what we do is we imagine what it would be like to choose each of the options that are available. Then, we choose the option that gets us more of what we want -- pleasure, desire satisfaction, useful stuff like money, credibility, or notoriety, etc. I take it that this is the standard way we go about making practical decisions, so we can call this way of deciding ‘the Procedure.’

For instance, if I’m at a lunch buffet trying to decide whether to have a salad or sandwich, I would employ the Procedure and imagine what it would be like to have the salad, imagine what it would be like to have the sandwich, and choose the option that I think I would enjoy more (that is, if enjoyment is what I’m after. Maybe what I want is a healthy lunch, and so whether I would enjoy the salad or sandwich more might not come into the picture. The central idea is that, no matter what the basis of the decision, it’s a basis tied to my future experiences -- to what it will be like for me after I’ve chosen.) But not every decision is like this; not every decision is as easy as deciding what to eat for lunch -- even when it’s a decision about what to eat!

For some decisions, the Procedure isn’t helpful. Some of the choices we make involve things that we can’t know anything about before we make our choice. These decisions are epistemically transformative -- after we make our choice and have the experience, we gain new knowledge. For example, in Transformative Experience, L.A. Paul discusses the decision faced by someone who’s never eaten a durian fruit. The durian is rather polarizing. To some, it has a sweet smell and tastes delicious. To others, it smells like rotting flesh and tastes awful. If I’ve never had a durian, how can I decide whether or not to have one by imagining what it would be like? I wouldn’t be able to imaginatively project forward and compare having the durian against not having it until after I gained knowledge of what it tastes like.

New experiences don’t just give us knowledge. They can also change who we are. Some experiences that we have can change us in fundamental ways. For instance, being the victim of an attack, fighting in a war, having a religious experience, and many other experiences can fundamentally change who someone is. These experiences are personally transformative and occasionally might also be epistemically transformative -- in which case we can call them Transformative Experiences, full stop.

For the Procedure to work, we have to be able to imaginatively project into the position of having chosen each of our options so that we can decide between them. But we can’t know what it will be like for us if the choice and subsequent experience fundamentally changes us. How can we decide, prior to changing, how we would experience the change? Being disabled and having had multiple surgeries in the past, as well as having struggled with my disability as a child, my parents asked me how I felt about the possibility of surgery. What would it be like not to have the surgery -- to become debilitated by my curving spine, to risk dying a presumably slow and painful death? What would it be like to have the surgery -- to suffer anxiety as the surgery approached, to be bedridden for two or three weeks, to struggle with pulmonary and physical rehab, to miss the first month or two of grade nine, etc.? In this kind of situation, the Procedure fails. How, then, should I have made my decision?

The occasions for transformative choices are much more common than we might think. We come across them frequently. The choice to become a parent or to remain childless is one example. One often hears of people who, though selfish or even self-centered while childless, change dramatically after seeing their child for the first time. Suddenly, everything one does is for the sake of another human being.

Of course, transformative experiences aren’t restricted to situations involving a choice. Sometimes things just happen and our lives change. Losing a child or a spouse, being the victim of an attack, having a religious experience -- these are all occasions on which we might have a transformative experience without having made a choice. While these latter cases -- cases of transformative experience without choice -- are very interesting, they don’t present the kind of interesting puzzle that transformative choices do. How can we decide what to do in a situation in which the normal way we make decisions fails to provide us with the resources we need to make those decisions? This is the Problem of Transformative choice, or ‘the Problem’ for short.

The Problem is interesting for many reasons, but especially because it suggests that we make some of the most important choices in our lives non-rationally. Another reason why the Problem is interesting is that it implies that things like advice, testimony, and maybe even empirical studies are not as useful as we might think. That is, if there is no rational basis for me to decide whether or not to become a parent, to become (further) disabled, or to take either this or that job, because I lack the requisite knowledge, i.e. I don’t know what it would be like for me to have those experiences, then it would be doubly difficult for someone else to give me advice about those things. They can certainly tell me about their experiences as a parent or a disabled person. They can answer a variety of questions but all I learn from them is what it is like for them, not what it will be like for me.

To be clear, the Problem is more than just a problem about lacking knowledge of the options before us in a choice-situation. It’s more than just the familiar problem of deciding under uncertainty. It’s a problem, not only because we don’t know what it will be like to choose this or that option, but because we can’t even imagine, first-personally, what it would be like for us to choose one of the options.

Another of Paul’s examples might help to illustrate. Suppose I had the opportunity to gain a new sense modality. Apparently, when vultures are flying through the air, they can see thermal currents. What would it be like to see like a vulture? As I write this, I’m imagining a Heads Up Display, the kind found in video games and sci-fi movies like the Terminator, telling me the windspeed and direction, and other information. But it’s probably not like that at all. In fact, I can’t really imagine what it would be like. And that’s precisely the point, that’s precisely the Problem.

One might think this isn’t a serious worry. One might think that the information we can get from experts, those who have already had the relevant experiences, and various empirical studies relevant to the experience would be sufficient to inform our decision. But this misses the point. The Problem isn’t a problem because there’s nothing to inform my decision. It’s a problem because everything that can inform my decision can only do so to a limited, impersonal extent -- others’ opinions and the data can’t tell me what it’s like for me, they can’t tell me what I will value and disvalue about my future experiences. If we can’t make transformative choices rationally, and the reason why is because we can’t know what it would be like for us to have the experiences we will have after the transformation, then what good does it do us to know what it’s like for someone else?

You might experience disability very differently from me. If your experiences of disability are different from mine, then your recommendation doesn’t tell me much, if anything, about what it would be like for me to be disabled. Even if you and I are very similar, or even if there are a host of studies showing, say, comparative levels of life-satisfaction among people with various disabilities and other ailments, there seems to be something rather suspect about my deferring to your judgment or that of the studies authors’.

There’s a tension here -- two concerns pull in opposite directions. On the one hand, we think that it’s important to get things right, to choose the option that will bring about the best outcome. On the other hand, deferring to another’s judgment seems to be choosing for reasons that are not our own. There’s a sense in which deferring to someone else’s judgment is inauthentic because we are alienated from the basis of our choice. The reasons offered by others’ experiences are their reasons, not our own.

Now, in some cases, choosing on this basis -- someone else’s -- might not be problematic at all. When you go to a new restaurant, you might ask your server what the restaurant’s most popular dish is. You reason, plausibly, that their most popular dish is the one most likely to satisfy you. After all, it probably wouldn’t be the most popular dish if it were terrible. In non-transformative practical contexts, seeking this kind of advice is more than reasonable. We save time and resources by consciously or unconsciously deferring to others’ judgments or to assessments of probability. I could try every dish the restaurant has to offer to find out which one I like most, but that would be inefficient. Opting for the most popular dish allows me to take advantage of the work done by all of the restaurant’s previous patrons.

But now imagine making a deeply personal, important life-decision this way. Suppose you are in a relationship and trying to decide whether you want to propose marriage to your partner. The analogy with asking the server might be something like asking people you know who are married how satisfied they are with their marriage. Does it make sense to propose marriage to your partner based on other people’s satisfaction in their marriages? Hardly. You want to know whether you will be satisfied in your marriage. You want to know whether you (and, hopefully, your partner) will benefit from being married. But the quality of someone else’s marriage can’t tell you anything about the future quality of your marriage. This is the problem with deferring to the testimony or authority of others in transformative contexts -- they cannot tell you what it will be like for you, and this is because the decision is a deeply personal and transformative one.

While deferring to the relevant opinions of others or to some statistics might be rational, in that it will perhaps help you to maximize expected utility, this comes at a cost. Again, one way we might describe this cost is as a loss of authenticity in your choice. And again, because the decision is such a deeply personal and potentially transformative one, passing the decision off to someone else seems like the wrong way to go about making it. Not choosing authentically would be choosing in a way that is untrue to ourselves. This seems, on the face of it, to be a bad thing. It is choosing in a way that is inconsistent with who we are, who we take ourselves to be. It would be choosing in a way that’s more characteristic of someone else.

Imagine making all of your life’s decisions like this -- should I get married? Should I have children? Should I take this or that job? Should I move to another country? Should I have this life-altering surgery? There’s certainly a sense in which it seems important to be true to ourselves when making these decisions, in part because we are the only ones living our lives and we think it’s important to take as much ownership of our lives as we can. Deferring to someone else’s judgment about what to eat for lunch is one thing. Deferring to someone else’s judgment about whether to have children is another thing entirely.

However, there is a way of thinking of authentic choices that might avoid the Problem’s clash between rationality and authenticity. First, it isn’t clear to me that deferring to someone or something else’s judgment is inauthentic or any less true to myself than employing the Procedure -- at least, given a few conditions are met. As long as I am still the one making the decision for reasons that I take to be genuine reasons, the decision seems clearly mine. It would be odd if I deferred to someone else’s judgment without taking there to be something recommending that course of action. If a study suggests there are good reasons to prefer A to B, selecting B over A would be ignoring important data that I should take into account.

Take a more mundane case for a moment. Studies repeatedly show that people are bad at multi-tasking -- this is why many US states have laws against using a phone while driving. Our attention is diverted enough that driving is impaired. We can either attend to this evidence and avoid using our phones while driving, or we can decide “authentically” whether or not we are competent enough to text while driving. It seems wildly unreasonable to think that, here, authenticity should trump rationality. So, for the prudential reasons associated with the risks of texting while driving, it seems clear that no matter how much I want to, or identify as a good multi-tasker, no matter how inauthentic the decision not to text while driving might be, I should choose rationality over authenticity. But in deeply personal, transformative decisions, is it clear that I should choose rationality over authenticity?

It’s true that in a transformative decision context, the choice is a much more deeply personal one. It’s true that nothing about my identity hinges on the case of texting while driving. These are important distinctions between the two decision contexts. I can, if I took the time, calculate the expected utility of texting while driving on any particular occasion. But the Problem is a problem in part because, given my lack of knowledge about what it will be like for me in the post-choice situation, I can’t determine the expected utility of any of my options. But this doesn’t mean that there isn’t important data that I should be attending to.

When we are in transformative contexts, arguably, if there is a fact about whether we will enjoy A more than B, it isn’t a fact that we can know prior to experiencing A and B -- at least, it isn’t a fact that we can consciously entertain; this just is the Problem. But it might be a fact that, say, 80% of people who declined the spinal surgery recommended to me died within a few years. Rather than not being rational to decide on this basis, it seems like it would be wildly irrational to do otherwise. “But,” says the proponent of authentic decisions, “you’re just playing the numbers. The particulars of the decision could be anything -- it could be a decision between cake and pie or disability and death. You’re just playing the numbers. That’s why your decision is inauthentic.”

So, again, the worry about the tension between authenticity and rationality is that, in choosing what rationality recommends, I am alienating myself from my choice. There are several questions we might ask about the relationship between authenticity, alienation, and rationality. But the most natural place to start, as I see it, is in questioning whether there really is a tension here between authenticity and rationality. I don’t think there is. In fact, I think in many case it’s irrational to be inauthentic. If it is, then transformative contexts might not present us with a problem between two independent values -- rationality and authenticity. Instead, they present us with a conflict between two different ways of exhibiting our rationality -- by maximizing expected value and by choosing authentically.

It’s irrational to choose inauthentically because when we decide inauthentically, we are deciding in a way that is untrue to ourselves, we are deciding on the basis of considerations that we ourselves don’t take to be reasons. There is a sense in which the decision is someone else’s. Deciding in this way, we relinquish our agency -- the thing that makes us who we are. Those who frame the Problem as one between authenticity and rationality seem to have this much, at least, correct.

But deciding authentically doesn’t mean ignoring the data, nor does it mean ignoring the advice of other, perhaps more experienced people. If this is what it means to decide authentically, there really would be a clash between rationality and authenticity. But then, if deciding authentically meant ignoring the data, why would authenticity be something that we value? And if we do take the data to offer us reasons, then it doesn’t seem the decision would be inauthentic.

We can imagine a transformative decision context in which what we should do is clear, precisely because the evidence favors one course of action far more than the other. For instance, if my doctor had told me that the spinal surgery would, with 100% certainty, fix my spine and leave my back pain-free for the rest of my life, but not having the surgery would, with 100% certainty, leave me in unending agony for the rest of my life, then clearly I should take the doctor’s advice and have the surgery. It would be irrational not to, even if not taking the doctor’s advice would have been the authentic choice. So here, we see, that the tension between rationality and authenticity exists only because the authentic decision (in this context) would be an irrational one.

If I’m correct and it’s irrational to be inauthentic (at least in certain contexts), then the Problem wouldn’t present us with a clash between rationality and authenticity at all. But if we take the advice of others or the deliverances of some studies as actually providing us with reasons to act one way rather than the other, then not attending to what we take to be reasons seems as much like a subversion of our agency as deciding on the basis of reasons that we reject. We are left, however, with a puzzle regarding which advice, testimony, and empirical data we should attend to, because, of course, not every piece of information is going to be relevant to our choice. An answer to this question, though, would require a much lengthier treatment of the concepts of authenticity and alienation than current space would permit.

Do the preceding considerations mean that the Problem of Transformative Choice is not a genuine problem? Not necessarily. Taking ourselves to have various reasons does not mean that we have good reasons. It certainly doesn’t mean that our decision will be a good one. The Problem of Transformative Choice is a genuine problem because no matter what studies there are, no matter what we know, no matter what we take ourselves to have reason to do in a transformative decision context, we still cannot know what it will be like for us after the decision. Our decisions in transformative contexts are, by the nature of the context, made from an epistemically impoverished position. Does this mean we should throw our hands up and go wherever the wind takes us? Certainly not. As agents limited by our finite bodies and minds, we can only do our best. But our best is still what we should do.

After an unexpectedly long absence, I've gotten things up and running again. That is, I've finally uploaded this website at which you're reading these words. The reasons for the delay are many, but none are particularly good. It's the same old story (for me, at least). When I was writing my dissertation, I spent several months planning out the entire thing, and several more months trying to get the first chapter started. I've always had a problem with (at least) two things: 1) showing unfinished work and 2) starting in the middle.

While I was perfectly capable of throwing up a nonsense website (as I did), I wasn't terribly comfortable doing so. It was just a page to host links to various pieces of work. It didn't tell you who I was (so it didn't start at the beginning :wink:) and it was, let's be honest, a load of rubbish. The thing is, though, that if I don't just throw my work out there and get eyes on it, I'll never make it any better than only I can make it.

Aside: That's actually one of the things that I find most exciting about open-source software: the collaborative nature of it. Not only do the size and scale of many projects make it untenable to work on them alone, but by working with other people you're bound just to get better. And the work will be better.

So that's sort of the point here, with a few caveats. In various ways, since the way I'm learning is mostly unstructured (at least for the time being), this site will be built in a similarly unstructured way. That is, I'll do a little bit here, a little bit there, maybe the two will be related, maybe not. I'll, hopefully, be keeping track of the things I'm doing -- both by posting projects and by blogging about them. In large part, I suspect I'll be prioritizing what needs work in my skillset. If you're a naturally right-footed soccer player, you ought to be spending more time working on your left foot than your right. Don't ignore your weaknesses. Focus on them (in the right way!).

So, for instance, this website is currently garbage to look at on a mobile device. Despite the fact that, after building the initial iteration of it, I took steps to make it look quite good on mobile devices, I've since broken a few things. As I mentioned in my first post, this site was originally made by following along with Travis Neilson's DevTips YouTube Channel. It was built using Jekyll, Jade (now Pug), Sass, and it used Gulp as a task runner. Since building the first iteration of the site, though, I found myself intrigued by Webpack and wanted to learn more about it. I decided I would rebuild the site using Webpack instead of Gulp. That initially proved more difficult than I expected.

One problem I had was that, since I was following along with a tutorial, I was doing just what the tutorial was doing (at least, in large part. I'm in no way suggesting that anything wrong with my website is anyone else's fault but my own). For that reason, I was using Gulp to compile my Sass without realizing that Jekyll could do that. So, when I started integrating Webpack into the project, I had a heck of a time getting things going. It was a reminder to RTFM. If the docs are there, read 'em.

After doing some digging around, I found this tutorial by Allison H. Zadrozny on integrating Jekyll, Webpack (which is all I was after), and React (which I was trying to avoid until I had a better handle on JavaScript itself). Allison's tutorial was so super clear, that I immediately started mucking around with it trying to integrate it with what I already had.

At this point, all I had to do was get Webpack to eat and spit out my pug files so that I could stick that html where it needed to be (I'm pretty sure this isn't the technical way of describing what's happening.). I spent a solid few days trying to do this. Ultimately, I was able to get all of my pug files into one html file (I couldn't figure out how to split them up into individual files). Once I had that, I was able to cut, paste, and edit that html to make it JSX so I could stick it in my React components.

It's not perfect. It's probably not even good. But that's OK.

When I first looked into learning JavaScript, one of the most frustrating things was finding someplace that provided fairly clear instructions on just how to get a JS development environment up and running. So, in this post I'm going to try to outline the steps I took to get started.

One thing that I kept coming across was people saying how great it is that all you need in order to write JavaScript is a text editor and a browser -- or really just a browser, since you can write JavaScript right into the browser console. That's all well and good for very small, very quick bits of code. But when I was asking around, I was looking for a place to write more than just a few lines of code. One thing I didn't want to have to trouble myself with was holding the shift key down in order to input multiple lines of code. In the browser console I was using (Chrome), if you press return, that tells the console to run the line of code you've written. It's a small, thing, really, to remember to hold the shift key down, but it was more of a pain than I wanted to deal with.

So the first thing I wanted to do was to get a text editor that was robust enough that I wasn't going to find myself, when I've learned more, wanting a more powerful editor. I wanted something that was customizable and free. There are lots of options, and this is ultimately a personal decision. I chose GitHub's Atom Editor because it seemed the easiest thing to use. It's open source, easy to install, and easy to customize. There are loads of packages that make it a real pleasure to use.

The Atom packages I've got installed are the following: - atom-beautify - atom-ternjs - autocomplete-emojis - color-picker - emmet - file-icons - file-types - filesize - git-history - git-plus - highlight-line - highlight-selected - jumpy - language-pug - linter - linter-alex - linter-eslint - minimap - terminal-plus - wakatime

Hello again, World!

This is the second post on my new blog! In this post, I'll briefly talk about who I am and what I'm doing.

Meet Rich Cordero!

My name is Rich Cordero, Dr. Rich Cordero. In 2015, after nine long years, I received my PhD in Philosophy from Florida State University. I am currently making the move from academia to the field of JavaScript and Web Development.

For the past year, I've been an adjunct professor of philosophy at Tallahassee Community College but for medical reasons am no longer able to continue in that role. So I'm teaching myself JavaScript and web development with the aim, ultimately, of securing (ideally) remote employment as a developer.

On this blog, for the most part, I will be writing about my experience learning the dark arts of web development. My main focus for now, as far as I can tell, is going to be on JavaScript. I'd like to get a handle on JS itself before branching out and looking at some of the more popular frameworks like Angular, React (I'm really looking forward to sinking my teeth into this by Brian Holt), Ember, etc.

I also might be talking about my experiences as a person with a disability (PWD). I require the use of mobility aids to get around (full-leg prosthesis (L) and one-point walking stick) and suffer from chronic pain because of scoliosis. This makes life difficult, to say the least. I hope that by talking about it, it'll prove cathartic for me and perhaps, just maybe, it'll let someone else know that they're not alone in their struggles.

Hello World!

This is the first post on my new blog. I built this site in large part (i.e. almost completely) by following along with Travis Nielson of DevTips's series "Design+Code My Personal Site in 12 Hours". If you're interested in Web Development, I highly recommend the DevTips channel. It's great.

At the time of writing, this site is not actually live. I'm building it now, and once it's a little more presentable, I'll upload it to the web. Until then, enjoy not knowing I exist!