Web — 2 comments
03
Dec 12

Twitter doesn’t scale (for conversations)

Note: this post is about people, not technology.

Let’s imagine for a moment that you’re following someone on Twitter that’s fairly popular in your niche – not a star, mind you, but someone with a couple thousand followers. Someone like Gary Bernhardt or Phil Sturgeon.

One fine day, the person you follow tweets something interesting, thought or discussion provoking, or perhaps incorrect, and you find yourself wanting to reply.

Now for the trick question: do you reply?

If you do, you might be one of tens (or hundreds) of people saying the same thing, effectively flooding and annoying the target. But if you don’t, your possibly unique and interesting feedback won’t get heard. It’s not that unique, you decide, and you weren’t asked directly, why bother…

So you can either be apathetic or troll. Your choice.

What if you’re on the receiving side – you’re the big fish and get hundreds of replies to every other tweet you send? You can either ignore them (except from the people you know and maybe follow yourself), effectively making Twitter a broadcast medium ala RSS, or actually try to strike conversation with all the people replying to you, wasting a lot of time.

So you either use Twitter as RSS (with a few notable exceptions) or waste a lot of time and probably get annoyed a lot to boot. Your choice.

Beyond a few thousand followers, Twitter just doesn’t scale for conversations. You can either reach a big crowd or actually talk to a small number of people, but not both.

Blogs, Facebook or Google+ actually don’t have this problem. Why? Because, when commenting on someone’s post, you can see all the other comments. It’s up to you to decide whether you’re contributing something meaningful or meetoo-ing.

On Twitter, there’s no way to do that.

Programming / Web — Comments Off
29
Nov 12

WebCamp Zagreb 2012

Last Saturday I participated in a WebCamp Zagreb conference. The conference was organised by several web developers groups from Zagreb (I was one of the organisers on behalf of Croatian Python community), with participants from entire Croatia and wider – we had speakers as well as attendees coming from Slovenia and Serbia as well. I’m also proud to say my company Good Code was one of the sponsors of the event.

The atmosphere was phenomenal and the conference itself was extremely well received. Actually we were limited by the venue size, since the interest both from the speakers (over 60 really good talk proposals for 24 slots) and atttendees (all the free tickets were “sold-out” in hours, and by my estimate, there were around 250 people in total). And the biggest complaint we had is that we hadn’t printed out the schedule for people who aren’t WiFi-enabled. Yeah, stupid mistake that, but I’m happy that was the biggest one :)

I was one of the presenters, and I talked about our experiences with introducing code reviews, unit testing and continuous integration - my slides are available on Speakerdeck. Don’t worry if you don’t understand Croatian, they just served as background for my talk anyways. All the talks were recorded and hopefully the videos will be ready in a few weeks. The talk was well received and I got a lot of feedback and questions from the audience (and even more later on the post-conference drinkup event). Although I’m confessedly not an automated-testing/continuous-integration expert, it seems that our from-the-trenches knowledge in starting down that path was very interesting to the audience.

My colleague Goran talked about lessons learnt from a project we did in Good Code – a distributed feature film video management system (slides on speakerdeck, will update the post when videos are available).

All in all, a great event. Can’t wait for the next years’, which is bound to be even bigger and better :-)

 

Linux / Programming — Comments Off
25
Jun 12

Easy VirtualBox VM management for the command line

I tend to create a virtual machine for each of the projects I’m working on. I’m using VirtualBox, which has nice enough UI, as well as a set of commandline tools I can use. Since I create and destroy my VMs quite often, I wanted to streamline this a bit.

To that end, I created a single template virtual machine (out of Debian Sid), set it up the way I like:

  • set up an account with typical shell environment, and with my SSH key add to authorized hosts so I don’t have to type password to log into it
  • install a few packages I use most of the time: git, ipython, vim-nox, …
  • set up shared folders so I don’t have scp/rsync stuff all the time
  • set up port forwarding for SSH and HTTP traffic

Then, for each new machine I want to create, I simply clone this machine and I’m up and running in a few seconds. I start the machine, work in it, and then suspend it so I can pick up where I left off when I come back to it later.

