First synthetic cells that operate

December 10, 2007 – 03:11

Enrico Fermi researchers have made simple cells comprising a fatty membrane containing just 36 enzymes and purified ribosomes.

The Italian team’s advance is to make simple cells which are essentially bags made up of a fatty membrane containing just 36 enzymes and purified ribosomes – microscopic components common to all cells which translate the genetic code into protein. The primitive cells are capable of manufacturing protein from one gene. The team chose a fluorescent green protein found in jellyfish because it was easy to see, using a microscope, when the protein is being made. “We are trying to minimise any system we put in place for the cell,” said Dr Murtas. “We can prove at this point that we can have protein synthesis with a minimum set of enzymes – 36 at the moment.” He hopes the project will teach him about the earliest stirrings of life in Earth’s primeval slime some 3.5bn years ago.

On software development business: startupping

December 8, 2007 – 18:05

Yurii Rashkovskii recently blogged about the structure of (consulting) software development house.

There he suggests:

Here we come to a structure for a consulting company that I like. Instead of being employees of some company, professionals of different kinds (i.e. developers, designers, sales, etc.) could team up and define their rules of game transparently. They can decide which cut of income is being spent for what — like 10% for reserve fund, 50% to developers, 30% for designers and 10% for sales. In this structure they are all in charge and if they could play together efficiently, nobody will be frustrated.

Doing this business for 10 years, I’d say that this plain idea won’t work as expected.

The real issue is that every person in such software development team should

  • understand what he’s doing; that is the team has to have a quantitative model of their business
  • share the common goal – why they are doing that? To become rich one day? To do an interesting stuff? Or what?
  • share all or at least knowingly distribute the risks

I’d say that all these three points are nearly impossible to have at once.

Take, the model. Hardly any of the software shops, I’ve seen, has a live documented software development process. I mean not the documents from ISO 9K ok CMM certification bundle that’s safely collecting dust somewhere. I mean the process that’s actually used and measured.

Let alone any company would be able to say and prove with numbers that they’d reach some milestone with 95% budget and clock time accuracy.

So I would safely cross out item 1 from “dream team” checklist.

Given that there would not be a quantitative verifiable reference, everyone in the team would understand the main business process differently. And that would lead to misunderstandings, conflicts and broken trust.

Moreover, even if at some point of time, team converged on the common understanding of the ultimate goal, they will still differ on the plan to reach it. No verifiable company model will lead to different predictions and actions of the team would become unfocused pretty early.

Alas, crossing 2nd item. Hardly they’ll have a common goal for a long time, necessary to build a sustainable business.

Finally, the most complex stuff. The risks. I find that just handful of developers understand that at all. We’ve too accustomed to the deterministic nature of our workhorses – computers. We tend to forget that real world is much more complex that any of our workstation and just could not be analyzed in every detail. Some should be viewed from statistic viewpoint.

I’ve seen no team that would be able to answer the question of when the particular piece of software would be finished and why. Those, who where “the best” at this always put the most risk on the end developers: they had to work overtime, under constant stress, lower quality and, of course, with no or little extra compensation.

Since that basic question could not be answered yet, how can each team member assess the impact of his action (or non-action) on the team and his personal revenue risk? What should guide him to make his frequent decision: “What’s better: spend couple hours refactoring or developing new feature?”

That way someone will alway try to underplay others by lowering his personal risk, no matter how it affects the company risk profile.

Summing it up, the attempt to build such a team, would reach the common attractor: those who have most of money and information will take nearly all monetary risks and, in attempt to refund them will strike a “solid company structure” upon the rest, who will bear the clocktime risk.

Banned on FeedBurner?

December 8, 2007 – 15:57

