qcon2009sf: other talks

Posted by anton
on Monday, February 01, 2010

for completeness sake, in addition to outstanding talks, i should mention a few others that were memorable.

i caught the second half of eric “DDD” evans talk – it was moving at a glacial pace (a trait of a professional consultant that is paid by the hour?) and was terribly overcrowded, but i liked what i heard. he took the roundabout path to get to the importance of evolution of the existing systems, but he made his point well with some great insights along the way. i have been setting aside his book for years, and i know it is long overdue, but i should read it.

i was surprised that none of the talks on the “cool stuff with java” track appeared all that cool to me. perhaps i have already looked at the tech behind them too closely, and the talks did not offer much on top of that.

nevertheless, project voldemort talk was a good refresher on brewer’s CAP theorem, consistent hashing (or DHTs), amazon’s "dynamo". i wish it were more technical, since the devil is in the details, and i wish there was more comparisons to other systems in this landscape (e.g. cassandra which seems to be further ahead).

hadoop is pretty much a household name these days, so a generic intro to the tech and its ecosystem did not do much for me. still, having built and run ETL environments in the past, i think that anyone in this position must consider hadoop these days – after all, if your ETL environment is trying to scale vertically and is using one of the big boys’ mammoth software, then it will make sense to compare 1MM for the license + hardware costs with 100K for commodity hardware + free software. this is a subject for a whole different post though.

by the end of the conference i have acquired a nervous twitch each time i heard another attempt at cloud computing definition. i did like stu charlton’s talk though – he had a good business perspective, and although i do not believe in his product, i would be keeping an eye on it, since they are trying to solve a real problem.

finally, i was disappointed by my own reception of “architectures you’ve always wondered about” track. facebook, linkedin, amazon – i think i’ve already knew enough about them, so signal to noise ratio in these talks was too low for me, and i could not justify staying there for long.

qcon2009sf: individual talks

Posted by anton
on Monday, February 01, 2010

as promised, these are a few talks that i have attended and found worth mentioning. i know i missed a lot due to scheduling conflicts, but that’s the nature of the game.

clojure talk by stu halloway

a great talk that had to be witnessed; it was a fast-paced flight through the language, illuminating its features and defining its place. there was a story, there was excitement, and there was a pragmatic take on it all. since languages track was aimed at actual usage in the field, half of the talk was spent on war stories – things that worked and things that did not. it was a tight, erudite talk, with just the right amount of details.

i am still ambivalent about the language – i do not have enough experience with it to see it used in production on the systems i am working on right now; it still exhibits growing pains, and feels a little rough around the edges. perhaps it is my lack of functional language exposure that shows. at the same time i am absolutely fascinated and excited about the things that it gets right – the immutable data structures and the whole concurrency story. the language feels nimble, finely honed, and it is great to witness its evolution, as it happens in front of my eyes. i love the way it makes my brain feel, the way it challenges my perspective on language design and features.

if tech is your competitive advantage, and you have small sharp teams, then by all means, give it a try. even if the language does not survive in its current state, the ideas and their implementation will live on – i think they are that important.

groovy on the trading desk by jonathan felch

there is always a bit of a stigma associated in my mind with conference “thought leaders” – unless they have proven their credibility by repeatedly building and shipping, i always take their words with a grain of salt. after all, those that have the time to float from conference to conference, from client to client, might (d)evolve into pundits. there is a definite value in that, and i certainly would still attend their talks and buy their books, but i would always remind myself of their perspective.

i really liked jonathan’s talk because it was ruthlessly pragmatic, coming from someone driven to ship, working with traders to solve real problems quick. in a sense, this environment is somewhat of an aberration, since outside of the trading desk the software development world is quite different.

his team was bending technology, doing very creative things right on the bleeding edge; by any means necessary they had to deliver software for the business under the tightest deadlines. in some respects, this is the technologist’s ultimate dream – when politics and money and all the other pressures of architecture and enterprise world are pushed aside and all that matters is whether you can deliver. this freedom is scary and exciting at the same time.

