A job/task/gig can be:
- fast
- accurate
- cheap
Problem is, you can pick only two out of three.
Is that so difficult to understand?
Archive for January, 2005
I finally managed to import all of my blog history on this blog. Importing from blogs.cocoondev.org’s MT was a piece of cake and went just smooth. Importing from Linotype, OTOH, has been an entirely different matter, but I managed to automate most of it: a shell script plus an XSLT file did most of the job, producing an MT-compatible export, even though I had to fix some stuff by hand.
Unfortunately, after I imported the entries, I noticed that I should have done better with the stylesheet: b2evolution doesn’t quite like namespaces (so much for XHTML support, yuck). The change was trivial, but unfortunately now the system doesn’t let me re-import the updated posts since it assumes that they have been previously imported. The side effect is that unless I go through a painful retyping, stripping out all the namespace declarations by hand, my old Linotype posts will look a bit clunky. But well, content is there anyway, so I’m quite happy.
However, note to self: if I’ll ever manage to come out with my dream Cocoon-based weblog, import and export should be high on the priority list…
Expect lightweight blogging: holidays are now over, and everyone will wake up tomorrow with stuff to do. We are also on the final stage of an interesting CMS project, and that will absorb quite a bit of my time. There are a couple of projects in their bootstrap phase, and they will require my attention as well.
Also, I’m resuming travel: wednesday I’m demoing Cocoon Forms some 300km from here (hope weather will be nice and without fog, it’s going to be a longish drive). And yeah, then there is the usual business work, with offers to do, documentation to write, general backoffice stuff and, most prominently, a very interesting business proposition to follow. Finally, we committed ourselves to a new version of our site by end of this week. Interesting times ahead: let’s see if I can manage to keep up with blogging as well… 48-hour’s days anyone?
One thing I was missing from Linux was the ability of having different color/font/dimensions from my countless terminal windows. I’m a heavy CLI user: I just seem to have a bad relationship with mice and file manager windows.
Quicksilver saved me from opening everything from a terminal, but still I always keep a frightening number of terminals open at any given time (the current total is 8, but this has been a quiet day). Unfortunately, given this huge mess, even Exposé is able to sort me out anymore: fonts are just too small to really understand which one is the window I’m looking for.
Today I just realized that I was spending way too much time fiddling with terminal windows. A quick Google search taught me that Terminal.app settings can be saved in .term files, and that opening a .term file actually fires a terminal with the correct settings. It took me some time to create the four different profiles I need (two different kinds of remote shells, a local shell and a tiny window to control running applications like Tomcat and Jetty), but finally I am back in control. Well, once again Apple rocks! Now, if only rumors are true and there is really a $500 apple box coming, I think I’ll start to seriously lobby my company to gradually switch our Linux workstations…
2004 has definitely been a business-oriented year. Not that I don’t enjoy talking to customer and advocate open source in general, quite the opposite actually, but I’ve been sorely missing some “hands on” stuff. So, given my huge amount of Copious Free Time (not!) these are my geek side Open Source objectives for Y2005:
- build a Lucene & Cocoon based blog engine/micro CMS, as much feature complete as possible;
- finish up and publish Sourcerer, our Cocoon based remote repository management tool;
- help the Jackrabbit & JSR170 effort;
- get back to some serious Cocoon stuff
- build a ESI compliant HTTP proxy cache, possibly with Simpleweb if nothing better comes out in the meantime
- check out Rails, which looks definitely cool;
- decide whether Daisy (which looks quite good but still has a few things I’m not really sold on) can really be my preferred CMS alternative. If so, join the party.
Phew, that’s a lot of stuff. I know I won’t have the time to accomplish even a fraction of that, but the list looks interesting anyway…
Inauguriamo la categoria dei post golfistici con una foto dei nuovi bimbi, arrivati da poco direttamente da oltreoceano:
Gli arnesi arrivano dritti dritti da Gigagolf, un produttore americano di cloni: dopo un po’ di indagini mi sono lasciato convincere da chi afferma che in un bastone da golf quello che conta davvero è lo shaft e che comprando roba di marca si pagano soprattutto spese di marketing. Soprattutto quello che mi ha convinto è notare come al mio livello di canite non c’è quella gran differenza tra un callaway di ultima generazione e un manico di scopa legato a un sasso.
La prova sul campo (Lainate e Tolcinasco) ha confermato le impressioni di cui sopra: i nuovi bimbi si comportano bene se non meglio dei vecchi TaylorMade RAC HT (una prece per loro e una maledizione stile Alex Drastico al ladro che me li ha rubati), nel senso che le palle vanno come al solito un po’ di qua, un po’ di la’ e, ogni tanto, dritte e lunghe. Di nuovo da segnalare c’è giusto che avere i legni 5 e 7 in sacca sta da un lato facendo una bella differenza sui secondi colpi, ma dall’altro mi sta disabituando all’uso dei ferri lunghi… che non è una bella cosa.
Devo ancora capire, invece, se il putt mi piace o no: al momento stiamo ancora litigando, anche se qualche soddisfazione non è mancata. Sicuramente però il mio vecchio Mizuno in grafite, leggero come una piuma, mi mancherà da impazzire (e non lo sto trovando in giro).
Ovviamente, peraltro, i bastoni sono arrivati nel giorno preciso in cui il mio campo pratica ha deciso di chiudere per delle ferie natalizie che a momenti arrivano a Pasqua: al di la’ di qualche sporadica uscita in campo mi toccherà aspettare il 17 di gennaio per fare un po’ di prove serie. Mannaggia.
Matthew is blogging (again) about SpikeSource and Open Source support. I definitely share his view (well, that’s certainly not the first time) and I’m quite puzzled about all this “Open Source stack” thing.
As I understand it, the idea is pretty simple: you gather a few OSS “products” that potentially fit together to fullfil an infrastructure as a whole (say an OS, a web server, an application server and some middleware) and you either package and redistribute it with a nice name, box and manuals (the RedHat way), or you “just” claim that you can provide overall support on the whole thing.
Now, the last one is a serious claim to make, expecially when middleware becomes part of the game. I can certainly foresee some traditional support around software that has “just” a configuration and a log file: send me your configuration, send me your logs and I will be probably able to sort you out. So, talking about LAMP, this can be more or less easily done for the L, the A and the M. There are some important issue with the P (supporting a programming language is much harder: go figure a middleware slution). But hey, this is plain old support, has been done for ages, I was doing that back in 1992, when I started working in IT. What does it have to do with a “stack”? Marketing buzzword, or am I missing something?
All in all I still believe that supporting a full-fledged solution (OSS based or not) is much different than supporting the single pieces. A solution is like a jigsaw puzzle: what is the point in supporting the single pieces when the real value is knowing how they can fit together?
To me (to us) “support” really means a process that starts with an assessment phase (what do you want to do? what are the proper tools for that?), goes through a mentoring/consulting process (here is the best way to do it, and here is a helping hand for you) and finally lands to a real support line (I know your setup, I know your people, I can really help now). There is still room, of course, for bulkish traditional support (hardware, infrastructure software and so on), but still I don’t quite see how companies like SpikeSource can provide real value to their customers given the current state of affairs in software-land. Unless they plan to move towards a network-based business… but this is something for a future post.
Now, I have some reservations about this process: in my experience not only (as Matthew points out) customers are interested in just a specific piece of the picture, but also it’s incredibly difficult to provide generic support. Middleware is nasty: without knowing how the different pieces have been glued together, what is the desired outcome and how are the different components cooperating, it’s just impossible to provide real second-level and above support. Unless you have trivial problems (tipically the ones that can be found with a “I feel lucky” Google search), it’s nearly impossible for a support person to nail the problem down and provide a solution.
So, how do you support Open Source middleware? Well, I can imagine two different ways: the first option is about providing what I’d call “stock” support. That is, on the other end of a phone line you have a smartish operator going through a knowledge base and trying to answer your questions. Basically it will be installation/upgrade issue, or generic questions that, once again, can probably be found on Google. The added value here is that the operator will answer you right away, is committed to solve your problem, can probably escalate the issue to more knowledgeable people and so on.
That’s a good start of course, and I can certainly see it happening for infrastructural software such as a web server. I wonder though how this process can solve a problem with your message-driven bean who all of a sudden doesn’t work anymore: at a very least you have to fly code back and forth, assuming that from small snippets taken out the real context the support team can figure out what’s going wrong. At a very least this requires that on the other side of the phone line there is a very knowledgeable person
Con questo post annuncio solennemente il mio ingresso nella blogopalla. Ero già un utente slandrone della “blogosphere”, con una media di post all’anno che ricordava quella di matematica del primo quadrimestre (nel secondo passavo al primo banco, facevo gli occhioni alla prof e in qualche modo la sfangavo), ma questo è il primo ingresso nel fantastico mondo dell’italico blog.
Brevi istruzioni per l’uso, a volte ve ne importasse qualcosa: qui si troveranno post in inglese e in italiano. Quelli in inglese riguarderanno la mia vita “professionale” (si parlerà di Open Source, di programmazione, di progetti e di lavoro in genere, con qualche sporadico saracco), mentre mi riserverò l’italiano per ragionare di minuzie e varie amenità. O forse no: non sono così bravo a rispettare le regole, facciamo che vediamo come gira e poi si tirano le somme. Comunque, per chi mi volesse fare l’onere di includermi in un aggregatore, se la mistura di inglese e italiano non crea particolari scompensi ci si può sottoscrivere a questa URL. Gli autarchici, invece, possono accomodarsi qui.
Proposito del nuovo anno: dopo avere tenuto un blog per quasi due anni con un numero ridicolo di post, nel 2005 mi riprometto di scrivere almeno un centinaio di note. Se non dovessi riuscirci, chiunque se ne dovesse ricordare in mia presenza avrà il caffé pagato.
I’ve been coding again lately. Boy, that feels good for a change, after a lot of time spent doing project management, offerings, backoffice and a LOT of travel. Sure, you earn free miles for vacation flights, but what’s the point when you don’t have any time off?
Anyway, back to coding: I’ve been using Cocoon again and I’m amazed at how far it went, how incredibly powerful CForms + continuations are, and how easy is to build a seemingly complex app with very few lines of code: I have sitting on my hard disk a full-fledged web file manager with inline XHTML editing, with full internationalization and skin support. with this little thingy you can manage almost everything: a local file system or a remote FTP/WebDAV server (we’re using it as a Subversion frontend). All this fits into less than 150K of overall code, and could definitely use more optimization. We’re using it as a poor man’s CMS and fits the job quite nicely. And yes, as soon as I manage to polish it a bit better, it will be Open Sourced. Hey, glad you asked! 
There is quite a bit of room for optimization in Cocoon though, especially with regard to ease of configuration and deployment. There are very promising work in progress (Sylvain and Carsten rock!) about better componentization and modular configuration, but this is really, and badly, needed. It’s incredibly and overly painful to come up with a nice setup to integrate, deploy and distribute an application inside Cocoon. At best, there is a royal PITA in managing patch files for configuration, copying resources and libraries all around the place and figuring out the best way to make an application really portable (where “portable” to me means that it can be mounted anywhere inside a Cocoon installation: Application “foo” should work as /, /foo, /bar/foo and so on).
Howerer, no pain no gain, and using Cocoon indeed pays off in the end: big time. And I hope to have some time this year to help in this area.
(now, if only the Slide folks had not badly broken their client library I would be a much happier man…)
