17 November, 2013

How long a blog post takes

What, you write blog posts more often than once a year?

Sometimes, yeah. I spent about five minutes thinking about this blog post by Sacha Chua that prompted this reply post from me, as I thought a post would be better than a comment. After all, her original post was made three years ago.

Thinking about what to write

This takes the longest length of time, funnily enough. It’s one of the reasons there’s such a long time between posts on my blogs. Of course, once I’ve actually got a subject to talk about, then it’s just a case of clawing together some details, which takes time. Most of it is definitely spent just plain thinking about how to write my subject matter.

An aside—selecting tools

Using a standalone editor—emacs, (g)vim, kate, TextMate or gedit—vs a web-based editor? It doesn’t matter, both of them work with getting words into a framework. However, with the standalone editors, I have to write in html source mode. Render mode won’t happen until I get it into the “render” mode of the blog, so it’s better to put some of the framework into place while I’m writing the blog entry. If I was really insane, I’d write in TeX and use a LaTeX renderer to output into HTML, PS, PDF or other supported output formats. Unfortunately, I’m not familiar enough with it to be comfortable writing in markup alongside of paragraphs.

I had a tinker with posting back ends—I wrote the bare text and headers, while the posting back end handled turning it all into HTML goo ready to be viewed by a browser. Most of these editors didn’t do what vim does—nor emacs, for that matter. Often, they were a bit simpler, providing clipboard operations and a preview-ish window.

Anyhow, I seem to have settled on using vim, writing my text out to a file to preview in a browser as I go. It’s just the tool I’m most familiar with. It doesn’t slow me down particularly, or at least no more than other editors would.

Working out what the text will be.

Adding material

Once I’ve got the germ of an idea, content writing takes a while in its own right as I’m not exactly a quick thinker. Waiting for thoughts to shuffle around and arrange themselves on the stage of my mind is simply a case of waiting for other thoughts to come out of hibernation and percolate around the original thought.

Cutting material

Sometimes, stuff just plain doesn’t need to be there. it either repeats what I already said, or it doesn’t fit and should be shifted somewhere else or removed altogether.

Correcting goofs, rewriting and adding new material

Thankfully, this doesn’t take long. Often the previous section happens in parallel with generating text just to make sure I don’t miss too much. I inevitably miss something, of course.

POSTING!!

Shortest bit. About 3 to 5 seconds. Done. Now to check the post… oh heck, I missed that???

Posting again!!! after correcting goofs I missed the first nine times!

Even with “proofing” manually in a browser, there’s inevitably something I’ll end up missing by the time I post, so by the time I get my final content posted—and edits applied, it could be a little while longer. Especially if weblinks change, that can take a little while to percolate through. I hate dead links.

Minecraft got more loving

New Music by c418

I finally don’t have to feel guilty about playing c418 music any more. This guy here is responsible for the music in Minecraft, among other things. He released a new album last week, and some of that music worked its way into the Minecraft game recently. I was thinking it was about time, as I like his music. One nice thing that c418 did for his latest album was to provide stereo versions of some of the minecraft records, which had previously been available in mono. It seems strange hearing them, it’s like they’ve got this … extra dimension to them now. They occupy a distinct space which hadn’t been true before.

For all you non-audiophiles out there who don’t know what I’m on about when I talk about with mono/stereo, don’t worry, I’m not talking about your soundsystem getting a incurable virus. Stereo is two distinct channels of sound, mono is one channel. The modern take on surround sound contains 4, 5, or in some cases even 9 distinct channels of sound. With headphones, it’s a little harder to feel the music love, but don’t worry. You can still hear music just fine, as most of it is written for plain old stereo. After all, we have two ears.

Anyhow, ’nuff from me.

03 October, 2013

The Death of Respect

... or The Rant Against Fish.

Something's Fishy here.

Having seen the amount of vitriol splashed about the Internet gaming community for game developer Phil Fish and his outspoken opinions, I'm frankly surprised the guy hasn't been driven into suicide. I don't need to link the article about him quitting, hundreds of websites have done that already. I feel sorry for the guy, frankly. Yes, he's considered a strongly opinionated person with a massive following of haters, but he doesn't deserve the complete hate campaign against him. Nobody deserves that.

Thankfully, people support him, although their support is completely overwhelmed by all the negative comments that Phil has engendered. Looking through the comments on Phil's latest blog post about dropping game development, I'm not entirely surprised at his reaction. I am surprised at the complete flood of hate directed at Phil, purely because some people absolutely totally and utterly hate the guy. I mean, some people think he's worse than Mussolini, Hitler, Caucesceu and Mao all combined, in part because of what he said about some modern Japanese games. And that's not including the general opinion on his previous statements in the press. Let's face it, in a lot of cases, this guy is honestly loathed. And frankly I'm totally sick of it.

