Disclaimer

BEFORE YOU START: Please note that although I currently volunteer for both the Stroke Association and Age UK, the views expressed in this blog are strictly my own. I am not a spokesperson for either (or, indeed, for any) organisation. I am based in the UK and the blog therefore has a UK bias - I've tried to use the Glossary to explain any terms which might be ambiguous, but if you think there is anything I've missed, please message me.

Thursday, 28 February 2019

What a blood pressure measurement is in reality

Seems a bit daft to post on this subject, but I struggled to find anything out on the web about what the numbers actually represent. There's plenty of stuff telling you what values are high, normal etc. but nothing about what is actually happening during the course of a measurement. But I found some documentation eventually, looks like it is aimed at clinicians, which I'll try to explain.

You wrap the cuff around your upper arm. At that point, you're over your brachial artery, so a direct route to the heart. The documentation I looked at made a big deal of this, so this is important.

The cuff inflates sufficiently high that it stops blood flowing. If you were listening with a stethoscope, you'd hear nothing.

You gradually let the pressure out of the cuff. Your heart pumps with sufficient pressure that, sooner or later, it overcomes the pressure in the cuff, and the blood starts flowing again. Again, if you had a stethoscope, you'd hear the heart beating. When blood first starts flowing, this is the systolic blood pressure - the pressure when the heart beats.(

You keep releasing pressure from the cuff. You can still hear the heart beating. Again, sooner or later, you stop hearing anything. At that point, this is the diastolic blood pressure. Basically the pressure in the cuff is sufficiently low that your heartbeat can't be heard. It's the pressure when your heart is resting. In my simple world, I think of the heart as a machine which is either on (pumping) or off (resting). In this scenario, at any rate.

I mean, a stethoscope is just one way of detecting these signals. I would imagine an electronic machine would detect these points by "feeling" when the pulse starts and stops (a momentary slight increase in pressure, say, as the heart pulses). I think my next task is to find this out.

I've tried to explain this briefly and in layman's terms. If you feel i could do better, please leave a comment, or there's a link at the bottom of the page which you can use to contact me.

Progress

I wanted to say a little bit about the application I've been writing. I finally finished it yesterday, after about 6 months. For one person, quite a tall order.

I finished writing it yesterday, but there is still more to do. The first thing I did, once I'd finished, was to allow Microsoft's Code Analysis tool to inspect the code. This came up with about 350 warnings and messages. Some of these, it wasn't practical to change, others of which, it was in a snippet of code I'd pulled off the web, so I was reluctant to change it. But there were some bits and bobs where I'd fallen foul of some convention or other. There were also parts that I guess I'd written in quite an old-fashioned style, and the tool suggested I rewrite these using some simpler construct, of which I was previously unaware. I mean, in that respect the tool was brilliant - I'm aware that we write in the flavour with which we're comfortable, so when new advances come along, we don't necessarily adopt them. Especially when these advances are just shortcuts in any case - you can still achieve what you want the original way, but the new way is cleaner or quicker or less code.

There's an old industry adage that the less code you write, the fewer bugs you write, and it is still every bit as true today. Where Microsoft have included a feature, it's a good idea to use it, if possible, just because they'll have had teams of people developing and testing that feature, far more reliable than little old me. It doesn't always work out that way, but that's the general rule.

So I had these 350 warnings. It sounds a lot but it's not, in my experience. I went through them one-by-one, and changed my code accordingly. I gave the app a cursory test this morning, just to make sure it all still hung together, and there were a few areas where changing the code had actually introduced bugs.

