We are currently undergoing rapid expansion and require a senior Frontend Developer to join our team.

Technical requirements:

- Deep knowledge of HTML/XHTML
- Deep knowledge of CSS2/CSS3 and how they’re supported by browsers
- Knowledge of Javascript
- Exposure to Javascript frameworks (YUI, JQuery, Prototype)
- Knowledge of Flash and ActionScript
- Knowledge of mobile technologies (WML, XHTML-MP, CSS-MP) will be a big plus

The ideal candidate will be passionate about frontend development, enthusiastic about learning & constant improvement and have a strong understanding of the Internet and emerging web technologies.

Working with our programming team, you will be developing & modifying our online web and mobile site. You will need to familiarise yourself with the intricacies of our web and mobile site, along with being capable of implementing new web and mobile based interfaces.

We are currently undergoing rapid expansion and require a junior PHP Developer to join our team.

Technical requirements:

- PHP5 language (OO programming)
- HTML knowledge
- SQL knowledge
- familiar with Subversion

The ideal candidate will be passionate about PHP development, enthusiastic about learning & constant improvement and have a strong understanding of the Internet and emerging technologies.

Working with our programming team, you will be developing & modifying our online software system. You will need to familiarise yourself with the intricacies of our custom-developed software, along with being capable of implementing new web and mobile based applications.

We are currently undergoing rapid expansion and require a senior PHP Developer to join our team.

Technical requirements:

- PHP5 language (OO programming, SPL)
- SQL knowledge
- AJAX technologies knowledge (Javascript, XML, JSON)
- familiar with TDD (PHPUnit)
- familiar with PECL/PEAR packages
- familiar with Subversion
- exposure to MVC frameworks (Symfony, CakePHP, Zend) will be a big plus

The ideal candidate will be passionate about PHP development, enthusiastic about learning & constant improvement and have a strong understanding of the Internet and emerging technologies.

Working with our programming team, you will be developing & modifying our online software system. You will need to familiarise yourself with the intricacies of our custom-developed software, along with being capable of implementing new web and mobile based applications.

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:

È ormai di dominio pubblico la notizia che Google ha iniziato il suo assalto al mondo mobile attraverso il suo sistema operativo Android basato su Linux. Inoltre, per creare ancora più eccitazione intorno alla sua nuova creazione, Google ha indetto una competizione mondiale con un monte premi di 10 milioni di dollari. Wow! Notiziona! Appena l’ho letto mi sono scaricato subito l’SDK aspettando il weekend per dargli un occhiata approfondita.

Purtroppo, leggo oggi sul blog di Fabrizio Giudici che l’Italia e il Quebec sono gli unici paesi al mondo esclusi da questa competizione a causa di leggi troppo restrittive inerenti la gestione dei concorsi a premio!!!

Quasi quasi scrivo all’indignato speciale!

In sostanza Paul non dice nulla di completamente nuovo. In realtà porta alla luce qualcosa che ogni bravo programmatore sa già intuitivamente, ovvero che per risolvere un problema devi avere tutto il problema in testa.
Il problema sarebbe il programma che deve fare quello che il programmatore vuole e la sua soluzione sarebbe la trascrizione del programma stesso in un linguaggio interpretabile dalla macchina.

Ma come si fa ad avere tutto un programma in testa? Come si fa a entrare “nella zona”?

Sono sempre stato convinto (ed altri colleghi e amici me lo confermano) che esista uno stato mentale (che alcuni chiamano la zona o il flusso) in cui programmare diventa un atto puramente intuitivo, non si pensa al codice che si vuole scrivere come una serie di istruzioni ma si pensa a quello che si vuole ottenere e magicamente il codice fluisce dalla mente alla macchina attraverso le proprie mani e la tastiera.

Il problema sollevato da Paul Graham è che per entrare in questo stato mentale e sfruttarlo al meglio sono necessarie una serie di condizioni:

