I haven’t used JavaScript and CSS seriously for many years now. These dinosaur-riddled posts provided good catch-up material for both:

• https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs
• https://medium.com/actualize-network/modern-css-explained-for-dinosaurs

FS-data was the first web hotel in Sweden to support Ruby on Rails (in August 2006, I think) and I’m glad they did. Unfortunately they haven’t touched their setup since, so patrons are still limited to (a) apps in subdirectories only and (b) FastCGI (FCGI). I have seen many complaints about FCGI, but I have only one: it’s really hard to know if it’s running my latest release. FS-data have added a control panel of sorts, but it’s pretty unreliable. Thus, I have to resort to killing. But what to kill?

$ ps -fe | grep rails
UID        PID  PPID  C STIME TTY          TIME CMD
wcj      27292  3558 27 13:41 ?        00:00:02 RAILS: /home/w/wcj/rails/sis/public/dispatch.fcgi
wcj      27365  3558 40 13:41 ?        00:00:02 RAILS: /home/w/wcj/rails/sis/public/dispatch.fcgi
...

With more than two processes I refuse to kill by PID – FCGI is just too quick to spawn new processes, and I’m not sure if they will run the right version of my app either. So it’s killall. But what to killall?

$ killall -9 'RAILS: /home/w/wcj/rails/sis/public/dispatch.fcgi'

does not work. So it’s ps to the rescue:

$ ps -eo pid,comm:30
  PID COMMAND
27365 rails_dispatche
27292 rails_dispatche

rails_dispatche, really? No final ‘r’? Whatever:

killall -9 rails_dispatche

It works and I’m happy again.

[This is a re-write of a project note I wrote in project over a year ago. Published here to make the world a better place.]

There has been some commotion recently regarding XHTML and HTML, where standardistas have reiterated their arguments about XHTML: it’s a nice standard, but since is isn’t actually treated as XHTML by browsers, it’s better to use HTML.

The “standard” text on this (at least for me) is http://www.hixie.ch/advocacy/xhtml from which I’d like to quote the executive summary:

If you use XHTML, you should deliver it with the application/xhtml+xml MIME type. If you do not do so, you should use HTML4 instead of XHTML. The alternative, using XHTML but delivering it as text/html, causes numerous problems that are outlined below. Unfortunately, IE6 does not support application/xhtml+xml (in fact, it does not support XHTML at all).

I have come back to that text on several occasions, but it never quite convinced me. I didn’t want to lose the well-formedness of XHTML. Then I ran across http://www.webdevout.net/articles/beware-of-xhtml which made me change my mind. The article uses numerous examples to show that XHTML is not just a syntactically nicer version of HTML, but it actually has slightly differing rules for how to apply CSS. So basically, in all projects that I have used XHTML, I have been relying on bugs in present browsers. Ouch.

Time to change—back

They promised us that XHTML was the future, so I haven’t worried too much about HTML lately. Are there any downsides to using HTML instead? Well, not per se. But the tools and platforms I use are slightly XHTML-centric.

1. All the standard Rails helpers (form helpers, JS helpers, etc.) produce xhtml. The simple solution is to drop this in a file in lib/:

   module ActionView::Helpers::TagHelper
     def tag_with_html_syntax(name, options = nil, open = true, escape = true)
       tag_without_html_syntax(name, options, open, escape)
     end
     alias_method_chain :tag, :html_syntax
   end
   

2. TextMate snippets produce XHTML. Most of them can be controlled by an environment variable, but there are exceptions, like C-ret which produces produces an XHTML self-closed br element.

3. External tools, data sources and parsers are usually xml-centric.
4. WordPress, which I have used for a few client projects lately, spits out XHTML. I’ll see if I can create a patch for that and have it accepted.

Oh well. XHTML, I’ll miss you. HTML, can we be friends again?