I went on a quest to find an awesome game for Ubuntu. It doesnt matter how much it costs I just want an awesome game. So there are some ones that most people know about Heroes of Newerth, Nexuiz, Warsow, OpenArena, Tremulous and a load of id software games.
So we have lots but most of the good ones are first person shooters. So what about massively multiplayer online games? On windows and mac they have Wow and we can run that on wine but it isnt exactly ideal. So I went looking for some good mmorpg games and i found two games that dont look bad Neverwinter Nights and Vendetta Online. Oh and if you count Heroes of Newerth we have 3 good online multiplayer fantasy games and lots of FPS games already available.
The problem is that there isnt enough people using linux yet to justify most companies making games for Linux but its great that id software and a few other nice companies accommodate us.
So what we need is for lucid+1(10.10) we get as many good games in the software center. So commercial or free, proprietary or free software lets make everything available. Lets have some fun
EDIT: I got neverwinter nights wrong its not a MMORPG, its just a RPG. Whoops :/

For the first time in several years, I had the opportunity to attend a software conference in the city where I lived at the time. I’ve benefited from many InfoQ articles in the past couple of years, and watched recordings of some excellent talks from previous QCon events, so I jumped at the opportunity to attend QCon London 2010. It is being held in the Queen Elizabeth II Conference Center, conveniently located a short walk away from Canonical’s London office.

Whenever I attend conferences, I can’t help taking note of which operating systems are in use, and this tells me something about the audience. I was surprised to notice that in addition to the expected Mac and Windows presence, there was a substantial Ubuntu contingent and some Fedora as well.

Today’s tracks included two of particular interest to me at the moment: Dev and Ops: A single team and the unfortunately gendered Software Craftsmanship.

Jason Gorman: Beyond Masters and Apprentices

A Scalable, Peer-led Model For Building Good Habits In Large & Diverse Development Teams

Jason explained the method he uses to coach software developers.
I got a bad seat on the left side of the auditorium, where it was hard to see the slides because they were blocked by the lectern, so I may have missed a few points.

He began by outlining some of the primary factors which make software more difficult to change over time:

• Readability: developers spend a lot of their time trying to understand code that they (or someone else) have written
• Complexity: as well as making code more difficult to understand, complexity increases the chance of errors. More complex code can fail in more ways.
• Duplication: when code is duplicated, it’s more difficult to change because we need to keep track of the copies and often change them all
• Dependencies and the “ripple effect”: highly interdependent code is more difficult to change, because a change in one place requires corresponding changes elsewhere
• Regression Test Assurance: I didn’t quite follow how this fit into the list, to be honest. Regression tests are supposed to make it easier to change the code, because errors can be caught more easily.

He then outlined the fundamental principles of his method:

• Focus on Learning over Teaching – a motivated learner will find their own way, so focus on enabling them to pull the lesson rather than pushing it to them (“there is a big difference between knowing how to do something and being able to do it”)
• Focus on Ability over Knowledge – learn by doing, and evaluate progress through practice as well (“how do you know when a juggler can juggle?”)

…and went on to outline the process from start to finish:

1. Orientation, where peers agree on good habits related to the subject being learned. The goal seemed to be to draw out knowledge from the group, allowing them to define their own school of thought with regard to how the work should be done. In other words, learn to do what they know, rather than trying to inject knowledge.
2. Practice programming, trying to exercise these habits and learn “the right way to do it”
3. Evaluation through peer review, where team members pair up and observe each other. Over the course of 40-60 hours, they watch each other program and check off where they are observed practicing the habits.
4. Assessment, where learners practice a time-boxed programming exercise, which is recorded. The focus is on methodical correctness, not speed of progress. Observers watch the recording (which only displays the code), and note instances where the habit was not practiced. The assessment is passed only if less than three errors are noticed.
5. Recognition, which comes through a certificate issued by the coach, but also through admission to a networking group on LinkedIn, promoting peer recognition

Jason noted that this method of assessing was good practice in itself, helping learners to practice pairing and observation in a rigorous way.

After the principal coach coaches a pilot group, the pilot group then goes on to coach others while they study the next stage of material.

To conclude, Jason gave us a live demo of the assessment technique, by launching Eclipse and writing a simple class using TDD live on the projector. The audience were provided with worksheets containing a list of the habits to observe, and instructed to note instances where he did not practice them.

