Speesh Filters

I’ll be the first to admit I lack a certain filter that prevents me from saying stupid shit. I’ve been the poster child for the Peanut gallery since junior high (I was almost suspended for being “too funny”). As I progressed in my career smart people educated me on things you shouldn’t say to other people, especially your coworkers. There’s a whole other list of things you don’t say in meetings, especially if it’s a clash of departments. So, here’s my list:

• Don’t insult someone to their face and laugh. They might not think it’s funny.
• Don’t add to other people’s sentences, especially if you’re trying to be funny. You will come off as a jackass.
• Lay off the f* bombs. It doesn’t add to your intelegence, but does tell people volumes about you anger management skills.
• Don’t make fun of other people’s department/position. Ever. You’re not a godsend to the company and in fact do NOT know everything.
• Don’t say anything out loud that you wouldn’t say in an e-mail. Just because there’s no written record doesn’t mean things don’t travel around

Now I will do my best to follow those simple rules. It’s going to be hard, but I’m going to try because not doing the above is a) unprofessional b) make you a tool.

Giants pushing giant trains!

I found this gem trolling the internets. It’s a skit from a British comedy show that showcases a really remarkable level of stupidity. I mean, you wait for it to get better but no. The dialog is brilliant. Enjoy:

Android is here

On Monday Google Android was set loose on the general population. Android is Palm OS of 2007. Back in the day, Palm went out and tried to unify the mobile platform. One OS to rule them all, and in the darkness bind them… But we all know how the story ends. Google is going about this quite differently. They formed an alliance with the most influential companies of mobile market today and leveraged it all with an open-source community. After watching the demo of Hello Android application being built I firmly believe this will change mobile computing forever. Mobile platforms will become like PCs of today. The biggest deal about this is being able to swap your OS and run any application on any handset. We’ll have cheap handsets that run your basic apps and high-end phones with 3D accelerators able to play Quake. The future of mobile computing is getting very interesting indeed.

Learning Latin

When somebody tell you they are a programmer what do you usually assume? Besides the fact that he/she knows a programming language people usually assume he/she knows the language that’s still alive and well. For example you hear things like: “I’m fluent in C, C++, Java, and dabble in bash scripting”. That’s like 95% of all tech resumes out there today. Since we are including scripting into this, let’s add things like Ruby, PHP, Python, and Perl too. So that’s a pretty standard arsenal of coding lexicon. But then we start getting into more and more obscure stuff. Say, when was the last time you heard of Object Pascal? How about ML, or ALGOL, or COBOL, or Ada. Now I’m pretty young, but I haven’t even heard of Ada before.

This got me to thinking about languages in general. We can safely consider that Latin is a dead language since nobody that spoke it originally is around to tell us the correct pronunciation and unless you are going into law or medicine you probably will have little use for it (thus it’s a dead language). With the pace of current progress I would not be surprised if C and C++ will eventually go the way of Fortran and Cobol and become the domain of Universities and Department of Defense (security through obscurity).

So go out there an learn an obscure language and use it so that one day somebody stops by your cube to see what you’re working on and go “What the hell is that syntax?”.”Oh, that’s ALGOL.” you answer nonchalantly. It’s a geek equivalent to “Yeah, I’m fluent in Latin”.

Evolution of programmer

I was thinking the other day about the evolution of a coder. If you have picked up the skill on your own and have moved pass simple hacks the following may sound familiar.

Step 1: 1 + 1 = 2

This is when you are just starting out. You need an app that does something very specific. The code has tons of global constants and there are assumptions on every corner. Basically the program computes the sum of 1 and 1. If you try to plug in 1 + 2 it will crash. After a while you find yourself writing hundreds of these hacks and as soon as you are tasked with something more complex then a coffee mug, the code gets bulky and unmaintainable. That’s it, the next step is upon you. Evolve or die.

Step 2: x + y = z

Eventually you realize that all the code in the world uses a few simple procedures over and over in increasingly elaborate ways. When push comes to shove, no matter what you are making you will need to be able to do very basic things over and over. Using the “Step 1″ mentality we could just copy and paste the code n-many times and all will be happy… For a while at least. Then use realize that the one simple procedure is flawed or can be more efficient. Now what? Thus you arrive to the concept of reusable code. It takes years of coding to be able to break up your code into a well balanced architecture but everything flows some much nicer when you do. A cool side effect is that your code becomes scalable.

Step 3: Duck <?## Polar Bear %%%^ Refrigerator

What drives today’s world of compatibly and interoperability are APIs. It’s cool to reuse your own code, but it’s even cooler when you use someone else’s. This is when things get really interesting. Even more interesting is what you are the one writing an API. Say you have a some meta data that you copied from a website. You would like to send it to your friend with a Nokia in his pocket. So, you paste your data (it can literally be anything) and your code has enough intelligence to digest it and come back with something that can be sent over the GSM network and into your friend’s phone. Alas your toolkit may have some limits on the input (otherwise we are looking at an infinite state machine, i.e. artificial intelegence) but you are free to take the input and do whatever is necessary to make the output pliable to the user. You can create your own language, or rules, or use another toolkit to help you chew the data. When it comes to building APIs that hardest part is thinking of ways the user might utilize it and making that process simpler.

Puppy is back

