Training sessions: I’m proud to say this is a definite success. I was the initial Coordinator for our Reykjavik Python Community of Practice (studio-wide volunteer group that discusses python in general and its use at CCP), where I started two initiatives I’m very proud of. One is the weekly ‘enrichment session’ where we watch a PyCon video, go through a demonstration or tutorial, etc. These have gone over great, the trick is to do them even if only 4 people show up :) The other is Python in the Pisser, a python version of Google’s Testing in the Toilet. I hope we can open source the newsletters and maybe share content with the outside world. More information on that coming in the future.

Collective vision/tasking: We run an XP-style team on tech art so I like to think my TAs feel ownership of what they are working on. In reality, that ownership and vision increases with seniority. We are actively improving this by doing more pairing and having more code reviews- the team is at a level now where they can review each other’s work and it isn’t all up to me to mentor/train them.

Evolving standards and practices: We started in Hansoft, moved to Outlook Tasks, and settled on Trello. We’ve discovered our own comfortable conventions and can discuss and evolve them without getting into arguments or ‘pulling rank’.

Community engagement: The CoP and mentoring has definitely done some work here. I try and give everyone 10%/10% time, where 10% is for ‘mandatory’ training or non-sprint tasks, and 10% is for their personal enrichment.

Move people around: We haven’t had much of an opportunity for this but we did change desk positions recently :) The art team is too small to have many opportunities and all graphics development is on one scrum team.

Code katas: We had one and it was mildly successful. We plan to do more but scheduling has been difficult- we do two releases a year, and DUST introduces complications in the middle of those releases, but we’ll be doing more things like it for sure.

I’ve also been doing very regular 1-on-1′s and, I hope, been getting honest feedback. Overall I am happy with my performance but can improve in all areas, even if that means doing more of the same (and becoming a better XP team).

Anyone want to share what successful cultural practices they have on their team/at their studio?

Remote Debugger: Just follow the instructions here: http://tech-artists.org/forum/showthread.php?3153-Setting-up-PyCharm-for-use-with-Maya-2013. We ended up making a Maya menu item that will add the PyCharm helpers to the syspath and start the pydev debugger client (basically, the only in-Maya instructions in that link).

Autocomplete: To get autocomplete working, we just copied the stubs from “C:\Program Files\Autodesk\Maya2013\devkit\other\pymel\extras\completion\py” and put them into all of the subfolders under: “C:\Users\rgalanakis\.PyCharm20\system\python_stubs” (obviously, change your paths to what you need). We don’t use the mayapy.exe because we do mostly pure-python development (more on that below), and we can’t add the stubs folder to the syspath (see below), so this works well enough, even if it’s a little hacky.

Remote Commands: We didn’t set up the ability to control Maya from PyCharm, we prefer not to develop that way. Setting that up (commandPort stuff, PMIP PyCharm plugin, etc.)  was not worth it for us.

Copy/Paste: To get copy/paste from PyCharm into Maya working, we followed the advice here:  http://forum.jetbrains.com/thread/PyCharm-671 Note, we made a minor change to the code in the last post, because we found screenshots weren’t working at all when Maya was running. We early-out the function if “oldMimeData.hasImage()”.

And that was it. We’re very, very happy with the result, and now we’re running PyCharm only (some of us were using WingIDE or Eclipse or other stuff to remote-debug Maya or work with autocomplete).

————————

A note about the way we work- we try to make as much code as possible work standalone (pure python), which means very little of our codebase is in Maya. Furthermore we do TDD, and we extend that to Maya, by having a base TestCase class that sends commands to Maya under the hood (so the tests run in Maya and report their results back to the pure-python host process). So we can do TDD in PyCharm while writing Maya code. It is confusing to describe but trivial to use (inherit from MayaTestCase, write code that executes in Maya, otherwise treat it exactly like regular python). One day I’ll write up how it works in more depth.

Note: I’ll be using python functions and terminology but this applies to any language.

It goes without saying but, use the tempfile module. Don’t use environment variables or roll something yourself (I’ve seen both done).

Never hard-code the location of a temporary file. I’ve used middleware that does an equivalent of “os.path.join(gettempdir(), ‘myscratch.foo’)“ to get some path. Which means running multiple processes at the same time causes file lock errors! I’ve had to change the temp directory before calling these processes.

