So many words, so little meaning

Doug LeMoine:

This is a pretty impressive effort toward designing an interaction framework for a massive media conglomerate with a dozen sub-brands, content licensing deals with who knows how many third-parties, and an absolute clustercuss of a styleguide.
Translation: MSNBC aggregates content from a lot of other sites. Their redesign is not as cool as I would have made it.

Personally, I like the new MSNBC look—getting rid of pagination is a welcome change, the typography is significantly better and the numerous small touches make the site much easier to use, even though the whole “show more text” feels completely superfluous to me, and their heavy use of colour in some sections makes my head spin.

⇥ Formatting Flex Datagrid rows

I keep coming across people who seem to think that Flex’s data formatting facilities are somewhere between Voodoo and rocket surgery, particularly when it comes to data visualization elements like DataGrids.

Nothing could be further from the truth—Flex may not be the best system in the world, but it’s all about manipulating data; therefore, it has some excellent (and super-easy) formatters.

Inside a DataGrid, what seems to be a problem for so many is the fact that the data is seemingly rendered without any input from the developer. All this means, however, is that you need to write your very own, custom item renderer.

Sounds scary? It couldn’t be simpler: all you have to do is create a mini-component inside your DataGrid’s rows. For example, consider a simple DataGrid whose data provider contains the two columns orderDate (a date) and and orderAmount (a currency value). Normally, your code would probably look like this:

<mx:DataGrid dataProvider="{data}" width="100%">
  <mx:columns>
    <mx:DataGridColumn headerText="Order Date" dataField="orderDate" />
    <mx:DataGridColumn headerText="Order Amount" dataField="orderAmount" />
  </mx:columns>
</mx:DataGrid>
Obviously, there is nothing wrong with this code, which will work just fine… except that the output is not quite as user-friendly as it could be:

I don’t know about you, but my clients don’t normally work in GMT—and those crazy devils just insist that their amounts must be properly formatted with currency signs and thousand separators.

Luckily, this can be rather easily achieved using two of Flex’s many built-in data formatters—namely, mx.DateFormatter and mx.CurrentyFormatter. DateFormatter takes a string specification like “YYYY-MM-DD” and uses it to format a date. CurrencyFormatter, on the other hand, provides a number of parameters, like precision and thousand separators, that can be used to control the textual representation of a currency value. For example, we could write our two formatters like this:

<mx:DateFormatter id="dateFormatter" formatString="YYYY/MM/DD" />
<mx:CurrencyFormatter id="moneyFormatter" currencySymbol="$" useThousandsSeparator="true" precision="2"/>

Remember that both formatters are non-visual elements and, therefore, must be added to the <fx:Declarations> element of your component.

All that remains to be done now is to create item renderers to provide a custom representation of each of the DataGrid’s columns:

<mx:DataGrid dataProvider="{data}" width="100%">
  <mx:columns>
    <mx:DataGridColumn headerText="Order Date" dataField="orderDate">
      <mx:itemRenderer>
        <fx:Component>
          <mx:Label text="{outerDocument.dateFormatter.format(data.orderDate)}" />
        </fx:Component>
      </mx:itemRenderer>
    </mx:DataGridColumn>
    <mx:DataGridColumn headerText="Order Amount" dataField="orderAmount">
      <mx:itemRenderer>
        <fx:Component>
          <mx:Label text="{outerDocument.moneyFormatter.format(data.orderAmount)}" width="100%" textAlign="right" />
        </fx:Component>
      </mx:itemRenderer>
    </mx:DataGridColumn>
  </mx:columns>
</mx:DataGrid>
As you can see, we simply use <fx:Component> to declare an inline component inside the itemRenderer attribute of each column. Once instantiated, the custom component will have its own scope, but we can still access the data row whose values we must visualize through the data property, while the main component (where our formatters reside) is stored in the outerDocument property. Note that I am using <mx:Label> and not <s:Label>, because the DataGrid is a Halo container and, therefore, most Spark components cannot be fit into it1. For good measure, I also-right aligned the currency column; note that I am setting the label’s width to 100 percent so that it will stretch all the way to the end of the column; otherwise, the right-alignment will be ineffective because the label will only occupy as much space as necessary.

