macdiggs.com

I have faced a little problem today when I needed to merge two folders' contents, but with a little trick.

Basically, I usually work on projects using Subversion, so I always keep track of what's changed, but sometimes I have to give the files to third party for various  - usually design or content - enhancements. The problem is that I usually just don't have time/will/both to explain how Subversion (of version control systems, for that matter) works, and just handle exported files to the third party. This approach removes version control from files, but when I get the modified files back, I want them back into Subversion structure - this way I can see what exactly was changed, as well as have a ground to blame a specific person if some parts which should have not be touched, were actually touched and some part of the system broke in the result.

So, in order to that kind of trick, I need to merge "new" un-versioned directory structure into "old" versioned one, replacing all old files with new ones, but keeping my previous .svn directories.

You can't do folders merging using Mac OS X Finder, as well as I haven't found a good way to do that using FileMerge utility from Developer Tools. But there is actually an easy way to achieve the required result - and the tool for it is good old tar utility.

The way tar works during un-archiving is that is actually merges files and folders, and doesn't replace them. So, if directories on your hard drive and inside the .tar archive have the same name, the directories on your hard drive won't get erased and then replaced with stuff from .tar, but rather have their contents and contents of .tar directories merged. Just what I need.

Here's what you need to do to merge stuff.

We have two directories: project_trunk is a versioned directory, project_changed is the un-versioned directory we received from third-party. These directories are located on the same level so we can go between them with "cd ../project_trunk" or "cd ../project_changed" commands.

Open Terminal application and to the following:

cd /path/to/project_changed
tar cf  allfiles.tar *
mv allfiles.tar ../project_trunk
cd ../project_trunk
tar xvf allfiles.tar
rm allfiles.tar

You're done! The un-versioned directory structure was successfully merged into the versioned one.

Now just do svn status on the project_trunk directory and compare changes and commit. Very fast and easy :)

.. is a new server of course :)

Though I'm not much of a full-fledged SA, and just have to do it because nobody else in the company where I work at, can.. Still, there was a very warm and fuzzy feeling when I was unpacking our new Dell PowerEdge 1900 servers (well, only one of them because I'll do setup next month).

These actually are the first "real" servers which I'll be setting up and administering myself (there were lots of built-it-yourself servers before.. I wonder how they match against the "real" ones)

I'll be setting up separate application and database servers.. The specs are as follows:

Application: Intel Xeon Quad 2.33MHz, 8Gb RAM, RAID10 (6×250Gb), DRAC5 remote access card, Intel's Dual 1Gb Ethernet, RedHat 4.5

Database: Intel Xeon Quad 1.86MHz, 4Gb RAM, RAID10 (6×250Gb), DRAC5, Intel Dual 1Gbit Ethernet, RedHat 4.5

Well we don't yet even have a server room, closet, or anything.. Lots of things to setup, even more stuff to learn.

Here's a quick tip if you're getting errors like this one in your Rails application:

/usr/local/lib/ruby/gems/1.8/gems/actionpack-2.0.2/lib/action_controller/session/active_record_store.rb:84: [BUG] Segmentation fault

The most probable reason you're getting the Segmentation fault and your server crashes is because you're trying to store too much data in sessions table of your application (I assume you are using active_record_store as a session store).

The problem with "too much data" is that by default, the session table creation rake task created the following migration in Rails 1.x:

class AddSessions < ActiveRecord::Migration
def self.up
create_table :sessions do |t|
t.column :session_id, :string
t.column :data, :text
t.column :updated_at, :datetime
end
add_index :sessions, :session_id
end

def self.down
drop_table :sessions
end
end

Please note the data field defined as text. This means that it can only store up to 64Kb of data. And that also means that if you're trying to store more than 64Kb in your session.

In order to fix the problem, you just need to manually change the column type before you run migration which creates session store, or just create a new migration which changes parameters of the data column in existing sessions table:

Should look something like that (Rails 2 syntax):

class CreateSessions < ActiveRecord::Migration
def self.up
drop_table :sessions

create_table :sessions do |t|
t.string :session_id, :null => false
t.column :data, :binary, :limit => 10.megabyte
t.timestamps
end

add_index :sessions, :session_id
add_index :sessions, :updated_at
end

def self.down
drop_table :sessions
end
end

Empty your sessions table, restart your server and you're done. No more segmentation faults. Of course you shouldn't store that much data in a session in the first place, but well.. things happen. Now I'm off to fix my code which stores Megs of data in a session store ;)

Just as if I am not stressed enough to fight with IE for the correct layout, the IE Developer Toolbar just keeps bombing me with annoying and useless popups. Every time I place mouse over its panel

Well after thousand times I've been shown the popup I believe I already understand the idea of that particular panel, BUT NO. It keeps popping every time I put my cursor over the panel.

Every. Fucking. Time.