Either your directory or your filename should always be programmatically looked up: so “mkstemp(dir=os.path.join(gettempdir(), ‘myscratchfiles’)“ is acceptable, as is “os.path.join(mkdtemp(), ‘myfile.foo’)“.

Try and clean up your files and folders! I say ‘try’ because it isn’t always possible. Sometimes your library may need to return the path to some file it generates. In that case, rather than rely on the caller to clean up the file (which would be a bizarre dependency and docstring!), you’re better off to take in the ‘output path’ to your library, and write the result file there. And your library can clean up the intermediate temp files. That way the caller can be responsible for deleting the result file if it needs (hopefully it doesn’t) because it knows more about the path.

In a lot of cases, I don’t bother cleaning up temp files for internal software. Management of temp files takes a non-negligible amount of work, and if I can keep the software simpler by not worrying about it, I will. I’d rather rely on the developers to keep their hard drives in good shape, which they’ll do anyway.

If you’re running something that will generate a lot of temp files (maybe your test running script), you can also set your temporary directory to a temporary subdir, and then clean that up. Something like:

oldtemp = tempfile.gettempdir()
newtemp = tempfile.tempdir = tempfile.mkdtemp() # Maybe set os.environs TMPDIR/TMP/TEMP as well?
try:
    nose.run() # Or whatever processing you need to do
finally:
    tempfile.tempdir = oldtemp
    shutil.rmtree(newtemp)

And lastly (it’s last because I’m sure people have some religious objection to it), I’ve actually created a custom mktemp function that just calls mkstemp and closes the file descriptor. Just getting a path is useful and worth the performance overhead in (IMO) the vast majority of cases, especially since we often just need the filename to pass to some external process.

What advice do you have for working with temp files (and where is my advice poor)?

At my current company, our last two Art hires have had a much more abbreviated hiring process- the Art Manager, myself, and the Art Producer (and the Art Director if needed).

So I’ve been through and a part of interviews at both ends of the complexity spectrum. I’ve been thinking about it recently and I’ll share some thoughts (and I’d also love people’s own opinions and experiences).

• Only a few people are generally good interviewers. If this doesn’t correspond with your Leads/Directors/Managers, there’s a problem. So I am not sure the depth of the interview varies greatly between the two styles.
• On the other hand, interview experience is important for more junior members, and if they don’t get experience they’ll not turn into good interviewers.
• Only a few people are generally responsible for making the decision anyway, and I’ve never actually seen a contentious decision: if one or two people have a thumbs down opinion, it’s enough of a red flag for everyone else. What’s the point of six or twelve people sitting around and pretending to decide?
• How often are interviews really surprising? You know in the first couple minutes whether you’ll accept someone or not, or whether they’re in the middle (usually meaning you need to find a better candidate).

So given those experiences I’m going to try do the following for the interview process for Tech Artists:

• See who wants to be part of the interview. Cultivating this skill is vital, but it isn’t for everyone, and people who have no interest shouldn’t waste their time.
• Expand the interview to include those people- it should definitely extend past the manager/lead level.
• Be rigorous, and don’t bother hiring anyone that isn’t unanimously liked. When the candidate pool is thin or work is slipping, it’s tempting to take a chance. It’s not worth the risk (in my opinion, of course).

I’m curious how other studios handle it, and what people think of those processes?

*I feel obligated to mention that if your studio is a management-run people-churner, please gripe at your managers and not me for writing this post!

I understand what creative/technical/art/design/qa/(product|game) direction is. I have no idea what “development direction” is. And if I do, I have no idea how it’d be beneficial. I mean, the few decisions like “we are using Hansoft for scheduling and backlog management” can be made at the project producer level, and most other ‘development direction’ I can think of negatively infringes on team autonomy.

Has anyone actually had success with the role of development director? Not just a super-talented individual who happened to do a good job, but an actual use for the role?

Which is why singletons are, to me, the worst form of framework masturbation in python. You will never be able to stop people from doing something stupid if they’re determined (in pure python). In the case of a singleton, that means instantiating more than one instance of a type. So spending effort on ‘designing’ singletons is not just a waste of effort, but actively harmful. Just provide a clear way to use a single instance, and your system should fail clearly if it detects an actual problem due to multiple instances (as opposed to, trying to detect multiple instances to keep said problem from happening).

The best method for singletons in python, then, is- whatever is simplest!

1. Some form of module or class state is, to me, the clearest. It requires someone reading or using your code to know nothing more than the most basic python. Just prefix your class def with an underscore, and expose an accessor function to an instance stored on the module (or on the class). The capacity for failure is minimal and the behavior is clear (it requires no behavior modification to the type itself).
2. Overriding __new__ is pretty bad but OK. It requires someone to understand the subtleties of __new__, which is a useful thing to teach someone but, are singletons really the time and place?
3. Using a metaclass is a terrible solution. It has a higher likelihood of failure (how many people understand the nuances of metaclasses!?). Misdirection even for people just reading your code, trying to understand your type’s behavior. Avoid.

Overall, the process isn’t too hard. Information is pretty clear (and in English), everyone was very accommodating, and there were no surprises from Iceland’s side. I wouldn’t bother getting a service to do it, I’d just do it myself. And our dog came out no worse for the wear.

Anyway, on to the timeline (I’ll list prices at the end):

1. In early September, I applied for a permit from MAST, which is good for up to a year. I should have done this much earlier. I needed to get the permit at least 30 days (something like that) before importing Shoni, which meant by the time I got the permit, she couldn’t come with us in October. This threw everything off and caused a lot of stress and extra shots. So get your permit ASAP. The rest of the process is filled with timing restrictions, don’t mess this one up.

2. There are two quarantine places. Once is in the far north (Hrisey, near Akueyri), one is nearer to Keflavik. They stagger their intake, so one takes pets for a few days in the middle of the month, the other at the end/start of the month. If you have a choice (and are living in the capital area), I’d choose the one near Keflavik, to avoid an extra return flight and less transport overall. I’ve also heard their English is better. Shoni ended up going to Hrisey though, because I screwed up the permit and that’s what worked out timing-wise.

3. There are certain shots that the dog needs to have at least 60 days from departure. There are other shots that she needs no more than 30 or 60 days from departure. Read everything and schedule everything in advance. Don’t mess this up! Though we did a little bit but talked to MAST and everything was fine.

4. Make sure you have an airline-ready travel crate, and make sure your dog is used to sleeping in it! A regular crate won’t do, you may need a special crate for air travel. We lucked out, Casady’s aunt and uncle had one they weren’t using, from their recent international move.

5. Shoni flew from Texas to New York in mid-October, after our wedding, in coach with my Aunts. This was the least harrowing part of the entire trip, even though a 10kg dog in the cabin is too big! If you can book your pet in the cabin, do it (it’ll also be cheaper). Try it even if they may be too big- she flew Jet Blue, and it made me like that airline even more. If she must go cargo, I’ll note that airlines have restrictions and cautions for certain dog breeds during certain months. Boston Terriers are brachiocyphallic (snub-nosed), so they can overheat and die during travel, especially during summer months (usually sitting out on the tarmac). Different airlines have different records and different breeds have different accident rates. But do your research and be safe (if the dog is worth the price you’re going to pay to move her, she’s worth this risk, I’d say). We sent Shoni’s (empty) crate as baggage.

6. It was difficult and a huge burden to place on someone (my Aunts) to prep a dog for an international move. We did a bunch of stuff in Austin, but there was stuff that needed to be done 30/10 days before departure, that my Aunts needed to do. Shoni ended up getting several unnecessary shots; there was lots of confusion and stress in the month she was with my Aunts. On the other hand, breaking the trip into two parts was easier on Shoni. I would have been scared for her life if she went on an 18 hour trip in her crate. The key takeaway is that better planning and less procrastination would have made things easier, but even with mistakes along the way everything turned out fine.

7. Again, read the paperwork. There’s stuff you need to fax 5 days before your pet arrives. There was, not surprisingly, a lot of stress in the last few days. Lots of calls with MAST and my family and making sure everything was good to go.

8. With everything set, Shoni flew Icelandair cargo in mid-November from JFK to Keflavik. It was painless and we got confirmation she arrived, the worst parts were over. The quarantine people picked her (and presumably other pets) up, drives them to Hrisey (or wherever your quarantine is), and they start their quarantine. There is no way to interact with your pets AFAIK, even if you are on the same flight (sometimes you may see them in the luggage area but it isn’t like you can take them out to pee!).

9. Once in quarantine, we asked for updates/photos, and got them. The “warden’s” English was not great so it was difficult to communicate, so I needed to have a friend translate some emails between English and Icelandic. Shoni looked nervous and the place was obviously pretty sterile, but she looked safe and healthy. Shoni is very well-adjusted and adaptable, so if you have a nervous pet she may fare worse. Also, I think you can visit your pets- but I wasn’t about to go to Akureyri as a new resident in December, but I probably would have visited her in Keflavik.

10. After 4 weeks (right before Christmas, for us!), Shoni’s time was up. And here’s another reason to choose Keflavik over Hrisey- Icelandic winter weather is fickle and her flight was delayed several times. She was on one of the last flights from Akureyri. We picked her up from the airport, took her home in a cab, and all was well. She didn’t have any of her toys or blankets she was sent with- the stuff has to be boiled and rarely survives it.

11. Costs. All are approximate.

• Permit: $240 (including transfer fee)
• Flight Austin->JFK: $100
• Flight JFK->Keflavik: $450
• Akureyri->Reykjavik: $100
• Quarantine: $1600 (varies with pet size)
• Customs fee: $100
• Vet bills: $700 or so, not sure
• Total: About $3500

In the end, it wasn’t a question of whether or not it was worth it- there was no question, she was coming. However, procrastination complicated things. And it is expensive. Bigger dogs will be more expensive, cats are smaller and require less shots so would be cheaper.

Anyway, I hope this post is helpful, and feel free to ask me any questions about my experience.

And at some companies, it works. My previous job was at a well-regarded studio, working on a huge game and IP, in a wonderful city, and lots of developers were looking for work (and we had the money to hire them, if not keep them after ship…). People really wanted to work there (I once interviewed someone as I was near the end of my tenure there, and told him pretty clearly, “you won’t like programming here.” And of course he took the job anyway). It didn’t make sense to spend effort training QA people when you could just hire the people you wanted directly.

However, I now work at a place that is much more difficult to hire for. Outside people respect the company and know the game, but the audience is smaller than one of the biggest IPs and most successful game studios of all time. And especially, it’s in Iceland. Iceland is a wonderful country, but we’ve had several people turn down offers or on-site interviews because their family said “no way” (myself almost included).

In my opinion, it makes more sense to hire QA people (often out of the EVE or local Icelandic community), and set them up on a career path that leads outside of QA. There will never be a serious shortage of applications for a QA job, but it can take a year to hire and relocate a senior person (and you are taking a big risk on that time and expense!). And to a large extent, this is what we do (and while we have sometimes failed at providing career paths, I still think it remains the goal).

I quite like this new strategy- not only does it produce good results over time, it also seems to have more integrity- QA people are too often treated like second class citizens, rather than devs-to-be. I’m not sure if my mind will change if I move on to another studio, but it’s at least how I feel now. I wonder how other studios approach this issue?

(Side note- I am not saying there isn’t a need for senior and permanent QA people, I’m just saying, there are lots of people in QA that don’t want a career in QA. There should also be career development inside of QA, but that shouldn’t be the only career development)

I don’t know why it took so long to figure out how to teach decorators (even harder than first figuring out how to use them!), but Steve’s method works, and I’d encourage you to use it to teach anyone who’s interested.

So a few weeks ago I gave up and said, forget it, I’m just going to write retrying rmtree/remove functions. It took a long time because I refuse to do cargo-cult programming on problems like this, so once I saw that article, I went ahead with it.

I just wanted to spread this information in case you’re in the same situation I was in. You may as well harden and test your little helper retying-delete function I know you have hidden away somewhere, and make it a part of your core libraries.

<No code provided- this is the hacky shit that cannot have a straightforward design and IMO shouldn’t leave your studio, so you’re on your own to figure out an acceptable design and implementation!>

I don’t know what I could have done differently. I just wasn’t happy at work, and there was little I could do to change it. The quality of my work was apparently very good, I was just terrible for morale, because I was either 1) pissing people off or 2) encouraging people to be pissed off at the problems I/we saw. Eventually I got the best advice I’ve ever gotten (which deserves its own blog post), and left the company. I went to the right place and became a positive developer.

