Mac,on the topic of  Linux, PHP, Tools, Web Development
03.18.2010   |   0comment

I just spent about an hour banging my head on a brick wall with the apparently well known “Unable to create selectable TCP socket” problem, which manifests itself most notably with failing imap_open() calls from PHP. It is related to fd_setsize and a frequent limit of 1024 open files (or at least selectable open files). It is quite well documented that it is some kind of bug/shortcoming in the c-client libraries that underlie a lot of email-related stuff, particularly the UW suite of tools like uw-imap, pine, alpine, etc. as well as the IMAP extension in PHP. I love being able to go Google for answers and find a ton of related content. It is really annoying though when people have been talking about this bug for years, since at least early 2007, with very very few workable solutions posted, or even workarounds.

So, I’m going to do my part: I found a workaround that I think might work very well for a lot of people who run into this problem. It’s biggest advantage is that it is very very easy to try, and has almost no downside, even if it doesn’t work for your particular situation. In my case, I found that Apache did indeed have a lot of files open, including log files for all my VirtualHosts, all the libraries that httpd depends on, files from sites that are hosted there (though it seems to open and close those just fine), and a large buildup of hundreds of entries for /tmp that were open and apparently never got closed properly. In my case, the server in question has an uptime of over 2 years, and while “apachectl restart” runs at least daily for log rotation, it seems that doesn’t really close unused file descriptors. The workaround I discovered was running “apachectl stop” followed by “apachectl start” which fixed the problem completely for me, at least for the next year or two I hope. From over 1600 open files, after restarting Apache fully that way, it only reopened about 325 files. And the imap_open() calls started succeeding as they should.

One last thought before I hop off my soapbox: when you find an answer to a problem, and that answer was hard to find or was not well documented, do your part to remedy that for the next guy or girl to hit that problem, and post your solution somewhere that Google will find it. It makes the internet a better place for all of us, and makes us all more productive. Who knows, maybe down the road you’ll run into the same problem again yourself, and not remember how to solve it until you find your own post from years before, and it will be your own time you’ll save. I fully recognize that a lot of what I accomplish each day is based on work done by others that I have found and emulated, as they say, standing on the shoulders of giants. Each contribution to the body of human knowledge lets us reach that much higher, so when you can, add your bit and as we all do that, it adds up.


Mac,on the topic of  Food, Fun
11.30.2009   |   0comment

On Friday, November 20th, we had our annual Thanksgiving Feast with our neighbors, WhiteLabel SEO, and decided we needed to share a few recipes.  This will hopefully be the first post of several along this theme over the next month or two.

Raspberry Cheesecake

This first recipe comes from Susan Ehlers, spouse of Chad Ehlers who works here at Code Greene, who was willing to share her awesome Raspberry Cheesecake recipe with us.

  • 8 oz. cream cheese
  • 1 cup powdered sugar
  • 8-12 oz. Cool Whip / whipped topping
  • Graham cracker crust (homemade or purchased)
  • Raspberry Pie Filling (or other pie filling or pudding)

Mix cream cheese and powdered sugar together until smooth. Add Cool Whip (8 oz for a pie tin, 12 oz for 9×13 pan) over graham cracker crust. Top with Raspberry Pie Filling, or substitute another topping of your choice. Any pie filling works well, also pudding is a great alternative! Chill until ready to serve.

Ham Loaf

The name might not sound that appetizing, but I can assure you it is a family favorite and people at the party trying it for the first time said they liked it a lot and wanted the recipe. My wife, Susan Newbold, brought this from her side of the family and I’ve loved it ever since.

  • 3 lbs. ground ham (Keep it a simple – no fancy smoked ones, just plain. Bone in works fine, or boneless, but preferably one without added water.)
  • 2 lbs. ground pork (Almost any cut works great here, we usually use boneless pork chops)
  • 2 cups soft bread (you can break it up by hand, or I often use the food processor)
  • 4 eggs
  • 1/2 cup milk
  • 1/2 tsp pepper
  • The Special Sauce:
    • 1/2 cup pineapple juice
    • 1/2 cup vinegar
    • 1 tsp dry mustard
    • 2 cups brown sugar
  • 2-6 rings of sliced pineapple (optional)
  • Maraschino cherries (optional)

Mix meat, bread, eggs, milk, and pepper, and knead it by hand until it is well mixed. Form into two loaves as you would meatloaf. Mix sauce ingredients in a saucepan on medium heat until brown sugar is dissolved. Pour sauce mixture over the loaves. If desired, garnish with pineapple and cherries. Bake at 350 degrees for 75-90 minutes. Because we live in Utah, I actually bake mine at 375 degrees because of the high altitude. Check with a meat thermometer to make sure it’s cooked all the way through, probably 170 degrees internal temperature should do. (It is pretty hard to overcook, and you can baste it with the sauce if you’re worried about it drying out.)

