Funkatron

Open Sourcing Mental Illness at php|tek13

2013-05-20T00:00:00-04:00

So I gave my “Open Sourcing Mental Illness” talk for the first time last week at tek13. This was exciting, and scary, and overall went well, I think. Here are the slides and audio:

I got a bunch of just amazing feedback, all of which I do not feel worthy. I don’t like to self-promote, but I sorta feel like the message here is bigger than my need for humility, and good reviews will help me bring this talk to more places. So:

An outstanding, emotive, important talk. Ed is very brave to deliver this talk with an intense but necessary level of personal details. Would have been pleased with this as a keynote, and I wish that it had been, as it would have reached more folks. link »

This is such an important topic but by its very nature, the people who truly understand it can find it hard to tell those stories. Ed gave so much of himself to tell that story today, I tweeted that he is a hero, and I meant it. link »

I’m in awe of @funkatron’s complete openness about his experiences. It takes a lot to share all of this. Thanks, Ed, for sharing! #tek13 link »

@funkatron’s “open sourcing mental illness” talk was worth the price of admission for #tek13 — equal parts inspiring and thought provoking. link »

@funkatron “Open sourcing mental illness” Amazing & moving. Highlight of #tek13 for me link »

Hey developer conferences, each of you should do whatever it takes to get @funkatron’s “Open Sourcing Mental Illness” talk at your conf. link »

@DragonBe Great wrap-up! I would agree that talks by @funkatron and @sprunka were the most noteworthy and original at #tek13 link »

I am scheduled to give the talk at these upcoming conferences:

Thank you for all of your support.

Open Sourcing Mental Illness

2013-02-15T00:00:00-05:00

Update update: I started a campaign to fund my travel expenses giving this talk at tech confs. The response has been amazing. Thank you!

Update: I talked more about this in Episode 28 of the Development Hell podcast

In June of 2012, we posted an episode of the Development Hell podcast that was a little out of the norm. Instead of focusing on technical issues or open source community stuff, we talked about mental illness: specifically, my ongoing struggles with depression and anxiety.

I had just come from the tek12 conference, which was one of my worst conference experiences ever. I had forgotten some of my daily medications, and also ended up getting (physically) ill. The whole experience was a big struggle for me physically and mentally. I ended up going home early because I was deeply uncomfortable and unhappy.

I felt really compelled to talk about it when I was home for a couple days. I wasn’t quite sure why, exactly, but I had been carrying this burden for a long, long time, and I was tired and frustrated dealing with it privately. I wanted to explain what it was like for me. I hoped I would feel a little less alone with it. Maybe other folks could learn from it.

I was blown away by the response. We received far more feedback to this episode than we ever had, or since.

I simply wanted to write and say that I have never been able to put into words how I feel as well as you all did.

For too long it’s even restricted my commitment to OS, not that I’m using it as an excuse for my lack of contribution. Sharing your thoughts like this and seeing the other side is really encouraging, despite what my brain wants me to think.

… I so sympathize with Ed. It really sucks to have a brain that wants to continually sabotage you and keeps you from reaching your potential. Just know there are millions, and I do mean millions of people, that understand what you go through.

The more we can get these stories out there, the better chance we have of influencing general public perception, and most importantly, helping others who suffer to try to get help.

… it’s times like these that make this feel like more of a community. … I used to think mental illness was something most people could just overcome through effort and attitude—mostly due to some bad experiences with people who basically blamed all their problems on some undiagnosed “problems.” Then I started living with some guys, one of which really struggled with a ton of different issues (bi-polar being the least of which).

Listening to the latest @dev_hell is really making me think about how I treat people. You never know what someone else is going through.

They told us that they finally felt like someone was talking about the issues they struggle with every day.

They said they valued the insight they’d gained into what it’s like to cope with depression and anxiety.

I was inspired, and energized, and I wanted to do more. But I didn’t really know what. I thought long and hard about it, but didn’t come up with anything that seemed feasible.