And that’s sort of what struck me about the article and about how we typically deal with negative developers. Some developers are just not a good fit, regardless of how amazing their work is. If someone is negative because she is “culturally incompatible”, because there’s nothing you or your manager can do to fix it. And it is worth it to have a frank discussion about whether that person can ever be happy without changes to the studio, and if that person says ‘no’, you should discuss plans to part with mutual respect at a mutually agreed date.

I had to put in my two weeks at my last job to have this advice given to me by the President (GM? Can’t remember) at the time. It convinced me to un-quit, and to stay on another year. It ended up being a miserable year in many ways, but it was the right thing to do and worked out for the best. As managers- and friends and team members of negative developers- we need to keep this advice in mind when dealing with negative developers (and ourselves).

Are you making any decisions when you do this?

And if someone is making decisions that may be unnecessary:

Can we get from A to B without making any decisions?

I value the people I work with and I want them to be more effective. Sometimes people are afraid I’ll automate them out of a job, or they like a manual part of their workflow. More often they take pride in being the manual bottleneck behind a tricky or brittle process.

Humans are valuable because we can make complex decisions very quickly. When I automate an area someone isn’t immediately comfortable with, it’s not because I don’t value what he or she does. On the contrary: because I value their skills and time, I want to see them doing something that requires their unique abilities.