Julian Simpson: Siloes are for farmers

Production deployments using all your team

After a brief introduction to the problems targeted by the devops approach, Julian offered some advice on how to do it right.

He began with the people issues, reminding us of Weinberg’s second law, which is “no matter what they tell you, it’s always a people problem”.

His people tips:

• In keeping with a recent trend, he criticized email as a severely flawed communication medium, best avoided.
• respect everyone
• have lunch with people on the other side of the wall
• discuss your problems with other groups (don’t just ask for a specific solution)
• invite everyone to stand-ups and retrospectives
• co-locate the sysadmins and developers (thomas allen)

Next, a few process suggestions:

• Avoid code ownership generally (or rather, promote joint/collective ownership)
• Pair developers with sysadmins
• It’s done when the code is in production (I would rephrase as: it’s not done until the code is in production)

and then tools:

• Teach your sysadmins to use version control
• Help your developers write performant code
• Help developers with managing their dev environment
• Run your deploy scripts via continuous integration (leading toward continuous deployment)
• Use Puppet or Chef (useful as a form of documentation as well as deployment tools, and on developer workstations as well as servers)
• Integrate monitoring and continuous integration (test monitoring in the development environment)
• Deliver code as OS packages (e.g. RPM, DEB)
• Separate binaries and configuration
• Harden systems immediately and enable logging for tuning security configuration (i.e. configure developer workstations with real security, making the development environment closer to production)
• Give developers access to production logs and data
• Re-create the developer environment often (to clear out accumulated cruft)

I agreed with a lot of what was said, objected to some, and lacked clarity on a few points. I think this kind of material is well suited to a multi-way BOF style discussion rather than a presentation format, and would have liked more opportunity for discussion.

Lars George and Fabrizio Schmidt: Social networks and the Richness of Data

Getting distributed webservices done with Nosql

Lars and Fabrizio described the general “social network problem”, and how they went about solving it. This problem space involves the processing, aggregation and dissemination of notifications for a very high volume of events, as commonly manifest in social networking websites such as Facebook and Twitter which connect people to each other to share updates. Apparently simple functionality, such as displaying the most recent updates from one’s “friends”, quickly become complex at scale.

As an example of the magnitude of the problem, he explained that they process 18 million events per day, and how in the course of storing and sharing these across the social graph, some operations peak as high as 150,000 per second. Such large and rapidly changing data sets represent a serious scaling challenge.

They originally built a monolithic, synchronous system called Phoenix, built on:

• LAMP frontends: Apache+PHP+APC (500 of them)
• Sharded MySQL multi-master databases (150 of them)
• memcache nodes with 1TB+ (60 of them)

They then added on asynchronous services alongside this, to handle things like Twitter and mobile devices, using Java (Tomcat) and RabbitMQ. The web frontend would send out AMQP messages, which would then be picked up by the asynchronous services, which would (where applicable) communicate back to Phoenix through an HTTP API call.

When the time came to re-architect their activity , they identified the following requirements:

• endless scalability
• storage- and cloud-independent
• fast
• flexible and extensible data model

This led them to an architecture based on:

• Nginx + Janitor
• Embedded Jetty + RESTeasy
• NoSQL storage backends (no fewer than three: Redis, Voldemort and Hazelcast)

They described this architecture in depth. The things which stood out for me were:

• They used different update strategies (push vs. pull) depending on the level of fan-out for the node (i.e. number of “friends”)
• They implemented a time-based activity filter which recorded a global timeline, from minutes out to days. Rather than traversing all of the user’s “friends” looking for events, they just scan the most recent events to see if their friends appear there.
• They created a distributed, scalable concurrent ID generator based on Hazelcast, which uses distributed locking to assign ranges to nodes, so that nodes can then quickly (locally) assign individual IDs
• It’s interesting how many of the off-the-shelf components had native scaling, replication, and sharding features. This sort of thing is effectively standard equipment now.

Their list of lessons learned:

• Start benchmarking and profiling your app early
• A fast and easy deployment keeps motivation high
• Configure Voldemort carefully (especially on large heap machines)
• Read the mailing lists of the NoSQL system you use
• No solution in docs? – read the sources
• At some point stop discussing and just do it