the talk was about a distributed computational in-memory engine they have built to support a trading desk, standardizing on groovy and building on top of terracota in 2006. this allowed them to deliver new features in a matter of hours for their traders.

essentially it was a graph where cascading properties were recomputed in response to events; logic could be injected via closures at runtime, state and behavior of individual nodes could be extended at runtime; all of it written in functional style, avoiding shared state.

he talked about the areas where groovy shined, and walked through some of the problems they have run into. predictably, the strength was writing DSLs, terseness, convenience, speed of writing code, dynamic nature, integration with other systems; pains were performance, math, and language gotchas.

jonathan also managed to give a perspective on quantitative finance in general – what is the business about, who are the people involved, what tech is used, and what problems they have to deal with. this is what really made the talk “sink in.”

i dismissed groovy early on, when the race to add new language features trumped the need for quality and thoroughness. the whole affair seemed to be too sloppy and haphazard, so i only watched its evolution from the distance. i suspect that the situation has changed, even before spring source acquisition, so i should give groovy another try.

architecture for the cloud by michael nygard

i am yet to read "release it", but i have come to appreciate his perspective based on the articles, blog entries, and book excerpts. i think michael has a great gift for organizing and presenting the patterns of operations architecture, a field that for the longest time has been the dirty secret of running systems; the proverbial “last mile” of software development, the achilles’ heel.

it takes someone straddling the fence between operations and developers to recognize the issues. having been in this role myself (and having ranted about it on this very blog), i am really grateful to him for illuminating and organizing the patterns in a manner that (hopefully) should help us as a community to avoid repeating the same mistakes.

why do patterns matter? it is a shared language that allows those responsible for operations and development to communicate with each other and recognize the problems and their solutions.

why does operations matter even more now? the proverbial admin/developer fence is disappearing, cloud means fast provisioning of many machines done by developers/users; the developers become more and more aware of infrastructure, which, in turn, becomes more of a commodity, while the job of the sysadmin is changing. i really liked his practical insights into the way cloud computing will be changing the roles within the enterprise.

overall, i mostly nodded along with the slides, but it helped me organize my own thoughts on the subject (which, in the end, might be far more important).

doug crockford on javascript

an immensely entertaining and sprawling talk that went into the history of the language, its evolution, and its future. it was exactly the kind of the talk i dismissed earlier, but at the end of the long day, and from someone as entertaining as doug turned out to be, i was ready to kick back and enjoy the ride. there were plenty of anecdotes and killer one-liners, so if you get a chance, watch him speak.

erik meijer on rx

as opposed to the doug’s talk mentioned above, this was a great example of a conversation, or riffing, where ola bini, don box, dan north, amanda laucher, sadek drobi, and a few others completely derailed the whole rx presentation into a joyous bantering about languages.

erik meijer is a joy to listen to as it is, but if you add a small responsive audience and a few beers, the whole experience is unforgettable. he loves to be paradoxical, and he revels in controversy. he was dropping tweetable gems at an astonishing rate – the sparks were flying, and my brain could hardly handle it.

at last we were pretty much forced out of the room by the staff – it was a perfect closing for the conference.

eclipse import static

Posted by anton
on Tuesday, January 26, 2010

i very much believe in a craftsman approach to software development, which, among other things, advocates the value of mastering the tools in your toolbox.

i consider using keyboard shortcuts in your IDE of choice a part of this craftsmanship approach. i do sympathize with unclebob’s plight for mouse-less editing and with stevey’s earlier posts on the subject.

back in 2004 java5 went GA and introduced static imports among several other syntactic niceties.

this feature is most useful for static helper methods – instead of writing Assert.assertEquals, i would rather use assertEquals, since i know i am writing a test, and in the domain of testing, assertEquals does not need to be qualified. same goes for many internal utility methods that i tend to use a lot (e.g. asList()) or static factory methods (e.g. newDateTime()). as a side note, using newXY() as a static factory method as opposed to create() makes it more suitable for static importing.

