Programming Leftovers
-
Observing trees through the seasons with ForestryPi
Ed returned to university to study aquaculture and fisheries, where he was struck by the number of examples of academic papers detailing “really cheap bits of computer equipment to monitor XYZ” in poor parts of the world. “I was always really interested in those papers, and how little, cheap computers really can democratise science and give everyone the chance to do fairly complicated stuff that would have, a few years ago, required thousands of pounds worth of kit.” Having read a paper last year about monitoring a forest canopy, Ed decided he could do something similar, despite being “no expert coder.” A Raspberry Pi Zero, Witty Pi 3 real-time clock, fish-eye lens, 20,000 mAh battery pack, and a 32GB SD card, plus a plastic casing, formed the basis of the ForestryPi setup.
-
Writing a Chat Client from Scratch
There are a lot of things that go into building a chat system, such as client, server, and protocol. Even for only making a client there are lots of areas of focus, such as user experience, features, and performance. To keep this post a manageable size, we will just be building a client and will use an existing server and protocol (accessing Jabber network services using the XMPP protocol). We’ll make a practical GUI so we can test things, but not spend too much time on polish, and look at getting to a useful baseline of features.
You can find all the code for this post in git. All code licensed AGPL3+.
-
Schedule your holiday for 2038
The end of the year is approaching, so it’s time to start scheduling your holidays for the next year. But I decided to go a step further and already planned those for 2038! Why? Well, a few weeks ago I gave a presentation to students, when I realized they had no idea what I was talking about when mentioning the Y2K-problem. Most of them weren’t even born yet in the year 2000! I also realized at that moment that I’m probably becoming a grumpy old man, but that’s a subject for another post… ;-) But I also found out a new similar problem is approaching in … 2038!
-
Tech systems amplify variety and that's a problem
I recently read "Designing Freedom" by Stafford Beer. It has me thinking a lot about the systems we have in place and something clicked for why they feel so wrong despite being so prevalent. I'm not sure what any solutions look like yet, but outlining a problem is the first step, so let's go.
-
Our First Peer-Reviewed Statistical R Packages!
These packages were peer-reviewed by statisticians and developers to conform to a set of standards we’ve developed with community input. These standards cover areas such as documentation, testing, algorithm design and interoperability. As part of the review process, authors have also annotated their source code to document how and where they comply with these standards.
-
A Better Way to Borrow in Rust: Stack Tokens | Armin Ronacher's Thoughts and Writings
As a Rust programmer you are probably quite familiar with how references work in Rust. If you have a value of type T you can generally get various references to it by using the ampersand (&) operator on it. In the most trivial case &T gives you just that: a reference to T. There are however cases where you can get something else.
[...]
I maintain a crate called fragile. The purpose of this crate is allow you to do something that Rust doesn't want you to do: to send a non Send-able type safely to other threads. That sounds like a terrible idea, but there are legitimate reasons for doing this and there are benefits to it.
There are lots of interfaces that through abstractions require that your types are Send and Sync which means that it needs to be send-able to another thread and self synchronized. In that case you are required to provide a type that fulfills this purpose. But what if the type does not actually cross a thread boundary or not in all cases?