iPhone programming

iPhone is the brand-new Apple product which has changed the way Apple thinks. Because of iPhone, Apple strip the word "Computers" from its brand name. And because of iPods and iPhone products, Lepoard developmenet slip a bit, blurring the focus on pure technology.
To be true, I do not beat on  the iPhone success, but the product success is at least  bright this year. And the iPod touch has also added value to the iPods product catalog. But I am an IT-man, damn you boy! So I want to buy it to play with it, to program with it!

The iPhone Open Application Development, is a fresh book on iPhone Developement, edited by O'Reilly which come into play. The book has less then 280 pages, and is well organized. First of all, the bad news: the book lacks figures and tables (only one, and not so useful) and no Photo on it. Then breaking the iPod firmware is not a thing Apple likes a lot. As far as I know, it is NOT illegal, because Apple is opening the device too.
Anyway, breaking the iPhone firmware can prevent you to get the upgrades so, you must know what you are going forward to do.

And now the good news: the book is well written, and guide the user from the beggining to the end.  There are a lot of way to free the iPhone from the jail.

After that, you can also use Linux to program on the iPhone, where the Apple SDK seems only "PC Mac"-enabled.

The book is composed of 7 chapters. After unlocking the iPhone (first chapter), the author explain us how to write code for it, and what is Objective-C. Objective-C is a very nice idea developed by Brad Cox, in the 1980. It is a C++ language "ante litteram". I like the ideas of Objective-Ch because you get the power of C for fast tasks (like  you know, coding your quicksort or your perfect B-trees :) and you get a true dynamic O.O. language, like SmallTalk is. Objective-C was not so lucky, and there are only two major implementation: the GNU one and the Apple one, used to build the entire MacOSX.
I have no time to study it a lot, but I suggest you to code the iPhone in Objective-C.
Then the books start to explore iPhone features like:

  • Basic user interface building blocks
  • Graphic Services and animation effects. You get also a Coreflow-like animation in the Appendix
  • Sound Control
  • Deep integration. A nice thing is the way to make calls: you simply ask the emmeded Safari to open a "tel://" url

The code presented is always very compact, and the style is nice.
The Appendix give us a lot of code samples.

Programming a so riche device is not easy, but the good news is you have a full O.S. to work with.
Java midlets and J2ME are much more difficult to use, if you will find your way with Objective-C.
A very good book, for very nice techno-guys, and not (only) for nerds!

 

 

 

Boosting Squeak: RockSolid images

As some of you know, I was a Smalltalk fan&developer in the last twelve years. I have stopped working on smalltalk years ago… anyway, I am happy to look forward the Squeak Smalltalk Community from time to time.

I republish here an original article posted by me on SqueakPeople, over 4 years ago.
The reason is simple: I am very happy to see a Squeak code fork called “Sapphire” which share most of my thoughts:

Sapphire wants to take a fresh look at the Smalltalk philosophy and current implementations. The idea is to produce high quality open-source packages that will be loadable on a micro kernel. 

 I will take a look to Sapphire, and you will find my throughts here in the next months.

Boosting Squeak: RockSolid images
Posted 30 Dec 2004 by jj
(Journeyer)

I have read the “rant” and “unrant” subject with a mix of uneasiness (embarrassment) and fear. The “Rant” thread began on the 15th of December 2004, and produced a lot of discussion. I will not summarize the thread, because a lot of people read it. Instead, I will go forward and try to find a pragmatic and constructive of helping the community (and yes, I am also very bold and handosome :) << ironic comment).

Part I: The “easy smalltalk”

I think the true problem faced by squeak is to boost harvesting and organize things so that the real problem will be the opposite: too many people fixing bugs :) The stronger danger is the feel of unstablility of squeak; I got some problems when trying to develop a small project in my spare time, forced not to update to the latest squeak because of incompatibilities and so on. On the opposite, mantaining Celeste requires me to be always up to date, and I will not be shocked if the beta release is a bit unstable: I need it!

So my needs change in respect of what I am doing.

On the other side, developing with a stable system is a pre-condition to leverage the community and helping the widley use of squeak in big project. In my opinion, if squeak users feel unstability as a problem, we will never go on without solving it. Decoupling the core release schedule from package release schedules would allow the package maintainers to work at their own pace. This is more or less how it is today. Though perhaps not clearly stated.

We must enforce all these ideas, so I have this proposal: We can have a very dynamic, and tiny “Base Squeak Image”. It will be depurated from all the libs with the exclusion of

   Kernel/Collections and so on   VMRebuilding (needed to generate the SqueakVM)   Mophic   Minimal Sound Support   Minimal Networking Support (only for updating it...)

