jump to navigation

mime-types version 1.16 has been released!
Monday, 2 March 2009

Posted by austin in: Ruby, comments closed

After an excessive amount of time, I’ve released MIME::Types 1.16. The primary purpose of this release is compatibility with Ruby 1.9.1, but I haven’t ignored the latest IANA registered types. I have also picked up a few other types that others submitted as patches and scanned through the latest version (1.27) of the Perl MIME::Types library.

MIME::Types for Ruby allows for the identification of a file’s likely MIME content type based on the file’s filename extension, or provides a list of extensions associated with a MIME content type, if known.

MIME::Types for Ruby originally based on and synchronized with the Perl version by Mark Overmeer, copyright 2001 – 2009. As of version 1.15, the data format for the MIME::Type list has changed and synchronization, if it happens, will be sporadic at best. The preferred source of input for a MIME::Type is the IANA registered list.

Copyright: 2002 – 2009, Austin Ziegler; based on prior work copyright Mark Overmeer.

Licence Notes

MIME::Types is available under Ruby’s disjunctive licence with the GNU GPL or the Perl Artistic licence. See the file Licence.txt in the package for full details.

Requirements and Installation

MIME::Types has been tested with Ruby 1.8.6, Ruby 1.8.7, Ruby 1.9.1, JRuby 1.1.6 (in Ruby 1.8 mode), and MacRuby 0.3.

MIME::Types can be installed with:

% ruby setup.rb

Alternatively, you can use the RubyGems version of MIME::Types available as mime-types-1.16.gem from the usual sources.

MIME::Types 1.16

Aw, Damn (Au Revoir, M Decoux)
Thursday, 25 September 2008

Posted by austin in: Ruby, comments closed

Guy Decoux, an extraordinary Rubyist, died earlier this month in tragic circumstances.

He will be missed by the community.

_why has some of the best commentary on this.

There’s already talk of a permanent addition to Ruby in his honour, $ABOUT.ts (”ts” was his email address), and Ruby Central is considering naming something (possibly a grant) in his honour.

Optimize What?
Sunday, 25 November 2007

Posted by austin in: Apple, Ruby, Technology, comments closed

There’s been a furore recently over an article by Ankur Kothari where he optimized CTGradient. As an exercise in optimizing code, it was fairly aggressive but otherwise pedestrian. As an article, it was inflammatory and insulting from the beginning:

CTGradient contains an incredible diversity of built-in gradients, gradient styles… For demonstration purposes, all these features are excellent. For production, this is a nightmare.

It gets no better at the end:

…The documentation already shows you how to draw gradients, yet the number of applications using CTGradient – the whole 1300 lines of it – is astonishing.Please: When you use other people’s code, don’t put it in without a thought. Go through it, understand it, and optimize it for your specific need. For the better performance and reduced RAM usage, computers will thank you.

Quite legitimately, some Mac developers spoke out about this. Hoare’s famous dictum Premature optimization is the root of all evil was pulled out early. It’s completely applicable here by any measure. This story would have ended here, and I wouldn’t be writing now, had it not been for a series of bile-filled nonsensical articles posted at Rixstep, starting with one calling Mac developers (such as Daniel Jalkut) objecting to this inflammatory article as the Landed Gentry of Mac Development™.

Which Optimization?

I’ve been developing software for a long time. While I haven’t done any Objective C programming yet, there’s nothing in Ankur’s article which is unique to Objective C. When developing software, you make it work, make it right, make it fast. In that order. The goal is to ship your software, not have it languishing in interminable development. Mac developers aren’t the only ones who will use third-party source without looking for optimizations (or further optimizations, as the case may be); Unix and Windows developers do this, too. Any developer worth their salt does this, because the first goal is to make it work. At work, when we see performance and memory issues, we don’t start digging through third-party code. We don’t even start looking at our own code. We start looking at profiled performance data. Then, and only then, do we start to make something fast.So, if the first goal of software development is make it work, what’s the first optimization you should do? You should optimize your developers’ time toward shipping the softare. Window background gradients aren’t the type of thing that will sell more copies of an application, but their absence may prevent some sales because the application doesn’t look “tasty” enough. So, you start looking at how to provide gradients. You see that Core Graphics supports it, and you start digging in the documentation and you see that it’s going to cost you lots of extra time to learn the CG gradient support. And then you have to debug what you’ve written. No sensible unit testing here; this is visual inspection. If you can add a single file that reduces your time to implement a background gradient—which you don’t really care about yourself but you know it’ll cost you sales not to have it—then you’re going to be better off entirely. Scott Stevenson of Theocacao stated it much better in 2006:

Ah. Now doesn’t that feel better? It’s not that the class does anything that is otherwise impossible, it’s just a lot cleaner because all of the goofy callbacks and whatnot are moved into their own code space. In other words, you have more free time to work on the actual application.

CTGradient is (almost) all about developer optimization. It also helps you deal with the second optimization: optimizing for correctness. It’s code that someone else has written and debugged. You know that other people who develop Mac apps are using it, and no one is screaming loudly about bugs in the code, so you feel pretty comfortable with it. So, you know that by using this drop-in library, you are not only getting this negative feature done, you’re getting it done right. At this point, you can forget about the getting it done fast, because no one has complained about gradient performance at this point, because you’re not yet done shipping.Make it work; make it right; make it fast. Optimize for developer time first (and this includes good design), and then worry about the rest when you need to.

More Code Optimization = Better Developer?

Things really went off the rails with this discussion when Rixstep posted the “Landed Gentry” article. He’s posted further bilious articles attacking some of the developers involved in the discussion over CTGradient optimization, but I’m not considering those articles for this discussion, since they’re pure bile and add nothing meaningful to the discussion (that is, they’re still based on false optimizations that I’ll address in a moment). In the “Landed Genry” article, Rixstep asks:

Who would you rather have engineer your software? Someone who’s as conscientious as Ankur Kothari? Or someone who squirms and attacks and insinuates and does the absolute utmost to avoid the actual question? You the user/paying customer can decide. Wander over to Ankur Kothari’s article on CTGradient and see who’s objecting. At least you’ll now know what the Landed Gentry of Mac Development™ think of you.

Rixstep presents a false dichotomy here. Ankur isn’t particularly conscientious in his article; there are specializations presented as optimizations, and some optimizations aren’t geared toward the most important parts of development anyway. Daniel Jalkut, on the other hand, is very conscientious toward his most important target: his customers’ time in using the program. I’d be very surprised if anyone was saying that MarsEdit is too slow because of gradient display.Optimizing on parts of code that don’t matter doesn’t make you a better developer. Optimizing the right parts of code at the right time do. If I were hiring Ankur and Daniel, I’d have to watch over Ankur more to ensure that he wasn’t working on stuff that doesn’t matter to the customer. Like optimizing gradient code without actually knowing that it was a performance bottleneck. Ankur does a decent job of making sure that the resulting code meets the minimum required needs of the job (which, if you’re developing from scratch is a good thing, after all, YAGNI). He outright says that one should spend time going through third-party code that (probably) isn’t relevant to the primary mission of your softwasre, and therefore doesn’t help toward “make it work.”In reality? They’d probably both work out as great developers. But Ankur cares no more about a user’s software experience than Daniel does, despite the insinuations of Rixstep. I do question Ankur’s judgement on the optimizations made and how they were reached, or at least how they were explained.

The Axis of Optimization

