HOX II! Joo nyt taas paistaa. Väliäkö hällä. Pian se nähdään. Ehkä jo sunnuntaina saavat ennusteenkin kohdalleen.

HOX IIIIIHH! Vettä! Märkää! Iiiih! Ulkoiloittelu vaarassa! Tai pikemminkin mäellä!! Niin siis arvon asiakkaat, pohdimme suurissa mielissämme että jos keli ei vakaannu aurinkoiselle puolelle niin siirtäkäämme lejriä lähemmäs katettua tilaa eli tuohon tähtitörnin mäelle. Voidaan jekuttaa keliä ottamalla välillä satunnaisia spurtteja kohti mun kämppää.

Jos keli kuitenkin paranee niin voidaan hypätä lauttaan.

HOXIS! Fiudat tääl mitää ala sataan. Mut eisemidist, otetaa ny silti toi tähtis ettei kelit muutu.

Kaikki saa liittyä seuraan lauantaina 27.6. suokkiin tähtitorninmäelle jos aurinko-povaukset pitää jotensaki kutinsa.

Hieman jos viettelisi suurieleetöntä synttäriä siinä ohessa.

Hissimusat hostin puolesta ja jos ei sillä päihdy+kylläzy niin kandee pakkaa eväxiä mukaan. Ja äänet tosiaan pihistetään näistä mun työpöytäpurkeista, ei mitää isostelua siinäkään.

Lahjoituksia ei oteta vastaan. (En kannata ostos kexuxia.) Panostakaa omaan viihtyvyyteenne.

Leiripaikka tarkentuu jossain vaiheessa, mahdollisesti jo ennen sunnuntaiaamua. Järjestyksenvalvojia karkaillessa voi myös vaihtua pitkin iltaa.

Eli neljäks tai jälkeen inee, viimeistään kahden lautalla lentää pihalle.

Kesiä ainakin! (tai, muodossa yksikön kolmannen persoonan indikatiivin preesens, kesii!)

Back to business –>

Welcome to the developer documentation for protocol buffers – a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more.

Hah, Google did it again! Excellent. God damn, I’ve really waited for something like this.

Protobuf is of course missing tons of features compared to XML (schema), but I’m quite sure there’s nothing fundamental that can’t be built on top of protobuf. And this is the way to go: very small core that’s a good ground to build on.

Missing:

• namespaces (implement with field numbers)
• validating data types (use higher abstractions; message types)
• types, types of types (simple/complex), elements, attributes, groups… all the cruft (just types and extensions; rok)

(Protobuf doesn’t compare to JSON; former is strongly (statically) typed. JSON is good for small-scale browser stuff.)

Oh, I just luuuuuv it! (== positive initial impression)

Because it will use open protocols, the goal is to let users carry their identites anywhere on the web. Updates made to those identities out on the web will make their way back to Genome instead of users having to return to Genome to edit their profiles.

This means the implementation of volatile Social Graph. Go, ruskies!

And this was very nice to hear as well:

Genome will provide an open instant messenger that’s integrated with your contacts.

(I’m sure that implies XMPP.)

And right after Hackers & Painters I started reading this short story collection Hackers. Oh boy, what a nice combination. I can definitely recommend if you’re really serious about software. (People without experience on functional languages don’t need to bother; trust me, I’ve been there. It’s a whole other realm on the other side.¹)

And why was this so spectacular? While reading Painters, I came to realize that the more fundamental aspect of hacking may actually be the current (or becoming) leading edge in natural sciences. For example, there has already been heated discussion if information can escape black holes; scientists are starting to use information to represent physical phenomena. (Just mentioning here so that you can believe the facts instead of me. By the way, as a tip for youngsters, I’d be a little hesitant on choosing physics over compsci just because one has so much experience on computers already.) Furthermore, the more philosophical aspects of information theory may be the “leading” topic in metaphysics as well.

What I’m trying to say is that hacking is not just about programming computers, but it’s actually about the (current) most fundamental aspects of reality. Becoming the most “serious” of the “serious” sciences. (Compsci has traditionally been considered an order of magnitude less serious than math or physics, and universities adopting Java hasn’t really helped in this regard… ;)

This quote by Dijkstra is one of my all time favorites:

Computer science is no more about computers than astronomy is about telescopes.

But we are still in the early days of comprehending and applying information. Do we have any good reason for not considering information (currently just merely 1 and 0) as the current water-fire-earth?