A couple months later, at another conference, a developer I admire greatly told me that when I opened up on /dev/hell about my own issues, they had been inspired to seek help for some of their own issues. I was blown away, of course, that someone I looked up to would have gotten some reassurance and strength from what I was saying about my own issues.

So I decided that maybe I just needed to keep talking.

I started working on a basic abstract, and targeted two conference I really love: Open Source Bridge and OSCON. I asked folks on Twitter what they’d want to get out of a talk on this topic, and i got lots of good feedback. But this one struck me the most:

Knowing I’m not alone.

Reading that is overwhelming and humbling. I’m just talking about myself and what I’ve been through. Part of me feels selfish for doing so; suspicious of myself, that maybe I’m just doing this for attention and sympathy. But I know it helps me to talk about it, and other people seem to get strength from it too.

I submitted to both, and pointed folks on Twitter to the proposal listing on the OSBridge web site. Since then I’ve submitted to a couple other technical conferences with open CFPs as well.

I’m not excited about the prospect of traveling a lot this year – it triggers my anxiety pretty badly. Just thinking about it makes me nervous.

But if I can help them know they’re not alone, it’s worth it.

If I can help people understand what it’s like for people who struggle with this, it’s worth it.

In my community, the Open Source community, I think I can help. So I’m going to try.

So if you know a conference, a user group, or another place where open source & techie types get together, I’d like to speak there. If it has to be on a google+ hangout, I can do that. If it can be in person, that would be great too (time and money permitting). And if you want to hear me talk at a conference you’re attending, tell me and I’ll submit – or tell the organizers if it’s not an open CFP.

And thank you for listening and understanding.

I know

2013-01-12T00:00:00-05:00

I know.

I know how it felt to have a whole bottle of pills in my mouth, mixed with water. While I sat on the cold plastic tile of the bathroom floor, back against the door, while she tried to push her way in.

It was an impulse in a lost moment. It passed, and I spit them out.

I know how it felt to drive on that backroad between cities, my world in pieces, and be certain I wouldn’t be alive in a year.

I know how it felt to be convinced that you were broken. You didn’t work right. That things that seemed so easy for everyone else were so hard for you. That you cry because you can’t take it any more. That it was never, ever going to get better.

I know how it feels when the only thing standing between you and that place are the pills you have to take every morning, every day, for the rest of your life.

I didn’t know him. But I wish I could have sat with him, and listened to his pain, and tell him that I know.

I know, brother. I know.

Supporting Conferences That Commit to Diversity

2013-01-08T00:00:00-05:00

If you pay any attention to my twitter stream or the Development Hell podcast, you probably know two things about me: I love to hear myself talk, and I’m concerned about the extremely low number of women who participate in open source.

In the PHP community, where I’ve done most of my open source stuff, we’re lucky compared to a lot of groups. We have a strong, supportive group in PHP Women, and I’m not aware of any incidents of harassment at the events I’ve attended. But I still think the participation of women is much lower than it should be, and I want to help change that.

To that end, I’ve provided a little financial support to organizations like the Ada Initiative, and I’ve tried to raise awareness of the issues on the Development Hell podcast by having guests like Selena Deckelmann, Elizabeth Naramore, and Ashe Dryden.

One place I haven’t addressed it much is in conference participation. I don’t speak at a ton of events every year, but I do get to speak at a few. So this year I’ve decided to pursue attending or speaking at conferences that do the following:

Adopt a public anti-harassment policy / code of conduct
Make a strong, concerted effort to get female speakers and panel participants

This shouldn’t be taken as a threat or boycott of events that don’t choose to do these things. Rather, I’m choosing to support events that prioritize these issues. If you’re working to improve the participation of women in open source, then I want to support you. I want to be part of what you are doing.

Specifically regarding the number of female speakers, I don’t really want to attach numbers to the percentage that’s acceptable. I think the goal should be 50%, but going from 0% to halfsies is probably not reasonable at this time. I do think that having no female speakers is not okay, and I think doing better than last time around is a very doable thing.

