Tales of an IT Nobody

devbox:~$ iptables -A OUTPUT -j DROP

PHP Interface rant June 15, 2015

This isn’t my first rant about interfaces (which are finally receiving a due adjustment).

I haven’t tested it, but don’t believe I’ve seen anything pertaining to interface inheritance, look at the following use case for example, which fails in current PHP 5.6:

There are some benefits to doing this, however as you can be implicit with the interface while supporting explicit behavior in other areas.

No Comments on PHP Interface rant
Categories: php rant

Laravel/Lumen vs Symfony/Silex a corporate perspective May 30, 2015

YAPFC. Yet Another PHP Framework Comparison. I’m judging Silex and Lumen through their bigger brothers, Symfony 2 and Laravel 5.

After doing some extensive research, re-evaluating the PHP framework atmosphere, two frameworks and their respective “mini-me” counterparts seem to rule the seas.

In this post I’m simply sharing my opinion of Laravel and Symfony and their lighter-weight counterparts: Lumen and Silex. Drawing from my 15 years as a PHP developer, 10 as a professional (aka: full time employed) I am drawing from my perspective as a small business owner who does contract work and a government employee.

The winner is (for this developer): Symfony / Silex.

Let’s just start: I’m resting my laurels on Silex. (and Symfony).

As a business owner, it’s my job to choose  the best balance between productivity and production for my clients. As leader of a development team, my concerns are pretty much the same, but I have to answer for more than being my own boss on the side. These are my points as to why I feel confident saying this (right now).

Quick note: Laravel is a very nice framework – if LTS was offered and there was a demonstrated history of design stability, my vote would be different.

1. Longevity.

Symfony offers LTS (long term support) for it’s versions, it’s corporation backed and has THE following of experienced developers doing their thing. This is extremely important to know, because that means the rug won’t be pulled out from under you from version to version. There’s a highly structured process in place for dealing with upgrades and notifying of BC breaks. Silex absolutely benefits from this.

Laravel on the other hand is more of a one-man show than Symfony. In my travels, I examined the version history of Laravel and Symfony, and I found that Laravel was simply too volatile for adopting into the environments that I work in. For lack of a better phrase, cutting edge in Laravel at times have clobbered those who chose to jump in with both feet at a more frequent cycle than Symfony. Lumen will have the same woes.

(Re-read that: at a more frequent cycle, PROGRESS has a cost – but there needs to be a methodical approach for enterprise environments to feel comfortable).

Not quite ready

