Digital Tumbleweed

Recently I added another slice to my list of servers but whenever I add slices on Slicehost with Ubuntu, they come with the locale problem. You might recognize it. The following shows up in almost ever source compile you do (frustration mounts):

 

 

Then, after reading the error you see that it doesn't even have en_US installed! *GRAH* Well, there is a simple solution. In my case I use en_US, but if you use something different then make sure you specify it.

 

This should fix the problem. To see what your system is set to use, you can do the following: locale

It will spit out something like this:

 

 

Hope it helps.

This AM I was attempting to update my existing version of Choqok and received an error. I thought I'd share since it did take a couple of minutes to find a solution for fixing. Dependencies:

• I'm running Kubuntu Karmic, that's the KDE Ubuntu 9.10
• I pulled the latest Choqok on Gitorious which is where I hit my issue.

The concepts will likely work elsewhere, but not within the nice packages provided in aptitude. The Problem

 

 

Short Fix Use aptitude

 

 

Long Fix Use apt-get

 

 

Now, reinstall the libraries that were uninstalled.

 

 

Fin

The basic idea here was to reinstall the libqt4-phonon-dev library. This made it so that the include files were back in place and I could compile source code. Now, you should be able to continue compiling your phonon based source. In this case, as stated above, I was compiling Choqok. But, I doubt this issue is relegated solely to Choqok compilations. I just haven't yet had the opportunity to compile other KDE4 based apps on Karmic Kubuntu.

 

I'm ideating a method proposition to add enterprise grade value which will synergize your verticals. *cringe* Hold on a second...I need to go wash off the dirty. In all of what I typed above, I didn't actually tell you _anything_. But, what you expect now is some thing that should make your things work well together. Why don't we just say that? Because people expect exact answers and the above sounds more like an exact answer! Keep in mind that most places wont do anything nearly as drastic as what I posted above. Where To Begin? Buzz words suck. Often times these words start as a way to differentiate products and/or services. While grande, buzz words tend to lose their meaning when _everything_ and/or _everyone_ uses them. When people adopt them on a large scale you're not actually saying anything. Most people can get the gist of what you're attempt to say because most people have a brain that works reasonably well, at the very least better than this weasel. However, you lose credibility when you start throwing those kinds of words around. I've been, for a while now, trying to figure out why they are so popular. I'm not sure where it started. The main reasons for using them, that I can think of, are differentiation and filler. Differentiation The attempt to be different. This works out reasonably well when you're the first person/company to say that you are an "enterprise" solution. But, when every competitor uses the term, SURPRISE, you're no longer different. Or are you? What about the feature you can create a pony out of thin air? I'd say that likely differentiates you, wouldn't you? Stick to the features and to your capabilities. Those should be what differentiates you. Filler If you find yourself with a lack of descriptors then use the ones you can think of. When you "innovate" in the market, what are you really doing? People thirst for information so give it to them. You don't need to ramble on, but providing some detail is a great teaser. The movie industry uses teasers to pique your interest. You should do the same. Additionally, using buzz words doesn't make you sound any more intelligent. In fact, it often does the opposite because you aren't providing substance. More Proof If you need more proof that buzz words are everywhere and how irritating they can be. Sit at your next "all hands" type of meeting. Listen to the specific words being used. You'll notice that a lot of these phrases aren't really telling you much. It's almost like eating at McDonald's, you might get something that resembles a message, but really all your getting is an ill feeling in your stomach. Try playing games like buzz word bingo. Another that I've played is to come up with a list of words and assign points to those words. Each person picks a word they think will provide the most points. Give each person a word to tally and then collect the tallies at the end. Multiply the tallies for the word by it's value and those are the total points. Once you have the totals you send them out. The prizes are your choice, I tend to prefer a free lunch, but it at least makes the 1-2 hour snore fest more exciting. The point is that you'll find out just how many buzz words and phrases are used to try and pitch you information and direction. Where To Go From Here Well, I'm certain I've used buzz words in the past. With so many floating around, it's bound to happen. Fret not, you can stop using them and gain back your credibility. Make a conscious effort to stop using them and give the terms meaning again. Also, you'll be generating more intelligent conversation. This, to me, seems like a positive. Suggestions You may be able to get a clearer picture of exactly what I'm talking about with some examples. So, here are some off the top of my head.

