Paul's Journal

iBloglines, now has more features. The Bloglines Blog has more details.

Geoff has a comparison of iBloglines to NewsGator’s iPhone site.

It turns out, even Google Reader users like our iPhone site. Hurrah.

Google Gadgets API Terms and Conditions:

Prohibited Actions

You will not and will not allow on your behalf third parties to (a) make and distribute copies of any aspect of the iGoogle page (including the API) or accompanying documentation except as permitted by these API Terms and Conditions; (b) attempt to copy, reproduce, alter, modify, reverse engineer, disassemble, decompile, translate, or attempt to discover any prototypes, software, algorithms, or underlying ideas which embody the iGoogle page or Google API;…

The Netvibes UWA, seems like a decent response/alternative gadget API. However, it seems pretty much dead since its release in April. It also doesn’t have a specific license or terms associated with the UWA API Documentation itself.

All I want is a public and open API for developing widgets and gadgets against. Sigh..

Short: Bloglines Users, go to i.bloglines.com on your iPhone.

Last Saturday, I got an iPhone. It was great, but the full size Bloglines on it, with the Zoom Mode, sucked. Trying to read large volumes of text is a massive pain on the iPhone.

On Sunday morning, I started working on an iPhone specific site for Bloglines. By mid-afternoon on Sunday, I had something that worked reasonably well.

I spent the rest of this week taking in refinements and new feature suggestions from everyone inside the company.

Thanks to everyone on the Bloglines team for helping out with this project. It is by far the coolest thing we have released this year so far.

The iBloglines site is written with:

• 253 lines of C++ in 5 files
• 382 lines of client side Javascript in 1 file
• 287 lines of ETL Templates in 8 files

Of course, this is only counting the code we wrote specifically for the iPhone, but it does make me doubt that you need to use a Scripting Langauge for rapid development, if your framework is good enough.

iBloglines is built upon iUI . Originally we tried to just using it as a base, but in the end, we essentially forked it. We entertained using Dojo 0.9 on the iPhone, but since the only required browser to support is MobileSafari, it would of been pretty heavy.

We used The Electric Template Language, or ETL for generating the HTML. Relatively young compared to things like ClearSilver, it is much cleaner and was a joy to work with.

Developing for the iPhone has been pretty fun, but I believe Apple has been less helpful that they should be.

We might not need a SDK for ‘native’ Applications,
but we need better tools for the iPhone.

Simple things, like making an official iPhone Simulator, like Microsoft has for Windows Mobile, which had identical rendering to the iPhone would be very helpful. iPhoney is a good start, but it really should be an official Apple Developer tool.

We did most of our development on Firefox with Firebug, and then ported it to the MobileSafari later, because the tools for Firefox are so much better.

In closing: I love my iPhone, I hope Apple will hurry up and make better developer tools, and I hope the Bloglines users enjoy the new iBloglines!

So, I didn’t rush to get one on launch day; But enough people have said good things about it, and it doesn’t look like a flop, so today I went up to the Valley Fair Apple Store in Santa Clara at about 4pm.

Walked in, and it was crazy busy, people all huddled around the demo units. I figured they were sold out, but asked an employee, and he said to just go to the checkout. And so now I have an iPhone.

The migration was painless. I ported my existing Cingular/ATT account. When I originally signed up with Cingular, it took 3 hours to activate the phone in a store. With Apple, I did it form home, in 3 minutes, via iTunes. It is about time cell phones stopped sucking.

I’m happy to announce the release of a new piece of software that I’ve written. Cluster Tail or ctail for short. Basically, it multiplexes lots of SSH connections, to invoke tail -f on a large set of machines or log files.

It isn’t the most amazing idea, but if you have ever had hundreds of machines (or even a dozen), trying to understand what is going on across all of can be very difficult, and this is just another tool to make that easier.

Most other methods of reading log files on large clusters get away from classic Unix Philosophy, but ctail can easily be piped into other commands.

Campfire seems great. We have been playing with using it at work, rather than our internal IRC network, after seeing this blog post.

The UI is great, the file sharing is great… But the only major blocking issue right now is the complete lack of an API.

Most other 37 signals apps have official APIs, but Campfire only has an unofficial ‘API’ which is just a Ruby Module which scrapes the HTML.

Look, Ruby is great, but when you are integrating a large project, with existing chat services, you need a standard protocol with good API libraries. Right now on our IRC channel, we have Bots written in Ruby, Python, TCL, and C/Lua.

They perform all kinds of services, from searching Google, to SVN commit notification, to controlling our buildbot builds.

If Campfire at least had some kind of official API, it could be XML based, JSON based, or even something else, I don’t really care — it would allow us to easily port our existing tools in many languages. Heck, if it had an API, you could also make a Jabber Gateway easily.

So, here is my request to 37 signals: I just want an API.

An API so we can become entrenched into your solution. So we would never leave. Right now its a hard sell — we would be either writing/porting Tinder for 3 or more languages, or investing lots of time in a Ruby based Proxy of some kind, but that all seems excessive. Look at the other 37 signals apps with APIs, a whole ecosystem of things that support your products appear. APIs are good for you, and good for us, a potential user.