Archive for the ‘Uncategorized’ Category.

Why Aren’t You Speaking?

Earlier today, I asked on Twitter why technical conference attendees hadn’t been a speaker at a conference themselves. Here are a few of the responses and my advice.

I haven’t been willing and able to spend the prep time I feel that would deserve.

All I can say to this is, budget your time. If it’s important, you’ll make the time for it. All speakers have to. While speaking may not be for everyone, I do highly recommend giving it a try at least once.

Stage fright. Lack of competence (or impostor syndrome). Thinking my areas of expertise wouldn’t appeal to others. Basically, fear.

Not feeling I am enough of an expert or knowledgeable on a topic to get up and speak. (CFPs can be intimidating too.)

Speaking for 45min-1hr is intimidating; didn’t have subject I’m confident in and have that much content for.

My talk submissions have not been accepted, likely because I lack local practice.

Perceived lack of expertise comes from the Dunning-Kruger effect, specifically the aspect of when a relative (to the audience) expert underestimates the extent of their own knowledge. It’s a cognitive bias that has to be overcome.

The same applies to stage fright. I’ve seen people who would quite literally faint at the prospect of speaking in front of a group overcome their fear and go on to become great speakers. It takes practice and repeated effort, but it can be done.

There are a few ways to dip your toes in the pool of speaking:

  • Start by writing a blog post or article for a site like SitePoint or a magazine like php[architect] about the topics you’re considering speaking about. In addition to helping you build knowledge and practice presenting it off-stage, these can help you build credentials as someone familiar with the relevant subject matter.
  • When speaking, start small. Give a lightning talk for a group like Nomad PHP, which has a significantly shorter length than one for a conference. Attend a conference that hosts an unconference and volunteer to give a shorter talk there. Volunteer to speak at a local user group or your local Toastmasters chapter.
  • Need help developing your conference abstracts? Use a site like HelpMeAbstract to get help from successful speakers or use a site like PHP Mentoring to find someone who can provide more one-on-one help.
  • Read my post on speaking resources for help when you’re ready to start submitting to conferences and how to handle preparing when you get accepted.
  • Don’t let rejections discourage you. It can take a while to get accepted. Be persistent. Try to improve your proposals, write new ones, and keep on submitting.

If you’ve spoken at a conference before, what are your tips for prospective or first-time speakers? If you haven’t, why not?

On Remaining Employable

Following my post on changing jobs, I communicated with a friend who’s in the market for a job. His circumstances inspired me to write a post for a slightly difference audience. So, here’s some advice on remaining employable as a developer.

  1. There are some job sectors wherein it’s been common for a developer to remain employed with the same organization for years, sometimes even decades. Government is one example of these. These sectors have two notable qualities: a) they are few in number; and b) they are becoming fewer by the day.
  2. These days, it’s very difficult to survive in the tech industry without some sort of specialization. There are too many technologies for you to be competent with all of them. While there are some exceptions, most companies look for developers with a specific set of skills who can hit the ground running when they’re hired, as opposed to developers who may be generally savvy, but will take time to become acclimated to a new tech stack. Choose your specialization carefully and, once you choose it, immerse yourself in it.
  3. There’s a balance to be found between the extremes of being a niche specialist and being a jack of all trades. Too specific a niche will mean that people with your skill set are difficult to find. While this sounds good, the lack of supply can ultimately limit available positions. That’s not to say that job availability should be the sole factor in what tech stack you choose to specialize in, but market demand is a factor worth taking into consideration.
  4. Do not become complacent in any position you take. Do not become too content or comfortable, do not assume that you will have the same job indefinitely. Things happen, losses are suffered, organizations downsize, people end up out of work. You need to remain potentially valuable to other organizations to stay employed, which means you need transferrable skills.
  5. Do not stop learning. If you only deal with technology from 9 to 5, you are what’s called a “day coder.” It may earn you a paycheck, but it will not keep you employable. Technology is too massive and changes too frequently for you to keep a reasonable handle on it from what few opportunities most 9 to 5 jobs will afford you.
  6. Be prepared to take time off the clock and spend your own money for professional development. Do research on new tech, experiment, work on side projects, contribute to open source projects, attend conferences or local meetings of professional industry peers, etc. Sadly, few companies that I’ve encountered seem to have both the resources and interest in the professional development of their employees to contribute significant time or money to such efforts.
  7. Network with people, and do not wait until you need a job to do it. Go to user groups or conferences, make a point of talking to people, form relationships, and stay in contact. Get online, join IRC and Twitter, ask questions, participate in discussions, put your name out there, and maintain visibility in those communities.
  8. Put your work in the public eye. Write articles for sites like SitePoint or magazines like php[architect]. File issues and submit pull requests to open source projects, or start your own. Submit to and speak at conferences and user groups.
  9. Update your résumé frequently. Add descriptions of projects you’ve worked on, both at work and on the side, complete with the tech stacks you used. Include links to your profiles on sites like GitHub or Bitbucket. List any publications or speaking engagements you’ve had.
  10. If you haven’t already, give my friend Cal Evans’ book on the subject a look.

