Friday, January 05, 2007

Why oh why did my Staging Box Die!?

I know what your thinking but no it was not me this time. Our staging box crashed about 10 minutes ago and is complaining about something to with its EIP value. This box has already crashed hard once in the last month but it came back online (with much fiddling by our sysadmin). Now it has happened again and he's out getting a drivers licence (not what you think).

So I ask again why oh why did my server die? This is an especially big pain in the ass as this box is running our svn, cruise control, dns, mysql, webserver, etc... for all internal development. Man what a pain. I invite all readers to share similar stories about crashed boxes in the comments field. (I'll post a pic of the box next week).

Krispy

Labels: , , , ,

Tuesday, January 02, 2007

Why oh why did my BIOS die!!!

So I'm on my xmass break from work and I get the clever idea to update my bios on my Toshiba M60 laptop. Why would I do this you ask? Well, I like to fiddle. In this case I was attempting to boot from a usb drive (a way to "clean room" boot for testing). Turns out I need to update the bios to allow the laptop to be able to boot from usb. No problem.



I go to Toshiba Canada and download the latest bios and read the instructions carefully: They actually recommend using Windows to preform the bios update as opposed to burning an iso to cd and booting from that. OK.... um.... well they must know more about it then I do so here we go.



The flasher starts up no problem and starts doing its thing when OH NOOOOO!!! Blue Screen of Death dump all over the screen!!! NOOOO!



So it puked and froze. Just like in that mac ad (BTW: I hate windows and have been using Ubuntu for the last 4 months ~ and I am also now using a Mac G4 dual 800Mhz)



It does not respond to a powerdown request by me (along with some obsene profanity). I actually had to remove the power and the battery to get the thing to reboot. Well sort of. It was a brick at that point. No boot up for me. Crap.



It wont boot from the CDRom either - the bios has died. So its off to the repair shop for me. I recommed anyone who buys a laptop also buy an extended warrentee plan - it is soo worth the extra money. Saves you so much time and effort in the long run.



I hope to have it back in my hands (with a new motherboard no less) by Thursday. In the mean time I've shang highed a spare system in the office and installed FC6 on it.



Ah the life of a geek.









powered by performancing firefox

Sunday, November 26, 2006

20 Lession

Originally Posted At: http://www.dcs-media.com/desdev/Detail.aspx?ArticleId=578

Here are my most memorable lessons so far.

  1. Set a duration of how long you think it should take to solve a problem - C'mon, admit it! I'm just as guilty as the next programmer. I've seen programmers sit in front of a monitor for eight hours at a time trying to solve a particular problem. Set a time table for yourself of 1 hour, 30 minutes, or even 15 minutes. If you can't figure out a solution to your problem within your time frame, ask for help or research your problem on the Internet instead of trying to be super-coder.
  2. A language is a language is a language - Over time, once you understand how one language works, you'll notice similarities between other languages. The language you choose should provide you with a suitable "comfort" level, the ability to produce efficient (and clean) code, and, above all, allow the language to suit the project and vice-versa.
  3. Don't over-"design pattern" applications - Sometimes it's just easier to write a simple algorithm than it is to incorporate a singleton or facade pattern. For the most part, it even allows for cleaner, understandable code. :-)
  4. Always backup your code - I've experienced a complete hard drive failue and lost a lot of code when I was younger and felt horrible because of what had happened. The one time you don't back up your data may be the one time where you have a strict deadline with a client and they need it tomorrow. Source code/version control applies here as well.
  5. You are not the best at programming. Live with it. - I always thought that I knew so much about programming, but there is always someone out there better than you. Always. Learn from them.
  6. Learn to learn more - With number five explained, I've always had a magazine or book in my hand about computers or programming (ask my friends, they'll confirm). True, there is a lot of technology out there and keeping up with it is a fulltime job, but if you have a smart way of receiving your news, you'll learn about new technology every single day.
  7. Change is constant - Your knowledge of technology and/or programming should be similar to how you treat stocks: Diversify. Don't get too comfortable with a particular technology. If there's not enough support for that language or technology, you might as well start updating your resume now and start your training period. My general rule of thumb that has kept me going? Know at least two or three languages, so if one dies off, you have another one to fall back on while you train for a new technology.
  8. Support Junior - Assist and train the junior/entry-level developers on good programming guidelines and techniques. You never know...you may move up in rank and you'll feel more confident having personally trained and prepared them for their next position.
  9. Simplify the algorithm - Code like a fiend, but once you're done, go back through your code and optimize it. A little code improvement here and there will make support happier in the long run.
  10. Document your code - Whether its documenting a Web Service API or documenting a simple class, document as you go. I've been accused of over-commenting my code and that's something I'm proud of. It only takes a second to add an additional comment line for each 3 lines of code. If it's a harder technique to grasp, don't be afraid to over-comment. This is one problem most architects, backup coders, and support groups don't complain about if you've done your job right.
  11. Test, Test, Test - I'm a fan of Black Box Testing. When your routine is finished, your "stamp of approval" period starts. If you have a Quality Assurance department, you may be talking more to them than your project manager regarding errors in your code. If you don't test your code thoroughly, you may develop more than code. Possibly a bad reputation.
  12. Celebrate every success - I've met a lot of programmers who have conquered headache-style problems with a great programming technique and celebrated with a fellow programmer by doing the "shake", the high-five, or even a "happy dance." Everyone has enlightening periods in their life and even though that one happy coder asked you to come and see his extraordinary piece of code and you've seen that one piece of code over 100 times in your experiences, celebrate the success of a fellow developer for the 101-st time.
  13. Have Code Reviews Frequently - On projects and personally. In the company, you will always have code reviews of how well you coded something. Don't look at it as people crucifying your coding style. Think of it as constructive criticism. On the personal front, review your code and always ask, "How could I have done it better?" This will accelerate your learning and make you a better programmer.
  14. Reminisce about your code - There are two ways to looking at old code: "I can't believe I wrote this code" and "I can't believe I wrote this code." The first statement is often of disgust and wondering how you can improve it. You'd be surprised at how old code can be resurrected into a possible and better routine, or maybe even an entire product. The second statement is of amazement and achievement. Developers have their one or two project code achievements that they completed and had everyone standing up and taking notice. Again, based on your excellent coding ability, you could take those past routines or projects and update them into a better product or idea.
  15. Humor is necessary - In my 20 years of development, I have never met a programmer who hasn't had a decent sense of humor. Actually, in this industry, it's a requirement.
  16. Beware the know-it-all, possessive coder, and the inexperienced coder - Humble yourself when you meet these types of coders. The know-it-all tries to upstage you instead of working as a team player, the defensive coder created code that he doesn't want to share with anyone, and the inexperienced coder constantly asks for assistance every ten minutes where the finished code developed is yours, not theirs.
  17. No project is ever simple - I've been asked by friends, family, and associates to just "whip something up for me." To "whip" up a program or web site, it takes planning from both parties to complete something that both sides can appreciate. If someone needs a 3-page web site with Microsoft Access from the start, it winds up becoming a 15-page web site with SQL Server, a forum, and a custom CMS (Content Management System).
  18. Never take anything for granted - If you take on a simple project, you may think that a certain section will be easy to complete. Don't think that even for a moment. Unless you have a class, component, or piece of code already coded...and has been tested thoroughly...and is in production from an existing project, don't think it will be easy.
  19. Software is never finished - A fellow programmer once told me that software is never finished, it's "temporarily completed." Sound advice. If the client is still using a program you wrote and has stood the test of time, chances are, you are still updating it, which isn't a bad thing. It keeps you working. :-)
  20. Patience is definitely a virtue - When clients, friends, or family members use a PC, they get frustrated and proceed to hit a component of the PC or storm off. I keep telling everyone, "you are controlling the computer not the other way around." You need to have a certain level of patience for programming computers. As soon as programmers understand what they did wrong, they look at it from the computers point of view and say, "Oh, that's why it was doing that."

