John Congdon

So, I had a very strange thing happening only in chrome.  Phoneburner.com has a way for people to record voicemail messages that they want to leave while making phone calls.  On the page that lists them for the members to listen to before using, we do a simple object embed of a small flash player.

This has worked flawlessly for a long time.  All of a sudden, we noticed in Chrome that some would randomly not show.  In this one account, there are about 20 of these embedded flash players and only 3-5 would show up.  The weird part is that if I refreshed, a different mix of 3-5 would show.  Some would disappear, others would appear.

There were no errors in the Developer Console.  I played with the flash plugins and noticed if I disabled both, reloaded the page, and then enabled the plugins all would show up…

Debugging things that don’t make sense is VERY difficult.  So I went to the javascript console and decided to use jQuery to hide them all and then reshow.  Sometimes that worked.  Ok… getting closer, CSS may be the answer.  I then tried just showing, not hiding first.  Most would show, but not always all of them.  But if I ran it a few times, they would eventually all show up.  WTF?!?!??!!

So I added a dirty hack to make it work.

$().ready(function()
{
$(“object”).css(‘display’, ‘inline’);
$(“object”).css(‘display’, ‘inline’);
$(“object”).css(‘display’, ‘inline’);
$(“object”).css(‘display’, ‘inline’);
$(“object”).css(‘display’, ‘inline’);
$(“object”).css(‘display’, ‘inline’);
});

I recently practiced my Tek13 presentation at my SDPHP user group.  What I really like about user groups is the interaction and discussion that often ensues about the given topic.  At the time, one of the members asked me about trying to outdo your adversary with what amounts to “Security by obscurity”.  He was asking about MD5 hashing multiple times to throw off an attacker.  My response was not a good enough reason, but it was the best I had at the time, which was “it’s not a good idea, it won’t do you any good.”

After thinking about it, I have a good reason why now.  I will try to put it into words here.

First, security algorithms are all about best practices and trusting the experts.  Meaning, everything we use today is open source and has been tested by the brightest. Encryption algorithms are very hard to understand, so we shouldn’t try to do it ourselves.

Now for the real explanation.  Hashing just gives us a value, also called a digest.  At the end of the day, at least when it comes to passwords, attackers just want access to the system, not necessarily the password.  Sure, they would love to have that as well, but it’s not necessary.  Attackers can also rely on hashing collisions to give them access.  Let me try to demonstrate.

A hash collision is when two different strings give you the same digest.  So trying to secure your passwords by obscuring the method used, doesn’t really help you here.  All I need to do is find any string that when hashed gives me the proper value.

In the end, follow best practices and use bcrypt now.  Don’t try to make md5 or sha1 work for you in this scenario.  Trust the experts… rolling your own is a bad idea in this area.

I just left Chicago after attending my favorite conference, php|tek.  This is an event that has become near and dear to me, and I am so grateful that the musketeers have stepped in to make sure that it continues running.

I first attended back it 2010, and have continued to grow ever since then.  When I say grow, most people will immediately assume that I have become a better developer, and while that is true, I have grown in more important ways.  I have become less introvert (notice I did not say that I have become an extrovert).  But I have learned to not shy away nearly as much.  I have grown to respect myself enough to know that I am more than I think I am.

In 2010, I decided that I wanted to speak at a conference one day.  I feel I did it the right way by starting off with my local user group.  I didn’t jump right in and try to tackle a conference.  Starting with the user group gives you a great intermediary step.  You probably know many of the members in the group, and it is usually smaller than a conference.