1. Eliminare le distrazioni

   La mente dev’essere focalizzata sul problema quindi ogni distrazione va eliminata. Spesso è molto difficile isolarsi, soprattutto nei tipici luoghi di lavoro: sentire persone che parlano ad alta voce, telefonate (odio gli open space) o semplicemente essere interrotti con domande che ti costringono a distogliere l’attenzione da quello che stai facendo.
   In realtà essere focalizzati sul problema non significa necessariamente starsene davanti al PC a programmare. Fortunatamente la nostra mente è talmente sofisticata da riuscire a continuare a pensare a quell’algoritmo a cui stavamo pensando la mattina anche mentre ci mangiamo un panino al bar all’ora di pranzo.
   Il punto è che vanno evitate quelle interruzioni che costringono a ragionare su qualcos’altro, creando così un context switch mentale che può richiedere ore per farci ritrovare la concentrazione persa.
   Infine, oltre alle distrazioni non programmate, è bene anche evitare il più possibile le distrazioni programmate. Quale programmatore si mette a lavoro su un problema complesso quando sa che un’ora dopo deve andare in riunione? Meglio quindi fare le riunioni la mattina e rimanere concentrati per il resto della giornata.

2. Programmare ininterrottamente

   Ovvero è più produttiva una serie di hacking run seguita da un periodo di “ricarica delle batterie” piuttosto che seguire un orario di lavoro prestabilito.
   Questo deriva dal fatto che ci vuole un po’ di tempo per entrare ed uscire dalla “zona”. Personalmente quando faccio una sessione di coding “spinta”, poi trovo molto difficile uscirne, anche se sono fisicamente stanchissimo il mio cervello continua ad elaborare (anche tramite le brain waves sarebbe possibile rendere più veloce questo passaggio).

3. Usare linguaggi sintetici

   Lo spazio di attenzione nel nostro cervello è limitato visto che sfortunatamente la mente umana non riesce ancora a fare un uso cosciente dell’enorme capacità d’immagazinamento a sua disposizione. Quindi un modo per “risparmiare spazio” è quello di aumentare il livello di astrazione usando linguaggi più sintetici e potenti.
   Prendiamo ad esempio un’applicazione web per gestire un blog. Pensa alla sua implementazione in C o in Java o in PHP o Ruby (on Rails). In quali di questi linguaggi riesci ad avere una visione dell’applicazione più chiara e completa?
   Inoltre Paul suggerisce che il processo di astrazione possa avvenire anche a livello applicativo, non soltanto tramite il linguaggio. Con un approccio bottom-up ci si crea un insieme di macroblocchi (una sorta di domain specific language) con i quali poi costruire l’applicazione (ed è proprio questo il motivo per cui vengono usati i framework software).

4. Riscrivere i programmi

   Da buon geek sono sempre stato un sostenitore della programmazione evolutiva, che non ha niente a che fare con gli algoritmi evolutivi ma descrive soltanto l’approccio alla programmazione di tipo iterativo. Questo tipo di coding comporta una riscrittura frequente del codice per aggiungere nuove funzionalità, fare bug fixing o semplice refactoring.
   Riscrivere il codice più volte ha due vantaggi: il primo è che la qualità del codice non può far altro che migliorare (anche se non è sempre così) ed il secondo è permette di acquisire familiarità con il codice, chiarificandone la funzione nella nostra mente.

5. Scrivere codice leggibile

   Un programmatore può avere vari stili di scrittura del codice a seconda del suo stato mentale e del motivo per cui lo sta scrivendo.
   Se sto scrivendo un prototipo per verificare che l’idea che ho avuto un’ora prima ha un qualche senso, cercherò di risparmiare tempo scrivendo codice conciso ed immediato, lasciando eventualmente ad una sessione di refactoring successiva l’onere di rendere il programma più leggibile.
   Se invece sto scrivendo del codice che probabilmente dovrà leggere qualcun’altro o dovrò riprendere in mano tra un lasso di tempo indefinito, cercherò di rendere chiaro quello che sto facendo magari con l’aiuto di qualche commento.
   Per inciso, molti pensano che per scrivere codice leggibile basti mettere dei commenti qua e là. Niente di più sbagliato. Il codice deve essere leggibile perchè il suo scopo deve essere chiaro a chi lo legge. L’algoritmo implementato deve essere evidente leggendo il codice dell’implementazione.