Grinding the meat: you can do it yourself with a meat grinder (we use our Kitchenaid mixer with the grinder attachment) or you can order it from your local grocery stores. Some stores won’t do it, but others are willing and usually don’t charge anything extra. We’ve found locally that Harmons will, and Albertson’s used to, but some locations won’t do it for me any more. They usually prefer to do it first thing in the morning in their grinder, so that they can clean the grinder once instead of twice. (They have to prevent cross-contamination, so if they’ve been grinding beef, they’d have to clean the grinder before and after the pork, but if they do the pork first thing on a clean grinder, they don’t have to clean twice.) Because it involves a little extra work, some butcher counter employees get huffy and refuse to do it. You can also usually find ground pork – not out with the other meat, but at the butcher’s counter. Hope this helps!


Mac,on the topic of  Fun, Linux, News
09.16.2009   |   0comment

UTOSC 2009 Speaker

I’m getting excited for the upcoming Utah Open Source Conference 2009, Thursday October 8 through Saturday October 10. It’s hard to believe another year has gone by already. There are a ton of great speakers and events that I anxiously await. Not to make light of the conference presentations, some of my favorite parts are the social events, like the Boardgame Bash at the end of the conference. For a bunch of geeks, we seem to be a pretty fun crowd, I think. I also love that the UTOS folks take family seriously, and have family events on Saturday that are fun for the wife, kids, and other non-geek family members. There’s a healthy focus on bringing new people, and less technical people, into the Open Source fold, which I think is great.

This year, as soon as submission of abstracts opened, I tossed in a presentation for the first idea that came to mind, which happened to be about one of my favorite open source platforms, FreeBSD. Lo and behold, after the voting and committee meetings were over, I was one left standing, so now I’ll be presenting “Why FreeBSD is the Best Linux Distro*” at the conference. Of course, when I decided to run the risk of making a joke in a room full of highly technical purists, I knew I better use the asterisk and let them in on the joke: “* Yes, FreeBSD isn’t really a Linux Distro. It’s a different Operating System that has emulation for and binary compatibility with Linux and can run almost all the same programs.” Even though it isn’t really a Linux distribution, for me it serves the same purpose and I think it does a better job than the various Linux distributions I’ve experienced.

Anyway, early-bird discounts end on Saturday the 19th, and there are some 50% off coupon codes drifting around if you’re interested. There are codes you can get from speakers, any local Linux User Group (LUG), or other groups like UPHPU.


07.30.2009   |   4comment

The old adage that “an ounce of prevention is worth a pound of cure” couldn’t be more true in web development. Through recent experiences we’ve found out that it is well worth the effort to go to extremes in planning something out before you build it. Spending an extra 4 hours in planning can literally save 40 hours of development later, if not more. If you’ll indulge me, I’ll share a few stories to illustrate my point.

A project some of us have been involved with had a budget of X, and a scope of Y. It seemed simple enough that the planning was skimped, and the client wanted to get things moving quickly, so everyone just plunged in. Before you know it, there are things that we told would be done one way, and now they’re changing it and wanting it another way, and features A, B and C come out that they never mentioned to us until long after the budget was fixed. We try to make it work, and scope is now 2-3 times where it started out. Time goes on, and it turns out that the final client wanted something different than the decisions and instructions we were given, and wanted features D through H as well. Red flags have been raised several times, and some renegotiation gets 3X the budget to go along with what at the time was 6X the scope. Everyone is unhappy, because more information keeps coming out that we weren’t given, and the client got something different than what they were expecting because the expectation wasn’t made clear at the beginning, when the planning should have happened. Of course now everything is late too, and still not done the way they wanted, so features I through M make it into the mix, along with major changes to 8 of the existing new features. 8 times the original scope and counting, for 3X the original budget, and nobody is very happy.

What did we learn from that? We need to be much more strict about the planning, no matter how much they beg us to just get started, hoping that getting started sooner instead of planning more will get them to the desired destination faster. That’s like getting on the freeway and driving, so that you arrive faster at your destination, before you bother to figure out which direction the destination lies, and what paths might make sense for getting there on the timeline and budget you’re hoping for.

We often share with people a metaphor about their website is a building, and the plans are the blueprints. It’s relatively easy for an architect to move a wall on a blueprint, because he can just change the plan. But once the blueprint is in the hands of the construction company, and they’ve built the building part way, or all the way, it’s harder to move the wall. A client often thinks “I only need to move the wall 6 inches” but unfortunately that doesn’t change the fact that it is a wall, and would probably need to be torn down and rebuilt in the new location. Granted, not every change is moving a wall. Sometimes they want a window over here, or a door there. Sometimes they want to switch around the plumbing or the electrical. Some changes aren’t as major as others, but they all make some kind of difference when you have to redo or undo something. If they have us paint the room red, which we do, and then decide they want it blue, it will probably cost about double at that point to repaint. If they change their mind before the room has been painted, it isn’t a big deal, unless we already bought the red paint for them. The timing of the decision makes all the difference in what costs are sunk and what work has to be done, undone, or redone to make the changes they want.