That’s it2! The output of our little application has improved considerably:

Now, we could, in theory, have placed the formatters into the individual item renderers, as long as we enclose them in their own <fx:Declarations> block:
<mx:DataGridColumn headerText="Order Date" dataField="orderDate">
  <mx:itemRenderer>
    <fx:Component>
      <mx:Label text="{outerDocument.dateFormatter.format(data.orderDate)}">
        <fx:Declarations>
          <mx:DateFormatter id="dateFormatter" formatString="YYYY/MM/DD" />
        </fx:Declarations>
      </mx:Label>
    </fx:Component>
  </mx:itemRenderer>
</mx:DataGridColumn>
This will arguably keep our code a little cleaner and make it easier to customize multiple columns to different formatting specifications. However, the added flexibility would come at the cost of creating an additional object for each item renderer for each row that is displayed at any given time.

  1. Ironically, <s:Label> will actually work here, but the compiler will complain about the fact that the data property cannot be accessed. That’s because Spark’s version of the label is not designed for use as an item renderer… which unfortunately is not mentioned in the error reported to you.
  2. Note, most interestingly, that we do not have to worry about the bindability of each row’s individual properties—that’s because the DataGrid object actively invalidates the data property of the item renderers for each row that needs to be displayed.

An SSH server written in PHP? Why, yes, you can.

Mark Karpeles

Last time I already tried to prove PHP can do anything when it comes to network protocols by implementing a DNS server. This time I’m doing it again with a server-side implementation of the SSH2 protocol.
Leaving aside for a moment whether one should write an SSH (or DNS) server in PHP, the fact that one can is pretty cool.

Should we get ready to go nuts over cookies?

The Register on a new EU law, due to go into effect next year, that requires sites to ask for consent prior to storing cookies on a user’s browser:

An exception exists where the cookie is “strictly necessary” for the provision of a service “explicitly requested” by the user – so cookies can take a user from a product page to a checkout without the need for consent. Other cookies will require prior consent, though, and the law must be implemented in member states by May 2011.
So, how do you define “strictly necessary?” If your PHP installation has sessions on by default even though you don’t use them, is that a violation of the law? What if you use Google Analytics on your site? Should you, or Google, request permission?

If any of my European friends want to chime in with what this means, I’d welcome the information. Please try keeping the swearing down to a minimum, if you can…

WordPress 3.0 Upgrade: What to Expect

Cameron Chapman:

With virtually any WordPress release (or the release of any open-source software, for that matter), there are bound to be bugs.
I’ve already upgraded this website with minimal problems in my custom theme—the only thing that stopped working was my “Quotelet,” a little bookmarklet I use to create posts based on a selection of text from another website. It turned out that the bug was mine, too—so I can’t even complain about WP3 breaking compatibility.

The new WP seems a little faster than the old one, though, being on a shared host, that could also be due to a million different things. Of course, T·A·B is my personal playground, so failure here is always an option—we’ll hold off on upgrading any of our production sites to a later date.

⇥ Ten ways to solve iPhone 4′s antenna problems

  1. Duct-tape the metal band around the phone. Not as colourful as Apple’s bumpers, perhaps, but for $30 you can probably buy the United States’s entire supply of duct tape.
  2. Duct-tape your hand to prevent it from shorting the antenna.
  3. Duct-tape the phone to your head1.
  4. Hold the phone to your head using a stick with a suction cap.
  5. Hold the phone upside down (note: you may have to speak a little louder for this method to work).
  6. Attach the phone to the base and swivel arm from an iMac G4 to avoid touching the antenna. Makes for a trendy combo, especially when you’ll be able to get your hands on a white iPhone.
  7. If you’re a leftie, learn to hold the phone in your right hand. If you’re right-handed, learn to hold the phone with the Force.
  8. Speaking of the Force, this is not the problem you were looking for. Move along now.
  9. Don’t call Apple customer support. Steve can only answer so many e-mails in any given day.
  10. Google for solutions from antenna experts directly from your iPhone, only to find out that, in a case of extreme bitter irony, the entire antenna-expert industry has converted all its websites to Flash
  11. It’s all the folders’ fault.
  1. Warning: may leave residue on your head and, more importantly, on your phone.