Not quite ready (http://www.reddit.com/r/PHP/comments/1eld2t/why_would_anyone_choose_laravel_over_symfony_or/)

2. Opinionated

Lumen is easy to set up – because it’s opinionated. Opinions in my world mean you’re harder to “slip stream” into a code base refactor. Can you gut it and make it your own? Yes. But that’s just as much work as starting with something without an opinion, right?

Silex is barely opinionated. Almost no training wheels, which makes it more hostile for inexperienced developers.

That’s it!

Really, those are the things that rub me the wrong way. I think Laravel/Lumen have a lower learning curve (due to opinion) and you truly can get off the ground faster with Lumen in my opinion. However, these frameworks largely do the same thing.

This is a somewhat painful decision

I honestly like Laravel/Lumen a bit better in regards to learning them quickly. Laracasts are a true contribution to the community – not just bettering the cause of Laravel.

I think in a few years, Laravel will become the big kid on the block that it deserves to be – but right now there’s too many warning flags going off regarding API stability and decision making.

Somewhat painful?

Yes! Laravel and lumen ship with Eloquent out of the box. It uses the active record paradigm and AR can’t hold a candle to a data mapper pattern in terms of protecting yourself from your dependencies.

This really rubbed me the wrong way because it’s like giving a loaded gun to an inexperienced developer (or team). I expected a better ORM architecture for a framework for artisans.

I realize I can ignore it, and use Doctrine – but really, they should not have coupled an ORM from the get go. It’s a “crack factor” for the framework in my opinion.

2 Comments on Laravel/Lumen vs Symfony/Silex a corporate perspective
Categories: php programming

A PHP bug – really? (custom session handlers) April 18, 2015

It’s not often I ramble about PHP, since it’s my bread and butter. But after perusing the RFC notes to get up to speed on the PHP 7 pipeline, I found this: https://wiki.php.net/rfc/session.user.return-value

That bug has been around for how long? I’m amazed folks with pitchforks haven’t come out on that one sooner. I myself have suffered great pains dealing custom session handlers for this exact bug. Shame shame! (At least it’s getting fixed)

/rant

No Comments on A PHP bug – really? (custom session handlers)
Categories: php programming rant

PHP 7 Roundup – implicit ‘array to string’ conversion April 15, 2015

Feast your eyes upon this: https://wiki.php.net/rfc/array-to-string

If you’ve been in the trenches for a long time, chances are you’ve been bitten more than enough by the implicit array to string conversion as such:

It will now look like this in PHP 7:  Catchable fatal error: Array to string conversion

 

 

No Comments on PHP 7 Roundup – implicit ‘array to string’ conversion
Categories: php programming

PHP 7 Roundup: Chainable ternary awesomeness. April 12, 2015

Feast your eyes on this: https://wiki.php.net/rfc/isset_ternary

This eliminates quite a bit of ‘noise’ and ‘fluff’ use in any display logic, it’s a new ternary operator that allows you to quickly set a default without doing the isset() dance.

This has a limited affect if you use a templating engine like Twig, but it’s still very nice if you have to do some quick and dirty default setting at the code level for display.

 

No Comments on PHP 7 Roundup: Chainable ternary awesomeness.
Categories: php programming

How to use PHPUnit installed by composer in PHPStorm April 5, 2015

Ever wonder how to properly use those packages installed from the require-dev section of composer.json?

Ideally you’d integrate them with your IDE, or perhaps set up your system path to access it via vendor\bin\phpunit – If you use PHPUnit, take a quick look at this on how to properly set up PHPUnit in PHPStorm on a per-project basis (because not all projects use the same PHPUnit version).;

No Comments on How to use PHPUnit installed by composer in PHPStorm

PHP 7 Roundup: RETURN TYPES! March 27, 2015

Many years ago (in 2011) I wrote “interfaces are worthless“. For the most part they have remained mostly worthless for me as typically a superclass of sorts has proven to be a better solution for taxonomy and enforcing the exact typing rules I have criticized interfaces in PHP for in the past.

Feast your eyes on this: https://wiki.php.net/rfc/scalar_type_hints_v5  – not enough for you? ok, how about THIS! https://wiki.php.net/rfc/return_types

PHP 7 is shaping up to be a pretty awesome release. FINALLY. RETURN TYPES. INTERFACES. JOY.

No Comments on PHP 7 Roundup: RETURN TYPES!
Categories: php programming rant

Composer and getting to vendor/bin March 22, 2015

Want to stop typing ‘vendor\bin\toolname’ to access tools like PHPUnit, phpcs, etc when installed through composer?

It’s a simple process really – merely add “vendor\bin” into your PATH variable and profit! (as long as you’re running the command from the project root).

No Comments on Composer and getting to vendor/bin
Categories: php programming tools

PHPCS custom standards and PHPStorm integration March 9, 2015

At about 6 minutes long, I threw together this screencast to show a method to involve your custom PHP CodeSniffer standards into your project workflow when using Composer. Essentially it covers the convenience of putting your standards into a Composer package and adding a wrapper to ‘extend’ the PHPCS shell/batch script to automatically detect your custom standards without having to install them system-wide in your development environment. *Best viewed in full screen*

No Comments on PHPCS custom standards and PHPStorm integration
Categories: php programming tools

Using Logstash to log SMTP/email bounces like a boss July 26, 2013

I’ve recently worked on a customized emailing suite for a client that involves bulk email (shutter) and thought I’d do a write up on a few things that I thought were slick.

Originally we decided to use AWS SES but were quickly kicked off of the service because my client doesn’t have clean enough email lists (a story for another day on that).

The requirement from the email suite was pretty much the same as what you’d expect from SendGrid except the solution was a bit more catered toward my client. Dare I say I came up with an AWESOME way of dealing with creating templates? Trade secret.

Anyways – when the dust settled after the initial trials of the system and we were without a way to deliver bulk emails and track the SMTP/email bounces. After scouring for pre-canned solutions there wasn’t a whole lot to pick from. There were some convoluted modifications for postfix and other knick knacks that didn’t lend well to tracking the bounces effectively (or implementable in a sane amount of time).

 

Getting at the bounces…

At this point in the game, knowing what bounced can come from only one place: the maillog from postfix. Postfix is kind enough to record the Delivery Status Notification (‘DSN’) in an easily parsable way.

 

Pairing a bounce with database entries…

The application architecture called for very atomic analytics. So every email that’s sent is recorded in a database with a generated ID. This ID links click events and open reports on a per-email basis (run of the mill email tracking).  To make the log entries sent from the application distinguishable, I changed the message-id header to the generated SHA1 ID – this lets me pick out which message ID’s are from the application, and which ones are from other sources in the log.

There’s one big problem though:

Postfix uses it’s own queue ID’s to track emails – this is that first 10 hex digits of the log entry. So we have to perform a lookup as such:

  1. Deterimine the queue ID from the application generated message-id log entry
  2. Find the queue ID log entry that contains the DSN

 

(Those of you know where this is going – skip this next paragraph).

This is a problem because we can’t do two at the same time. The time when a DSN comes in is variable – this would lead to a LOT of grepping and file processing – one to get the queue ID. Another to find the DSN – if it’s been recorded yet.

 

The plan…

The plan is as follows with the above in mind:

  • Continuously trail the log file
  • Any entries matching message-id=<hash regex> – RECORD: messageId, queueId to a database table(‘holding tank’).
  • Any entries with a DSN – RECORD: queueId, dsn to holding tank table
  • Periodically run a script that will:
    • Process all rows that have a DSN and messageId that is NOT NULL. (This will give us all messages that were sent from our application that have DSN’s recording)
    • Delete all rows that do NOT match that criteria AND are older than 30 days old (they’re a lost cause and hogging up space in the table).

Our database table looks like this:

Making the plan stupid simple, enter: Logstash

We use Logstash where I work for log delivery from our web applications. In my experience with Logstash I learned that it is a tool with so much potential for what I was looking for. Progressive tailing of logs and so many built in inputs, outputs and filters for this kind of work it was a no brainer.

So I set up Logstash and three stupid-simple scripts to implement the plan.

Hopefully this is self explanatory to what the scripts take for input – and where they’re putting that input (see holding tank table above)

Setting up logstash, logical flow:

Logstash has a handy notion of ‘tags’ – where you can have the system’s elements (input, output, filter) enact on data fragments tagged when they match a criteria.

So I created the following configuration logic:

Input:
/path/to/maillog

Tags:

  • bounce – matches log entries containing a status of ‘bounced’ – (not interested in success or defer)
  • send – matches log enries matching the message-id regex for the application generated ID format

Output:

  • EXEC: LogDSN.php – for ‘bounce’ tags only
  • EXEC: LogOutbound.php – for ‘send’ tags only 

 

Full config file (it’s up to you to look at the logstash docs to determine what directives like grep, kv and grok are doing)

 

Then the third component – the result recorder runs on a cron schedule and simply queries records where the message ID and DSN are not null. The mere presence of the message ID indicates the email was sent from the application. the DSN means there’s something to enact on by the result recorder script.

 

Simple overview

* The way I implemented this would change depending on the scale – but for this particular environment, executing scripts instead of putting things into an AMQP channel or the likes was acceptable. 

1 Comment on Using Logstash to log SMTP/email bounces like a boss

PHP 5.5 RC1 released – what I’m most excited for.. May 9, 2013

Where I work we have unfortunately had to skip the 5.4 release of PHP; the release cycle between PHP 5.4 and PHP 5.5 was pretty darn fast and we never got around to replacing APC. We’ve finally got everything up to speed to adopt 5.5 when it hit’s stable release.

I figured I’d fill in some of the blank air by listing (even if a personal memo for myself) the things I find most exciting for the upcoming PHP 5.5 release.

In no particular order:

      • finally{} support (As in try-catch-finally)
      • HUGE myriad of new CURL support –  these intrigue me the most:
        • CURLOPT_SSH_KNOWNHOSTS
        • CURLOPT_DNS_SERVERS
        • CURLOPT_USE_SSL
        • CURLOPT_LOCALPORT
        • CURLOPT_LOCALPORTRANGE
        • CURLOPT_TCP_KEEPALIVE
        • CURLOPT_ACCEPTTIMEOUT_MS
        • CURLOPT_SSL_OPTIONS
      • Array dereferencing
      • Built in opcode cache and optimizer (Zend optimizer plus) (This is a biggie since APC never saw light of day in PHP 5.4, I suspect many are in the same position as we are with APC…
      • array_column()

Observation, or a gripe/complaint/whatever:

I’m not quite sure about the password_hash ‘suite’ functionality – it’s not clear what’s finally made it in, I’d assume everything? People that don’t understand hashing and encryption are probably going to be confused a bit more than they were before unless this addition is advocated heavily in the documentation for counterparts (e.g.: the md5 documentation page).

I understand that trivializing the process is beneficial to avoid self inflicted damage, however I always get a tad annoyed when we see things labled as ‘STRONG ENCRYPTION’ since that term is a moving target; I long to see better implementations and standards recognition, e.g.: a FIPS level .

Honorable mention

The generators addition  gets an honorable mention – I think it will take some time to trend and the scenarios for use case are probably fairly low to save time on writing your own iterators.

 

2 Comments on PHP 5.5 RC1 released – what I’m most excited for..
Categories: php programming

A safer approach to using Monolog’s SocketHandler April 3, 2013

Monolog is perhaps the most popular logging library out there for PHP at the time of this writing. It has a lot of support and a nice balance of features.

Unfortunately I have one gripe to make about the rather closed implementation of the SocketHandler , er, handler?

 

The problem with the Monolog SocketHandler (as of 1.4.1)

The key problem is that Monolog treats it complete with assumption that say, a TCP port can be connected to. So you can setup your chain of handlers and processors; but with a critical application such as logging, the SocketHandler simply let’s itself into the logger object without testing to see if it can make a TCP connection.

The problem is: there’s no pragmatic way to test if a SocketHandler object can connect; there’s only an isConnected() helper method – but no canConnect() or similar.

 

The solution…

The solution is a bit less pragmatic than I wanted, because the SocketHandler class has it’s key method: connect() as a private method. Thankfully the class has a ‘mock’ method to at least attempt a socket connection and not affect the state of the object. We can use that to probe if the socket can be opened, and add it as a handler to our logger object accordingly.

 

Example

 

Then, you can have a little bit more assurance that you’ll get your logging to go through the handler without a nasty exception…

 

 

 

A final word…

In a high parity environment; the SocketHandler is still not immune to losing connectivity to the target socket. It would sadly, be better practice to make your own logger wrapper to safely handle logging to a file, and the SocketHandler. Perhaps sometime in the future the SocketHandler can be revised to (optionally) suppress itself from connection failures.

No Comments on A safer approach to using Monolog’s SocketHandler
Categories: php programming

PHP: array_merge(array $a, [ array …]); October 9, 2012

Wait, PHP wants to array_merge an array with… itself?

Take another look at this: array_merge(array $a, [ array …]);

If you’re good at reading API’s – you’ll see how … odd this is. Seeing as I just got nipped in the butt by forgetting to have another array to merge into – it’s curious as to why the hell it doesn’t enforce a minimum of two arguments… any guesses? Or should we tack this up as a valid, non-nit-picky pitfall of PHP? Otherwise, what are you merging into? Doesn’t make sense…

No Comments on PHP: array_merge(array $a, [ array …]);
Categories: php programming rant

Zend Studio + PHPUnit upgrade: A faster method May 11, 2012

As a counterpart and refinement of my previous how-to, this update shows how to update the PHPUnit library faster than using the symlink method:

View in HD!

No Comments on Zend Studio + PHPUnit upgrade: A faster method

Mercurial (hg) checkstyle hook, at last! May 7, 2012

As far as I can tell, there’s not much in the lane of check style hooks for Mercurial.

There’s a lot of hits for git and SVN, but not much for Mercurial.

Check it out in my ‘hg-checkstyle-hook‘ bitbucket repo.

I thought I’d share my (imperfect) rendition of a Mercurial checkstyle hook. It’s meant to be setup for a pretxnchangegroup event.

Basically it does this:

  • Find what files have changed from the beginning of the changegroup to the tip
  • Copy those files to a staging directory in /tmp
  • Run PHPCS ( PHP_CodeSniffer, a PHP checkstyle command) on those files specifically
  • Provide a report on any violations resulting in a non 0 exit code.
  • The script should be configurable for any checkstyle command, as long as it takes a space delimited list of files at the end of it’s arguments.
No Comments on Mercurial (hg) checkstyle hook, at last!

PHP’s APC – Don’t back yourself into a corner April 23, 2012

We heavily rely on running multiple instances of code where I work. At any given time several of us have several copies/branches of the site code configured to run from various spots on our development server.

A path we have gone down with APC’s user variable caching is merely one of convenience for the most part. There’s only one resource that comes to mind that requires caching.

At any rate, testing things in a multiple instance environment is prone to collisions. Much to my dismay, I find the APC configuration options lacking:

– Can’t set a global prefix – This could be wildly useful for shared hosts and for our scenario, set a global prefix and transparently prepend.

– Can’t turn entire thing off – You can’t turn APC off via .htaccess/ini_set() (forcing things to draw ‘fresh’ every time)

In a nutshell, start smart by generating a global prefix and being diligent with the prefix for your codebase. (Or, perhaps wrap APC to make this easier). It will pay off someday, I’m just glad we aren’t in too deep to quickly rewire it all.

No Comments on PHP’s APC – Don’t back yourself into a corner
Categories: php programming

Disable PHP 5.4’s built-in web server, while keeping CLI … February 6, 2012

Administrators: Don’t get blind-sided by PHP 5.4’s CLI web server!

I’ve gone over a similar issue like this before regarding the likes of git/hg. While those are developer tools and are less likely to be present on a production machine.

PHP 5.4 is jumping on the bandwagon to include a ‘cute’ little internal server – which is enabled by default.
The ‘everything needs a standalone server’ thing is starting to get on my security nerves feel silly.

It has limited use, and most developers will have limited use for it due to it’s lack of mod_rewrite (and equiv.) behavior … The worse part is: You can’t disable it if you want to keep cli (e.g.: no pear!)
 
Wish I spoke up on the list!

Anywho, here’s a hob-knobbed patch (for PHP 5.4.0RC6) that will change that for you.
(GNU/*nix only!) The patch adds a new configure option ‘–disable-cli-server’.

Download the patch here: patch-php5.4.0RC6-no-cli-server.diff
Place it in the PHP source base directory.

In the future I’ll plan on formalizing this patch and propose it in php.internals when I get a chance to make the windows part of the patch.

References:
https://wiki.php.net/rfc/builtinwebserver
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/sapi/cli/
https://gist.github.com/835698

2 Comments on Disable PHP 5.4’s built-in web server, while keeping CLI …
Categories: linux php security servers

PHP Vulnerability – DJBX33A – Hash table collisions January 14, 2012

Trickling through my RSS feeds this morning was an article with quite the topic “PHP Vulnerability May Halt Millions of Servers“.

In a nutshell: A modest size POST to almost all PHP versions in the wild (Sans 5.3.9+) are in danger of an extremely simple DoS.

The vulnerability exploits the PHP internal hash table function (responsible for managing data structures) – more specifically: the technique used to ‘hash’ (generate a key for the hash table) the key for a key=>value relationship.

Here’s the informative part regarding PHP’s problem in the security advisory for this:

Apache has a built in limit of 8K max request length (that is, maximum size in request URL) by default.
Can the damage from an 8k request (this affects GET) – really cause the mentioned DDoS attack on reasonable hardware?

Additionally – PHP has a limiter on POST data too: max_post_size.
It’s this configuration variable in particular I think should be put in the limelight.

max_post_size is a run-time/htaccess configurable directive that maybe we don’t respect like we should.
Often, administrators (myself included) just tell php.ini to accept a large POST size to allow form based file uploads – It’s not uncommon to see:

– in almost any respectable setup.

Perhaps we should evaluate the underlying effects of this setting; maybe it should be something stupidly low by default (enough to allow a large WYSIWYG CMS article’s HTML and a bit more? 32K?) – and then delegate a higher limit using Apache configuration.

Caveat: these settings are PER DIR meaning:

  • .htaccess use is limited, you can’t set the php_value in a .htaccess with a URL match – you’re stuck using a context sensitive .htaccess (within a dir) or use thedirective – this won’t work for people using front controllers through a single file on their websites/apps.
  • Modifying the actual vhost/host configuration is a sound bet – you can do Location/File matching and set these at will; for situated web apps, this may be a feasible decision to take whitelist or blacklist approach on uploader destinations.

More resources:

  • Here’s the video that thoroughly covers the vulnerability – I’ve shortcut it to their recommended mitigation (outside of polymorphic hashing):
  • A full blown rundown, including proof of concept (USE AT YOUR OWN RISK!)
  • A string of hash collisions targeting DJBX33A for vuln testing (PS: Firefox seems to struggle with this in a GET format, Chrome doesn’t, odd!)
2 Comments on PHP Vulnerability – DJBX33A – Hash table collisions
Categories: php security servers

All of your PHP code is going to look silly! PHP 5.4, here we come! July 22, 2011

No, not as in 5.4 will make you write stupid code. As in it will make all pre-5.4 attempts to maximize re-use through crazy inheritance chains look ridiculous compared to what traits will deliver.

I already have a sense of dread of being a year into PHP traits looking at not-too-old code; how painful it will be to look back at what kind of crap we put up with!

This is going to be awesome, and I for one, welcome our new trait supporting overlords.

Now .. WHERE ARE MY RETURN TYPE HINTS! 

I recently had a discussion with a peer and we pretty much summarized what we wish the stance on types for PHP will become something like this:

PHP is a loosely typed language, as it matures in OOP, it must support more strict typing features (including generics: string, int, float, bool, etc). Emphasis on support, not enforce.

Those who want to leverage the dynamics of loosely typed programming can go for it, there’s a place for everyone here to do what they want.

It’s the hippy thing to do!

P.S.: Here’s a fun conjecture about the php.net domain name and a get-rich-quick scheme!

No Comments on All of your PHP code is going to look silly! PHP 5.4, here we come!
Categories: php programming

Upgrading to PHPUnit 3.5 on Zend Studio June 29, 2011

Here’s a quick clip I made to show those who hankering to have an updated PHPUnit plugin for Zend Studio.

I hope this video is obsoleted soon so others don’t have to endure the annoyance.

View in HD!

1 Comment on Upgrading to PHPUnit 3.5 on Zend Studio