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.