bgror

Planet Argon Podcast, Episode 3: How We Manage Bugs »

Created at: 11.11.2009 19:46, source: Robby on Rails, tagged: programming PLANET ARGON agile bugs lighthouse planetargon podcast collaboration clients

Earlier this week, we published Episode 3 of the Planet Argon Podcast. In this latest episode we responded to one of the ideas someone in the audience asked on this brainstormr, which was, “How do you manage bugs?”

We had a round table discussion about how we classify and prioritize bugs with our clients, ticketing systems, and other tools that we use to streamline this process.

You can listen to this on iTunes or online.

RailsOnPg released »

Created at: 22.10.2009 01:07, source: Robby on Rails, tagged: Ruby on Rails programming PostgreSQL PostgreSQL rubyonrails plugins databases

Hello fellow PostgreSQL and Ruby on Rails geeks,

Alexander Tretyakov (twitter) recently released a plugin for Ruby on Rails, which extends migrations and provides you with the ability to create.

• Functions (pg docs)
• Triggers (pg docs)
• Views (pg docs)

While you can already do something like this with execute in your migrations:

execute("CREATE VIEW my_tasty_snacks AS SELECT * FROM snacks WHERE food = 'Tasty';")

With RailsOnPage, you’re provided a DSL so that you can do the following:

create_view :my_tasy_snacks do |view|
  view.select     '*'
  view.from       'snacks'
  view.conditions 'food' => 'Tasty'
end

note: I haven’t tested the above, just a hypothetical example

Anyhow, if you’re in the habit of using views, functions, or triggers with your PostgreSQL database and are using Ruby on Rails, you might give RailsOnPg a whirl.

Tracking AJAX-driven events in Ruby on Rails for Google Analytics conversion goals »

Created at: 21.10.2009 21:09, source: Robby on Rails, tagged: Business Ruby on Rails programming ajax rubyonrails analytics javascript prototype kpi conversions

Tracking your KPI’s is extremely important in your online venture. At a minimum, you should be using something like Google Analytics to track conversions in your application. Setting up goals is actually quite simple, especially if you’re just tracking that specific pages are loaded. However, if some of your conversion points occur through AJAX, you might not be capturing those activities in Google Analytics.

Lucky for you, it’s actually quite simple to update this. I thought I’d show you a fairly simple example to help you along.

On our web site, we have a mini contact form at the bottom of many of our pages. When submitted, if JavaScript is enabled, it’ll perform an Ajax request to submit the form. If you fill out the main Get in Touch form that gets processed and we redirect people to a thank you page. The URL for that is unique and we’re able to track those in Google Analytics quite easily.

However, with the Ajax-form, the URL in the browser isn’t going to change so Google Analytics isn’t going to track that conversion. So, we needed to track that properly.

To do this, we just need to call a JavaScript function that the Google Analytics code provides you.

  pageTracker._trackPageview("/contact_requests/thanks");

Let’s look at some simple code from our controller action. If the request is from JavaScript, we currently replace the form area with the content in a partial. (note: if you’re curious about the _x, read Designers, Developers and the x_ factor)

  respond_to do |format|
    format.html { redirect_to :action => :thanks }
    format.js do
      render :update do |page|
        page.replace :x_mini_contact_form_module, :partial => 'mini_contact_form_thanks'
      end
    end
  end

As you can see, the redirect will within the format.html block will lead people to our conversion point. However, the format.js block will keep the user on the current page and it’ll not trigger Google Analytics to track the conversion. To make this happen, we’ll just sprinkle in the following line of code.

  page.call 'pageTracker._trackPageview("/contact_requests/thanks");'

However, if you need to do something like this in several locations in your application, you might want to just extend the JavaScriptGenerator page. GeneratorMethods. (you could toss this in lib/, create a plugin, etc…)

  module ActionView
    module Helpers
      module PrototypeHelper
        class JavaScriptGenerator #:nodoc:
          module GeneratorMethods
            # Calls the Google Analytics pageTracker._trackPageview function with +path+.
            #
            # Examples:
            #
            #
            #  # Triggers: pageTracker._trackPageview('/contact_requests/thanks');
            #  page.track_page_view '/contact_requests/thanks'
            #
            def track_page_view(path)
             record "pageTracker._trackPageview('#{path}');"
            end
          end
        end
      end
    end
  end