• Enterprise - We can handle a lot of [users|documents|<insert noun>]. When you say this you'll need some statistics. So have them ready.
• Web 2.0 - Our web application is primarily built using Javascript, AJAX, and some aesthetically please designs. We are also standards compliant.
• Synergy - Our product works well with <insert other technology>. Or, this will allow <X> to work well with <Y>.
• Best of breed - We've used <X> technology. This gives us the ability to do <Y>.
• Leaders in - Hmm... No you aren't. Just accept it now and get over this phrase. KTHXBI.

Authenticity One thing I touched on above was authenticity. When you stop using gibberish in your messages you gain credibility. People start to listen to your messages because they are gaining something from it. If you are interested in some ways to approach this take a look at Personality Not Included. I read this some time ago and really liked much of what Rohit had to say. Go Forth Go now and conquer! Take out those editors, rewrite those presentations, press releases and websites. Get the word out that you wont put up with buzz words anymore. And, if someone tries to push you into it, you can always threaten them.

At Axiom Software we're working on the next release of SEOversite. It's been exciting. This is basically a tutorial on debugging the Apache HTTPd side of things (keep in mind that this is as much an informational thing for you as it is a reminder for me. I assume that I'm going to have to re-read this at some point). Background In production, we've been using Apache on Ubuntu Server. This has worked out well seeing as aptitude rocks pretty hard. But, we run into some issues doing debugging and profiling. It's easier to have the code all within one place, so for development purposes we're pulling the source so that we can specify the configuration and compiler options for Apache. Debugging What other tool do you use to debug C code than the GDB? With any language you need a way to be able to properly debug your code and usually print statements just don't get it done. So, why stop at the ability to print out from the code when you can actually step into your functions, print out variables, and see back traces. With normal C applications you can simply just load the binaries into GDB: # gdb <binary> This doesn't quite work in our setup though. We are in the situation where we need to debug modules, not just Apache. And, to really be able to step into the code we need to compile it appropriately. When we're dealing with setting up our module for debugging we need to make sure we pass in the -g flag. The -g flag just makes it so that your code can be debugged with gdb. So, we have our module which we'll call seoversite.c. We're looking to debug so our build looks something like this: ~/seoversite/# /opt/apache/bin/apxs -ci -Wc,-g seoversite.c This turns on debugging within the binary which means that we are letting GDB process the source of our file. With apxs, the -Wc, flag allows you to pass compiler flags along for when your code is actually built. We then have a really simple startup for GDB. /opt/apache/# gdb bin/httpd As soon as this fires we get a prompt that lets us specify what we want to do. Today I was debugging a simple method that processes a URL so I'll go through some of that. When we start up gdb we're presented with a prompt. This is where we need to enter some input. (gdb) b get_fullurl Function "get_fullurl" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (get_fullurl) pending. Because our module is shared, gdb doesn't find the method signatures right away. That's ok. We'll wait till they load on the request. Basically, the above puts a breakpoint on the method call get_fullurl. Thus, any code paths that use get_fullurl will halt activity until processed in gdb. So, we start the server. (gdb) run -X Starting program: /opt/apache/bin/httpd -X [Thread debugging using libthread_db enabled] [New Thread 0x7fce2930d760 (LWP 14174)] warning: Temporarily disabling breakpoints for unloaded shared library "/opt/apache/modules/seoversite.so" [Switching to Thread 0x7fce2930d760 (LWP 14174)] The command we typed was "run -X" meaning, start the binary with these command line options. -X is the debugging flag for Apache. So, we're telling it to start Apache HTTPd in debug mode. This is what we want. It tells you that it'd loading a shared library and is going to disable the breakpoints while it loads. Afterward it enables the breakpoints you've defined. At this point, because our code is dependent on a request, we should make one. I hit a virtual host url that is setup to use our module and immediately see that our method is hit. Breakpoint 1, get_fullurl (ctx=0x19d4908, use_base=0, args=1) at seoversite.c:330 330 if (use_base) { This isn't entirely useful information. I know where my method starts. However, we aren't limited to just this information. Let's say that I want to see the back trace of method calls that got me to this method. (gdb) bt #0 get_fullurl (ctx=0x19d4908, use_base=0, args=1) at seoversite.c:330 #1 0x00007fce2402299a in filtering (f=0x19cba78, bb=0x19d0298) at seoversite.c:1739 #2 0x000000000044f446 in ap_pass_brigade () #3 0x000000000047b2ed in ap_proxy_http_process_response () #4 0x000000000047bad0 in proxy_http_handler () #5 0x000000000046af37 in proxy_run_scheme_handler () #6 0x0000000000467524 in proxy_handler () #7 0x0000000000441450 in ap_run_handler () #8 0x0000000000441ce9 in ap_invoke_handler () #9 0x000000000048823c in ap_process_request () #10 0x00000000004851f0 in ap_process_http_connection () #11 0x000000000044ae72 in ap_run_process_connection () #12 0x000000000044b2f9 in ap_process_connection () #13 0x00000000004ac48b in child_main () #14 0x00000000004ac56e in make_child () #15 0x00000000004acb03 in ap_mpm_run () #16 0x000000000042857c in main () This is now getting useful. Not only is this nice for debugging purposes, it's really nice for inspecting call traces of modules you've never used before. Inspecting the actual behavior will provide you a much better clarity of the source code. In our case, this confirmed my assumption of the calls that lead up to getting to get_fullurl. Now I know how we got to my method, but I need to see where it's failing. Ideally I have the source up in Emacs and can look at line numbers while debugging. What I don't get with this however is the ability to go one line at a time and inspect the values and types of variables. GDB provides this capability. (gdb) n 334 if (ctx->f->r->parsed_uri.query != NULL && args) { As with most debugging software, this allows me to step through code, line by line, to see what the execution does. Obviously, this is a useful thing. But, to enhance it we get the ability to inspect variables. (gdb) n 334 if (ctx->f->r->parsed_uri.query != NULL && args) { (gdb) p args $2 = 1 (gdb) p ctx->f->r->parsed_uri.query $3 = 0x0 And, to make sure you have the appropriate context for what you are dealing with, you can print out a handful of lines to accompany your inspection. (gdb) l 327 char* baseuri; 328 char* fullurl; 329 330 if (use_base) { 331 baseuri = get_baseuri(ctx->f->r); 332 } else { 333 if (ctx->f->r->parsed_uri.query != NULL && args) { Ultimately this has made things easier. And, there is no longer the "ok, add a new print line in here, recompile, run, check logs, rinse and repeat" type of process. It really simplifies my life when I have to hack on C code and I know it helped one of our other guys track down some memory based issues. The only downside here is that there is no longer any sword fighting.

Homework If you watch the following video with Trent Reznor, it's about 40 minutes long, you'll likely understand the rest of this post. But, for the TL;DL crowd, the interview had a lot of undertones to it that I really thought needed to be elaborated on. Not only do they pertain to what he's doing within the music industry; what he discusses has to do with, at the very least, the tech industry. I see it as a fundamental shift in the way business is being conducted. At any rate, take a glance, and there will be more after the video. Thoughts First- Trent Reznor is the f*ing man. Second- Trent Reznor is the f*ing man. Third- there is new information coming out lately about how we're in a time of mergers and acquisitions (M&A). M&A is a way to grow your company in size (employment), in revenue and, if you did your homework correctly, in profit. Ultimately the point of the larger companies is to make themselves money. They need to sustain the business styles they have grown into. Younger companies tend to be far less concerned about the profit engine as they are a bout their idea. Pay attention here. If you listened to what Trent said about record labels and artists then this should sound familiar. However, his thoughts don't just apply to the recording industry. Small businesses tend to be focused on producing some idea that changes the world, makes it a better place to live in, or makes my cheese burger taste even that much better. They are _not_ focused on whether the special sauce will be cheaper if they use Angus vs norm. In fact, a lot of smaller companies will make a deliberate decision to go for quality. They know it will cost more, but often that deliberate decision is an important differentiator in the market. However, the businesses doing M&A tend to be focused on things that generate profit. They need to feed the meat grinder and produce dollars. After all, they have investors to satisfy. But, and this is where Trend hits the nail on the head, if you want to keep your vision, in most cases, you need to stay away from the M&A scene. If you're looking to just make some cash or want a much larger exposure to the market knowing that you may lose some of that "somethin', somethin'" then M&A may be right for you. Something to keep in mind here is that the internet does allow for a great "grassroots" style exposure method. While the phrase it overused and overassumed, "your stuff could go viral!!! OMG!" Fourth- in the interview Trent provides some notes about what artists starting out can and should do. This is not unlike the technology industry. Now-a-days there is often very little capital required to start. You can literally buy a domain and hosting for 21 dollars a month, throw up a blog, software, etc. and you're on your way. The most expensive equity at that point becomes sweat equity. Here is something to note, investors tend to like it if you require less money from them and can produce something which will make them rich. Seems to make sense yea? If you can show that you work your ass off, made this product in your "free" time, and then have plans for the future, you're well on your way to getting some funding. Keep in mind that getting funded is much like acquisition. While the investor will be much more likely to care about your vision they are still concerned about the profit engine. However, because it doesn't feed into some conglomerate view of the bottom line, there is a bit more attention on the details that make your company tick. Fifth- things are changing. The way that business is done is changing. This is somewhat hidden in my fourth note. Trent noted a distinct difference with the way artists need to operate now from when he was coming into the industry with Nine Inch Nails. The technology that exists today makes it so that the companies today that are really taking off are just starting as hobbies or side projects. There are a ton more as well. The point here is that these companies are utilizing the infrastructure to make something really interesting and really useful, but most importantly, something that they themselves want to use. This is where I see technology companies going. There are a few things about this topic I haven't elaborated on. If you make something that you yourself want to use then you will likely lack passion, devotion, and when the chips are down it'll be easier to cashout than to dive back on in. Starting projects, companies, or ideas is hard work. It requires a ton of time and effort. You'll get to a point where it will feel better to just throw it away. But, if what you are doing is worth it to _you_ then you will pour that extra cut of "oomf" and push through it. And, IMO, if investors overlook this crucial element, they don't deserve the profit you would make them. :)

Linux has some great software built for it and the video editing arena is no different. The videos that I create tend to be fraps based out of games, but they still require some editing. I was interested in finding some software that wasn't hard to use and would allow me to produce quality videos. Enter Kdenlive. Kdenlive is a non-linear video editing tool that provides nearly everything that an amateur like me would want. And, having seen Adobe Premiere Pro, I'd imagine it's what professionals want as well. The software itself is laid out really well. My focus and attention is always on the video itself. And, since the second area where I do most of my detail work is with the tracks, it only makes sense that it be very large as well. The project tree, left of the video, can be toggled for other things as well. You can view the effects and the transitions lists in this pane. Then, should you want to add something you can drag it in place. I have checked out some other software before too but it was incredibly buggy and way too crashtastic. The one I tried the most to use was OpenShotVideo and it just isn't there yet. It seems like it could be a great tool in the future. For now, this novice is sticking with Kdenlive. :) At any rate, I'm not great at "reviewing" video software since I do so little of it. I just wanted to throw out a post mentioning the capabilities here in case others of you who do the same thing I do with video were interested in it. I hope that this is helpful to someone.

