Programming Leftovers
-
Burkhard Stubert ☛ A Yocto Recipe for Qt Applications Built with CMake – Burkhard Stubert
How hard can it be to write a Yocto recipe for building a Qt application with CMake? Actually, it turns out to be pretty hard. I have seen my fair share of slow-and-dirty workarounds (nothing is ever quick with Yocto, not even the diry workarounds) how to force the Qt application into the Linux image and onto the device. Over the years, I turned my own slow-and-dirty workarounds into a hopefully quick-and-clean solution. Here it comes.
-
Adolfo Ochagavía ☛ 10 years in Open Source
Today marks 10 years since my first pull request to the Rust compiler. Though I’m no open source legend, to me it’s an important date still. As I’ve mentioned in the past, my involvement in Rust was pivotal to my development as a software engineer, so I can’t let this day pass without a mention in my blog!
-
Screenplay Studios Inc dba Graphite ☛ Why Facebook doesn’t use Git
I work on building Graphite, which is fundamentally inspired by internal Facebook tooling. When I set out to create a startup with friends, I had never heard of Mercurial - despite being passionate about all things devtools. My previous engineering experience has included personal projects, college homework, iOS development at Google, and infra development at Airbnb. Throughout my life, git was as common as water. It was so common, in fact, that I assumed it was the only viable tool for creating and managing code changes.
-
Lars Wirzenius ☛ 40 years of programming
In April, 1984, my father bought a computer for his home office, a Luxor ABC-802, with a Z80 CPU, 64 kilobytes of RAM, a yellow-on-black screen with 80 by 25 text mode, or about 160 by 75 pixels in graphics mode, and two floppy drives. It had BASIC in its ROM, and came with absolutely no games. If I wanted to play with it, I had to learn how to program, and write my own games. I learned BASIC, and over the next few years would learn Pascal, C, and more. I had found my passion. I was 14 years old and I knew what I wanted to do when I grew up.
When I was learning how to program, I thought it was important to really understand how computers work, how programming languages work, and how various tools like text editors work. I wanted to hone my craft and produce the finest code humanly possible. I was wrong.
This essay is a condensation of what I wish I had been told after I had learned the basics of how to code. Instead, I was told, in person and in magazine articles, that by the time I would be twenty five years old, I'd be too old to work as a programmer. It was critical that I learn as many algorithms, data structures, and languages as quickly as possible. Programming was, after all, a young man's game, and required being able to stay up all night, every night, to crank out more code than anyone else. That was the only way to succeed. It turns out that none of that was true: not the part about youth, nor the part of missing sleep, and especially not the part about gender.
As I write this essay, it will soon be forty years to the day since I first wrote computer code. I've managed to support myself by developing software, and I still write code every day. There is nothing else I would rather do for a living. I can't point at enormous successes and impressive feats, but I hope that surviving for decades in the industry gives me sufficient credentials to speak about software development.
This essay discusses some of the things I've learned about how to successfully build software. These are things I've learned from my own experience; I'm not a researcher, and there are few references to sources, and this is largely not supported by evidence. I'm basing this essay on my own experience, and if you disagree, that's fine.
My goal in this essay is to get the reader to think, to research, to learn, to ponder. My goal is not to tell the reader how to think, what to think, how things are, or to give the answer to every question about every aspect of the process of building software.
-
[Old] Hillel Wayne ☛ What We Know We Don't Know: Empirical Software Engineering
Empirical Software Engineering is the study of what actually works in programming. Instead of trusting our instincts we collect data, run studies, and peer-review our results. This talk is all about how we empirically find the facts in software and some of the challenges we face, with a particular focus on software defects and productivity.
-
Shell/Bash/Zsh/Ksh
-
Gregory Anders ☛ State of the Terminal
I’ve also found that many people who use terminal based tools (including shells like Bash and editors like Vim) know very little about terminals themselves, or some of the modern features and capabilities they can support.
In this article, we’ll discuss some of the problems that terminal based applications have historically had to deal with (and what the modern solutions are) as well as some features that modern terminal emulators support that you may not be aware of.
-
-
Rust
-
Rust Weekly Updates ☛ This Week In Rust: This Week in Rust 538 [Ed: Rust publishes an ocean of Microsoft links, promoting a proprietary codeforge]
Hello and welcome to another issue of This Week in Rust!
-
-
Licensing / Legal
-
[Old] Joel Spolsky ☛ Strategy Letter V – Joel on Software
Every product in the marketplace has substitutes and complements. A substitute is another product you might buy if the first product is too expensive. Chicken is a substitute for beef. If you’re a chicken farmer and the price of beef goes up, the people will want more chicken, and you will sell more.
A complement is a product that you usually buy together with another product. Gas and cars are complements. Computer hardware is a classic complement of computer operating systems. And babysitters are a complement of dinner at fine restaurants. In a small town, when the local five star restaurant has a two-for-one Valentine’s day special, the local babysitters double their rates. (Actually, the nine-year-olds get roped into early service.)
All else being equal, demand for a product increases when the prices of its complements decrease.
-