Node File System

Alot of work today so didn’t have much time to commit to study, but almost finished “Node the right way” chapter 2 which goes over Node’s File System module. Reading, writing, using events and handling errors.

Working and Learning Javascript

I’m mostly a javascript developer these days. Although my company utilizes Rails as the UI of choice for their back-end APIs, the rich set of functionality demanded by the UI means most of the new code is done in havascript.

I had a crash course in Knockout.js when I first got here (along with a dive in the JS deep-end, at least relative to where I was at the time) and have spent most of the last year that I have been here writing production code, trying to minimize my mistakes and, when I had time, learn more javascript.

Further, our company is transition to a full-on Ember, Node, and MongoDB stack, so mastering javascript has become even more important.

JS can be a difficult language to get a complete handle on, though. Async, “this”, closures, prototypes: these concepts can take a bit to get used to, and even more to be able to use fluently.

I haven’t blogged much here. Work has taken priority and, honestly, coming up with coherent thoughts at the end of the day can seem like work itself. But I think it’s in my best interest to record how this goes so I can look back and gauge where my learning is and has been going. Or something like that.


Today I did an hour of “Node.js: the Right Way”, chapter 2 specifically. Building up a file-watching utility. I’ll probably have more to say about it later on this week.

Replication Server Project

I’ve spent last week and this week building a single page “dashboard” application as my first project here at Cogility. The following is a recap of how it went:

Day (-1) – September 6th – Friday

I got my laptop the previous Tuesday, and spent about a day getting my development environment up, and the rest of the week getting Cogility’s rather elaborate environment configured. At the close of this day I still hadn’t gotten my laptop completely ready to move forward (thanks to an Oracle version issue). I did meet with a colleague to go over the requirements for the application, sketching it out on a whiteboard about what info is expected where.

Day 0 – September 9th – Monday

After spending nearly the whole of the previous week on setting up my development environment, I finally got that squared-away in the morning. In the afternoon I initialized my Rails app and got it talking to all the services it needs. I browsed over similar applications that have been built here for a decent idea of how to work in their specific set-up (we don’t have traditional models, per se, data calls are made through web services via a server application that hosts the database).

Day 1 – September 10th – Tuesday

Using Bootstrap, I laid out the basic format of the app. Its basically three columns with two tables, vertically arranged in the first column, and a single table in each of the second and third columns. The web service calls I needed for the data were not built yet, so I used the Faker gem to populate the tables so I could continue to work on the UI.

Day 2 – September 11th – Wednesday

Getting the basic layout down, I implemented collapse-ability of the data tables, using Bootstrap’s collapse.js functionality. I sent a rough version of the app to my colleague, specifying my “ideal” data calls (faking them out was a really good way to find out exactly how I’d like the data to be delivered). It looked like this:


Day 3 – September 12th – Thursday

A variable refresh rate was a key feature that needed to be implemented with this app. It turned out to be a good deal trickier than I originally planned. Through no less than three different attempts, I finally found the right combination of functions, callbacks, AJAX and jQuery to get the job done.

Day 4 – September 13th – Friday

I needed to change some of the styling to get the app to blend in with the overall application suite it was going to eventually be a part of. I implemented sorting, another key feature, with the tablesorter.js library, which wasn’t without it’s hiccups due to the dynamic nature of the table’s content. By the end of the day the app looked something like:


Day 5 – September 16th – Monday

Using jQuery, I made the refresh rate options capable of being hidden with a nice animation. I had a scattering of odd bugs to address, and made some slight enhancements here and there.

Day 6 – September 17th – Tuesday

The web services were built, allowing me to hook up the tables to real data. With a small bit of server-side processing the data rolled out smoothly. I had to make a few adjustments to the app, take care of situations were no data was available, and polish out a few of the odd bugs introduced. We’ve tested the application with new data uploads and the app seems to be working as specified in my colleague and I’s meeting the Friday before last. I will demo the app tomorrow for the engineering team, hoping it goes well.


Thursday – Half the day I was working through the more complicated Knockout JS examples. The other half I helped interview a Senior Rails Developer ( I created a basic programming assignment for him) and worked through the JQuery course at Code School.


Friday – Worked through the rest of the JQuery course. Worked on a few JQuery topics.


Yesterday – Built a basic Rails app in the morning to freshen my knowledge for an upcoming assignment. I created a Hodgepodge app where I will be explicitly practicing stuff. I got my new computer mid-morning and spent the rest of the day setting up my workspace and development environment.

Today – I’m almost finished with my personal development environment configuration stuff. Cogility has a fairly elaborate procedure to get their development stuff built up. I’m going to be working on that today.

Writing Knockout.js; Hellish DMV

Spent this morning trying to write my own versions of the live examples on the Knockout.js website.

Then I had to go to the DMV to order a new driver’s license (the old one had my DOB off by a day…really.) Which to a shade over four hours. Here’s to a better day tomorrow.

More Knockout.js

Knockout.js has some truly excellent documentation. Although its a pretty powerful framework, it’s actually fairly simple to understand. I was able to take notes on all the docs this morning. I wanted to get a full feel for what Knockout can do and how it does it.

I spent the rest of the day working through their live examples. It’s one thing to have a good conceptual understanding of a framework, getting the common syntax and idioms burned into your fingers, however,  is a much greater, though more satisfying, challenge.  Given the title for each example I tried to build them with what I already knew of Knockout, and only peeked when I absolutely had to. I then deleted all the code and started from scratch again, repeating this process until I could write the whole solution from my head.