Let’s play along for a moment, though. Assume we have already determined that there’s a measurable performance problem and we don’t have any currently outstanding feature requests or other problems that are higher priority than this performance problem. Assume further that we’ve profiled our program and we’ve determined that yes, our source of program slowdowns is CTGradient.There’s a legitimate question about whether Ankur’s effort was really optimization or specialization. When he says Firstly, let’s remove the methods we know for sure we won’t need…, the discerning reader should be asking why we don’t need those methods. Ankur doesn’t explain how he reached this conclusion. This means that the developer who is doing their job right won’t immediately think of eviscerating the entire CTGradient library, but rather measuring the performance characteristics of the library.Ankur made a mistake in his approach. Yes, simpler code is usually easier to maintain, debug, and will usually perform better. But simpler code does not necessarily mean better or more performant code. A bubble sort is simpler than quicksort; there’s no way that it’s faster. One may as well look at binary size for comparison. This isn’t to say that one shouldn’t strive for smaller binaries; the larger your binary, the more likely it is that you’ll cause something else the user uses to swap out to disk, which would be bad. Can CTGradient actively contribute to this? It’s not distributed as a Framework, so most projects compile it directly into their code.CTGradient’s 1,172 lines of code in six source files (as determined by Sloccount) doesn’t even come close to adding meaningful binary code bloat. I compiled CTGradient from the latest available SVN checkout and Ankur’s “Lean Gradient” project. I compiled both as Universal using the default settings and compared the final binary size (from Contents/MacOS/) and the intermediate object file sizes. Since the projects are structured differently, it’s not a completely fair comparison. Ankur’s binary does one gradient and results in a binary size of 42,992 bytes; CTGradient does a lot of different types of gradients and results in a binary size of 78,776 bytes, a difference of a mere 35,784 more bytes of Universal code. A lot of the binary size differences is overhead, though. CTGradient creates three object files per architecture: CTGradient.o (55,964 bytes), CTGradientView.o (14,160 bytes), and main.o (976 bytes), leaving an overhead slack of 7,676 bytes. optGrad just has main.o (10,912 bytes), leaving an overhead slack of 32,080 bytes. So, CTGradient.o isn’t going to add to your binary size overhead in any meaningful way.What about memory use? Ankur posted two follow-up comments that suggested that CTGradient adds between three and ten megabyes of memory use to a program over and above his approach. That suggests that there might be room for a CTGradientLite, but making that would require extensive profiling to determine the parts that could be excised prior to doing so. And, of course, if all you need is a single gradient like Ankur did, and have the time and mathematical knowledge to do what Ankur did, by means do so. Ankur’s five minutes, though, might be five hours for you—so make sure that you don’t have something more important you should be working on.

The Unwashed Messes

Ankur can perhaps be forgiven for the mistakes he made, as other posts by Rixstep suggest that he’s quite young. He hasn’t yet had to learn the personal interaction lessons that most of us have to learn, and that most of us do learn. There’s a few who don’t, and Rixstep appears to be one of these developers who resisted learning about how to behave toward other people throughout his career. He stepped into this discussion “defending” Ankur from the “Landed Gentry”, who were simply asking the same questions that any good software developer would. He’s gone further recently into personal attacks against two of the more vocal questioners. Reading further on Rixstep’s site, anything that is selling better than his software seems to result in that anything being called the “Landed Gentry” of something. He thinks that he’s defeating dragons, but in reality he’s tilting at windmills just as usefully as Don Quixote did.Rixstep is supposedly in the business of selling software. The content and tone of his posts have managed to do the opposite. I had recently considered purchasing some of his software; I know now that to do so would have been a mistake, because he doesn’t treat his peers well. It’s impossible for him to treat his customers well with that sort of attitude. It doesn’t take much to be generous in spirit to people, at least in starting. It doesn’t take much to realize that there are better ways to deal with conflict than has been done.There is a difference between taking a hard-line, hard-nosed approach to something and defending it on technical grounds and actively attacking someone without basis. Rixstep’s attacks, starting with the “Landed Gentry” article, are entirely without merit. Ankur didn’t optimize CTGradient; he made a specialization. This is valid sometimes, but in reality something like window gradients isn’t central to your application’s purpose, and to spend more than an hour or two dealing with them would be wholly inappropriate. The good developer knows that it’s better to ship than to spend all your time optimizing someone else’s code or rewriting it yourself.

Where does Ruby Fit into This?

The astute reader would have noticed that I filed this as a Ruby article as well. While I haven’t mentioned Ruby until this point in the article, the parallels here are obvious. Rixstep and Ankur both say that the dozens of applications that use CTGradient are abusing their users because it uses too much code, too much space, too much memory, and it’s too slow. Aside from the memory use, the claims have either been exposed as false already or haven’t been supported with data. As Scott Stevenson’s quote suggests, CTGradient optimizes for developer time.So does Ruby. I can get more written with Ruby than any other language that I use. It won’t be the fastest software, it might be a little more memory intensive, but I will get it written—and written correctly—faster. And that, given that shipping is the goal, is important. When Rixstep rejects CTGradient without providing a more optimized yet equivalent functionality alternative, he rejects any developer-side optimizations in favour of hand coding everything, including using more expressive languages.I reject that notion. And so should you.

