- meeting with LAS GNOME team
- sort out issues I've had with GNOME's build system(s) for applications
- get automated testing working with the Jasmine-GJS testing framework and identify an area lower in GNOME's stack where I can contribute
- attend some awesome talks and learn what my fellow GNOMErs have been up to lately
I was particularly interested in and disappointed by Michael Catanzaro's talk "Migrating from JHBuild to BuildStream". I appreciate all the time and effort the Release Team has put into maintaining and developing the build systems, so I'm including my experience here as an example, not as a criticism.
Over time I've gotten used to JHBuild and become adept at searching for and fixing its sometimes bizarre error messages. A few months ago, after running into some modules that failed on JHBuild, I read the announcement about GNOME's modulesets moving to BuildStream. I spent a couple days removing JHBuild and rebuilding everything in BuildStream. Except I ran out of disk space. So I removed as much as I could and started over. Except then PulseAudio wouldn't work. Luckily I'd occasionally run into the same errors caused by an unavailable PulseAudio daemon when I was using JHBuild. I tried restarting the daemon, etc, and looked for info on the subject. In the end it turned out that PulseAudio wasn't available within the sandbox, so I scrapped BuildStream and went back to JHBuild.
Going forward, I'm planning to move from JHBuild to using FlatPak, Builder, and GNOME's nightly runtime build. I'm happy that the community is providing solutions, and, while things are still in a confusing state, at least they are moving quickly in interesting and promising directions.
When I was working mostly with Python I got into the habit of using TDD. As is usual in startupland, we had a release every two weeks, and features were being sold before they were developed (maybe that part's not so normal). I love tests: they document the expected behavior of the code, they shorten the development cycle by integrating debugging and coding, and they catch it when you break something in code you think you haven't touched. You can just stick nice hook in your repo, and then you can't push till everything is working.
During my time on the Board I found that I had less time for development, and I really wanted automated testing so I wouldn't cut corners on testing and accidentally release broken code. The Sound Recorder is hastily written student code, and somewhat fragile. So I started writing tests with Dogtail and Behave, only to find that the framework had been deprecated. Hence my mission to get Jasmine GJS working.
Jasmine takes a very different approach to testing from Dogtail and Behave. Behave uses ATSPI to provide a context from the actual running application. Using that context you can manipulate the UI elements. Jasmine GJS provides a framework more adapted to API testing. I had a short discussion with Philip Chimento about how he is using mock objects, and got my tests working. I also got a chance to talk to Philip about some easy bugs in GJS. I've been using C++ at work, and I use Javascript to write application code for GNOME, so GJS seems like a great option.
Last but not least, I got to attend a bunch of great talks by my fellow GNOMErs! I particularly enjoyed Federico's talk on porting Librsvg to Rust (complete with awesome illustrations of fairies by his daughter), Christian Hergert and Corentin Noël's talk on Builder, and Benjamin Otte's talk on GTK+ and developing for GPUs. I'm looking forward to watching all the great talks I couldn't see during the conference!
Thanks again to the GUADEC organizers, and hope to see you all at LAS GNOME in September!
No comments:
Post a Comment