List of Shared Articles

Salaries in an Open Culture Organization

From: Managed Chaos

I think that if you have an organization of empowered self-organized smart employees then, you should consider having:

The standard response I get to this proposal in companies from the management is that

“Employees are not matured enough to handle this in the right spirit”.

My response is

“You can’t learn how to swim by standing outside water and watching others swim, you have to jump in and try”.

TopHomepage


MF Bliki: FluentInterface

From: www.martinfowler.com

FluentInterfacedsl20 December 2005Reactions

A few months ago I attended a workshop with Eric Evans, and he talked about a certain style of interface which we decided to name a fluent interface. It's not a common style, but one we think should be better known. Probably the best way to describe it is by example.

The simplest example is probably from Eric's timeAndMoney library. To make a time interval in the usual way we might see something like this:

TimePoint fiveOClock, sixOClock;...TimeInterval meetingTime = new TimeInterval(fiveOClock, sixOClock);

The timeAndMoney library user would do it this way:

   TimeInterval meetingTime = fiveOClock.until(sixOClock);

I'll continue with the common example of making out an order for a customer. The order has line-items, with quantities and products. A line item can be skippable, meaning I'd prefer to deliver without this line item rather than delay the whole order. I can give the whole order a rush status.

The most common way I see this kind of thing built up is like this:

    private void makeNormal(Customer customer) {        Order o1 = new Order();        customer.addOrder(o1);        OrderLine line1 = new OrderLine(6, Product.find("TAL"));        o1.addLine(line1);        OrderLine line2 = new OrderLine(5, Product.find("HPK"));        o1.addLine(line2);        OrderLine line3 = new OrderLine(3, Product.find("LGV"));        o1.addLine(line3);        line2.setSkippable(true);        o1.setRush(true);    }

In essence we create the various objects and wire them up together. If we can't set up everything in the constructor, then we need to make temporary variables to help us complete the wiring - this is particularly the case where you're adding items into collections.

Here's the same assembly done in a fluent style:

   private void makeFluent(Customer customer) {        customer.newOrder()                .with(6, "TAL")                .with(5, "HPK").skippable()                .with(3, "LGV")                .priorityRush();    }

Probably the most important thing to notice about this style isthat the intent is to do something along the lines of an internalDomainSpecificLanguage. Indeed this is why we chose theterm 'fluent' to describe it, in many ways the two terms are synonyms.The API is primarily designed to be readable and to flow. The price ofthis fluency is more effort, both in thinking and in the APIconstruction itself. The simple API of constructor, setter, andaddition methods is much easier to write. Coming up with a nice fluentAPI requires a good bit of thought.

Indeed one of the problems of this little example is that I justknocked it up in a Calgary coffee shop over breakfast. Good fluentAPIs take a while to build. If you want a much more thought outexample of a fluent API take a look at JMock. JMock, like any mockinglibrary, needs to create complex specifications of behavior. Therehave been many mocking libraries built over the last few years,JMock's contains a very nice fluent API which flows verynicely. Here's an example expectation:

mock.expects(once()).method("m").with( or(stringContains("hello"),                                          stringContains("howdy")) );

I sawSteve Freeman and Nat Price give an excellent talk at JAOO2005 on theevolution of the JMock API, they since wrote it up in an OOPSLA paper.

So far we've mostly seen fluent APIs to create configurations of objects, often involving value objects. I'm not sure if this is a defining characteristic, although I suspect there is something about them appearing in a declarative context. The key test of fluency, for us, is the Domain Specific Language quality. The more the use of the API has that language like flow, the more fluent it is.

Building a fluent API like this leads to some unusual API habits.One of the most obvious ones are setters that return a value. (In theorder example with adds an order line to the order and returns theorder.) The common convention in the curly brace world is thatmodifier methods are void, which I like because it follows theprinciple of CommandQuerySeparation. This convention doesget in the way of a fluent interface, so I'm inclined to suspend theconvention for this case.

You should choose your return type based on what you need tocontinue fluent action. JMock makes a big point of moving its typesdepending on what's likely to be needed next. One of the nice benefitsof this style is that method completion (intellisense) helps tell youwhat to type next - rather like a wizard in the IDE. In general I finddynamic languages work better for DSLs since they tend to have a lesscluttered syntax. Using method completion, however, is a plus forstatic languages.

One of the problems of methods in a fluent interface is that they don't make much sense on their own. Looking at a method browser of method by method documentation doesn't show much sense to with. Indeed sitting there on its own I'd argue that it's a badly named method that doesn't communicate its intent at all well. It's only in the context of the fluent action that it shows its strengths. One way around this may be to use builder objects that are only used in this context.

One thing that Eric mentioned was that so far he's used, andseen, fluent interfaces mostly around configurations of value objects.Value objects don't have domain-meaningful identity so you can makethem and throw them away easily. So the fluency rides on making newvalues out of old values. In that sense the order example isn't thattypical since it's an entity in the EvansClassification.

