Archive for the ‘Personal’ Category.

How to be a Great Developer

I’ve shamefully ripped off the title for this blog post from what I expect will be a phenomenal session given by Ed Finkler at php[tek] 2014. Sadly, I haven’t seen the session and may not be present at the conference. However, I’ve spoken with Ed and seen him give sessions on several occasions, so I know he sets the bar pretty high.

If you’ve not considered attending the conference and his session, I highly recommend doing so. Ed has plenty of insightful things to say about being a great developer. Today, the subject coincidentally crossed my mind and I realized I had a few things to say on the matter that may also prove useful to others.


A friend of mine who had some previous programming experience, but was not a developer, recently set out to learn more about what it’s like to be one. This led to many conversations between the two of us that reiterated a few things to me: this person is very intelligent and very determined, and while they felt quite out of their element in this pursuit, they were iteratively making progress toward their goal of understanding what being a developer is like.

This same person recently told me that, over the course of this pursuit, I was the only person they interacted with regarding it who, in their own words, didn’t make them feel like an idiot when they approached me. While I was glad that they had someone like this, I was sad that I was the only one who fit that description.

One thing I have learned over the course of my life is that “genius” is a very relative term: it all depends on who you’re sitting next to. I can name people who make me feel fairly smart just as I can name others who make me feel fairly dumb. I know these people well enough that I can say the latter don’t do this intentionally. Nevertheless, the sentiment keeps my ego in check, which I believe is a good thing.

We all start at the bottom of the totem pole. It benefits you to never forget this and to empathize with those who are going through that journey. Be open to learning from everyone, whether that person is perceived as a master or an apprentice. Nikola Tesla once said, “Our senses enable us to perceive only a minute portion of the outside world.” His words are worth remembering in the context of the limits of our individual knowledge.


Whether it’s with troublesome technology, difficult people, learning newbies, or even yourself as you go through the process of being a newbie once again to pick up a new skill, you will invariably feel frustrated by one thing or another in the process of being a developer. You have to learn to recognize when frustration is transient, when you can use it as motivation to continue and succeed, and to recognize when it’s a sign that you’ve done all you can do and that you should move on.


There is no silver bullet for anything. This applies as much to one’s technology stack or personal tool belt of choice as to one’s self. There is no state of enlightenment that a developer eventually attains. As cliché as it sounds, being a developer is more about the journey than the destination. The best goal you can set for yourself is to be better at what you do than you were yesterday. Compete with yourself, not with others. Aim to solve problems and be pragmatic, not dogmatic, in how you approach them.


These are things I’ve learned from my own experiences. I state them here realizing that they may be more applicable to me than they are to you. You must form your own opinions and find your own wisdom. I’ve said before what and who make me love what I do. I hope you share in some of that, and in some of what I’ve spoken about in this post. In the end, you must find your own path. Regardless of what that path is, I hope you find the passion shared by myself and those who inspire me and I wish you well in your pursuits.

Thoughts on Working Remotely

There’s been a lot of hubbub recently with regard to the recent decision of Yahoo! CEO Marissa Mayer to mandate that all employees, including those currently working remotely, either commute to a corporate office or face termination. This has spurred a lot of speculation in regards to her reasoning behind the decision, from being a less conspicuous form of layoffs to shed expense while saving face with investors to stemming from a more traditional camp of management thought for which productivity requires physical presence in an office. It’s even spurred some accusations of hypocrisy being that Mayer recently paid to have a nursery installed in her office. Be that as it may, I thought I’d take a blog post to share some highlights from my own thoughts on remote working that I’ve gained over the course of doing it for over four years.

Remote working is not for everyone

As much of a public proponent as I may be for remote working, I’ll readily agree that it’s not an ideal arrangement for everyone. Some people need the atmosphere of an office and the presence of managers and coworkers to be productive. These things can have a very real and substantial psychological effect on the motivation and productivity of an individual.

Think about how much time you spend either at work, sleeping, or performing necessary day-to-day tasks like grocery shopping or paying bills. If work doesn’t necessitate that you leave home, you spend a lot more time there and less out in the Real World™. This can be extremely isolating and difficult to tolerate if your employer doesn’t maintain channels of communication that enable you to feel connected to your peers. It also takes a lot of self-discipline to be committed to getting your work done despite there being no one physically looking over your shoulder to ensure that you’re getting the job done.

