Category: Technology

Categories
Technology

Pastel fruit flavored marshmallows

Recovered from the Wayback Machine.

Perhaps I’m overly tired tonight, but Noded’s post today really resonated. JR wrote:

I think back to the people at SXSW who are supposedly the movers and shakers in our high tech online world. They seem to be working in mediocrity, working with browsers that break, operating systems that leave you vulnerable to constant attack, unwieldy programs that fail to do what they are supposed to, web sites that are impossible to navigate. I’m hoping at some point someone down in Austin starts to realize things ain’t going to fix themselves.

As serendipity would have it, the WaSP weblog updated, based on today’s SxSW meeting, in order to promote a new initiative: WaSP Street Team:

The WaSP Street Team is about you. No, not all the other YOUs reading this but YOU you, in your actual skin. The idea is that together we create a number of tasks – challenges if you will – to help the promotion of web standards in your local community. Things that will help get the word out to the businesses, educational institutions, web shops and individuals who live and operate directly near you. As a central group it’s hard for us to reach those people, but as a distributed team, it’s easy.

In between edits this last week, I moved all my images to Amazon’s S3 using a variety of RESTful applications, wrote about it (and will write again about it), ported my weblog over to being served as XHTML, wrote about it, ran my first test of embedded SVG within a web post, wrote about it, and decided that the WordPress category scheme won’t work for my needs and am creating a replacement. All of the functionality I’m creating for my web site I’ll write about, as clearly as possible, so that everyone, techs and not, can understand. I hope. All the code I create will eventually be released, as plugins or applications or what have you.

All will be using industry standard specifications: XHTML, CSS, RDF, Atom, REST, as well as JavaScript, PHP, Python, Java, and Ruby (for my S3 work).

I don’t know how many people read my site. Hi People! Regardless of the number, you all are my outreach. I may not go to conferences, you may never meet me face to face, chat with me over IM or twitter, vidcast each other, or swap spit, but I never fail to share what I discover. Yet we value those who go to conference after conference, who jump on to the next tech gewgaw, join in the next group hug, cellphone planted in one ear, iTunes in the other, eyes aglow talking about this brave new world where people don’t have to live and work face to face, all the while telling people they have to meet face to face to be real–busily twittering away about every…mundane…act, because if they stop, they actually stop, the silence will catch up with them like a humongous tidal wave and do something horrid!

For the last year, reading much of this, I feel like I’ve lived on a solid diet of marshmallows–you know, the small pastel, fruit flavored kind? It’s good at first, and even tasty, but eventually you’d kill for an apple or a cheese sandwich.

Frankly, anyone who goes to more than one conference every month is just not someone who stands still long enough to have anything interesting to say. And if we ever do meet face to face someday, I can tell you it won’t be in the midst of 4000 other conference goers, all twittering away while ignoring everything around them(!?)–or while we share toasted marshmallows over a campfire snuggled up in sleeping bags among 150 strangers.

Twitter is the big thing coming out of SxSW. My god people. Might as well run a magnet across your synapses.

Update:

GoogleWatch on Twitter:

Sure, I get it. It’s a message board for BlackBerry-toting tech zombies. And the majority of posts I’ve seen include the blabberspeak mumblegum language of incessant now-ness:

LaughingSquid: “up, barely, coffee soon”
jidnet: “just woke up.”
daveboob: “Watching a bulldozer outside with Sam.”

Riveting.

To which Seth Ladd replies:

In an age where style easily trumps content, Twitter has neither.

OK, wienie roast is over, back to the book edits.

Categories
Technology Web

Wither away Ajax?

Dare Obasanjo has wrung the death knell on Ajax, but I disagree with him on several counts.

He writes:

Most people who’ve done significant AJAX development will admit that the development story is a mess. I personally don’t mind the the Javascript language but I’m appalled that the most state of the art development process I’ve found is to use Emacs to edit my code, Firebug to debug in Firefox and attaching Visual Studio to the Internet Explorer processes to debug in IE. This seems like a joke when compared to developing Java apps in Eclipse or .NET applications in Visual Studio. Given how hypercompetitive the “Web 2.0” world is, I doubt that this state of affairs will last much longer.