But in a fully dynamic language that has so much power- not understand how the language itself works puts you at a severe disadvantage. I’m not just talking about the one thousand aspects of meta-programming, but even just taking advantage of duck-typing (ie, instead of creating/passing a type, can you just pass a callable that returns a new instance?). Or how decorators work, or how importing works.

I am pretty sure I asked this when I started python but, are there any books (or courses) about python, written for more-or-less experienced programmers (even python programmers), that aren’t about ‘teaching python’ in the normal introductory (or cookbook/reference) way? More along the lines of CLR via C#, or some of the better python guides out there (Idiomatic Python). I am sure there are a large number of people out there who would get huge benefit from such a book or comprehensive guide.

It’s been fun to see the frustrations, problems, and questions she’s had:

• For loops. So hideous. I don’t know who invented such the syntax “for (i=0; i<100;i++)”, but really I blame the people that continued the tradition into later languages where it is a truly stupid syntax.
• Speaking of i++/i–. What are these things and why do they exist?
• Curly braces. What a waste of space!
• var. When do I use it and when do I not use it?
• Why do I need to end my lines with semicolons?

They also have a python course, I’ll be interested to see how that one goes. I suspect it’ll make less sense since she’ll now expect all languages to work as poorly as Javascript :)

Also to preempt the comments about how this doesn’t mean anything about a language and we shouldn’t design languages for complete programming newbies- yes, I agree. Mostly I found this interesting because the grievances she’s had all have their roots in C-style languages yet they are found in JavaScript which was designed to be novice-friendly. Though admittedly the novice in 1995 and 2012 start with very different dispositions.