in my current IDE (Eclipse) i rely on auto-completion Ctrl+1 programming, so i would start typing Assert., followed by Ctrl+Space and then manually convert normal import to import static. it was very undignified.

it turns out that in Eclipse Ctrl+Shift+M that i already used to import dependencies under the cursor, also works for converting static method calls into static imports.

now all i have to do is type Assert.assertEquals once, then press Ctrl+Shift+M (obsessively followed by Ctrl+Shift+O to organize imports), and i can start using assertEquals all over the place without qualifying it with Assert.

as an additional convenience, i always set Number of static imports needed for .* to 1 under Java -> Code Style -> Organize Imports in Eclipse preferences. this way a single static import of a method from Assert triggers import static of Assert.*, which is what i want.


Posted by anton
on Thursday, December 03, 2009

it was my first time at qcon, and i found myself quite conflicted before the conference – i kept asking, what was the main reason for me to attend?

i already know roughly 75% of the speakers – i’ve read their books, i have been following their blogs and twitter feeds, i even saw their presentations online. i know for the most part what they would be telling the masses, thus i could not expect a blow-your-mind experience, the ultimate conference “catch” i am sure everyone is after. perhaps this is the curse and the blessing of the ultimate transparency.

if i am interested in this stuff, i have already taken all the easier steps to get up to speed; attending a conference comes next for me – not before, not instead.

as it turns out, once you get a dozen or so people that roughly have the same level of expertise and the same interests, and that do not expect to be spoonfed as they doze off, something else emerges – a conversation. this is the main attraction for me – conversations around the speakers – whether they are happening during their sessions (best case scenario) or in-between.

i do not arrive there to be re-told the ideas i have already heard, i would like to use them as a basis to explore further.

these days conferences where i know most of the topics and the speakers are definitely about conversations. this probably does not apply to a lot more focused/specialized conferences or those where i am not as familiar with the speakers. but here’s the paradox – i need to know the speakers well enough before i decide to go, at which point it seems like there is no reason to go anymore.

i am after passionate, articulate experts in their respective fields leading and participating in a conversation where most of the people are already familiar with each others’ backgrounds, arguments, works, and build on top of that.

which leads to a few conclusions, stemming from the need to create and nurture conversations. the whole idea of a keynote for a large audience is useless to me, since anything over a 15-minute intro is something i have probably seen/read already; any audience that is more than 20 people is too large; any audience that is not “up to speed” on the topics discussed will drag the conversation down.

the requirements above are probably a bit idealistic, but good user groups, and self-selecting gatherings (like hacker b&b at Stu Halloway’s i was fortunate enough to have been invited to this summer) prove that it is possible. another example is speakerconf, although its selection bias might turn it into an echo chamber.

so given all this, how did qcon fare? each day had something good, and i will try to write these highlights down in the next post.

would i attend again? it all depends on the speakers, and, even more importantly, whether i would be able to get to know more people beforehand and thus have good conversations outside of conference sessions.


Posted by anton
on Monday, July 27, 2009

scarred, but not defeated by vim, i decided to try a recently released beta of rubymine 1.5, and it’s been great so far.

massive disclaimer: i have not tried anything else for ruby/rails coding except for vim.

unlike a similar offering from netbeans, rubymine is a standalone install that seems to reuse a lot of the existing intellij idea codebase.

it was great experience out of the box – i pointed it at the local svn working copy and it verified all the installed gems (even though i am fortunate enough to run on cygwin, it recognized them all).

it has great rake support, and all rake tasks run without any modifications. however, for script/server in cygwin evironment i had to replace -e"STDOUT.sync=true;STDERR.sync=true;load($0=ARGV.shift);" with -e"STDOUT.sync=true;STDERR.sync=true;RAILS_ROOT='/cygdrive/c/project/root/dir';load($0=ARGV.shift);" in ruby arguments field. once the server runs, it also displays its log with proper color-coding.

