Sunday, December 16, 2007

Book Notes: Spam Kings

The web is now been around in its commercial form for about ten years. What I mean by commercial is eBay, Amazon and the like. With it I also acknowledge the many lay persons of the web have increased exponentially in that amount of time, who of course buy all that stuff (ergo commerce!). Previously the web consisted mostly of a group of people who are more 'underground' by todays standards. This includes those wild figures such as news group posters, researchers, software pirates, tech geeks, etc. etc. I picked up a book at work called "Spam Kings". It was published by O'Reilly which I happen to work for (thanks for the freebies, heres some publicity ;).

I've read the first 50 pages, and so far its an entertaining story. The book follows a host of characters in a 3rd person narration. The writing is not tough to follow, it almost feels like I am reading an article from a magazine such as Time or News Week. Maybe a newspaper even. Nothing written so far has been what I would consider too terse for a reader who is unfamiliar with the concepts of the book. Layman's terms are used to explain the various concepts to the reader; while I've found myself (a reader experienced in the books domains) not bored to death. Thats a feat in itself.

I would recommend this book to any person interested in the political and social underground of the web. While reading my interest holds steady in part due to the activities of each individual which seem to shape and influence the landscape of the web. The book was published back in 2004. I'm guessing you could find a copy on the chep at a used bookstore. It should make for an interesting, quick read.

Sunday, November 4, 2007

Super Cheap Functioning Laptops

Many people have heard of the "One Laptop Per Child" (OLPC) program (Please excuse the terrible site. Here is the wiki, much better ;). The gist of OLPC is many companies have banded together to create a sub $200 laptop geared towards school children. It is expected the developing nations of the world will buy these units up in large numbers. They then will use them to increase the quality of education by giving the children a chance to experience the "greatness" of the internet, the word processor, the spreadsheet program, the mp3 yada yada yada... So anyway some guy over at Asustek, the maker of Asus brand computers decided "hey, lets build a ultra cheap laptop that is geared towards the Adult demographic". Great idea guy. Check out the EEE pc.

I had some hands on time with the OLPC at the OSCON convention last July. It was neat in the sense of how far technology has come. It seems to work, which is an accomplishment considering the nature of the project, and conference attendees all seemed genuinely impressed. My deal though is this: it is a laptop geared towards a 8 to 10 year old boy. The color scheme and user interface all scream to this effect. I would not buy one of these and lug it into a coffee shop. Guys like me already have enough trouble making acquaintances without hauling a "hello kitty" lunch box everywhere we go. So in comes the Asus EEE pc. Seems to look good enough. The interface is simple. See mock up here. It also includes all the applications a person such as my mother, god mother, or wife need. Its perfect for Facebooking, instant messaging, video conferencing, writing email, browsing the web, plus the rest of the top 20. If it provides a seemless enough experience I think soon we will be seeing many more of these types of machines around.

Now the crazy thing is both the EEE pc and OLPC are Linux based. Why you ask? Duh, because a copy of Windows is a few hundred bucks. The computer itself will likely cost less than a copy of Windows Vista Professional! Oh oh M$, your days may soon be the slightest bit darker. As an aside I read somewhere, not saying I believe it, but M$ got scared that Windows would not be running on the EEE and so are giving Asus a chance to offer XP at $40 dollers as an upgrade. How many will spring for this? Not a single person I know. When you figure that the Linux based OS is tailored to the EEE it would be hard to beat it. Not to mention but the EEE runs on a very small amount of disk space. This disk space is all flash memory and clocks in at 4 to 8 gigs. Windows will suck up your whole disk!

Saturday, October 20, 2007

Resumes, Hiring, Yada Yada Yada

I'm sitting in my comfy chair, found in my little piece of wine country heaven. I'm sipping from a delicious can of "Peter's Brand Dutch Classics" Pilsner style ale. I just want to kick out some thoughts on hiring, resumes and what not. I work with computers, being that I attained a degree in computer science from a four year university. Now in the short time I have actually been in the "industry" I have seen curious things related to employment in general.

