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.

RailsConf 2013 – Notes and Review

Quick Thoughts



Great speech.
Ruby community pioneers.
We don’t stay in “Kansas” although there is nothing wrong with Kansas. Tradeoffs.
Great frameworks are extracted, not invented.
Rails driving vision is hyperlinked documents.
The web is the platform, not a delivery system.
Flash is a failure, flash clones are failures, apps will ultimately fail.
HTML and the web are the past, present, and future.
Speed is what is most important to users.
Speed is achieved via extensive, aggressive cacheing.
Russian doll approach.
Javascript decoration is necessary.
Client-side Javascript will grow.


How Shopify Scales Rails
Interesting talk.
Mostly above my head.
About scaling, of course, deployment, configuration. Tweaks.
Workers, Redis, Resque, Unicorn.
Good summary here:
Talk here:


Nobody Will Train You But You

Disappointed with this talk.
Copy and memorize a good tutorial.
Memorization is undervalued.
Write on notecards what you look-up on SO.


Simple and Elegant Rails Code with Functional Style

This talk was utterly boring.
I remember literally nothing from this talk. Really excited by the topic title, but it did not live up.


Front-end Testing for skeptics

This was a good talk.
Javascript now works.
Epic full stack testing post:


Real Time Rails

Another good speaker.
This talk was mostly about deployment, which I’m pretty light on, so above my head for the most part.
Still interesting ideas.
Puma as a web server.


Building Extractable Libraries in Rails

Good talk.
Treat you lib directory like a temple.
Be ready to extract logic in lib to a gem at any moment.
Doman Context Interaction. Awesome.
Fake classes as test doubles. Or structs as test doubles.


Michael Lopp

Lame talk about how being a “Volatile” is good, being a “Stable” is bad, but not really, but yes really.



Yehuda Katz

Cool talk.
Everyone agrees more client-side Javascript is the future.
Nearly one Mb of Javascript != Sprinkles of Javascript.
Ad-hoc javascript is not cutting it anymore, we need to evolve to a structured Javascript framework.
There is still need for server side processing.


Rails Vs. The Client Side

Very good talk.
Most current innovation is on the client side.
Where does the app live: client-side or server-side? Lines becoming meshed.
Stop Hiding from Javascript
Stop ad-hoc Javascript
Don’t use Backbone.


The Magic Tricks of Testing

Very cool talk.
One of the most practically useful talks in the conference, along with the Pry talk.
Don’t conflate queries with commands.
Space capsule idea for object testing.
Do not test internal object messaging.
Do not test outgoing messaging.
Test incoming messages, receiver is always responsible for test verification.
Test interface only.
Avoid temptation to over-specify just because you can.
Test doubles should stay in sync? #need to look further into this


From Rails to the Web Server to the Browser

Not a fan of this talk. Pretty dull.
An explanation of Rack’s function, request-response cycle.
Other web servers.


What Ruby Developers Can Learn From Go

Pretty good talk.
Go has a very strong agenda.
Treats errors as normal.
Methods have multiple returns.
Encourages use of lots of well-defined packages and libraries.
Learning new languages gives you context for appreciating features in other languages.
Learning new languages allows you to abstract what’s common to all languages.


Ruby Libraries Important For Rails

This was a tutorial section with the great Michael Hartl.
This tutorial was way basic, for very new rubyist and it was hard to keep interest.


Pry – the Good parts

Awesome talk, really good.
Pry is a clear step up from IRB and print debugging.
My takeaway is I need to start using Pry now, get over the slight learning curve and use it.


James Duncan Davidson

Somewhat interesting talk, I guess, not really technical more about the possible unrecognized global impact of our efforts and his travels. Or something.


Firefighting on Rails

Really fascinating talk.
One programmer, who happens to be a volunteer firemen, taking initiative to develop a most basic app to upgrade the archaic system in place for alerting firemen of emergencies.
Emphasis here was it doesn’t have to be pretty to be useful, he built his system paying attention to only the most critical minimal requirements, all crushed together in one weekend, and it had a significant impact on his work, and the ability of firemen to respond to calls.
Really inspiring. I want to look into the repo and see if I can help.


Your First Rails Pull Request.

Excellent talk.
The speaker went over all the details necessary to make a pull request to rails, shared his particular story, talked about motivation for doing so.
Stressed how much he learned about rails by putting the effort into doing a pull request.
It’s not easy though, there are no easy issues.
If you do the work, your chances of getting accepted are high.
But you could get rejected.
But you still win by learning in depth about Rails.
You can also submit fix issues with one of the many supporting gems.
Use easy way set-up
Vagrant. Virtual Box.


DevOps for the Rubyist Soul

Good speaker. Interesting talk.
Deployment focused, so just tried to absorb what I could.
Puppet and Puppet Configuration.



How to Talk to Developers

By far the most awesomest talk, performance-wise, of the conference.
Mostly tips on public speaking.
Keep forearms at 90 degrees. One hand in pocket is okay, Two is not.

Better summary -
Power Pose.
Singing Happy Birthday.

TDDing iOS Apps for Fun and Profit with RubyMotion

Really loved this talk.
Went through the steps of using RubyMotion to build a simple to-do list app
You get to use Ruby to build and iOS app (mostly). How cool is that?!

My big takeaways:

- I need to learn Javascript – Now.
– I need to find out everything I can about cacheing.
– I should learn more about deployment.
– I want to attend RailsConf in 2014. Its a great way to get a glimpse at the state of the industry from the best minds.

Appointment Sheet Submitted

I submitted the pull request for my appointment sheet feature. It’s still a work in process, but I think its at a minimally functional level where I can benefit from the ass-whiping constructive criticism of my colleagues.  Here is a screen shot of the sheet as it looks now:

I was able to get most of the data they wanted, some I could not for various reasons.

I was able to get most of the data they wanted, some I could not for various reasons.


Get every new post delivered to your Inbox.