I will work through the four live examples left tomorrow. These are the most detailed examples and it should be fun. I will then move on to other JS stuff and get up to speed with CoffeeScript, since we use that with our UI too.

First Day at Cogility Software; Knockout.js

Today is my first day working at Cogility Software. I’m going to be helping them expand their interface for an application that tracks IEDs and other events for the U.S. Army. I got to take a look at what my colleague Tien has already built and its pretty amazing. I assumed since this was a government-military application, the interface would be efficient but dry and bureaucratic. Tien, however, has built a modern interface full of client-side behavior and heavy on Javascript.

He makes extensive use of various JS plugins and frameworks, one being Knockout.js. I’ve spent all of today deep-diving in Knockout, learning about observables, binding and the MVVM architecture. It’s been a pretty enlightening day. I’m looking forward to filling out my front-end skills, learning JS in depth and helping to make this already awesome UI even better.

Importance of demos; Projects that I’d like to build

I’ve been going through some interviews lately, attempting to convince would-be employers of my skills as a software developer. One key factor that I noticed every time I finished an interview was the power of having a demonstrable project that you have built yourself. Its important that the project is deployed, and that the code is solely your own. Even though I have spent over a year helping to build a complex application for the National Children’s Study, it was a checkers game that I deployed on Heroku over a year and a half ago that I kept leaning on to show potential employers what I could do. Even though the code I wrote for the NCS is openly available on Github, its potency as testimony of my competence was significantly diminished by the fact that it wasn’t all my own code and demonstrating it was tedious and piecemeal. The checkers game was all my code, it was visual and it was very quick to demonstrate.

Most interviews don’t last more than an hour or so, and, with lots of other things on the agenda in that compressed period of time, demos need to be quick and powerful. And you should have demos. Its good to be articulate when you answer their questions, but the persuasive power of a visual demonstration far surpasses any kind of lengthy verbal exposition. Knowing that the checkers program I was demonstrating did not accurately reflect the growth I have had in the past year and a half killed me.

Good projects take time, though. I wrote the checkers program as an intern where I had many hours to devote to personal projects for the sake of developing my skills. That has not been the case for the past year since, as a professional, I needed to spend most of my time working productive tasks for the company. Even though the code was readily available on Github, most interviewers have neither the time or the inclination to sift through it.

So I have resolved that I will build some projects that reflect the current state of my skills. I will also use these projects, as I did with the checkers program, as learning tools. Here are a few ideas I have had for projects:

  • Blog –  Which t will eventually takeover the role of this WordPress blog. Its slightly embarrassing that, as a professional web developer, I don’t have my own version of the most basic web application types. This blog will function much like this one does, only with a page devoted to project demos.
  • Retirement Planner – Its dry, but there are lots of opportunities to build some interesting models, try out some different back-end configurations and its useful to me.
  • Dashboard – I have this idea of a interactive continuous calendar that will track metrics that I consider important in my life.  I built a paper tracker to keep track of new habits I was trying to incorporate in my life. A friend at work suggested I check out the Quantified Self movement, and that further inspired me to create this application. This will server as an excellent opportunity to work some front-end stuff, HTML, CSS for sure and a good deal of JQuery or other Javascripty things.
  • Exercise Log – This should be a good project for practice throughout the stack.
  • Weather Gambling – It’s a silly premise, but it would be good to practice managing users, authentications and authorizations, etc. that I don’t get as much with the other applications that are primarily about my own interests.

I’ll probably have other ideas and I’m hoping to record them here.

Working Remote

I officially started working remote today.

I’m moving to the Los Angeles-Orange County area this Saturday. My accomplished, successful and beautiful wife is in Sales, and her company has reassigned her to the Southern California territory.

Given the hassles of doing a move (even when it’s a full-service ultra-plush corporate style move) I asked if I could start working remote this week and they agreed, which was very cool. Really excited about the possibilities that open up here, I basically get back three and half hours of my life every workday that I would otherwise lose to commuting.

Right now I’m just trying to stay productive while attending to the move. I will be better set-up next Monday when we get in to the short-term housing they have for us.

Enough of the lifestyle, let me talk about I’m actually doing.


So we have a Participant type, which, up to somewhat recently, has only been created when a pregnant women has entered the study. Now their children, after birth, are also participants. There is a record called the PpgDetail that assigns the participant to a certain group, based on her pregnancy status. This record is auto-generated when a new participant record is created. Obviously a child participant should not have a PpgDetail record.


Remove the auto-generation of the PpgDetail record in the case of a child participant creation. Sounds simple, though many complicated issues begin as simple problems.

First Day Back in the Office

I went to Portland last week for RailsConf, and Los Angeles the week before in preparation for my upcoming June 1st move. I’m now back in the office for the first time in over two weeks and it feels really good.

My first order of business is to set right a few issues with my appointment sheet feature that I heard about while I was away.  I presumed that an appointment sheet must have an event and an event time, or it wouldn’t make any sense. While most of the lesser components of an appointment sheet, i.e. contact info. upcoming appointments, etc. have some sort of message when empty, I didn’t build in any “empty” behavior for an event or event time. So when these things are missing, the application just breaks, which, in hindsight was a mistake. I wasn’t sure what the behavior should be in the case these things are empty, I believe I thought then that it should “break” since I thought of those components as critical, but I should have realized that breaking the application was not acceptable and sought clarification for what should happen when these attributes are missing.

In any event, the appointment sheet feature has not deployed and I can still fix it, which I am doing now.