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.
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.
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!....
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..)
This one I designed as a joke to be worn at a specific company in front of a specific manager. (limited run of 2)
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)
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.