Software development is always a good way to realize that you're human. I'm sure there are other professions that give you this feeling as well, but my experience is limited to the software development field so I'll talk about it from that light. There are really two ways to go on this subject. I could talk about code rot and the need to clean it up and/or talk about test driven development. Because I think they both have something to do with each other, why not make it about both eh? The Church of TDD Test Driven Development is a nice concept. The key here is concept. The idea here is that you write tests for a piece of functionality (ideally you know what you're trying to get out of your function) and then write the actual functionality such that all your tests pass when your functionality is complete. Why you might ask? Well, I'll answer! The reasoning is that when you're 3 months into your project, breaking Brooks' law, and trying to cope with the ever changing requirements of your project, you'll simply have to make your change and re-run your tests. If they fail, you caught the problems at test time rather than at 3 AM when your boss friend calls you up and lets you know that he was just informed about emails being sent around to customers with usernames, email addresses, phone numbers, and contact lists for about 500,000 users. Obviously a made-up case, but I have read about similar scenarios. That said, test driven development is only useful when you're testing the right things. Testing functionality isn't just about testing that you get a string back in all cases. Let's say your working with Java and StringTokenizer's. You might need to test the return values of each token. Also you may have to test the number of tokens or if a token is supposed to be empty that it isn't null. If an exception should be thrown, you should check that case too. There are plenty of example cases to check here, but the point is that if you're testing a method and only checking that something was returned then you aren't finished. Start out with a plan. This works in either the agile or waterfall methodologies. By this I mean, think about what you are about to produce. It usually helps me to take a step back and process what the method is expected to do. "What do I expect to see when I call x()?" "What assumptions do I seem to be making about x() where I'm calling it?" Running through questions like these are a good way to get a base set of tests for your functions. So now you have a handful of tests that should make sure your code works right? Right!?!? Not necessarily. Let's go back to my first line here. "Software development is always a good way to realize that you're human." You'll miss something. It's inevitable and, what's better, it isn't because you are bad at what you do. There are so many other things that are likely going on in your brain. If you are anything like me the whistle of a dart flying by your head or the ping and the pong of a game going on in the distance is enough to bring you out from your "I should write tests" concentration. What's more, there are just going to be cases that you miss. It is O.K. to miss things, but there is a stipulation here. When you do and when it is caught, you need to write a test that checks for the situation/case. Subscribing to TDD for the sake of it wont get you far and will likely slow your productivity. But, if you take a pragmatic approach to TDD and write tests as you think of cases your source base will likely be more stable since you'll find bugs when you run the tests instead of through the client. And, you'll have a system in place for those bugs that do slip through so that you can make sure they don't come up again. Clients are a lot less understanding when you have issues with your code base and you can't assure them that you wont ever have that problem again because you have no tests in place to ensure it. Code Rot and Technical Debt

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. - Ward Cunningham on Technical Debt