It’s my hope that more and more conferences deal with this stuff up-front. Because CFPs frequently precede a conference by 6 months or more, some of this stuff might not be decided. I’d ask that if you’re involved in organizing a conference, you bring it up early on, because it does matter to many of us who would respond to your CFP.

If information is not already publicly available, I intend to ask privately about these issues. I think that most conference organizers are well-intended, and I’d much rather bring up these issues in a private, less threatening way. If they haven’t put much thought into it, or if they’re not sure how to address it, I’ll point them towards resources available from the Ada Initiative and other groups.

I hope that if you’re thinking about attending or speaking at a conference, you’ll ask about these things too. Make it clear that these issues matter to you, and support events that are trying to do the right thing.

More Code, More Problems

2012-12-13T00:00:00-05:00

I wrote an article for this year’s WebAdvent (previously PHPAdvent) called “More Code, Mode Problems.” It expands on the MicroPHP Manifesto I wrote early this year and applies it to other languages, establishing a set of principles for creating clear, reusable code.

Please go there to read it, but you can leave comments here if you like.

When is Design Evil?

2012-10-13T00:00:00-04:00

Ben Pieratt gave a compelling talk at Brooklyn Beta this year about his experiences founding, and then leaving, Svpply. He bravely described both his successes and failures as a founder, and it was one of the highlights of the conference.

Ben made an interesting assertion during his talk that I’ve been chewing on for a few days since: that he thinks that people are his medium, not the web or paper or video or what have you. As a designer, his job is to influence user behavior.

My initial reaction to this was negative. When we’re talking about influencing people, I usually think of Evil Shit. Stuff like the world in They Live, where advertising and media all work to suppress independent thought and promote consumption. That was satire, but based firmly in the reality of government and the private sector’s manipulation of user behavior via the media. And in interface design, plenty of Evil Shit is done to influence user behavior, like aping the look of Windows in popups or making it hard to choose free options. Many more examples are mentioned in the slide deck “Usability Engineering for Evil”.

When I’ve done web design, I’ve typically focused on the utility of what I’m making, in order to empower the user to accomplish his or her goals. I’ve always been suspicious of attempts to appeal to one’s emotions to influence behavior, particularly when it lacks any logical argument. For example, I’ve been happy with Apple’s products and continue to purchase them despite having advertising that consistently turns my stomach with its strong emphasis of style over substance.

But design exists somewhere in the overlap of utility and evoking emotion. The aesthetics of a thing always evoke some kind of emotional response in the user, subtle as it may be. I choose to use some applications over others because I find the aesthetic choices more appealing, even when they have similar functionality. I generally find it more pleasant – or at least less unpleasant – to use a utility when the UI is both effectively engineered and aesthetically pleasing.

Poor aesthetics in a vendor’s web site often lead me to dismiss them as an option. Compare the Hover splash page:

To this one from UglyBill:

I find Hover not only more aesthetically pleasing, but both easier to use and more trustworthy because of the level of effort put into the design.¹ Of course, Hover at one time stored passwords as plain text, so it’s not as if good design itself indicates good stewardship.

Still, there’s a difference between making a utility appealing to help the user accomplish what he or she wants, and design that gets the user to do what you want he or she to do. The latter is fraught with many more ethical issues.

I’m a big fan of Soviet propaganda art from the 1930s and 40s. This is a good example of the period:

Compare this to the familiar Obama “Hope” poster:

Both of these posters want to influence and inspire in similar ways. Most of us would probably agree that supporting the Soviet regime of the period was not a great idea – even worse than supporting Obama! If we can say it supported an “evil” regime, is the design itself “evil”?

A similar, but more extreme, approach is used in recent anti-smoking and methamphetamine use campaigns:

Since smoking tobacco and taking methamphetamine is generally regarded as bad for you by most people, we’re generally okay with these campaigns, despite their appeal to extreme emotions. But they don’t present anything like a logical argument – it’s purely scare tactics, just like those used by William Randolph Hearst to demonize marijuana in the 1930s. That’s not to say the approach isn’t justified in some cases, but I’m not personally comfortable with it as anything but a last resort.

Propaganda is one thing, but interface design can be equally problematic. The Dark Patterns wiki has lots of good examples of UIs designed to get people to do things they probably shouldn’t. The wiki calls it “tricking” users, but I’m guessing the designers behind many of these would have used words like “entice” and “encourage.” And many of these aren’t obviously nefarious; the involve things like requiring opt-out, defaulting to sharing more data than less, and reducing the visibility of certain UI elements – stuff that’s commonly discussed in web app development.

Ultimately, if you’re good at your job, you have to become a steward. Developers are stewards of their users’ data. Designers are stewards of their users’ emotions and behavior. Users put their trust in us; respecting that trust means considering the ethics of our design and development choices. As Dennis Kardys says in The Ethics of Influence and Manipulation (which deals with many of these same issues much more intelligently than I do here):

It can be convenient to do your job without thinking about the bigger picture. It’s easier to be passive than to be confrontational, and it’s easy to place the weight of responsibility onto your boss or the client. But the truth is that we alone are responsible for the things we create and contribute to making.

We owe our users that much.

I actually use Gandi.net for domain registrations. I find their web site a bit harder to use, but their “no bullshit” slogan appeals to me, and they never try to up-sell me on anything. Consider this a recommendation.↩

The MicroPHP Follow-up FAQ

2012-02-07T00:00:00-05:00

My previous post, The MicroPHP Manifesto, resulted in much excitement. In between fits of rage and crying, I found some time to answer folks questions, and also discuss the topic on the /dev/hell podcast with my cohost Chris Hartjes. To summarize and address some of the common questions, I felt I should write a small FAQ.

Got a question? Ask me. I’ll add additional entries here as things come up.

So you think full-stack frameworks suck?

No. I think sometimes they’re very appropriate. It depends on your needs: will the pros you get with library/component/framework X outweigh the negatives? If so, it’s probably a good choice. If not, it’s probably not.

You need a large framework to enforce best practices!

Sometimes you do. My experience at FictiveKin has been that our small team is able to work faster, smarter, and more efficiently by minimizing the size of our PHP codebase and removing all unnecessary layers of abstraction. In some cases that meant not doing certain tasks in PHP anymore (almost all HTML generation was moved to the browser). In others, it meant ripping out a bunch of code and replacing it with a simpler solution that required far less boilerplate and replication. We still kept some code that had more dependencies than we’d like because the wins we get with it outweigh the downsides.

I’ve certainly seen situations where choosing a popular full-stack framework is a better idea. As teams get larger, enforcement of coding standards and not doing Dumb Shit becomes harder. Hiring and training engineers is usually easier with popular, full-stack frameworks. On the other hand, we’ve found that devs coming from non-PHP backgrounds liked how quickly they can be productive with simpler libraries and frameworks. Your mileage may vary.

So you’re saying we should write our own framework/libraries/components?

Good God no. There is lots of very good, well-written code out there that’s already solved the problem you’re facing. Most of the time I don’t want to try to solve an issue like oAuth request signing, because it makes my brain hurt and I’d rather focus on building stuff. So, I’ll look for an existing solution that fits my needs first. I sometimes choose to write something from scratch because the existing solutions (that I can find – discovery is a whole other issue) don’t fit well with my existing application structure, or I feel it will introduce more maintenance issues than I’m comfortable with.

You should check out my microframework!

Sure. Generally I think people should work on writing libraries/components, personally. We have plenty of framework choices. But this is PHP, so you have to write your own framework sometime.

Is “X” a microframework?

Long answer: I tend to believe that the reference implementation of “microframework” is Sinatra. Routing, request/response objects, sessions, maybe some hooks for template rendering. Generally I think the inclusion of an ORM is a clear sign of non-micro-ness.

