Posted on March 17th, 2008 by Jeff
Joel Spolsky, of Joel On Software fame, recently wrote about
web standards. Now, I’m a regular reader of Joel’s blog and usually find some nuggets of wisdom there, especially when it comes to running a business. However, on the subject of doctype and standardistas, he’s dead wrong.
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
Posted on March 6th, 2008 by Jeff
It’s been a long time since I’ve worked on VisEmacs.net for varied reasons, the biggest being that I’m
still stuck using Visual Studio 6.0. I’ve watched VS2002, then 2003, ‘05 and now ‘08 get released and I had no itch to scratch.
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
Posted on January 14th, 2008 by Jeff
Last time, I promised that we’d make our testimonial application more friendly for users and less so for spammers and that’s what we’re going to do today, among other things of course. Let’s get’r done!
Somehow, we overlooked the user’s name when we created the schema for the testimonial leaving us only the email address to use as an attribution. Fortunately Rails’ migrations makes it trivial to add the new field. Drop into the shell and generate a migration:
script/generate migration AddUserName
create db/migrate
create db/migrate/004_add_user_name.rb
end
Open that in your editor, and make it look like the following. I think 64 characters is long enough to hold a name for this app.
class AddUserName < ActiveRecord::Migration
def self.up
add_column :testimonials, :name, :string, :limit => 64
end
def self.down
remove_column :testimonials, :name
end
end
Alright, now we’ve added a place to store the user’s name.; we’ll let ActiveRecord handle the CRUD for us but it’s still our task to ask the user to enter their name. To that end, we need to edit the form that is used to edit a testimonial. We factored that out of the add view into a partial named _form.rhtml. Let’s ask for our customer’s name before we ask them to give up their email address, that seems more neighborly, don’t you think? At the top of the form, add the following:
Read more…
No Comments »
Filed under: Rails, walkthrough
Posted on January 7th, 2008 by Jeff
While working on the Testimonial application, I needed a way to store application specific configuration details — the parts that are specific to a deployment: site name, url, etc. A quick search turned up the
ApplicationConfiguration plugin which does exactly that, using YAML. It’s based on the technique described by
Dmytro Shtefluk and uses OpenStruct to parse the config file and supports RAILS_ENV specific settings.Borrowing Dmytryo’s example:
common:
support_email: admin@myhost.com
root_url: myhost.com
photos_max_number: 6
production:
email_exceptions: true
development:
root_url: localhost:3000
photos_max_number: 10
In your application, it’s pretty simple to get at these values. Each value specified is stored as a member in the ::AppConfig structure:
AppConfig.photos_max_number
AppConfig.email_exceptions
I did run into one problem using the plugin; it uses config as the name of the structure, which conflicts with Rails, or some other gem that I’m using. I edited the plugin source and changed the name of the struct to AppConfig and now I’m happily keeping my configuration data DRY.
No Comments »
Filed under: Rails
Posted on December 31st, 2007 by Jeff
I was reading the
Pickaxe book today, brushing up on my Ruby skills and came across a passage that had me thinking about how our approach to programming affects our job and career. It started simply enough, explaining Ruby boolean expressions
Ruby has a simple definition of truth. Any value that is not nil or the constant false is true.
But then it got worse:
However, C, C++ and Perl programmers sometimes fall into a trap. The number zero is not interpreted as a false value. Neither is a zero-length string. This can be a tough habit to break.
Read more…
2 Comments »
Filed under: General
