This year, I want to make danirod.es my main online identity and stop relying so much on social networks for hosting my content, such as my photos or my status updates. This will not change the use I make of social networks, so if you follow me on social networks, not much will be noticeable. This blog post will help me control the list of changes and features I’ll add to my website through the year in order to make it open, federated, and independent.
Este año, quiero convertir danirod.es en mi principal identidad online y dejar de depender tanto de las redes sociales para alojar mi contenido, como fotos o actualizaciones de estado. Esto no cambiará el uso que hago de las redes sociales, así que si me sigues en una red social, no vas a notar demasiados cambios. Esta entrada de blog me ayudará a documentar la lista de cambios y características que voy a implementar en mi página web a lo largo de este año para volverla abierta, federada e independiente.
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)
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?
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.
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.
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.
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.
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).
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.