Thursday, September 4, 2014

Going to Akademy 2014

I'm going to Akademy. Now. I'm about to leave for the train to Brno and am looking forward to the people, presentations, discussions, workshops, hacking sessions, beers, ideas, and everything else which makes Akademy special every single time.

For me Akademy will start with a series of presentations:

On Friday I'm presenting the report of the KDE e.V. board to the membership. It will be the last time I do this, as my term ends, and I will not run again. It's the end of nine years being on the board of KDE e.V. Not being on the board anymore will be a change, but I'm happy that we have great candidates to fill the open positions. I also still want to and will be involved in KDE e.V., but as a regular member.

On Saturday I will give a short talk about Inqlude. This is a side project, I really enjoy working on, and it gains more and more traction. With the release of KDE Frameworks 5 we now have a huge number of libraries from KDE listed there. There is plenty of awesome stuff to use for any Qt developer. I will report about the current state, and would also be happy to see more people getting involved with further developing the tool and the site.

On Sunday I will give the community keynote. I will talk about how KDE makes you a better person. Some more information is on the dot in the announcement of the Akademy keynotes, and the interview Carl did with me. KDE is an amazing environment which has given me a lot. I will talk about how I see KDE enabling growth in people, and how we can maintain that.

There are many more interesting talks in the program. I'm especially looking forward to Kevin's talks about craftsmanship, and agile, as I think we can learn some good things from what others and the software development community in general are doing. I'm also excited to hear more from the KDE Visual Design Group. They will talk about community design and how designers tick. The visual design group has made a big difference to KDE in a short time, and I'm looking forward to see more of that.

But there is more than presentations to Akademy, meeting old and new friends, discussing technology, community, and many other things, hacking with others on the latest projects, and more...

See you all in Brno tomorrow.

Tuesday, August 26, 2014

Running on Cheese and Chocolate

This is a big thank you, a thank you to all the people who made the Randa Meeting 2014 possible, the people who invested their time and their energy to go there and work on free software, and the people who made donations to support this.

Tons of things happened at Randa this year. Among other things there was lot of porting work to KDE Frameworks 5 done on kdevplatform, KMyMoney, Gwenview, KMix, Artikulate, and Kig. KDevelop got QML and Javascript support, the API docs got some love, Phonon 4.8 Beta was released, KStars tools got polishing, Kdenlive got a roadmap, and the first alpha of the Inqlude tool was released. We wrote a book, and made a movie:

It can't be overestimated what kind of magic place Mario created at Randa. It is such a focused and supportive environment, that it's hard to not be productive. It generates a sense of community which reaches way beyond the meeting itself, and fuels so much of future work. I have written about what makes this special spirit. But I suspect that the real secret is that Mario runs us on Swiss cheese and chocolate for a week.

So thanks again to the donors, to the sponsors, to the people who wrote code, or text, or took photos, or brought their kids, or organized, or simply provided happiness, or helped in any other way. It was an awesome event.

Wednesday, August 13, 2014

The Book

When inviting to the Randa 2014 meeting, Mario had the idea to write a book about KDE Frameworks. Valorie picked up this idea and kicked off a small team to tackle the task. So in the middle of August, Valorie, Rohan, Mirko, Bruno, and me gathered in a small room under the roof of the Randa house and started to ponder how to accomplish writing a book in the week of the meeting. Three days later and with the help of many others, Valorie showed around the first version of the book on her Kindle at breakfast. Mission accomplished.

Mission accomplished is a bit of an exaggeration, as you might have suspected. While we had a first version of the book, of course there still is a lot to be added, more content, more structure, more beautiful appearance. But we had quickly settled on the idea that the book shouldn't be a one-time effort, but an on-going project, which grows over time, and is continuously updated as the Frameworks develop, and people find the time and energy to contribute content.

So in addition to writing initial content we spend our thoughts and work on setting up an infrastructure, which will support a sustained effort to develop and maintain the book. While there will come more, having the book on the Kindle to show it around indeed was the first part of our mission accomplished.

Content-wise we decided to target beginning and mildly experienced Qt developers, and present the book in some form of cook book, with sections about how to solve specific problems, for example writing file archives, storing configuration, spell-checking, concurrent execution of tasks, or starting to write a new application.

There already is a lot of good content in our API documentation and on, so the book is more a remix of existing documentation spiced with a bit of new content to keep the pieces together or to adapt it to the changes between kdelibs 4 and Frameworks 5.

The book lives in a git repository. We will move it to a more official location a bit later. It's a combination of articles written in markdown and compiling code, from which snippets are dragged into the text as examples. A little bit of tooling around pandoc gives us the toolchain and infrastructure to generate the book without much effort. We actually intend to automatically generate current versions with our continuous integration system, whenever something changes.

