Personal blog of Davorin Ruševljan.
I really like version control systems, especially when they get me out of some of my careless deeds. Other that that I prefer if I can remain unaware of them, and that they do not compete with my brain cycles with other tasks.
Git is in many ways great, but unfortunately, it requires constant attention and care. You just need to have rather deep understanding of how it operates under the hood. There are some great cheat sheets - but they will get you only so far that you get yourself hooked into git. But if you rely only on them, pretty soon you will be shooting yourself in both feet while tightening the rope around your neck.
Some of the reasons while git can be demanding stem from its roots. Once upon a time Git was a VCS toolkit assembled of procedures to manipulate git database. So it was more designed to offer nice and complete API, rather than simple command line user interface. As more people with less knowledge of git started using it, git got friendlier command line, but some things remained. For instance, imagine you have been experimenting a bit changing some files in working directory, and then you decide you just want to throw all that away, and return to last commit. It is something conceptually simple, and in my work-flow occurs on regular basis. Yet to instruct the git to perform this simple operation you have to tell it:
git reset --hard HEAD
You can find this on number of cheat sheets, but I could not remember it if my life depended on it. I mean reset sounds like a serious verb (not necessary connected or limited to what I want to do), and takes one option (--hard), and one parameter (HEAD). What if I get some of that wrong, what in the git world is going to be reseted and to which effect? So I kept googling for it each time I needed to perform this operation. Until I found this great explanation of git reset command and things now finally make some sense to me.
What I wanted to say, is there is just no easy way with git. It demands its own time and understanding, sometimes even for simple operations. I definitely like git, but it surely finds its way to drain my resources.
Recently AMQP working group has promoted 1.0 version of its specification to final status. While small tick in version numbers from 0.9 to 1.0 might suggest a small incremental change, nothing could further from the truth. AMQP 1.0 is completely new and fundamentally different protocol than existing 0.x family.
What do I mean by fundamentally different? Well, to begin with, problem domain that 1.0 tries to solve is different. Existing amqp protocols describe messaging brokers, their behavior, how to connect to them, and how to control then (to certain extent). So there were exchanges, exchange types, routing keys, queues etc.
1.0 takes different route. It tries to define protocol that could be used to connect more or less any 2 messaging entities - called nodes in 1.0 terminology, and safely and predictably transfer messages between them. It defines how to achieve various message transfer semantics: "at least once", "at most once" and "exactly once". It also specifies how to resume interrupted transfers if they occur.
But what nodes do with those messages after transfer, well, that is completely up to them, and specification leaves this open. It could be that you are transferring a message to old style AMQP broker with exchanges and queues, and it would do probably same thing as before. It could be that you are sending a message to some JMS system, and effects of that message transfer would be according to the JMS semantics. Or you could be transferring a message to your in house optimized messaging entity, like for instance stock exchange trading system, which would in turn process that message as trading order, match it with other orders, execute, and distribute new price information further down the line.
So one look at this might be that by specifying less (since it does not specify broker behavior at all), 1.0 provides opportunity to apply it in larger number of situations. But keep in mind that at this time, this is still just an opportunity, not something that you can do right away. Someone would need to write JMS gateway (or write trading system that uses 1.0) before that.
I hope that after this 1.0 release, which could also be considered "core specification", AMQP group would get really busy on other specifications layered on top of it, which would deal with standard broker behavior and management of brokers.
After a rather long period of my life that was dominated by public transport and cars, in recent years I have rediscovered the joy of riding a bicycle. I use it both for daily commuting, and for visits to countryside around Zagreb or family rest house on river Kupa.
When I (re)started driving a bike, it was an old faithful Rog Senior bike that was resting in my brother-in-law's basement. If you are thinking of trying to use bicycle for the first time or after the long period, I would recommend the same strategy. Do not head for the bicycle shop, it is likely that you will spend a lot of money on bike that might not be suitable for your needs, or you may even never catch up with cycling leaving you with almost new bicycle. Instead head for the basements or flee market. There is great chance some of your friends have some neglected bicycle and would be happy to lend it or sell it to you for a small price. Bring it in for service and necessary repairs, hop on it, and it will serve you very well for your beginnings. After a year of such use, you will know much better what kind of bike you need, and the money you have saved on fuel or public transport will pay for the new bike easily.
As my daily rides started to get longer and longer, combined with me being an overweight, old Rog Senior started giving signs that such use might be getting a bit too much for him. So I decided that is now time to get him replaced, and did a quick wish list:
- road usage
- it should be suitable for daily commute on Zagreb roads
- it should be suitable for longer 60-100 km weekend rides
- decent brakes
- I would need to equip it with, lights, fenders, panniers
- d sturdy built drive, wheels, and tyres with puncture protection to cope with might weight and glass on the streets
- a bit of under looker so that it does not attract thieves too much
- not to cost an arm and leg - it should be a work machine that pays for it self, not a pet.
In local shops, there are some great bikes, but I was having trouble to find one that would fit well my wishes above. Since I was in no hurry, I decided to try to build one. I bought old bicycle that I used as a frame donor, and started to collect all other necessary parts. Which gave me an opportunity to learn what are basic parts of bike, how they interact, and which parts are compatible with other parts. Bicycle is a simple machine, but when you are noob, everything is new and exciting!
As the pile of parts has reached critical mass I have started working on bike, lacing the wheels, disassembling the old bike to the bare frame, painting it, assembling the drive and derailers, connecting the chain, mounting shifters and brakes. Sometimes I worked for a few days in a row, sometimes a whole month would pass before I could return to do some more. Sometimes I had to shop for another part since I did not know I need it, or buy another one that would fit. Also along the way I had to obtain some tools specific to bicycles, like the chain tool used to break or connect the chain.
And after a little more than a half of year, my bike was ready for maiden ride. I drove it to bicycle shop so that they check if everything is in place and tightened well, and that was it! Now after 3 months of use, and more than 2500 km I must say I am very happy how it all turned out. I got a bike that suits my needs and learned something. It was fun to build something physical with my hands, not something I as programmer do quite often. On the other hand it was still simple enought to be within my very limited skills. Lastly, riding a bicycle often gives you a feeling that your are a bit more self contained, no dependency on gas, parking, rush hours. Just hop and ride. And when you do that on bike you have built by yourself, that feeling even gets stronger.
So to summarize, if you would like a cheapest bike, wait for January and shop. If you would like to have something custom tailored, with unique touch, and would like to learn something along - building one might be a fun!
After a rather long process, AMQP 1.0 Recommendation has been updated and published.
The spec was updated based on results from 3 Connect-a-thons on which several vendors tried interoperability of their implementations. Wording of the spec was improved, and it seems to me that it is now more clear.
Anyway, it seems to me that there is still a lot of work ahead for AMQP. That is, if goals from AMQP 1.0 presentations floating around are still within its target. Current 1.0 spec defines codec, transport, messages and message transfer between 2 nodes, transactions and security. But broker behavior, and many other planned aspects of 1.0 are still in drafts.
I did a quick peek at CloudFoundry, recent attempt of open sourced PaaS by VMWare. Currently besides announcement presentations, there is not much documentation about it, so sources are main source of information. I have also found this post and presentation very usefull.
From the bird eye perspective, CloudFoundry seems like small, tight, piece of code, that just does what needs to be done. It is written in Ruby, and the code seems nicely written.
CloudFoundry deals with deploying of apps to the cloud, updating it, connecting to the services like data base or message queues, starting and stopping of application instances, load balancing and monitoring.
On one hand this is not much, but it is certainly needed. And if open sourced model would bring a number of additional bindings for services and frameworks that are not supported at the launch, CloudFoundry could become a very interesting building block. Needles to say it would be great if Seaside could get supported.
Ineteresting angle is that while VMWare offers its service CloudFoundry.com, others are free to offer their service. So one could have app running on micro cloud on his notebook, and later on move it to the cloud to the provider of his choosing.
In CloudFoundry architecture, there is an entity called router, which intercepts all incoming requests, and distributes them to correct instances of the application. I guess over the time different providers could compete on offering routers that could sustain huge amounts traffic.
Anyway it will be interesting to see if this router can nicely coexist with Seaside.
