Usability

Get rid of variable variable syntax

 

Uniform Variable Syntax was voted in (almost unanimously) for PHP6 PHP7 and introduces a rare back compatibility break, changing the semantics of expressions like these:

                           // old meaning            // new meaning
1. $$foo['bar']['baz']     ${$foo['bar']['baz']}     ($$foo)['bar']['baz']
2. $foo->$bar['baz']       $foo->{$bar['baz']}       ($foo->$bar)['baz']
3. $foo->$bar['baz']()     $foo->{$bar['baz']}()     ($foo->$bar)['baz']()
4. Foo::$bar['baz']()      Foo::{$bar['baz']}()      (Foo::$bar)['baz']()

IMO the “variable variable” syntax $$name is a readability disaster that we should get rid of. ${$name} is much clearer about what this is (dynamic name lookup) and what it’s doing: $ is the symbol table, and {$name} tells us that we’re finding an entry in it under a key with the value of $name. PHP should deprecate $$name syntax and emit a notice in the next minor version.

It should also deprecate the syntax ->$name and ::$$name. Both are bad news.

Doing so would completely eliminate the first 3 ambiguous expressions above, and the new warning emitted would call out code that would otherwise silently change meaning in PHP6 (one big negative about this RFC).

As for the fourth, Consider these expressions:

A. $foo->prop
B. $foo->prop()
C. $foo->prop['key']()
D. Foo::$prop
E. Foo::$prop()
F. Foo::$prop['key']()

To the chagrin of JavaScript devs, PHP will not let you reference a dynamic property in an execution context, so expression B will try to call a method “prop”, (and fatal if it can’t). For consistency, PHP should fatal on expression E. Currently PHP just does something completely unexpected and insane, looking up a local variable $prop.

Expression C does what you’d expect, accessing the property named “prop”, so expression F should do the same, which is why I think the RFC is a clear step forward at least.

What, when, and how is your IDE telling you?

 

A programmers.stackexchange question basically asks if there’s an ideal frequency to compile your code. Surely not, as it completely depends on what kind of work you’re doing and how much focus you need at any given moment; breaking to ask for feedback is not necessarily a good idea if you’re plan is solid and you’re in the zone.

But a related topic is more interesting to me: What’s the ideal form of automated information flow from IDE to programmer?

IDEs can now potentially compile/lint/run static analysis on your code with every keystroke. I’m reminded of that when writing new Java code in NetBeans. “OMG the method you started writing two seconds ago doesn’t have the correct return type!!!” You don’t say. And I’ve used an IDE that dumped a huge distracting compiler message in the middle of the code due to a simple syntax error that I could’ve easily dealt with a bit later. I vaguely remember one where the feedback interfered with my typing!

So on one side of the spectrum the IDE could be needling you, dragging you out of the zone, but you do want to know about real problems at some point. Maybe the ideal notification model is progressive, starting out very subtle then becoming more obvious as time passes or it becomes clear you’re moving away from that line.

Anyone seen any unique work in this area?

Stepping back to the notion of when to stop and see if your program works, I think the trifecta of dependency injection, sufficiently strong typing, and solid IDE static analysis has really made a huge difference in this for me. Assuming my design makes sense, I find the bugs tend to be caught in the IDE so that programs are more solid by the time I get to the slower—and more disruptive to flow—cycle of manual testing. YMMV!

String Subtypes for Safer Web Programming

 

Valid HTML markup involves several different contexts and escaping rules, yet many APIs give no precise indication of which context their string return values are escaped for, or how strings should be escaped before being passed in (let’s not even get into character encoding). Most programming languages only have a single String type, so there’s a strong urge to document function with @param string and/or @return string and move on to other work, but this is rarely sufficient information.

Look at the documentation for WordPress’s get_the_title:

Returns

(string) 
Post title. …

If the title is Stan "The Man" & Capt. <Awesome>, will & and < be escaped? Will the quotes be escaped? “string” leaves these important questions unanswered. This isn’t meant to slight WordPress’s documentation team (they at least frequently give you example code from which you can guess the escaping model); the problem is endemic to web software.

So for better web security—and developer sanity—I think we need a shared vocabulary of string subtypes which can supply this missing metadata at least via mention or annotation in the documentation (if not via actual types).

Proposed Subtypes and Content Models

A basic set of four might help quite a bit. Each should have its own URL to explain its content model in detail, and how it should be handled:

Unescaped
Arbitrary characters not escaped for HTML in any way, possibly including nulls/control characters. If a string’s subtype is not explicit, for safety it should be assumed to contain this content.
Markup
Well-formed HTML markup matching the serialization of a DocumentFragment
TaglessMarkup
Markup containing no literal less-than sign (U+003C) characters (e.g. for output inside title/textarea elements)
AttrValue
TaglessMarkup containing no literal apostrophe (U+0027) or quotation mark (U+0022) characters, for output as a single/double-quoted attribute value

What would these really give us?

These subtypes cannot make promises about what they contain, but are rather for making explicit what they should contain. It’s still up to developers to correctly handle input, character encoding, filtering, and string operations to fulfill those contracts.

The work left to do is to define how these subtypes should be handled and in what contexts they can be output as-is, and what escaping needs to be applied in other contexts.

Obvious Limitations

For the sake of simplicity, these subtypes shouldn’t attempt to address notions of input filtering or whether a string should be considered “clean”, “tainted”, “unsafe”, etc. A type/annotation convention like this should be used to assist—not replace—experienced developers practicing secure coding methods.

Simpler API for Zend’s built-in Firebug Logger

 

Zend Framework has functionality to send messages to the Firebug console (via Firefox’s FirePHP addon), but if you’re not using the ZF front controller, the API is a bit of a pain. Besides your instance of Zend_Log, you must keep track of a few additional objects just to manually flush the headers after all your logging calls. Since I knew the old FirePHP class didn’t need this follow-up step, I figured I could just flush the headers after each send.

The result is FireLog. On the FireLog instance, calls to methods like log(), info(), warn(), etc. are proxied to an internal Zend_Log instance, while the methods send(), group(), and groupEnd() are proxied to the static methods on Zend_Wildfire_Plugin_FirePhp. In both cases the headers are set immediately using some simple ZF subclassing. Continue reading  

Content Delivery and Format Fail

 

screenshot from Ney Year's DaeThe pic on the right is from The Berrics’ “New Year’s Dae” video. The skating is amazing—well worth a dollar—and the site’s registration and checkout was painless, but the rest has been a disappointment:

  • There’s no way to download this “downloadable part,” as it’s advertised. You must install an Adobe Air application, which downloads the video.
  • There was nothing in the checkout process to let me know I needed to install Air first. The only link to “download instructions” (who would think they need to read this?) was on the “add to cart” page. Once most people have checked out they’ll have to run to Google what an .air file is.
  • The app isn’t digitally signed, so the publisher reads “unknown” and it asks for “unrestricted” access to my system. Does not inspire trust.
  • You can only watch the video via the app! So no fancy controls you might want while, say, watching a skateboarding part.
  • Considering I downloaded 150MB for a 5 minute video, the quality is astoundingly bad. See the horizontal lines in the screenshot? They’re a constant distraction and it all looks even worse at full screen. Every video on the The Berrics site looks better than this. Like most Rodney and Daewon parts, the filming is just not exciting, but it’s forgivable.
  • Since I downloaded it on my wife’s PC last night, the download link in my account is already “expired”, so I can’t install it on mine.

The pic is actually from a copy I found immediately on Vimeo, highlighting the absurdity of this level of copy control. Lesson: Only paying customers have to deal with DRM nonsense.

Update: 5 days later, the video no longer plays.

?YouWontSeeMe

 

In beta 11, Opera’s going to hide all “http(s)://”, and also all querystrings (until you focus the addressbar). Opera’s devs are right that users consider them mostly “gibberish”, but I think this change could cause a ton of problems and confusion for people, especially support staff, and there are plenty of sites/apps still out there with URLs based on querystrings. I can see this setting as short-lived.

A Zend Framework App in a Single File

 

Most PHP micro-frameworks I’ve reviewed have some major cons: incomplete namespacing of functions/classes/global vars; doing too much/little; being under-tested; and the worst: forcing a unique (and usually under-documented) code structure that will make it difficult to “graduate” an app into a more full-featured framework. It also seems silly to rely on “micro-optimized” code if performance isn’t your number one goal and you have well-tested libraries sitting around.

So over the weekend, as a proof of concept (and mostly to get better acquainted with ZF’s MVC implementation), I built some minimal classes allowing one to implement a “quick and dirty” Zend Framework MVC app in a single script, with the resulting abomination being relatively easy to convert to a full app. The README shows how such a script might look. Continue reading