Month: January 2009

  • Major Seagate/Maxtor Fail

    drive_failIt’s Friday, 10pm, and I’m not a happy camper. This picture is me holding a pile of ordinary hard drives I keep on my home desk. They are cycling backup drives and are not in any way frequently used. Four are Seagate Barracudas–one of which I’ve already had replaced–and the fifth a Maxtor DiamondMax. The oldest of the bunch appears to be from 2002 and all are PATA 200-250GB models. 

    I’m unhappy because I picked them up tonight to run a very infrequent backup of all my household data: over a TiB worth while requiring the use of all of them for a complete home backup. Much too my dismay, I won’t be running any backups this weekend.

    Failure rate: 100%. (5 out of 5 failures.)

    I haven’t been this unhappy with a manufacturer since the last of my IBM DeathStars failed around 2003. Fortunately all the Seagate models are still under warrantee, but such performance is still disheartening and frustrating.

    What’s happened to quality drive manufacturing in the 21st century? Some of the ~10MB hard drives in my 486-era machines easily lasted 10+ years, but a single drive these days lasting over 3 seems ever more scarce. Sigh.

  • Asset Tracking Webapp Written In Ruby On Rails

     

    asset_tracker
    Keeping track of company assets is important for insurance, warrantee and general informational purposes for purchased software licenses and hardware. I wanted a dirt-simple webapp written in Ruby on Rails, so I wrote one the other night and put the code on github. It’s a really simple Rails 2.2.2 app … no frills but does the job. If anyone would like to add some frills such as searching, sorting, pagination etc. I’d be happy to pull them back in. OpenRain would be very thankful 🙂
    asset_tracker 
    “A simple web-based asset tracking system for small businesses written in Ruby on Rails (RoR). New equipment is assigned to a specific location and the responsible person is notified of the assignment. You may optionally add serial numbers and an arbitrary amount of notes to each asset. Configured to run on top of PostgreSQL and sendmail by default, though both are reconfigurable.”
  • How To Make Original iPhone Sim Work In iPhone 3G

    I live in the U.S. and upgraded from the original iPhone to an iPhone 3G. If you simply put your old SIM into the 3G, however, you will only be able to use EDGE, and the phone will not use the 3G network. When purchasing a 3G model, multiple Apple sales representatives advised me that I would need to either keep each SIM in the phone with which it shipped and call AT&T to swap the phone numbers, or order a new SIM card for my existing number.

    Problem: AT&T won’t switch the phone numbers since each phone is still obligated to its own, separate 2-year contract, and ordering a new SIM will cost you $25.

    Solution: I physically went to an AT&T store and explained the issue. The sales rep just had to perform some voodoo in his computer system to enable 3G for the original iPhone SIM so it could be used in the new model and access 3G services. This allows AT&T to avoid having to modify any contracts while allowing you to upgrade to an iPhone 3G and use 3G services.

    Done!

  • Ben The Snowman Picture

    OpenRain’s heater when out recently, and it got cold. Property management figured out how to hack the unit into a working state again, but only after some badgering. Ben dropped some not-so-subtle hints 🙂

     

    img_0167

  • What If Ruby Had Final Variables Like Java Or Erlang?

    ruby

    After a long confusing Ruby debate today at OpenRain on the merits of functional, Erlang-esque write-once-read-many variables, I’m going to step onto the podium and just say it… Ruby should get “final” or “const” variables in a similar semantic style to Java, except at runtime. Rather than ramble on for 12 paragraphs explaining exactly how this might work, read this fictitious Ruby code snippet instead. (Optional: Also check out the chapter on “final” in Hardcore Java.)

    Final variables like this are really just an inline TDD mechanism.

    Allowing local stack data to be constant provides no functional enhancements to the software, but alleviates the need for certain types of tests by using the compiler and/or runtime to assert certain memory is immutable. The “friend_best” method variant in the code snippet would obviously break most existing Ruby programs, but ups the bar for defensive programming by preventing many common bugs out-of-the-box while still providing support for traditional Ruby variables. At the very least we should have something like “friend_better”. Adding this information to the parse tree will also make it easier for IDEs to provide features more easily implemented for static languages.

    TDD/BDD is in–no qualms about it–but we can make our code safer, cleaner and more concise by applying some of the lessons learned by our statically-typed language cousins over the last few decades.