Andres Kitt: Building Skype

Learnings from almost five years as a Skype Architect

Andres began with an overview of Skype, which serves 800,000 registered users per employee (650 vs. 521 million). Their core team is based in Estonia. Their main functionality is peer-to-peer, but they do need substantial server infrastructure (PHP, C, C++, PostgreSQL) for things like peer-to-peer supporting glue, e-commerce and SIP integration. Skype uses PostgreSQL heavily in some interesting ways, in a complex multi-tiered architecture of databases and proxies.

His first lesson was that technical rules of thumb can lead us astray. It is always tempting to use patterns that have worked for us previously, in a different project, team or company, but they may not be right for another context. They can and should be used as a starting point for discussion, but not presumed to be the solution.

Second, he emphasized the importance of paying attention to functional architecture, not only technical architecture. As an example, he showed how the Skype web store, which sells only 4 products (skype in, skype out, voicemail, and subscription bundles of the previous three) became incredibly complex, because no one was responsible for this. Complex functional architecture leads to complex technical architecture, which is undesirable as he noted in his next point.

Keep it simple: minimize functionality, and minimize complexity. He gave an example of how their queuing system’s performance and scalability were greatly enhanced by removing functionality (the guarantee to deliver messages exactly once), which enabled the simplification of the system.

He also shared some organizational learnings, which I appreciated. Maybe my filters are playing tricks on me, but it seems as if more and more discussion of software engineering is focusing on organizing people. I interpret this as a sign of growing maturity in the industry, which (as Andres noted) has its roots in a somewhat asocial culture.

He noted that architecture needs to fit your organization. Design needs to be measured primarily by how well they solve business problems, rather than beauty or elegance.

He stressed the importance of communication, a term which I think is becoming so overused and diluted in organizations that it is not very useful. It’s used to refer to everything from roles and responsibilities, to personal relationships, to cultural norming, and more. In the case of Skype, what Andres learned was the importance of organizing and empowering people to facilitate alignment, information flow and understanding between different parts of the business. Skype evolved an architecture team which interfaces between (multiple) business units and (multiple) engineering teams, helping each to understand the other and taking responsibility for the overall system design.

Conclusion

Overall, I thought the day’s talks gave me new insight into how Internet applications are being developed and deployed in the real world today. They affirmed some of what I’ve been wondering about, and gave me some new things to think about as well. I’m looking forward to tomorrow.

I just finished reading Designing Social Interfaces. The book is written by the creators of the Yahoo! Pattern Library. I had no knowledge of any such pattern library previous to reading this book, but I've really been exploring the idea of creating user experiences on the web that will bring in users and keep them happy (and not confused). I think a lot of this interest has to do with Canonical's current focus on design and usability.

The book is an O'Reilly book, but once it's opened, it certainly doesn't feel like an O'Reilly book. The pages are slicker than normal O'Reilly books (and I own many of them). They're also in full color. This is great for a user experience design book, since it's often hard to look at screenshots of web sites when they're in black and white.

