A recent article about upcoming updates to the Firefox web browser contained an offhand remark about how often Adobe's Flash Player plugin causes the browser to crash:
Flash is responsible for more Firefox crashes than any other plug-in.
Of course, the linkbaiters and Flash-hating bandwagoners were quick to isolate the quote and link away as (supposedly) yet more evidence that Flash sucks!
Newsflash: Flash is so ubiquitous that the only way that statement would be surprising is if it said that "Flash is not responsible for more Firefox crashes than any other plug-in."
If you think that the statement that Flash causes more Firefox crashes than any other plugin is an indicator of what a piece of junk Flash is, you're reading it incorrectly. Flash is an integral part of the web experience. It causes more crashes, because it's being used more. Saying that Flash causes more crashes than other plug-ins is a "no duh!" statement. Like saying that cars are responsible for more road accidents than any other mode of transportation. Of course they are, there are more cars on the road than bicycles, motorcycles, etc! And this is an apt metaphor, actually, because in my experience it's less the cars fault than the drivers (Unless it's a Toyota!). Give the keys to just any bozo you meet at a party and you're likely to end up in a ditch with a broken arm.
Try browsing for a week, or perhaps even a day, without Flash Player installed. You'll end up bookmarking a lot of content to come back and experience after you've got Flash back.
If you want to harp on problems the Flash Player may or may not have, get some useful data. How about the percentage of times that the Flash Player crashes out of the times it runs? How about the percentage of users that experience a Flash Player related crash? How about an average number of times per week a given user may experience a Flash Player crash?
Don't get me wrong. I'm not shilling for Flash or Adobe. Flash has its problems (near constant security updates, anyone?), just like anything else. And I for one am very excited about the inclusion of these new "Lorentz" and "Electrolosys" features. I thought the idea was brilliant when Google announced Chrome, and I still do. I'm glad that I won't lose unsaved work in one tab because of a stupid flash-based banner ad in another.
But really? Flash haters? Get over yourselves.
Posted in
Flash |
Firefox
| 6 Responses
February 22 2010
During the CF9 Beta process I was among several people who submitted bugs about the headerRow attribute of the new CFSpreadsheet tag, and how it might not be working as well as it could:
When specifying the headerrow attribute in [CFSpreadsheet], the column names are retrieved from the header row, but they are also included in the first row of the query. The expected behavior is that they should not be included in the query at all, only as the column names. [#72740]
I was contacted by an Adobe engineer about my bug report, and after some back and forth essentially I was told that this isn't a bug. Before we get any further, let me make sure I've explained this perfectly clearly. Let's start with a spreadsheet with some data in it, and column headings:
Now, let's read the contents of that spreadsheet into a query, setting the column names based on that first row of data:
<cfspreadsheet
action="read"
headerRow="1"
query="result"
src="#expandpath('./test.xls')#"
/>
<cfdump var="#result#" />
And here's what gets dumped:
It might be a little subtle, so if you didn't immediately notice, let me point it out: The column headers remain in the data. I would expect that the use of the headerRow attribute would "eat" the headers from the data. I can't think of a logical reason they should remain in…
I verified that this behavior is the same for both Excel 97 (xls) and OOXML (xlsx) file formats.
Do you agree that the header rows should be "eaten"? Disagree? I'd like to know.
Despite the public bug tracker, Adobe is strangely quiet on this issue. I've had some correspondence with one of the engineers, who told me it wasn't a bug (my own bug was closed and marked as a duplicate, but #72740 remains open, marked as not a duplicate, verified (usually meaning reproduced), and somehow, not reproduced…).
In my correspondence with Adobe, I was told that to get the desired behavior I should do the following:
<cfspreadsheet
action="read"
headerRow="1"
query="result"
src="#expandpath('./test.xls')#"
rows="2-65536"
/>
The only difference between this and my original code is the addition of the rows attribute; so it's not that much extra work. What it's doing is specifying to skip the header row and return all rows of data up to the theoretical maximum (the number is the Excel 2003 row limit, (2^16) and Adobe confirmed that this is the limit for ColdFusion as well).
This specifies that I want to skip the header row, does in fact get me the results I want, and in general isn't terribly difficult. On the other hand, I've basically been asked to commit the number 65536 to memory, or to put it on a post-it on the side of my monitor, so that I can refer back to it later. So for that reason, I don't consider it an acceptable work-around.
To me, an acceptable work-around might be implementing one of these syntaxes: rows="2+" or rows="2-" or rows="2..". For what it's worth, the documentation for the rows attribute currently reads:
The range of rows to read. Specify a single number, a hypen-separated row range, a comma-separated list, or any combination of these; for example: 1,3-6,9.
Still, a work-around would be a black eye in this case, in my humble opinion. What reason is there to leave the header values in the data set? Can anyone out there give a practical example for wanting them to stay? Until I see one, I will continue to believe that they should be removed; and while I would begrudgingly accept a work-around, I'd really much rather see the issue addressed because I want to see ColdFusion become the best platform & language it can be.
If you agree with me, I would encourage you to leave a comment on the open bug indicating so, and vote for it. If enough people agree with me, perhaps Adobe will answer the call.
Posted in
ColdFusion
| 8 Responses
February 18 2010
This year I finally worked up the courage to submit a couple of topics for CFUnited:
- FlexUnit: From Zero to… Something Greater than Zero! — A beginners guide to unit testing in Flex with FlexUnit.
- Pragmatic Version Control Using Git — An introduction to Git with a pragmatic approach.
Voting is open to the public, so if you would like to learn more about these topics, and potentially witness a grown man pee his pants, please go vote for them!
I'll be there regardless — this will be my 3rd time in the last 4 years — but it would be pretty cool to be a speaker.
Posted in
CFUnited
| 1 Response
February 12 2010
Today I'm happy to announce that SweetTweets (both the stand-alone cfc, and the Mango plugin) have been updated and are available for download.
Huge, huge, huge hat tip to Ray Camden, who brought this proejct to my attention. After deconstructing how it worked, I was able to rip out the old search method that SweetTweets did and replace it with the same technology. If you're curious about the tech, I'll get into it a little bit after the download links.
For now, the short version of the story is that link reverse lookups are finally possible — which means that ANY url shortening service* can be used, and you'll still get your tweetbacks… Yes, even bit.ly!
SweetTweetsCFC users can download version 2.0 from the Riaforge project page. Mango Blog plugin users can get the latest version here:
- Plugin:
- SweetTweets
- Version:
- 2.0
- Requires:
- Mango Blog 1.2+
- Auto-install URL:
- http://fusiongrokker.com/get/SweetTweets
How does it work?
There's a service available called Topsy that has their own API, including reverse-lookup for links — essentially exactly what I was looking for in my last post about Tweetbacks. And since we don't have to lookup and cache what the short url's are, you should notice that SweetTweets is much faster than previous versions. The only thing I rewrote was the search tech. Local caching and AJAX access are more or less untouched.
If you were using custom code to implement SweetTweetsCFC, you'll notice that the getTweetbacksHTML and init methods have two new optional arguments allowing you to specify the header text for when there are or are-not tweetbacks found. I'm pretty sure that's about the only interface change. The data returned should be roughly the same. Oh, and I updated the links that it adds to hashtags to use search.twitter.com instead of hashtags.org, which is the new standard; and I also fixed a bug where only the first hashtag in the tweet would be converted to a link.
Using Topsy does have its own limitations. They limit results to 50 tweets per page, and I don't see the need to implement paging, so at the moment the most you can get back is the 50 most recent tweets.
*I'm not sure if shorteners that add a "bar" (frame?) to the page will work. This includes services like ow.ly (the shortener used in HootSuite).
Posted in
My projects |
Mango
| 2 Responses
February 11 2010