Marco Bellinaso

Nel progetto SharePoint al quale sto lavorando in questi giorni è uscita la necessità di mostrare l'elenco delle attività (presenti all'interno di una list Tasks normale) con delle formattazioni particolari. Ad esempio si volevano marcare con dei colori diversi le attività non completate ma già scadute o in procinto di scadere, le attività con scadenza entro 15 giorni, e così via. Una cosa tipo quello che rappresenta lo screenshot seguente:

Dopo una breve ricerca via web, ho trovato un attimo post -- Filtering and Formatting with Date Values -- presente nientemeno che sul blog del team di SharePoint Designer. L'esempio che propongono è proprio sulla colorazione di celle/righe in base alla differenza tra date; perfetto quindi. La soluzione si basa sull'utilizzo di SharePoint Designer (ovvio, visto dove si trova il post) per trasformare la ListView webpart standard in una DataView webpart e poi modificare pesantemente l'XSLT che renderizza la griglia con le attività, sfruttando dei template per calcolare la differenza tra le date e condizionalmente applicare stili custom.

Sebbene sembrasse perfettamente funzionante, dopo un po' di riflessioni ho deciso di abbandonare quella strada. Un po' per il fatto che sebbene lo comprenda l'XSLT non è il mio pane quotidiano, ma più che altro perchè questa soluzione non è particolarmente manutenibile, flessibile e riutilizzabile. Cosa accade infatti se voglio applicare lo stesso rendering custom su altre webpart delle attività (perchè magari ho più viste della stessa lista in homepage, con filtri diversi)? Dovrei rifare tutto lo stesso procedimento con SharePoint Designer. O perlomeno dovrei esportare l'XSLT modificato dalla prima webpart, applicarlo sulle altre e poi a mano correggere una serie di cose. Se dovesse saltare fuori un bug ovviamente la pezza andrebbe riapplicata ovunque. Se si dovesse fare un'ulteriore customizzazione, stesso discorso. Fino magari ad arrivare ad un punto dove la customizzazione non è neanche possibile (che so, la creazione di voci di menu contestuale personalizzate, il mix di dati provenienti da un'altra fonte, ecc.).

La soluzione verso la quale mi sono orientato è quindi stata quella di crearmi una webpart custom che mi permettesse di fare quello che volevo con il massimo della flessibilità e capacità di debugging. Per semplificarmi la vita ho usato la mitica SmartPart, una webpart "generica" che fa da contenitore di normali UserControl ASP.NET. Ho anche fatto riferimento ai seguenti 2 articoli che mostrano per bene come utilizzare il controllo SPGridView di SharePoint per creare una griglia con l'aspetto e tutte le caratteristiche delle griglie standard di SharePoint, ma caricate e gestite con una logica e dei dati custom:

- Displaying Data by Using the SPGridView Control in Windows SharePoint Services 3.0
- SPGridView and SPMenuField: Displaying custom data through SharePoint list

SPGridView eredita dalla classica GridView di ASP.NET, quindi c'è davvero poco da imparare per poterla usare. Si configurano le sue colonne, si ricava in qualche modo una DataTable (o un altro insieme di dati che implementa IListSource o IEnumerable), la si associa alla proprietà DataSource della griglia, si chiama DataBind, e il gioco è fatto. I dati potrebbero essere tranquillamente presi da un DB esterno, in tutto o in parte.

Nel mio caso volevo semplicemente mostrare il contenuto di una lista standard di SharePoint: una volta ottenuta una collezione SPListItemCollection la si può facilmente usare per creare una DataTable corrispondente grazie al suo metodo GetDataTable. Ricreata con poche righe la griglia dall'aspetto standard, per applicare le formattazioni custom basta intercettare l'evento OnRowCreated e modificare le proprietà dell'intera riga corrente o di una sua cella (BackColor o CssClass, ad esempio) in base alle proprie "regole di business".