I soon realized that I was fascinated with the book itself. When it comes to web design, there are a few staples (Don't Make Me Think comes to mind), the books don't seem to be specific enough. They usually just show good examples, but they don't show the why of the good examples. Designing User Interfaces starts with the why, which is something I can really appreciate.

As a developer, I also have a tendency to think in "design patterns." By presenting the interfaces as "patterns," it was easy for me to start thinking up my own variations of those design patterns to work with my existing experiences and products. This is probably what sealed the fate of this book. It made me excited to re-design and re-think interfaces I've implemented (including Launchpad).

I would highly recommend this book for anyone doing front end work, whether it's just implementing existing designs or creating your own designs. I've noticed that I now critique web interfaces with an eye I didn't have before I read this book.

I've decided my old homepage was bad enough to revisit now that I've got a bit more content hosted deep within it. I replaced my crappy hand written HTML with tools written this decade, and threw in some amateur visual design.

The software

Firstly, in order to keep the webpage fresh with little effort, I've chosen RSS aggregation as the method of content generation. Since I know Ubuntu and Debian both use Planet, that's where I first looked. But it seems Planet 2.0 is aging, and the fork Planet Venus brings some neat new options. It expands the selection of templates, adds a configurable RSS filter step, and makes the normalization step configurable.

It's also packaged in Ubuntu as planet-venus, making it fairly simple to set up. Deployment was a little tricky, as the package leaves most of the site configuration to the admin. You'll need a config.ini (I used /etc/planet/planet.ini), a template dir (/usr/local/share/planet-venus/theme), a cache dir (/var/cache/planet) and an output dir (somewhere in /var/www typically). Finally, you'll need to set up a cron job to run the static output generation script regularly. The script reads all the feeds and parameters in config.ini, caches the results to save bandwidth on subsequent runs, passes them to the template engine, and places the final product in the output dir.

When building a lifestream style site, you have to be picky about the kinds of feeds you put in or it gets Facebook / Twitter style spammy. This is where the RSS filter step can help; Planet Venus comes with a few filters like 'notweets', and a few stripAds filters to cleanse ads before republishing. It's the same design pattern I talked about before here with Liferea. In the future I could write one to add in comment feeds and then filter out everything that fails to meet some strong quality criteria.

Output templates

Planet Venus's real selling point to me is using Django templates. I've been meaning to learn Django for a while now, and this is a pretty good way to work with the templates portion of Django. And again, the filter pattern pops up. Here, filters take python variables as input; in Planet Venus's setup you have access to feed and item variables, as well as planetwide settings. One example filter might be to simply pluralize a word based on a variable (yes, you can even handle 'y' pluralization). Another example is the urlize filter that adds HTML anchor tags to likely URLs (not so great when you already have anchor tags in the filter's input).

I also use templates to generate an RSS feed. Nothing difficult about it, since the input to templates is basically an RSS feed to begin with. To reduce the probability of bugs, I translated a provided example htmptmpl RSS template into Django, and it's much smaller and clearer to me. Unfortunately, there's a bug in Planet Venus that prevents the use of multiple Django templates. I've reported it upstream, and I'm sure I can fix it or work around it.

Web Design

I also decided to take a look at CSS layout frameworks, to get up to speed on the subject quickly. 960.gs is popular, but it's 960 pixel width assumption works poorly with quirky resolutions found on massive monitors and smartphones. Luckily, I found found fluid960, which is very similar, but implements fluid layouts. It retains the CSS class names of 960.gs, so tutorials and documentation on one translate fairly well to the other. Which is good, because fluid960 pretty much relies on you already knowing regular 960 (I didn't). This presentation gives a good summary of things you might want a CSS framework for, and this 960 tutorial covers what I needed to know.

Color scheming is probably the hardest part for me. It's simple to pick a color pallate that goes together, but there is a higher level opportunity to communicate something through visual design. I could choose a purple scheme to reflect my collegiate experience, or an Ubuntu pallete, but it seems inappropriate for a personal site. I've got a bit of low level coding experience, so I could go with a green on black terminal theme, but it's been done to death ever since the Matrix, and it's basically impossible to beat jwz's version.

Since I'm not really looking to break into web design, I went with a relatively muted color scheme that organizes the content without distracting from it. Truthfully it doesn't matter all that much, as experience shows the majority of hits will come via RSS.

Well, that's basically all there is to my automated homepage system. On to more important things, like setting up a calDAV server or a feed processing tool.

I realize the openssl s_client tool tries to be upper-layer protocol agnostic, but doesn’t everything that uses SSL do commonName checking (HTTP, SMTP, IMAP, FTP, POP, XMPP)? Shouldn’t this be something openssl s_client does by default, maybe with an option to turn it off for less common situations?

Here it doesn’t complain about connecting to “outflux.net” when the cert has a CN for “www.outflux.net”:

echo QUIT | openssl s_client -CApath /etc/ssl/certs \
  -connect outflux.net:443 2>/dev/null | egrep "subject=|Verify"

subject=/CN=www.outflux.net
    Verify return code: 0 (ok)

This is awkward.   We need to talk.

March 3rd was a strange day. It was one day before User Interface freeze for the upcoming Ubuntu Lucid long term support release.   By the end of the day we were supposed to have the entire look and feel of the desktop settled on so people could start writing documentation and books.

