Jeff Merlet - Filed under 'architecture'

November 9, 2009

My Twitter Hacking list

Taking advantage of the new Twitter List feature, I just created a hacking list focusing on relevant programmer news, from architecture to coding, including high scalability systems and a dose of cloud computing. I tried to avoid including "people" with too much noise or tech news style. For such lists, I would recommend scobleizer lists: you can not find more exhaustive lists than his!.

This list is going to evolve by adding or removing "people" based on noise level and technical relevancy. Any feedback or suggestions is welcome!

Loading mentions Retweet

Filed under // architecture Cloud Design Developer Development hacking Key-Value Store list Programming Scalability Twitter

Comments [0]

June 26, 2009

Liked "Twitter, an Evolving Architecture"

via infoq.com

Loading mentions Retweet

Filed under // architecture Cache Deployment Design memcached Scalability Twitter

Comments [0]

June 3, 2009

Must read and apply: "TOP 25 Most Dangerous Programming Errors"

Nothing really new here, but still a good reminder for architects and development teams. And nice to see this being pushed to CS curriculums.

Via http://www.sans.org/top25errors/#s4

Loading mentions Retweet

Filed under // architecture Developer Development Programming Security Software Tutorial

Comments [0]

May 20, 2009

Liked "A Low Impact Woodland Home"

via simondale.net

Loading mentions Retweet

Filed under // architecture Design House Permaculture Straw Wood

Comments [0]

May 7, 2009

And here is the 400+ years old door of our rental place in Provence, Sisteron

Loading mentions Retweet

Filed under // architecture Door History House Old Provence Sisteron Wood

Comments [0]

May 7, 2009

Pretty cool 400+ years old carved beam in the Provencal place that we rented for the next 2 months

But really scare our Californian baby girl: no worries there is no earthquake here!

Loading mentions Retweet

Filed under // architecture History House Old Provence Sisteron Wood

Comments [0]

April 24, 2009

REST Web services resources for Java developers

Representational State Transfer (REST) is an architectural style for creating, maintaining, retrieving, and deleting resources. REST's information-driven, resource-oriented approach to building Web services can both satisfy your software's users and make your life as a developer easier.

via javaworld.com

REST Introduction

- The father of REST, Roy Fielding, dissertation on "Architectural Styles and the Design of Network-based Software Architecture"

- Why REST?

- For more resources see REST Wiki, including the REST in plain English article.

Building REST Services

- RESTful Service

- Building Web services the REST way

- Build a RESTful Web service

REST related Design Issues

- Versioning REST services

- Common REST mistakes

- PUT or POST: the REST of the story, or see also the interesting interview with Elliotte Rusty Harold

- Asynchronous REST or Slow REST:

- Instead of returning a custom object we could use the Content-Location header for the in-progress status URI of the requested operation. This URI could also use headers to provide information regarding the in-progress operation:

- Status-Code: "202 in progress" or "204 No Content" when completed or any error code

- ETag: for the operation progress status. Could be strong and still give a notion of progress

REST for Java Developers (via javaworld.com)

- Part 1 - it's about the information, stupid

- Part 2 - Restlet for the weary

- Part 3 - NetKernel

- Part 4 - The future is RESTful

REST Libraries

- Notes:

- All of them are supporting JAX-RS, aka JSR-311, the Java API for RESTful Web Services

- And here is good presentation of JAX-RS

- Restlet project

This is my favorite library, and I like the fact that it is running on GAE/J and supporting GWT

- RESTEasy from JBoss.org

- Jersey part of Sun's GlassFish project

- CXF from Apache.org

- REST Libraries usage trend:

Via GoogleVolume.com

Tools

- RESTY is a simple cURL-based command line tool

- rest-client is a Java-based GUI and command line tool

- HTTP4E is an Eclipse HTTP client

Update 1: Added a libraries and tools sections.

Update 2: Added a section on design issues related to building REST services

Loading mentions Retweet

Filed under // API architecture Design Developer Development HTTP Java Library Protocol REST Software Tool Web Services

Comments [1]

April 3, 2009

Trying to apply a MapReduce concept to synchronization

Trying to figure out if the MapReduce concept could be adapted to a synchronization process (server side mostly). I.e. could we find independent, parallelizable work unit? My first thoughts tend to be a yes. Hereafter is my first high level draft, on which I will work on and refine.

Coarse level: each data section (or database) could be an independent work unit

Could be problematic for interdependent section like container (or group or folder or etc.) referencing new item in another data section. Possible solutions: only parallelize the independent sections or use an optimistic approach and reduce could finalize potential identifier mapping
Pretty coarse level, but easy to implement

Fine level: each data section item could be an independent work unit

Would provide an easy way to parallelize the core of the synchronization process (duplicate detection, merging, field level conflict, etc.)
An improvement would be to put in the work unit n items, and the n could be dynamically calculated based on resources (memory usage, number of threads, network latency, etc.) availability and consumption (opposite effects)

The reduce part is aggregating the synchronization process intermediate results to produce the result of the overall sync process

Would be not easy to find a solution working for any type of synchronization protocol like OMA DS, a.k.a. SyncML, or FeedSync

Perform a double stage MapReduce with both coarse and fine levels

The MapReduce concept could be easily applied at a server instance level, which will result in parallel thread, but also at the cluster level as it is the real intend of MapReduce

At the server instance level the changes to integrate a MapReduce programming level should be easy by wrapping the core synchronization process
At the cluster level, the changes are more dramatic as impacting the intrinsic architecture and the deployment

We would have specialized node (process or server instance) like map, synchronization, reduce, etc.

The protocol and session handling would be around the MapReduce architecture

A synchronization process is always involving data and data storage either through a direct persistent storage access (database, etc.) or through a higher level service managing the data storage access

The specificities of the data storage (latency, atomicity, transaction, etc.) would also directly impact the granularity of the Map
In synchronization, the performances are almost always dependent of the data storage performances. I.e. direct impact on the design of integrating MapReduce

And now let's the fun begin to work out all the details and most importantly validate the feasibility.

Loading mentions Retweet

Filed under // architecture MapReduce synchronization

Comments [0]

Tags

architecture