I haven't seen a lot of fluent interfaces out there yet, so I conclude that we don't know much about their strengths and weaknesses. So any exhortations to use them can only be preliminary -however I do think they are ripe for more experimentation.

There's a good follow up to this from Piers Cawley.

Update (23 June 2008). Since I wrote this post this term's been used rather widely, which gives me a nice feeling of tingly gratification. I've refined my ideas about fluent interfaces and internal DSLs in the book I've been working on. I've also noticed a common misconception - many people seem to equate fluent interfaces with Method Chaining. Certainly chaining is a common technique to use with fluent interfaces, but true fluency is much more than that.

TopHomepage


Million Ways to Kill your Project

From: Managed Chaos

Most often I find people introducing all forms of accidental complexity and screwing up their projects. Over the years I’ve learnt some powerful ways to kill a project/organization.

Mediocracy over Innovation and Excellence
Indifference (I don’t care) over Passion and Pride
Sloppiness over Craftsmanship and Self-Discipline

are some of the most common values. And there are many ways to encourage them:

TopHomepage


Another resume tip

From: Joel on Software

Are you a software developer applying to a small company?

Here’s a tip from someone who has read thousands of resumes. When you’re applying to a startup, or a software company with less than, say, 100 employees, you may want to highlight the Banging Out Code parts of your experience, while deemphasizing the Middle Management parts of your experience.

When a startup CTO sees a resume that says things like:

they think, “Spare me, that’s all we need, somebody running around trying to manage and optimize and architect when we just need someone who isn’t afraid to write code.” Here’s the stuff CTOs at startups want to see on a resume:

If you’ve been in a large company for too long, you may feel that you put in your time, with all those years working your way up the hierarchy from the $50,000 coder jobs to the $250,000 Senior Vice President in Charge of Long Meetings With Other Senior Vice Presidents, and you’re kind of enjoying the nice parking space and the personal assistant and stuff, and coding? not so much, so now you’ve found a cool startup or small company, and you’re thinking, maybe now’s the time to jump ship? So you send your resume with your ERP stuff and SAP stuff and Vice President stuff to the startup, and it gets tossed.

Those VP jobs just don’t exist at startups, and the few VPs they have are the founders and a key early hire or two. Not you. And startups certainly don’t need extra middle managers. To a startup founder, middle managers just seem like added expense without more code getting written, and the only thing we REALLY need is

Now, there’s a lot of resumes I see where, actually, I suspect that the candidate may have been (ahem) slightly overemphasizing the management/leadership/“architect” parts of the job, and slightly underemphasizing the banging out of code. And that’s fine if you’re looking to jump to a management position at a big company that, inexplicably, doesn’t have anyone to promote from within.

But for startups, everything about your resume has to scream getting your own hands dirty. Otherwise your resume makes you look like you’re looking for the kind of job where you can call meetings that take people away from coding all day long, which, to a startup, is about as useful as a one-legged man in a butt-kicking contest.

(More resume tips, and, if you’re really looking for a job, don’t forget the job board).

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

TopHomepage


Perform Case Sensitive Search with Google

From: Digital Inspiration - Technology Blog

google is case insensitive Google says that they treat search queries as case-insensitive and all letters in a search phrase are always interpreted in lower case. For example, searches for barack obama, Barack Obama and BARACK OBAMA will all return the same results on Google.

There are however instances when the case of a search query is as important as the search phrase itself because the word meaning can change with the case. Some examples of Capitonym words include March (month) & march (walk), Polish (language of Poland) & polish (to shine), Bill (person’s name) & bill (invoice), etc.

For instance, "Ram" is the name of a Hindu God while "RAM" is an abbreviation for Random Access Memory. They both share the same spelling and it’s the case that helps you understand the real context of the word. Unfortunately, Google searches are not case sensitive (or fold case) and hence most search results for Ram or RAM are about the "temporary" memory.

To solve this problem and help you conduct case sensitive searches on Google, someone has created a Google Appengine powered search engine at Case Sensitive Search - it scans through Google search results and filters out results that match the case of your search query.

Coming back to original example, here’s is a comparison of case sensitive Google search results for "Ram" vs. "RAM".

Google Search - Case Sensitive

Perform Case Sensitive Search with Google - Digital Inspiration

TopHomepage


Java 7 - small language changes

From: Stephen Colebourne's Weblog

Todays news that there are likely to be language changes in JDK 7 was a bit of a surprise. It seemed like the chance had passed.

Small language changed for JDK 7

Joe's post isn't very long, but it is clear.

I've used this blog, and previous visits to JavaPolis (now Devoxx) to discuss possible language changes. Some have been good ideas, others not so good. The main point was to provide a place for discussion.

The next phase after that was to implement some of the language changes. This has been achieved with the Kijaro project. As far as I'm concerned, anyone can write up an idea for a Java language change, and then I'll provide commit access at Kijaro for it to be implemented in javac - no questions asked.

Expectations