Just for the sake of context, lets remind here that in “ancient greece” the basic elements of nature were water, fire, and earth. At some point along came gravity and ether. In last century the hot topics were related to structure of matter and Theory of everything.

It would be interesting to know what are the “atoms” of information, but I’m not holding my breath here — getting from water et co. to atoms took quite a while, if measured in human lifetimes. (And we still don’t know shit about gravity.) Qubits may shed some light to this in the near future.

In any case, I’m pretty sure it’ll be interesting to try to master information. A purposeful goal for a lifetime or even few, I suppose.

All classes fear this relentless abstraction of the world, on which their fortunes yet depend. All classes but one: the hacker class. We are the hackers of abstraction. We produce new concepts, new perceptions, new sensations, hacked out of raw data.

— in A Hacker Manifesto, second paragraph

I’ve always been intrigued by sharp edges — it’s merely fascinating to get little cuts to your fingers every now and then. And what’s a more fundamental cutting edge than one that’s shared in philosophy as well.

ps. I just found out that in emacs you can duplicate line with shift-up/down. Neat. (And, in addition to the readily provided shift-left/right character transpose, I’ve had line and word transposes for a while as well. Recommend.)

pps. I’m quite confident that there’s a quite straightforward religious aspect in this philosophy as well… haha, the languages, naturally! Where Lisp is the One True God and pg is the head preacher. ;) (But, seriously. Programming languages are the tools for molding information. (And Lisp is the most abstract.))

1) Imperative programming is about abstracting computers, functional about abstracting information. The longer you deny it, the more you’ll regret.

[Malcolm] Gladwell drew on social science research that documents the importance of practical skills (“tacit knowledge”) over raw brainpower; the tendency of individuals who think they’re smareter than others (and get treated that way) to worry more about acting smart than learning new things; and the dangers of what three psychologists have called “the dark side of charisma.”

[…]

Groups don’t write great novels, and a committee didn’t come up with the theory of relativity. But companies work by different rules. They don’t just create; they execute and compete and coordinate the efforts of many different people, and the organizations that are most succesful at that task are the ones where the system is the star.

(pp. 198-199)

In the last couple of years, I think I’ve been starting to learn that accomplishing things is less about individuals and more about coherent, healthy, and diligent groups of people. This implicates also that projects need to change along the people and a successful system must support such a living structure. In today’s world—or at least with Internet-related projects—you can’t afford spending a year to collect a team, and then go away for a few years to establish a single company.

Current, tens of years old form of a company doesn’t support this kind of an approach; shares and wages should be deprecated as forms of ownership and compensation. For building successful businesses we need to create more dynamic models; and an open attitude, as always.

And, of course,

[…] a system without stars is not going to win.

— John Sullivan on p. 200

although those stars may be revealed (or made) not until by that exact system.

GAE is definitely packed with a lot of sweet features. Like having Python as the first language, and Django being the ‘featured’ web framework there. Ruby might have been pretty much as good as a language, but Python’s more comprehensive platform suite stuff is very handy to have; and I got a feeling that the Ruby community has a minor emphasis on creating “flashy web sites” over creating a bit more novel services.

Also, I was very happy to see relations and transactions in the DB interface. SimpleDB is just too simple.

But, now, I also think that (to be frank) the AppEngine is a little retarded already: the only communication pattern available is request-response. Nothing like event-based mechanisms can be implemented using the current interfaces.

There are currently at least two factors that limit the design of more responsive apps:

1. connection timeout limit is ‘a few seconds’ → no persistent connections (think Comet)
2. no threads or background processing

Drivers for this are clear: current API structure grants that there are absolutely no limits to distribution and scalability of the applications. (You can’t build such even you wanted! Interesting, eh?) Programmer doesn’t need to care about load balancing, state handling, platform architecture, etc. He can just feel happy that them codes are proposedly running on BigTable etc. And the abstraction really does feel successful. At least for simple apps.

But now, if you remember that

• services are switching to two-way communications to suppress polling load and cut down lag,
• amount of time-sensitive information is increasing, and
• patience of a user is decreasing (might be plural, but to be on the safe side),

you don’t need to be Nostradamus to see the severity of the request-response cycle.

Basically, I’m disappointed not seeing interfaces to Google’s messaging platform anywhere. But, push assumes quite a different application architecture so I guess there wasn’t enough business reasons — and perhaps not enough concrete experience — to design/publish that kind of a platform. Dion might know a little more about Google’s standing..

