| «« Software Needs Communication | MVC Part II: Attack of the Mutators »» |
|
About
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.
Projects
» 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
BulletBlog
Now hosted on Hey! Heads Up -- check it out!
Syndication
Pings
Recent
Derek Lowe's (Ryan's older brother) words at Ryan's funeral
blog@ryanlowe.ca no more Forging Email Headers: Good, Bad or Ugly? Sarcastic Dictionary (Part 1 of Many) Tags Hierarchies Twisting Rails is Risky Business Risky Business? My Take on Early Alphas Whoa, it's August 2007 Closing Comments A Postscript to "Growth at the grassroots" »» All Blog Posts
Linkage
del.icio.us/ryanlowe
technorati/ryanlowe.ca/blog Aurora Roy Jim Andrew Trasker Travis Kibbee Karen Dr. Unk Ayana Van Bloggers Joel Spolsky Robert Scoble Tim Bray Dave Winer Raymond Chen James Robertson Ruby/Rails Bloggers rubyonrails.org weblog David Heinemeier Hansson Dave Thomas James Duncan Davidson Mike Clark Jamis Buck Signal vs. Noise Tobias Luetke Amy Hoy: (24)slash7 Jeremy Voorhis Eclipse Bloggers Planet Eclipse EclipseZone Luis de la Rosa Eclipse Foundation Kim Horne Billy Biggs Ian Skerrett Mike Milinkovich Bjorn Freeman-Benson Denis Roy
Archives
|
Showdelayers
Wow, been a pretty slow week. Two things I'm working on for AudioMan right now: threading and file library issues. The file library issues are easy to fix but will take some refactoring. The code that reads the file meta data has the AudioMan object AudioData throughout it. From a coupling standpoint, this is bad. So even though it will make the libraries less efficient (copying data), I'm making libraries that can be used on any other project not just AudioMan. I may even release them under the LGPL later, assuming I can get everyone's permission. The threading issue is really sticky. Once you start to get more than one thread going in a program the complexity skyrockets. You have to think of all of the situations a simple operation could be interrupted and how events can conflict or resources can deadlock. There's no question that AudioMan should be multi-threaded, the only question is how and how much. The major problem causer at the moment is letting people browse the collection will files are being included, on a long Include Directory operation that crawls all of your directories. While the view is switching models, the mutators are sending messages to the models and they get shown by the wrong views. Other tracks are getting lost. I think I will have to suspend the mutators while the view is swapping ... but that's not as easy as it sounds. At any rate, I'm taking some time to figure out those things before I attack. These are both basic problems that need to be addressed right now. Posted at March 06, 2004 at 06:39 PM ESTLast updated March 06, 2004 at 06:39 PM EST Comments
"The code that reads the file meta data has the AudioMan object AudioData throughout it. From a coupling standpoint, this is bad." I was looking over this section of the code yesterday and thought the same thing. » Posted by: James at March 7, 2004 07:33 PMWhy did we do it that way? Well, we were following the admittedly lazy YAGNI (you ain't gonna need it) principle, which favours simplicity over an involved design. We weren't going to support other file formats then, so it wasn't necessary to "design" for it. Now we can go back and refactor the code. » Posted by: Ryan at March 7, 2004 09:19 PMI forgot to add that the benefit of this "lazy" strategy's simplcity is that it is more agile and therefore easier to maintain. Because we only had one type of file to read, the coupling offered a simpler more direct solution to the problem. Seperating them would have been cleaner architecturally but would have left people asking "why?". Exactly. Overdesign slash extreme up-front design solves nothing. It looks great on paper but ultimately by the end you have no product, just paper. We spend more time producing, iterating and getting feedback and less time pontificating on the architect chair. » Posted by: Ryan at March 8, 2004 05:36 AM |