funkatron.com

Links for 2010-03-08 [del.icio.us]

2010-03-09T00:00:00-08:00

OpenClipart Beta - OpenClipArt

Links for 2010-03-01 [del.icio.us]

2010-03-02T00:00:00-08:00

bytespider's jsOAuth at master - GitHub
"jsOAuth is a javascript library implimenting the OAuth protocol. jsOAuth aims to form the basis of custom service objects such as Twitter. Both Yahoo and Twitter OAuth services will be catered for in the first release."
Phishing Attacks Using Social Networks

Links for 2010-02-18 [del.icio.us]

2010-02-19T00:00:00-08:00

Sammy
"Sammy is a tiny javascript framework built on top of jQuery. It’s RESTful Evented JavaScript."

We’re the Stupid Ones: Facebook, Google, and Our Failure as Developers

2010-02-16T00:43:44Z

Photo by michiel

Normally I try to chew on an idea for a post for a few days; it lets me sort out my thoughts and form some kind of thesis. I’m totally not doing this here, though, so I should preface this with a note that I could be completely off-base. But I don’t think so.

Discussion about how we interact with computers heated up recently with the introduction of the iPad. Lots of nerdy types (myself included) were frustrated that Apple had introduced not a tablet “computer,” but a big iPod Touch. They’re both computers, of course, but the way we interact with them is different: the modern computer interface uses a multitasking windowing motif, and the iPod/iPad interface is fullscreen and single-task focused.

As a Nerdy Power User, I am well-versed in how to navigate a multitasking interface, and for the most part I understand how and why it works the way it does. I, in fact, enjoy learning about the intricacies of these kinds of systems. So when I use a single-task interface like that of the iPod Touch, I frequently bash my noggin against the barriers it imposes. Copying a URL from the web browser to my Twitter client takes orders of magnitude longer than it would on OS X or Windows, for example.

What I’ve learned from interacting with most computer users, though, is that they do not give a rat’s ass about how computers work. They want to accomplish certain tasks, and will do this in the way that is most sensible and direct for them. And the way they end up accomplishing these tasks within the multitasking window motif is typically not the way I would do it.

The recent fiasco on ReadWriteWeb, where a RWW article became the first Google result for “facebook login,” is a classic example of this. And, unfortunately, so is the reaction of most Learned Computer Fellows: one of mockery and derision, admonishing the confused users for being stupid, incompetent, or lazy.

I’ll admit that I took some glee when I first saw the numerous comments on the article; I love a humorous clusterfuck as much as the next guy. But seeing some of the reactions by the Very Smart Computer People, I began to realize that We Are Not Getting It. Consider:

Isn’t this really a failure of Google? How did it become so easy to game search engine results that an article about Facebook and AOL became the first result for ‘facebook login,’ instead of the obvious thing people are actually looking for?
How is it the fault of the users when we present them with multiple, barely-differentiated text fields within the same window. Is it really surprising that they don’t understand the differences between each? And is it surprising that they choose to use the one which works with more natural language, rather than entering syntactically-unnatural domain names?
There is LOADS of anecdotal evidence that most users simply use search engines as a sort of natural language CLI. Shouldn’t we be designing interfaces that work in the way most natural for the majority of users?

These people have better things to do with their days than tweaking out the spacing in their browser toolbars. A computer for them is a utility. One that is increasingly complex, and one that is used because it’s the only option for accomplishing certain things – not because it’s a good option.

It’s kind of like the Photoshop Problem: when people want to crop a picture, we give them Photoshop. Photoshop is a behemoth application with nearly every image editing and touchup function imaginable, and it is terribly complex. Now Photoshop is an impressive tool, but only a very tiny percentage people need the power it offers. The vast majority just want to crop their ex-husband from the photo and let their friends look at it. But even iPhoto, the poster child for Apps So Easy Your Grandparents Can Use Them, continues to pile on features and complexity.

When folks need an elevator, we should give them an elevator, not an airplane. We’ve been giving them airplanes for 30 years, and then laughing at them for being too stupid to fly them right.

I think we’re the stupid ones.

Update

As I said at the start, I wrote this piece a bit off the cuff, so upon further review I think I could have made it a bit clearer. First, a couple great rebuttals I read:

I posted a comment on Phil Crissman’s blog, which I think explains a bit further what I’m thinking, and addresses the notion that some learning may still be required. To copy and paste myself:

I certainly don’t think that the computer can become (anytime soon) a magic box that determines our whims, nor do I think that people shouldn’t have to learn some things.

