Ubk

ubk is a framework that allows the web-developer to rapidly build up data-driven or data-based web-applications. Pages are written in an xml/xhtml dialect, rich of build-in tags made to loop through a result-set, show data in a variety of ways, easily navigate the db structure, reuse xml snippets, and so on. All of the application logic resides in pure php files, that can be used to manage lots and lots of xml-page-definitions with the same abstract logic, adding separation between application-logic and presentation. This version includes AJAX support via the (gorgeous) prototype library.


http://code.google.com/p/ubk/

ubk è un framework che permette agli sviluppatori di costruire rapidamente applicazioni orientate alla gestione dati. Le pagine sono scritte in un dialetto di xml, ricco di tag fatti per ciclare su un result-set, visualizzare i dati in vari modi, "vascare" facilmante la struttura del db, riutilizzare parti di codice xml, e via dicendo. Tutta la logica applicativa risiede in file php puri, che possono essere utilizati per gestire molti file xml che condividano la stessa logica di funzionamento, fornendo quindi la separazione fra logica applicativa e presentazione. Questa versione include il supporto per AJAX attraverso la (fantastica) libreria prototype.


http://code.google.com/p/ubk/

Touch the future

The iPhone has a 3,5" touch screen, an accelerometer, a proximity sensor, a light sensor... and a impressive user interface.
In the near future I expect to see some innovations in computer interface devices too; years ago Octopus and I were trying to design a user interface for computer aided software design based on a virtual glove (such as this one) with very poor results, but touch screens at a low cost and multi touch tecnology could be the real great innovation in user experience.
Right now these tecs are focused in daily use PIM apps (and devices) but we'll surely soon see innovations in technical applications too: technical modeling and designing, web navigation, and so on, but the most interesting evolution from my point of view will be in software developement tools: new user interfaces will drastically improve object oriented software design, with the result of better software produced in less time.
It could be an interesting challenge to design some innovative IDE focused on Object Oriented design, design pattern usage, GUI design, all running on a 3D environment with multitouch screen interoperability functions: and IDE focused on the structure of the software with less new and more re-used code, template/pattern based code writing assuring more quality. And far more fun.
Wanna write sw with an iPhone instead of a mouse ;)

Il pattern "catena di montaggio"

Applicabilità:

quando a fronte di una sorgente di dati più o meno complessi, occorre effettuare una catena di operazioni condizionate dal contentuto degli eventi stessi, operazioni che possono anche essere condizionate l'una dall'altra rispettando però la sequenza temporale. La catena di montaggio può prevedere instradamento multiplo per il prodotto in elaborazione, ed inoltre in macchine che dispongono di più unità di elaborazione, ogni stazione di montaggio può lavore su un Thread separato utilizzando il meccanismo del pipelining.

Struttura:

il pattern è composto da un oggetto "costruttore della catena" il cui compito è quello di assemblare la catena di montaggio, un oggetto "catena di montaggio" il cui compito è quello di eseguire il ciclo di montaggio, ed una sequenza di oggetti implementanti l'interfaccia "stazione di montaggio", che effettuano le operazioni necessarie per assemblare la soluzione finale.

Implementazione:

Stazione di montaggio
Una stazione di montaggio è un thread che effettua operazioni su dati prelevati da un unico input (una coda FIFO sincronizzata) e che può, in funzione del contenuto del dato da elaborare, instradare in output su una o più code il prodotto della sua elaborazione verso altre stazioni.

Catena di montaggio
questo oggetto si occupa dell'instradamento del "semilavorato" all'interno delle stazioni, fornendo la struttura, il percorso ed i meccanismi di trasporto dei semilavorati.

Costruttore della catena
Ovviamente questo à l'oggetto più importante: ha il compito di costruire la catena di montaggio, cioè interpretare correttamente la configurazione richiesta e posizionare le specifiche stazioni nell'ordine corretto. In questa situazione si può utilizzare un Factory Method delegando quindi alle implementazioni della factory la logica di assemblamento della catena di montaggio.

Un esempio

Ho utilizzato questo pattern per un applicativo di monitoring di una rete: ogni sessione di monitoring ha le sue caratteristiche particolari, per cui viene costruita una catena di montaggio ad hoc in funzione di una configurazione presente in un database; al passaggio di un pacchetto di dati, viene effettuata una sequenza di operazioni:

• Calcolo di una funzione di valorizzazione di una parte del pacchetto determinata dal valore dell'intestazione del pacchetto e da dati contenuti nel DB


• Aggiornamento di una cella di una tabella, la cui posizione e contenuto vengono calcolati dalla prima stazione di montaggio


• Trace su un file in funzione dell'intestazione del pacchetto


• Entry in un report HTML o XML


• Aggiornamento di un grafico

Utilizzando la costruzione "al volo" della stazione di montaggio ho semplificato drasticamente il codice di interpretazione degli eventi, rimosso gran parte delle istruzioni condizionali e, cosa più importante, ho la possibilità di estendere a piacere le operazioni da svolgere al variare della configurazione.
Inoltre, utilizzando una catena di montaggio "multilinea", dove cioè gli eventi vengono instradati verso direzioni diverse ad ogni stazione, sono riuscito ad ottenere la variazione di comportamento in funzione dell'evento in modo molto semplice.

Aforisma

