Alfa Jango Blog Engineering, Software, and Entrepreneurship

Archive for the ‘Ruby’ Category

Communication in Engineering, Software, and Open-source

Tuesday, September 27th, 2011

Engineers and developers are not known for being the best communicators. Technical details? No problem. Explaining things in plain English? Err, that’s a different story. I’ve seen entire projects flounder from ineffective communication through my career as an engineer.

Since transitioning to the role of startup founder and open-source developer, communication has become an even larger part of my day. Below is an analysis, including my humble suggestions, for improving the state of your projects by improving your team’s ability to communicate.

A special thanks to Cory Flanigan (@seeflanigan), who gave a talk at Great Lakes Ruby Bash 2011 entitled, Communicating Effectively for Fun and Profit, which prompted me to write this, and also for providing feedback on this article.

Communication is about winning. Whenever you engage someone in communication, it is a competition. Who has the better story? Who can talk/write more? Who has the better code? And if you don’t win, you lose.

False.

Fact: if you win a conversation, then you also lose. This is especially true when your conversation must accomplish some achievable goal.

Actionable discussion

Let’s first define “actionable conversation” as that in which we are trying to achieve some explicit goal, whether to persuade someone of something or to find a solution to some problem.

Now, let’s divide actionable conversation topics as one of two types:

Opinion vs opinion

The majority of the time, there is no right or wrong, only opinion and differing opinion. To consider yourself right here is to disregard the differing opinion as decidedly wrong. Be careful, doing this makes it difficult to ever grow and learn.

Fact (true vs false)

Then there are topics for which there is a right and wrong. Let’s say you and I are arguing the solution to 1 + 1 = 2. You say it’s 2, but I say it’s 3. In a technical sense, you are right and I am wrong.

(more…)

Remotipart 1.0 Released

Wednesday, August 31st, 2011

Just 6 weeks after the announcement of v0.4, I’m pleased to announce the release of Remotipart v1.0. With this release, AJAX file uploads in Rails 3.0 and 3.1 (building off the standard jquery-ujs driver) are as easy as humanly conceivable. This was possible thanks to a large push from Adam Kerr.

The two major changes for v1.0 are:

  • New jQuery 1.6 iframe-transport instead of dependency on form.js
  • New rack middleware does away with configuration

With the release of v1.0, the new officially maintained repo for Remotipart has moved from here to the JangoSteve fork on Github.

There is also now a more robust test suite. Read more about that in the Remotipart docs.

New jQuery iframe-transport

Previously, the process of submitting files via an ad-hoc iframe element and inserting the response back into the page (described here) was done by the form.js. For those who aren’t familiar, form.js is an awesome plugin that does a lot of really useful things. However, we weren’t really doing it justice by requiring it as a dependency for only one small part of its capabilities.

(more…)

Rails 3 AJAX File Uploads with Remotipart

Tuesday, July 12th, 2011

In my last article, we discussed the difficulties of file-uploads via AJAX, and how the iFrame method works around the issues to provide an AJAX-like interface for uploading files to the server.

So how does this relate to Rails?

Rails 3 uses Unobtrusive JavaScript for remote links and forms (and comes packaged with the jquery-ujs driver via the jquery-rails gem as of Rails 3.1!). However, because jquery-ujs relies on jQuery’s standard .ajax() function, it is incapable of doing AJAX file uploads.

The Remotipart gem

Remotipart to the rescue! The Remotipart gem does two things:

(more…)

New ajax:aborted Rails jQuery UJS Hooks

Tuesday, May 3rd, 2011

In my last article, Rails jQuery UJS: Now Interactive, I talked about my push to make Rails jQuery UJS (aka jquery-ujs) more interactive and easier to customize and extend with third-party plugins. Along those same goals, let’s discuss another recent change: ajax:aborted hooks.

There are now two scenarios where remote forms will not be submitted, and the AJAX submission will instead be aborted. When this happens, jquery-ujs now publishes hooks, to which we can bind handler functions to gracefully handle these situations.

Let’s take a look at each of these scenarios and how we can utilize the event hooks.

Scenario Hook name
blank required fields ajax:aborted:required
non-blank file inputs ajax:aborted:file

Required fields

(more…)

Rails jQuery UJS: Now Interactive

Friday, April 22nd, 2011

The Rails jQuery UJS adapter (aka jquery-ujs) has undergone some major renovations over the past few weeks. This particular change is one I’m very excited about, as I’ve been wanting to do this for a while. Without further ado, jquery-ujs is now InteractiveTM.

What do I mean by “interactive”? Well, we can now plug into every facet of jquery-ujs, binding to custom events, and even customizing internal functions, without hacking or monkey-patching the rails.js file itself.

We’ll start with a brief explanation of the change and then dive into a few examples.

Feel free to bypass my blabbering and check out the the commit.

Closure style

