Random Ramblings on LabVIEW Design

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