I will explain quickly how to install mc on mac (Mac OSX Leopard 10.5.6) using Fink. Installation with Fink should be painless and this blog post should not exist but I experienced an issue with the process I wanted to share quick solution:

1. If you don’t have Fink yet install it
2. Run:

sudo apt-get install mc

3. Try to start Midnight Commander:

mc

4. Fink should install all dependencies but if you encounter following error go to step 5, if not you are done:

dyld: Library not loaded: /sw/lib/libintl.1.dylib  Referenced from: /sw/bin/mc

Reason: image not found

5. Small dirty hack to fix the previous problem:

sudo ln -s /sw/lib/libintl.3.4.3.dylib /sw/lib/libintl.1.dylib

I know that there are more clean solutions than this one. Share this with me! What’s your favourite OFM?

Share This

Resilience

Terracotta clusters offer simple and scalable HA implementations based on the Terracotta server array. Terracotta server arrays can vary from a basic two-node array consisting of an active server instance backed by a hot standby (for instant failover), to a multi-node array with many active server instances providing scale and deep failover coverage. Terracotta give high availability of the data by not only replicating it across servers for redundancy, but also by providing a simultaneous permanent storage of all current shared (in-memory) data to disk – available to all server instances (no loss of application state). Temporarily disconnected server instances and clients are automatically reconnected, hot standbys restored without operator intervention. There is no single point of failure and bottleneck in the Terracotta architecture.

Failover

Terracotta server array provides instant failover and continuous uptime and services using a hot standby or multiple active servers. Multiple Terracotta servers can be clustered together in active-active or active-passive configurations, helping to further scale Java applications and to provide disaster recovery.

DB Persistence

Terracotta helps to protect database in a scale out architecture. There is a problem with usual approach with a cache in front of the database. The performance of the cache is degradated when the number of nodes increases. Hibernate offers a second-level cache option, which can improve the performance of the Hibernate application by eliminating the need to fetch often used data objects from the database, instead storing, or caching, that data in process with your application. Without any mechanism to provide replication of the underlying cache, data written in one node can be stale on another node. This problem is not solved by Hibernate, rather it is up to the underlying cache to provide a replication scheme to keep multiple copies synchronized. Terracotta provides a consistent mechanism to keep any cache written in Java synchronized, and therefore provides this support for caches such as EHCache. Advantages: Performance — Reading and writing to replicated data with Terracotta can be 10x - 100x faster than other solutions, Cluster-wide load — Replication of data eliminates the need for more than one node to load data from the database. In a scaled-out application, this can reduce database load by a significant factor due to the fact that only one node needs to request any piece of data for a cache miss and all subsequent requests on other nodes will result in cache hits.

Distributed caching implementation

Terracotta uses concept of the Network-Attached Memory. It clusters JVMs directly underneath applications providing distributed, shared heap. The implementation doesn’t rely on serialization of whole objects, rather on instrumentation of the byte code and injecting hooks in there which allow synchronizing of deltas in the object state. State changes in a Client JVM are published to Terracotta Server Array and all other Client JVMs are seamlessly updated. Other Terracotta’s features apart from shared heap are: distributed locking, distributed data structures – (HashMap, ArrayList, LinkedBlockingQueue, any POJO), guaranteed coherent clustered objects. Objects do not have to implement Serializable to work with Terracotta.

OS/Platform restrictions

Terracotta is a 100% Java solution.

Certified platforms: Solaris 10, Solaris 9, RedHat ES4, SUSE ES10.1 (32/64bit), Windows Server 2003 R2, WindowsXP (dev only)
Server JDKs: Sun Hotspot 1.5.0_16, Sun Hotspot 1.6.0_07
Client JDKs: Sun Hotspot 1.4.2_18, Sun Hotspot 1.5.0_16, Sun Hotspot 1.6.0_07
Containers: Tomcat 6.0.18 / 5.5.26 / 5.0.28, Apache Geronimo 1.1.1, BEA WebLogic 8.1 sp6, BEA WebLogic 9.2.MP2, JBoss 3.2.8.sp1 / 4.0.5, Jetty 6.1.11, WebSphere CE 1.0.1.2 / AS 6.1.0.7, Glassfish V1 ur1-p01-b02, Glassfish-v2 ur2-b04

Ease of implementation

