Senin, 31 Desember 2007
Matematika itu menyenangkan
Anda boleh setuju atau tidak, hasil polling pada blog ini menunjukkan baha ternyata matematika bukanlah pelajaran yang menyeramkan seperti yang diperkirakan. memang masih ada 1/3 responden yang berpikir matematika itu susah, akan tetapi hasil secara keseluruhan menunjukkan bahwa matematika itu mudah/menyenangkan. Mudah-mudahan hasil polling ini dapat semakin mematahkan mitos yang mengatakan
Rabu, 26 Desember 2007
Link di Internet
Berikut ini adalah beberapa link yang cukup menarik dalam bentuk microsoft word :1. Soal Matematika SMA ( klik disini )2. Soal Matematika SMK kelas 10 ( klik disini )3. rpp kelas 11 IPA ( klik disini )4. silabus matematika kelas 10, 11 dam 12 ( klik disini )
Rabu, 19 Desember 2007
Code's Worst Enemy
I'm a programmer, and I'm on vacation today. Guess what I'm doing? As much as I'd love to tell you I'm sipping Mai Tais in the Bahamas, what I'm actually doing on my vacation is programming.
So it's a "vacation" only in the HR sense – I'm taking official time off work, to give myself some free time to get my computer game back online. It's a game I started writing about ten years ago, and spent about seven years developing. It's been offline for a while and I need to bring it back up, in part so the players will stop stalking me. It's going to take me at least a week of all-day days, so I had to take a vacation from work to make it happen.
Why did my game go offline? Not for want of popularity. It's a pretty successful game for a mostly part-time effort from one person. I've had over a quarter million individuals try it out (at least getting as far as creating a character), and tens of thousands of people who've spent countless hours playing it over the years. It's won awards and been featured in magazines; it's attracted the attention of game portals, potential investors, and whole schools full of kids.
Yup, kids. It was supposed to be a game for college students, but it's been surprisingly popular with teenagers and even pre-teens, who you'd think would be off playing some 3D console game or other. But I wrote it for myself, and apparently there are sufficient people who like the same kinds of games I do to create a sustainable community.
I took the game down for all sorts of mundane reasons - it needed some upgrades, work got busy, I didn't have lots of time at nights, etc. But the mundane reasons all really boil down to just one rather deeper problem: the code base is too big for one person to manage.
I've spent nearly ten years of my life building something that's too big.
I've done a lot of thinking about this — more than you would probably guess. It's occupied a large part of my technical thinking for the past four or five years, and has helped shaped everything I've written in that time, both in blogs and in code.
For the rest of this little rant, I'm going to assume that you're a young, intelligent, college age or even high school age student interested in becoming a better programmer, perhaps even a great programmer.
(Please – don't think I'm implying that I'm a great programmer. Far from it. I'm a programmer who's committed decades of terrible coding atrocities, and in the process I've learned some lessons that I'm passing along to you in the hopes that it'll help you in your quest to become a great programmer.)
I have to make the assumption that you're young in order to make my point, because if I assume I'm talking to "experienced" programmers, my blood pressure will rise and I will not be able to focus for long enough to finish my rant. You'll see why in a bit.
Fortunately for me, you're young and eager to learn, so I can tell you how things really are. Just keep your eyes open for the next few years, and watch to see if I'm right.
I happen to hold a hard-won minority opinion about code bases. In particular I believe, quite staunchly I might add, that the worst thing that can happen to a code base is size.
I say "size" as a placeholder for a reasonably well-formed thought for which I seem to have no better word in my vocabulary. I'll have to talk around it until you can see what I mean, and perhaps provide me with a better word for it. The word "bloat" might be more accurate, since everyone knows that "bloat" is bad, but unfortunately most so-called experienced programmers do not know how to detect bloat, and they'll point at severely bloated code bases and claim they're skinny as a rail.
Good thing we're not talking to them, eh?
I say my opinion is hard-won because people don't really talk much about code base size; it's not widely recognized as a problem. In fact it's widely recognized as a non-problem. This means that anyone sharing my minority opinion is considered a borderline lunatic, since what rational person would rant against a non-problem?
People in the industry are very excited about various ideas that nominally help you deal with large code bases, such as IDEs that can manipulate code as "algebraic structures", and search indexes, and so on. These people tend to view code bases much the way construction workers view dirt: they want great big machines that can move the dirt this way and that. There's conservation of dirt at work: you can't compress dirt, not much, so their solution set consists of various ways of shoveling the dirt around. There are even programming interview questions, surely metaphorical, about how you might go about moving an entire mountain of dirt, one truck at a time.
Industry programmers are excited about solutions to a big non-problem. It's just a mountain of dirt, and you just need big tools to move it around. The tools are exciting but the dirt is not.
My minority opinion is that a mountain of code is the worst thing that can befall a person, a team, a company. I believe that code weight wrecks projects and companies, that it forces rewrites after a certain size, and that smart teams will do everything in their power to keep their code base from becoming a mountain. Tools or no tools. That's what I believe.
It turns out you have to have something bad happen to you before you can hold my minority opinion. The bad thing that happened to me is that I wrote a beautiful game in an ugly language, and the result was lovely on the outside and quite horrific internally. The average industry programmer today would not find much wrong with my code base, aside from the missing unit tests (which I now regret) that would, alas, double the size of my game's already massive 500,000-line code base. So the main thing they would find wrong with it is, viewed in a certain way, that it's not big enough. If I'd done things perfectly, according to today's fashions, I'd be even worse off than I am now.
Some people will surely miss my point, so I'll clarify: I think unit testing is great. In fact I think it's critical, and I vastly regret not having unit tests for my game. My point is that I wrote the game the way most experienced programmers would tell you to write that kind of system, and it's now an appallingly unmanageable code base. If I'd done the "right thing" with unit tests, it would be twice appalling! The apparent paradox here is crucial to understanding why I hold my minority belief about code base size.
Most programmers never have anything truly bad happen to them. In the rare cases when something bad happens, they usually don't notice it as a problem, any more than a construction worker notices dirt as a problem. There's just a certain amount of dirt at every site, and you have to deal with it: it's not "bad"; it's just a tactical challenge.
Many companies are faced with multiple million lines of code, and they view it as a simple tools issue, nothing more: lots of dirt that needs to be moved around occasionally.
Most people have never had to maintain a half-million line code base singlehandedly, so their view of things will probably be different from mine. Hopefully you, being the young, eager-to-learn individual that you are, will realize that the only people truly qualified to express opinions on this matter are those who have lived in (and helped create) truly massive code bases.
You may hear some howling in response to my little rant today, and a lot of hand-wavy "he just doesn't understand" dismissiveness. But I posit that the folks making these assertions have simply never been held accountable for the messes they've made.
When you write your own half-million-line code base, you can't dodge accountability. I have nobody to blame but myself, and it's given me a perspective that puts me in the minority.
It's not just from my game, either. That alone might not have taught me the lesson. In my twenty years in the industry, I have hurled myself forcibly against some of the biggest code bases you've ever imagined, and in doing so I've learned a few things that most people never learn, not in their whole career. I'm not asking you to make up your mind on the matter today. I just hope you'll keep your eyes and ears open as you code for the next few years.
I'm going to try to define bloat here. I know in advance that I'll fail, but hopefully just sketching out the problem will etch out some patterns for you.
There are some things that can go wrong with code bases that have a nice intuitive appeal to them, inasmuch as it's not difficult for most people to agree that they're "bad".
One such thing is complexity. Nobody likes a complex code base. One measure of complexity that people sometimes use is "cyclomatic complexity", which estimates the possible runtime paths through a given function using a simple static analysis of the code structure.
I'm pretty sure that I don't like complex code bases, but I'm not convinced that cyclomatic complexity measurements have helped. To get a good cyclomatic complexity score, you just need to break your code up into smaller functions. Breaking your code into smaller functions has been a staple of "good design" for at least ten years now, in no small part due to the book Refactoring by Martin Fowler.
The problem with Refactoring as applied to languages like Java, and this is really quite central to my thesis today, is that Refactoring makes the code base larger. I'd estimate that fewer than 5% of the standard refactorings supported by IDEs today make the code smaller. Refactoring is like cleaning your closet without being allowed to throw anything away. If you get a bigger closet, and put everything into nice labeled boxes, then your closet will unquestionably be more organized. But programmers tend to overlook the fact that spring cleaning works best when you're willing to throw away stuff you don't need.
This brings us to the second obviously-bad thing that can go wrong with code bases: copy and paste. It doesn't take very long for programmers to learn this lesson the hard way. It's not so much a rule you have to memorize as a scar you're going to get whether you like it or not. Computers make copy-and-paste really easy, so every programmer falls into the trap once in a while. The lesson you eventually learn is that code always changes, always always always, and as soon as you have to change the same thing in N places, where N is more than 1, you'll have earned your scar.
However, copy-and-paste is far more insidious than most scarred industry programmers ever suspect. The core problem is duplication, and unfortunately there are patterns of duplication that cannot be eradicated from Java code. These duplication patterns are everywhere in Java; they're ubiquitous, but Java programmers quickly lose the ability to see them at all.
Java programmers often wonder why Martin Fowler "left" Java to go to Ruby. Although I don't know Martin, I think it's safe to speculate that "something bad" happened to him while using Java. Amusingly (for everyone except perhaps Martin himself), I think that his "something bad" may well have been the act of creating the book Refactoring, which showed Java programmers how to make their closets bigger and more organized, while showing Martin that he really wanted more stuff in a nice, comfortable, closet-sized closet.
Martin, am I wrong?
As I predicted would happen, I haven't yet defined bloat except in the vaguest terms. Why is my game code base half a million lines of code? What is all that code doing?
The other seminal industry book in software design was Design Patterns, which left a mark the width of a two-by-four on the faces of every programmer in the world, assuming the world contains only Java and C++ programmers, which they often do.
Design Patterns was a mid-1990s book that provided twenty-three fancy new boxes for organizing your closet, plus an extensibility mechanism for defining new types of boxes. It was really great for those of us who were trying to organize jam-packed closets with almost no boxes, bags, shelves or drawers. All we had to do was remodel our houses to make the closets four times bigger, and suddenly we could make them as clean as a Nordstrom merchandise rack.
Interestingly, sales people didn't get excited about Design Patterns. Nor did PMs, nor marketing folks, nor even engineering managers. The only people who routinely get excited about Design Patterns are programmers, and only programmers who use certain languages. Perl programmers were, by and large, not very impressed with Design Patterns. However, Java programmers misattributed this; they concluded that Perl programmers must be slovenly, no good bachelors who pile laundry in their closests up to the ceiling.
It's obvious now, though, isn't it? A design pattern isn't a feature. A Factory isn't a feature, nor is a Delegate nor a Proxy nor a Bridge. They "enable" features in a very loose sense, by providing nice boxes to hold the features in. But boxes and bags and shelves take space. And design patterns – at least most of the patterns in the "Gang of Four" book – make code bases get bigger. Tragically, the only GoF pattern that can help code get smaller (Interpreter) is utterly ignored by programmers who otherwise have the names of Design Patterns tatooed on their various body parts.
Dependency Injection is an example of a popular new Java design pattern that programmers using Ruby, Python, Perl and JavaScript have probably never heard of. And if they've heard of it, they've probably (correctly) concluded that they don't need it. Dependency Injection is an amazingly elaborate infrastructure for making Java more dynamic in certain ways that are intrinsic to higher-level languages. And – you guessed it – DI makes your Java code base bigger.
Bigger is just something you have to live with in Java. Growth is a fact of life. Java is like a variant of the game of Tetris in which none of the pieces can fill gaps created by the other pieces, so all you can do is pile them up endlessly.
I recently had the opportunity to watch a self-professed Java programmer give a presentation in which one slide listed Problems (with his current Java system) and the next slide listed Requirements (for the wonderful new vaporware system). The #1 problem he listed was code size: his system has millions of lines of code.
Wow! I've sure seen that before, and I could really empathize with him. Geoworks had well over ten million lines of assembly code, and I'm of the opinion that this helped bankrupt them (although that also appears to be a minority opinion – those industry programmers just never learn!) And I worked at Amazon for seven years; they have well over a hundred million lines of code in various languages, and "complexity" is frequently cited internally as their worst technical problem.
So I was really glad to see that this guy had listed code size as his #1 problem.
Then I got my surprise. He went on to his Requirements slide, on which he listed "must scale to millions of lines of code" as a requirement. Everyone in the room except me just nodded and accepted this requirement. I was floored.
Why on earth would you list your #1 problem as a requirement for the new system? I mean, when you're spelling out requirements, generally you try to solve problems rather than assume they're going to be created again. So I stopped the speaker and asked him what the heck he was thinking.
His answer was: well, his system has lots of features, and more features means more code, so millions of lines are Simply Inevitable. "It's not that Java is verbose!" he added – which is pretty funny, all things considered, since I hadn't said anything about Java or verbosity in my question.
The thing is, if you're just staring in shock at this story and thinking "how could that Java guy be so blind", you are officially a minority in the programming world. An unwelcome one, at that.
Most programmers have successfully compartmentalized their beliefs about code base size. Java programmers are unusually severe offenders but are by no means the only ones. In one compartment, they know big code bases are bad. It only takes grade-school arithmetic to appreciate just how bad they can be. If you have a million lines of code, at 50 lines per "page", that's 20,000 pages of code. How long would it take you to read a 20,000-page instruction manual? The effort to simply browse the code base and try to discern its overall structure could take weeks or even months, depending on its density. Significant architectural changes could take months or even years.
In the other compartment, they think their IDE makes the code size a non-issue. We'll get to that shortly.
And a million lines is nothing, really. Most companies would love to have merely a million lines of code. Often a single team can wind up with that much after a couple years of hacking. Big companies these days are pushing tens to hundreds of millions of lines around.
I'll give you the capsule synopsis, the one-sentence summary of the learnings I had from the Bad Thing that happened to me while writing my game in Java: if you begin with the assumption that you need to shrink your code base, you will eventually be forced to conclude that you cannot continue to use Java. Conversely, if you begin with the assumption that you must use Java, then you will eventually be forced to conclude that you will have millions of lines of code.
Is it worth the trade-off? Java programmers will tell you Yes, it's worth it. By doing so they're tacitly nodding to their little compartment that realizes big code bases are bad, so you've at least won that battle.
But you should take anything a "Java programmer" tells you with a hefty grain of salt, because an "X programmer", for any value of X, is a weak player. You have to cross-train to be a decent athlete these days. Programmers need to be fluent in multiple languages with fundamentally different "character" before they can make truly informed design decisions.
Recently I've been finding that Java is an especially bad value for X. If you absolutely must hire an X programmer, make sure it's Y.
I didn't really set out to focus this rant on Java (and Java clones like C#, which despite now being a "better" language still has Java's fundamental character, making it only a marginal win at best.) To be sure, my minority opinion applies to any code base in any language. Bloat is bad.
But I find myself focusing on Java because I have this enormous elephant of a code base that I'm trying to revive this week. Can you blame me? Hopefully someone with a pet C++ elephant can come along and jump on the minority bandwagon with me. For now, though, I'll try to finish my explanation of bloat as a bona-fide problem using Java for context.
The Java community believes, with near 100% Belief Compliance, that modern IDEs make code base size a non-issue. End of story.
There are several problems with this perspective. One is simple arithmetic again: given enough code, you eventually run out of machine resources for managing the code. Imagine a project with a billion lines of code, and then imagine trying to use Eclipse or IntelliJ on that project. The machines – CPU, memory, disk, network – would simply give up. We know this because twenty-million line code bases are already moving beyond the grasp of modern IDEs on modern machines.
Heck, I've never managed to get Eclipse to pull in and index even my 500,000-line code base, and I've spent weeks trying. It just falls over, paralyzed. It literally hangs forever (I can leave it overnight and it makes no progress.) Twenty million lines? Forget about it.
It may be possible to mitigate the problem by moving the code base management off the local machine and onto server clusters. But the core problem is really more cultural than technical: as long as IDE users refuse to admit there is a problem, it's not going to get solved.
Going back to our crazed Tetris game, imagine that you have a tool that lets you manage huge Tetris screens that are hundreds of stories high. In this scenario, stacking the pieces isn't a problem, so there's no need to be able to eliminate pieces. This is the cultural problem: they don't realize they're not actually playing the right game anymore.
The second difficulty with the IDE perspective is that Java-style IDEs intrinsically create a circular problem. The circularity stems from the nature of programming languages: the "game piece" shapes are determined by the language's static type system. Java's game pieces don't permit code elimination because Java's static type system doesn't have any compression facilities – no macros, no lambdas, no declarative data structures, no templates, nothing that would permit the removal of the copy-and-paste duplication patterns that Java programmers think of as "inevitable boilerplate", but which are in fact easily factored out in dynamic languages.
Completing the circle, dynamic features make it more difficult for IDEs to work their static code-base-management magic. IDEs don't work as well with dynamic code features, so IDEs are responsible for encouraging the use of languages that require... IDEs. Ouch.
Java programmers understand this at some level; for instance, Java's popular reflection facility, which allows you to construct method names on the fly and invoke those methods by name, defeats an IDE's ability to perform basic refactorings such as Rename Method. But because of successful compartmentalization, Java folks point at dynamic languages and howl that (some) automated refactorings aren't possible, when in fact they're just as possible in these languages as they are in Java – which is to say, they're partly possible. The refactorings will "miss" to the extent that you're using dynamic facilities, whether you're writing in Java or any other language. Refactorings are essentially never 100% effective, especially as the code base is shipped offsite with public APIs: this is precisely why Java has a deprecation facility. You can't rename a method on everyone's machine in the world. But Java folks continue spouting the provably false belief that automated refactorings work on "all" their code.
I'll bet that by now you're just as glad as I am that we're not talking to Java programmers right now! Now that I've demonstrated one way (of many) in which they're utterly irrational, it should be pretty clear that their response isn't likely to be a rational one.
The rational response would be to take a very big step back, put all development on hold, and ask a difficult question: "what should I be using instead of Java?"
I did that about four years ago. That's when I stopped working on my game, putting it into maintenance mode. I wanted to rewrite it down to, say, 100,000 to 150,000 lines, somewhere in that vicinity, with the exact same functionality.
It took me six months to realize it can't be done with Java, not even with the stuff they added to Java 5, and not even with the stuff they're planning for Java 7 (even if they add the cool stuff, like non-broken closures, that the Java community is resisting tooth and nail.)
It can't be done with Java. But I do have a big investment in the Java virtual machine, for basically the same reason that Microsoft now has a big investment in .NET. Virtual machines make sense to me now. I mean, they "made sense" at some superficial level when I read the marketing brochures, but now that I've written a few interpreters and have dug into native-code compilers, they make a lot more sense. It's another rant as to why, unfortunately.
So taking for granted today that VMs are "good", and acknowledging that my game is pretty heavily tied to the JVM – not just for the extensive libraries and monitoring tools, but also for more subtle architectural decisions like the threading and memory models – the rational answer to code bloat is to use another JVM language.
One nice thing about JVM languages is that Java programmers can learn them pretty fast, because you get all the libraries, monitoring tools and architectural decisions for free. The downside is that most Java programmers are X programmers, and, as I said, you don't want X programmers on your team.
But since you're not one of those people who've decided to wear bell-bottom polyester pants until the day you die, even should you live unto five hundred years, you're open to language suggestions. Good for you!
Three years ago, I set out to figure out which JVM language would be the best code-compressing successor to Java. That took a lot longer than I expected, and the answer was far less satisfactory than I'd anticipated. Even now, three years later, the answer is still a year or two away from being really compelling.
I'm patient now, though, so after all the dust settles, I know I've got approximately a two-year window during which today's die-hard Java programmers are writing their next multi-million line disaster. Right about the time they're putting together their next Problems/Requirements slide, I think I'll actually have an answer for them.
In the meantime, I'm hoping that I'll have found time to rewrite my game in this language, down from 500,000 lines to 150,000 lines with the exact same functionality (plus at least another 50k+ for unit tests.)
So what JVM language is going to be the Next Java?
Well, if you're going for pure code compression, you really want a Lisp dialect: Common Lisp or Scheme. And there are some very good JVM implementations out there. I've used them. Unfortunately, a JVM language has to be a drop-in replacement for Java (otherwise a port is going to be a real logistics problem), and none of the Lisp/Scheme implementors seems to have that very high on their priority list.
Plus everyone will spit on you. People who don't habitually spit will expectorate up to thirty feet, like zoo camels, in order to bespittle you if you even suggest the possibility of using a Lisp or Scheme dialect at your company.
So it's not gonna be Lisp or Scheme. We'll have to sacrifice some compression for something a bit more syntactically mainstream.
It could theoretically be Perl 6, provided the Parrot folks ever actually get their stuff working, but they're even more patient than I am, if you get my drift. Perl 6 really is a pretty nice language design, for the record – I was really infatuated with it back in 2001. The love affair died about five years ago, though. And Perl 6 probably won't ever run on the JVM. It's too dependent on powerful Parrot features that the JVM will never support. (I'd venture that Parrot probably won't ever support them either, but that would be mean.)
Most likely New Java is going to be an already reasonably popular language with a very good port to the JVM. It'll be a language with a dedicated development team and a great marketing department.
That narrows the field from 200+ languages down to maybe three or four: JRuby, Groovy, Rhino (JavaScript), and maybe Jython if it comes out of its coma.
Each of these languages (as does Perl 6) provides mechanisms that would permit compression of a well-engineered 500,000-line Java code base by 50% to 75%. Exactly where the dart lands (between 50% and 75%) remains to be seen, but I'm going to try it myself.
I personally tried Groovy and found it to be an ugly language with a couple of decent ideas. It wants to be Ruby but lacks Ruby's elegance (or Python's for that matter). It's been around a long time and does not seem to be gaining any momentum, so I've ruled it out for my own work. (And I mean permanently – I will not look at it again. Groovy's implementation bugs have really burned me.)
I like Ruby and Python a lot, but neither JVM version was up to snuff when I did my evaluation three years ago. JRuby has had a lot of work done to it in the meantime. If the people I work with weren't so dead-set against Ruby, I'd probably go with that, and hope like hell that the implementation is eventually "fast enough" relative to Java.
As it happens, though, I've settled on Rhino. I'll be working with the Rhino dev team to help bring it up to spec with EcmaScript Edition 4. I believe that ES4 brings JavaScript to rough parity with Ruby and Python in terms of (a) expressiveness and (b) the ability to structure and manage larger code bases. Anything it lacks in sugar, it more than makes up for with its optional type annotations. And I think JavaScript (especially on ES4 steroids) is an easier sell than Ruby or Python to people who like curly braces, which is anyone currently using C++, Java, C#, JavaScript or Perl. That's a whooole lot of curly brace lovers. I'm nothing if not practical these days.
I don't expect today's little rant to convince anyone to share my minority opinion about code base size. I know a that few key folks (Bill Gates, for instance, as well as Dave Thomas, Martin Fowler and James Duncan Davidson) have independently reached the same conclusion: namely, that bloat is the worst thing that can happen to code. But they all got there via painful things happening to them.
I can't exactly wish for something painful to happen to Java developers, since hey, it's already happening; they've already taught themselves to pretend it's not hurting them.
But as for you, the eager young high school or college student who wants to become a great programmer someday, hopefully I've given you an extra dimension to observe as your tend your code gardens for the next few years.
When you're ready to make the switch, well, Mozilla Rhino will be ready for you. It works great today and will be absolutely outstanding a year from now. And I sincerely hope that JRuby, Jython and friends will also be viable Java alternatives for you as well. You might even try them out now and see how it goes.
Your code base will thank you for it.
So it's a "vacation" only in the HR sense – I'm taking official time off work, to give myself some free time to get my computer game back online. It's a game I started writing about ten years ago, and spent about seven years developing. It's been offline for a while and I need to bring it back up, in part so the players will stop stalking me. It's going to take me at least a week of all-day days, so I had to take a vacation from work to make it happen.
Why did my game go offline? Not for want of popularity. It's a pretty successful game for a mostly part-time effort from one person. I've had over a quarter million individuals try it out (at least getting as far as creating a character), and tens of thousands of people who've spent countless hours playing it over the years. It's won awards and been featured in magazines; it's attracted the attention of game portals, potential investors, and whole schools full of kids.
Yup, kids. It was supposed to be a game for college students, but it's been surprisingly popular with teenagers and even pre-teens, who you'd think would be off playing some 3D console game or other. But I wrote it for myself, and apparently there are sufficient people who like the same kinds of games I do to create a sustainable community.
I took the game down for all sorts of mundane reasons - it needed some upgrades, work got busy, I didn't have lots of time at nights, etc. But the mundane reasons all really boil down to just one rather deeper problem: the code base is too big for one person to manage.
I've spent nearly ten years of my life building something that's too big.
I've done a lot of thinking about this — more than you would probably guess. It's occupied a large part of my technical thinking for the past four or five years, and has helped shaped everything I've written in that time, both in blogs and in code.
For the rest of this little rant, I'm going to assume that you're a young, intelligent, college age or even high school age student interested in becoming a better programmer, perhaps even a great programmer.
(Please – don't think I'm implying that I'm a great programmer. Far from it. I'm a programmer who's committed decades of terrible coding atrocities, and in the process I've learned some lessons that I'm passing along to you in the hopes that it'll help you in your quest to become a great programmer.)
I have to make the assumption that you're young in order to make my point, because if I assume I'm talking to "experienced" programmers, my blood pressure will rise and I will not be able to focus for long enough to finish my rant. You'll see why in a bit.
Fortunately for me, you're young and eager to learn, so I can tell you how things really are. Just keep your eyes open for the next few years, and watch to see if I'm right.
Minority View
I happen to hold a hard-won minority opinion about code bases. In particular I believe, quite staunchly I might add, that the worst thing that can happen to a code base is size.
I say "size" as a placeholder for a reasonably well-formed thought for which I seem to have no better word in my vocabulary. I'll have to talk around it until you can see what I mean, and perhaps provide me with a better word for it. The word "bloat" might be more accurate, since everyone knows that "bloat" is bad, but unfortunately most so-called experienced programmers do not know how to detect bloat, and they'll point at severely bloated code bases and claim they're skinny as a rail.
Good thing we're not talking to them, eh?
I say my opinion is hard-won because people don't really talk much about code base size; it's not widely recognized as a problem. In fact it's widely recognized as a non-problem. This means that anyone sharing my minority opinion is considered a borderline lunatic, since what rational person would rant against a non-problem?
People in the industry are very excited about various ideas that nominally help you deal with large code bases, such as IDEs that can manipulate code as "algebraic structures", and search indexes, and so on. These people tend to view code bases much the way construction workers view dirt: they want great big machines that can move the dirt this way and that. There's conservation of dirt at work: you can't compress dirt, not much, so their solution set consists of various ways of shoveling the dirt around. There are even programming interview questions, surely metaphorical, about how you might go about moving an entire mountain of dirt, one truck at a time.
Industry programmers are excited about solutions to a big non-problem. It's just a mountain of dirt, and you just need big tools to move it around. The tools are exciting but the dirt is not.
My minority opinion is that a mountain of code is the worst thing that can befall a person, a team, a company. I believe that code weight wrecks projects and companies, that it forces rewrites after a certain size, and that smart teams will do everything in their power to keep their code base from becoming a mountain. Tools or no tools. That's what I believe.
It turns out you have to have something bad happen to you before you can hold my minority opinion. The bad thing that happened to me is that I wrote a beautiful game in an ugly language, and the result was lovely on the outside and quite horrific internally. The average industry programmer today would not find much wrong with my code base, aside from the missing unit tests (which I now regret) that would, alas, double the size of my game's already massive 500,000-line code base. So the main thing they would find wrong with it is, viewed in a certain way, that it's not big enough. If I'd done things perfectly, according to today's fashions, I'd be even worse off than I am now.
Some people will surely miss my point, so I'll clarify: I think unit testing is great. In fact I think it's critical, and I vastly regret not having unit tests for my game. My point is that I wrote the game the way most experienced programmers would tell you to write that kind of system, and it's now an appallingly unmanageable code base. If I'd done the "right thing" with unit tests, it would be twice appalling! The apparent paradox here is crucial to understanding why I hold my minority belief about code base size.
Most programmers never have anything truly bad happen to them. In the rare cases when something bad happens, they usually don't notice it as a problem, any more than a construction worker notices dirt as a problem. There's just a certain amount of dirt at every site, and you have to deal with it: it's not "bad"; it's just a tactical challenge.
Many companies are faced with multiple million lines of code, and they view it as a simple tools issue, nothing more: lots of dirt that needs to be moved around occasionally.
Most people have never had to maintain a half-million line code base singlehandedly, so their view of things will probably be different from mine. Hopefully you, being the young, eager-to-learn individual that you are, will realize that the only people truly qualified to express opinions on this matter are those who have lived in (and helped create) truly massive code bases.
You may hear some howling in response to my little rant today, and a lot of hand-wavy "he just doesn't understand" dismissiveness. But I posit that the folks making these assertions have simply never been held accountable for the messes they've made.
When you write your own half-million-line code base, you can't dodge accountability. I have nobody to blame but myself, and it's given me a perspective that puts me in the minority.
It's not just from my game, either. That alone might not have taught me the lesson. In my twenty years in the industry, I have hurled myself forcibly against some of the biggest code bases you've ever imagined, and in doing so I've learned a few things that most people never learn, not in their whole career. I'm not asking you to make up your mind on the matter today. I just hope you'll keep your eyes and ears open as you code for the next few years.
Invisible Bloat
I'm going to try to define bloat here. I know in advance that I'll fail, but hopefully just sketching out the problem will etch out some patterns for you.
There are some things that can go wrong with code bases that have a nice intuitive appeal to them, inasmuch as it's not difficult for most people to agree that they're "bad".
One such thing is complexity. Nobody likes a complex code base. One measure of complexity that people sometimes use is "cyclomatic complexity", which estimates the possible runtime paths through a given function using a simple static analysis of the code structure.
I'm pretty sure that I don't like complex code bases, but I'm not convinced that cyclomatic complexity measurements have helped. To get a good cyclomatic complexity score, you just need to break your code up into smaller functions. Breaking your code into smaller functions has been a staple of "good design" for at least ten years now, in no small part due to the book Refactoring by Martin Fowler.
The problem with Refactoring as applied to languages like Java, and this is really quite central to my thesis today, is that Refactoring makes the code base larger. I'd estimate that fewer than 5% of the standard refactorings supported by IDEs today make the code smaller. Refactoring is like cleaning your closet without being allowed to throw anything away. If you get a bigger closet, and put everything into nice labeled boxes, then your closet will unquestionably be more organized. But programmers tend to overlook the fact that spring cleaning works best when you're willing to throw away stuff you don't need.
This brings us to the second obviously-bad thing that can go wrong with code bases: copy and paste. It doesn't take very long for programmers to learn this lesson the hard way. It's not so much a rule you have to memorize as a scar you're going to get whether you like it or not. Computers make copy-and-paste really easy, so every programmer falls into the trap once in a while. The lesson you eventually learn is that code always changes, always always always, and as soon as you have to change the same thing in N places, where N is more than 1, you'll have earned your scar.
However, copy-and-paste is far more insidious than most scarred industry programmers ever suspect. The core problem is duplication, and unfortunately there are patterns of duplication that cannot be eradicated from Java code. These duplication patterns are everywhere in Java; they're ubiquitous, but Java programmers quickly lose the ability to see them at all.
Java programmers often wonder why Martin Fowler "left" Java to go to Ruby. Although I don't know Martin, I think it's safe to speculate that "something bad" happened to him while using Java. Amusingly (for everyone except perhaps Martin himself), I think that his "something bad" may well have been the act of creating the book Refactoring, which showed Java programmers how to make their closets bigger and more organized, while showing Martin that he really wanted more stuff in a nice, comfortable, closet-sized closet.
Martin, am I wrong?
As I predicted would happen, I haven't yet defined bloat except in the vaguest terms. Why is my game code base half a million lines of code? What is all that code doing?
Design Patterns Are Not Features
The other seminal industry book in software design was Design Patterns, which left a mark the width of a two-by-four on the faces of every programmer in the world, assuming the world contains only Java and C++ programmers, which they often do.
Design Patterns was a mid-1990s book that provided twenty-three fancy new boxes for organizing your closet, plus an extensibility mechanism for defining new types of boxes. It was really great for those of us who were trying to organize jam-packed closets with almost no boxes, bags, shelves or drawers. All we had to do was remodel our houses to make the closets four times bigger, and suddenly we could make them as clean as a Nordstrom merchandise rack.
Interestingly, sales people didn't get excited about Design Patterns. Nor did PMs, nor marketing folks, nor even engineering managers. The only people who routinely get excited about Design Patterns are programmers, and only programmers who use certain languages. Perl programmers were, by and large, not very impressed with Design Patterns. However, Java programmers misattributed this; they concluded that Perl programmers must be slovenly, no good bachelors who pile laundry in their closests up to the ceiling.
It's obvious now, though, isn't it? A design pattern isn't a feature. A Factory isn't a feature, nor is a Delegate nor a Proxy nor a Bridge. They "enable" features in a very loose sense, by providing nice boxes to hold the features in. But boxes and bags and shelves take space. And design patterns – at least most of the patterns in the "Gang of Four" book – make code bases get bigger. Tragically, the only GoF pattern that can help code get smaller (Interpreter) is utterly ignored by programmers who otherwise have the names of Design Patterns tatooed on their various body parts.
Dependency Injection is an example of a popular new Java design pattern that programmers using Ruby, Python, Perl and JavaScript have probably never heard of. And if they've heard of it, they've probably (correctly) concluded that they don't need it. Dependency Injection is an amazingly elaborate infrastructure for making Java more dynamic in certain ways that are intrinsic to higher-level languages. And – you guessed it – DI makes your Java code base bigger.
Bigger is just something you have to live with in Java. Growth is a fact of life. Java is like a variant of the game of Tetris in which none of the pieces can fill gaps created by the other pieces, so all you can do is pile them up endlessly.
Millions of Lines of Code
I recently had the opportunity to watch a self-professed Java programmer give a presentation in which one slide listed Problems (with his current Java system) and the next slide listed Requirements (for the wonderful new vaporware system). The #1 problem he listed was code size: his system has millions of lines of code.
Wow! I've sure seen that before, and I could really empathize with him. Geoworks had well over ten million lines of assembly code, and I'm of the opinion that this helped bankrupt them (although that also appears to be a minority opinion – those industry programmers just never learn!) And I worked at Amazon for seven years; they have well over a hundred million lines of code in various languages, and "complexity" is frequently cited internally as their worst technical problem.
So I was really glad to see that this guy had listed code size as his #1 problem.
Then I got my surprise. He went on to his Requirements slide, on which he listed "must scale to millions of lines of code" as a requirement. Everyone in the room except me just nodded and accepted this requirement. I was floored.
Why on earth would you list your #1 problem as a requirement for the new system? I mean, when you're spelling out requirements, generally you try to solve problems rather than assume they're going to be created again. So I stopped the speaker and asked him what the heck he was thinking.
His answer was: well, his system has lots of features, and more features means more code, so millions of lines are Simply Inevitable. "It's not that Java is verbose!" he added – which is pretty funny, all things considered, since I hadn't said anything about Java or verbosity in my question.
The thing is, if you're just staring in shock at this story and thinking "how could that Java guy be so blind", you are officially a minority in the programming world. An unwelcome one, at that.
Most programmers have successfully compartmentalized their beliefs about code base size. Java programmers are unusually severe offenders but are by no means the only ones. In one compartment, they know big code bases are bad. It only takes grade-school arithmetic to appreciate just how bad they can be. If you have a million lines of code, at 50 lines per "page", that's 20,000 pages of code. How long would it take you to read a 20,000-page instruction manual? The effort to simply browse the code base and try to discern its overall structure could take weeks or even months, depending on its density. Significant architectural changes could take months or even years.
In the other compartment, they think their IDE makes the code size a non-issue. We'll get to that shortly.
And a million lines is nothing, really. Most companies would love to have merely a million lines of code. Often a single team can wind up with that much after a couple years of hacking. Big companies these days are pushing tens to hundreds of millions of lines around.
I'll give you the capsule synopsis, the one-sentence summary of the learnings I had from the Bad Thing that happened to me while writing my game in Java: if you begin with the assumption that you need to shrink your code base, you will eventually be forced to conclude that you cannot continue to use Java. Conversely, if you begin with the assumption that you must use Java, then you will eventually be forced to conclude that you will have millions of lines of code.
Is it worth the trade-off? Java programmers will tell you Yes, it's worth it. By doing so they're tacitly nodding to their little compartment that realizes big code bases are bad, so you've at least won that battle.
But you should take anything a "Java programmer" tells you with a hefty grain of salt, because an "X programmer", for any value of X, is a weak player. You have to cross-train to be a decent athlete these days. Programmers need to be fluent in multiple languages with fundamentally different "character" before they can make truly informed design decisions.
Recently I've been finding that Java is an especially bad value for X. If you absolutely must hire an X programmer, make sure it's Y.
I didn't really set out to focus this rant on Java (and Java clones like C#, which despite now being a "better" language still has Java's fundamental character, making it only a marginal win at best.) To be sure, my minority opinion applies to any code base in any language. Bloat is bad.
But I find myself focusing on Java because I have this enormous elephant of a code base that I'm trying to revive this week. Can you blame me? Hopefully someone with a pet C++ elephant can come along and jump on the minority bandwagon with me. For now, though, I'll try to finish my explanation of bloat as a bona-fide problem using Java for context.
Can IDEs Save You?
The Java community believes, with near 100% Belief Compliance, that modern IDEs make code base size a non-issue. End of story.
There are several problems with this perspective. One is simple arithmetic again: given enough code, you eventually run out of machine resources for managing the code. Imagine a project with a billion lines of code, and then imagine trying to use Eclipse or IntelliJ on that project. The machines – CPU, memory, disk, network – would simply give up. We know this because twenty-million line code bases are already moving beyond the grasp of modern IDEs on modern machines.
Heck, I've never managed to get Eclipse to pull in and index even my 500,000-line code base, and I've spent weeks trying. It just falls over, paralyzed. It literally hangs forever (I can leave it overnight and it makes no progress.) Twenty million lines? Forget about it.
It may be possible to mitigate the problem by moving the code base management off the local machine and onto server clusters. But the core problem is really more cultural than technical: as long as IDE users refuse to admit there is a problem, it's not going to get solved.
Going back to our crazed Tetris game, imagine that you have a tool that lets you manage huge Tetris screens that are hundreds of stories high. In this scenario, stacking the pieces isn't a problem, so there's no need to be able to eliminate pieces. This is the cultural problem: they don't realize they're not actually playing the right game anymore.
The second difficulty with the IDE perspective is that Java-style IDEs intrinsically create a circular problem. The circularity stems from the nature of programming languages: the "game piece" shapes are determined by the language's static type system. Java's game pieces don't permit code elimination because Java's static type system doesn't have any compression facilities – no macros, no lambdas, no declarative data structures, no templates, nothing that would permit the removal of the copy-and-paste duplication patterns that Java programmers think of as "inevitable boilerplate", but which are in fact easily factored out in dynamic languages.
Completing the circle, dynamic features make it more difficult for IDEs to work their static code-base-management magic. IDEs don't work as well with dynamic code features, so IDEs are responsible for encouraging the use of languages that require... IDEs. Ouch.
Java programmers understand this at some level; for instance, Java's popular reflection facility, which allows you to construct method names on the fly and invoke those methods by name, defeats an IDE's ability to perform basic refactorings such as Rename Method. But because of successful compartmentalization, Java folks point at dynamic languages and howl that (some) automated refactorings aren't possible, when in fact they're just as possible in these languages as they are in Java – which is to say, they're partly possible. The refactorings will "miss" to the extent that you're using dynamic facilities, whether you're writing in Java or any other language. Refactorings are essentially never 100% effective, especially as the code base is shipped offsite with public APIs: this is precisely why Java has a deprecation facility. You can't rename a method on everyone's machine in the world. But Java folks continue spouting the provably false belief that automated refactorings work on "all" their code.
I'll bet that by now you're just as glad as I am that we're not talking to Java programmers right now! Now that I've demonstrated one way (of many) in which they're utterly irrational, it should be pretty clear that their response isn't likely to be a rational one.
Rational Code Size
The rational response would be to take a very big step back, put all development on hold, and ask a difficult question: "what should I be using instead of Java?"
I did that about four years ago. That's when I stopped working on my game, putting it into maintenance mode. I wanted to rewrite it down to, say, 100,000 to 150,000 lines, somewhere in that vicinity, with the exact same functionality.
It took me six months to realize it can't be done with Java, not even with the stuff they added to Java 5, and not even with the stuff they're planning for Java 7 (even if they add the cool stuff, like non-broken closures, that the Java community is resisting tooth and nail.)
It can't be done with Java. But I do have a big investment in the Java virtual machine, for basically the same reason that Microsoft now has a big investment in .NET. Virtual machines make sense to me now. I mean, they "made sense" at some superficial level when I read the marketing brochures, but now that I've written a few interpreters and have dug into native-code compilers, they make a lot more sense. It's another rant as to why, unfortunately.
So taking for granted today that VMs are "good", and acknowledging that my game is pretty heavily tied to the JVM – not just for the extensive libraries and monitoring tools, but also for more subtle architectural decisions like the threading and memory models – the rational answer to code bloat is to use another JVM language.
One nice thing about JVM languages is that Java programmers can learn them pretty fast, because you get all the libraries, monitoring tools and architectural decisions for free. The downside is that most Java programmers are X programmers, and, as I said, you don't want X programmers on your team.
But since you're not one of those people who've decided to wear bell-bottom polyester pants until the day you die, even should you live unto five hundred years, you're open to language suggestions. Good for you!
Three years ago, I set out to figure out which JVM language would be the best code-compressing successor to Java. That took a lot longer than I expected, and the answer was far less satisfactory than I'd anticipated. Even now, three years later, the answer is still a year or two away from being really compelling.
I'm patient now, though, so after all the dust settles, I know I've got approximately a two-year window during which today's die-hard Java programmers are writing their next multi-million line disaster. Right about the time they're putting together their next Problems/Requirements slide, I think I'll actually have an answer for them.
In the meantime, I'm hoping that I'll have found time to rewrite my game in this language, down from 500,000 lines to 150,000 lines with the exact same functionality (plus at least another 50k+ for unit tests.)
The Next Java
So what JVM language is going to be the Next Java?
Well, if you're going for pure code compression, you really want a Lisp dialect: Common Lisp or Scheme. And there are some very good JVM implementations out there. I've used them. Unfortunately, a JVM language has to be a drop-in replacement for Java (otherwise a port is going to be a real logistics problem), and none of the Lisp/Scheme implementors seems to have that very high on their priority list.
Plus everyone will spit on you. People who don't habitually spit will expectorate up to thirty feet, like zoo camels, in order to bespittle you if you even suggest the possibility of using a Lisp or Scheme dialect at your company.
So it's not gonna be Lisp or Scheme. We'll have to sacrifice some compression for something a bit more syntactically mainstream.
It could theoretically be Perl 6, provided the Parrot folks ever actually get their stuff working, but they're even more patient than I am, if you get my drift. Perl 6 really is a pretty nice language design, for the record – I was really infatuated with it back in 2001. The love affair died about five years ago, though. And Perl 6 probably won't ever run on the JVM. It's too dependent on powerful Parrot features that the JVM will never support. (I'd venture that Parrot probably won't ever support them either, but that would be mean.)
Most likely New Java is going to be an already reasonably popular language with a very good port to the JVM. It'll be a language with a dedicated development team and a great marketing department.
That narrows the field from 200+ languages down to maybe three or four: JRuby, Groovy, Rhino (JavaScript), and maybe Jython if it comes out of its coma.
Each of these languages (as does Perl 6) provides mechanisms that would permit compression of a well-engineered 500,000-line Java code base by 50% to 75%. Exactly where the dart lands (between 50% and 75%) remains to be seen, but I'm going to try it myself.
I personally tried Groovy and found it to be an ugly language with a couple of decent ideas. It wants to be Ruby but lacks Ruby's elegance (or Python's for that matter). It's been around a long time and does not seem to be gaining any momentum, so I've ruled it out for my own work. (And I mean permanently – I will not look at it again. Groovy's implementation bugs have really burned me.)
I like Ruby and Python a lot, but neither JVM version was up to snuff when I did my evaluation three years ago. JRuby has had a lot of work done to it in the meantime. If the people I work with weren't so dead-set against Ruby, I'd probably go with that, and hope like hell that the implementation is eventually "fast enough" relative to Java.
As it happens, though, I've settled on Rhino. I'll be working with the Rhino dev team to help bring it up to spec with EcmaScript Edition 4. I believe that ES4 brings JavaScript to rough parity with Ruby and Python in terms of (a) expressiveness and (b) the ability to structure and manage larger code bases. Anything it lacks in sugar, it more than makes up for with its optional type annotations. And I think JavaScript (especially on ES4 steroids) is an easier sell than Ruby or Python to people who like curly braces, which is anyone currently using C++, Java, C#, JavaScript or Perl. That's a whooole lot of curly brace lovers. I'm nothing if not practical these days.
I don't expect today's little rant to convince anyone to share my minority opinion about code base size. I know a that few key folks (Bill Gates, for instance, as well as Dave Thomas, Martin Fowler and James Duncan Davidson) have independently reached the same conclusion: namely, that bloat is the worst thing that can happen to code. But they all got there via painful things happening to them.
I can't exactly wish for something painful to happen to Java developers, since hey, it's already happening; they've already taught themselves to pretend it's not hurting them.
But as for you, the eager young high school or college student who wants to become a great programmer someday, hopefully I've given you an extra dimension to observe as your tend your code gardens for the next few years.
When you're ready to make the switch, well, Mozilla Rhino will be ready for you. It works great today and will be absolutely outstanding a year from now. And I sincerely hope that JRuby, Jython and friends will also be viable Java alternatives for you as well. You might even try them out now and see how it goes.
Your code base will thank you for it.
Selasa, 18 Desember 2007
Your Comment
Terima kasih atas beberapa masukkan yang disampaikan baik melalui email ataupun shoutbox untuk blog ini. Berikut adalah tanggapan atas saran yang masuk :1. Pembahasan soal - soal dan kisi - kisi untuk Ujian Nasional akan segera muncul segera setelah 3 bab kumpulan soal yang tersisa selesai, be patient !2. Blog ini secara khusus memang hanya seputar matematika sma khususnya materi - materi yang
Kamis, 13 Desember 2007
Search Engine Optimize ( SEO )
Search Engine Optimize ( SEO ) adalah sebuah upaya yang dilakukan agar mendapatkan rangking yang baik pada hasil pencarian. Sebenarnya ada banyak teknik SEO ( klik disini ) yang bisa diterapkan agar kita bisa mendapat rangking yang baik di SERP ( Search Engine Result Page ).Tulisan ini bukan untuk membahas tentang SEO, karena saya juga tidak menguasai hal tersebut. So saya hanya ingin menunjukkan
Utak - atik Turunan
Ada dua soal yang kelihatannya bakal keluar di Ujian Nasional untuk materi turunan.1. Soal yang berkaitan dengan turunan berantai, biasanya lebih sering muncl dalam bentuk fungsi trigonometri.2. Soal yang berkaitan dengan aplikasi turunan, mencari nilai maksimum atau minimum suatu fungsi fungsi atau kadang juga mencari persamaan garis singgung suatu kurva
Selasa, 11 Desember 2007
Soal Turunan
Berikut adalah soal - sola materi turunan 2 tahun terakhir ( format wordnya dapat diklik disini :1. Jika f(x) = sin² ( 2x + π/6 ), maka nilai f′(0) = ….a. 2√3b. 2c. √3d. ½√3e. ½√2Soal Ujian Nasional tahun 20072. Turunan pertama dari f(x) = sin ( 3x² – 2 ) adalah f’(x) = ….a. 2 sin² ( 3x² – 2 ) sin ( 6x² – 4 )b. 12x sin² ( 3x² – 2 ) sin ( 6x² – 4 )c. 12x sin² ( 3x² – 2 ) cos ( 6x² – 4 )d. 24x
Kamis, 06 Desember 2007
Boring Stevey Status Update
I had an exciting morning of not getting fired today. Get this: I'm on a trip to Google's Mountain View headquarters, and was glancing at Reddit between meetings, and lo and behold, I was inexplicably in the Reddit Tabloids again, this time for being fired, or so people were speculating (far too hopefully, I might add. Geez.) Needless to say, I immediately put all my other work-related plans on "pause" while I tried to figure out whether I was, in fact, being fired. Can't accuse me of not having my priorities straight!
It turns out it was a minor mixup by an automated system, a system that decided to jump-start its own evolution by going directly from brownian motion to VP-level decision-making (2 evolutionary hops total. Hee.). This automated system had apparently just watched the movie Brazil, and thought it would be fun to send me off to Information Retrieval. So my account was disabled, from which lonely data point the Reddit crowd concluded that I must be getting fired right now, in real time, like OJ in his white SUV. And seeing as I was too surprised to think of a counter-hypothesis, I spent about 20 minutes in an undignified, trouser-soiling panic. Thanks, Reddit!
Anyhoo, after some friends inside Google had undone the mistake for me, I pondered the overall thrust of the Reddit comment thread ("You suck". "No, YOU suck." "Your mom sucks." comment score below threshold) and decided I really ought to write something. Otherwise I'm likely to fall off the wagon and disappear for a year. Time is just whooshing away. I wish I could get back to High School Time, where even a single hour-long class can seem like eternity, and 4 years is effectively infinite. Sigh.
I do have a bunch of half-finished blog posts lying around, but nothing has really gelled yet. So I guess I'll ramble about stuff I've been up to. You know. A status update. Blech.
Incidentally, I've decided to try to limit myself to roughly 1000-word posts, which is about the length of a newspaper column, near as I can tell. I'll prolly just call it 5000 non-whitespace characters, and write an Emacs function to tell me when I've gone over. Off the top of my head, maybe something like:
which, when I run
So... In 500-ish remaining words, here are the first things that come to mind as I sit in this comfy modern-looking couch in Building 43 of Google's Mountain View headquarters.
JavaScript
I've been doing a lot of JavaScript-related stuff lately. I don't know if JavaScript 2 (aka ECMAScript Edition 4) is going to be the Next Big Language, but it's certainly going to be a Next Big Language. (There's room for more than one, obviously.) And in the meantime, well, JavaScript 1.7 is working plenty well for me.
Let's see... I'm working on a book on Mozilla Rhino with Norris Boyd (the primary author of Rhino, now a Googler in Boston). It's coming along in bursts, and is probably about 10% complete after 3 months of dorking around with it on weekends between football games (that goes for both me and Norris, as it turns out, although his team is 12-0, dammit). But it should be a pretty cool book, assuming football season ever ends. The book is pretty much where all my Joke Output has been focused lately, which hopefully helps explain my recent blog drought.
I've been watching the EcmaScript Edition 4 fireworks with keen interest. While I wouldn't want to name any specific parties, for fear of offending someone, it seems to me that one party, whom I'll refer to as "Uncle Mike", is up to his perverted old tricks again. If, like many others, you feel that "Uncle Mike" is being a "complete dickwad" (to put it as euphemistically as I can) then you can help by getting all your friends and sales people and random family members to switch to Firefox. Really. It'll help.
You might also write a polite letter to your favorite Ecma General Assembly Voting Member Company, telling them how much you and your ten thousand closest friends are really looking forward to the imminent ratification of EcmaScript Edition 4. Or hell, spam all of them. That's what Uncle Mike does.
NBE
Continuing in the spirit of freeing all my cats from bag-imprisonment, I should also mention I've been working on an Ecma-262 compliant JavaScript interpreter in Emacs-Lisp. I used to have actual details here, but it ate up 1000+ words, so I'll just summarize for ya.
The short synopsis is that I'm building a complete JavaScript environment in Emacs-Lisp, with two goals: (1) create a world-class JavaScript IDE for Emacs, and (2) permit writing Emacs extensions in JavaScript, since (2a) people aren't exactly flocking to elisp, and (2b) JavaScript turns out to be a better language, now that I know them both in excruciating detail. Emacs is a great environment that needs a better extension language, and JavaScript seems well suited to navigate the popularity-vs.-elegance tightrope I'm faced with.
That's the elevator pitch: puts people to sleep in 20 seconds, guaranteed.
The status-in-brief is that I now have a fully functional, Ecma-262 compliant JavaScript interpreter and runtime in elisp, which began as a port of Narcissus. I'm currently reworking the parser and parse tree to be faster and more IDE-friendly. Next I'll need to turn the interpreter into a byte-compiler that emits Emacs-Lisp bytecode, which should enable it to run as fast as (or faster than) Emacs-Lisp. Then I'll need to actually write the IDE and the emacs host objects.
The whole thing looks to be at least a year out, at least on my current budget of 3 hours a week, so don't hold your breath. I'm giving priority to the IDE functionality, since I kinda need it for other projects, so that could potentially happen by summer.
If you happen to think of a clever name for this project, please let me know.
Other Stuff
Well, this 1000-word limit is... a toughie. I've already blown through it, although hopefully I get some slack for counting HTML tags. But I have to wrap up, so I'll close with some Unsubstantiated Random Thoughts that maybe I can clarify in upcoming crudely-truncated entries:
Google continues to be an astoundingly awesome place to work. Like my friend Dominic says, "it feels like I've won the lottery every day."
Our Rhino on Rails framework is still working great for us, and has finally begun to gain serious internal momentum at Google. Hopefully next year we can open-source it.
Interviewing for tech jobs at Google continues to be really hard (for both interviewer and interviewee), and I've accumulated enough truly useful interviewee-prep tips to merit a full blog post. Look for that one soon.
I still use Emacs to an extent that could justifiably be described as "unhealthy". I'd love to do another Effective Emacs post someday.
I still watch a lot of Anime. Currently watching Le Chevalier D'Eon, which is pretty awesome so far.
I taught my dog Cino to play guitar, a feat which so astounds people that they all say I should put it on YouTube, so there's Yet Another Side Project for me.
I'd love to write more about all this. The 1000-word limit seems to have made it feasible for me to create posts in a single sitting, with no bathroom breaks, provided I can actually go to 1500 "words". So hopefully in addition to all my side projects, I can blog more often.
And with that, I'm going to get back to my "day job" project(s), which are sadly confidential. But they're so cool that if I did tell you about them, you'd be so overwhelmed that you'd have to go sit in one of our $5000-ish massage chairs, like the dude sitting next to me right now.
Man this place rocks.
It turns out it was a minor mixup by an automated system, a system that decided to jump-start its own evolution by going directly from brownian motion to VP-level decision-making (2 evolutionary hops total. Hee.). This automated system had apparently just watched the movie Brazil, and thought it would be fun to send me off to Information Retrieval. So my account was disabled, from which lonely data point the Reddit crowd concluded that I must be getting fired right now, in real time, like OJ in his white SUV. And seeing as I was too surprised to think of a counter-hypothesis, I spent about 20 minutes in an undignified, trouser-soiling panic. Thanks, Reddit!
Anyhoo, after some friends inside Google had undone the mistake for me, I pondered the overall thrust of the Reddit comment thread ("You suck". "No, YOU suck." "Your mom sucks." comment score below threshold) and decided I really ought to write something. Otherwise I'm likely to fall off the wagon and disappear for a year. Time is just whooshing away. I wish I could get back to High School Time, where even a single hour-long class can seem like eternity, and 4 years is effectively infinite. Sigh.
I do have a bunch of half-finished blog posts lying around, but nothing has really gelled yet. So I guess I'll ramble about stuff I've been up to. You know. A status update. Blech.
Incidentally, I've decided to try to limit myself to roughly 1000-word posts, which is about the length of a newspaper column, near as I can tell. I'll prolly just call it 5000 non-whitespace characters, and write an Emacs function to tell me when I've gone over. Off the top of my head, maybe something like:
(defun blog-check ()
(interactive)
(save-excursion
(goto-char (point-min))
(let ((count 0))
(while (not (eobp))
(unless (looking-at "\\s-")
(incf count))
(forward-char))
(message "%s: %d chars, %d words"
(if (<= count 5000)
"OK so far"
"Dude, too long")
count
(/ count 5)))))
which, when I run
M-x blog-check, faithfully reports:"You suck." "No, YOU suck." "Your mom sucks."Oops, sorry. Wrong macro. My new function actually tells me:
OK so far: 2177 chars, 435 words.Halfway there, baby!
So... In 500-ish remaining words, here are the first things that come to mind as I sit in this comfy modern-looking couch in Building 43 of Google's Mountain View headquarters.
JavaScript
I've been doing a lot of JavaScript-related stuff lately. I don't know if JavaScript 2 (aka ECMAScript Edition 4) is going to be the Next Big Language, but it's certainly going to be a Next Big Language. (There's room for more than one, obviously.) And in the meantime, well, JavaScript 1.7 is working plenty well for me.
Let's see... I'm working on a book on Mozilla Rhino with Norris Boyd (the primary author of Rhino, now a Googler in Boston). It's coming along in bursts, and is probably about 10% complete after 3 months of dorking around with it on weekends between football games (that goes for both me and Norris, as it turns out, although his team is 12-0, dammit). But it should be a pretty cool book, assuming football season ever ends. The book is pretty much where all my Joke Output has been focused lately, which hopefully helps explain my recent blog drought.
I've been watching the EcmaScript Edition 4 fireworks with keen interest. While I wouldn't want to name any specific parties, for fear of offending someone, it seems to me that one party, whom I'll refer to as "Uncle Mike", is up to his perverted old tricks again. If, like many others, you feel that "Uncle Mike" is being a "complete dickwad" (to put it as euphemistically as I can) then you can help by getting all your friends and sales people and random family members to switch to Firefox. Really. It'll help.
You might also write a polite letter to your favorite Ecma General Assembly Voting Member Company, telling them how much you and your ten thousand closest friends are really looking forward to the imminent ratification of EcmaScript Edition 4. Or hell, spam all of them. That's what Uncle Mike does.
NBE
Continuing in the spirit of freeing all my cats from bag-imprisonment, I should also mention I've been working on an Ecma-262 compliant JavaScript interpreter in Emacs-Lisp. I used to have actual details here, but it ate up 1000+ words, so I'll just summarize for ya.
The short synopsis is that I'm building a complete JavaScript environment in Emacs-Lisp, with two goals: (1) create a world-class JavaScript IDE for Emacs, and (2) permit writing Emacs extensions in JavaScript, since (2a) people aren't exactly flocking to elisp, and (2b) JavaScript turns out to be a better language, now that I know them both in excruciating detail. Emacs is a great environment that needs a better extension language, and JavaScript seems well suited to navigate the popularity-vs.-elegance tightrope I'm faced with.
That's the elevator pitch: puts people to sleep in 20 seconds, guaranteed.
The status-in-brief is that I now have a fully functional, Ecma-262 compliant JavaScript interpreter and runtime in elisp, which began as a port of Narcissus. I'm currently reworking the parser and parse tree to be faster and more IDE-friendly. Next I'll need to turn the interpreter into a byte-compiler that emits Emacs-Lisp bytecode, which should enable it to run as fast as (or faster than) Emacs-Lisp. Then I'll need to actually write the IDE and the emacs host objects.
The whole thing looks to be at least a year out, at least on my current budget of 3 hours a week, so don't hold your breath. I'm giving priority to the IDE functionality, since I kinda need it for other projects, so that could potentially happen by summer.
If you happen to think of a clever name for this project, please let me know.
Other Stuff
Well, this 1000-word limit is... a toughie. I've already blown through it, although hopefully I get some slack for counting HTML tags. But I have to wrap up, so I'll close with some Unsubstantiated Random Thoughts that maybe I can clarify in upcoming crudely-truncated entries:
Google continues to be an astoundingly awesome place to work. Like my friend Dominic says, "it feels like I've won the lottery every day."
Our Rhino on Rails framework is still working great for us, and has finally begun to gain serious internal momentum at Google. Hopefully next year we can open-source it.
Interviewing for tech jobs at Google continues to be really hard (for both interviewer and interviewee), and I've accumulated enough truly useful interviewee-prep tips to merit a full blog post. Look for that one soon.
I still use Emacs to an extent that could justifiably be described as "unhealthy". I'd love to do another Effective Emacs post someday.
I still watch a lot of Anime. Currently watching Le Chevalier D'Eon, which is pretty awesome so far.
I taught my dog Cino to play guitar, a feat which so astounds people that they all say I should put it on YouTube, so there's Yet Another Side Project for me.
I'd love to write more about all this. The 1000-word limit seems to have made it feasible for me to create posts in a single sitting, with no bathroom breaks, provided I can actually go to 1500 "words". So hopefully in addition to all my side projects, I can blog more often.
And with that, I'm going to get back to my "day job" project(s), which are sadly confidential. But they're so cool that if I did tell you about them, you'd be so overwhelmed that you'd have to go sit in one of our $5000-ish massage chairs, like the dude sitting next to me right now.
Man this place rocks.
Senin, 03 Desember 2007
Tips dan Trik Matematika
Sebenarnya saya kurang setuju dengan cara - cara yang digunakan oleh beberapa bimbingan belajar ( kayaknya hampir semua bimbel ) yang mengajar trik - trik tertentu ( kadang disebut sebagai rumus cepat ) untuk mengerjakan soal matematika.1. Saya kadang suka mendapat pertanyaan dari siswa " apakah ada rumus cepatnya pak ? " jika sebuah soal terkesan agak sedikit menjelimet dalam proses pencarian
Useful online mind maps
While surfing internet, I get to know about some good readymade mind maps. Here are the links of them...
1. On Pythagoras theorem http://agutie.homestead.com/files/pythagoras/pythagoras_proof_mind_map.html
2.Geometry help
http://agutie.homestead.com/files/mindmap/geometry_math_com_help.html
3.Euclid's elements
http://agutie.homestead.com/files/mindmap/mindmap_elements_000.html
4.weblog
http://agutie.homestead.com/files/mindmap/mindmap_blog_weblog.html
5.Optical illusion
http://agutie.homestead.com/files/mindmap/optical_illusion.html
Mindmap Instructions:
To see a note, hover over a note button above.
To Fold/Unfold a node, click the node or right click a Node and select Fold/Unfold all from Node. To scroll the mindmap above, drag the map's background and move it around, or click on background and use the arrow keys.
To link to another page, click a link button above. Buttons above: Search, Go to, Zoom in or CTRL '+', Zoom out or CTRL '-', Reset (center), Shadow On/ Off, FreeMind, BG color.
1. On Pythagoras theorem http://agutie.homestead.com/files/pythagoras/pythagoras_proof_mind_map.html
2.Geometry help
http://agutie.homestead.com/files/mindmap/geometry_math_com_help.html
3.Euclid's elements
http://agutie.homestead.com/files/mindmap/mindmap_elements_000.html
4.weblog
http://agutie.homestead.com/files/mindmap/mindmap_blog_weblog.html
5.Optical illusion
http://agutie.homestead.com/files/mindmap/optical_illusion.html
Mindmap Instructions:
To see a note, hover over a note button above.
To Fold/Unfold a node, click the node or right click a Node and select Fold/Unfold all from Node. To scroll the mindmap above, drag the map's background and move it around, or click on background and use the arrow keys.
To link to another page, click a link button above. Buttons above: Search, Go to, Zoom in or CTRL '+', Zoom out or CTRL '-', Reset (center), Shadow On/ Off, FreeMind, BG color.
Rabu, 28 November 2007
Selasa, 20 November 2007
Page Rank
Sebenarnya saya tidak terlalu ngerti banget makhluk apakah page rank itu ? Konon penilaian yang diberikan berdasarkan banyaknya tautan yang dilakukan oleh situs lain terhadap situs tersebut. 2 hari yang lalu iseng coba ngecek pagerank di beberapa situs untuk mengecek blog ini, ternyata hasilnya sebagai berikut :1. http://www.top25web.com/pagerank2. http://seopen.com/seopen-tools/pagerank.php3.
Practising Venn diagrams
Click on the given link to use the online tool for practising about venn diagrams .
http://mathdl.maa.org/images/upload_library/3/Jimenez/VD3_Numbers-NOTATION_01.html
http://mathdl.maa.org/images/upload_library/3/Jimenez/VD3_Numbers-NOTATION_01.html
Senin, 19 November 2007
Writing Mathematics
In mathematics we need to type it as it is done in the classroom or given in the text books.By this I mean to say that we have to write correct mathematics also, when we are posting information for our students.I was looking for some free software or facility which could solve this problem of mine as well as the students. While surfing internet, I stumbled upon a free equation editor. It has solved all my problems of writing mathematics. And the best part is ,it is free and can be inserted in a blog/website ,through the HTML code provided.
You may get this from http://www.sitmo.com/latex/
You may get this from http://www.sitmo.com/latex/
Utak atik Lingkaran
Materi lingkaran termasuk materi yang hanya keluar 1 soal tiap tahunnya. Pokok bahasan yang sering muncul adalah mengenai persamaan garis singgung yang menyinggung lingkaran. Pada tahun 2006 dan 2005 soal lingkaran muncul sebanyak 2 soal, akan tetapi di tahun 2007 hanya 1 soal. Sepertinya kehadirannya di 2 tahun tersebut karena sebelumnya pokok bahasan lingkaran muncul bersama irisan kerucut
Jumat, 16 November 2007
Soal Lingkaran
Berikut adalah soal lingkaran 2 tahun terakhir1. Salah satu persamaan garis singgung lingkaran ( x – 2 )² + ( y + 1 )² =13 di titik yang berabsis –1 adalah ….a. 3x – 2y – 3 = 0b. 3x – 2y – 5 = 0c. 3x + 2y – 9 = 0d. 3x + 2y + 9 = 0e. 3x + 2y + 5 = 0Soal Ujian Nasional tahun 20072. Persamaan garis singgung lingkaran x² + y² – 2x – 6y – 7 = 0 di titik yang berabsis 5 adalah ….a. 4x – y – 18 = 0b. 4x
Kamis, 08 November 2007
Rabu, 07 November 2007
Utak - atik Persamaan Linier
Kalau melihat kehadirannya pada Ujian Nasional ( 3 tahun terakhir ), soal persamaan linier lebih banyak tampil dalam soal cerita. Meskipun tampil dalam bentuk cerita tetapi merubahnya menjadi persamaan matematika ( 2 tahun terakhir 3 variabel, kelihatannya tahun depan soal yang keluar juga bakal 3 variabel )tidak terlalu sulit.So, untuk bisa mengerjakan soal ini di Ujian Nasional :1. Anda harus
Rabu, 24 Oktober 2007
Soal Persamaan Linier
Berikut adalah soal Ujian Nasioanla 3 tahun terakhir :( untuk format wordnya bisa diklik disini )1. Ani, Nia, dan Ina pergi bersama – sama ke toko buah. Ani membeli 2 kg apel, 2 kg anggur, dan I kg jeruk dengan harga Rp 67.000,00. Nia membeli 3 kg apel, 1 kg anggur, dan I kg jeruk dengan harga Rp 61.000,00. Ina membeli 1 kg apel, 3 kg anggur, dan 2 kg jeruk dengan harga Rp 80.000,00. Harga 1 kg
Selasa, 09 Oktober 2007
Idul Fitri
Tidak terasa akhirnya hari raya akan tiba dalam 4 hai lagi. Untuk itu perkenankan saya mengucapakan " TAQABBALALLAHU MINA WA MINKUM " semoga di hari raya nanti kita bisa menjadi manusia yang lebih baik dari sebelumnya.Lewat tulisan ini juga saya mohon maaf yang " tak terhingga " kepada anda semua yang sudah mampir ( mungkin nyasar ketemu blog ini ) ke blog ini, semoga di lain hari blog ini bisa
Rabu, 26 September 2007
Download Soal Ujian Nasional Matematika
Sebenarnya ada keinginan agar file ( microsoft word ) kumpulan soal ujian yang ada di blog ini bisa di download dengan mudah, akan tetapi saya belum punya tempat yang tepat untuk itu ( sebenarnya sudah coba pakai google doc tapi kok hasilnya kurang sesuai dengan yang diinginkan ).1. cara 1kalau webnya lagi nggak ngadat bisa klik disini2. cara 2Jika anda kesulitan dengan cara diatas, maka anda
Selasa, 25 September 2007
Ten Tips for a (Slightly) Less Awful Resume
| Objective: Obtain a position at IBM -- some idiot applying to Amazon.com |
WARNING: These are my own *personal* opinions, not Google's or Amazon's or anyone else's. I do think you'll find that most resume screeners at tech companies — particularly tech companies that build their own software in-house, like Yahoo! or eBay or Amazon.com or Microsoft or Google — will agree with a lot of this stuff, on the whole. But experienced screeners disagree on lots of the little details, and in the end these are just my own opinions. These tips are not guaranteed to get you any better results. Your mileage may vary. Do not use these tips in a bathtub or when standing in a pool of water. Do not tap on the glass or the tips will be irritated. Do not feed the tips. Etc.
Today's scientific question is: why are the resumes of programmers so uniformly awful? And how do we fix them? The resumes, that is.
If you've spent more than approximately seventeen kiloseconds as an industry programmer, you've had to review bad tech resumes. It's just part of the job. Programmer resumes ultimately have to be gauged by programmers — it takes one to know one. So it winds up being a kind of karmic revenge on you for bad resumes that you've written. C'mon, you know you've done it. You even knew it was bad when you were writing it. Admit it! You listed HTML under programming languages, didn't you? Argh!
So why are tech resumes so bad? You know what I mean. You see the craziest stuff on resumes. Like the candidate who proudly lists every Windows API call she's ever used. Or the candidate who lists every course he took starting from junior high school. Or the one who lists college extension courses he took while doing time for armed robbery.
Or that really dumb guy who accidentally listed "work at IBM" as the objective on his Amazon resume. Ha, ha! What a dork!
Oh wait — that was me. D'oh. I sometimes refer to it as my "million dollar typo". It's kind of a painful story, especially for my eardrums, since whenever I tell it people predictably point at me and scream with hysterical girly laughter. Dammit. Not to mention the fact that it cost me a fortune in stock-option valuation because I applied before the IPO and was quite understandably ignored by Amazon recruiters until I re-applied long after the IPO, this time saying that haha, no hard feelings, my bad, I actually wanted to work for Amazon. Ahem.
But hey, I deserve what I got (in a word: "nothing"), because I was, if I may employ the common parlance, an idjit. I think almost everyone's been guilty at one time or another of idjicy when writing a tech resume, although maybe not quite as flagrant as mine was. And if almost everyone's guilty of it, then they must be hard to write.
I think there are multiple root causes. One is that nobody teaches us what companies are looking for. And we don't write resumes very often in our careers, so we don't get much practice at it.
Another root cause is that much of the advice on resume-writing from other industries doesn't necessarily carry over to tech resumes. I'll cover some of these mismatches in my tips below.
Another minor, yet oddly persistent problem is that many candidates are raving pathological liars. You'd be amazed at how many candidates tell me: "Oh, I just put that buzzword on there for the recruiters." Needless to say, this response leads directly to the time honored end-of-interview transmission code: DYHAQFM? ("Do you have any questions for me?")
In spite of all these problems I hold out hope that it might be possible to get at least some people to write better programmer resumes by giving a few free tips. You never know. After all, I can't ask my favorite phone-screen questions anymore – candidates tell me they've read my blog. So maybe someone will pay attention to these tips, too.
I'm just talking about software engineer resumes today, and specifically just the subset intended for applying to companies that build their own software. I have no idea how much (if at all) this stuff applies to resumes for other kinds of positions, or companies. Maybe not much. Sorry!
Anyway, here are my resume-writing tips, which I'm giving directly to you, free of charge, with no strings attached, because I care about you so much.
Tip #1: Nobody cares about you
Ha, ha! Saw that one coming, I'll bet.
Well, let's be a bit more precise: nobody cares about you yet. Not during resume screening, anyway.
Resume screening is just pattern matching. People are trying to figure out if you have the skills they're looking for. If they could do this reliably without human intervention, so much the better. Screeners will like your resume best if it's easy to scan visually, and stories about you and your fun-loving personality and fiercely loyal carnivorous parakeet and year-long hiking expedition in Tibet and blah Blah BLAH just don't scan.
The output of the resume screening step is a decision: should they proceed with you or decline you? Once that go/no-go decision is made and entered into the system, the screeners want to forget all about you. Seriously. They need their cache cleared for the next pattern-matching session. So anything you say about yourself — anything that differentiates you from a machine that can crank out beautiful code — is just an annoying and potentially harmful distraction. At best, the screener will ignore it. At worst, they'll get mad at you and start grading more harshly.
So your best strategy is to avoid talking about yourself. All your hopes, fears, goals, dreams, ambitions — DELETE. (Your resume's going to get a lot shorter from these tips, in case you were wondering.) Your cover letter? DELETE. Nobody cares! Your little clever in-joke in your objective? DELETE. Especially that one. Resumes are not a time to be funny. Believe me, your resume is probably already funny enough without any additional effort on your part.
But what about your precious hobbies section, which identifies you as a well-rounded and socially adjusted person of taste and culture? DELETE! Unless you have relevant hobbies, that is. If your resume is borderline, and you say you're a World Origami Federation grandmaster, then you obviously don't have enough time for programming, so it'll likely get eighty-sixed. If your hobby is writing code, or administering a website, or doing anything remotely computer-related, then it might tip the scales in your favor. Otherwise, just don't mention it!
Face it: all the traditional advice about trying to convince the hiring manager that you're a plucky, scrappy young individual from a farm in Alabama who's destined for greatness on account of your Uncle Ted having given you that pep talk after you fell off your horse when you were a kid — that advice may as well have come from the back end of your horse, because the hiring manager just wants to profile your current skill set. Mr. Plucky goes into the Round File.
Don't get all depressed about this tip. People will start caring more about you as a person in later phases of the recruiting process, particularly if you're one of those candidates who doesn't really like showering.
Tip #2: Use Plain Text
Your resume is going to go through a bunch of automated transformation tools and will be mangled horribly along the way. Any non-ASCII character, such as those nonstandard Microsoft Word bullets, or any accented character, or (heaven help you) Unicode will be turned into our old favorite, the question-mark character ("?").
You don't want your resume to look like this:
Resum? for Bob?T???Moblin
?Experience
1997?Present? Vice?F???**??didn?t?do?sh???for?ten?yea???
So write it in plain text. Yes. Text. You know. Like from a typewriter, or Windows Notepad. ABCs, not PDF.
Don't expect any whitespace to make it through except newlines and single spaces. And don't assume your resume will be viewed in a fixed-width font. If you make a nice pretty formatted table using tab characters, it will look like ascii-art smoke signals by the time a human being looks at it.
The maximum amount of ASCII art you can get away with, and even this is stretching it, is hyphenated lines and bullets. For instance, this might be OK:
Education
---------
* B.S. Computer Science, University of Wherever, 1997
* M.S. Resume Writing, 2003
– graduated .357 magnum
But I wouldn't overdo it.
If your name has accent characters in it, your best bet is to change your name. For instance, if your name is Pièrre l'Éléphant, think about whether you'd prefer to have it seen as "Pi?rre l'?l?phant" or "Pierre l'Elephant". Sure, your accented characters might make it through, but I'd play it safe.
HTML formatting usually makes it through safely because it's plain text. However, even if your tags are left alone by the automated mangler, there's no guarantee that your resume will be viewed from a browser, and nobody wants to read through a bunch of ugly markup while they're trying to assess your skills. So you shouldn't use HTML either.
Text! All the best resumes are plain text. Use text.
Tip #3: Check, please!
Attend to your basic hygiene: spell-check, grammar-check, style-check.
For starters, they have these wonderful programs called "spell checkers", and they even know some computer jargon. For God's sake, don't submit a resume without a spell-check. This is one bit of traditional advice that's still true for tech resumes. People care about your spelling, because if you're misspelling things it means you don't care enough about the quality of your job application to spend 30 seconds running it through a program that can find your mistakes for you. That's pretty damn lazy.
If you flat-out refuse to use a spell-checker, please at least refrain from misspelling Lisp as "Lips". You'd be amazed at how often people do this.
Don't misspell "Curriculum Vitae". The proper spelling is r-e-s-u-m-e, unless you have a Ph.D. or you're applying for a non-US company where "CV" is standardized. In the US, "curriculum vitae" is likely to be mistaken for a venereal disease.
Please, please, please learn the difference between "lead" and "led". It's one of the most common grammatical errors on resumes, and it annoys the hell out of many screeners. "Lead" is either the present-tense verb meaning "not doing any coding", or it's a metallic element that makes you sterile if you accidentally ingest it. "Led" is the past tense of "lead". Example:
* 1995-1996: lead a team doing blah blah blah. we were...
The date is long past, and rest of the paragraph is in the past tense, so this is clearly one of those people who don't know "lead" from "led". That, or she was trying to sterilize her team members. Either way, it doesn't look good.
Keeping the tense consistent between sentences in a paragraph is related to the important grammatical notion of "parallelism", in which you try to use the same structure for clauses in a sentence. For instance, you should never say: "Job responsibilities: pretty much doing nothing and pick my nose." Screeners will be much more impressed if you use the parallel gerund form, picking your nose.
None of this advice applies to blogs, of course. If you find spelling or grammatical errors in my blog, it's because I put 'em there on purpose. Pshaw.
To finish off our spiffy lead/led example, I should note that you can also use "lead" as a noun, as in "tech lead", but you risk having it interpreted as "wanker", so read tip 5 before you attempt it.
So! Spell check and grammar check. Gotta have 'em. What about style?
I could of course rant at length about style, but it's pretty open-ended: people constantly find clever new ways to be unclever. So I will restrict my stylistic remarks to the use of the word "utilize". "Utilize" has been scientifically demonstrated to be used only by stupid people, so if you use it you could easily be mistaken for one. A stupid person, that is, not a scientist. "Utilize" is one of the all-time classic Stupidity Indicators, right up there with saying "choo-choo-choo" out loud when you're thinking. Ever notice how only stupid people make train noises when they're thinking? "Oh gosh, lemme think, chsh chsh chsh... hmmm, choo choo choo..."
Yup. They sound like Winnie the Pooh, who as you may recall "thinks" by pounding his head and saying "think think think." DYHAQFM!
Tip #4: Avoid Weasel Words
Weasel Words are impressive-sounding verbs that make it sound like you did something useful, when in fact all you did was snork down chocolates from the big candy bowl in the conference room while other people did all the actual work.
"Participated" is the all-time champion Weasel Word. As an example of just how weaselly it is, consider this: I can say truthfully that I participated in the Gulf War. I even received a medal for it. The actual form of my participation involved watching it on CNN; I happened to be active duty Navy at the time but wasn't on tour. But I "participated" so I got a medal, despite the fact that I probably couldn't identify the Persian Gulf on a map.
Heck, I even "participated" in the election of George W. Bush, specifically by not voting for him. But it's true! I participated!
Given that you can participate in something without doing much or having any real impact, the word "participate" becomes a semantic sink: it sucks all meaning out of a paragraph, nullifying any deductions we can make about your actual contribution. If any form of "participated" appears in a paragraph describing something you did, experienced resume screeners will simply draw a big red line through that paragraph and move on.
"Proposed" is another Weasel Word, unless it's immediately followed by a claim of bona-fide work, such as "...and implemented". There's a certain type of candidate who drifts from job to job and produces nothing but proposals. This can mean that the person doesn't like to do real work, or that nobody ever listens to the person, but either way it's not good.
One big class of Weasel Words is the "stalker" category, including "analyzed", "studied", "learned", "observed", "watched" and their ilk. Nobody wants to hire you based on your extensive experience with observing work occurring. If all you did was analyze stuff, assuming it wasn't some sort of rigorous statistical analysis worth bragging about, then just take that whole item out of your tech resume.
Resume screeners keep an eye out for non-weasel words, aka Productivity Words. These are words that you can't weasel out of when someone asks you about them. The best are synonyms of "got real stuff done", including "coded", "implemented", "developed", "delivered", and "launched".
It's perfectly OK to use "designed", as long as you follow it up with a Productivity Word. If you design something without implementing it, then it's just a synonym for "Proposed". If you prefer to design things that other people ultimately implement, then you're quite possibly outstanding material for a company full of kneebiters. But a real tech company like Amazon or eBay or Microsoft or whoever isn't going to hire you, because they can find plenty of people who can both design things and implement them.
"Tech lead" is, sadly, another weasel word if you're applying for an individual contributor position, because it's all too easy for your tech skills to rust into oblivion if you spend long enough as a tech lead without helping with the coding. It's especially a red flag for college hires who are talking about their group projects; weaker programmers often gravitate towards the coordinator position on their project, and wind up not having any real knowledge to show for their effort. Hence, if you're applying for a programming position and you were a project leader of any kind, make sure to call out whether you did any coding on the project, or screeners will assume that you did none.
Tip #5: Avoid Wank Words
Wank Words are words that inflate your perceived importance (e.g. using "architected" rather than "designed"), or words that have simply become synonyms, such as "Rational UML Process", for the so-called work done by people who sit on their asses and don't know how to code anymore.
Wank Words are worse than just devoid of content; they're active indicators of total inactivity. Resume screeners either delete Wank Words or replace them with the word "wank" (e.g., "Certified Wank Master"), which makes the resume a lot easier to scan.
"Advocate" is a common wank word, when it refers to a title or position. If it's a verb then it's just a weasel word, but if you think it's your title, then you've inflated yourself into Wanker territory. Either way, if you're walking around advocating stuff, it means you're not working. Also, it means nobody listens to you, because if you possessed actual leadership, people would just do what you recommended and then you wouldn't need advocate it anymore. So "advocate" just means "wanker".
"Consultant" is often another absolutely outstanding synonym for "wanker". Now let me just add, before I get stabbed to death by eager members of the heavily armed Consultant Industry, that some consultants are great. The problem is that the odds are completely stacked against you in tech resume screening. It's like fast-food experience when applying to be a waiter at a fancy restaurant. It might have helped you hone your waiter skills, but the odds are against it, and a lot of the art of resume screening is about weighing odds.
The problem with "consultant" is that it has two meanings. It can either mean "person who was hired on a contract basis to fill a coding need in the organization", or it can mean "person hired to 'consult', aka 'wank', because the hiring organization is too clueless to solve their own problems and too incompetent to retain even one full-time staff member capable of helping them, so they turn to paid self-help." When you see the word on a resume, it can be hard to distinguish which kind it is.
The all-time worst Wank Word is probably "Methodologist". It will definitely get your resume circulated around at tech companies, but not for the reasons you were hoping. Any sort of amusing synonym for "Methodologist", such as Scrum Master, generally has the same effect.
Wank Words are a bit like the adjectives on restaurant menus — meaningless fluff words added in an attempt to make the dish sound tasty. You can get a much clearer idea of what the hell it is that you're contemplating eating if you take all the adjectives out, including nouns and noun-strings that serve as adjectives. For instance, House Cured Spice Rubbed Apple Smoked Line Caught Columbia River Coho Salmon, when all the Wank Words are removed, becomes "Salmon", which is of course the only part of the description that you're actually eating. Depending on how you feel about what that winds up being, you can replace all the adjectives with either "icky" or "yummy", e.g. "Yummy yummy yummy yummy yummy yummy yummy yummy Salmon", or "Icky icky icky icky icky icky icky icky Eggplant."
Hence, many wank-filled resumes wind up looking, after the screeners have marked them up a bit, like this: "Senior wanker wanking for the Wank-Wank Institute of Wankology on the wank wank wank project during which I wanked successfully with seven other wanky wankers."
Well, "senior" is also kind of a wank word, but you get the idea.
Tip #6: Don't be a Certified Loser
Don't ever, ever use the word "certified" your resume. It's far and away one of the most prominent red flags in resume screening, bordering on a dead-giveaway round-file 86-that-bad-boy no-review-required situation, if you know what I mean. (If you don't know what I mean, well, you know the old saying about not knowing who the sucker is at the poker table.)
Certification is for the weak. It's something that flags you as a technician when you really want to be an engineer. If you want to be a television repairman, you can become certified in TV repair. If you want to work for Sony and design their next big-screen TV, then you clearly don't need a busy-working-adults course on how to repair the fugging things.
Same goes for tech certification. It means you had to take a course to learn something you could have read in a book. If you know something, just say you know it, and then be prepared to answer questions about it during your phone screens and/or interviews. If you feel compelled to add that you're certified in said skill, it's just broadcasting that you lack confidence in your own self-assessments, which doesn't help you in the slightest.
Seriously. Take all mentions of certifications off your tech resume. It's actively hurting your chances of getting an interview.
Tip #7: Don't say "expert" unless you really mean it
The term "expert" makes experts' eyes glow red. It doesn't bother me personally, but I know enough interviewers who care vastly about it that I'm advising you to steer clear. If you say you're an expert in something, many interviewers take it to mean you claim to have a bigger penis than they do, metaphorically speaking of course, and they're going to pull out their still highly metaphorical measuring stick during the interview and size you up. I employ this metaphor in its most gender-neutral possible interpretation, needless to say.
A friend of mine at Amazon once told me that he takes resumes that list "expertise" and he tells the candidate something along these lines: "Wow! You don't often find true experts in fields like this. I feel like I've found a kindred spirit here. I don't often do this, but I'm going to pick one of these technologies you're an expert at, and we're doing to do an incredibly deep technical dive on the subject. But before I start, is there anything you want to take off the resume?"
He says it's like truth serum. (Hi, H.B.!)
Tip #8: Don't tip your hand
Resume writing is just like dating, or applying for a bank loan, in that nobody wants you if you're desperate. And there are dozens of sure-fire little ways to let it slip out accidentally that you are, in fact, desperate, such as (just as one example) using the word "desperate" on the actual resume. Don't do that.
Ideally you want to appear confident and competent. Regardless of your overall skill level, from "Magna Cum Laude" to "Platyhelminthes", you'll want to appear confident that you can function effectively at that level.
One way of sounding really desperate is to apply for 18 jobs in one sentence. "Objective: Highly personable, results-oriented programmer seeking opportunity to lead or contribute individually on projects or programs involving e-commerce, 3D multiplayer gaming, b2b, web programming or client/server networking with database or other persistence strategies while utilizing my broad background in problem-solving to do pretty much any menial job you'll give me oh please please please hire me, I'm d-d-des-desp-waaaaaaah!" Works like a charm!
You can apply for 18 jobs, but you should send 18 different resumes, each targeted at that job, and you shouldn't send them all at once.
Another really obvious sign of desperation is saying you're eager to learn. Never, ever say "eager to learn" on a resume. In the ancient and occult secret rosetta-stone decoder language of technical resume screeners everywhere, "eager to learn" means "unskilled labor". Let's face it: if you were really eager to learn, you'd have done it by now.
"Fast learner" — definitely another bad one. Doubly so, because it combines desperation with ignorance; you wouldn't need to call it out if you could demonstrate something concrete that you've already learned. If you have some true demonstration that you're a fast learner, such as entering college at age 14, then sure, call it out. But the phrase "fast learner" is a fast track to the Big Resume Bin in the Sky.
"Motivated" is another resume-screening synonym for "desperate". Don't say you're motivated. It's like wearing a suit to the interview. It'll turn people off, guaranteed.
The best way to sound non-desperate is to be non-desperate. You can do that by lowering your expectations, tightening your belt, and not applying for that job you know you're not qualified for. Failing that, just make a nice clean resume that sticks the bare facts about your skills and accomplishments.
Tip #9: Don't bore us to death
Consider this resume statement:
* designed and developed runtime library code to emulate
MS-DOS and BIOS calls on a variety of Unix platforms. This
enables binary-ported DOS application programs such as Quicken
and Microsoft Word to run under a commercial emulator on Unix
platforms. This enables users who do not currently have access
to a DOS machine, but who have blah blah BLAH lather rinse repeat.
All it needs is the first sentence; we can deduce the rest.
Incidentally, if you're cleverly thinking of commenting that I need to follow Tip #9 in my blogs, well, just remember this: if you ever write well enough to attract commenters, they'll hate you too. So there!
Seriously, take a close look at your resume and delete anything that seems obvious. If you worked at a company that everyone in the world has heard of, such as Microsoft or Amazon, then don't spend time explaining to us what they do.
Be as specific as possible. Don't say "managed several small projects and one medium-sized one." That's useless. If the projects were too small to detail, then don't mention them at all.
Don't repeat information from section to section. That happens a lot. Candidates seem to think that screeners might miss something important on the resume, so they wind up saying the same thing over and over. This copy-and-paste strategy has two major downsides. The first is that the screener will be irked that you're repeating yourself, causing them to start grading more harshly. The second is that if you're repeating something the screener finds comical, such as "Senior Agile Methodologist" or "Certified J2EE Consultant", you're not exactly helping by repeatedly honking it out like a wounded seagull.
Resumes aren't a time for storytelling. Your goal, as a resume writer, should be to cover your entire academic and professional career in a way that makes it as easy as possible for screeners to match up your skills and accomplishments with things they recognize. It's basically a checklist.
Don't go overboard on me and make a resume with so little information that nobody can figure out what the heck you did on any of your projects — I've seen that too. When in doubt, provide more information, not less. There's nothing wrong with a long-ish resume, despite what you might have heard from other industries. Just try to leave out stuff that can be found through a search engine.
Tip #10: Don't be a lying scumbag
See, it's like this: you'll get caught. I'm still amazed at how many candidates think that the resume game is some variant of bingo, wherein all the words on your resume have optional invisible stars indicating whether you actually know something about that word, and you just cross your fingers hope the interviewer shouts out Bingo! after randomly selecting five starred words.
The weird thing is that so many people do it. Maybe they had to write a 10-line program in Forth back in approximately fourth grade, so they shrug and list "Forth" in their programming languages section, squeezed in at the end right between "HTML" and "English", in the hope that it looks good but won't be selected for Interview Bingo. That, folks, is tantamount to lying.
I do realize that "lying" is a rather harsh criticism, so I'm willing chalk it up to a gentlemanly misunderstanding over the definition of the number "five". Many people who rate themselves in some skill as being "average", or "intermediate", or "passably fair to middling", or 4 through 6 on a 1-10, have redefined those terms to mean "have been briefly exposed to the concept, but don't remember a single thing about it now except the name." Really. I'm not making this up.
Seeing as candidates are redefining the number five to mean "one", I figure I can redefine "grossly exaggerating" to mean "lying". Fair enough?
If you lie on a tech resume, you'll get caught. Of course one of the interviewers is going to be a passionate closet Forth user (as if there's any other kind), and they'll get all excited and ask about it, which sends the candidate into a pants-crapping frenzy of lost-at-Bingo smoke-screen tactics, which include hemming and hawing and saying "oh gosh it's been a long time" and all those other things that so endear them with interviewers.
What were they thinking?
Incidentally, I know this is supposed to be about resume writing and not interviewing, but let me just state for the record that I remember my college courses from nearly 20 years ago as if they were last week. If I'm interviewing you and I ask about your OS course and you say "oh gosh, it's been a long time, lemme think, choo choo choo, I can't remember" and then I look at your transcript and you took it 2 years ago, well, DYHAQFM?
Here's your absolute bestest-best winning strategy: don't lie and don't exaggerate. Everyone's had brief exposure to programming languages they didn't like and didn't understand, and there's nothing to be gained by listing them on a resume. Do your best to give a qualitative estimate of proficiency for every skill on your resume (the acceptable levels being "novice", "amateur", "tyro", "newbie", and "invented it" if you want extra insurance towards Tip #7).
Summary
Resume writing is a fine art, and everyone has their own cherished opinions about it, and no doubt I've angered even more than the usual number of certified agile consultants. But I estimate that I've screened well over five thousand tech resumes, and I've interviewed or phone-screened over 1200 candidates in my 18-year career, and I've worked with people who've got those numbers beat by a wide margin. Despite broad philosophical differences in opinion about how to conduct technical interviews, all the engineers I've talked to over the years pretty much look for the same things in resumes.
At the risk of boring you to death, I'll reiterate that I'm not speaking for Google here. It's not actually possible to speak for a whole company on a subject as diverse and opinionated as resume writing (or screening), but even if it were possible, I wouldn't be doing it.
This concludes today's little set of free, personal tips on writing programmer resumes. Thanks for reading!
DYHAQFM?
Jumat, 21 September 2007
Kunci Jawaban Persamaan dan Fungsi Kuadrat
1. C2. C3. B4. E5. C6. A7. E8. B9. A10. A11. A12. B13. C14. E15. E16. D17. C18. B19. ?Mohon koreksinya jika ada kunci jawaban yang salah (matematika3sma@gmail.com)
Utak - atik Eksponen dan Logaritma
Materi eksponen dan logaritma merupakan materi yang agak sedikit sulit diprediksi kehadirannya di Ujian Nasional. Pada 2 tahun terakhir ada 3 soal yang muncul dengan jenis soal yang berbeda, pada tahun 2007 soal yang keluar adalah 2 buah soal mengenai bentuk akar dan logaritma dan 1 soal mengenai persamaan Eksponen.Sedangkan pada tahun 2006 soal hadir dalam bentuk persamaan eksponen dan logaritma
Rabu, 19 September 2007
Kunci Jawaban Eksponen dan logaritma
1. C2. B3. A4. B5. E6. B7. A8. C9. C10. D11. E12. B13. B14. E15. E16. A17. E18. A19. D20. E21. ?Mohon koreksinya jika ada kunci jawaban yang salah (matematika3sma@gmail.com)
Selasa, 18 September 2007
Soal Eksponen dan logaritma
Berikut adalah beberapa contoh soal Persamaan eksponen dan logaritma, Jika anda butuh kumpulan soal ini dari tahun 2000-2007 ( dalam microsoft word )anda dapat menghubungi email saya di matematika3sma@gmail.com1. Akar – akar persamaan 3^2x+1 – 28.3x + 9 = 0 adalah x1 dan x2. Jika x1 > x2, maka nilai 3x1 – x2 = …a. – 5b. – 1c. 4d. 5e. 7Soal Ujian Nasional Tahun 20072. Akar – akar persamaan 2.3^4x
Senin, 17 September 2007
Utak - atik Persamaan dan Fungsi Kuadrat
Dari tahun 2000 s.d. 2007 kurang lebih ada 18 soal yang berkenaan dengan materi Persamaan dan Fungsi Kuadrat. Soal Persamaan lebih mendominasi ( ada 14 soal ) daripada soal Fungsi kuadrat ang hanya ada 4 soal. Jadi bisa dipastikan soal persamaan kuadrat paling tidak satu soal akan muncul di Ujian Nasional dan kalau melihat tahun 2007 kelihatannya soal Fungsi kuadrat juga bakal muncil 1 soal.Soal
Kunci Jawaban Persamaan Kuadrat dan Fungsi Kuadrat
1. C2. C3. B4. E5. C6. A7. E8. B9. A10. A11. A12. B13. C14. E15. E16. D17. C18. B19. ?Mohon koreksinya jika ada kunci jawaban yang salah (matematika3sma@gmail.com)
Soal Persamaan dan Fungsi Kuadrat
Setelah hampir 2 minggu absen, akhirnya rampung juga kumpulan soal untuk materi persamaan kuadrat dan fungsi kuadrat.Seperti biasanya kumpulan soal banyak memuat gambar dan microsoft equation ( dan saya belum bisa menampilkannya di blog ini ), so kalau anda butuh soal persamaan kuadrat dan fungsi kuadrat ini anda dapat menghubungi saya di matematika3sma@gmail.comAda kurang lebih 18 soal yang
Sabtu, 01 September 2007
Stevey's Tech News, Issue #1
Welcome to the first-ever edition of Stevey's Tech News! And possibly last-ever as well! I've managed to get the scoop on a number of important tech-industry stories before they hit the presses, and I'm sticking it to The Man by getting this valuable information to you -- my loyal readers and casual passersby and violent detractors and so on -- before you can read it anywhere else. Enjoy!
Sun Microsystems Demands University Study Retraction
The University of Washington, apparently hoping to capitalize on the recent hype around their controversial study on Baby Einstein™-style videos, followed up yesterday with another, similar study. In the new study, researchers found that Java programmers understand an average of seven fewer Computer Science concepts per hour spent with Java each day compared to similar programmers using other languages. Sun calls the study "seriously flawed", citing the fact that you can combine the names of Gang of Four Design Patterns to form new Computer Science concepts that all Java programmers understand, such as the ObserverFactoryBridge, the BridgeFactoryObserver, and the well-known FactoryObserverBridgeChainOfCommandSingletonProxy, beloved of Java programmers everywhere. Java experts at Sun say they're not sure how many combinations there are of the twenty-three pattern names, but there are "definitely a lot of them."
Man Dies Waiting for Eclipse to Launch
A software engineer in San Jose, CA was found dead at his desk yesterday, apparently having died while waiting for his Java editing program, Eclipse, to finish its boot process. Coworkers say the engineer came in that morning vowing to "get Eclipse working on his box or die trying." The last thing anyone heard him say aloud was the cryptic comment: "I see the splash screen is appropriately blue." Nobody knows what he meant. The man was then thought to have fallen asleep, but hours later it was discovered that the engineer had died suddenly of apparent natural causes. The forensics team's investigation that evening was reportedly interrupted unexpectedly when the dead man's Eclipse program suddenly finished launching. The team tried to interact with it to see if they could find clues about the man's death, but the program was unresponsive and the machine ultimately had to be rebooted. At this time, the police commissioner says there is no evidence of foul play, and they currently believe the man simply died of either boredom or frustration.
Bill Gates Hacks Security System
This week's issue of Time Magazine reports that Bill Gates hacked a security system at age 13. One of our staff investigators was intrigued enough to dig further into the story, and soon discovered that the security system in question was in fact one that Bill had written when he was 12. He managed to hack his way into his own system just under one year, a remarkable programming feat for the young Future Richest Man. One apocryphal version of the story claims that Bill finally cracked the system by accidentally turning over his mouse pad and finding the password he'd forgotten the year before, but the reality is that nobody still alive today knows how he did it. However, our investigative reporter did uncover one amazing twist to the story that should firmly cement Bill in programming legend, with concrete shoes of programming glory. The surprise twist: the little security system that Bill wrote at age 12 and hacked into a year later is still in production today, in Windows Vista.
MyTube Having Growth Difficulties
Ted Turner's highly anticipated MyTube™ social network for men is having sizing problems, according to media analysts. The new social networking site is Turner Broadcasting's answer to Oprah Winfrey's highly acclaimed and successful Oxygen television network aimed at young women. Unfortunately, MyTube, which is implemented entirely in Ruby on Rails, is hitting a scaling barrier at peak usage hours, which are reportedly between midnight and 2am PST. An insider at MyTube tells us confidentially that they get up to 100 users before the system slows to a crawl, causing bored users to delete random files from their servers by requesting well-formed URLs like http://mytube.com/database/delete and http://mytube.com/debugger/start. "It's just so rude", MyTube engineers were overheard saying in their Atlanta office. "Some of our users are just plain wankers."
Fundamental Computer Science Discovery
Computer Scientists around the world have been reeling in shock, the stir caused by a quiet publication in the latest Communications of the ACM. The ACM article that has everyone buzzing was submitted by an anonymous software engineer at an undisclosed Seattle-area software company. The engineer has formulated a proof that invalidates one of the most fundamental results in Computer Science, specifically that "recursion" and "iteration" are formally equivalent. The new proof by counterexample is simple, compelling, and undeniable, and theorists are said to be furiously scratching themselves over the proof's implications, which are far-reaching enough to impact virtually all computer-automated industries, from aerospace technology through zooospace engineering. The anonymous author of the paper has found that there is in fact one thing you can do using recursion that you can't do using iteration, namely: "You can use it to weed out stupid fugging interview candidates."
Dyson Unveils the iSuck™ Personal Vacuum Assistant
Dyson Corporation announced today their latest innovation, a mobile handheld vacuum cleaner the size of a flashlight, dubbed the "iSuck". Dyson's spokesperson was quoted as saying that although the device was originally targeted at the middle-aged housewife demographic, the iSuck has turned out to be unexpectedly popular with men of all ages and demographics. Pundits speculate that the iSuck has finally achieved a form factor that entices men to do their own housecleaning. Dyson claims that based on extensive early user feedback, new versions of the iSuck are planned for near-term release, including a unit that doesn't dampen the motor vibrations (we assume this is to increase battery life), a wet/dry vac, and a limited edition run titled "The Patriot", which hums the U.S. National Anthem as it operates, expected to be popular aboard U.S. Navy ships for vacuuming those hard-to-reach nooks and crannies. Dyson's shares soared on the news, with analyists recommending that Dyson milk every drop from their innovative new product.
Sun Microsystems Demands University Study Retraction
The University of Washington, apparently hoping to capitalize on the recent hype around their controversial study on Baby Einstein™-style videos, followed up yesterday with another, similar study. In the new study, researchers found that Java programmers understand an average of seven fewer Computer Science concepts per hour spent with Java each day compared to similar programmers using other languages. Sun calls the study "seriously flawed", citing the fact that you can combine the names of Gang of Four Design Patterns to form new Computer Science concepts that all Java programmers understand, such as the ObserverFactoryBridge, the BridgeFactoryObserver, and the well-known FactoryObserverBridgeChainOfCommandSingletonProxy, beloved of Java programmers everywhere. Java experts at Sun say they're not sure how many combinations there are of the twenty-three pattern names, but there are "definitely a lot of them."
Man Dies Waiting for Eclipse to Launch
A software engineer in San Jose, CA was found dead at his desk yesterday, apparently having died while waiting for his Java editing program, Eclipse, to finish its boot process. Coworkers say the engineer came in that morning vowing to "get Eclipse working on his box or die trying." The last thing anyone heard him say aloud was the cryptic comment: "I see the splash screen is appropriately blue." Nobody knows what he meant. The man was then thought to have fallen asleep, but hours later it was discovered that the engineer had died suddenly of apparent natural causes. The forensics team's investigation that evening was reportedly interrupted unexpectedly when the dead man's Eclipse program suddenly finished launching. The team tried to interact with it to see if they could find clues about the man's death, but the program was unresponsive and the machine ultimately had to be rebooted. At this time, the police commissioner says there is no evidence of foul play, and they currently believe the man simply died of either boredom or frustration.
Bill Gates Hacks Security System
This week's issue of Time Magazine reports that Bill Gates hacked a security system at age 13. One of our staff investigators was intrigued enough to dig further into the story, and soon discovered that the security system in question was in fact one that Bill had written when he was 12. He managed to hack his way into his own system just under one year, a remarkable programming feat for the young Future Richest Man. One apocryphal version of the story claims that Bill finally cracked the system by accidentally turning over his mouse pad and finding the password he'd forgotten the year before, but the reality is that nobody still alive today knows how he did it. However, our investigative reporter did uncover one amazing twist to the story that should firmly cement Bill in programming legend, with concrete shoes of programming glory. The surprise twist: the little security system that Bill wrote at age 12 and hacked into a year later is still in production today, in Windows Vista.
MyTube Having Growth Difficulties
Ted Turner's highly anticipated MyTube™ social network for men is having sizing problems, according to media analysts. The new social networking site is Turner Broadcasting's answer to Oprah Winfrey's highly acclaimed and successful Oxygen television network aimed at young women. Unfortunately, MyTube, which is implemented entirely in Ruby on Rails, is hitting a scaling barrier at peak usage hours, which are reportedly between midnight and 2am PST. An insider at MyTube tells us confidentially that they get up to 100 users before the system slows to a crawl, causing bored users to delete random files from their servers by requesting well-formed URLs like http://mytube.com/database/delete and http://mytube.com/debugger/start. "It's just so rude", MyTube engineers were overheard saying in their Atlanta office. "Some of our users are just plain wankers."
Fundamental Computer Science Discovery
Computer Scientists around the world have been reeling in shock, the stir caused by a quiet publication in the latest Communications of the ACM. The ACM article that has everyone buzzing was submitted by an anonymous software engineer at an undisclosed Seattle-area software company. The engineer has formulated a proof that invalidates one of the most fundamental results in Computer Science, specifically that "recursion" and "iteration" are formally equivalent. The new proof by counterexample is simple, compelling, and undeniable, and theorists are said to be furiously scratching themselves over the proof's implications, which are far-reaching enough to impact virtually all computer-automated industries, from aerospace technology through zooospace engineering. The anonymous author of the paper has found that there is in fact one thing you can do using recursion that you can't do using iteration, namely: "You can use it to weed out stupid fugging interview candidates."
Dyson Unveils the iSuck™ Personal Vacuum Assistant
Dyson Corporation announced today their latest innovation, a mobile handheld vacuum cleaner the size of a flashlight, dubbed the "iSuck". Dyson's spokesperson was quoted as saying that although the device was originally targeted at the middle-aged housewife demographic, the iSuck has turned out to be unexpectedly popular with men of all ages and demographics. Pundits speculate that the iSuck has finally achieved a form factor that entices men to do their own housecleaning. Dyson claims that based on extensive early user feedback, new versions of the iSuck are planned for near-term release, including a unit that doesn't dampen the motor vibrations (we assume this is to increase battery life), a wet/dry vac, and a limited edition run titled "The Patriot", which hums the U.S. National Anthem as it operates, expected to be popular aboard U.S. Navy ships for vacuuming those hard-to-reach nooks and crannies. Dyson's shares soared on the news, with analyists recommending that Dyson milk every drop from their innovative new product.
Polling baru
Beberapa hari yang lalu saya menambahkan polling lagi di blog ini.Sebelumnya sudah ada polling bagaimana tanggapan anda tentang matematika, nah polling yang saya tambahkan kali ini adalah tentang pendapat ada tentang blog ini.Walaupun baru kurang dari 10 orang yang memberikan suaranya mengenai blog ini ( 1 September 2007 ), tetapi kelihatannya suara yang masuk mengisyaratkan blog ini memiliki
Selasa, 28 Agustus 2007
Kunci Jawaban Matriks
Kunci Jawaban Matriks1. C2. C3. A4. C5. B6. D7. B8. ?Mohon koreksinya jika ada kunci jawaban yang salah (matematika3sma@gmail.com)
Soal Matriks
Diatas adalah salah satu contoh soal matriks pada Ujian Nasional.Seperti biasanya saya kesulitan untuk menampilkan soal - soal yang menggunakan microsoft equation, begitu juga pada soal matriks. hanya ada 7 soal yang muncul untuk materi matriks pada ujian nasional (2000-2007).kalau anda butuh soal ini dalam bentuk microsfot word, anda dapat menghubungi email saya di matematika3sma@gmail.com
Jumat, 24 Agustus 2007
Kunci Jawaban Integral
Kunci Jawaban Integral1. D2. E3. C4. D5. B6. C7. D8. D9. C10. C11. A12. A13. A14. A15. C16. B17. C18. D19. C20. D21. B22. A23. E24. D25. B26. C27. D28. D29. D30. C31. C32. ?Mohon koreksinya jika ada kunci jawaban yang salah (matematika3sma@gmail.com)
Senin, 20 Agustus 2007
Terima kasihku
Sudah 3 hari tidak membuka internet, terakhir kali mencoba mencari blog ini lewat kata kunci matematika sma saya mendapatinya dihalaman ke-6.Hari ini ( 20 agustus 2007 ) saya coba buka kembali dengan kata kunci yang sama, eh ternyata sudah ada di halama pertama.Wah ternyata semakin hari blog ini semakin mendapat apresiasi dari para netter, jadi terima kasih atas kunjungannya ke blog ini, dan saya
Jumat, 17 Agustus 2007
How To Make a Funny Talk Title Without Using The Word "Weasel"
I haven't blogged in a while. So much fun stuff going on! You have no idea. Fun! This blog entry is a bit overdue, though, and my muse hasn't visited me lately, so I'll just wing it tonight and hope for the best.
OK. So branding. Yeah. Branding. A couple weeks ago, I gave a keynote talk at O'Reilly's OSCON. Nat Torkington, the world-famous co-author of the Perl Cookbook, was kind enough to invite me to be a keynote speaker. I don't know what he was smoking, but it must have been really good stuff. I'm still jealous.
But wait, it gets even better. He had me scheduled at some godawful hour, like 9:45am or something. So I naturally assumed -- this being a programmer's conference and all -- that I was essentially one of those crap garage bands that just barely make the cut for Bumbershoot and get slotted on Friday morning before anyone actually shows up. Fine. So I'm filler. I can live with that. In any case I haven't been to Portland in a while; maybe I can grab some of their famous oysters while I'm there.
Nat wants a title for my talk. Crap. That means I have to commit to something. Uh. I'm going to talk about... ummm... not sure. He says he wants me to be funny. Just like in Finding Nemo. "You're a clownfish! Say something funny!" OK. Funny. Oh, and he wants it to be educational too. Funny and educational. Hm. Like slamming your hand in the car door, I guess. No, on second thought, that's only funny years later, and only to other people, whereas Nat wants me to be funny, like, right there on stage.
Well, pretty much anything can be funny, as long as it happens to someone else. Yeah. Funny happens to other people. So what's happened lately to people I know?
Let's see... I'd just gotten back from Foo Camp, after all that embarrassing Rails-clone hype (-- I mean, jeez, it's about a year premature; thanks, John! --) and I saw some interesting talks there. Any material worth rehashing? Oooh, there was that Open Source Attack one. Yeah, that one. What was up with that?
See, like, here's the deal: Foo Camp is... hot. Damn hot. O'Reilly's headquarters are in Sebastopol, CA, which is like one stop from Hell's Gates. I mean, don't get me wrong -- Foo Camp was really fun. Tim O'Reilly is definitely one of the World's Coolest People just for throwing a big free party and inviting people to come and partake of the free food and open bar and brilliant company.
Hell, it was almost like weekdays at Google.
But if I'd known how hot it was going to be, I'd have... I'm not sure what I'd have done, except maybe bring a pair of shorts and a bigger tent. Oh, and maybe lost some weight? Possibly, possibly. At any rate, it was hot there, and I was pretty miserable at least half the time, me being from Seattle and all. I know. Wuss.
So on the third day, I'm wandering around, and all the sessions are dying down, but there's one talk going in the ONLY room that apparently has some form of air conditioning on the ground floor. It also has network access, so people are in there with their laptops. Sounds good. Maybe I can read mail. So I'm sitting there minding my own business when I suddenly find myself listening to a talk from the OSI folks called "The Attack on Open Source".
If nothing else, it was reminiscent of Star Wars, so I listened in.
The gist of their talk is pretty simple: we forgot to trademark the term "Open Source", blah blah BLAH; Richard Stallman isn't the creator of Open Source, hah hah HAH; companies are using our term to apply to closed-source software, wah wah WAH. What can we do about it?
Send letters. That was their solution. Have all the "real" open-source licensors "federate" (a nice technical term for a riled-up, impotent mob) and then send angry letters to offenders, and nice letters to non-offenders. Or something along those lines. Who's up for it? Will you help us out?
They passed around a little pledge-your-support sheet. I put my name on it, since it seemed like the thing to do at the time. Plus there were, like, actually cool people in the room, and having my name on the same sheet seemed like the thing to do. Just in case that little sign-up sheet becomes the next millenium's Declaration of Independence or something. I wrote my name kinda big, so I could be, like, John Hancock, except without his overtly phallic name.
Someone at the talk suggested maybe making, like, a new name, one that could be trademarked and protected and stuff. I forget who suggested it, but they were whipped like a mangy cur for the suggestion, and it died right there. I almost did too, since the room was still pretty hot, and at Foo Camp when someone's giving a talk that sucks, it's kind of hard to escape politely. Not that their talk sucked, mind you -- it was their conclusion that sucked -- but once you've passed the 10-minute mark you're pretty much stuck until they stop talking.
Me? I was all for changing the name. What the hell does Open Source mean, anyway? It seems like the term has been gradually deteriorating since the 1980s when people would release "shareware", which soon became called "crippleware", which of course pretty much killed it dead. Crippleware. Nasty name. Nasty marketing tactic. Brilliant, but nasty.
Shame, I guess. I'm not sure why the whole try-before-you-buy concept never made it in software. Maybe for the same reason runtime-elevatable mountain bike seats never made it in the mountain biking circuit. When you're riding a mountain bike, you want the seat low for balance and high for power, so ideally you want it low going downhill and high going uphill. So someone invented a seat that could change its height while you were riding, and how did it do? It failed miserably! The pro riders took one look at it and said: "hey, nice seat. I was thinking of getting one for my girlfriend." Ouch. Like I'm gonna buy one now.
Marketing. It's not the banner ads. It's what your friends are saying.
So, like, here I am, trying to think of a title for my OSCON talk, and I keep thinking about that "Attack on Open Source" Foo Camp discussion, and the poor sorry OSI folks who are fighting to keep their beach from eroding in the midst of history's largest tsunami. Or something. I mean, if it's not trademarked, and you can't protect it legally, and it's just two vanilla words concatenated, then you're screwed: evil companies can jump on the buzzwagon and say their stuff is "Open Source", when it is, in fact, proprietary and you can't get the source code.
I mean, who's to stop them? So that's exactly what's happening. At least, so say the OSI folks, and I believe them.
Problem is, "Open Source" has no definition. There was a certain amount of respectful sour-graping going on at this Foo Camp talk I was at, because (as they pointed out quite sour-grapey-respectfully), Richard Stallman did a bang-up outstanding job of defining what "Free Software" actually means from a philosophical and legal perspective. It might not be exactly what the OSI folks want, but it's clear as day.
"Open Source", on the other hand, means... uh, it means you take this betrothed, er, beloved... uh, source... damn. It's like trying to remember the Ten Commandments. Thou Shalt Not Leave Foo Camp Talks Halfway Through, Lest Thee Not Be Invited Back.
That's roughly when some random synapse or other fired and reminded me of a book my friends Jacob Gabrielson and Jeff Peterson had been waving in my face about 15 years ago, called The 22 Immutable Laws of Branding. I don't know why, but it just popped into my head.
See, they (the OSI folks, that is) were breaking not just one, but several of those Immutable Laws. I'd read the book one time, fifteen years prior, but you can't fool me: I know what immutable means. It means you can't mute it. These laws were just screaming not to be broken.
So I decided, then and there, with me not knowing Jack Squat about marketing, to do my OSCON presentation on marketing.
Yeah. Well, I knew more about it than YOU do, because I've read exactly one marketing book, and you've read exactly zero. Right? (People: when I say "you", I'm using the collective "you", which if "you" will recall, means some fuzzy statistical aggregate. So please, if "you" want to email "me" about how "you" have actually read TWO marketing books, I would appreciate it if "you" would just keep that wonderful factoid to "your" self. Thanks!)
OK, great. What title to use? I'll be honest. I confess. My original title, funny as it was, was not as funny as my beta-tested replacement. See, I sent Nat the proposed title How to Ignore Marketing and Become Irrelevant in Five Easy Steps. That summed it up pretty well, and the Five Easy Steps part gave me some wiggle room about what specific sub-topics I'd talk about. I had no idea what they were, but I needed some Wiggle Room, by which I mean Procrastination Material.
Later, I was driving to Foo Camp (from the nearest airport, which is conveniently located six hundred miles away) with my buddy Greg Linden, telling him about my talk-title dilemma, and as I was saying it, it dawned on me that I really needed to make it two easy steps. If I have to explain why it's funnier, well, just take my word for it. It is. Greg laughed and laughed, and after we had established that he wasn't laughing at, say, something funny he'd just thought of, or at a sign we'd just passed, or my haircut or something, I decided: hey, that's my new talk title.
So I mailed Nat and Vee and begged them to change it. And they did!
Now you know how I came up with such a wacky idea for a keynote talk.
The rest is history. I went to the conference, along with some three thousand other geeks. It was fun. I loved Larry Wall's late-evening talk on Perl 6. He's quite the entertaining speaker. I even got a chance to talk to him that night at some party we were both invited to. I was embarrassed, for reasons you Perl folks will likely understand without explanation. I apologized. He graciously said it was no big deal. (Thanks, Larry. I can die in peace now. Or someday far from now, preferably.)
I showed up late to my talk, since, hey, I was the crap garage band, remember?
Whoops. It turns out Nat had me scheduled LAST. There were like four or five keynote speakers before me. Imagine that! Tim O'Reilly managed to get three thousand programmers to wake up at 7am. There must have been some sort of measurable blip on our GNP over the next week.
So I show up with my laptop on Thursday at about 9:00am, and I walk up to the registration booth hoping I can sneak in without a ticket. I tell them I'm a keynote speaker, and ask where I'm supposed to go.
People start talking into hidden microphones. "Mr. Yegge is here." I look around for my dad, and realize they're talking about me. A sharp-dressed dude at the registration booth stands up to take me to who-knows-where. He walks past me, stops, looks me up and down with the exact same expression the restaurant waiters in Paris used on me, and he says...
(I'm not making this up, by the way...)
"I see you have more of a sense of STYLE than MOST of the people here!"
I laugh uproariously. Wow. All I can say in my defense is: it wasn't a high bar.
Then he turns on his heel, marches me up to the second floor, and never once looks at me again.
Without looking my way, he marches me through a big crowd that's listening to the current keynote speaker, some economist who's ending his talk with "so you all SUCK, and you're all ASSHOLES too", or something along those lines. I'm not really 100% listening, but that's sure what it sounds like.
Note to self: be nice to crowd.
The Style Guy, without looking at me, walks me right past the front row, past the black-velvet-clothed stage and giant blue screens (of death, as it turns out), and right past the curtain in the back. We go through this weird back-alley hallway reminiscent of the movie Jacob's Ladder. The hospital scene. Yeah, that one. I start to get kinda nervous. I'd made some slides the night before, but this seems a bit more, um, serious than I'd originally imagined it.
We sneak through another door, and suddenly I'm behind the stage. There are two technicians there, and Parisian-Waiter Style Guy hands me off to them. They whisper at me: "do you have slides?" Yes. "What kinda computer?" Mac. "Good! We'll set you up!"
Yeah.
Some other tech materializes with a microphone and they hook me up. I accidentally start to straighten up (I've been stooping), and they all gesture violently at me for me to start stooping again, because if I stand up straight my head gets in the way of the rear projector and everyone in the crowd can see me.
Yikes. What if the microphone's already on? Oh no, what if I fart? Did I fart? I'm not sure. It's certainly possible, in theory. I'm not accustomed to this show-business stuff. They hook me up and tell me to bring my laptop to the podium when my talk starts, and then they tell me to go wait in the front row. On my way out of the weird, tiny little behind-the-stage AV room, they hand me a dongle that says "I stole this" or something like that. It's a Mac DVI connector. They say I need to bring it with me.
OK.
So I sneak out the door and back around the curtain, ducking, and practically crawl to the front row. I sit down. The economist finishes reviling the crowd, leaves in a smattering of tentative applause, and some Microsoft dude comes up to talk about how great Microsoft's open-source contributions are.
That one goes pretty fast.
Suddenly I notice a technician-type dude sneaking up to me. He whispers that my microphone isn't set up right, and he changes it for me. Hey, he's a tech. He could have said my pilfer grommit wasn't connected to my weasel pin, and I'd believe him. He fiddles with the thing clipped to my shirt. After sufficient fiddling, as defined by him, he leaves.
The next guy is from Sweden (I think), and he's talking about the Pirate Party. It's a great talk. Not only is he a good speaker with a compelling, well-written presentation, but the material itself is also fascinating. People in the crowd start to pay attention.
I'm not sure when I'm up, but I see Nat get up there in his shorts and Hawaiian shirt, and he starts talking about the next speaker. To be safe, I assume it's me, and I look for my dongle.
Oh god, my dongle is gone. I swear, I had it before that sneaky technician showed up, and now it's gone. Nat talks on, blah blah blah, and I'm digging frantically through my backpack. Nothing. It's gone. The technician must have grabbed it inadvertently on his way out.
I vow silently to get up earlier next time.
Nat finishes his preamble, which by the way is brilliant in its simultaneous hopefulness and not-my-fault-if-he-sucks hedging, and it's time for me to stride confidently up to the stage.
Without my dongle.
I get to the podium, shake hands or something, and a technician materializes with a dongle. I give him my laptop and hope for the best.
Nat leaves.
A thousand people are looking at me and the technician expectantly.
My slides aren't working.
Cool.
So what would YOU do?
Here's what I did: http://blip.tv/file/319044/
Tune in next week for the exciting conclusion of "Hey, you're a Clownfish! Say Something Funny!"
I can't wait. :)
OK. So branding. Yeah. Branding. A couple weeks ago, I gave a keynote talk at O'Reilly's OSCON. Nat Torkington, the world-famous co-author of the Perl Cookbook, was kind enough to invite me to be a keynote speaker. I don't know what he was smoking, but it must have been really good stuff. I'm still jealous.
But wait, it gets even better. He had me scheduled at some godawful hour, like 9:45am or something. So I naturally assumed -- this being a programmer's conference and all -- that I was essentially one of those crap garage bands that just barely make the cut for Bumbershoot and get slotted on Friday morning before anyone actually shows up. Fine. So I'm filler. I can live with that. In any case I haven't been to Portland in a while; maybe I can grab some of their famous oysters while I'm there.
Nat wants a title for my talk. Crap. That means I have to commit to something. Uh. I'm going to talk about... ummm... not sure. He says he wants me to be funny. Just like in Finding Nemo. "You're a clownfish! Say something funny!" OK. Funny. Oh, and he wants it to be educational too. Funny and educational. Hm. Like slamming your hand in the car door, I guess. No, on second thought, that's only funny years later, and only to other people, whereas Nat wants me to be funny, like, right there on stage.
Well, pretty much anything can be funny, as long as it happens to someone else. Yeah. Funny happens to other people. So what's happened lately to people I know?
Let's see... I'd just gotten back from Foo Camp, after all that embarrassing Rails-clone hype (-- I mean, jeez, it's about a year premature; thanks, John! --) and I saw some interesting talks there. Any material worth rehashing? Oooh, there was that Open Source Attack one. Yeah, that one. What was up with that?
See, like, here's the deal: Foo Camp is... hot. Damn hot. O'Reilly's headquarters are in Sebastopol, CA, which is like one stop from Hell's Gates. I mean, don't get me wrong -- Foo Camp was really fun. Tim O'Reilly is definitely one of the World's Coolest People just for throwing a big free party and inviting people to come and partake of the free food and open bar and brilliant company.
Hell, it was almost like weekdays at Google.
But if I'd known how hot it was going to be, I'd have... I'm not sure what I'd have done, except maybe bring a pair of shorts and a bigger tent. Oh, and maybe lost some weight? Possibly, possibly. At any rate, it was hot there, and I was pretty miserable at least half the time, me being from Seattle and all. I know. Wuss.
So on the third day, I'm wandering around, and all the sessions are dying down, but there's one talk going in the ONLY room that apparently has some form of air conditioning on the ground floor. It also has network access, so people are in there with their laptops. Sounds good. Maybe I can read mail. So I'm sitting there minding my own business when I suddenly find myself listening to a talk from the OSI folks called "The Attack on Open Source".
If nothing else, it was reminiscent of Star Wars, so I listened in.
The gist of their talk is pretty simple: we forgot to trademark the term "Open Source", blah blah BLAH; Richard Stallman isn't the creator of Open Source, hah hah HAH; companies are using our term to apply to closed-source software, wah wah WAH. What can we do about it?
Send letters. That was their solution. Have all the "real" open-source licensors "federate" (a nice technical term for a riled-up, impotent mob) and then send angry letters to offenders, and nice letters to non-offenders. Or something along those lines. Who's up for it? Will you help us out?
They passed around a little pledge-your-support sheet. I put my name on it, since it seemed like the thing to do at the time. Plus there were, like, actually cool people in the room, and having my name on the same sheet seemed like the thing to do. Just in case that little sign-up sheet becomes the next millenium's Declaration of Independence or something. I wrote my name kinda big, so I could be, like, John Hancock, except without his overtly phallic name.
Someone at the talk suggested maybe making, like, a new name, one that could be trademarked and protected and stuff. I forget who suggested it, but they were whipped like a mangy cur for the suggestion, and it died right there. I almost did too, since the room was still pretty hot, and at Foo Camp when someone's giving a talk that sucks, it's kind of hard to escape politely. Not that their talk sucked, mind you -- it was their conclusion that sucked -- but once you've passed the 10-minute mark you're pretty much stuck until they stop talking.
Me? I was all for changing the name. What the hell does Open Source mean, anyway? It seems like the term has been gradually deteriorating since the 1980s when people would release "shareware", which soon became called "crippleware", which of course pretty much killed it dead. Crippleware. Nasty name. Nasty marketing tactic. Brilliant, but nasty.
Shame, I guess. I'm not sure why the whole try-before-you-buy concept never made it in software. Maybe for the same reason runtime-elevatable mountain bike seats never made it in the mountain biking circuit. When you're riding a mountain bike, you want the seat low for balance and high for power, so ideally you want it low going downhill and high going uphill. So someone invented a seat that could change its height while you were riding, and how did it do? It failed miserably! The pro riders took one look at it and said: "hey, nice seat. I was thinking of getting one for my girlfriend." Ouch. Like I'm gonna buy one now.
Marketing. It's not the banner ads. It's what your friends are saying.
So, like, here I am, trying to think of a title for my OSCON talk, and I keep thinking about that "Attack on Open Source" Foo Camp discussion, and the poor sorry OSI folks who are fighting to keep their beach from eroding in the midst of history's largest tsunami. Or something. I mean, if it's not trademarked, and you can't protect it legally, and it's just two vanilla words concatenated, then you're screwed: evil companies can jump on the buzzwagon and say their stuff is "Open Source", when it is, in fact, proprietary and you can't get the source code.
I mean, who's to stop them? So that's exactly what's happening. At least, so say the OSI folks, and I believe them.
Problem is, "Open Source" has no definition. There was a certain amount of respectful sour-graping going on at this Foo Camp talk I was at, because (as they pointed out quite sour-grapey-respectfully), Richard Stallman did a bang-up outstanding job of defining what "Free Software" actually means from a philosophical and legal perspective. It might not be exactly what the OSI folks want, but it's clear as day.
"Open Source", on the other hand, means... uh, it means you take this betrothed, er, beloved... uh, source... damn. It's like trying to remember the Ten Commandments. Thou Shalt Not Leave Foo Camp Talks Halfway Through, Lest Thee Not Be Invited Back.
That's roughly when some random synapse or other fired and reminded me of a book my friends Jacob Gabrielson and Jeff Peterson had been waving in my face about 15 years ago, called The 22 Immutable Laws of Branding. I don't know why, but it just popped into my head.
See, they (the OSI folks, that is) were breaking not just one, but several of those Immutable Laws. I'd read the book one time, fifteen years prior, but you can't fool me: I know what immutable means. It means you can't mute it. These laws were just screaming not to be broken.
So I decided, then and there, with me not knowing Jack Squat about marketing, to do my OSCON presentation on marketing.
Yeah. Well, I knew more about it than YOU do, because I've read exactly one marketing book, and you've read exactly zero. Right? (People: when I say "you", I'm using the collective "you", which if "you" will recall, means some fuzzy statistical aggregate. So please, if "you" want to email "me" about how "you" have actually read TWO marketing books, I would appreciate it if "you" would just keep that wonderful factoid to "your" self. Thanks!)
OK, great. What title to use? I'll be honest. I confess. My original title, funny as it was, was not as funny as my beta-tested replacement. See, I sent Nat the proposed title How to Ignore Marketing and Become Irrelevant in Five Easy Steps. That summed it up pretty well, and the Five Easy Steps part gave me some wiggle room about what specific sub-topics I'd talk about. I had no idea what they were, but I needed some Wiggle Room, by which I mean Procrastination Material.
Later, I was driving to Foo Camp (from the nearest airport, which is conveniently located six hundred miles away) with my buddy Greg Linden, telling him about my talk-title dilemma, and as I was saying it, it dawned on me that I really needed to make it two easy steps. If I have to explain why it's funnier, well, just take my word for it. It is. Greg laughed and laughed, and after we had established that he wasn't laughing at, say, something funny he'd just thought of, or at a sign we'd just passed, or my haircut or something, I decided: hey, that's my new talk title.
So I mailed Nat and Vee and begged them to change it. And they did!
Now you know how I came up with such a wacky idea for a keynote talk.
The rest is history. I went to the conference, along with some three thousand other geeks. It was fun. I loved Larry Wall's late-evening talk on Perl 6. He's quite the entertaining speaker. I even got a chance to talk to him that night at some party we were both invited to. I was embarrassed, for reasons you Perl folks will likely understand without explanation. I apologized. He graciously said it was no big deal. (Thanks, Larry. I can die in peace now. Or someday far from now, preferably.)
I showed up late to my talk, since, hey, I was the crap garage band, remember?
Whoops. It turns out Nat had me scheduled LAST. There were like four or five keynote speakers before me. Imagine that! Tim O'Reilly managed to get three thousand programmers to wake up at 7am. There must have been some sort of measurable blip on our GNP over the next week.
So I show up with my laptop on Thursday at about 9:00am, and I walk up to the registration booth hoping I can sneak in without a ticket. I tell them I'm a keynote speaker, and ask where I'm supposed to go.
People start talking into hidden microphones. "Mr. Yegge is here." I look around for my dad, and realize they're talking about me. A sharp-dressed dude at the registration booth stands up to take me to who-knows-where. He walks past me, stops, looks me up and down with the exact same expression the restaurant waiters in Paris used on me, and he says...
(I'm not making this up, by the way...)
"I see you have more of a sense of STYLE than MOST of the people here!"
I laugh uproariously. Wow. All I can say in my defense is: it wasn't a high bar.
Then he turns on his heel, marches me up to the second floor, and never once looks at me again.
Without looking my way, he marches me through a big crowd that's listening to the current keynote speaker, some economist who's ending his talk with "so you all SUCK, and you're all ASSHOLES too", or something along those lines. I'm not really 100% listening, but that's sure what it sounds like.
Note to self: be nice to crowd.
The Style Guy, without looking at me, walks me right past the front row, past the black-velvet-clothed stage and giant blue screens (of death, as it turns out), and right past the curtain in the back. We go through this weird back-alley hallway reminiscent of the movie Jacob's Ladder. The hospital scene. Yeah, that one. I start to get kinda nervous. I'd made some slides the night before, but this seems a bit more, um, serious than I'd originally imagined it.
We sneak through another door, and suddenly I'm behind the stage. There are two technicians there, and Parisian-Waiter Style Guy hands me off to them. They whisper at me: "do you have slides?" Yes. "What kinda computer?" Mac. "Good! We'll set you up!"
Yeah.
Some other tech materializes with a microphone and they hook me up. I accidentally start to straighten up (I've been stooping), and they all gesture violently at me for me to start stooping again, because if I stand up straight my head gets in the way of the rear projector and everyone in the crowd can see me.
Yikes. What if the microphone's already on? Oh no, what if I fart? Did I fart? I'm not sure. It's certainly possible, in theory. I'm not accustomed to this show-business stuff. They hook me up and tell me to bring my laptop to the podium when my talk starts, and then they tell me to go wait in the front row. On my way out of the weird, tiny little behind-the-stage AV room, they hand me a dongle that says "I stole this" or something like that. It's a Mac DVI connector. They say I need to bring it with me.
OK.
So I sneak out the door and back around the curtain, ducking, and practically crawl to the front row. I sit down. The economist finishes reviling the crowd, leaves in a smattering of tentative applause, and some Microsoft dude comes up to talk about how great Microsoft's open-source contributions are.
That one goes pretty fast.
Suddenly I notice a technician-type dude sneaking up to me. He whispers that my microphone isn't set up right, and he changes it for me. Hey, he's a tech. He could have said my pilfer grommit wasn't connected to my weasel pin, and I'd believe him. He fiddles with the thing clipped to my shirt. After sufficient fiddling, as defined by him, he leaves.
The next guy is from Sweden (I think), and he's talking about the Pirate Party. It's a great talk. Not only is he a good speaker with a compelling, well-written presentation, but the material itself is also fascinating. People in the crowd start to pay attention.
I'm not sure when I'm up, but I see Nat get up there in his shorts and Hawaiian shirt, and he starts talking about the next speaker. To be safe, I assume it's me, and I look for my dongle.
Oh god, my dongle is gone. I swear, I had it before that sneaky technician showed up, and now it's gone. Nat talks on, blah blah blah, and I'm digging frantically through my backpack. Nothing. It's gone. The technician must have grabbed it inadvertently on his way out.
I vow silently to get up earlier next time.
Nat finishes his preamble, which by the way is brilliant in its simultaneous hopefulness and not-my-fault-if-he-sucks hedging, and it's time for me to stride confidently up to the stage.
Without my dongle.
I get to the podium, shake hands or something, and a technician materializes with a dongle. I give him my laptop and hope for the best.
Nat leaves.
A thousand people are looking at me and the technician expectantly.
My slides aren't working.
Cool.
So what would YOU do?
Here's what I did: http://blip.tv/file/319044/
Tune in next week for the exciting conclusion of "Hey, you're a Clownfish! Say Something Funny!"
I can't wait. :)
Langganan:
Postingan (Atom)