Robi's Blog

From Omakub to WSL

2024-11-23T00:00:00+00:00

Recently, I’ve had the opportunity to reconsider my tech choices and habits.
Both hardware and software.

At first, I finally got around revamping my old (like almost a decade old) System76</a> laptop</a>. Initially, thought to just upgrade to latest Pop!_OS</a>, but this turned out to be bit of a bumpy ride, given how outdated it was.

Next, recalled DHH</a> just promoting an Ubuntu-based distro, Omakub</a>, geared towards developers coming from the Mac to Linux. And I have to say it rocks. So many great things in there. Even if you’re not inclined to leave the Apple bubble, I’d recommend taking a look at its CLI toolchain</a> and dotfiles</a>, at the very least. Having loads of fun</a> with this, and also finally managed to get my Linux laptop hooked up reliably to my similarly ancient Apple Thunderbolt display</a> (still a solid screen with some dock-like hub capabilities, a sufficiently well-working webcam, and exceptionally good analog speakers built in).

Then, got to choose a new work laptop. In the end, went with a Lenovo ThinkPad X1 Carbon</a> (Gen 12) – what a great machine. Maxed out most specs, like 64 gigs of RAM and a 2 TB SSD (but a less high-resolution display for battery life). Now, initial plan was to install Linux on it as well, as it came with Windows 11 Pro. While updating stuff like drivers, firmware and BIOS, thought why not actually giving it a spin. Having heard from DHH’s story</a>, he went down a similar path, spending some time on Windows while finding his way out Apple lock-in. With things like WSL</a> it’s become a seriously nice environment for developers (even got a decent terminal app</a> by now), and the OS itself is a pretty pleasant window management system, getting out of the way, these days (PowerToys</a> FTW). Amusing how Apple and Microsoft appear to have swapped roles — with MS actively supporting and embracing open-source</a> software.

So, am currently happy with this setup. In my home office having ThinkPad connected to my second screen, a good old Dell UltraSharp 27-incher. Seamlessly toggling between Linux and Windows/WSL box via USB switch</a>. Keyboard-wise, am since what feels like an eternity using a Matias Quiet Pro</a>, and just got me a Lofree Flow84</a> for on-the-go. Mouse-wise, I like Logitech MX series. Bose headphones rule. In terms of mobile devices, moved from an iPhone (SE) over to a Fairphone 5</a>. Also Android is pretty neat nowadays, but that’s something for another time, I reckon (Windows mobile integration is quite comfy as well, by the way).

PS: might share some more on my WSL shell setup in the future, stay tuned.
In a nutshell, it’s a mix of Oh My Zsh</a> with Starship</a> prompt, Nerd Font</a>, various tools (like Neovim through LazyVim</a>), and some custom dotfiles, plus gum</a>-based maintenance scripts, also heavily inspired by Omakub.

Blog NG

2024-10-19T00:00:00+00:00

As I’m moving on to become a consultant, and eventually trainer, this blog is experiencing a breath of new life.
In its current incarnation, it’s moved from an Octopress</a> setup to one powered by Zola</a>.
Features like tags, comments, archive, what-have-you, may come (again) later – or not.
Here’s to new beginnings</a> 🙂
Side note: Atom feed appears to also be broken now, is anyone still using these anyway?
Edit: Aaand it’s back</a>.

About

2024-10-01T00:00:00+00:00

Hi, I’m Robert Thurnher</a>,
living and working in
Amsterdam, NL.
You can find me on
Linkedin</a> and Github</a>.
A current CV a.k.a. résumé
can be provided on request.
In case you’d like to contact me:
robert[at]thurnher.email</a>
On Mastodon:
@robi42@toot.community</a>

TempMunger || Zeitfresser

2017-06-17T00:00:00+00:00

So, in order to revive this blog a little, I’ve written a thesis</a>… :)
Code of the prototype resides on Github</a> – backend</a> & frontend</a>.
In a nutshell: poster.pdf</a> (presentation slides are available as well)

