• 7060fb7ac5a8ad3d4101bbb09ae89b1b?s=66
    05
    AUG
    2013

    Notes from the July Meeting of the Memphis Ruby Users Group

    by Daniel Pritchett

    Our local Ruby group got together again at Coroutine's Memphis office at the end of July with a good crowd and two all-new presentations. We had around 15 people show up for pizza and talks, including several new faces! Thanks everyone for making it a memorable meetup. This month's presentations were from regular attendee Jason Charnes and from me, Daniel Pritchett.

    Crowd shot of Jason's presentation

    Jason gave us a great walk through of his experience learning different statically typed languages in school and then drifting towards dynamic languages for his personal projects (and for work!). His presentation covered some of the highlights of the Ruby language and the Ruby ecosystem, from the natural-language feel of Ruby to the many libraries freel available via rubygems. See Jason's slides here.

    I put together a second presentation on xray-rails, a gem that helps me regularly when working on views for larger Rails projects. The functionality of xray is pretty simple when explained, but I had a good time digging into the internals of the gem to see how exactly it manages to inject HTML and JavaScript to views as they're rendered so that you can trace the source of each page element to a source template.

    Elsewhere in Memphis tech...

    • Java User Group organizer Thomas Langston dropped in on July's meeting. Their August meeting is coming up in ten days!
    • HackMemphis (September 14) is getting closer and still seeking volunteers and sponsors.
    • This year's TechCamp Memphis will be on November 2 at Southwest Tennessee Community College. There is an open call for presenters. Send in a proposal today - I did!

    How can I participate in the next MRUG meetup?

    There's lots of ways to help out: show up, give a presentation, bring a friend, follow us @MemphisRuby on Twitter. The next meetup time and location will be posted on Meetup soon.

  • 7060fb7ac5a8ad3d4101bbb09ae89b1b?s=66
    31
    MAY
    2013

    Catch up with the Memphis Ruby Users Group

    by Daniel Pritchett

    May meeting: Static sites in Ruby, JS testing tips

    Last week's second Memphis Ruby Users Group meeting featured great presentations from two local developers, Josh Lewis and Jordan Kasper. I was interested to learn that both presenters work fully-remote dev jobs.

    Josh showed us Fast Sites with Middleman, a gem for generating static web pages in Ruby. Josh built the presentation as a small site using Middleman and a presentation library called impress.js. You can find the presentation source on his github repo! We discussed a few options for static site hosting such as github pages and possibly Heroku.

    Jordan gave a live demo of some of the tools he's using to test his JavaScript applications: Grunt for running JS tasks (test suites!), PhantomJS to execute DOM tests in a headless JS engine, and QUnit for simple assertions. You can find a longer writeup of Jordan's JavaScript testing strategies on his blog. There were a lot of similarities between this JS testing style and some of the Ruby testing we do here at Coroutine!

    April's inaugural meeting: Background jobs with Resque, Android dev in Ruby with Ruboto

    Our inaugural MRUG meeting had a great crowd of nearly twenty people. Friends from @MemphisPython showed up to support the Memphis developer scene. Our two presentations were from Mike Cochran and Daniel Lissner.

    Mike started us off with a dive into asynchronous Ruby job processing with Resque. He recommended that a Resque-based job processing workflow pass minimal information - say a primary key for looking up a record that needs processing - to the Redis messaging server. Mike gave us a really neat look at how he's running a production app on Heroku using a Redis add-on to handle their worker queue. Since Heroku bills by the second he can dynamically spin up a bunch of workers when his backlog gets too big, and then shut them down when the backlog starts to shrink to a manageable level. Mike's Resque slides are available for you to look over.

    Daniel's talk took us through a crash course on building Android apps with Ruby using the Ruboto framework. Ruboto is able to expose all of the Android APIs via JRuby, so you won't be limited in the same way you might be by other mobile dev frameworks which only implement a subset of the native functionality.

    Elsewhere in Memphis tech...

    • Community organization for HackMemphis is ongoing with weekly meetings and a target date of September 2013.
    • Congratulations to the SeedHatchery 2013 cohort on their recent demo day!

    How can I participate in the Memphis Ruby Users Group?

    The one thing that keeps a community like this going is participation. Attend any meetings you can and invite your dev friends. Presentations are always welcome - we still have a speaker slot open for June!

    Follow @MemphisRuby for regular updates on upcoming meetups. Information on upcoming events will be at Meetup.com.

  • 7060fb7ac5a8ad3d4101bbb09ae89b1b?s=66
    29
    MAY
    2013

    TDD and the Half-Life of Information

    by Daniel Pritchett

    When one programmer questions another's proposed feature idea with "YAGNI!" she's just trying to help everyone stay honest with themselves: The design path being followed is drifting away from the observable needs of the project. Information half-life may not be a concept we discuss often in software, but there are plenty of related tropes we do revisit day after day: Just in time compilers. Lazy evaluation. Continuous integration. Premature optimization. Lean startups. Iterative development. YAGNI.

    Each of these concepts is an application of the same basic idea: the older your plans and your intel, the farther removed they are from reality. This is why waterfall projects and eighteen-month gantt charts devolve into a painful kabuki where most participants go through the motions without any real expectation of success. This is why I like having a test suite that runs itself continuously while I code.

    Mission-critical applications

    At Coroutine we build mission-critical applications that other companies can build their businesses around. This means we have to build them well, in a timely fashion, and within budgetary expectations. Since old specs and old budgets are inherently imperfect, we have to realign our expectations continuously. Regular client communications. Daily stand-ups. Test suites that run throughout the work day. Continuous tests which verify that our applications are growing in the way we think they are without sacrificing existing features and expectations.

    Ruby on Rails has proven to be a solid choice for this type of central business-driving application. It allows us to get the rough outline of a system up and running relatively quickly. From there we work with clients to reshape plans and features and fill in the gaps and deliver the bespoke solutions our clients' businesses need.

    Since we're on Rails, I like a certain set of tools to keep my tests running smoothly. I'll be the first to admit that each of these tools was recommended by my coworkers and I'm not yet branching out to develop my own tastes, but this is what I'm using to get things done:

    Tests that run automatically

    Guard. Every time I save a file, the test suite runs from the current file outwards to the entire test suite (depending on my configuration and whether any tests have failed recently). This means I'm never more than a few seconds away from learning whether my current bit of code is doing what I think it's doing. This is me minimizing my feedback loops. Accepting the half-life of my information.

    Tests that run quickly

    Spork. Ruby tests sent to an always-on daemon that keeps my application's environment loaded and up to date. No more ten-second Rails environment load time before a thirty second test run.

    Tests that do exactly what they say on the tin

    RSpec. Shoulda. These descriptive testing tools speak for themselves.

    describe "A blog post about Ruby TDD with Guard, Spork, and RSpec" do
      context "Guard keeps the tests running automatically" do
        before { raise NotImplementedError unless Guard.present? }
    
        context "Spork preloads the environment for faster test runs" do
          before { raise RunTimeError unless Spork.present? }
    
          it "should use RSpec" do
            expect{ RSpec.configure }.to_not raise_error
          end
    
          it "should use Shoulda" do
            (2 + 2).should == 4
          end
        end
    
      end
    end
    

    Software that works

    I realize this post will be covering well-trodden ground for TDD devotees, but I really enjoy the work we do here. The constant feedback from my test suite is very empowering. I get to make visible progress every day and share it with clients who are just as happy about it as I am.