Google Wave, a new API/protocol and platform was presented on Google I/O. It’s a hosted, embeddable communications and collaboration platform that introduces quite a few interesting features that are currently either not available or require multiple service vendors/providers. It was written in Java/GWT.

Google has made it clear that the protocol is going to be open and there will be open source [reference] versions of the server and client, although someone could — theoretically — write their own before that by following the specifications on the aforementioned site. Wave includes Robots and Gadgets which are server and client-side applications [respectively]. The former are automated participants for waves and gadgets are applications that run on the client and allow for new input methods. Google is also allowing for embedding of waves on third-party websites through the Wave Embed API.

This is a great project by Google, which, of course, is going to be a building block [and trojan horse] for online collaboration; viz. Google Office + Collaboration; features that might, in the not-so-distant future, render Microsoft’s workhorse [Office] dead. The fact that they are open sourcing the whole thing is fantastic news.

While the potential is there — and is undoubtedly great — I believe that we should be careful before judging how disruptive Wave is going to be in the next few years. Many technically interesting projects have withered and died for numerous reasons, sometimes political other purely business. Wave is probably going to be extremely useful for intranets from the very beginning. The reason for this is that it’s very easy to use the Wave infrastructure where a single server hosts the service. But its promise, its full potential lies in the fact that its an Open System; it might become an extremely disruptive technology for the whole ‘net. Besides replacing all sorts of pointless centrally hosted services [twitter, disqus, facebook], the Federation protocol is probably the single most impressive thing about Wave; it assures interoperability and maximises plurality without creating walled gardens. What’s more, that the protocol is open and that the code is open source means that in the future the Wave platform might evolve into a fully distributed protocol. The Openness of Wave and the Federation Protocol is the single most impressive, brave decision I’ve seen Google take and one that elevates Wave well above other similar technologies.

To the Google team behind Wave, in the words of their own Lars Rasmussen: “Thank you, thank you, thank you, thank you!” =)

Ανακοινώθηκε αργά μέσ’την ημέρα (ώρα Ελλάδος) προχθές, γρήγορα έφτασε στα χέρια χιλιάδων εγγεγραμμένων προγραμματιστών για iPhone. Το νεο λειτουργικό προσφέρει πολλά, τόσο σε χρήστες όσο και στους ανθρώπους που σχεδιάζουν και αναπτύσσουν εφαρμογές για τη συσκευή.

Για τη χώρα μας ιδιαίτερου ενδιαφέροντος φυσικά αποτελεί το ελληνικό πληκτρολόγιο, το οποίο περιλαμβάνει την ίδια τεχνολογία αυτόματης διόρθωσης που είχαμε δεί στα αγγλικά. Ακόμη πιο σημαντικό — για όσους δε νιώθουν άνετα με τα αγγλικά — είναι το πλήρως εξελληνισμένο περιβάλλον. Με δεδομένα τα παραπάνω, καθώς και τη φημολογία πως η Vodafone σύντομα δε θα αποτελεί μονόδρομο για την απόκτηση iPhone στην Ελλάδα, το iPhone ενδέχεται να έχει ένα λαμπρό μέλλον και στη χώρα μας.

Πέραν τις σημαντικές προσθήκες στο πεδίο των χρηστών (το copy-paste είναι ίσως από τις σημαντικότερες όμως υπάρχουν εκαντοντάδες άλλες — δε θα μπώ σε λεπτομέρειες: ο ιστός προσφέρει αρκετό υλικό για όσους ενδιαφέρονται), θεωρώ άκρως σημαντικότερες τις προσθήκες για developers. Μια σειρά από νεα APIs, φοβερές δυνατότητες χαρτογράφησης και επικοινωνίας εντός των εφαρμογών, η υπηρεσία push (επιτέλους) αλλά και οι νέες μέθοδοι πώλησης και διάθεσης σπονδυλωτών εφαρμογών μέσω του AppStore αλλά και των ίδιων των εφαρμογών προς πώληση καθιστούν το iPhoneOS μια σημαντική κίνηση από την Apple που διορθώνει αρκετά από τα ελλείματα των προηγούμενων εκδόσεων για τη συσκευή και προσδίδουν νεα λάμψη σε ένα ήδη εντυπωσιακό προϊόν.

Ατυχής, κατά τη γνώμη μου, η επιμονή στη κοστολόγηση της αναβάθμισης για iPod Touch. Βλάπτει τους χρήστες, βλάπτει όμως και τους προγραμματιστές που δεδομένου του εμποδίου αναβάθμισης πολλοί από τους χρήστες των εφαρμογών τους ίσως μείνουν σε παρωχημένες εκδόσεις λογισμικού, κάτι που σαφώς επηρεάζει τόσο τον κύκλο της ανάπτυξης γενικότερα, όσο — ίσως κυρίως — και τη φάση των δοκιμών.

Yep, the iPhone SDK does not support dynamically linked libraries. And that’s truly fantastic news for all iPhone developers wishing to leverage existing code out there. You can, of course, use a statically linked library in your code, or — if you have the code for the third-party libraries you’re going to be using — copy the files in your project and compile them together with your own source.

One way to facilitate the inclusion of third party code, is by using what Apple calls, sparse SDKs, or additional SDKs. These are what some people call custom SDKs. From the XCode Build System Guide:

There may be times when, in addition to a system SDK, you need link against sparse SDKs. A sparse SDK is an SDK that is not a system SDK. Sparse SDKs may be provided by third parties, or you may build them yourself.

“Build them ourselves”, they said. “Develop for the iPhone, they said”. :)

Sadly there is practically no documentation for building custom SDKs for XCode. Some people have used the existing toolchain and some ‘inventive’ cooking of the accompanying metadata files to create custom SDKs for use in the iPhone, but I guess your mileage may vary.

Which brings us to the main point here; Apple has been prodigiously improving their platform over the past seven years; from what was a kludge, a crude amagalm of classic Mac OS and NeXT APIs has become the state-of-the-art platform of our time. Yet, over the years I’ve come to realise that Apple’s developer documentation — while steadily improving — is almost as bad as Microsoft’s code quality. The documentation — especially in newly released SDKs — ranges between sparse and non-existent. Coupled with the numerous bugs one’s bound to come across in the process of developing even a smallish application, bad documentation really detracts from the experience. And while — I’m sure — everyone will agree that good code is arguably better than good documentation, Apple could certainly improve there. At least the company seems to be using meaningful naming. :)