After seeing the new trailer for Star Wars Episode VII, I was suddenly overcome with the urge to play my favourite Star Wars game of all time, Jedi Knight II: Jedi Outcast. Since I’ve sworn myself to a Windows-free home environment, some challenges were posed.

Lucikly, Raven Software released the source code for the game engine last year, and this helpful person has created binaries that will run it on Linux: https://github.com/xLAva/JediOutcastLinux. But since it is only the engine and not the game assets, we need to get them from somewhere. Steam to the rescue! I went ahead and bought the full Star Wars pack on sale. But when you open Steam, you’re told that you can’t install the game since it is not available for Linux on Steam. Booo.

This is where SteamCMD comes in! It’s a commandline tool meant for administrating dedicated servers, but it can be used to download game data for any game! Follow the instructions on the site to download it and run it, and if you have Steam for Linux installed, it will automatically pick up on your Steam login.   Just remember to remember to force it to pretend it’s on Windows by setting the correct variable, and then download the  app.  For JKII, the Steam app ID is 6030. (Protip: You can check the steam app ID by looking at the page for it in the Steam store: http://store.steampowered.com/app/6030/ .)

Next, you have to follow the README for JediOutcastLinux.  One snag I hit was that Ubuntu 14.04 LTS 64-bit does not have ia32-libs, but install lib32z1,  libopenal1:i386, and libXrandr2:i386 instead and things should work the same. (When you run the game from the command line error messages will tell you what you’re missing.) Just download the whole repo as a zip if you’re only interested in playing, and grab the binaries from the code/Release folder. Copy the base folder that you’ve downloaded via SteamCMD together with the binaries, mark the binary as executable, and you should be good to go! The game works beautifully, with fullscreen, crisp graphics and smooth framerates.

Update: I just finished playing through the entire game without ever crashing! (Which I believe is better than when I played it on Windows back in the day…)  The only things that were a bit off were that debug messages sometimes appeared in the top left corner, and that dark or foggy places sometimes were overly dark/foggy. (I guess the video drivers behave a bit differently than ten years ago on Windows.) But no problem, because we have night-vision gear in the game!

I even managed to make it load up a mod, but sadly it crashed after the mod’s intro was over. Ah well, still not a bad showing all in all!

Or, my rather unordered ramblings on what happened last week.

On the city and social stuff (PDX)

As a European I enjoyed it a lot! Portland has great public transport, is very bike-friendly, close to nature and is about the right size for me. It’s well known for its beer, but maybe less well known is that the Willamette Valley outside Portland is chock full of vineyards and wineries. I went on the FOSS4G wine tour and had a great time!

Another tour I was on is the Keep Portland Wired tour, which also was a blast! It’s a real shame that not more people showed up. (The closing keynote went over time, so I had to bail out to make the tour, I guess a lot of people prioritised the keynote.) We toured the offices of Jive software and Mozilla’s office/working space in Portland. At Jive we were showed around by the company’s founders, two really nice fellahs who were happy to to engage with a bunch of geogeeks. They gave good insights on their experiences starting and running a tech company in the USA, and a killer tour of the building. Their offices were in the old Federal Reserve building, so the facilities included a indoor shooting range and a bank vault with a massive steel door, both of which had in typical Portland fashion been converted into bicycle garages. Otherwise the offices were typical movie-style tech offices with cool gadgets and free snacks and food all over. Local Portland craft beer was available on tap, of course.

Mozilla was also awesome as expected (totally impartial judgement from the guy with a Firefox sticker on his laptop.) They had a slightly different vibe, as one might expect from a non-profit, idealistic type organisation, but were still equipped with a bike garage and Tardis stylings on their refrigerator. Nice conversations were also had in this space, and Firefox swag was secured! (They also had free beer and stuff.)
The FOSS4G parties were good fun too. The opening reception was interesting, a vey nice building filled with interesting folks. I missed the Null Island party because I needed a rest, but in hindsight after talking to other attendees, I kind of wished I went anyway. The Gala evening had a misleading name, insofar as anyone in a tuxedo would have been sticking out like a gangrenous thumb. The location however was nigh on perfect for the gathering, at the World Forestry Centre, with lots of cool interactive museum exhibits for all the geeks to play with and cool local food options.

I got to the Mapbox closing party after the walking tour. Super-hipster post-industrial space with heavy freight trains rolling past, and recent OSM edits being projected on to the wall. Beer, wine, snacks and a great atmosphere. What else could you expect from a Mapbox  party in Portland?

Got to meet some really cool people, like Lyzi Diamond from Code For America, who wasted no time in getting me to promise I’d have a go at gauging the interest for Maptime in Norway. Kristin Bott, who did a great job on the organising committee and whose vision for more diversity in our space I totally share.  Vladimir Agafonkin of Leaflet fame who actually remembered my last name from the internet and said nice things about the Leaflet plugin I made at work, practically making me swoon. Also, like a true Norwegian I spent lots of time talking to other Norwegians, which is very useful. Why not do your local networking on the other side of the globe?

Trends & Impressions (PDX)

• Macs. Everywhere! Come on folks, hooking up a Linux machine to projectors has gotten much better, only like 37% painful. You have to suffer for your art!
• Javascript is surging ahead. FOSS4G isn’t a web tech conference yet, but you could probably pick your talks to make it look like that if you wanted to.
• Lots of buzz about vector tiles and personalisation of maps. Nice to see the stuff that was future-tech back when I wrote my thesis is rapidly becoming reality. (Still bleeding edge though, but three more years from now it’ll be pretty pervasive, I think.) The talk on adaptive maps by John J Czaplewski was a very interesting conversation starter on what we might do with these technologies.
• WebGL is  also maturing nicely, a lot of libraries and apps coming together now. We shall see which ones emerge victorious from the Thunderdome of adoption rates in a few years.
• Speaking of the Thunderdome, in my opinion both the Leaflet + Mapbox GL combo and OpenLayers 3 are in sum promising a lot of the same things when they’re done, but neither are done yet and have different things finished. (OL3 even replicated MapBox Gl’s big party trick by showing off drone/sat video overlaid on a map!) So there is still room for both!
• Like Atlefren mentioned, projections are hard and people would rather go shopping, so use WGS84 for vectors and Web Mercator for maps unless you actually have a compelling scientific reason. (Like if your data *actually* has the kind of accuracy and precision that warrants a local projection, or you’re mapping something north/south of 80 degrees. His observation on more and more non-classically trained folks entering the field also holds true. (AKA. you don’t need 5 years of univerity geomatics to put a pin on a map, and on some levels it probably doesn’t help, either!) But I still feel that scientific rigour has its place, especially for those who are making the tools everyone else wants to use. (But then again, that might just be the five years of university talking.)

Random Observations (PDX)

• Somebody needs to make a LCARS interface for GRASS.
• Compostable utensils and cups that still feel like plactic confuse the hell out of me, I never know which bin to use.
• Dear Portland: “MAX Light Rail” and “Portland Streetcar” are really just two different names for “Trams in Portland”. Why not just call them “the large tram” and “the small tram”.
• Did not see any werewolves or supernatural policemen while visiting, did see at least two locations I recognised from episodes of Grimm.

FOSS4G NOR

Two days after I got back from Portland I attended the local Norwegian FOSS4G event, where 86 happy hackers and useful users of open source geospatial software in Scandinavia’s most coast-liney country (award-winning fjords!) got together for a day of presentations and chatting. Together with Alexanno I did a ten minute lightening talk on impressions from FOSS4G PDX, in which our rate of speech steadily increased throughout as we tried to cram in more and more information in the allotted time.

The other talks were also very interesting, like Bjørn Sandvik’s presentation on the impressive open source-based stack the journalists at NRK use to publish maps with their news stories, and the talk on how the Norwegian Defence Research Institute makes maritime monitoring systems  for the coast guard using open standards and open source. We were told that the Norwegian Armed Forces mandate OGC compliance in their internal secured systems, which is pretty cool. OGC standards, open source software, and things that are expensive and make other things explode. Can it get any better?

I believe all the slides from the talks should soon make it out to the internet, sadly not full recordings like the big FOSS4G does. Next year we’re hoping to attract a bigger crowd of students and others to FOSS4G-NOR, making it less dependent on the big companies. All in all I’ve had two great FOSS4G’s in two weeks, and I hope to attend many more in the future!

I’ve been neglecting to blog the last three days because I’ve been going full steam ahead since the last blog post! After I finished the GTK#3 template for MonoDevelop, I moved on to use it to create a new Mono.Addins subproject named GuiGtk3. This subproject was needed so that apps depending on Mono.Addins.Gui (Pinta, Tomboy, F-Spot)  could move forward, while still allowing GTK2 projects to use the original Gui. The API is identical, so all you need to do is drop it in place of ye olde one and change the using statement. Right now the pull request is pending.

With that successfully concluded, I took over where Stefan Hammer left off on Tomboy, and using all the knowledge I learned from Pinta, Mono.Addins, Mirco Bauer and Bertrand Lorentz I powered through Tomboy’s porting work. (Hopefully there will be a technical post/memo for future use forthcoming…) The net result is Tomboy, in GTK3, using GSettings, and with every last scrap of horrible icky C code evicted!

Right now the code is living in this branch, but we can expect a release in time for the next version of Ubuntu, when all the needed library dependencies have made it in. (If you want to run it, you need to pull down the Mono.Addins.GuiGtk3 branch mentioned previously and make install it to have the GTK3 Gui available.)  There is one thorny issue remaining, which is the state of GTK3 on Windows and Mac. Someone will have to make installers for this on these platforms before we can make GTK#3 releases there, but I think that the current attitude is that Linux is the lead platform and the others will just have to wait.

The port is complete, but we don’t yet take advantage of all the features of Gnome Shell and/or Unity, so among the things we have noted for future improvement are improved DBus connections to allow direct interaction with the shell and making the panel applet an add-in which can be deactivated where appropriate.

The hackfest, summarised

I didn’t get to finish porting Pinta, but by tackling it head-on I learned some important things that were very useful when I did the projects I’ve completed this week. (Talk about diving in on the deep end!) I managed to make important contributions to tooling and dependencies for future GTK#3 work, and I managed a complete port of my first open source love, Tomboy Notes. We have had a great time together and been super productive, and there is no doubt in my mind that the benefits of inspiration and  direct knowledge transfer that come from being in the same room cannot be matched in any other way.

Finally, let me once again thank our gracious sponsors:

Norkart AS, Norway’s premier supplier of Geographic Information Systems and related consulting and my most lovely employer (website, logo)

Collabora Ltd, Open Source Consulting (website, logo)

Hotel Schottenpoint, Our hotel partner (website, logo)

Novacoast IT, Professional Services and Product Development (website, logo)

The GNOME Foundation, providers of the GNOME desktop (website, logo)

Venue sponsor:

• The University of Vienna (website, logo)
• Institute for Theoretical Chemistry (website)

Here I am in my hotel room in the lovely city of Vienna, after en evening spent eating Chinese food together with lovely Open Source hackers. I’m looking forward to this week’s hacking!

Since add-ins for Pinta are more or less wrapped up (one or two small things to fix), most of this week will be about a new branch for Pinta, where we will try to port it to GTK#3. This is very exciting (not to mention scary) since GTK3 has been known to make a fair few breaking changes, and Pinta also has a good deal of generated GUI code. I’m a total beginner on GTK#3, and I’m slightly daunted by the task. But there can truly be no better place to get started on the task than in the company of other talented hackers, all working together towards the common goal of bringing Mono applications into a shiny new GTK3 future!

As usual, we must thank the sponsors for their generous contributions allowing this hackfest to happen:

Norkart AS, Norway’s premier supplier of Geographic Information Systems and related consulting and my most lovely employer (website, logo)

Collabora Ltd, Open Source Consulting (website, logo)

Hotel Schottenpoint, Our hotel partner (website, logo)

Novacoast IT, Professional Services and Product Development (website, logo)

The GNOME Foundation, providers of the GNOME desktop (website, logo)

Venue sponsor:

• The University of Vienna (website, logo)
• Institute for Theoretical Chemistry (website)

At work, we have a project where an Android application depends on a Android library project for some theme files. The application project has a simple path to the library project, so they always have to be in the same position relative to each other. For reuseability the library project lives in its own Git repository. There are two possible ways of making this work on the both the local side and the server side:

One is to have the library project checked out as a submodule to the application project and make the path simply be the subfolder name. The advantage of this is that it will work equally well on the server (Jenkins) side and locally within a workspace. The disadvantage is that you can’t have more than one project using the library in our workspace, unless you modify the projects project.properties file. (Which quickly becomes a version control pain in the ass. It might be possible to modify local.properties instead, which I haven’t tested, but keeping machine-specific  configs outside of version control also creeps me out.)

Now, I don’t know if this is Eclipse Best Practices, but I typically keep several Android projects in the same workspace since it makes it easier to jump between them when working. Therefore I prefer to have the library checked out as a top level project in the workspace, and all the projects referring to it have a path like “../TheLibrary”. This will, on the other hand, create problems for Jenkins when it checks out the project and then can’t find a folder in that location with the library. So I use the “Multiple SCMs” plugin to fetch both the application and the library, and set them up to checkout to separate directories within the build workspace. (Branches  to build -> Advanced -> Local subdirectory for repo)  Voila, we have recreated the essential parts of the Eclipse workspace and things will build happily without any differences between IDE and build server!

Right now managing Android libraries is quite difficult, and hopefully this will improve with the new Gradle based build system. Being able to package them in a binary format that you can drop into the project’s lib folder sounds like exactly the ticket for something that doesn’t change very often. Alternatively, I have been thinking about maybe setting up an inernal Maven repository to make things properly automagical!

Edit: I forgot to mention that if you set up an Android build with subdirectories like this, you will also have to go to Build Steps -> Invoke Ant -> Advanced and specify the build.xml file since it is no longer in the root.

Full disclosure department: The good folks over at Packt Publishing provided me with a review copy of this eBook, on the condition that I review it on my blog and mention it on Twitter and stuff. So here goes!

This book was relevant to my interests since I work a fair bit with Leaflet, and one of the things I do at work is train others to use Leaflet. In fact, two weeks ago I held a small workshop at my job where I went through the basics of Leaflet use, and I thought it would be interesting to see how much the things I talked about overlap with the things in this book. I have not tried running the sample code to verify that there are no bugs in it.

The stated mission of the book is to provide simple, step-by-step instructions for setting up a web map for those with little to no previous experience. I think it does a quite good job of this, and it spends a fair bit of text explaining what exactly the code it asks you to copy does, line by line. Furthermore, it does no try to hide the fact that Leaflet has excellent API documentation and often links there to explain details. (Which I approve of!) It covers all the basic things one might expect, and even one thing I didn’t cover in my intro to Leaflet, which is adapting to mobile and using location APIs. Each chapter builds on the previous, essentially starting with a super simple map and building it out to a relatively complex and useful one.

The last chapter is a bit odd in that it suddenly ratchets up the difficulty a bunch of notches, going from dead simple to an actually rather complex task.  (The “Advanced” chapter on designing interactive choropleth maps.) It does a decent job of explaining that as well, and works as a cookbook recipe, but I feel the book might have benefited from another intermediate step before building something that complex.

All in all, I have to say that as an experienced Leaflet user I didn’t really learn anything new from this book, but I can appreciate the structure and relevancy of the examples. For someone who is completely new to Leaflet (and web maps in general) this would serve as a useful condensed guide. On the other hand, all this information can really be gleaned from existing tutorials online.  Therefore, I would say that is up to the buyer to decide if spending 4£ on the eBook to save a few hours of surfing about is worthwhile for them. If I was researching Leaflet as part of a job with a salary anywhere north of 4£ an hour and needed info quickly, it would probably be quite easy to justify. Buying the printed version from Amazon (at 13£) would be a waste of time and money, and is indeed probably not how this book is primarily intended to be consumed.