This can all be done quite easily with the VirtualBox tools, but as I’m starting/stopping/creating the machines all the time, I built myself a handy shell script to simplify it:

$ vm list
Available virtual machines:
"DebianServerTemplate" {83113c2e-22f7-46fa-bcdd-7b1a641ace9b}
"anothervm" {aee1140c-fe4b-4146-bc93-34ce08eaf5cd}
"projectvm" {3b361f0a-d34a-41cc-82b8-cb734c465ec1}
$ vm create testmachine
Create a new virtual machine named 'testmachine' [y/N]?
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Machine has been successfully cloned as "testmachine"
$ vm start testmachine
Waiting for VM "testmachine" to power on...
VM "testmachine" has been successfully started.
$ vm status
Running virtual machines:
"testmachine" {fe48fd07-d2d2-471c-b191-89aa873cab7c}
$ vm stop testmachine
"testmachine" {fe48fd07-d2d2-471c-b191-89aa873cab7c}
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
$ vm destroy testmachine
No way Jose. If you're really sure, destroy it via the GUI

The omission of VM destroying in the shell is intentional – I don’t want to accidentially destroy a VM due to my fingers being quicker than my brain.

The script is available here. You’ll want to edit it to use your VM template UID (change the BASE_TEMPLATE variable in the script), as it’s going to differ from mine.

Comments, suggestions, bugreports, patches are welcome. And before you mention Vagrant – Vagrant is cool, but this is way faster.

Git — Comments Off
03
Apr 12

When to do git merging or rebasing

This one pops up fairly often, and can indeed be quite confusing – when to use merge versus rebase in git? Here’s the answer.

The story so far …

In merge, you combine two divergent branches back into one. There’s also a special kind of merge called fast-forward, done when a branch being merged is just a continuation of the branch you’re merging into – so the new commits are just pasted on top of the target branch (ie. it is “fast-forwarded”).

In rebase, you change your branch (that’s being rebased) so it looks like it was branched off a new base, not the original one. This involves rewriting the commits, so you’ll end up with different commit IDs.

… and now the conclusion

So, when to use either? The rules are suprisingly simple:

Never rebase public branches

By “public branches” here I mean branches that other people might have checked out. Rebasing rewrites history, and anyone having branches that were checked out of the history you just unmade will be sad, angry or worse. That’s one reason you can’t just push rebased branch on GitHub (unless you force it and sacrifice a kitten). So just say no.

Rebasing private branches is perfectly fine, and in fact often done when squashing or rearranging commits, cleaning up a branch before going public with it, or just updating long-running feature branch (go easy on the last one, though).

Never merge upstream master into your master

By “merge” here I mean a recursive (non-fast-forward) merge, ie. the one that leaves tracks. And the rule is not only for master, but for any upstream tracked branch you may want to merge back into one day.

As a rule of thumb, fork master should always be in sync with upstream master (ie. only do fast forward merges/pulls), only having the commits that are in upstream already. Also, you should never have to merge master (local or remote) into a feature branch. If you need to update an existing feature branch, rebase it rather than merging into int.

Updating public feature branches

What to do if your public branch needs to be updated from upstream? You can’t rebase it since it’s public, and you can’t merge into it since you’ll want to merge it back some day.

Turns out it’s really simple: create a fresh one off of upstream, merge your branch into it, and continue working on a new one.

(This was originally a comment on the How To GitHub: A Complete Guide to Forking, Branching, Squashing and Pulls article Hacker News discussion. The article itself and the ensuing discussions are full of useful advice – if you haven’t already, go read them!).

Javascript / Web — Comments Off
16
Feb 12

HTML input placeholder handling with jQuery

There’s a million of small jQuery snippets which handle input placeholders (ie. the help/explanation text that’s shown until you actually write something in the field), and when HTML5 gets widespread, they’ll all be obsoleted.

But nevertheless, here’s another one.

this post is more for self reference, but if it’s useful to you, be my guest.

← Older Entries