Following on from previous time related posts, it's time to welcome in 1234567890, or 23:31:30 UTC on 13 Feb 2009. Computer time is measured in seconds since the epoch, 1st Jan 1970, so if you have a programming language handy you can verify for yourself:
import java.util.*;
public class Test {
public static void main(String args[]) {
System.out.println(new Date(1234567890L*1000L));
}
}
// Prints Fri Feb 13 23:31:30 GMT 2009
Happy geeky new year!
I've been doing a bunch of iPhone development recently, and what struck me is how little XCode seems to have evolved since its initial inception (and it wasn't that much of a leap over Project Builder before it, either). People wax lyrical about Mac development tools, so it's interesting to see where XCode is when positioned against other languages and tools that support them. You can either read the rant, or jump to the bottom where the interesting bit is.
Back in University, I bought a NeXTstation, also affectionately known as my friends as 'a very black and very expensive way of checking my e-mail'. Not only was it a great computer (pity I could only afford the black-and-white model) but the software became the forerunner of the Macs that I work with today. Even though it only had 8Mb (my graphics card probably has more than that now!) and a 68040 on board (same as the trusty Amiga) it was the software that drove great things (not to mention the intertubes). Like the Mac that followed, Nextstep had it all under the control of one supplier, so provided magneto-optical drives, audio conferencing and everything postscript, so faxing and printing was built-in.
Nextstep left many legacies in today's Mac development kits; from the NS in NSObject to the AppKit framework that realised there was more to life than a main() method. But arguably its most important contribution is that of the development environment, which made developing, debugging and deploying applications a breeze; and free, which in the days of yore was considered unheard of. After that, I went down the Java path as it took off and my (then) company with it.
Scan forward to the present day, and what do we have? Well, other than a name change and some fancy new tools for doing analysis graphically with DTrace, basically the same tools I was working with over ten years ago. Even Interface Builder hasn't changed that much, except the astute will have noted that NIBs (Nextstep Interface Bundles) have been renamed XIBs (XCode Interface Bundles) and gone all XML on us.
Project builder has now been renamed XCode and ... well, that's pretty much it. OK, it's got Subversion support which Project Builder didn't have when it was first created; but then subversion didn't exist when Project Builder was first created either. But other than a few template differences - and more distinctly the ability to compile against different platforms (like the iPhone) - it's pretty much the same hunk as it always used to be. One might argue that it's got more functionality; but actually, that's been added by the additional frameworks (CoreData, GrandCentral etc.) rather than the tools themselves.
And developing in project builder XCode is ... painful. Which is a shame, because it was the first developer IDE I ever used, and ever since I've been moving onto bigger and better tools. About the only thing that came close to Project Builder and Interface Builder was Visual Age for Java; a much maligned and misunderstood tool due to its lack of a filesystem. Ultimately, that was what killed it — HelloWorldians were used to 'javac HelloWorld.java' and simply couldn't think in terms of classes. Even now, its direct descendant Eclipse supports a tree-based file view of your system by default (with its inability to scale much past about 20 files; Mylyn of course cuts down your project's view to about 20 files, which is why it's so popular). Those who are In The Know go to the class browser, which provides a VAJ-like view (and if you find the button, you can even make it hide everything outside the current method ... but that really is showing my age). Ironically, Mylyn doesn't tend to work so well with the class browser if only because it suffers far less than the pseudo-infinite tree of files ...
So, coming back to XCode, I expected ... well, not to have to go back ten years. PB XCode has an annoying habit of not knowing whether it's a project-based or window-based application, and seems to have slept the last millenium without hearing of the concept of tabs or simply the ability to have two files open at once in the same window side-by-side. (Emacs users, please laugh now.) It has an annoying concept of 'grouping' files (think directories but that bear no resemblance to the filing system) and an utter inability to appreciate that maybe, just maybe, Foo.h and Foo.m might be related and present them in some kind of unified node in the tree that you could flip between (c'mon! Stick a fancy flip-over animation to go between the interface and the implementation! You can do it for a dashcode widget; why not the source for that widget?).
The auto-complete is a joke. Guess which key you press? Well, congratulations if you thought Tab or Space or (heaven forbid) waiting 500ms for the box to automatically pop up. Nope, it's ESC, probably the most uselessly available key on the keyboard and with absolutely no escaping involved. (Aha, but it escapes your typing, I hear you cry ...) And even though Objective-C is a beautiful and typed language*, pressing Escape brings up every frigging possible selector in the known universe. I mean, nine out of ten targets are fully typed, and the ones that aren't (id) are usually used directly from a [Foobar alloc] call; it's a fairly safe bet that the initializer you want to run is from the Foobar class. *OK, so it's got typed and untyped objects, and it's possible to send any selector to any object; it mightNotRecognize it, but you can send anything to anyone (or to no-one, but that's nil-picking).
Refactoring? Hyperlink browsing? API documentation in a nice little pop-up hover box* when you mouse over a method? Pah. Documentation is for wusses, and for people who really absolutely want to download the complete set of 150Mb every week when someone updates a typo at Apple. (Do you know, the downloads contain not only the documentation, but source code (formatted as HTML), source code in a ZIP and source code in a DMG. Maybe it wouldn't be a 150Mb download if you didn't send the same stuff in three different - and incompatible - formats.) And let's not get into the craptastic solution of having to register just to see the iPhone documentation - it's not like the GoogleBot is ever going to sign up to develop iPhone applications, is it? No, far better that people can't find out how to do things via the intertubes. *OK, it has the research assistant. But the research assistant is always down at the pub and failing to notice what you want or being in any way useful. It's late for meetings, comes back smelling of alcohol, and bringing his mate Clippy with him.
So, what to do? Well, it just so happens that I've done the odd bit of playing around with Eclipse, implemented my own language parser and the like in the past; and I'm fairly au-fait with both Java (which is what the majority of Eclipse is written in) and Objective-C. Wouldn't it be nice if there were a way of developing Objective-C applications in Eclipse? To be able to use whatever storage provider you wanted instead of 'that one' and 'that other one'? If hyperlinking really was hyperactive and documentation was a pleasure instead of a pain? A world in which your Objective-C was really objective instead of obstinate and XCode didn't make you cross while you coded?
I propose that we create ObjectivEClipse. It could be based on CDT but with bindings to format and display Objective-C code. We could export bindings to Mylyn, stuff it in Git or Hg, and even build composite projects containing web content or other language plugins (AppleScript, I'm thinking of you). It's going to take time, it's going to take effort, and it's going to take people. Only people with all of the above need apply. Register your interest here, or in bug 68083, and let's have a beer at EclipseCon. Whilst it would probably make sense to start work in an incubation component of CDT (not the least of which is using Eclipse's infrastructure to host EPL'd code), I think we need to build up a suitable base of interested people and some demo code before we can think of doing that. In the meantime, I've created ObjectivEClipse at Google Code so those who want to play, can.
See you at EclipseCon!
Every now and again, I stumble upon a website that uses FTP to power its downloads. I really can't understand why, in this day and age, people are still using FTP to make data available.
Firstly, FTP is a particularly unfriendly protocol when it comes to accessing data. It opens up parallel connections; a 'command' channel over TCP, and a 'data' channel over UDP. However, whilst the ports are well defined (port 20 for command and 21 for data), the actual incoming ports use a randomly-assigned port that's negotiated as part of the FTP channel. That means firewalls (which are a necessity in this day and age) either end up blocking FTP or have some serious deep packet inspection to try and open up the data coming back in again. In fact, the only reason that FTP works via NAT is that the NAT device 'knows' about the way FTP works, and performs a juggling act to hook it together.
FTP is an anachronistic protocol that has long since been superseded by HTTP. For a start, the concept of password-protected FTP sites (where the password is transmitted in clear-text) is pointless in this day and age; and even now, most sites/browsers use an anonymous login for downloading files. The anonymous login - where you transmit your e-mail address as the password - is also something that is seen as less worthwhile, especially given the volume of spam that's seen these days, to the extent where browsers fill in a dummy value (mozilla@example.com) instead of providing a real e-mail address.
Although extensions exist (like SFTP*, FTP over SSH, FTP over Socks over SSH), all of these are trying to work around the obvious hole that occurs when the data isn't protected.* SFTP isn't based on FTP, but rather SSH file transfer protocol - thanks to Brett for highlighting this in the comments.
When HTTP was first released, it was able to compete with FTP on almost every level. The only thing that HTTP/1.0 didn't support is the concept of resumable downloads. A reusable download occurs when a client is disconnected through the process, and needs to start again. Although optional, most FTP servers and clients support this feature. It wasn't until HTTP/1.1, and the associated Accept-Ranges and Content-Range headers, which allowed ranges of bytes to be defined, that resumable HTTP transfers were possible. Although technically more flexible than FTP (allowing arbitrary ranges of data to be acquired rather than just a starting point through to the end), the practical effect is that it's possible to resume the download of files if the client loses the connection to the server. (Some 'fast' HTTP proxies work by initiating multiple requests for non-overlapping data ranges instead of one request to handle it all.) It would even be possible to support a bit-torrent like 'chunking' of data over HTTP ranges in the same way that HTTP servers work today (and you could even include HTTP redirects for others who might have a different chunk ...)
HTTP also has many other advantages over FTP for pure downloads. FTP has always been a bit bipolar when it sees the world as either 'Binary' or 'ASCII', not the least of which is that the world has moved on from ASCII to Unicode. But realistically, a client and server know nothing of the file type that's being sent back, and it's up to the client to guess the type based on the extension. HTTP on the other hand can positively identify what the file type is as part of the response (and doesn't have to be a file on the hard disk either).
Further, HTTP provides a number of additional benefits - automatic compression of data, finding out about the type of a file without downloading it, proxy support - not to mention the ability to run over SSL with HTTPS - which aren't possible in vanilla FTP at all.
So, why do companies still insist on setting up and making data available via FTP? Well, sometimes the company has been around for a while (like before Windows 3.1) and they may just have an antiquated system that they can't (or won't) update. But more often than not, it's ignorance; the assumption that HTTP is used for the web and FTP is used for downloads. Many of these servers in fact support HTTP as well - just changing the protocol from ftp: to http: is enough to convince the server to use this century's mechanisms.
FTP is of course used for more than just download. One aspect is the ability to navigate through a repository, and of course to be able to upload files as well. But both of these uses are far less often used than the data acquisition across the web. There are also standardisation problems - the format of the output generated by 'dir' or 'ls' commands can vary, and clients have to screen-scrape the text to present a list of files.
All of this is possible with HTTP - WebDAV is a set of additional HTTP methods; and so, works within the same framework, proxying, encryption, type decoding, partial range satisfying etc. Although WebDAV can do a lot more (versioning, in particular) it's possible to use WebDAV to connect to a remote server, get the contents of the files and then download them. And the nice thing about HTTP is that should another method be more appropriate (or be located on a different server) the protocol has built in redirection to allow the server to inform the client to go somewhere else.
I suspect one of the reasons WebDAV isn't as widely used as FTP is of historical inertia. That and the fact that command-line programs for WebDAV aren't that common (when in fact, most OSs have the ability to mount WebDAV drives far more efficiently than FTP clients can navigate a remote hierarchy). It's also less likely that you can sell CuteWebDAV or FastWebDAV that bring GUIs to the FTP experience, since you can mount WebDAV drives and traverse them with your favourite file manager commands.
Still, it won't be long before there are command line tools and WebDAV GUI clients, and when that happens perhaps FTP can finally be laid to rest.