|«« Super Size Me||MT-Blacklist Kicks Ass »»|
I'm Ryan Lowe, a Software Engineering graduate living in Ottawa, Canada. I like agile software development and Ruby on Rails.
I write this blog in Canadian English and don't use a spell checker. Typos happen.
» Full-time Ruby on Rails freelancer
» Full-time with Rails since May 2005
» Former committer for RadRails (now Aptana)
» I also have a few Rails side-projects in development:
1. wheretogoinTO.com Toronto nightlife
2. Hey Heads Up! TODO list and sharing
3. Layered Genealogy family history research
4. foos for foosball scoring
5. fanconcert for music fans (on hold)
Hiring Rails developers? I can telecommute by the hour from Ottawa, Canada
»» Email: rails AT ryanlowe DOT ca
Now hosted on Hey! Heads Up -- check it out!
Derek Lowe's (Ryan's older brother) words at Ryan's funeral
email@example.com no more
Forging Email Headers: Good, Bad or Ugly?
Sarcastic Dictionary (Part 1 of Many)
Twisting Rails is Risky Business
Risky Business? My Take on Early Alphas
Whoa, it's August 2007
A Postscript to "Growth at the grassroots"
»» All Blog Posts
David Heinemeier Hansson
James Duncan Davidson
Signal vs. Noise
Amy Hoy: (24)slash7
Luis de la Rosa
Java New I/O for Abstractions and ... Perf? Yes.
If you were used to dealing with Java I/O the old way, the New I/O APIs in Java 1.4 are really handy.
You don't have to read a chunk of bytes from the source file and write them to the destination file in a while loop -- it's all done for you. Roy has been testing this code for me and he says it's really fast too. Sweet.
Another nice class in
Buffers also keep track of where you are in the wrapped array. You can make your way through the buffer, pass it around to other methods and the current position and array length are passed as well. This makes ByteBuffer really handy for parsing bytes, and CharBuffer for parsing chars.
In particular I simplified my frame parsing code a lot by using a ByteBuffer and a method I made to pop the next null-terminated string off the front of it. It cleans up the frame parsing code nicely: I'm not looping through bytes looking for null in my frame parsing code any more, it's all abstracted. The great thing about this abstraction of course is that (encoded) String parsing is centralized now, leading to less errors in frame parsing code itself.
This is the intermediate step towards specifying frame fields with constants, like I mentioned before. These constants will specify for each frame field the type expected, it's maximum and minimum length, etc. Then you put it in a general frame field parser that understands how to parse all of the field types to objects from a byte. You get an array of parsed Objects back.
If all of the field values are in an Object array in the Frame subclasses, then the Frame superclass can handle general implementations of equals(), hashCode() and toString() and other methods. Not only will this save me from implementing all of these methods in the subclasses (there will be about forty), but it will also save me from testing them too.
Thinking about testing is often encouragement to get rid of code duplication, because if you have code duplication you'll end up with test duplication too. Who wants to write more tests then they have to?
 id3v2 supports Unicode UTF-8 and UTF-16.Posted at September 01, 2004 at 04:57 PM EST
Last updated September 01, 2004 at 04:57 PM EST