A friendly user submitted the (lib)curl bug report #2154627 which identified a problem with our URL parser. It doesn't treat "file://" as a known protocol if the locale in use is Turkish.
This was the beginning of a minor world-moving revelation for me. Of course this is already known to mankind and I'm just behind, but really: lots of my fellow hacker friends had no idea either.
So "file" and "FILE" are not the same word case insensitively in Turkish because 'i' is not the lowercase version of 'I'.
Back to strcasecmp: POSIX pretty much makes the function useless by saying that "The results are unspecified in other locales [than POSIX]".
I'm a bit annoyed by this fact, as now I have to introduce my own function (which thus cannot use tolower() or toupper() since they also are affected by the locale) and use since the strings in our code is clearly used for "english" strings so file and FILE truly are the same string when compared case insensitively...
I just thought I'd share a lesson I learned today:
I've been struggling for a long time at work with a gdb problem. When I set a break-point and then single-step from that point, it sometimes (often) decides to act as if I had done 'continue' and not 'next'. It is highly annoying and makes debugging nasty problems really awkward.
Today I searched around for the topic and after some experiments I can now confirm: if I remove all uses of popen() I no longer get the problems! I found posts that indicated that forking could confuse threaded programs, and since this program at work uses threads I could immediately identify that it uses both popen() and system() and both of them use fork() internally. (And yes, I believe my removal of popen() also removed the system() calls.)
And now I can finally debug my crappy code again to become less crappy!
My work PC runs glibc 2.6.1, gcc 4.1.3 and gdb 6.6. But I doubt the specific versions matter much.
I find it hilarious that IDG.se out of all publications put together the "best developers in Sweden" and lists the top-75 ones (article in Swedish). It is funny because IDG is not exactly a place flooding over with technical (or any kind of in-depth) knowledge, so obviously they got this list by getting input from others and how on earth can they then compare person A against person B when they've been mentioned by different sources? Also, just lumping every kind of "developer" into the same pile and then trying to order them is also an interesting challenge. Clearly some of these devs are more project managers, theorists and similar, while others are hardcore kernel-hackers, C coders or Java dudes.
I don't mean to bash the people present on this list, as I'm sure I would also liked being present if I had been that. I just think the list fits so well into IDG's style of populistic journalism. The audience wants top-lists, let's give them another one!
Or perhaps I'm just jealous that I'm not included! 😉
Today (uh make that yesterday since we're now past midnight here...) around lunch I drove my two kids over to my parents in law and got back to my house to host four friends (associated with a company that shall remain nameless in this blog - at least for now) coming over to discuss some work stuff.
It was great fun sitting in my living room chatting for a few hours, having a cup of coffee and instead of using a fancy company white board I brought my kids' drawing easel (oh we love IKEA). The picture is the actual model we used, called "MÃ…LA".
And we did indeed manage to get some good decisions done and some proper architectural stuff set. Admittedly, my kids' drawing pens were a bit thin and not as thick and "powerful" as the ordinary office white board pends tend to be.
Frederick Brooks wrote this classical book already back in 1975 and added a few extra chapters for the twenty years anniversary 1995...
Large portions of it feels of the age and there's a lot of talk about Fortran, System/360 and PL-1 as if we should know about them (which made me fast forward over some chapters). But there are gems as well, and the most significant things people seem to remember Brooks' book for are still pretty valid and fine.
Adding more people to a project leads to the need for more communication and thus it may slow down development rather than speed it up. Also known as Brooks's law.
Given the complexity of software and software development, there's no single method or concept that will lead to an improvement by an order of magnitude - within a decade. There's No Silver Bullet. (This section was not in the original edition of the book.)
The risks involved when rewriting something and wants to fix everything that was wrong in the previous version so you over-work and over-design the successor. The so called Second system effect.
A lot of the book is spent on thoughts and theories around how to manage really really large software projects, like when you involve thousands of persons. Is it even possible to make such huge projects successful and if so, what does it take? The extra chapters do indeed add value since they offered Brooks a chance to re-evaluate his earlier claims and ideas and to check what seemed to be truths and what mistakes he did in the original edition.
A very interesting read that I'm glad I finally got time to get through!