The base image should be “naked” and only for developers: they can choose the tools to configure it. This could be the goal, the essence of the “Base Squeak Image”: light as a mouse, strong as a tiger :)

Then we can have a “Rock Solid” released about every two or four base Squeak releases. It will have a new version number but the “RS” letters at the end. For example:

 

  Squeak 4.0 RS  Squeak 4.1 (base)  Squeak 4.2 RS  Squeak 4.3 (base)  Squeak 4.4 (base)    Squeak 4.5 RS      <--- Example of delayed Rock Solid release

(Note: there will never be two release with the SAME number, to avoid confusion) The RS should have: a Release notes Workspace and some nice stuff for developing already installed. They will be very very similar to the current releases, at least with some more toys (like Celeste…).

Part II: How will we do it? The incremental step!!

I love the Part I because all seem easy: the trobule went when we JUST try to DO IT.

To obtain a such thing we need to restructure the actual community, and also to change our way of thinking squeaking? Someone said we have tons of things to get a grip on but we are more or less paralyzed unless we change the way the community is “steered”.

The Guides approach may need re-targeting and recalibration, but I will not face this problem now.

The process which brings us to the RockSolid idea will be incremental: let’s start with the actual base image, and start building the first Rock Solid on it.

We can have a Linus-like leader (RockSolid Man or R-Man :) which will do this hard job, asking support to Guides, for example.

We can choose a new R-Man for every RockSolid release, thous freeing it to have too much work on his/her shoulders.

A similar approach will bring to us a more clean evidence of problems, like abandoned code, lazy supporters, alone girls asking for an hero saving them and so on.

On the other side this approach will slow down things at minimum and reduce the “friendliness” of the community of a very very small portion. The squeak-dev mailinglist will have only a new [RS] tag on it.

In summary we have:

We need:

  1. R-Mans
  2. A bunch of SUnits code to build the RockSolid Image. This code will help us to speedup the process.
  3. Voting the above ideas.

The good (?) news is: I will give my work to let the thing born. I will help for emerging of a more vast and accepted way of organizing this thing. I know Squeak, the base kernel, and the collections (and my Italian DNA give me also a lot of good advantages with “alone girls” :)

If you like I can also be the first R-Man (it look like a very bold and handsome position :) << ironic comment).

Kit Lezione 6: Cosa fare se ti vogliono far lavorare

Ciao giovine  ex-BRIT! Cosa vuol dire BRIT? Ma ovviamente Body Rental Information Technology!

Sei contento al calduccio nel tuo ufficio? Hai quindi scritto vagonate di codice scopiazzando di qua e di là e ora sei stato assunto a tempo indeterminato?

Bene, sappi che sei un ottimo elemento ma… eh potresti incorrere in numerosi altri pericoli!

Difatti mio giovane e gioviale fringuelletto, in Italia esistono degli oscuri luoghi di lavoro, in cui… si lavora per davvero!! E questi luoghi brulicano di  gente folle che osa anche tentare di capire quello che fai, per vedere se magari (orrore!) non stai mangiando pane a tradimento!

Come se mangiare fosse un delitto!

E come fare allora? Per fortuna sei in Italia, e quindi ci sono sempre un miliardo di scappatoie con il tempo indeterminato…ma quale scegliere?

Ed ecco che qui entra in azione la lezione sei del Kit!

Se si esclude il desiderio di capire che cavolo è sto’ Java (cosa che vi sconsiglio, e fidatevi, io lo so ci lavoro dal 1995… i listati sono lunghi e pieni di punti e virgola…insomma la punteggiatura è pessima) ecco qualche idea buttata lì:

  • Iscriviti ad un sindacato. Le probabilità che riescano a licenziarti è già bassa in Italia, ma se sei iscritto ad un sindacato sei (quasi) in una botte di ferro. Uno vale l’altro eh. E’ una triste realtà (per il sindacato) ma funziona di brutto! Se poi sei in un impresa statale, è a botta sicura.
  • Prendi la tessera dell’ultimo partito che ha vinto le elezioni. Questa tecnica, chiamata anche “salire sul carro del vincitore” in Italia è stata applicata per centinaia di anni (più o meno dall’invasione dei Longobardi in poi). In alcuni periodi di grande incertezza (per es poco prima di  Waterloo) non era sicura ma ora ci sono appena state le elezioni….e poi comunque il 9o% degli eletti hanno più di sessant’anni… sapete come è facile ingannare un anziano?!…
  • Buca il sistema dall’interno. La tecnica più semplice è accumulare ferie facendo giorni di malattia, poi prenderle di botto e quindi scomparire dalla circolazione per mesi e mesi. Se il tuo capo ufficio è arrivato in quella posizione con un sistema all’italiana (lo vedrai nella prossima lezione del kit: “promozione alll’italiana”) hai già vinto. Puoi anche provare a non farti più vedere e voilà, assumeranno un paio di BRIT economici per darti una mano!