Short answer: I don’t care, really – and you shouldn’t either. If it works for you, awesome.

How do you choose what gets listed in the MicroPHP code collection?

Generally I think about these things:

Does it try to solve one task, or a small set of closely related tasks?
Would it be easy to use with almost any existing code base?
Is the code as short as it can be, while still being clear and easy to follow?

None of these are hard and fast rules, though. I encourage people to share things with me they think others would find useful.

Why do you hate Rush?

I don’t. I like some of their songs, but don’t own any of their work. I also think they’re incredibly smart, talented musicians. My point was to suggest there are other valid approaches, not to reject complexity outright.

The MicroPHP Manifesto

2012-01-03T00:00:00-05:00

Update 2012-01-06:

The manifesto itself and the collection is now at MicroPHP.org
Here’s a Czech translation
The MicroPHP Fallacy
O Manifesto Micro Php E A Macro Discussão.
Meus Dois Centavos Sobre O Microphp Manifesto
The MicroPHP Manifesto – What People Are Overlooking

Update 2012-01-04:

I’ve started a collection of lightweight PHP libraries and frameworks on Gimme Bar [json] [rss]. If you have suggestions, let me know!

The standard line about the history of Punk is that it was a reaction to the excesses of modern rock, particularly progressive rock of the time. The reality is undoubtedly more complex, but I suspect there is some truth to that. Rock n roll did seem to be the realm of Golden Gods in the late 60s and 70s, inaccessible to average folk. The contrast between bands like Rush and Black Flag –– both supposedly playing “rock” –– was extreme.

For fun, let’s take a look at Rush drummer Neil Peart’s drum kit:

Now, here’s Black Flag playing in LA in 1979:

You can fit the entirety of Black Flag in the space of Neil Peart’s drum kit. And they would still play awesome shit and rock you the fuck out.

In the past few years, the PHP Zeitgeist seems like it’s been moving in the Neil Peart direction. Lots of work by lots of smart people is going into complex, verbose solutions. Lots of files, lots of nested directories, and lots of rules. I frequently see PHP libraries/components that look like this:

All that, just to start your application.

It doesn’t mean this approach is bad, per se. But when I see it, I have a visceral negative reaction. My brain screams

FUCK.

THAT.

SHIT.

I can’t do it. I don’t want it. And I don’t think we have to do it this way to do cool things and build awesome stuff.

The approach I’ve been taking lately is to start with as lightweight a foundation as possible, in the form of a “microframework.” A few of these exist for PHP (of course), including Slim, Epiphany, Breeze, Limonade, and others. For additional functionality, I pull in lightweight libraries that help me accomplish only the tasks I need. Clarity and brevity are my top considerations.

My other big consideration is the commitment I make when I use code I didn’t write. Typically I don’t have time to do a full code audit on libraries, so there’s a level of trust that goes with it. And each dependency means more trust. Not just that there aren’t bugs (I expect that if they’re anything like me), but security issues – both whether they exist, and how they will be handled. Will an announcement go out to a mailing list? How long will security fixes be provided that don’t break backwards compatibility? Will I have to upgrade all my dependencies if I upgrade to the next PHP point release? And all of that assumes the author will have the time and motivation to provide prompt fixes. If they don’t, you’ve just added a bunch of technical debt to your codebase.

Finding lightweight libraries that don’t pull in lots of additional code dependencies is much harder than it should be. Mostly I think that’s attributable to PHP devs being more interested in framework-specific development. Some work is being done to make mature frameworks less monolithic, and many devs on Twitter have recommended Symfony components as an option. Unfortunately, I think my definition of “lightweight” is not the same as theirs.

Here’s the cloc output for a git clone of the symfony2 HTTP Kernel component:

Mon Dec 26 19:42:23 EST 2011
coj@PsychoMantis ~/Sites > cloc HttpKernel
      94 text files.
      93 unique files.
      12 files ignored.

