software development

38 Articles

How Not To Get Paid For Open Source Work

July 5, 2019 by 47 Comments

[Avi Press] recently made a Medium post sharing his thoughts on a failed effort to allow for paid users of an open source project. [Avi] is the author of Toodles, a tool to help organize and manage TODO items in software development. Toodles enjoyed unexpected popularity, and some of its users were large organizations. It seemed that Toodles was of value to people who could afford to pay, and they might even be willing to do so if [Avi] provided a way for them to do it. It turned out that the monetizing process was far from simple, and he ultimately wasn’t successful.

Before he even started, [Avi] thought carefully about things and found that even basic and preliminary questions were difficult to answer, such as:

  • How many people were actually using the software on a regular basis? Were they gaining quantifiable value from it?
  • What exactly would someone be buying? How would they pay, and how would it get delivered to them?
  • How could companies be charged for the tool while still offering it freely to individuals?
  • Is it even ethical to accept money for a project to which others have contributed? How could money be shared with contributors? How to fairly decide who gets how much?

In short, [Avi] discovered that much of the data he felt he needed in order to make these decisions didn’t exist, wasn’t easily accessible, or couldn’t be reliably measured. His experiment in adding a license and payment system (which always seemed to need more work than it should) yielded no fruit, as there were zero paid users anyway.

Regardless of whether “difficulty in shoehorning a paid license system into an open source project” should be filed under “Feature, not Bug” [Avi] does thoughtfully present the issues he encountered. Open source and getting paid are not necessarily mutually exclusive. Octoprint is one example of an open source project that eventually navigated these waters, but that doesn’t mean it was easy, nor does it mean there are established tools and processes.

“Good Code Documents Itself” And Other Hilarious Jokes You Shouldn’t Tell Yourself

March 5, 2019 by 159 Comments

Code documentation — is there anything more exciting than spending your time writing extensive comments? If I had to guess, your answer is probably somewhere along the lines of “uhm, yes, everything is more exciting than that”. Plus, requesting to document your code is almost like an insult to your well thought out design, this beautiful creation you implemented so carefully that it just has to be obvious what is happening. Writing about it is just redundant, the code is all you need.

As a result, no matter if it’s some open source side project or professional software development, code documentation usually comes in two flavors: absent and useless. The dislike for documenting ones code seems universal among programmers of any field or language, no matter where in the world they are. And it’s understandable, after all, you’re in it for the coding, implementing all the fun stuff. If you wanted to tell stories, you would have chosen a different path in life.

This reluctance has even formed whole new paradigms and philosophies claiming how comments are actually harmful, and anyone trying to weasel their way out of it can now happily rehash all those claims. But, to exaggerate a bit, we’re essentially villainizing information this way. While it is true that comments can be counterproductive, it’s more the fundamental attitude towards them that causes the harm here.

In the end, code documentation is a lot like error handling, we are told early on how it’s important and necessary, but we fail to understand why and instead grow to resent doing it again for that same old teacher, supervisor, or annoying teammate. But just like error handling, we are the ones who can actually benefit the most from it — if done right. But in order to do it right, we need to face some harsh truths and start admitting that there is no such thing as self-documenting code, and maybe we simply don’t understand what we’re actually doing if we can’t manage to write a few words about it.

So let’s burst some bubbles!

Continue reading ““Good Code Documents Itself” And Other Hilarious Jokes You Shouldn’t Tell Yourself” →

From Software To Tindie Hack Chat With Brian Lough

March 4, 2019 by 4 Comments

Join us Wednesday at noon Pacific time for the From Software to Tindie Hack Chat!

Brian Lough has followed a roundabout but probably not unusual route to the hardware hacking scene. Educated in Electronic and Computer Engineering, Brian is a software developer by trade who became enamored of Arduino development when the ESP8266 hit the market. He realized the microcontrollers such as these offered incredible capabilities on the cheap, and the bug bit him.

Since then, Brian has fully embraced the hardware hacking way, going so far as to live stream complete builds in a sort of collaborative “hack-along” with his viewers. He’s also turned a few of his builds into legitimate products, selling them on his Tindie store and even going so far as to automate testing before shipping to catch errors and improve quality.

Please join us for this Hack Chat, where we’ll discuss:

  • How software hacking leads to hardware hacking;
  • The creative process and how live streaming helps or hinders it;
  • The implications of going from project to product; and
  • What sorts of new projects might we see soon?

Continue reading “From Software To Tindie Hack Chat With Brian Lough” →

Crash Your Code – Lessons Learned From Debugging Things That Should Never Happen™

January 22, 2019 by 58 Comments

