Ian Oxley

I thought I'd posted these on here a while ago. But, as I couldn't find them earlier when I was looking for them, I'll add this post now so I can find them in the future

Anyway, here they are: Visual Studio settings files

I nearly always rely on the command line when moving data and / or schema changes between two different MySQL servers, exporting data with mysqldump then importing via something like:

mysql -u foo -p dbname < script.sql

When running this the other day though I was presented with the following error:

ERROR 1153: Got a packet bigger than ‘max_allowed_packet’ bytes

Fortunately help was at hand via this forum post. All I needed to do was run some SQL statements to set some global variables in MySQL like so:

set global max_allowed_packet = 1000*1024*1024;
set global net_buffer_length = 1000000;
	

To check whether this worked was merely a matter of running:

-- should return 1048576000
select @@max_allowed_packet;
	

Of course, you could always set the max_allowed_packet in your my.cnf file instead.

Update

After upgrading my MacBook Pro to OS X Snow Leopard, error 1153 was replaced with:

ERROR 2006: MySQL server has gone away

Fortunately the above still fixed things. Of course, if I'd listened to Phil Sherry in the first place I might not have had to re-install MySQL after upgrading OS X (although installing MySQL via the binary package installer did seem to install in /usr/local/bin leaving me puzzled as to why it disappeared after the Snow Leopard upgrade. But that's a story for another day…).

I was really impressed with the Xdebug Tailored Installation Instructions earlier today. Setting up a dev machine at my new job wasn’t going quite according to plan because, as nice as Ubuntu 10.04 Lucid Lynx is:

1. Installing PHP via sudo apt-get install php5 installs the latest version from the repositories (version 5.3 at the time of writing)
2. We do a lot of work in Drupal, mostly version 6 which isn’t compatible with PHP 5.3 (and quite a few modules that work with Drupal 6 don’t work with Drupal 7 apparently – Drupal 7 plays a lot nicer with PHP 5.3 by all accounts).
3. So it was necessary to uninstall all the PHP 5.3 packages, add the karmic repositories to the sources.list then reinstall PHP – this time PHP 5.2

Once all this was done, it was time to install Xdebug. The tailored installation instructions seemed the best option as I’d just had to revert to a previous version of PHP. And, it couldn’t have been simpler or more straight-forward to do:

1. Go to http://xdebug.org/find-binary.php, paste in the HTML from your phpinfo() output and submit the form
2. You’ll get a nice summary and some instructions to follow
   

   Summary

   

   Instructions

After following the instructions, restart apache and reload your phpinfo() page: if your experience is anything as good as mine you should see all the xdebug configuration options set up nicely and ready to go.

Since going freelance at the end of last month I made the conscious decision to use Git for my source control on freelance projects. I’d kind of used it a bit when adding stuff to GitHub but hadn’t really used it in anger on anything. Until now. And so far so good.

Quite a nifty little cheatsheet I found was this: http://cheat.errtheblog.com/s/git

I really like the aliases and colour-coding – simple stuff but these save you a lot of typing / keystrokes and make it easier to see at a glance what’s what respectively

This is just meant as a reminder for me, as I can never remember the colour values to use when trying to add that yellow highlight colour to some CSS (in fact, even as I’m writing this the WordPress permalink editor is taunting me with that very same colour).

So, without further ado:

• Hex: background:#FFFBCC;
• RGB: background:rgb(255, 251, 204);

I came across this nifty bit of code the other day when looking for a way to do this and, just for fun, thought I’d convert it to IronPython. So I did. And here it is:

import System

def is_assembly_debug_build(filename):
	"""Returns true if filename appears to have been built in debug mode"""
	result = False
	dll = System.Reflection.Assembly.LoadFile(filename)
	customAttribs = dll.GetCustomAttributes(False)
	for att in customAttribs:
		if att.GetType() == System.Type.GetType("System.Diagnostics.DebuggableAttribute"):
			result = att.IsJITTrackingEnabled
	return result

I saved this in a file called diagnostics.py. So using it (you’ll need to be in the same directory as diagnostics.py or have added diagnostics.py to your path – more info can be found here: http://docs.python.org/tutorial/modules.html#the-module-search-path) is simply a matter of doing something like this:

from diagnostics import is_assembly_debug_build
is_assembly_debug_build([absolute_path_to_your_dll])

If you’re interested you can grab a copy of diagnostics.py from http://gist.github.com/206177

Have fun

I often use a couple of paragraphs of Lipsum when testing forms containing <textarea> tags and have had this bookmarklet I cobbled together sitting on my Bookmarks Toolbar for a while now.

Anyway, I thought it might be fun to hook it up to a HTML 5 form to let you customise how many paragraphs of Lipsum you want each time you click it. So that’s what I went and did:

Lorem Ipsum Bookmarklet Generator

Hopefully it’ll save you a few mouse clicks next time you’re testing some forms.

(Please note that the form used in the generator uses the <input type="range" /> HTML 5 tag which currently works best in the latest version of Opera. YMMV when using other browsers).

So, you are using the e text editor and try to run a bundle only to be confronted with the following:

ruby: no such file to load — ubygems (LoadError) ruby: no such file to load — ubygems (LoadError)

After doing some digging it turns out the cause is the RUBYOPT=-rubygems environment variable that is set by the Windows one-click Ruby installer. Now, if you have not got rubygems installed you might be able to get away with simply unsetting the RUBYOPT environment variable (although YMMV).

However, as e text editor makes use of Ruby via Cygwin, another solution is to modify your .bashrc file:

Try this:

Go to the cygwin bash prompt.  If you don't know how to get there, use Start -> Run -> c:\cygwin\cygwin.bat.

Type:
echo unset RUBYOPT >> .bashrc

Type:
. .bashrc

Type:
irb

If you see:
irb(main):001:0>

You should be good to go.

But what worked for me – and I don’t know whether this has anything to do with me having Ruby installed under Windows and under Cygwin – was making the same changes to .bashrc outlined above to my .profile script (so simply replace .bashrc with .profile in the quoted text above).

Hopefully at least one of these methods should work for you.