Monthly Archives: May 2012

Reloading changed files during development with Sinatra

While developing Sinatra applications, to reload changed files I’ve been stopping the server (Ctrl C) and restarting it (Rackup), wasting precious time with every change. Today I finally went ahead and added the Reloader extension. Here is how:

Install the gem on your machine (I didn’t add it to the Gemfile since I don’t need it on production):

$ gem install sinatra-contrib

For the simple wedding website that I am working on, a classic Sinatra application, I’m simply requiring it through:

require "sinatra/reloader" if development?

For the modular application that I’m building at work, I added the following code to require it:

require "sinatra/reloader"

class MyApp < Sinatra::Base
  configure :development do
    register Sinatra::Reloader
  end
end

That’s it! Either application will now reload the changed files with every incoming request. If you need to restart the HTTP server on every request check out shotgun.

Sources:
What happened to reloading in Sinatra 0.9.2?: http://www.sinatrarb.com/faq.html#reloading
Sinatra::Reloader: http://www.sinatrarb.com/contrib/reloader
Shotgun: http://rtomayko.github.com/shotgun/

Apprenticeship week 13

This post was originally posted on Trunk Club’s tech blog at http://techblog.trunkclub.com/post/25244797215/trunk-club-apprenticeship-week-13.

What a great week: I just built an entire Rails app from scratch for Trunk Club. GeckoBoard was not giving us enough flexibility and the charts were too big for the largest widget size allowed. So I more or less built a custom version of GeckoBoards for Trunk Club.

Thanks to the Sinatra app that I built last week it was easy to just get the data by calling the API that we used to push data to GeckoBoards. After the initial setup, I spent a big part of the week on implementing Highcharts (fun) and I spent the other part of the week working on the look and feel of the app with SASS (more fun). And I also implemented a feature to send a daily email in the morning to stakeholder so that they see yesterday’s KPIs on their way to work, a feature to export a dashboard to pdf to share it with others, and authentication through Devise using our employee database. Woo!

I keep feeling like I need less help. I still get stuck but not against a wall, just slowly making progress and eventually getting there. However, the week was pretty long and I haven’t been really good at pacing myself or doing apprenticeship tasks such as reading and bogging. I think it’s ok every now and then but I don’t want to get burned out either.

Next week: resuming blogging, moving on to another project, planning for four months apprenticeship review.

Apprenticeship week 12

This post was originally posted on Trunk Club’s tech blog at http://techblog.trunkclub.com/post/25203856230/trunk-club-apprenticeship-week-12.

This week I built my first Sinatra app! It was refreshing to work with such a simple and lightweight framework. I also got my own Heroku instance to deploy the app, which will allow me to circumvent our usual weekly release cycle in favor of daily code releases while we build up the application.

The main purpose of the app is to run specific queries on our main database to extract KPIs and then output the data in json to be displayed in Geckoboards or another application that would call the service.

In retrospect, I kinda regret that Mike set this Sinatra app up to help me get started. It was simple enough that I should have done it myself. But it makes sense that I still need help.

Since I’m going to work with Sinatra for a little while, I picked up Sinatra: Up and Running by Alan Harris and Konstantin Haase. It’s a short book, with a good section on the basics that can serve as reference. It also features an interesting section that digs deeper into middleware and modular applications. I’ll report on it soon.

Next week: replacing GeckoBoards, finishing deadline.

Book: Passionate Programmer

This week I finished reading Passionate Programmer by Chad Fowler. While reading it I found myself highlighting a lot of snippets of the book, so I’m going to use this blog post as a reference and put down all the sections that I highlighted. I’ll comment on my favorite ones:

On being a developer, what it means for your employer:
Your challenge is to become an obviously good investment. You will start to judge your own performance in terms of the business value you bring to the organization.

Coming from marketing/management I absolutely agree with that idea and am totally embracing it. I want to write great code, but not at the expense of the business. I try to bring value to the business by working on projects that have either a great impact or an immediate impact, or both. And I feel like this is even more important since I am a junior developer still learning a lot.

On the career of a programmer itself:
Schedule lunch with a businessperson. Talk to them about how they do their job.
Pick up a trade magazine for your company’s industry.
Look for industry websites that you can monitor on a regular basis.

Nice reminders, things you already know but forget to do when you’re focusing on coding.

On mastering the platform that you are working on:
It’s rare, and refreshing, to find a developer who truly understands the platform on which he or she is working. Applications are better and work gets done faster as a result.

On practicing:
Try a small project, twice. Try it once in your home base technology and then once, as idiomatically as possible, in a competing technology.

When you’ve picked the tool, allot yourself a small period of time each day to learn one new thing about the tool that wil make you more productive or put you in better control over your development environment.
You have to make time for practice.
Research model-driven architecture (MDA). Try some of the available tools. Look for somewhere in your work to apply the concepts of MDA if not the full toolset. Think about applying MDA concepts with just the tools you use every day.

I need to do a better job of working a little bit every day on my pet project, beebuzz, to repeat and practice what I learn.

