Diciamocelo, il panorama dei blog tecnici in Italia lasciava un po’ a desiderare, nulla si avvicinava a siti come Ars Technica, Slashdot o Wired. Fino ad oggi.
Da quel vulcano di Antonio Cangiano è partito il progetto di creare un collettore di eccellenza per produrre articoli tecnici di altissima qualità.
Finalmente questo progetto è giunto alla luce, il suo nome è Stacktrace.it, fateci un giro.

Sul web 2.0 si è detto di tutto e di più, cose più o meno vere, opinioni, oggettività. In mezzo a tutto questo qualcosa è evidente: il web 2.0 è fatto di persone.
Persone che fruiscono contenuti, persone che creano contenuti, persone che comunicano con altre persone e creano reti di interessi, condividono esperienze.
E tutto ciò accade anche a chi lavora in questo settore, a chi produce siti, contenuti, a chi si incontra nei barcamp, nelle conferenze, oppure a chi porta l’innovazione nelle aziende.

C’è un certo fervore nell’aria, “quelli bravi” si accorgono sempre più che qualcosa sta per cambiare, che si può innovare e divertirsi invece di rimanere nella gabbia di una grande azienda.
E grazie a questo potente mezzo che è la rete, stanno nascendo nuovi modi di lavorare assieme, nuovi modi di collaborare, nuove forme di scambio.

L’aspetto che più mi piace di questo periodo di fervore è la comunità. In Italia si sta creando un network di elite interdisciplinare: programmatori, esperti d’informazione, bloggers, designers. Si comunica, ci si diverte, si lavora assieme e gli altri stanno a guardare, seguono.

Ed ecco il senso di questo post.
L’ultima volta che mi sono sentito parte di qualcosa del genere è stato negli anni ‘90, quando Internet era per pochi e si comunicava con Fidonet, quando invece di Skype e degli instant messenger c’erano IRC e la netmail.

In quel periodo, principalmente in Europa, si diffuse il fenomeno della così detta “scena demo“, ovvero gruppi di appassionati di programmazione, grafica e musica che, sfruttando al massimo la loro creatività e le capacità dell’hardware di quei tempi, producevano software chiamati demo (in realtà vere e proprie opere d’arte) che dimostravano le loro abilità e la loro bravura.

In Italia questo fenomeno fu seguito da qualche decina di giovani appassionati e con tanta voglia di dimostrare al mondo le proprie capacità e di competere con i fratelli nordici.
A quel tempo comunicare non era facile come oggi, i cellulari erano una rarità e collegarsi a Internet o Fidonet costava una cifra. Così ogni occasione era buona per incontrarsi di persona, scambiare idee e codice, iniziare collaborazioni o creare su due piedi qualcosa di nuovo.

Quello che ricordo con più nostalgia è sicuramente l’unione che si era creata in questo gruppo di persone, si era tutti amici, indipendentemente dalla città d’origine, quando ci si trovava (allo SMAU, a casa di qualcuno o semplicemente in giro) c’era sempre di che imparare e di che insegnare, non ci si annoiava mai e ci si divertiva sempre.

Ed è proprio questo aspetto che mi fa sentire un po’ come in una nuova scena, sperando che continui e prosperi e che non muoia come la mitica scena demo degli anni ‘90.

Per avere un idea di quello che è stato, ho trovato questo clip su YouTube girato al The Trip 98, uno dei pochissimi party che si sono tenuti in Italia ed organizzato dal team di cui facevo parte (DeathStar). La mia bella facciona appare al 1′47″:

Update: nei meandri del mio hard disk ho trovato il mio video report del Trip 1999 tenutosi al Palasport di Firenze dal 25 al 28 Marzo 1999:

One of the most important characteristics of modern web application is scalability. With the advent of the web 2.0 era your web application can grow up very fast to millions of users and almost all the now famous websites that experienced this rapid growt shared the same problems: how to design a web application to serve from hundredths to hundredths millions of user requests.

Some people would argue that some language is faster than others or some framework is better scalable than other but the real answer is that there’s no silver bullet for scalability.
What you have to do instead is to follow some simple rules while you write the application from the ground (even if someone says that performance is not an issue before performance is an issue).

Monolitic applications cannot scale

This is far the most common issue in scaling. If you build a web application that is a big block of code, a huge monolitic tightly coupled mixture of code and HTML, you will loose the ability to optimize and separate what can run fast and what can be run more slowly.

Like a modern manufacturing system, your application must be built as separate and loosely coupled modules. By keeping each module small and independent you can optimize the usage of limited resources like CPU and memory and get the best performances.

By using standard RPC mechanisms (like SOAP or REST) or enterprise message busses (like ActiveMQ or XMPP servers) you can easily and transparently interconnect these modules while maintain the ability to optimize and scale each single module.

Some common features that can be separated from the main application are:

Administration panel

Many web applications need an administration panel needed to configure the application and manage user and data. Usually all this data is stored in a database that can be accessed and modified by a separate administration application.

Mail delivery

Many web applications handle the mail delivery in a synchronous way. This means that the HTTPD process has to wait for the SMTP server or the mail delivery program to complete. By keeping a shared mail queue (like a mysql db) you can minimize the queing time and manage or delay the actual delivery.

Batch data processing and statistics generation

This is a common source of load on backend databases in websites that show download/view counters of media items such as images or videos. A common approach is to update the “views” and “downloads” fields in the database on each user request. This puts the databased under a huge load that can bring it down to his knees during traffic peaks.
A better approach is to move the views/downloads counters updates to an asynchronous process that updates the database once in a while. This process can analyze the web server log to find how many times an item was viewed or downloaded. Another option involves the use of asyncronous messages queues or shared memory caches such as memcached.

When I discover delicious it was too late for me since at the time I had too many bookmarks already tagged in Yahoo’s Myweb. But since then I’ve always wanted to move all my bookmarks to delicious but didn’t found how to do it, until now.

Some days ago I found this python script that makes use of myweb and delicious web services to migrate the bookmarks.
Unfortunately the script wasn’t very reliable, it was crashing quite often and, since I have more than 1500 bookmarks, it was quite painful since every time I launched it, it was starting from scratch.

So I decided to build a new script (actually two)… in Ruby.

Step 1 : prerequisites

First of all you must install Ruby and rubygems on your system.

Then you must install rubilicious gem.

Step 2 : export myweb bookmarks

Here’s the first ruby script that you must run:

Copy this code and paste it to a file (like myweb_export.rb). You also want to set the yahoo_id variable with your myweb ID.

Then you can run the script:

Step 3 : import bookmarks into delicious

For the final step you’ll need the script below:

You want to set the proper values for USER and PASSWORD of your delicious account and copy the code to deli_import.rb.

The script waits 1 second after each URL since this is required by the delicious API.

Limitations: unfortunately since the Myweb web services only allow the search of public bookmarks, you’ll not be able to migrate private bookmarks. You must do this by hand or wait that Yahoo will release a Myweb webservice that supports authentication.