I was privileged enough to give two presentations this year at tek.  My first one, which I felt more prepared for was a little shaky, and I knew it.  :(  I did not take any offense to some of the criticism that I received.  I blame it partially on being the first time I have used a mic, and hearing yourself and knowing that I did not want to over modulate, I tended to speak more monitonely.  I am upset with that fact… I also tended to go through my slides faster than I should have.  I just needed to take more deep breaths and slow myself down.  Overall, I am pleased with the results, and on a scale of 1 (I passed out) to 10 (I knocked it out of the park), I would give myself a 5.1.  I know there is a ton of room for improvement in my public speaking, and I will do that.

My second talk was much better for the most part.  I did no use a mic this time, as the room and number of people were much smaller.  I am very happy that Beth Tucker-Long, joined in for a couple of reasons.  She was the only one to tell me that I needed to speak up.  It’s very easy to start off talking strong and projecting, only to end up trailing off into a conversational voice.  My overall energy level during this talk was much better, and I felt like I was having a conversation.  I hope I was less monotone, and better paced.  What I really like about presenting is the ability to have a conversation with the entire group where I get to learn as much as I may have taught.  If there is one thing I know, it’s that everyone has something to share.  Just because you go to a class to learn, there is probably something you know that can help the entire class (including the teacher).

I set some of my personal goals down on paper last year, and at this point have realized almost all of them.  I have been published in a PHP magazine (twice I may add), I have lost a bunch of weight (2 pounds to reach the goal I set), I spoke at a conference, among others.  Time to break out the pen and write some more down.  Beth and I discussed this and she mentioned maybe adding “book author” to the list…  Intriguing.

Thank you Musketeers.

One of the greatest lessons I have learned over the last few years was to “Learn to know what I don’t know”.

This seems like an impossibility on the surface, but digging into the details I found that it didn’t mean to learn everything at once.  The important piece is to know what is out there in general.  It’s important to immerse yourself in your community and keep your ears open.  Listen to what people are talking about, so that in the future, those little snippets may help you.

I’ve attended many user group presentations, and while I don’t always get it completely, afterwards I at least have a clue.  I attended a presentation about Continuous Integration once.  The presentation was over my head at the time, and I wasn’t in a place to put that topic into practice.  A few months later, I knew I was ready to make a change and I remembered the basic principles of continuous integration.  Because I knew about it, I was able to do the research to truly learn about it and put it into practice.

Without having heard that presentation, I may still have been in the dark and would not have been able to implement that simple piece of tech.

At SDPHP we are starting an open source project (grouptopics) for user groups, but that is for another post.

We are setting up oAuth authentication with Google, Twitter, and Facebook.  While doing so, the developer that did the initial integration stopped with the Twitter integration because they do not give you an email address, and he is steadfast that an email address should be required for a user.

I have thought a lot about this lately, and I am of the personal belief that an email address is not required.  While I would like to have one for communication, the main goal is authentication.  Having the email address does nothing to accomplish this authentication, it just serves our greedy desire to send emails that are probably unwanted.

I have not given any final direction towards the group.  What are your thoughts?  Do I listen to him and require it, or go with my gut and say that it shouldn’t be required?

Just had a strange query happen that I thought I would share.  I am by no means a Mysql expert, I know enough to usually write decent queries that are performant.

I had one today that was baffling me.  First, I know this should be extracted into reusable code, but right now that’s not the plan.  In one part of our system a query was happening pretty quickly.  In a new part that I am working on it was taking forever, to the point I had to kill the query (after 30+ seconds) so that it didn’t bring the entire system down.

I was trying everything to figure out why one was worse than the other.  They both seemed like terrible queries from first sight.  I rearranged the WHERE clause so that they matched, and that didn’t fix the problem.

The good query had: ORDER BY dateadded desc, id

The bad query had: ORDER BY dateadded desc

I guess that is something to try when you have non performant queries.  There was a subquery happening as well, so I think the order by may be helping the subquery.

It was just interesting to me and I thought I would share.

To me this is HUGE news in the PHP World.

If you are in the PHP community and don’t know PHP|A, then you have been missing out.  I learned about them when I decided I HAD to grow and improve my skillset.  I was a sole developer that was stuck.  I wanted to be better, but to do so, you have to work with better people than you are.  So I set out a goal of learning things, and luckily enough I kind of knew what I was looking to learn.  Part of my whole speech about needing to know what you don’t know.

PHP|A offers a magazine (used to be in print, maybe again soon?), books, trainings, and conferences.  The conferences are what first drew me in.  I attended TEK-X, back in May of 2010 and thus start of the new me.  Within 2 years, I completely transformed myself for the better, and made some huge life changing decisions.

I met all of the members of Musketeers.me while on my new quest.  I met @EliW first at Tek-X, and while he won’t remember it, I certainly do.  I got to hang out with a large group of people in his room playing Rock Band until late in the night.  I was very shy that year, and stayed to myself.  I met the rest of the team (@omerida, @SandyS1, and @kevinbruce) this year at Tek12.  I talked with them way more than I thought I would have, and it was a great experience.

The Musketeers were the team behind MojoLive.com, until funding ran out and the backers pulled the plug.  At least this is how I interpreted the story.  They decided they liked working together and formed a new company called Musketeers.met.

This is a great story for potential PHP startups.  I am looking forward to what comes of all of the changes at PHP|A.  Will the conferences continue?  If so, will they be as good as they were, or better?  Congratulations GUYS!!!

Developers often inherit legacy codebases, and sometimes those codebases do not have version control. How do we maage that?

I recently joined a team, and while they tried to have some good practices in place, it really was a mess.  Luckily they know that, so I am not saying something they don’t already know.  ;-)