What I do think is that the current interface modern OSes on computers provide is simply overwhelming for most users, to the point that it’s very challenging to learn how to accomplish tasks without a very significant investment of time. Driving would be a good example of a task that does require investment of time, but is not so overwhelming that the vast majority of people fundamentally get it wrong: you don’t see people steering with their feet, or accelerating and braking with the radio. I’d argue that modern computer interfaces, in a rush to offer flexibility and capability, make it possible to steer with your hands, feet, teeth, and knees — and don’t make it particularly clear which one is best.

Update 2

Some more responses:

Feel free to forward me others; I think I’ve given up trying to track them down for now.

Links for 2010-02-11 [del.icio.us]

2010-02-12T00:00:00-08:00

wattz.net :: programming, design, and wtf ever
"a simple library I created to generate html forms using pure javascript. Modeled closely after Django forms, jsforms allows you to create forms using only js syntax."
js-forms - Project Hosting on Google Code
"A JavaScript port of Django's awesome form display and validation library"
Iconic Icon Set – 103 icons in raster and vector format — Some Random Dude
"Iconic is a minimal set of icons consisting of 103 marks in raster and vector formats — free for public use."

Elizabeth Naramore Joins the Spaz Team

2010-02-05T01:02:20Z

I am super proud to announce that Elizabeth Naramore has agreed to become Support Lead for Spaz. Liz is an accomplished PHP developer and a tireless community organizer for open source. I am honored that she’s chosen to help Spaz.

If you are interested in helping with user support for Spaz, please check out the Spaz User Support Team Google group, and tell Elizabeth you want to help.

Links for 2010-02-01 [del.icio.us]

2010-02-02T00:00:00-08:00

CSS3 Gradient Generator

Links for 2010-01-25 [del.icio.us]

2010-01-26T00:00:00-08:00

When Your Wordpress Blog Gets Hacked | Snipe.Net

Links for 2010-01-22 [del.icio.us]

2010-01-23T00:00:00-08:00

nzakas's computer-science-in-javascript at master - GitHub
Collection of classic computer science paradigms, algorithms, and approaches written in JavaScript. All of the code is available under an MIT License.
mtrack: a software development tracker + wiki - Evil, as in Dr.
"Enter mtrack; on one hand it's a clone of many of Trac's features (possible due to their pragmatic BSD license), but on the other it has some refinements in terms of its workflow. What's important to me is that it is built to work with multiple code repositories and allows breaking out information on a per project basis. It also tries hard to avoid losing your wiki or ticket edits if someone else updates things while you're working."

Ron Devera Joins the Spaz Team

2010-01-11T15:09:06Z

I’m really happy to announce that Ron Devera has agreed to become the UI Lead for Spaz Desktop.

Spaz has been a very informally organized project since I began it back in spring 2007. A number of people have contributed important pieces of code, and support was primarily handled by @kibitzer for over a year.

So why a title and all that? It seems like a good idea at the moment. I’ve been trying to establish more structure in the development and support efforts of Spaz to make it easier for others to contribute, including Lighthouse (development coordination) and Tender (user support) sites where volunteers can see who needs help and what needs to be done. Adding an “official” team member is a part of these efforts.

Ron is a smart, talented developer, with a diverse set of skills, and he’s demonstrated an ongoing commitment to making his contributed “Leopaz” theme very high-quality. He’s a strong JavaScript, Ruby and HTML/CSS dev, and his attention to detail has made Leopaz the strongest theme Spaz offers. I’m very excited about having him a part of the team.

An Open Source Milestone: Spaz webOS 1.0

2009-12-29T21:01:48Z

I really don’t like to toot my own horn. Well, actually I do, but I’m also embarassed by it, so writing the title for this post was a bit painful. Nevertheless, I do think it’s accurate: Spaz webOS 1.0 is now available in the Palm App Catalog, and that’s a significant milestone for the project, and for open source on webOS.

I first started playing with webOS a year ago, over Christmas break at my day job. In June, Spaz webOS was in the App Catalog at release, and back then I was quite proud of the fact that we’d been able to ship a truly open source, transparent app on the first day of a new platform. And now, a year since I first cobbled together a Hello World in Mojo, Spaz has reached a reasonable level of maturity – at least as mature as something called “Spaz” will ever have.

Originally I was going to call this release v0.6. I am shy of using 1.0 because I am painfully aware of all the flaws in my software, and it certainly never feels “done” or “ready” to me. However, a recent discussion with Keith Casey led me to think more seriously about using the “1.0” designation – Spaz webOS is very much Safe To Use, but a pre-1.0 version might make some potential users to think otherwise.