Infine mio caro ex BRIT, evita, per favore, di farti mettere incinta e/o di chiedere permessi se sei padre. Difatti benché la legge italiana dovrebbe difenderti, questa è l’unica tattica che non è adeguatamente tutelata… che peccato eh?!

Nota per le persone senza humor e con la polemica in zucca.
Il sindacato è una cosa importantissima, e anzi spesso dove non è presente si verificano situazioni di insostenibilità lavorativa non da poco. Purtroppo però in Italia si può constatare come esistano situazioni di serie A e serie B.
Se sei a tempo indeterminato hai più diritti di quelli che non lo sono. Per dimostrare questa affermazione è sufficiente vedere l’importo del mutuo che una qualsiasi banca è disposta a concederti a seconda della tua tipologia di contratto, a partità di condizioni al contorno (età, reddito, ecc).
Allo stesso modo, se sei di sesso femminile e hai magari il desiderio di mettere al mondo dei figli alcune società tendono a guardarti con sospetto, come se potessi danneggiarle…

E infine, la satira è satira: colpisce chi vuole, quando vuole!
Provaci anche tu, ti divertirai!

The Valueteam PDFGenerator

 

Per un importante cliente di ValueTeam, ho sviluppato per un'applicazione chiamata PDFGenerator, che è stata pacchettizzata come un vero e proprio prodotto.
PDFGenerator nasce in una situazione caratterizzata da un alta variabilità dei requisiti utente.

Le specifiche del progetto hanno subito variazioni significative nell'arco di quattro anni, ed alla fine i requisiti utente erano parecchio mutati.  L'applicazione, già fatturata, non era ancora stata validata dal Cliente finale, ed era passata di mano moltissime volte.
Da un lato c'era la necessità di fornire uno strumento semplice da utilizzare, dall'altro la possibilità di espanderlo nel momento in cui le esigenze di Business del Cliente fossero cambiate, contenendo i costi di sviluppo.
Questi due aspetti erano acuiti in questo contesto, poiché i dati potevano provenire da fonti assai eterogenee per tipologia (database o personale del marketing) e l'utente finale doveva elaborarle in modo uniforme e rapido.
Per queste ragioni la specifica era cambiata spesso nel tempo, e la sfida era notevole.
PDFGenerator è semplice dal punto di vista software, e la sua forza sta nell'idea, e nella capacità di capire l'utente finale.

Si tratta di una applicazione che è in grado di caricare dati da un backend, e di generare poi a partire da esso una serie di documenti Word parametrici, da cui l'utente genera documenti pdf.
Tali documenti sono una serie di informative sui prodotti erogati dal Cliente verso i loro partner commerciali.

Si tratta di gestire agevolmente oltre 500 documenti, simili tra loro ma divisi in moltissime tipologie.

L'applicazione consente all'ufficio marketing di creare informative personalizzate, ed è integrata con Microsoft Office.
Il back end può essere esteso in diversi linguaggi (Java, .NET ecc) purché generi in uscita un file Excel.
Un modello MS-Word poi si occupa di integrare, con una serie di macro, i dati provenienti dall'Excel e di consentire, in modo guidato, la generazione di un vasto numero di documenti MS-Word.
E' quindi possibile estendere l'applicazione nelle due direzioni:
+ dal lato backend, arricchendo i moduli che forniscono i dati.
+ dal lato del front end, personalizzando l'interfaccia utente
L'estrema attenzione al Cliente si è concretizzata nello sforzo di fornire una interfaccia di amministrazione semplice e gradevole, seguendo i più moderni dettami dello Human Interface Design.

Inoltre, l'aspetto più importante è stato comprendere le esigenze del cliente attraverso lo sviluppo incrementale di una serie di prototipi operativi. Lo sviluppo di prototipi operativi in tecnologia WebJ2EE risulta difficoltoso,  mentre appoggiandosi agli widget grafici di MS-Office è stato possibile ridurre di quasi tre volte lo sforzo operativo.

Per maggiori informazioni, mandate un email