Posted by Chris Shorrock
Tue, 29 Aug 2006 23:05:00 GMT
So work has REALLY been s l o o w i n g down lately. I'm not a salesman and never have been so finding my own work is often difficult. I feel I'm very skilled at what I do yet establishing yourself on the global market is something that isn't easily accomplished. I'm now debating going back to an office job but find the whole prospect of doing so somewhat demoralizing.
My current work arrangement is quite good, I work from home in my nice little office in a nice quiet neighborhood in a nice quiet town. I'm able to focus and get heaps of work done since there's nearly no interruptions and I'm very self motivated. I can wake up at 7, work for 10 hours and still be home by 5. I can BBQ for lunch, and if I need to, workout during my lunch break. All in all, I really have nothing to complain about.
On the flip side, my nice quiet home has a mortgage attached to it, as well as a wife and daughter living inside of it who, for some reason, demand food now and then. So due to the downswing of work it may be time to head back to a real office as baby and mom aren't so happy when the bills don't get paid.
But why is going back to an office job so bad? Well, I suppose I just appreciate a good thing and throwing that behind you can be difficult. My nice little neighborhood is about an hour and a half commute to downtown where I'm sure I would end up working. That means 3 hours each day commuting minimum, and that's if I drive, which I probably wouldn't, so public transit would be getting a new customer.
Also I need to consider what I want to do. Do I go with Java or Ruby? Java is a great language which I enjoy (and even named my dog after... yes I'm that much of a dork) but getting stuck in a web shop that does glorified business card sites gets tedious quick, so I would almost need to find something with a level of complexity to challenge myself in order to remain sane. On the other hand, I've really enjoyed Rails work as of late, the ability to turn stuff out quickly makes even normal web development enjoyable due to the high ratio of work to show; that is, the amount of hours put in results in more done that typical development environments.
This entry has turned into a rant with no real focus or direction but It had been a while since I posted anything so I thought I'd just throw up what was on my mind. I'm still not sure what's going to happen in the near future but hopefully it turns out for the best. I still have some time until I need to make a decision so hopefully I can find the light at the end of the tunnel I've just entered.
Posted in Programming, General | Tags contracting, java, rails, ruby, work | 1 comment | 1 trackback
Posted by Chris Shorrock
Tue, 22 Aug 2006 04:35:00 GMT
A recent article over at Software By Rob has illustrated a very interesting point regarding common attributes that he finds if skilled programmers. It's a good read for anybody in the industry, but I thought I'd throw my own 2 cents in the direction of the topic, so without further ado, here's my brief list of Things Required To Not Suck At Programming.
Laziness
While it sounds crazy, all great programmers must be lazy to some degree. A lazy programmer will go to great lengths in order to abstract out ideas and concepts into small manageable and (key word here) removable pieces which can then be used in other places. It's their desire to only ever do something once, this will generally cause their architecture to be such that repetition will not be seen anywhere . Everyone has ran into a small piece of logic has 300 if statements in a row each testing for a different condition, and you can bet it was a very eager programmer who did this - as a lazy person would take the time and figure out how they could avoid typing out all of these 300 lines.
Anal Retentiveness
Have you ever jumped into a project half way through development and thrown up on your keyboard (repeatedly) due to hap-hazard nature the authors of said project had taken towards code cleanliness. A mixture of tabs and spaces, different variable naming constructs in every other class, so you go through and take a considerable amount of time reformatting everything for consistencies sake? After which the code runs no different than it did before, but at least this way you can look at it without having to reach for the pepto-bismol. Similarly in real life, these programmers, also have minor OCD tendencies where their desk must have a sense of symmetry before they can work. It may seems (because it probably is) that these people are a little crazy but their desire need to have everything just so, in every circumstance, is a testament to their attention to detail and their unrelenting approach they take to software quality.
Artistic
Anyone who said that programming isn't art is either not a programmer, or not a very good programmer. Great programmers relish in beautiful designs that solve multifaceted problems using very simple abstractions. They have an innate ability to make things "as simple as possible, but no simpler", that is, they can do something in a small amount of time that will address all of their requirements. They are able to take a problem and construct a solution out of thin air that takes a tenth of the time and will often operate several magnitudes faster than a solution crafted by a less skilled programmer. Art, at it's core, is taking things and putting those things together to make something beautiful; those programmers who approach code from a perspective of creating elegance, opposed to gettin'er done are often the ones you want on your team.
From a personality perspective we've painted a picture of some lazy hippy living alone in a loft with his 300 paintings (well.. 1 painting and 299 photocopies) organized on the floor with exactly 3cm's separating all of them. Find this person, teach him what an if statement is, and you have your next team lead (providing you can get rid of that hippy smell).
Posted in Programming | Tags anal, artistic, hippy, lazy, programming | 1 comment | 1 trackback
Posted by Chris Shorrock
Tue, 15 Aug 2006 22:15:00 GMT
So I'm not much of a gambler (unlike my daughter), so putting money towards something that I have no clue as to the value of is something I find difficult.
$6.50, this is all about 6 frickin 50 (with a coupon). I was sitting at my desk attempting to find a good reference for Rails based RJS Templates (AJAX made easy) when I found O'Reilly, the king of technical references, was offering me what seemed to be the definitive guide on the subject. I was having so much trouble justifying spending $6.50 on something I couldn't physically touch, but eventually decided to do so. chris.good_decisions++
The book is written by Cody Fauser who, previous to writing the book, had written a few tutorials on the subject. In fact his tutorials had helped me with RJS pre rails 1.1 when I was working on iCompete so I knew he had a good grasp for technical writing. He also recently updated the book, so if you happened to purchase it recently be sure to go grab an update.
The book is well written and the examples are very clear and do a good job of outlining the point they are trying to make. It's not a huge book, at 58 pages, but it doesn't need to be as it does what it sets out to do; show you how to use RJS templates avoiding some of the common pitfalls while taking advantage of Rails built in functionality as well as points you in the direction of some very handy tools. Additionally the RJS Reference at the end of the book will turn out to be a well used addition as it lists all the commonly used features of the library.
I'm sure this book will be worth it's weight in gold as I recently started out on a new rails project in my personal time. For a technology as useful as RJS Templates, it's shocking that there isn't much more literature out there, but when you can pick up a book like this for $6.50 I suppose it doesn't matter. A great purchase, and maybe in the future I'll learn something from my daughter
Posted in Programming | Tags ajax, code, fauser, rails, rjs, ruby, templates | 2 comments | 1 trackback
Posted by Chris Shorrock
Fri, 11 Aug 2006 15:20:00 GMT
As someone who is probably still considered a youth by most of the general public (26), or at least I can fool myself into thinking that until I hit 30, I can't help but wonder what the current state of the programming world is doing to the kids just coming up in the world.
I'll probably receive some email from someone stating since I've never worked with punch cards I have no idea what I'm talking about, but I'll ignore that for now. In the good'ole days there were no fancy IDE's and there certainly wasn't any fancy programming concepts like agile development processes or extreme programming(whether or not I buy into these is another issue). I'm a strong believer that this type of environment fostered some very valuable skills.
Now don't get me wrong, I work with an IDE and it does save me a bunch of time, but the time I put in with a text editor and a command line taught me more than I can imagine. Failure is the best teacher, and if we're not allowed to fail because our IDE picks it up right away, or we have someone sitting behind us watching every character we type how much are we really learning? Is this process efficient? Of course is isn't, but the time spent struggling with a stupid problem will pay of later when you're getting paid to work and you avoid that problem all together. So am I suggesting that people just starting out programming should avoid automated tools all together? Well, yes, until you're getting paid the process is more important than the end result, allow yourself to fail.
I had a friend (sorry Dan) who I started my first job with who literally spent about 3 hours trying to debug the following piece of code (simplified in Java for presentation purposes):
while(expression.is_valid() && null != name); {
Log.info( "Why doesn't this work" );
}
The astute (or even half-asleep) reader will see the extra semicolon and pick up why the log statement was never reached. But the time spent solving this problem taught him a valuable lesson that wouldn't of been learned had he been doing this in today's modern IDEs.
That's my message for the younger generation. Give a man an automation tools and you'll feed him for a day, teach a man how to write automation tools and you'll feed him for life. And with all that said I'll leave you with some humorous images of todays generation (my wife is a teacher):
Posted in Programming | Tags agile, automation, extreme, humandoing, programming, youth | 4 comments | 1 trackback
Posted by Chris Shorrock
Wed, 09 Aug 2006 19:50:00 GMT
Now I’m not here to name names, or call people out on their bad designs, but there is something very scary about how credit card processing works. As someone who has had to implement credit card processing using a variety of different processors for a variety of different companies I’m always amazed by the amateur status of almost (as their are a few rare exceptions) all credit card APIs.
For those of you who are wondering what the problem is, let me enlighten you, these APIs seem to have been designed by monkeys. It’s my belief that these companies have employed the infinite monkey theorem to get things done. I can’t speak to what happens after you send you’re information to these companies as the process is (as it should be) a black box, but if the client interface is any example you should be afraid, very very afraid.
Now considering that my monkey theorem presented above is correct, I have to applaud the monkeys for at least getting the documentation correct some monkey needs to be spanked for the awful documentation that is presented to developers of almost every system. Let’s take a peek at an the XML structure for an unnamed payment processor.
<auth>
<order>
<orderDescription>order12312323</orderDescription>
<customerPaymentPageText>M123456789</customerPaymentPageText>
<currencyText>USD</currencyText>
<amount>100.00</amount>
</order>
<card>
<cardHolderName>Steve Smith</cardHolderName>
<cardNo>8005787962</cardNo>
<securityCode>123456789</securityCode>
<cardTypeText>BLAH</cardTypeText>
<ipaddress>192.168.1.1</ipaddress>
</card>
<option>
<useroption>100000000000000000000000000000</useroption>
</option>
</auth>
Looks good? Sure it looks ok, until you start looking at the description for each of these fields:
cardNo: you would expect this to the card number of the card. However, the monkeys thought differently, this is actually a 1-800 number. Yes, that’s right, a phone number is stored in the cardNo field.
useroption: What’s this happy little fella? Most processors give you some level of customizability, this is this processors attempt at this. The problem lies in that if you omit this field or if it does not equal 100000000000000000000000000000 you will get an error which reads Request Timed Out from Processor - Connect switch. So there’s a field that is required that is meant to provide customizability, yet can only contain 1 value or else you get an error that reads like it was a configuration problem? Yes - thank you monkey, thank you for the for the 4 hour headache this caused as I worked out the problem with your technical support monkey who I’m sure was reading answers out of a book.
Does it work? Yes, eventually, after costing more development money than it should.
Is it scary? YES^2.
Why is it what should be an uber-professional API is almost always is a gong show? Marketing - because these processors have a nice looking website, with flashy buzzwords, the powers that be, WOW’d by the shiny objects, will always go with the service thats has the most shine. What they neglect to realize is that the company has thrown the monkeys in the back room while they smear their poo on the wall. Not so shiny in that room…
Posted in Programming | Tags cards, credit, java, monkeys, programming | 23 comments | 2 trackbacks
