tmux and Technical Blogging now in print

tmux now available and Technical Blogging now in print and shipping

Googlebot Gotcha

Did you build your site thinking that googlebot can’t understand your javascript? I did, and I was a bit surprised when I learned I was wrong…

Continue reading “Googlebot Gotcha”

Googlebot Gotcha

Did you build your site thinking that googlebot can’t understand your javascript? I did, and I was a bit surprised when I learned I was wrong…

Continue reading “Googlebot Gotcha”

#328 Twitter Bootstrap Basics

Twitter Bootstrap can help make beautiful web apps quickly by providing you with useful CSS and JavaScript. Here you will learn how to include it into Rails with the twitter-bootstrap-rails gem.

UndoManager for ActionScript

UndoManager is A simple ActionScript library to add undo/redo functionality to your Flex/ActionScript projects. I just extracted this library from one of the project I’m working on.

Read more on my new blog

Enjoy!
Daniel

UndoManager for ActionScript

UndoManager is A simple ActionScript library to add undo/redo functionality to your Flex/ActionScript projects. I just extracted this library from one of the project I’m working on.

Read more on my new blog

Enjoy!
Daniel

UndoManager for ActionScript

UndoManager is A simple ActionScript library to add undo/redo functionality to your Flex/ActionScript projects. I just extracted this library from one of the project I’m working on.

Read more on my new blog

Enjoy!
Daniel

Edge Rails: PATCH is the new primary HTTP method for updates

What is PATCH?

The HTTP method PUT means resource creation or replacement at some given URL.

Think files, for example. If you upload a file to S3 at some URL, you want
either to create the file at that URL or replace an existing file if there’s
one. That is PUT.

Now let’s say a web application has an Invoice model with a paid flag that
indicates whether the invoice has been paid. How do you set that flag in a
RESTful way? Submitting paid=1 via PUT to /invoices/:id does not conform to
HTTP semantics, because such request would not be sending a complete representation of the invoice for replacement.

With the constraints of the methods GET, POST, PUT, DELETE, the traditional answer
is to define the paid flag of a given invoice to be a resource by itself. So,
you define a route to be able to PUT paid=1 to /invoices/:id/paid. You have
to do that because PUT does not allow partial updates to a resource.

Now let’s think about ordinary edit forms in typical Ruby on Rails applications.
How many times are we sending a complete representation for replacement? Not
always, perhaps we could say that it is even rare in practice that you do so.
For example, the conventional created_at and updated_at timestamps normally
can’t be set by end-users, though they are often considered to belong to the
representation of resources that map to records.

PUT in addition is an idempotent method. You should be able to replay a request
as many times as you want and get the same resource, something that sometimes
is violated by conventional idioms for creating children resources using
nested attributes while updating a parent resource.

There’s nothing theoretical preventing PUT from doing partial updates, but when
HTTP was being standarized the replacement semantics were already deployed.

Because of that, the PATCH method was defined in 1995 and standarized later.
PATCH is a method that is not safe,
nor idempotent, and allows full and partial updates and side-effects on other resources.

In practice, as you see, PATCH suits everyday web programming way better than
PUT for updating resources. In Ruby on Rails it corresponds naturally to the way
we use update_attributes for updating records.

Thus, PATCH is going to be the primary method for updates in Rails 4.0.

Routing

This is an important change, but we plan to do it in a way that is backwards
compatible.

When a resource is declared in config/routes.rb, for example,

resources :users

the action in UsersController to update a user is still update in Rails 4.0.

PUT requests to /users/:id in Rails 4.0 get routed to update as they are
today. So, if you have an API that gets real PUT requests it is going to work.

In Rails 4.0, though, the router also routes PATCH requests to /users/:id to
the update action.

So, in Rails 4.0 both PUT and PATCH are routed to update.

Forms

Forms of persisted resources:

form_for @user

get “patch” in the hidden field “_method”. The RFC is deliberately vague about
the way to represent changes in a PATCH request. Submitting a form is
perfectly valid, client and server must simply agree on the accepted ways
to update a resource.

Let me emphasize that the “_method” hack is a workaround for the limitations in
web browsers. As you probably know Rails routes real HTTP methods. That is, actual
PUT, DELETE, and now, PATCH requests are routed to their respective actions.

General availability

PATCH requests are available in all places where the rest of the methods are
available today. There is a patch macro for the routes DSL, :via understands
the symbol :patch. Tests can issue PATCH requests, request objects respond to
patch?, etc. Please see the original commit for details (with an important
followup here).

Will my web server understand PATCH?

