Both of these problems are related to shared libraries that PHP relies on:

libresolv

Running make resulted in the following error:

Undefined symbols:
  "_res_9_dn_expand", referenced from:
      _zif_dns_get_mx in dns.o
  "_res_9_search", referenced from:
      _zif_dns_get_mx in dns.o
      _zif_dns_check_record in dns.o
  "_res_9_dn_skipname", referenced from:
      _zif_dns_get_mx in dns.o
      _zif_dns_get_mx in dns.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [libs/libphp5.bundle] Error 1

Thanks to a great StackOverflow thread I was able to get around this fairly easily by editing 2 lines in the Makefile after running the configure script:

EXTRA_LIBS = -lresolv [... all of the other flags that are already here]
EXTRA_LDFLAGS = -lresolv [... all of the other flags that are already here]

libiconv

An error was also thrown in reference to libiconv. Apparently there is something strange with Apple’s included libiconv libraries. I was pretty easily able to get around this by compiling a local copy of libiconv from the source at gnu.org:

# download source, extract, enter directory
./configure --prefix=/usr/local
make
sudo make install

Then, just add –with-iconv=/usr/local to your configure options so PHP will link to your copy instead of the Leopard one.

Final configure command:

./configure --prefix=/usr/local/php52 --with-apxs2=/usr/local/apache2/bin/apxs\
 --enable-shared=all --with-zlib --with-curl --with-freetype-dir=/usr/local\
 --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/local --with-gd\
 --with-mcrypt --with-mysql=/usr/local/mysql\
 --with-mysqli=/usr/local/mysql/bin/mysql_config\
 --with-pdo-mysql=/usr/local/mysql/bin/mysql_config --with-iconv=/usr/local

Note: I did find that these issues have been resolved in the PHP 5.3.1 branch and will most likely be backported to 5.2 at some point, so make sure to check future versions before taking this route.

Hopefully this helps someone else out until these issues are resolved by either the PHP team or Apple. Do let me know if I have missed something stupid here or if there is an easier way to resolve these issues.

However, thanks to Stack Overflow, I was able to find a very elegant solution for this situation when you are working from a Mac client: pbcopy (and the yen to it’s yang, pbpaste). These 2 little programs allow you to pipe text to and from your clipboard into your terminal. For example, pretend I have a configuration file that I need to copy into a blog post or wiki:

$ cat localhost.conf | pbcopy

Now I can just use a standard paste command to insert the contents of the file into any input field. No need to open the file in an editor: easy. The inverse is also possible. Pretend you have copied a code snippet from an online tutorial to your clipboard and you need to create a file with the copied text as the content.

$ pbpaste > somefile.txt

I am sure that there are some other cool uses for these commands, so put your ideas into the comments!

To begin with, I have finally moved this blog to a permanent home at andrewbredow.com instead of a subdomain to a site that I have no intention of developing any time soon. Any old links to site will be redirected here with 301 (permanent) redirect for the time being, and I will probably get rid of the subdomain altogether in a couple of months.

Additionally, I have made the switch over to Feedburner (which is now owned by Google) for my RSS feed. This will provide me with some better metrics and additional exposure and it also allows the possibility of switching out blogging software while keeping the same feed address. If you are subscribed to the old feed it will continue to work as long as the redirect is in place. However, it would be great if you re-subscribed using the Feedburner feed!

That’s all for now; there are more exciting things coming soon!

When I first developing web applications I was only responsible for one site. My typical workflow was to have a checkout of the application in my document root and to just use http://localhost to debug it before I checked in my changes. As I started working on other projects, I would just go into my Apache configuration and change my document root to another directory. This got rather annoying after a while since I had to edit files and restart Apache every time I switched gears.

Then the light bulb clicked on: I knew how to configure virtual hosts to run multiple sites on web servers, why didn’t I just do the same thing on my local machine? Once this is accomplished, it becomes very painless to switch contexts between multiple applications. As an added bonus it also makes it very easy to install open source web applications on your local machine, do some hacking, and learn how they work. While this same thing is technically possible just by adding new folders to your document root, this can really confuse some web applications that are expecting to handle all of their URLs as directly relative to your base path.