Remote working has mutual benefits

My commute is the distance from my bed room to my living room. I have time to feed my kids a hot breakfast and put them on the school bus in the morning, then brew a pot of coffee and check my personal e-mail before starting my work day. If I need to, I can step away from my work laptop for a bit in the afternoon to get my kids off the school bus and get them started on their homework or take a short lunch and knock off a bit early to run errands before I pick my kids up from after-school care. Telecommuting and flexible hours enable me to do all these things and thereby significantly reduce my stress level.

I use my own home and internet connection for my work, so I don’t contribute to any needs for equivalent office space or bandwidth in an office. I’m one less car on the roads during the morning and evening rush hours that might be delayed by traffic jams or weather conditions. I’m just a phone call away in an emergency situation. If I’m within reach of my work laptop and an internet connection, that’s as far as I have to walk to provide support. I can communicate in real time via IM, VoIP, Skype, or any number of other tools and mediums.

Remote working has disadvantages

My coworkers need to check their e-mail or be on IM for me to communicate with them; I don’t have the ability to physically track them down or stop by their desk in an office. I may miss out or be the last to hear about casual or in-passing conversations and office news that isn’t formally announced via e-mail. I can’t go out to a local bar for happy hour with my coworkers. I have to open an IM window instead of turning my head to verbally ask a question or make a remark. To at least some degree, I’m out of sight, out of mind, and coworkers must be vigilant to include me in communications, both professional and casual, as much as I must be vigilant to be present and heard. Culture is top-down and has to be maintained both in person and online.

I can’t physically raise my hand to a whiteboard to draw a picture or gesture with my hands. My coworkers can only see my face in photos or video chat. Most of the time, they’re limited to text or my voice and whatever obscure contributions they may make to my ability to communicate. Much of the excitement, disappointment, or general nature of my responses may be lost in translation. I miss out on watercooler conversation and the social element of employment and am forced to find time and opportunity to seek it elsewhere.

Remote working is necessary

The global nature of the job market is only increasing. The state of the US economy is making remote working more of a necessity and less of a privilege. Commutes directly affect the livelihood of those who undertake them in fuel costs, vehicle maintenance, and time commitment. The state of the real estate market and the high variability of cost of living and salary offerings make relocation a difficult or infeasible prospect for many homeowners, which comprise much of the older and more experienced work force.

Limiting hiring to those who are local or are able to relocate significantly diminishes the available talent pool. Companies who dismiss the option of allowing employees to work remotely are forced to hire those who are more convenient rather than those who are best qualified. This leads to a relatively stagnant talent pool as well. Experienced non-local talent is less commonly brought in from the outside, perspectives are limited by locality, and local opportunities for professional development experience less growth. That any of these things need be limited by geography is a limitation that exists entirely in the mind.

Sufficient technology exists for day-to-day operations to carry on remotely in at least close approximation of efficiency to a traditional office space given individuals truly dedicated to that purpose. Any organization that would say they’re “too big” or “culturally incompatible” with remote working is either in trouble or in denial. Either way, they’re doing themselves a disservice that will be illustrated by others like Synacor, GitHub, and Mozilla successfully recruiting the best and the brightest.


Remote working may not  be for every company or employee, but it’s dismissed more often than it should be as a viable employment arrangement. The technological and economical state of the world is only making it more commonplace and will eventually render those who resist it ancient fossils of an industrial era gone by. The age of the knowledge worker has arrived and that knowledge is a commodity that must be sought after regardless of its origin or residence. Any institution that will stand the test of time must follow this principle and eventually globalize or perish.

Recipe: Gumbo

Once aspect of my identity that isn’t readily apparent to new acquaintances is that I’m a native of the state of Louisiana. I have red hair from my paternal Irish grandmother. The Welsch and Irish accents of my paternal grandfather and grandmother respectively seem to effectively cancel out the Cajun French accent of my maternal grandparents. I’m a far cry from what someone might expect of a Louisianian if their basis for comparison is comprised of programs like Swamp People. That said, I value my Cajun heritage, particularly its cuisine. A few coworkers of mine expressed an interest in that area, so I thought I’d share a recipe for a local dish: chicken and sausage gumbo.


  • 1 stick of butter
  • 1/2 cup of flour
  • 16 oz of diced onion, bell pepper, and celery or another common variation of the holy trinity
  • 1 12 oz can of amber ale beer
  • 2 32 oz boxes of chicken stock
  • 3 lbs of boneless skinless chicken breasts
  • 1 lb of sausage
  • 2-2 1/2 cups of rice

