HOX! Keliarpojilla putos kolikko toiselle kyljelle, nyt on luvassa sadetta. Seurataan tilannetta ja pysytään rauhallisina. Suunnitelma Bollingeria pohditaan tarvittaessa.
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!)
Minor update: I’m a little concerned over the ‘service’ construct; is request-response still such a valid schema that it’s worth promoting to a native concept in the specification? I might rather try to suppress it in favor of asynchronous patterns.
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.
- 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.)
Bwah, I was really spoiled by my readings while I was traveling from Helsinki to Rovaniemi by train last night. At first I finished reading Hackers & Painters by Paul Graham, which was simply the best non-technical book about programming I’ve ever read. (For some of the others, you can check my LibraryThing.) It also got me considering using Lisp in an embedded system project. (Other strong candidate is OCaml—I’m having this hybrid season now—but the selection is a whole other blog post…)
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.1)
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.
Read the rest of this entry »
While reading the quite excellent book “Mavericks at Work”—which discusses about the most innovative and imaginative companies in the US—I bumped into these notes that I think are quite relevant in this era of fast evolution (technological and others):
[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.
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.
Uh oh, AppEngine is the shit! I’m very excited! Might just be the News of the Year.. we’ll see about that. But, I always want more..
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:
- connection timeout limit is ‘a few seconds’ → no persistent connections (think Comet)
- 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..