-
Today I was working on the Overview of the Gnome Platform, which is written in Mallard. I am a die-hard Emacs user, but a lazy one, and so I haven't kept up with all the relatively new things in Emacs: nxml-mode, the incredible Emacs Wiki, elisp package systems...
I became tired of Mallard documents opening up in plain nxml-mode, with no schema. So I learned how to teach nxml-mode about Mallard files and its RELAX NG schema. And I got to thinking why we don't have a well-known set of Elisp utilities for Gnome developers.
Back in the Gnome 1.x days, we had a wonderful little snippet of Elisp by Michael Zucchi, which would let you press a hotkey to add inline documentation comments for gtk-doc. If you had code like this and the point was at [*]:
GtkSandwich * gtk_foo_make_me_a_sandwich (GtkFoo *foo, GList *ingredients, GError **error) { [*]Then you could hit the hotkey and this would be inserted before the function's prototype:
/** * gtk_foo_make_me_a_sandwich: * foo: * ingredients: * error: * * Put the description here. * * Return value: **/ GtkSandwich * gtk_foo_make_me_a_sandwich (GtkFoo *foo, GList *ingredients, GError **error) {This elisp doesn't work anymore, sadly.
And so, I've started a little collection of Emacs stuff for Gnome developers. Let's tweak it to perfection.
git clone https://github.com/federicomenaquintero/gnome-emacs-utils
-
For the software-development-as-urbanism crowd: "When Tokyo was a slum" is an excellent article. It doesn't talk about software, but the process of construction of cities on a piecemeal basis is very illuminating.
When the war ended, Tokyo’s municipal government, bankrupt and in crisis mode, was in no condition to launch a citywide reconstruction effort. So, without ever stating it explicitly, it nevertheless made one thing clear: The citizens would rebuild the city. Government would provide the infrastructure, but beyond that, the residents would be free to build what they needed on the footprint of the city that once was, neighborhood by neighborhood.
[...]
The central part of the city is the historical core of Edo, which became Tokyo in the late 19th century. But the periphery grew largely without planning. Tokyo swallowed up the surrounding villages as it sprawled outward [...].
[...]
Throughout the 20th century, as surrounding villages were absorbed into the expanding city and rural villages became urban neighborhoods, their inhabitants preserved some of their customs and social organization. But the central government never saw the autonomy of these neighborhoods as a threat.
Does Gnome operate somewhat like that, and if so, what can we learn from the process? Is the center (the core desktop) traditionally the "capital", and has it swallowed little villages in the periphery (apps and libraries that became part of the core, or otherwise became tightly integrated with the core)? How much autonomy (let them be) vs. how much central planning (let's tackle horizontal issues)?
How do we remain civil as the city grows, when it is no longer possible to know everyone who lives there in person?
Jane Jacobs, in The Death and Life of Great American Cities, makes a point that one virtue of a great city is that it allows complete strangers to live very close to each other. A great city gets made through explicitly allowing and nourishing diversity: diversity of uses, so you don't have business neighborhoods which go dead at night; diversity of people, so any minority's needs don't go unmet; diversity of age in buildings, so people can afford a cheap shop or apartment if they need one, or a big and new building if they can.
Jacobs also talks about the "self-destruction of diversity":
[...] the tendency for outstandingly sucessful diversity in cities to destroy itself; the tendency for massive single elements in cities (many of which are necessary and otherwise desirable) to cast a deadening influence; the tendency for population instability to counter the growth of diversity; and the tendency for both public and private money either to glut or to starve development and change.
[...]
The purpose of recognizing and understanding [these forces] is to try to combat them or — better yet — convert them into constructive forces. Besides influencing the growth of diversity itself, these forces also sometimes affect the ease or difficulty with which the basic conditions for generating diversity can be introduced. Leaving them out of account, even the best planning for vitality would fall a step back for every two steps forward.
There is a lot of food for thought in all of this. See also, Photoshop is a city for everyone: how Adobe endlessly rebuilds its classic app for a tangible example of a large, old software project, that everyone seems to love and hate. This article also portrays its subject as a world-class city!
-
The Produce Savant, a wonderful blog about what to do with "unpopular" vegetables. By Sally of the amazing Tools for Working Wood.
-
2013 Developer Experience Hackfest, Brussels
I'm late to the blogging party about the Developer Experience Hackfest, which happened right before FOSDEM, but here it goes!
The Hackfest
We split into four teams: tooling and IDEs, application bundling and sandboxing, development platform, and documentation. I was part of the documentation team.
In the docs team, Allan focused on developer.gnome.org, our main web site for developers, while Meg worked on an introduction to the Gnome libraries. Fred, Thomas, Aleksander, and Jasper worked on documentation tools — DevHelp and documentation generation. I worked on updating our historic Overview of the Gnome Platform document, based on Tuğçe Şirin's analysis of what it lacks or what could be made more clear in it.
That document has a little history that is worth noting. Shaun McCance wrote it on comission from the Gnome Foundation in 2006. It is, to the best of my knowledge, the first time that the Foundation contracted someone for pay to do something related to development of Gnome. Shaun did an excellent job of summarizing the libraries we had available as part of the core development platform.
Over time, however, that document has gotten a bit outdated. People have kept it mostly up-to-date with respect to the libraries, but the document suffered from a bit too technical language at times, and from being a catalog of stuff rather than an introduction on how things work together.
I've been making some changes to the Overview of the Gnome Platform to add the missing platform libraries, to make the descriptions easier to understand, and to add a bit of a better structure to the document.
JavaScript
Practically any high-level, garbage-collected language is much better than plain C, in terms of productivity, once you get used to the idiosyncrasies of the bindings to the Gnome libraries.
So, I'm very happy that we have a high-level language accepted as officially supported for Gnome. I was kind of surprised that Python, our de-facto and historically "best supported binding" wasn't chosen, but if this means that another high-level language can get as much work put into it, then all the better.
Also, for JavaScript we have outstanding tutorials in Gnome Developer Platform Demos mega-document. Taryn Fox, Tiffany Antopolski, and other people who have worked on this have done an excellent job. See also the coordination for this in the wiki page for the Gnome Application Developer's Guide.
My hope is that we will get good tutorials for beginners, and that people will later take care of making sure that the examples are available in all our "good" language bindings, and that the text makes sense regardless of programming language. Gnome is a polyglot project, fortunately, and people will program in whatever language they find the most conveninent — which is perfectly okay.
Brussels in winter
Cold. Wind. Rain. Wind. Rain, and cold. The streets are littered with the corpses of umbrellas. My own didn't last one minute after taking it out of the backpack.
Still, it's worth it once you get to the pretty architecture, which permeates the center of the city. And a waffle warms you up. This is Juan Pablo Ugarte, from the Glade / IDEs team, a marvelous guide and conversation partner from Argentina, recharging his batteries.
Also, churros in Brussels? For 5€? What is this how can they I don't even.
Thanks
The hackfest took place at the Betagroup Coworking Space. This is a nice place! They have desks and chairs, coffee for which you pay based on an honor system, a kitchen, good networking, beanbag chairs, and it all leads to a very nice atmosphere. This is the first time I visit a coworking space, and it was very nice.
Thanks to the Gnome Foundation for sponsoring my flight/hotel!
