Coding for love

Before I say anything, it should be noted that I rarely play video games. I used to get a few hours of gaming in a week, but eventually the hassle of putting the DVD into the system was just too annoying. That might seem awfully petty, but sometimes tracking down the DVD was a chore. I just paid $50 for it, why can’t you just install the thing into my system and let it be? Remember the good ‘ol days?

So this DRM is one of those things that should’ve never happened. But it did and it’s oh so wonderful. Chances are it was a management decision. So yeah, whatever.

However, what’s funny to me is the comments in some of the fourms. They seem to come in several flavors.

“I hope they learned their lesson!”
Yeah, they might have. But it won’t stop them from trying it again on their next game.

“This is why people pirate!”
This is probably more true than it is false.

“Just because they have awful DRM doesn’t mean you can pirate their game. Stealing is stealing.”
Thank you captain obvious. It’s people like you that make other want to impose an intelligence test before allowing you on the internet. In the real world, after working at 8-10 hour day, the last thing people need is to be frustrated by crappy DRM that gets in the way of their entertainment. But I’m glad your reality is constructed by such simple rules that always seem to work.

“It’s a DDoS attack!”
Yeah, I certainly wouldn’t doubt it.

“Haaa-ha!”
Nelson’s laugh. Appropriately so.

“The only way these people will learn is if we stop buy their DRM games.”
Yeah, like that’s going to happen. Not to say that I don’t agree. Jus saying that it’s a bit too much to expect out of people.

…obviously there are other subcategories to these responses.

I didn’t really know what to title this post, so I picked something very generic. There might be some truth to it.

I don’t know if anyone else feels or thinks this way, but I think it’s time someone calls the “code design” camp out. What do I mean? Code design is a crock and it pretty much is like the Abominable Snowman. It doesn’t exist. I think we tend to believe it exists in large because we see patterns in code. Now, it might be one of those religious type existences where some people would believe that we would have a lot more bad code if it weren’t for the morals held up by design principles, read religious tenants. Okay, so that might be jumping to conclusions too early. But lets break this down and see where we arrive at.

How Does One Design Code?
I think depending on who you ask, you will get various answers. Often, it’s really difficult to see what’s right and what’s wrong unless it’s just clearly wrong. I think the grand illusion here is that most people really want to believe that you can engineer code like you can something mechanical or electrical. I’m certainly not saying you can’t. However, the one thing that mechanical and electrical engineers don’t have to deal with often is scope creep. You’re going to have to think this one out for yourself. If you apply Internet Literal Quickest Path to Conclusion Logic to what I just said, you’re going to sound really stupid when you start to talk. Obviously, there are degrees of differences. If you have experience with attempting to design code, you’ll know what I mean. If you don’t, then keep trying to design code. My answer to this question is at the bottom.

What About Design Patterns?
You should probably know what they are for job interviews. There’s a weird double standard to this one. If you read the description for the design patterns, you generally think, “Oh wow, that’s what it’s called. I’ve used that so many times in the past!” But if you try to take one of those design patterns and use it in a design…how often does it really work out like you expected? I think they’re effective communication tools. I’ve always found that with a lot of force, you can generally make them fit. You might undo them later though.

…about job interviews…and then code…
So you go to an interview and they ask you all these questions about how you should do this and that? What do these words mean? What scenario would you use this design pattern in? You answer, get the job. You look at the code and what do you see? From my personal experience, I normally see a program that does a specific thing – absolved of any of the weirdo details that I was asked about in an interview. However, I do often hear those words I was asked about in the interview used in conversations about the code. But rarely do they transfer from the conversations directly into design except for variable names.

The Stupid Visio Diagrams
Does anyone really use this? I’ve seen charts at companies made from this stuff. But the few times I did try to follow the charts to see what went where – there were sections that were missing. When I asked about it, I was simply told, “oh, that didn’t really work out in practice.”

If you’re really intelligent and insightful and consider yourself intellectually above your peers, all of what I have said is stupid. Stop reading.