But, the thing shall be called PollEngine for now.

And yeah, I’ve been a little too occupied with work now recently, severely lagging in following the industry. At least I got my ACM Queue order in place, which I think as one of the best tech magazines. Although I need to still get a couple more issues to be really sure about it..

Tags: architecture, platform, web, XMPP

(The snow effect is available only until Jan 2^nd, unfortunately. So, we must enjoy it as much as possible while it lasts!)

For instance, if you land on a Business Week article about IBM, the site will then look at your LinkedIn profile (assuming you’ve given it permission to do so) and highlight the people you know at IBM.

in The New LinkedIn Platform Shows Facebook How It’s Done.

That goes very much to the direction I super-briefly outlined before, even though these ‘features’ are only scratching the surface of the whole (dynamic! real-time?) SNS system.

And LinkedIn was thought to be dead already… Will 2008 bring pervasive social networks? And how will it mash with micro-stuff? The micro-ness is absolutely one of my favourite predictions. Exciting times ahead, hopefully also business/technology-wise (as in speaking of our little startup..)

In fact, it’s no longer even in your best interest to store data about people long term because, in fact, the data ages so rapidly that it’s next to useless to try to keep up with it. Instead, it’s about looking across the data that someone makes transactionally available to you (for a split second) and offering up the best service given what you’ve observed when similar fingerprint-profiles have come to your system in the past.

Now back to my contribution…

Now that everyone’s frenzying over the gruffalo, I guess it’s as good a time as any (at least) to expand my graph post [also] a little. The post isn’t anything notable but it gives some context, if interested.

For the topic’s current initiation, see TBL on Giant Global Graph:

[Internet] made it simpler because of [instead?] having to navigate phone lines from one computer to the next, you could write programs as though the net were just one big cloud, where messages went in at your computer and came out at the destination one. The realization was, “It isn’t the cables, it is the computers which are interesting’.
[...]
The WWW increases the power we have as users again. The realization was “It isn’t the computers, but the documents which are interesting”.
[...]
Now, people are making another mental move. There is realization now, “It’s not the documents, it is the things they are about which are important”.

(See also a nice roundup on ZDNet, Who is afraid of the GGG?)

My views next.

Dynamic graphs

Put it simply, my approach to building a next-gen SNS would be to extends the current feed polling capabilities to the graph aspects as well (social networks etc). For example, I have Facebook ‘importing’ my Jaiku feed currently, so why FB couldn’t just as well import changes to my Jaiku contact list and apply them to the FB domain?

The underpinning aspect here is that the future services should not try to be exhaustive by themselves, but to present the whole graph from their point of view as well as possible — be that ‘entertainingly’ or whatever is their beef. More generally, services should fetch data all over the web, and decorate it in their own, valuable way. Services would be much more interesting if they combined all the data and not just tried to hold on to that very tiny fragment (eg., the FB account) of my overall graph so fiercely.

This implicates that services would need to adapt to whatever changes in the user’s social graph, and that happens to be exactly what I want at a very personal level — ofcourse, this is also professionally highly intriguing. In practice, it’d be even somewhat trivial; just import the damn changes as you read the feeds. The difference to feed polling here is that it’s not new content per se that is fetched, but changes to existing data. So, services need to delete stuff (relationships etc.) as well. For implementation details, see for example “Dynamic Graph Algorithms” by Eppstein et al., 1999, which appeared among the first google hits (can’t remember for what; try out). (‘Someone’ should probably adopt those to rails so we could get the ball rolling…)

Of course, the most prohibiting problem currently are the walled gardens. (I expected the Open Social to do something about this, but Google failed me.) There are however at least a couple of sites that publish more data, but it’s very little still. And note that the data here comprises is the basic building blocks of the semantic web, but semantic web drafts completely ignore the fluctuating nature of data; which is why I think the semweb is born retarded.

Supergraph instead of a flat global graph

Then there was my notion about ‘supergraphs’ in the title; volatile was just to emphasize the true dynamism — if you don’t store external data, you don’t need to synchronize it. (Keep it simple.) With supergraph I mean that different kinds of graphs should not be bluntly blended but the metadata should be used accordingly. Social networks provide a fine example here, too.

This ‘supergraph’ thing should be very intuitive also: if I ever wanted my LinkedIn contacts to be mapped to Facebook, it’d be extremely nice if the LI contacts were presented in a different style than my Jaiku contacts. And, perhaps, there could be some different tools available for each kind of network — please, no vampire stuff (like, wtf…) for the business contacts, aight?

