{5} Setfive - Talking to the World - Page 42 of 66 - Ramblings on code, startups, and everything in between

A few days ago I ran across 2012: A Year in PHP which is a blog post highlighting what changed in PHP during 2012 and what upcoming changes we can expect in 2013. The post sparked a lively discussion on Hacker News which unfortunately basically devolved into a mix of anti-PHP rants and some “meta” commentary. Anyway, as someone that uses PHP daily I started thinking about what irks me about PHP and what would fix it. Thinking through the issues, it feels like fixing PHP’s type system by making primitives real objects would significantly improve the readability, consistency, and attractiveness of the language.

If strings were real objects…

This one is subjective but I think one of the reasons that PHP code looks so ugly is because the procedural array_* and str* functions look jarring mixed in with object oriented code.

Check out this snippet from the Doctrine ORM framework. Even though the code is “object oriented” and nicely spaced, the array_* and str* functions are a serious eye sore. In addition to looking “off”, the procedural functions have inconsistent argument ordering which leads to “needle or haystack?” bugs.

So what would I switch to? How about a fluent interface replacement for the array and string functions that operate as if they were real objects.

If arrays were real objects…

PHP arrays are in a funny place in terms of how they interact with the standard library and the syntax of PHP. Arrays in PHP are a primitive type and they are arguably the de-facto data structure for most PHP applications. Like strings though, arrays aren’t objects so programmers are stuck using the procedural array_* functions to manipulate arrays. Similar to above, if they were actually objects we could do away with the procedural functions and manipulate arrays with object oriented style functions.

Another array related issue is “foreach hell”, a situation where the easiest way to accomplish a few array related tasks is to run a “for each” over the list which then leaves the code with a tangled mess of collection variables and for each loops of varying lengths. PHP has array_* functions to mitigate this but it wasn’t until the proper introduction of closures and anonymous functions that they became practical to use. Unfortunately, since arrays aren’t objects you can’t really chain any of the functions and the code ends up looking as bad if not worse. If arrays were actually objects, PHP code could easily adopt functional techniques like Javascript’s UnderscoreJS which are usually cleaner and easier to follow.

Compounding the “foreach” issues is the existence of the Iterator interface which allows PHP classes to specifcy that they can be traversed using a foreach loop. This introduces a frustrating limitation in the sense that you can make an object “look” like an array but since the array_* functions only operate on the primitive array type, you can’t leverage any of them on iterable objects. If arrays were actually objects, additional interfaces could be specified to allow some subset of the array_* functions to work on a given class.

In true PHP fashion, arrays as objects actually “sort of” exist within the Standard PHP Library (SPL) Datastructures extension. The SplFixedArray provides a fixed length, integer only array data structure that is actually a PHP object. The problem is you can’t easily just “switch” between using an array versus one of the SPL data structures since they aren’t subsets or supersets of regular primitive arrays, they are PHP classes making them difficult to convert between.

If objects were real objects…

Unlike Java or Javascript, PHP objects don’t all “share” or extend from a common ancestor. In Java, every object extends the Object class and in Javascript every object is connected in the Prototpe chain to the Object prototype. What this shared inheritance fosters is that generic programming is significantly easier because introspection and reflection is more straightforward. Comparatively, check out PHP’s Reflection class to see how much of a disaster introspection and reflection in PHP.

Could it happen?

Unfortunately, I don’t know anything about how primitives PHP types work internally so I can’t speak to how difficult it would be to implement these changes. From a compatibility standpoint, it would naively seem like these changes could be made without seriously breaking backwards compatibility while slowly phasing out the old primitive types. On the whole, as long as we don’t end up with Java’s type boxing issues I think we’ll be in a much better place with PHP as a language.

Earlier today, I was adding a “slider” UI element to a project that was using Twitter Bootstrap as well as jQuery UI. Although they weren’t designed to work together, the two projects generally stay out of each other’s way since their CSS classes are namespaced pretty well.