Ora la domanda è: ok, hai duplicato la griglia standard e ci hai personalizzato l'aspetto...ma l'hai fatto in modo specifico per una singola vista con dei filtri prefissati...che succede se la vuoi applicare a viste diverse della stessa lista? E' semplice anche questo: è bastato aggiungere alla webpart una proprietà custom che permetta all'utente di specificare il nome di una delle viste di SharePoint create per la lista sorgente (ad esempio "Attività personali", "Attività in scadenza oggi" ecc.), e usare il modello ad oggetti di SharePoint per recuperare solo i dati di quella vista. Questo articolo che ho scritto ormai ben 3 anni fa spiega come fare (l'articolo richiede una registrazione gratuita al sito). Quindi non occorre neanche gestire N proprietà per specificare in modo complesso una serie predefinita di filtri, cercando di fornire una qualche flessibilità alla vista; basta solo scrivere quelle 5 righe per definire questa singola proprietà e poi lasciare a SharePoint il compito di ricavarsi i dati filtrati esattamente come avrebbe fatto per la sua UI standard, nonchè lasciare all'utente la possibilità di creare nuove viste (o di modificare quelle esistenti) con gli strumenti standard di SharePoint che già conosce.

Per la cronaca, lo screenshot in alto raffigura proprio la webpart custom creata. Non si sarebbe detto, visto che replica addirittura il menu contestuale, vero? (menu che è comunque possibile personalizzare con le proprie voci)

La webpart creata mi permetterà di aggiungere velocemente funzionalità a tutte le istanze sparse per il sito(i), correggere bug o modificare anche pesantemete l'aspetto della griglia...modificando, compilando e ri-deployando solo 2 file (il .ascx dello UserControl e il relativo assembly .dll). Seguendo la soluzione SharePoint Designer + XSLT le cose non sarebbero certamente state altrettanto semplici. In casi simili a questo, dove la flessibilità e il riutilizzo sono importanti, direi proprio che vale la pena affrontare il maggiore investimento iniziale (comunque molto contenuto).

Vi siete mai chiesti come sono gli uffici di mega corporation tecnologiche come Microsoft, Google, Apple e Yahoo, o di più recenti startup di successo (o mega successo) come Skype, Twitter, Facebook, Mozilla e Last.fm? Beh, OfficeSnapshots è quello che fa per voi: è un blog dove in ogni post vengono presentate decine di foto degli uffici di aziende tecnologiche (con qualche eccezione), scattate dagli stessi dipendenti o dall'autore del blog in visita. Per aziende multinazionali spesso ci sono post multipli che mostrano gli uffici sparsi in giro per il mondo, permettendo qualche curioso confronto tra uffici a NY e a Bangalore della stessa azienda.

Ecco qualche miniatura degli uffici di Google nel quartier generale a Mountain View: 

Un po' diverso dal tipico ufficio italiano, eh? Mi sono sempre chiesto però se chi lavora in queste aziende ha poi davvero il tempo di usare i biliardi e le console attaccate a mega schermi, o se invece tutto ciò serve per impressionare i visitatori e fare da "arredamento" ;) Certo che a pari quantità e tipo di lavoro, stare in un ambiente grigio e smorto o in uno vivace e pieno di gadget (da usare anche solo sporadicamente), può fare una certa differenza...Lo dice anche Joel Spolsky (con molte più argomentazioni :-)

Dopo più di 2 anni di lavoro super intenso, Code Architects ha rilasciato la versione 1.0 di VB Migration Partner, il miglior strumento attualmente esistente per la conversione di codice VB6 in VB.NET. Ok, io sono di parte, avendo anch'io lavorato al progetto sotto la guida di Francesco Balena, ma questo beta tester non lo è:

After 15 years of developing our application in VB3, VB4-16 bit and VB6, I was disappointed to discover that we could not move to VB.Net. Our application was too large to rewrite into the new syntax. In spite of edits made to follow the new rules, such as omitting the lower bound on Dim statements, the migration tool available (NDR: quello incluso di default con Visual Studio) ran for 5 hours and gave 1947 errors to fix; and that was just on our main application program. Using VB Migration Partner, we converted that same code to .Net in 9 minutes and had 3 compilation errors to fix, all having to do with a third-party OCX. After commenting out those lines, the application started up and ran just fine, displaying dialogs that invoke our VB6 COM servers to perform calculations and print reports. Amazing! We need to keep developing our code in VB6 for our current clients, but the batch processing and code-test-fix methodology will allow us to convert a changing code base without making the same changes twice, once in VB6 and again in VB.Net.

ASC has been providing this application to businesses for over 25 years and we have successfully migrated from the mini-computer platform in the past. A rewrite would be impossible with an application such as ours that has evolved over so many years. Our client base has grown steadily during that time, and now includes 100’s of small to midsized firms with networks of 5 to 30 concurrent users of our application, and 20 of the top financial institutions in the nation, two of which have over 100 concurrent users of our application. With this tool, we will be able to support our existing platform and roll out a VB.Net version with minimal disruption to our clients. 

Brian Olson
Actuarial Systems Corporation, USA

Sembra "abbastanza" buona come prima recensione, no? Del resto Francesco e i ragazzi in ufficio a Santeramo hanno fatto beta testing per mesi e mesi, lavorando su applicazioni VB6 reali, di clienti reali, con milioni di righe di codice VB6. Al confronto, applicazioni "più tipiche" (molte applicazioni non superano le 5-10.000 righe di codice...anche se poi magari ci sono decine o centinaia di queste piccole app a formare la mega app completa) dovrebbero essere quasi uno scherzo. Le righe di codice VB6 in circolazione sono ancora miliardi, e un tool efficace può essere la soluzione a molti problemi.

So (sappiamo) benissimo che gli sviluppatori vedono con molto scetticismo i tool di migrazione in generale...e questo scetticismo è perfettamente giustificato dai risultati mediocri che i tool attuali ci hanno abituati ad aspettarci. Ma questo non è il "solito" tool di migrazione, e mi auguro che se vorrete approfondire l'argomento ve ne renderete conto. 

Maggiori informazioni sul prodotto (nonchè un sacco di informazioni sulla migrazione in generale, utilissime anche a prescindere dall'utilizzo di questo tool) le potete trovare sul sito ufficiale, o sul blog dove Francesco posta le ultime novità (e i successi).  

Hackers & Painters è una collezione di saggi scritti dal famoso Paul Graham, prima co-fondatore di Viaweb (l'azienda che è poi stata acquisita da Yahoo diventando Yahoo! Store) e poi co-fondatore di Y Combinator (azienda che finanzia e aiuta a crescere startup tecnologiche e web-based nelle fasi iniziali di vita). Se non lo conoscete, vi consiglio caldamente di fare un salto sul suo sito, dove potrete trovare decine di ottimi saggi liberamente disponibili.

In questo libro scrive di argomenti tipo:
1) Perchè i nerd sono impopolari al liceo, e invece più tardi hanno successo nel lavoro
2) Hacker e pittori: gli hacker sono "gente che fa", come i pittori, gli architetti o gli scrittori
3) Pensare al di fuori del coro, proporre teorie originali anche se "eretiche"
4) Vincere rompendo le regole
5) Le potenzialità del software/servizi web-based contro i software desktop
6) Come fare fortuna! (risposta: crea la tua startup e lavoraci come un pazzo)
7) Come battere la concorrenza: essere sopra la media
8) I linguaggi di programmazione: perchè diventano popolari, come scegliere il proprio, a cosa dare importanza, il linguaggio "da sogno"
9) Design contro Ricerca: la ricerca deve essere nuova; il design deve essere buono
10) Come sconfiggere lo spam

