Disqus - Latest Comments for malcolmt

Re: #AltDevBlogADay » A Formal Language for Data Definitions

Malcolm Tredinnick — Sat, 17 Nov 2012 18:26:12 -0000

Yes, ASN.1 was my thought as well. It was designed to specify byte layout on the wire for telecom protocols. Very extensible and not too hard to read (although its flexibility makes writing a fully compliant parser kind of ... fun).

Re: Attaching custom exceptions to functions and classes

Malcolm Tredinnick — Thu, 02 Aug 2012 22:45:43 -0000

There's always going to be one critic and here he is...

I'm not generally in favour of this technique. Except in limited cases of an exception from inside a class a la Django Model subclasses. Putting it on a function seems too cute and not particularly necessary. If your package's exceptions are reasonably logically organised they can be in a single module (encouraging reuse in multiple modules in the package) and then you do "import exceptions" and "exceptions.DoesNotCompute".

You do import things at the module level, not from inside the module, right? So that code readers know where a particular object comes from? (And, yeah, many people don't do this. Those people are dead to me. :-) )

Re: Who Are You?

Malcolm Tredinnick — Wed, 13 Jun 2012 21:22:49 -0000

What draws me here is the easiest: the articles here are so unpredictable in their content. Every few days I get to read about a random piece of history I usually haven't heard of before. What an easy way to get educated! Was sent over here by a friend about 8 months ago (maybe) from a comment much like that: "it's something different every time."

I've grown into a love of history in the 20 years or so since leaving schooling, having overcome a strong dislike of it from the high school years. IT and mathematics background, but with a love of gaming -- mostly fantasy and RPG style -- and historical influences and knowledge are certainly present in that arena.

Keep up the great work, all contributors! I'm very appreciative.

Re: http://blog.mattwaite.com/post/19159657696

Malcolm Tredinnick — Sun, 11 Mar 2012 22:59:37 -0000

Nice idea. Skynet couldn't be implemented by a nicer guy.

One thought: a fair portion of the "maker" crowd have been gravitating towards open hardware licenses, rather than CC ones, for somewhat technical (including patent) reasons specific to physical manufacturing. Now that CERN have released/backed/coordinated a fairly well accepted one (last year), might be worth considering.

Re: Part 49: Sound

Malcolm Tredinnick — Thu, 01 Mar 2012 16:28:45 -0000

Looks like you've solved your problems as far as linking to OpenAL goes, but you might find http://hacksoflife.blogspot... interesting for comparison. Ben Supnik's blog contains a number of those kinds of practical gems, supporting OpenAL and OpenGL code across multiple OSes and multiple versions.

Re: http://blog.mattwaite.com/post/15309339878

Malcolm Tredinnick — Wed, 04 Jan 2012 17:35:00 -0000

I'm not a data nerd, but I've been known to dabble in some of these tools. Without knowing exactly what you're concerned about, I would suggest leaving out the phrase "tools of the data analyst", since if you don't already know what the class is about, that phrase is only going to add to the ambiguity. How about something along the lines of "data journalism uses software and brainpower to look at raw data, rather than convenient summaries, to aid investigative reporting"?

The rest of it seems clear enough. You could tighten up the sentences a bit, but that's mostly a matter of personal style and knowing your audience and I'm going assume / hope that you know U Nebraska students' minds better than I do.

Re: http://altdevblogaday.com/2011/11/12/ill-just-refactor-that/

Malcolm Tredinnick — Sat, 12 Nov 2011 18:08:28 -0000

I would agree with Richard on this: productive refactoring moves the code towards simplicity and, as a by-product, clarity. Removing unneeded code is part of this. I suspect this goes beyond what Lee might consider to be refactoring, since it does change some aspect of the external behaviour, but the goal is to do that when that behaviour is not being used. If you have to change external components as a result, it's no longer refactoring (I would want to see somebody remove the dependency on that functionality first, then, step two, being to refactor to no loner provide the functionality in the component).

To speak to the main article, I don't have a problem with "refactoring" as a term, but I have learned to call people on it when they say they are going to refactor something. Refactoring as a prelude to making broader changes make sense; keeping the two steps separate (at the level of commits to the VCS, for example) is good practice. To avoid exactly the ambiguity and slippery slope problems Lee is writing about. As a technical manager and dev mentor to a young team a couple of years ago, I worked with a few enthusiastic types who used "refactor" as a code word for "let me at it and I'll come up with something *awesome*!" Asking them upfront why they wanted to refactor and what the goal was would help keep the day's goal to a reasonable size and allow me to point out where they'd overstepped the simplifying/clarity-inducing phase and added or changed externally used functionality. It was only a two minute conversation and seemed to, in effect, help them take a breath and clarify, in their own minds, what they were about to do.

Re: The book "Blender Basics 4th edition" in Russian

Malcolm Tredinnick — Mon, 07 Nov 2011 00:50:45 -0000

Er.. typo in the headline. The great new 2.6 Blander (sic) product is proving not to be the enthusiasm-inspiring marketing success Ton hoped it might be and he's gone back to the old kitchen utensil name.

Re: http://altdevblogaday.com/2011/11/02/a-few-conceptual-prototyping-tips/

Malcolm Tredinnick — Wed, 02 Nov 2011 22:54:55 -0000

There was no way you could have posted this relevant information, say, ten days ago? When I could have done with the reminder? I got a bit sucked down a rabbit hole of "not what I was intending to test" on a personal project last week. Caught myself over the weekend and refocused on where I wanted to end up and the smallest steps to get there. it's always obvious in hindsight, but so very easy to get "in the zone" on something and not be aware you've lost a little focus, no matter how much experience we might have. Particularly in exploratory prototyping.

Re: BlenderNation Changes: Header archive, Logo!

Malcolm Tredinnick — Thu, 27 Oct 2011 07:08:20 -0000

This is a good idea. I've been really enjoying the various banner images in the new layout. Thanks, Bart.

Re: A Handful of Components « #AltDevBlogADay

Malcolm Tredinnick — Sat, 08 Oct 2011 20:19:48 -0000

Ooh... I'm definitely stealing the virtual joystick idea! Seems obvious in hindsight, but I hadn't thought of that before. I only do gamedev stuff as a hobby, but I see many of the components I've found to be beneficial in your list. That's kind of comforting (I'm *not* insane, despite what everybody says, after all!).

I haven't rediscovered "Bob" yet, but I have a propulsion component I'm finding useful. It provides impulses for anything that is moving under power. My current fun project has both a horse and buggy and jetcar-like thing and both of those get bumped along with periodic pushes from the propulsion component. I could see Bob falling out of that if I wanted to have bouncing power-ups.

Been implementing a "situational awareness" component this weekend that seems very similar to your threat/fear combination. For NPC's that are wandering trying to find something, it gives them information -- via very limited look-ahead -- that they are ending up in a closed-in area or, conversely, an open space with lots of room to act like they're exploring. In my case, closed-in spaces are a kind of threat, since it cuts off their options to behave naturally and means they'll have to backtrack a lot, so the AI uses the information from those messages to guide them elsewhere.

Re: The Importance of Game Jams « #AltDevBlogADay

Malcolm Tredinnick — Thu, 01 Sep 2011 01:31:36 -0000

An alternative, which doesn't invalidate Adam's points in the article, is slightly longer competitions. For example, Pyweek starts in a couple of weeks. Same idea as Ludum Dare, but a week long, so you can do a bit each evening after work, with the constraint that things must be in Python (and, hey, it's a prototype situation, so stretch your language skills).

Re: Getting people's names right in software design: a LOT harder than it looks

Malcolm Tredinnick — Tue, 23 Aug 2011 18:46:49 -0000

That's what their policy say, but Skud's experiences show otherwise. Her "government ID" name is Kirrily Roberts (which is public information), but everybody in the industry knows her as Skud, yet Google won't accept that.

Reality meets Google policy with predictable confusion. Hence threads like this, because Google aren't even allowing their own policy to be followed (let alone the bootstrapping problem of how your common name becomes commonly known).

Re: Does Gameplay Always Come First? « #AltDevBlogADay

Malcolm Tredinnick — Fri, 05 Aug 2011 05:31:29 -0000

Woah... deja vu! On Tuesday I was rewatching the Extra Credits video on Graphics vs. Aesthetics (http://www.escapistmagazine... ) and this is along exactly the same lines: gameplay includes the "feel" and atmosphere as much as the "what". Putting faces on the cubes gave made them part of the environment a bit better and helped the gameplay.

Re: Localization: We need a standard format! « #AltDevBlogADay

Malcolm Tredinnick — Sun, 10 Jul 2011 01:39:15 -0000

I didn't see mention of this, but maybe you've already looked at it: your requirements list and the discussion pretty much describes XLIFF (http://docs.oasis-open.org/... is the spec, and the wikipedia page on the topic gives you a taste). That format has been used in the localisation industry for a number of years now at various scales from "small shop" to "enterprise-y". Never really took off in the open source software world because the gettext PO/MO format sufficed, but once you start needing finer-grained classification and metadata, XLIFF shines.

Of course, the usual comment is "yes, but I want something smaller" and then "just this one extra thing" upon little extra requirement get added and you're up to something just like that. My experience in the past decade is the OASIS group generally (within reason) don't over-specify things, but they do the necessary research to avoid under-specifying as well. Writing tools to support that existing standardised format would seem better, even in the short term than trying to get adoption for Yet Another Not Quite A Standard(tm).

Re: Debugging an AI Server « #AltDevBlogADay

Malcolm Tredinnick — Sun, 03 Jul 2011 17:45:31 -0000

I love seeing people do stuff like this: why write a UI client if a web browser suffices? So nice post topic.

Reading the code fragment, I'm not immediately convinced you need to drop and recreate the script element every time, but I'll trust you've discovered that was necessary for some reason and debugged it into existence. However, as a debugging tip, be aware that we have console.log(), rather than alert() for debugging. Any browser worth its salt supports it (as well as things like Firebug's console tab supporting it) and having scrollback and not needing to dismiss an alert box every time makes it very useful to use in loops and the like.

(Edited to sound less obnoxious. The console.log but was intended as a friendly "you may not know" tip.)

Re: Director Challenge: Founder CEO Performance

Malcolm Tredinnick — Wed, 30 Mar 2011 20:13:23 -0000

Whilst I agree with the idea here, CEO's are human, too and real problems won't be revealed this way. "Mixers" or other group meetings tend to be terrible ways to solicit feedback because truly critical stuff is very difficult to bring up in group situations, as even the pretense of confidentiality is gone. If the CEO is doing a bad job in some way (e.g. making their primary job to ensure that nothing is the CEO's fault), then a mixer hosted by the CEO is not going to be a way to extract that information, as it will inevitably rebound on the person doing the complaining. That is simple human nature and the utopian situation would be unrealistic to expect.

In response to the question in the original post. CEO reviews should definitely happen. A lot of founder CEO's are there by default and they won't be perfect. Outside parties (such as non-executive board members) are in an ideal position to act as facilitators here, since they're privy to the inside information already, but removed enough not to be an internal political threat to the people they are talking to for feedback.

Re: Django and Relativity Updated

Malcolm Tredinnick — Tue, 05 May 2009 15:59:30 -0000

No, because you want the path of the file you're importing, which isn't necessarily in the current directory. The sort of thing Rob is talking about here goes in, e.g, a Django settings file, which can easily be somewhere other than the "current" directory from the perspective of the thing doing the importing.

Re: Django and Relativity Updated

Malcolm Tredinnick — Tue, 05 May 2009 15:56:54 -0000

You haven't really justified your preference for realpath() -- and since it's your blog, I guess you don't have to. I've seen this debate go around a bit in the past, though, and it's a two-sided sword that, if I'm an operations manager or system admin, I would prefer to avoid, usually. If symlinks are involved, they're there for a reason and reporting the correct name (the symlink name) in debugging output, etc, is important. Changing that, by removing the links from the name can lead to confusion.

On the flip side, removing the symlink from any reported paths does help demystify why "../" is referring to an entirely different location to what you were expecting at times. However, using ".." in files that are going to be symlinked into random locations is probably indicative of a larger problem in the code.

In short, I'm not convinced about your best option being best. I think your "good" is actually closer to "bad" for the primary reason that it doesn't give an absolute path.

Re: Officially Lucky, a blog by Clint Ecker

Malcolm Tredinnick — Thu, 02 Apr 2009 21:38:31 -0000

Whilst I agree with you, Clint, I don't like your argument about payment already occurring due to simultaneous car ownership. Hopefully that becomes less and less of a case (and is it really true in cities, for example?). I ride a bike and I don't have a driver's license, for example. Trading car for bicycle should be being encouraged.

However, the proposal is stupid for more fundamental reasons. Motor vehicle registrations aren't the sole source of funding for roads. In fact, they're a minuscule portion. Federal and state funding in many countries comes from the general tax pool as well and those taxes are paid by everybody, not just car owners. It also comes from things like fuel excises, again paid by everybody, as they're built into the cost of good that rely on fuel to be delivered. I also contribute my fair share to vehicle registrations when I buy a bus ticket, for example. So non-drivers are already paying for drivers.

Is this guy also proposing that pedestrians pay a registration fee? I see many of them crossing the streets every day -- have even noticed it happening when I've visited Oregon -- and repair work being done that won't affect cars, but make things safe for pedestrians. Does he realise the extent of freeloading going on from those bipedal beings? Clearly hasn't done all his background research.

Finally, cars have also not paid a single penny towards maintaining roads. Car *owners*, however, have. Just like bike owners already do. So even more points off for failure to communicate using the English language.

Re: My Django Project Conventions

Malcolm Tredinnick — Thu, 12 Feb 2009 00:39:50 -0000

Firstly, regarding template location. They're not "supposed" to be at the app level. That's just sometimes convenient, if they truly are app-specific. But there are a lot of cases when you're wanting a project-wide template or two. A site-wide base template, for example. I've done a number of projects where there were no app-specific templates at all, since the apps had the functionality and the presentation was more coordinated at the site level. Don't see anything wrong with that at all.

On the settings front, I think your idea is pretty useful. However, I'd use Python a bit more than you're doing. Instead of parsing your own input format, you can kind of let Python do it: the modes are strings (module names) in a list. You comment out ('#' becomes the new anti-'*') the lines that you don't want included. Loop through the list names and import all the modules. If you import '*' from each module, Django will automatically pick up all the things that are appropriate as settings (any all-caps module-level variables). That reduces the amount of code in your "sludge" by at least half. Let the language work for you here.

Re: Clearing Django Form Fields One By One

Malcolm Tredinnick — Wed, 10 Dec 2008 16:43:20 -0000

Now, my intuition arguably works differently from others, but I'd argue that this approach is slightly backwards. It certainly works and I can't see it ever failing, but on some level it's coupling input to output more than you might prefer. Altering the submitted data is the wrong end of the pipeline. The end goal is never to render that piece of data, which is a property of the form.

I'll eventually write this up for the docs (or you could beat me to it and submit a patch), but here's my preferred approach to this kind of problem: http://groups.google.com/gr...

Re: Officially Lucky, a blog by Clint Ecker

Malcolm Tredinnick — Sat, 22 Nov 2008 01:16:26 -0000

If you're going to argue that daylight savings is the problem, rather than rather irrational settings of air-conditioning as a rule in the US (it doesn't have to be set to "Arctic" in the summer. Really), then you have to go all the way. The work day should be moved to start at 11:00 pm and finish at 7:00 am. That will mean that, during summer, nobody will be in the offices in the warmest part of the day and the residual heat from the building will keep things warm most of the night. Instant AC cost reduction to close to $0 (alright, there'll be a small heating bill). Sure, it will be massively inconvenient, but it enables people to avoid having to consider the real problem that's indicated here. Maybe it's the over-chilling of buildings that is causing people not to be able to think of such a logical conclusion.

Re: Officially Lucky, a blog by Clint Ecker

Malcolm Tredinnick — Sun, 16 Nov 2008 21:38:26 -0000

This is some kind of transparent attempt to have multiple Thanksgiving dinners spread over a couple of weeks, isn't it? Don't you think people will see through it when you keep "practicing" through the first half of December as well?

Re: Secrets of the Django ORM

Malcolm Tredinnick — Sat, 08 Nov 2008 13:48:00 -0000

You've pointed out that this is internal API and it's going to be one of those cases where it really will change. The "having" implementation is very fragile at the moment and has to be changed (it will end up looking more like Query.where). So any code treating it as a list won't work on trunk very shortly.

I hope people are really, really paying attention when they use internal stuff like this and have lots of tests so that they will notice when the internal code changes.