Speaker Cuts Off C-SPAN Cameras When Dems Attempt To Bring Vote On Payroll Tax Cut

This is dirty politics at it’s worst, but it may likely be a blessing for the Democrats in the 2012 election year, as it’s exactly the sort of misguided and secretive damage control gone wrong that will allow the Republicans to be portrayed as against the interests of the middle class.

House democrats attempted a procedural move to get a floor vote on extensions to a payroll tax cut, and were curbed by Republicans, who responded by adjourning the house, and then quickly cutting the video feed from the chamber.

Now, to me, it should be very clear who the Republicans want to cut taxes for, and it’s not you and me…They couldn’t stand for taxes to be raised on upper income people, but they are sitting here letting them be raised on the poor and middle class?

From the article on ThinkProgress:

During a quick pro-forma session of the House this morning, Republicans rebuffed a Democratic attempt to force an up-or-down vote on the Senate-passed payroll tax holiday extension, which Republicans have thus far refused to allow. Rep. Michael Fitzpatrick (R-PA), who was serving as the speaker pro-temp, ignored shouts of “Mr. Speaker!” from Democratic Whip Steny […]

via Speaker Cuts Off C-SPAN Cameras When Dems Attempt To Bring Vote On Payroll Tax Cut.
During a quick pro-forma session of the House this morning, Republicans rebuffed a Democratic attempt to force an up-or-down vote on the Senate-passed payroll tax holiday extension, which Republicans have thus far refused to allow. Rep. Michael Fitzpatrick (R-PA), who was serving as the speaker pro-temp, ignored shouts of “Mr. Speaker!” from Democratic Whip Steny […]/p

via Speaker Cuts Off C-SPAN Cameras When Dems Attempt To Bring Vote On Payroll Tax Cut.


Useless use of flash

Once upon a time, the renowned Perl wizard Randal L. Schwartz used to issue a series of “useless use of cat” awards to posters on the usenet newsgroup comp.unix.shell that abused the “cat” utility for purposes other than which it was intended.

The classic UUoC was something like:

$ cat file | grep foo

The UUoC awards highlighted the most egregious misuses – the cat utility is designed for concatenating two files, not for display of a single file, and certianly not as the first stage of a pipe.

On the modern web, we see similar occurrences with Flash in websites, where it has no business being used.

Flash is useful when it does something that web standards either can’t do, or can’t do easily. Flash is useless when it adds nothing to the content of the site that can’t be duplicated with a few lines of JavaScript and CSS.

Interacting with webcam and microphone? Useful.

Embedding a video game into a web page? Useful.

Performing rollover effects on a link? Useless.

Playing a slideshow? Useless.

Displaying advertising? Useless.

Playing video? Still useful. (But on the way out, thanks to HTML5 video).

Useless use of flash is a more serious violation than useless use of cat ever was – instead of costing you a process, it costs every visitor to your website a process, along with the memory that goes with it. It also costs accessibility – assistive technologies like screen readers and braille terminals don’t really work for flash.

Using Flash when it’s not called for is a demonstration of laziness and incompetence on the part of web designers – it’s unprofessional, and it needs to stop.  I’m going to start highlighting examples of useless use of flash (UUoF) when I see them, in the hope that it will draw attention to the epidemic of poor web design that is a UUoF.

There are many examples out there, and I plan to start showcasing the worst of them here 🙂

Corporate tax break reform

I have a very simple idea for closing tax loopholes while getting corporations keep getting tax breaks.

Tie tax breaks to jobs created and maintained, with additional credit given for length of service and certain salary milestones, so that businesses are credited for their positive impact on the economy and on the tax base.

With each american worker on the payroll providing a sizable credit, it should be designed so that companies start with a high tax rate, but can easily reduce or eliminate their tax burden by providing STABLE, long term, and reasonable paying jobs to enough of the people that need them.

The beauty of this is that it would directly encourage companies to keep good jobs here, and the companies that get out of paying taxes under this approach are going to generate tax revenue indirectly through high employment, generally enough to ofset the lost taxes.


Thoughts on the enterprise and rapid updates