Il messaggio di fondo che pervade un po' tutto il libro è: per avere successo devi darti da fare, lavorare 10 volte meglio dell'impiegato medio, non avere preconcetti e non aver paura a pensare in maniera diversa rispetto agli altri o a prendere decisioni inusuali, pensare a cosa vuole l'utente, creare prototipi delle proprie idee da far vedere ed evolvere, ecc. ecc. Magari non è niente di sconvolgente, ma di sicuro lo racconta molto bene, con osservazioni e storie provenienti dall'esperienza sul campo (come la scelta di Lisp per creare il suo software di commercio elettronico, che gli ha permesso di essere infinitamente più veloce dei concorrenti che usavano Perl e C su costosi ambienti Sun). Come "bonus" ci sono anche un sacco di curiosi paralleli e confronti con il mondo dell'arte (Paul ha studiato arte a Firenze, dopo il dottorato in Informatica ad Harvard!), filosofia, ed eventi storici.

Unica nota un po' negativa è che alcune argomentazioni a volte possono sembrare un po' troppo forti e arroganti, e un po' troppo pro-USA...cosa che potrebbe forse infastidire qualcuno...ma nel complesso la lettura è molto scorrevole, piacevole, informativa, e anche ispirante. Una lettura consigliata insomma!

P.S: una preview del libro è liberamente accessibile su Google Books.