This will allow us to do the following:

  page.track_page_view "/contact_requests/thanks"

  # or using a route/path
  page.track_page_view thanks_contact_requests_path

So, our updated code now looks like:

render :update do |page|
  page.replace :x_mini_contact_form_module, :partial => 'mini_contact_form_thanks'
  page.track_page_view thanks_contact_requests_path
end

With this in place, we can sprinkle similar code for our various conversion points that are Ajax-driven and Google Analytics will pick it up.

Happy tracking!

The 8-Hour Rails Code Audit »

Created at: 20.10.2009 15:13, source: Robby on Rails, tagged: Business Ruby on Rails ruby programming PLANET ARGON code codeaudit agile programming planetargon audit

While our team is typically focused on larger client and internal projects, we do get an opportunity to assist businesses on a much smaller scale. Whether this be through retainer-based consulting or through code audits, we have seen a lot of Ruby on Rails code over what has nearly been… five years!? We’ve been able to compile a fairly extensive checklist that we use in our code audit process that we’ve decided to streamline it into a smaller product.

Historically, this service has ranged anywhere from $2000-6000, depending the size and scope of the projects, but we want to help smaller startups¹ and projects outline a roadmap for how they can begin to refactor and optimize their existing code base so that they can be more efficient at the start of 2010. So, we’ve scaled things down into an extremely affordable flat-rate package where we work off of a pre-defined number of hours.[2]

Through the end of 2009, we’re now offering the 8-Hour Rails Code Audit package for just $1000 USD (details).

We’re currently limiting this service to just two projects per week, so reserve your spot now.

¹ Larger projects are welcome to benefit from this service and custom quotes are available upon request.

² As always, we’re happy to discuss longer engagements.

Related Posts

• Audit Your Rails Development Team
• Rails Code Audits and Reviews, continued

There is no magic, there is only awesome (Part 3) »

Created at: 09.10.2009 19:48, source: the { buckblogs :here } - Home, tagged: Essays and Rants awesome keynote programming talk

This is the third article in a series titled “There is no magic, there is only awesome.” The first article introduced the “four cardinal rules of awesomeness”. The second article discussed knowing your tools.

Opening A.—Pass index finger of right hand distal to the little-finger loop, and passing round the ulnar side of that loop, bring it up from the proximal side into the thumb loop, and with the index finger pointing downard, take up with the back of the index finger the radial thumb string and return.

Even to string figure adepts, it can be challenging to parse those instructions. That paragraph is an extract from the instructions for an Eskimo Caribou string figure, written in 1903 by Dr. A. C. Haddon and published in American Anthropologist (you can read the whole thing on Google Books if you’re really feeling sleepless).

The original string figure notation described by Drs. Rivers and Haddon in 1902 used very technical anatomical terms to identify each finger, and the location of the string on each finger. As in that paragraph, you’ll see terms such as proximal (closer to the base of the finger), distal (closer to the finger tip), radial (closer to the thumb), and ulnar (closer to the little finger). These and other terms are used to describe locations relative to the fingers, as well as to name specific strings (“radial thumb string”) on the hand.

The strength of this notation is that it is very precise, and can be used with little need of external illustration. However, it is also fairly verbose, making it hard to parse without very focused attention and (potentially) multiple read-throughs. Also, the use of the technical anatomical terms makes the descriptions hard for novices to pick up.

To make her book more accessible to a larger audience, Caroline Furness Jayne (or “CFJ”) modified this notation so that “proximal” and “distal” were replaced with “lower” and “upper”, and “radial” and “ulnar” were replaced with “near” and “far”. (She left dorsal/palmar alone, for the most part, although in some figures she referred to the “front” or “back” of a hand or finger.) Her modifications introduced ambiguity, though, and required even more verbosity and copious illustrations to counter.

For example, she described the same movements (from the Eskimo Caribou figure) as follows:

First: Opening A. (The left palmar string must be taken up first). Second: Bend the right index away from you over the right far index string and over both strings of the right little finger loop and down on the far side of the right far little finger string; then draw toward you on the near side of the right index both right little finger strings and the right far index string, allowing the right near index string to slip over the knuckle of the index and to the far side of the finger. Now put the right index (still bent and holding the strings on its near side) from below into the thumb loop, by pressing the near side of the bent index toward you against the right far thumb string, and putting the tip down toward you over and on the near side of the right near thumb string. Pick up, on the far side of the bent right index, this right near thumb string, and lift it and the former near index string up by turning the index away from you and up to its usual position.