And, just to note, not all contact networks should be mapped to every service (of course), but that’s a whole another graph story and I’ll leave it for later.

So, this ‘volatile supergraph’ thingy should be rather easy to implement (no hard non-trivialities) if you was a systems designer (and not part of the 80%) and I’d be very excited to have it working. I bet a few googol other zimboes would be as well.

Expect next: dynamic, rich graphs. (Or probably not. But still,) Thanks for listening!

Dynamist artists used the concept as part of a way of representing the complexity of processes, rather than be limited by the discrete and static moments within change, which also illustrated the limits of human perception.

— found in Wikipedia

Tags: Internet, Social networks, Standards, Theory, Future

“It is unlike data compression, which has overhead associated with it,” explained Schneider, whose day job is as CTO of AgileDelta, which makes XML parsers. “XML is verbose and inefficient; [EXI] streamlines all of [the processing] with the minimal size representation of XML information possible,” said Schneider. “We want to make it competitive with hand-optimized binary formats.”

“When W3C tested EXI, it was, on average, 12 to 14 times faster than processing normal XML.”

I hope people will finally stop mixing up compression and efficient processing.

Me:

Quoting myself: ;)

And, as the binary format should be the most efficient way to represent that data, it really is the leanest ad-hoc binary format.

and

Only minor improvements should be able to be gained with further ad hoc binary formats, as the qualitative improvement in reducing the parsing complexity is already achieved. Thus, there should be no room for more efficient ad hoc format [...].

override def init(ctx: ComponentContext) {
  val descs = descriptions(new File(ctx.getInstallRoot))
  provides.foreach { svcName =>
    debug("Searching description for service %s", svcName)
    descs.map(t => (t._1.getService(svcName), t._2)).find(_ != null) match {
      case Some(t) => services = t :: services
      case None => warn("No description found for service '%s'", svcName)
    }
  }
  info("Found %d services: [%s]", int2Integer(services.size), services.map(_._1.getName).mkString(", "))
}

def descriptions(dir: File): Iterator[(Description, Document)] = {
  val cache = new HashMap[String, Option[(Description, Document)]]
  dir.listFiles(wsdlFilter).elements.map(f =>
    cache.getOrElseUpdate(
      f.getAbsolutePath,
      try {
        wsdlReader.synchronized {
          debug("Reading WSDL '%s'", f.getName)
          val doc = domParser.synchronized(domParser.parse(f))
          Some((wsdlReader.readWSDL(wsdlReader.createWSDLSource | { s => s.setSource(doc) ; s.setBaseURI(f.toURI) },
                new WodenHandler(f.getName)), doc))
        }
      } catch {
        case t: Throwable => error(format("Exception while reading '%s': %s",
                                   f.getName, t.getMessage), t)
                             None
      })
  ).filter(_.isDefined).map(_.get)
}

Works fine. :)

ps. definitely not the best show-case for abstraction, but I just wanted to play around with files a little.

pps. my editor is 100 cols wide, and the parts that don’t fit are irrelevant.

Plus, beer & listening to Antony and the Johnsons may have something to do with this. Life’s good at times.

(And hey, despite the slacking, I’m still 250% more productive compared to Java; although, that figure is probably something like 1k due to increased happiness. (Non-leaky) Abstractions rule.)

I am very happy
So please hit me
I am very very happy
So come on hurt me

I’ll grow back like a Starfish
I’ll grow back like a Starfish
I’ll grow back like a Starfish
I’ll grow back like a Starfish

— in “Cripple and the Starfish”

Example 8.1.2 Consider the following function definition:

def f(x: Int, y: Int) = x match {
case y => ...
}

Here, y is a variable pattern, which matches any value. If we wanted to turn the pattern into a stable identifier pattern, this can be achieved as follows:

def f(x: Int, y: Int) = x match {
case ‘y‘ => ...
}

Now, the pattern matches the y parameter of the enclosing function f. That is, the match succeeds only if the x argument and the y argument of f are equal.

And, a little earlier:

A variable pattern x is a simple identifier which starts with a lower case letter.

I was trying to match a type with a lowercase name and it took me a moment to figure out why it didn’t work.. :)

Btw., I don’t like this syntax-by-convention a bit, and it was a major surprise to bump into such here (with Scala, that is). I guess I need to question this at the forum.