Qualche sera fa ho partecipato ad un interessante e piacevole incontro con gli amici Andrea, Eugenio ed Elia; il tema: programmare per iPhone! Eh si, l'ho comprato principalmente spinto dalla curiosità di esplorare almeno un po' le sue potenzialità come piattaforma applicativa, e un po' alla volta sto vedendo le basi della programmazione con Cocoa Touch in XCode. Devo dire che è tutto un altro mondo rispetto allo sviluppo con .NET, ma l'impressione è che una volta fatta la mano non sia una cosa così terribile ;). Andrea fortunatamente è un grande esperto di Mac OSX e quindi ha promesso di darci una mano (anche se qualcosa mi suggerisce che nei prossimi tempi sarà parecchio impegnato su nuovi e più importanti progetti... Andrea, congratulazioni per la nascita di Valentina!).

La nostra attrezzatura: 1 MacBook Air, 2 MacBook, 1 MacBook Pro, 3 iPhone, 1 iPod Touch

Per il momento chiudo segnalando un ottimo sito per chi avesse qualche curiosità su questo mondo, iPhoneDevCentral.org: si tratta di una collezione (costantemente in crescita) di screencast sullo sviluppo per il dispositivo di casa Apple. I video sono parecchio "alla buona", ma raggiungono bene lo scopo di mostrare concretamente almeno i passi fondamentali necessari ad iniziare i propri esperimenti.

Quando da SharePoint Designer si crea una DataView webpart con un qualche raggruppamento, il codice auto-generato fa uso della funzione ExpGroupBy per l'effetto di apertura/chiusura dei gruppi. Sfortunatamente tale feature non funziona in FireFox, alla faccia del tanto propagandato supporto cross-browser. La cosa simpatica (si fa per dire) è che il raggruppamento all'interno delle liste standard di WSS funziona bene anche in FireFox invece -- ma in quel caso la funzione usata è ExpCollGroup.

Sono andato a vedermi il codice della funzione ExpGroupBy, presente nel file Core.js, scoprendo che semplicemente la funzione termina subito se il browser è FF! Ma perchè? Non c'è nessun limite tecnico, è una cosa semplice tutto sommato. Togliendo tale condizione e provando il codice si scopre però che effettivamente la funzione non va su FF...ma, di nuovo, non per limiti tecnici, quanto perchè tale funzione è stata scritta abbastanza da schifo usando javascript non standard! (le variabili non sono dichiarate, gli array sono acceduti tramite (x) invece di [x], e qualcos'altro ancora). Pur non essendo assolutamente un esperto di javascript mi sono armato di FireBug sono riuscito a metterla un po' a posto in modo da farla funzionare sia su IE che su FF. Di seguito potete scaricare il risultato:

Download ExpGroupBy.txt (2,34 kb)

Il nuovo codice lo potete sostituire al codice originale all'interno di Core.js, oppure (soluzione preferita e da me adottata) inserire all'interno di un file .js custom da referenziare nella masterpage *dopo* Core.js (in modo che ne faccia l'override). 

Il problema si è risolto con uno sforzo relativamente basso, ma:
1) Era proprio necessario far codificare due funzioni molti simili a due persone diverse?
2) Possibile che chi ha implementato ExpGroupBy non sia andato a vedersi come era stata codificata (correttamente) ExpCollGroup?
3) Possibile che l'autore di ExpGroupBy non si sia posto il problema di come rendere cross-browser una funzione così semplice, invece di escludere a priori FF?
4) Possibile che nessuno abbia testato una funziona che è sicuramente usata in un mare di webpart create da SharePoint Designer, e abbia sollevato ua bandierina alla scoperta del problema? (soprattutto considerato che nelle liste standard la funzione sorella non ha problemi...almeno per coerenza fatele o non fatele funzionare entrambe!)

Tutto questo mostra come anche in MS non tutti gli sviluppatori siano dei fenomeni (e si presume che chi ha codificato quella funzione sia anche un esperto di JS, altrimeni si sarebbe occupato di codice di back-end o di altra roba) 