First I will start with resumes. These are strange to me. I mean when it comes to computer work, specifically software engineering, how can a piece of paper accurately describe what you are capable of doing or what you are worth? Maybe it can, maybe it can't. Given a resume I will immediately have the mindset that this document is unlikely to provide any solid information. With out even taking a look at it. I've seen many resumes already in my field that for lack of better term "SUCK". Mine included... You can write in detail about projects you have worked on; but the hard problems you have faced and conquered, those that test your mind and patience, rarely come to light. It feels awkward to write a story in a resume, and for good reason. The story is often bland and not telling of concrete achievements. The reader, after reading paragraphs of story, will know you created some product such as "Shopping cart for my last employers website". But where is the actual difficulty in creating said product?

If you really want to give the reader the understanding of your real worth you must show them you can do things, amazing things, and that you have beaten hard times before and finished with good results. How can you do this? I have some tips, but by no means am I an expert. Just a guy with some interest in this dilemma. A resume should be thorough but brief. Next time you are working on a resume try this: list the places where you have worked in the last five to ten years. For each place of employment list out the three hardest problems you had to solve while employed at respective places. Now write up these problems as simple problem, action, results format. This data should be top to listing all the "words" you know.

On "words": Most software engineer resumes have boat loads of words that are supposed to give the reader the idea you know x y z. These words do not actually give the reader any real idea of what you are capable of. I mean anybody can become a J2EE Python Ruby Rails Hibernate Struts master, without actually having solved a real problem.

For the graduate: If you do not have experience in anything, meaning you have not really solved any problems then you are probably not worth much. Now this is not likely to be the case. During my collegiate schooling I solved many interesting and difficult problems. If you are graduating use the hard problems you had to solve in school projects to your advantage. In my case I could have listed "Created AI for solving mine sweeper using computer learning" and "Created scheduling algorithm for safe and timely operation of multiple elevators". These are not easy problems, and giving a brief and thorough treatment of these problems should allow the resume reader to see you in a proper light.

In taking this "problem solver" approach to resume writing you will not need to write long stories about projects you worked on. You will high light the problems that lied within some project(s) and how you were able to solve them. This will help the reader so much more than "Created SOAP layer to ecommerce business object layer, using XFire and Hibernate with all content encoded in UTF-8", or worse "Java J2EE Struts Hibernate Ruby on Rails XML ...".

Now on to my second deal, hiring. This one is tricky. You need good people, and there are never enough of them. Regardless of what it is your company does in the software engineering field you will never be able to get enough people that have exactly that experience needed for the task at hand. Think round peg and square hole, now scale that up to every shape possibly imaginable. Each company only has a small set of unique holes and each possible job candidate has a certain 'peg' shape. You end up often making hires of pegs that do not fit your companies holes, but in hopes that they will be able to fit at some point. The sooner the better. So for that peg to change its shape it should be highly adaptable. You should be sure of this quality in a peg/candidate this when making the hire.

I think the best way to be adaptable is to have the basic and intermediate knowledge of your field down pat. For me this is being able to identify the best algorithms and data structures to use in a given situation, or when to choose the usage of a MVC web framework over simple Servlets. Things such as fonts and encodings are very important, especially in these days of i18n. Being able to describe and properly use HTTP, TCP/IP and other ubiquitous protocols is very important. The ability to pick up new languages quickly and effectively is something that speaks volumes about your understanding of your field. Recursion, why do you not understand this? There is no good answer if you do not. Object oriented languages are here to stay, so you should be able to give reasons why you would use an interface rather than an abstract class, or describe what delegation is.

Once you have that peg which fits said hole, do not ever let them leave. I know this is not really possible, at least not in a country like the US of A, but you should be doing whatever it takes to ensure that these people stay. Turnover kills in our industry, like few others. The knowledge gained by a software engineer is akin to that of a powerful business type. The business type knows all the contacts, all the players in his industry and if he leaves you may have to kiss good bye to some of those important relations (or contracts) that keep your company afloat. Now the software engineer (or IT Programmer Analyst or whatever) knows all the business systems, the software that keeps your company running. If that person leaves you are losing the person that knows how to get what is needed from the software for your business to run. Yes you can replace him, but you will need time and money to get those "contacts" back, and have things running in proper order again. There is nothing you can do to alleviate this problem. It is possible you will quickly find someone to replace the person, someone with exactly the knowledge needed to do what that person did. Not likely though... most software used in a company is purposefully altered to do things particular to the company of example. It is not an exact match to any other software running in any other place.