The big lesson for me has been that it isn’t unreasonable to spend 4 hours planning a project estimated to take 40 hours, or 10 hours on a project that will probably take 100 hours. It is time well spent, because in the end you get done faster, you can be confident that you understood what they wanted, and it is much more likely that it will be done right. When you can get it done right, on time, and on budget, you’ll have happy clients.


Mac,on the topic of  Business, PHP, Web Development
05.15.2009   |   1comment

This morning Mark and I attended a great talk by Eric Smith, CTO and Co-founder of Control4, at the UTC CTO P2P Forum, titled “Outsourcing: What not to do.”  The short version of the story is that a few years ago Control4 decided they should try outsourcing. They spent about $700,000 setting up a nice 50-man shop in Bangalore, with a good Indian HR manager and a guy from here that moved over there as a technical manager for the shop. In about a year and a half, they spent about $3,000,000 on the facility, and ran into a bunch of problems. They couldn’t hire and keep the top notch developers because they weren’t a big name company, and they had a lot of churn and turnover due to the 20-25% annual growth in average salaries. They had a hard time being clear enough and specific enough in their specs and task lists to get it built right the first time. The 12.5 hour time difference made things very hard for communication. On some projects, they had to go back and forth 17 times with changes, bugs, clarifications, etc. before it was done right.

When he talked about the results they got from this $3M, 1.5 year investment, he said that only about 30% of what the team produced was able to be salvaged and used. The other 70% had to be rebuilt from scratch. One of the most telling things he said was that by the time they got all the kinks worked out and the team there was working at full speed, the production they saw from the Bangalore office was about what they would have had if they had kept their technical manager here in the States and hired one more guy like him. Two top notch guys (for argument sake, say you’re paying them each $150K per year, a total of $300K/year plus their office space and any other administrative overhead) would have yielded the same output as a 50 person team costing $2M per year. He didn’t say, but if that doesn’t already factor in the “30% usable output” then the difference is even more drastic. Don’t forget that another cost besides the money is the time it takes to get to the right solution. If 1.5 years is what it would take to do it right, then 1.5 years to get it 30% right means you still have a lot of work to do and a lot more time (1-5 years) to really get it done, which in a competitive market can leave you in the dust.

One really sad thing is that this story is hardly unique. Many people we’ve talked to who have tried outsourcing projects (to India, Russia, or anywhere) have run into similar problems and worse. Most of the outsourced web development projects we hear about didn’t get in that deep of course, but the principle is the same.

So what is the moral of the outsourcing story? It really is the same lesson many others have learned: Cost, or hourly rate, isn’t the only thing that matters. Sure your outsourced developers are cheap, but what do you get for it? What’s the quality and quantity of their output?

Mark tells a great story about a guy who has a brain tumor. continue reading Outsourcing, Brain Surgery, and The 9’s”


Mac,on the topic of  PHP, Tools
03.25.2009   |   1comment

In a long-awaited promotion from the “public beta” status it has enjoyed for the last 18 months, the new Gradefix.com is finally live. Many hands have played a role in getting this to where it stands today, not the least of which is Luke Larsen, who did the design built the HTML/CSS for the new site. But the face isn’t all that’s new – the back end has been overhauled with new and improved algorithms and features that our users have been asking for. Some of them were so anxious that they switched all their Gradefix use to the beta server to start enjoying the new features now. (There’s also another good reason to revisit the site: there are actually 6 different design themes that you’ll see as you visit the site. The cookie that sticks you to a single theme for your visit is valid for an hour, so either wait and come back, or delete the cookie to see the other themes.)

Screenshot of the Blue theme of the new and improved Gradefix.com

Screenshot of the Blue theme of the new and improved Gradefix.com

Gradefix is one example of a project that we at Code Greene conceived, planned, designed, and built for ourselves. After building enough sites for other people that make them a bundle of money, you eventually decide to make one yourself, and that’s part of how Gradefix came about. Our CEO, Mark Polson, had the dream of what Gradefix could be back in about 2003 or 2004, and we partnered up and started building it in 2005. It launched to the public in 2006, after 2 full rounds of reworking and rebuilding, and has had a few major updates to the internals in the first few years. This is not only a major improvement to the algorithm in response to user feedback, but also a dramatically improved look and feel based on the response our target audience has had to the site. It was hard at first to get used to the idea of letting go of the old look, but I’ve grown attached to the new one now, and I think it is a lot more trendy and up-to-date and will succeed a lot better with our user base, which is primarily college and high school students.

We’re always looking for feedback on Gradefix, so let us know what you think or how you think we could improve it. Feel free to blog your own reviews, or if you’re interested in an interview etc. for your own blog, let us know and we’d be happy to talk to you about it.