Quando l'altro giorno mi è stato chiesto di importare i dati di un foglio Excel in una tabella di SQL Server 2005, mi son detto "no problem, lancio il Data Import/Export wizard, e via". Purtroppo tale tool non è presente nella versione Express, dal momento che mancano anche i SQL Server Integration Services (SSIS) and SQL Server Agent sui quali quel wizard si basa. Mi sembrava uno spreco installare la versione Standard solo per questo, quindi ho cercato qualche soluzione alternativa. E' possibile ad esempio scrivere una macro VBA direttamente in Excel per ciclare sulle righe e colonne, e inserire i dati in SQL Server tramite il vecchio Recordset di ADO...ma anche questo mi sembrava troppo lavoro per un compito così semplice! La soluzione che ho adottato -- e che ha funzionato alla perfezione -- è stata di usare la funzione OPENROWSET, in questo modo:

SELECT * INTO Negozi FROM 
OPENROWSET('Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=c:\temp\DatiNegozi.xls', [Sheet1$])

Questo codice prende tutti i dati presenti nel file XLS specificato (nel foglio Sheet1), e li copia in una nuova tabella chiamata Negozi. La prima riga del foglio Excel dovrebbe essere di intestazione, ed è quella che il comando utilizzerà per estrarre i nomi dei campi da creare nella nuova tabella. Se alcuni campi dovessero essere creati con un tipo diverso da quello desiderato (ad esempio float ancihè int, o varchar invece di nvarchar) sarà ovviamente possibile modificare lo schema della tabella direttamente da Management Studio Express dopo l'importazione.

Il comando però non funzionerà se le "Ad Hoc Distributed Queries" non sono abilitate. Per attivarle, eseguire i seguenti statement: 

sp_configure 'show advanced options',1
reconfigure with override
go
sp_configure 'Ad Hoc Distributed Queries',1
reconfigure with override
go 

Cercando tramite Google la soluzione ad un qualche problema di sviluppo o sistemistico, per una qualsiasi piattaforma, vi sarete senz'altro imbattuti spesso nelle pagine di Expert-Exchange. Questo sito è sostanzialmente un enorme forum omnicomprensivo, esistente da più di 10 anni e con più di 2,1 milioni di soluzioni varie. La cosa particolare è che per vedere le risposte alle domande (oltre che per fare nuove domande) in teoria si deve pagare, altrimenti le risposte vengono "coperte" da un messaggio che invita a registrarsi. Solo pochi giorni fa mi sono reso conto di come sia possibile accedere liberamente alle risposte senza iscriversi: basta scorrere la pagina fino in fondo!!! Ecco una pagina di esempio.