So long, and thanks for all the fish.

Boot REST

2014-04-13T00:00:00+00:00

Here’s a little sort of template toy project regarding contemporary JVM-based REST APIs powering HTML5/JS SPAs:
https://github.com/robi42/boot-rest</a>
Built with JDK 8, Spring Boot, Elasticsearch, Jersey 2, Gradle, Yeoman, Bootstrap, AngularJS, fun, and all that jazz…
PS: look Ma, no XML! :)
Update 2015: now with ES6 a.k.a. ES 2015 via JSPM/SystemJS…
Update 2016: these days, “isomorphic” Redux/React is all the rage on the FE side of things…
One may want to check out Este.js</a> & co.
On the BE, Spring Boot’s playing nicely with Kotlin, and Spring MVC’s favourable to JAX-RS, IMHO.

Java.next?

2013-07-07T00:00:00+00:00

After several years of programming Java while always keeping an eye on alternatives around, I’ve recently come to the conclusion:
Actually, there are just a few things still missing in the language these days which would render me a happy camper™ indeed (enjoying its mature ecosystem of libraries & tools).
Especially, since Lombok</a> takes a lot of the general boilerplate code PITA away here (with useful features like convenient property accessors, hashCode/equals/toString</code> impl., logging facility injection, …).
Also, Guava</a> does a truly good job in enabling one to write more concise and robust code.
Plus, Java 7 brought at least some nice, welcome improvements</a> in → try-with-resources</code>, exceptions multicatch</code>, etc.
Finally, modern DI</a> with Spring 4 (or Guice) using javax.inject.*</code> and Java config frees one from most needs for XML and, after all, a build sys beating Maven for real has yet to come.
So namely, here’s a personal wish list FTW:
Pretty much everything coming up with Java/JDK 8</a> (sooner than later, hopefully) – particularly lambdas (at last…)</li> More type inference (which the JVM is totally capable of); Java 7’s diamond operator’s definitely a good start there but, please, let me write val foos = ...</code> (like in Scala…)</li> Collection literals à la Python or C#, something like this would be really sweet:</li> </ul> val foo = #{"bar": "baz"}; foo["bar"] = "qux"; </code></pre> Pretty please. :) PS: literal multiline strings, and so on and so forth, could be nice (but I can live without). PPS: wouldn’t say no to optionally named function/constructor args, though. Update 2016: these days, Kotlin</a>’s the way to go, IMHO. :)
The Zen of Python 2013-02-27T00:00:00+00:00 $ python -c 'import this' </code></pre> Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren’t special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one– and preferably only one –obvious way to do it. Although that way may not be obvious at first unless you’re Dutch. Now is better than never. Although never is often better than right now. If the implementation is hard to explain, it’s a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea – let’s do more of those! Tim Peters — PEP 20</a> </blockquote> The Humble Programmer 2012-12-07T00:00:00+00:00 The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. Edsger W. Dijkstra — ACM Turing Lecture 1972</a> </blockquote> A Visual Music Exploration Plugin App for Spotify's Desktop Client 2012-11-21T00:00:00+00:00 This R&D project which I’ve finished recently is in its essence implementing an innovative way of visualizing Spotify music collection data. It’s mainly geared towards discovery of similar music related to the currently played tracks of a user. Technically, the project partially builds upon the foundation layed out with a previous labs project – here’s a report</a> (PDF). Organisationally, it was done as a cooperation with Spectralmind</a> and the MIR group</a> of Vienna University of Technology. Implementation</h2> Basically, the app connects to Last.fm data for similarity computation with their (more or less) RESTful web service API via JSONP. In addition to that, Spotify’s desktop client plugin apps</a> JS API is used pretty heavily. The graphics are rendered as interactive SVG through Raphaël.js. Plus, Backbone.js is applied as a mean to improve structure and, consequently, maintainability of the app. For layouting the animated visualization itself a force-directed spring graph</a> algorithm implementation is employed which was orginally written within Google’s Caja project and now adapted + tuned for the specific use case here. Functionality</h2> In the beginning, the user sees the current track symbolized by a central blue bubble and a loading spinner indicating app activity. Here’s a screenshot: After that, found similar tracks are arranged as red bubbles in a concentric circle around the central one. Again, a screenshot: Here’s how the actual animated spring graph layouting visualization initially looks like: And this is how it can look like when the animation finished rendering: The history of played tracks is visualized as a diagonal, interactive sort of a time axis which can also be seen here: Intuitively, clicking on a bubble plays the respective track in the Spotify audio player and triggers a visualization iteration, BTW. Conclusion</h2> The approach proved to be viable and it can be worthwhile indeed searching and discovering new music fitting to one’s individual taste in an entertaining way with this Spotify plugin app. Nevertheless, there are still numerous details where improvements and enhancements are possible. E.g., the graphics and visualization could be made more pleasant. Apart from that, also further tweaking connected to similarity computation could be done. Yet, as a research prototype demonstrating a proof of concept this is sufficient, it was fun building it, and possibly it’ll show up within a polished product in one way or another. :) PS & FYI: Spectralmind is currently looking for Android developers – I’d recommend applying</a> since they’re great folks to work with on interesting projects. Pragmatic App Stats With R 2012-10-21T00:00:00+00:00 Here’re some tips for conveniently generating automated visual app stats from MySQL data. Recommended toolchain: R</a> + RStudio</a></li> RMySQL</a> + ggplot2</a></li> *nix, cron + mailx & co.</li> </ul> Corresponding code bits to get one started: Simplified R script</h2> #!/usr/bin/Rscript #install.packages('RMySQL') #install.packages('ggplot2') library(RMySQL) library(ggplot2) library(grid) # PNG layout of plots helper. vplayout <- function(x, y) viewport(layout.pos.row=x, layout.pos.col=y) # Connect to DB. dbUsername <- 'some_user' dbPassword <- 'some_password' dbName <- 'app_stats_snapshot' dbHost <- 'localhost' dbConnection <- dbConnect(MySQL(), user=dbUsername, password=dbPassword, dbname=dbName, host=dbHost) # Exemplary queries. recordsPerDayQuery <- 'select date(created_at) as Day, count(*) as Count from records where created_at >= "2012-1-1" and date(created_at) < date(now()) group by Day' otherRecordsPerDayQuery <- 'select date(created_at) as Day, count(*) as Count from other_records where created_at >= "2012-1-1" and date(created_at) < date(now()) group by Day' # ... # Query data and plot charts. d1 <- dbGetQuery(dbConnection, recordsPerDayQuery) xlabText <- '2012'; ylabText <- 'Count' Records <- d1$Count heading1 <- 'Records per Day' plot1 <- qplot(as.Date(d1$Day), d1$Count, geom='line', color=Records, main=heading1, xlab=xlabText, ylab=ylabText) d2 <- dbGetQuery(dbConnection, otherRecordsPerDayQuery) Other <- d2$Count heading2 <- 'Other Records per Day' plot2 <- qplot(as.Date(d2$Day), d2$Count, geom='line', color=Other, main=heading2, xlab='2012', ylab='Count') # ... # Write data tables to mail text file. mailTextFilename <- '/path/to/stats-mail.txt' cat(paste('Hi,\n\n#', heading1, '\n'), file=mailTextFilename) write.table(d1, file=mailTextFilename, append=TRUE, row.names=FALSE, quote=FALSE, sep=' | ') cat(paste('\n#', heading2, '\n'), file=mailTextFilename, append=TRUE) write.table(d2, file=mailTextFilename, append=TRUE, row.names=FALSE, quote=FALSE, sep=' | ') # ... # Make PNG with plotted charts. png('/path/to/stats.png', width=1024, height=768) grid.newpage() pushViewport(viewport(layout=grid.layout(2, 1))) print(plot1, vp=vplayout(1, 1)) print(plot2, vp=vplayout(2, 1)) # ... dev.off() </code></pre> Related crontab sending stats mail once per week</h2> # m h dom mon dow command 30 4 * * 1 /path/to/stats.r 0 5 * * 1 mailx -s '[Example] Stats' -a /path/to/stats.png stats@example.com < /path/to/stats-mail.txt </code></pre> HTH. Xamarin FTW? 2012-09-24T00:00:00+00:00 Often, when developing a mobile app one wants to target iOS as well as Android (+ maybe MS’ OS). Now, this basically means developing the app from scratch and consequently maintaining it at least twice on different platforms, written in different languages (Objective-C and Java, that is), using different sets of tools etc. Cumbersome and potentially error-prone. Well, there’s a viable alternative: With Xamarin</a> one can write mobile apps targetting iOS and Android in C# using .NET (and native) libraries, sharing code (business logic, data & web service layers, utilities, …) while creating fully native UIs built on each platform’s own SDKs, providing access to all respective device capabilities. In addition to that, there’s for example MonoTouch.Dialog</a> making it easier and more fun to create table-based iOS UIs and for Android there’s a useful visual UI design tool</a> within the MonoDevelop IDE. Plus, there’s Xamarin.Mobile</a> aimed at exposing an unified API facade for accessing common device features. All interesting stuff when used sensibly. Here’s some demo code (which is loosely based on samples from the recommendable book “Mobile Development with C#”</a>) showing how mentioned shared layers could benefit: Simple model</h2> public class Tweet { public long Id { get; set; } public DateTime CreatedAt { get; set; } public string Text { get; set; } } </code></pre> Simple REST API client</h2> public class TwitterApiClient { const string BaseUrl = "https://api.twitter.com/1/statuses/"; public void DoWithTweetsForUser(string username, Action<IList<Tweet>> callback) { var webClient = new WebClient(); var url = string.Format("{0}user_timeline.json?screen_name={1}", BaseUrl, Uri.EscapeUriString(username)); webClient.DownloadStringCompleted += (sender, e) => { var tweets = (from element in JsonValue.Parse(e.Result) as JsonArray let tweetData = element as JsonObject select new Tweet { Id = tweetData["id"], CreatedAt = DateTime.ParseExact(tweetData["created_at"], "ddd MMM dd HH:mm:ss zz00 yyyy", null), Text = tweetData["text"], }) .ToList(); callback(tweets); }; webClient.DownloadStringAsync(new Uri(url)); } } </code></pre> Exemplary user code</h2> var apiClient = new TwitterApiClient(); apiClient.DoWithTweetsForUser("robi42", tweets => { foreach (var tweet in tweets) // Just for demo purpose. Debug.WriteLine("Tweet from {0}: {1}", tweet.CreatedAt, tweet.Text); }); </code></pre> And with .NET 4.5’s new async features</a> landing in Monoland soon, related code will get even more convenient to write and handle. Pretty neat, IMHO. What do you think? Play 2 Boilerplate 2012-09-21T00:00:00+00:00 A little project aimed at getting one up and running quickly with building a contemporary web app using Play 2</a> framework. Contains a bunch of current web dev best practices and niceties, from latest Twitter Bootstrap (LESS) & Backbone.js to CoffeeScript with CommonJS modules support & proper JS bundling. Here’re a couple of exemplary code snippets to whet one’s appetite: main.coffee</h2> {log} = require './utilities' $(document).ready -> window.app = {} log 'Hello, world!' return </code></pre> Application.scala</h2> object Application extends Controller { def index = Action { Ok(views.html.index(Messages("app.name"))) } } </code></pre> Get it on GitHub</a> while it’s hot. Hello, World! 2012-09-16T00:00:00+00:00