Skip to content

Jan 29

2 Comments

OAuth2 and LabVIEW — Part Three, Improving the Example

This is part three of a three four nine part blog post where I describe how to use OAuth2 with LabVIEW. See also:

In part one, we created a web service that the authentication process is going to use to call us back with an authentication code. In part two, we wrote code to go through the authentication process and call an example Google web service. Here in part three, we’re going to start writing some tests, replace the JSON parser, and think about what we else we could do to improve the example.

Improvements for Testing

I’m usually not a Test-Driven Development (TDD) kind of guy.  That’s where you write unit tests first, show that they fail, and then write the code that passes the tests.  I’ll sometimes use TDD when I clearly know what the right answer for a function ought to be.  For example, I once used TDD for figuring out a SQL query to a database—I could look at the database and deduce what I wanted the query to return, so I wrote a test for that.  Then I iterated until I got a SQL query that returned the right answer, and then iterated until it was efficient.

In our OAuth2 case, I decided from the start not to use TDD.  I wasn’t as confident that I knew the “right answer” to each step.  But I still kept testability in mind as I went along, and I wasn’t afraid to go back and write tests (and refactor for testability) after the first pass of the app was “done”.

It’s worth talking about the structure of the C# example that I started from.  It was badly structured for testability.  Here’s a high-level pseudo-code overview of this structure:

Read more

Jan 28

9 Comments

OAuth2 and LabVIEW — Part Two, The Authentication Process

This is part two of a three four nine part blog post where I describe how to use OAuth2 with LabVIEW. See also:

In part one, we created a web service that the authentication process uses to call us back with an authentication code. Here in part two, we’ll write code to actually go through the authentication process and call an example Google web service.

Calling the Authentication Server

Okay, with the callback ready, we can now call the authentication server and request a code.  Fortunately, Google has conveniently set up example servers and client codes to make testing with their endpoints easy.  That’s what we’ll use for this example.

We will call https://accounts.google.com/o/OAuth2/v2/auth as our authorization endpoint.  It takes several parameters that are part of the OAuth2 standard which we’ll pass with the URL:

  • response_type=”code”
  • scope=”openid profile”
  • redirect_uri=<our redirect endpoint>
  • client_id=<client id registered in advance>
  • state=<state>
  • code_challenge=<code challenge that’s part of the PKCE extension hashed with SHA256>
  • code_challenge_method=”S256″

The “redirect_uri” is what we created in part one of this blog post. The “client_id” for our example belongs to an “AppAuth Example” which Google created for testing. The “state” is a random string used to discriminate between calls. “code_challenge” and “code_challenge_method” are part of the PKCE extension.

We’re also going to need some helper VIs…

Read more

Jan 27

11 Comments

OAuth2 and LabVIEW — The Evolution of an Example

This is part one of a three four nine part blog post where I describe how to use OAuth2 (and PKCE) with LabVIEW. OAuth2 is used to authenticate with web services such as Google, Twitter, Facebook, and almost every major cloud-based service today.

See also:

Introduction

I own a slightly faulty beverage refrigerator. What makes it slightly faulty is that it sometimes wants to be a beverage freezer—it starts cooling, and doesn’t stop. It only does this rarely, and is otherwise a nice enough refrigerator that fits conveniently in a spot in our laundry room, so I’m hesitant to replace it. Instead, being the engineer I am, I decided to address the issue with more technology!

I purchased a Wireless Sensor Tag and a Wemo Mini Smart Plug to solve the problem.  The Wemo Wifi plug controls power to the refrigerator.  The Wireless Tag monitors temperature and humidity in the fridge. I use an IFTTT recipe to turn on the power when the temperature is too high, and turn off the power when the temperature is too low.  I ask it to keep the temperature within a four Fahrenheit degree temperature range.  On average, it is on for one hour, off for four hours, and then repeats.

It works surprisingly well. I set the Wireless Tag to send its data to the cloud every five minutes. I can view temperature and humidity graphs over the last several months and know it’s working. IFTTT is imperfect as a control system, but has worked out more reliably than expected. It’s only missed the too-high/too-low alarm twice in the few months since I’ve had this setup, and I work around this by having the alarm continue to trigger every fifteen minutes until the temperature is back in range.

All in, I’ve spent about $90 to avoid buying a new, inexpensive refrigerator—but it was way more fun to do it this way!

I can’t help but wonder about using LabVIEW to replace IFTTT as the controller, or to use LabVIEW to analyze my months of temperature and humidity data—and that’s where this journey begins…

Read more

Sep 3

Book Review: Peopleware

Peopleware: Productive Projects and Teams
by Tom DeMarco

The right to be right is irrelevant; it’s only the right to be wrong that makes you free.

– Peopleware, by Tom DeMarco

I don’t recall, exactly, what prompted me to pick up and read this book again in May of this year. I first read it many years ago–probably when the first edition (1987) was new. I imagine someone referenced it at this year’s NIWeek conference. It might have been Steve Watts, who has been known to suggest that software engineering is somehow related to people.

And indeed it is. This book is quite aligned with my management philosophy that software developers are people, too. Many of them darn smart, good, and interesting, worth cultivating as humans, and not just churners out of code.

Build teams to last…