Ok, forse sarò stato l'ultimo a scoprirlo (tralasciamo l'imbarazzo...), ma il fatto è che prima di arrivare alle risposte in chiaro spesso ci sono chilometri di risposte coperte, e poi c'è un'ulteriore lunga sezione con link a tutti gli altri forum. Tipicamente bisogna scorrere parecchio per arrivare alle risposte in chiaro, e normalmente abbandonavo il sito immediatamente o al massimo una volta raggiunta la sezione con i link alle sezioni (che credevo essere l'ultima). Non avrei mai immaginato che usassero una strategia di questo tipo, ma a quanto pare con qualcuno può funzionare...Certo è che se avessi addirittura pagato per l'accesso, e poi scoprissi che le risposte sono in fondo, mi sentirei quantomeno preso per i fondelli...

Quando il 29 giugno 2007 è uscito nei negozi americani l'iPhone di Apple, a seguito dell'annuncio ufficiale di Steve Jobs alla WWDC, sono stato uno di quelli che ha minimizzato alla grande l'evento non mostrando un minimo di interesse. E per cosa mi sarei dovuto emozionare poi? Un device bloccato sui network americani, senza UMTS, ma soprattutto senza possibilità di scrivere o installare applicazioni aggiuntive! Insomma un cellulare non smart, con solo un ottimo touchscreen...che ci faccio?

Qualcosa, anzi più di qualcosa, è cambiato però il 6 marzo 2008 quando sempre Jobs ha presentato l'SDK per sviluppare applicazioni native (contro lo sviluppo di mini-siti web specializzati per iPhone, come era possibile fare sino a quel momento). Il piano era già chiaro ad ottobre 2007, ma erano solo parole...subito dopo l'ultimo annuncio invece è stato reso live l'iPhone Dev Center, dove scaricare l'SDK (2,1GB), centinaia di pagine di documentazione (sul linguaggio Objective-C, il framework Cocoa per Mac OSX e Cocoa Touch per iPhone e iPod Touch), vari esempi di codice, video, FAQ ecc. Insomma è stato un grande lancio, con un supporto ai livelli delle nostre tecnologie di casa Microsoft. Entro 4 giorni dal rilascio sono stati contati più di 100.000 download. Niente male, per un dispositivo che per ora ha una distribuzione tutt'altro che globale, no?

Ma perchè è così interessante per uno sviluppatore la prospettiva di poter creare software per l'iPhone? Ci sono vari motivi, legati tra loro:

1) Uniformità delle feature nei device di destinazione: quando si decide di sviluppare per l'iPhone si sa benissimo quali sono le caratteristiche del 100% dei dispositivi sul quale girerà il proprio software: c'è una fotocamera, un display con una ben determinata risoluzione, un accelerometro triassiale, un display con multitoch ecc. ecc. Essere sicuri che tutta questa roba sia presente, e funzioni esattamente allo stesso modo ovunque, dà una certa tranquillità, eccome! E' vero che la varietà dei device presente nel mondo Windows Mobile e Symbian garantisce una più veloce evoluzione, concorrenza e prezzi migliori...ma è anche vero che uno sviluppatore deve spesso fare i salti mortali per gestire i casi in cui un utente abbia una risoluzione diversa da quella usata per lo sviluppo, abbia una fotocamera con risoluzione minore che non garantisce la stessa qualità, abbia una CPU più lenta, abbia un display con colori meno forti che al sole risulta illeggibile, non sia fornito di questa o quell'altra funzionalità ecc. Apple dà una sola scelta (scegliere tra 4 e 8GB non la considero una gran scelta...), ma è quanto basta al suo target, ed è una scelta che rende la vita molto più facile per chi scrive applicazioni.

2) Feature interessanti: avere a disposizione un accelerometro triassiale, un display multitouch e un dispositivo di geolocalizzazione basato su wi-fi spot e cell towers apre le porte a tutta una serie di applicazioni interessanti impossibili da creare su altri device, perlomeno non senza aggiungere aggeggi esterni.

3) Framework completo preinstallato: Cocoa Tourch e il resto dello stack applicativo (compreso SQLite per la gestione di dati su DB) è quello che ha usato anche Apple per lo sviluppo degli applicativi forniti di default...e quindi trovate già tutto installato, su tutti i dispositivi. Questo vuol dire meno problemi per il deployment, e creazione di pacchetti il più piccolo possibili. Il framework fornito vi permette di usare facilmente tutte le varie funzionalità del dispositivo (contatti, fotocamera ecc.), e di gestire gli eventi di movimento, posizione cambiata, pressione con più dita ecc. Se pensate a Window Mobile, solo recentemente sono state introdotte le classi per integrarsi con gli applicativi PIM di sistema....prima bisognava ricorrere a librerie di terze parti (da installare) o a funzioni di basso livello. Di nuovo, il problema delle librerie esterne poi è che non si ha mai la garanzia che funzionino perfettamente su tutti i device.

4) Mercato ampio: entro fine anno Apple intende arrivare a 10 milioni di device venduti. Che poi ci riesca è un altro discorso, ma se si sbagliano probabilmente non si sbaglieranno di molto. Tra l'altro, gli basterebbe accelerare l'immissione nel mercato globale. Per ora in Europa l'iPhone si trova solo in Inghilterra, Germania, Francia, Austria e Irlanda. Si parla da molto del rilascio in Italia, che sembra sempre stia per arrivare a giorni, ma per ora niente. Comunque certamente numeri di tutto rispetto per un device che a fine anno avrà solo un anno e mezzo di esistenza.