Software development is one of those knowledge based fields. You write software with what you know at the time. If you are any good at what you do, you should still be learning every single day. The old saying "you can't teach an old dog new tricks" really doesn't hold water in this industry. Once you stop learning new things, techniques, and methods, you've effectively signed yourself into retirement or unemployment. That is just the way our industry works. So, with this new-found knowledge and all powerful ability you'll begin to smell something. It's a familiar smell. You'll be working on your code base and look at a method you wrote a couple weeks ago and have to plug your nose. That, my friends, is code rot. The two, technical debt and code rot, are interesting. Understanding that you may take shortcuts to get a project moving only works when you refactor. If you do not refactor your code after you've introduced the questionable code you're in for a "fun" time. Lets not get the two confused. Code rot is typically when things change external to the code such as your ability to program or changes in the industry that your software works with. Technical debt tends to be what you introduce knowingly to the code with the intention of cleaning up later. However, as you find code rot, it becomes technical debt when you do nothing about it. Technical debt is something that needs to be paid back. Relating this to real life; imagine yourself going so far into debt that you cannot imagine yourself ever getting out from under the load you carry. You will either be stuck with extreme payments the rest of your life or you'll claim bankruptcy. In a software project, the equivalent of bankruptcy is a complete rewrite. You have invested time, sweat, tears, and likely a decent amount of money into whatever you're working on. You don't want to lose what you already have, but sometimes it's inevitable. The point I'm trying to make here is that you need to be willing to pay back your technical debt such that when you incur more debt, you aren't overwhelmed by it. Paying that back can be related back to time and effort. Hell, even if you spend 5-10% of your time just refactoring your code you'll have been paying back some of the incurred debt. I'm probably beating a dead horse here so I'll move on. Problems There are always issues right? "Sure, what you're saying makes sense, but we don't have the time or the budget to go through our code and fix it." I know. I've heard and said this before. But, think about it like this. I have a car. I drive it places and it serves me well. I put gas in and all is right in the world. Then one day I feel some light vibrations when I press the brake. I don't think much of it because the car still _works_. I don't have the time to get it taken in to the shop. About a week or two later I feel a stronger vibration and every so often some squeaking coming from the car. Again, no time- I'm a busy man! Another couple weeks pass and now the squeaking is a screeching and it's loud. It pierces my ears. I know that sound and realize that it means I likely need to fix more of the car. Now things are getting pricey and I don't have the money to fix it all at this point. You see what's happening? I put it off so long that it became prohibitively expensive to surgically remove the rot. Instead now it is going to cost me a fair amount of cash, time, and effort to actually get these fixed. And, who knows, if I continue on the current path I might end up in a wreck. Still when you are under constraints that you have very little control over there doesn't seem to be much that you can do. Most of the time you are forced into situations where you either piss off the PM's and management or just continue to let the code grow it's warts. Ideally, you'll prove to those that make time and budget based decisions that your changes will be worth it. By worth it I don't mean "the code will be better", I mean "in the long run, we'll say 30% and gain 5% in revenue". Solutions One of the serious mistakes that developers make with manager types is that they think they are relating to them with terminology and analogies. Typically it requires actual impact to prove that you are right. In order to get impact values you have to gather some metrics. Hopefully some of what follows can help there. If you already have tests in place for the code you've written you can do a couple of things. Lie to the people that are asking you what you're working on. *cough* working on that scalable synergistic thing-a-ma-bob that will grow our profits exponentially *cough*. Or, you can tell them the truth. Regardless of what you do, you can have some faith in the fact that your system should operate in the way you expect it to because you have tests in place for just this reason. At some point this code was going to be changed and you wanted to make sure that you did some CYA when it did change. If you don't have tests you can again, lie to the people. Or, you can explain to them why it is important and some tactical approaches to solving the problems. Some fuel for the fire:

• Measure and Frequently Repay Technical Debt - Intel Software Network Blogs
• Start Paying Your Technical Debt - The Mikado Method - Thoughts of a Goldfish
• The IT Manager's Dilemma with Software Debt - Chris Sterling's Blog

Think about things like this. You want to get rid of this technical debt. It's very likely that the project manager does too. But, explaining these things to the people who are interested in release dates can be challenging. Try explaining that customers are more happy when their software works. The more you can ensure that the better. Often it'll require charts and figures with bug numbers over time. Be sure to show where you're making improvements too. For instance, "as you can see we refactored the code on 3/12 and the number of bugs being reported decreased by n%". By doing this, you are effectively showing ROI and how your changes  affect the bottom line. For people concerned mostly about money that is important. And, if all else fails, show them this video! Sometimes it's better to just ask for forgiveness in doing these things. Even if it means temporary irritation, the benefits  outweigh the downside.

In the pursuit of learning a new language I picked up Programming in Scala. I had fumbled around the Scala examples and read some of their documents like Scala by Example. I did replicate one of their examples by implementing a Quick Sort. I don't feel it's sufficient to know the language by taking an example they have provided and merely reimplement it, so I've decided to try my hand at a web server from scratch. So far it's been quite fun. At first I figured, "All I have to do is spawn some threads and write to the output stream". Then, my curiosity got the best of me, per the usual, and I thought, what about if I just take the bytes from the files and write those instead of just reading lines from HTML. Then I can support any content types. Obviously just using file extensions wasn't going to be enough for me so I figured I'd integrate mime-util as I've had some good experience with that in Axiom Stack. And, I've been working on a implementing Handlers in the way that allow different handlers to manage different paths. So, now what do I have? I have a functional web server that provides 200, 404, and 500 level response codes. Ultimately I have an experiment that has gone pretty well. To get a feel for whether I was actually headed in the right direction with web servers and Scala I decided to take a peak at the Lift source. While I'm obviously not there yet, it seemed as though I had the right idea in terms of how they thought it should work which is comforting to me (something to keep in mind is that I do have some experience with web servers since I'm an active committer to Axiom Stack). So. While it's great to have a static content web server, that's really just the tip of the tip of the tip of the...stack overflow...iceberg. I'd like to bring this server into a better set of compliance, make it faster, and truly test the "scalability" of the server. I know that it handles me slamming on F5 pretty well but that is the only kind of testing I've really done with it so far. Additionally, I'd like to figure out what it would take to get the distributed requests and such working well within it. I might try to bring in Terracotta for that portion of it. There are a lot of things I'd like to do with Beaker but I just don't know whether it is worth my time to continue to develop the server. We'll all find out together I guess. ;D Also, while all this is great, the biggest reason for doing this is to really get a good personal comparison of Scala and Erlang. While the threading model for Scala is stolen from Erlang, the language similarities essentially stop there. I may try my hand at replicating this server in Erlang at some point. If you're interested and haven't yet fallen asleep you can grab the source for Beaker on Github. Fork it, hack it, let me know what a noob you think I am. I can handle it. Enjoy. *Update 1* I suck at art. No making fun of the beaker - it's hawt (on second though, maybe I should lace it with bacon...).