Big advantage of Terracotta. A clustered application looks no different than a standard Java applications. In theory a correct multi-threaded application can be clustered just by providing a simple xml config defining roots of application state hierarchy which one wants to share across multiple JVMs. Distributed locking and thread coordination uses usual language artefacts like ’synchronized’, ‘wait’/'notify’ and java.util.concurrent support. Pre-existing Terracotta Integration Modules (TIMs): purpose-built, tested, and tuned to implement a particular clustered architecture pattern or integrate with a particular third-party technology, for example use TIMs for Spring, Hibernate, Quartz, Compass, Lucene, Guice, Camel, Struts, Joda time and more to seamlessly add clustering to an application. Last but not least: Terracotta is an open source product with an active community.

Hardware requirements

Client:

Memory Sizing - Java Heap: each client JVM should do work on data that fits in its local heap
Memory Sizing - RAM: enough RAM to accommodate the heap of the Terracotta client JVM
Number of client nodes: determined by the total size of the active clustered data set and total required throughput. Entire data set will fit in the sum of the total heap available for clustered object storage across all Terracotta client JVMs.

Server:

Memory Sizing - Java Heap: Ideally, all of the clustered object data should fit into its heap, note: allow for garbaged objects, not recommended heap > 6/8GB
Memory Sizing - RAM: enough RAM to accommodate the heap of the Terracotta server JVM. In addition, there should be enough RAM headroom to keep the blocks of the Sleepycat data store files in the host operating system’s filesystem cache for fast access.
CPU: dedicated server, capacity planning needed. Note: The more garbage your application creates, the more CPU resources will be consumed by the Terracotta Distributed Garbage Collector. Likewise, the higher the object read or write rate between Terracotta client nodes and a Terracotta server instance, the more CPU resources that server instance consumes.
Number of server nodes: min 2 for HA and failover

Network

Gigabit full duplex between server and clients, and server array, low latency network, redundant NICs and redundant switches with automatic failover

Performance

According to Terracotta: it is faster than other distributed cache, data grid solutions. It is due to the nature of synchronizing only deltas of object state. Terracotta scales much better than i.e. Coherence even with big transaction payloads. At small scale it has throughput 2x Oracle’s at all transaction sizes. At high scale (8 nodes) throughput was as much as 10x higher than Oracle. However independent tests of a specific use case scenario should be performed to back up the results.

Support package

There are Enterprise Subscription packages: production support GOLD 7X24 | SILVER 5X12 with issue escalation privileges and procedures. Also consulting and training services. Pricing individually discussed.

Code stability

Current version 2.7.1. Code is mature as the company started to work on Terraccota in 2003. Two years ago project has been opensourced. Licensed as Terracotta Public License, based on the Mozilla Public License. Free version requires displaying the words “Powered by Terracotta” in user interfaces. Commercial Version removes this requirement. Typical price $7,000 per node. A single Terracotta server can handle up to 150 nodes, but on heavy Java applications, such as those used in online reservation systems, that gets reduced to somewhere between 15 to 20 nodes per Terracotta server.

Partitioning

Workload partitioning:

Terracotta does not ship with a particular workload partitioning strategy in the box. Layer 7 sticky load balancer that is able to route requests for a particular user session to the same Terracotta client application server and is likewise able to balance user sessions evenly across all available application servers can be used to achieve workload partitioning. Use of round-robin or a non-sticky load balancing is strongly discouraged. Other forms of workload partitioning may be required for different use cases. Implementing workload partitioning algorithms in Java that can then be made cluster-aware via Terracotta is often a simple way to meet custom workload partitioning requirements.

Data partitioning

Each application server should only have the data that its workload requires access to in heap. (Magic warning!) Terracotta detects how your application uses its data and optimizes the data location automatically to minimize network updates. Terracotta manages replicating in the most efficient way. Only deltas to your object graph are pushed, objects automatically reside in JVMs that need them, and not in JVMs that don’t (vs. alternatives that always force you to configure and partition up front).

Transactional

Terracotta transactions are sets of clustered object changes that must be applied atomically. Transactions are bounded by lock acquisition and release. When a clustered lock is acquired by a thread, a Terracotta transaction is started and all changes to clustered objects made within the scope of that lock are added to that transaction. When the lock is released, the Terracotta transaction is committed. If a thread attempts to modify a clustered object outside the context of a terracotta transaction, a runtime exception will be thrown.

Replication and consistency