Let’s be honest, no one likes to see their program crash. It’s a clear sign that something is wrong with our code, and that’s a truth we don’t like to see. We try our best to avoid such a situation, and we’ve seen how compiler warnings and other static code analysis tools can help us to detect and prevent possible flaws in our code, which could otherwise lead to its demise. But what if I told you that crashing your program is actually a great way to improve its overall quality? Now, this obviously sounds a bit counterintuitive, after all we are talking about preventing our code from misbehaving, so why would we want to purposely break it?

Wandering around in an environment of ones and zeroes makes it easy to forget that reality is usually a lot less black and white. Yes, a program crash is bad — it hurts the ego, makes us look bad, and most of all, it is simply annoying. But is it really the worst that could happen? What if, say, some bad pointer handling doesn’t cause an instant segmentation fault, but instead happily introduces some garbage data to the system, widely opening the gates to virtually any outcome imaginable, from minor glitches to severe security vulnerabilities. Is this really a better option? And it doesn’t have to be pointers, or anything of C’s shortcomings in particular, we can end up with invalid data and unforeseen scenarios in virtually any language.

It doesn’t matter how often we hear that every piece of software is too complex to ever fully understand it, or how everything that can go wrong will go wrong. We are fully aware of all the wisdom and cliches, and completely ignore them or weasel our way out of it every time we put a /* this should never happen */ comment in our code.

So today, we are going to look into our options to deal with such unanticipated situations, how we can utilize a deliberate crash to improve our code in the future, and why the average error message is mostly useless.

Continue reading “Crash Your Code – Lessons Learned From Debugging Things That Should Never Happen™” →

A Cheat Sheet For Publishing Python Packages

December 13, 2018 by 5 Comments

[Brendan Herger] was warned that the process of publishing a Python package would be challenging. He relishes a challenge, however, and so he went at it with gusto. The exhausting process led him to share a cheat sheet for publishing Python packages with the goal of making the next time smoother, while also letting other people benefit from his experience and get a running start.

[Brendan] describes publishing a Python package as “tying together many different solutions with brittle interchanges.” His cheat sheet takes the form of an ordered workflow for getting everything in place, with some important decisions and suggestions about things like formatting and continuous integration (CI) made up-front.

The guide is brief, but [Brendan] has made errors and hit dead ends in the hopes that others won’t have to. The whole thing came about from his work in deep learning, and his desire to create a package that allows rapid building and iterating on deep learning models.

Deep learning is a type of machine learning that involves finding representations in large amounts of data. [Brendan] used it in a project to automatically decide whether a Reddit post contains Star Wars plot spoilers, and we recently saw it featured in a method of capturing video footage only if a hummingbird is present.

Warnings On Steroids – Static Code Analysis Tools

December 12, 2018 by 11 Comments

A little while back, we were talking about utilizing compiler warnings as first step to make our C code less error-prone and increase its general stability and quality. We know now that the C compiler itself can help us here, but we also saw that there’s a limit to it. While it warns us about the most obvious mistakes and suspicious code constructs, it will leave us hanging when things get a bit more complex.

But once again, that doesn’t mean compiler warnings are useless, we simply need to see them for what they are: a first step. So today we are going to take the next step, and have a look at some other common static code analysis tools that can give us more insight about our code.

You may think that voluntarily choosing C as primary language in this day and age might seem nostalgic or anachronistic, but preach and oxidate all you want: C won’t be going anywhere. So let’s make use of the tools we have available that help us write better code, and to defy the pitfalls C is infamous for. And the general concept of static code analysis is universal. After all, many times a bug or other issue isn’t necessarily caused by the language, but rather some general flaw in the code’s logic.

Continue reading “Warnings On Steroids – Static Code Analysis Tools” →

Warnings Are Your Friend – A Code Quality Primer

November 6, 2018 by 63 Comments

If there’s one thing C is known and (in)famous for, it’s the ease of shooting yourself in the foot with it. And there’s indeed no denying that the freedom C offers comes with the price of making it our own responsibility to tame and keep the language under control. On the bright side, since the language’s flaws are so well known, we have a wide selection of tools available that help us to eliminate the most common problems and blunders that could come back to bite us further down the road. The catch is, we have to really want it ourselves, and actively listen to what the tools have to say.

We often look at this from a security point of view and focus on exploitable vulnerabilities, which you may not see as valid threat or something you need to worry about in your project. And you are probably right with that, not every flaw in your code will lead to attackers taking over your network or burning down your house, the far more likely consequences are a lot more mundane and boring. But that doesn’t mean you shouldn’t care about them.

Buggy, unreliable software is the number one cause for violence against computers, and whether you like it or not, people will judge you by your code quality. Just because Linus Torvalds wants to get off Santa’s naughty list, doesn’t mean the technical field will suddenly become less critical or loses its hostility, and in a time where it’s never been easier to share your work with the world, reliable, high quality code will prevail and make you stand out from the masses.

Continue reading “Warnings Are Your Friend – A Code Quality Primer” →