Despite the widely held belief that rapid release spells the death of Firefox in the enterprise, I still believe that its a blessing in disguise.

Enterprise apps have been absurdly brittle for years. This in and of itself is a huge risk, but beyond that, its a trap and a money pit. By passing problems down the line we might see lower costs here and now, but in reality we just wrote a whole book of blank checks that will eventually get cashed in one at a time.

Rapid release introduces change into Firefox at a rate that seems staggering, especially to IT departments that are already gunshy about changes from dealing with brittleness all the time.

The only answer to this kind of volatility is to build more robust applications, and to rely on standards rather than release numbers. You see, standards are a sort of contract with the future – you may not know what direction the browser world will take, but in 5 years its a safe bet that the html5 family of technologies will still be there, and that a site using them will still function more or less as intended.

Besides needing to test applications for compatibility though, there are other issues, as Mike Kaply points out. Documentation has to be updated, sometimes including a lot of screenshots. Support staff may have to be trained. Deployment plans have to be developed.

These aren’t minor problems, and I totally agree it’s a concern. There are a few possible solutions already there, and enterprises have no further to look than Mozilla’s own development and QA processes for answers. You see, these aren’t new problems, Mozilla had to address them to even be able to implement rapid release.

Mozilla has a much smaller budget than many enterprise IT departments, but they have a widely used product, that’s used in an environment that’s anything but heterogeneous. The “tier 1”, or fully supported operating systems include at least 5 different versions of Windows, numerous Linux distributions, and 3 major version of MacOS X.  Mozilla also has community support for as many as several dozen other platforms to stay busy – including Solaris, FreeBSD, and OpenBSD, and an emerging mobile effort using the same codebase to support Android and Maemo users.

How do they do that kind of testing within the short time tables of rapid release? Automated testing is a large part of it, but here are some highlights.

The QA process starts with the developers – strict code review requirements, and a culture that chastises developers for “breaking the tree” with code that fails tests. As soon as code is checked in to version control, automated tests start to fire off, with builds for every platform triggering. As soon as a build finishes, automated tests are triggered to assess basic functionality, insure regressions don’t return, and makes sure performance doesn’t suffer.

These tests are just a start, tens of thousands of users follow nightly builds and report bugs. The QA team performs verifications as bugs are fixed to validate the fixes. The QA team also performs more automated tests. Both manual and automated tests are crowdsourced also, through Litmus, and MozMill Crowd.

As each version moves closer to release through the Aurora and Beta stages, testing efforts become more intense, and the number of users on early versions increases dramatically.

Now, how this applies to the enterprise is that there is no reason why enterprise adopters can’t benefit from the same automation that Mozilla uses – in fact, I’d say by now the Mozilla QA team are automation experts.

MozMill is a good tool to drive automated testing of Firefox itself. Selenium is good to drive automated tests of your web applications themselves. Litmus can be used to drive and organize your manual testing process for both new versions of Firefox and your applications themselves.

MozMill could probably be easily adapted to being used for documentation purposes too – scripting all the dialogs and dropping screenshots as it goes would make it possible to update screenshots very quickly, and would also validate your documents – documentation probably doesn’t need to be changed until the documentation screenshot scripts fail.

Training is still an issue, but it doesn’t have to be a big issue. The benefit of small, but frequent changes is that the user impact will also be small, so training can just focus on the highlights of the changes.

As it stands now, enterprises will have to start their testing at the moment that a new version enters beta to get 6 weeks of testing time. While this should be enough, that still leaves one major enterprise need – a backout plan. Right now, they don’t have it unless they deploy at beta. That’s understandably unacceptable. N+1 might be realistic for security support for Mozilla, but just as enterprises have a fear of change, Mozilla has a fear of LTS becoming “the version that won’t go away”, as happened with Internet Explorer 6. Remember that Mozilla’s mission isn’t market share or necessarily to push a browser – it’s to push open web standards forward. Given this mission, having the web be stuck at a particular level of technology goes against everything they stand for.