And potential users are a bit more of a consideration now, because in a couple weeks (probably the week of January 11), Spaz webOS will start charging $2 for App Catalog downloads in the United States. This is something I’ve been planning for a while, but it’s still stepping out a bit, both for me (I’ve never charged for software before) and for open source software in general. To be clear, here’s how it will work:

Spaz webOS will cost $2 to download in App Catalog markets that support payments. Right now the only market that supports payments is the US. It will be free in all other markets.
Spaz will still be completely open source. The full source code will always be available.
I will not stop users from packaging and installing Spaz webOS themselves. In fact, I encourage it! I always need more testers, designers and developers. Hacking, patching, and messing with Spaz are fully endorsed. If you can’t help in one of these ways, consider donating to the SpazCore project.
Revenue made from paid App Catalog downloads will be used to support development and offset equipment and hosting costs. I’ve never made any money from Spaz, and despite some generous donations over the past couple years, I’m still well in the red. I don’t do this for the money (obviously), but lightening the burden and compensating myself and other people who have given their time for Spaz is reasonable, I think.

Another thing that isn’t changing is the principles that guide the Spaz project. I wrote up a statement of purpose a while, back, which I’ll replicate here:

Spaz was built for the sake of building it. It is not a means to an end. However, creating it has had several good consequences.

Spaz demonstrates that making things is good, and sharing how you make them is better.

Spaz is a necessary counter to closed, hidden technologies. Spaz must always be open.

The value of Spaz does not lie in the judgements of others, but in the process of building it, and the enjoyment derived by those who use it.

We welcome anyone who wishes to participate in the Spaz Project with open arms, as long as they understand and respect the purposes of the project.

The Spaz project values clear and open communication between participants.

This is how I think software should be made. If you agree, I hope you’ll consider supporting what we’re doing in a way you see fit. We always need help!

Thank you for making Spaz far more than I could have imagined.

ZendCon 09: PHP, JavaScript, and RIAs, Oh My!

2009-10-24T01:20:52Z

Photo by DragonBe

No more travels for me until SXSW in March, I believe. I’m far too tired.

Did I say that? I actually knew very well that a week later, I would be traveling to San Jose for ZendCon 09. Foolish me.

I spoke at ZendCon on Building Desktop RIAs with JavaScript and PHP. I’ve given this talk other places, but this time I showed off some fun PHP-powered jQuery within Titanium. Here’s a snippet:

<script type="text/php">        
    /**
     * run the passed function when DOM Ready event runs 
     */
    $jQuery()->ready( function () use (&$jQuery) {
        /**
         * set some CSS properties 
         */
        $jQuery('#phpjQ')->css('display', 'none')
                        ->css('background-color','#333')
                        ->css('padding','10px')
                        ->css('border','2px solid #000');
        /**
         * bind a delegated click event to the passed function 
         */
        $jQuery('#invokePHP')->live('click', function () use (&$jQuery) {
            /**
             * set the text color and reveal 
             */
            $jQuery('#phpjQ')->css('color', 'red')->slideToggle(500);
        } );                
    } );
</script>

Building Desktop RIAs with JavaScript and PHP

Slides
Code: Server-side PHP, AIR, Titanium

Codeworks 09 talks

2009-10-09T21:48:17Z

Photo by caseymultimedia

Unlike some others, I only participated halfway in CodeWorks 09, doing the east coast leg of Atlanta, Miami, Washington, D.C., and New York City. It was an enjoyable adventure, and I liked being able to try different approaches in my talks and see what worked best.

I was able to record audio with the voice memo app on my iPhone. Getting hour-long recordings off is a bit of an adventure – they refuse to appear in the voice memo playlist in iTunes, so you have to find the files in the MobileSync backups folders and do some renaming work – but they turned out pretty well.

Introduction to CodeIgniter

Building Desktop RIAs with JavaScript and PHP

No more travels for me until SXSW in March, I believe. I’m far too tired.

Results of Spaz webOS Pricing Survey

2009-07-31T17:40:32Z

Photo by gusset

Yesterday I put together a short survey that asked some questions about what people would be willing to pay for Spaz webOS. It’s been my plan all long to change a small fee (when possible — you can’t yet in the Palm App Catalog) for Spaz webOS, and use the revenue to support further development. Since I believe strongly that Spaz must be an open, transparent project, here are the results so far from 145 responses:

PDF of Spaz webOS Pricing Survey Response Summary data

…and here are some comments on the results:

What is the most you would pay to purchase Spaz in the Palm App Catalog?