I read a good deal of feedburned feeds through my custom newsreader (http://www.chytach.com). Last night I’ve noticed that feedburner keeps dropping my attempts to update the feed:

Failed getting http://internet.seekingalpha.com/feed/ with URLError: (104, 'Connection reset by peer')
Failed getting http://feeds.feedburner.com/TechCrunch with URLError: (104, 'Connection reset by peer')
Failed getting http://feeds.feedburner.com/Mashable with URLError: (104, 'Connection reset by peer')
Failed getting http://feeds.feedburner.com/readwriteweb with URLError: (104, 'Connection reset by peer')
Failed getting http://feeds.feedburner.com/rashkovskiicom with URLError: (104, 'Connection reset by peer')
Failed getting http://radar.oreilly.com/feed with URLError: (104, 'Connection reset by peer')
Failed getting http://feeds.feedburner.com/programmableweb with URLError: (104, 'Connection reset by peer')

I’ve tried to access these feeds from different machine, and they work ok.

What’s going on? I’m banned on feedburner??? I can’t anymore read any feed that decided to use feedburner service?

What’s common between snow and code?

December 7, 2007 – 16:26

See the writeup by Tim Ottinger: Shoveling code

I was ill when the first snow fell last weekend, and didn’t get out and scrape the drive and sidewalks. Sadly, neither did I bundle up my kids and send them out with shovels. As a result, the snow melted and refroze. When I left home on sunday morning, clearing the snow was frustrated by the presence of hard, packed ice under the snow.

django’s urlconf for webware

December 3, 2007 – 21:51

It appears to be quite easy (from technical side) to do a coup refactoring an application from webware to django.

As a first step could be substituting default webware url mapper from url-maps-to-file-hierarchy to django-like regexp matcher.

url map would look like familiar django file:

from django.conf.urls.defaults import patterns
from Pages import Main

urlpatterns = patterns(
    '',
    (r'^$', Main.Main),
)

where Pages.Main is a webware servlet (e.g. a Cheetah compiled page).

To make it work, add a custom urlParser for a module. For the example above, it could well be in Pages/__ init __.py. That parser would use django urlconf module to parse an url in an incoming request:

class UrlConfParser:
    'django urlconf-like URLParser for WebWare'

    def parse(self, trans, requestPath):
        'parse request'
        from urls import urlpatterns

        for pattern in urlpatterns:
            res = pattern.resolve(requestPath)
            if res:
                return res[0]
        return

That’s it! Just make sure that you’re mapping urls to good old webware servlets – that’s what the caller expects.

link: Amazon's Dynamo – all-distributed failure-resistant storage

November 13, 2007 – 18:19

Dynamo: Amazon’s Highly Available Key-value Store

Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall and Werner Vogels

Amazon.com

Abstract

Reliability at massive scale is one of the biggest challenges we face at Amazon.com, one of the largest e-commerce operations in the world; even the slightest outage has significant financial consequences and impacts customer trust. The Amazon.com platform, which provides services for many web sites worldwide, is implemented on top of an infrastructure of tens of thousands of servers and network components located in many datacenters around the world. At this scale, small and large components fail continuously and the way persistent state is managed in the face of these failures drives the reliability and scalability of the software systems. This paper presents the design and implementation of Dynamo, a highly available key-value storage system that some of Amazon’s core services use to provide an “always-on” experience.  To achieve this level of availability, Dynamo sacrifices consistency under certain failure scenarios. It makes extensive use of object versioning and application-assisted conflict resolution in a manner that provides a novel interface for developers to use.

This is real journal-level paper.   Very inspirational.

link: Deliverables That Work: Design Description Document

November 6, 2007 – 18:35
Deliverables That Work: Design Description Documents

It’s first time I meet such well-written guideline to managing a design in a web project. Saved in del.icio.us.

10 reasons not to contract me

October 4, 2007 – 20:36

Several days ago I was told that my “5 reasons to contract” me are plain self-advertisement and even test ethical limits. Today, after (yet another) talk full of misunderstandings, I’ve decided to defend the opposite thesis.

Here you have 10 reasons not to contract me or to partner with me:

  1. I don’t understand your personal defaults. If you expect something from me, I expect to hear this explicitly and be stated in written.
  2. I’m quite opinionated – my experience cost me my blood, heart and money. So I expect you’re going to do business with me for my experience, not for my obedience.
  3. Don’t tell me what I have to do. Tell instead what you want to achieve. If we’re partnered, also mention how it fits our common goal and why I should be interested in doing that now. If you contract me, this also would be useful, but since you’re paying your money, you get what you pay for.
  4. If I see you doing or asking for a wrong thing I warn and start asking questions. If you contract me and insist on doing things I consider wrong, you get what you’re paying for. If it breaks, you keep two pieces and get my paid assistance to fix it. If we partner, I simply won’t do wrong things no matter how you ask or insist.
  5. I don’t give estimations. Usually. If I trust you (see below), I may mention some numbers. Don’t hold your breath, software estimation is black magic, and more personal development process gets, more black color should be expected. Usual best expected date is “when it will be ready”. And if I’m interested (I don’t take dull projects) and it’s possible and it’s not a moving target, this will be quite soon.
  6. I put lot of emphasis on personal relationships. I usually start with trust. In this “mode” I’ll happily give you my personal crude estimations and expectations of what and how something would be done. But as soon as I’ll feel you misuse this information, e.g. start treating it as commitments, you lose my trust and this information becomes closed.
  7. You’re still reading? Huh!? :) Then deadlines. I perfectly understand that “real world has deadlines”. Unfortunately, quite frequently deadlines are arbitrary (from software development point of view) and unreasonable. Just explain your deadline goals and let’s discuss how they could be achieved. If any of factors in the equation changes (scope, deadlines, budget, quality requirements), let’s discuss stuff again, since we now have completely new goals. Regarding deadlines, the proposed solution is simple: put your money where your mouth is. That’s put fines into the contract for missing specific dates, be ready that I’ll decide to pay that fines instead of meeting the date and let’s work together to deliver month earlier.
  8. I prefer to model software product development as a financial investment:
    • we have some capital initially (ideas, people, money, market, users)
    • we work on increasing the value we’ve got by providing things users need
    • we buy options to decrease our risk: make tests, get product to (selected) users early, iterate frequently, fail sometimes and learn from product failures
    Since software development if much riskier than any financial market investment, not buying options is foolish. So, if you decide not to do that – this falls under “bad things” (4) above: be prepared to kiss your money and time goodbye.
  9. Just few days ago we’ve got our first baby and thus won’t:
    • relocate,
    • travel,
    • talk to you for hours (which anyway is a bad idea) or,
    • work hours you consider reasonable.
  10. I live and work in Ukraine that you know nothing about. Why bother?