Since jQuery UI was already loaded I naturally decided to just use the jQuery UI slider control to power the slider. One of the limitations with the jQuery UI slider is that it has no native way to show the current slider value over the slider handle, as a developer you have to display that number somewhere. Fortunately, the control has the event hooks neccesary to make this happen – specifically the slide event which is triggered everytime the slider is moved.

With Bootstrap also loaded, I decided to try and use the tooltip plugin to dynamically display the current value of the slider above the handle. Getting the initual tooltip setup was pretty straightforward. Check it out here.

But the issue is that even with the “slide” event, the Bootstrap tooltip plugin has no exposed method to force a reposition. The only way to get a tooltip to reposition itself is to hide it and then show it again. Obviously, that’s less than ideal since you get a noticible “jump” as the tooltip is hid and then shown again.

With this issue in mind, I decided to take a look at how the Tooltip plugin actually does the positioning. It turns out it’s really simple, the relevant code is on GitHub. Ok, so its easy to reposition them but how do you get the “right” tooltip div incase you have multiple sliders? Looking through the code, the Tooltip plugin actually uses the jQuery.data() function to store config options and additionally stores a reference to the correct div there. Getting a handle to the correct div is as easy as $(“#slider .ui-slider-handle:first”).data(“tooltip”).$tip

Looking at the actual plugin code, it’s simple enough to just copy that out and use it to reposition the tooltips. Check it out in action at http://jsfiddle.net/cqVPM/7/

Anyway, let me know if you run into any issues in the comments.

With 2012 wrapping up, I thought it would be fun to make some predictions for 2013. I’m normally not a huge fan of these lists since they are usually a bit dull so I’ll try and make this one a bit scandalous. So here we go, looking at startups, technology, and a bit of everything else.

Series A Crunch

It’s over hyped but still probably worth mentioning. There was a huge uptick in angel activity in the last few years and as a result there’s a glut of start-ups looking to raise a Series A round. Unfortunately, there won’t be enough Series A deals to be had and with the general cooling in the consumer web sector VCs aren’t jumping for ways to make them happen. The net result of this situation will probably be a an increased number of “zombie” start-ups, aqui-hires, and obviously deadpooled companies. Fred Destin from Atlas has a full post discussing this, Series A Crunch, Seed Blues.

Breakout Health Company

The health and wellness vertical has been heating up for a couple of years, but we still haven’t seen a company have their “mint.com” moment in the space. I think we’ll see one in 2013 because of a combination of the penetration of smartphones and tablets, growing popularity of health data interoperability, and the federal mandate that electronic medical record keeping be implemented across the board. Deep pocketed companies like athenahealth have also hinted that they’d be open to acquiring startups in this space which should up the ante.

Meta Cloud APIs

Looking back at 2012, it could be affectionately nicknamed the “year of the outage”. Several providers were hit by downtime, but the Amazon Web Services disruptions were arguably more serious and frequent than they had been in the past. For some companies, the AWS issues highlighted the fact that relying on a single cloud provider was too risky given the potential of extended downtimes, even across regions. I think because of this, in 2013 we’ll start seeing services that make it easy to provision and configure identical environments at multiple cloud providers. This would essentially allow you to have live instances running on AWS but then have an identical setup running at Rackspace. The foundations for something like this already exist in the jclouds library.

One JS MV* To Rule Them All

There’s been an explosion in the number of Javascript MV* libraries in the last couple of years. Libraries like BackboneJS, AngularJS, and KnockoutJS are all meeting similar needs for the same group of developers. I think in 2013 we’ll see at least some consolidation in the number of libraries and maybe even the emergence of a clear favorite. Hopefully this will lead to some clear patterns for Javascript MVC development just like the paradigms used by backend frameworks like Rails or Symfony.

Google Releases a Play API

Its a bit surprising that in 2012 mobile app discovery is still a disaster. Google Now can automagically tell me my flight is delayed but Google Play can’t seem to offer up even the basic recommendations. What’s even more surprising is that there isn’t an official Google Play or iTunes app store API. It’s also a bit odd that even if I “sign in” with a Google Account on a site, I can’t automatically download apps to my phone from their site. I think Google is going to change this in 2013 and open up a wave of innovation around mobile app discovery and monetization. This should shake up the app store distribution problem and also reduce the friction to convert a web user to a mobile app one.

Second Screen Showdown

With the rising popularity of tablets, the second screen TV experience will become increasingly popular in 2013. You’ll be able to download network (Showtime, HBO, NFL, etc.) branded apps which will display enhanced content as you’re watching your favorite show or team. Look for networks will use this to boost engagement and drive revenues through sales of content related items.

Anyway, these are all a bit off the cuff but I’d love to discuss in the comments.

D3 is a “newish” visualization library that has been getting a lot of attention recently. The New York Times has been using it extensively to create visualizations, and in fact its creator is currently employed by the NYT. I’d been meaning to take D3 for a spin for a while but couldn’t find a dataset I wanted to play with until a few weeks ago.

At the end of November, the LA Times published a dataset titled Capital appreciation bonds which highlighted how various California school districts were funding various projects with extremely high interest rate bonds. The LA Times described the data as:

Hundreds of California school and community college districts have financed construction projects with capital appreciation bonds that push repayment far into the future and ultimately cost many times what the district borrowed. Government finance experts consider bonds imprudent if the total cost is more than four times the money borrowed or the maturity period is greater than 25 years.

Anyway, you can check out my attempt at a visualization here.

Last week, one of our projects hit a pretty odd limit that I’d never expected to reach. The project is an analytics platform that allows admins to “pull” data from another, third party application. To accomplish this, the application allows admin users to dynamically add and remove columns from SQL tables and then dynamically chart these columns. Because of this, one of the tables had gotten over 350 columns which had all been created dynamically at runtime.

Anyway, things were working fine until last week when the application started throwing the following fatal error: “Fatal error: Uncaught exception ‘Doctrine_Table_Exception’ with message ‘Invalid expression found: ‘ in /usr/share/php/symfony/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Table.php:2746″ Looking at the error, I noticed a warning was actually getting thrown right before the fatal error: “Warning: preg_replace(): Compilation failed: regular expression is too large at offset 32594 in /usr/share/php/symfony/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Table.php on line 2745″ Looking through the code of Table.php, its clear that because “preg_replace” fails the $expression is subsequently blank which causes Doctrine to throw an error. I wanted to see how bad the regex was so I updated the Table.php to dump the expression. Here is what Doctrine was trying to run:

/(lsc_calculated_promoterscore_delta_innovativeness_formula|Lsc_calculated_promoterscore_delta_innovativeness_formula|lsc_calculated_promoterscore_delta_innovativeness_order|lsc_calculated_promoterscore_delta_favorability_formula|Lsc_calculated_promoterscore_delta_favorability_formula|Lsc_calculated_promoterscore_delta_innovativeness_order|Lsc_calculated_promoterscore_delta_favorability_order|

[Lots of columns...]

|Grid_mac_total|GridTotalTotal|GridTotalWinpc|Grid_total_mac|GridWindowsMac|grid_both_mac|grid_mac_ipad|audience_type|GridBothWinpc|GridBothTotal|Grid_both_mac|GridTotalIpad|Audience_type|WindowsosFy13|Grid_mac_ipad|grid_mac_mac|Grid_mac_mac|Program_type|program_type|AudienceType|GridMacTotal|GridBothIpad|GridTotalMac|GridMacWinpc|venue_child|ProgramType|GridMacIpad|Venue_child|GridBothMac|Program_id|program_id|VenueChild|GridMacMac|Fiscalyear|fiscalyear|is_locked|Is_locked|ProgramId|IsLocked|Country|country|venue|Venue|os|OS|id|Os|Id)(Or|And)?/

Looking at the php.net documentation for preg_replace and preg_match neither actually mention a hard limit on the size of a regex that can be compiled. Obviously there is a limit though and I imagine it must depend on the underlying RegExp library that your PHP is compiled against so it might be platform dependent.

As for solutions for this problem? The best solution for an extreme case like this is probably to just manually fill those in with real methods in the Doctrine_Table classes:

PHP: What if primitive types were objects?