The next step is to give it a thorough test, and that meant writing scripts for all the tiny things on each screen to go wrong. Ideally, somebody else should do this, because a developer will tread a certain path through an application, and will be less likely to spot problems. A tester will also tread a path, but it will be a different path and, in any case, a good tester will vary the path they take. But alas, there is only me. So I've just finished test scripts and will start on those tomorrow, just to give myself a break. Unfortunately, when you use "community" editions of software, the amount of help you get with testing is minimal - I'm not sure it is a great deal better with more enterprise versions. In any case, you need to start with scripts, just because they tell you what to test. But I'll probably steer clear of anything automated. Previously, I've found it brilliant to be able to click a button and watch everything be tested automatically, but it takes a lot of effort to get to that point. And, people still employ testers, so my experience is obviously consistent with industry - if you could do it at the push of a button, they wouldn't have jobs.

I like to think that my attention to things like project plans and testing is what sets me apart from other one-man-bands. Of course, you can cut corners when you're on your own (and I do!) but things like this are just natural to me because of the environments in which I've worked.

Monday, 25 February 2019

People's knowledge of diabetes

We went over to see my mother-in-law at the weekend. We also met up with my sister-in-law while we were over there. It was funny that, for both of them, a lot of their knowledge of diabetes was just plain wrong.

I mean, nothing against them. Neither of them has diabetes, certainly not to the extent where they're shoving meds into their body to control their sugar, so why should they be expected to know about something they don't have?

But it was interesting that they have picked up their (mis)knowledge from the media, and a lot of that is just wrong. There is an implicit assumption that diabetes is about sugary food, whereas it is carbs in general. Sure, sugar is carb, but a portion of bread might have every bit as much effect on my sugar. I know, because I measure it. And there's a hereditary link, it's not just down to lifestyle. I know this because much of my father's family have it, too. In fact, I can tolerate a bit of chocolate every now and again, a 50g bar every week or so, and it doesn't raise my  sugar noticeably. Certainly not as much as if I have hot dogs/rolls for lunch.

But it really gets my goat that the media continually spreads this misinformation. I've even argued online with somebody who've said to me, "change your diet and you'll reverse your diabetes". And I can stop taking insulin, just like that. Actually it made me have a stroke, smartass.

Tuesday, 19 February 2019

Information Exchange

Developing sortware, you'd often come up with a problem and think "how do I solve that?" There is documentation available online, of course, but often it doesn't hit the mark, People have written blog posts, too, but often they are very simplistic, I suppose to help convey their main point.

There was another type of site, one which used the community's collective knowledge to help solve a problem. Once one person has accomplished something, they can teach somebody else to solve that problem, and pretty soon the "thing" isn't a problem any more.

One such site was Experts Exchange. They would tantalise you with the same question you had but, oops, before you were allowed to see it, they just wanted you to subscribe to their site. The idea of knowledge being so directly associated with money really used to put me off, although when you think about it, it is everywhere these days. But, in my book, why would you not share knowledge, especially in a niche subject with a willing pupil?

So I never went near Experts' Exchange.

One other site was Stack Exchange. This site, at least, was free to both request and contribute. In fact, for several years I was actively involved in the Bicycles version of the board, until shortly before the stroke. They also have a board on the subject of software development, in which I've dabbled but was never a serious participant. Of course, all these boards are the same thing - it is just the subject matter of each which is different. In theory, you join the site for free and post your question for everyone to see, and people can try to help, normally with a partial answer. You end up with several of these answers, and hopefully by aggregating them together you get a decent idea. The site has nuances, such as the duplication of information. If you ask the same question as somebody else, people will close your question and point you to the other question/answers instead. If people like your question, you earn some points, known as your reputation. If people like your answer, you get more points. In that way, the helpful people, and those who ask the most meaningful questions, float to the top.

This sounds like a great site, but it has its own drawbacks.