Prerequisites

The only prerequisite to this tutorial is that you have a relatively clean install of Apache on your local machine. You can use the default OS X install, or also also a vanilla copy installed via the Windows Apache installer. I am going to give instructions for a *NIX OS, but this setup also works fine in Windows.

Set up

1. First, you will want to locate your Apache configuration directory (containing http.conf). On OS X or most other flavors of UNIX it is /etc/apache2/, or Windows: C:/apache2/conf. Next, open your terminal and cd into the directory:

   $ cd /usr/local/apache2/conf

2. Add a “sites” subdirectory to your Apache configuration directory. This is the directory that will hold all of your virtual host configuration files.

   $ mkdir sites

3. Locate your httpd.conf file, open it up for editing

   $ nano httpd.conf

4. Now, we want to edit a couple of configuration settings. You may find variations of these already in the file that you can either delete or modify.

   NameVirtualHost *:80
   Include conf/sites

   The first line tells Apache to use name-based virtual hosts. This means that it will match virtual hosts based on the domain name of the request. The second line causes all files in the sites directory to be included when Apache reads in it’s configuration files. Note that this folder location is relative to your ServerRoot location which you will find elsewhere in httpd.conf if you search for it.

5. Next, you are going to go into your “sites” folder and create your first virtual host configuration file. It is helpful to name the files based on the domain that they reference (I am going to create http://local.andrew).

   $ cd sites
   $ nano local.andrew.conf

   The basic file contents are

   <VirtualHost *:80>
     ServerName local.andrew
     DocumentRoot /Users/andrew/Sites/somecoolsite
    
     <Directory /Users/andrew/Sites/somecoolsite>
       Options +FollowSymLinks
       AllowOverride All
     </Directory>
   </VirtualHost>

   This is fairly self explanatory. In the first line you set the domain that you want to use with the ServerName directive. The document root of your files (they can be anywhere on your computer) goes after the DocumentRoot directive. Finally, the Directory block is where you can put any settings that are specific to this host (e.g. Rewrite rules).

6. Next, you will need to create an entry in your host file to direct all traffic sent to your custom domain to your local machine. On any *NIX system the file is /etc/hosts, and on Windows it is C:\WINDOWS\system32\drivers\etc\hosts. The format is the same on all systems, just add a line like:

   127.0.0.1  local.andrew

7. You are all done setting up your first virtual host. Restart Apache (you will probably need to use a hard restart - apachectl restart - for your vhost settings to be applied), and direct your browser to whatever hostname you created. You should see your site right away!

Now that you have 1 host set up it is super easy to add more. Just copy your existing host file to a new name and edit the settings accordingly! This should greatly improve your workflow and help you be a more productive ninja developer.

My day job at Live Oak is has been great lately. I am continually reminded of how blessed I am to have a great job where I am surrounded by such smart people! On the project front, I have spent the last few months planning and beginning development on a large social networking application. I am not sure how much I can actually talk it about on here, but I hope to fill you all in as soon as possible. However, I will say that this is a unique project for me not only because it is technologically awesome and challenging, but also because I am excited about the impact that it will make when it launches. For me, this is the height of career satisfaction: being able to use my abilities and intellect for a cause that I believe in.

Outside of work, I am continuing to work on SailboatConnection.com, a project that has been in the works since last summer. While it got off to a bit of a slow start, the pace has really picked up over the last couple of months, and we are nearing the first milestone that will accessed by select public users. This project has been really fun mostly because it is the first project that I started using Zend Framework (including the MVC stack) from the beginning. I will share more details about this project as soon as it is available to the public.

On the personal front, things at home have been good. Carrie is nearing the end of her last semester with classes! I am really looking forward to spending more time with her this summer, even though she has to start work on her comps for her dissertation (boo). We don’t have tangible plans yet, but I am guessing that we will make it up to Michigan to see family and friends at some point, in addition to branching out and seeing more of Texas than just Austin and the hill country (please leave any suggestions on the comments!)

However, there were some complications as well. New users have been registering and entering all kinds of valuable information for the last 7 months, and much of this data needed to be moved around to new tables and models. This presented some interesting challenges during development because the changes had to all be implemented in a one time application upgrade, eliminating the possibility of gradually moving the information into the new data model.

Thankfully, the upgrade went very smoothly, so I thought I would take a bit and summarize some of the principles that I utilized to make this happen. This should generalize pretty well to any web application that is heavily data-centric and needs to undergo significant model/schema changes with minimal downtime.

• Automate as much as possible - For small changes to an application, it is acceptable to just keep a running list of steps you have completed in your development environment and then perform these in your live environment when you roll out your changes. However, this is hugely prone to human error, and cannot be tested with great reliability. Maintain a sql file with all of your schema changes, and begin generating a script to perform all data migration operations as early as possible in your development cycle. Ideally, these will encompass all of your data migration (with the possible exception of filesystem changes). You will be most in-tune with the changes that need to happen at the time of implementation - not right before you are ready to go live!
• Use your data models in your migration script - When I originally started working on my migration script for this project I thought I would write an old-school procedural “quick and dirty” script to just shuffle the data around. But as I thought about it, I realized that I was ignoring the dependencies that existed within the database. For example, whenever a new user is created, it is not as simple as just inserting a row in the users table. I needed to create a user group, the associated group memberships, assign permissions, etc… Of course, all of this already happens inside of the data models in the application. So instead of going in the back door, have your migration script utilize your application’s data models so you can rely on code that you have already verified (hopefully!) to follow your business rules.
• Simulate your migration, and then do it again! - Creating a comprehensive migration script during the development phase of your application affords you the awesome opportunity to be able to do some simulations before you actually run your script in the live environment. This is pretty simple. Do a dump of the database from your live environment and import it into your testing database (if your database is too large for this, just choose a representative sample). Now you can run your migration script until you feel comfortable that you are covering all of the different scenarios that exist in your live database. Once you have fixed an issue in the script, just re-import the data from your database dump and try again. I had tested my migration script like crazy before I started simulations, and I still found quite a few issues that only turned up when I encountered the live data that had been entered by real users and not programmers. Once you have run the simulation several times with success, you are ready to think about deploying your application.
• Stage your application in the live environment - I know that it is not possible for everybody to do this. However, I have encountered several ugly MySQL bugs that affected either my development server or my live server (but rarely both). It is not possible to anticipate environment variables such as these - so if it is at all possible, get your application running on a new virtual host in your live environment as soon as possible. This is the perfect place for your co-workers, testers, or even your clients to interact with the application. After a while, you can be sure that you will not encounter issues with your live environment when you go live with your changes, allowing you to focus on more important things.

That should give you a good start on lowering the stress associated with large application changes in a production environment. Of course, I still ran into a couple of issues with the migration process - so don’t get down on yourself. The bottom line is that migrations are really ugly and almost always come accompanied with unexpected issues. The first goal of developers should be to minimize the chances that the affects of the resulting bugs will significantly affect the end user. Automation is a significant step in that direction.

So what have you learned about upgrades and migrations? Please share any stories and lessons that you have learned in the comments.

As I think about it today though, I am feeling  better about these details. It is not that I have figured everything out in some kind of master plan. Rather, I have begun to think about this project from the other side of the screen: the end user. Like a novel, every line of code that we developers write translates into a unique experience for the end user. Applications, like philosophy or a work of poetry, can either take the end user to a place that is more clear and understandable or can lead to frustration or disconnect. The important thing to remember though is that no technology in and of itself necessarily creates this dynamic experience for it’s users.

Think of your favorite application - what does it convey to you? Gmail is one of my favorites. Gmail tells me that I can make sense of a barrage of information through filtering and tagging and stringing together threads of communication. Moreover, it is an inspiration in the sense that it is as fast and efficient as a desktop application because of the awesome architecture under the hood. I have been using Gmail since very early in it’s life in 2005, and have seen many different technical iterations that were inspired not just by new cutting-edge browser technology, but rather by painstaking attention to what would create the best user experience. That is to say, the client experience necessitated the cutting edge technology and not vice versa.

I think it is easy to forget this as a developer. We spend so much time working on the nitty-gritty details that make things work - which is essential, but often uninspiring. We want to see cutting edge techniques and elegance under the hood. But when this becomes frustrating to do, it is easy to become disillusioned with the whole process. In short, we often put the cart in front of the horse. I think this is less of a danger when the technology that we are utilizing has been carefully chosen to create a particular user experience. It is no longer an issue of technology as an end in and of itself, but rather as a means to something greater.

So I am going to try this week to remember the human side of the software that we are envisioning and architecting. The important thing to think about at this stage of the game is not the inevitably complex architecture of what we are about to do. Rather, we need to develop a clear understanding of the experience that we will be creating for the end user. Once we have paid adequate ettention to these big elements, the rest will be easier to conceptualize and architect.

I have been meaning to post about this for a while, and since I have talked to a few interested people lately, I think now is a good time. One of the biggest downsides to getting an Xbox over some other modern systems is that it does not come with built-in wireless. This is fine, since I think most people have their router next to their television or, at the very least, are able to drop in an ethernet port. But, as you can imagine from the title of this post, I do not fall into either of these groups. I did a little research, and found good news: there is a wireless card for the Xbox. WIN! And then, I realized that the price tag on this little encapsulation of 1999 technology was $80! ULTRA FAIL!

Now I am not a notoriously cheap person, but I do have a small problem with this ridiculous price tag for what is undoubtably a cheap chip beneath the surface. So I set out to find a alternative; but not just any alternative, I wanted the cheapest alternative possible.

The obvious option is a wireless bridge. These tiny devices connect to your wireless router as a client and then bridge the connection to an ethernet port into which you can plug any device. And the good news is that these things only cost about $50. Getting warmer, but not quite there yet. After a little searching, I found yet another device. The Linksys WMB54G “music bridge.” This thing is great. It is cheap (about $30 from the Amazon vendor that I got it from), and it can function as a wireless bridge. However, when I got it I realized that setup is a little difficult, particularly if you aren’t interested in running their P.O.S. setup program that will only run on windows.

Instructions

All you’ll need to get this running is any computer and the contents of from the box. Don’t be afraid to try anything, if you end up screwing up your device so you cannot communicate with it, just hit the reset button and start over.

1. First, unbox everything and plug in the WMB54G. Plug the ethernet cable into the adapter and directly into the ethernet port on your computer.
2. While it boots (it is slower than hell), open up the wireless settings on your computer and change your ethernet connection settings to “Static” and assign the following IP addresses:
   IP Address: 192.168.1.120
Subnet mask: 255.255.255.0
Router (”gateway” on Windows): 192.168.1.100
   You don’t need to worry about any DNS settings since we aren’t going to need an external connection during setup.
3. Open your favorite browser and navigate to 192.168.1.210. This will bring up the web configuration utility for the bridge.
4. Don’t do anything with the LAN settings at this point. Use the “search” button to find your wireless network information, and enter your wireless key. I had trouble getting it to work with WEP for some reason (shoot be an email if it works for you and I will update this post). Once I changed my network over to WPA it worked great. Also, don’t get confused if you see “PSK” for security type - they mean WPA.
5. Once your wireless information is all entered correctly, click “Apply” at the bottom. Go get yourself a cold one while it reboots - you are almost done.
6. Next, you are going to want to set a cusom password for the admin utility. Do this in the “Password” tab (pat on the back if you guessed that), and then click “Apply” to save. You will need to re-authenticate once the device reboots if you change the password.
7. Once it has rebooted, you can enter your LAN information. For 99% of you, leave it as “Automatic Configuration - DHCP.” If you have a manually configured network enter your settings. Click “Apply,” and wait again while it reboots.
8. Once it is rebooted, you will just want to test that everything is working. Change your ethernet settings on your computer back to their original settings (and disable your wireless adapter if you have one) and test that the connection works. You should be able to access the internet just like usual. If your computer cannot connect, neither will your Xbox be able to connect. Note: you may need to refresh or “repair” your network connection on your computer so it can get a new IP address.

One last note: if your router supports Static DHCP, I would recommend making an entry for the MAC address of the WMB54G so you can easily access the admin in the future (it is printed on the bottom). If your router does not support this, you will need to log in to the router and try to figure out what address has been assigned to the WMB54G if you ever want to edit the settings again.

Hope that this helps some people! Let me know if there is anything on here that I can clarify!

Coming from a nontraditional background, I never learned programming in any kind of academic environment. I picked it up while working customer service at a small software company, and played around for months before I tried writing some demo apps and then later started working on some of the internal applications that were used by only a few people. I found programming syntax to come pretty easily since it is just applied logic. However, it was the application architecture that started to get the best of me when I realized that I was running into common problems that had to have simpler solutions than the ones from which I was approaching them.

At this point there were several key people who I turned to when I got really stuck, but one in particular really took the time to actually mentor me and began to patiently sharpen my programming mind by teaching me about design patterns (or more importantly, how to use them to solve real life problems), showing me examples of code that he had written, and describing lessons that he had learned. I am not sure that I understood how important this was at the time, but looking back it is clear to say that I would not be where I am today were it not for his involvement at this pivotal point in my life.

This brings me to my reflection in my journal from this morning (and maybe a little call to action). I am no expert and most certainly have a long way to go still. However, I have learned a few lessons and am beginning to wonder if I may may be able to also play an important part in an upcoming programmers life. The most important thing about mentoring is not knowing every little detail, but rather, encouraging someone to stick with it and to either develop their love for it, or to realize that there is something better on the horizon. As such, I think there are a few key characteristics of successful mentoring in the world of software:

• Take risks - there is no reason to protect a new programmer from your code (that is what version control is for), assign real tasks that will stretch his or her abilities. It is this kind of real world trust that builds confidence.
• Don’t give too much preemptive advice - Allow him or her to take a stab at a problem and then help when asked.
• Frequent code reviews - Once the code is working, walk through it and spend time identifying patterns, pointing out optimizations, and talking about alternative approaches. This helps to frame all of the explanations in relation to problems that have been recently addressed by the programmer
• Warn against pre-optimization - Teach that the first priority is to get something that works, second to that you figure out if there are any bottlenecks that need to be optimized. This one took me a long time to learn, as it was made apparent to me that I spent way too much time analyzing problems because I was so worried that I would slow down the application. I became much more efficient when I learned this simple lesson.

I am sure that this list is not complete - so please add on in the comments if you have any other suggestions. In the meantime - get out there and see who you can encourage someone in their quest to become a good programmer!

http://www.theprintedblog.com/

At first, I thought this is the dumbest idea I have heard in a while. I mean, isn’t the best part of the web that we have access to realtime information free from the constraints of the print publication workflow? Isn’t it great that we don’t have to pay for paper that is simply thrown away? Isn’t the most revolutionary thing about the web as a news source that we have access to perspectives from around the world and we can choose the angle that we are reading on events (c.f. Drudge vs Huffington) or editorial (c.f. Daily Dish vs. Kos)?

The answer to all of these things is “yes.” And this is truly the thing that print media mostly misses. The Printed Blog definitely offers an interesting compromise between traditional print and electronic media. I think that people like me any many of my peers would never pay for a print publication like this, but there may be a portion of newspaper readers who would be turned on to the blogosphere and internet news for the first time if they could consume the content in the same way that they always have: in print. Furthermore, because the content of the paper is voted on according to region, the perspectives represented will more closely mirror that of the locals, as oppose to that of the editors of the paper.

The trickiest obstacle I see for The Printed Blog is getting the paper into the hands of people who don’t already read blogs. But if they are able to accomplish this feat, it could mean bringing a whole new audience to the blogosphere, further broadening the perspectives that are shared online. Thoughts?