There’s a Ruby Debugger?
Wednesday, 31 October 2007

Posted by austin in: Ruby, Technology, comments closed

Yeah. My post title is a little over the top, but since I started using Ruby in early 2002, I can’t count the number of times that I’ve used the Ruby debugger. After all, how does one count the empty set?

This is not to say that I haven’t had to debug; it’s to say that where tests haven’t sufficed in helping me specify behaviour correctly, Kernel#p has helped me find what did go wrong so that I could fix the problem and add a test (where appropriate; PDF::Writer, for example, has no tests).

So I think that Giles Bowkett is right, even though I’d say that debuggers aren’t harmful; they’re pointless in a pointerless language.

I find that I mostly use the debugger in C/C++/C# for stack traces in any case. It’s a bit less painful with a good IDE, but depending on the nature of the problem that I’m debugging (especially one in a tight loop), I will usually add print outputs to a log file and debug based on those logs. Yes, even when there’s pointers involved (because it’s usually a binary search approach where I figure out where a pointer went bad over a large run).

On Derek Siver’s Return to PHP…
Sunday, 23 September 2007

Posted by austin in: Ruby, Technology, comments closed

Derek Sivers, recently abandoned his CD Baby rewrite from PHP to Rails. This isn’t bad news for Rails or Ruby, nor is it good news for PHP. It’s good news for CD Baby. Anyone who reads it otherwise is missing the lesson.

There are plenty of reasons to dislike PHP (although all of my criticisms have to be aimed at PHP4 right now, as I haven’t done anything with PHP5), but it is a useful general purpose language. It has different philosophies than Ruby, and I think that in general it isn’t nearly as good a language as either Ruby or Python. But it is just fine for a lot of people and projects.

Derek’s planned migration to Rails was probably doomed from the beginning for several reasons:

  1. Derek chose the technology for the wrong reasons. He chose it partially based on the hype of Rails, but he envisioned it as a silver bullet that would magically make his application better just because it’s in Rails. Rails has advantages (not least of which is its language, Ruby), but it has drawbacks and weaknesses, too.
  2. Rails didn’t fit Derek’s application model for CD Baby, and Derek’s application model is more important than the technology to be used, since it represents a business he understands well. Rails requires that your application fits its model, not the other way around. As Derek says:

    I hired one of the best Rails programmers…Jeremy [Kemper] could not have been more amazing, twisting the deep inner guts of Rails to make it do things it was never intended to do. But at every step, it seemed our needs clashed with Rails’ preferences.

  3. He ignored his existing experts for the new technology. Neither he nor his employees knew Ruby aside, perhaps, from playing around with it. This wasn’t a technology that was deemed to be appropriate from experience; this was a technology deemed appropriate by management (sorry Derek, you might still be getting your hands dirty with code, but you’re still management).

    I’ve wanted to introduce Ruby in my workplace for several years, but aside from a number of compile-time helper scripts, it hasn’t been appropriate to do so. First, our product isn’t in Ruby’s sweet spot. Second, none of my co-workers know how to deal with it or its development environment. Even when Ruby is a superior choice, it’s hard to introduce it, because I’m the only Ruby expert at work.

  4. Derek approached the project as a whole-environment ground-up rewrite with a One Big Day deployment, without considering ways to phase it in over time. It’s almost always possible to find interface points where you can replace one broken piece at a time. Ultimately, this is what the Rails folks wouldshould tell you anyway: replace one area at a time, each with a different codebase. Interface them as REST-ful services. Don’t make them depend on a single database schema.

Derek is wrong, though: language matters. A “better” language may not be the right choice for your environment, but its lessons will help you immensely. Without the Ruby and Rails experience, Derek would not have known to apply the lessons Ruby teaches to his PHP rewrite. I find that I write both C++ and C# with strong Ruby flavours these days. My boss, who has only used Ruby casually, has come to prefer the Ruby method naming convention (like_this) and a number of Rubyisms that I’ve introduced.