Hopefully, the rift between the enterprise and Mozilla will work out, and it’s good to see the Enterprise Working Group back on the radar, but it’s going to take compromises and ongoing effort on both ends to make this work. Fortunately, being an open source project, enterprise customers don’t just have to be customers – they can be developers as well – and hopefully this encourages them to contribute the resources Firefox needs for more enterprise adoption.




The problem with BrowserID and OpenID (and other website registration stuff)

Both Mozilla’s up-and-coming BrowserID technology, and OpenID still have one fatal flaw – reliance on a single authority.

There’s no inherent recovery capability in either of these solutions – in order to be able to put full faith in them, I need to be able to revoke an identity and migrate to a new one at will. BrowserID concentrates the identity on the email address – which means my identity is in the hands of my ISP, a free mail service, or I have to pay money to host my own mail server. OpenID has the same problem – my identity is either in the hands of a public web service, or I have to pay to host a site.

Websites that implement their own registration are even worse. They usually rely on the registered email address, and may even revert back to an older email address even after you switch email addresses – so if your email is compromised, you are SOL.

Ultimate control needs to be firmly in the hands of the user – in the form of something that can be used to prove you the same person who created an identity, and replace that identity with another, whenever it proves necessary. The information, key, or token to do that needs to be safely in my hands, not with my identity provider.

Don’t miss the train – addons in the new rapid release world

Disclaimer: I’m not an addon developer, just a concerned end-user that tries to be involved with the Mozilla community and follow the development process. Hopefully this will still make sense.

Updated June 23: Added links to http://blog.mozilla.com/addons/2011/04/19/add-on-compatibility-rapid-releases/ – thanks @jruderman for pointing this out.

Firefox 5 shipped yesterday, on time, the first of many releases on the new, accelerated rapid release schedule.

There’s been a lot of talk of rapid release being a negative for users, particularly due to addon compatibility. While it’s certainly a valid concern, it’s not as bad of a situation as it appears on the surface. The Mozilla developers, in particular the Addons.mozilla.org team have been doing a lot to prepare for rapid release and to make the transition less painful for both users and addon developers. The addons team has even put an automatic compatibility update in place that finds addons that will work and marks them compatible early in the release cycle.

Continue reading Don’t miss the train – addons in the new rapid release world

On email etiquette and privacy…

>While almost everyone these days is using email, either at home, at work, or both, there are some simple principles of email etiquette that are largely ignored.

Protect your contacts
I give out my email address to my friends and colleagues so that they can communicate with me. Unfortunately, not everyone can keep things to themselves. While many people wouldn’t think of writing the addresses of every person they know on an envelope, that’s exactly what they do when sending an email. Not only is this a huge breach of trust and downright rude – it also helps spread viruses and spam. Use Bcc whenever you are sending to a group of people.

Don’t pass along chain letters and hoaxes
Chain letters are downright annoying, and are a form of spam – about the only thing worse than spam is spam from a friend.
Hoaxes can spread panic, clog mailboxes, and waste many, many hours trying to clean up the mess afterwards.

Use a clear concise subject for your messages
Some people get a lot of email – hundreds or thousands of messages a day. When dealing with that many messages, it helps to be able to find things quickly, and know what you need to look at first. Thus, the subject line can be the most important part of the message – in about 40-60 characters or so, it should tell the recipient clearly what the message is about so that they can decide when they need to read it, and can find it later.

But don’t abuse words like urgent or important
Sure, your message is important to you – every message is for that matter… however, trying to draw attention to your message in this manner is like crying wolf – it makes the recipient numb to such cries and may even make them ignore you entirely. Furthermore, such keywords are common in spam emails – and may cause your message to get eaten by spam filters.

Remember that email isn’t private
Emails can be easily forwarded, printed, and copied. You never know who else may be looking at the screen. Furthermore, email usually travels unencrypted over public networks – similar to a postcard – everyone that handles it can read your message. If privacy matters to you, then you – and whomever you are trying to correspond with need to take special measures to protect privacy, including using encryption software, screen locks, and other means to keep private messages private. Even with encryption, you have no control of what the recipient of a message does with it.