While some content now is in the book git repository, we intend to maintain the examples and their documentation as close to the Frameworks they describe. So most of the text and code is supposed to live in the same repositories where the code is maintained as well. They are aggregated in the book repository via git submodules.

Comments and contributions are very welcome. If you are maintaining one of the Frameworks or you are otherwise familiar with them, please don't hesitate to let us know, send us patches, or just commit to the git repository.

I had fun writing some example code and tutorials for creating new applications and how to use KPlotting and KConfig. The group was amazing, and after some struggling with tools, network, and settling on what path to take, there was a tremendous amount of energy, which carried us through days and nights of writing and hacking. This is the magic of KDE sprints. There are few places where you can experience this better than in Randa.

Update: Many people are involved with creating the book, and I'm grateful to everybody who is contributing, even if I haven't mentioned you personally. There is one guy I should have mentioned, though, and that is Bruno Friedmann who made the wonderful cover and always is a source of energy and inspiration.

Sunday, August 10, 2014

Announcing first Inqlude alpha release

Three years ago, at Randa 2011, the idea and first implementation of Inqlude, the Qt library archive, was born. So I'm particularly happy today to announce the first alpha release of the Inqlude tool, live from Randa 2014.

Picture by Bruno Friedmann

I use the tool for creating the web site since quite a while and it works nicely for that. It also can create and check manifest files, which is handy when you are creating or updating these for publication on the web site.

The handling of download and installation of packages of libraries listed on Inqlude is not ready yet. There is some basic implementation, but the meta data needed for it, is not there yet. This is something for a future release.

I put down the plan for the future into a roadmap. This release 0.7 is the first alpha. The second alpha 0.8 will mostly come with some more documentation about how to contribute. Then there will be a beta 0.9, which marks the point where we will keep the schema for the manifest stable. Release 1.0 will then be the point where the Inqlude tool will come with support for managing local packages, so that it's useful for developers writing Qt applications as end users. This plan is not set in stone, but it should provide a good starting point. Longer term I intend to have frequent releases to address the needs reported by users.

You will here more in my lightning talk Everything Qt at Akademy.

Inqlude is one part of the story to make the libraries created by the KDE community more accessible to Qt developers. With the recent first stable release of Frameworks 5, we have made a huge step towards that goal, and we just released the first update. A lot of porting of applications is going on here at the meeting, and we are having discussion about various other aspects how to get there, such as a KDE SDK, how to address 3rd party developers, documentation of frameworks, and more. This will continue to be an interesting ride.

Wednesday, July 9, 2014

The one donation you will want to make today

In the first week of August 45 KDE people will meet at Randa in the Swiss mountains. They will spend a week of their free time and an uncountable amount of passion and dedication to work on free software. It needs money to bring them together and make the best out of their energy. You can help. We are running a campaign to make this happen. It ends today. Please donate now.

I had the opportunity to be at Randa in 2011. I have been at lots of KDE sprints over the years. Randa is one of the very special ones. There is an amazing level of energy, the buzzing atmosphere of getting things done, a deep sense of purpose. Randa is a good place to create free software.

Part of that is the environment. In the middle of the mountains with not much around than the impressive nature of the Swiss Alps, you feel physically focused on what's important. Everybody is living in the same house for a week, eating, sleeping, and hacking. There are no distractions, there is a quietness which is inspiring.

Another part is the deep commitment of Mario, the organizer of the meeting. He puts in a lot of personal energy. He even dragged in his family and friends. He equipped the house with WLAN. During the meeting he tries hard to create the best possible environment for all the volunteers who come to Randa, so they can focus on creating free software and all what is around that.

With this in place, magic happens. KDE Frameworks 5 was started at Randa. The famous tier diagram was created there. One of the projects I have been working on, Inqlude, originated there. Sebas came up with the name, the idea was discussed and prototyped, and on the train home I wrote the first version of the web site, inspired and motivated by the energy from the meeting. Lots of other good stuff originated from Randa.

All this is only possible with the help of all of you. Many people put in their passion, energy, vacation, free time. But it also needs money to bring people together who otherwise couldn't afford it. You can help with a donation.

Are you a KDE user? Do you use KDE software for work or leisure? You can help the community to sustain the development of the software you use. You can give something back with a donation.

Are you a KDE contributor or have been one in the past? You have experienced what a difference meetings such as the one at Randa can make. Maybe you have met your employer or your employees at a KDE sprint. Maybe you started as a student in the KDE community and now have found your dream job as a software developer. You know what it means to learn and grow in the KDE community. You can help, you can give back, you can contribute with a donation.

Do you care about freedom? You want to be in control of your software and your privacy. You want to be able to study your software to see what it does, be able to change it and help others by giving them the changes as well. KDE is committed to this for more than 17 years now, to protect the freedom of users and contributors, and give access to great technology to everybody. Eva Galperin said in her Akademy keynote last year: "You are the developers. You are our last and only hope. Save us". That's what meetings such as Randa help to do. You can support it with a donation.