Update (a better look): Ok, backquoting an id is an established syntax for denoting a stable identifier. Oh so novice for not knowing. But still, “identifier which starts with a lower case letter”.

Tags: Scala

The IM interface is the killerest, thanks guys. It feels like the way Jaiku should be used, 140 char input really doesn’t need a web page.

Update 10/09: And at the very last time: Jaiku got bought by Google, and they’re invite-only currently.

Congratulations, guys! That’s awesome!

(Fixed it already.)

ps. spammers would be unbelievably stupid not to use some very simple OCR to read addresses out of those pics…

I stumbled upon this discussion and couldn’t resist… My reply on I *wish* that existing social sites would import from CSV (was that Re: Six Apart is Opening the Social Graph) on Social Network Portability.

Related to the long-awaited opening of the graph. (*yawn*)

OAuth includes a Consumer Key and matching Consumer Secret that together authenticate the Consumer (as opposed to the User) to the Service Provider.

I.e., the service provider needs to know the consumer service in advance. Although the spec says

Consumer Secrets MAY be an empty string when no Consumer verification is needed.

the approach is clear.

So, what’s my issue? It’s simply that the Consumer Key kills spontaneous federation. For example, OAuth might get very handy with the opening of the social networks, but not all social networks can (and much less should!) be registered to each other; with these 93 services, it would require 8556 registrations. Furthermore, these registrations could slow the growth rate of new services as the users had to wait for the services to register with each other. And, while I wouldn’t like to sound too cynic, this allows services to completely deny federation with other, chosen services. (Read: ‘big services’ may easily cripple ‘small services’ by closing them off).

Please correct me, but it seems the OAuth board took a step backward from OpenID. I’m a huge fan of OpenID, and I’d like to see also the OAuth taking the bright path.

Even Google’s own protocol has a more friendly approach in this regard (see also x-google-token):

Decide whether or not to register your web application. Registered web applications have the advantage of being trusted by Google; the standard caveat displayed to users on the Google login page is omitted.

Vs. “you MAY not need to register your application.” (Emphasis not mine, although the quote somewhat adapted..) But, at least the Google doesn’t punch you to the nose for a welcome (and that’s really something.. :)

This was also interesting (from OAuth; my bolds):

Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider.

Well, is it secret or not.. So, you still need to do IP-based authorization? This also undermines the “allows the Service Provider to vary access levels”.

I hope that I’m wrong and someone corrects me. I really would like to have an open federation mechanism.

Tags: OAuth, Mashups, Standards

The reminder was in 10 More Future Web Trends, the prediction about “Integration into everyday devices”. I had played with a thought of applying XMPP to that domain: all those embedded terminals would contain simple XMPP clients and they would publish themselves as my latest communications resource as soon as I’d entered their presence. Thus, all my communications would follow me effortlessly. The terminals could—for example—use known bluetooth device addresses (ie., phones) to authenticate people, I guess it’s signal would be enough short-range for routing communcations somewhat correctly. Though, if I’d have the phone with me all the time what would be the point… But it’d be oh so neat. :)

Also, link-local would offer more lightweight m2m-comms compared to upnp.

Ah, and of course the Nabaztag should support natively use XMPP. That’s so trivial.

Tags: XMPP, Internet, Future

More precisely, it’s schema+encoding that define a concrete protocol, but if we’re assuming the verbose encoding (‘normal’ XML, for debugging), it’s the schema alone that suffices for defining the protocol. And, naturally, each version of an XML schema defines a different protocol. Due to the flexible processing of XML, apps are quite often able to handle several protocols. (Which albeit are/shouldbe/mustbe quite similar.)

And as encodings are completely isolated from the schema, those are transparent for the application.

Btw., this is no way an academic discussion, this is pure practice. I’m into implementation currently, all major research is on the hold currently.

(A concrete protocol is defined by schema and encoding. I.e., each version of an XML schema is a new protocol. Understanding this is a prerequisite for reading any further.)

Stefan Tilkov notes about some basic differences between AMQP and XMPP, and especially this one caught my eye:

One of my motivations, though, was that XMPP is based on XML, while AMQP (AFAIK) is binary. This suggests to me that AMQP will probably outperform XMPP for any given scenario — at the cost of interoperability (e.g. with regard to i18n).

Which of course is very correct for sure. XML is a bad choice for a transport protocol for a number of reasons. XML is complex to parse, and too ambiguous. These are not that critical when dealing with documents, but with live communications, all complications tend to escalate sharply.