Fully synchronous replication between nodes. The data is always coherent and doesn’t suffer any cache drifts.

Share This

My girlfriend is pursuing chartered accountant qualification. In order to qualify as an ACCA member, one has to complete 14 exams. The length of time it takes to qualify depends on the student as the course is designed to be flexible. Each year there are two examination session and one can sit up to four papers per session. With just couple of exams, it makes substantial amount to read, digest, revise, rehearse, to be able to pass. But in the same time it is pretty predictable. If you put this much of effort you can expect particular result. So, the problem can be defined as:

with a limited time on hands, how to score >= 51% for each of the exams one attempts to pass.

I could see her struggle. She knew what she has to do but she didn’t know if with current time constraints it is durable. She didn’t know if she will be able to prepare well enough for all the papers, or maybe drop an exam to give more time to other exams. What was needed is a simple plan with estimation put in realistic time frame. I decided to step in and help organize it using agile planning tool which I’ve been using for last two years: ScrumWorks. I’m trying to be quite serious here but I can see glimpses of smile appearing on faces of many people reading it now. I understand and it would be quite amusing for me as well. But hey, there is no such thing which we can’t do to entertain other people!

We started our planning with creating user stories. It would map directly to modules in each paper. The size of each user story would be the same to start with. Then each user story would be tasked out: each module requires particular amount of time allocated to reading, making exercises, revising. On the top of that there was time allocated to mock exams and wide spectrum revising. Each of the tasks can be quite well estimated. What’s unusual here is that all the user stories were tasked out up front and not on weekly iteration planning. In this case it was possible and needed as the deadline is fixed and domain well understood. After this agile planning exercise we ended up with very clear backlog. We knew what it takes to pass exam. The second part of this was allocating user stories with tasks to particular weekly iterations. It was easy enough just to divide workload in equal batches and reserve some time in last two weeks for this known-unknowns which always appear before release.

It’s her fifth iteration now. Except the initial introduction of the process I haven’t been interfering much. Each Sunday she was re-planning to accommodate real velocity, adding, removing or changing tasks, re-prioritizing. I have to say that she loves Scrumworks! It is a very simple tool which just does the job. Especially drag-and-drop re-planning and burn down charts she found very handy and useful.

So, what has changed since introducing this process? First advantage is improved visibility of progress which in very honest and direct way shows if one is doomed or not. It helps to make difficult decisions. With weekly iterations it helps to maintain a high average focus and saves a lot of stress being generated by not knowing if we are behind or ahead with preparations. I recon I will have to wait till exams to see how well the geeky project management can help “an average Joe”.

Share This

As it is going to be my first Marathon I wanted to run some other longer run just before Paris to boost my confidence and I have chosen Half Marathon in Lisbon, Portugal which is 2 weeks before on 22nd of March 2009. I decided to do that one because of the weather which should be better than in UK or NSE (Non-South of Europe :). Plus, I have never been to Lisbon and I found the location of the run very appealing. Just check out the photos!

And the last but not least on my calendar the Bupa 10k in London on 25th of May 2009. It should be quite fun run! The race starts on Birdcage Walk and follows an anti-clockwise route around the City of Westminster and the City of London via Parliament Square, Embankment, Blackfriars Bridge, Queen Victoria Street, Cannon Street, Great Tower Street, Crutched Friars, Fenchurch Street, Leadenhall Market, Cornhill, Queen Victoria Street, Puddle Dock, Embankment, Horseguards Avenue, Whitehall and via Trafalgar Square to the Finish in The Mall.

Congratulations for Gabby for finishing her first 10k couple of weeks ago!

Share This

• homeworkers based in the same city,
• to people based in the same country in different offices/cities
• followed by team members located in the different countries
• then continents and
• time zones.

Luckily we haven’t left this planet yet!

It is nothing unusual to have a team working together day by day dispersed between two, three or four timezones (I’m lucky now with three timezones but with majority of people in the same room). Searching for the new highly skilled professionals, acquisitions in new global markets or outsourcing to cheaper regions could be some of the reasons for increasing distribution.

The physical distance and time difference is not helping to create a funcional agile team. It is actually very far from ideal situation where people sit in the same room, with whiteboard handy and plenty of formal and informal communication going on, following all practices. Broken communication and being unable to apply original agile/xp practices are first problems which come to my mind. It is rather intuitive that dispersed teams will never be as good as team working under the same roof. Or maybe, as I think the last thought goes a bit too far and takes away any hope, the amount of work and skills required to create successful distributed team is bigger for at least an order of magnitude. And again, as always in agile, it is up to each and everyone in the team to make it work.

