It's about time I posted my Kiwi PyCon talk from last August! I spent an enjoyable 30 minutes talking about what Sloecode is, how we built it, and the problems encountered along the way. As per my usual approach to public speaking, I tried to keep things light-hearted and entertaining. Anyway, the slides and audio are available here:
KiwiPyCon Sloecode Talk
Dear Journalists: Bits and Bytes
Dear Journalist type person,
There's something we must discuss. You see, you've been making a very basic mistake in many of your articles when it comes to writing about the Internet, and specifically Internet speeds. Let's take a look at a small quote:
...unless you have an internet connection of impossible speeds. (Mine is nominally 10MB, by the way, which in practice means maximum download speeds of 1.4 megabytes per second).(source: Rock-Paper-Shotgun).
Can you spot the problem here? Internet speeds are measured in megabits per second. The symbol for 'bits' is a lower-case 'b', so an Internet connection that's 10 Megabits per second could be written as "10 Mbps". I guess if you're feeling lazy you could leave off the "ps", and end up with "10 Mb" (although it's a really sloppy thing to do), but NEVER "10 MB" - that means something else entirely.
Modern PCs use bytes that contain 8 bits. The correct symbol for a byte is an upper-case 'B'. so "10 MB" means "ten mega-bytes", not mega-bits, which is probably what you meant when you were describing the speed of your Internet connection.
If your eyes glazed over, or perheps you felt light-headed reading that, here are a few take-home points to make it easier for you:
- Connection speeds are measured in megabits-per-second. The correct unit symbol for this is "Mbps".
- Files are measured in Megabytes.
- A Byte has 8 bits. So to turn your connection speed into something useful, divide the number by 8 and make the unit symbol "MBps".
Kind Regards,
KiwiPyCon 2012 will be in Dunedin
It is a great honour and privilege to be involved in bringing the New Zealand Python developers conference (KiwiPyCon) to Dunedin in 2012. I intend to blog regularly with details of next year's conference as they emerge, so watch this space for more information over time!
Finally, a huge "Thank You" to Tim McNamara for organising the best KiwiPyCon to date. I have a huge task ahead of me, and he's raised the bar very high indeed.
Have any good ideas for next year? Please let us know!
Sloecode 1.1 - get your bugreports in now!
I'm at KiwiPyCon in Wellington, New Zealand. It turns out, being surrounded by geeks is great inspiration & motivation. Because of this, I've created a Sloecode 1.1 milestone in launchpad. If you have any bugreports or feature reuests, now's the time to get them in!
...I can't believe I'm asking people for bug-reports. This feels wrong...
Sloecode: now with 100% more website
Sloecode now has a real website! It's a rather minimalist affair at present, but it's better than nothing!
Since I last blogged, the setup instructions for the Sloecode server have changed a lot. The new instructions are available on the new site.
Representin' the home-boys!
That's *exactly* the kind of blog title that's liable to get me in trouble down the road. Faux street swagger doesn't age well.
In other news, I'm presenting a talk at this years NZ Python conference KiwiPyCon. Their website does not have the schedule visible yet, but there is a list of talks available.
I'm looking forward to meeting other python developers, and maybe getting some help with Sloecode!
Unity Workarounds
I'm currently running the unity desktop shell on my development computer. I got fed up with KDE's lack of support, and the gnome-shell just annoyed me. Unity seems like a good start, but suffers from several problems. I've found workarounds for all of these, and thought I'd post them below.
Scrollbar Corruption:
One of the major changes in unity is the thin scrollbars (technically called "overlay scrollbars", I believe), which are enabled by default for all GTK applications. This is what I'm talking about (image from techgarage.com):
The problem can be avoided by turning the thin scrollbars off. How do you do that? Easy - launch the application with the "LIBOVERLAY_SCROLLBAR" environment variable set to 0, like this:
Panel Corruption:
Whenever I change a setting in the compiz config settings manager (ccsm), the top panel of my unity desktop becomes corrupted. Previously the only way to fix this was to log out and log back in again (effectively restarting unity). Here's a screenshot of the problem:
Solution:
When this happens you can restart unity without having to logout, or close any applications. Simply run (either by pressing Alt+F2, or in a terminal):
unity --replace
CAPTCHA Fail
I can understand the need to filter humans from machines on the Internet, but we need to do a much better job. It seems like the most common captcha software I run into these days is reCAPTCHA. The system has some noble goals - specifically, users who submit captchas are actually helping digitize books. However, here's the problem:
What the hell does that say? The first word is obviously "the", the second? "Claccupr?". Perhaps I have bad eyesight, but I often get these wrong. Here's an alternative proposal:Instead of asking humans to perform text recognition (something computers can already do reasonably well), ask them to do something that comes naturally to humans, but not to computers. How about asking the user to pick which image they might find at a beach. Or ask the user to pick the image that represents the largest object in real life. Use context that humans understand instinctively, but computers do not.
Any ideas? Someone should build it!
Any ideas? Someone should build it!
Sloecode: Now with Ubuntu Packages!
What is Sloecode?
Sloecode is an open source project, hosted on launchpad.net that aims to provide a comprehensive, installable code forge. A "code forge" is a set of tools that help groups of people write software (think sourceforge, launchpad etc). It typically includes a revision control system, and optionally project wikis, bug tracking, issue tracking, feature planning and any other features people might need. However, it's important to note that we're not trying to replicate Launchpad! Launchpad is a great service, and we don't want to compete with it. Instead, we're providing a tool for people who:
- Don't want their code to be public - either because it's commercial software or because it's not ready yet. You can use sloecode in your business, college, university without having to release your software to the wider world. You can do this on launchpad, but you must pay for the privilege. The project was borne out of the need to have a code forge for an educational environment: putting students' work online is not an option.
- Want their code forge system to be hosted locally. For large code bases, the communication times between a local machine and the central launchpad.net servers can become expensive - especially in locations where the Internet connection is poor. Running sloecode is easy (as we'll see soon) and gives you complete control over the system. You're are responsible for server maintenance, backup, and general administration.
Compared to Launchpad, we're aiming for a completely different user base.
How does it Work?
Sloecode is made up of two distinct parts:
The Bazaar/SSh smart server is a python-twisted application that understands the SSH protocol, and runs bzr-serve on demand for users. Every time you interact with the server using a Bazaar client application you're actually talking to the smart server. We need this component for several reasons: first, we don't want users to require a system account on the Linux server (which is the usual way of setting up a Bazaar server), but we do still want to use SSH public/private key authentication. This means the SSH server needs to know about our database and be able to retrieve keys from it on demand.
The Sloecode Web App is the front-end for the whole system. It's written in pylons, and makes use of a whole host of other libraries including jinja2 (page templates), formencode (input validation), YUI3 (javascript components), repoze.what and repoze.who (authorisation and authentication), and a whole lot more. The web-app provides control for managers and administrators to create projects and users and assign users to projects (with different levels of access). Regular users can see basic information about their bazaar branches (both personal repositories and project repositories), and manage their SSH keys.
The plan for the future is to add optional components - the key word being optional. One of our design goals is to make sloecode easy to install; this includes minimising install-time dependancies.
The key thing to understand about Sloecode is that we're not writing the VCS ourselves - we're simply making Bazaar easier to install and manage.
Enough already, give me the server!
Sloecode has not yet been released, but you are welcome to participate in testing. To set up the server, you'll first need the sloecode PPA in your sources.list. To achieve this, run the following command:
Then update your package lists:
You can now install the sloecode server package:
The server package should install all the package dependancies. However, before you can run the server, you need to set up the database back-end. The default back-end us sqlite, which is fine for testing or for very low-use installations. Sloecode uses sqlalchemy, which allows us to use any number of databse backends. This, and many other configuration details can be edited by tweaking this file:
Once you're happy with the settings, you need to create the database tables. Do this by running:
This command will read the values present in the configuration file, and create the default database tables for you. You only need to run this command once (to create the tables in your database)!
If you have edited any of the other values, you will want to restart the server:
By default, log files are in /var/log/sloecode, Bazaar repositories are created in
and the default database is a simple SQLite file (which won't handle any kind of heavy workload or concurrency, so you may wish to change that). The RSA public/private key pair the smart server uses to communicate with clients are stored in
And the clients?
Client setup is much simpler. Simply follow these steps:
That's it! Everything is all set up. Now you can start using the sloecode server.
Bazaar / Sloecode Basics
I won't cover the details of how to use Bazaar. If you need that instruction, look at the official Bazaar documentation. However, here are a few pointers:
The Sloecode Web App is the front-end for the whole system. It's written in pylons, and makes use of a whole host of other libraries including jinja2 (page templates), formencode (input validation), YUI3 (javascript components), repoze.what and repoze.who (authorisation and authentication), and a whole lot more. The web-app provides control for managers and administrators to create projects and users and assign users to projects (with different levels of access). Regular users can see basic information about their bazaar branches (both personal repositories and project repositories), and manage their SSH keys.
The plan for the future is to add optional components - the key word being optional. One of our design goals is to make sloecode easy to install; this includes minimising install-time dependancies.
The key thing to understand about Sloecode is that we're not writing the VCS ourselves - we're simply making Bazaar easier to install and manage.
Enough already, give me the server!
Sloecode has not yet been released, but you are welcome to participate in testing. To set up the server, you'll first need the sloecode PPA in your sources.list. To achieve this, run the following command:
sudo add-apt-repository ppa:sloecode
Then update your package lists:
sudo apt-get update
You can now install the sloecode server package:
sudo apt-get install sloecode
The server package should install all the package dependancies. However, before you can run the server, you need to set up the database back-end. The default back-end us sqlite, which is fine for testing or for very low-use installations. Sloecode uses sqlalchemy, which allows us to use any number of databse backends. This, and many other configuration details can be edited by tweaking this file:
/etc/default/sloecode-production.ini
Once you're happy with the settings, you need to create the database tables. Do this by running:
sudo paster setup-app /etc/default/sloecode-production.ini
This command will read the values present in the configuration file, and create the default database tables for you. You only need to run this command once (to create the tables in your database)!
If you have edited any of the other values, you will want to restart the server:
sudo service sloecode restart
By default, log files are in /var/log/sloecode, Bazaar repositories are created in
/srv/sloecode/bzr-repos
and the default database is a simple SQLite file (which won't handle any kind of heavy workload or concurrency, so you may wish to change that). The RSA public/private key pair the smart server uses to communicate with clients are stored in
/var/sloecode/keys
And the clients?
Client setup is much simpler. Simply follow these steps:
- Make sure you have an account created for you in the sloecode web interface. Log in to the web interface with your username and password.
- Click on the "Manage SSH Keys" link on your home page. You need to paste your SSH public key in the form provided. This allows your Bazaar client to authenticate with the sloecode server. If you don't have an SSH key, you can generate one by running:
ssh-keygen
and view the public key by running:
cat ~/.ssh/id_rsa.pub
- All client machines need the 'bzr' and 'bzr-sloecode' packages installed. Assuming you have the sloecode PPA installed (see instructions for doing this in the server section, above), you can run:
sudo apt-get install bzr bzr-sloecode
- Finally, you need to tell the Bazaar sloecode plugin where the sloecode server is. The client plugin looks for an environment variable called "SLOECODE_SERVER", and will complain if it is not found. The easiest way to set this environment variable is to edit your "~/.bashrc" file and add this line to the end:
export SLOECODE_SERVER=domain.of.your.server.com
The value of this variable should be either a domain name, OR an IP address that points to the sloecode server you wish to use. For example, if the server is installed on the local network you might have the following:
export SLOECODE_SERVER=192.168.1.10
Note that you must not add any network protocol specification - the sloecode client plugin takes care of that for you. If you are running the sloecode ssh service on a port other than 22, you must add this port to the end of the string, like so:
export SLOECODE_SERVER=192.168.1.10:4022
- Finally, if your username on the sloecode server is different from your local computer username, you need to tell the Bazaar sloecode plugin what username it should use. To do this, run the command:
bzr sc-login sloecode_username
Where "sloecode_username" is the username you use to log in to the sloecode web interface. For example, on my machine the command is:
bzr sc-login thomir
If you run the command without a username it will tell you what username is currently set.
That's it! Everything is all set up. Now you can start using the sloecode server.
Bazaar / Sloecode Basics
I won't cover the details of how to use Bazaar. If you need that instruction, look at the official Bazaar documentation. However, here are a few pointers:
- Every user on the sloecode server has a personal repository. To push code to your personal repository, do this:
bzr push sc:~sloecode_username/branch_name
By default personal repositories are created with no branches, so whenever you push or pull from a personal repository you must always specify a branch name!
- Personal repositories are private - you are the only one who can read or write to your personal repository. If you need to share your code with someone else, you need to store it in a project repository.
- To pull code from a project repository, the command looks like this:
bzr pull sc:project_name/branch_name
Note that there is no tilde character before the project name. Also note that you need not specify the branch name if you want the special branch called "trunk". For example, if I want a copy of the trunk branch of project "elastic", I'd run the following command:
bzr pull sc:elastic
However if I want a specific branch called "fix-bug-1234", I'd run the following:
bzr pull sc:elastic/fix-bug-1234
Final Thoughts:
We're still writing sloecode - it's an ongoing effort and won't be finished any time soon. We welcome your feedback - the best way to contact is us via the sloecode-developers mailing list, or in the #sloecode channel on freenode IRC, or leave a comment below. Have we missed anything? Spot any bugs? Have suggestions for improvements/future direction? We'd love to hear from you!
We're still writing sloecode - it's an ongoing effort and won't be finished any time soon. We welcome your feedback - the best way to contact is us via the sloecode-developers mailing list, or in the #sloecode channel on freenode IRC, or leave a comment below. Have we missed anything? Spot any bugs? Have suggestions for improvements/future direction? We'd love to hear from you!
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:
- 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:
- Installs the plugin to the right place.
- Sets the SLOECODE_SERVER environment variable to whatever you want.
- It doesn't check that Bazaar is installed first.
- 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.
- No validation on the Bazaar server address.
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:
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:
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.
Easily installed on my own server. It is technically possible to install launchpad wherever you want, but it's difficult.
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).
Visual Studio Fail
Perhaps this is a symptom of the underlying operating system, rather than the Visual Studio IDE. In either case it sucks:
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.
Console Hacking
Several news outlets are reporting that the PS3 has been compromised. What strikes me as odd is that most of the time, the people doing the hacking have no interest in piracy (at least, that's their claim). Instead, their motives seem to be towards allowing home-brew app creation. This is a noble goal, and one that will surely become more and more popular, as we start moving away from passive entertainment towards a more participatory model.
My question is this: Why do console manufacturers still struggle to prevent home-brew projects? The time spent trying to prevent these sorts of exploits must be incredible, and so far, none of them have succeeded.
Personally, I'd love a console that allowed me to run whatever code I want on it - imagine the uses! MythTV running on an XBox? Awesome!
Subscribe to:
Posts (Atom)
Posts
View Thomi Richards's profile