Good luck!

On Changing Jobs

An apprentice recently sent me an e-mail:

For the past month or two my work has been a not fun and I’ve been very unhappy. I felt like I was being mismanaged, being setup for failure, thrown under the bus for things that were out of my control, and the lack of on-boarding really hurt my ability.

Two friends have asked to join their companies and I have interviewed but have not completed them. The company I am at is pretty good and it would be a positive step in my career but I’m quite miserable. I was working 14 hrs/day for a few days out of the week and a min of 9/10 hrs. It just caught up to me.

Then my boss quite and now I’m being managed by people in [redacted]. They discovered my work hours and cut it back to a normal day, sprints push back when feature creep happen, but I still have that bad taste in my mouth. Things have gotten a little bit better but the idea of working with my old boss from a previous company is tempting. Plus the code I’d be writing would be relevant and not just for profit.

Do you have any advice?

He later told me my response to his question was blog-worthy, so I thought I’d publish it for posterity.

Here are my observations:

1) Burnout is a very real thing. If you’re doing 50-60 hour weeks, that can be a fairly good sign of mismanagement. It’s good that you aren’t doing this anymore, but obviously that alone isn’t going to determine whether or not you’re happy.

2) In terms of money, most people ultimately work for someone else’s gain. You’ll be hard-pressed to find a job where you aren’t the source of another person’s dollar. In terms of having an impact on the world around you, whether or not you’re making the impact you want to make is something only you can decide for yourself. That said, I can definitely appreciate working for a cause you believe in and I very much think that’s an idea you should consider further.

3) Working for people you interact with mostly online or with a significant time difference can definitely be challenging. (Some other thoughts on that here.) It sounds like your new managers are at least trying to make circumstances better. Not all managers do that. Just something to consider. If there’s anything they haven’t improved that you think could stand improvement, try to approach them about it in an open and honest fashion.

4) There is definitely a “grass is greener” bias when it comes to your current job versus a prospective job, especially when friends are involved. (Side note: working with friends isn’t always what it’s cracked up to be.) The trick is learning to recognize that bias in your own thinking and to judge each job as objectively as you can. One method that’s helped me is making a list of pros and cons for each job that I’m considering, current and prospective. This forces you to really consider what matters to you.

5) Every job change is a risk. It’s possible the place you’re going to will be worse in some aspect, be it personal happiness, job security, or something else. There are many things you won’t necessarily know unless you actually make the job change. Make a point of asking as many questions as you can of prospective employers during the interview process to get a sense of what working at a new job would be like. This may give you food for thought.

6) If you do decide to quit your current job, I would definitely avoid doing so before you have a new job lined up complete with an official offer letter. Also, depart from your current job as amicably as you can. You never know what bridges you may need to cross again; burning them can limit your options in the future.