I’ll certainly have much more to say once she moves into the rest of JS, and then into Python.

Also, Code Academy is really awesome.

Except it isn’t stylistic preference. And unlike my rant about tabs-vs-spaces, it isn’t easy to fix either.

Imagine a simple scenario (note, this only applies to Windows- I should mention in my line of work we are usually on Windows) :

1. You create a file, myModule.py, you put some awesome code in it, and check it into source control (probably Perforce but AFAIK any source control has the same problems).
2. A while later, you rename it to mymodule.py, fix up your code references, and check it in.
3. The code breaks on all your users machines, and you can’t clean it up without manual intervention, or changing your module to be called something else.

Did you see what happened? When you checked in the code, everyone synced down ‘myModule.py.’ When you changed the capitalization, everyone else’s VCS synced down the new file contents but, because the file was already there, didn’t delete myModule.py. So everyone else got the new code calling ‘import mymodule’ but keeps the old filename ‘myModule.py’. Fixing this problem either requires removing the file from people’s client and force syncing (manually or by mass-deploying a fixup script), or just renaming ‘mymodule’ to something else entirely.

The problem stems from python, which is case-sensitive, relying on the filenames of paths, which rely on Windows, which is case insensitive. Don’t bother blaming anyone, it’s just the way it is.

So the way to deal with it? Always use lowercase, which is exactly what the PEP8 style guide suggests.

Initially I thought they should be excluded- after all, it’s your ‘real’ code people are generally worried about- but now I’m not so sure. You should probably make sure your test files are actually run and covered, as once you have a large amount of tests that often bend in various ways, it isn’t always a given. And actually that’s just the case  we were in today, we have tests that are still not runnable on our CI server, but the report doesn’t show which ones.

Not to mention having your test source easily browseable in the form of a coverage report, which is easier for test-curious people to browse than a source depot.

