They say you learn something new every day.

Posts tagged ‘software’

Getting Management To Listen (27/03/2012)

Management like PowerPoint. They love charts and summaries. You need to give them something like this every week/month and then they’ll be happy.

I’m producing a communications plan at the moment at work, to try to hit lots of these at once. It’s actually incredibly important – after all, if they don’t know you’ve done it, then you might as well not have bothered.

My boss has just come back from maternity leave, and a slight danger of her deploying some micromanagement. So to get in there quickly, and keep her happy and feel in control I need to put together a regular “pack” of stuff for her. She might not read it, but at least if she can see it or know it’s coming, she’ll be satisfied I have things in control.

And actually, depressing as this is, sometimes more important than actually having it under control.

Less Advanced Than You Think (24/03/2012)

I remember a while back reading that “Listen Again” (the radio version of iPlayer) only accounts for 2% of all radio consumed. And being amazed.

This was in 2009, so it may not still be true now, but I don’t expect it’s moved that much.

The thing is: most people aren’t as technically advanced as you think. Not being they’re stupid, they’re just not as interesting as you are (especially if you’re reading this, you’re almost certainly in the top quartile. Even if you don’t think it, you probably are: you’re reading a blog for Christ’s sake. Most people don’t even know what a blog is.)

A colleague of mine has to give a presentation about a Corporate iPhone AppStore that we’re building. Half way through, he realised the audience weren’t feeling it, and so said, “Who here knows what an appstore is?”. About four people their hands up.

It’s back to this thing about making basic applications. Almost no one cares about fancy features. It’s why the iPad and iPhone have taken off, even though they have the computing capacity of my eight year old laptop. Get the key basics right – the things people are actually interested in – and you’ve got them. And get those bits sorted before you start adding all sorts of new features that no one wants.

Pretty Basic (21/03/2012)

An application I built at work has been rolled out to a group of pilot test users.

One of the first pieces of feedback that came back was:

“It’s pretty basic but it does what I need”

I have to admit, I took this as a massive compliment.

I designed the application to fix a massive problem that’s been dragging on for about 10 years. It’s been given a grade 1 audit severity report. People have tried and failed to fix it many times before (there was once a manual process – the instructions were 20 pages long). People have argued, meetings have been had. I’ve been in meetings with 30 or 40 people about these issues.

The application itself came out of a number of meetings I had with senior technologists, who had no idea how to fix the problem.

The fact that someone can look at the solution and say, “m’eh, it’s pretty basic” is really a sign of a good solution, I think.

Obviously, part of my plan was to simplify the process as much as possible (in fact, as a result of his feedback, someone gave me an idea which meant I could remove one of the drop down options from the form). It’s a real case of the Unix Philosophy in action:

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

In actual fact, it even handles text streams as well!

I’m reminded again of the importance of simplicity in application development. In fact, the application replaces some scripts that I wrote. That turned out to be too intricate complex. They were longer, more involved, relied more on their input being in the right format. At the time I thought they were the neatest solution, but I was wrong. They weren’t simple enough.

How you achieve simplicity in a complex world where people complicate things all the time is a difficult question. All you can do is practice it at all times, and try to get more and more experienced at developing “simple” applications. 

Keeping on Top of Things (16/02/2012)

In many ways my last few days have been filled with thoughts about scope creep. As I said a little while ago, a lot of my projects are suffering from this. And partly it’s because I’m being a little bit too ambitious. So I’ve intentionally dialled back on what I’m doing to make sure I hit the core values.

Part of this has involved reviewing my coding, and I’ve reminded myself of the importance of building a central, maintainable framework.

“Maintainable” is the key word here because “code rots”:

Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted. The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there’s more stuff to move around.

You realise this when you come back to something you were working on several months ago, try to run it and it crashes.

  • Partly it’s because of that bug that you never got round to fixing but knew about and knew the workaround for.
  • Partly it’s because something else changed along the way and broke it.
  • Partly it’s because you’re not caring for it and fixing bugs and improving it any more.

As soon as you stop actively looking after it, it starts getting worse.

Of course, you can’t look after every project at once, but what you can do is write a centralised code library, look after that, and pull much of your stuff from that. That way, you’re actively looking after most of the code at once.

Jeff calls this “tending to your software garden” and I think I agree with him. I think I need to come up with more ways to keep my garden well looked after.

At Least the Directories are Active (30/01/2012)

I may be struggling with my house situation, but life trundles onto.

I’ve been building my web application at work, which I’ve really been enjoying doing. It’s great to be totally in control of a project and just fix it however you like.

However, I’m writing it in ASP.Net, which is a language I don’t really know that well.

Today I a discovery. If the DNS is set up correctly, you can get the asset number of the machine that’s connecting to the webpage.

Assetnumber = System.Net.Dns.GetHostEntry(Request.ServerVariables(“REMOTE_ADDR”)).HostName

This is brilliant. It’s something I didn’t think you could do. But the header data contains the IP address, and if you do a Reverse DNS lookup, you can get the asset number.

