fogbound.net




Wed, 24 Sep 2014

Another Maytag FAPOS*

— SjG @ 7:49 pm

In 2007, the old dishwasher that had come with the house gave up the ghost. Repair would have cost 2/3 the price of a new one, and thinking that perhaps better water and energy efficiency could be had, we bought a new one.

We went to Sears, and bought a Maytag. Hey, we thought Maytag’s a solid brand. We want this thing to last! We didn’t know that in that in ’06, Maytag was bought by Whirlpool. We also didn’t know that somewhere in the early naughts, the appliances that they were manufacturing were being designed to fail right along the warranty boundaries. But for the moment, we had our Quiet Stream 300, shiny, new, and efficient.

In 2009, I had to replace the control panel circuit board. Seems the power drawn by the LEDs is right about the limit of what the transistor can switch. Maybe a bit over what it can handle. In any case, it melted.

Melty Melty

$156 bucks plus shipping later, then an hour of playing around with tools, and we were back in business.

Today I came home to find the door latch jammed up in a weird way, and all the dishes taken hostage. A little feeling around, and it was clear the handle was no longer supplying the necessary leverage to whatever latched the door. Further poking around with a thin screwdriver, and I was able to open the door. Removing all the front panel, I got ahold of the latch assembly.

Well, look at that. That hinge design… those metal rods give strength to the latch handle, and are secured within the plastic of the handle itself — by delicate, thin sleeves.

Maytag Flimsy

Now look at this blurry shot, and check out the spring this flimsy little plastic sleeve is working against. Yes, it’s working against it with a lever arm. But seriously? Under-engineering a latch to save $0.00001 worth of plastic?

Blurry spring

Yup. The spring itself is made of wire thicker than the plastic of the sleeve. For fuck’s sake. Who comes up with a weaksauce design like that? Well, it’s either some asshole engineer who doesn’t give a rat’s ass, or some shit-sucking lickspittle manager who abuses the engineer into doing it so they can increase margins. Either way, I raise my middle finger in salute to the bastards, and hope they choke on an under-ripe rutabaga.

*FAPOS – Flimsy Ass Piece of Shit

Filed in:

Wed, 17 Sep 2014

PHP 5.5, PHPUnit/Selenium, Yii, and Mac Ports on Mavericks.

— SjG @ 4:07 pm

There is a special place in hell where every programming project creates its own package manager and you have to use it if you want to use the project. Oh, wait. That’s not a special place in hell. That’s here. Crap.

Some days, I shouldn’t bother getting out of bed. On those days, I have that weird broken cognition that I call “user brain” — I don’t read error messages, I don’t stop to think, and instead of looking at problems and trying to solve them, I randomly bounce around and break things.

So I had User Brain. I was setting up a new name-based SSL virtual host in my development environment, and dropped a line from the configuration. Then I didn’t read the Apache error message carefully, and foolishly thought “Oh, I must need to update my certificate trust chain.” This resulted in my updating my environment via mac ports — and when it asked me if I wanted to migrate from php5 to php5.4, I said OK.

When I finished that process, my development environment was completely b0rken, and I hadn’t solved the original problem. Fast forward an hour of questionable language, and I had a new strategy. Install PHP 5.5!

There are several guides out there on how to make all this stuff work, but they didn’t really work for me. What did, was the following. First, I logged in as root. If I’m going to make stupid mistakes, it’s best to do it with unlimited power. Anything else is unsporting.

# port uninstall --follow-dependents php54

That got rid of all the PHP 5.4 stuff left over from my previous debacle. So now it’s time to install PHP 5.5, and the various modules I need:

# port selfupdate
# port upgrade outdated
# port install php55 php55-gd php55-mbstring php55-iconv php55-curl php55-zip php55-soap php55-pcntl php55-xmlrpc php55-openssl php55-sockets php55-imagick php55-mcrypt php55-solr php55-mysql
# port select --set php php55
# port install php55-apache2handler
# cd /opt/local/apache2/modules
# /opt/local/apache2/bin/apxs -a -e -n php5 mod_php55.so