The Game's Up, and it's all good.

I'm not qualified to judge Phil's comment about Japanese games. I haven't tried modern Japanese games, and I don't own a modern console. Most of the games I have are from the Indie community or from Valve, so I'm not approaching this question from a hard-core game player's perspective. Instead, I'm stating what I feel as a casual gamer approaching a game I hadn't seen before but had certainly heard of.

Now that I've tried Fez, I quite like it. Phil does the necessary work needed to introduce the game mechanics, and then gets into what makes the game so good, at least for me. Yes, I'm frustrated by not being able to get further through the game, but I can lay that entirely to my lack of skill, rather than any flaws in the design of the game. I like the degree of having to figure stuff out, without it getting entirely frustrating.

Phil Fish, if you ever read this, I hope you are able to continue to partake in the Internet community. You probably already have a skin like a turtle's shell. I would love it if you reconsidered your position about game development, but I won't blame you if your decision is final.

As for those that wish to completely vilify and revile a character, think about what happens if that flood is aimed against yourselves one day. How would you hold up?

09 September, 2013

Learning to code from drowning

First, you drown (and get saved)

Simply put, I'm not a coder. I found this out the hard way with my first C program, called list. It tried to display a file to the screen, a la less(1) or more(1) but with a wrinkle. Of course, I decided I wouldn't look at any previous source code from either of those programs.

First off—although I didn't know it at the time—I did two things wrong. I learned a long time later that coders don't reinvent the wheel if an established codebase already exists. They simply credit, use, and move on. The second thing I did wrong? I didn't expose myself to how things were done properly. I came in as an almost completely new coder, barely knowing what a function was. One of the things that experienced coders have done is to examine as much good code as they can manage to without invading corporate secrets. I get the impression that they practically drown themselves in good code, hoping—or perhaps knowing—that some of the code will stick in their memories to use later on.

A function is always embedded in code. To be successful at this, each function has to do one job, and only one job. For code reuse to work, a typical function has to be used more than three times within a codebase. You have to know what job your program does. You also have to know how you divide up that job into functions. It might be stretching it to say that your “job” should only be decomposed into functions you already know how to write. If that were the case, then I would have never persisted with programming. However, you do have to know how to write good code. There's no sense in creating a C program that doesn't free any memory you allocate. There's no sense in trying to write your .NET without classes—it's practically impossible. And there's no point in trying to fight the programming language to do what you want to do. If you can't write the function you need to—either because you don't understand the programming language or the programming language won't allow you to—then you have two options. Learn the language inside out, or change languages. This isn't practical within the context of a single program, as you have to stick to one language for one program.

Now, you learn to swim

Of course, reading lots of good code isn't any use to you until you understand it—especially how it interacts with other code. Often, bugs aren't caused by poorly written code, but instead by poorly understood code. You wouldn't use a mini to transport your 5-bedroom house, but I swear that some programmers would try it.

Try another beach

Specialising purely in one language or another will make you really good—eventually—in that one language, but won't be very portable to other languages until you understand the programming concepts behind the code. It's usually a pretty good idea to at least become familiar with multiple languages, and even families of languages, as this can often make the difference between barely reaching the target or being the best tool for the job at hand. You may not see Haskell in your workplace if it's a Java shop, but knowing the concepts that led to Haskell may give you an edge in understanding. And if you spent your life learning assembler, then Smalltalk can seem like another planet.

17 February, 2013

A tale about incorrect challenges

First, the soup

Several years ago, I got onto the broadband bandwagon after putting up with the increasingly inadequate ability to cope from my dialup account of the time. At the time of the upgrade, I gained a D-Link DSL modem from other sources, plugged it in, and prepared to see what the world was about on broadband. Until I hit a snag. Things weren't staying online consistently. After stuffing around with various things, moaning at my ISP, getting one of their modems (a Dynalink DSL-302) and still getting no real joy, we finally got our local telecommunications company around here. They replaced enough of the phone lines in the place to get things working and I haven't had a hiccup since, until I had to replace the ISP's modem because it started showing erratic behaviour over several weeks, then finally died.

It had lasted a while, but I did rather think it would have lasted longer. Never mind, modern throwaway hardware being what it is, I guess we just had to take it on the nose. We bought a more up-to-date modem (the TD-8840 from TP-Link), plugged it in, set it all up, and tried getting back to the surfing habits we'd got used to. Ha. Except that wasn't exactly the case.