I just found out that there was a small chunk of code I forgot to change before releasing Inline Google maps 2.1.1, which could cause either no maps rendered on your page, or just some maps to be rendered.

Well, it's fixed now, so please download the plugin again here:

http://macdiggs.com/download/gmaps_v2.php.zip

Sorry about the problem… Was trying to fix the stuff asap, and the little bug slipped thru :/

I've been working on optimizing of a system written in PHP, which started to perform slowly, and I had to implement content caching so I could, say, calculate access stats once a day and then just output cached content to the user, or have top page regenerated every 15 minutes.. Stuff like that.

I thought I'd share my approach (which may not be the best around, but is a working one and can save somebody some time). So here goes….

First, we need to create a table to store cached information (I store cached information as well as system-wide settings in that table)

CREATE TABLE `settings` (
`key` varchar(250) NOT NULL default ",
`data` text NOT NULL,
PRIMARY KEY (`key`)
)

Next, we need accessors to the data in the settings table (just put these functions somewhere accessible by your code):

function settingsGet($key)
{
$key = addslashes($key);
$qstring = "select * from settings where `key`='$key'";
$result = queryDB($qstring);
$stuff = mysql_fetch_array($result);
return $stuff[data];
}
function settingsSet($key, $value)
{
$key = addslashes($key);
$value = addslashes($value);

$qstring = "select * from settings where `key`='$key'";
$result = queryDB($qstring);
if (mysql_num_rows($result)>0) {
//updating
$qstring = "update settings set data='$value' where `key`='$key'";
} else {
//inserting new
$qstring = "insert into settings (`key`, data) values ('$key', '$value')";
}
queryDB($qstring);
}

Next, we'll setup function to get and set cached data, which in turn use settings table accessors we created above. Again, just place them anywhere accessible by your code.

function get_cachedData($data_id, $expireSeconds = 3600) {
//expiring every hour by default

$data = unserialize(settingsGet("data_cache_{$data_id}"));

$lag = time() - $data["ts"];

if ($lag > $expireSeconds) {
return false;
}
return $data[value];
}
function set_cachedData($data_id, $value) {
$ts = time();
$data = array();
$data["ts"] = $ts;
$data["value"] = $value;
settingsSet("data_cache_{$data_id}", serialize($data));
}

Basically, we just use (hard-coded) prefix "data_cache_" to store data in the settings table (useful if you store something else in the settings table as well), as well as "data_id" variable by which you identify the "name" or id of data you wish to cache.

We will also need some nice wrappers:

function startCaching($data_id) {
if ($data = get_cachedData($data_id)) {
echo $data; return true;
}
ob_start();
return false;
}

function endCaching($data_id) {
$data = ob_get_contents();
ob_end_clean();
set_cachedData($data_id, $data);
echo $data;
}

Usage example:

Before caching:

function print_access_rating() {
/*
some code which requires a lot of time to get generated
*/
}

After caching was added:

function print_access_rating() {
if (startCaching("xxxxxxxx)) return;
/*
some code which requires a lot of time to get generated
*/
endCaching("xxxxxxxx");
}

The "xxxxxxxx" would identify the chunk of data you wish to cache. Say, you want to cache latest news section on your top page. For the forementioned usage example you can use print_access_rating as the data_id parameter. Or you can just pass the __FUNCTION__ php 's variable which is always set to the name of current function, if you want.

That's basically all. Please notice that you can use optional second argument of get_cachedData function to set number of seconds for which to cache a particular chunk of data.

Don't know how usable it will be for anyone except for myself, but here it is.. :) Modify to suit your needs.

..just kill me because I absolutely have no time to dig into it doh! For these lucky who do have time, follow here Somebody stop the planet and give me a couple of months of rest with just me and the computer (and the Internet, of course) :) 

We have a very weird problem with one of sites running WordPress. Suddenly, TinyMCE visual editor stopped working. It just disappeared, and we only got the weird:

realTinyMCE is not defined

error in the console.

Of course  visual editor was turned on in users preferences and all that stuff. Switching to a different theme was solving the problem.

Turned out that the problem was in the functions.php file which was located in WordPress current theme's directory. And the reason was the most weird one you can imagine! We had several excessive line breaks after the php closing tag!!

Have a look at these pictures:

Take  notice of these 2 excessive line breaks after the closing tag of the functions.php file.

Just remove them…

And everything's back to normal again!

So, check that the functions.php file in your current WordPress theme doesn't have any excessive line breaks after the closing php tag.

Sorry for keeping you waiting. I have finally had time to make a quick fix for the problems with browsers becoming unresponsible when Inline Google Maps plugin is used on them.

The new version of Inline Google Maps 2.1.1 is out now and can be downloaded from the link below. Everyone who's using this plugin, please update to the new version as soon as possible.

Download Inline Google Maps v2.1.1