From doing a little math on this, it seems like $2 is the optimal price point in terms of revenue generation, followed closely by $3.

PDF of “revenue potential” data

What 1-3 features would make you more likely to purchase Spaz in the app catalog?

First off, lots of people ignored the request to pick 1-3, which isn’t surprising (you couldn’t set a max number of choices). That being said, 4 items were far and away the most popular choices

Faster Performance (56%)
Spaz does seem to perform slower than comparable apps. Part of this is because we use a combined timeline, and therefore it takes longer to build results. We also initially requested a LOT more messages from Twitter at startup than comparable apps, and processing them takes more time. We’ve lowered the default numbers (you can up them in prefs), but it’s still higher.

We’ve also had some CPU usage issues. Those have been dramatically lowered since initial release, but there’s probably more we can do. This shows up especially while processing new messages.

The other issue I think this response refers to is sluggish scrolling speed. This one perplexes me a bit, but I’m guessing we may be running into performance limits of the Pre’s webkit renderer. We’re going to do some experiments with stripping out CSS styling and markup on our timelines to see if the scroll speed improves in either case. If so, we will need to modify how we style and/or build the markup for our timeline.
Direct uploading to image hosting services like Twitpic (54%)
This was really close to #1, which tells you how badly the lack of direct file upload APIs in webOS is hurting devs. What’s most frustrating is that the email-based workarounds actually took longer to implement than direct uploads would — we already have plenty of code from the desktop app we could have adapted. Here’s another plead to Palm to please expose the file upload APIs to 3rd-party developers ASAP!
New message notifications even if the app is closed (42%)
I’ve heard this a lot. I kind of assumed people would just leave an app open if they wanted it still running, but how I use things isn’t necessarily how others will. One consequence of implementing this will be reduced battery life, so we will need to be careful about it. Note that Palm recommends not doing background network requests more than 15min per hour. We won’t exceed that if and when we do implement this.
Facebook support
This one kinda surprised me. I only added it as a bit of an afterthought, but I suppose it makes sense, especially since there’s not a good native Facebook app for the Pre. I actually know very little about the Facebook API and am not super duper excited about building for their walled garden, but if someone wants to build a SpazCore lib for it, we’ll probably implement something.

Also of note were some of the “Other” responses. They included:

“More optimized code (use less cpu!)”
This falls under Faster perf, fo sho.
“tweet with google maps link to current location”
This is on the list to get implemented
“hit user pic in timeline to @reply”
We’re going to implement something that lets you do actions on a message without going to the detail view. Kinda sucks right now.
“low power consumption”
The way you do that is to make fewer network requests. This responder will not want background checking, then 8)
“more identica/laconica support”
I’d like to see this happen too. If you want it to happen, volunteering to code a Laconica-specific API (or somehow scraping up funding to sponsor development) would help us out a lot. We don’t have time to do much with non-Twitter APIs right now.
“Livejournal support”
Seems like a microblogging client isn’t a good match for this, but if we add ping.fm support, you should be able to post to LJ through that. As for reading LJ posts, I think RSS feed support would allow that.
“It needs a non-offensive name before I would purchase it anywhere”
We had to get one of these, although I’m surprised we only got one in nearly 150 responses. It’s not changing. Read the FAQ. Sorry!
“Since last 2 updates it really drains my battery. LOVE it’s look and feel though.”
These are the kinds of things we need to get reported to us. Can’t fix it if you don’t report it. Go to our support site and file an issue, please. Please make sure Spaz is the only culprit involved, though.
“Direct blip.fm support (streaming via clicking a link)”
That would be interesting. If someone’s willing to look into it dev-wise, I have no issue with it.
“Why? When tweed is free. And there’s more twitter apps to come.”
No applications are allowed to charge for apps at the moment. That will change in the future, though. I wouldn’t assume Tweed will remain free, but I have no idea what their plans are.
“Copy and paste”
Talk to Palm, dude. 8)
“Change the name!!!”
Okay, maybe we got another one, but this didn’t claim I was making fun of physically or mentally disabled people. Sorry, not changing.
“None”
This surprised me a little. You could have written “shits money and cleans my house.” Surely that would make you more likely to buy it, yes?

The Spaz Project Statement of Purpose

2009-07-26T05:33:44Z

Photo by sidewalk flying

This is something I’ve been thinking about and working on for a few weeks now. I wanted to post it here both to understand my motivation, and to hear feedback.

