I have played a little with OpenShift and it is very easy to use and deploy. I ported a small application using node.js and Redis to it in a matter of minutes (I will write about it in my next post).
Over the past 6 months, we've "scaled" MongoDB by moving data off of it. [...] For key-value data, we switched to Riak, which provides predictable read/write latencies and is completely horizontally scalable. For smaller sets of relational data where we wanted a rich query layer, we moved to PostgreSQL.
As usual, take this with a grain of salt (performance varies with data size, use cases, read/write ratio, etc).
I had a short experience developing with MongoDB and I like it. Unfortunately, I had not the opportunity to see how it behave in production use.
What we're really trying to build is the Internet's file system. —Drew Houston
As a follow up to my previous post, this is an interesting interview from Dropbox founder, Drew Houston.
I use heavily Dropbox to synchronize contents and share documents between my iDevices and home/corporate laptop and it works without any problem.
I have not used their APIs but I hear it is great. Given the number of apps installed on my iPhone and iPad which uses it to share content, it is likely true.
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.
Talking about WebSockets, it is nice to see that Internet Explorer will support them. This post provides a good and up-to-date explanation of WebSocket protocol.
Watching his presentation reminded me of a conversation I had with an ex-colleague about messaging and distributed execution frameworks.
I have contributed to several messaging servers over the years, mainly on HornetQ. During my previous job in a Web media company, I also used Hadoop Map/Reduce for Big Data processing.
With Big Data, the amount of data is so important that you can not process everything sequentially. Instead you parallelize the execution on several nodes. In practice, this implies to distribute the execution: the execution code (the mapper and reducer tasks) moves to the data nodes - where the data to process is stored - and runs locally.
With Messaging, you can achieve the opposite: to distribute the data. Messages containing the data are sent to consumers that will process them. In many cases, the data transported inside the messages is not the data to process; it can be an event or contains the location of the data to process. Nonetheless, the result is the same: the execution code will not moved, it will fetch the data and process it on its own node.
Messaging moves the data close to the execution code.
Distributed Execution moves the execution code close to the data.
If I understood Galder correctly, Infinispan proposes the two approaches:
a Map/Reduce model where the mapper and reducer tasks are sent on the cluster nodes to distribute the code execution.
Messaging is a model that is widely used in entreprise applications and may become mainstream on the Web with the support of WebSockets by all Web browsers. Distributed execution framework like Hadoop Map/Reduce or Twitter Stormwill become mainstream as the amount of generated data to process and analyze (on the Web or behind firewalls for entreprise softwares) will continue to grow.
Infinispan seems to hit a sweet spot by providing the two models and the ability to mix and match them. I am looking forward to seeing what's next for Infinispan and the best ways to leverage it...
For the full fiscal year 2012, total revenue was $1.13 billion, an increase of 25% over the prior year, and subscription revenue was $965.6 million, up 25% year-over-year.
I take pictures. I use Lightroom to process them. I like it. The current camera emits DNGs that average between 20-25M, and I take them dozens or hundreds at a time. Lightroom 4 is, um, not faster than Lightroom 3 and I see no evidence that Adobe knows how to make any future version faster. Lightroom on the current machine is just barely fast enough, where "just barely" means "not really".
I have the same problem: my old MacBook is slowly dying and can no longer run Lightroom 3 (or Xcode for that matter) in an usable fashion. I download the trial version of Lightroom 4 and it is worse.
I am looking to upgrade to a new Apple laptop. My ideal machine would be a 13-Inch MacBook with Retina Display, SSD (+ external HDD), at least 8Go and the latest Intel processors. I am waiting for the next generation of MacBook Air and Pro to be released to check if one of their models matches my expectations. However, I will monitor comments on Tim's post in case the next Apple laptops do not change that much.
In the mean time, I am stacking up photos until I can post process them...
Note this method of structuring cannot be done in a sequential language - since there is only one thread of control - thus in a sequential language all error handling MUST be done within the process itself. That's why you have to program defensively in a sequential language - you get one thread of control and one chance to fix your error.
— Joe Armstrong
I can not warm up to Erlang language and syntax but there is no denying that the Erlang worker/observer model is much more simpler and simple to figure out that code which mixes business logic and error handling.