Of course, it’s the full domain name, so you have to trim a bit off the end, but that’s easy:

Assetnumber = UCASE(LEFT(Assetnumber,INSTR(Assetnumber,”.”)-1))

Once you can do this, the possibilities are quite exciting. It means you know who the user is, and what computer they’re on, so you can really tailor the results back to them.

Never underestimate (25/01/2012)

There’s a couple of projects I’ve been working on that I thought were going to be really easy and were actually incredibly difficult. I’ve realised, there are so often so many unforseen circumstances.

I’ve realised that even though I’d read Jeff’s article on estimating before, I’m still rubbish at estimating how long things will take:

When you compare the original single-point estimates to the Best Case and Worst Case estimates, you see that the 11.25 total of the single-point estimates is much closer to the Best Case estimate of 10.5 days than to the Worst Case total of 18.25 days.

You’ll also notice that both the Best Case and Worst Case estimates are higher than the original single-point estimate. Thinking through the worst case result can sometimes expose additional work that must be done even in the best case, which can raise the nominal estimate. In thinking through the worst case, I like to ask developers how long the task would take if everything went wrong. People’s worst case estimates are often optimistic worst cases rather than true worst cases.

I need to start doing this in my projects, and, also, asking other people to do this as well.

I had to get angry with our outsourced IT partner this week as they came to a meeting having not done the one thing I asked them to do. I think I got the balance right – calm but very displeased. So we’ll see if they do it again.

Afterwards, they were so eager to please me that they said they’d get the next bit of work done within a week. I probably should have pushed more for best case/worst case estimates.

Taking Shortcuts (20/01/2012)

I was fiddling around in Notepad2 today and I needed to comment out a bunch of lines (to see the effect without them).

It turns out there’s a keyboard shortcut for this:

Control + Q

And this seems to be a standard. By chance, I was working in Notepad++ this afternoon and it worked there too. Another one to file away in the memory

All is not lost (19/01/2012) were unable to retrieve the post I lost. It’s one of the first things I can think of that I’ve irrevocably lost on a computer. It’s somewhat ironic, because I’ve only just started my backup plans.

The “missing post” was about some free OCR software called tesseract. It’s not a massively important post, and I have a copy of the one key thing about it (the command line syntax) which is:

tesseract.exe FILE output -l eng

As well as, somewhat ironically, the pictures. Unlike Jeff I’ve kept the pictures but lost the text.

Here they are, showing the effect of the update. Accuracy of old version:

Old version

Accuracy of new version:

New version

However, I don’t want to talk about what’s missing.

Since I started my aim to learn something new each day, I’ve managed to write something every day. But losing this post was the first time that made me think, “oh damn, is it worth it”. It really annoyed me – perhaps more than it should.

There’s a section in Transformative Entrepreneurs where Jeffrey Harris talks about what makes people successful:

Successful entrepreneurs combine optimism, creativity, passion, courage and perseverance. They have an uncanny ability to keep going when times get tough. They have such excitement about what they are doing, and a need to prove to the rest of the world that their idea has merit and that they don’t quit.

Now, admittedly, losing one post isn’t the biggest set back in the world. It’s nothing compared to the set backs Mr Honda went through before his company became successful:

Like most other countries, Japan was hit badly by the Great Depression of the 1930s. In 1938, Soichiro Honda was still in school, when he started a little workshop, developing the concept of the piston ring.

His plan was to sell the idea to Toyota. He labored night and day, even slept in the workshop, always believing he could perfect his design and produce a worthy product. He was married by now, and pawned his wife’s jewelry for working capital.

Finally, came the day he completed his piston ring and was able to take a working sample to Toyota, only to be told that the rings did not meet their standards! Soichiro went back to school and suffered ridicule when the engineers laughed at his design.

He refused to give up. Rather than focus on his failure, he continued working towards his goal. Then, after two more years of struggle and redesign, he won a contract with Toyota.

By now, the Japanese government was gearing up for war! With the contract in hand, Soichiro Honda needed to build a factory to supply Toyota, but building materials were in short supply. Still he would not quit! He invented a new concrete-making process that enabled him to build the factory.

With the factory now built, he was ready for production, but the factory was bombed twice and steel became unavailable, too. Was this the end of the road for Honda? No!

He started collecting surplus gasoline cans discarded by US fighters – “Gifts from President Truman,” he called them, which became the new raw materials for his rebuilt manufacturing process. Finally, an earthquake destroyed the factory.

After the war, an extreme gasoline shortage forced people to walk or use bicycles. Honda built a tiny engine and attached it to his bicycle. His neighbors wanted one, and although he tried, materials could not be found and he was unable to supply the demand.

Was he ready to give up now? No! Soichiro Honda wrote to 18,000 bicycles shop owners and, in an inspiring letter, asked them to help him revitalize Japan. 5,000 responded and advanced him what little money they could to build his tiny bicycle engines. Unfortunately, the first models were too bulky to work well, so he continued to develop and adapt, until finally, the small engine ‘The Super Cub’ became a reality and was a success. With success in Japan, Honda began exporting his bicycle engines to Europe and America.