5) Semplicità di deployment: la distribuzione (a pagamento o meno) del software di terze parti avverrà esclusivamente (volendo restare nell'ufficialità) via App Store di Apple, ovviamente integrato sull'iPhone / iPod Touch. Ci sarà una sezione software dalla quale cercare ciò che ci interessa, comprarlo o scaricarlo, e averlo automaticamente installato. La facilità d'uso dovrebbe in teoria essere altissima; sia per l'utente finale che per lo sviluppatore, che non si dovrà preoccupare di installazioni. Ma non si dovrà neanche preoccupare di crearsi un sito per la vendita e del relativo marketing di base; mettendo il proprio software su App Store questo sarà facilmente accessibile a tutti i fruitori del servizio (ovviamente immagino sarà comunque possibile avere spazi più di rilievo nello store, comparire nella homepage o in cima ai risultati di una categoria ecc.). Certo, l'utilizzo dell'App Store costa 99$ (anche se intendete distribuire applicazioni gratuite) e Apple si tiene il 30% della somma pagata dai clienti (per costi di gestione, hosting, banda...e anche per guadagnarci qualcosa ovviamente)...ma del resto qualsiasi distributore vi fa pagare una cospicua percentuale (anche 40%), senza offrirvi la strettissima integrazione con il dispositivo target, l'autoinstallazione, una così grande visibilità ecc.

6) Mercato vergine: l'SDK nativo è attualmente in beta, e l'App Store dovrebbe venire aperto per le applicazione di terze parti a giugno. Sebbene attualmente esistano già parecchie applicazioncine sviluppate con "metodi alternativi", solo quando la distrubuzione sarà ufficiale e supportata il mercato sarà interessante. Non essendo ancora arrivati a quel momento, non ci sono per ora leader nelle varie categorie (utility per far questo e quello, giochini di un certo ecc.) - dato l'altissimo numero di donwload dell'SDK è facile supporre che saranno tantissime le applicazioni lanciate non appena sarà possibile farlo...ma comunque i concorrenti saranno sicuramente meno rispetto a piattaforme esistenti da molti anni. Di sicuro si tratta di un mercato interessante per chi sviluppa e intende trovarsi una sua nicchia.

7) Interesse dei finanziatori: è stato creato un fondo (coerentemente chiamato iFund...) di 100 milioni di dollari, per finanziare applicazioni che vengano ritenute "degne". Anche se immagino che alla fine saranno destinati ad aziende con un certo nome e con progetti piuttosto grossi e impegnativi, e difficilmente allo sviluppatore hobbysta con un progettino per divertirsi, questo perlomeno dimostra l'interesse che gira attorno a questo nuovo mercato. 

8) Semplicità di sviluppo: è molto difficile raggiungere la semplicità di sviluppo offerta dai tool di sviluppo Microsoft, ma comunque Apple ha un suo IDE (XCode) già installato con OSX, e l'SDK dell'iPhone aggiunge una serie di template di progetto e un emulatore (velocissimo) del dispositivo. XCode è ancora lontano da VS, ma comunque offre un designer di UI (per iPhone questo deve ancora arrivare, ma dicono che ci sarà con l'SDK definitivo...per ora la UI deve essere scritta a manina), un debugger, integrazione con un source manager, un designer di classi e altre cosette. Non è male, e comunque è meglio di quello che c'è per altri ambienti (questa l'ho solo sentita dire però...). La documentazione, gli esempi, i video e tutto il materiale di supporto completano il quadro. Certo non si trovano i centomila libri e guide non-ufficiali, ma...non è male :-)

Questo è quanto mi è venuto in mente finora...e mi pare non sia poco! Sembra che Apple stia veramente puntando sugli sviluppatori, e sembra che questi si stiano dimostrando interessati. Presto cominceremo a vedere cosa ne verrà fuori.

Sulla mia macchina di svilluppo uso regolarmente l'accoppiata SQL Server 2005 Express + SQL Server Management Studio Express, lasciando le versioni full (e a pagamento) sui server di test e (ovviamente) di produzione. Per un ambiente di sviluppo la versione Express va benone, a parte la fastidiosa mancanza del Profiler, indispensabile strumento di analisi delle query che vengono elaborate dall'engine. Fortunatamente esiste un SqlProfiler open-source di terze parti che sopperisce alla mancanza, offrendo grosso modo le stesse funzionalità del tool ufficiale.