Top 10 Stupid-in-Tech: Things that Shouldn’t Be but Are

10.

SMS
Seriously, how the hell can anyone read that?

9.

Text messages.
Okay, text messages aren’t all that stupid. Their excessive use, however, is. What’s worse is that young people–sitting next to each other on a train–are increasingly more likely to text each other than to simply turn their heads and talk.

8.

Text messages part two
The rates are absurd. Providers charge in upwards of $0.20 per text message for standard plans. Considering each text message can only contain a maximum of 140-160 characters, it’s about 0.125 cents per character. That doesn’t sound like a whole lot, but if e-mails were charged at this rate with about 1.5KiB per message (1,500 characters), you’re looking at about $1.88 per e-mail or $812,500 for a single CDROM ISO. Transmitting a DVD ISO would cost a little over $5 million.

But hey, who’s counting?

7.

Twitter Social Networking Sites
Useful, but I’m afraid people obsess just a little too much over them. On the other hand, it’s a great way for companies to advertise, bring in revenue, and make grossly obscene profits, which is awesome. Okay, so it’s not really the fault of the social networking sites. It just annoys me every time I hear from someone “Hey, do you have a ${currently_popular_site_of_the_moment} account?” Bonus points if that same person asks me about a new service once a month.

6.

Wireless Speakers
I’m not going to say anything else. I don’t need to.

5.

Windows Powershell
Seriously, Microsoft, there are plenty of good shells available. The verbose horror that PS is should never have been born into the world.

That’s okay, though–I usually just install Cygwin.

(Okay, I confess that being able to query things like WMI from PowerShell is really useful. I hate the syntax, though.)

4.

Flash
I hate Flash. The only good use of Flash is for video sites like Youtube (with one exception, see #1). Purely Flash driven sites are and have always been a disgrace to web designers world wide. Please, learn how to use HTML and (maybe) CSS. There are even applications that will do it for you. It’s not hard.

Thankfully, there’s only one thing worse than Flash-driven sites. Unfortunately, that one thing happens to be broken Flash-driven sites.

3.

Electronic Arts
Your site sucks. Thanks to #4, I can’t even navigate it unless I have Flash installed. I was browsing it about a month ago so I could look up information on a game you published. I finally gave up and went to Wikipedia.

2.

Macintoshes
I’m only posting this to insight and inflame my beloved Mac users. I’m not worried, either. Since you guys still can’t right-click out of the box, I’d imagine you probably can’t carry a pitchfork in one hand and a torch in the other when you come to lynch me.

He who cannot right click cannot dual wield; see but cannot stab, stab but cannot see. ‘Tis a disastrous predicament, is it not?

1.

How-to Videos–for Programmers
I’ve never understood this one. Don’t believe me? Do a search on Youtube. You’ll find how to videos for just about every language out there. Oh, and good luck reading the text. It’s like posting a “how to drive a car” video taken of only the vehicle’s exterior. Given the screen capture and compression quality imposed by Youtube, you can imagine then that this video might be taken of a car while it maneuvers in a region occluded by trees and from an altitude of 3 miles. You can’t see the car. You can’t really even see the road. Heck, it might even look a little like what you ate this morning as it greeted you on the way back up because the bus driver for your Big City Transportation Company happens to believe that his multi-ton monstrosity was just entered into the Indianapolis 500 the moment you stepped on board. It doesn’t work.

How to videos have their place in life (Blender comes to mind), but for the love of all that is holy please, please, please don’t post “how to program in $lang” videos on Youtube. You can achieve the same thing with about 10-20 kilobytes of text on a hosting provider elsewhere. Best of all, you can copy text tutorials and their example code!

4 comments.
***

The Blessing and Curse of Standards

Some months back, I was playing around with software I had written to automatically decompress World of Warcraft addons, record their contents, and place them in a single zipped archive for download via our guild site. I ran into some peculiar issues with a handful of WoWAce-based addons that I eventually traced to the developer’s use (incorrectly, I might add) of Subversion externals. Oddly, the archive would behave correctly under Windows while using both the built-in Windows zip utility and 7-zip. That was when I started thinking about the blessing and curse of standards. Read more…

No comments.
***

Brief Comparison of Servers and Frameworks

This article has been deprecated as the fundamental principles behind the data acquisition are flawed and incorrect (at the time, I didn’t have multiple machines to test on; as a consequence, benchmarks were performed on the same server by the same server). You should not cite this article as authoritative, but it can give you some additional foundations to base further research on.

I’ve been working with a couple of Python-based frameworks for web applications recently and have elected to try my hand at writing my own application server in Stackless Python due to its simplified concurrency model (and threading in Python appears to have performance-related issues compared to languages that support it natively, like Java). My efforts haven’t gotten much further than creating a basic skeleton so far, and it certainly seems as though I’ve learned much more about Python’s internals than I ever wanted to know! Performance has been a fairly significant concern up front, and I believe it’s necessary to examine how your own software performs early in the development process rather than waiting until the design has been solidified. Once you’ve been bitten by a fundamental flaw or serious bottleneck around which your entire design relies heavily on, it’s very difficult to alter the application’s behavior without significant refactoring. While I’ve heard it said that it’s sometimes better to write the application first and worry about performance later, I have never had such luck. It seems easier to write the application correctly the first time, in terms of developer time spent now and in the future on maintenance.

However, there is one benefit I didn’t predict from this exercise: This experience has also afforded me an opportunity to compare different frameworks and servers for performance and behavior under load. Read more…

2 comments.
***