Zend Certified Engineer (ZCE), Zend Certification

June 16th, 2010 by Richard Morgan, a web developer in Dallas, TX.

I became a Zend Certified Engineer in January 2009. At the time, I was more excited that there were under 50 PHP 5 Zend Certified Engineers in Texas than I was to actually be one of them! But I believe the Zend Certification is an important credential — especially as a PHP developer. Being a ZCE doesn’t mean you’re a good programmer, but because the barrier to entry is so low for PHP, it establishes that you at least know the language well. I’ve met people who’ve claimed to be PHP programmers simply because they installed and customized a PHP script. Being a Zend Certified Engineer doesn’t mean you’re great programmer, but at least it shows that you know PHP.

The biggest problem with the Zend Certification is its limited scope. It really only tests one thing — whether you know PHP. It will definitely test that you understand the difference between all the different sort methods and that you more or less know the order of parameters for all the important PHP functions (and several that you may not have thought were important), but when you think “Zend Certified Engineer”, you think of someone who understands what is required to build an enterprise-level PHP application that’s secure and scales well without any major maintenance issues. The biggest shortcoming with the exam is that it simply fails to test those things.

The good news is most recruiters don’t know that! Or if they do, they don’t care! (Maybe I’ve just had bad luck, but I’m impressed when I meet a recruiter who knows the difference between Java and JavaScript.) Being a ZCE has one major advantage that I’ve seen: if there are a couple dozen resumes sitting in a pile, the handful that say clearly Zend Certified Engineer will likely be moved to the top. Those candidates are simply the most likely to be qualified. Now the key is if it says Zend Certified Engineer, there’d better be some good work experience, or chances are it’s going to be a disappointment!

Here’s my actual listing in Zend Yellowpages: Richard Morgan

Refugees in Vickery Meadow, Dallas; Bhutanese Refugees in Dallas, Burmese Refugees Lewisville

June 16th, 2010 by Richard Morgan, a web developer in Dallas, TX.

In April, I met with the International Rescue Committee (IRC) about the tens of thousands of refugees living in Dallas. Here is what I learned:

Each year, the President sets a cap on the number of refugees that the US will shelter. In 2010, the US will accept up to 80,000 refugees, though for some reason, we usually don’t usually process anywhere close to the full number allowed. There is a cap of 2,500 refugees from Europe and Central Asia combined. 710 refugees came to Dallas via the IRC last year — 450 from Burma, 120 from Bhutan, 80 from Iraq, and the rest from other various countries. The Iraqi refugees are by far the most educated, but there are a lot of Bhutanese refugees, specifically in Vickery Meadow, who have little education.

Most of the refugees who come to Dallas live in Vickery Meadow (which is several square miles, northeast of Central Expressway and Northwest Highway), although there is a strong group of Burmese refugees in Lewisville. Vickery Meadow makes sense for a number of reasons: there are already lots of refugees nearby, rent is cheap, it’s within walking distance of the Dallas IRC headquarters, and people can have easy access to DART. I was told that there are “10’s of thousands” of refugees in Dallas, most of them living in Vickery Meadow, and the number is going to grow quite a bit over the next several years.

Refugees assisted by the IRC are provided with financial assistance for 120 days, and the goal is to get them familiar with their surroundings, working, and able to more or less provide for themselves within that time frame. Most of the refugees get food stamps and Medicaid within a few weeks of arriving. The food stamps can be renewed after the initial 4 months, depending on employment.

One of the IRC’s goals is to try to pair each family up with a mentor. It’s a 6-month mentorship program that just involves a volunteer spending about 2 hours a week, on average, with a refugee family, helping them practice their English, helping answer their questions and show them around, helping explain western culture, helping with job applications, etc. However, with around 60 volunteers and 710 refugees last year alone, they are quite understaffed. There are many other agencies and nonprofits working in the same neighborhoods but with their own refugees — it didn’t seem like they worked together much, but it may be that I just didn’t get to see that level of the operation.

To learn more or get involved, head to the Dallas IRC website. They will be happy to answer any questions.

Content Generation and Search Engine Optimization

May 17th, 2010 by Richard Morgan, a web developer in Dallas, TX.

[rough draft]

I’ve been thinking about content generation lately. Search engines are in the business of finding and organizing information and then presenting the most relevant information they can find to those who are looking for it. Usually when I have anything interesting to say, I put it somewhere like Facebook or Twitter. It’s effective in that it more or less gets the people who follow me, but it does nothing to bring more visitors to my site.

It must be nearly impossible for a small, 5-page site to rank well for any competitive keyword. I’m not suggesting a simple site can’t get a top ranking — I’ve built half a dozen of those sites, and they’re all sitting very nicely in their market, but there is a big difference between holding the top ranking for House Cleaning Rockwall or Rockwall Web Design — neither of which have more than a dozen serious competitors — and getting a top ranking for something like Dallas Web Design which has thousands of competitors.

One of the phrases that has always interested me most is “search engine optimization”, because whoever can rank best for that phrase really is the best at search engine optimization. And the most obvious thing I continue to notice about that phrase is the top results all come from sites that have tons and tons of content and tons and tons of people linking to that content. That is what makes it the best result to show.

And so returning to the topic of content generation, the key to increasing organic traffic and getting a site to rank well is generating lots of content — content that can be indexed and organized, and content which is useful enough to cause others to link to and discuss it.

