So the year is shooting past at a breakneck speed and here comes NIWeek 2015, sadly I blew my Jolly Fund in Rome and I won't be crossing the Pond this year. So this is a bit like me in a restaurant picking the meat dishes for my carnivore friends (I'm a veggie), here's what I would go and see if I was going....

As well as the keynotes, these are my picks (bear in mind I don't do many test systems any more so it's heavily biased on the software side of things)

TS6421 -      Don’t Panic: LabVIEW Developer’s Guide to TestStand - Chris Roebuck

TS5740 -      Computer Science for the G Programmer, Year 2 - Stephen Mercer and Jon McBee

TS7238 -      Curing Cancer: Using a Modular Approach to Ensure the Safe and Repeatable Production of Medicine - Duncan MacIntosh ,Fabiola De la Cueva

HOL7309 -   Hands-On: Introduction to Software Engineering and Source Code Control - Chris Cilino

TS6142 -      Hidden Costs of Data Mismanagement - Pablo Giner,Stephanie Amrite

TS6408 -      NI Linux Real-Time: RTOS Smackdown - Joshua Hernstrom

TS6720 -      Effective Project Management of LabVIEW Projects - Ryan Smith,Paul Herrmann

TS6977 -      10 Differences Between LabVIEW FPGA and LabVIEW for Windows/Real-Time Programming - Erin Bray

TS6303 -      LabVIEW FPGA Programming Best Practices - Zachary Hawkins

TS5898 -      Inspecting Your LabVIEW Code With the VI Analyzer - Darren Nattinger

TS7477 -      Using LabVIEW in Your Quality Management System - Maciej Kolosko

TS5698 -      Augmenting Right-Click Menus in LabVIEW 2015 - Darren Nattinger,Stephen Loftus-Mercer

HOL5977 -   Hands-On: Code Review Best Practices - Brian Powell

TS6420 -      5 Tips to Modularize, Reuse, and Organize Your Development Chaos - Fabiola De la Cueva

My interests here are software engineering, FPGA, and an increasing interest in data management. So I've chosen 13 hours of presentations + keynotes. Hopefully they will be video'd!

Talking of videos I've been busy tidying up some of our CSLUG presentations (more to come!)

These can be found here https://decibel.ni.com/content/thread/32010

I think it will make a nice archive over time.

If we manage to organise it, we're doing something a little different for the next CSLUG meeting on the 17th September, we're going to pick a subject and have a series of 4 slide presentations with multiple presenters. We should then get a spread of concepts for databases, error handling, customer sign-off etc etc. Each subject will be about 30 mins. We'll see how it works out!

Finally I'll be presenting on immediacy at the CLD summit in Newbury on 9 or 10th of September, so I'm busy updating my Rome presentation, I'm actually adding more technical content and taking some of the jokes out! I've been applying some of the techniques and can show some of these off now.