On resources to practices:
TopCoder—TopCoder.com is a long-standing programming competition site. You can register for an account and compete online for prizes.
Code Kata, which are small, thought-provoking.

On being more efficient:
Pick a task you normally do repetitively, and write a code generator for it. Start simple. Don’t worry about reusability. Just make sure your generator saves you time.

I should probably start with learning bash scripting to create shortcuts for repetitive daily tasks.

On getting things done:
To be successful, raw ability wil get you only so far. The final stretch is populated by closers—people who finish things.
Parkinson’s law is an empirical observation—not an unescapable human mandate. A sense of urgency, even if manufactured, is enough to easily double or triple your productivity.
If you do more than what they ask for or you have already done things before they ask, you will delight them.
All of us can benefit from scheduling and tracking our accomplishments.
Simply setting a goal (daily, weekly, or whatever you’re capable of) and tracking this type of accomplishment can radically change your behavior.
The hurdle rate: The minimum rate of return on a project or investment required by a manager or investor. In order to compensate for risk, the riskier the project, the higher the hurdle rate. In the hedge fund world, hurdle rate refers to the rate of return that the fund manager must beat before collecting incentive fees.

On marketing yourself:
On the surface, marketing yourself is simple. You have only two goals: to let people know you exist and to let them know you are the person who can solve the tough problems that keep them up at night.
Start keeping a development diary. Write a little in it each day, explaining what you’ve been working on, justifying your design decisions.
Make a list of co-workers, bosses, and customers whom you don’t talk to enough. Put recurring appointments on your calendar to call and check in with them.
Make a list of your recent accomplishments. Write the business benefit for each.
Make your elevator speech, and memorize it.
Have a mission. Make sure people know it.
Writing about (and linking to) the stories in your aggregator that you find interesting.
Google yourself —Search Google for your full name in quotes. Look through the first four pages of results.

On getting started with contributing to open-source projects:
Take a piece of open source software with unit tests. Run the unit tests through a code coverage analyzer. Find the least-tested part of the system and write tests to improve the coverage of that code. Untested code is often untestable code. Refactor to make the code more testable. Submit your change as a patch.

On being better than awesome:
What can you do that would make you and your accomplishments like the purple cow? Don’t just master a subject—write the book on it. Write code generators that take what used to be a one-week process to a five-minute process. Instead of being respected among your co-workers, become your city’s most recognized authority on whatever technologies you’re focusing on by doing seminars and workshops. Do something previously unthinkable on your next project.
Try to do something remarkable on your current project or job. One way to experiment is to shoot for remarkable.
Do the work in a remarkably short time. See whether people “remark.” If not, why not? If so, in what ways? Fine tune the variables, and try again.

On reaching out to great people:
Really good people won’t mind if you want to know them. People like to be appreciated, and they like to talk about the topics they are passionate about. The fact that they are the professional or the guru or the leader or the renowned author doesn’t change that they’re human and like to interact with other humans.

It’s crazy how easy it is to get great programmers and business people to respond to you when you ask nicely. I have to take advantage of that more. And make myself available as well, return the favor.

On staying informed and current:
The process in this book is a loop that repeats until you retire. Research, invest, execute, market, repeat.
Carve out weekly time to investigate the bleeding edge. Make room for at least two hours each week in order to research.
Prototype new-tech versions of the hard bits of your current-tech projects to understand what the differences are and what the new technologies enable. Put this time on your schedule. Don’t let yourself miss it.

On enjoying the craft itself, not just the results:
One of America’s biggest problems is that it is a goal-oriented society. We’re a nation of people who are always focused on the outcome of a process, whether it is the process of learning, one’s career, or even a drive in the car. We’re so centered on the outcome that we forget to look at the scenery.
The real meat of your career is not the promotions and salary advances. It’s the time you spend working toward those advances.

That was one of my key realizations over the last few weeks: instead of having a good week/month or being happy when a project is successful, while I still enjoy these moments, now I love the tasks that I do daily, the work itself and not just the outcome.

On thinking about the long-term:
Before mapping out where you want to go, it can be encouraging and informative to map out where you’ve been. Take some time to explicitly lay out the timeline of your career. Show where you started and what your skills and jobs were at each step.
Books recommendations: The Miracle of Mindfulness by Thich Naht Hanh and Zen and the Art of Motorcycle Maintenance.
Focus on making whatever it is you’re trying to improve better today than it was yesterday.
Make a list of the difficult or complex improvements you’d like to make; they can be personal or professional. It’s OK if you have a fairly long list. Now, for each item in the list, think about what you could do today to make yourself or that item better than yesterday. Tomorrow, look at the list again. Was yesterday better than the day before? How can you make today better? Do it again the next day. Put it on your calendar. Spend two minutes thinking about this each morning.

Long road ahead, good planning will only help.

Apprenticeship week 11

This post was originally posted on Trunk Club’s tech blog at http://techblog.trunkclub.com/post/25201990811/trunk-club-apprenticeship-week-11.