This was the same day that Canonical finally released the new theme that had been under secretive development.   It was bold, daring, light-inspired, and perhaps most popularly, not brown.   Jono Bacon, Canonical’s community manager, broke the news.   Mark Shuttleworth followed up on his own blog, thanking three members of the design team for leading the effort.

The most important change, however, wasn’t actually talked about.   The designers don’t blog themselves, and Mark and Jono didn’t mention it directly.   It had to be found in the screenshots, or experienced firsthand by alpha testers.

This is not ok

Soon, the community learned the change was intentional: a bug about the misplaced window controls was quickly marked invalid,   and when the controls briefly reappeared on the right again the change was reverted.   What’s disturbing is that Planet Ubuntu has been rather silent on the topic.   No one’s posted a real defense of this change yet, or for that matter even claimed responsibility. It’s like there’s this collective unease about criticizing something that feels like it came directly from on high.   So, instead, people are just silent.   I’d certainly be if I worked for Canonical.   Perhaps I should be, as I still hope to work for them.

If you read between the lines, you can tell that people aren’t too happy about it.   The most flattering thing a developer’s said about the left-sided Window controls is that they “got used to them after a few days”.   We’re quick to praise the theme (it’s gorgeous), but talking about this major sudden change to the window controls feels like taboo.   That’s incredibly unhealthy for a community project.   It’s like there’s this collective unease and everyone’s worrying if we’re about to release something embarrassing.

This experiment was a failure and we need to realize it

The alpha releases are great places for usability experiments.   Sometimes, they don’t work out.   Put a new user on today’s Ubuntu Lucid and they’ll think it’s fantastic, sleek, and absolutely gorgeous right up to the point where they have to close a window.   That’s where our first impression becomes something awful.

Note: The new card backs pictured above are my doing and are now default (Mads Rosendahl drew them).

A brief summary of the complaints about  the left side window controls

Some of these I noticed myself, a few are gathered from various comment threads on forums and blogs over the past week.

• Because the window title isn’t centered, the window controls being placed directly in front of it put it in a weird indented position
• The “slightly off left” location is inconsistent with Nautilus, Firefox, Thunderbird, Pidgin, Empathy, and every other tabbed program we have, which have close buttons for their tabs on the right.
• The left position is inconsistent with Windows, previous versions of Ubuntu, and even OSX – users have to relearn decades of muscle memory.
• Users who interact with both Windows and Ubuntu machines (or migrate from Windows) will have a much harder time than they did before.
• The buttons are too close to the file and edit menus, making catastrophic misclicks much more likely.   Closing something on accident should be as rare as possible.
• Even without misclicking, a user will have to take more time to use the window control and avoid a misclick.   This is an example of Fitt’s Law.
• The close position is also inconsistent with the power button in upper right.   Currently, “close it down” is something you can always do from the upper right anywhere in the system: within a tab, within a window, and even for the whole computer.   The new window controls break that entirely.
• The new position leaves a lot of empty, wasted space in the upper right of most windows.   While strictly speaking the amount of unused space is the same, it looks much worse when it’s all clustered together.   When the controls are on the right, the extra space can function as a buffer for the potentially destructive window controls.
• Similarly, the upper left of most windows now becomes much more crowded, creating a rather unpleasing contrast to the relatively empty upper right.
• In previous Ubuntus you could close windows on the left if you really wanted, by expanding the small circle menu that’s now gone entirely.   File->Quit is also an option, which is now very close to the close box.
• Gnome upstream has them on the right, causing consistency and developmental problems when we deviate.   This is particularly jarring with the adoption of future projects like Gnome shell and Gnome 3, which will change again how we interact with window controls.
• The current implementation breaks themes not designed for the new button order (which is currently every theme we ship, so even changing the theme back doesn’t help)
• A day before User Interface freeze of a long term support release is the worst possible time to suddenly spring this on everyone without explanation.
• It is very difficult to change them back as we don’t have any UI tool for doing this (the current method is manually editing gconf keys)
• The new position doesn’t actually do anything beneficial.

That last point is the most important.   Other than “looking different” the change doesn’t do anything helpful.   It’s a huge usability loss for an awful lot of people.   Some people get used to it quickly.   Others don’t, and like me end up getting physically angry when trying to use their computer.   I can’t remember ever having my computer make me feel this way for a long time, and I’ve been running Ubuntu alphas for five years now.

