A Quantum Immortal

Situation
It’s Thursday/Friday evening, the daily version / master branch was deemed too risky to install, and you decide to wait for Sunday/Monday with the deploy to production.

There’s a new critical bug found in production.
We do not want to install the bug on top of all the other changes, because of the risk factor.

What do we do?
Develop the fix on top of the production branch, in our local machine, git push, and deploy the fix, without all the other changes.

How can I do this?

My example uses a Play Framework service, but that’s immaterial.

1. gitk –all – review the situation
2. Suppose the latest version deployed in prod is 1.2.3, and master has some commits after that.
3. You checkout this version:
   
   git checkout 1.2.3
   
   
4. Create a new branch for this hotfix.
   
   git checkout -b 1.2.3_hotfix1
   
   
5. Fix the bug locally, and commit.
6. Test it locally.
7. git push
8. On the production machine:
   1. git fetch (not pull!)
   2. sudo service play stop
   3. git checkout 1.2.3_hotfix1
   4. sudo service play start
9. Test on production
10. Merge the fix back to master:
    1. git checkout master
    2. git merge 1.2.3_hotfix1
    3. git push
11. Clean up the local branch:
    
    
    git branch -d 1.2.3_hotfix1
    
    
    (Note: the branch will still be saved on origin, you’re not losing any information by deleting it locally)

I recently subscribed to Javascript Weekly, a weekly newsletter (yes, no RSS! or RSS feed) rather high quality weekly collection of Javascript cool stuff.

I’ve been picking the best links and sending to people at work, when I thought … hmm, I actually have a blog, why not summarize it here instead?
So, whenever I feel like it, I’ll be posting my own picks out the this week’s JS weekly.

Today, we have:

• Select2, an awesome replacement of HTML <select> boxes.
• jQuery 1.9/2.0 – the TL;DR edition
• Breaking the JavaScript Speed Limit with V8 (vid, I only skimmed it)
• Wakanda reaches 1.0 – A full stack JS environment (Server, DB, even IDE). For JS nuts (I’ll be sticking with my IntelliJ for now, thanks).
• Modern JavaScript engines can defer the parsing process of a function body until it is completely needed
• jam – package manager building on top of require.js  (“jam upgrade jquery”)
• The new sizzle (jQuery CSS selector engine). Did you know it was extensible? (You can code in and precompile custom selectors!)
• 5+1 reasons to choose AngularJS as your client-side templating / MVC framework

If any of you are intereview for a job any time soon, please take this advice to heart – just like KISS is a good principle in your every day job, it’s a great principle in a job interview.

Some people like to boast their skills when interviewing.

“I’m a Java Guru”

“I’m excellent at Big Data analysis on a NoSQL system in the cloud”

“I like well designed code … here are my favorite design patterns, I use them all the time”

Some of the above statements could apply to you … but be sure to be relevant to the job you’re interviewing for, and the tests you’re given. If you are asked to do a simple hands on coding session, know that your interviewer just want to see you code, he doesn’t need to you implement Map Reduce or show off your Uber Design Pattern skills.

Sure, it’s nice to sprinkle in good design, unit tests, and write scalable code … but before you do all those things, make sure you get the job done, on time, without bugs. Do the important stuff first, and show off later, if you have the time.

After a few months of gathering forces, we have a critical mass of people interesting in learning and teaching about Java & JVM related technologies.

Our first Tools Night is this upcoming Sunday (29/04), in Sears Israeli (Hertzelia Pituah).

Please check out the schdeule on EventBrite, and subscribe if you’re interested. Also don’t forget to subscribe to the google group.

Hi all, this is your newb web developer talking again. While some of the following might be obvious to the more experienced web devs among you, this is a post that I wish I’d read when I just started using jQuery.

Write your own jQuery plugins

