Well.

Bit more of a trouble than I wish to deal with today, but apparently Mongrel has changed somewhat in the latest version and doesn't deliver content as HTML, instead delivering it as text/plain (source html).

If you are using Mongrel to deliver your Ruby Apps, and you're sure your versions of gems meet the requirements - take a look at the below to try.

Add this file in, restart your application - and hopefully away you go. Again there is a lot of read/take in when it comes to dealing with this issue - hopefully I'm saving you about 1.5 hours of research. Original Source for the Patch I've forked..

Add this to redmine/config/initializers/mongrel.rb (create a new file)

# Pulled right from latest rack. Old looked like this in 1.1.0 version.
  # 
  # def [](k)
  #   super(@names[k] ||= @names[k.downcase])
  # end
  # 
  module Rack
    module Utils
      class HeaderHash < Hash
        def [](k)
          super(@names[k]) if @names[k]
          super(@names[k.downcase])
        end
      end
    end
  end
  
  # Code pulled from the ticket above.
  # 
  class Mongrel::CGIWrapper
    def header_with_rails_fix(options = 'text/html')
      @head['cookie'] = options.delete('cookie').flatten.map { |v| v.sub(/^\n/,'') } if options.class != String and options['cookie']
      header_without_rails_fix(options)
    end
    alias_method_chain :header, :rails_fix
  end
  
  # Pulled right from 2.3.8 ActionPack. Simple diff was
  # 
  # if headers.include?('Set-Cookie')
  #   headers['cookie'] = headers.delete('Set-Cookie').split("\n")
  # end
  # 
  # to 
  # 
  # if headers['Set-Cookie']
  #   headers['cookie'] = headers.delete('Set-Cookie').split("\n")
  # end
  #       
  module ActionController
    class CGIHandler
      def self.dispatch_cgi(app, cgi, out = $stdout)
        env = cgi.__send__(:env_table)
        env.delete "HTTP_CONTENT_LENGTH"
        cgi.stdinput.extend ProperStream
        env["SCRIPT_NAME"] = "" if env["SCRIPT_NAME"] == "/"
        env.update({
          "rack.version" => [0,1],
          "rack.input" => cgi.stdinput,
          "rack.errors" => $stderr,
          "rack.multithread" => false,
          "rack.multiprocess" => true,
          "rack.run_once" => false,
          "rack.url_scheme" => ["yes", "on", "1"].include?(env["HTTPS"]) ? "https" : "http"
        })
        env["QUERY_STRING"] ||= ""
        env["HTTP_VERSION"] ||= env["SERVER_PROTOCOL"]
        env["REQUEST_PATH"] ||= "/"
        env.delete "PATH_INFO" if env["PATH_INFO"] == ""
        status, headers, body = app.call(env)
        begin
          out.binmode if out.respond_to?(:binmode)
          out.sync = false if out.respond_to?(:sync=)
          headers['Status'] = status.to_s
          if headers['Set-Cookie']
            headers['cookie'] = headers.delete('Set-Cookie').split("\n")
          end
          out.write(cgi.header(headers))
          body.each { |part|
            out.write part
            out.flush if out.respond_to?(:flush)
          }
        ensure
          body.close if body.respond_to?(:close)
        end
      end
    end
  end

Full credit to Ron Savage over at Stack Exchange. He's written this fantastic function which creates a temporary table with two columns, 'interval_start' and 'interval_end'.

You call this function with a MySQL datetime ('2011-02-23 05:00:00'), and a MySQL end datetime ('2011-02-23 16:00:00'). You then specify what you want returned back to you (Seconds, Minutes, Hours, Days etc. See the function below for the full list of options).

What is returned is below will be similar;

I've been helping out of couple of friends with their University assignments recently and one thing that has bugged me to no end, is how they're not being shown how to keep code clean and manageable.

Take the following example (which is close to what their University lecture's have been giving out as an example).

<?php
	$fruitArray	= array(
					"apple" => "green",
					"tomato" => "red", 
					"banana" => "yellow", 
					"grape" => "purple", 
					"orange" => "orange");
	
	echo "<table>";
	echo "<tr>";
	echo "<th>Fruit</th>";
	echo "<th>Colour</th>";
	echo "</tr>";
	ksort($fruitArray);
	foreach ($fruitArray as $fruit => $colour) {
		echo "<tr>";
		echo "<td>" . $fruit . "</td>";
		echo "<td>" . $colour . "</td>";
		echo "</tr>";
	}
	echo "</table>";
?>

So the dilemma rose tonight when James wanted WordPress installed on his domain that he’s had since the dawn of time.  Awesome I say!  How exciting!  Get the zip, unzip it, set it up and go for it.

Well after fighting with Dreamhost for a little while on setting up new SQL database, I discovered there’s 5+ years worth of junk sitting in his root public html directory.  ”K dude, I’m just going to move these to a subdomain files. and you can start using that”.  Well, after posting for 5 years of links around the internet – he didn’t like that idea.

So I had this fantastic idea – install WordPress in a subdirectory and I’m sure we can find some .htaccess rewrite rules to compensate.  Turns out, it doesn’t appear to be a popular topic on the web.

(more…)

So I hope this gets into the world out there. I’m running the latest version possible of XAMPP for windows (shame on me for windows right?), Eclipse and xDebug.

One interesting thing that has frustrated the absolute hell out of me while working recently is that Apache continues to fail on every breakpoint in my code. “Apache has Stopped working”, and then silently restarts itself.

Sadly there is no further advise from Apache or PHP Logs even went making everything log to their fullest capacity.

And thus brings me to http://windows.fyicenter.com/view.php?ID=68&R=71 – Which is a fantastic little thing you can try on your local dev machines – which quickly and shamefully easily makes your PHP scripts run in php-cgi rather than the default setup of XAMPP.

I’m break-pointing again and everything is well in the land of New Zealand (Oh btw, I’m in New Zealand working my little coding ass off at the moment, should be back in the land of Oz early early June).

Cheers Chaps.