Here is a quick overview of the Linux Boot Process, if you are a little rusty. After all, it’s not every day that you need to look into, troubleshoot or adjust the boot process of a Linux box. This might come handy before your next SysAdmin job interview too.
- Make it easy to change
- Make it really readable
- Make it work
- Make it elegant
- Learn from accomplished practitioners
He is also listing a few books to learn from (the Amazon links are those of Eric – I have no idea if they are affiliated or not, but if they are, he’ll get the credit, like he deserves):
- Clean Code: A Handbook of Agile Software Craftsmanship
- The Clean Coder: A Code of Conduct for Professional Programmers
- The Pragmatic Programmer: From Journeyman to Master
- Working Effectively with Legacy Code
- Test Driven Development: By Example
- Code Complete: A Practical Handbook of Software Constructio
And while I’m still pretty happy with my MATE desktop, it’s nice to see people taking an effort into making things better. Two particular features caught my eye in the release announcement:
Multiple-monitor support! Each monitor is treated as an independent entity – making it great for presentation systems which use a temporary monitor or for workstations which utilize an array of monitors for various tasks.
This is super cool! Current iterations of Gnome and KDE do support multi-monitor setups, but they treat all monitors as a single work space. Using multiple virtual work spaces is supported, but one can’t switch a work space on a particular monitor without switching the corresponding work space on all other monitors. I haven’t tried Lumina Desktop myself yet, but from the announcement it looks like they support exactly that – switching monitor work spaces individually and not all together.
Personalize the initial settings for users with a single configuration file!
This is how things used to be in the old days (back when I was using AfterStep and the like). A single configuration file is super convenient when you want to move your setup from machine to machine. Both Gnome and KDE these days utilize numerous configuration files and GUI tools to manage them, which makes automating these setups with tools like Ansible very impractical.
I’m way too busy with work stuff these days to try a different desktop environment, but I will keep an eye on the Lumina Desktop Environment for now. Maybe one slow Friday I’ll give it a spin.
Slashdot is running a discussion thread on what are the best browser extensions these days. The comments cover a variety of browsers and all kinds of extensions. The most popular are, of course, well know. But there are a few gems here and there.
For me personally, I’ve picked the Tab Snooze extension. I’ve tried quite a few tab management solutions, and neither one of them fits my needs even though most tried (I want to run a single browser window, with dozens or hundreds of tabs open, but I want them to be organized into groups and hidden until later, when I need them). Tab Snooze approaches the problem from a slightly different angle. It sets the reminder for when to reopen the tab, and once that’s done, it closes the tab. You can find all snoozed tabs and open them before the due date, of course.
This works surprisingly well for me. If only I could control the opening of the tabs with something like “17 tabs were woken up and are about to be open. Continue?”. Currently, I get the notification and the tabs are open automatically, which is often not at the best time. Waking up a lot of tabs can slow the system down a bit and get in the way of things on which I’m working at the time.
TravisCI – a continuous integration service – shares some of the insights from over 2,000,000 builds they’ve run, in an blog post called “What We Learned about Continuous Integration from Analyzing 2+ Million Travis Builds“. For me, the most valuable bit is about the reasons for failing builds, which clearly indicates the need for and the importance of unit, integration, and UI tests:
Around 20% of all builds fail. There is a variation based on the language – for some programming languages, testing is part of the process and culture – for others it’s an acquired tool. Once you do implement testing, most of your builds will run. You’ll cancel very few. But about 20% will fail due to failed unit tests, configurations, or environment setups. Catching these 20% before it hits production is super important.
A few days ago BitBucket announced the re-worked dashboards, which are now much more focused on the Pull Requests that you’ve created or need to review, rather than lists of repositories that you have access to. I’ve enabled the feature for my team and it looks super awesome!
If you’ve been suffering from being lost in dozens or hundreds of projects and missing out on the Pull Requests activity, check them out. You’d be surprised.
Slashdot readers notice first that “Popular BitTorrent Search Engine Site Torrentz.eu Mysteriously Disappears“.
Bummer! This was my torrent search engine of choice … And this is just days after I’ve upgraded my Internet connection.
I’m sure there is a replacement out there, but habits are so difficult to change. I still hope this is a temporary issue.
With August, a month when so many people take their annual leave, upon us, CommitStrip nails it once again:
I’ve been hiring, firing, and working with developers of all sorts for the last couple of decades. In those years, I realized that each developer is very unique – their strong and weak sides, knowledge gaps, working rhythm, social interaction, communication abilities, etc. But regardless of how unique each developer is, it is often useful to group them into expertise levels, like junior and senior. Companies do that for a variety of reasons – billing rates, expectations, training required, responsibility, etc.
And this is where things get tricky. One needs a good definition of what a senior developer is (other definitions can be derived from this one one too). There is no standard definition that everybody agrees upon, so each one has their own.
I mostly consider a senior developer to be self-sufficient and self-motivated. It’s somebody who has the expertise to solve, or find ways of solving any kind of technical problems. It’s also someone who can see the company’s business needs and issues, and can find work to do, even if nothing has been recently assigned to him. A senior developer would also provide guidance and mentorship to the junior teammates. I’ve also came to believe that people with the real expertise have no problem discussing complex technical issues in simple terms, but that’s just a side note.
Anyway, recently, I came across this very short blog post, which sent me a spree of pages, charts, and discussions:
Because of this “What is a senior developer?” conversation on Reddit, I am reminded of the Construx Professional Development Ladders, as mentioned to me long ago by Alejandro Garcia Fernandez. Here is a sample ladder for developers.
The original article for the Reddit discussion – “The Conjoined Triangles of Senior-Level Development” is absolutely brilliant. In the beginning it provides a chart of the conjoined triangles of senior-level development, which reflects my definition and understanding:
But it doesn’t stop there. It dives deeper into the problem, and, eventually features this Venn diagram:
.. and more. By now, I’ve read the article three times, but I keep coming back to it – it just makes me think and rethink over and over again. Once it settles in my head a bit, I’ll look deeper into the Professional Development Ladder and it’s example application to the senior developer.
Overall, this is a very thought provoking bunch of links.