Because of these points, people who are naturally competitive will follow the site in minute detail, and will put forward anything that they can possibly think of, in the hope that somebody gives them points. Sometimes it is useful, but often not. So it degenerates into a pissing contest, and in fact you do see rivalries played out there, and the primary aim of helping people soon becomes no more than a by-product - the casual visitor won't notice this, but I found it surprising how personal things could get. And very often, this translates into voting patterns, too, and I'm afraid I sometimes fell into this trap. So-and-so thinks a contribution is good/bad, you trust their judgement so you vote that way too, possibly not paying as much attention to the actual contribution as you might. In the bicycles forum, a group of us would also go to a bolted-on chatroom quite frequently, so we became friends with each other, as well as participants in the forum. And it is certainly easier to be kind to someone when you know and like them.

Similarly, in a zealous attempt to avoid duplication of data, somebody will spend two seconds looking at a question, pick out a few keywords, see that those keywords appear in another question, and close the question because it is a duplicate. Of course it very often isn't a duplicate, but a totally different question which is unfortunate enough to be in the same area. If people read the question, they'd know that, but they don't. And that there is somebody out there asking for help, who might have spent an hour or more just writing their question, counts for nothing.And again, people tend to vote with them, although in some cases they have the power to act unilaterally.

I mean, this was primarily the reason why I disengaged from the Bicycle site. The whole ethos of the site is that someone is out there asking for help. But some people decide not to give that help fro the most arbitrary of reasons.

I suppose it is a fine line. On the bicycles site, we often used to get questions like "I found this bike in a dumpster, how much is it worth?". And you'd straight away think, "its previous owner put it out in the trash, so how much do you think it's worth?" So a question like that, I suppose it is reasonable to conclude that it is time wasting. One man's meat is another man's poison I guess.

Monday, 18 February 2019

Food For Thought

A guy came around last week. We met in a technical environment (IBM) so it was good to talk vaguely technical to somebody, and of course I told him about the application that I am currently up to.

I only worked with him for a few months, the role at IBM was my first contract so the priority was simply to prove that I was good enough to do the job, rather than worrying exactly how interesting the project was. As it happened the IBM role was not-at-all challenging, I got out as soon as the contract finished, and I went on to do many more interesting roles both locally and in London. His job was to support, rather than develop, one of IBM's flagship products, MQ Series. I make the point about "support" because IBM had a definite structure where developers developed, they were the glory boys, and supporters supported - there was limited crossover between the two. Rightly or wrongly - as a consultant on a specific project, I worked separately to both, although geographically closely. . But this guy obviously got very intimate with that one product, and eventually he himself became a consultant. I know myself that there is a small but well-paid market for MQ consultants (i.e. people who can configure systems to use it), whereas my skills included only a small amount of MQ - I've used it a few times since - but lots of other things too. By the sounds of things, the chap spent a lot of time not working, but when he did, he would have been well paid. It's a very niche market.