The word “plugin” usually entails something complicated and with some non-trivial learning curve (e.g. how many of you ever wrote a Chrome of Firefox plugin?) Well, in jQuery, this is really not the case. Here is how you write a simple jQuery plugin:

$.fn.enable = function() {
  $(this).prop("disabled", false);
};
 
$.fn.disable = function() {
  $(this).prop("disabled", true);
};

I find it useful to wrap even simple one liners such as .prop(“disabled”, false) with a plugin, because the semantics of writing $(“#foo”).disable() is much nicer than playing with properties/attributes directly. I haven’t written a lot of plugins yet, but it’s something to keep in mind as a useful tool to wrap actions on specific DOM elements.

Know the commonly used plugins
There are a ton … I still know very few of them. Here are a bunch of useful ones (and the ones I personally know and use).

A lot of plugins are very easy to use, and have good documentation and demos, so not using them and rolling your own solution is usually just a result of ignorance. Take the time to educate yourself!

UI Queues
For a long time I’ve that you can do things like $(“#mydiv”).show(), $(“#mydiv”).hide() and even $(“#mydiv”).show(1000) for a simple animation. Only recently I discovered you can actually chain these using Event Queues:

$("#mydiv")
  .hide(1000)
  .delay(500)
  .show(200)
  .fadeOut();

Each call to an animation method gets queued up and executes after the previous one.

Deferred
jQuery Deferred is a little gem. It lets you write fluent code similar to the queue example above. Here is how you use it:

$.when($.post('http://api.com/request_1'),
       $.post('http://api.com/request_2'))
  .then(function(){alert("Got two responses")});

You can also use them with the event queue:

  $("#mydiv")
    .show(1000)
    .delay(500)
    .promise()
    .then(function(){/*do something */});

That’s all I have for now. Have any essential tips & tricks that I’m missing out on?

I’ve been refactoring code all my professional career. I started from C/C++, and when I hit C# (Resharper) and Java (IntelliJ), my productivity at refactoring was boosted by a few factors by the wonderful IDEs and refactoring tools that these languages have.

I am rather confident when I write “dirty code” in Java or C#, because I know that I can swiftly refactor it into beautiful code without too much trouble. Both aforementioned IDEs are so great at this, that it’s painless. You can take an ugly 300 line method and break it into several methods, break a long class into several classes, inline, move, and otherwise shape your code.

Enters javascript and web development.

Last year I’ve made the plunge and officially started working on front end web development, first at Google, and recently at Commerce Sciences. And I’ve recently discovered that … refactoring javascript and frontend code is hard.

The language is dynamically typed

Compilers and IDEs can help you less when the language is dynamic. They can make less assurances about your code, making reasoning and refactoring harder. Safely moving a method from class Foo to class Baz is an easy feat in a statically typed language, and a difficult or impossible one in a dynamic language.

Classes are not first-class citizens

While you can do OOP in javascript, classes are not first class citizens, but rather they’re implemented using functions, objects and prototypes. Automatically reasoning about “classes” without having an equivalent of keyword class is difficult.

Your code is not just Javascript, it’s HTML & CSS as well

Web development is not just about javascript, it’s a combination of JS, HTML & CSS (not to mention other potential technologies such as LESS/SCSS, HAML, JSON, and whatever language your backend is written in). Unless you’re already a web development ace and perfectly design your codebase … you will get these mixed up. Refactoring is about changing the design of your program, and when that design is split up between three or four different technology domains, design mistakes are harder to rectify.

You can’t (at least not yet) do an automatic refactoring to “move inline css into an external css file”, or to “convert static html snippet into a javascript DOM manipulation method”. The makers of IDEs and refactoring tools don’t have javascript completely figured out yet, no wonder they haven’t gotten around to building cross-domain refactoring!

Again, if you “know what you’re doing”, you can structure your program perfectly in the first place, and won’t ever have to do this kind of “cross domain refactoring”. Sadly, we’re not all born with this kind of experience.

It’s harder to know when you’ve broken something

Backend code is so much easier to test than frontend code. While frontend testing is important, and growing, it is by no means as well understood or practiced as classical “backend TDD, this is a calculator, assertEquals(30, calc.plus(10, 20))”.

So, since BE code has much wider test coverage than FE code, and is bloody compiled for Java & C#, when you refactor FE code it has a much greater chance of breaking down, often in subtle ways you’ll only notice on IE 8, or when the network is slow, or whatever edge case surfaces your particular bug.

So … how do we manage?

• Refactor less – Since we know refactoring is hard, we try to do less refactoring and more pre-factoring. Think a little more than usual before coding. While I’ve grown the habit of “code first, think about design later” over the years due to power of refactoring, it’s less useful in FE dev, so I need to take the time before coding and try harder to get it the design right on my first attempt.
• Still .. refactor – IntelliJ and Resharper both offer some refactoring capabilities. I’m most comfortable with “limited scope refactoring” – those that affect one function like Extract Variable. Use the tools you do have, instead of whining about the tools you don’t.
• Try to think harder about the different problem domains (JS/HTML/CSS), and to develop a better understanding of how to structure your program in a way that won’t force you do to refactoring across problem domains.

Please do share your own experience with refactoring in web dev!

Update - I advise you to take a look on how the Trello team manage Trello.

When I initially read about Trello, I wasn’t over excited (much like my first thought upon hearing of Stack Overflow was “oh no, yet another Q&A site”). Trello, if you haven’t had the pleasure, is a simple List Management App. No more, no less.

Then, we happened to want a little bit more order in our task management back at <Unnamed Hot New Startup I Recently Joined>. After considering several tools (somehow, always, Excel rears its ugly head in such discussions), we agreed to give Trello a shot.

So far, we’re about three weeks into the process, and while I can’t yet speak for everyone, personally I’m liking the experience a lot.

Trello is a member of the “let’s keep everything simple” family of tools. It is certainly not fully featured (at least not as a project management app), but as a simple tool to manage 1-6 people, it’s really a no overhead, no bullshit tool that gets the job done (we’re currently only 3 people, so I can’t testify to how it scales yet). After a bit of tweaking, we arrived at the follow scheme of working with Trello:

1. Keep a “current week/sprint” list
2. Keep three lists for Small, Medium and Large features
3. Maintain a “deployed, not yet reviewed” list, and another “done, not yet deployed list”

That’s it. This is how it looks like:

Our “sprints” are 1 week long, mostly because of the stage we’re at – we’re only three people at this point, and our priorities are very dynamic (remember, a sprint is just a unit of planning – it doesn’t correlate to how many deployments we do).

At least every week, we review the board together, and see what we’ve done in the last sprint. Any tasks that we haven’t completed, we move to the next sprint (or to the appropriate backlog if its priority has decreased). Completed tasks usually just get archived – well, rather the entire “Sprint X” list gets archived. Sometimes, when there are features that are especially relevant for review, we move the features to the “Code Ready” list, and when deploying, to the “Deployed, ready to review” list. When the features are reviewed, we then archive them individually.

We pick features for the next sprint by looking at the three buckets or backlogs. First we see if there are any “Large” features we want to accomplish or make progress on this week (usually there are). Those gets picked first. After that, we might fit in a few Medium or Small features. Small/Medium features are also useful to fill in gaps in planning – sometimes, I have an hour or less free, and I don’t want to start working on a Large or Medium feature … I know that just getting into the state of mind will often take half an hour, so I pick one of the Small features from the current sprint or from the backlog, drag it to the current sprint, and execute it quickly.

We also have little icons on the cards that show who they’re assigned to (not shown in this image). A feature can be just a headline, or can be very detailed with a description, checklist of sub-tasks, and other shiny items. Most features are simpler, but sometimes you just need to conduct some kind of conversation about the feature, and the best place to keep it is on the card itself.

What I like about our system is that it’s really ultra simple, gives us the ability focus to on what’s important right now, and to plan a bit for the future. It will not scale to long plans or huge teams, and it won’t give us any “smart conclusions”, like Evidence Based Scheduling in FogBugz. But it’s simple, it’s free, and it works (for now).

What are you using to manage your projects? (And please, “Excel” is not a good answer)

A little while ago, while coding Bitcoin Pie, I found the need to overcome the notorious Same Origin Policy that limits the domains javascript running on a client’s browser can access. Via Stack Overflow I found a site called Any Origin, that’s basically the easiest way to defeat Same Origin Policy without setting up a dedicated server.

All was well, until about a week ago,  Any Origin stopped working for some (but not all) https requests. It just so happened that in that time I had gained some experience with Play! and Heroku, which enabled me to quickly build an open source clone of Any Origin called Whatever Origin (.org!) (on github). For those unfamiliar with Play! and Heroku, let me give a short introduction:

Heroku is one of the leading PaaS providers. PaaS is just a fancy way of saying “Let us manage your servers, scalability, and security … you just focus on writing the appliaction.” Heroku started as a Ruby shop, but they now support a variety of programming languages and platforms including python, java, scala, javascript/Node.Js. What’s extra cool about them is that they offer a huge set of addons ranging from simple stuff like Custom Domains and Logging through scheduling, email, SMS, and up to more powerful addons like Redis, Neo4j and Memcached.

Now for the application part, I had recently found Play! Framework. Play is a Java/Scala framework for writing web applications that borrows from the Ruby on Rails / Django ideas of providing you with a complete pre-built solution, letting you focus on writing your actual business logic, while allowing you to customize everything later if needed. I encourage you to watch the 12 minute video on Play!’s homepage, it shows how to achieve powerful capabilities from literally scratch. Play! is natively supported at Heroku, so really all you need to do to get a production app running is:

• play new
• Write some business logic (Controllers/Views/whatnot)
• git init … git commit
• “heroku apps add” to create a new app (don’t forget to add “–stack cedar” to use the latest generation Cedar stack)
• “git push heroku master” to upload a new version of your app … it’s automatically built and deployed.

Armed with these tools (which really took me only a few days to learn), I set out to build Whatever Origin. Handling JSONP requests is an IO-bound task – your server basically does an HTTP request, and when it completes, it sends the response to your client wrapped in some javascript/JSON magic. Luckily Play!’s support for Async IO is really sweet and simple. Just look at my single get method:

public static void get(final String url, final String callback) {
    F.Promise<WS.HttpResponse> remoteCall = WS.url(url).getAsync();
 
    await(remoteCall, new F.Action<WS.HttpResponse>() {
        public void invoke(WS.HttpResponse result) {
            String responseStr = getResponseStr(result, url);   // code for getResponseStr() not included in this snippet to hide some ugly irrelevant details
 
            // http://blog.altosresearch.com/supporting-the-jsonp-callback-protocol-with-jquery-and-java/
            if ( callback != null ) {
                response.contentType = "application/x-javascript";
                responseStr = callback + "(" + responseStr + ")";
            } else {
                response.contentType = "application/json";
            }
 
            renderJSON(responseStr);
        }
    });
}

The first line initiates an async fetch of the requested URL, followed by registration to the completion event, and releasing the thread. You could almost think this is Node.Js!

What actually took me the longest time to develop and debug was JSONP itself. The information I found about it, and jQuery’s client-side support was a little tricky to find, and I spent a few hours struggling with overly escaped JSON and other fun stuff. After that was done, I simply pushed it to github, registered the whateverorigin.org domain for a measly $7 a year, and replaced anyorigin.com with whateverorigin.org in Bitcoin Pie’s code, and voila – the site was back online.

I really like developing websites in 2011 – there are entire industries out there that have set out to make it easy for individuals / small startups to build amazing products.