Dani Rodríguez picture.

I'm Dani Rodríguez, but I'm usually known online as danirod.

I’m a creative software engineer living in Madrid, Spain, specialized in web development, who likes to play with web frameworks like Ruby on Rails, Django or WordPress. Online, I'm also known for being the founder and video producer at makigas.

This is my site, currently hosting my blog articles and linklog bookmarks. You may reach me via e-mail. You can also find me on Twitter, LinkedIn, GitHub, or through any of my social media profiles and online accounts.

By the way, I'm available
for hire

I'm looking for a new job in 2018. So, if casually you are (or your company is) looking for a position, I published my resume on this site. You may also find me on LinkedIn or get in touch with me by other ways.

Recent stuff

    gtk-rs tutorials for Rust

    This unofficial series for gtk-rs provides some tutorials for the key aspects of the GTK Rust library – the most important GTK+ binding for the Rust programming language.

    This unofficial GTK Rust tutorial series will focus on documenting important GTK features, demonstrating how they are used in practice, and displaying some Rusty software techniques along the way, as we explore what GTK GUI development in Rust is like.

    Via This week in Rust (slowly catching up on my feeds)

    Receive SSH login notifications through Slack or Discord

    I have a problem. Sometimes I'm slightly paranoid about computer security. Sometimes I wonder if the pages I visit are being logged somewhere when I'm on my university network. And when it comes to servers I manage, sometimes I wonder if I'm actually alone or not. Logs aren't enough, as someone clever enough may wipe their footprints after getting access to the server. If you want to reliably track break-in attempts, you'll have to log them outside your server, somewhere where your lurker won't be able to remove the traces. How about one of the many chat applications that are always running on my phone?

    Give `git merge` some love

    This article exposes some of my concerns about the different integration strategies available in Git. Summarizing the Git theory which you may already know, the three most common integration strategies are merge, rebase and squash. I’ve used each strategy on different occasions, and while I’m not keen on a particular one, I like rebase the least.

    I’m not going to try to convince anyone because everyone will have their preferences, plus part of engineering is knowing when to use the best approach and knowing that there is not a hammer for all the nails. But the purpose of a VCS should still be to make easy to track and understand changes in the codebase, and to make simple to detect and fix bugs. A pretty history graph helps and is a good think, but it should be a secondary thing that never compromises the utility of having the right amount of information at your tips to do your work the best you can. Pragmatical use of Git is cool.

    Rectball 0.4.10 is now available

    I’m releasing Rectball 0.4.10. It doesn’t have much new features, but it fixes a few bugs found in Rectball 0.4.9. It also brings back Kotlin to the codebase. This is the second time I try to add Kotlin code to the Rectball codebase. I expect to succeed this time. Download the game from the Google Play Store or look at the GitHub release for detailed changes.

    Rectball 0.4.9 is now available

    Yesterday I released Rectball 0.4.9, the first Rectball release in three months. This version is focused on bug fixes, such as finally fixing the blurry fonts on high density screens.

    Note that the game version available in the Google Play Store is 0.4.9.1, as I had to roll out a hotfix a few hours later after deploying 0.4.9 because of a regression found in the settings saving and loading system.

    I’m still refactoring some game components. An additional 0.4-series release is still expected with more internal changes very soon, next week probably. However, I can already guarantee that a 0.5.0 release is coming up in September with a big usability change that it’s going to make the game easier to play.

    Frontend development is not that bad

    In his latest blog post, Coder frozen in 2009 awakens to find frontend development is not awful, Ruby developer Richard Schneeman discusses the current state of frontend. And it turns out, despite how complicate it looks sometimes given all the frontend tools there exist these days, it’s not that bad.

    I’d like to focus on the jQuery side because it’s important to know that many things that used to be done in jQuery a few years ago have been possible to replicate using vanilla JavaScript for a couple years in all browsers.

    Gedit is no longer maintained

    UPDATE, 2017-08-11: It turns out Gedit found two maintainers, actually; as it can be seen at their wiki page. I’m adding a link to the HN thread I saw as it seems it was sent almost at the same time new maintainers were announced.

    According to this message posted in the Gedit mailing list three weeks ago (that for some reason hasn’t pop out until this week), Gedit is no longer maintained. They are looking for someone to maintain the software including all the plugins.

    Gedit was my number one graphical choice years ago, as a general plain text editor and when working with programming languages that did not require an IDE such as PHP or Python. The user interface was easy and the software felt powerful with all those syntax colours and settings.

    Then GNOME 3 came and they rewrote the UI and they made it almost unusable by removing most of the menu commands and moving things to places it made no sense at all. geany is still a good choice I use on VMs, even though for serious work I moved to VSCode (open source).

    Mistakes to avoid when developing Atom feeds

    My blog syndicates its new contents through an Atom feed so that people can subscribe to updates. And according to the server logs, people use them (that was the initial point of having them; so, thanks!). However, it wasn’t until recently that I actually read the standard and a few other online sources, when I discovered that a few things, such as the entry identifiers, have been done wrong all this time. I’m documenting these issues publicly in order to save for future reference.

    Sibbell: get updates on the GitHub repos you care about

    It is too easy to star a project on GitHub, maybe because you consider it is a fun experiment or because it actually matters to you. However, keeping track about updates (say about repositories your project depends on), is harder. You can watch a repo, but then you’ll also be subscribed to all the clutter that sometimes issues and PRs cause.

    Sibbell is a service that, once connected to your GitHub account, will sync your starred repos, and then, it will automatically check for new releases or tags on those repositories. Whenever one of your starred repositories gets a new release, you’ll receive a notification on your e-mail.

    Free tier allows you to receive updates on your starred repositories as they happen; paid tier allows you to digest those updates into a single mail per day or week, and disable starred repositories you are not interested in knowing about.

    Port tunneling with SSH

    Here is another quick one that is also easy to forget. One of the many uses of SSH is local and remote port forwarding. Using local port forwarding, you can set up a socket between a port in your local machine and your SSH server. Whenever a communication is established on that local port, it will be forwarded to the server and then, made. This has some interesting use cases, such as connecting to local services (web administration panels, databases…) or acting as a jump server or just a proxy server.

More posts in the archives »