There is an Eclipse plugin for JavaScript development (actually, more than one), and that’s only one of many JS development tools. I tend to use text editors and Firebug because I’ve found both to be sufficient for my needs. All you have to do is search on “edit JavaScript” to pull up a host of free, open, and/or commercial tools to simplify JavaScript editing. This is in addition to the graphical tools for working with SVG and Canvas.

As for Firebug, I think that Dare sells this application way too short. With Firebug I can not only inspect a web page contents, stop a process and inspect programming constructs, drill into the CSS and markup, investigate what’s taking so long for the page to load, and review responses back from Ajax calls, I can see the document object model at a glance, and how all these little pieces pull together. I’ve worked with a host of desktop tools: none has ever had the ability to drill into every aspect of the application as much as Firebug allows me to do so with a simple web page.

Dare also writes:

There is too much pressure on Web companies to improve their productivity and stand out in a world full of derivative YouTube/MySpace/Flickr knock offs.

Yes, but why did all of these become so popular? Because they’re all accessible using something that everyone has: a web browser. There’s nothing to install, other than the ubiquitous Flash plug-in. There’s nothing proprietary about most of the technology used. These applications work with most browsers, except perhaps the older Internet Explorers or Netscape 4.x. Even then, most work with operating systems and browsers that the companies that provided both dropped support for years ago.

In fact, Ajax, rather than being a technology that’s heading out the door, could actually be one of the few open doors left for the people who have not been able to buy that new Macbook Pro, or dual-processor Dell machine. Microsoft, Sun, Apple, Adobe–any one of these companies would leave the less affluent in the dust in a heart beat. The web page is the great equalizer on the internet.

I do somewhat agree with Dare, in that desktop development systems that incorporate Ajax-like technologies, such as JavaScript, will grow. I imagine that Flash/Flex, OpenLaszlo, and WPF/E will get a following and do well. But their health is not negatively correlated with the health of Ajax, with one gaining only at the expense of the other.

Ajax isn’t just a name or a set of technologies: it’s a way of pulling out as much functionality as can be pulled out of a web page as possible. The desktop applications such as Google’s office killers get a lot of the publicity, but the real power behind ‘Ajax’ is little things like comment live preview, Flickr’s in-place edits, or WordPress’ expandable form elements. It’s deleting a row and not having to re-find your place as the page loads. It’s zooming in on a picture, mapping out a route on a map, live updating unread feeds, and a host of other ways of Doing Things Better.

If there’s anything to worry about with Ajax is that sometimes accessibility and validity of web page contents are sacrificed for ‘cool effects’. That, and the hype. By hyping Ajax as a ‘thing’ than it becomes easier to dismiss that ‘thing’ in favor of other ‘things’. But the concepts, effect, libraries, tool, techniques, go beyond being just ‘a thing’–it’s just the way web development will be done in the future. You can no more say that its day is done, as you can say that the hyperlink is old and therefore passè.

Dare also mentions about Java being the most used language today. Frankly, I doubt that it is the most used language. I would say that JavaScript is the most used language, followed closely by PHP. Java is most likely the most used for corporate development, but I don’t think it can compete with all the folks running simple little PHP applications just to upload their photos. Or post thoughts online, like this one.

For every person using a WebLogic or WebSphere application, there’s ten thousand webloggers using WordPress. For ever consumer of EJBs, there’s a thousand people using Gallery. For every web site that runs off Tomcat, there’s a million, or more, running PHP, Perl, Python, and Ruby. Google and Yahoo big users of Java? MSN the same with .NET? None of them would be anything without the millions, billions of simple web pages the rest of us produce.

Now is when things are really starting to get good. More web services, more semantics, more agreement among the browser developers, advances in the technology–better graphics, better JavaScript, better CSS and markup, and interesting twisty new ways of bringing it together…give it up? Not likely.

Of course, I’m finishing up a book on Ajax, and it’s natural I’ll say these things. But I didn’t write this book for the Mega-tool developers, the Kool Kids, or those who seemingly want to replace Photoshop or Office with online tools. I certainly didn’t write it to support the la-la land that is Silicon Valley, or the megapolis that is Microsoft. I wrote the book for the webloggers and the Gallery users; the folks running an online store, a corporate site, or an online publication; those digging after knowledge, and the knowledge providers; those who come to the web to teach and those who come to learn. Saying Ajax is ‘going away’ makes as much sense as saying all of these are going away.