For the holy trinity mix, I generally use the Creole Seasoning from Guidry’s Fresh Cuts, which contains yellow onion, bell pepper, celery, green onion, parsley, and garlic. Cajun and Creole cuisine share some similarities, such as their common use of variations of the holy trinity, but also differ significantly from each other. Guidry’s is something of a local staple and an easier option than acquiring and cutting the individual vegetables myself, so it’s an instance where I veer a bit from the Cajun recipe for the sake of convenience.

For the amber ale beer, I use Abita Amber Ale, which is produced by the Abita Brewing Company located in Abita Springs about 30 miles north of New Orleans. Their Amber Ale brew has a great flavor that lends itself well to the gumbo.

Finally, for the sausage, I use Savoie’s Mild Pork Sausage.


  1. Cut the stick of butter into small segments. Place them into a large pot on low-medium heat (on my stove, which has settings of Low, High, and 1 through 9, I use 4 here) until the butter is completely melted.
  2. Use a spatula to stir in the flour. Continue stirring once every 20-30 seconds until the butter-flour mixture, or roux, is the color of milk chocolate. (This will take a while.)
  3. Stir in the holy trinity mix. Continue to stir often until the vegetables soften.
  4. Add the beer. Let the foam settle, then stir until the ingredients are mixed well.
  5. Add the chicken stock, then stir until the ingredients are mixed well.
  6. Increase the heat to medium-high (on my stove, I use 6 or 7) and let the mixture come to a boil.
  7. Carefully slide the chicken breasts into the pot. Let the mixture continue to cook for 45 minutes, stirring occasionally.
  8. Before you reach the 45 minute mark, prepare the rice. I use a microwave rice cooker, which takes about 15 minutes for this much rice.
  9. Also before you reach the 45 minute mark, cut up the sausage.
  10. Once you reach the 45 minute mark, carefully lift the chicken breasts out of the pot, shred them, and replace them into the pot. I just use two forks to do this.
  11. Add the sausage to the pot. (This is done late in the process to prevent the gumbo from getting overly greasy.) Let the gumbo cook for an additional 5 minutes.
  12. Place the rice into bowls and pure the gumbo over the rice. Optionally place the bowls in a freezer for 5 minutes or so to cool them down to eating temperature, stirring them again when you take them out.
  13. Serve and enjoy!
  14. Optional: prior to refrigerating leftovers, mix remaining rice into the gumbo. This will enable the rice to keep in the refrigerator better than it would otherwise and allows for ready-to-heat lunch-size portions.


Why I Love Writing Software

“Charlie sees math as beautiful, and he wants everyone else to love it the way he does.”
~ Judd Hirsch playing Alan Eppes in Numb3rs Season 4 Episode 9, “Graphic”

I’ve been using computers since I was five years old. In my early teens, I started writing computer software as a hobby. I took computer science courses in high school and went on to graduate from college with a bachelor’s degree in computer science. All of my jobs have at least involved information technology. Most of them, including the one I have now, have involved writing software.

I’ll turn 31 early next year. I haven’t been doing this as long as some, but I’ve been around the block a few times. In that time, I’ve noticed a few things about how others — muggles, if you will — perceive people who write software. I wanted to talk about those in this post as well as describe what writing software means to me and why I love doing it so much. Whether you do as well or not, please read on.

People tend to think that, in order to be capable of or good at writing software, you have to be a math or science nerd. Truthfully, it certainly doesn’t hurt, but it’s not a necessity. I struggled with math in college. It took me multiple tries to get through most of the math courses with the minimum grade required by my curriculum. As it turns out, I don’t use what I learned in those courses very often when I’m writing software. Given my academic track record, I’m rather grateful for this.

I’ve also found that people don’t view writing software as being a craft or creative pursuit. At its center, writing software is problem-solving. Think about the last time you had to solve any problem, big or small. How did you do it? Was the solution simple or complex? Would it seem unusual or creative to someone else if you explained it? Did you feel a sense of satisfaction when you found the solution? These questions apply to writing software just as they might to anything else, perhaps more so because software can be applied to so many different problems.

