posted under category: Software Quality on March 21, 2016 by Nathan
Something that comes up from time to time is the idea of reusable software, and why can’t we really reuse things that other people wrote. It’s a mystery. Robert Glass, a programming legend who worked at my company (1965-1982) said this:
- Reuse-in-the-small (libraries or subroutines) began nearly 50 years ago and is a well-solved problem.
- Reuse-in-the-large (components) remains a mostly unsolved problem, even though everyone agrees it is important and desirable.
Now we like to think we’re so much better off. Look at cave man. He can’t reuse software. He can’t even boil an egg. Look at us now. We have mechanical egg poachers and GitHub and NPM.
Using a library (jQuery, Bootstrap, React) is still “reuse-in-the-small.” Bigger reuse means more homogenization, and all programmers have not-invented-here syndrome to some degree that usually teeters between healthy and unhealthy. We like our own software because we know how it works, we know how to fix it, and it works exactly how we want it. We don’t like pre-written software that we can’t control.
Living in the world of StackOverflow and GitHub, I believe that we can extrapolate Glass’s statements even further. It looks like this:
amount of code reuse by the size of code being shared
That’s why programmers lose their minds when they see something like Ruby on Rails that generates a working MVC app based on some database tables. Of course the reality ends up being something different, but you could almost hear the internet erupting with excitement back when Rails was first introduced.
Anyways, Glass’s proverb remains true. Code reuse in small parts is solved. Code reuse on a large scale is wanted but still far off.
(Discuss with Disqus!)
posted under category: IDEs and tools on March 17, 2016 by Nathan
Many years ago I read an article where someone put their linux-os home directory in source control - probably CVS at the time, this was a while back. He’d had it running that way for a long time, too, and could roll-back his desktop to last week, checkout the latest version on any new PC, throw away destructive changes, and save & commit beneficial changes. It got me thinking. Version control software isn’t just for code, it’s for any file.
Years ago, when playing Minecraft server admin for my kids, I came up with the idea to put their Minecraft world into Git. We could check in changes nightly, which would allow us to blow everything up and just roll back, or invite a destructive friend over and then undo everything he did. It also gave us the ability to clone the server into a local world when the server was too slow, play locally, then push progress back up to the shared server. And then there’s branching - one child could go out and do stuff in another part of the infinitely generated world, then merge changes back on to the server if it worked out, or drop the branch if it didn’t. It’s brilliant. It ended up a little more work than anyone wanted to do, but the idea was there.
Recently, when researching backup software, I found two real categories of solutions for backups:
- Your backup is just a copy of your files on another server or drive, with no historical data integrity
- Your backup software in a database somewhere, but you have to use specialized software to retrieve your files
After searching for a while, I found bup. It’s actually based on Git, which gives you the best of both worlds for backup software - a live, local copy of files that you can browse like any file, plus versioned incremental backups that you need a special client to retrieve. You can host it on a file share, and effectively, git-clone (technically bup-clone) to add another backup server.
I’ve no doubt that there are a million other potential uses, too. Version control software is not just for programmers and code!
(Discuss with Disqus!)