(I ommitted the illustrations for brevity’s sake, but if you want to see them, you can view the complete instructions here.)

The lack of technical terms is definitely an improvement, but the (significantly!) greater quantity of text means that the instructions require even more effort to parse. To combat this, the ISFA (International String Figure Association), in its publications, uses an abbreviated notation, numbering the fingers 1 (thumb) through 5 (little finger), and using other one-letter abbreviations for right (R), left (L), near (n), and far (f). They retain the use of proximal/distal in some cases, but also use “below”/”above” and “lower”/”upper” where it isn’t too ambiguous. The ISFA notation reduces the above text to this:

Opening A. R2 rotates away from you, over all strings, around 5f, then back under the strings, and proximally enters R1 loop. R2 hooks up R1n and retraces its path. (from http://www.isfa.org/arctic/30.htm)

This is much more concise, and is easier to scan. It settles on standard meanings of terms like “rotate away”, “hook up”, and “release”, which reduces verbosity, but also requires the reader to know how those words are defined in this context. Also, it is concise at the cost of specificity; there is often ambiguity that must either be resolved at “runtime”, or be countered with more verbose descriptions.

Two other notable attempts at describing string figures are SFN (String Figure Notation) by Eric Lee, and Mizz Code by Kyoichi Miyazaki (“Mizz”). The former is a variation on ISFA notation, employing various abbreviations to reduce verbosity, while the latter is an entirely new take on describing string figures that simply denotes how the string needs to move, without specifying finger movements at all. Both of these are much more concise than any of the others described above, but are also quite specialized and require some study before you can really make heads or tails of them.

So, that gives five different ways of describing string figure construction! How do you choose which one to use? Ultimately, the ISFA notation is the most widly used, as well as the verbose prose of CFJ (thanks to the popularity of her book). But a string figurist will benefit from knowing as many ways to describe a figure as possible, because each notation’s strategies reveal different insights into the techniques, and has different strengths in different situations. CFJ’s prose (if accompanied by a modicum of illustration) is good for beginners, because it does not require any specialized knowledge. The ISFA notation is a good general tool that allows people to quickly learn figures, with only a little training. And notations like SFN are great for quickly jotting down a figure as you learn it from someone else, or as you invent it yourself.

Really, as a string figurist, the more string figure languages you know, the more power you have.

Computer Languages

Thus, the second rule of awesomeness: know thy languages.

As a computer programmer, you’re faced with an even greater flood of languages than string figurists are. Even if you use primarily a single language, you might be surprised at how many incidental languages you use on a regular basis. Are you a web developer? Odds are that you dabble in both HTML and CSS, and probably Javascript, too. SQL is almost mandatory for most interactive systems. Furthermore, if you do anything at all in a text console, you probably know a little bit of shell script. Building your application and deploying it to production probably require a specialized DSL or two as well. And regular expressions are practically everywhere these days.

Despite there being more computer languages than string figure languages, the advice is the same: the more you know, the more power you have. And “knowing” is not merely “knowing about”. Look back at the four “knowledge gauge” questions from Part 2:

1. What does this do best?
2. What does this do worst?
3. Why should I use this in particular?
4. When was the last time I learned something new about this?

Take a minute and try to list all the languages you use on a regular basis. This includes even languages you use only tangentially, like SQL, regular expressions, Javascript, HTML, XML, CSS, and so forth. Try to answer each of the four gauge questions for every language in your list. If you struggle to answer any of them, consider that a jumping off point for further investigation.

If you aren’t really sure what a particular language is best or worst at, it may be because you aren’t familiar with enough programming languages to compare it with. You’ve probably heard the old saying, “to a man with a hammer, everything looks like a nail,” and that surely applies here. You may be at the pinnacle of guruship in your chosen programming language, but if that’s all you know, then you can’t give worthwhile advice on when that language should be used. You’re living in a house with no windows, and no matter how well you know that house, and no matter how big it is, you can never tell callers what’s just outside.

It’s been suggested by people much smarter than me that you should learn a new programming language every year. I can’t recommend this enough. I won’t deny that there have been years where I haven’t followed this advice, but every time I’ve spent a few months tinkering with a new programming language I’ve come away with my eyes open that much wider. It’s like having a lever, and finally discovering a fulcrum to use it with.

Learning a new language

Now, it’s all well and good to say “learn a new programming language”. It’s also remarkably easy to download the development kit for Ruby, Python, Java, Erlang, Haskell, or just about any other language you want to learn. And once you’ve started learning a language, the learning effect tends to snowball, so that’s not really a challenge either.

What’s hardest (for me, at least) is discovering a good “entry vector” into the language.

Here’s what works for me:

1. Find the documentation for the language. Look for a page or two that give you a glimpse into the syntax. Not every language provides an introduction like this, but when you can find one, it’s a great way to get a “feel” for how the language expresses things.
2. Next, look for a “hello world” example, or tutorial. Generally, these things are useless, but as an introduction to the language, it’s a good way to see what’s involved in a fully functional program. How much boilerplate does a program need? How is a program compiled or interpreted, and run? The “hello world” example is also a good place to start experimenting. As trivial as it sounds, try changing the string that gets printed. Try displaying an additional string. Hold on to this file; you can use it to play with as you progress through the next steps.
3. Now, look deeper. Try and find a more advanced tutorial. Look for examples that demonstrate writing procedures, objects, conditional branching, and so forth. They will almost certainly include concepts unique to the language, which will be new to you, but that’s the point! Work through those tutorials. Find additional documentation to clarify concepts that are unfamiliar to you. Go beyond the tutorials and experiment with these concepts, to solidify their meaning in your mind.
4. Once you’ve finished some tutorials, look for actual production code written in that language. GitHub is a fantastic resource for this kind of exploration, as are similar sites like SourceForge. Individual languages may have their own project “forges”, like RubyForge. Just find a project that looks interesting and read the code. This kind of “code spelunking” in a new language will give you valuable experience with the practical, day-to-day idioms used by experienced programmers, and will also give you solid examples of the concepts you read about and played with in the tutorials. (I intend to talk a lot more about “code spelunking” in the fourth article in this series.)
5. Lastly, think of a program or library you’d like to write, and write it in this new language. Nothing else you do will teach you the language as well as this step. You’re going to run into road blocks, but don’t get discouraged. If you need to do something that wasn’t covered in any of the tutorials, consider it an opportunity to read more documentation! Look at other projects and see how they accomplished similar tasks. Your first couple of programs in the new language will be very “unidiomatic”, but that’s how you start. Find someone experienced in the language and ask them to review your program, and point out better ways to do it.

By the end of the process, you won’t necessarily be an expert in the language, but you’ll know enough to compare it to other languages you know. You’ll also know whether you enjoyed the language enough to keep playing with it. Who knows? Maybe you’ll discover your new favorite language this way! I certainly wasn’t expecting to fall in love with Ruby when I started tinkering with it, but here I am, eight years later, and still tinkering.

Learning more

If you are already familiar with a language, the steps described above are not going to be as effective for increasing your knowledge. You’re probably in a rut, comfortable with what you know and able to accomplish almost everything you need to with it. That’s no excuse to stop learning, though; if you push yourself and learn even just a little more, you’ll almost certainly be surprised how useful that extra knowledge can be, even on a daily basis.

But how do you push yourself out of your comfort zone? This is probably harder than learning a new language, in many ways, because when you’re in the rut, it’s hard to see what the benefit of more knowledge would be.

One way is to find a good reference for the language, electronic or otherwise. Spend a little time each day (even just 15 minutes!) skimming that reference, looking for something you didn’t know before, or weren’t as familiar with as you would like to be. Once you find something, spend a little time playing with it. Find a way to add it to a project you’re working on. Blog about it. Tweet it. Just do something with it! Then, try to do something with it on a regular basis, so it stays in your memory.

Another technique is to find a library or program that uses concepts that are new to you. Unfamiliar with socket programming? Look for a networking library to read through. Want to be more familiar with threading techniques? Look for something that does a lot of parallel processing. Even if you have no specific learning goal, a good starting point is to select a programmer you admire, and find projects that they’ve worked on. You’re sure to find idioms, tips, tricks, and language features you’ve not seen before.

Ultimately, though, the game is not about “who can learn the most programming languages”. No one is keeping score. There is no tally scratched into the bedpost of your career, here. The goal is to educate your opinions. Awesome people have opinions born by experience. You want to be awesome? Then you need to be willing to keep pushing the envelope of your knowledge. Never settle for what you already have, even if you’re otherwise content. Keep looking. Lift the curtain on the unknown. If you want to be awesome, you need to explore.

Know thy languages.