Spaz was built for the sake of building it. It is not a means to an end. However, creating it has had several good consequences.
Spaz demonstrates that making things is good, and sharing how you make them is better.
Spaz is a necessary counter to closed, hidden technologies. Spaz must always be open.
The value of Spaz does not lie in the judgements of others, but in the process of building it, and the enjoyment derived by those who use it.
We welcome anyone who wishes to participate in the Spaz Project with open arms, as long as they understand and respect the purposes of the project.
The Spaz project values clear and open communication between participants.

AIR, Titanium and webOS: 10 Things You Can’t Do in A Browser

2009-07-13T14:29:57Z

Photo by Rob Watling

In the past two years I’ve spent most of my free time working on desktop applications written in JavaScript, HTML and CSS. I write them on top of web runtime platforms like Titanium and Adobe AIR, and more recently Palm’s webOS. In this time, I’ve heard a misconception raised repeatedly: that “local” (desktop or mobile) applications written on top of web runtimes offer no advantage over remotely-hosted, browser based apps. Or, to paraphrase something I overheard recently:

HUH huh your app is written in JavaScript and HTML, why don’t you just load the web site DURRRR.

I suppose this kind of thinking comes from the JS+HTML+CSS being almost exclusively used for web site front-ends for so many years. It’s a knee-jerk reaction, much like the one that says “oh, you can’t use PHP in the ‘enterprise’” or “Oreos aren’t for breakfast.” Proved my mom wrong on that one.

So, I decided to make a list of what things you can do in a web runtime platform that you can’t do in a browser. Now some of these vary depending on the platform or the browser, and I’ll try to make note of them in my list:

Cross-browser compatibility issues are a thing of the past
I should offer a caveat here — even though the rendering engines are the same, you’ll sometimes run into OS rendering differences. AIR, for example, supported CSS3 box shadows on OS X until v1.5, but never did on Windows. But the differences are far, far smaller than you’d see between, say, Safari 3 and IE6. Trust me — you will love not having to worry about getting your layout working in some ass-tastic box model implementation anymore
Advanced rendering features (CSS3, etc)
Since you don’t have to worry about looking the same in different browsers, you can take advantage of the special features your runtime’s rendering engine supports. Titanium, for example, supports the same advanced CSS features that Safari 4 does, like box shadow, border radius, and CSS gradients.
File system access
On desktop web runtime platforms like AIR and Titanium, you can interact with the filesystem just like any other application: read, write, and create files and folders with the permissions of the executing user. webOS offers less freedom in this respect, but you can read and write files on a limited basis.
Networking
Both of the major desktop web runtime platforms provide much more advanced networking capabilities than are available within a browser. I’m not much of a networking programmer, but both platforms allow the developer to open TCP socket connections and communicate over them. Titanium seems especially well-prepared in this area, with its ability to leverage Python and its powerful networking capabilities.
No same-origin policy restrictions
If you want to pull data from a web site other than your own in the browser, you have to resort to JSONP — basically an XSS attack waiting to happen — or set up a proxy on your site’s server. Web runtime app platforms don’t have this issue, so you can make XHR calls to any domain you wish, and interact with any APIs.
No need to support non-JS users
This might seem like a small issue, but having to support users who have disabled JS was one of the major reasons I never did serious browser-based frontend programming before I started working on Spaz two years ago. Now the cool kids at SXSW will tell you that “nobody” disables JavaScript, but I think that’s kind of short-sighted.

Nevertheless, this argument and the need for graceful degradation and “unobtrusive” JavaScript become moot in the web runtime app platform. JavaScript is there, it’s expected, and you can’t disable it. So go crazy.
Using/interacting with platform-specific UI elements
This includes things like window chrome, menu systems, Dock items (OS X), menulings (OS X) and the System tray (Win/Linux). Both major web runtime platforms display your application within the native window chrome, allow you to create native menus, and give you some access to the system tray and OS X’s Dock. Titanium is a bit better in this regard in that it inherits the native look of form widgets and scrollbars, and provides access to the OS X menubar (those little icons in the top-right).
Sound playback without plugins
Until HTML5 becomes standard in all browsers and bestows the grace of plugin-less media playback, we’re stuck <embed>ing <object>s in our gorgeously crafted markup. Funk dat. Web runtime platforms provide sound playback APIs that mean we don’t have to stick a Flash applet in our document and hope it doesn’t catch the CPU on fire. AIR has a particularly good playback API (probably because the whole thing is running in a Flash engine. Small victories).
Interacting with other applications/shell interaction
Being able to leverage other applications on the machine/device can be really valuable, especially on Unix OSes (Mac OS X, Linux, etc) that have a bevy of useful utilities available from the shell. Titanium is the only desktop web runtime platform that allows the developer full access to these capabilities; AIR is limited to interacting with other Flash-based applications at this time (although this may change in the future). Runtimes on mobile devices are typically much more limited, although webOS’s Application Manager service does let applications launch and pass arguments to other apps.
Database support
Typically this is implemented either via the HTML5-style database stuff (usually asynchronous) or a platform-specific SQLite (usually synchronous). Out of the box, support isn’t provided for external DB servers (MySQL, PostgreSQL, MS-SQL, etc), but with Titanium this should be possible by delegating to Python or Ruby scripts, or Titanium kernel modules. DB servers that provide HTTP interfaces (like CouchDB) will work fine, though.

