Years ago, while the GPLv3 was still being drafted, I got a chance to attend a presentation by Richard Stallman. He did his whole routine as St IGNUcius, and then at the end said he would be answering questions in a separate room off to the side. While the more causal nerds shuffled out of the presentation room, I went along with a small group of free software aficionados that followed our patron saint into the inner sanctum.
When my turn came to address the free software maestro, I asked what advantages the GPLv3 would have to a lowly hacker like myself? I was familiar with the clause about “Tivoization“, the idea that any device running GPLv3 code from the manufacturer should allow the user to be able to install their own software on it, but this didn’t seem like the kind of thing most individuals would ever need to worry about. Was there something in the new version of the GPL that would make it worth adopting in personal or hobby projects?
Interestingly, a few years after this a GPLv2 program of mine was picked up by a manufacturer and included in one of their products (never underestimate yourself, folks). So the Tivoization clause was actually something that did apply to me in the end, but that’s not the point of this story.
Mr. Stallman responded that he believed the biggest improvement GPLv3 made over v2 for the hobbyist programmer was the idea of “forgiveness” in terms of licensing compliance. Rather than take a hard line approach like the existing version of the GPL, the new version would have grace periods for license compliance. In this way, legitimate mistakes or misunderstandings of the requirements of the GPL could be resolved more easily.
Contrary to popular belief, LISP does not stand for “lots of irritating spurious parenthesis.” However, it is true that people tend to love or hate this venerable programming language. Whichever side of the fence you’re on, many of the ideas it launched decades ago have become staples of other newer languages. How much C code do you think it takes to make a functional LISP system? If you guessed more than 200, you’ll want to go look at this GitHub repository.
Actually, the code isn’t as good as the (sort of) literate programming white paper on the program, but it gives a good overview of how 200 lines of C code can produce a working LISP-like language good enough to create its own eval loop. It does lack memory handling and error detection, so if you really wanted to use it, you’d probably need to spruce it up a bit.
The BBC micro:bit has been with us for about eighteen months now, and while the little ARM-based board has made a name for itself in its intended market of education, we haven’t seen as much of it in our community as we might have expected.
If you or a youngster in your life have a micro:bit, you may have created code for it using one of the several web-based IDEs, a graphical programming system, TypeScript, or MicroPython. But these high level languages are only part of the board’s software stack, as [Matt Warren] shows us with his detailed examination of its various layers.
The top layer of the micro:bit sandwich is of course your code. This is turned into a hex file by the web-based IDE’s compiler, which you then place on your device. Interestingly only the Microsoft TypeScript IDE compiles the TypeScript into native code, while the others bundle your code up with an interpreter.
Below that is the micro:bit’s hardware abstraction layer, and below that in turn is ARM’s Mbed OS layer, because the micro:bit is at heart simply another Mbed board. [Matt] goes into some detail about how the device’s memory map accommodates all these components, something essential given that there is only a paltry 16 kB of RAM in hand.
You might wish to program a micro:bit somewhat closer to the metal with the Mbed toolchain, but even if that is the case it’s still of interest to read a dissection of its official stack. Meanwhile, have a look at our review of the board, from summer 2016.
There is often an observable difference between what is considered the right thing to do, and what actually is being done.
Terry Pratchett said it best when he made Death declare mercy and justice nonexistent: “TAKE THE UNIVERSE AND GRIND IT DOWN TO THE FINEST POWDER AND SIEVE IT THROUGH THE FINEST SIEVE AND THEN SHOW ME ONE ATOM OF JUSTICE, ONE MOLECULE OF MERCY.” (Note that Death is not shouting, he simply speaks upper case.)
We can’t measure justice and mercy. These are collective fictions — things we agree to believe to enable us to get along — and finding consensus on the immeasurable extends to political systems, religion, and most of economics. In a recent article [zwischenzugs] makes the point that methodologies in software development fall into the same category. Like collective societal fictions, methodologies tend to elicit strong emotional responses among those dealing with them.
A software development methodology is a playbook for getting from nothing to something. It’s a control system for how people working on the project spend their time. And there are a lot of these prescribed methods, from Agile to Waterfall, and any combination of letters is likely to turn an abbreviation for a methodology. An interesting game when hanging out in groups of software engineers is to start the “Have you ever tried the…” conversation. Just don’t expect to move to another topic anytime soon.
One disheartening aspect of methodologies is their resistance to scientific scrutiny. Two samples of development teams will differ wildly in so many characteristics that a meaningful comparison of the way they organize their work is not possible. Which will leaves us with anecdotes and opinions when discussing these things.
Current opinions regarding the impact of methodologies on the success of a project range from ‘marginal’ to ‘essential’. The latter position is mainly propagated by consultants selling agile certifications, so you may want to take it with a grain of salt. Whether a team adheres strongly to the methodology or adopts it in name only, it’s obvious they serve a purpose — but that purpose may not match the face value of the method.
The lights dim and the music swells as an elite competitor in a silk robe passes through a cheering crowd to take the ring. It’s a blueprint familiar to boxing, only this pugilist won’t be throwing punches.
Each match of the International consists of two 5-player teams competing against each other for 35-45 minutes. In layman’s terms, it is an online version of capture the flag. While the premise may sound simple, it is actually one of the most complicated and detailed competitive games out there. The top teams are required to practice together daily, but this level of play is nothing new to them. To reach a professional level, individual players would practice obscenely late, go to sleep, and then repeat the process. For years. So how long did the AI bot have to prepare for this competition compared to these seasoned pros? A couple of months.
People learn in different ways, but sometimes the establishment fixates on explaining a concept in one way. If that’s not your way you might be out of luck. If you have trouble internalizing floating point number representations, the Internet is your friend. [Fabian Sanglard] (author of Game Engine Black Book: Wolfenstein 3D) didn’t like the traditional presentation of floating point numbers, so he decided to explain them a different way.
Odds are that if you’ve been to the beach or gone camping or somewhere in between, you are familiar with inflatable products like air mattresses. It’s nothing spectacular to see a rectangle inflate into a thicker, more comfortable rectangle, but what if your air mattress inflated into the shape of a crane?
We’ve seen similar ideas in quadcopters and robots using more mechanical means, but this is method uses air instead. To make this possible, the [Tangible Media Group] out of [MIT’s Media Lab] have developed aeroMorph — a program that allows the user to design inflatable constructs from paper, plastic or fabric with careful placement of a few folding joints.
These designs are exported and imprinted onto the medium by a cartesian coordinate robot using a heat-sealing attachment. Different channels allow the medium to fold in multiple directions depending on where the air is flowing, so this is a bit more complicated than, say, a bouncy castle. That, and it’s not often you see paper folding itself. Check it out!