Have you ever written something where you carefully arranged information and chose words to make it easy for someone to consume, whether it was a document for professional instruction or a work of fiction? People who write software do this too. In many cases, the software we write can be used by others to build other software. It can be like a tool or the foundation of a house in that respect, except that it can be made available to anyone who wants it by releasing the source code. It’s not unlike releasing artistic works as creative commons and allowing derivative works.

Writing software also has a pedagogical nature to it because the product of writing software is instructions that a computer — and, ideally, a human being — can understand. It’s a way of sharing knowledge in a form that’s usable directly. In fact, software is often written to be usable without having to know how its innards work, much like how you don’t need to know the mechanics of a combustion engine to drive a car. Much like what I’ve felt when teaching or mentoring and having someone form an understanding of something that I’ve communicated to them, there’s a satisfaction in being able to successfully teach a computer to do something useful.

I’ve seen few other hobbies or professions where I can share a problem with someone and a few minutes or hours later have a working solution I can use to solve that problem. And that person can live halfway around the globe from me! The possibility for collaboration on software projects is incredible. People who write software are able to empower themselves and each other to create and empower others by creating things that make their lives easier. As pervasive as technology has become in our society, the ability to exercise this power can be both useful and enjoyable.

If this post reads in a bit of a distracted way, it’s because the reasons why I love writing software are many, diverse, and wonderfully complex and nuanced. I think it has a beauty all its own and that’s something I want to share with others. Hopefully, what I’ve said here has given you some insight or, if you write software too, it’s reminded you of why it’s a passion we share. I’d love to hear your thoughts in the comments. Thanks for reading.

Recruiter Dos and Don’ts

It’s certainly no secret that people in my profession are often targeted by recruiters. I may not get as many such communications as some of my peers, but I do receive them sporadically. There’s a fairly common format to them:

“Hi, my name is [name] and I work for [company]. I have [one or more positions] available in [one or more cities I don’t live in]. I would like to schedule some time with you to begin the interview process.”

Having been through such interview processes on numerous occasions, I can speak to several things that I’d like to see more recruiters and companies do going in.

  1. Get to know us especially what motivates us like things we value more than money and the culture inherent to our vocation.
  2. Be aware that corporate perks may be important to some of us, but that’s certainly not a universal truth.
  3. Be aware that we tend to change jobs often. Understand why so you can curb this trend. Don’t offer lame engineering jobs.
  4. If you get as far as an actual interview, know what to look for or how to look for it.

These are some common situations I see when recruiters make first contact:

  1. I have positions you’re not qualified for based on your skill set. Take the time to read my résumé!
  2. I have a position, but won’t tell you anything other than the desired skill set. If you can’t at least tell me the industry or types of projects I’d be working on, I can’t tell if I’m interested or not and we’re at a stalemate.
  3. The positions I have open are in cities nowhere near you and working remotely isn’t a possibility. I have no economic ability or desire to relocate. Being open to a remote working arrangement for a candidate who can function well in one will set you apart.
  4. 50+ hour weeks or late nights are frequent and commonplace. Such hours are not conducive to work-life balance, which is important.
  5. The daily schedule is fairly strict. Some guaranteed hours are understandable, but I require trust that I’ll put in the time required to get the job done around family and other obligations.
  6. Travel lasting more than a week is frequently required. I appreciate the value of face time, but spending a significant portion of my life on planes and in airports isn’t something I’m signing up for.
  7. You would be reporting to a manager who has no programming experience. If someone doesn’t understand what I do, I think it significantly impedes their ability to manage me.
  8. No support is provided for professional development, such as attending industry conferences. If I’m not growing, I’m stagnating, and any other opportunity for growth with eventually supersede the position I’m in.

While I can’t speak for everyone in my field, I think these circumstances don’t apply to just me:

  1. I’m a husband and a father of small children. I have family in the area where I live (where family is a large element of the local culture), they have close relationships with my children, and they provide most of the only consistent familial support we have in raising my children.
  2. My family has a weekly routine. I often have to get my kids to school in the morning and get them off the bus or pick them up in the afternoon. This isn’t always conducive to being in at 8 AM on the dot, being at a keyboard every minute until 5 PM, working after 5 PM, or being away from home for long periods.
  3. The cost of living where I live is low. This is offset by the cost of raising three children, but it is better than moving to a major city where it costs two to three times as much to live what I would view as just as well.
  4. The current state of the real estate market makes relocation a losing proposition. It’s a buyer’s market. To sell and relocate would in all likelihood require a five-figure loss that’s unlikely to be mitigated by a relocation package.
  5. Companies where I’m not growing and learning as a professional don’t stay appealing very long. Coworkers and managers who contribute directly to this and companies that allow me opportunities to learn from and network with others in my profession do.