Yes, it should. I have personally tried Apache, nginx, Phusion Passenger,
Unicorn, Thin, and WEBrick. They all understood PATCH requests out of the box.

Also, HTTP clients should be in general able to issue PATCH requests. For example
in curl(1) you’d execute:

curl -d'user[name]=wadus' -X PATCH http://localhost:3000/users/1

Credits

We would like to thank David Lee for this
contribution and endless patience to keep interested in this even after months
of discussion
.

Also I would like to
highlight the quality of the patch itself. It is excellent: code, tests, all
docs revised, comments in code revised. Everything carefully and
thoroughly updated. An exemplar patch.

Java Hackathon

This weekend, join us for a Java Hackathon at the Heroku office in San Francisco.

We’ve decided to kick things off with a contest. To enter, build a creative and/or useful application that enables or manages interactions with customers or potential customers via social media channels. It can be any social media channel, and your app will be judged on how well it fits the contest criteria as well as the quality of your concept and implementation.

The overall winner will receive a $500 Amazon gift card and a $500 Heroku credit. Two runners up will win a $100 Heroku credit.

Here are the basic rules to enter:

  • Your app has to be in Java or a Java framework.
  • You don’t have to be at the Hackathon, but you do have to reside in the U.S., Canada (excluding Quebec), or the U.K.
  • To enter, deploy your app to Heroku and post the code to a public repository on Github. Email your app name and a link to the Github.com repository to contests@heroku.com with the title of the contest (Heroku for Java Hackathon) in the subject. Entries must be received no later than 11:59pm PST on 3/4/2012. One entry per person.
  • For the official rules of the contest, please see this page. If you have questions, please contact us at contests@heroku.com.

    This is a good excuse to get familiar with the Heroku platform and how productive you can be by using it. Learn the basics on our Java DevCenter page and of course, we’re more than happy to help you if you can make it out to the Hackathon.

    Win a $500 Amazon Gift Card with Your Java App

    Heroku is proud to announce its first ever Java Hackathon, this weekend in our offices in San Francisco.

    We’ve decided to kick things off officially with a contest. To enter, build a creative and/or useful application that enables or manages interactions with customers or potential customers via social media channels. It can be any social media channel, and your app will be judged on how well it fits the contest criteria as well as the quality of your concept and implementation.

    The overall winner will receive a $500 Amazon gift card, and two runners up will win a $100 Heroku credit.

    Here are the basic rules:
    1.) Your app has to be in Java or a Java framework.
    2.) You don’t have to be at the Hackathon, but you do have to reside in the U.S., Canada (excluding Quebec), or the U.K.
    3.) To enter, deploy your app to Heroku and post the code to a public repository on Github. Email
    your app name and a link to the Github.com repository to contests@heroku.com with the title of the contest (Heroku for Java Hackathon) in the subject. Entries must be received no later than 11:59pm PST on 3/4/2012. One entry per person.

    For the official rules of this contest, please see this page. If you have questions, please contact us at contests@heroku.com.

    This is a good excuse to get familiar with the Heroku platform and how productive you can be by using it. Learn the basics on our Java DevCenter page and of course, we’re more than happy to help you if you can make it out to the Hackathon.

    Programming Your Home: Automate with Arduino, Android, and Your Computer now in print

    Programming Your Home: Automate with Arduino, Android, and Your Computer now in print and shipping

    Deploying a Nesta CMS Blog with Pygments Syntax Highlighting to Heroku

    Blogging and/or setting up a simple site should be a simple proposition. There are a lot of great frameworks out there that handle the software portion of running such a site. However, you don’t just want a stock setup. You have to take into account proper asset caching for performance, slick syntax highlighting, an aesthetically pleasing theme, app instrumentation, feed redirection and production deployment.

    I’ve gone ahead and boiled down all these concerns into just a few steps based on the Nesta CMS framework.

    If you’re not much for foreplay a fully deployable starter template of this site can be found here on GitHub and seen running here on Heroku.

    Background

    Having wrestled with quite a few blogging engines in the past I had several requirements of a new setup. Firstly it had to support a workflow that lets me write on my local machine using the tools I prefer, namely markdown formatted articles composed with IA Writer or a basic text editor.

    Second, it had to support a git-based workflow. My content is going to live in git and there’s no reason the publishing platform shouldn’t build on top of that as well. This also plays well with Heroku deployments.

    Static site generators are all the rage and fulfill the first two requirements. However, I’ve found them to be rather rigid and obtrusive for the very incremental edit-view-edit workflow I assume when writing. My last requirement was that I could write and immediately refresh my browser to see the fully rendered site running locally. Waiting for the whole site to generate on every minor edit proved to be far too slow for me in the past.

    Fortunately, there’s a better way.

    Landscape

    The list of dynamic file-backed Heroku-friendly blog engines isn’t particularly long. I investigated both Toto and Nesta CMS and, after a brief wrestle trying to get Toto’s HTTP request headers to play nice with rack-cache, settled on Nesta. Nesta is under active development and is written with Sinatra, the very simple and hackable web framework for Ruby.

    For deployment Heroku is the obvious choice given its seamless git-based workflow and variety of add-ons. I also work there.

    These steps assume you have git and ruby available from the command line and have already signed up for a Heroku account. The Heroku Toolbelt can get you up and running if you’re missing any components.

    Template

    Though the Nesta quick-start is solid, as are all their docs, we can skip ahead by using an app template. I’ve created one on github that’s already setup for syntax highlighting with Pygments, the “clean” theme you see running this site and the minimal artefacts needed to quickly deploy and provision a full-featured Heroku app.

    Fork the starter template using the “Fork” button on the template GitHub page.

    Fork starter template screenshot

    This will fork it to your GitHub account. From there you can clone your fork locally. Find the repository URL for your fork and copy it (your URL will differ from the one shown below).

    Repository URL screenshot

    Clone the app template to your local environment using git. Use the domain name of your site instead of mysite.com

    
    $ git clone git@github.com:rwdaigle/nesta-app-template.git mysite.com
    Cloning into mysite.com...
    remote: Counting objects: 72, done.
    remote: Compressing objects: 100% (38/38), done.
    remote: Total 72 (delta 29), reused 63 (delta 20)
    Receiving objects: 100% (72/72), 11.69 KiB, done.
    Resolving deltas: 100% (29/29), done.
    

    The application’s source is now installed locally in the mysite.com directory.

    Run

    Now that the site template is present in the local environment you can install required dependencies and render the site locally before deploying to a remote server environment. A bootstrap.sh script is provided for your convenience.

    The bootstrap.sh script does not use sudo or make any destructive commands. However, please review the script source before executing.
    
    $ cat bootstrap.sh
    $ ./bootstrap.sh 
    Using RedCloth (4.2.9) 
    Using addressable (2.2.7) 
    # ...
    Submodule path 'themes/clean': checked out '889e094749008d2bf4ecf901555fce44c7f7bc87'
    

    Once bootstrap has finished start the app using the foreman utility.

    
    $ foreman start
    14:25:47 web.1     | started with pid 59647
    

    Opening http://localhost:5000 should display the site running with a single getting started article listed on the home page. Any errors that occur will be shown in the terminal where you entered the foreman start command.

    Deploy

    Assuming you have a Heroku account and have successfully installed the Heroku Toolbelt you can use the provided helper script to quickly deploy the site install any dependencies and setup the appropriate configuration.

    The app deployed to Heroku will not incur any charges on Heroku.
    
    $ cat deploy.sh
    # ... review script source ...
    
    $ ./deploy.sh 
    Creating vivid-sword-9170... done, stack is cedar
    Adding memcache to vivid-sword-9170... done
    # ...
    Opening http://vivid-sword-9170.herokuapp.com/
    

    Next

    You’ve forked your own copy of the app template, got it running locally and deployed it for free to Heroku. Not bad for a few minutes of your time! To customize the site, setup analytics and write your first post go ahead and read the welcome post included in your new site (a copy can be found here).

    Welcome post screenshot

    My hope is this template and theme eliminates many of the sticking points associated with taking a great framework like Nesta and turning it into a running, usable and deployed site. Let me know if you run into any issues (or better yet, submit a pull request to the template or theme projects on GitHub).


    Nezumi 2.0 for Managing Heroku Apps ‘on-the-go’ Now Available for iPhone

    Heroku users are known for leading jet-setter lifestyles. It’s true! Developers with refined, sophisticated tastes git push to the cloud in order to appreciate the finer things of life: foreign cinema, travel to exotic destinations, and focusing on development instead of configuring system infrastructure.

    So it’s only natural that Heroku developers on-the-go reach for Nezumi.

    Nezumi is a paid 3rd-party iPhone app created by Marshall Huss that allows you to scale dynos, restart apps, and so much more–perfect for when you’re away from your computer. Its latest release adds support for Cedar applications, multiple accounts, a revamped console and log viewer, and a sleek, new app icon, which will look amazing on your home screen.

    Nezumi Console Nezumi Dashboard

    Nezumi can be purchased on the iTunes App Store now at a limited-time introductory price of $4.99. Existing Nezumi customers can download 2.0 as a free upgrade.

    Nezumi has given us a few promo codes that can be redeemed for a free download. Leave a comment below for a chance to have one e-mailed to you!

    Nezumi 2 for iPhone

    Heroku users are known for leading jet-setter lifestyles. It’s true! Developers with refined, sophisticated tastes git push to the cloud in order to appreciate the finer things of life: foreign cinema, travel to exotic destinations, and focusing on development instead of configuring system infrastructure.

    So it’s only natural that Heroku developers on-the-go reach for Nezumi.

    Nezumi is a paid 3rd-party iPhone app created by Marshall Huss that allows you to scale dynos, restart apps, and so much more–perfect for when you’re away from your computer. Its latest release adds support for Cedar applications, multiple accounts, a revamped console and log viewer, and a sleek, new app icon, which will look amazing on your home screen.

    Nezumi Console Nezumi Dashboard

    Nezumi 2.0 is a free upgrade for all existing users, or can be purchased on the App Store now at a limited-time introductory price of $4.99.

    We have few promo codes that can be redeemed for a free download. Leave a comment below for a chance to have one e-mailed to you!

    #326 ActiveAttr

    ActiveAttr provides what Active Model left out. If you need to create a table-less model with features similar to Active Record, watch this episode.

    Ruby 1.9.3-p125

    Jason and Peter talk about the new release of Ruby, clang and llvm support, Aloha Ruby Conf, and more.

    Control Your Development Environment And Never Burn Another Hamburger

    Everything I know about the world of fine dining I know from watching Top Chef and from eating at Five Guys. But I do know this: chefs have the concept of mise en place (which does not mean Mice In Place), which is the idea that everything the chef is going to need to prepare the food is done ahead of time and laid out for easy access. The advantages of having a good mise en place include time savings from getting common prep done together, ease of putting together meals once the prep is done, ease of cleanup. Again, I have no idea what I’m talking about, but it seems like the quality and care that a chef puts into their mise en place has a direct and significant benefit on how well they are able to do their job.

    You probably know where I’m going with this, but I’m becoming increasing convinced that one of the biggest differences between expert and novice developers is control over the environment and tools they use. I came to this the hard way – for a long time I was horrible about command lines, it was actually something that kept me away from Rails for a little bit. It’s not like I’m Mr. Showoff Bash Script guy these days, but I know what I need to know to make my life easier.

    Let me put it another way. Once upon a time I read a lot of human factors kind of materials. I don’t remember where I read it, but I read once about an expert short-order cook at a burger joint. His trick was that he would continually shift the burgers to the right as he cooked them, such that by the time they got to the end of the griddle, they were done. Great trick (though admittedly you need to be a bit of an expert to pull it off). Not only did the cook know when things were done without continually checking, but it was easy to put on a burger that needed a different amount of doneness simply by starting it farther left along the griddle.

    What does that mean?

    The name of the game in being an expert developer is reducing cognitive load.

    Try and list all the things you need to keep in your head to get through your day. Think about all the parts of that you could offload onto your environment, so that you can see them at a glance, like the short order cook, and not have to check. What are the repetitive tasks that you do that can be made easier by your environment? What can you do so that your attention and short-term memory, which are precious and limited, are focused on the important parts of your problem, and not on remembering the exact syntax of some git command.

    This is not about which editor you use, but it is about picking an editor because you like it and understand how to customize it, not because all the cool kids use it. If you are going to use Vim, really learn how to use Vim – it’s not that hard. But if you use Vim, and don’t learn the Vim features that actually make it useful, then it’s not helping you, and it’s probably hurting you. Is Vim (or TextMate, or whatever) making your life easier or not? Vim drives me nuts, but I’ve seen people fly supersonically on it.

    I’m getting a little cranky about seeing people’s environments – I’m not normally a big You’re Doing It Wrong kind of guy, but, well, I’m getting a little bit cranky.

    If you’re doing web development, there are probably three things that you care about at any given time: your text editor, a command line, and a web browser. Every man, woman, and child developer at my fine corporation has a laptop along with a second monitor that is larger than a decent surfboard. If you can’t see at least two of those three things at all times, try and figure out how much time you spend flipping between windows that you could be seeing together. If you are running Vim in a terminal in such a way that you can never see an editor and a command line at the same time, I think you can probably do better.

    If you use Git, for the love of God, please put your git branch and status in your shell prompt. RVM status, too. And it’s not hard to add autocompletion of Git branches, too. Or, go all the way to zsh, which has fantastic autocompletion. Again, reducing cognitive load – you can see your environment without checking, you can type complex things without knowing all the syntax.

    Use a clipboard history tool. I use Alfred, which is generally awesome as a launcher and stuff, but it’s not the only one.

    Use some tool that converts frequently used text to shorter easier to remember text. Shell aliases do this, I also use TextExpander, which has the advantage that TextExpander shortcuts are usable in SSH sessions.

    The thing is, I don’t know what the most important advice is for you. You need to be aware of what you are doing, and strangely, lower your tolerance to your own pain. What do you do all the time that is harder than it needs to be? Is there a tool that makes it easier or more visible? How hard would it be to create or customize something? Are you the cook who can look at the griddle and know exactly when everything will be done, or are you the guy constantly flipping burgers to check?

    Filed under: Uncategorized

    Control Your Development Environment And Never Burn Another Hamburger

    Everything I know about the world of fine dining I know from watching Top Chef and from eating at Five Guys. But I do know this: chefs have the concept of mise en place (which does not mean Mice In Place), which is the idea that everything the chef is going to need to prepare the food is done ahead of time and laid out for easy access. The advantages of having a good mise en place include time savings from getting common prep done together, ease of putting together meals once the prep is done, ease of cleanup. Again, I have no idea what I’m talking about, but it seems like the quality and care that a chef puts into their mise en place has a direct and significant benefit on how well they are able to do their job.

    You probably know where I’m going with this, but I’m becoming increasing convinced that one of the biggest differences between expert and novice developers is control over the environment and tools they use. I came to this the hard way – for a long time I was horrible about command lines, it was actually something that kept me away from Rails for a little bit. It’s not like I’m Mr. Showoff Bash Script guy these days, but I know what I need to know to make my life easier.

    Let me put it another way. Once upon a time I read a lot of human factors kind of materials. I don’t remember where I read it, but I read once about an expert short-order cook at a burger joint. His trick was that he would continually shift the burgers to the right as he cooked them, such that by the time they got to the end of the griddle, they were done. Great trick (though admittedly you need to be a bit of an expert to pull it off). Not only did the cook know when things were done without continually checking, but it was easy to put on a burger that needed a different amount of doneness simply by starting it farther left along the griddle.

    What does that mean?

    The name of the game in being an expert developer is reducing cognitive load.

    Try and list all the things you need to keep in your head to get through your day. Think about all the parts of that you could offload onto your environment, so that you can see them at a glance, like the short order cook, and not have to check. What are the repetitive tasks that you do that can be made easier by your environment? What can you do so that your attention and short-term memory, which are precious and limited, are focused on the important parts of your problem, and not on remembering the exact syntax of some git command.

    This is not about which editor you use, but it is about picking an editor because you like it and understand how to customize it, not because all the cool kids use it. If you are going to use Vim, really learn how to use Vim – it’s not that hard. But if you use Vim, and don’t learn the Vim features that actually make it useful, then it’s not helping you, and it’s probably hurting you. Is Vim (or TextMate, or whatever) making your life easier or not? Vim drives me nuts, but I’ve seen people fly supersonically on it.

    I’m getting a little cranky about seeing people’s environments – I’m not normally a big Your Doing It Wrong kind of guy, but, well, I’m getting a little bit cranky.

    If you’re doing web development, there are probably three things that you care about at any given time: your text editor, a command line, and a web browser. Every man, woman, and child developer at my fine corporation has a laptop along with a second monitor that is larger than a decent surfboard. If you can’t see at least two of those three things at all times, try and figure out how much time you spend flipping between windows that you could be seeing together. If you are running Vim in a terminal in such a way that you can never see an editor and a command line at the same time, I think you can probably do better.

    If you use Git, for the love of God, please put your git branch and status in your shell prompt. RVM status, too. And it’s not hard to add autocompletion of Git branches, too. Or, go all the way to zsh, which has fantastic autocompletion. Again, reducing cognitive load – you can see your environment without checking, you can type complex things without knowing all the syntax.

    Use a clipboard history tool. I use Alfred, which is generally awesome as a launcher and stuff, but it’s not the only one.

    Use some tool that converts frequently used text to shorter easier to remember text. Shell aliases do this, I also use TextExpander, which has the advantage that TextExpander shortcuts are usable in SSH sessions.

    The thing is, I don’t know what the most important advice is for you. You need to be aware of what you are doing, and strangely, lower your tolerance to your own pain. What do you do all the time that is harder than it needs to be? Is there a tool that makes it easier or more visible? How hard would it be to create or customize something? Are you the cook who can look at the griddle and know exactly when everything will be done, or are you the guy constantly flipping burgers to check?

    Filed under: Uncategorized

    Control Your Development Environment And Never Burn Another Hamburger

    The Developer’s Code now in print

    The Developer’s Code now in print and shipping