To fix the broken communication we should actually simply collocate as often as possible with emphasis on planning and release time. It is almost unavoidable. But it is also investment which will pay off when team members will have to work on distance together. People who actually know each other will later on communicate much better. To enable this communication we have to provide right tools: unlimited voice communication with conferencing capabilities, IM clients, tools for remote desktop sharing, access to the same network resources, webcams, hand free headsets. One should also learn how to be open and approachable, that’s a key factor! Pairing is for many people difficult even in the same room and becomes even more difficult on distance, but still possible and beneficial. It’s simply much harder and takes longer to learn how to do it comfortably. Couple of pieces of advice: don’t break something what works by constantly reorganizing teams, don’t loose some people by letting them drift away forgotten. As I already mentioned not all xp/agile practices can be used in original form like pair programming. How you are going to use for instance index cards stuck to a wall with dispersed team? It might not work. But there is always some answer. Maybe a given practice can be slightly modified to fulfill its role, or maybe it can be replaced with some other practice (see paper from Thoughtworks on Subclassing XP) which might work better. To figure out what works and what doesn’t frequent retrospectives with all members is a must. As I said: it is all about communication!

Share This

Firstly, I managed, thanks to all your generous donations, to raise £546, which exceeds the target by far. I am certain the money will go a long way with a little help from The Starfish Charity! Secondly, I finished the Royal Parks Half Marathon, my first such long run. My time was 1h 58min 40 sec, couple of minutes faster than my target time. Yes, it was hard, it is bloody 13 miles, isn’t it? But with 12 thousand other runners around and thousands of people cheering along the way it was much easier. Afterwards a couple of days of being stiff but no serious injuries. If you want to try a half marathon I really recommend the Royal Mark Half. It was a first edition of this run this year and I think it already found enough fans to have a permanent entry in London’s runners calendars.

The route is prime with start and finish in Hyde Park, leading through Green Park and St. James Park and places and landmarks like Buckingham Palace, Houses of Parliament with Big Ben, London Eye, Embankment, Trafalgar Square, The Mall. Tremendous location. Plus weather! What’s the stellar day. Mid October but the day was sunny, with blue sky and maybe around 24 degrees. Perfect setup for the run! Now couple of goodies for you: here are some photos from the day. There is also GPS data with some stats (distance is slightly inaccurate as the position signal was noisy that day).

Big thanks to Andre Vermeulen who convinced me to run the Royal Parks and raise money for the Starfish.

Side note: I’ve been rejected 3rd time for London Marathon but I already signed up for the Paris Marathon on 5th of April 2009. Let me know if you want to do it as well.

Share This

Just to give some perspective… In the past when working on the BT SDK with Web21c team I was using ScrumWorks for managing user stories or, as some other people would call it, features, improvements or bugfixes and mapping those to particular releases. The public releases were very infrequent and scheduled every 3 months. Emergency releases with bug fixes could happen more often. Of course as for an agile team internal releases occurred more often, usually every 2 weeks ended with an acceptance session with a product owner. The Subversion has been used as the source repository, with all active development happening usually in parallel in the trunk. Some time before release the code was frozen in a branch by copying an active trunk and only bug fixes were applied to the release branch, subsequently merged back to the trunk. I could call this process “Develop in trunk, release from a branch”.

At my current project we use only JIRA for managing bugs/features/improvements and matching it to particular releases and the releases will occur much more often (every week or two) with possible multiple emergency releases in meantime. Source is kept in Subversion as well. The team is not calling itself “agile” however I think it has to be very agile to cope with the schedule and a right process should be established to support it. It could look like:

Development time

1. In JIRA we create a bunch of tickets for new features, bug fixes or improvements. A developer is assigned (hey, who likes that phrase?) a task to work on.
2. Before starting work a new branch is created from trunk with the JIRA number as a name
3. Work on that task commences and all changes are committed to the new branch. If there are several dependant tickets then JIRA should have a parent ticket created and all dependant tickets assigned as children. It resembles higher level user story with tasks from Scrum.

Build/Release time