Ultimately, though, Derek’s Rails rewrite failed because he made a number of classic technology management mistakes. Not because of Ruby, Rails, or PHP. Because of management decisions made for the wrong reasons. Fortunately, he recognised this and was willing to reverse an expensive decision to fit his business better.

Beyond time
Saturday, 4 August 2007

Posted by austin in: Ruby, Ruby PDF, comments closed

In Twitteriffic today, I hit the wrong button on a message sent by Nathaniel Talbott and it took me to his blog, which had his entry about handing off test/unit to Ryan Davis. It has taken me a long time to reach this point, but it has to happen: I no longer have time to maintain PDF::Writer and most of its support libraries. I need a successor. Over the last year (since RubyConf ‘06), I have been talking with several people, but no one has actually submitted patches for me to review so we could push out some fixes.

I don’t really want to give up PDF::Writer or its ancillary libraries, but I owe it to the community to find a maintainer who will be more responsive and put more effort into it than I have. There are some issues to sort out regarding the pieces of the projects, and some changes that I would like to see someone implement. There are basically three projects:

  1. Transaction::Simple. This has improved significantly since the last release, but I have not yet implemented the Ruby 1.9 Marshal.load block trick that Matz implemented for me after a minimal case for a #become-like behaviour was shown.
  2. color-tools: This involves someone else, because after some preliminary discussion last year, I moved the color-tools codebase to the Color project on RubyForge and restructured things to be a bit smarter. There’s also some work that should happen hear regarding colour profiles, but that’s manageable. I basically want to work with the current owner of the Color project to hand this entire project off to someone who is interested in the math behind colours, and has the expertise to do something with it.
  3. PDF::Writer. The big one. I need someone to take care of this. No, the community needs someone to take care of this. I’m more than willing to share some thoughts about the code, but it’s a bit of a mess, and there are better ways to do what I did. The code can’t support the ultimate goal of reading.

None of this means that I’m giving up on Ruby, or on PDF generation; if I find time, you may yet find a different set of PDF tools from me in the future. But PDF::Writer is here and it needs someone to help maintain it.

Could that be you? Comments open on this post for interested parties to let me know. Be warned: I’m not just handing off PDF::Writer. I’m going to be looking at code samples; wanting patches. I need to know that you’re going to give the care the PDF::Writer needs and deserves before I hand off the virtual keys to the project.

Responding to Comments on “What’s Wrong…”
Friday, 27 April 2007

Posted by austin in: Ruby, comments closed

Huw Collingborne: I don’t know if Bitwise has an anti-Ruby agenda. I know that your initial articles that I read last year were…I don’t have anything nice to say about them, truthfully, I think they were that bad. On the other hand, you have committed some pretty serious resources with Sapphire in Steel, so I know you like Ruby.

As far as editorial responsibilities, I think that you do have a responsibility to ensure that what an author writes is both sensibly written and doesn’t contain gross errors. Editing does not mean that you change the authors’ words for them. You let them know when something isn’t clear or likley to be misunderstood. This was the policy at Artima’s Ruby Code & Style under James Britt. The words for the article that I wrote (and another that hasn’t yet seen the light of day, so I will probably publish it here after rewriting it) are all mine. Not someone else’s.

Matthew Huntbach: Somehow, I missed the reference to that other article. Aside from the fact that GameSpy made it nearly unreadable with stupid pagination, the original author’s point is as muddled as your own on this matter (of array addition). If a lot of people missed that point on array addition, I think that it’s clear your concept in writing that point was not.

You similarly missed my main point about Ada: Ada is actually a fine language and had reasonably “packaging” semantics that would act a lot like object orientation if used properly. Ada failed primarily because people could get cheap and easy compilers for C++, but Ada was completely proprietary. That’s why I pointed out Turbo C++ specifically. Pascal lasted a lot longer than it should have, because of Turbo Pascal and later Delphi. Similarly, Java would not have made the impact that it did without javac having been freely available.

You suggested that academics have had to be convinced that OOP was more than a fad. Personally, I have yet to be convinced that it’s more than a fad. I don’t mean, by that, that OO will go away. It will lose its primal position in CS at some point as people realise that it’s just another technique for organising your code, and it doesn’t automatically solve your problems. I’ve had enough arguments with people who don’t know how to do object modelling to strongly believe that most people don’t understand OO at all. I suspect that people like Booch and Rumbaugh understand it less than most, given how loudly they have trumpeted it without consideration for reality.