7) To paraphrase Cal Evans, if you’ve tried to make positive changes in your job such that you can be happy, to little or no effect, you’re ultimately left with only two other options: a) suck it up, get on board, and do your job to the best of your ability; 2) leave. Again, that’s a choice only you can make.

So Long, Blopboard

I began an amazing journey with Blopboard when I joined them in October 2013. Unfortunately, it looks like that journey is coming to an end. For reasons unrelated to the quality of the team (which has been awesome) or the product (which has also been awesome), the decision has been made to cease operations at the end of June. As such, I will be investigating new employment opportunities within that time period.

I’ve published an updated version of my résumé at http://elazar.github.io. I’d very much appreciate it if you, my dear readers, could review it, share it on social media, and point me to anyone who may have opportunities that would be a good fit for me. It’s worth noting that I’m located in New Orleans and have obligations that will keep me there for the foreseeable future, so opportunities I’m able to consider would have to be either local or remote-friendly. Thanks in advance for your help.

Positive thoughts and moral support that have been and will be given are appreciated. Here’s to the next chapter…

Sniffing Outgoing HTTP Traffic on an iOS Device

I’m posting this mainly for my own benefit, but hopefully someone else finds this useful. A lot of people have recommended Charles as a debugging HTTP proxy for OS X. It looks like a great piece of software, but does require that you pay for it after 30 days. I was looking for something quick, easy, and free to analyze outgoing HTTP traffic on an iOS device.

Sadly, such options are few and far between, but if you’re willing to install a JDK (which Mavericks handily prompts you to do the first time you try to run a JAR file, and automates much of the installation process), they’re slightly better. I found a free edition of one called Burp Suite and managed to figure out how to get it working, so I’m documenting that here for future reference.

I’m using a Macbook Pro and an iPod Touch to do this, but since Burp Suite is written in Java, it should be possible to do this using any Java-capable device on your LAN and any device running iOS.

On the device with Burp Suite:

  1. Open up a terminal (I use iTerm2), run the ifconfig utility, and note the LAN IP address of the local machine (e.g. 192.168.1.113)
  2. Run the Burp Suite JAR file from a terminal like so: java -jar burpsuite_free_v1.5.jar &
  3. In Burp Suite, click the “Proxy” tab and, within that, click the “Options” tab
  4. Under the “Intercept Client Requests” section, uncheck the checkbox marked “Intercept requests based on the following rules” if you don’t want to modify requests, only view them (because individual intercepted requests are blocked by the proxy until you manually opt to forward them from the “Intercept” tab within the “Proxy” tab)
  5. Likewise, under the “Intercept Server Responses” section, uncheck the checkbox marked “Intercept responses based on the following rules” if you don’t want to modify responses, only view them
  6. Under the “Proxy Listeners” section, select the existing entry in the table and click the “Edit” button
  7. In the “Edit proxy listener” window that appears, next to the “Bind to address” label, select the “Specific address” radio button and, from the drop-down menu next to it, select the LAN IP address of the local machine, then click the “OK” button
  8. Make sure the “Running” checkbox next to the proxy listener is checked, then click to the “History” tab within the “Proxy” tab

On the iOS device:

  1. From the desktop area, click the “Settings” icon
  2. In the “Settings” menu, click the “Wi-Fi” option
  3. In the “Wi-Fi” menu, click the option for your LAN
  4. Scroll to the bottom of the screen, find the “HTTP PROXY” section, and enter the LAN IP and port on which the HTTP proxy is running (8080 by default, you can find it in the proxy listener rule in Burp Suite)
  5. Return to the desktop area, then select the app for which you want to monitor HTTP traffic
  6. Perform some operation that kicks off an HTTP request, then find details on it in the Burp Suite “History” tab

On What to Learn

An aspect that I’ve enjoyed of participating as a mentor in the PHP Mentoring program is the interesting and provocative questions I receive from my apprentices. One such question, and in my opinion a rather important one, came up recently:

“One thing I feel I struggle with is wanting to take on too much. There are so many languages out there, and I would love to learn all of them… How do you balance your time while still staying on top of the game? In your opinion, which languages do you think are the best to focus on?”

This will probably sound cliche,  over-dramatic, overly philosophical, or what have you, but understand that I’m simply stating it as fact to reinforce the point: perhaps our biggest limitation as a species is that we are bound by time. We exist for a very brief period. With every moment that passes, the state of our world is subject to one constant condition: change. A skill you learn today may be obsolete a few years from now. A memory may be with you decades from when it’s first formed, continuing to color your views and experiences.

Some of us — perhaps the best of us — would love nothing more than to have the time and capacity to learn everything that the world has to offer, but that’s not within our physical capabilities. Our only other option is consciously limiting what we learn and what we focus on. It’s regrettable that we must do this, in particular because the acquisition of knowledge is a noble goal, but it is the way of things. To at least some degree, we have to specialize our knowledge.

The question of what to learn is one I’ve pondered before this person ever posed it to me. At a time when I lacked a good answer, I did what I normally do in such situations: I consulted my betters, in this case Dr. Alan Perlis. Dr. Perlis was an American computer scientist with many accomplishments to his name, most notably his pioneering work in programming languages.

In 1982 — the year of my birth, fittingly — Dr. Perlis published a work entitled “Epigrams on Programming” in the monthly newsletter of SIGPLAN, a special interest group of the Association for Computing Machinery focused on programming languages. One quote from this publication stood out to me:

19: A language that doesn’t affect the way you think about programming, is not worth knowing.

I don’t know that I necessarily agree with Dr. Perlis on this point in all cases, but it does provide a rule of thumb of sorts when considering what to invest time and effort in learning. Programming languages aren’t especially different from spoken languages in this respect: learning one Latin-based language may help you to learn others, but learning one that isn’t Latin-based such as Russian or Chinese increases your overall understanding of language.

When I was in college, I took a course on programming languages specifically aimed at increasing our breadth of knowledge about them. We wrote a parser for a subset of ALGOL 60 (a language for which Dr. Perlis was a member of the development team) in SNOBOL, a tokenizer for ML in ML, and an object-oriented rendition of a switch statement in Smalltalk. These aren’t hipster programming languages; the thought that went into their development formed the foundations of modern programming and paved the way for the languages we use today. Each of these proved interesting to study in their own way and fulfilled the goal of the course.

So, to come full circle, here are my reflections reduced to a few epigrams of my own:

  1. Rein in your desire to learn everything while maintaining your desire to continue learning.
  2. Focus your efforts on learning things that contribute to the quality of your understanding and of your craft.
  3. Every once in a while, learn something just because you want to.
  4. Make a point to sporadically have experiences in which learning is not your primary goal.

And one last parting thought: you can find more and better words of wisdom in The Pragmatic Programmer. If you haven’t read it, I highly recommend you make the time to do so.

My best,

Matt

Restaurants and Web Sites

Today I saw the most recent episode of Kitchen Nightmares, which takes place in the city of Metairie in my home state of Louisiana. After the episode, I visited the web site of the featured restaurant. My experience there combined with other similar recent experiences inspired me to write this blog post.

The topic of this post is not new. Let’s face it: once there’s an Oatmeal strip about a topic, chances are it’s been around the block once or twice. However, it seems like the point isn’t being driven home to its intended audience: restaurant owners. So, I’m aiming to present the material at a slightly different angle than I generally see it presented in hopes that it has the intended effect. Feel free to pass the link around to anyone you think is a member of that audience.