One of my goals for this site is to have a top ranking both for my name (Richard Morgan) and for the phrase web developer in the context of Dallas, Texas (where I live). Apparently Richard Morgan is a relatively popular name, because last I checked, there were nearly 4.5 million search results for it. Not just that, but there are a number of Richard Morgan’s who have either written books or run for political office, which means tons of sites are already linking to theirs. That sets me behind slightly, but I’m really not too concerned about it. When it comes to my name, it’s really just a matter of time and a little content before I outrank them. Simply having the domain name www.RichardMorgan.com will cause my site to rank a lot higher than many of the others. But my url doesn’t help me when it comes to ranking for Web Developer in Dallas.

There are two key aspects to ranking well. One is to increase the overall reputation of the site, and the other is to increase the relevance and reputation of a page. Ignoring page-specific optimization for now, since there’s really only so much that can be done, increasing the reputation of my site as a whole will pay off for each of the pages I decide to optimize individually.

Ultimately (down the road), the content I write on this site is a marketing tool. The more different phrases and topics my site ranks for, the more ways people can find my site, and the more people who find my site, the higher the chance they hear about and potentially use my services. What this means is that even just writing what little I know about refugees living in Vickery Meadow is a marketing campaign. There’s not a lot of reason to suspect that people trying to learn about the refugee situation here in Dallas are looking for a web developer, but who knows — they could be!

That’s the beauty of it. Simply by writing about all the different things that interest me, I’m creating content and building up more and more content that can be indexed. By writing about my interests, eventually groupings will begin to emerge. For example, if I write occasionally about going to happy hour in uptown, I may start to rank for specific happy hour queries, even if the bulk of my site is about business or web development.

As a result, writing about absolutely anything which interests me is an investment. And the beauty of writing about interests is that with time, hopefully they will develop, and I will begin to have more meaningful, insightful posts. The more meaningful the content, the more likely it becomes that it will further stimulate discussion regarding what I’ve written, again causing people to link to it. So simply by writing, I write better, and by writing better, I create leads and increase my site’s reputation.

As a web developer in Dallas, competing against my peers (and against multi-million dollar businesses) for a really tough keyword, I don’t know of a cheaper, easier way to begin to establish my site’s reputation in such a competitive market.

Conclusion

Ultimately, what I’m considering is that I’m doing myself a disservice to simply post random stuff on Facebook or Twitter. If I truly value my own site and want to begin to develop it and establish a reputation in Google, I need content that can be indexed–content that not only can be indexed but that can generate discussion and lead to others discussing my content. Ultimately, I need to be writing about the things I care about on my own site so that as I gain deeper understanding into all these random things, they will begin to feed visitors into my site and ultimately my interests will fuel my sales.

Disclaimer

Odds are I will be posting a lot of rough drafts. There is actually good reason for it, at least at this point. If I wait to write and rewrite and perfect each topic before posting it, it will take days or weeks for me to get around to completing a single post. I’m too much of a perfectionist to ever be satisfied with less. By simply posting what I have, I’ll solve the content generation problem quickly, and as I develop my points, I’ll begin to refine my writing.

Troubleshooting Errors: How many bytes?

April 18th, 2010 by Richard Morgan, a web developer in Dallas, TX.

Since tracking down a really annoying IE 8 issue last week, I’ve become increasingly observant of the number of bytes involved in the code I’m troubleshooting. For quite some time now (several months), I’ve been getting a number of 404 errors which appeared to be scrambled strings, often containing html. The only thing they had in common was that Trident/4.0 appeared in the User-Agent. (Trident/4.0 is what identifies IE 8, even if the User-Agent says IE 7 — which is IE 8 running in compatibility mode.) As it turned out, IE 8’s Lookahead Downloader has a quirk that affects url’s that span any 4096th byte. The resulting url generated is a concatenation of the string immediately preceding the cutoff and the string immediately following it. It appears to treat any single or double quotation marks as delimiters. Fun issue. Not really — if you use XHTML, there’s no practical way to avoid getting these 404 errors from IE 8 users.

Several days later, I was troubleshooting an issue that also made little sense. There were two errors — one was an unclosed comment, and the other was an unexpected end of file. I went to the line in question and saw nothing abnormal that would be causing the issue. The page that errored is one that gets automatically re-generated, and the only possible scenario I could imagine was that the page must have been included as it was being written, and so the error took place because it had only been partially written when included. Made sense — seemed possible — but it was at most a theory. However, on a hunch, I checked the filesize of the page and noticed it was 69 KB, which made me excited. Sure enough, the error occured towards the bottom of the page. I copied the source code after the line the error occured and measured the number of bytes — it was right around 5 KB. At first, the most I had was a theory — a possible scenario, but with little support other than that I had no other explanation. Once I was able to demonstrate that the error occured 64 KB into the page, I had a case. Some numbers just aren’t coincidence.

Finally, a couple hours ago, one of my dba’s came by to tell that me a bunch of records were truncated after running my import process. I knew of no immediate reason why my script would have truncated any strings. I asked him whether his columns were able to hold the full length of the string, and he confirmed that they were. He said they were getting chopped off at “inf”, just a few words from the end. He hinted that my import script might be messed up, which I didn’t think was very likely. First thing I did was paste the string (up to “inf”) into my editor and check the length. It was 100 characters. Just too good a number to be coincidence. At this point, I found the procs that were responsible for saving the values to his tables. Sure enough — varchar(100).

Nothing terribly profound, but being aware of the number of bytes involved where issues occur can help confirm theories and be a helpful push in the right direction. In that last example, if the string had been truncated at 89 characters or 113 characters, I doubt I would have looked in the import proc first — I would have been scanning my code for string manipulation functions to see if something else could have chopped off the end. Strange, random number of characters, and I’m looking for a messed up regex; even, meaningful number of characters — I’m looking for something that truncates at a given number of bytes.