So many toys, so many bits of paper. Our eldest son recently took an interest in his big sister’s Doodle Penguin toy, but we couldn’t find the instructions for it so had no idea how to choose from the 100 different pictures it’s able to draw. Needless to say for whatever reason the instructions are nowhere to be found on the web, luckily a little searching and I did find the original paper copy so I’ve scanned it, you can download it below. The PDF also contains the French (Pixel le Pengouin) and German (Mal für mich Pinguin) instructions. If this helped you, please leave a comment and let me know.
These are my notes from getting Ruby and rails installed on Fedora 8. I was setting up a Redmine test server at the time so I also had to install the ruby mysql gem for native mysql access.
I fell into every trap possible so here’s how I got around various issues.
Continue reading Install Ruby on Fedora
If for whatever reason you’re still maintaining an old install of Fedora 8 or 9 and need to get updates with yum you might find your way to this page fedoraproject.org – Enabling new signing key which contains links to download the new signing keys. Sadly the page hasn’t been updated in a while and the key rpm links are broken. You’ll probably find them with a Google search but might end up with suspicious files which sha1sum doesn’t match the sum given on Fedora’s own page
You can however grab the correct file direct from Fedora’s own archives
We were recently migrating some user records over to a new system and found that the older system had allowed a number of rogue characters into the username field (auto-generated based on firstname/surnname). So I needed to query the old SQL Server 2000 database to find any usernames that wouldn’t be accepted by the new system. At first it seemed that a huge list of
LIKE tests would be required, but ideally what I needed was a way to use a simple regular expression to match any username that didn’t contain acceptable characters. The T-SQL
PATINDEX allows you to do simple expression matching so I was able to pull out the records quite easily.
SELECT * FROM [usertable] WHERE PATINDEX('%[^- a-zA-Z0-9]%', username) > 0
Bascially the pattern starts and ends with a wildcard
% and then contains a range of acceptable characters, which is negated with the
^ operator, thus ensuring it only returns usernames that do not contain the acceptable characters. Since PATINDEX returns the starting position of the first match, the statement is looking for results where PATINDEX returns
This statement could also be written using basic LIKE syntax but the negation makes it confusing to read.
SELECT * FROM [usertable] WHERE username LIKE ('%[^- a-zA-Z0-9]%')
See the PATINDEX documentation over on MSDN
I’ve been helping our Operations team resolve some issues integrating a Joomla front-end with the SugarCRM SOAP API. The main problem: the sugarcases Joomla component refused to return any data from Sugar. After spending some time debugging the interaction between the Joomla component’s PHP-SOAP client and Sugar’s NuSOAP server, I managed to trace the following two errors:
looks like we got no XML document
SoapFault Object *RECURSION*
by enabling the SoapClient trace (
'trace' => 1) feature, I was also able to call
__getLastResponse to print the HTTP response content that was being sent from Sugar. What I was seeing was a completely garbled text. I concluded this must have been some sort of encoding mismatch between the client and server, so my first step was to disable SOAP compression by removing the constructor option:
$this->sugarClient = new SoapClient(null, array( 'location' => $this->server ,'uri' => 'http://www.sugarcrm.com/sugarcrm' ,'soap_version' => SOAP_1_1 ,'trace' => 1 ,'exceptions' => 0 //,'compression' => SOAP_COMPRESSION_ACCEPT | SOAP_COMPRESSION_GZIP | 5 ));
Immediately after doing that I was seeing valid content coming through in the response, and the Joomla component was correctly displaying data. Obviously we want to use gzip compression if Sugar and Joomla are going to be sharing large amounts of data, so I needed to get to the bottom of this. Fortunately a little more research, and I found a hint, way down in the comments (comment 45) on this nonplussed blog post.
Basically both Apache and NuSOAP were gzipping the response. NuSOAP was responding correctly to the accept-encoding header and encoding the response, but then apache was also gzipping the already gzipped content. So by the time PHP-SOAP got its hands on the response and decoded it, it still had a second layer of encoding to deal with, which it couldn’t.
To workaround this I modified
nusoap.php and commented out the compression logic (30 lines in total) in the
send_response() method, and I could then re-enable the compression in my SoapClient instance and everything worked as intended.