A Quantum Immortal

After looking at several backup solutions for a linux-based project of mine, ranging from more advanced systems like bacula to a range of python/bash scripts, I finally found the ultra simple duplicity. Don’t get me wrong, bacula and its brethren really seem more powerful overall, but when you just need a simple solution, you can’t compete with duplicity’s simplicity.

duplicity is drop-dead simple backup system that does incremental/full backups, and supports a wide variety of backup targets from the box, including file, ftp, scp, s3, and a dozen others. The usage is simply

duplicity /folder/to/backup file:///path/to/target/folder

You can have the target folder be a local or S3-mounted folder (with the excellent s3fs), or use other supported URIs. The default is an incremental backup, by you can override by choosing a full backup. It even has support for “keep the last N full backups and delete the rest”.

The only feature that I required, and duplicity didn’t have, is automatically choosing when to do full vs automatic backups. I would like to tell it “every 100 runs, do a full backup”, and this is not supported out of the box … although easily fixed with a wrapper script. Put that in crontab and you’re set. Oh, by default it requires setting a PGP key, but if you’re lazy you can skip it with the –no-enc option.

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('api.com/request_1'),
       $.post('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!

As most of you know, I left Google a few months ago to join a hot new eCommerce startup (I can finally reveal it’s Commerce Sciences).

So far it’s been just Eyal, Aviv and myself working here at our Herzliya office.

Well …

We are pleased to announce that we secured an investment of more than 1.5 million dollars, and are now ready to spend that money on you!

That is … if you’re a really top notch developer looking for adventure, learning, teaching, cutting edge tools and challenges, a terrific product (still stealth mode, but we already have some clients) that will change the way we do eCommerce, together with a superior team.

You will be our second or third employee … plenty of room to grow, influence the team, the code/architecture and the product.
I was actually just planning to write a post about “why I love startups so much” when the news of the investment round was made public .. look forward to it.

I can’t elaborate publicly about the product, but technology wise I can say we’re working with Java 7 (thinking about Scala), Groovy, Play! Framework, Javascript/HTML/LessCss (will integrate Coffee Script first chance we get) Amazon EC2, git, and Trello.

There’s a new group in town.

If you’re a Java/JVM developer, and live in the Tel Aviv (or Israel) area, please join.

I don’t like repeating myself, so please, if you fit the above criteria, read the linked post.

I just discovered FollowUpThen via Pasha a few weeks ago, and wanted to share. It’s an easy to use website that complements other task management systems, and would be especially useful to those of you that don’t manage your tasks in a full fledged “system”, but just keep them in your inbox.

In shorts – if you send an email to a FollowUpThen address, you’ll get a reminder after a specific time. E.g. send an email to 3days@followupthen.com to get a reminder 3 days from now. Check out the video on their homepage, and just use it – it’s dead simple.

Thread.sleep() has always been considered a “bad thing” in programming, something you do when you don’t have a good alternative. You could sleep() when you’re polling for a long operation, but the better solution would always be to get a notification when the operation completes, to avoid blocking a thread and generally wasting time – if the operation finished in 600 milliseconds, and you poll only every second, then you completely wasted 400 milliseconds, right?

Well, it turns out there is at least one use case where you really should waste those extra 400 milliseconds – User Interface.

I recently implemented a web UI component that checks if another website is reachable, and only then proceeds. If the website is not reachable, the user has to stay on that page and try again (perhaps he mistyped the URL). I implemented a server method that checks if the URL is alive, and called it from the client side via AJAX. The code looks something like this:

showLoadingIcon(); // displays a "loading" GIF
$.post(url, function(result) {
  hideLoadingIcon();
  if (result.good) {
    // proceed
  } else {
    // Display error message
  }
});

Well, it turns out that while this code is perfectly correct and efficient, it feels erratic from a usability perspective. If the page took a long time to access, it would behave fine, but if the page was very quick, and the method returned within say 200 milliseconds, the “loading” icon would flicker, creating an annoying experience for the user.

The solution is adding a manual, “artificial” sleep(). If the loading was long, no sleep was necessary, but if it was too short, I added a call to setTimeout, to ensure the loading image is always spinning for at least a full second.

While this is not really an example of Thread.sleep() (that doesn’t really have a javascript equivalent), this does show that sometimes delaying an interaction is required to reduce the user’s pain or confusion.

In case you have been living in a hole and haven’t heard about SOPA, I’ll just explain it briefly – it’s a proposed US bill that if passed, would literally destroy the internet as we know it. This bill includes massive punishment for anyone who hosts or streams copyrighted material, or even merely links to such sites (Go TV Links!).

Even sites that host or index user generated content such as Facebook, Wikipedia, WordPress or Google are not except. What’s especially outrages is that no court order is required for liability – if anyone doesn’t like a certain blog post that contains links to copyrighted material, and they file a complaint, if the owner does not remove the offending content, then he is liable, as well as a vast array of internet infrastructure that “assist him in his activity” – Internet Service Providers are expected to block his domain name, payment networks such as Paypal are expected to refuse to work with him. It’s a literal thought police, and it could happen.

Luckily, a lot of companies have stepped up and announced their objections to SOPA. If passed, SOPA could destroy those companies, but I believe that a major part of their objections is also on moral grounds. SOPA is pure evil, a revert to darker times.

Today, the U.S government still controls the internet. The major internet user-facing business are based on U.S soil, as well as payment processors and ISPs. This will not be the situation forever. Bitcoin is proving to be an alternative to the U.S dollar and Paypal, that no body can shut down or control. Namecoin can be a fully distributed alternative to DNS and SSL Certificates. These technologies are not yet mature, but the very idea of SOPA being proposed in the so called “land of the free” clearly shows the necessity of disentangling the internet from U.S control.

The internet is our home. It’s the force that binds us together, and we will not let it be corrupted and controlled.