All of this doesn’t mean web runtime platforms are going to replace browser-based apps anytime soon. There are clear advantages to remotely hosting an application (speed of updating comes to mind), and supporting an app on a user’s machine brings a new group of debugging headaches. But for applications already chafing at the limitations of the browser, web runtime platforms offer a compelling option.

Spaz 0.5.0 out now

2009-07-09T20:31:59Z

Spaz 0.5.0 went out to the Palm Pre App Catalog today. The coolest new thing is image posting support for TweetPhoto, Twitpic, yfrog and Twitgoo. While webOS still doesn’t have a generic file uploading service that third parties can use, these services support email posting of images, so we were able to build a workable solution using that. It’s not optimal, and as soon as webOS supports file uploads we’ll be there with support for even more services, but it works for the time being.

The other major enhancement in 0.5.0 is with notifications. Previously Spaz on webOS had just used “banner” notifications when new items were loaded, which appear and disappear quickly on the screen. Lots of users asked for what are called “dashboard” notifications in Spaz, though, which are like the ones you get with the email app: an icon is displayed in the corner of the screen, and if you tap it, a larger dashboard appears with more information. These notifications are persistent – they won’t go away until you dismiss them by swiping or tap on them to bring up the Spaz card.

All of these enhancements are available to other webOS developers as well. Because Spaz is open-source with a liberal New BSD-style license, you can use code from Spaz or the SpazCore libraries in your own apps. So if you want to do email-based photo posting to Twitter like Spaz does, you can! And although you are not obligated to tell us, if you do use our code, we’d love to hear about it.

As always, if you have problems, questions or suggestions, talk to us at our Tender-driven support site.

Spaz Comes to the Palm® Pre™: How You Can Be Part of It

2009-06-26T17:24:18Z

Folks who got the fancy lad Palm® Pre™ on opening day found the App Catalog chock full of superapps. One of them is Spaz, a ground-up rewrite of the award-winning desktop application I created for the Adobe AIR platform using pure HTML+JavaScript. Getting Spaz on webOS™ has been a big undertaking for me, and the process has certainly had it’s ups and downs. But I’m proud of the fact that we shipped a truly open source, transparent app on the first day of a new platform.

But much like Spaz on the desktop, this is not a revenue generator for the project. Everyone who works on the Spaz project is a volunteer, and we rely on motivated folks to help us make cool software. It doesn’t need to be a huge commitment — even just getting involved in the discussion and coming up with ideas is a big help. But here’s where we need help the most:

Coding

While I intend to be the lead on Spaz for webOS™ for a while, I really could use help — I’m working in my free time, and that’s pretty limited with a family and a day job. The full source code of Spaz for webOS™ is available on GitHub, and people who want to help make new features happen are encouraged to check it out.

Even if you’re not well-versed in webOS™ coding, if you have a good JavaScript background (or don’t and are just interested in developing one), we need help to build up SpazCore, our component library that drives Spaz for webOS™, and will drive all our projects in the future. Hacking on SpazCore requires no knowledge of webOS™.

Support

We have a brand new, very awesome support site at http://spaz.tenderapp.com/ which is sponsored by the awesome folks at ENTP. We need to direct people there, and we need to get involved in helping them there. We also should build up the FAQ/Knowledge base. In addition, identifying folks on Twitter who are trying Spaz or having issues and pointing them to the support site is very important.

Advocacy

Do you like Spaz? Why? First off, let us know — I’d like to build a repository of positive mentions like that. In addition, telling people about Spaz and encouraging them to check it out is great. Hwoever, this needs to be done in a nice, non-abusive, non-spammy way, and we always need to respect other applications and their developers. THIS IS NOT A COMPETITION — it’s making people aware of quality alternatives to closed, non-transparent software.

Design/UI