That’s all pretty straightforward. But my httpd.conf had a few stray lines in it that needed cleaning up. I had to replace LoadModule php5_module modules/mod_php54.so
with
LoadModule php5_module modules/mod_php55.so
and change
Include conf/extra/mod_php54.conf

to

Include conf/extra/mod_php55.conf

Now I could start up Apache and see what kinds of errors I had.

# /opt/local/apache2/bin/apachectl restart

Well, this is where I finally found and fixed the dropped line that got me started on this whole sordid adventure. I also discovered I didn’t have a good php.ini file, so I copied the distribution one and customized it.

# cp /opt/local/etc/php55/php.ini-development /opt/local/etc/php55/php.ini
# vi !$
# /opt/local/apache2/bin/apachectl restart

Now my dev sites were back up, but I couldn’t run tests. The way that phpunit is structured has changed since the days when it was a Pear package. It now uses a phar package and composer. Now, at some point, I’ll restructure my Yii projects the New Right Way and have a phpunit distribution per project, but I need to get back productive, so I set it up globally for the time being.

# cd /opt/local/bin
# curl -sS https://getcomposer.org/installer | php
# mv composer.phar composer
# wget https://phar.phpunit.de/phpunit.phar
# chmod +x phpunit.phar
# mv phpunit.phar phpunit
# composer global require 'phpunit/phpunit-selenium=*'
# composer global require 'phpunit/phpunit-story=*'
# composer global require 'phpunit/dbunit=*'
# composer global require 'phpunit/php-invoker=*'

This is where I discovered the php.ini had set the default include path to a not-quite-right location. I ended up changing

include_path=".:/opt/local/lib/php5/lib/php"

to
include_path=".:/opt/local/lib/php"

and then once again restarted the environment.
# /opt/local/apache2/bin/apachectl restart

Now there were only two things wrong. The current project is based on Yii 1.1.x, and it still tries to include individual PHPUnit files.

Based on numerous forum posts and false starts, I edited framework/test/CtestCase.php, and changed those “requires” up top to:

if (!method_exists('PHPUnit_Runner_Version', 'id') ||
version_compare(PHPUnit_Runner_Version::id(), '4', '< =') ) { require_once('PHPUnit/Runner/Version.php'); require_once('PHPUnit/Autoload.php'); }

PHPUnit unit tests now run, as do Selenium tests, but they do throw an ugly warning on test failures to tell me:

Warning: include(): Failed opening 'PHPUnit_Extensions_Story_TestCase.php' for inclusion (include_path='.:/Users/samuelg/project/X/Y/protected/commands:/Users/samuelg/project/X/Y/protected/behaviors:/Users/samuelg/project/X/Y/protected/components:/Users/samuelg/project/X/Y/protected/nuclear_secrets:/Users/samuelg/project/X/Y/protected/models:/opt/local/lib/php') in /Users/samuelg/project/X/Y/framework/YiiBase.php on line 418

Nor does it give me line numbers of failures in Selenium tests if I enable screenshots. It’s also seemingly taking screen shots of the wrong pages of the site when there’s an error. I don’t yet have a solution to any of these problems.

Lastly, PHP 5.5 is more sensitive about some things than I expected. First, I had to migrate some crappy developer support code from using direct mysql commands (e.g., mysql_connect, mysql_query, etc.) as they’re deprecated. I now use PDO, and that’s all fine.

But beware PHP being stupid about what’s a variable and what’s a reference. In PHP 5.5 strict mode, it whimpers about things like

$foo = end(my_func());

even if my_func() returns an array. Now, in a sane language, I’d be able to do stuff like that, because hey! an array’s an array, even if it’s being returned by a function! I mean, not to devolve into pointless discussion of language implementations and flaws, but flaming owls of imminent death, is PHP a mess!

Anyway, this post is a mostly cleaned-up version of my little adventure. If it spares anyone else some of the same pain, it will be worth while.

No, the project doesn’t really have a nuclear secrets directory. I just felt stupid nerfing the project name in the first place.