Braintree’s CFO and two of their engineers came over on Wednesday for our team lunch to talk about how we use their service and what they have in their product pipeline. It was good to hear about their technology, their stack and their practices. Great company, great guys.

I finished reading Passionate Programmer this week. I really enjoyed it and highly recommend it to anyone who wants to start a career as a developer. It is full of good advice, examples and reminders. It is very pragmatic. I’ll write a blog post soon highlighting my favorite excerpts. Thanks Chad!

I also released the new sales report that I have been working on for the last couple of weeks. With the new features that were added to it, the finance team now has a tool that’s easier for them use to notify the company about the sales performance of every sales person. It’s also a more efficient way for them to do this daily task and will save them a lot of time. I do like that aspect of the job, making other employees’ job easier through the use of technology.

This week I feel like I turned a corner: things are easier and I can tackle larger projects. I’m less often asking “How do you do this?” so much, it’s more often “Is this how you do it?”. It feels good after two months of working pretty hard.

Next week: Building my first Sinatra application.

Presenter Pattern

I have to admit that I haven’t had a chance to implement a presenter but I am very intrigued by it after reading Jay Field’s excellent article from 2007 on it.

The presenter pattern strays from the Rails standard MVC framework. It creates a class representation of the view to simplify bloated controllers. Normally controllers (C) should present the data on the view (V) after pulling the data from the model (M). However, this can sometimes create overloaded controllers or even views that do some logic work that should belong in a controller or a model.

The presenter pattern offers an elegant solution to this by aggregating the data for the view:

From Jay Field’s example (until I can add my own):

class CompletePresenter < Presenter
 def_delegators :user_account, :name, :name=
 def_delegators :address, :line_1, :line_2, :city, :state, :zip_code, :line_1=, :line_2=, :city=, :state=, :zip_code=
 def_delegators :user_credentials, :username, :password, :username=, :password=
 def user_account
  @user_account ||= UserAccount.new
 end
 def address
  @address ||= Address.new
 end
 def user_credentials
  @credentials ||= UserCredential.new
 end
 def save
  user_account.save && address.save && user_credentials.save
 end
end

Thanks to this presenter, the controller becomes very light and simple:

class OrderController < ApplicationController
 def complete
  @presenter = CompletePresenter.new(params[:presenter])
  redirect_to thank_you_url if request.post? && @presenter.save
 end
 def thank_you
 end
end

I’m sure I can find a use for this and can’t wait to try it. I’ll update this post when I do.

I highly recommend reading Dmytro Shteflyuk’s article. It also mentions cells plugins, just as interesting. Let me know what you think!

Apprenticeship week 10

This post was originally posted on Trunk Club’s tech blog at http://techblog.trunkclub.com/post/25041531247/trunk-club-apprenticeship-week-10.

There was an interesting presentation at Geekfest today about being a better apprentice. Isaac Sanders, a high school senior interning at Groupon shared stories of successes, and lessons learned from his failures. He has spent the last year of his high school on an “Apprenticeship Tour,” working at EdgeCase and 2Checkout.com in Columbus, OH and at LeanDog in Cleveland, OH. He used a lot of chapters from Dave Hoover’s book on apprenticeships as discussion topics, elaborating on them based on his own experience. He is definitely a strong advocate of apprenticeships, with an interesting experience.

I had a bit of a setback with my month-to-date sales report project and spent a lot of time this week dealing with that. We had to re-think how it was going to be generated, which meant changing our database a bit and dealing with time zone inconsistencies. As disappointing as that was, it was very interesting to review my code from just a few weeks ago. I had to do a lot of refactoring and I felt like my code was getting cleaner and leaner. It was a long but meaningful exercise.

Next week: working on a new BI tool that was developed internally, finishing reading Passionate Programmer, launching the new sales reports.

Using git blame

Another nice trick from Sarah Grey: git blame. We were looking for the author of a strange code change that broke one of our tests. Git blame allows you to find easily who made what change in your terminal:

git blame file

There are more options available:

usage: git blame [options] [rev-opts] [rev] [--] file

–incremental Show blame entries as we find them, incrementally
-b Show blank SHA-1 for boundary commits (Default: off)
–root Do not treat root commits as boundaries (Default: off)
–show-stats Show work cost statistics
–score-debug Show output score for blame entries
-f, –show-name Show original filename (Default: auto)
-n, –show-number Show original linenumber (Default: off)
-p, –porcelain Show in a format designed for machine consumption
-c Use the same output mode as git-annotate (Default: off)
-t Show raw timestamp (Default: off)
-l Show long commit SHA1 (Default: off)
-s Suppress author name and timestamp (Default: off)
-e, –show-email Show author email instead of name (Default: off)
-w Ignore whitespace differences
-S <file> Use revisions from <file> instead of calling git-rev-list
–contents <file> Use <file>’s contents as the final image
-C[<score>] Find line copies within and across files
-M[<score>] Find line movements within and across files
-L <n,m> Process only line range n,m, counting from 1

Here is an example that shows my recent changes to a Gemfile:

Git blame example