6. Lavorare soli o in piccoli gruppi

   Dopo molti anni in una grande azienda posso dire la mia sul fatto di lavorare in grossi team di sviluppo: è un gran casino! Specialmente se i membri del team sono distribuiti su tre fusi orari diversi.
   Il problema di lavorare in team è che si creano delle dipendenze, che dal punto di vista del programmatore sono come dei buchi neri nella sua visione dell’applicazione. Il suo orizzonte di conoscienza finisce dove finisce il suo codice e se ha bisogno di vedere più in là allora nascono i problemi e si rischia lo stallo.
   La soluzione è quella di lavorare in piccoli gruppi suddividendo l’applicazione in parti disaccoppiate tra di loro. In questo modo si eliminano le dipendenze all’interno del gruppo massimizzandone l’agilità.

7. Evitare che più persone lavorino sullo stesso codice

   Anche all’interno di un singolo gruppo possono nascere delle dipendenze. Evitare quindi che più programmatori lavorino sulla stessa funzionalità. Ogni programmatore ha il proprio stile implementativo e cercare di capire il codice altrui non è sempre un impresa facile, specialmente se il codice non è per niente leggibile.
   Sarebbe come se due pittori cercassero di dipingere un ritratto sulla stessa tela, ognuno col proprio stile.

8. Iniziare dalle cose semplici

   Il modo migliore per riuscire ad avere un programma complesso in testa è quello di prenderne familiarità lentamente. Cercare di pensare subito all’applicazione in tutta la sua complessità sarebbe come pensare di scalare una montagna guardandone la cima, invece che pensare ad un lungo cammino è meglio pensare a tanti piccoli cammini meno intimidatori.
   Allo stesso modo è bene iniziare a pensare all’applicazione come un insieme di black box che “fanno qualcosa” senza pensare al “come”, per poi approfondirne la conoscenza aumentando il livello di dettaglio. Come allo stesso modo si costruisce una casa partendo dalle fondamenta e dalle impalcature, fino ad arrivare ai dettagli come il colore delle mattonelle o il tipo di maniglie per le porte.

Penso che sia molto difficile applicare tutte queste regole, almeno nel caso in cui si faccia il programmatore “per lavoro” e sicuramente nel caso in cui si faccia parte di una grossa azienda che probabilmente è abituata a procedure standard che non si sposano molto con il concetto di geek o di hacker.

Il target dell’articolo di Paul Graham è sicuramente quello delle startup (visto che ne finanzia molte), dove si è più liberi ed è più facile seguire queste regole, ma sono sicuro che in futuro gli stessi concetti inizieranno ad essere applicati anche da chi lavora per aziende un po’ più grandi visto che sarà l’unico modo per mantenersi competitivi da un punto di vista tecnologico (specialmente nel campo del world wide web).

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.

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:


require 'net/http'
require 'uri'
require 'rexml/document'

end


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:


ruby myweb_export.rb > data.txt


Step 3 : import bookmarks into delicious

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


require 'rubilicious'
require 'uri'

$stdin.each_line do |l|
title, description, url, keys = l.split('&').collect { |i| URI.decode(i) }
keys = keys.split(',').collect { |k| k.strip.gsub(/\s+/, '-') }.join(' ')
puts title + "\n" + url + "\n" + keys + "\n---\n"
r.add(url, title, description, keys)
sleep(1)
end


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


ruby deli_import.rb < data.txt


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.