Let me make it clear: your impression that Ruby isn’t a silver bullet isn’t what’s embarrassing, in my opinion. Your arguments attempting to support your impression are muddled and sometimes simply incorrect.

You can say that you don’t think it’s all that radical. I’d agree with you. I’m not necessarily convinced that Ruby 1.8 is a good teaching language: there’s a few ugly, weird corner cases. Yet Chris Pine thought well enough that he wrote Learn to Program. Ruby will help people learn what it means to be intentional in their programming, and less rely on an IDE to write code for them (as is increasingly necessary with overwrought, overweight frameworks and languages like C#, Java, and to some degree C++). I have adapted my C++ code sytle to follow a very Ruby style in this—and it has really improved the readability and maintainability in the place where I work. So much so that there are people who now do the same things that I do.

For what it’s worth, I have little problems with academics, and I have significant problems with the asinine responses you received from members of the Ruby community. I do think that academics often forget that there is a real programming world out there while they’re teaching (having interviewed dozens of would-be programmers straight out of university with a CS degree but no knowledge)—but pushing for something bigger and better and smarter isn’t a bad thing, and academic researchers are necessary to push that forward. Non-researchers, though, seem to change very slowly and push ideas that, in practice, haven’t worked out very well in implementation—or, perhaps, were too early and need to be rediscovered again.

Static typing hasn’t proven to be all that useful—it catches a very small class of errors at compile-time while hiding much more serious errors (buffer overflows, for example) a run-time. (Ada wasn’t vulnerable to this, of course, because it put static typing into both compile- and run-time both.) Dynamic typing is much more likely to be useful in the long run, or some combination of it—either in Erlang’s “pattern matching” or in Haskell’s type inferencing.

What’s Wrong With Bitwise Magazine?
Saturday, 17 March 2007

Posted by austin in: Ruby, Technology, comments closed

I have a problem with Bitwise Magazine. They have published several articles critical of Ruby—and those articles have been singularly devoid of informed content. I’ve seen better articles on Slashdot, to be honest. Huw Collingborne’s article from a while back was bad enough (although he has done significant work lately to redeem that with Sapphire in Steel), but the latest example, What's Wrong with Ruby? is a shining example of ignorance masquerading as informed opinion.

It is obvious that Matthew Huntbach hasn’t done serious programming with Ruby or serious analysis of programs that are already in existence. Most of the vaporous commentary written (probably 80% of the article) would have been burned away by that simple exercise. Even if one were to accept the argument that [1, 2, 3] + [10, 20, 30] should be [11, 22, 33] instead of concatenation—an argument smashed as soon as one attempts to add heterogeneous arrays together, or arrays that don’t contain items that respond to #+—it would be trivial to add such a special case (and then abandon it because it does present such a special case to normal Array#+).

Mr Huntbach’s history is even questionable, with respect to Ada. Ada wasn’t accepted because it was something of a bastard language designed by committee (very similar to Pascal, but with amazingly strong type restrictions), not just because it was facing C++. Ada failed because Turbo C++ was cheap and, well, there was no Turbo Ada. It failed to capture the next generation of programmers because it wasn’t readily available the way that C and C++ were and introduced a number of significant development-time restrictions that made interacting with the rest of the operating system difficult. (It may not sound like it, but I actually like Ada, and I have ever since I took a class on it in early 1993. I still don’t program in it, although I have programmed in a descendant, PL/SQL.) If Java had not been available as a free download (as the JDK), no amount of computer science department gushing about it would have saved Java from the cheap and free C/C++ compilers available at the time. Ada was doomed because the whole world was changing (and not just to OO-style development) and it was stuck in a restrictive model.

The comparison of Ruby to Ada is a false one in any case: Ada was designed to solve a particular subset of programming problems (namely, those requiring exact specifications, e.g., military applications) that required a very strict specification and completely predictable behaviour. If a particular sensor can only return values between -128 and 127, then you can make a subtype of Integer restricted to those values—and you can be absolutely guaranteed that the values in variables of those types will never be outside of those ranges. So Ada wasn’t designed as a silver bullet; it was designed as a language where specifications, interfaces, and code very closely matched. Ruby, on the other hand, was designed to solve problems that Matz had. When he introduced it, other folks realized that it helped them solve problems that they had. And so it has grown from 1993 to 2007, where now literally thousands of developers realize that they are running into the limits of current programming languages. They’re writing tens of thousands of lines of code that don’t solve their problems, but provide scaffolding for their programming languages. Once those are written, they can usually write code to solve their problems. I believe that Matz has even said that if something came along that was better than Ruby and helped him solve his problems better, he’d use it. (At the very least, he’d take ideas from it to make Ruby even better, which he has shown himself willing to do many times over.)

A lot of Bitwise’s articles seem to lack editing. Mr Huntbach’s article was, at best, stream of consciousness, and had the feel of a blog posting, not an article in a magazine. If you’re going to call yourself a magazine, invest in editing resources. Ruby Code & Style, the Artima Ruby magazine, is going through some transitions and will be experimenting with a CodeProject-style system, where articles can go live without editing, but they will still be edited by a team of volunteers, and will be marked unedited until they are well-considered. Editing would raise questions about why easily refuted examples are chosen, fix errors with historical inaccuracies, and prevent articles as embarrassing as this one from being published under the magazine’s banner in the first place.

Yet, that’s not the only problems. As a long-time Rubyist, I’m actively embarrassed to read many of the comments on Mr Huntbach’s article. There are a few well-informed comments on the article, but the vast majority of them are painful to read and unnecessarily insulting. Mr Huntbach needs to be better informed, and his article needs editing, but there is no to be as insulting as some of the comments were.

Edit: I was alerted to this article through a post on RedHanded. I find Why the Lucky Stiff’s response to be useful, but there’s a lot of the same attitude that I didn’t like seeing in the Bitwise comments on RedHanded’s comments. Remember MINASWAN, folks. Regardless of what you think of Mr Huntbach’s credentials or where he teaches, it gains nothing to slag them; help him understand where he’s wrong and we’ll be that much better for it.

Transaction::Simple 1.4.0
Saturday, 3 February 2007

Posted by austin in: Ruby, comments closed

So I’ve finally had an opportunity to start working on my projects again, after having not worked on them for the latter part of 2005 and all of 2006. (I had other things going on.) I spent last night and today working on Transaction::Simple 1.4.0. I converted it to use Ryan Davis’s hoe. I made the .gem and the .tar.gz files idempotent (yes, my Rakefile depends on RubyGems—if you have problems with this, use the .tar.gz, thanks) and provide setup.rb 3.4.1 as part of the distribution. I also added a post-rewind hook (#_post_transaction_rewind) to fix the issues discussed last year. I went through and eliminated the warnings that appear, and I’ve decided that the #transaction method is bogus and will be removed with Transaction::Simple 2.0.

Transaction::Simple provides a generic way to add active transaction support to objects. The transaction methods added by this module will work with most objects, excluding those that cannot be Marshal-ed (bindings, procedure objects, IO instances, or singleton objects).

I’m going to need to look at hoe a little closer to provide a patch that will support the way that I need to use it (hoe’s default behaviour is pretty good, if not great for greenfield development; I have legacy behaviours I need to support). If Ryan doesn’t accept it (or at least the functionality I need, even if it’s in a different form), I may need to keep a private version around, because I had to do entirely too much manually even after I reorganized the project to match a lot of Ryan’s expectations.

Wow!
Monday, 6 November 2006

Posted by austin in: HaloStatue, Ruby, comments closed

Tom Copeland just reported that there’s a new RubyForge mirror in town. My mirror has had its ups and downs, but we hit on a great approach a while back: I’m just serving the Windows installer (and I’m the only one serving it, for now). I’m serving about a terabyte a month doing that. I’m glad I can do something to help with the growing bandwidth requirements for RubyForge. Right now, RubyForge and its mirrors are serving three and quarter terabytes monthly. Just wow.

(I’m deep in the middle of wedding planning, so more on the Transaction::Simple stuff later.)