Categories
Programming Languages

Perfect example

Recovered from the Wayback Machine.

Here’s a perfect example of how the computer field is broken:

In a post at Coding Horror, based on earlier posts at Imran on Tech and Raganwald, the author parrots what the others state, that programmers can’t program. With lots of exclamation points.

Why make such a breathtakingly grandiose claim? Because of what happens in interviews. It would seem that the originator of this newest fooflah created a series a tests given during the interview process and found:

After a fair bit of trial and error I’ve discovered that people who struggle to code don’t just struggle on big problems, or even smallish problems (i.e. write a implementation of a linked list). They struggle with tiny problems.

So I set out to develop questions that can identify this kind of developer and came up with a class of questions I call “FizzBuzz Questions” named after a game children often play (or are made to play) in schools in the UK. An example of a Fizz-Buzz question is the following:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Want to know something scary? The majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

Jeff Atwood of Coding Horror also goes on to quote others who run into the same problems: interviewees can’t seem to do even the simplest coding tasks during interviews. These gentlemen completely ignore the environment and focus on the grossest of generalities:

Programmers can’t program.

Here’s a clue for you: I don’t do well in programming tasks during interviews, and I’ve love someone to come into my comments and tell me I can’t program based on this event. No, I’ve only faked it while working for Nike, Intel, Boeing, John Hancock, Lawrence Livermore, and through 14 or so books–not to mention 6 years of online tech weblogging.

In fact, you’ll find a lot of people who don’t necessarily do well when it comes to programming tasks or other complex testing during job interviews. Why? Because the part of your brain that manages complex problem solving tasks is the first that’s more or less scrambled in high stress situations. The more stress, the more scrambled. The more stressed we are, the more our natural defensive mechanisms take over, and the less energy focused into higher cognitive processes.

Why do you think that NASA, the military, and other organizations training people for high risks jobs spend so much time in simulation? Because they want the tasks to be so ingrained that in a stress situation, the people’s responses are almost automatic.

If you add the potential for embarrassment on to the strong desire to do well, the need to get the job, toss in a panel of arrogant twats sitting around a table looking directly at you while you do your little tests, and you have the makings of an environment that almost guarantees the elimination of many fine candidates.

Who does well in these kinds of testing situations? Good testers, the supremely self-confident and equally, typically arrogant, and the people who don’t care: none of which is necessarily the best candidate.

The whole purpose of tests such as these are not to determine if a person has programming capability–how can one stupid test determine this? What these tests do, though, is add to the self-consequence of the person doing the interview.

“I can do this, but all these people can’t. Therefore, I’m so much better.”

It’s also a lazy interview technique, which shows that HR associated with the company doesn’t give a crap about the IT department.

Some justify such tests with, “We need people who can do well in stress situations.” Bilge water.

The stress one goes through when one is an outsider faced with a bank of insiders, is completely different than the stress an individual goes through when they’re part of a team trying to fix a problem or roll out a product. Comparing the two is ludicrous, and nothing more than a demonstration of completely two-dimensional thinking: one form of stress is completely the same as another. My god, no wonder we’ve had few tech innovations lately if this is demonstrative of leadership in IT.

Having candidates bring in samples of code and having the interviewer and interview team review such, and question why decisions were or weren’t made is an excellent way of getting insight into the person’s problem solving skills, without the trained dog and pony show. Asking a person what approach they would use in a situation is superior to doing a random memory test on keywords. Providing applications and having the person provide their own critique is an amazingly effective way of getting insight, not only into their problem solving skills, but also into their personality. If they point out errors but do so in a thoughtful manner, it’s a heck better than doing so in as scathing a manner as possible.

Looking at past applications or effort is another effective approach. New programmers with no job experience can provide pointers to open source applications; experienced people who have worked in an NDA situation can provide pointers for discussions and work online: heck, Google the person’s name–that will tell the interviewer much more about the person than a silly programming test.

That primitive techniques such as the abysmally stupid “FizzBuzz” approach are used shows that companies are still missing out on good people because they have idiots doing most of the interviews.

