Saturday, 19 August 2017

That Moment...

You know that moment when you see this...

And the mage rolls need....

Yeah, that's the kind of day I've had.

More World of Warcraft topics to follow...

Thursday, 10 August 2017

People: Email & Names

When you interact with someone, say face to face, you get to gauge who they are, what they're thinking, the subtle and many clues from body language, posture, intonation and even just where they're looking tell you an awful lot about how that person works, how they think, whether you agree with them.

However, when you're communicating digitally, via e-mail or text, you loose this personal grip.

One has to therefore rely on the face value of the information presented, is it spelt correctly, is the grammar correct, have they thought out the reply and addressed all your requirements from anything you sent them?

In my case I am often asked things like... "What do you do to better yourself?"... "Or have you done anything of note recently"... And I'm asked by people who have read my blog, or CV, or just know me... And I often say "Have you read my book?... Have you read my Blog?"

This kind of interaction puts me on a huge downer, why should I bother with this person if they've not performed what I consider the basics of due diligence?

Then there's my huge pet peeve in E-mail... I send a mail... "Dear whoever, bla bla... Xel"... They reply... "Dear Zel"...

No, not "Zel"... "Xel"... spelling, and it's not just spelling, it's that you've been given the answer right in front of you, if you can't have been bothered to take the last thing you read, and put it into the first thing you write, you're being lazy or worst still you're being purposefully obstructive and annoying, because this grates on me so much.

I once worked with a lady called "Grace", she hated being called anything else, "Gracie", "Gracy", "G-dog"... All really, really annoyed her... and people did this day in, and day out, her final response was to stop communicating with these people with their own names... Even our co-boss, who was a "Mr Khan", he became "Mr Purple-Whipple-Snapple"...

When he queried this, she said "if you wish to call me G-Dog, I will call you anything I like also".

It was the perfect most polite and poignant reply on this matter ever seen, but it took a silly outrageous example to make this clear, if you can't call "Robert" a "Robert" on the next page, or a "Susan" a "Susan", or even a "Xel" a "Xel" don't reply.

Wednesday, 9 August 2017

Development: Silly Things Said in Software

"Rather than get away from the concept of the password required completely, the password is hard coded as 'password'"...

I literally just heard this statement, from a senior software engineer ten feet from my desk to another engineer as they consulted with one another about the system they are working on.  And I simply can't let it go... So here I am to have a moan....

The problem with this kind of thinking really annoys me, they could make passwords optional with configuration, meaning the option is present and supported.  They could remove the passwords altogether, as 'password' as a password is not a password at all, it only leverages an attacker to want to rip the soul from your data and scatter it to the four winds.

But more than that, remove the password if it's useless code, don't complicate the system, don't exacerbate the effort to maintain the code.

There are so many faults in the way this engineer is thinking I'm quite pleased I don't work directly with them; and luckily - as they're departing these fair shores in a fortnight - I never will.

Aaaannnnnddd... Relax...

Seriously though folks, don't over complicate things, if you use good source control you can resurrect sections of code from the previous revisions easily, so get drastic, get smarter in the process, chop and cut your code to bits.

This video from the 2 1/2 minute - ish - mark really shows you the process from someone else's eye... and I agree with him, when he talks about thinking about what's beyond scope, however, this also needs to be considered from the point of view of maintaining the code once released.

Monday, 7 August 2017

Life Tip...

Top tip... If you run a business... And print people invoices... Learn to count... Tip ends.

This story is to be continued....

Wednesday, 2 August 2017

Development: Design, Prototype then Code

When I were a lad, I were taught to use flow chart stencils....

I was shown how to write data dictionaries, to thought-cloud through the possible data members for these dictionaries, to define the mutable and non-mutable points and abstract away the common elements between these definitions in order to design the code to be written.

All pretty much on paper, before you sat before the computer.

The reason being?  Paper was cheaper than electricity, and it took a long time to compile and recompile, and then even longer to debug, a program.  Bugs got hidden and only appeared when testing took place.

And if a bug ended up in test, which could obviously have been caught on paper, long before it reached the coding phase, then you got egg on your face.  In a nice way, you all knew you had to do more than cut code.

Unfortunately Moores law exists, a blessing, and a curse.  As I feel it's made the quality of software design fall, as people can afford to code and compile and try before thinking.

No-one I work with, certainly no-one immediately around me, designs anything on paper, or performs thought exercises on the task before diving at the keyboard.  Event when they have dived at a keyboard they're not prototyping, they're immediately producing code for release use, and it's starting to show.

As such, I've instigated a new rule, "if you have to prototype, it must be in a different language to the release code", the language I've stipulated is a python for system scripts or data processing tasks, and C# to replace any windows C++ being produced.  For C# I'm still thinking, but Java might be the best option...

This realisation came to be from the back of my mind, and it came from experience, however it seems other authors have had thoughts along these lines:

"One trick to ensuring your prototype code isn't obliged to become real code is to write it in a language different from the one your game uses.  That way, you have to rewrite it before it can end up in your actual game" - Robert Nystrom.