I’m an opinionated fellow and rather controlling of how the Spaz apps look, but I also know there are better designers and UX experts than me. If you’re interested in helping with design and UI work on Spaz — including additional themes — I’d love to hear your ideas.

What About the Desktop?

You are not forgotten. Spaz’s desktop client is long in the tooth, and we have Big Plans for a full rewrite based on SpazCore. That’s long-term though, and in the interim work is still being done on the current Spaz codebase, including adding multi-account support and improving filtering capabilities. We also intend to transition away from AIR to the Titanium platform.

So if you want to stop bitching in your Twitter account and actually make things better, here’s your change. Drop me a line at spaz@funkatron.com and we’ll sort out the best way for you to kick ass.

Searchatron, Titanium, and Funding Open-Source Development

2009-04-15T17:07:59Z

A few of you may know of a small app I did in AIR a while back called Searchatron. It’s mostly a proof of concept, but does have some usefulness in making it a bit easier to track multiple Twitter search queries. Searchatron uses an MVC-style pattern similar to how the next version of Spaz will be built, and much of Searchatron’s code provided the basis for the SpazCore component library.

As more of you may know, I’m very interested in the new Titanium platform. It’s similar to AIR, but fully open-source, and much more extensible. In order to learn more about Titanium, I tasked myself last week with converting Searchatron from AIR to Titanium. The whole process only took a couple hours. You can download the result from http://get.titaniumapp.com/app/12GKqr3.

What’s interesting is that Appcelerator, the creators of the Titanium platform, are running a contest right now. Two $500 prizes will be awarded for the most downloaded app, and the highest-rated app, respectively. If Searchatron wins either of these prizes, I’m pledging now to use the prize money to support further development of Spaz and the SpazCore project, in the form of cash gifts to our most giving volunteers. It might not be a lot, but it does mean real money is going to people working on open-source development. I hope to continue doing so when feasible and prudent.

If you’re interested in helping, this one is pretty easy: download Searchatron, and if you like it, suggest others do the same. Feel free to point them here if you like. By doing so, you’ll be doing a lot to encourage the continued development Spaz and its related projects.

Why Spaz isn’t “signed”

2009-03-09T02:56:26Z

We don’t sign Spaz with a code signing certificate generated by one of the 4 (as of this writing) certificate authorities Adobe accepts. This means that when you install Spaz, you get a scary “Publisher:UNVERIFIED” warning. This is why we don’t sign, from a letter I wrote when asked about it in Spring 2008:

If I sign Spaz with a paid-for Thawte cert, I am on the hook every year for a Thawte cert. I can’t change my cert signer or go back to a self-signed cert without breaking auto updating (at least as I understand it), and I’m therefore locked into a $300 expense every year. That’s not terrible for a commercial app backed by a company, but that’s a pretty significant chunk of change for a free, open-source app developed by one person as a hobby to lay out.

I’m familiar with how certs work, and how Thawte handles certification as compared to other, less expensive cert vendors. Were I convinced that Thawte did some kind of verification process/background checking on the applicant I could see the value, but at least with SSL certs, they certainly didn’t do anything more than vendors who donate free certs to EDUs.

Currently, there are 3 other CAs in addition to Thawte, and the prices range between $180 and $300 per year. Some of these CAs do seem to do a little more background checking. Still, the same arguments apply, especially the one related to cost.

Spaz doesn’t generate revenue, and relies on donated time from myself and a handful of other generous folks. Committing to a yearly expense in the hundreds of dollars seems unwise.

If this is something you would like to see change, I’d encourage you to ask Adobe to make code signing a realistic option for Free, Open-Source Software like Spaz by providing certificates free-of-charge – after a reasonable review process – to projects like ours.

Security for the Social Set at SXSW - A Conversation

2009-03-06T22:34:22Z

Do you work in social media? Do you develop social networking sites? Do you like it when people do not hack your Facebook account? If you answered “yes” to one of the above, then you simply must attend Security for the Social Set, a Core Conversation I’m leading at SXSW. It will take place on Sunday morning at 11:30 a.m.

I’m excited to be able to lead this conversation, especially because I think security – especially practical solutions – is woefully under-represented in social media discussion. It’s my hope that we can raise awareness of these issues, identify where the biggest problems lie, and start sorting out how to address them.

I am told the Core Conversations will suck less this year. Last year it was often hard to hear people in your group if there was a raucous group next to yours. This year each group should have their own room, which will be a lot better, I think.

Hope to see you there!

Tech Journalism and Cash Money

2009-03-04T16:13:31Z