http://cloc.sourceforge.net v 1.53  T=0.5 s (164.0 files/s, 18736.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
PHP                             72           1175           3440           4290
Bourne Shell                    10             56            155            252
-------------------------------------------------------------------------------
SUM:                            82           1231           3595           4542
-------------------------------------------------------------------------------

Here’s the same for the Slim framework:

Mon Dec 26 19:42:27 EST 2011
coj@PsychoMantis ~/Sites > cloc Slim
      54 text files.
      51 unique files.
      13 files ignored.

http://cloc.sourceforge.net v 1.53  T=0.5 s (82.0 files/s, 17752.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
PHP                             31            660           4473           3280
Bourne Shell                    10             56            155            252
-------------------------------------------------------------------------------
SUM:                            41            716           4628           3532
-------------------------------------------------------------------------------

and the Epiphany framework:

Mon Dec 26 19:42:30 EST 2011
coj@PsychoMantis ~/Sites > cloc Epiphany
      83 text files.
      70 unique files.
      31 files ignored.

http://cloc.sourceforge.net v 1.53  T=0.5 s (102.0 files/s, 5246.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
PHP                             40            218            309           1632
Bourne Shell                    10             56            155            252
HTML                             1              0              0              1
-------------------------------------------------------------------------------
SUM:                            51            274            464           1885
-------------------------------------------------------------------------------

When there are more files and lines of code in your component than in my entire base framework, I can’t call it “lightweight.”

It doesn’t mean that stuff is bad, in the grand scheme of things. It doesn’t mean it has no value or is the wrong approach for many. But it’s the wrong approach for me, for sure. And I don’t think I am alone.

I don’t want to be the prog rock superstar, writing a pretentious rock opera. I want to play shitty power chords in a punk rock band that plays shows in a VFW lodge with no stage, and leaves you so fucking pumped that you go out and form your own band. That’s the coder I want to be.

I don’t want to be Neil Peart. I want to be Gregg Ginn.

So I wrote this. A “micro PHP manifesto,” if you will. I plan to use it to guide my PHP dev. Maybe you will find it useful as well.

I am a PHP developer

I am not a Zend Framework or Symfony or CakePHP developer
I think PHP is complicated enough

I like building small things

I like building small things with simple purposes
I like to make things that solve problems
I like building small things that work together to solve larger problems

I want less code, not more

I want to write less code, not more
I want to manage less code, not more
I want to support less code, not more
I need to justify every piece of code I add to a project

I like simple, readable code

I want to write code that is easily understood
I want code that is easily verifiable

Building a Tumblelog with Gimme Bar and PHP

2011-11-05T00:00:00-04:00

One of the coolest things about working on Gimme Bar has been the opportunity to build a platform. While most folks interact with our service via the web site, the site is just one application built on top of the Gimme Bar content collection and curation system. Our web site interacts with the system via our HTTP API, which is open to everyone, not just our internal team. That means that anyone can build applications on top of our platform to suit their own needs or interests.

To demonstrate this, I built GimmeMe, a simple tumblelog-type web app that’s powered by Gimme Bar. It uses methods in our API that don’t require authentication, so you don’t need to register with us to use it. And it’s a drop-in, set-one-option-and-go install, so you don’t need to fiddle with a bunch of stuff to use it (but you can if you want).

I have a running demo on my web server at http://funkatron.com/GimmeMe. It shows the 50 most recent pieces of content I’ve grabbed with Gimme Bar.

Installation

To install the web app yourself, you’ll need a web server with:

PHP 5.2.x or above
APC 3.0.8 or above

Install as follows:

Download the source code as a .zip or .tar.gz from the project’s download page
Decompress the files somewhere under your web server’s document root
Edit the $config['username'] value in index.php 4 .Optionally set the $config['gb_addthis_pubid'] value to include AddThis widgets, if you’re into that kind of thing
Load the appropriate URL in your web browser to view the install on your web server

The Code