Please donate now.

Tuesday, June 3, 2014

How to write unit tests dealing with files

I have written quite some Ruby code recently which worked with files in a file system somehow. Reading, writing, manipulating data stored in a file, or in a set of files in a directory, or in a set of directories, or one of the countless variations of this. There is a lot of code like this, and one question always is: How do I write unit tests for this code?

You need test files as input for tests. You need space to write files, which is cleaned up after the test. You often have series of tests which use similar but not quite identical sets of files. Doing all this in unit tests is inconvenient, as you usually can't just do it in the test code, but have to interface with some actual file system.

One approach is to stub all the interfaces dealing with the file system and fake them with test code, which mirrors the desired environment without ever hitting a real file system. FakeFS is one low-level way of doing this. You can also often do something similar on a higher level stubbing functions of your own code, when interaction with the file system is well encapsulated.

But this approach often is too limited. When you are using external libraries or calling external tools, you don't have access to the code interacting with the file system, so you can't stub it. You also limit your test coverage, as the actual interaction with the file system usually is an essential part. Finally it can be quite some work to isolate, separate, and fake the code, which interacts with files.

So we do want to have a better solution, right?

My solution is GivenFilesystem. It is a set of helpers for use in RSpec-based tests. It also provides a basic class, if you prefer more direct access or want to integrate it with some other test framework.

GivenFilesystem provides a simple and convenient way to create test files and directories. These can be structures as complex as needed. They are built up from test data you store as part of your tests. But you only need to store the data once, and create different scenarios using this data in your unit test code. GivenFilesystem also provides an easy way to create temporary locations in the file system for writing files. These are automatically cleaned up after the tests.

Here is an example of some code creating test files (see the details in the docs):
path = given_directory "mydir" do
  given_directory "one" do
    given_file "myfile"
    given_file "myotherfile"
  given_directory "two" do
    given_file "myfile2", :from => "myfile"
The only assumption is that you have a way to specify the path your code uses to read and write files. There is no magic behind the scenes, which replaces internal code accessing the file system, but your code has to be structured in a way that you can tell it where files are. Usually this is something you want to have anyway, and which gives nicely structured code.

So if you come to the point, where you need to set up files for unit tests, or worry about cleaning up files written by your tests, consider giving GivenFilesystem a try. It has made my life a little bit more simple and convenient, maybe it can do the same for you.

I put some effort into polishing GivenFilesystem. It comes with tests, has full test coverage, and clean code. This turned out quite nicely, also thanks to the magic of code review.

Get the gem, read the docs, get started.

Feedback and other contributions are always welcome. Or if you just want to talk about it, simply drop me an email.

Thursday, May 22, 2014

My first patch

It was 1999, when I submitted my first patch. I had started to work with Qt at my job at the university, and was intrigued by it. Programming with Qt was fun and exciting. It was C++ as it was meant to be, and you could do graphical user interfaces in the best way possible at that time. I had heard about the ideas of free software, and of course used a lot of free software already. So I was interested to try writing some myself.

Not really being content with the software I had on the HP-UX workstation I used for most of my work, I thought it would be a good idea to get organized a bit and write a calendar application. A colleague of mine had told me about KDE, which was the shiny new thing back then. So I decided to write "KOrganizer".

Looking a bit closer I realized that KOrganizer was already there. That was a nice surprise. I checked out the source code from CVS, compiled it, ran it, and it crashed immediately. So I began debugging and found a solution. I ran it again, and it crashed later. This was progress, so I submitted my first patch:

As you can tell, I didn't really have a clue. I told the people on the developer mailing list how to change the one line, which caused the crash. I didn't know about diff and patch. But the patch was accepted and I was hooked.

I continued to work on KOrganizer and was blown away by the community. The people were helpful, passionate, and excellent in what they were doing. It felt like meeting old friends, although we didn't really know each other, and mostly only communicated via the Internet. Personal meetings came later, and the feeling of meeting friends has never gone away. It's part of the magic of free software.

Over the years I wrote a lot of code, maintained frameworks and applications. I learned a lot. I grew into the board of KDE e.V. and am serving as its president now. I met a lot of people in KDE and in many other communities. I got a job working on and with free software, and I'm still doing it. It has been an incredible ride.

This is were I am, precisely fifteen years after I sent my first patch. I wouldn't be here if I wouldn't have sent this first patch. It was the beginning of a journey, which shaped my career and my life. I'm grateful to all the people which I met on this journey and for all what free software gave me.

When do you send your first patch?

Governance on demand

I have talked about the Spectrum of Open Source Governance Models  before. After rereading Nadia Eghbal's excellent post Governance with...