Let’s look at a hypothetical scenario. There’s a person, who we’ll call Joe, and he’s coming up on his lunch break at his office job. A few of his coworkers come around, say they’re thinking of dining out for lunch, and invite him to join. The group then tries to decide on a venue. To give them a better idea of their options, Joe pulls up a web site like Google, Google Maps, or Urbanspoon to see what’s nearby. A number of questions need to be answered when considering any individual option.

  • What are the restaurant’s hours?
  • Is it open for breakfast, lunch, or dinner?
  • What type of food is served (e.g. burgers, Chinese, etc.) and how is it priced?
  • Where is the restaurant and what are the directions to get there from the office?
  • Does the restaurant offer orders for carry-out or delivery?
  • How long is the wait time before a customer is served?
  • Is a reservation required? If so, how far in advance does it need to be made and can it be done online?
  • For more uncommon questions, how can the restaurant be contacted?

How much of this information does your site provide and how easily can potential customers find it? Are different pages of the site clearly named, linked to in a prominent navigation section, and populated with well-organized and relevant information? Are important basics like location, hours, and phone number prominently featured on every page?

Now, information from internet sources isn’t always accurate. Let’s say that the group chooses a restaurant, drives there, and realizes that the restaurant has closed down. They’re no longer near a computer, but with the increasing availability of mobile devices, each has a mobile phone. They use them to search again and review other options. There are several things that might make the group pass up a particular venue at this point.

  • Desktop-targeted web sites. While these can be viewable on a mobile phone, they can require a lot of zooming and panning to read and may not display as well in mobile browsers. Offer an alternative minimalistic version of the site for mobile devices.
  • Flash animations. Not only can they be large to download over a mobile network, but many mobile phones don’t support them and simply won’t display them. You probably don’t need Flash on your web site to begin with. If you really think you do, only use it on the desktop version; leave it out of the mobile version.
  • Menus in PDF format. Like Flash animations, they’re typically larger than a web page and many mobile phones can’t read them without supplemental software. Even with that software, they can be annoying to navigate. PDF files are great for printing and passing around the office, but the ideal situation for mobile phones is having the menu content on an actual web page, preferably one that’s mobile-specific. This also gives search engines additional content to pick up and associate with your restaurant.

How mobile-friendly is your web site? Can all the information it offers be easily consumed by mobile devices as well as desktop computers?

One last parting thought: the end goal of a web site depends on the business it represents. Too often, I see restaurant owners lose sight of what the purpose of their web site should be: to get customers off the site and into the restaurant as quickly as possible. This contrasts with some sites like Facebook or Amazon, where the goal is to keep customers on the site as long as possible.

A restaurant web site can accomplish its goal by enabling prospective customers to get the information about the restaurant that they need and then leave. While it isn’t always feasible to measure, a web site that doesn’t do this effectively can have a very real, negative impact on the bottom line of the restaurant as a business because it is a reflection of that business.

If you own a restaurant and don’t have a web site yet, please keep these things in mind when having one developed. If you already have a web site and it veers from these guidelines, I urge you to consider having it changed. As usage of the internet and mobile devices increases, these guidelines will only become more important.

Twitter XSS Vulnerability

So by now a lot of people have realized that the Twitter web interface has succumbed to an XSS vulnerability. The JavaScript contained in one particular tweet that’s part of this causes you to retweet it so that it will spread to others and then establishes a modal overlay on your Twitter home page so that mousing over it forces you to continue retweeting it over and over again.