Now, if you have a real interest in figuring out one of the biggest problems that plague us coders, please continue.

I am certainly not advocating we don’t design our program and libraries. I am advocating we remove the ideas and concepts that have been dreamed up in the past two decades that do not work at all in code design.

I find myself designing code by thinking about a component I want to code and figuring out how to fit it into my existing code. To visualize this design, I will write pseudo code( read C++ ) to see if it compiles. Then I have it print function calls to make sure the ordering is correct. I rarely graph anything. I might right out the names of the variables.

I gave up on the code design books a few years ago. Their ideas always felt too restrictive for what I wanted to do. My approach is to see how things play out in practice. Code, to me, embodies a particular frame of thinking that postulates itself around requirements criteria at a certain time. Later on, I’ve often found that what I was thinking when I implemented these criteria isn’t robust enough. This is generally due to a better understanding of the problem and the elimination of requirements that didn’t make sense.

The motivation of this post comes from how Maya plug-ins are written in C++ and the love/hate relationship people have with them. I will expand on this in the next post.

Who really cares? It’s not censorship and if it really does affect your day to day life, you have a much bigger problem.

There’s a lot of things I love about Boost. I mean a lot. However, there are a few things I absolute hate about Boost.

1. boost::filesystem
2. boost::program_options
3. boost::iostreams

It’s hard for me to understand how these made it into Boost considering they have strict standards.

boost::filesystem
My first introduction to this was around version 1.29 – 1.31. At the time, the design philosophy for boost::filesystem was so far out in left field, it’s a wonder that people were able to use it at all. It was definitely a moment of when abstract concepts made its way into implementation. A lot of pedants will argue that you need to purely understand things like leaves and branches in a file system. That’s just plain dumb and silly. It’s a file system, treat it as one. We’re not dealing with generalize mathematics here. boost::filesystem is probably the biggest bait and switch scheme in all the bad boost libraries. It lures you in with promises of functionality only to find that it locks you into what amounts to a prison shower gang rape scene in a bad movie. I would go as far to say that it should be ejected from boost and redone completely by someone sane.

boost::program_options
Just stay away. Bait and switch as well, just not as bad.

boost::iostreams
Lack of documentation and examples. I’m pretty positive that this component is actually functional. But the lack of documentation and examples make it extremely frustrating to work with. I don’t know if it’s a philosophical thing as to why it’s not easy, but doing something like getting the position of the stream is not obvious. My obvious, I mean looking at the class and seeing something that looks like it could be what you want.

I recall a few years ago when AMD released the first 64-bit CPU. I was crazy excited, I downloaded the x86-64 release of Fedora right away and started mooking with it. I tried my hands at GCC in 64-bit mode. It was fun in a nerdy sort of way. I didn’t really know what to do with it, but it was exciting to know that I could. At the time I thought it was weird that x86 was just now getting 64-bit. I had believed that the transition to 64-bit had already been done and that x86 was just lagging behind. I also thought it was annoying that none of the major software vendors had made any effort on the 64-bit front. You had this really cool platform, but nothing to use on it.

Well, after a few years of first hand experience at 64-bit…I found out that for most people, the 64-bit transition had started. For some very high end users it might have ended and they have been on 64-bit since the dinosaurs roamed the earth. However, for the mass majority, the adventure was just beginning.

Herb Sutter said that the free lunch was over when CPU speed increases came to a bit of a halt. Now we had to learn how to use threads to get performance benefits. If that bit is comparable to a full blown meal such as lunch, I would say that moving to 64-bit is like getting a free snack at best. Depending on who gives it to you, the quality varies.

So here’s a few things I’ve ran into recently. This might or might not change in the next few days as I learn and discover new things.

• Memory management is important as ever
• More memory doesn’t always translate into bigger “stuff”
• Using more memory means more memory access
• More memory access can affect performance