The point of this post isn’t to discourage recruiters from contacting me (though they should understand that I like where I’m working now and I’m not on the market). We all know time is valuable. Rather than spend it repeatedly reiterating all the things I’ve written in this post to each recruiter who comes along, I’d rather write it once and point them to it. If they still want to talk, that’s fine. Otherwise, that’s time we can both spend furthering our respective careers in other ways.

Recruiters and developers alike are invited to leave their comments on this post.

Speaking at Confoo and php|tek

2011 seems to be a year of multiple firsts for me.

First, I’ve been invited to speak at Confoo. I’ve submitted there before, but this year is the first time I’ve been accepted. This will be my first trip outside of the United States, as Confoo is held in Canada, more specifically Montreal. I’ve never spoken at a conference on a topic that wasn’t PHP-related, but this time I’ll be venturing outside of my comfort zone to speak on developing REST web services with Jersey, a framework written in Java that I used as part of a work project at Synacor for the latter half of last year.

Second, I’ve also been invited back to speak at php|tek. I spoke there last year on the new SPL features available in PHP 5.3. I haven’t spoken at the same conference twice, but I’ll be happy to return to this one as I consider it one of the best PHP conferences in this hemisphere. I’ll also be giving two presentations, one on web scraping accessing web resources in PHP (thanks Cal) and the other on creating applications with Titanium and PHP.

If you plan on attending either of these conferences, please take the opportunity to say hello and introduce yourself. I look forward to seeing you!

Why I Write

Someone I know recently sent me a question that I found interesting.

“I’m… exploring why I continue to pursue the insanity that is writing, and I want to get some views from people who write in other disciplines. Got any insight to share on why you wrote your book?”

I’m unfortunately still seeing delays in the print edition of my book being published. My apologies to those of you who have been asking after it; trust me when I say that I’m doing everything I can at this point to make it happen.

Unpleasantries aside, I decided to take a blog post to answer this question. I’ve actually written on this subject in the past with respect to technical publishing in particular, if you’d like more background on that.

As far as my personal reasons go, they certainly didn’t relate to money. Technical publishing may not be as saturated a market as mainstream fiction, but it’s also not as lucrative for authors.

Its relatively limited audience also eliminates fame as a reason, at least outside of that audience. A book may complement an existing reputation, but it’s more rare to establish a substantial level of notoriety through being published. Respect within that community — colleagues, peers, and prospective employers — is a more feasible goal.

That leads me to my personal main reason for writing my book: credentials. My knowledge and skills were vetted by a publisher respected within the industry for the quality of the books they publish. While it may not be directly monetary, that respect has value and there are few ways for an individual to attain it. Publishing a book is one such method.

Lastly, I felt I had something to share with an audience with whom I had a common interest. The topic of my book may be a bit niche, but prospective readers are all the more likely to be fervorous about studying or otherwise pursuing it. Readers of science fiction and technical books have this trait in common. If I ever end up publishing a fiction piece, it will likely be in the former genre.

It’s one thing to publish a blog post or an article in a professional magazine, but a book signifies a higher level of commitment, dedication, and perseverance. If writing is insane, it’s in the same boat with getting married and going to college. I doubt there are enough padded rooms and straitjackets in the world for all its college students, married couples, and writers.

Leaving K-fx2

There are times in life when things don’t go to plan. You may start a new job and then, after some time in the position, come to find that it’s just not a good fit for you. Regretfully, that’s been a recent experience of mine: I’ve decided to leave my position at K-fx2. I wish my coworkers well; they have my thanks for the experiences I had in my time there. If you are a PHP developer; live within the Lafayette, Baton Rouge, or New Orleans areas; and are looking for work, consider joining them.

As for what’s next for me, I’ve accepted a position with Synacor as a Senior Engineer on their Content Management Platform team. I will be traveling to their offices in Buffalo, NY for orientation on April 26th. The team seems excited about me coming on board and I’m looking forward to meeting them in person. If you live near the area and would like to see me while I’m in town, just let me know.