i still run script/console from cygwin command line, since rubymine does not do readline support (i use ctrl+L, ctrl+R, tab completion, ctrl+e/ctrl+a and other goodness quite a lot in my irb).

things to love
  • color-coding, auto-indenting (including color-coding of matching brace/bracket/do-end block)
  • ctrl+shift+n/ctrl+n for finding files and getting around; with alt+f1 to show current file in different contexts/views
  • ctrl+f12 for current file structure
  • visible spaces (otherwise the ruby coding standards make the code look too squeezed to me)
  • ctrl+click when mousing over (jump to all kinds of things, including template names, css style names – all of it very nicely integrated)
  • ctrl+/ for toggling comments
  • rails project structure
  • parsing my stacktraces and linking them to the source code
  • autocompletion, although i do not find myself using it too much
  • all the usual things that idea has – svn and git support out of the box (and shelving works, just like in idea, in case you have to work with svn)
  • pretty sweet diff (ctrl+d) that rivals tortoisesvn visual diff
  • ctrl+shift+up/down to move the current line
  • ctrl+d to clone selection
  • shift+delete to delete the whole line
  • ctrl+shift+f12 to go full-screen
  • alt+number to toggle between tool windows
  • file structure tool window (alt+7)
  • alt+f7 to find usages
  • alt+shift+f10 to bring up run menu
  • shift+f10 to run current run
  • simple refactorings (introduce method, rename variable/method, etc).
  • it is pretty damn stable, and occasional errors do not kill the IDE.
things to improve
  • unlike netbeans, it is not a full-blown ide with ruby support, so some things that exist in idea are missing (notably, database support, some of the team communication and code sharing features, and other bells and whistles)
  • ctrl-q for docs is a bit wonky (frankly, i’d rather jump to matching place in the online api docs – it gives me context)
  • code folding fscks stuff up sometimes
  • still do not know how to jump to matching brace/do-end block
  • svn switch could not be found
  • ctrl+shift+f10 to run current test (and any other ad-hoc run tasks) does not work on cygwin, unless you do RAILS_ROOT trick above

i have not tried all the other stuff, like haml support, cucumber support, rspec, and rspec w/ drb.

overall feel is nice and polished – most things just work out of the box (unlike the frankenstein monster that eclipse can be sometimes – truly a Windows of IDEs).

i do believe in using “idiomatic” shortcuts with an IDE, thus i did not try any of the “compatibility” keyboard modes.

for now, i do not see myself coming back to vi for rails development – for a hundred bucks, rubymine is a great development tool.

ode to vi

Posted by anton
on Friday, July 24, 2009

i recently had to do a small rails project. so i did what i usually do in these cases – fired up the easiest IDE that runs anywhere – vim.

now let me reminisce a bit – i’ve been using vi on and off ever since i got my hands on linux in 1997, and i have not learned much beyond the basics over the years. it works the same way on half a dozen unixes i’ve used it on, as well as on cygwin and macs; even dreaded beasts like mks toolkit provide it. it is an indispensable cross-platform tool.

it does not require much horsepower, and it fits well with the back-to-command-line ideology of rails.

if all you are using it for is editing occasional file or two, it does everything you need out of the box. throw in basic syntax highlighting, auto-indenting, split windows, buffers – and you have enough to survive.

oh, did i mention the macho factor? it takes some effort to tame the menu-less monster of an interface with a barrage of keystrokes that appear as magic incantation to others.

vi has a peculiar physical effect – i often surprise myself when i remember certain editing commands, but at the same time i am utterly unable to remember them when standing behind someone, advising them what to type – my fingers twitch, but my higher brain functions are not firing.

curiously, this reminds me too much of some of the mainframe folks i’ve seen, or even an occasional SAP jockey. consider it a compliment – there is a lot of power in short mnemonic commands compared to drill-down menus. yes, every powerful system must have a command line, but it must degrade gracefully. with vi the discoverability of interface is pretty much non-existent, and the learning curve is steep.

my current theory is that the muscle memory vi creates leads to a particular form of addiction which explains its appeal (and perhaps the religious zeal).

