From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Mildly Offensive Corporate Wear

swatts
Active Participant

Nothing too serious this time my lovelies as your brains are full of NIWeek stuff.

One of the things on my strange bucket list is to produce a range of corporate wear as a reaction to polo shirts with slogans such as "Delighting our customers with our passionate approach to LabVIEW solutions" or some such!....

Metrics.PNG

This one has my favorite software related cartoon, I designed it as a prize for the European CLA summit 2013 (limited run of 3, ahhhhh Paris in the spring..)

Lego.PNG

This one I designed as a joke to be worn at a specific company in front of a specific manager. (limited run of 2)

Fab.PNG

For this one I doctored the original list of names for LabVIEW, Can only be worn by people called Fabiola....or maybe Fabian. (Limited run of 1)

Spexy.png

Just promoting the new book, and everyone should look Spexy! (limited run of zero)

I have an extremely offensive one in my mind that involves QR codes, maybe for NIDays this year, but I'll probably chicken out, Got 2 others in the pipeline too, will post them when I've done them.

On previous blogs it was suggested that we must be doing something with action engines that others aren't and it got me thinking.....

All of our components (action engines) are designed with an understanding of coupling, cohesion and information hiding. A great deal of our book was dedicated to this subject, rather than just describing a technique. Now if you just use a technique with no comprehension of what makes a good component, state machine, class, actor etc etc I'm guessing you'll run into trouble. Another consideration is that where possible we base our components on real world objects and steer clear of abstract software constructs (for example we toyed with communication layer components for test systems and stepped away from them because they lacked clarity of design). From a coupling point of view we try to minimise communication paths and reduce dependencies, while still trying to get the block diagram to clearly represent the problem domain.

I'll keep on mulling this one over I think.

Reading Robert Glass book at the moment and in it is this quote (no-one credited for it).

Reality is the murder of a beautiful theory by a gang of ugly facts

I think it is rather apt when applied to software design.

Lots of Love

Steve

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments