Danielle's technical stuffs
Tammy Butow is putting together a montage of Australian women in tech for the Go Girls event, because role models are important.
If you’re an Australian tech lady, submit your picture (remember to make it landscape, which I forgot the first time).
Here’s my self portrait (hooray for camera remotes):
Apparently I’ve had a github account for ages, and never used it. Recently I’ve been using github a for some work I’ve been doing with Intel at Collabora.
Anyway, I thought it might be neat to move some of my random personal projects and misc that were stored on git.collabora.co.uk to github.
I picked up my saxophone for the first time in a while last night and went along to a big band rehearsal. Very quickly discovered that I’ve forgotten most of my scales and that I need to do some practice.
Realised I didn’t feel like writing eight scales out in nine keys, and there had to be a better way, so I played around for a bit with lilypond and then hacked together a bit of Python to help generate my scales.
Anyway, I thought this was pretty neat, and possibly useful to others, so I’ve shoved it on github.
I rebooted the other day, which got me a new kernel (3.2.9 ((I think I was running 3.2.1 before, which got uninstalled. Fedora helpfully left 3.2.6 and 3.2.7, neither of which I think I ever booted into.))), and now it seems my wireless (rtl8192ce) has become really flaky and unstable. At first I thought it was the router playing up, but everything else in the house works fine (everything else in the house is made by Apple it seems).
Typically it fails to associate until you reboot the router (which is why I thought it might be the router) or occasionally the laptop. When it is connected performance is occasionally crappy. I’m totally out of my depth debugging this. I poked around a bit but found nothing meaningful.
Help appreciated!
Since it’s annoyingly hard to work out what muxer to use for m4a files, and I don’t have a profile for encodebin, here’s the gst-launch command to make m4a or m4r (ringtone) files.
gst-launch filesrc location=input.file ! decodebin2 ! audioconvert ! faac ! ffmux_mp4 ! filesink location=output.m4a
This is a neat trick, and so I thought worth reblogging. I was handed a corrupt SD memory card yesterday and asked if I could try and get some Christmas photos off it.
Typically, the first thing I did was image the card with ddrescue (package gddrescue in Debian/Ubuntu), confirming that the partition table was intact, it looks like the problem was a corrupted FAT, so I wanted to run fsck on the partition.
Back in the day this would have involved either dd-ing the partition out of the image, or re-imaging the card, both slow, or screwing around with loopback offsets. Instead I discovered a tool called kpartx which maps the partitions from the image into the device mapper, giving a device like /dev/mapper/loop0p1, which can be used like a regular block device.
~
Unfortunately while different, both FATs were damaged, and has been incorrectly repaired by something, and I ended up recovering the files with photorec instead.
Happy new year, everyone!
Once again my former employer, Fugro Seismic Imaging, is looking for two new R&D staff for their office in Perth, Western Australia (one to replace someone who’s moving on, and another to grow the team).
The team there is approximately half a dozen people, generally open-source experienced, who are primarily developing graphical front ends to geophysics applications (there’s also some other stuff, in general it’s pretty cool). You’ll almost certainly have to know C. Knowing any of C++, Python, Perl, GTK+, Qt or Fortran also a benefit. You don’t have to know any geophysics, but knowing a bit of maths and physics helps. You’ll easily pick up what you don’t know as you go along.
Pay and conditions are very good. FSI have previously provided sponsored work visas for skilled applicants looking to work in Australia.
If you’re interested, send your CV to the regional manager, Kelly Beauglehole.
I find it so amusing yet depressing how afraid your average engineer now is now afraid of a computer.
My brother started his first real engineering job and rapidly found himself with a problem he needed to solve. He can’t afford Matlab or Mathematica, so I suggested he teach himself Python and use that. After all, Python has excellent scientific credentials. He looked at Python and agreed it looked easy to learn and met his needs.
His boss however, vetoed the idea on the basis that if a tool were written in Python, no one would be able to come back later and edit it. The implicit assumption here seems to be that programming is hard. That no one else could learn enough of the language to later edit the program.
Once upon a time, computers didn’t do very much. They could read and write data and execute programs. Engineers and scientists had to teach themselves to write their own programs to solve their problems.
Over time programs got bigger and more complex. Then people started collecting them together into packages of tools and turning them into a product to sell to other people. They hired engineer-programmers to work on them. Eventually they glued user interfaces on top and so we get the engineering and scientific packages you see today. [My first programming job was working on one of these packages.]
New engineers start in the field and they are simply taught the package at the user interface level. Sometimes they hit the limits of the interface, and learn how to drive the individual programs underneath.
Rarely though do they still see the computer as the blank canvas which they can use to solve their problem. It does so much now that the idea of learning to make it do more seems foreign. Engineers are now afraid of the tool.
It is my belief that engineering students should be compulsorily exposed to some computer science; The core stuff with useful tools. They should have to implement algorithms that have meaning to engineers: solving equations, not a booking system for tennis matches. Perhaps then they’ll stop being afraid of using computers to do computation.
The GOPW application period is coming to a close soon, and so potential interns are currently getting their initial contribution in to qualify.
Obviously the nicest way to submit your patch is as a commit, or series of commits using git, either via git bz or git format-patch (a branch is nice too, but submitting the patch in Bugzilla allows for inline review).
Of course, after your patch is correct, the maintainer is going to want to merge it into the tree, in which case you need to have a useful commit message. GNOME has some guidelines on commit messages, but here are the important dot points:
Here are some good examples taken from Empathy:
Don't destroy MainWindow on delete-event, just hide it
This stops MainWindow being unreferenced, and prevents crashes caused by things which then try to use it.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=659118
This one has a tag:
e-account-widget-jabber: Use GtkGrid instead of GtkTable
This works around bug #657621.
https://bugzilla.gnome.org/show_bug.cgi?id=646630
Here’s another way of doing a tag (preferred by some projects):
[contact-chooser] emit 'activate' on 'row-activated' as well
This means the selection can be activated when the treeview is focused.
Or a one-liner commit:
[contact-chooser] Move the selection up/down without defocusing the entry
Remember that your commit message is important. They tell other developers what’s changed. What a commit fixes, or does, or is meant to do, and occasionally, what it doesn’t do. Commit messages are often used by the maintainer to write the release notes. When things break, people come back looking through the code for what broke it (e.g. via a git bisect) so clear and useful commit messages are essential.
October 7th is Ada Lovelace Day. A day that showcases women in science and technology by profiling a woman technologist or scientist on your blog.
This year I wanted to write about two women who I’ve met and worked with in the last year as a mentor of the GNOME Outreach Programme for Women and the Google Summer of Code.
Chandni Verma
I met Chandni when she applied to be an Empathy intern for the GNOME Outreach Programme for Women. Chandni had never worked in open source before, but she approached it with an amazingly keen enthusiasm. Before too long Chandni began to grasp the ropes, learning GTK+ and Telepathy. She then went on to fix bugs in Empathy as well as the Telepathy connection managers.
Chandni studied computer science at the Dr M.C. Saxena College Of Engineering & Technology and has a passion for algorithms and would regularly participate in algorithm competitions. She learned about open source from a friend and in her final year of college and ordered Ubuntu CDs to check it out. Chandni says “I liked the idea of open source particularly since it allowed one to learn and evolve without any restrictions even if you are a student.”
Chandni applied for GOPW after completing her final year and has remained working on Empathy since the end of her internship. Chandni gave her first conference presentation, detailing her experience with the programme, at GNOME.Asia. She had hoped to give it again at the Desktop Summit, but unfortunately bureaucracy got in the way. She looks forward obtaining a position with a company working on GNOME.
Tiffany Antopolski
Tiffany was in the same intake of the GOPW as Chandni, working on the documentation for GNOME with Paul Cutler. I then met Tiffany when she applied for the Google Summer of Code to work on integrating Empathy and Evince.
Tiffany is studying software engineering at McMaster University and also taught first year programming to students of the same course, having helped to design the curriculum. Before studying software engineering, Tiffany was a veterinary technician, and used to work in an emergency vet clinic. She also works part time in a neuroscience research lab.
Tiffany got involved in GNOME through the GNOME Documentation Project after being an Ubuntu user for around two years prior. In 2011 Tiffany attended the GNOME docs hackfest, the Open Documentation Conference and the Desktop Summit, where she worked on improving the documentation for GNOME. She successfully applied for Google Summer of Code with a project to work on integrating Telepathy into Evince. Recently Tiffany began working on the Esperanto translation for GNOME.