Afraid? Something bothers you? Drop me a comment and let’s talk. Or just look for a different developer.

Yet reading. Time to know what you get in exchange:

  • 15 years of software development for money (and at least several more years out of legal age)
  • scientific, commercial, offshore and startup experience
  • from system programming through GUI to web development
  • from bottoms of unit-testing with 100% coverage to integration testing of whole system image
  • strong virtualization experience
  • from Fortran to C++ to Python, from plain text files through berkeley db to complex installations of mysql and postgresql
And know what? I now got the contract. You might consider this bonus 11th reason, unless you’re not considering your project interesting.

how to use mysql replication in django

October 1, 2007 – 22:19

I’ll start with warning.  Now it’s just a pure thoughts, none of code is tested or ever written and is just a dump of an idea came up at Python Exception.

For those who do not know the issue.  MySQL replication syncs databases one way, from master(s) to slaves.  This allows to keep a lot of read-only slaves and send updates only to the master.  Of course, this gives any benefit only if you have lots of SELECT’s and just handful INSERT’s/UPDATE’s.  Obviously, this requires having two distinct db connections and a handle to switch ORM between slave and master connections.

There are two possible solutions for this:

  • statement-level routing, where connection object decides where to route the actual request and
  • view-level routing, where decision is done on django view level
First I thought about statement-level routing, but Ivan Sagalaev quickly explained that it will fail as soon as you do any transaction.  Imagine that
  1. master and slaves are slightly unsynchronised
  2. transaction starts
  3. initial selects are done on slave
  4. code makes some decisions based on out-of-sync slave data and changes data on master
Ouch.

Thus, the proper decision would be a view-level routing.

It should do three things:

  1. On django startup, create two db connections: one to the master and one to the slave.
  2. Decide which connection the ORM should use as default (say, slave).
  3. The view, that requires non-default access (e.g. master), should be wrapped with the decorator that changes ORM connection to the different one before view code gets executed and restores the value after.
This won’t work for middleware and other non-view stuff.  On the other hand, they are pretty self-contained and usually know well which connection they should use.

Implementation anyone?  My pet project had not yet reached the size, that justifies such setup.

5 reasons to contract me

September 20, 2007 – 14:33
  1. Deliver fast.
  2. Develop code with tests first and deliver only code 100% covered with tests.
  3. Work in small iterations (biweekly, weekly or even less)
  4. Scaleable – you may test with one-week part-time contract and scale as your needs grow up to team of several developers
  5. 15 years of total development experience, and 10 of them – in web applications.

And bonus - Focus on bringing Value to your users.

[contact-form 1 "Project request form"]