I think I’m going to re-include tests in the report, despite it skewing our coverage percentage (favorably :)). But I’m really curious if there’s accepted practice or good reasons either way I haven’t thought of.

First: Read/write data, like UI/user preferences. I say, just use python dictionaries, and serialize them however the hell you want (json, yaml, pickle, cPickle, I don’t care). I don’t understand why anyone would build anything more complex (except maybe a wrapper over this functionality), and especially why anyone would bother using a non-serialized format like ini or cfg. Can there be a good reason?

Second: Read-only data, like application configuration (nothing that is edited by your app). This, too, is very commonly in config files with special like xml or ini. Well in this case I say, why bother even with serialized data at all? Just make it code! This data, by definition, does not have to be statically known and serialized, it is only needed at runtime. So why not make it a python module, have your code import/exec the python file, and access attributes from the python module? There’s a good deal of data we may only know at runtime, or we cannot statically represent, so we end up making the systems that consume this configuration data much more complex. (For an example, see Sphinx’s config, I think it does it right).

An example of where I think python-as-configuration has huge power is with complex configuration data like for a plugin system. Instead of relying on some static functionality, the configuration can even be callables that return a plugin instance- so now you don’t have to refer to globals inside of your plugins, you can have your own initializer with a much larger signature, and the plugin system can have its well-defined initialization interface.

I’m not sure I did a great job explaining that example- it deserves its own post. We’ve used it extensively for new tools and systems we’ve developed and it seems to work great (and results in zero globals or singletons used by the plugins, which is an artifact of most plugin systems I’ve seen).

These are my opinions and practices and I know there are plenty good modules which rely on ini/xml/config files. Other than legacy decisions or to be compatible with pre-existing systems, why would someone choose a config file/format over 1) serialized python objects and/or 2) python code?

 The problem I´m having: I can control the ears now manually, after setting up the reactions, but apparently the CAT system isn´t respecting any keyframes I set on the facial controls, neither in setup nor animation mode.

He already hinted at the answer in the same post:

Even though I´ve heard a couple of times not to rely on CAT in production…

So there’s your answer.

Never depend upon closed-source frameworks that aren’t ubiquitous and proven.

It’s true of CAT, it’s true of everything. And in fact it is one reason I’ll never go back to developing with .NET on Windows (the 3rd party ecosystem, not the framework itself). If you don’t have the source for something, you 1) will never fully understand it, and 2) never be able to sustain your use of it. When I was at BioWare Austin, and the Edmonton guys decided to switch to CAT, I was up in arms for exactly this reason. We had an aging framework- PuppetShop- but it worked well enough, we had the source, and acceptable levels of support (Kees, the author, is/was readily available). Instead, they switched to a closed-source product (CAT) from a vendor that has repeatedly showcased its awful support (Autodesk), and headache ensued. Fortunately I never had to deal with it and left some months after that. Without the source, you’re dependent upon someone whose job it is to provide support just good enough so you don’t leave their product (which is difficult since they own everything), and bad enough that you have to hire them to fix problems (they pride themselves on this level of support, which I call extortion).

As for the ubiquitous and proven part: unless this closed source solution is incredibly widespread (think Max, Maya, etc.), and has a lot of involved power users (ie, Biped is widespread but difficult to get good community support for because it attracts so many novices), it means you have to figure out every single workaround because you can’t actually fix the problem because you don’t have source. Imagine working with no Google- that’s what you give up when you use a closed-source framework that isn’t an industry standard.

So don’t do it. Don’t let others do it. If you’re currently doing it, think about getting the source and if you can’t do that, start making a backup plan.

Hey Rob. 5 months? Are you really this shortsighted? It’s like watching a kid say he’ll NEVER get tired of THIS toy. Frankly, if you don’t get tired of it you stopped growing. Take it as a good learning experience for the time when you forge your own destiny, but if you aren’t back to being a grumpy asshole in 6 months I’ll eat my hat. Not that I wear hats.

So 6 months (and a released expansion) later, have things changed? No, not one bit. In fact, late-night-drunk-rants have growth even more positive all around. Few of the bitch-sessions I’ve been used to in my career. It is an unfamiliar feeling. But addictive.

So why am I not back to being a ‘grumpy asshole’? Because there’s nothing to be grumpy about. There’s plenty wrong, but we’re moving at a steady pace in the right direction. And everyone is on board that it’s the right direction. No “we’ve decided this is the right direction so STFU and do what you’re told”. This happens because the talented people that complain loudly have several constructive outlets (I put myself in that group, at the risk of sounding egotistical).