If you’re a developer type, you’ll probably want to poke around the source code in the GitHub repo. The main work is done by libs/GimmeMe.php, which handles grabbing data from the API, caching it, and rendering the HTML.

In GimmeMe::getAssets(), we load the data using the GET /public/assets/:username method. This returns a JSON object with an array of asset data in the records propert. We decode the response JSON into a PHP object (the $assets variable), and add a couple properties that we’ll use in the HTML template. Then we cache the object in APC, and return it. Next time around, if the cached object has not expired, it will just pull it from APC and return it, so we don’t make more requests to the API than necessary.

The GimmeMe::render() method loops through the assets we retrieved and makes each one into a GimmeAsset object. GimmeAssets are view objects used by the Mustache templating library to encapsulate display logic, so we set up special methods or data massage in there. After we set those up for each asset, the entire data structure is passed to the Mustache library for rendering, using the ‘page’ template defined in templates\templates.php.

Right now I also am including a a simple router class at vendors\Router.php. We’ll need this for stuff that would involve different URLs, like paging back through assets or loading single-asset pages, but I haven’t quite gotten that far.

I’d be remiss in not mentioning http://hereslookingathue.com/, a collection of beautiful imagery collected and organized by Gimme Bar user hereslookingathue. It’s another cool example powered by our public API methods.

Hopefully this gives you a taste of what’s possible with the Gimme Bar API. Most read-only things, like embeddable widgets or reposting tools, would be easy to do with just the public API methods. Beyond that, the vast majority of our system is exposed through the public API, so powerful collection, replication, and organization applications can be built.

If you have questions or comments, please hit us up on Freenode at #gimmebar-api, or email us at api@gimmebar.com.

Photo by rovingI

Stepping Down From Spaz

2011-10-07T00:00:00-04:00

The Spaz project has been an very important part of my life for nearly five years now. It’s been extremely rewarding personally and professionally. I’m proud of what we’ve accomplished. In recent months, though, the stress of running the project has become overwhelming. My ability to meet my responsibilities as a father, husband, and member of the FictiveKin team has suffered. So, I’m stepping away from Spaz, and letting others take the reins.

I’m very pleased to say that Josh Roesslein (@applepie) has agreed to take over as project lead for Spaz. He’s an excellent coder, very experienced with cross-platform JavaScript applications, and committed to open source. I’m confident that Spaz is in good hands with him.

I’m still going to have some involvement with Spaz behind the scenes, but it will be very reduced. I’ll probably code a bit here and there, and will continue to maintain existing resources as needed, but I plan on taking a “Project Lead Emeritus” role from here on out.

To all of the users, supporters, and friends who have made Spaz one of the best experiences of my life: thank you for everything.

photo by Paolo Margari

Links for 2010-12-15 [del.icio.us]

2010-12-16T00:00:00-08:00

audio.js

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

2010-12-01T00:00:00-08:00

A successful Git branching model » nvie.com

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

2010-11-21T00:00:00-08:00

A TextMate Bundle for Lithium

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

2010-11-20T00:00:00-08:00

Higher Order Javascript
"In the presentation I asked for a show of hands from people who’d done higher ordered programming before. A scattering of hands went up. Then I asked who’d used jQuery’s $.each(function {...}) and most hands in the room went up. Which means that most of the people in the room had used higher order programming and never realised it."
CoffeeScript

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

2010-11-19T00:00:00-08:00

How to Install Android on an iPhone in Six Easy Steps

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

2010-11-13T00:00:00-08:00

MathJax | Beautiful math in all browsers
Plupload - A tool for uploading files using Flash, Silverlight, Google Gears, HTML5 or Browserplus
"Allows you to upload files using HTML5 Gears, Silverlight, Flash, BrowserPlus or normal forms, providing some unique features such as upload progress, image resizing and chunked uploads."

Links for 2010-10-28 [del.icio.us]

2010-10-29T00:00:00-07:00

Knockout : Home