Previously, rails.js was one big closure.

Before:

(function($) {
  ...
  function fire(obj, name, data) {
    var event = $.Event(name);
    obj.trigger(event, data);
    return event.result !== false;
  }
  ...
})( jQuery );

// cannot access fire() function here

This closure design had many advantages. However, the biggest advantage, in this case, happened to be the biggest disadvantage as well: everything inside was self-contained and inaccessible by the outside world.

So, what if we like most of what jquery-ujs does for us, but just want to modify one little function? Before, we’d have to open rails.js in our editor and start hacking away. But no more!

Object literal style

(more…)

Rails js.erb Remote Response not Executing

Tuesday, March 15th, 2011

A common issue that comes up in the GitHub Issues for the Rails jQuery UJS and the Remotipart gem / jQuery plugin goes like this:

The JavaScript response from my js.erb is being interpreted as text and not being executed.

I usually point to this comment in GitHub Issues, which I posted the first time I came across this problem. But GitHub Issue comments are difficult to link to, and almost useless in search results due to all their ajaxy-ness. So, I’ll repost and explain here for future reference.

(more…)

Rails 3 Remote Links and Forms Part 2: Data-type (with jQuery)

Tuesday, January 18th, 2011

Continued from Rails 3 Remote Links and Forms: A Definitive Guide.

Since writing the Rails 3 Remote Links & Forms Definitive Guide, one question keeps coming up:

How can we make our remote links and forms retrieve JS.ERB, instead of an HTML partial?

In the last article, we requested an HTML partial to be inserted into the page by our AJAX callbacks. But what if we want JavaScript to be executed? Or JSON or XML to be parsed? Or plain text to be displayed?

Spoiler Alert: this article concludes with a complete working example using js.erb.

Equal parts Rails & jQuery

First, we must understand the :remote => true process in Rails 3. It’s equal parts Rails and jQuery magic. But don’t worry, it’s very little magic, bundled into a 4-step process:

  1. Rails tells jQuery, “Hey, bind your ajaxy goodness to this sweet little link/form,” with the :remote => true option.
  2. jQuery hi-jacks the element’s click/submit event and binds it to the .ajax() method. Now that element submits via AJAX instead of loading a new page in the browser.
  3. Rails receives the AJAX web request when the element is clicked/submitted and responds with some content.
  4. jQuery receives the response content with the .ajax() method that hi-jacked our element, and provides callbacks for us to handle the response in the page.

In this article, we’re exploring the different ways we can specify the format of the AJAX response and handle it accordingly, which actually spans all 4 steps above.

(more…)

Track jQuery AJAX Requests in Google Analytics

Thursday, January 6th, 2011

There is an easy way to track all jQuery AJAX requests in an application. This method could really be used to log our AJAX requests however we wish, but this particular example will log requests to Google Analytics.

The code

This code will automatically log all jQuery AJAX requests in our application, including those using $.ajax(), $.get(), or $.post() (and .load() too).

This will also work for any jQuery plugins using AJAX requests (e.g. lightbox plugins, etc.), as well as for all Rails 3 remote links and forms (provided we’re using the jQuery UJS driver).

In the page layout or in an included js file, we add the following JavaScript:

(more…)

Disable Rails 3 Remote Links After Click (using jQuery)

Thursday, December 23rd, 2010

I’ve frequently come across the need to disable remote AJAX links in Rails 3 after the first time they are clicked.

The typical scenario is that we have a link that fetches content from the server and loads it into the page. The problem is that after the first time the user clicks it, and the content is loaded into the page, we don’t want to keep fetching the same content from the server and re-loading it into the page if the user clicks it again.

The ideal solution

Ideally, we could easily just unbind the click.rails event binding to disable the links after we click them. In fact, that’s why I added the .rails namespace to the event bindings in rails.js in the first place.

Unfortunately, jQuery is not able to unbind (aka .die()) .live() bindings for specific elements in this way. See the Problem with .die() section in Exploring jQuery .live() and .die().

The good news is that I’ve rewritten the .die() method in jQuery to go along with the namespacing change to rails.js, so that we can do this. And it looks like the jQuery core team is planning to pull my rewrite into jQuery 1.5 (see discussion).

But until then we’ll have to make do with…

(more…)

Counting Block Nesting Depth in Ruby
(an Exercise in Exception-handling, Thread-safety, & Meta-programming)

Tuesday, November 30th, 2010

This question recently arose on the SFRuby users group mailing list. Given some nested block methods, Steven Harms asked how we could track the current block-nesting depth during runtime:

method1 "something" do
  method2 "something else" do
    "hiya"                    # < = We are now 2 block levels deep
  end
end

Unfortunately, Ruby does not have any built-in runtime methods to return the current block nesting depth. So, it looks like we’ll have to roll our own.

(more…)

Page 1 of 3123