Fancy Bread

Today, I was able to get https working for localhost connections after following these step by step instructions for creating and signing a cert and updating httpd.conf and httpd-ssl.conf on Mac OS X Hints. Problem is, I need https for vhosts. When trying to connect to a local vhost over https, I encountered the following error: Error code: ssl_error_rx_record_too_long). Much more googling turned up the answer. You need to turn the SSLEngine On for vhosts. Thanks to the Ubuntu forums for that gem. Here's an example vhost that uses SSL.

<VirtualHost 127.0.0.1:443>
DocumentRoot "/Users/paul/Sites/myproject"
ServerName myproject.fancybread.local
SSLEngine On
SSLCertificateFile "/Users/paul/certs/localhost/newcert.pem"
SSLCertificateKeyFile "/Users/paul/certs/localhost/localhost.nopass.key"

DirectoryIndex index.cfm
<Directory "/Users/paul/Sites/myproject">
Options +Indexes FollowSymLinks +ExecCGI
AllowOverride AuthConfig FileInfo
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

In a previous post on the topic of using the MXUnit eclipse plugin with virtual hosts, I described how I setup my eclipse project and Apache virtual host for testing. Although that setup worked, I would get periodic errors that necessitated disabling and re-enabling the MXUnit plugin. Until recently, I was still running eclipse 3.2, so when I got the opportunity to configure a new machine from the ground up, I decided to go with a fresh install of the latest eclipse (3.4) and essential plugins, CFEclipse (1.3.1.6), Subclipse (1.4.5) and MXUnit (1.0.7).

Read more...

As I delve deeper into Test Driven Development (TDD), I have refined my development setup in order to feel confident that my tests are relevant and that they provide immediate feedback about the status of my working code. The two most important goals that I have tried to accomplish with my revisions are to follow the credo of never committing broken code and to isolate and reset the database to ensure the integrity of test data. The following examples are not solely related to TDD, but represent an accumulation of development "best practices" gathered from many sources. I'm going to admit straight up that I am not a TDD purist. I almost always write model components before tests. But I always test before running code on the client side. One of the biggest selling points about unit testing and for me is that I can debug faster should a problem arise and I can do it repeatedly and confidently. Working this way makes me feel somewhat pragmatic. I'm willing to spend a known amount of time setting up and running tests so that I can avoid spending an unknown amount of time debugging. First up, my application directory structure and Apache virtual host settings.

Read more...

If you are into Unit Testing and haven't yet heard of MXUnit, I definitely recommend giving it a whirl. Some things that stand out for me, thus far in my evaluation, are the simple, but extensible, assertions, the ecplise plugin, and the debug output. One gotcha that has come up for people when using the eclipse plugin, is that is was designed assuming that the package path to your components resolves directly from your web root. For people who run separate server instances, virtual machines, or develop locally with Apache virtual hosts, this is a show stopper. Luckily, for folks, like myself, who prefer to develop locally with Apache, getting the MXUnit eclipse plugin to work is simply a matter of adding a couple of Alias directives to your vhost.

Read more...

So, if you find yourself using flash forms and you wonder why the form won't display when you know you have Flash installed, check out this Adobe TechNote. Sure, I could have avoided the headache by learning Flex. I'll reform, sooner or later. And while I'm putting a nail in the wall about that, I'll put one in for switching to Apache as well...