Ada Lovelace Day and Amazing Grace

So, if you hadn’t already heard, today is Ada Lovelace Day. If you aren’t familiar with it, it’s is an internationally observed event during which its participants use blogs, podcasts, videos, and all other forms of internet media to celebrate the achievements of women in the fields of technology and science. Read more about the event and its namesake or take a look at this timeline of major female figures in computing from its beginnings with Ada Lovelace to present day.

Many people choose a friend or colleague who’s helped them to excel in the field. I myself have a number I could name, but with this being the first year I’m participating, I chose instead to veer from the beaten path and write this blog post about someone I’ve admired since I began serious study of computer science in high school. The very first computer science course I took began with a unit on the history of the field. Among the other Big Names included in that unit was that of Rear Admiral Dr. Grace Hopper, also sometimes referred to as “Amazing Grace.” And did she ever live up to that name.

The first reason I admire Grace is because she was no stranger to failure or perseverence. When she applied to Vassar College at the age of 16, she was rejected because her test scores in Latin did not meet admission requirements. She persisted and was admitted the following year, going on to earn a bachelor’s degree in mathematics and physics from Vassar College and a Master’s degree from Yale. She would eventually return to Vassar to share her knowledge as an associate professor of mathematics.

While my own academic achievements are an understated far cry from hers, I relate to this quality because it took a large amount of persistence for me to complete my own degree, partly due to my admittedly lacking abilities in mathematics as compared to the requirements of the curriculum under which I graduated. I struggled, had to retake several classes due to not meeting grade requirements, but persevered and earned the degree that hangs on my wall today.

The second reason I admire Grace is the magnitude of her aspirations. In a time period when not all colleges in the country accepted women, women were mainly relegated to “lace-collar jobs” in the workforce, and the right to suffrage for women had not yet been won, Grace chose to pursue her education in a field that to this day is still predominantly occupied by men. Not only did she participate in the field, she excelled in it, contributing to technological breakthroughs that literally became the stuff of legend and the foundation for the technology that we enjoy today. Hers is truly a story for the history books, one of defying stereotypes and overcoming adversities of society to achieve something spectacular.

The final reason that I admire and even envy Grace is her contributions to the innovations of her era. In 1944, during her service in the US Navy Reserve, she served on the programming staff for the Harvard Mark I, the first large-scale automatic digital computer in the country, and coauthored papers on it and its two successors. In 1949, she became senior mathematician for the team that developed the UNIVAC I, the first commercially available computer in the country. The work she did between 1950 and 1980 resulted in the first compiler, an accomplishment to which many professional software developers today owe their livelihood. In the 1970s, she pioneered standards for testing computer components and systems for which administration would later be assumed by the National Institute of Standards and Technology. She was right there in the thick of the industry’s beginnings, making contributions that would echo in the decades to come.

Sadly, Grace passed away six years before I came to know the significance of her accomplishments to my future career and the technological state of the entire world. She was laid to rest with full military honors in Arlington National Cemetery on January 1, 1992. I regret never having had the chance to shake her hand and tell her in person all that you’ve read here just now. So Grace, I salute and thank you for the immense impact that your life and service have had on the planet you left behind. No matter where technology may take our race in the generations to come, I sincerely hope that they carry your memory with them.

Where I’ve Been

Things have been rather busy in my life recently, even though this blog doesn’t really reflect that. I thought I’d take a short post to share with any readers who may have wondered where I’ve been the past month or so.

I changed jobs a few weeks ago and the new one has kept me fairly busy learning processes, writing proposals, and beginning to work on projects. I’m getting acclimated to actively using Zend Framework again, which I’m enjoying.

I also recently launched Phergie 2.0, which was very well-received. Moving the project over to GitHub, launching the new project web site, and helping with the first round of bug fixes has kept me busy.

The ball has started rolling on getting my book published again. The ISBN has been obtained, the last round of edits is happening now, and the digital edition should be available for sale before the TEK-X conference in May. I’m hoping to have a few dead tree copies to distribute at the conference.

Speaking of which, I’ll be speaking at TEK-X, so I’ve also been working on preparing my presentation on new SPL features in PHP 5.3. I’m planning on putting my presentation content into (fairly long and embellished) blog post form, so keep an eye out for that.

I’ve been under the weather with a cold over the past week. I’ll try to find more time to blog once I’ve recovered and things have settled down a bit.