Vi è una sottile bi-implicazione tra la definizione di un problema e la sua soluzione.

db4objects: un db engine object oriented

db4objects è un engine db object oriented con doppia licenza (alla MySQL) disponibile in versione open e in versione commerciale ed è in grado di integrarsi con Java e con la piattaforma .NET.
Sembra disporre di tutto ciò che serve (transazioni, query language avanzato, sistemi per il supporto al refactoring) per lo sviluppo di applicazioni orientate ai dati di nuova generazione.
Staremo a vedere.

Violare la legge di Amdahl?

La Legge di Amdahl pone un limite all'incremento di prestazioni di un sistema multiprocessore (nella sua versione generalizzata pone un limite all'incremento atteso di prestazioni di un sistema di elaborazione quando vengono migliorate alcune componenti dello stesso): in particolare (rimando al link su wikipedia le formulazze), se P è la porzione di calcolo interamente parallelizzabile, mentre S è la restante parte di calcolo non parallelizzabile, il fattore di incremento è uguale a (P + S) / ((P/N)+S) [dove N è il numero di processori] - ovviamente senza considerare l'overhead dovuto al parallelismo.
Questo è un limite deprimente, soprattutto adesso che i sistemi multiprocessore (o multicore) sono oramai ovunque (e sopratuttto a casa mia... ;)
Ed ecco quindi, prendendo spunto sopratutto da un fantastico post di Carlo, una piccola disserzione sulle strategie che si possono adottare per ottenere un incremento di prestazioni in qualche modo superiore a quello che potremmo attenderci con un approccio tradizionale; in particolare, (visto che è impossibile violare la legge di Amdahl) si può lavorare per ottenere il massimo incremento possibile spostando quanto più possibile il "lavoro" nellla variabile P:

• Dove non è possibile parallelizzare un algoritmo, si può tentare di parallelizzare i dati
• Dove non si può parallelizzare un processo seriale, si può "pipeline-izzare"
• Dove non si può migliorare la performance, si possono introdurre nuove features sfruttando comunque il parallelismo e senza deteriorare le prestazioni
  

Se "lato server" è relativamente facile ottenere netti vantaggi dalla presenza di più unità di elaborazione, è "lato client", cioè per le applicazioni monoutente, che la legge di Amdahl pone seri limiti all'incremento di performance, e diventa veramente difficile ottenere dei vantaggi significativi.
A questo punto, è interessante il concetto di "velocità percepita", cioè la qualità di prestazione fornita dal computer percepita dall'utente. In questi termini diventa fondamentale il tempo di risposta ai comandi, il feedback fornito dal sistema, più che l'effettivo tempo di esecuzione dei job. In questo caso il fatto di avere più unità di calcolo potrebbe non tanto accelerare l'esecuzione di un processo quanto piuttosto dare la possibilità all'utente di continuare a sfruttare la macchina anche durante l'esecuzione di un compito pesante.

Assembly ad oggetti

Ai - per fortuna - pochi che hanno avuto il piacere di conoscere il più eclatante assemblerista ad oggetti della storia, posso ora dire con certezza che "l'assembler ad oggetti" (inteso come metodologia di sviluppo) non esiste. Sono giunto a questa conclusione dopo il refactoring del firmware di un device embedded, che mi ha procurato notti quasi insonni, e pochi momenti di sonno disturbati da un incubo ricorrente (una voce cavernosa che dal profondo di una gola oscura urlava "perchè iooooo....").
Strutturare un software poco più che banale in linguaggio macchina richiede capacità di concentrazione talmente elevate che risulta un compito praticamente impossibile a qualunque umano (solo un compilatore può farcela); è troppo difficile non introdurre bachi assurdi e indebuggabili in migliaia di linee di codice pseudo-organizzato, privo di controlli semantici, privo di vincoli strutturali... ogni tentativo di introdurre struttura (documentata peraltro a piu' non posso, con mooolte più linee di commenti che di istruzioni) introduce una probabilità in più di bachi. Fare binding dinamico in assembly è troppo error-prone, e al di fuori di qualche piccolo esperimentuccio, diventa impossibile riuscire sia a strutturare il software che renderlo efficiente (per efficiente intendo: terribilmente efficiente, sfruttando fino all'ultimo le risorse modeste dell'hardware).
L'uso indiscriminatamente ottimizzato dei registri (solo 16) su un processore RISC che sembra morire ad ogni accesso in memoria, il windowing virtuale (3 finestre da 4 registri) implementato per la chiamata ricorsiva (dalla 4 ricorsione in poi, i registri vengono dumpati sullo stack)... no, è troppo. L'assembly è fatto per programmarci in assembly, poi c'e' il C++. E quando si esce dal mondo embedded ci sono i vari Java e C#.
L'assembly ad oggetti è morto.
Lunga vita all'assember ad oggetti, e ai gloriosi pionieri dell'informatica.

Back to the Future (of Object Oriented)

I've recently read the slides of Bruno's speech at JavaDay06Roma, and it reminded me of my first experiences in C++, while reading Stroustrup's “The C++ Programming Language”. At that time, there weren't frameworks available to build applications, so my thinking was focused on the design, and not the implementation nor the technology to use: I should really do a step back, and start thinking again in terms of pure Object Oriented Design!
I want to start my new job in the best way!