So what can you do to keep people. I can't even begin. Some people get bored. Some people don't like their co-workers. Some need more money. Some have personal problems and just can't keep working. One thing I can suggest is honesty. If your company is one that is openly honest, meaning that employees can always be honest about themselves and others, you have a good chance of doing well. Honest companies will address problems pro actively. Honest people/companies are self conscious in not taking on more than they can finish. Honest people/companies make thorough assessments. The honest farmer does not sow 15 acres when he knows he can only reap 5, the honest framer does not begin building a barn when he knows he only has supplies enough for a shed.

Monday, October 8, 2007

RESTlet, POST and the HTTP Location Header

I spent a few hours this last weekend trying to get POST working in a RESTlet application I am developing for work. The problem is that RESTlet abstracts the fact you are using HTTP completely. So in my code I could not grab a HTTP response object and set headers directly. Not a big deal as long as the process of POST'ing in RESTlet is documented. It is not though... I'm reading up on REST and trying to build a well done implementation. That means using the HTTP location header to return a new resources location on POST. I dragged my nets across all documentation RESTlet and could not figure this out. I new it must be doable so I just started pushing the api methods and such, trying to find something. Finally I figured out what is needed. Here is a code snippet:

/**
* POST a document to resource. Should create a new resource with a new and
* unique UUID.
*/
public void post(Representation representation)
{
insertNewResource(representation);
getResponse().redirectSeeOther("http://www.domain.com/new_resource_location");
getResponse().setStatus(Status.SUCCESS_CREATED);
}

So what you see above is the simple way to create a new resource via POST. The 'insertNewResource' method would be your code which creates the resource in your underlying application. Once that is done you must use the 'redirectSeeOther' method to set the HTTP location header. You also will want to use 'setStatus' to properly notify the client that the resource was created.

Friday, August 17, 2007

Great OSCON Keynote Now Online

Steve Yegge is a guy who puts out a solid little blog. I really enjoy his thoughtful writings on a bizarre range of things. One of my favorites blog posts ever is "Good Agile, Bad Agile". I am a software developer who has worked in an "Agile" infected workplace ;) So anyway Steve gave a talk at OSCON that is good food for thought. Viddy the show!


Sunday, July 29, 2007

Reflections on OSCON 2007

I'm back from a week spent in Portland, Oregon at OSCON 2007. It was my first OSCON, or convention for that matter. There was some good stuff, and also some not so good stuff. I'll give some short summaries of what I found interesting.

I went to a talk about DBD::Gofer. This is a Perl module that allows stateless proxying. One useful case is connecting to a database from a machine that does not have the needed DB driver. In this case you can proxy to another machine to make the connection using Gofer. Gofer can even ssh to a machine and start up the Gofer if needed.

The OLPC was at OSCON in force. IBM and Oregon State University booths featured them. I got to talking with the OSU guys (seeing how I'm an alum there was much gab to be had) and garnered a lot of interesting details behind the machine. The monitor can be used in a ultra low power mode, where it essentially works like digital ink. You can see it very well in the sunlight too. One guy at the OSU booth told me that he and some friends first project was putting a Nintendo emulator onto the thing.

I mentioned before the Grails tutorial was great. Scott Davis is a very good presenter, likely due to his charismatic nature.

There was a talk by Matt Secoske on programming DSL's in Groovy. It was actually a very good talk for those wanting to learn some advanced features of the Groovy language and where they are applicable.

Haskell garnered some mind share. Simon Peyton-Jones gave a tutorial on Haskell and also some talks.

Tuesday, July 24, 2007

OSCon 2007

I'm at OSCon, it's been pretty cool so far. I'm in a Grails talk. I don't understand why this room is not packed. Grails really kicks the shit out of Rails. No disrespect. I have used both non-trivially. Grails just has all that powerful Java shit in the mix. It also has closures and such. It's got a better active record type api called GORM. Its also got a better selection of technologies such as Spring and such, which are damn useful when you have a large project.... Anyhoo another talk yesterday on integrating Second Life with real world objects was sweet...