My other dog (who knows Ruby, naturally) is safely snoozing in his crate. We picked him from Fresno SPCA tonight. So, let’s start from the top. On October 2nd, while running around the back yard Baxter (my 6 month old beagle) decided he was going to go for a walk. He found a board in my fence that looked weakest and jumped on it until it gave. Then slipped into my neighbor’s back yard and out of their gate. We don’t know if he made it too far (the officer didn’t note where he was picked up). It’s doesn’t really matter now. He’s OK. I very glad I marked all the places I posted missing posters since tomorrow I have to drive around and take them down. Oh well

SOAP in Ruby with Hpricot (a better way)

Ok, after a bit a comment war on the previous port (SOAP4R with Hpricot) I feel the need to present a better way of dealing with XML pass-through using Hpricot. This is why Ruby is such a powerful language.

So, let’s say we have and object. Any object in Ruby has “class” method, which in turn has “class_eval” method. Passing a code block to it is equivalent of adding things into the class itself. No “to_xmlpart” method? No problem! Behold:

require 'hpricot'

xml_doc = Hpricot::XML(File.read("MyXML.xml"))
xml_doc.class.class_eval do
   def to_xmlpart
      self.to_html
   end
end
puts xml_doc.to_xmlpart

Boom! Hpricot::Doc object suddenly has “to_xmlpart” method. Now you can pass it into any SOAP RPC method and it won’t try to muck with it. That my friends is the Ruby Way.

P.S. I hate you Scott. Curse you for not letting me half-ass things.

SOAP4R with Hpricot

SOAP4R is the Ruby SOAP toolkit making it easy to prop up a web service or set up a client to access a remote API. Hpricot is an amazing HTML/XML parser. It has a C back-end and is extremely fast (I would say it’s faster then libxml wrapper in my opinion). But what happens when you want to send an XML document over SOAP without SOAP4R mucking it all up (in most cases SOAP4R will just choke and leave you with some obscure “Can’t translate crocodiles into SOAP::Object” message. Alas, in version 1.5.8 SOAP4R has the ability to simply wrap the XML and send it on its way.

Cool huh? Oh wait, you can only use REXML Documents/Elements for this, and as we all know REXML is not really a speed demon. Besides if the rest of your code uses Hpricot why switch to REXML and back again just for SOAP stuff. Well, the key in the paragraph describing the XML pass-through feature is “… or any class with ‘to_xmlpart’ method”. Hpricot::Doc doesn’t have ‘to_xmlpart’ method, but you wouldn’t really need out. Behold the following:

xml_container.rb:

class XMLContainer
   def initialize(xml)
      @xml = xml
   end
   def to_xmlpart
     @xml
   end
end

XMLContainer class has ‘to_xml’ method and thus can be passed directly into SOAP4R calls without the fear of blow-up:

require 'xml_container'
require 'hpricot'

require 'soap/rpc/driver'

# Do SOAP initialization here and get the RPC driver ready to make SOAP calls
# ...

xml_doc = Hpricot::XML(File.read("MyXML.xml"))
xml_can = XMLContainer.new xml_doc.to_html

soapdriver->add_method("SendStuff","myXml")

soapdriver->SendStuff xml_can

And there you go. Have fun kids

Correction: in the newest version of SOAP4R they changed the method from to_xml to to_xmlpart. I’ve update the code above to reflect that change.

Finding Ruby boundaries

    I’ve spent a past few weeks doing thing with Ruby that I didn’t think the little scripting language can do (namely SSDP and UPnP). I have to admit that it’s very powerful, though not very well documented unless you bother spending some money on books. This doesn’t guarantee that you will learn about those undocumented features nobody but THE Ruby developers know about. For example the whole Socket family of classes is shrouded in mystery, and if you didn’t know how to do socket programing in Windows/Linux/UNIX you are up the creek without a paddle. For example in order to send a multicast group join you have to pass obscure structures into sock_options function and depending on which platform you’re on this structure changes. But enough about obscure sockets. Let’s talk about threads.

Threads in Ruby (1.8.7) are useless to the point of being unusable. Threads in Ruby does not translate into native threads on Windows, or POSIX threads, or anything that resembles threads in traditional sense. You just get a pseudo-asynchronous execution of blocks that all run in the same thread. It’s all runing in the same thread. You block one, you block all. One blocks up, the rest will just block and leave you scratching your noggin for hours. Awesome!

FYI: “Thread.abort_on_exception = true” is your friend.

When using Ruby to build heavy server applications (not Rails, it’s a different story) and attempting to take advantage of multi-core, hyper-threaded goodness of your monstrosity you’ll be suprised to find Ruby huddled in the corner chugging along as if you were running a single core, non hyper-threaded box. It’s comical to watch Ruby max out to 25% usage on quad-core box because the other 3 cores are inaccessible to it. There are arguments to be made for Green Threads (Java used them in medieval days, sometime around plague or Henry the VIII) but last I checked it’s 2007. Yarv (aka Ruby 1.9) will have native-ish Threads implemented so we’ll see how the code runs in an actual threaded environment. For now I’ll rely on multiple Ruby instances and DRb

Engineer + Beer Bottle = FIRE

Yes, that’s a beer bottle. :/

Originally uploaded by violetdaisies

It’s pretty reassuring to know that your boss can make fire using a beer bottle, a few odd sticks, and a piece of rope. So, if we get lost on our annual company hike I know I’m in good hands.