I came in this morning to a fresh windows 7 install, and I've spent the time since getting my workspace up to speed. That's more a knock on our workspace than it is on windows 7, but in the process I have some observations.
1. I don't like confirming everything twice. I'll turn off browser-open-file confirm boxes.
2. using the windows key to open programs is awesome.
3. yay search
4. using a third party zip utility to install things directly into the program files directory fails because they don't have access. The two I tried (winRar and 7Zip) did not handle it well.
5. It's pretty.
6. setting environment variables hasn't changes since what, windows 98? It still sucks hard. I know nobody ever actually does this... except anyone using java or maven. Grr.
But I can't escape the vague feeling that Microsoft have given up. It seems like their heart really isn't in it anymore, like they're just doing what the broader IT and design communities tell them to do. This is an operating designed by a company that's staring its death sentence in the face. They can feel themselves becoming IBM, and the irony is not lost on anyone. Windows 7 is a deer-in-the-headlights, avoid-all-controversy design. And it... well so far I find it vaguely depressing.
*Yes yes, nobody cares what I think.
programmer analogies
I've been thinking about different trends and practices in programming a lot lately, since they've been hitting me in the face at work. But instead of jumping into that I want to start off with an analogy.
What's the difference between building a truck (a big 18-wheeler), and building a racecar? They have a lot in common. They both have very powerful engines. They both meet very exacting quality standards. They're both very complicated. But there's a different mindset that goes into each one. Let me table you:
You see a lot of trucks on the road. Building trucks is serious business for serious people. People who build trucks can be proud of what they're doing. But you'd rather drive the racecar. (Or at least a sports car.)
So, I'd like to apply the analogy to something closer to my field of interest, namely browser-based MMOs. When you're making such a beast, you have a choice. You can look at it like a web application (see: facebook, amazon, gmail...) or you can look at it like a game (see: mario, halo, starcraft).
My contention is simple: web-apps are the trucks of programming, games are the racecars.
I think you can take this analogy a lot further, to look at the people who work on cars and programs, to look at their tools and trends, etc.. Anyway it upsets me that we're building a racecar, but our engineering decisions seem to follow the current truck-building trends and best-practices. They're not appropriate to our business and they've put us in a world of hurt.
>:-(
*This is a guess. Maybe fuel efficiency is important for racecars? I don't really know.
**web page response times of 1 second are acceptable. If you press a button in a game and don't see a response within 0.5 seconds, the game has crashed.
***World of Warcraft goes down for 6 hours every week, on Tuesday morning from 5AM to 11AM. If KFPW went down for a (scheduled!) 2.4 hours every day and was fine the rest of time, that would be just fine with me. But can you imagine if gmail did the same thing?
What's the difference between building a truck (a big 18-wheeler), and building a racecar? They have a lot in common. They both have very powerful engines. They both meet very exacting quality standards. They're both very complicated. But there's a different mindset that goes into each one. Let me table you:
| Truck | Racecar | |
| speed and handling | not important | vitally important |
| weight and aerodynamics | not important | very important |
| reliability target | months, years | one race |
| maintenance costs | must be cheap to fix | not important |
| fuel efficiency | very important | not important* |
You see a lot of trucks on the road. Building trucks is serious business for serious people. People who build trucks can be proud of what they're doing. But you'd rather drive the racecar. (Or at least a sports car.)
So, I'd like to apply the analogy to something closer to my field of interest, namely browser-based MMOs. When you're making such a beast, you have a choice. You can look at it like a web application (see: facebook, amazon, gmail...) or you can look at it like a game (see: mario, halo, starcraft).
My contention is simple: web-apps are the trucks of programming, games are the racecars.
| Web App | Game | |
| interface speed and handling | not very important** | vitally important |
| cpu efficiency and network latency | not important | very important |
| user accessibility, availability | 99.99 or better | 95? 90?*** |
| maintenance costs | must be cheap to fix | not important |
| bandwidth costs | important | not important |
I think you can take this analogy a lot further, to look at the people who work on cars and programs, to look at their tools and trends, etc.. Anyway it upsets me that we're building a racecar, but our engineering decisions seem to follow the current truck-building trends and best-practices. They're not appropriate to our business and they've put us in a world of hurt.
>:-(
*This is a guess. Maybe fuel efficiency is important for racecars? I don't really know.
**web page response times of 1 second are acceptable. If you press a button in a game and don't see a response within 0.5 seconds, the game has crashed.
***World of Warcraft goes down for 6 hours every week, on Tuesday morning from 5AM to 11AM. If KFPW went down for a (scheduled!) 2.4 hours every day and was fine the rest of time, that would be just fine with me. But can you imagine if gmail did the same thing?
back to basics, and it feels good
I've had all week off, and most of it I spent lazing around and playing videogames. I did some housework too. But I've been avoiding working on any of my real projects, because I've felt so burned out on programming.
Yesterday and today I finally sat down to work on a little project for Tim, and I find myself really invigorated by it. Programming for myself, by myself, on a new project, is a completely different experience from working on a huge MMO codebase. I don't have to worry about the side effects of my changes because there are no other systems relying on this code. I don't have to get into anybody else's head, and I don't have to reformat code to make it readable. I don't have to remember/wonder why something was done a certain/dumb way.
I control the horizontal, I control the vertical. I go from being the "veteran," to being the "guru."* My code is much simpler and less defensive. Which means, much faster to write. All the class and variable names are perfect. It is so refreshing. I know it won't last. but it's nice.
* Funny. http://coderoom.wordpress.com/2010/03/19/5-stages-of-programmer-incompetence/ Thanks Jared.
Yesterday and today I finally sat down to work on a little project for Tim, and I find myself really invigorated by it. Programming for myself, by myself, on a new project, is a completely different experience from working on a huge MMO codebase. I don't have to worry about the side effects of my changes because there are no other systems relying on this code. I don't have to get into anybody else's head, and I don't have to reformat code to make it readable. I don't have to remember/wonder why something was done a certain/dumb way.
I control the horizontal, I control the vertical. I go from being the "veteran," to being the "guru."* My code is much simpler and less defensive. Which means, much faster to write. All the class and variable names are perfect. It is so refreshing. I know it won't last. but it's nice.
* Funny. http://coderoom.wordpress.com/2010/03/19/5-stages-of-programmer-incompetence/ Thanks Jared.
curious
Living on the West Coast, it seems like most national news happens in the morning, much of it before I even wake up.
I'm curious if there's a different feeling on the East Coast, and if so, what kind of difference does it make in your outlook?
I'm curious if there's a different feeling on the East Coast, and if so, what kind of difference does it make in your outlook?
morality in the age of leisure
It's like love in the time of cholera, except completely different.
I just came off of an excellent discussion with Dave, and I want to reflect on it and flesh out my thinking.
When people are living in conditions of existential stress, (wars, famines, pre-technological societies), (my) conventional wisdom says that social pressures increase. Stressful times create intense personal bonding, and with that bonding comes strong social pressure to conform to the group.
There's a point I want to make here, that I'm struggling with...
Remember when calculators were introduced to schools? A lot of people who grew up without them said, "[That's cheating! Children will never learn how to do arithmetic by hand! They will grow up stupid!]" And well they were right about the second sentence, but wrong about the first and third. The fallacy that they fell into, is that their experience tells them that you will live most of your life without access to a calculator. But their experience is completely inapplicable to their children's lives. Kids growing up today will always, always, have access to calculators, and google, and wikipedia. For the rest of their lives, forever and ever. So, why would they need to know long division? It's a cute trick, and it's good to know what it means to divide two numbers. But you're never going to use that skill as an adult, except to teach it to your kids, who will also hate it.
So: calculators are not cheating, they are the future. Looking up facts online is not cheating. Storing all of your friends contact information into your devices so that you don't have to remember their phone number is not cheating. Using a GPS navigation system is not cheating.
Morality is having the same culture shock.
Example one is sexual promiscuity. 200 years ago, it was a big deal, because it caused all sorts of very real social problems in the form of unwanted pregnancies, orphaned and abandoned children and mothers, and disease. Today, (almost?) all of those problems can very simply and easily be avoided. The consequences of divorce are down too; divorced mothers are no longer helpless and hopeless. It still sucks of course. But it's not the moral hazard that it used to be, by a long shot.
So... that's all really great news for society, that we don't have these horrible problems anymore. But when some people's behavior starts expanding to fill the new environment, other people get really upset. "[That's immoral! People will start having sex any time they feel like it! Society will fall apart!]"
I'm going to come short of finishing the analogy I've drawn here, because I'm too uncomfortable with the topic myself. But I think it's clear where this argument is going. If resurrection were cheap and easy, murder would not be nearly so serious a crime. Nor would suicide. We would still want to find it abhorrent, but it wouldn't threaten society to the same degree. You'd have recreational suicide, ritualistic sacrifice, lethal game shows. And it wouldn't ruin society at all.
So, perhaps, the more advanced, the wealthier society gets, the more depraved it becomes, in the eyes of the older society. But also, the more liberated it becomes? Like I said, I feel pretty uncomfortable with this discussion, or at least, with having this discussion in public, outside of my own brain-space. Taboos are powerful things. But I wanted to get the point out.
I just came off of an excellent discussion with Dave, and I want to reflect on it and flesh out my thinking.
When people are living in conditions of existential stress, (wars, famines, pre-technological societies), (my) conventional wisdom says that social pressures increase. Stressful times create intense personal bonding, and with that bonding comes strong social pressure to conform to the group.
There's a point I want to make here, that I'm struggling with...
Remember when calculators were introduced to schools? A lot of people who grew up without them said, "[That's cheating! Children will never learn how to do arithmetic by hand! They will grow up stupid!]" And well they were right about the second sentence, but wrong about the first and third. The fallacy that they fell into, is that their experience tells them that you will live most of your life without access to a calculator. But their experience is completely inapplicable to their children's lives. Kids growing up today will always, always, have access to calculators, and google, and wikipedia. For the rest of their lives, forever and ever. So, why would they need to know long division? It's a cute trick, and it's good to know what it means to divide two numbers. But you're never going to use that skill as an adult, except to teach it to your kids, who will also hate it.
So: calculators are not cheating, they are the future. Looking up facts online is not cheating. Storing all of your friends contact information into your devices so that you don't have to remember their phone number is not cheating. Using a GPS navigation system is not cheating.
Morality is having the same culture shock.
Example one is sexual promiscuity. 200 years ago, it was a big deal, because it caused all sorts of very real social problems in the form of unwanted pregnancies, orphaned and abandoned children and mothers, and disease. Today, (almost?) all of those problems can very simply and easily be avoided. The consequences of divorce are down too; divorced mothers are no longer helpless and hopeless. It still sucks of course. But it's not the moral hazard that it used to be, by a long shot.
So... that's all really great news for society, that we don't have these horrible problems anymore. But when some people's behavior starts expanding to fill the new environment, other people get really upset. "[That's immoral! People will start having sex any time they feel like it! Society will fall apart!]"
I'm going to come short of finishing the analogy I've drawn here, because I'm too uncomfortable with the topic myself. But I think it's clear where this argument is going. If resurrection were cheap and easy, murder would not be nearly so serious a crime. Nor would suicide. We would still want to find it abhorrent, but it wouldn't threaten society to the same degree. You'd have recreational suicide, ritualistic sacrifice, lethal game shows. And it wouldn't ruin society at all.
So, perhaps, the more advanced, the wealthier society gets, the more depraved it becomes, in the eyes of the older society. But also, the more liberated it becomes? Like I said, I feel pretty uncomfortable with this discussion, or at least, with having this discussion in public, outside of my own brain-space. Taboos are powerful things. But I wanted to get the point out.
usb theremin?
Also what's the fastest /best/cheapest way to get a theremin interface hooked up to a modern digital synthesizer? (that uses digital samples?)
No-one makes a usb theremin? or do they? I don't know if MIDI would handle a theremin very well...
http://www.thereminworld.com/news.asp?cat=31
blech. None of those is what I want.
I'm feeling very Veruca Salt about theremins all of a sudden
No-one makes a usb theremin? or do they? I don't know if MIDI would handle a theremin very well...
http://www.thereminworld.com/news.asp?cat=31
blech. None of those is what I want.
I'm feeling very Veruca Salt about theremins all of a sudden
GIVE IT TO ME NOW!
Yeah ok time for lunch Nate...
micro episodic game design
I've been pondering whether it would be possible to produce a game in the idiom of a web comic, which is to say, three updates a week or more, with one or two authors.
At first glance it looks really, really hard. With a traditional (static) web comic it's pretty easy to put a number on how long it takes to produce each update. An hour to brainstorm the joke, an hour to sketch it out and complete the planning, and maybe a few hours to implement.
With a micro-episodic game, your players are supposed to come back every other day and play a little bit more, right? Is it possible to develop fun/deep gameplay, without driving away your audience? The average web comic audience, after all, only needs about 10 seconds to grok your latest update; value is delivered over a span of weeks, or during long binges as a new reader plows through the archives. Your game needs to stand up to both modes of play.
With a traditional game, value is delivered primarily through the novelty of the gameplay or the puzzle.
Comics tend to be character driven, and a good comic can coast for a while with no plot at all if the audience is invested in the characters. A game would need to capture that level of good-will. People need to want to come back each time to see what happens next.
Assuming you can solve that problem, you immediately hit another problem. In a comic, if a reader doesn't get or like a particular panel, they can skip it. A micro-episodic game would need to be very careful to not throw up any roadblocks for players. If players can get stuck and become frustrated, you have no audience.
In order for the game to be meaningful, there have to be choices. But in order for the micro-episodic format to function, each update has to be applicable to every player, regardless of their previous choices.
Web comics are not very bug-prone. A micro-episodic game certainly sounds very bug-prone. The game design and tech design would need to be very defensive and robust.
So. Like I said it looks really really hard.
Perhaps obviously, I'm looking at things like homestarrunner.com and mspaintadventures.com for comparison and inspiration. Those two sites are very successful at delivering many semi-interactive experiences on a regular schedule. Are there others I'm unaware of? Actually, I'm not sure I want to know. I like to jump into things like this without doing a lot of research first, because research tends to be depressing. ;-)
The game that's taking shape starts off very, very simply. It uses a character that grows as you make choices, in response to your choices, and you grow your character over the entire span of the game. The essential mechanic is navigation, you have to navigate to the next screen. Maybe the front edge of the game is always a "loading" screen which means that you're at latest. Probably you can navigate backwards and reverse (some of?) your choices to explore other options. There's a "reference" save game that anyone can use to jump into the game at the latest point. Maybe it's pulled from the community, maybe not. Or maybe that's not necessary, or maybe only at the start of chapters. We progress from blank screens to mazes to simple choices to character development, and as we go we introduce game mechanics that will stick around for the rest of the game.
Advanced ideas:
* navigation from late in the game back to early screens
* massively multiplayer
* time travel, revisiting old locations
* community driven content generation
* algorithmic/interactive content generation
Sounds fun. And still really really hard.
At first glance it looks really, really hard. With a traditional (static) web comic it's pretty easy to put a number on how long it takes to produce each update. An hour to brainstorm the joke, an hour to sketch it out and complete the planning, and maybe a few hours to implement.
With a micro-episodic game, your players are supposed to come back every other day and play a little bit more, right? Is it possible to develop fun/deep gameplay, without driving away your audience? The average web comic audience, after all, only needs about 10 seconds to grok your latest update; value is delivered over a span of weeks, or during long binges as a new reader plows through the archives. Your game needs to stand up to both modes of play.
With a traditional game, value is delivered primarily through the novelty of the gameplay or the puzzle.
Comics tend to be character driven, and a good comic can coast for a while with no plot at all if the audience is invested in the characters. A game would need to capture that level of good-will. People need to want to come back each time to see what happens next.
Assuming you can solve that problem, you immediately hit another problem. In a comic, if a reader doesn't get or like a particular panel, they can skip it. A micro-episodic game would need to be very careful to not throw up any roadblocks for players. If players can get stuck and become frustrated, you have no audience.
In order for the game to be meaningful, there have to be choices. But in order for the micro-episodic format to function, each update has to be applicable to every player, regardless of their previous choices.
Web comics are not very bug-prone. A micro-episodic game certainly sounds very bug-prone. The game design and tech design would need to be very defensive and robust.
So. Like I said it looks really really hard.
Perhaps obviously, I'm looking at things like homestarrunner.com and mspaintadventures.com for comparison and inspiration. Those two sites are very successful at delivering many semi-interactive experiences on a regular schedule. Are there others I'm unaware of? Actually, I'm not sure I want to know. I like to jump into things like this without doing a lot of research first, because research tends to be depressing. ;-)
The game that's taking shape starts off very, very simply. It uses a character that grows as you make choices, in response to your choices, and you grow your character over the entire span of the game. The essential mechanic is navigation, you have to navigate to the next screen. Maybe the front edge of the game is always a "loading" screen which means that you're at latest. Probably you can navigate backwards and reverse (some of?) your choices to explore other options. There's a "reference" save game that anyone can use to jump into the game at the latest point. Maybe it's pulled from the community, maybe not. Or maybe that's not necessary, or maybe only at the start of chapters. We progress from blank screens to mazes to simple choices to character development, and as we go we introduce game mechanics that will stick around for the rest of the game.
Advanced ideas:
* navigation from late in the game back to early screens
* massively multiplayer
* time travel, revisiting old locations
* community driven content generation
* algorithmic/interactive content generation
Sounds fun. And still really really hard.
amf serialization between as3 and java
I was cleaning out my blog and I found this old post in draft form. I don't know if anyone other than me will find it interesting, and yet I'm posting it! But I don't think the internet minds. The internet is nice like that.
~
Ok another inside baseball post for all those flash/java coders in my blog readership*. So, you say you need to pass objects back and forth between Java and AS3. You say you've tried using Xstream XML serialization, but it's just too slow? Let me tell you, you definitely want to be using AMF. It's Adobe's native object transfer format, and it is wicked fast**.
Ok so that means you want to use BlazeDS on the java side, and some kind of native deserializer*** on the client side. That sounds pretty simple! But since I know you're a vry srs software engineer, I know that you need your objects to be strongly typed and type-safe, so that you can plug them into the rest of your client and server logic. Well, to do that you need to carefully line up all of your classes on the java side and the flash side so that they are the same, and then register each AS3 class with a call to registerClassAlias. Ok still not so bad.
Next, forget about using AS3 enums. The AMF deserializer basically won't let you do it, and you'll lose the benefit of having an enum class to begin with. You can squirm and complain, but you're not getting out of this one: Java enums work fine. AS3 enums do not work. You must use primitive strings. You will lose enum type checking and compile time safety. DEAL.
Now, you're pretty close, but there are a couple more things to take note of. If you're working in vanilla actionscript 3, you don't have the mx packages linked in. That means that when BlazeDS sees a Java List, and it sends you something called an ArrayCollection, flash will barf. So you need to set the legacyCollection flag on the SerializationContext object before you serialize your java objects.
*pfft.
**about 40 times faster than our (admittedly unoptimized) as3 implementation of xstream. 40 times is a lot of times to be faster by.
***pronounced de-cereal-izer, which is also a great word. I think that's what you call someone who eats all the crumbs at the bottom of the 3 nearly-empty cereal boxes in the pantry.
~
Ok another inside baseball post for all those flash/java coders in my blog readership*. So, you say you need to pass objects back and forth between Java and AS3. You say you've tried using Xstream XML serialization, but it's just too slow? Let me tell you, you definitely want to be using AMF. It's Adobe's native object transfer format, and it is wicked fast**.
Ok so that means you want to use BlazeDS on the java side, and some kind of native deserializer*** on the client side. That sounds pretty simple! But since I know you're a vry srs software engineer, I know that you need your objects to be strongly typed and type-safe, so that you can plug them into the rest of your client and server logic. Well, to do that you need to carefully line up all of your classes on the java side and the flash side so that they are the same, and then register each AS3 class with a call to registerClassAlias. Ok still not so bad.
Next, forget about using AS3 enums. The AMF deserializer basically won't let you do it, and you'll lose the benefit of having an enum class to begin with. You can squirm and complain, but you're not getting out of this one: Java enums work fine. AS3 enums do not work. You must use primitive strings. You will lose enum type checking and compile time safety. DEAL.
Now, you're pretty close, but there are a couple more things to take note of. If you're working in vanilla actionscript 3, you don't have the mx packages linked in. That means that when BlazeDS sees a Java List, and it sends you something called an ArrayCollection, flash will barf. So you need to set the legacyCollection flag on the SerializationContext object before you serialize your java objects.
*pfft.
**about 40 times faster than our (admittedly unoptimized) as3 implementation of xstream. 40 times is a lot of times to be faster by.
***pronounced de-cereal-izer, which is also a great word. I think that's what you call someone who eats all the crumbs at the bottom of the 3 nearly-empty cereal boxes in the pantry.
from math to biology
When I was learning about computer science* in college, they taught it like math. Everything was entirely comprehensible, if abstract. Terms like "Lamda Calculus" reinforce the association. The study of computer science, in academia, is essentially an abstract theoretical pursuit. The skills you learn in this setting are extremely useful for writing algorithms, and analyzing dozens of lines of code.
When you first start a project, it acts like math. You write down a few formulas to transform your data, and you pass stuff back and forth between your various functions. But as the project expands, somewhere along the way it stops acting like math. You start to bump up against the limits of what you can hold in your head, and then you blow right past those limits. And even though your math skills are still relevant for looking at any one particular small part of the puzzle, it turns out you need a different approach when you're worried about hundreds of thousands of lines of code.
The analogy that strikes me most is biology (think of cellular biology). When you're facing certain classes of bugs in systems "of a certain size," the empirical approach just makes more sense. At some point it doesn't matter what you think the system should be doing, you need to actually test it to see how it performs. As you add modules and dependencies, you're relying on a dozen or a hundred or a thousand other developers, and their bugs are now yours. This is the point at which you say something like, "lets try changing the data and see if that solves our problem."
To a computer scientist, that sounds like defeat, surrender, or worse, a lack of rigor. But in my experience at least, the math approach falls on its face after a certain level of complexity. Just as it's impossible to solve even moderately complicated general mathematical equations, programs above a certain size defy clean theoretical solutions. The biological approach however, becomes more and more effective, in comparison.
I'm not trying to give advice here, more just making an observation. Maybe we should be teaching people about the skills they need to manage software that has grown its own eco system, that has its own biology. Or maybe that's what the IT department has been doing all this time, and I only just realized it.
*Computer Science is what professors call programming. Never tell a professor that you're a programmer. You should be a software engineer at the very least.
When you first start a project, it acts like math. You write down a few formulas to transform your data, and you pass stuff back and forth between your various functions. But as the project expands, somewhere along the way it stops acting like math. You start to bump up against the limits of what you can hold in your head, and then you blow right past those limits. And even though your math skills are still relevant for looking at any one particular small part of the puzzle, it turns out you need a different approach when you're worried about hundreds of thousands of lines of code.
The analogy that strikes me most is biology (think of cellular biology). When you're facing certain classes of bugs in systems "of a certain size," the empirical approach just makes more sense. At some point it doesn't matter what you think the system should be doing, you need to actually test it to see how it performs. As you add modules and dependencies, you're relying on a dozen or a hundred or a thousand other developers, and their bugs are now yours. This is the point at which you say something like, "lets try changing the data and see if that solves our problem."
To a computer scientist, that sounds like defeat, surrender, or worse, a lack of rigor. But in my experience at least, the math approach falls on its face after a certain level of complexity. Just as it's impossible to solve even moderately complicated general mathematical equations, programs above a certain size defy clean theoretical solutions. The biological approach however, becomes more and more effective, in comparison.
I'm not trying to give advice here, more just making an observation. Maybe we should be teaching people about the skills they need to manage software that has grown its own eco system, that has its own biology. Or maybe that's what the IT department has been doing all this time, and I only just realized it.
*Computer Science is what professors call programming. Never tell a professor that you're a programmer. You should be a software engineer at the very least.
looming personal crisis
What am I going to do with all this free time? I'm so used to working crunch time that when I'm at home for more than an hour I get restless and uneasy. And now here's a three day weekend. I'm not sure I can cope.
;-)
;-)
Subscribe to:
Posts (Atom)