May 19, 2010
community, freesoftware, gnome, guadec, maemo, work
2 Comments
I’m delighted to announce the availability of GNOME Developer Training at GUADEC this year. It’s been brewing for a while, but you can now register for the training sessions on the GUADEC website.
Fernando Herrera, Claudio Saavedra, Alberto Garcia and myself will be running the two-day course, covering the basics of a Linux development environment and developer tools, the GNOME stack, including freedesktop.org components, and the social aspects of working with a free software project, being a good community citizen, getting your code upstream, and gaining influence in projects you work with.
The developer tools section will go beyond getting you compiling the software to also present mobile development environments, and the tools you can use to profile your apps, or diagnose I/O or memory issues, dealing with the vast majority of performance issues developers encounter.
This is the first time I have seen a training course which treats the soft science of working with free software communities, and given the number of times that people working in companies have told me that they need help in this area, I believe that this is satisfying a real need.
We are keeping the numbers down to ensure that the highest quality training & individual attention is provided – only 20 places are available. The pricing for the training course is very competitive for this type of course – €1500 per person, including training, meals and printed training materials, and a professional registration to GUADEC, worth €250.
If you register before June 15th, you can even get an additional discount – the early bird registration price is only €1200 per person.
I’m really excited about this, and I hope others will be too. This is the first time that we will have done training like this in conjunction with GUADEC, and I really hope that this will bring some new developers to the conference for the week, as well as being a valuable addition to the GUADEC event.
May 4, 2010
work
10 Comments
During my recent adventures in San Francisco, I told a number of people about my jet-lag “cure”, and they found it sufficiently interesting I thought I would share.
On trans-Atlantic flights, you typically take off late morning and arrive early afternoon when traveling East to West, or you take off in the afternoon & land in the early morning when traveling West to East. There are two steps to dealing with major (>= 6 hours time-zone difference) jet-lag: what you do in the plane, and what you do when you arrive.
For me, when I’m traveling East to West, I don’t sleep much on the plane. I watch movies, get up & walk around, chat to the other people hanging around outside the toilets, read – whatever helps pass the time. This means that when I arrive at my destination, I’m tired – my body thinks that it’s late night and I’ve been awake all day. But in reality, it’s 2pm.
By the time you get out of the airport, get to your hotel and check in, it’s probably between 2pm and 4pm. If you go to sleep now, the chances are that you will sleep for several hours, then go out to eat a late dinner, and have difficulty getting to sleep for the night, resulting in tiredness early the following day. This is the vicious circle of jet-lag.
To break the cycle, here’s where my cure kicks in: get out of your hotel. Your body uses sunlight to set its biological clock, so by getting out in the daylight, you are helping your body to adjust to the new day and night pattern. Getting outside during the day suppresses the natural production of melatonin, which helps put you to sleep. It also stimulates the production of vitamin D, helping combat illness (another consequence of jet-lag).
The absolute best way to get out and get over jet-lag is to get some exercise. Go on a cycling tour of the city, or go running. Exercise stimulates the production of endorphines, making you feel good, and more importantly, after exercise you typically do not want to go to sleep. And a few hours later, when you do go to sleep, you sleep more soundly.
If you do an hour or two of outdoor exercise after arriving at your destination, then go back to your hotel and shower/bathe, go out for a bite around 7pm, and then get to bed at an early but reasonable 10pm, you should be able to have a good night’s sleep, and function all day the day after. I typically wake up very early the first couple of mornings when I travel to the States – which gives me an opportunity to (you guessed it) go for an early morning jog before getting ready to go where I have to be.
When traveling from West to East, the problem is similar, but the lag is in the other direction – you may have a hard time waking your brain in the morning when you travel 6 or more hours back in time.
The same trick works. Avoid excessive sleep in the plane – a couple of hours nap is about all I ever manage overnight on these flights. When you arrive, get outside and moving about for the afternoon. I love to go with the kids to the park when I come back from trips and run them (and myself) ragged with a football, or go for a walk with the family – anything to get us out of the house. To help me get to sleep, as well as skipping most of the previous night in the plane, I take a melatonin pill (purchased in Safeways while in the US, not on sale in Europe for some reason) to help me to get to sleep at the right time. And the following morning, when I have the most difficulty waking up my brain, I force myself with difficulty to put on a pair of trainers and go for a 45 minute jog.
And that’s all there is to it! Typically, the day I arrive I suffer, the day after I can function, but am not 100%, and the the day after that, I am fully adjusted to my new time zone.
Does anyone have any other hints & tips to overcome jet-lag? Comments open!
May 3, 2010
community, freesoftware, maemo
11 Comments
While I’ve occasionally been critical of Ubuntu as a project, it is a distribution with very open processes, for the most part.
I’d like to compare the experience of a casual Ubuntu user, an engaged Ubuntu user, an Ubuntu developer, and an upstream application developer to the equivalent MeeGo or Maemo experiences.
The casual Ubuntu user gets regular stable updates on a predictable schedule, with long-term supported versions less frequently, but still on a predictable schedule. Stability, releases, this user doesn’t want to know what happens behind the scene, he wants to get software when it’s “done”.
The engaged Ubuntu user can activate an unstable development distribution, and see the work going in as it’s being done! He updates daily, gets the latest and greatest, and occasionally stuff doesn’t work, but he doesn’t mind. The information how to do this isn’t on page one of ubuntu.com, but it’s there, and engaged users tell each other about it.
The Ubuntu developer can participate in the creation of the process by packaging his favourite software, pushing it through a public (although occasionally real-time & in-person) process for inclusion in the holy grail – default installation, or presence on the install CD. He can take care of packaging, shepherd the package through QA, ensure that problems get reported upstream and in general ensure that his package is a good Ubuntu citizen. Even if he doesn’t get the package in the default install, which is quite tough, he can follow public community processes to have it available in the Universe, available to every single Ubuntu user through a simple search of available applications.
The upstream developer doesn’t really care that much about Ubuntu. He develops his application, sees bug reports coming in from users & developers & downstream packagers. He adds features, and concentrates on what he loves best – coding the best app he can.
Now, compare that experience to Maemo, to see how we compare:
For the casual user, not much changes. He gets the software on a device, when it’s “done” (and the definition of done is considerably different for a phone than a PC distribution).
For the engaged user, who wants to follow the bleeding edge, the story gets murkier. In the Maemo world, hardware and software releases have been closely related. Without a Beagleboard or a prototype N900, Fremantle wouldn’t have been very useful. But even operating system updates like the upcoming long awaited PR1.2 are not packaged and prepared in public, so even existing N900 owners can’t follow along with the cutting edge.
There is a promise that the first release of MeeGo will work well on the N900, so potentially there is an opportunity for the engaged MeeGo user to follow along with unstable development – on condition that, like the engaged Ubuntu developer, they’re prepared for the occasional bricking & reflash. But the UX software for MeeGo is being prepared for release – we are told that some closed components are being opened, some others are not ready for release yet. So it is not (yet) possible for an engaged MeeGo or Maemo user to follow along & install a base alpha or beta distribution and update or reflash regularly.
For packagers who would like to propose their software for inclusion in the default repository, or even on the default install, of MeeGo or Maemo, there is not (yet) a clear path to get involved in the process. I could start working on a Maemo port of QuteCom, Shotwell or some other software, but if I did, there’s no way for me to get that software included by default. The current Extras/Extras-testing policy of Maemo has been heavily criticised by some developers – so it might not even be easy for me to make my software available to a large number of Maemo issues.
The upstream developer experience doesn’t change that much. Upstream developers still shouldn’t care about what packagers are doing, and should be concentrating on making the best apps possible. But for major parts of the MeeGo platform, namely the UX projects, the upstream and downstream will be hard to separate. As an upstream developer, I care about being able to follow commits, read Changelogs, do code review, develop and propose features, fix bugs and so on, in the open. For unrelated upstream projects, things also change – due to form factor and UX guidelines, the developer really needs to do a tailor-made UI for MeeGo or Maemo, requiring effort not being spent on features. And because you’re doing embedded development, your development environment becomes that much more complicated, with emulators and cross compilers and SDKs.
The embedded world is a special place, a lot of things change from desktop development, and some of those changes come with the territory. You’re going to have to work with a device emulator, and anything that requires a SIM card, the GPS, camera, accelerometer or any other hardware features, well, you’re going to have to wait for a device to make 100% sure those work. But we can certainly bear in mind the Ubuntu user experience(s) when we are designing the MeeGo community, and ensure that their experience is just as open.
That means open code, and more importantly open processes. It means an engaged user being able to use software that isn’t ready, a packager being able to propose software for inclusion in the OS and ensure its availability to all users of the distribution by following a well defined process, and a developer having a great experience helping to develop great applications.
