Looks like the latest update Google made to their maps API broke my Inline Google maps plugin. The symptoms are the page becoming un-responsible, or map flickers when browsing using Opera.Though the plugin is not developed anymore, I'm planning to make a fix for those who are using it on their web pages. The problem is that I'm totally buried with work currently, so you will have to wait until next week for the fix. Sorry :(
82%Thought I'm just a little bit over 100 ;)
If you haven't noticed already, Rails-based application's logs can grow up pretty fast with default settings even in production mode. I just have one system which generated about 500Megs of production.log in just about a month. This is not a very good situation when you're on a shared host with limited hard disk space. So unless you are totally anal about what's going when on your production server (and well.. I don't know why you should be, since stuff is supposed to be at least partially stable when you actually deploy it) - you might want to limit logging, or eliminate it completely. Here's how.By default, logging level in production mode is set to :info, meaning every request will be logged, and that's not your Apache log. A single entry is something like that:
Processing FrontController#news (for 124.110.11.17 at 2007-11-09 17:55:11) [GET] Session ID: f14f25c56d59f278194146955357c198 Parameters: {"action"=>"news", "id"=>"249", "controller"=>"front"}Cookie set: visitor_id=177; path=/; expires=Sat, 08 Nov 2008 14:55:11 GMTRendering within layouts/kyoroman/frontRendering front/newsCompleted in 0.56727 (1 reqs/sec) | Rendering: 0.29647 (52%) | DB: 0.00000 (0%) | 200 OK [http://kyo-roman.com/news/249]
Pretty long for a single request huh? And do you really really need this info in your logs?If not, just open your config/production.rb file and add the following line:
config.log_level = :error
This way only errors will be logged. You can use :fatal instead of :error and have even fewer stuff being logged.But still, even with :fatal settings, SOME stuff will be logged, and this stuff are really fatal dumps like:
ActionController::UnknownAction (No action responded to unknown_request): /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/action_controller/filters.rb:632:in `call_filter' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/action_controller/filters.rb:638:in `call_filter' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/action_controller/filters.rb:438:in `call' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/action_controller/filters.rb:637:in `call_filter' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/action_controller/filters.rb:638:in `call_filter'
…………………. many many lines ………………
So you might want to just disable the whole logging totally. In a hasta-la-vista-baby approach. In order to do that, just add the following 2 lines to the end of your environment.rb file:
ActiveRecord::Base.logger = nil
ActionController::Base.logger = nil
And that's it. You'll get zero-sized logs. Just remember - ALL logs will be empty, development, production and testing :) Now.. I think there might be a better way to control logging, so if anyone knows a better way please share it in the comments.
MS Office is a complicated piece of junk software. Especially when it comes to Excel handling non-Roman encodings in anything outside of native Excel worksheets.
I have faced this problem when I was asked to output data from database (everything is stored in UTF-8, of course), to a CSV file. Which I, of course, did - and used UTF-8 as the encoding for CSV file.
Now we have: Unicode, already 10 years in use, and CSV, in use for even a longer time, and Excel, being developed by the biggest corporation in the world during all that time. What could go wrong you wonder?
Well.. Excel can and mostly always goes wrong.
The problem - Excel DOESN'T KNOW how to import Unicode UTF-8 CSV files! It just doesn't know about Unicode when it comes to CSV import! Absolutely unbelievable. More than that - if you use non-Japanese version of MS Office (I use English version) - you can't even export Japanese-language Excel document to CSV file! All Japanese characters will be converted to underscores.
The solution.
It took me several hours of googling, but I finally brought all the pieces together and here is what you need to do to create Excel-readable CSV with Japanese characters in it:
And no, you can't test everything works as it should on non-Japanese version of MS Office. There's just no support for ShiftJIS there!
Of course you can use OpenOffice which read Unicode (and any other encoded)-CSV files without a problem. It doesn't work good on Mac, but is pretty nice on Windows.
I can talk for hours on what the hell is going with Microsoft and its Office package, but what I think is this situation is just not acceptable in the year 2007 (and was not acceptable even in year 2003 when the prev version of Office came out). But oh well.. at least there's a solution which will possibly save someone a couple of hours and some couple of millions nerve cells ;)
There's one simple thing every system administrator should take into account, when settings up cron jobs, and which I - to my shame - didn't know until now.
When you setup a cron job, especially for a root user, I guess, your command runs in a very limited environment (basically, not paths and other variables set). So if you have a command in /usr/local/bin directory and can "test" it executes just fine from command line - it doesn't mean the same exact command will be executed successfully when running as a cron job!
Same goes for setting up and "testing" cron jobs with Webmin. You can click the "Run Now" button in Webmin's cron jobs manager, and the command will run just fine, generating output you expect - but when running as a cron tab job, your command might NOT work at all.
The problem, as outlined above, is that not all paths you expect to be set are actually set for cron jobs.
How to confirm?
You can just read root's email (or cron job owner's email). In terminal just type "mail" and then enter a number of message you want to read. Here's the output for a problematic setup:
& 5000
Message 5000:
From root@……… Thu Nov 1 00:02:01 2007
Date: Thu, 1 Nov 2007 00:02:01 +0900
From: root@……….. (Cron Daemon)
To: root@……….
Subject: Cron <root@www> monit validate #relaunches monit if needed
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>/bin/sh: monit: command not found
The solution? Just specify full path to the command!
In my case, monit is located in /usr/local/bin/ directory, which clearly is not defined in the PATH. So, it's /usr/local/bin/monit validate and you're set.
So, use full paths to your commands, and inside shell scrips (or set paths), and don't really trust Webmin' Cron Run Now command.