We found that download speed would seriously fluctuate when we were using the modem at full capacity, even though we had been sold the modem on the premise that it would certainly more than cope with the load I stated. I took the modem back to the store, stated what was happening, and asked for another model or our money back. The shop was unable to comply, pointing out that their specific terms of return excluded the option of refunding the money, with the only other option provided being the same model modem as we already had.

In the end, we took the modem away with us, knowing that it probably wasn't up to the demand, but we purchased a Netgear N150 DSL modem. Again, this is busybox-enabled, but very slightly differently from the Dynalink I was using previously. I'm not going to bother plugging in the TP-link again, even though the expected load has now dropped (one less member in the household). The Netgear's done perfectly well as a performer, and even has the advantage of having wireless in addition to the four ethernet ports. I thought it was pretty good, and didn't need any further firmware patches.

Until the other week.

Now the meat

The issue first got noticed that not all might be right when I was gifted a DOTA2 key as part of Valve's somewhat-closed-but-getting-heavily-tested beta of DOTA2. I'd had issues with two other Steam games, but those were eventually sorted out with ping-pong calls to Steam's support service. Side note: they're quite good, although I find them very very slow, often taking days to reply. This issue on the other hand, wasn't something I could get Steam's help with, as the application started up fine, but would outright refuse to join any servers, with no indication of why. I even poked extra holes in the Windows firewall, even taking it down for one test. Of course, that didn't cure the problem. So that left the DOTA2 binary itself, something wrong with Windows itself, the DSL modem, the ISP, the Steam service or the remote servers as the likely suspect.

Someone else offered to help, and we got going on a TeamViewer session to see what was going on. For him, DOTA2 worked perfectly, so that counted out the servers he was connecting to. They were up, they were responding fine, no issues there. The next step we tried was to log into Steam from his computer, using my login credentials. I duly fed SteamGuard the right code to continue, and fired up DOTA2. Imagine my surprise when I found that DOTA2 worked perfectly as it was supposed to. With that, we counted out Steam themselves from having any involvement with the issue. Leaving only my machine, the ISP, and that DSL modem that had performed sterlingly up until now.

I found out that this program supported the -console switch too, so I fed that to the command parameters being used to launch the DOTA2 process. I started it up, and watched while various messages scrolled up the console window. All things appeared to be correct, so I tried to start up a multiplayer session with bots. And there I struck my next issue, and the real cause of the problem. In the console window whenever I tried connecting to a server, I was getting messages like this: Server connection did not have the correct challenge, ignoring. I hadn't seen this until I'd brought up the console, but it explained (partly) the problems I was having.

Don't forget the vegetables

I checked out whether I'd accidentally missed out any ports the ISP might not be forwarding, but struck no issues. In short, the ISP wasn't at fault (as if they ever were). Leaving ... you guessed it. That modem. The modem had been fingered by others as being suspect in a number of not-working DOTA2 installs from all over the world, mainly from the U.K. where the modem is commonly handed out by the ISPs to their customers. I was just the first to have struck the issue from New Zealand, where I live. It seemed that the DSL modem was mucking up the UDP packets and not giving them back correctly. So, now I had to find solutions. One solution (not optimal) was to switch the method that the modem used to talk to the ISP with, from VC-MUX over to LLC-based, however this meant that each packet leaving the modem and returning would have larger packets, increasing the amount of information transferred for no real gain in amount actually downloaded. Surprisingly, this actually worked for me, with my machine finally able to talk DOTA2 to the rest of the world. I didn't want to keep the modem in LLC-mode though, as it had been delivered in VC-MUX mode to begin with, and that's what the ISP supported directly.

The pudding (dessert for all you others)

The other option was to flash the firmware to see if it fixed any of the behaviours I was seeing. The last time I'd looked up firmware for this modem was very shortly after I'd installed it, at that stage, I already had the latest firmware, but now this was several months down the track. Anything useful was worth a try. I logged onto the Netgear website to look for updated firmware, found that yes, there were further updates, and downloaded them. I flashed the modem, hoping like anything I wasn't going to brick it, rebooted it, and hey presto. It came back up with all my settings intact, surprising me who was expecting to have to enter everything in by hand again.

Anyhow, the proof of the pudding was to reset the connection back to VC-MUX, and try starting up DOTA2 again. Thankfully, it all worked, and I was finally able to connect to servers, without me even having to reach for a Steam Support ticket. And the moral of the story? Sometimes it IS good to flash your modem, even when it's not obviously going to fix the error you currently have. And now I'm only stuck with the normal challenges of learning a game I've never played before, in a genre I hadn't played much if at all. But that's another tale, and one I won't tell for the moment.