They say you learn something new every day.

Posts tagged ‘programming’

Second Highest Value (02/04/2012)

I had to get the second highest value from a database today. Something that I thought was going to be really difficult. But actually, it wazs fine:

SELECT MAX( col ) FROM table WHERE col < ( SELECT MAX( col ) FROM table )

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.

Even More Basic (22/03/2012)

Somewhat ironically, given yesterday’s post, I found a way of making my application even simpler today.

I don’t want to go into the specifics, because this site is about general lessons, but I didn’t notice this simplification yesterday.

It involved changing one of the dependencies, and in my head yesterday I’d viewed them just as “fixed” points that I had to work around. Luckily, I was able to change them, and so make what was coming in simpler.

Once I could do this, it simplified the whole internal workflow – basically rather than splitting something into two arrays and searching either of them, I just left it as one and searched it all as once.

I think the lesson is, when you look at a problem, look at all parts of it. A friend of mine at work often says, “What’s the exam question here?”. I think it’s a good way to look at it: often people get so bogged down in the detail, they forget what it is exactly they’re trying to do.

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. 

Stringing it out (19/02/2012)

So, everyone knows string concatenation is bad. And by everyone, I mean everyone who understands vbscript or ASP and then me.

However, even though I’ve always known it’s bad, I haven’t really seen a way around it, without writing an array and constantly re-diming it. Which is… well, a mess really.

However, I came across the ADO textstream function the other day that allows you to do something like this:

Set Stream = CreateObject(“ADODB.Stream”)
Stream.Type = 2

’ This is where you put your loop

Stream.WriteText “test”
Stream.WriteText “test2”

’ End your loop here

Stream.Position = 0

Value = Stream.ReadText()

It’s surprisingly concise. Now, maybe, in some circumstances, there is a quicker way than this. But that requires a complex extra function, whereas this is so neat.

Time to go back and rewrite some things, I think.

A Touch of Class (17/02/2012)

I think I suddenly understood classes and objects today.

I get this quite a bit with coding concepts. Or maybe concepts in general. I leave them mulling over in my head, and then suddenly, one day, I get them,

I think no one has ever really explained objects very well, and I think a key part of that is that I never got when I would use one. I think the fact that you don’t really need them makes it even harder.

But classes are basically like multiple functions in one. Here’s a demo one I built to explain them to myself:

Class TVProgram

Public StartTime
Public Test
Public ProgramTitle

Public Property Get ProgramDate
ProgramDate = Day(Test) & ” ” & MonthName(Month(Test)) & ” ” & Year(Test)
End Property

End Class

Set objTVShow = New TVProgram
objTVShow.StartTime = CDate(“17:30”)
objTVShow.Test = DateSerial(1999,9,17)
objTVShow.ProgramTitle = “TV Show”

wscript.echo objTVShow.ProgramDate & ” – ” & objTVShow.Test

So the first few lines:

Public StartTime
Public Test
Public ProgramTitle

Are like the Function variables. You assign values to these.

Public Property Get ProgramDate

Is like the Function output. You can have several of these in one class, and this is the real value to them and the thing I don’t think I got until now: classes are like functions with lots of outputs. This means you can define different outputs with the same data, or different parts of output for the same idea.

It gives me a nice warm feeling when I suddenly understand something like this. And it makes me wonder why I never understood it before. However, I think part of this comes from the fact no one ever really says what classes actually are:

You can use classes to describe complex data structures. For example, if your application tracks customers and orders, you can define two classes for them, each with a unique set of internal data (typically called properties) and functions (typically called methods). You can then manage customers and orders as if they were native VBScript subtypes. More important, because you assign a class its properties and methods (i.e., its programming interface), you have an object-oriented tool to improve VBScript applications.

Does that really help in any way? Or does that leave you even more confused by what they’re actually talking about?

Tag Cloud