Category: Technology

Categories
Diversity Technology

Women hackers

Recovered from the Wayback Machine.

According to Techcrunch, the winning team of hackers at Yahoo’s HackDay was an all woman team. The project was a mobile computing device that one carries in one’s handbag or pack, which is a camera integrated with a pedometer that takes pictures every few steps, which it then posts it to Flickr using the Flickr API (a Yahoo! API).

The winning team consisted of Diana Eng, Audrey Roy, and Emily Albinksi. From lookups on their names, Diana and Emily have appeared in Make magazine for their techno-clothing (and Diana for her work with the popular TV show, “Project Runway”), and Aubrey looks to be an MIT engineer who has done some very interesting stuff with architecture, and who works with Sharpcast.

Some of the responses have been congratulatory, but I’ve seen a lot of “beaten out by a girl” crap, and it’s too bad that when women do participate, and participate very well, their effort is dismissed primarily because they are women. As such, I hate to join these others in making a point the winning team’s sex, because I imagine the three would like to think of themselves as complete hackers first, who happen to be women.

But I’m so damn proud!

Update

Beyond Caffeine wishes the project had been something non-gender related. True, the device was installed into a purse, but could be connected with a GPS device instead of a pedometer and installed into a backpack and allow people to follow along on a hike through the Alaskan outback, as much as a jaunt through the hills of San Francisco. Travel magazines would be of interest, and organizations such as the US Geological Service. Think of it: hands free static imaging, immediately posted to a group of interested folk.

If we keep putting caveats on how women must act and what we must do in order to establish our ‘cred’ with the tech community, we’ll never achieve any level of success because the bar continues to be moved. We seek to join the profession, but when we do we’re told we must be more visible; when we are, we’re told we must only do that work that satisfies a predominately male view of what’s “useful” and what’s not.

This is women being hackers, good hackers–plain and simple.

Categories
Technology Weblogging

October and November

Recovered from the Wayback Machine.

Despite temperatures this coming week into the 90’s and potentially breaking all records, we are into fall and our best color should be coming out in the next two or three weeks. Now is when I need to get into my car and get the fall color photos I’ve been wanting, and to visit all the mills I’ve not been able to reach easily from St. Louis.

The traveling will also take me to Columbus to the state historical society to view some microfiche, and perhaps some other odds and ends places. I also have the book deadline for the middle of November, not to mention the work ongoing at my sites.

Today I made a static copy of the old Burningbird, using the Unix utility wget to create a mirror image; including getting copies of all photos and stylesheets and such. With this copy I can eliminate the WP installation and database. I can also make permanent redirects from various pages to the new sites when they’re up. (The way WordPress modifies .htaccess made this difficult at times.)

Both the main page and the feed are now redirected here, and we’ll see how this shows up in aggregators. Bloglines shows the new site, but still lists it as the old feed URI. Since this is a permanent redirect it should change the adress, as well as redirect the content.

This weblog is the last of the subdomain sites. The old reasons for creating subdomains, such as weblog.burningbird.net, rather than sub-directories, such as burningbird.net/weblog, don’t seem to be as important–people really don’t look at URLs, other than those that are too long to do anything easily with. The thought that weblog.burningbird.net is ‘more professional looking’ than burningbird.net/weblog assumes people pay attention to this, and I think people are hit with enough demanding their attention that they have none to spare for such fooflah.

As for using relative addressing for stylesheets and such, most of us use dynamic functionality to generate pages, and again, this doesn’t seem to be the issue it once was. It also doesn’t impact on search engine optimization–the bots are smart enough to know when a group of sites all belong to the same place.

I’m also never going to use date in my URLs again–why ever did we decide this was the way to do things? The date just makes the URL messier, and it’s a bitch to deal with backups. You have to watch us techs: we’re like your kids in that we say the darndest things at times. Use dates in your URL; don’t use dates in your URL.

If you comment and it goes into moderation or you email and I don’t respond right away, think of me at a mill surrounded by fall foliage, taking photos and enjoying the cool, crisp autumn weather. Or think of me in front of my computer intently working away–cat on my lap, head turned up to me going, “my turn, my turn”. Whichever scenario turns you on.

Categories
JavaScript

Accessibility, Ajax style

