Samuel Taggart
The official "Architect of Adventure". I help teams create healthy, human-centered software development processes.
Unit Testing As An Aid For API Development
If you follow Test Driven Development (TDD) the first step is always to write your unit tests before you write your code. Well in LabVIEW that doesn’t work out quite so well because you need to have a subvi to drop into your test case.
That means that before
Unit Testing as Bug Repellant
Nobody likes bugs, whether they are mosquitoes, black flies, spiders, or software bugs. One mosquito bite is generally mildly annoying but tolerable. Similarly with software, if your customers find a bug, it usually results in mild annoyance. Of course, there are exceptions to both: some mosquito bites can be deadly
Unit Testing as a Delegation Tool
Delegation is hard. There are a variety of reasons, but there are two things I’ve heard quite often from customers, and they are related. They have trouble specifying and clearly communicating the exact requirements to the person they are delegating to. They also have trouble verifying that whatever code
Unit Testing as Documentation
Comments and documentation often lie. The only truth is the code.
Steve Watts commenting on Chris Stryker’s Clean Code presentation at NIWeek 2019
Now I don’t think Steve is accusing the developer who wrote the code or documentation of deliberately lying, but we’ve probably all encountered code
Using Maps As A Better Way To Pass Command Line Arguments
So for those who don’t know, LabVIEW 2019 incorporates some new datatypes: Sets and maps. Piotr Kruczkowsk has been posting a bunch of possible use cases on Twitter. You can see them here. Peter has inspired me to come up with one of my own.
The problem with CLI
The benefits of Continuous Integration
In a previous post, I talked about various ways to earn technical interest. One of those ways was Continuous Integration or CI. I thought I would elaborate a little on the benefits of using CI to automate the boring stuff so you can detect problems early, streamline your process, and
What are you designing for?
My upcoming webinar got me thinking about a recent conversation that I had with Fabiola about design decisions. It also reminded me of a few of Steve’s recent blogposts on Design Priorities and on Project versus API Design.
My discussion with Fabiola revolved around the differences between the Actor
Six Easy Ways To Earn Technical Interest
Steve Watts recently made a excellent blogpost about Technical Accounting. If you don’t follow Steve’s blog you definitely should. In this particular article, he coined the terms Technical Debt, Technical Investments, Technical Assets, and Technical Tax. Steve’s talk of Technical Investments, got me thinking about Technical Interest.
April 2019 Webinar
Choosing a Framework – April 24th 11am-12pm MST
So many choices
DQMH, AF, DCAF, SMO, ALOHA, TLB, and I’m probably still missing some. There are lots of LabVIEW Frameworks out there (and they all have cryptic acronymns). If you are confused by this alphabet soup of frameworks, then this presentation
A Business Case For Applying Design Patterns
This is my fourth article in a series on the Gang of Four book on Design Patterns. I thought four was an appropriate number of articles. Here are links to the first 3 articles:
1. Design Patterns – A Review
2. OOP Design Patterns in Actor Framework Part 1
3. OOP
Design Patterns - A review
I recently finished reading “Design Patterns: Elements of Reusable Object-Oriented Software” by Erich Gamm, Richard Helm, Ralph Johnson, and John Vlissades. Due to its popularity, the length of the title, and the fact that it has 4 authors, it is affectionately known as the “Gang of Four” book or GOF