And that’s exactly why I really would like to see some experimentation with binary encodings—at least for protocols, if not for other uses of XML. It’s only just over a year since I last argued this point. Unfortunately enough, other stuff has taken precedence over my tinkering with encodings.

Quoting myself: ;)

And, as the binary format should be the most efficient way to represent that data, it really isthe leanest ad-hoc binary format.

Ie., when done right (and why wouldn’t it be), EXI/whatever should be very competitive against any proprietary protocol—XML itself shouldn’t set much restrictions on the efficiency of information encoding. Merely vice versa, as when both sides know the respective ‘schema’ (protocol spec, like AMQP), the amount of space used for describing structure in the actual transferred content should be minimal. So, there shouldn’t be any reason at all to handcraft more transfer formats; room for further optimizations should be quite limited.

I must emphasize the following point as it’s constantly ‘misperceived’: binary encoding is not to compress, but for making parsing more simple and robust. (Well, that’s the most important feature for me, at least.) Naturally, binary encoding helps save some space as you don’t need to verbose the tags all the time, but it certainly doesn’t compress the actual content. Of course, the compression is a good selling point (to the masses), but no sentient being should constrain itself by focusing only on that petty (uninteresting, trivial) property.

Elaborating just a little bit more, the point with binary encoding is exactly the fact that it is just an encoding. That’s completely independent aspect/abstraction from the data model. So, XML has always its extensibility, was it encoded with excess number of tags or some simple, singular octets (or so, ykwim.) I don’t know how extensible the AMQP is, but I’m pretty sure it isn’t extensible in an ‘industry standard way’.

Summary:

• XML standard encoding: sucks (in protocols, ok in blogging)
• XML data model: rocks

This kind of a rant this time. Take care. :)

Tags: XMPP, XML

In the latest episode of GigaOM Show, Ryan Block of Engadget presented some interesting speculation about the rumored Google Phone. Ryan suggested that the Gphone would be a mobile terminal for Google’s data in the cloud—a rather obvious proposition, for sure. Although, I’d rather consider it as a client to services in the cloud, instead of mere data.

But hey, just watch the show.

[Google is] building a mobile operating system, and they want to make it flexible, extensible, expandable, and open.

(Based on a software platform by Android, which was bought by Google.)

Gphone’s placement was suggested to be against the more generic platforms like Nokia’s S60 and Windows Mobile, whereas iPhone has its own, more specific segment.

I’m expecting the Gphone to be an extremely interesting platform—if it ever materializes—but what I seriously would like to see (finally!) is a PC-kind of hardware standard for mobile devices. So that like with PC’s, individual hardware components would be upgradeable (memory, processor) and you could perhaps even add one or two additional components, like an RFID reader, a crypto/security chip, or even a 3D-graphics accelerator for fancier mobile game graphics; think mobile World of Warcraft client.

Btw., the GigaOM Show is one of my favorites, I recommend. Om is the man. :)

Tags: Mobile, Eq, Google

It almosts seems like Nokia had grown up and might be ready to put themselves ‘in the line of wire’. Of course, getting into content business is a fine business opportunity for them, but still, a street-credible service just might indicate that there’s some genuinely fresh thinking going on in there. (I mean, there’s tons of stuff being explored internally, but they don’t dare publish anything.) Also, the name selection, as it implies that they’re comfortable with their roots, tells something about maturity.

I hope I’m not overreacting. We’ll see how this starts to fold out.

Congrats to Nokia. Nice intro. Be brave! Or—C’mon, speak! Risk it!

I like Jonathan Schwartz a lot, but I think that unless some drastic changes are made to Java, the move to JAVA as Sun’s ticker symbol is going to be as relevant as changing it to COBOL.

Couldn’t agree more. Scala ftw. (for my tasks; feel free to use Ruby/whatever for web UI, etc…) An excellent post, btw.

“First heard” from Om Malik, at the GigaOM Show ep 3:

When you come to think of it, at the end of the day the only [...] social network that really matters, is the [...] people in our cell phone.

Like, hell yeah. Well, probably even I had heard this concept before, but now was the time for it to finally crystallize in full extent and clarity—and, ah, it’s so dead simple. Once again, so funny how the most obvious things are so hard to spot. It’s amazing how this realization took this long.

Ayo, technology! The only technical issue with the concept is to get your phonebook to the web—for which at least just about all Nokia phones already contain an adequate over-the-air synchronization solution. It’s actually scary how trivial this’d be.