when i work in a context of a project, where i constantly need to bounce around different files, vim UI starts to break down: built-in buffers support is inadequate. the editor needs to have a concept of a project i am currently working on, and, ideally, the framework i use.

i know that the usual answer is customize, customize, customize – and in this respect it follows very much a linux tradition – if you are 15yrs old, and have tons of time, and only one machine, you can spend days crafting that perfect setup that is just right. having done that a number of times, i have learned that it is just not worth my time – I switch computers often, work on client sites, bounce between different teams, so i want stuff that is reasonably workable out of the box.

i can take it easy and install some basic plugins – fuzzy finder to give me files i want fast, nerd tree for filesystem navigation, rails for rails integration, tComment for toggling comments on blocks of text.

but now i need to manage them across several machines, and perhaps i do not want to spoil my vi muscle memory that can cripple my vi-fu on that hp-ux 11.11 when i come across it (yeah right).

so perhaps i will draw the line and use some other ide for project work, leaving vi for simpler stuff.

to add some substance to this post, a few significant lines from my .vimrc:

syntax enable
filetype on
filetype plugin on

set tabstop=4
set shiftwidth=4
set expandtab

autocmd FileType ruby set shiftwidth=2|set tabstop=2|set expandtab

set number
set ai
set si

and some of the commands i use often (besides the usual navigation/editing/searching ones that are in my muscles, but refuse to be articulated):

  • :e! to reload the file i am currently editing
  • :retab i really hate those tabs
  • :ls to look at open buffers (the listing is a pain to read, trying to remember what those little symbols mean and matching numbers to file names)
  • :e filename to open a file in a new buffer
  • :bd to close the current buffer
  • :e# to bounce between two last buffers (how can i cycle between all the buffers ala alt+tab?)
  • ctrl+w followed by s or p to start splitting windows, then bounce around them with double ctrl+w or ctrl+w and arrows
  • ctrl+w followed by <number>+ or <number>- to shrink or grow the split windows
  • ctrl+w followed by q to close current window
  • zz to center screen on current line, accompanied by zt op and zb ottom
  • % to jump to matching brace
  • o and O to insert the line and switch to editing mode
  • I to insert at the beginning of the line (that i always forget, unlike its companion A)
  • m + letter to place a named mark, ' + letter to jump to the beginning of the line, ` + letter to exact position of the mark
  • >> and << are much easier for indenting, as opposed to my muscle-memorized number + > + enter
  • shift+v or v to do visual selection
  • once you visually selected stuff, you fold it with zf

finally, i find the whole :tabnew business utterly useless and insulting.

what i do miss in addition to project structure navigation, is easily looking up/jumping between methods, code block folding that follows language semantics, and decent tabs.

jamis buck blog entries on the subject were really informative and inspiring (especially the comments).

cloudcamp nyc

Posted by anton
on Sunday, June 07, 2009

i am organizing my notes from cloudcamp nyc 2009. the whole thing was done the unconference style, and i bounced around different groups for a few hours.


it seems that folks were struggling to come up with the taxonomy of the cloud. i see it is a continuum from bare OS instances (amazon’s EC2) to increasingly specialized services (google app engine, S3, salesforce, and even facebook).

bare OS instances are easy – nothing there is new, and what is changing is the elasticity of the capacity – you can spin up and wind down instances much faster (and recently announced amazon’s auto scaling makes it even easier). the only catch there is that you have to design for scalability yourself. but you have all the power and the flexibility, and there is no lock-in.

the latter is when you give up some of the flexibility for scalability out of the box – the design and implementation are taken care of for you – google app engine and facebook just scale. there is a lock-in there, but you might not care. somewhat unrelated, but pmarca had some things to say about it a while ago.


when dealing with OS instances, these developments make it obvious that if you have not embraced automation yet, it is time to do so. the lone admin doing things by hand does not cut it anymore; even barebones shell scripts and basic packaging might not be enough.

