App Challenge Day 1: Down The Rabbit Hole

Getting right into things today I decided to make the jump-off point PHP. It’s my most familiar and comfortable language so why not begin there? I haven’t yet worked with the Symfony2 framework but I hear good things and I’m obviously new to Ember.js for the front-end so that should be a fun experience.

A quick google search recommends getting started with Composer. This is PHP’s answer to Node’s NPM – a dependency manager. In theory, with a couple commands I should be able to install Composer and then install the Symfony2 framework along with any other libraries I should want to use for my project.

Another goal of mine today was to make my dev environment strictly cloud based – text editing notwithstanding. So I began by launching and configuring an Amazon Linux AMI EC2 micro instance.

First thing to do was to install Apache, MySQL and PHP which is all pretty standard stuff. Next off I grabbed Composer. Commands get a little funky because I have to essentially “sudo” everything (I know just enough Linux to get myself in trouble). I landed on a site which had me install Composer into the /usr/local/bin folder, although other tutorials that I saw presumed that the “composer.phar” file resided in the webroot folder.

After Composer was installed then I ran composer to download Symfony2 and initialize a project. Eagerly I ran to fire up my instance’s freshly associated IP Address only to run into a handful of problems both in opening up the proper ports in the AWS security group and subsequently tinkering with Apache’s httpd.conf hosts so it played nice with Symfony.

There were two additional hiccups, both AWS related. The first was that the PHP installed did not have a default timezone. I had to modify the php.ini file, uncomment the line and tell it to set my timezone to “America/New_York”. Secondly, it was yelling at me for not having permissions in the “log” and “cache” directories inside the app folder.

At this point Symfony was yelling at me for trying to access it from an external IP address since it’s set up for localhost dev connecting only in this mode… so I commented out that safety feature in the app_dev.php file and presto.. the default Symfony Hello World App welcome page.

I wrapped up the hour or so I had to work with by installing git on my EC2 instance, committing the project directory/webroot and pushing that to a new repository I made up for this project.

In order to be as flexible as possible in this cloud dominated world of webapps, I want to familiarize myself with all of EC2′s quirks and force myself whenever possible to provision, configure, and troubleshoot getting my apps up on the fly. If I had all the time in the world, digging much deeper into Linux would probably yield some really great results. As it is, I’ll learn what I need to know when I need to know it.

Triple App Challenge – The Process

The following three steps will be my guide posts as I build, and re-build, this web app.

A) Build out UX wireframes.

First I will look up some tools online to help me spec out the site, page by page, feature by feature so that it’s easy to visualize exactly how the simple app will flow, I’ll know how many “pages” I need to build and I can get a sense for the overall complexity. I’ll determine what are my minimum requirements to call it version 1.0 and I’ll have a general sense of how the design is going to go.

Keep in mind, I am NOT a UX guy, so this step is going to be clunky and foreign to me. But since I’m going to be building the same thing three times, it makes the most sense to spend the first week or so just plotting out exactly what the “what” is.

2) Draw up the design comps.

Enter the Photoshop. If doing some wireframes was foreign to me this step will be another planet. But I’m working as a one-man band for this operation so design by me it is. I’ll have the UX wireframes to reference so likely I’ll first take a look around the web for some similar apps, or some folks with a good design aesthetic in general and see what I can glean from that.

Once this stage is complete I will have fully visualized the exact pixel look and feel of the app for both smartphones and for tablet/desktop browsers. I’ll probably slice up, optimize, and save out all the image bits on this step. Additionally, I’ll mock up a very simple style guide for the project.

D) Code, Commit, Repeat.

Just code it, right? I’ll probably break this step up into further pieces later on down the road but for now let’s keep it simple. First I’ll spend a day or two diagraming up the data schema, since that should be consistent throughout whichever frameworks and languages I’m using. Then it’ll be time to crank it out. I will keep a careful log of time spent and assess how easy/fun/efficient each method was.

Estimated Timeline:

UX Wireframes – 1 week
Design Comps – 2 weeks
Data Object Modelling – 2 days
Build 1 – 3 weeks
Build 2 – 3 weeks
Build 3 – 3 weeks

The weeks are in real time but if I had to venture a guess, each “week” would wind up being no more than 20 hours.

Coming up next: Kick-off and Livestreaming.

The Summer Programming Challenge

I have a simple web application that I want to build (don’t we all?) but I run into the familiar problems of having a day job, not being sure what language or platform to build it in, and carving out the time for myself to actually build the thing.

The application itself is nothing world changing. Elevator pitch: it’s a session time tracking, budgeting, invoicing helper for my wife’s private practice therapy business with a few personlized features that would make it extra valuable to her.

