Swamped

Feeling swamped. Got a fair amount of feedback on my Appointment Sheet revisions, I have already made some adjustments, now I need to clarify all the issues brought up and get those resolved. I also have two other tasks on my plate but those aren’t slated until the next release. But I am still going to get those spiked because why not.

Feeling better. Squared away another round of fixes for the Appointment Sheet. I know it’s getting better and that feels good. This is a very feeling post. The other two things are child’s play compared to the appointment sheet.

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

DAY ONE

—-

DHH
—-
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.
Turbolinks.
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: https://gist.github.com/naoyamakino/5505169
Talk here: http://www.youtube.com/watch?v=j347oSSuNHA

 

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.
Capybara.
Phantom.js
Epic full stack testing post: http://blog.mattheworiordan.com/post/4701529828/full-stack-integration-testing-with-rails-3-cucumber

 

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.

—-

DAY TWO
—-

Yehuda Katz
—
Cool talk.
Ember.js.
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.

—-
DAY THREE
—-

—
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.
Vagrant

—-

DAY FOUR
—

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 -https://gist.github.com/jamesgary/5504200
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.

Railscasts #164

RC 164 cron-in-ruby

The whenever gem helps as a DSL interface to Cron to help with scheduling repeated tasks. The syntax looks a lot like ruby’s awesome time methods, and it has three built in types of tasks: commands, which are like bash-commands, rake tasks and a runner for calling class methods on objects in your app. You can also custom design tasks so that you can run javascripts if you’d like. You can also specify where all these activities get logged. It deployed easily through Capistrano.
Mentioned 271 for redis to do jobs. Then mentioned rescue scheduler, rufus scheduler and an alternative to whenever, clockwork.

I could see how these gems would be useful, especially in deployment, to run periodic clean-ups or inspections.

Appointment Sheet

We’ve been working on an app (Cases) that helps conduct the National Children’s Study with all sorts of supporting models: Participants, Persons, Contacts, Events, etc. What we don’t have yet is an aggregate summary that would help a data collector in the field conduct a single event with a participant. Something that would look like:

 

 

This involves collecting lots of data from the supporting models for a particular appointment. I have created the infrastructure and the wiring, now I am on to building up the queries in an AppointmentSheet model, test-driven, of course.

Past Week and a Half…

I’ve got to get better at this.

I’ve been working on Birth Cohort mostly, at least that’s what I remember most since that’s what I have been working on for the past couple of days. Specifically, I’ve been working on merging (at least partly) how we advance participant state. My previous iterations relied on the current implementation. I’ve spent the last couple days merging the advance method we use for advancing state from the field (iPad) app into our core app and dealing with the fallout thereforth (thereforth, I found out, isn’t actually a word) .

PersonRace record duplications; jQuery timepicker issues; Birth Cohort merge failure

Monday. First order of business is squaring away the duplicate PersonRace record issue. This problem is akin to the InstitutionPersonLinks duplication problem, in that its solution comes primarily in two parts: fixing the duplication, and creating a migration to remove existing duplicates (and adding a uniqueness constraint for prevention). The logic to prevent duplication was a bit convoluted because our process for handling race is convoluted. I finally figured it out last Friday. Today I have to generate the migration. So that’s what I’ll do now.

—

Completed the person_race task, made a pull request. Moving on to the next task.

Looks like the timepicker utility is not working correctly: its not saving or allowing 24 hour time. The first one I’m not so sure about, but the second I think is just a minor configuration issue with the jQuery plugin. Checking it out.

—

The timepicker is actually doing exactly as its configured to do (this is a very odd bug seeing how late we are into centers using the surveys, where these timestamps are on every survey – most times there are many of these timestamps – seems late to find this one).  This was an easy fix. Simple option in the jQuery function. Dealing with the second part of the bug is going to a good deal more difficult. It’s saving at odd times, seemingly at the selection of the datetimepicker tool, and doesn’t update when the time is changed, so that’s obviously a problem.

—

Had a mini-crisis, because I didn’t run the full CI suite of tests before my Birth Cohort branch was merged, it broke a number of tests in a section of code I didn’t run the tests in (but should have). The SampledPersonIneligibility record is created when a participant is deemed ineligible, but the Birth Cohort is different from the normal PBS participant. I had changed up the constituent eligibility methods to cope with this new fact, but failed to update the tests in SampledPersonsIneligibility. The fix was fairly easy, especially working on it with Paul. We were able to extract the part that was causing the failure into its own method in Participant, which prevented all the spec failures downstream. There is a hole, though, and I wrote up a ticket to address the inability of SampledPersonsIneligibility to distinguish between types of participants. That will have to wait until later.

—

Significant issue with my person_race branch that Rhett picked-up on: my current fix prevents any duplicate records, yet a person is allowed to have multiple “other” races. I need to fix the branch to reflect this behavior, which means: rewriting the SQL to not delete multiple “Other Race”-type records, remove the unique constraints

—

Rewrote the SQL command. It’s fairly gnarly.

—

 

Eat, breath and sleep railscasts

I’ve decided to go all in on Railscasts to take my Rails (web development) skills to the next level. I’m setting my initial goal of getting them all done (viewed, read, practiced, and blogged) in the next 6 months, although this might be too ambitious. We’ll see.

As a barely scraping intermediate developer with a solid professional year under my belt, the RailsCasts are exactly in my sweet spot for learning right now. I want to do them all and cover all the tangents they will inevitable take. This will be my main professional development focus until I complete them.

Past three weeks…

I always want to kick myself when I don’t stay in the habit of logging my work notes. My intermediate-term memory can hold for a rolling day or so, at best. Reconstructing what I’ve done in the past is a pain, but I’ll try anyway…

• I built a Birth Cohort feature – spent about two days researching the hell out of our event administering process, from the time a participant takes the eligibility screener, to the end of the Birth event, with the screener event in-between. This branch was chock full of learning as the process is positively huge, and involves some interation with PSC, where all the scheduling logic is located.  Basically, Cases handles the storing of the participants and the administering of the events, but PSC handles when those events are and what they are composed of. As an aside, in the middle of researching this feature, I started to build documentation of the process. I wanted to build an as-elegant-as-possible flowchart detailing the vast array of interactions involved in making the event administering process possible, but technically problems with the documenting software and the sheer size of the task quickly made this implausible. Instead I took extensive notes and then walked through the scenario with Paul. His help was huge, and afterwards, it was a fairly easy couple of steps to the solution. The code is currently on its own branch and hasn’t gotten any comments yet.
• I also finished up my MakeIneligible branch, which got over 50 comments before it was all said and done. It actually became the AdjudicateElgibility class (I truly love that name, Rhett came up with it) once it incorporated the conditional for eligibilitiy in the context class.

Now I’m working on a similar bug to the one I was working on the last time I blogged. This time its the PersonRace records that are duplicated. The mechanism for duplication was a little hard to arrive at, compared to the institution case, but, with some help from new guy Frank, I finally fixed the bug in the code that produces duplicate records. I still need to build the migration to erase existing duplicates, and then place unique constraints on the records themselves.