the sad thing is that i do not see an easy, thorough, cross-platform management tool that does everything out of the box. cfengine was the closest thing back in the day, but i want something that embraces source control and declarative configuration; something that is transparent and easy to use; something that is cross-platform. chef and puppet look promising.

so there are a lot of new vendors coming out and touting their products for managing the cloud.


same thing with monitoring – sscope was a killer app almost a decade ago, but i have not seen a compelling polished replacement (until, possibly, hyperic) – something that could scale down and up, something that can be either agentless for small easy deployments and agent-based to be able to scale beyond that. amazon’s cloud watch is a step in the right direction, but it is just the beginning.

i hope that cloud computing developments will give this industry a push it needs to clean up its act and finally come up with comprehensive convenient set of tools that is sorely overdue.

bottom line is that with clouds there will be more stuff to manage, and the demands for the management tools will become stricter.

i want commodization of these tools – monitoring, deployment, etc. ideally they will be independent of cloud provider and i want them to be simple and transparent and composable and hackable.

usage scenarios

it is almost a no-brainer these days for startups writing green-field apps to rely on amazon for their capacity. it is great, since they are not as concerned with SLAs and lock-in is not that big of a deal.

amazon truly has kick-started the industry that lurked in the shadows for so many years with all the major players trying and failing to launch a successful pay-as-you-go cloud computing service. i guess their secret was extracting a service from their own successful projects, instead of trying to come up with something new for others.

as for enterprises though, i do not see them embracing the cloud platform as it is now, however there are some scenarios possible right now, and i am sure many more will emerge:

  • a single batch that needs to be processed (amazon now has hadoop services ; also consider load testing from the cloud, some sort of one-off processing, or anything else that is a spike in demand could be good)
  • overflow capacity for something like flash traffic during holidays for retailers – extend your private infrastructure, or certain pieces of it into the cloud and wind down when you are done
  • POC, development – it is hard to test on the same hardware as prod, so roll your stuff out on the cloud and then for prod/uat deployment put it back inside
  • one-off isolated apps that can deal with current state of SLAs and lack of private clouds, or even pieces of existing apps

there is a chance for internal infrastructure folks to learn something from the cloud experience. in most large companies servers and storage have been increasingly provided as a service and billed back to the projects, but provisioning is still not elastic, and utilization is often the usual low numbers. granted, more and more are using vmware to virtualize (at least dev/uat) to increase utilization, but it is a far cry from the experience of the likes of amazon.

the ideas and some of the tech from the public clouds could and should be looked at by the internal infrastructure people, and not just the servers/storage, but also those that provide middleware services – messaging and monitoring, for instance.

clouds in your own data centers? some of the vendors seem to head this direction – give us the servers and the datacenters and we will create cloud infrastructure for you, taking care of management, monitoring, apis, provisioning, etc.

i wonder how the chargebacks in organizations will change between departments – since instead of a capital investment upfront with depreciation we can convert it to operating expense with pay for use billing – would that allow us to win anything? of course, for small companies it is great – no upfront costs, no hardware, etc.

ms azure is somewhat an outlier here – first of all, it lacks tinkerability (yes, it is a term) – the barrier for entry is too high, but at the same time it is not a vertical app, but a full-blown platform with all the development tools in place. the problem is that it is too opaque, and i would imagine it will be a while before the whole kitchen sink has proper api, billing, provisioning, etc working properly – as usual the idea is fantastic, but the implementation, knowing the track record, is something to be wary of. since windows is notoriously hard to automate, perhaps azure will finally sidestep this problem and offer that as a service, but i cannot see how it can completely do it, unless it provides something as easy and transparent as ssh+shell scripts and declarative versioned management for that.

coming up

development in several directions – granularity of service, privacy of the cloud; standards – one must talk about a certain place in the continuum – standards for infrastructure level monitoring/provisioning are perhaps possible, but once we run into more vertical services, standards make little sense, since you are buying into the provider.

there will be consolidation, since, as failures of ibm and sun showed and success of amazon shows, it is a low-margin business, and amazon knows it first-hand.