So then I sit there and in my precious few moments between working with a software team during the day and putting the kids to bed at night I twiddle my thumbs reading Hacker News or other gossip rags about that latest and greatest Javascript framework or Google’s newest coding language that’s going to change the world guaranteed.

Well, that indecisive waffling ends here today. I’m going to build that app. Actually, I’m going to build that app THREE times. Enter the Three Month App Challenge. Each month I will put code to paper and write the application from the ground up using a different backend-frontend pairing.

If it sounds ridiculous, that’s because it probably is. There’s no sound business sense in doing things three different times three different ways and having roughly the same thing to show for it. But what it will do is force me outside of my comfort zone to learn new ways of programming, with no mindset other than “execute and deliver”.

The Challenge:

Build one web application three different times using three different languages/frameworks/methodologies over three months.

Candidate Backend Languages:

Candidate Frontend Javascript Frameworks:

This sounds great. I’ve got myself all amped up and ready to rock and roll. But it doesn’t solve one primary trouble – the time, energy, and motivation factor. Changing habits is hard. Really, truly difficult. And that’s why I’ve got a secret plan up my sleeve this time!

I’ll see you at the starting line next week.


Avoid using console.log in Internet Explorer!

Subtitle “at least when releasing production code“. I also considered naming this post “Another reason why I’m really going to miss Flash“.

A funny thing happened to me on the way to testing browser compatibility today. My javascript seemed to completely disappear on me when running in IE9. So I popped open the developer tool console in IE9 and suddenly… *poof*…. my code was working correctly. I shrugged it off as a fluke after looking at it closely.

I went back to finishing up the code and then went back to give it one last pass. And again, code was completely non-functioning in Internet Explorer, that is, until I opened up the dev tools.

At that point I had to investigate further (i.e. google), and here are the stunning findings courtesy of T.J. Crowder on StackOverflow:

On IE8 and IE9, the console object doesn’t exist until/unless the developer tools are open. Strange but true.

You should be getting script errors along the lines of “console is undefined” when you don’t have the dev tools open.

Well now I know better.

Node.JS Up And Running In The Cloud – on Amazon EC2

I got the information for this post from another blog post by Kostas Mavropalias, which was super helpful and insightful. All credit to him!

It’s not much good if I can only build and test node locally. Deploying to the web is an integral part of development. For Node.JS the options are a little tricky as of today. Services such as Nodejitsu are cool and have their perks, but there are limitations such as being an invitation-only beta and the trade-off of black-box platform-as-a-service deployment. Hosting companies, even excellent ones such as Dreamhost, don’t allow you to run background processes such as Node unless you pay for premium services.

The solution I’m liking so far is using a micro-instance on AWS EC2. For the sake of brevity, this post will assume that you already have set up an AWS account, have launched an EC2 Linux instance, and have shell access to said instance. In a later post, I plan on going over that process step-by-step. For now, we’ll begin from the terminal, having SSH’d into our instance.

First we run the basic updates:

[gist id="2957236" file="01-Initial-Updates.txt"]

Next we clone the Node build files and run the installer. The “make” step can take twenty or more minutes to complete.

[gist id="2957236" file="02-Git-And-Node.txt"]

Once we’ve installed Node, we have to make it accessible to all users using sudo commands.

[gist id="2957236" file="03-Making-Node-Available.txt"]

Now that Node is globally available to us from the terminal prompt, we need to install our package manager, NPM:

[gist id="2957236" file="04-Install-NPM.txt"]

Lastly, you should install all of the node modules and packages that you’ll need for regular use. Of particular importance is Forever. This is what will allow us “set-it-and-forget-it” execution of Node processes so as to have a “real” server!

[gist id="2957236" file="05-Node-Packages-To-Install.txt"]

Now our EC2 instance has a full Node.JS capabilities, congrats! My suggestion is to make yourself an AMI of the machine in this state from the AWS console so that you can quickly boot up to this point when testing projects in the future, it will save you the build time and headache.


Hi, I’m Kit Phelps and I like making software on the web. It’s been awhile since the last major overhaul to my webpage, and I figure if Batman and James Bond can pull off a reboot, so can this simple portfolio page.

I’m currently enjoying my days as a product manager with an ed-tech start-up Late Nite Labs in the heart of New York City. There’s a tremendous team over there and I hope to be able to share some technical insights for some of the fun things we’re putting together.

In my spare time I’ve been digging into Node.JS (particularly multi-user functionality via websockets in Socket.IO) as well as some native iOS programming.