⇥ NoSQL, round holes and square pegs

Ivo Jansch:

In last year’s conference, there was a talk on CouchDB, introducing a ‘NoSQL’ database as a response to relational databases often being a hassle when web data needs to be stored and manipulated. This year, we could see that NoSQL is catching on and becoming more mainstream. Matthew Weier O’Phinney, project manager of the Zend Framework, discussed NoSQL in detail, and MongoDB (Another NoSQL database) was mentioned in a couple of talks. NoSQL is definitely something to have a look at, and it might be useful even in existing projects. More info can be found on the Wikipedia page.
We saw the same at this year’s TEK·X conference. More and more people are realizing that working with SQL is, at least in some cases, an exercise in fitting a square peg to a round hole; NoSQL, however, still presents a movement “on the rebound” from SQL, so that they seem to be trying to round out a lot of pegs that maybe don’t need to be. On the other hand, some uses of RDBMSs are a little ridiculous. If you’re storing documents inside a MySQL database, you’re not using the best tool for the job.

However, the NoSQL community still has a long road ahead of itself, with many issues that need resolving. Right now, fragmentation—the result of the relative youth of these systems1—makes the adoption of any one system risky, while the lack of a common data querying language (or even vocabulary) makes it difficult to future-proof any project based on a document-oriented database system.

Eventually, I suspect that we’ll reach some sort of equilibrium in which one of the document-oriented systems will prevail and become as ubiquitous as, say, MySQL has become, or, at least, some sort of bottom-of-the-barrel standard like SQL will become common among the various implementations, so that developers will be able to switch between systems more easily and focus on the differences that make one more appropriate than the others in a particular development scenario. Of course, the various NoSQL leads could simply attempt to get together and find some common ground that can help them grow more organically and cohesively—but this is software… so I won’t be holding my breath.

  1. Document-oriented databases have been around for a long time, but they were relegated to specialized applications until recently. With greater awareness, there are an increasing number of competing systems being developed in a completely haphazard and disconnected way.

Adobe: record earnings for 2010Q2

Speaking of earnings:

In the second quarter of fiscal 2010, Adobe achieved record revenue of $943.0 million, compared to $704.7 million reported for the second quarter of fiscal 2009 and $858.7 million reported in the first quarter of fiscal 2010.  This represents 34 percent year-over-year revenue growth.  Adobe’s second quarter revenue target range was $875 to $925 million.
As predicted, the whole Apple thing doesn’t seem to have had any real impact on Adobe’s revenues or profits—at least, not yet. It goes to show that customers choose Adobe for its tooling, and that Flash itself is, therefore, replaceable as a web technology in the long run without, I think, permanent damage to the company.

On the other hand, I think that Flash has a great future as a cross-platform development platform for GUI applications; it’s a shame that Adobe has decided that it will no longer support iOS, because enterprise customers could have benefited greatly from a technology that supports heterogeneous deployments, and they are not bound to the terms of the App Store.

Red Hat grows 1Q revenue, profit

Jeff Drew:

For the three months ended May 31, Red Hat posted net income of $24.1 million, up about 30 percent over the $18.5 million earned by the company in the year-ago quarter. On a per-share basis, earnings climbed to 12 cents from 10 cents – a 20 percent increase.

Revenue rose by 20 percent, to $209 million, beating the consensus analysts’ estimate of $202.89 million. Subscription revenue also rose by 20 percent, to $179.1 million.

Excellent showing for a company that has made OSS the focus of its business.

Stop Forking with CSS3

Aaron Gustafson:

Boiled down to its essence, eCSStender (pronounced “extender”) is a JavaScript library (akin to jQuery or Prototype) specifically built for working with CSS. On its own, eCSStender doesn’t do anything but analyze your stylesheets. When powering “extensions,” however, eCSStender allows you to use properties such as @border-radius and selectors like @.seven:nth-child(even) without having to resort to forks or hacks.
The real question is: why do we have to resort to hacks in the first place? Libraries that equalize the CSS differences between browsers are still hacks—they just hide the “hacky” part from the developer, but they do so in exchange for a developer’s loyalty to something that is not a standard. If you have to use jQuery (for example) to build an application, you are not using standards.