Also, Jaiku is definitely in the prime spot for this; they already pwn your contact list so it’d be trivial for them to bring it to the web (although their technology may currently be limited to Nokia phones.) Albeit, for me Jaiku is still merely a microblogging platform and less of a Facebook, but it’s probably just me once again. (Or, perhaps do some minor brand tweaking in the future?) They must have thought about this a lot as Jyri is a social systems heavyweight.

And if Jaiku’s not willing to head this direction, I’m sure it’d be fun and interesting to build such a system—just ask if you need some technology or extra hands. :)

Btw., also the note about “IM chat list” by Joyce was delightful. Although, I’m sure these lists will soon converge into a single contact book. (Like, d’uh.)

Tags: Social, Mobile, Web, Future

Rosenberg’s Law: Software is easy to make, except when you want it to do something new. And then, of course, there is a corollary: The only software that’s worth making is software that does something new.

— Rosenberg, p. 268

I just finished reading “Dreaming in Code” with some mixed feelings. It was really good as a story book, but entertainment was pretty much all it had to offer. I had hoped a little more; new stimuli for improving project management, not just to confirm the average case. The book described a lot of “don’t do this”-stuff, but the “do this instead” was missing.

The bulk of the content was a well-written story about the early history of OSAF, and it’s project Chandler. While it was some easy reading, the project was yet another incident of unclear plans and execution. So it wasn’t that helpful, just (somewhat) entertaining.

The last third of the book was more interesting as there was listed some of the most accurate and interesting observations from the history of computer science and practice. Still, even if the quotes were very interesting reading, it didn’t educate much. Programming methodologies and technologies have advanced a lot in half a century, but, although some later developments are also described in the book, the main focus in the book was just in verifying the unfortunate state of an average software project with less-than-optimal practises.¹

However, it was a very fine story book! A must read for managers and relatives, not so for programmers themselves.

Joel Spolsky was quoted several times, and I must include this quote here as it describes one of the most important aspects of my aspiration for being an entrepreneur in software product business:

Craftsmanship is, of course, incredibly expensive. The only way you can afford it is when you are developing software for a mass audience. Sorry, but internal HR applications developed at insurance companies are never going to reach this level of craftsmanship because there simply aren’t enough users to spread the extra cost out. For a shrinkwrapped software company, though, this level of craftsmanship is precisely what delights users and provides longstanding competitive advantage, so I’ll take the time and do it right.

— in ‘Craftsmanship’

(Delivery as shrink-wrapped is essentially the same as delivery as a service.)

Tags: Books, Programming management, History, Culture

PS. a three-page excerpt of the book available here.

¹) Perhaps the main message of the book was that software projects are hard to manage; thus the title.

So, as a quick fix, I reverted back to RSS Bandit, which had a serious bug fixed a while ago so it’s usable now. But it’s much heavier compared to FeedDemon, and it and Eclipse don’t really fit into my machine concurrently (1,8g/1 mobile pentium, 1,5gig mem.) So, now it was performance issues which made the reading slow.

So, I was looking for another solution and decided to give Google Reader a go. I knew to expect fabulous things from the Google engineers, but I was a little suspicious over the web interface. I really liked the native UIs: the multi-pane layout, high responsiveness and UI elements playing together well. The web interface of the Reader really does fall short on those areas, but the reading list is still functional enough—though, HTML is a language for presenting content, not UI. Reader however provides preview and title listing modes, which suffice well.

There are also a couple features where the server-side solution excels compared to a local client: performance—as in handling the feed item mass—and feed updating. Now I can use Eclipse and have a feed reader available simultaneously. ^_^ The feed updating issue was something I discovered during my short vacation of a week, during which I couldn’t let the Bandit update feeds. It would’ve cost a long penny to do over cellular networks… This resulted in missing items in some high-volume feeds (read programming.reddit.com). Fortunately, that’s bygones now.

Currently, I’m still in middle of the transition to Google Reader. It’s pretty tedious trying to maintain the read state of little over 800 feeds… Divide and conquer, one category at a time.

PS. I also tried NewsGator but it had some issues back then.

tags: web+services, google

The principles of lust // Are easy to understand
Do what you feel // Feel until the end
The principles of lust // Are burnt in your mind
Do what you want // Do it until you find // Love

— in “Principles of Lust” by Curly M.C. et al. (1990)