My editor, Simon St. Laurent, and I both agreed that with the new book, Adding Ajax, the work would all be valid and accessible. Some of this effort is easy; much is not.

One particular area has to do with updates. When using a screenreader, or when using a screen magnifier, if the data in the page is updated, the web page reader may not be aware that such updates have taken place. You then need to provide some form of cue, and I don’t mean the color fade (which if you think on it, is about the most unaccessible Ajax effect there is).

As has been discussed elsewhere if screenreaders didn’t support JavaScript, life would be simpler because the readers would then get the no script version of the page contents. Screenreaders do support JavaScript, though, and that plays all sorts of havoc.

Anyway, while researching the current state of accessible Ajax (which threatens to be an oxymoron), I came across some resources I thought might be of interest.

Regardless of whether you’re a web developer or not, it’s a good idea to test your page as it appears in screenreaders. I use Apple’s VoiceOver, which is built into Mac OS 10.4 and up. Unfortunately, its behavior differs from other screenreaders, such as JAWS.

Categories
Technology

You say agile I say chaos

Recovered from the Wayback Machine.

I skimmed through Steve Yegge’s “Good Agile, Bad Agile” piece and was thinking of responding, but luckily Dare Obasanjo responded first and said all I’d say and more–especially as regards to the ‘star’ treatment accorded to developers at companies like Google, and the employees gratitude back for being ‘so well taken care of’.

Dare writes:

I remember interning at Microsoft five years ago and hearing someone say how grateful he was for “the things Microsoft has done for me” and thinking how creepy and cult-like that sounded. A company pays you at worst ‘what they think they can get away with’ and at best ‘what they think you are worth’, neither of these should inspire gratitude. Never forget that or else you’ll be on the road to heartbreak.

We should respect the companies where we work or, at a minimum, respect our responsibilities as employees; but gratitude and loyalty, both, will eventually lead to heartbreak.

Categories
Technology

PPK at SxSW

PPK, writer of QuirksMode, has a panel proposal in at SxSW I wanted to point out to those of you attending. PPK is well known in the JavaScript circles and someone I respect for his good, commonsense approach to web page development–particularly with JavaScript. Yes, I am pointing you to a competitor, because he’s worth being pointed to and his sessions sounds to be one of the more interesting at SxSW.

My panel will not be technical. Instead, I’d like to address some of the social issues that face JavaScript nowadays, issues I also touched on in my JavaScript and “serious” programmers entry. Not entirely coincidentally, this entry has about the highest overall comment quality on the QuirksBlog, which means (I suppose) that people are truly interested in the subject. In turn, that means the panel could prove to be quite interesting.

It’s not easy finding the proposal when using Firefox on the Mac, because something in the panel picker causes the browser to crash if you try to expand the list. Unfortunately, there’s also no title search (which I guess demonstrates that maybe the SxSW people should consider going to this session.) Frankly, it’s not easy finding it with any browser–the interface really sucks. But I persevered and found the following:

Now that JavaScript is in fashion again, we’re facing a few non-technical issues that may be more important than the technical ones. There are two ways of writing JavaScript: the client side and the server side way. They focus on different things: application development vs. CSS/accessibility, respectively. Is one of the two clearly “right”, or is there place for both? What’s going to happen once the Ajax hype folds?

PPK lists out a set of issues related to today’s use of JavaScript/Ajax, in particular the approach the application developer takes as compared to the web developer. Among some of the issues:

The web developers’ strong points are good knowledge of accessibility, HTML and CSS, as well as immersion in the ideas of the CSS revolution. Their weak points are sloppy spaghetti-coding and a general lack of knowledge about application design.

The application developers’ strong points are strict coding practices and lots of knowledge about application design. Their weak points are a total disinterest in accessibility and sloppy HTML coding practices.

This is a discussion I’ve indulged in at my site, in particular, this new breed of JavaScript developer who is completely indifferent to standards and accessibility. I’d like to think two decades of development and a comp sci degree doesn’t mean I’m on the other spaghetti coding side, but there are people who have come to JS through the web page design who aren’t familiar with good coding practices. Chances are they’ll never become aware, because the application developers tend to be cryptic, as well as being a tad over-engineering.

This promises to be an interesting panel. If you’re going, find it and click the “Pick Me” associated with the proposal.