And making the leap between how people do on interviews into such grand claims that programmers can’t program demonstrates that idiocy travels up the food chain.

You know what’s especially humorous? All the people who solve the test questions in the comments. What possible reason would a person have to do such a thing? It’s completely irrelevant to the environment in which these so-called tests are given. This no more shows that these people can program, then it shows that the other people can’t.

The lack of logic in this whole thread is amazing.

What’s less funny, though, is the slavish adherence to Joel Spolky’s elitist crap. Joel runs a smallish computer company with limited products: what the hell makes him the definitive answer on these topics? Perhaps the people should spend less time making pronouncements, and more time developing independent thinking skills.

Many of the comments in the Coding Horror post do mention these concerns, and provide other effective approaches to interview. If the people who create these tests will actually read these responses, some good will have come from the discussion.

I have found, though, that people who write these kinds of tests aren’t always willing to considering other options. The other approaches just aren’t ‘clever’.

Categories
Internet

Distance learning

Eric Langhorst is a history teacher in Liberty, Missouri. He’s been specializing in ways of using the internet in order to aid in the teaching of history, and has posted conference notes about his research for the MidWest Education Technology conference here in St. Louis.

It’s a nice presentation, but it does demonstrate the growing importance of global broadband coverage. Our community is looking at wide-area wireless for the county, and all the public library system now provides free wireless, as does the downtown St. Louis area.

Lee at Black River News mentions the new Missouri Virtual School program, which lets kids take classes over the internet. This would be particularly valuable for rural areas, especially within school systems struggling with funding. It’s unfortunate that there’s no plan for providing the internet coverage into those areas more likely to benefit from such.

Categories
Technology

Browser testing

Roger Johansson details his browser testing strategy and it is far more extensive than mine–at least for CSS and markup, though I go much further when it comes to JavaScript.

  • I start with, and use extensively, Firefox on the Mac. The main reason why is the extensions, specifically Firebug. I think that Joe Hewitt’s Firebug is the third single-most important component of today’s new web development–following on Mozilla’s innovative architecture, which enables such extensions, and REST.
  • I then test with IE7 on Windows XP. Why? Because if anything I do is going to break, it will break with IE. I no longer have an IE6 box, but I do use Total Validator to take screenshots in IE6 and Konquerer if I’m working on issues of design.
  • Next, I test with Opera on the Mac, which helps me discover those things that Firefox allows that aren’t necessarily standard. I find Opera to be the most standards compliant browser.
  • Then I go to Safari and the most current WebKit, both still on the Mac.
  • I need to test with Camino and Flock more. However, my logs tell me I have people using IE, Firefox, Safari, some Opera, rarely Konquerer, and older versions of IE, on Windows and the Mac. These are my target audiences.
  • I tested the book with OmniWeb, but I don’t have it any longer as it’s a ‘cost’ browser and the cost isn’t justified.
  • I test with Netscape and Opera on Windows XP, last. I used to test for IE6, and I did for the book. However, I don’t have access to a IE6 machine, now, so am dependent on IE6 users to tell me if something breaks.
  • I provide a mobile stylesheet, which Ralph at There is no Cat, was kind enough to test for me. I also use Opera’s mobile feature to test.

One thing I talked about in the upcoming Adding Ajax book is understanding your audience before making a choice of target test browsers. If we use progressive enhancement as a development approach, which means creating the functionality without the use of scripting and then gradually adding script effects, then we always have a natural fall back if a script effect doesn’t work with one browser or another: just disable the effect for the browsers that choke. Those few who are still using IE 5.5 on the Mac (why?), or IE 3.2 (WHY!), at least get a decent shot at a workable page, if not a terribly interactive or visually appealing page.

Then there’s my feeds. If all else fails, I provide full content feeds.

Roger’s mention of semantic markup is spot on, also. I haven’t been pursuing this as diligently as I should, and plan to go over my design one more time and look for better uses of markup—after the book has gone to production, of course.

My biggest design problem? Fonts. I can never find a font that seems to look good everywhere, and that scales as well as I’d like for each resolution. That’s mainly because I haven’t taken the time with fonts as I should. Another thing to explore as soon as the book is finished.

Oh, and this site is using a conditional IE stylesheet.