Now, I work in CG. So the requirements for me is different from someone who works in games. The game guys have to be completely on top of their game when it comes to memory. I’m allowed to be a little sloppy here and there since I rarely ship an end product. Most of the time, the tool just has to work for the life cycle of the production. Attempting a full on clean design with the best practices of coding might end your project before you get to use it.

Anyway, I did have to work on rendering lots of stuff recently. Which means lots of geometry. So I thought, oh yeah, lots of memory lets just toss it all into the RAM and see how it does. Just in case you’re wondering – not a good strategy. Now, it might be that some of this software was just designed when memory size was more of a limitation so there are mechanism to help alleviate certain congestion so that gets in the way of other things now that we have more RAM. I can’t say for sure since I didn’t work on something like say, PRMan.

I won’t go into great detail here, but I noticed that when there are lots of geometry in the scene and PRMan couldn’t purge it. The renders would take a long time. So I reimplemented a DSO to give better bounding information so PRMan could purge it. This sped the rendering up quite a bit – as well as used less RAM.

In short, just because everything has a 64-bit label on it these days, doesn’t mean it will solve all your problems. It might solve some initial problems and give you an entirely new set of problems to solve.

This is pretty much a rant, you’ve been warned. But this crap comes up all the time and it’s really annoying.

If you’re a mathematician or coder I’ve been told that we’re not creative. In fact we’re the opposite of creative according to some very reliable sources. Apparently there have been studies done to show that people who are very technical are not creative at all. Even further, there is no amount of education or self will that can change this. As technical people we are beholden to a life lacking of all creativity. We can’t animate, light, draw, model or write. According to these reliable sources.

There are probably studies conducted right now to find the gene that locks into this lack of creativity. So the next time you think you’ve found a ‘creative’ solution to a problem. It’s not creative. I don’t know what word you would use to describe it. But it’s not creative, according to reliable sources who have read studies.

And if you don’t like what you see from these ‘creative’ individuals, it’s because you lack the ability to understand it – maybe even due to some genetic predisposition.

Also these studies have concluded, “Well, in general, a lot of technical people are that way.”

Where are all these studies? Who the hell knows.

It’s like Gattaca in real life – or maybe Idiocracy.

About four years ago, I sorta became really obsessed with speeding up my compiles. Why? Well, because they were taking forever. I went through the entire PCH business and did the compilation firewall thing – and it helped. However, PCH is kind of a pain. Compilation firewalls are cool though. I still use them to this day. However back then, even with both of these and few other things on the software side – my compiles for large projects were still very slow. Slow for me is like 5-10 minutes. Mostly because I work on projects with really tight turn arounds. Anyway, I just wanted to throw my two cents in on what you can do speed up compiles.

Faster Hard Drives – Not Noticeable
If you time it, you will see a speed difference. However, in the grand scheme of compiling it’s not easily noticeable. I went from a couple 7200RPM 16MB Cache 300GB Western Digital drives to a couple of 15000RPM 16MB Cache 150GB Raptors and the speed up was hardly noticeable. I tried having the drives on different SATA channels – still not very noticeable. Sure it saved some seconds here and there, but nothing to write home about.

Faster CPU – Noticeable
If you’re looking for just for raw speed increases, this is the way to go. You will definitely notice a different. Might be expensive though.

Multi-Core CPUs – Very Noticeable
If you’re just looking for insane speed increases, this is it. On the Linux side, this has always been possible with the -j flag to make. Starting with Visual Studio 2008, the /MP allows for multi-file compiling. I run Vista and Mac OS X at home on a 8 core Mac Pro, multi-core compiling has helped turn things around so much quicker. Building Boost seems to be 8 times faster. I know it’s not exactly 8 times faster, but it’s close enough to count. My friend Andrew got an i7 recently and he’s made mention of how crazy fast compiling stuff has been on it with multi-core.

So if you’re looking for a way to compile faster go multi-core. Chances are you got more than one core on your system already.