I had a hunch on how to get around this that turned out to be correct. Go to your Twitter user page (in my case, http://twitter.com/elazar). This JavaScript doesn’t appear to affect that page, allowing you to undo the retweets so you can access your Twitter home page again. Note that this won’t prevent retweets from people you follow from showing up in your feed. The best you can really do about that is help to spread the word about how to fix this situation.

At this point, I would suggest deleting your cookies, logging into Twitter, navigating manually to http://twitter.com/settings/account, changing your password, logging out, and logging in again. It may also be best to use a Twitter client instead of relying on the web interface until it’s fixed. No word from Twitter on this as of yet.

If you have any other comments that may be handy in this situation, please leave them on this blog post.

Stop Asking, Start Helping

Full disclosure: I’m not on the internals team. The topic of this blog post just happens to push my buttons and I want to be able to point people to a URL rather than answer the question over and over again.

A question that seems to be popping up more and more these days is, "When will PHP 6 be released?" It’s especially annoying because the people that enjoy an exercise in futility ask this question are the same people that simply refuse to take WIR for an answer. Or maybe they just read into the hype generated by trigger-happy publishers who want to preempt a stable release, I don’t really know.

There’s been no alpha or beta release of 6; it hasn’t moved anywhere outside of the CVS repository yet. I would think that would provide some indication that 6 is still a ways off. The feature freeze for 5.3 was originally set for 7/24/08. The first beta release only came out this week. This is all public knowledge and I think a pretty good indicator of the speed at which the landscape is changing.

Given what was originally planned for 6 and how much of it ended up in 5.3, the 6 envisioned today could be worlds away from what actually ends up being released. Take a look at those TODO lists; the amount of work left to be done is anything but trivial. The internals team is not a corporate entity and its members are not compensated for their work in any way. They are volunteers and most work on PHP when they’re off the clock from their day jobs. This limits how quickly progress can be made and how accurate estimated release dates can be. So respect them and their time and stop asking when it’s going to be ready, because they don’t really know much better than you do.

Another thing: PHP is server-side software. It’s not a new web browser coming out where the user may or may not upgrade when you have had time to adapt your application to work with both the old and new versions. No one is forcing you to upgrade the installation you use internally. If you have customers that maintain their own PHP installations, don’t feel pressured to be on the bleeding edge just because they want to be.

Be sensible: don’t lag more than two or so minor point versions behind the current stable offering, don’t immediately upgrade to a brand new stable version, and have automated tests that can be run against release candidates so it’s easier to discern issues that might arise when a stable release does come out and you want to upgrade.

If you really want to be prepared, there are several things you can do. Keep tabs on the accepted and implemented RFCs to see what features are being added and what effect, if any, they have on BC. Search the bug tracker for issues reported and fixed in the branch relevant to you. Don’t limit yourself to testing new versions with your own test suites, but help to write tests for PHP itself to ensure that new versions are as stable as possible. These will make your time much better spent than asking a question that has no definitive answer. And it will keep the rest of our blood pressures all the lower for it.

Natural Ordering in MySQL

I ran into an instance recently where I wanted to implement natural sorting of a result set in MySQL. When you’re dealing with numerical strings or strings with a common non-numeric prefix, the common solution of casting the order column to an integer by adding zero to it works fine. However, if neither of the aforementioned conditions is the case, it takes a little more work.

What actually happens when you add zero to a non-numeric column depends on the characters at the beginning of the column value. If the column does not begin with a sequence of one or more numeric characters, then adding zero to that column produces zero. (Ex: “dog” + 0 = 0) If the column does begin with numeric characters, then adding zero to it produces the sequence of numeric characters up to the first non-numeric character in the original value or the end of the value, whichever comes first. (Ex: “12 dogs” + 0 = 12) An example might be the easiest way to illustrate this.

mysql> SELECT name+0<>0, name+0, name 
    -> FROM `recommendation` 
    -> ORDER BY name+0<>0 DESC, name+0, name;
+-----------+--------+------------------------+
| name+0<>0 | name+0 | name                   |
+-----------+--------+------------------------+
|         1 |      3 | 3 month follow-up      | 
|         1 |      6 | 6 month follow-up      | 
|         1 |     12 | 12 month follow-up     | 
|         0 |      0 | Intervention           | 
|         0 |      0 | Observation            | 
|         0 |      0 | Specialty Consultation | 
+-----------+--------+------------------------+
6 rows in set (0.00 sec)

The first ORDER BY clause checks the string to see if it begins with numeric characters, then places results for those that do first. If you prefer that numeric results appear after non-numeric results, then you can exclude this clause.

The second ORDER BY clause orders the numeric results by casting them to integers and ordering by those integers.

The third clause orders the non-numeric results by the original column value.

And that’s all there is to it. Hope this proves helpful to someone.