So, before we all submit lots of crazy ideas and get carried away, lets remember that Sun provided some hints at JavaOne 2008. This presentation includes the following as ruled out:

And the following as 'under consideration':

The following are listed as 'long term areas of interest':

So, there is already quite a wide list on the table. Plus, there were other ideas suggested at last years JavaPolis, by both Josh and Neal:

In addition to all the above, I strongly suspect that there isn't going to be a chance to tackle problems with generics. This is similar to closures and properties. There isn't the timesclae or manpower to tackle these big issues in the timeframe being talked about (especially now Neal Gafter works for Microsoft).

My ideas

Well, I'll mostly save those for another day. But I would like to see a proper consideration of enhancements to help with null handling. And enhancments to the for-each loop.

Saying NO!

Finally, an appeal to Sun. Many in the community are deeply sceptical of any language changes at this point. The message should be simple - people need to feel that there is a clear means to vote or argue AGAINST a proposal, just as much as to make suggestions FOR change. Although I don't expect to make much use of the facility, I know there are many that do want to express this opinion.

Summary

This is a new departure for Sun in so openly asking for ideas from the community. We need to respond and reply with thoughtful ideas for what will and will not work.

TopHomepage


Calvin and Hobbes for December 22, 2008

From: Calvin and Hobbes (Unofficial)

TopHomepage


Strategy: Facebook Tweaks to Handle 6 Time as Many Memcached Requests

From: High Scalability - Building bigger, faster, more reliable websites.

Our latest strategy is taken from a great post by Paul Saab of Facebook, detailing how with changes Facebook has made to memcached they have:


...been able to scale memcached to handle 200,000 UDP requests per second with an average latency of 173 microseconds. The total throughput achieved is 300,000 UDP requests/s, but the latency at that request rate is too high to be useful in our system. This is an amazing increase from 50,000 UDP requests/s using the stock version of Linux and memcached.

To scale Facebook has hundreds of thousands of TCP connections open to their memcached processes. First, this is still amazing. It's not so long ago you could have never done this. Optimizing connection use was always a priority because the OS simply couldn't handle large numbers of connections or large numbers of threads or large numbers of CPUs. To get to this point is a big accomplishment. Still, at that scale there are problems that are often solved.

Some of the problem Facebook faced and fixed:

  • Per connection consumption of resources. What works well at low number of inputs can totally kill a system as inputs grow. Memcached uses a per-connection buffer which adds up to a lot of memory that could be used to store data. Nothing wrong with this design choice, but Facebook made changes to use a per-thread shared connection buffer and reclaimed gigabytes of RAM on each server.
  • Kernel lock contention. Facebook discovered under load there was lock contention when transmitting through a single UDP socket from multiple threads. Sockets are data structures too and they are subject to the usual lock contention issues. Facebook got around this issue by maintaining separate reply sockets in different threads so they would not contend with the receive sockets. They found another bottleneck in Linux’s “netdevice” layer that sits in-between IP and device drivers. They changed the dequeue algorithm to batch dequeues so more work was done when they had the CPU.
  • Application lock contention. Nothing brings out lock issues like moving to more cores. Facebook found when they moved to 8 core machines a global lock protecting stats collection used 20-30% of CPU usage. In application that require little processing per request, as does memcached, this is not unexpected, but doing real work with your CPU is a better idea. So they collected stats on a per thread basis and then calculated a global view on demand.
  • Interrupt floods and starvation. With so much traffic directed at a single server the hardware can flood the CPU(s) with interrupts and keep the CPU from doing "real" work. To get around this problem Facebook implements some complicated strategies to load balance IO across all the cores. As I am less clever I might try more network cards with a TCP Offload engine.

    • When you read Paul's article keep in mind all the incredible number of man hours that went into profiling the system, not just their application, but the entire software hardware stack. Then add in the research, planning, and trying different solutions to see if anything changed for the better. It's a lot of work. Notice using a nifty new parallel language or moving to a cloud wouldn't have made a bit difference. It's complete mastery of their system that made the difference.

    A summary of potential strategies:

  • Profile everything. Problems are always specific. The understanding of the problem must be specific. The fix must be specific.
  • Burn profiling into your regression tests. Detect when and where performance tanks as a regular part of your build.
  • Use resources in proportion to what grows slowest. This requires multiplexing, but at least your resource usage is more predictable and bounded.
  • Batch work. When you have the CPU do all the work you possibly can in the quantum or the whole system grinds to a halt in processing overhead.
  • Do work and maintain resources per task. Otherwise locking for shared resources takes more and more time when there's less and less time to do the work that needs to be done.
  • Change algorithms. Sometimes you simply need to do things differently. Tweaking will only get you so far.

    • You can find their changes on github, the hub that says "git."

    TopHomepage


    Comic for December 15, 2008

    From: Dilbert Daily Strip

    TopHomepage


    Comic for December 13, 2008

    From: Dilbert Daily Strip

    TopHomepage