Been working on a pretty big project to make things more efficient in ‘rendering’…part of which requires me to code some file translators, data exchange mechanism, etc. It’s been a really great experience, definitely pushes the limits of my C++ design skills. Both the project and my friend Andrew have motivated me to buy The Design and Evolution of C++. But C++ stuff, I ran across something today that I’ve never thought about – mostly because I was unaffected. I don’t know if this will be helpful to anyone, but it’s a bit interesting…maybe.

Knots in MFnNurbsCurve/MFnNurbsSurface
If you hadn’t taken the time to notice, there isn’t a method for MFnNurbsCurve and MFnNurbsSurface that lets you set the knot domain(s). At least not one that I could find. When I was coding the MayaBGEO importer/exporter I didn’t even think about it. BGEO files do not seem to carry the knot domain start/end in NURBS curves or surfaces – so I never had to set or get them.

From my observation, Maya calculates them when you set the knot vector itself. This is very nice of the Maya API. So if you ask Maya for domain of the knot(s), you always get the right values. Obviously Houdini calculates them as well. But since I didn’t have to interface with Houdini through the HDK, I don’t know exactly how it does it.

At some point when I get sleep and finish up other projects, I’ll put together something detailing the different NURBS formats between Maya and Houdini that I’ve encountered.

If you’re a TD that develops tools or just strictly a software developer at a visual fx place, you probably had to work with artists. To be completely frank, there are a lot of lazy artists out there. I met a TD once that kept a list of all the lazy artist he knew to ensure that he would never have to work with them again. That’s either extreme or smart depending on how you feel about the matter.

But onto the topic at hand…we often hear developers say “…well, that’s just user error” or users will make some comment about how a tool is only usable to someone who is a programmer.  The first five hundred times, it’s funny. Actually about the first five, maybe four, maybe three – maybe. After that you might begin to wonder if it might be true. So with that, I want to offer my two cents on part of the matter.

Now whether you believe in evolution or God, neither endowed its resulting creation with the ability to read minds. However, people often seem to forget this. Okay, so surface level, this might be more comical than anything else. So lets dig deeper.

Lets say a developer has to write a very complex tool that ultimately the artist will use without the assistance of the programmer. If you work at a good company, the artist and developer will work together to develop a tool. If you work at an okay company, the artist will say something like, “Oh, just look at this shot for example test data.” If you work at a really bad company, the artist will probably not care or will the developer.

So the first and the last don’t seem to matter much since they both have a way of resolving themselves. But the second is a problem, perhaps a very big problem. Some artists seem to have this idea that if they can carefully write down or describe an idea and give the developer some test data, a usable tool can be develop. Obviously this goes back the classic problem of users and designers believing something can be coded because it’s logical and since we’re humans…well you get the idea.

I believe the source of the problem here is that developers can’t read minds and artist don’t want to be involved in the development process because they want to do art. In this broken state, the developer will attempt to develop the tool to the best of his abilities guided by his design docs, conversations, and emails. But more often than not, in the end the tool that results from this process is almost usable. Not quite there yet. Because he can’t read the artist minds, he may or may not understand how to properly design the work flow.

There’s no rocket science needed here to understand why. People secure the failure in the tools development by not being involved in it, just like every other thing in life.

So I wrote a pretty glowing review of Qt Creator a few months ago. I still like and still think it’s one of the best things ever created. However, there is one really annoying aspect of it that I can’t seem to locate in the documentation without thinking, “Wow, that’s just completely stupid.”

Why is there NOT a way to easily add include paths and 3rd party libraries?

Philosophical design decisions aside, having QMake or CMake or whatever thing you want to use assemble include paths is extremely annoying. There’s being a hard head and then there is plain stupid. Okay, yeah I’m sure the world gets it that somewhere someone wants to keep things clean of the Qt Creator’s heart and soul being the .pro file. But it’s infuriating mistyping INCLUDEPATH or INCLUDEPATHS to add an include directory. Yes, I know only one of those is correct – that’s the point: which one? You simply don’t know until your stuff doesn’t compile.

I’m pretty sure this falls under the plain stupid category. I will continue to use Qt Creator so I will have to continue to have to answer my friends’ questions about this.