They had 4 production servers and 1 development server.  So when I started, I thought that was a great setup.  They had SVN in place, and while I am a Git guy, I figured I could pick up SVN just fine.  After starting, I learned that they didn’t use SVN very well, and that much of the code was not in sync.

I wanted to get rid of SVN and introduce git into the mix.  My boss was very open to the idea, and surprisingly, so was the rest of the team.  There was a HUGE issue though.  So many changes have been made in production, so there could actually be 5 different versions of the same file across all of the machines.  And not just different versions, but completely different functionality within said file.

Because of these facts, my boss was hesitant about my desire to use git.  I convinced him that I would take it slow, and I laid the plan out in front of him.  Because of my slow and methodical approach, he gave me the approval to move forward.  You don’t have to add all of your code into a version control system all at once.  Start slowly with a well laid out plan.  And I don’t mean that you have to know every file in your codebase and the order you want to add them.  My plan was to start with the files we were currently working on.

Our steps when we needed to change a file:

1. Copy all 5 versions to the dev server.  Creating different file names of course, these will just be temporary files.
2. Use some process to figure out the differences between the files.
1. vimdiff is a great tool for this.  It can help you merge up to 4 files at once.
3. The goal is to get a single files that could be in 5 different states into a uniform version that should work properly on all 5 systems.
4. Remove the temporary files
5. Add the newly merged version into git
6. The key now is to keep a backup of the various version “Just in case” and get the newly merged code into production.
7. Lather, Rinse, Repeat

The process is still not complete for us.  However, we are in a MUCH MUCH MUCH better position then we were a few months ago.  I can make changes and test in development, and deploy most of our code fairly easily.

The fact that a company that just hired me, had that much trust in me to completely change their workflow, was pretty impressive as well.

Being the organizer of SD PHP has been one of the most fulfilling experiences I have had yet. It has gone above and beyond anything I thought it would mean to me.

I have met some great people, and have learned more about what makes the PHP community so great.

So, we finally put a website up. It’s nothing great right now. It’s just your basic WordPress site, but it will at least give us a place to start putting some content. As always, I am very open to feedback and criticism (of the constructive kind).

I just got “Master Your Mac: Simple Ways to Tweak, Customize, and Secure OS X” yesterday and am amazed with the amount of material covered in it.

It’s almost 400 pages of great material that is useful for everyone from newbies to veterans. It contains simple shortcuts, using the new features of Mountain Lion, using the hardware, configuring the software, and even shows useful third party applications (many of which are free).

My favorite section so far is simply a Bluetooth Proximity Monitor. This chapter tells you how to setup your mac so that if you walk away from it with a connected bluetooth device, it can automatically run whatever tasks you want. For example, pause iTunes, set your away status in your chat app, and even lock the screen. And then it can do the opposite when you get back with the Bluetooth device.

With 38 chapters of information, there will be something for everyone. I highly recommend this book if you have a Mac.