Communication breakdown.

Progress on the swimming waveform analysis front is grinding to a halt as communication between the various team members has become difficult. A combination of time zone differences (12 hours between the 'thought leader' and the 'development team'), recovery from jet lag and unfamiliarity with the code sharing site have all contributed to the situation.

How best to get a grip on things again?

The main issue has been the way development has had to be carried out using a 'rapid prototyping' approach. Essentially get something up and running and review what it looks like then tweak (sometimes TWEAK) then review then tweak again ..... continue ..... until right answer. Which all worked fine when all parties were together in one place. However, now the review and development cycle has become protracted  the 'thought leader' is struggling seeing the code run and the 'development team' is wondering what happens next.

If you read the text on this software engineering practice everything works seamlessly and Bob's your aunt you end up with the perfect code (sorry 'app' - fully documented too!). We are attempting to use an approved approach that will keep us out of the hacking arena. However, what its not doing is helping much on progressing around the development cycles or on homing in of the final solution. You could end up going round and round and round and round ...... just another variation please.

What we need is a means of facilitating the capture of emerging requirements and or questions from the 'thought leader' that the 'development team' can then work on and reply to. Done in a simple and visible way so that all parties can immediately understand the level of progress, identify any issues, and know who is in the seat for resolving them. Progress around the cycle can then be maintained - hopefully.

Just need to get everyone using Trello properly now then ..... ;)

Languages suck .... computer ones that is ;)

More a though for the day this one....

I have been both impressed and confused over the last few months by the sheer number of software languages that you appear to need to keep abreast of these days. I am easily into double figures on the count and I'm not even trying. What is going on?

In the good old days you would get by with BASIC, FORTRAN and possibly C but only if you were a real geek. Oh and then there was JCL (my god - I'd almost forgotten about that). These days the number has ballooned and careers have been made upon the back of the various mutations of operating systems and their associated languages.

In past blogs - as you can read - even the production of a simple package (sorry 'app') to analyse a waveform has required quite a bit of soul searching on which language to use. Surely what is needed is some overarching operating system of languages to act as a master controller - hey maybe nobody has thought of that one!

With the IoT (Internet of Things) emerging what is the best way forward - or are we doomed to even greater mushrooming of languages.

The balloon (or my mind) must pop at some point.....

Data presented!

Well not much progress last week as holiday return trip home has got in the way - was a long way back!

There was a little bit of movement though - the week was spent checking the code. I was please to note that even with all the new programming language bell's and whistles we still ended up de-bugging using the good old print statement. Which was actually very simple in Python - unlike my memory of Fortran 'WRITE' statements - though I'm sure all that has changed by now - at least I hope so.

Anyway - here is a print out of 5 right (top) and 5 left (bottom) hand pressure waveforms extracted from the first dataset.

The work going forward is to start to analyse the structure of these to try and come up with an optimum shape that will deliver maximum power for the swimmer. A swimmer can then use this information in real time to make adjustments to their technique.

I don't know much about swimming but this is interesting stuff - the appliance of science!

Data extracted!

Well much to my amazement Bambofy has managed to build a code to pull out the swimming pressure data from the hand sensors. Not that I doubted he could do it, just that I didn't think Python was appropriate for doing this extraction. Just goes to show - old dog's and new tricks can happen. 

My view of Python - from looking over the shoulder - is it seems pretty flexible for string manipulation, good for object coding, simple to produce plots (we would still be loading the plotting library in Fortran - Python variant knocked up in 10mins no lie!) and can add up. Not sure what editor is being used to build the code but it puts out a great psychedelic screen for doing the edits!

Not sure how it will get on with the next phase which will involve a bit more complex mathematics - we will see......

Data extraction!

Not by me - Prof Jefferies has appointed Bambofy to help sort out the analysis of the swimming data.

First up is the data extraction so that we can pick out the waveforms associated with each hand. Given the way the data is stored even doing that is turning out to be a bit of a trauma. This is being done using Python code - so that's the end of me - PJ was going to do this in Fortran (same code era as me you see) but we have been overruled.

The monkey is now on Bambofy's back to split the waveforms into left and right hand sets - then the fun starts.....