His plans were stopped by the whole world going to war and his factory was destroyed by a blooming earthquake. But he didn’t give up. I’m not sure I’m there yet. I think if an earthquake destroyed one of my projects I’d probably call that one a day, but I think this is an incredible lesson to us all.

The thing I’ve learnt today is to be successful you need to carry on even when you fail. Even if you fail ten times and then succeed, you’ve succeeded. Succeeding isn’t not failing, it’s working through all the failures to get to the success at the end.

It’s like that old joke:

“Why do I always find my keys in the last place I look?”

“Because you give up looking when you find them.”

The only way to not fail is to keep trying.

The other thing, of course, is to review your failures. They may be painful, but failure is the only thing you can learn from.

Consequently, I’ve reviewed Jeff’s list of “how to backup” again and looked at my process:

  • Don’t rely on your host or anyone else to back up your important data. Do it yourself. If you aren’t personally responsible for your own backups, they are effectively not happening.
    [I assumed queued posts were backed up. They weren’t]
  • If something really bad happens to your data, how would you recover? What’s the process? What are the hard parts of recovery? I think in the back of my mind I had false confidence about Coding Horror recovery scenarios because I kept thinking of it as mostly text. Of course, the text turned out to be the easiest part. The images, which I had thought of as a “nice to have”, were more essential than I realized and far more difficult to recover. Some argue that we shouldn’t be talking about “backups”, but recovery.
  • It’s worth revisiting your recovery process periodically to make sure it’s still alive, kicking, and fully functional. 

And I’ve got a plan to stop this happening again.

MP3’s gain is Volume’s Loss (11/01/2012)

I ripped a CD the other day (the first time I’ve ripped a CD for ages. Rather embarrassingly, I couldn’t find the “Rip CD” button in Windows Media Player for ages. The sooner physical media dies the better as far as I’m concerned.)

However, listening back to it, I noticed the track volumes were all over the place. This wasn’t a fault of Media Player – they were like that on the original CD as well.

My first job was basically normalising audio tracks (there may have been a little more to it than that, but only just), so I thought to myself, I’ll just normalise them. But then I found MP3Gain:

MP3 Gain

It’s a nifty little algorithm that finds the average highest value, rather than just one freak loud noise, and normalises all the tracks in a folder to that same level.

It’s very easy to use, and lossless too. Which is great. What’s also nice about it is that it comes with a command line version (we all know how much I like command line software). Although I’ll be damned if I can find a list of the command line switches anywhere.

Backup to the Future (09/01/2011)

And so my backup quest continues. What I learnt today was probably the most important thing so far: actually backing up the files on my computer.

There were three important requirements to my plan:

  1. It must be automatic.
  2. It must be free.
  3. The process must not affect my life or computer use.  

I turned today to looking at ways at backing up the important files on my computer.

My plan with these is to upload them to my webserver. This will probably be quite a big job at first, because there are a lot of them, and I’m happy to do this once, as long as I can do automatic incremental backups from then on.

Thankfully, I found WinSCP. Having played with it a bit now, I like WinSCP – perhaps more than Filezilla. For my purposes, what is really useful about WinSCP is that it allows you to run commands from the command line.

It took me a little while to figure this out, but I got there in the end. First you need the .bat file, something like this:

winscp /script=file.txt

This will run winSCP against the commands stored in file.txt

Then we create file.txt:

synchronize remote “D:\Files” /www/Files/

This logs onto the FTP server with the given credentials and synchronizes the local file against the remote one. It adds all the missing or updated files.

What’s particularly good is you can add lines and lines of as many folders as you like. It works so well, that I’m thinking of setting all my FTP folders up like this, and ditching FileZilla entirely.

However, I still had a problem. Running the .bat file loads up a command prompt window.

 Black window of fear

Now these windows are harmless enough (although I remember a friend saying to me once “whenever I see one of these I just think ‘something has gone really wrong’.”)

However, remembering back to #3 I don’t want the process to affect me. And a black window popping up does. Allbeit not very much. Look, I just don’t want to see the black window, okay?

Luckily, there’s a way round this. Instead of running a bat file, you run the command in vbscript:

 ’Create scripting Object
Set oShell = CreateObject(“Wscript.Shell”)

 ’Run script in invisible mode
 oShell.Run “winscp /script=UploadList.ini”, 0, false

This runs the command invisibly, so I don’t even know it’s doing it. And because it’s a synchronise, it will just identify all the new or changed files and back them up.

I could put it as a scheduled task, but I turn my computer off and on everyday, so I’ll stick it in the Startup folder, and just let it run when my computer boots up. Backup plan complete, I believe.

What’s also good is that it’s another command line piece of software for me to add to my collection. I’m aiming to use a lot more command line software in 2012 and automate more things if possible.

Tag Cloud