1. In JIRA a release or version will be set up and given a name (i.e. 1.0.1). This will contain a list of tickets that are to be used for this release
2. A new branch will be created in SVN from trunk, matching the name of the JIRA release.
3. The branches that match the JIRA tickets for this release are merged into the new release branch.
4. A continuous integration build is pointed to the newly created release branch.
5. The build should pass unit tests, integration tests, automated acceptance tests, is then deployed to UAT environment for final user acceptance tests.
6. When ready for release, a tag is created from the branch matching the JIRA release name. The software is deployed to production.
7. The code from the tag is now merged back to trunk

It is clearly “Develop in branches, release from trunk”. Sounds weird at the beginning. Have to admit that I didn’t use exactly this process before but my first impression is that it is really structured methodology which:

• gives superb view what actually is currently deployed (via mapping tickets to releases in JIRA)
• allows adding/removing changes easily – we can always take a previous tagged version and apply selected modification by merging
• supports external auditing

In the same time my gut feel tells me that:

• merging before release might be a nightmare (volunteers for a release manager?)
• the process seems to be too regulated, “boxed”, “walled”

It will very much depend on the release schedule and how often the changes will be released which means how often the trunk will be up to date with the latest code. Let’s assume we have biweekly releases. It will mean that at the average a developer will be working with a one week old code. With an application in a maintenance mode with occasional bug fixes which doesn’t change dramatically it would be acceptable but taking as example a new project with many contributors, dependencies between components and a lot of expected changes in design and implementation I think that might be problematic.

It really doesn’t encourage refactoring neither. Just imaging what would happen if two branches taken from the same version of TRUNK were exposed to wider and more intensive refactoring? And for me refactoring is a necessary factor which means continuous and gradual code quality improvement leading to system quality improvement. I know, we should do everything right first time. Why I didn’t think about this before?

Other downside which I can see is that we might completely lose transparency and visibility what is happening with the code. People will commit to “own” branches without a continuous integration. I have to say that I like to monitor changes to current source code via email from continuous integration with last check-in comments. It gives me a way of quickly assessing if the ongoing development is related to my current task, I can merge incoming changes one by one with my changes which means that I don’t do something which someone already has done or something which doesn’t make sense any more.

So, I have mixed feelings. The biggest advantage of the process I can see is easy adding/withdrawing pieces of functionality at short notice. And it (at least in theory, not mentioning the merging hell) fulfils the role very well. The process actually resembles the way how open source communities work. Each contributor branches from trunk and does development on his/her own without breaking anyone else code. When feature is ready then it is (after code review) merged back to trunk or release branch.

It appears that the problem here is caused by subversion not being the best at the merging job. So as we can see a good tool for merging is essential here to make the life easier. It looks like open source guys moved towards GIT and BAZAAR now with GIT getting a lot of traction as it has support for SVN as well.

The process described is not final and would look into refining it to better support given development/release practises. If you have suggestions, comments or you have been using similar process please free to contribute and share.

Share This

Share This

Last Sunday I took part in a Nike project: The Human Race which was aiming to get million people worldwide to run 10km. Here in London the race started at the Wembley Stadium and the finish line was located on the Olympic Way next to the stadium. I have to honestly say that despite a heavy rain before and during the race it was really good fun! Pretty amazing feeling to take part of such a big run starting at the pitch of famous Wembley and to run along with Paula Radcliffe. Me and my girlfriend managed to finish in 01h 01min 53sec (6.43sec/km - 2.5km, 6.16sec/km - 5km, 5.48sec/km - 7.5km, 5.58sec/km - 10km). London managed to get 2nd fastest average time of all the cities taking part in the race with result 57min 47sec, just 1min 13sec more that Madrid. Well done to everyone! Here are some photos from the day.

I wanted to apologize to everyone who had a wrong impression that I will run a single 31km run for the Starfish charity. I believed I made this clear but probably not. So… I was planning to run Nike race (10km) and then a half marathon (21mk). I am really doing my best! :)

Share This

I usually don’t do that but this time I would like to ask you for your financial support and I am inviting you to join me in this effort to help improve the lives of children by raising £500 for The Starfish Charity.

I set up a fund raising site on Justgiving which makes donating quick, easy and totally secure. I put also a widget on the right side of this blog so you can see the fundrising progress. I will be posting updates on my training and results as always to my Twitter and Flickr streams.

I am really nervous if I can raise so much as it is my first such effort. However I know that I can count on you!

Share This