I tend to favor efforts that benefit the long term view–even at the (hopefully limited) expense of the short term. The best way to build good software is to grow a team that knows how to build good software–that is, you should invest in your people.

We stopped talking about building teams, and talked instead of growing them. The agricultural image seemed right. Agriculture isn’t entirely controllable. You enrich the soil, you plant seeds, you water according to the latest theory, and you hold your breath. You just might get a crop; you might not. If it all comes up roses, you’ll feel fine, but next year you’ll be sweating it out again. That’s pretty close to how team formation works.

— Peopleware, by Tom DeMarco

Let’s obsess for a moment about the short term. “We have product to get out the door. Our customers depend on it. Our company depends on it, or we’ll go out of business.” To be clear, I in no way suggest we eschew market realities. What I don’t like is when cutting corners becomes a way of life.

Read more

Aug 27

Photo of Edsger Wybe Dijkstra

Humility and Better Programming, Six Years Later

Here’s everything you need to know about my software development philosophy:

“The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.”

– Edsger W. Dijkstra, The Humble Programmer, ACM Turing Lecture 1972

Edsger Wybe Dijkstra

Six years ago, I wrote a series of articles about being a humble programmer, based on the ideas of some really smart people, like Dr. Dijkstra. The articles have gotten a lot of views and positive comments, and I think they’re still relevant reading today.

I wrote them back when I worked at National Instruments. I had a blog called labviewjournal.com. (I saved all that content. It’s now at https://stravaro.com/lvjournal, and the old hostname redirects there.) My colleague, Nancy, and I wrote several articles about our world of helping people develop better software.

We both find that helping developers be more successful is fun and rewarding. That’s why I created Stravaro.

Anyway, back to the old blog series–there’s almost nothing I would change if I were writing it today. It feels just as relevant as when I wrote it. Even though the articles were written with the LabVIEW developer in mind, I believe it’s a philosophy that should be followed regardless of programming language. When I worked at athenahealth, I gave a presentation on the same theme at an internal technical conference.

If you haven’t read the series, I invite you to do so now. Do any of you have a similar philosophy that’s worked well? Or a radically different one? Leave a reply below to share your thoughts.

“Every person that you meet knows something you don’t; learn from them.”

– H. Jackson Brown Jr.

“The greatest lesson in life is to know that even fools are right sometimes.” 

– Winston Churchill

Aug 20

From the archives: 64-bit LabVIEW!

The other day, I saw this tweet from Darren Nattinger, replying to a tweet by Jim Kring, of JKI…

And I realized that it’s been over ten years since we released 64-bit LabVIEW. I wrote about it in the blog I had at the time (which lives forever, like everything on the internet 🙂 ).

I led a team of two other amazing developers, Adam and Kyle. The three of us just plowed through the few million lines of C/C++ and made it 64-bit aware. No big deal. 😉 When we first started, I felt like there was a greater than 50% chance that we’d fail. Most likely, that we’d decide it wasn’t worth the effort–we’d hit some very large boulder, and decide not to go on. But we persisted, and ended up coming in ahead of schedule and below budget. We actually had to wait (a year, I think) for the device driver groups to catch up with their 64-bit support.

Read more

Aug 15

Book Review: Organizational Culture and Leadership

Organizational Culture and Leadership, Fifth Edition

Organizational Culture and Leadership, Fifth Edition by Edgar H. Schein

When I first became VP of Engineering at insurance startup The Zebra, I wrote a long internal blog post sharing several book recommendations–books that have made an impression on me in my career. From time to time, I plan to review a few of those for you here in my blog.

I first ran across MIT Professor Emeritus Dr. Schein when I worked as Lead Developer and Director of Engineering at athenahealth. Athena, being based in Watertown, Mass., generally prefers ideas that come out of places like Harvard and MIT, and ideas about company culture were no exception. I failed to really appreciate Dr. Schein’s ideas until I moved on to a local Austin startup that had a somewhat more ambiguously defined company culture.

Among other topics in the book, Schein gives an approach for really understanding culture. He focuses on three areas:

Read more

Aug 13

GDevCon Logo

Excited for GDevCon #2–But I won’t be there!

Almost a year ago, I was in Cambridge, England, presenting at the very first GDevCon—a graphical developer conference.  I am so grateful for that experience. My topic was “My Continuously Evolving Practice of Software Engineering”.

GDevCon #2 is coming up on August 20-22 in Birmingham, England, and I’m very disappointed I’ll be missing it this year.  Instead, I’ll be on a trip I booked months ago, watching opera in Santa Fe, New Mexico,

My friends at GDevCon have once again lined up a fabulous agenda with wonderful presenters.  For those who are going, I declare my jealousy and hope you have a wonderful time.  I look forward to watching the videos afterwards, and hopefully will see you in person next year.

Jul 29

1 Comment

My Journey to Consulting

Hello.  I’m Brian Powell.  Some of you know me.  Some of you don’t. Let me introduce myself.

At least in Austin, if you have “VP of Engineering” on your LinkedIn profile, you get calls almost every week from a recruiter saying, “Hey, there’s a local startup that needs a VP of Engineering–are you interested?”  I’ll sometimes take a look, and more often that not, my reaction is, “No, you don’t need a VP of Engineering.” What you need is someone to come in and help you solve a problem. Here are some examples…

Read more
Newer Entries →