Whether or not to regularly spend time and effort upgrading dependencies can be a contentious topic on development teams. Advocates argue that not doing the work allows tech debt and bitrot to accumulate, while opponents accuse them of chasing new-and-shiny novelties while ignoring what’s actually valuable to the product. Despite what feels like an unending amount of time spent on the churn of upgrades, security teams still struggle to get risky old dependencies patched, and developers complain about using deprecated tools.
After being burned several times by excruciatingly tedious forced upgrades of vulnerable or broken legacy codebases, I’ve come down firmly on the side of favouring frequent updates — with plenty of flexibility and some caveats.
I’ve updated my recommended reading list for software professionals (introduced and explained here) with a new section on people and project management.
Don’t think you need the word “manager” in your job title to benefit from learning these skills. If you want to make yourself more useful to a team, teach others, help your projects succeed, or guide groups to making good decisions, these books will help.
I’ve just added a new section to my recommended reading list for software professionals (introduced and explained here). This new section covers the presentation of information, design, and user interfaces/experiences.
I’m not a designer, and reading these books won’t make you one either. But every developer should know how to present information and interfaces clearly and comprehensibly.
You can find the list itself here.
I’ve started putting together a list of the “core” books I recommend for people interested in exploring different facets of our field. I certainly don’t think you need to read all of them to be a capable software professional; rather it is the list I would put together if asked about how to learn more about specific areas.
This list came about because after compiling similar lists two or three times over the years in various places and formats, I’m following good development practice and factoring it out for reuse and sharing.
You can find the list itself here.
The list is far from complete; in fact today I’m starting with just one area: the culture and history of our field. Over time I will add sections on technical system design and architecture; project and people management; data visualization, information presentation, and user experience design; etc. Let me know if there are areas you want covered, or if you have recommendations of your own!
The rexiv2 library crate (available on crates.io) for Rust provides read and write access to media file (mainly photo) metadata in the Exif, XMP, and IPTC formats. Many file formats are supported, including of course JPEG, PNG, TIFF, XMP sidecar, some camera raw formats, and various others.
You can view the documentation here, get the source code, and report bugs or contribute code.
Matthew Garrett's timely post GPL enforcement is a social good reminded me to revisit my old Geeky Guide to Giving list, and to reprise and update it; this time with a Software Freedom theme. So, below, a list of charitable organizations seeking your help to advance the cause of Free/Open Source software.
Doug Crockford gave a talk at the University of Waterloo last night as part of the Yahoo! Hack-U (University Hack Day), on the same topic as his new book, JavaScript: The Good Parts. I was lucky enough to get a seat, and have tried to condense my nine pages of notes into an overview of the highlights of his talk. Though I've rewritten parts, all of the content and wisdom is Doug's — I'm just the humble scribe. Of course, any errors of transcription are mine.
Makefiles are the granddaddy of build systems. Though falling out of favour relative to more modern systems like SCons and ant, make is still the lingua franca of software builds, particularly in the C and C++ parts of the open source world. Because of this, it is imperative to have at least a basic understanding of makefiles and their use.
There are plenty of tutorials introducing the fundamentals of makefile syntax, and a handful that show off some advanced features. There are very few, however, that actually show how to write a useful makefile, or that introduce makefile conventions and patterns. For me, this meant that writing makefiles became an arduous process of stringing together snippets from various places, and hoping they interoperated harmoniously. Frustratingly, I'd often learn of a new feature months later and rip out half of the file and replace it with a single line. Worst of all, I had no idea if what I was doing was “conventional” or even passable as a serious makefile.
I am afraid that I have to admit that the development of this site has until now proceeded in what any programmer must consider a state of sin: it was not under version control. Sure, I had periodic snapshot backups, but forget about versions, branches, and reverts.
The reason for this is that I was under the mistaken impression that my VCS of choice, git, made it difficult to set up remote branches. I think my confusion stemmed from the fact that it is somewhat tricky to set up public-facing ones with good commit-access control etc (which is why GitHub is so great).
Now that I looked into it more, I find it's actually tremendously easy, and
I've got a really great work-flow set up: I have a master repo on the server,
a development repo on my laptop, and another one in the directory from which
the site is served. I can make changes on my laptop (and thanks to the magic
of makefiles and m4 macros, keep a separate dev config file), and then push
those to the master repository. When I'm ready to launch, I just pull them to
the serving repo and run a make prod.
I am a software developer in Ontario, Canada, sharing interesting pieces of information about technology, programming, and other subjects. More details can be found in my biographic summary.
In addition to the blog, I also have a library of things I've written, along with books and links written by others that I find useful.