Programmers will tell you that you should learn a new programming language every year. I'm not going to tell you otherwise. In fact I agree with this. Here's why, I believe that a language is just a tool to get your job done. More over, Python is not how you program, Python is a means by which you write programs. When I got out of college I didn't really grok this. I knew there were many different programming languages, but Java was how I programmed. When I thought of a problem, I saw the solution in Java. It's almost like communicative languages. If your first language is English and you are taking French, you translate the French to English before really understanding the French. This is what I would do with other languages and Java. It's not the best method to learning the language I've found. In fact, every language is different so trying to transpose one language to the other tends to push the write Fortran in any language approach (no scientific study, just my experience). So, if I take a Java programmer and give them a project and tell them that the language being used is Javascript, they will write Java and the code will likely get written, but poorly and need to be completely refactored. Going For The Goods The way I would approach new languages was to  take some existing problem and attempt to solve it in the new language. While this is one of the steps you'll need to take to really know the language, shouldn't you get familiar with it first? Think about your education for a moment. When you were in school taking Spanish, did the teacher start you off by saying english("I") and then spanish("I") or did she start you off by saying spanish("Take out your translated version of Tale of Two Cities in Spanish and read")? I'm going to assume the first scenario as this is what my experience was. For me, diving into an existing problem and trying to tackle it with a language I've had no experience with just ends messy. It's almost like when you...ok I'm going to try not to make the Rails mistake. But, really, everything we as humans do when learning is experience based. We crawl, then learn to stand, then walk, then run...and so on. So why not start out with the same approach and build momentum for your language? I'm not saying that you need to spend hours relearning what a for loop is. I am saying that you should spend some time getting familiar with the syntax and differences of one language before trying to "go for the goods". The Foreplay Because I noticed that I was trying to run before walking with languages, I started taking a new approach. Instead of transposing language constructs, I instead started to rewrite common/well known data structures or algorithms in the language I was learning. There are a couple reasons to do this. First, I constantly feel out of practice when it comes to algorithms/data structure design. I don't claim to be a math wiz so re-reading and implementing them is great practice. Additionally and perhaps more importantly is that the algorithms/data structures I'm implementing aren't new ideas. These are tried and tested concepts that span languages. Thus, I will have comparable results. Take this for instance. If you write a merge sort in one language, you'll most certainly be able to write it in another language, it will just be written differently using the appropriate syntax and language designs. Since you already know how a merge sort jiggles when you poke it, you can compare your version to the typical. Plus, you can calculate the speeds of doing said algorithm in the new language. This will provide you with some benchmarking for better decision making about the language. Another Analogy If you need another analogy, I used to play instruments. Typically, outside of August Rush, people who haven't touched a musical instrument must go through some period of time to learn the instrument. You need to learn how to caress it so that it will make music rather than just a mixture of noise. When you start out you don't learn Für Elise you start with notes and scales. The notes and scales apply across instruments. You have to learn them for the instrument you're using, but you understand the concepts. Conclusion Warming up to the language seems to work best for me as I can compartmentalize the diffs of the languages preserving my memory for other interesting things. Then I can pull out what I need from each language. Think of it like this, the algorithms and data structures are your minds libraries and the syntaxes of the languages are the methods written on top. The algorithms aren't likely to change, but you're trying to evolve your syntaxes. To summarize: I have a specific methodology for learning languages that I've found works really well for me. Although I'm sure many of you will have your own method for learning them, maybe this will help someone trying to get more familiar with differing languages and maybe give you a different approach. Disclaimer Always leave room to learn more about algorithms. Who knows, you might be the one to figure out how to make quick sorts obsolete. So, don't write them off, but know that they are tried and tested and because of that, produce predictable and comparable results. That is my reasoning for recommending them.

Rhino is a fairly awesome tool. You get the full capabilities of writing Javascript, plus the availability of the Java ecosystem. However, there is another awesome feature that I didn't know about until a few months ago when I read Todd Ditchendorf's post about thread synchronization in JS. You can actually implement Java interfaces from your Javascript. For example, let's say you want to override the toString method on a String object. I used his technique when I was writing a module to allow HTTP calls from the JS side of the house, on the server side. Below is the code that allows for asynchronous requests to be made. Very simple and very much like Todd's examples, but that is all it needs to do and it works beautifully. In essence it creates a new Runnable object, defines the run method, and then passes that Runnable object to a new Thread. While this code demonstrates the functionality with the Runnable object, you have the capability to do this with any other interface right from within your Javascript. It's really handy and took me a while to find so I thought I'd post something about it. Hope it helps.