I've used a lot of different source code management systems over the years: SCCS, RCS, CVS, ClearCase, Subversion, Perforce, and Git, as well as some pre-UNIX solutions, depending on what my employer or client of the moment preferred or what was available. Since 1995, Digital Aggregates' own SCM server has migrated from RCS to CVS to Subversion. As part of a gradual shift to Git, I've started hosting some of Company's open source projects in the cloud on GitHub.
This is still very much a work in progress. But since some of my projects licensed here under the GPL (3.0), the LGPL (2.1), or the Apache license (2.0) have found their way into a variety of commercial products and other projects, I thought the use of GitHub might make my and other folks' lives easier.
The tarballs of the projects listed below are still available on the Digital Aggregates web site.
Amigo: FreeRTOS-based C++ system for AVR ATmega Arduino-compatible boards.
http://www.diag.com/navigation/downloads/Amigo.html
https://github.com/coverclock/com-diag-amigo
Biscuit: mechanism for encrypted Linux system maintenance scripts automated via hot plug.
http://www.diag.com/navigation/downloads/Biscuit.html
https://github.com/coverclock/com-diag-biscuit
Buckaroo: Java traffic shaping classes and instant managed beans (recently updated and unit tested).
http://www.diag.com/navigation/downloads/Buckaroo.html
https://github.com/coverclock/com-diag-buckaroo
Concha: examples of object oriented design in C.
http://www.diag.com/navigation/downloads/Concha.html
https://github.com/coverclock/com-diag-concha
Desperadito: useful embedded patterns in C++.
http://www.diag.com/navigation/downloads/Desperadito.html
https://github.com/coverclock/com-diag-desperadito
Diminuto: Linux systems programming library in C (recently updated and unit tested).
http://www.diag.com/navigation/downloads/Diminuto.html
https://github.com/coverclock/com-diag-diminuto
Hayloft: multithreaded C++ framework for AWS Simple Storage Service.
http://www.diag.com/navigation/downloads/Hayloft.html
https://github.com/coverclock/com-diag-hayloft
Lariat: thin C++ layer over Google Test for use in automated unit testing.
http://www.diag.com/navigation/downloads/Lariat.html
https://github.com/coverclock/com-diag-lariat
Telegraph: collection of C functions useful in non-Linux systems (recently updated and unit tested).
http://www.diag.com/navigation/downloads/Telegraph.html
https://github.com/coverclock/com-diag-telegraph
Feedback welcome.
Monday, February 03, 2014
Saturday, February 01, 2014
Be a Product Developer
From time to time I am asked what I do for a living. People in my line of work know that this isn't always an easy question to answer.
I could legitimately say that I am a "computer scientist". I have two degrees in computer science from an accredited program at a brick-and-mortar university. I've done research, published papers, filed patents, and worked at a national lab sponsored by the National Science Foundation. I'm a believer in the scientific method and being evidence-based. And anyone who has worked with me has got to believe that I like to teach. But being a scientist is not really what I do for a living.
Back in the 1970s I was called a "systems programmer". I have always liked that title and the distinction it draws with an “application programmer”. But alas that nomenclature has fallen out of favor.
I don't like the term "software engineer" because although much of what I do is engineering, to use the term "engineer" in a title has legal and certification requirements in many states (although not where I live, in the great state of Colorado).
I could use "software developer". For sure I write a lot of code. But I don't feel that term really describes the set of skills that I bring to the table. But there's a better reason that I don't like it: for a software developer to consider themselves successful, they have to develop working software. While developing working software is a hard enough job indeed, it's a far cry from shipping a product.
So I choose to call myself a "product developer". This implies a broad range of skills and capabilities ranging from product definition, process, architecture, design, implementation, testing, maintenance, field support, decommissioning, and even occasionally management; soup to nuts, across the entire lifecycle of a product, that's what I do.
But more importantly: for a product developer to be successful, they have to ship a working product.
No matter what you may do day to day -- sales, product owner, project management, systems engineering, quality assurance testing, hardware or software development, lab support, field support, what have you -- I would encourage you to think of yourself as a product developer. All of those activities are necessary to ship a working product, but none are sufficient. Although perhaps you contribute to one or two of those activities, for you to be successful as product developer, all of them have to be done.
All successful product development projects are team efforts, because it takes a team of product developers -- diverse in skills, culture, and experience -- working together to make it happen.
I could legitimately say that I am a "computer scientist". I have two degrees in computer science from an accredited program at a brick-and-mortar university. I've done research, published papers, filed patents, and worked at a national lab sponsored by the National Science Foundation. I'm a believer in the scientific method and being evidence-based. And anyone who has worked with me has got to believe that I like to teach. But being a scientist is not really what I do for a living.
Back in the 1970s I was called a "systems programmer". I have always liked that title and the distinction it draws with an “application programmer”. But alas that nomenclature has fallen out of favor.
I don't like the term "software engineer" because although much of what I do is engineering, to use the term "engineer" in a title has legal and certification requirements in many states (although not where I live, in the great state of Colorado).
I could use "software developer". For sure I write a lot of code. But I don't feel that term really describes the set of skills that I bring to the table. But there's a better reason that I don't like it: for a software developer to consider themselves successful, they have to develop working software. While developing working software is a hard enough job indeed, it's a far cry from shipping a product.
So I choose to call myself a "product developer". This implies a broad range of skills and capabilities ranging from product definition, process, architecture, design, implementation, testing, maintenance, field support, decommissioning, and even occasionally management; soup to nuts, across the entire lifecycle of a product, that's what I do.
But more importantly: for a product developer to be successful, they have to ship a working product.
No matter what you may do day to day -- sales, product owner, project management, systems engineering, quality assurance testing, hardware or software development, lab support, field support, what have you -- I would encourage you to think of yourself as a product developer. All of those activities are necessary to ship a working product, but none are sufficient. Although perhaps you contribute to one or two of those activities, for you to be successful as product developer, all of them have to be done.
All successful product development projects are team efforts, because it takes a team of product developers -- diverse in skills, culture, and experience -- working together to make it happen.
Tuesday, December 24, 2013
Update
I haven't written much in the way of new blog articles for a long time. Work consumes. But I have been busy updating some existing articles. Today I wrote an addendum to We Shape Our Tools And Then Our Tools Shape Us to include some serious upgrades to my field support capability for air travel. If you take a dead serious approach to field support like I do, you'll like the what you see. (Go all the way to the end of the article.)
Subscribe to:
Posts (Atom)
