Deactivating Facebook

For a while I have been very uneasy with Facebook’s privacy policies (as well as ownership policies for uploaded photos and the like), like a number of people I was very surprised by how much access to my data applications run by my friends had, data that I had marked as private and only available to friends. So a month ago I deactivated my account. In the event it turns out that I was not the only one, the recent privacy changes (which left Mollie Wood miffed) caused a number of others to leave too.

I did leave a message for Facebook when I deactivated my account, but I doubt Mark Zuckerburg will read it. Frankly I think he needs to, Facebook is built on users, they are fickle and will desert you when something better comes along.

I have not yet deleted my Facebook account, but I will if I don’t feel the need to use it in the next few months.

FoxTrot Search for Mac OS X

If you were looking for an alternative to Spotlight on Mac OS X, you might want to check out FoxTrot Search:

CTM FoxTrot Professional Search is a powerful new find-by-content product for legal, media or mobile professionals and their networks, which offers precision tools for finding the proverbial “needle in a haystack” within PDF, HTML, word processing, e-mail and rich-media metadata.

Wolfram Alpha iPhone/iPad App

I was happy to see (via Beyond Search) that Wolfram Alpha dropped the cost of their iPhone/iPad app, originally it was one cent short of $50, now it is a much more reasonable $1.99.

Voting Woes

Amazing that the porbeagle shark got protected status at all given this:

So the chair ordered the technicians to reset the system. Before a new vote on the porbeagle, a test was ordered. “Could everyone please vote ‘Yes’ now?” he said. After thirty seconds the chair said he had received votes from everyone in the room, and that the system was working. He then observed dryly that of the 137 nations that had been supposed to vote ‘Yes’, seven had voted ‘No’ and two had voted to abstain.

Memory Leaks in Java

I came across three good articles on memory leaks in Java and how to go about tracking them:

Memory leaks et alii

One of the most common problems in building enterprise web applications are leaks. A leak is consumption of a resource by a program where the program is unable to release the resource. Leaks come in various types, such as

  • Memory leaks
  • Thread and ThreadLocal leaks
  • ClassLoader leaks
  • System resource leaks
  • Connection leaks

A day in the life of a memory leak hunter

… but my overall happiness level suffered a noticeable drop when I got a mail in my Inbox from a coworker saying that the logs of a particular service in our dev cluster are littered with OutOfMemoryError-s.

Taxonomy of class loader problems encountered when using Jakarta Commons Logging

This document attempts to systematically categorize the types of problems encountered when using Jakarta Commons Logging, hereafter abbreviated as JCL.

Assessing the Cost-Benefit of Substituting Open Source Solutions

Recently I was having a conversation with a VP of Engineering about search, amongst other topics, and they mentioned in passing that they were getting some pressure to substitute a well known open source search engine for their own internally developed search engine. They were telling me that the case was not clear cut as they had invested a lot of resources into developing their own search engine to meet their needs and the needs of their customers.

Which got me thinking how you go about doing a cost-benefit analysis to assess this and I reduced it to two sides of a balance sheet.

On one side you need to assess the cost of the component you are looking to replace, presumably this translates into a savings. This is not as simple as it looks and it may well not be as significant as it looks. There is always a large amount of support infrastructure around a basic search engine such as all the document preparation aspects, user accounts, integration into document management systems, etc… For companies who make their living taking databases from publishers and making them available on their search engine, this would probably be quite significant.

On the other side of the equation, you need to assess what needs to be changed in the open source solution you are planning to adopt to meet your needs. An open source solution would typically be quite generic, so there may well be specific features which are not catered for and which will need to be built. These features would need to be re-incorporated into future releases of the open source solution. You could also be constrained by the release cycle of the open source solution.

This is not an easy calculation.

Release Cycles and Platforms

Interesting article at Engadget about Android and its speedy release cycle (by way of Beyond Search).

The second part of this doubled-edged attack on platform fragmentation comes from a simple reality: we’re hearing that Google may be nearing the end of its breakneck development pace on Android’s core and shifting attention to apps and features. By the time we get to Froyo, the underlying platform — and the API that devs need to target — will be reaching legitimate maturity for the first time, which means we should have far fewer tasty treat-themed code names to worry about over the course of an average year. We like awesome new software as much as the next guy, but Google’s been moving so fast lately that they’ve created a near constant culture of obsolescence anxiety among the hardcore user base — and in turn, that leads to paralysis at the sales counter.

When then hardware is easily accessible (such as in your own datacenter) it is easy to do lots of small incremental released, pushing a new release out should be as simple as running a script (backing down should be just as simple.) When your software gets out on third party devices, this kind of release cycle will lead to fragmentation because users don’t upgrade, or can’t upgrade. This makes life more complex for third party developers who now need to figure out which releases they can run on. Ultimately you need to slow down your release cycle and create a predictable ecosystem for the developers to work in. Apple for example is only a yearly release cycle with the iPhone platform (in sync with new hardware), and a two yearly release cycle with Mac OS X. This makes life easier for developers and users too.