Workwise: SSDC Maritime Division is beginning to blossom, we're currently waiting on orders that are worth 150% of last years turnover! I'm also working on a distributed oscilloscope program that seems to be generating some interest (I'm actually quite proud of it so far) and then we are waiting for the go-ahead on a data repository design and reporting system. Any of these jobs may have a profound effect on SSDC and I may finally get the company hovercraft I always wanted. The downside is I will probably be slower on my blog output!

If you are travelling to Austin; travel safe, if you are presenting; present well!

Lots of Love

Steve

Hello Lovelies,

I'm going to be very candid in this article and once again no LabVIEW so bonus random points for me.

There will be no meditation, sobriety or jogging in this article so rest easy.

I'm pretty unemotional and shallow. In fact below are photos of me with my various moods on display

And I have an iron constitution, so essentially for 40 odd years my body was just for moving my brain from point A to point B and for filling with beer.

My twitter feed has a few comic book writers on it and these guys are doing a job they are intensely enthusiastic about, they are also doing a job they can carry around with them. Most are slightly younger than me and have been doing it for years.

It sounds idyllic and not dissimilar to my situation.

So it really interested me when one of these writers complained about feeling anxious and what could he do it about (it was anxious to the point of not being able to work, not just a bit fretful)

And then came the flood of rubbish advice.

• Have a cup of tea (mostly British)
• Have a walk
• Listen to music
• calm down
• blah blah blah

And I really wanted to chip in, but not on twitter.

A few years back the same thing happened to me. Here's the details.

I love writing software, just love it. I'd do my 9-5 work and go home and have some food, say hello to my family. I'd then sit down and while they watched rubbish TV I would start programming again and this would then go on until 10ish and then bed. Every gap I had I would fill with software.

This was fine until one day I was driving home and I felt most odd, like I was having a heart attack. Bear in mind my body had never spoken to me for 45 years so I wasn't very good at listening.

Trip to the Docs, Heart going too fast, asked me if I was stressed, working too hard, told me to stop being stressed and working too hard.

So I looked at my life and felt surely doing something I loved wouldn't have this effect on me would it!. Well actually it did.

The issue was I wasn't differentiating my work time and home time. Essentially I was never finishing my working day.

The cure?

I just separated the things I think as work (i.e. programming), with the things I don't regard as work. The things I do as work I do 9-5, the other stuff I do when it entertains me.

Luckily I don't regard research, writing blogs, making presentations as work so I could still manage to pack in some extra hours, which is useful when running your own business.

Did it work? Almost instantly and following these rules have kept me very happy for the last few years.

Just look at my little face....

So my friends be nice to your brain, it's kind of useful!

Lots of Love

Steve

I'm very enthusiastic about the subject of the last article and will attempt to flesh out some details in the months to come (sorry but my brain does not work in a linear fashion and neither do my enthusiasms).

I think the combination of OOP, Functional etc etc may be the unified theory of software development!

And these grand statements may be part of another problem, a problem that we have contributed to in our innocence.

In fact we kind of predicted it by using the following quote in our book.

"If this is true, building software will always be hard. There is inherently no silver bullet"

- Frederick P. Brooks, Jr 1987 Computer Vol 20 

And I really want everyone to understand this. Please, please understand it!

We presented LCOD as a method and carefully explained modular design, thinking that by describing the whys and wherefores the job was done. We then went back to our day jobs and didn't really have time or energy to follow it up.

I see all the frameworks, methodologies, processes, techniques and theories enthusiastically evangelized (ours included) and I want to shout "a badly implemented Silver Bullet will still be crap"

What do I mean by badly implemented? Taking LCOD as an example we can separate the techniques of implementation (what we place on the block diagram) and the hard work of design. So we could quite easily create a god component that does everything we want our program to do, but this is obviously a bad design decision. With LVOOP we could similarly have god objects and I expect we could have a god actor (Morgan Freeman).

Someone said the following to me at the CLA summit "OOP is the best way to write software!", it elicited the following slightly snarky response... "Define BEST". Statements like that de-value all the great software written that isn't OOP and doesn't really add anything to the conversation. OOP is a great and valuable tool to be added to your toolbox and used where appropriate. You do not become a great carpenter by using great tools, they help but it's not the full story.

And with all our best intentions you can put the silver bullet in a dirty weapon and have it back-fire on you (as Fab put it). Now I have some bad news for buyers of self-help books, I think good software design comes with hard work, study and experience, and pretty hard won experience at that! Also good software design does not depend on the methodology or process you favor, it depends on using a technique appropriate to the requirements.

"Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they’re never a substitute for thinking critically about your work."

Jeff Atwood The Ferengi Programmer

I found this quote from a spat between Joel Spolsky and Uncle Bob Martin, 2 people who are very loud in the software design community and have very differing views on Test Driven Design. Both can't be right, but their opinions are espoused as absolute truth.

And here is an uncomfortable truth: you won't create decent designers by teaching techniques, offering frameworks and imposing rules. Good designers understand their tools, understand design and can assess what they have been told and reject what doesn't work for them. Also they generally get better with each job they do!

Software is a practical subject the best way to learn how to design is to design stuff. (<---Mr Mercer has made me re-evaluate this statement!)

Software is a practical subject the best way to learn how to design is to design stuff, while being taught how to design stuff. (<-- this is how I learnt and it served me pretty well, but I needed the experience of writing lots of code prior to being taught to really hammer home the lessons)

As one of the loudest people in our little community I have one message for you all to take away

Curmudgeonly yours with love.

Steve

I had a go at SMORES a while back in this article

SMORES, SMURF or SCRFFMRDM

(actually it was really an attack on mindlessly following acronymns)

and like most things it's not quite as black and white as I originally put it (time, conversation and thought have added colour and shade).

The conversation on this subject has mostly been with AristosQueue and I think we have stumbled on a point of convergence (I'm only speaking for myself here). Link to one part of the conversation is here

The breakthrough statement is as follows.

You need different design methods for different stages in a project.

To back up my theory I've split a project into 3 stages

In reverse order let's look at the Low Level API/Drivers part. So this would be hardware drivers, reporting, data handling, communications.

Next we come to the framework there are plenty available (Actor Framework, Delacor, JKI, James Powells, TLB, Aloha to name a few), this should handle all the common tasks associated with most applications.

Finally we have the Customer Facing/Final Application software, this is the bit that brings together all of other parts and makes you money.

Here's a table of important considerations for good software design. And as an exercise I've selected 5 of the most important for each stage.

A bit of Acronym/Anagram fun gives us

Low Level API/Driver = STORE

Framework = FRERC

Final Application = FRUMF

It's important to note that the considerations I picked are the ones that are important to me, my company and my customers. They may not be important to you, so pick your bloody own!.

So if the requirements at each stage vary so much it stands to reason that we should apply different design tactics, even different designers.

There is one extra consideration that I would like to put in for frameworks (with thanks to Thoric) and that's Inobtrusive. I want a framework to be visible but not get in the way. I would like to see what it is doing but I don't want it masking the solution to problem I'm solving.

The other aspect to think about is the size of each section, so if you only ever tackle one type of job you may find that the customer facing part is small compared to a big ol' framework. In short they are variable in size.

More questions than answers as usual, but it's food for thought.

And to quote Leslie Lamport for the second time this week "Thinking does not guarantee that you will not make mistakes. But not thinking guarantees that you will."

Lots of Love

Steve

I'm such an adult! but the title made me laugh so it stays.

AristosQueue presented "Various Tangents Around The Circle of Design Patterns" and as usual it was a well thought out, extremely well presented and original piece of work. Sadly it wasn't recorded so you will have to take my word for it.

Now I've said all these nice things I'm going to discuss one of the ideas presented and my starting position is that I'm not entirely sure a component as defined in LCOD is actually a singleton pattern at all....

I have a very early edition of the GoF book and I actually was pretty keen on patterns when I was researching our book. Sadly my edition of Design Patterns is in almost perfect condition. This tells me only one thing....I didn't find the book very useful or applicable to LabVIEW, this is where AQs talk of idioms comes into play I think. My opinion is that the patterns described are idiomatic  to C++/Java and they help deal with a lot of the heartache and nause related to those languages. I strongly believe LabVIEW has it's own idioms.

The Singleton Pattern Defined (by wikipedia)

In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects. The term comes from the mathematical concept of a singleton.

There is criticism of the use of the singleton pattern, as some consider it an anti-pattern, judging that it is overused, introduces unnecessary restrictions in situations where a sole instance of a class is not actually required, and introduces global state into an application

and here's a pretty good definition..

"Ensure a class has one instance, and provide a global point of access to it." (Note: I was too lazy to read the book again so swiped it from this excellent article http://gameprogrammingpatterns.com/singleton.html)

For us a component/action engine is purely there as a high level construct to restrict access to related modules in a program. This is design construct aimed purely at simplifying the block diagram. So for example here is a component as defined by us, this is an oscilloscope and the customer requires the ability to have either NI racks or Agilent with a variety of oscilloscopes.

Note: I'm still wrestling with the Acqiris Cards, they will hopefully be an AcqirisScope subclass as per the NIScope class.

As we can see there is little relationship to a singleton pattern here, rather the component is a restricted interface to a group of related objects. So what is the point of this? I think this is where AQ and I are converging (this is not a static situation, because we are analyzing designs at greater depth, publishing our ideas and discussing them).

I will talk about this convergence in greater depth in my next article, for a preview sneak a peak at the conversation here

Lots of Love

Steve

Well Hello programming chums

At the European CLA 2015 summit Sacha Emery presented "Actor and benefits of different frameworks" where he described his journey through various design choices when applied to a standard set of requirements. This segued nicely into various topics that were being discussed throughout the summit and it I also hijacked it selfishly to promote one of my interests.

I'm after finding some way of measuring the complexity of a system, now ideally I would like this to be something tangible like function points.

Data Functions:

Internal logical files

External interface files

Transactional Functions:

External Inputs

External Outputs

External Inquiries

The complex problem is how to identify these items within a LabVIEW Block Diagram (I haven't given up on this)

One of the advantages of function points is that you can can get them from requirements and use them for estimation. My primary interest is not for estimation tho' I want a common measure of the the complexity of a project so we can better assess and discuss our design choices. The disadvantage is that it is hard work and takes a lot of time to undertake a study.

So how does Sacha's presentation link to this?, like all good test engineers I like my processes to be calibrated and I think this might be the perfect tool to do this. Here's how we think it will work (and I say we because this is based on conversations with Jack Dunaway, Sach and various other luminaries).

We have a common set of requirements.

We apply a framework/design/architecture to provide a solution.

We tag all the project items that are original items.

We analyze all the items that are in the problem domain (i.e. separate the solution from the architecture).

We apply a change/addition in requirements.

We analyze the additional items that have been generated to satisfy the change.

This should give us several numbers

Items in Basic Architecture (A)

Items to Solve the Problem (B)

Items to Make an Addition (C)*

And this is what we call the Emery scale.

The preconception is that generally the code to solve the problem should be pretty repeatable/similar.

So dumping Function Points for the time being and going back to a more simple idea (care of Mr Dunaway), we should tag the architectural parts and count the nodes using block diagram scripting. As Chris Relf has stated there is some good data to be had from LOC (lines of code) comparisons in similar domains.

And what use is all this work? For 1 it should give us an estimate about the number of VIs our design will have on a given target (The ratio of B:C(#requirements) should give us a size) . This is an essential bit of design information.

Early stages and a long term project. It could be part of my CS thesis if I was doing one...

This is only one potential benefit of the kind of baselining that Sacha has started (from an educational perspective seeing the same problem solved with different frameworks will be invaluable)

Thoughts appreciated

Love Steve

*A late addition to give us some concept of how a change affects the project

Hello Lovelies

This years event was in Rome and in my opinion the quality of the presentations was higher than ever, it was held in the same hotel as where most people were staying and this improved the networking greatly. One of the things I look forward to most is meeting old friends and new.

To summarise :-

Rome: Excellent

Presentations: Highest quality

Access and involvement of NI People: Marvelous

Networking: What a nice bunch of people the LabVIEW community is, I didn't meet a single person I didn't like (apart from a certain Mr Mercer who I have gone right off!, I got my revenge tho' oh yes..)

I think I have garnered enough material for 6 or more articles which is a real bonus.

So to summarise the presentations (and this is all from my perspective)

Frameworks

You are in a rich place indeed if you are in the market for a framework thanks to the efforts of these folks.

James Powell - A Dynamically Reconfigurable Actor System

Fabiola De La Cueva & Chris Roebuck - Delacor QMH (mentioned in their presentations)

Jim Kring - State Machine Objects with Events

It was interesting to me as well because it got me to thinking about what makes a good framework.

Show and Tell

Dmitry Sagatelyan - Going Agile, Applying Agile OO Design Principles

Dmitry was showing off a vintage boat refurbishment (Al Capones) and it was very cool. Beautiful code on a georgious ship.

Richard Thomas - Code Reveal – Swish a UI toolkit for Windows 8 type touchscreen

Dr Thomas does the BEST UI stuff!

Philisophical

I really liked the discursive nature of a lot of these presentations.

Fabiola de la Cueva - To Model or not to Model

As always a great presentation from Fab, I completely agree about using models to clarify your designs.

My Conclusion not Fabs: use modelling to help your own brain, help your customers brains but don't have them as your controlled documentation if at all possible as it's another thing to maintain.

Stephen Loftus-Mercer - LabVIEW and Classic Design Patterns

Oh he got me hook, line and sinker. Reeled me right in. Once again this was a brilliantly researched and fantastically presented piece. If you ever get a chance to see him present you should do it!

Sacha Emery - Actor System Benefits of Different Frameworks

Sacha has done important work here by baselining a common set of requirements into various frameworks and techniques. This has important ramifications that I'm really excited about. We just need Sacha to stop be self-effacing, this could be the dawning of the Emery Scale!

Arnoud de Kuijper - An Architectural debate: How to Abstract Hardware?

Always good, talking about when and where to abstract? No conclusions but a led discussion, Arnould is a star presenter IMO and another one to just go and see if you can.

Malcom Myers - The Trusted Advisor

Well presented and extremely useful, I feel we should see more of this type of presentation in future events.

Chris Roebuck - Architectural Design Processes and Methodologies For LabVIEW

Light and interesting talk on how Chris and Fab (for indeed it was them) tried to reconcile very different ways of developing code.

Techniques and Toolkits

Jarobit Piña - Revealing The Secrets Of The Packed Project Libraries

A nicely clinical review on an area most of us hadn't really deep-dived.

Peter Horn - Assertions in LV

This is based on a section in Code Complete and is a really good piece of work and damn useful. Good software engineering!

James McNally - LabVIEW and the Web

Useful to know and very well presented. Now I need to review his slides to see what to get up to speed on!

Sam Sharp - WebSockets - Bringing LabVIEW to the Web

Extremely well designed tool-kit, one I will be using.

and of course the peerless Jeff K showing us how to visualise asynchronous data between loops, I thought it was particularly effective with producer/consumer loops set side-by-side.

Any techniques presented were usually shown with advantages and disadvantages, I really applaud this clinical approach.

After that there was the discussions that fleshed out the ideas and formulated new ones.

This is a valuable event and I am so lucky to be able attend, if you get the chance give it a go! It's also great fun.

All I can say is thanks Nancy Jones, you done good!

Lots of Love

Steve

Fabs Review:http://www.walkingthewires.com/2015/04/22/cla-summit-europe-2015-post-event-review-2/

Martins Review:http://www.dvel.se/blogg--nyheter/certified-labview-architect-summit-2015-a-quick-summary

Right then clever clogs's

Here's a blast from the past and I was quite pleased with it. I'll show the code later...

I have the following characters (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z and 4 control chars)

I want to transmit 20 characters but only have 14bytes to do it.

How is it done?

PS. As a technique this would be useful in the FPGA world I think.

If you're coming to Rome next week come and say hello and travel safely

Love

Steve

Sorry I've not been very talkative lately, I've been busy putting together my presentation for the CLA Summit in Rome and it's been a considerable effort (although you'll find it hard to believe when you see it!).

So all the slides are complete (sort of), and now I'm just running through the story I want to tell.

All in all I'm fairly pleased with it, although I'm suffering the usual pre-presentation angst.

• Am I the only one interested in this stuff?
• Am I the only one who finds my jokes funny? (although this presentation only has 1 joke)
• Am I the only one who thinks this is worthy of a CLA summit?

In my strange mind if I wasn't asking the above questions I guess I wouldn't bother doing the presentation in the first place.

My research was hampered by there being very little computer science on graphical programming, this is as surprising as it is interesting. Why is LabVIEW ignored by academia?

I joined the ACM to help with the research and I have to say it's pretty good value at $99/year, although it does seem full of articles like

"META II: Digital Vellum in the Digital Scriptorium - Revisiting Schorre's 1962 compiler-compiler "

             ^

           ^  ^       

             |

A fascinating read, I highly recommend it!

The webcasts are brilliant tho' involving industry giants like Steve McConnell et al

Business wise we've been really busy this year and the decision to step away from industrial test systems seems to be paying off, we're now breaking into maritime systems and we hope/believe this will be a major source of work for us. The best thing about it is that it is pretty much virgin territory with regards NI. Keep a look out for the SSDC emergency response yacht. Thanks cRIO for giving us the tools to do the job!

Finally a shout out to the LabVIEW community, you are so generous and helpful. I needed a problem solving quickly and at little cost (a demo we're not being paid for) and on the off-chance someone had done something similar I posted it on the forums, within 48 hours I had a working VI in my grubby mitt. Kudos to all! I don't post enough on the forums (my wierd little niche interests about LabVIEW design aren't really relevant to a lot of the specific questions being asked, but I need to pay back my debt so will now try and answer at least 3 questions)

I will do at least one article based on my presentation after the summit and I also have one on Agile in the pipeline, I've been watching some quite interesting videos on it lately.

Here's a sneak preview of a howl of anguish in powerpoint form

Travel safe anyone coming to Rome, I look forward to seeing you there.

Lots of Love

Steve

Tomorrow the CLA Summit in Austin starts and I really wish I was there. Ah well I'll have fun in Roma.

So just to bring everyone up to speed.....

CLA = Certified LabVIEW Architect <--- highest LabVIEW certification.

Every year there are 2 CLA summits, one in Austin and one in Europe. A subject is picked (which I usually studiously ignore for my presentation), and 2 days of presentations and a day of round table discussions follow.

It's full on! and I have to admit I begin to flag after day 2 and while I'm in confession I'll also admit that sometimes the discussions go right over my head, but that's actually a really good thing. I want to be challenged by the discussions, it's brilliant. For me the main education I now get is from the community.

The software process is coming to the fore and currently there's a focus on Agile, LabVIEW fits very nicely with the Agile Manifesto. In fact Kent Beck would explode with joy if he saw the inclusive way most LabVIEW projects are developed. The only thing I would like, is for us to push our own manifesto, I strongly believe that LabVIEW is sufficiently different and rapid that it bends standard processes somewhat.

The focus in Europe seems to be more at looking into architectural issues and pulling them apart. Also 6 of the presenters come from our user group CSLUG, it's something of which I'm pretty proud.

I'll also doff my cap to the new CLD summits, I attended the latter part of the inaugural summit in Newbury and it was excellent.

Austin in March smells nice to my European nose, is it the Cedar?

I'm enjoying preparing my presentation this year, it's something a bit different again, hopefully it will sit in the back of peoples mind and niggle away at them. It's been a long time in gestation and explores some thoughts I've been mulling for years now. The start of formalising the concepts started here and in the LabVIEW Rocks section of our book. I really want to get a handle on why I found LabVIEW to be different to the other languages I've used.

So if you need an excuse to get certified, it's hard to get and easy to keep and you get to meet up with clever people in nice places, as a bonus you get your brain filled up with ideas.

So for everyone who is attending travel carefully and enjoy!

Lots of Love

Steve

As you may have noticed I studiously avoid writing marketing pieces carefully disguised as news..........

But NOT today!

It's only because I'm chuffed though as we got our ISO9001:2008 certificate on Friday and it's been a pretty positive process.

First of all it's a fair investment of time and money for a company of 3 (about $4k a year for consultancy and surveillance) and that doesn't include our time in designing and maintaining the processes. Like all business decisions the question needs to be ..can we get the money back?. Rather luckily for us one of my customers pays this as part of their support agreement..bonus!

Why do they do this you may ask, is it because we're so amazing. Nope, it just makes their paperwork easier. If we have a certificate they don't need to audit us, they in turn don't need to be audited and so the gravy train rolls on.

So for the small businesses out there here's what we did....

We hired a consultant (Daniel Russell) that supplied an online Quality Management System (QMS), this was modified to our company needs.

The QMS describes the scope of the system (design, provision and supply of software with associated support) and then describes the processes and documents used for handling complaints, training, roles and responsibilities etc. Covering Design, Nonconforming product, purchasing, inspection and monitoring. It has an online audit, management meeting, training and feedback system.

I found this to be the difficult bit to get my head around, luckily our consultant made it nice and easy.

We automated what we could (see Emails, Bug Reporting, Backups, VPS) and were in the lucky position where we all work in approximately the same fashion (consider that between the 3 of us we have about 90 years experience, so it could have been a bit like ductaping 6 angry giraffes into a cardboard box). For us automation is great, it's what we do and saves us writing documentation. So for example the method for backing up is to select backup from a menu on our project management tool.

Let's look back at the working in the same fashion comment, this I think is what has made it relatively straight forward and is a bit of an advantage for us. We have a common design methodology that allows us to all develop code in a similar way and to a similar rhythm. So although our methodology may cause some contention out there in the community, the fact we all comply to it is HUGELY valuable (Oh and we broke though 200+ projects now, so it's pretty tried and tested).

Bug reporting and version control are other fantastic tools that most of us routinely employ and that the world of quality just loves!. Showing how we can download the latest versions of our documents, just by right-clicking and selecting update was a real boon.

So the assessment was conducted last Friday by our assessor Stan and we sailed through with nothing more than a "Well Done!". He was extremely helpful and made some very good points. It took 6 hours and made my brain hurt!. We will then be checked yearly and the jobs a good-un!

The benefits are pretty easy, we are adding value to our service so we can charge more, but on top of that are that good practices make good software. The effort we put in means that the system works for us, rather than us bending to it. In the UK military, Govt, large blue chips all would like their suppliers to have it, because it saves them money and time in assessing us.

Lots of love

Quality Steve

Howdy Doody LabVIEW Lovelies

Emails are great for circumventing firewalls and IT. It has been very useful for our bug reporting system to have an on-board email client and a dedicating email address. We just give it out to customers and away we go!

So here's how we did it.

First we need a POP email client and one can be downloaded here.

We wrote a bit of code to plug the email details into our bug reporting database (this gives us a metric of how quickly we respond to an issue for ISO9000).

We can then query the database and search for any new emails in the system, this is done on a button press with my pretty email button.

All nice and easy....except when you add attachment and also every single email server appears to format it's emails differently (currently I'm fixing it on command but I really need to do some more studying of this).

First issue was attachments. Some descriptions of this are included here

Email is sent as text and therefore the attachment will need encoding into data that is safe to transport. The most common method appears to be base 64. For us base 64 is pretty marvelous for encoding blobs in databases (Binary Large OBjects) for similar reasons to emails we don't want spurious control characters as part of your SQL query. In fact I would now recommend encoding any entered free text as base64 into a query.

Here is how it looks in my database.

So the only time I want to decode it is when I display the attachment.

Someone cleverer than I wrote this (search base 64 decode).

An attachment is essentially made of 3 parts, the filename, the mimetype and the encoded attachment data, you then recreate the file in a temp directory and display it in a universal mimetype display (the webbrowser does this very well)

The other challenge is parsing the email and I haven't got a very robust solution to this at the moment, every new email I get from a different server appears to have a different standard. I need to hit the books I think or do a reiterating parse until I get something useful (yuck!)

There! an article with LabVIEW in it, hope it is useful

Lots of love Steve

PS there is a bug in the Pop VIs that can't handle large attachments, I'll be happy to help (supply code) if there is an interest.

PPS encode and decode base64 is useful for other stuff too where you need to restrict the types of characters.

Hello My Sweets

This article is a plea! Sadly the people who really would benefit from listening to this plea will probably not read it, but it may add power to you my dear readers.

PLEASE PLEASE PLEASE DEAR CUSTOMER IF YOU SPEND $$$$$$$ ON SOFTWARE, DON'T SPEND 0.000$ ON THE HARDWARE IT WILL LIVE ON!

Most LabVIEW programmers in the western world charge between $50 and $250 an hour. Most software that is written will cost in excess of $10k.

As discussed many times in this blog a well designed program will cost less to maintain than a badly designed one. Taking software maintenance out of the loop, let's reflect on some of the uses of our systems and how saving money on the hardware can be a bad thing?

Production Test

A reasonable percentage of our systems will be part of the production environment, generally these projects are costed on a payback basis, this payback is generally ❤️ years (if you can get the payback <2 years you are almost certain to get the job!). For most industry sectors the expected life time for a test system will be >5 years.

The cost of failure here can be as follows......

• Inability to produce
• Reduced capacity to produce
• Disruption in the product flow
• Poor test quality
• Lateness
• Cost of repair/support

Monitoring

We are looking for accurate measurements here, generally these projects are justified on a pre-existing failures and retrospectively costed on the cost of putting the failure right. They usually sit on the machines for years.

The consequences of failure here could be...

• Machine Damage
• Machine downtime
• Poor decision making

Control

Here we usually need lack of down-time and responsiveness, these projects are often new requirements or replacement systems. The costing therefore is a pretty standard process improvement or cost saving.

In addition to the costs discussed earlier we have......

• Difficulty tuning
• Poor machine capability
• Destruction of the thing being controlled
• Safety

In summary bespoke software is expensive, LabVIEW is usually written to do high value and important things. The cost of failure for the customer is high!

For us the real cost of failure is that the project fails and is not used, this can result in loss of business and reputation. i.e. damned expensive!

SO WHY THE HELL IS SO MUCH OF MY SOFTWARE BEING PUT ON $200 DELL VOSTROS!!!

By way of example here's a case study...

We provided the software to control a vacuum furnace designed by a bespoke machine manufacturer to a large Aerospace company, the total cost of the system was approximately $350k, our software services were probably <10% of the total cost. To save money they used second hand vacuum equipments, scrimped on the sensors, heating elements and lid control. The prospects for the job were that we could modernise vacuum furnace design and sell these on, we could also replace the aerospace companies 4 vacuum furnaces. The system never worked correctly in all the areas where money was "saved", we suffered additional software costs struggling to get the system working. Unsurprisingly none of the prospective work surfaced.

On top of this consider the concept of rare resource, in most companies the guys and girls who write the bespoke software are usually bogged down with far too much work. Isn't it just good business to ensure this resource is used efficiently and believe me trying to get cheap-ass hardware to work is not efficient!!!

Starting the week in feisty mood.

Lots of love

Steve

HAPPY NEW YEAR!!

I hate shopping!, I detest trawling around shops looking at stuff I'm not interested in, I abhor the heat, the boredom, other shoppers!

But I don't hate all shopping, here's a list of things I like shopping for....

• Comics
• Music
• Boots
• Coats
• Custom made jewelry

The first 4 I like buying for me, the last one is weird in that I don't wear jewelry, so my wife is the lucky recipient. (this is leading somewhere I promise)

So for my wife I commissioned this ring (surprisingly inexpensive at approx $200 and a delightful experience from start to finish, click on the picture for more details)

When she finished it she sent an email with pictures, the heading of which was TA DA!!

And this got me thinking, the antithesis of the WTF! is the TA DA!!, where-as someone reviewing your code will judge it in WTF!s, when you unveil a piece of software that is very cool we should exclaim TA DA!!.

So may your 2015 bring many TA DA!!s and few WTF!s

Lots of Love

Steve

I WANT YOUR TA DA!!s PLEASE ADD A BIT OF CODE THAT YOU ARE REALLY PROUD OF TO THE COMMENTS, LET'S START 2015 FEELING SMUG

Festive greetings my Glorious G-Programming Gorgeousnesses it's time to recap the year

Where has LabVIEW taken us this year???

Work

Lots of Laboratory Management systems for me, plus some cRIO data logging, Oscilloscopes, Oil filter test systems, materials research testers (various). For Adrian and Jon instrumenting up a truck to fire lasers into the sky, cRIO comms hacking on ships, quite a lot of pressure test systems, high speed bearing test system and jet engine test software.

We've also been ploughing through ISO9000 certification.

We lost our project management and hosting system to hackers, if you've been paying attention you will have read all about that and the rebuilding effort.

This year was more difficult than last year but we've really made some advances in areas important to us and the forecast for next year is rosy indeed!

Blog

20 articles this year, >50000 views and 400+ comments passed and I'm still enjoying writing it although I expect the articles will have a longer gestation next year, with help from Jon and all the wonderful contributors. A huge thank-you to everyone, hopefully we'll have some more great discussions and collective brain scratching next year. I need to find some more contrary opinions I think.

Twitter

I finally got a phone with some smarts and can now be followed on @swatzyssdc.

Favorite Tweet belonging to me so far has to be .....

As you can see I'm being highly professional in my approach to social marketing!

CLA Summit

I was privileged to present about process smells at CERN in Geneva and it made me smile for weeks afterwards. The other presentations were fantastic and worth the effort of getting a CLA. A truly inspiring place and I got lost in a casino car park after drinking a tower of beer amid a lot of giggling.

Here's the where we got shown round ---> CMS detector

Tower of Beer Beer Beer! It made me happy!

CSLUG

4 meetings this year and some excellent material covered, the May meeting coincided with the inaugural CLD summit in Newbury. Our December meeting was broadcast and put on youtube. This is available if you join CSLUG and follow us in Google+ (This is a protected site because we want some freedom in our discussions)

Subjects covered...

Recursion

Re-use

A lot of amazing applications

SQLite (including James Powells fantastic application)

Version Control

TDMS

And much more besides......

It really has become a nice forum and I don't have to present every time too . The distance people are traveling is really stunning.

Adrian and I popped over to SoWLUG(UK) in October and I even got a round of applause for my presentation (don't get those at CSLUG!)

Case Study

Adrian has written a case study on our comms hacking Data Collection System for Condor Ferries and it's spiffing, we have high hopes for this!

Anyways I made a Christmas Card, have a great holiday if it's one you celebrate, if not enjoy the empty roads.

Lots of Love

Steve Watts (Middle)

Adrian Brixton (Right)

Jon Conway (Left)

Collectively SSDC Ltd

Hello my LabVIEW Lovelies

This is a topic that has been floating around my head for too long now and I've been mulling it over to the point it has become a bit ironic.

I'll warn you now, there's no LabVIEW here, but there is one of the things that cause projects to go horribly wrong.

I have lots of ideas, here's one of my less stupid ones.....

Business Card Top Trumps

So rather than a boring old business card, you get to make your Top Trump business cards, where you pick your cliched business attribute from a set number (110% Max from a bucket of 300%, only I'm allowed 110% for everything as it's my idea!). And you don't just give them away, you have to win the card fair and square!

What a brilliant idea you may think and you'd be right, trouble is ideas are cheap and rightly so, they should be cheap! An expensive idea is a very bad thing. It's converting the idea to reality that is the expensive thing, it's expensive in time, energy, effort. It's the blood sweat and tears that makes an idea expensive.

So why is an expensive idea such a bad thing? it's because it makes it harder to give up on. Think evolution..lot's of ideas, throwing away the ones that don't work.

Let's apply this to the software design process. We spend ages writing a "complete" list of all requirements, we design our code to cope with future requirements, present it to our customer and they start picking it apart. We feel defensive having worked really hard on this, it is the pinnacle of our programming capability,  we have also added complexity to cope with imagined future requirements. Our ideas are expensive and the term I use here is design pride.

Writing a "complete" list of requirements is a proportionally similar effort similar to writing code in a high level language. As we've discussed before the accuracy of requirements usually survive to point of the customer seeing the software (sometimes using the software). Reality has a habit of throwing up a whole new set of requirements.

So how do we keep our ideas cheap? We need to expend the minimum amount of effort prior to presenting a design to the customer.

This also applies to other areas of life, good management encourages lots of ideas and assigns no blame to the ones that don't work out. Experimentation is good and should be done with the minimum of cost, if you invest $$$$$$ in a feasibility study it is unlikely that the project will prove to be unfeasible (so many death-march projects should and could have been killed early saving billions).

Cheap failure is fantastic way to learn.

Here's hoping you hit the G-spot (now that's what I should have called this blog!!)

Much better on the Randomness this time I think!

Much Love

Steve

Loosely speaking I've been running a LabVIEW User-Group (with a great deal of help from Adrian Brixton, NI (numerous), Chris Roebuck, James Powell and many others) for about 5 years now. Click here to see more.

And I'll be honest one of the main reasons for starting it was as a bit of marketing, but over the years it's become much more than that. So here's my thoughts about user groups.

Presentation Skills

If ever you have seen me do a presentation, it may come as a surprise that I have no formal training. I'm a programmer and never went to university, so from 18 I have mainly interacted with machines on the factory floor. The idea of presenting filled me with horror!

In my opinion being able to present your ideas comes shortly after having some ideas worth presenting. So you learn LabVIEW syntax, learn some ways to program, make a few mistakes, nurture some opinions-----> now you will benefit by being able to present.

And why is this important? $$$$$$$$$$$$$$$$$$

People will never know you have these ideas and the value of them unless you can present them.

A User Group is the best place to find your presenting mojo! and technical presenting is our forte, give us 10 minutes to describe how great our companies are and we'll struggle, give me 10 minutes on why I hate \user-lib and I'll hit you with slides, opinions, enthusiasm and maybe a few jokes.

Ideas Ideas Ideas

Generally a well organised user group is a friendly and supportive place, with people with ideas and experience at least on a par with yours. What better place to throw out a concept that may have never otherwise seen the light of day. I love the idea of academic discussions from professional programmers, this holds a great deal more meaning to me than academic discussions from people who have never had the pressure of deadlines, fixed prices or being paid by the hour to do work.

Programming outside of your tunnel

All the worst mistakes I make are because I'm mentally lazy and I seldom solve a problem in any way other than the first one that springs to mind. I'll assume most of humanity also has this problem. Sharing you code is a great way of re-evaluating some of your design ideas, sharing your design ideas is a great way of re-evaluating some of your basic pre-conceptions.

Friendship

Hippy moment coming up....

I actually try to separate work and home life, but I've found business to be mostly about relationships and over the years I've met some really great people and a user group is a nice excuse to all meet up and talk about something we all are interested in (sandwiches).

I also have huge admiration for people who present their own code, it's really a very difficult thing to do. Kudos to my CSLUG friends!

Filthy Lucre

So finally let's talk about marketing, some people impress with their fancy cars, suits, offices etc. In the programming world it's generally brains and experience.  A user group is much more up our street, we have a genuine technical interest in LabVIEW, we have opinions and are happy (sometimes a little too happy) to share them. Out of all the marketing opportunities a user-group fits us perfectly.

Remember : Marketing=hourly rate

We're going to try something new for our up-coming meeting; broadcasting via google hang-outs, this will be available to anyone who joins the CSLUG circle (if I can work out what the hell I'm doing). It will be chaotic but should be amusing.

So if you have a user group near you, join up and when you're comfortable present (the pain wil pay for itself many times I promise you)

If you don't have one near you start one up, NI will be delighted with you and there's still lots of puns left using LUG!

If neither of those options are available try the virtual ones or come join us on google hangouts, we can get you to present on Skype

And NI, how about a user-group track at NIDays, NIWeek?

Lots of Love

Steve

Hello my lovelies

This blog has not been nearly ranty enough lately, so.................

There's a lot of proscriptive recommendations in the LabVIEW world and some of them we struggle to understand, so keeping with our foolish nature let's have a closer look at them.

Over-use of Case Statements is Bad!

This is often trotted out and  WE JUST DON'T GET IT!

A case structure in LabVIEW is equivalent to a switch statement in C++ or Java, It's interesting to see if there are design restrictions on the number of branches handled in a single switch statement in these languages. A search didn't show much, this indicates that it's not a big issue in these languages. In fact the only issue was that in text based languages the statement becomes a pain to read through. Um not an issue with LabVIEW (although better filtering/navigation of the case structure would be a massive improvement).

We've even seen a company coding standard that limited the number of cases in a statement. Why on earth would you want to constrain your designs in such a way??

Local Variables are evil!

Rather than blandly inhibit their use wouldn't it be better to describe the situations where badly placed local variable cause issues (the "expert" says that Local Variables are bad lets just spread the meme without thinking about it). If you have a massive block diagram spanning a lot of LabVIEW dataflow time and you bung local variables into the free space you will probably get dataflow issues. Methinks the issue is not understanding dataflow rather than using local variables.

Our advice is to use Local Variables in bounded LabVIEW structures doing one thing only (short and sharp). So Event Structures, States and Queue driven case structures work fine in our book. That way you will read a valid local value, the diagram will be nice, clear and clean and if you have named your variables correctly it will help document your diagram too. 

So what is more difficult to understand a clearly labeled and named case structure with bounded local variables acting on this data or a load of complex logic, data wires through shift registers or references. (ducks out of way of the incoming flames).

Oooh the concept of diagrams spanning dataflow time!!!, maybe there is a seed of an idea here related to the physical aspects of a system.

Global Variables are more evil!

Again the proscriptive statements around global variables are "Global Variables are bad, they cause race conditions". This annoys me because it takes a pretty standard software design issue and makes it LabVIEWesque. It would be better to write it "Global Variables can cause problems because shared data is tight-coupling and this will cause unpredictable behavior". We've said it before but once again: race conditions are just one symptom of poor data coupling. We find global variables very useful, but we make them private members of an LVLIB and use a public interface to control access to the data if required (ideally it should stay in the bounds of the LVLIB). The real truth is that in a well designed system you shouldn't need global access to data.

"Two routines are global-data coupled if they make use of the same global data. This is also called common coupling or global coupling. If use of the data is read-only, the practice is tolerable. Generally, however, global-data coupling is undesirable because the connection between routines is neither intimate nor visible. The connection is so easy to miss that you could refer to it as information hiding's evil cousin......information losing"

Steve McConnell - Code Complete

Stacked Sequence Structures are like the goto statement in BASIC

no they are not!

The worst crime a stacked sequence structure is guilty of is obscuring some of your code. It's equivalent to using 5 pages rather than 1 long page, and actually the true crime is writing code that needs compressing in such a cumbersome fashion. It's never caused us a single issue with understanding the block diagram. Unlike goto statements which are a complete structural nightmare in text based languages.

Our coding standards do not proscribe tools or techniques but mostly concentrate on readability and simplicity.

On another note..

Function Points.....

We think this is an important exercise and we're going to ignore the lack of reaction to the article and plough on regardless with a manual trawl through an SSDC project and try and finalise a method for reverse engineering the Function Points of a project. This will include some VI Metrics, but we're trying to pull out just logical complexity. We will then try and automate the process. We've just got to do the hard miles first.

Lots of Love

Steve and Jon

Hello Lovelies

We have been reading a lot of discussion recently about LabVIEW performance and scalability and this has become increasingly interesting to us because we don't have any real issues with it. Is it the technique/method or the project that is making the difference here?

Well, before we can really evaluate techniques and methods we need to be a bit more scientific about judging and comparing project complexity. If for example you are using 15 classes, 400 VIs etc to print "Hello World" it should come as no great surprise that LabVIEW grunts a bit when you actually throw a real-life project at it.

Function Point Analysis is a method of breaking down a project down into similar sized lumps, as an estimation tool these lumps are generally based on an approximate effort to do a task. In this discussion we want to pull it a little bit away from just being an estimation tool and use it as a baseline for our complexity metrics.

So project xxxx would have 350 FPs and if we use 500 VIs to solve the problem rather than 5000 will LabVIEW perform better. If this is the case (and without doing this work any discussion is fairly meaningless currently), should we then modify our techniques to better accommodate LabVIEW. At the very least we would have a tool the would help us predict if we're going to run into trouble.

So here are some examples of a single Function Point, this could be argued as being too fine a grain, but we have to start somewhere.

1 Hardware Action (e.g. DMM Initialise)

1 Database Query

1 File Action (save or load)

1 User Interface Update

1 User Event

1 Report Action

1 State - transition (counting the transitions may give a better number than counting the states, but I'm undecided about this)

1 Communication message (via Queue or any other transport mechanism)

1 Logical Decision

Distributed systems should be regarded as separate projects.

The point of the exercise is to come to a consensus regarding a projects complexity so expect a bit of averaging out here and there (for example an INSERT SQL statement is more tricky than a SELECT but it should even out in the end)

So a question to you clever people is...

Can you think of any others and do you think this worth pursuing?

The next stage will be to assign these FPs to existing projects and do some comparisons. Perhaps User Groups could help here.

Lots of Love

Steve

Hello Lovelies,

If you've read some of our articles you'll be aware of our thoughts on Codes Smells and Anti-patterns. We think the term enbugging is a very elegant addition to this lexicon.

This article is based on the article by the Pragmatic Programmers.

A bug creeps into your code, it's not your fault it's just a bug, a gremlin, a random happenstance....

Or that's what we tell our bosses.

That's the easy way out, a bug is a mistake, it's a mistake in understanding, a bad design decision, an over-complication. The only people who don't make mistakes are not doing anything. We're very suspicious of people who don't make mistakes!

Sometimes you can have a day when you seem to actively putting bugs into the code. Welcome to the world of enbugging.

It's usually takes some setting up to have a really good enbugging session, decisions that are made days before cumulate into a world of pain. Removing 1 bug will generate 2 more. It's a recipe for stress and worry.

The techniques in the article for reducing enbugging talk about encapsulation and information hiding, writing "shy code".

In OOP an object responds to messages and these messages should follow the rule "Tell, Don't Ask". In LCOD we call our enumerated type a command and not a query. We are telling our object to do something, it may respond with some data or it may not. It's internal data is private.

Also minimize how much our objects chat to each other, keeping the data shared by our objects to a minimum (coupling) also makes it more difficult to put bugs in. Generally less shared data equals more predictable code, easier testing and less bugs.

Bugs like to hide!, you can help the enbugging process by giving them lots of places to hide in. Large block diagrams, making lots of decisions are a wonderful, fertile bug garden.

Small Testable VIs are more akin to a desert.

A cluttered block diagram is also a wonderful place to hide bugs. A clean, easy to understand block diagram makes enbugging far harder.

If your bag is dynamic loading make the dynamically loaded VI cohesive enough to be tested.

In fact a lack of testability is a wonderful way to grow bugs. If testing is hard you need to be pretty damn sure of yourself!

Bugs can easily placed in arrays, logic, maths and my own particular nemesis dates.

So where else is the best place for bugs to lurk?

Lots of love

Steve Watts and Jon Conway

The Challenge today my lovelies is this...

How to you programatically find the width in pixels of a specific font in a Label?

I'm rather pleased with my solution, but can anyone beat it for elegance. Pint of beer for the winner (I still owe Rich I seem to remember)

I'll put clues in the comments.

Lots of Love

Steve

Hello My Gorgeous Graphical Programming Godesses and Gods,

Today I wrote a vi to convert free text into Binary Large Objects and back again (for putting into databases)

and I called it.

BlobDeBlob.vi

I think this is the best name ever!!

or is it? better names in comments please.

Have a great weekend

Love

Steve

The final piece in the recovery puzzle is bug reporting.

I didn't fancy designing the whole thing from scratch so instead I searched around for a MySQL schema for such things, step up bugzilla. I was quite pleased with how I got hold of it. On a virtual machine I loaded a turnkey linux bugzilla system I then did a MySQLDump of the schema and loaded it onto my VPS.

I wanted to have bug reporting in our General Template and as a standalone application. I downloaded some MySQL LabVIEW VIs  that work very nicely and stuck these in my project and wrapped them as I normally do.

Then I put in a bug reporting screen.

If you are doing a reasonable amount of MySQL I advise coughing up for Navicat, it saves so much time on creating and testing queries.

We can then take the generated SQL and make this in LabVIEW.

We just replace the variables in the query with %s and away we go.

The other aspect of Bug Reporting is to see the status of the reported bugs.

I put in a filter that controlled my queries, preloaded with all the status's (already loaded this for the previous screen, so just a menu item on the string)

Another right-click menu item allows us to edit the bug.

Because I don't want to maintain the bug reporting screen on all my projects I make it into an executable and have it as separate project. I call it using the command line and use command line arguments to pass the project name.

This is the bug reporting screen for our Project Management Utility. I add some posh splash screens etc to the build, the final bit of the puzzle is to get it to update itself. Here's how

Phew that was a few hours work! Thanks codespaces and your careless disregard for simple security.

If anyone is going a similar direction, leave a comment, I am happy to give what advise/help I can.

Now where was I with Open Document Format???????

Lots of Love

Steve

PS I'm only implementing a part of bugzilla at the moment, it's a big lump of database and quite nicely designed too. Looking at the schema is a good place to start.

Hello my lovelies,

Hope you are all safely back from NIWeek, vacations etc.

I'm most interested in the new cDAQ and cRIO platforms they look a real advance.

I'm all back and running again now and implemented some pretty nice stuff on my VPS (I still have a lot to learn here so fair warning). The VPS Subversion repositories are working lovely and I've even used post-commit triggers to send emails of any commit action, this is very cool and I didn't know Subversion even had this capability.

Popular advice is store your backups in the cloud, bitter experience has shown that actually the reverse is also vital. So this article discusses getting your stuff back from the server.

First things first lets look at repositories. We store a repository in a directory /usr/local/svn/repos/CompanyName-RepoName (for example our documentation will be stored in /usr/local/svn/repos/SSDC-CompanyDocs)

We want to list the directory /usr/local/svn/repos and pull out a list of Repos, we then want to zip them up and post them to a directory accessible by FTP

svnadmin dump /usr/local/svn/repos/REPONAME | gzip > /home/ftp/REPONAME.gz

The above Linux command will dump the repository at /usr/local/svn/repos/REPONAME and pipe it to a gzip file REPONAME.gz. Here I sacrificed speed for UI feedback by doing each file individually and then ftp'ing it out.

IMPORTANT NOTE: Remember to password your VIs to protect your important login information!!!!!

I had to doctor the standard LabVIEW FTP VIs to give me some real-time feedback of transferred data. This involved copying \National Instruments\LabVIEW 2013\vi.lib\FTP over to my project and making a LVLIB to hold it. I add some Local Globals (my facetious name for a privately scoped global variable) to get the data going through TCP/IP.

I also added a publicly scoped VI to allow me to read the global data. Now I have a nice progress bar control updating with transferred data.

Noticed that I changed the colour of the FTP Get Multiple Files.vi, this is a mental clue that I have changed a standard LabVIEW VI.

I also dump my shared databases using the similar Linux command. The process after that is exactly the same.

mysqldump --user=******* --password=******* dbName | gzip > /home/ftp/dbName.gz

If you want any details, leave a comment and I'll fill in the gaps. If you want any code I'm sure we can sort something out, especially if you're not a local competitor .

Next week will be the last in this series and I'll be looking at bug reporting.

Lots of Love

Steve

I saved you time generating a mission statement in a previous article, now I'm going to save you time if you fancy writing an episode of Murder She Wrote.

Click on Jessica to see more.

I've been in recovery mode so have been neglecting pretty much everything except paid work and rebuilding our infrastructure.

If anyone else wants to follow a similar path here's what I have done and how I have done it.

First I hired a VPS . The first challenge is how do I talk to it? I'm a Linux imbecile by the way.

PuTTY is the answer and you get presented with a screen like this.

Next we need to secure our server and to do this we need to create a new user and disable remote access to the root user. Here's how.

One way I like to edit files in Linux is vim.

You can press "I" to go into INSERT mode and and "ESC" to go to command mode, :w to write, :q to quit.

Another cool thing in Linux is you can type > man command and this will bring up the manual for the selected command....very nice, "Q" to quit.

Next I want to load Subversion (I will probably trial Mercurial soon). Here is a very good article on doing this.

I decided to use svnserve as the interface to connect to Subversion. Mainly for speed and ease. This also has the advantage of amazing speed, but it uses a port usually blocked by IT so eventually I will need to add HTTPS capabilities too. Another job for another day!.

I wanted the creation of repositories to be as seamless as possible. Within SSDC we have a Project Management tool that would be the ideal place to bung in Subversion stuff. I added functionality for creating and viewing repositories.

Talking to the server from LabVIEW was pretty easy using a program that came with PuTTY called Plink. This program takes a file of commands and applies them to the server as if typed. Here's the code for creating a new repo.

To control access to the repository I copy a template configuration file as follows.

I need now to make back-ups and FTP them out to a local machine, this will be the subject of Part 2.

In Part 3 I will show how our bug reporting tool has been implemented. This is just being tested as part of our General Template.

And then I'll be back on Open Document duties, sorry about the wait.

Expect various articles on Requirement Zero, Mr Conway and I were going to do a presentation on it for NIDays, maybe NIWeek 2015.

If you're going to NIWeek, travel safe and have fun. I'll be sunning myself in San Diego.

Lots of Love

Steve

We use www.codespaces.com to host our Subversion repositorys and bought into the cloud-based business model.

They use Amazon cloud services to host their system and the selling point was secure off-site back-up every 10 minutes. This all seemed perfect for us and it really improved how we do business.

Imagine my horror then to being informed that they have been hacked into closure with all back-ups deleted.

This gives me a suspicion about cloud-based businesses. These are essentially small, low overhead companies holding liability for vast amounts of data. If anything goes wrong they immediately shut up shop, leaving the poor customer up the creak.

So now I have to find an alternative repository/bug reporting/project management tool and change all my documentation.

What a nightmare.

Love

Steve

As part of my general research I come across some good videos, blogs and websites (some I've linked to in previous posts I'll try not to repeat them here)

Here's a few that I have found interesting.

3 Flaws in Software Design

Part 1: Writing Code that isn't Needed

Part 2: Not Making the Code Easy to Change

Part 3: Being Too Generic

Part 4: Incremental Development & Design + Wrap-up

This is a really good set of articles and is very applicable to most LabVIEW projects.

Reading Code

Software archaeology with Dave Thomas (his example about over-use of frameworks/patterns made me laugh)

Agile

Agile is Dead - Long Live Agility (covers some of my suspicions about glossy words, acronyms and sold methodologys. Note: I like Agile it just grates when people throw out buzz-words without taking the time to understand them)

Design

Enbugging (a concept I really like and links nicely into code smells, anti-patterns etc, expect me to steal this term)

The Paperboy, The Wallet, and the law of Demeter - A nice example of coupling and kind of explains a niggle I have in the back of my brain about certain concepts popular at the moment.

Genius

James Mickens (When I grow up I want to be him, except he's younger than me grrrr, just some of the funniest, most beautiffuly written articles on software development)

Physics of Software (Expect me to be pushing the theme of something "feeling natural" in the coming posts, some of this stuff feels very natural to me - my ambition is to come back to this, but it is a very big topic)

Update on OpenDocument - give me a couple more weeks and I'll have something to demonstrate, when I have reached that point I will stick it on GitHub and we'll see where it take us. I expect to be learning from this, specifically how a open-source project can work with LabVIEW, if GitHub is useful etc etc.

I won't be using XPath as I ran into a brickwall to do with namespaces, a shame as it looks really useful. Luckily there is a nice method in the XML Parser stuff that will get me all I need I think.

Enjoy your homework - Hopefully we'll get some more in the comments

Lots of Love

Steve

Hello my lovelies.

Update: Check out this tool

This article is a little bit different in that it's the beginning of a project I'm been thinking about for a little while. At the very least if I take it no further my scribblings may save someone some time.

First the why

The beauty of having open documents is that as a software developer I can make a package for disribution to my customer without worrying about licenses. This just feel much more wholesome to me. So I've looked at various options (ActiveX OpenOffice, dlls etc), but they all involve driving someone elses code. One of the reference books available is called OASIS OpenDocument Essentials and in it is this little snippet that sums up my general feeling.

When talking about storing in a propriety format rather than an open format.

Note also that your data can become inaccessible when the software vendor moves to a new internal format and stops supporting your current version. (Some people actually suggest that this is not cause for complaint since, by putting your data into the vendor’s proprietary format, the vendor has now become a co-owner of your data. This is, and I mean this in the nicest possible way, a dangerously idiotic idea.) J. David Eisenberg

What I actually need is a way to generate a spreadsheet checklist for all the VIs in a project.

So what is the OpenDocument format.

Wikipedia sums it up thus.

The Open Document Format for Office Applications (ODF), also known as OpenDocument, is an XML-based file format for spreadsheets, charts, presentations and word processing documents. It was developed with the aim of providing an open, XML-based file format specification for office applications

Stuff I've learnt....

OD File Structure

If you save an OpenOffice or LibreOffice file it will save as an ODS (for a spreadsheet), ODT (for a word processing document) or ODP (for a presentation). These are a JAR format file, this being Java Archive or simply put a ZIPped package where some of the contents are NOT compressed. Here's one unzipped.

My first hurdle was not compressing mimetype.

Here's how I did it (using the Open G Advanced Compression VIs, doctored so that I can set the compression type)

The file that does all the work is content.xml and here's what I've learnt about this bad boy. The best way to describe it is to show a spreadsheet with some data and display the xml and then describe how they get there.

NOTE: the XML is from a spreadsheet where the columns haven't been squashed for artistic license, the xml for the one shown may therefore have more column info to describe the cell size.

After some headscratching and surprisingly little help from the internet I fathomed that it works like this....

The 3 table:table-column nodes describe the 1st column, the 2nd column with added width and then the remaining columns

We then have 13 table:table-row nodes that contain the cell information.

Of course this all looks lovely and ordered but the file really looks something like this.

<table:table table:name="Sheet1" table:style-name="ta1"><table:table-column table:style-name="co1" table:default-cell-style-name="Default"/><table:table-column table:style-name="co2" table:default-cell-style-name="Default"/><table:table-column table:style-name="co1" table:number-columns-repeated="11" table:default-cell-style-name="Default"/><table:table-row table:style-name="ro1"><table:table-cell office:value-type="string" calcext:value-type="string"><text:p>Title1</text:p></table:table-cell><table:table-cell table:number-columns-repeated="12"/></table:table-row><table:table-row table:style-name="ro2"><table:table-cell/><table:table-cell office:value-type="string" calcext:value-type="string"><text:p>aaaaaaaaaaaaaaaaaaaaa</text:p></table:table-cell><table:table-cell table:number-columns-repeated="5"/>

So I'll be using the DOM xml parser VIs and some XPath for searching out the nodes.

My plan is to make a polymorphic container type component where the polymorphic selector is the command. This will wrap the LVOOP document classes. With methods to Load, Save, Save As, Add Cell to Table, Add Array to Table, Get Cell Data, Get Cell Data Type.

If anyone is interested I'll post the code (it may be useful to use github to allow methods to be added)

Next step is to do some UML diagrams of the class structure. But that's for another day.

Lots of Love

Steve

As most regular readers will know my prime interest is software design and specifically why a design becomes complex. Since becoming a CLA I have had quite a lot of my fellow CLAs stipulate how important SMORES is when judging a good design.

In the interest of foolishness I going to state now that I don't get it!

So the question I throw back is this.

Is SMORES the only tool you use to judge a good design?

First I guess I should describe SMORES

I'm going to do my due diligence now and explain each one in turn. Most of this has been stolen from here.

Scalable

For something to be scalable, it must work the same without modification regardless of how much throughput the system has to manage.  In software, scalable software can handle one or many users, one or many channels of data, one or many reports, etc.

Modular

If you use SubVIs you are making modular code, if these modules are designed with some regard to coupling, cohesion and information hiding your code will more pleasant than if you don't.

Optimized

Software, processes, and systems should be reviewed and streamlined to ensure the best possible output has been achieved. 

Reusable

To make something "reusable" refers to the extra investment required to take anything originally designed for a specific purpose and add the input and output definitions and refinements to make the same object attractive for use on another purpose.

Extensible

Extensible refers to the ability to connect new functionality onto an existing system without having to rearchitect whatever you are connecting on to.  A good example of this is a plug-in architecture.

Simplified

Simplified doesn't always mean the object can or should be "simple".  It means that there is value to be had in making the object you are building as simple as possible without sacrificing scalability, extensibility, etc.

I have several issues with these as design considerations in my problem domain, I'll tackle the easy ones first...

Optimized and Simplified - now these seem a little wishy-washy and hard to measure to my engineering brain, who defines simplified for example. As we have seen from our design discussions here simple for me is not necessarily simple for someone else (more likely the other way round in my experience), so how do we judge it?. Similarly at what point are we happy that a system has been optimized to our satisfaction.

Modular - I've whittered on about modular design a lot here and it is kind of an assumption that if you don't use SubVIs you probably shouldn't be worrying about SORES (see what I did there)

Scalable - We've had several interesting conversations about this and my position is this, we write configurable software, this gives us a certain amount scalability. I would also add that LabVIEW is a high level language (definitely 4GL), some might even call it a Rapid Application Development environment. Should we really be applying this amount of importance to scalability for a language so high level?

Extensible - I think the following quote from an excellent article by avilay sums up a lot of the point I'm trying to make.

“but suppose that tomorrow somebody wants to add X here…”. Be wary of this design principle. Be very wary. Unless “tomorrow” is a real date in the future, and “somebody” is a real person, this design principle can lead you down a deep rabbit hole with nothing but dirt at the bottom.

http://avilay.wordpress.com/2012/09/01/what-is-good-software-design/

Re-use - I like re-use, really I do. But I suspect a lot of time is spent polishing code for re-use and it gets stuck away and never touched. There is some very interesting and honest work done on re-use that concludes that the payback of planned re-use is not quite what you would expect.

Arnoud de Kuijper - Test and Measurement Solutions did an excellent presentation at the European CLA Summit, in it he introduced SMURF

A version is linked here

Scalable
Modular

Unique
Reusable
Flexible

I prefer this mainly because I love the little blue fellas. Also Flexible is very very important to me and Unique is actually a grown up way of describing what we do. We have a couple of standard templates but quite a lot of what we do is unique from system to system.

Now I would like to add a few more to the list.

I can't believe Functional and Robust are not on the list. Readable, Debuggable and Maintainable are extremely important design considerations too. Measurable is also an increasingly important design consideration, especially in RT or control systems. As mentioned earlier Configurable as a sub-set of scalable is a very important design criteria for us.

Now how do our customers mark our software if they have to allocate points and how does this compare to our own marks?

James Shore writes about good and great software design in an article titled Quality with a Name. From the article: A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.

Also these requirements don't always play nice together, many of the techniques for extensibility seriously affect readability and so it goes on.

So am I dismissing SMORES out of hand?

I think SMORES is useful if you are designing APIs and toolkits, I think it is less useful for projects.

So perhaps we need acronyms for each type of use case.

Or

Perhaps we should not use acronyms blindly.

Lots of Love

S.T.E.V.E

It's about time LabVIEW caught up with all things internet so here's a preview of the next great thing happening to our favorite language..

Introducing CatVIEW.....

Notice the box like structure indicative of a while loop. No cat icon will be able to resist it.

Wire up your hilarious cat icons with the wool tool.

With CATView you'll be feline great every day!

Lots of Love

Steve