One of the most exciting are communities of practice. Read the Wikipedia article if you like, but really they are a company-sanctioned forum for people with axes to grind to argue. Then we figure out what we want to do, and how to do it. And then we do it on some 15% time for skunkworks projects we’re able to reserve. Being able to talk about our common problems, across teams and responsibilities- we have everyone from tech artists to server programmers to the CTO there- is a refreshing experience.

(If you’re at a large company with lots of programmers who all aren’t on the same team, I’d highly suggest forming your own communities of practice).

The people who get shit done and can convince you of the way forward are given the responsibility to get more shit done. It’s nice. I think it has to do with the open source and python mentality.

I’m going to tell a story of a mouse click event. It is born when a user clicks her mouse button. This mouse click goes from the hardware, to the OS. The OS determines that the user wants to interact with your GUI, so it sends the mouse click event to your GUI’s process. Here, the mouse click sits in a queue of other similar events, just hanging out. At some point, usually almost immediately, your process (actually the main thread in the process) goes through and, one by one, dispatches the items (messages) in the queue. It has determined our mouse click is over a button and then tells the button it’s been clicked. The button then usually repaints itself so it looks pressed, and then invokes any callbacks that are hooked up. The process (main thread) goes into one such callback you hooked up, that will look at 1000 files on disk. This takes a while. In the mean time, the user is clicking, but the messages are just piling up in the queue. And then someone drags a window over your GUI, because they’re tired of their clicks not doing anything and want to see what’s new on G+. The OS sends a message to your UI that it needs to repaint itself, but that message, too, just sits in the queue. At some point, your OS may even realize your window is not responding, and fade it out and change the title bar. Finally your on-button-click callback finishes, the process (thread) is done processing our initial mouse click, and then goes back to processing the messages that may have accumulated in the queue, and your UI will refresh and start responding again.

All this happens because the thread that processes messages to draw the UI was also responsible for looking at 1000 files on disk, so it wasn’t around to respond to the paint and click messages. A few pieces of info:

1. You can’t just ‘update the UI’ from the middle of your code. In addition to being terrible form code-wise, clearing the message queue would just cause other things to block the main thread, and it’d all get into one giant asynchronous mess. Some programs may have their own UI framework that supports this. Don’t trust it. You really just need the main/GUI thread clear as much as possible to respond to events.
2. Your GUI process has a single ‘main thread.’ A thread roughly corresponds to, and I’m being not nuanced here, the software concept of a hardware CPU core. Your GUI objects can only be created and manipulated by the main thread.

This means, you want to keep your main thread free so it can act on GUI stuff (paint events, mouse clicks) only. The processing, such as your callback that looks at 1000 files, should happen on another thread (a background thread). When the processing is complete, it can tell the GUI thread that it is finished, and the GUI thread can update the UI. Your background thread can also fire events or invoke a callback that will be picked up by the GUI thread, so the GUI can update a progress bar or whatever.

How you actually do this varies with each UI framework. .NET, including WinForms and WPF, is quite easy to use (look at the BackgroundWorker class, but the Tasks Parallel Library and Async CTP make that less necessary). Python GUI frameworks are a bit worse off- multithreading in python in general is worse off- so it’ll be different for each one, and probably not as simple as .NET. There’s no excuse for python GUI’s to lock up, it just takes a little more effort to get it completely right (like callbacks to update a UI are a bit tricky).

There is one other vital thing to keep in mind- DCC programs generally require you to interact with the API or run all their script on the main thread, which as discussed should also be kept clear. Bummer! So the best thing we can do is block while we get our data from the scene, put the processing on a background thread, and report back to the main thread when done, applying the new data back to the scene if necessary. Unfortunately, if your processing interacts with the API in any way, you probably need to put it in the main thread as well. So, right now, your GUI’s in DCC apps may need to lock up, by design. There are, in theory, ways to avoid this, but they’re well outside of the scope of what you can handle if you’re learning anything from this article.

Whatever your language and program, those are the essentials of why your GUI locks up.

Note: This info is not nuanced (and is less accurate the lower down things go), may not be terminologically perfect (though it should be vulgarly comprehensible), and is Windows-only, though it should be enough to know how any higher-level GUI framework (such as Qt) would work on a non-Windows system).