For a while, I’ve been looking at plugin systems, but not really fully understanding the pattern behind them. Don’t get me wrong, I see how they work, but I didn’t know the reason why - the theory or pattern behind it. Well turns out, generally, they’re based upon the observer pattern. I decided to write my own observer pattern demonstration here.
Can it be done? YES! Luckily, functions like file_get_contents() support stream contexts.
I’ve been to far more meetings than any one on earth should ever have had to by the time they’re 25. With that experience, however, I can start to pick out key points of running a great meeting or demonstration. I know this is a different type of post for this blog, but I think its important. There may be times that you’re called on to conduct a meeting or demonstration, as a technical resource. Follow these tips and your meeting will go along smooth, efficiently and successfully.
One thing I remember being pounded into my head is to not create CSS classes after their physical attributes. So, for example, if your error text is red, do not call the class red. Instead, be more descriptive of the content.
The predefined PHP constant DIRECTORY_SEPARATOR is useless.
So, the other day, I saw a horrible thing. I saw two PHP associative arrays that needed to be combined into one, and the worst example of NOT using PHP’s built in functions to combine them. They weren’t using array_merge - instead they were looping through each value.
When working at “the triangle” we used junction points on windows to link to repositories that we needed to run the code base - but weren’t necessary for the project. (see creating junction points on windows with linkd.exe.)