Well this sucks. The people who control MongoDB changed its licensing last year from open-source to closed-source. I would say that it was a very popular alternative in the many database-like offerings out there.
So it looks like everybody’s dumping them from operating systems’ distribution systems and now HomeBrew has followed suit.
Okay, so it’s been a year since Microsoft purchased github for a cool US$7.5B. In today’s terms that’s merely Amazon’s annual gross in sales. Remember when a million dollars seemed like a lot of money?
For some of you who aren’t coders, you probably don’t understand the impact of this move especially within the context that Microsoft has a history of being sued for very questionable competitive practices. Github was likely the largest collection of freely-available source code in the public domain (also known as “open source”) and probably still so even after the acquisition. Do we even have to ponder the “why?” question at all?
Github had not just most of the open source code but it also contained countless private repositories from countless other entities. Imagine that almost overnight Microsoft then gained access to all the privately-held coding secrets of their competitors.
What does Microsoft really think of open source?
“The paradigm of freely sharing computer source code—a practice known as open source—traces back to the earliest commercial computers, whose user groups shared code to reduce duplicate work and costs. Following an antitrust suit that forced the unbundling of IBM’s hardware and software, a proprietary software industry grew throughout the 1970s, in which companies sought to protect their software products. The technology company Microsoft was founded in this period and has long been an embodiment of the proprietary paradigm and its tension with open source practices, well before the terms “free software” or “open source” were coined. Within a year of founding Microsoft, Bill Gates wrote an open letter that positioned the hobbyist act of copying software as a form of theft.” ~ Microsoft and open source – wikipedia
Is “Inner Source” actually Open Source?
Microsoft is now embracing something they’re calling Inner Source for their own internal coding. Clearly, Microsoft loves the infrastructure of tools and the free availability of open source… only they truly do not understand the idea of then sharing back with others.
Microsoft’s own Inner Source is like walking around the table in a poker game, freely viewing the cards in your opponent’s hands, purposely hiding your own cards and then expecting to be able to continue playing in the game.
Sorry, but I have to call bullshit on all this. Microsoft isn’t to be trusted. They’re not our friends. They’re stealing secrets from their competitors and they’re using those secrets to create closed-source software (business as usual). They’re destroying the very ethos of open source with every passing day.
Today’s post is a revisit of the synesthesia topic. Earlier I talked about an innovative new means of creating colorized tablature to promote this cross-wiring of the senses in new piano students…
Last weekend (for this installment), I thought it would be interesting to attempt to write a MIDI version of this so that I could create that same sort of feedback using color. Only this time, I would be playing the notes directly on my Yamaha digital keyboard.
Of course, this needs a Type A to Type B USB cable to connect the computer with the Yamaha digital keyboard. Mine is a P-45 in case you were wondering. It also requires Yamaha’s USB-MIDI driver (available from their website).
As usual, I’ve provided the source code so that you can also play with this if you’d like. Just verify that you’re on the OG-missing-C8 branch if you’d like the latest. At the moment, the master branch is just the original fork of ScottMorse’s work.
Fortunately, I just managed to create something that seems to work and the syntax isn’t too far off from the expected.
Kivy – An open-source Python library for rapid development of applications that make use of innovative user interfaces, such as multi-touch apps.
The Internet of Things (IoT) is the likely future of gadgets and devices that you’ll have in your homes and cars (if you don’t already) as well as technology that you wear. As a minimal criteria, these things use the cloud to gather and store information. In a way, even smartphones fall into this category if you think about it. Amazon’s Echo device is a good example.
For many of us who self-identify as “makers”, we use small computers with similar capabilities and we create these type of gadgets. Often when we’re coding software in this space, the Python language is the usual choice for the task.
Until now, we’ve not had many options for displaying graphical menus on such tiny screens other than the full “Desktop” GUI of some Linux-like operating system which didn’t really work, to be honest.
A relatively new technology is the Kivy library. Imagine being able to describe the many screens you’d find in an application, whether it’s a smartphone or the touchscreen of a printer or even a watch. Then Kivy takes care of the rest for you, rendering those screens using a graphics engine behind-the-scenes. It even manages clicks and other gestures, getting these to fire off portions of your code.
Kivy comes equipped with an impressive collection of pre-defined screen widgets as well as the ability to create your own custom types. And you get all this for the low, low price of free (unlike its $5K+/year—priced competitor Qt).
I’ve had the pleasure of working on an almost daily basis with Kivy over the last two months and I must say that I’m still just as fond of it now as the day I originally learned of it.
If you’re a coder and you know Python, I would suggest that you add Kivy to your toolbelt. You’ll find that it’s easy to use and worth the effort you put into it.
I was interested in exercising Github’s REST API so I burned out a quick-and-dirty applic-ation to display some statistics.
Honestly, a tool like this would be useful for a hiring manager in the software develop-ment space. Imagine being able to enter a list of ten accounts and to see a side-by-side comparison of the coders like this.
Puffed-up Like a Cheeto
I’m surprised at the number of Github accounts which are mostly filled with dead forks of someone else’s code with no contributions whatsoever. I don’t know if people are trying to pad their profile intentionally or if they just are unclear of the cloning behavior expected of them most of the time.
A good collection of code should include mostly your own authored work. You’re hoping to give something back to the community. From the standpoint of your résumé, you’re hoping to show what kind of work you’re capable of doing.
So What’s Good?
I think I’d suggest that for anyone who’s looking for a new position as a coder, that Authored percentage value should be above 75%. I suppose the theoretical limit of 100% could potentially be the best and yet it would likely indicate that you don’t help out other coders with their repositories.
Rule of Thumb
If you fork a repository, you should do one of two things:
immediately start creating your own new software from it or…
immediately start working to help the original author so as to create a pull request.
This behavior of fork-and-do-nothing just seems patently wrong to me. If you think about it, it’s almost the equivalent of copying someone else’s résumé content into your own.
I suppose Microsoft is trying to go with this whole… open source thing that the rest of the world embraced a long time ago. They’ve just placed the source code for MS-DOS out into the public domain about three or four decades after it’s useful. Seriously, guys?
It’s probably lost on most people that this code is utterly useless, unless you have access to a time machine, of course. In order to assemble the code you’d need MASM v1.10 which is a very old Microsoft Assembler program indeed. I remember actually owning that about thirty years ago, believe it or not.
Looks like whoever made this available has added a number of poison pills: file-renaming, garbage characters to prevent assembly, the absence of an old (required) assembler, etc. It’s so blatant it would be funny otherwise.
adj. Not straightforward or candid; insincere or calculating
The Internet is full of advice. This is especially the case in the world of Raspberry Pi tutorials. The problem is that sometimes you get an anti-pattern with respect to upgrading the Pi’s firmware and/or operating system: people are confused and they’re giving the wrong advice. And then this same wrong advice is repeated over and over.
Two Upgrade Paths and Only One Is Correct
There are two paths available to people so that they may upgrade their Raspberry Pi. One is for a tiny fraction of the coders out there, those who actually create the Raspbian operating system itself. And then the other path is for everyone else.
Unfortunately, the people who wrote the Raspbian operating system included the tools they themselves use to develop it. Just because it’s there as a command line tool, that doesn’t mean that most of us were supposed to use it.
Granted, people will take the fewest steps to get somewhere. If they think that they can save a few characters with what looks to be a simpler command, they’ll try to use it. If things don’t figuratively blow up in their face, they assume it’s good and they’ll give this advice to others.
What’s the Difference?
When you run the sudo apt-get -y upgrade version, you’re pulling the latest code from the stablemaster branch of Raspbian. That sudo rpi-update command instead pulls from the development branch known as next. It’s a great way of trashing your Ethernet and wi-fi driver stack so that you can no longer get to it remotely, turning your Raspberry Pi into a brick.
Source code—assuming for a moment that you didn’t already know this—is a collection of (often English) words and symbols for humans which usually is turned into something more meaningful for a computer to understand when the program is running. Each computer language has its own rules about how you order the words and symbols but most allow for a fair amount of leeway with respect to whitespace, the “rests within the melody”, if-you-will.
“most [computer languages] allow for a fair amount of leeway with respect to whitespace, the rests within the melody…”
“Source code formatting is the task of using that whitespace to maximize… something.”
Source code formatting is the task of using that whitespace to maximize… something. This of course means different things to different people. For some, they believe that source code formatting can be done only one way. To format code using any other method, in their mind, would be the equivalent of breaking some sort of law.
Others believe that your text editor knows best and should be the authoritarian on the matter. There’s usually a feature to “format document” which they believe always gets this right.
As someone who’s been coding now for almost forty years, I’d like to share what I’ve learned and to permission you to completely ignore those first two camps who would say that you must do it their way.
In my humble opinion, nearly all of the source code formatting as seen in the world’s collection of code suffers from poor readability. And this is so because of the attitudes surrounding the topic as well as the self-imposed “leaders” and big players who believe their way is better, demanding adherence to their own opinions.
In many software development firms, this is a hot topic for debate. Coders feel strongly about how all this plays out. Outspoken individuals like Douglas Crockford (author of jslint) have even developed tools to enforce their own (wrong) ideas about how code must be formatted.
As large corporations like Google publish more in the open source area, they bring with them this kind of Draconian mindset. If you bring in their code, you’re very likely also bringing in format-enforcing restrictions which come along for the ride.
“If we think of jslint as a virus that self-propagates, then cloning a Google-published project has now infected your project.”
I have personally been held hostage for days trying to make the jslint build tool happy when I’ve been forced to use it. It’s one of the worst anti-patterns I’ve seen in this industry, to be honest.
An Innovative & Meaningful Method of Formatting Your Source Code
For me, I choose to maximize whitespace instead so that I may understand the code instantly. The more I understand the code, the less likely it is that I will later introduce a bug into this code. The faster I can speed-read the code, the more productive and happier I’ll be.
“Code Complete” by Steve McConnell
The genesis of this new method comes in part from my having read this excellent book at least twenty years ago. At the time, this was ground-breaking in its revelations of coding statistics with respect to bugs and the impact of good source code formatting to minimize their presence in code.
My method goes beyond the author’s original suggestions and is the work of a couple decades in the making.
A Practical Example
Before (classic jslint-like formatting)
After (new, suggested method)
Hopefully you will see the appeal to the second method. The spacing in Fig. 2 allows us to quickly see that this section includes the creation of several variables by pulling them in from separate files and modules. Additionally, they are alphabetized to make it easier to spot accidental double-inclusions.
Given the column-like behavior and the symmetry of those “require” functions, it’s now much easier to scan down the list. It’s now a pleasure to read.
Before (classic jslint-like formatting)
After (new, suggested method)
Here, by tightening up the first/third activities to become single-line events in Fig. 4, it’s easier to then see that we have what appears to be a sandwich-like construction:
create a variable
fs.closeSync() with that variable
The second activity now has some pretty radical source code formatting. But it follows the column rule introduced from before: columns make assignments easier to scan.
1) The Column Rule
To sum this up: use consistent whitespace to create columns out of assignments (storing a value into a variable). This applies to multi-line assignments as well as to assignments which take more than one line to accomplish.
Create columns: “…use consistent whitespace to create columns out of assignments…”
2) Squash for Readability
If it is possible to remove vertical space so that an entire function may be reviewed in one screenful in your editor, then consider doing so. Good candidates for this treatment are the open/close pairs of file functions seen in Fig. 4. The pairing makes sense to most coders so it’s a welcome form of abbreviation.
Squash: “If it is possible to remove vertical space so that an entire function may be reviewed in one screenful in your editor, then consider doing so.”
3) Comment the Breadcrumb Trail
When there are several levels of braces in one group at the end of something, clearly comment each with judiciously-provided whitespace so that they line up as a column as seen in Fig. 5.
Breadcrumbs: “When there are several levels of braces in one group at the end of something, clearly comment each with judiciously-provided whitespace so that they line up as a column…”
4) Semicolons for Readability
Use line-ending punctuation to tell one type of scope/block from another. In Fig. 5 above, fs.readdir() and fs.unlink() as function calls are each terminated with a semicolon after the ending brace. Here, I’m omitting the terminal semicolons for both the sections in the if blocks and the for loop at their ending braces.
Semicolons: “Use line-ending punctuation to tell one type of scope/block from another.”
I’m sure this one will have its critics. I would argue that the introduction of chained functions and the concept of “Promises” have created some rather interesting “dogpiles” of code at times which are too difficult to follow without this strategy.
Applicability to Other Languages
Let’s see… NASA’s InSight probe supposedly landed on Mars back on Monday. Visit their website two days later and there are lots of videos and photos, all of which are CGI-generated or they’re hours’ worth of employees looking excited.
Here’s one I’ve managed to dredge up though:
Is that the best we can do for the US$1B price tag? Presumably, it’s a down-facing camera with a frog-eye lens.
Yet again, it feels like lies stacked on top of lies to me.