Anyway I talked to this guy about my application. He had a few thoughts. Some were off the planet (the environment in which I'm writing is very different to the environment in which he wrote), some were things I'd already thought of, but some did force me to think. I mean, most of my application is developed now but there are a few bits and bobs to complete. In software development, you start off with a vague notion about how you'll go about something, then put flesh on the bones as you make progress. For that reason it is difficult to cost projects up-front, but experience, where you've seen such-and-such a problem before, is invaluable.

One such area was the multi-user aspect of my application. I had a vague notion that the application would be written for one user, the currently-logged-on user. But would be usable by other people just by virtue of different users having different Windows logons, different file areas etc. Certainly my app is all files, so I'd always thought that it would be possible to have many different DIEM data files, in many different locations. But I got to thinking over the weekend, how exactly would I make it happen?

I didn't do anything until this morning, when I decided to check that the application would work for mutiple users. In the end it was easy, just because the application is pretty modular already so I only had to change a couple of tiny things.

But of course the big win is knowing not just that I want to do it, and knowing vaguely how I would do it, but having actually implemented it, I know exactly what steps I had to take to accomplish it.

At one extreme, I could have had my own database of users, passwords, data etc. but I decided that was too much overhead, and that the data here is not critical enough, plus I want the application to be as open as possible At the other extreme, I could have had no security whatsoever, just to keep the database in a single place, but the knock-on implication of that would be that I could only support a single user. So I'm in a halfway house, using Windows' inbuilt security features to separate users. I  wouldn't claim that it is 100% foolproof - I am an administrator on the machine and I can see everyone's area (I happen to be the only person who uses it) - but the application is as secure as you make Windows itself, and that seems fair enough to me.

Thursday, 14 February 2019

Getting Started

Tekkie post - I'll make it brief.


When I used to work commercially, the last phase of any project was creating an installer for whatever we happened to be writing, and I always used to underestimate just how long it would take. You'd be clapping each other on the back because you'd finished the application, but there was still one significant hurdle left to jump. In the early days I mainly worked on web stuff - it'd not only be installing the files to the required folder, but stuff like creating web sites, virtual directories etc. plus capturing and sorting the account credentials to make sure it had the necessary permissions. All of which I did by setup program, just because it was 100% repeatable if there was a problem - I wasn't reliant on some operations guy typing the wrong thing in.

In later years it was mainly desktop applications. I designed a lot of stuff (tek alert!) late bound if I could so there were always config files which needed updating. Late bound is: an application would need to use such-and-such a technology, but rather than just lump the technology in with the application, you'd keep the two parts separate. This allowed you to move from Technology A to Technology B, say, without impacting the application itself. At run-time, the application just used to look inside a configuration file to find out which approach it had to use. There were also things like database usernames and passwords - I never knew these for the "live" systems, so the Operations guy would type them in during install. And I wrote simple credentials-checking things to check that the operator himself hadn't mistyped things. Over the years I learned to leave as liyyle as possible to chance But again, it took time and effort.

But I have just had a wonderful experience with Microsoft's Setup program creator tool. I'd budgeted a month to do the setup program for my app, but it has only taken me a day! In fact, most of it was already done for me, I mainly just entered product-specific stuff. 'Course, it helps that this installer doesn't do anything complicated (one of my goals here was to avoid complication), but still, I'm pleasantly surprised. So, task number next!

Encouragement

Tony Benn used to say that the role of senior people in society was to encourage. I don't think there as a truer phrase, but I think it's true for all of us.

A kind word here, a compliment there, I think it all goes some way to telling somebody that, whatever effort they just made, it is appreciated.

That's all. I've got no parable behind this, it's just a mantra I try to live by.

Wednesday, 13 February 2019

Busy Bee

I'm sure I must have mentioned this before, but before the stroke I worked in IT. Well, immediately before the stroke I'd decided to have a career break and had followed my passion to become a bicycle mechanic, but, prior to that, I'd spent 25-odd years in IT, at quite a high level, amongst other things designing multimillion systems for banks. I worked at the high-net-worth end, with asset managers as clients. One of the clients was also Coutts.

I decided quite early on in my career that I wanted to stay as technical as I could, rather than becoming managerial, although in later years there was lots of cross-pollination.

Ironically, I had already decided to go back into IT by the time of the stroke - bicycle mechanics live on minimum wage. Then the stroke happened which was, to put it mildly, a setback.

Anyway for the last year and a bit I have had a goal of returning back to work. Everything is a bit slower one-handed (i.e. one-fingered!) and I make plenty of misspellings. Fortunately I correct most of them before they ever get published, plus with the tools I use, something called a compiler will insist that I type things properly. But whilst I felt I'd had enough of IT back in 2013, I've regained a lot of the passion I used to have in those early years. Plus I'm more experienced in a great many ways, and I make better decisions. But time marches on, and I needed to resharpen my IT skills back to full speed. So I've been doing little projects, just aimed at getting myself back up to speed with things. Little web sites, spreadsheet macros, writing my own applications. I mean, I used to run my own business so I was used to thinking at an entrepreneurial level, and there are plenty of ideas. Plus, as I've said I performed a niche job at a niche level. The current project - I started it getting on for 6 months ago, with just me working on it, albeit part-time alongside other commitments - is a Diabetes Tracking application. As you'll know from past posts, diabetes is significant for me.

It is funny, working on these things, how most of the time life just rolls along, the functionality of the application just increases at a pretty-much constant rate - that comes with the familiarity of a particular technology, and the experience of knowing where and how to find information when needed. I used to find the same with my big clients. But every now and again, something tiny comes along which really throws a spanner into the works.

One of the perks of doing my own stuff is that I don't have any formal deadlines, unlike when I consulted for other people. So I can prioritise "properly" over "quickly". One such area was the usability of a small part of the application. It might be small but it was critical - it is how someone would enter one of their glucometer readings. The control to capture the timestamp of a reading - its date and time - just wasn't usable. So, I took the wheels off, and set about re-working the screen. The "date" aspect was no problem, as there was something perfectly good that I could use out-of-the-box. But the "time"...well, I've probably spent most of the last fortnight trying to find something that looks good and is usable. I must have evaluated many people's efforts at a TimePicker, to see if I could either use it or extend it so I could use it.

Anyway, in the end I've come up with:




(Sorry, the screen capture program in Windows has cropped the lowest part of the image.) But I quite liked the idea first of some kind of pop up clock, which appears and disappears as the user works with it, and secondly of an analogue clock face. In terms of usability, the user just drags the hours and minute hands around the face, so pretty easy. The control is extended from somebody else's work - if I'd have done it from scratch, it would have been two lists, one 0-23 hours, and the other 0-59 minutes.

Two weeks' effort. Was it worth it?

You can see some more screenshots of my application, its pre-release name is DIEM, at http://www.diemware.com. For now it runs on Windows, just because that's where my expertise lies. But already I'm thinking of tablet versions to run on Apple or Android (maybe next version!) One of my thoughts with the project is that I want to try and help people rather than try to make money out of them, so when it is complete I want to distribute it for free. But to that end, one of my own drivers is that I don't want to be spending megabucks myself to buy suites of fancy controls, when I don't really hope to gain any revenue from it. So lots of my decisions have been based around the cost implications of using a particular approach.


Friday, 8 February 2019

Veteran

I had to chuckle - the co-ordinator at the stroke charity told me the other day that I'd clocked up 100 hours of volunteering. My first thought was, "how on earth did they calculate that?", which made me smile.

I mean, I volunteer for the stroke charity only once a fortnight, just going around the ward at the local hospital, the ward where I was once a patient. So that's 26 visits per year. I've been volunteering just over 2 years, so, I suppose, 60 visits. 100 hours? That's about 1½ hours per visit. About right. I mean, I used to have a 2hr slot on the hospital site - buses. Like it or not, I was there 2 hours. Sometimes the drop-ins took that whole 2 hours, other times I was in and out in 30 miutes. These last 6 months, they've cut the buses even further, so I'm 1½ hours on site. But certainly in the early days, I often went around the ward on my own, and nobody ever asked me how long it took, although the two most recent co-ordinators usually asked me.

The other thought is that 100 hours is not exactly a lot, is it? Somebody working full-time would do that in a few weeks, although of course, they're not recovering from a stroke. On the one hand it'd be nice if there was a bit more I could do, but on the other I'm aware that every time I do a drop-in, I'm out of the house for 4 hours, even though the drop-in might take only a fraction of that. So, to the Stroke Association, it might be 100 hours, to me it is more like 300-400. But, not that I begrudge giving the time, far from it, it's just a shame that such a vast proportion is spent either waiting for, or using, the bus.

It actually works out, quite accidentally, that I'm doing more voluntary work for the Age charity at the moment. I spend about 3 hours doing that every week, so that's about 150 hours per year (I've only been doing it about 5 months so far). I started with the Stroke Association first, but the drop-ins take as long as they take - I can't bug people into talking to me.

So...the gold watch is in the post, I presume.