Review: Envycasts What’s New In Rails 2.2
I’m not going to cover all the Rails goodness present in the ‘cast; that’d take the joy out of the whole thing for you, now wouldn’t it?
No Comments »
Filed under: Rails, reviews
Connecting ideas to code
I’m not going to cover all the Rails goodness present in the ‘cast; that’d take the joy out of the whole thing for you, now wouldn’t it?
No Comments »
Filed under: Rails, reviews
So how can such a noble endeavor go wrong? There are lots of reasons, but the most challenging to control is the effect that occurs when the QA department sits in the shadow of Development.
There is sometime a perception that the QA engineers are inferior technically to the developers. If this is the understanding in your organization, then QA will occupy a lesser position in the social structure. This mindset sets up an environment where development has a greater influence over the solitary QA engineer than is advisable.
There’s another variation on this trap that I’ve seen and that is when QA is over developmen — whether in actual reporting structure or pure political power within the organization. When this happens, QA is effectively driving the development process. Their schedule is imposed on the developers.
QA needs a build first thing Monday morning! Well, what if dev isn’t ready to give QA a build? Without equality between the departments or a capable arbiter, dev will be forced to overextend their resources (ie, work late hours or the weekends, resulting in lower morale and quality) or pass along an incomplete or buggy build to QA, thus wasting valuable time and possibly jeopardizing the schedule.
Another risk of having QA-over-Dev is that the development schedule may bloat to accommodate QA’s demands. When the schedule needs to be pulled in, management will be forced to cut features or testing time, neither of which results in a good, quality product.
The takeaway:
QA/QE and Development must be equals within the organization, preferably with a slight adversarial relationship.
1 Comment »
Filed under: Editorial
So here we are, merrily generating models, controllers and more. We’re writing code, writing tests and even running the tests to make sure they pass. All is good, right?
Wrong.
How many of you test your reverse migrations? Do they even work? I was bitten by this recently. The column names in a migration were spelled incorrectly so I thought, no problem, I’ll migrate down, fix the script and migrate up again.
Not so fast! The down migration was dropping columns that hadn’t been added yet — an error caused by modifying the migration before reversing it. Another error was caused by a misspelled table name, it wasn’t pluralized.
Since I’m working with mysql, ddl isn’t wrapped in a transaction. My development database is a snapshot of the customer’s data so dropping the whole database to recover from the failed migration isn’t an option either.
My advice: after creating a migration, migrate up, then immediately migrate back down. Make sure it works before moving on. The time you save might just be your own.
No Comments »
Filed under: Rails
DOCTYPE is a myth.
A mortal web designer who attaches a DOCTYPE tag to their web page saying, “this is standard HTML,” is committing an act of hubris. There is no way they know that. All they are really saying is that the page was meant to be standard HTML. All they really know is that they tested it with IE, Firefox, maybe Opera and Safari, and it seems to work. Or, they copied the DOCTYPE tag out of a book and don’t know what it means.
I think he’s got it wrong here. A designer or page author does, in fact, know that the html is standards compliant. We’re talking markup here, people. Any number of validators exist to check that it is so. This is not hubris, it is a fact.. or at least as factual as your validator is accurate! What a designer is not in control over though is the output of his markup. The doctype does not state that the output, i.e., the rendered page, is standards compliant but rather the input is.
Writing to a standard allows portability, whether your writing C++ or html. It wasn’t that long ago that Visual C++ couldn’t hand the C++ scoping rules for variables declared within a for-loop and when they fixed that bug it was a breaking change. Microsoft handled that in much they same way they’ll eventually handle the IE8 standards-mode issue: you have to tell the compiler (or browser) that you want the new behaviour.
It’s a reasonable decision.
No Comments »
Filed under: Editorial, webdev
But you’ve had one. And it’s time that itch was scratched!
Without much further ado, I’m releasing an early version of VisEmacs.NET. It’s a far cry from what I envisioned but it works -mostly. There are a few rough spots that result in your document not being sent to Emacs but no data loss bugs that I’m aware of.
As of this writing, there is no documentation. There is however, an installer. It’s pretty simplistic — it will happily let you install VisEmacs.NET on a system without Visual Studio — but it does get the job done. It does create the right registry keys and register the right interfaces for the addin to be loaded in VS2002 and VS2003. I don’t think it will work in VS2005 due to changes in the automation interface.
Once you have it installed, you need to tell it where to find gnuclientw and gnudoit, unless they’re on the path. Configuration is integrated into the Tools | Options dialog. There are other options there, most of them work with the exception of “Send Build Results to Emacs” — that’s not done yet.
As always, feedback is greatly appreciated. Let me know if you like it, love it, or hate it. If you find a bug, please report it to me at jeff <at> snowmoonsoftware <dot> com. Want a feature? Something not working? Send it in! Add a comment!
Please remember that this software is provided as is, and no warranty nor guarantee is given, express or implied. While I take pride in my work, this is not a finished product and has not been exhaustively tested.
You can download the pretest here (3.8MB).
1 Comment »
Filed under: News, Visemacs