I hope this list of lessons learned have either inspired or provided a chuckle for some people.

Wednesday, November 08, 2006

Java UTF8 and MySQL / JDBC

So if you have ever had the joy of trying to figure out why the hell java wont store UTF8 data correctly in a mysql table I have found the answer finally:

---- Orig Post ---- [ http://forums.mysql.com/read.php?39,43303,43303#msg-43303 ]
I have problems updating data in utf-8 table using JDBC's PreparedStatement. I use something like:

PreparedStatement stmt=conn.prepareStatement("UPDATE tab SET field=?");
stmt.setString(1, str);
stmt.executeUpdate();

Non-ASCII chars int str are converted into question marks. I can read utf-8 data without problems but updating is a bit problem. Updates via mysql console is problem-less as well as PHP. But those question marks are...simple said - problem.

Could somebody give me some advice?

Thanks,
Lukas
------------------------------------

To which the answer was

---- Post -------- [ http://forums.mysql.com/read.php?39,43303,43373#msg-43373 ]
Solved...
I had to use useUnicode=true&characterEncoding=UTF-8 in connection string... Now everything works fine.
-------------------

Guess what it actally works!!!

Tuesday, October 31, 2006

Fixing Exadel Studio Plugins

So I have had an issue for a while with Exadel Studio and trying to add new plugins and maybe some of you have had the same issue?

"The current configuration contains errors and this operation can have unpredictable results.
org.hibernate.eclipse.feature (3.1.0.beta5) requires plug-in "hudson.freemarker_ide"."

Well here is the solution:
--------------------------------------
We found a solution!
You need to delete this string



in this file

\eclipse\features\org.hibernate.eclipse.feature_3.1.0.beta5\feature.xml

It will be fixed in the next release.
--------------------------------------

BTW: it was not fixed in the 4.0 release.
Source of info:
http://forum.exadel.com/viewtopic.php?p=15548&sid=1705e75e0ec81aeebf3d0e8a11dce4c7

Labels: ,

Friday, October 20, 2006

Best Eclipse 3.2 ini settings

After much frustration here are the best Eclipse 3.2 ini settings I found for my system:

-vmargs
-XX:MaxPermSize=512m
-Xms512m
-Xmx1024m

Apparently there is a perm gen bug in jvm 1.5.08 from sun that is made worse by using eclipse 3.2. Origonal source: http://eclipsezone.com/eclipse/forums/t82472.html

Thursday, August 24, 2006

Ajax File Upload Monitored

This is cool but complicated...sort of... too many cool things could be done with this.

http://blogs.missiondata.com/?p=28