Alex “Bring The” Payne put an interesting post on his blog yesterday about improving the state of tech journalism. While I tend to feel that what he describes is not unique to IT, I don’t think that this means we should just say “oh well, it sucks.” Bad things will always be around, but I’d rather work towards making less of it, even if just in my own little circle of dorks.

While it’s a complex issue that likely needs to be addressed in several ways, one aspect that stuck in my head is incentive. Alex talks about this generally as one of a few possible solutions to this issue:

Incentivize technology reporting as a career — It’s hard to make a buck as a technology journalist, particularly one who reports on something more substantial than gadgets and empty enterprise software press releases. No wonder that TechCrunch has gone the route of sensationalism; it drives ad clicks and sparks debate, making a potentially dreary beat profitable and exciting. Tech journalism isn’t sexy, but it could be made so. That change starts with breaking the cycle of low-quality tech reporting, giving prospective technology journalists a set of role models they can aspire to.

I believe that at least in part, this comes down to (as so many things do) money: how much tech writers are paid. I also believe that we aren’t doing right by the folks who strive for excellence in tech journalism, making their jobs harder than they should be.

I frequently hear people talk about how teachers are underpaid; how those who have such an impact on our lives at an early age should be well-paid, because that will attract higher-quality candidates. I tend to agree with this idea, at very least in the sense that if you are paying more, you will tend to get better people.

I’ve done freelance writing off and on since I was a teenager, and I’ve been doing “development” in one way or another in computers for almost as long. One thing I can tell you with certainty is that it is far, far easier to make money doing IT stuff than writing about it. Tech writing simply doesn’t pay well in almost all cases. Every time I’ve written an article or worked on a book¹, the money was not the primary factor, because I was barely making minimum wage (or worse) if I actually did the math². Getting people who do know their stuff to write about IT is made significantly more challenging, because it means sacrificing productive, profitable opportunities. It can mean the difference between handling your mortgage payment with no problem, and asking your landlord for a couple extra days to get the rent money.

As consumers in the economy, we vote with our dollars. When we purchase a product, we enable the companies involved in creating that product to keep doing business as they see fit. We effectively endorse their actions (intentionally or not) in this way.

For “free” product like most web sites, though, we don’t vote with our dollars – we vote with our eyeballs. Ad revenue is determined by visits. Ad revenue is what keeps most journalistic³ sites in business. When we visit a site, we are enabling them to do business as they see fit. We are endorsing their actions.

Ad blocking software complicates the issue, especially on tech news sites, where the relatively savvy readership blocks ads at a much higher rate⁴. It’s sort of a passive-aggressive way of dealing with something we don’t like: still playing the game, but fudging the rules. Unfortunately, I suspect this only leads to two things:

more ads (and more intrusive/obnoxious ads) to make up for the loss
questionable and nefarious practices to make up for the loss

Obviously some folks are going to do lame stuff no matter what, and the use of ad blocking software won’t impact their behavior. But for people who want to do The Right Thing, this makes things harder. Harder for them to pay people to write. Harder for writers to support themselves and their families. Ad revenue is, in the vast majority of cases, the only viable revenue stream these sites have. By blocking ads, we use their service, but take away their ability to pay for it.

There are security concerns associated with some ads, of course, and sometimes we can’t anticipate what kinds of ads we might see on a new site. In these cases, I would suggest a couple potential approaches:

use a technology blocker like Flashblock to allow you to selectively enable Flash applets only on trusted sites
use an adblocker defensively at first, but enable ads on sites you trust

If you like the way a tech news site does business, vote with your eyeballs and turn off your ad blockers. If, however, you don’t like how they do business – or if they run obnoxious or potentially dangerous ads – follow the same principle and don’t visit the site. At all. That will be far more effective than simply blocking ads.

Update: a good piece from The Week titled “Is Writing for the Rich?”:

It’s not obvious how young writers without accommodating, well-to-do parents or a trust from gramps make it these days. Surely they can’t spend a year or two blogging without pay until an audience evolves to nurture them. They’ll starve. Meantime, freelance rates for non-fluff magazine writing have barely risen in the past 15 years. And the chances of getting a job at a quality newspaper or a serious magazine are fast approaching zero.

I’ve tech edited a few books, and I’m authoring one now. Believe me, you don’t do this for the money. ↩
Generally I avoid doing the math while I’m in the middle of a writing project, because knowing what I’m making on a per-hour basis would be far too demoralizing. ↩
I’m using a pretty loose definition here, so “blogs” that intermingle reporting with opinion would be included. ↩
Nearly half of visitors, or about 8 times the norm ↩