The past six months have also shown that, without proper developer tools and a clear explanation of how things work in backend, things don't "just work" — in fact, quite the opposite: some developers have given up entirely on building iCloud apps for now, others are wishing for new APIs that would make the platform suitable to their needs, while the ones who did implement iCloud in their apps are torn better the positive feedback of "it just works" users, and the frustration of those struggling to keep their data in sync on a daily basis.
I played a little bit with iCloud on a iOS personal project. Unsurprisingly, it is hard to get syncing right.
It was obvious from the start that supporting iCloud would not been easy. There are many fallacies to avoid once an application depends on the network (especially when it is as unreliable and spotty as a cellular network) and version conflict resolution works best with a deep knowledge of your domain.
Apple documentation for iCloud is too high-level to be helpful. The best resources I found about iCloud development are lectures 17 & 18 of Stanford's iPad and iPhone Application Development by Paul Hegarty. These lectures give the correct mindset to comprehend and work with iCloud.
Supporting iCloud is not an easy task and it requires to really think about it. It is not just about dropping files in a directory. However when it works seamlessly, it improves and simplifies the user experience. The user benefit is worth the developer pain. With the release of Mountain Lion I expect Apple to continue to improve iCloud API and features and make more developer resources available as they learn from adding iCloud to their own apps.
The X was growing on me. I was walking the streets of a new place with two cameras and three lenses and never once tired of carrying this gear. It was hanging on my side or in a pocket. The weight of all of it was distributed around my person and I never felt it. No tired neck. No sore shoulder. Kick ass image quality. Lens choices. As long as I was methodical in my shooting the camera, and all of its quirks and laggy issues, were beginning to fade away.
I am searching for a camera with good image quality that I can bring with me anywhere (my DSLR is too big for that). I like the X-Pro 1's retro look, its size seems adequate and the IQ is outstanding:
An analysis of using Redis to store data by my former colleague Brice Laurencin:
Do not over think your data schema when storing to Redis, it is faster than you may think, and a simple software compression may help you contain your data growth.
I have used a little Redis for a pet project and it is a great key/value store. Its sorted set data structure is invaluable to store time-based data.
Integration testing is hard but essential. It is hard to track down integration issues (due to a misunderstanding between the callee and the caller's contract/API/service) but that's where most of bugs are located from my own experience. Unit tests with mocking does not help. Who cares about my expectations about what a contrat/API/service provides if it does not match the actual implementation. Testing in situ is the best way to check the actual behavior.
Arquillian is a fantastic tool to help write, execute and maintain integration tests.
I prefer to take pictures with available light as I find the flash too intrusive. However this book makes me eager to experiment more: the possibilities offered by flashes open a whole new world of images.
To familiarize myself with running tests in JBoss AS7, I have created the smallest Maven project which uses Arquillian to manage an instance of JBoss AS7 with HornetQ enabled, deploy a JMS queue in it and run a test.