Let’s admit we have a problem

Ivanka deserves credit for being the first member of the design team to  at least talk about the controls:

Are we smoking crack to think that the learning curve or getting used to a new position is ever going to be worth any real or perceived benefit of new positions?

I’ll leave that question to the reader.

The Ubuntu Learning project has been quietly working away for the past six months, most of what we’ve been working on has been the technology to invite new contributors into the mix and get materials published, the plan for what we’re going to write and how to focus in on just a handful of topics so we can really get down to writing.

So you’ve probably read about the technology, GroundControl is a learning project tech. It’s built to allow writers to contribute their knowledge with minimum of fuss. The GroundControl project is suffering a little bit of a delay from changes in launchpad, but a lot of this is because the technology was before it’s time and launchpad and the ubuntu desktop need to be made more talkative before GroundControl and many other launchpad apps will really work nicely with launchpad.

The creation of the build functionality is all there, you just write a bunch of text files and hit go and it compiles your course into a nice book, with side book for lesson plan. There is more work that could be done on the GUI for hitting go, but that’s a nice to have.

The moodle website is pretty much functionally done and we can add classes when ever we like. There is a major need for a theme to be developed, something cleaner than the standard moodle installed theme with our own branding etc. But that’s on our todo list.

I’ve set up a physical systems administration class again for April onwards, this means I’ve taken control of the systems administration course and will be developing it further as the class proceeds. Nigel is still progressing with the teaching track and Elizabeth is collecting information on the Desktop track, hopefully there is plenty of room for collaboration with the Ubuntu Manual project there.

We’ve got a team meeting coming up on Monday 15th 23:00 UTC and we’re a year into our project here so we’ve going to be looking at a way to organise ourselves better. This might include some leadership reorganisation and it’s probably going to involve discussion in how we can get more people involved.

If you feel like learning materials and teaching FOSS topics is very important to the progress to world domination as we do; then please do join us at our meeting and tell us how you think learning materials should be produced and published. We’re looking forward to seeing everyone there.

Found these if you’re looking for a Chrome/Chromium theme to match Lucid:

• Theme
• Scrollbar

I had to turn on the system titlebars to make it fit the desktop which I have to get used to since I have grown accustomed to the melded tab/titlebar. Enjoy, and thanks to tobiash for making these!

I saw the Translations of package descriptions video from FOSDEM 2010. Every distribution has two translatable string for each package: a synopsis (summary, short description) and a long description. These descriptions differ from distribution to distribution. The descriptions should be shared between the distributions. This will enable us to share the translations of the descriptions.

My idea: Why not letting upstream provide the package description and the translation for it? They should have the knowledge to provide a good description and to update it if required. To encourage upstream to provide the description, we should create a freedesktop specification for it. Quick draft: The tarball should contain a file named package.info. The package.info file should contain three RFC-2822-like fields for each package: Package, Synopsis, and Description. Translation can be stored in package.info.<language> (for example package.info.de).

Example package.info:

Package: audacity
Synopsis: A fast, cross-platform audio editor
Description: Audacity is a multi-track audio editor for Linux/Unix,
 MacOS and Windows. It is designed for easy recording, playing
 and editing of digital audio. Audacity features digital effects and
 spectrum analysis tools. Editing is very fast and provides unlimited
 undo/redo.
 .
 Supported file formats include Ogg Vorbis, MP2, MP3, WAV, AIFF, and AU.

What do you think about this idea?

Edit: Alexandre Franke found an existing markup language designed for our use case: Description of a Project (DOAP). Package is name there, synopsis is shortdesc, and description is description. Here is my example in DOAP:

<Project xmlns="http://usefulinc.com/ns/doap#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <name>Audacity</name>
  <shortdesc xml:lang="en">
    A fast, cross-platform audio editor
  </shortdesc>
  <description xml:lang="en">
    Audacity is a multi-track audio editor for Linux/Unix,
    MacOS and Windows. It is designed for easy recording, playing
    and editing of digital audio. Audacity features digital effects and
    spectrum analysis tools. Editing is very fast and provides unlimited
    undo/redo.
    Supported file formats include Ogg Vorbis, MP2, MP3, WAV, AIFF, and AU.
  </description>
</Project>