Sloecode updates: UI tweaks

Several members of the sloecode team have been hard at work tweaking the sloecode web-app UI - we think we have a much more usable product as a result. We've still got a long way to go, but the UI is looking better every day. Here's a picture of the portal page a user sees when they log in:

Changes from the previous version include:

• Addition of the project menu - this allows users to quickly jump to any project they are a member of.
• Branch logs are now shown on separate pages, instead of cluttering up the main user/project page.
• "Account Settings" and "Logout" Links are now pushed to the right of the page menu bar, which is where most users expect them to be.
• More help topics have been written.
• Lots of small textual changes to page content - too many to list individually.

We still have not got the server package into our PPA. In the mean time, installing and running a sloecode server involves a few manual steps, but is by no means complicated. If you're interested in the project, feel free to drop in the #sloecode channel on irc.freenode.net, or introduce yourself on the sloecode developers mailing list!

bzr-sloecode Installer for Windows

There's now a basic installer for the bzr-sloecode Bazaar plugin for Windows. It currently does the following:

1. Installs the plugin to the right place.
2. Sets the SLOECODE_SERVER environment variable to whatever you want.

There are a number of aspects that require improvment however:

1. It doesn't check that Bazaar is installed first.
2. It doesn't ask if the user wants to install the plugin for everyone or just the current user. Currently the SLOECODE_SERVER setting is system-wide, which requires admin permissions to set.
3. No validation on the Bazaar server address.

...So it's a work in progress! Patches are more than welcome. You can grab the installer from the bzr-sloecode launchpad page.

Another Microsoft UI Fail

...this time in Microsoft Outlook. Could the programmer who was too lazy to write their code properly please go back to school? There is no excuse for this:

You want me to take this string, split it on comma characters, and re-join it with semi-colons instead? Sure, I'll do that you you, with my meat-fingers, because I'm really good at that, and computers are known to be terrible and SIMPLE TEXT MANIPULATION.

Introducing: Sloecode

Bazaar is wonderful. It combines the right powerful features with a good dose of common-sense and a sprinkling of usability. Well okay, perhaps more than a sprinkling of usability. I use bazaar a lot in combination with launchpad. The client-side bzr-launchpad plug-in makes this a breeze: I don't have to remember user-names, passwords, project URLs, or anything else. However, occasionally I don't want my code to be visible by default. Sometimes I don't want my code leaving the building. I could easily host a simple bazaar repository locally, but creating teams of users quickly gets difficult. What I'd love is a system like launchpad, but with a few key differences:

1. Optimised for the most common use-case. Launchpad does an awful lot of stuff that I have never used, and probably never will. All this functionality makes launchpad a very large beast indeed. I want a system that's compact and easy to use; I don't need translations, build recipes, mailing lists, bug tracking, etc. etc.

2. Easily installed on my own server. It is technically possible to install launchpad wherever you want, but it's difficult.

Enter my current open source project: sloecode. Sloecode is a simple wrapper around bazaar and a few other key technologies that makes it easy to set up multiple users & teams of developers. We're trying to optimise sloecode for the most common problems. What do we have so far?

• A simple web app (written in python & pylons) that allows one to create users, teams, and manage both.

• A bzr+ssh smart server that understands the accounts and teams created in the web-app.

• A client-side bzr plugin that allows users to use shortened repo URLs (similar to the lp:projectname scheme the launchpad plug-in provides).

Sloecode is still very much "work in progress" (we've got big plans), but it is usable right now. If you want more information, feel free to leave a comment below, or join the sloecode-dev mailing list on launchpad.

Visual Studio Fail

Perhaps this is a symptom of the underlying operating system, rather than the Visual Studio IDE. In either case it sucks:

I like to keep my files organised in folder hierarchies. Now I'm being forced to use a flat, wide folder tree by my IDE.

Not. Happy. At. All.

Virtualbox web front-end

I mentioned before that virtualbox rocks. Now it rocks even harder. I've always wanted to run multiple virtual machines on a powerful, headless server. Previously there hasn't been an adequate user interface (read: not a command line) that lets me manage multiple virtualbox instances.

Now there is.

...and my doesn't it look pretty?

Ubuntu One Madness

For those of you who have been living under a rock the last few months, Ubuntu One is:

...your personal cloud. But it's not just about syncing files — whether you need to access your contacts, notes or bookmarks from any computer or the web, enjoy your favorite music from a cloud integrated store or stream your entire collection to iPhone and Android mobile phones — we've raised the bar on personal clouds.

Clearly the marketing department at Canonical have been hard at work!

Unfortunately, the ubuntu one client has no support for any desktop environment other than Gnome. For a service that offers file synchronisation, having to launch a non-native client application makes the whole system rather useless. At first, this seems fair enough - a company with limited budget must allocate resources where they will do the most work. However, after a bit more digging, things seem to be in a rather poor state of affairs.

It's worth noting that the Kubuntu project is an official derivative of Ubuntu. It's listed as such on the Ubuntu derivatives page, you can purchase official canonical support for Kubuntu, purchase printed CDs through shipit, and the two projects use exactly the same software package repositories.

For a while there was light at the end of the tunnel: Harald Sitter started work on a KDE ubuntu one client. At one stage there were packages for it in a PPA, and people started using it. It even got a few independant web articles written about it. Then everything died. The PPA was removed, and development halted. Why? Harald commented on a bug report, and had this to say:

Well, Google Summer of Code is over.

And after having spent more than a week shaking a new graphical frontend for the now third version of authentication handling out my sleeve, I have learned but one thing. While you work on building something, something else will surely break in a way that will requrie half a work day to track down.
It is somewhat impossible to develop a KDE frontend while sitting outside of canonical and being in a completely different time zone than the Ubuntu One team.
On top of that I have seen crappy code design, crappy packaging, inexistance of cross-desktop awareness and cross-operatingsystem awareness and unavailability of a stable working target to develop against...

So I would put it as "I am giving up".

In the future I will devote time towards making ownCloud (a truely free "Cloud" implementation) more accessibile to the masses.

So what can we do? owncloud is not yet at a point where it can be used, and I cannot see any further development on an Ubuntu One client for KDE. Probably the most useful thing non-developers can do is to ask for clarification on the main bug report (politely please!), and make sure you click the "This bug affects me" link at the top of that page.

The real tragedy in all this isn't that there is no officially supported U1 client for KDE, or even that Canonical decided to support Windows and Mobile OSes before it's second-most popular operating system, it's that the upstream sources are (apparently) being built with no consideration to portability to other desktop environments. For a product with so many derivatives, you'd think this would be a required part of the development & planning process.