This evening, I signed a contract to work at Cenzic, Inc. of Santa Clara, CA.
Words fail to describe how ecstatic I am. It is quite literally a dream come true.
Now I need some help...
I start in two weeks, and I don't have a place down there lined up. I'm looking at Craig's List, and there are some good deals there. I'm trying to be frugal (renting a room is just fine for me), but I'm well aware that my current bank balance dictates a shorter-than-average move-in cost at mid-month (as in a minimal security deposit initially, but which I'd make up in two months at most), when the move needs to be finished.
Vallejo to Santa Clara is about 80 miles. So commuting by bus (which I prefer, but takes four hours) is out.
If readers know of any connections that would be willing to rent a room out for a fair price to a Mozilla enthusiast gentleman, please contact me at ajvincent at ye handy dandy gmail. I can offer plenty of references on my character both from my current land-lady, current employer, friends, etc. I'm just a tiny bit short on the cash at the moment; I may have to seek some sort of financial aid...
Me? Mozilla Man?
Oh, I wish. No, there are far more deserving people of that title. I think Ms. Ha really overstated my role here. Still, any good coverage of Mozilla-based products, I'm willing to promote.
I have an idea. Let's file a class-action lawsuit.
We can target the companies whose products are being offered, and the people doing all the advertising. We collect a log of blogspam we gather in a single day, week or month. Since MozillaZine hosts this blog and several others, they'd receive a good chunk of whatever damages we'd claim. It is their bandwidth being tied up.
We'd probably ask Google to file a "friend of the court" brief (or whatever they're called), since there's only one reason why these blogspammers would repeat so many links to the same site with the same phrase in a single post: search engines.
We help MozillaZine and other blog hosts to collect IP addresses and hosts of people submitting, track it down, and nail the people who use these automated tools on us as defendants. They'd better hope they pay technical wizards as good as we are by training, because otherwise we will find them.
(I'm not serious about this idea, but when I collect 400+ new spam in my new GMail account in less than a month, and 90% of that is blogspam notifications in my box, and I'm only one guy... do the math: there's a lot of blogspam out there just in the mozilla.org community.)
Well, it was quite a party. The only problem was that the Mozillian crowd of 180 didn't quite show up... at best we had maybe two dozen.
I arrived at 9:30 pm-ish carrying two trays of Ritz crackers, partially coated with blue-colored cream cheese. It was supposed to emulate the Firefox logo. Quite a few people tried them out, but even I had to admit that after a couple hours, they had somewhat lost their flavor (and the crackers had grown soft under the cheese). Oh, well. Better to spend $25 and a couple hours than $300+ for cookies that I couldn't find a baker for. I think people still liked them.
I finally met Brady Frey (a fellow moderator at CodingForums.com), and we chatted two or three times. Overall, we were happy with the turnout we got and the club itself.
Several people who were there had also attended the Mozilla 1.0 Release Party (including me), and were asking about Firefox t-shirts. Bart Decrem, what happened to you? :)
I was definitely the last Mozillian to leave... the Firefox crowd had cleared out no later than midnight, leaving me one lonely guy. I danced it up all the way to the close, enjoying myself.
Then I spent a few hours wandering San Francisco waiting for the ferry ride back to Vallejo. I ended up sitting down at a Denny's around 5th & Mission St (the same Denny's I landed at after the Mozilla 1.0 party) and had breakfast. I wandered towards the Ferry Building, and sat there for a couple more hours. I discovered there was a bus going back to Vallejo at 9 am, so I caught that. Coming off the bus, I walked up Santa Clara Street here to St. Vincent Ferrer Church, and arrived just in time for the start of one morning Mass. That rather surprised and pleased me.
The next few hours (after Church) I spent largely in a daze -- not from alcohol, but from not getting enough sleep. (I was attending the Parish Day, but spent most of it in a chair either reading Tom Clancy or drifting off to sleep.) Finally, about 3pm, the affair ended and I was driven home by a fellow attendee.
Therein I went straight to bed, and didn't wake up until 1:00 am Monday, to find several pictures of the party from two camerapeople posted. Here are the ones I found of me:
Blue Cheese Logo Crackers
Yours truly -- with one eye shut accidentally (I swear all I drank that night was Coca-cola.)
Someone else who caught me with crackers
I wonder: is there anyone else who was at Wish that night who took photos? I know there were a couple pretty young ladies with cameras, but they weren't from our crowd...
... everybody's waiting for you to arrive.
Party Like It's 1.999 for Mozilla Firefox.
Tomorrow at 7:00 P.M., the doors open.
(Apologies to Pink.)
Every now and then I run across a bug that you cannot reproduce without security privileges. However, it occurs to me we can provide XPI files as attachments, to offer testcases for such bugs within the chrome:// URI (experienced Bugzilla QA people only!)
I don't see any particular reason we couldn't...
I'm suggesting a specific chrome:// URI scheme for people to use if they post XPI's for chrome-based testing of bugs.
The first part of the URI path would be "bugtests". The second part, of course, is "content", "locale", or "skin". The third part would be the bug number. After these three parts, free range.
So, I could create an XPI that would install:
chrome://bugtests/content/179621/txmgrTest01.xul
which I could then use in bug 179621 (thanks roc for the r/sr+) to demonstrate the principle I'm working towards, or a bug.
It should be fairly easy to accomplish this. Of course, people who use Bugzilla should take bug attachments that mess with chrome:// with a grain of salt...
UPDATE: On a related note, I just filed bug 270765. The two would go well together in assuring bug testers and developers that XPI attachments really are safe.
Bug 179621, desperately seeking sr
Okay, I've tried being nice. I've tried being discreet. I've even tried a letter to staff. Now, I'm officially upset.
If anyone cares to notice, this particular bug's first patch has been idling in Bugzilla for nineteen months. After having my work blocked for a year waiting for the r+, I've gotten two r+ annotations from people who really don't have a solid grip on the TxMgr API. So, I asked for r? again (or sr) for the TxMgr-specific stuff. In other words, the r? on the patch is meaningless if I get a decent strong reviewer to check my work. Which has not happened and shows no sign of ever happening, unless I take drastic measures. Bouncing from one unresponsive reviewer to another isn't drastic enough.
Seven days ago, I got frustrated to the point of e-mailing staff (on the advice of #developers, when I would've e-mailed Brendan Eich alone instead, to avoid creating a scene). The number of replies I got is not encouraging.
Now, I expect some people who see this blog entry to instinctively point me to the mozilla.org module owners page under Composer (which is responsible for TxMgr). Unfortunately, that doesn't seem to do a bit of good, because from my point of view as a developer, hardly anyone within the mozilla.org community seems to care about Mozilla Composer anymore.
Daniel Glazman started work on N|vu a long time ago, and I respect him for that. But his company appears to be the only ones working on improvements to Mozilla Composer codebase, and they haven't gotten any large-scale checkins to Composer landed yet. So whatever he's doing isn't quite closed-source, but the barrier to entry (as I noted in the N|vu developers mailing list) is quite high.
It's even higher in the mozilla.org codebase directly, because we're letting it bit rot, byte mold, and Hertz mushroom. The Mozilla Foundation has continued to drive efforts on browsing (Mozilla Firefox, great work) and mail (Mozilla Thunderbird, great work). But who within the community is driving tools to edit web pages? Who's active in owning Mozilla Composer and its components, such as Transaction Manager?
As far as I can tell, there are no visible leaders on that, other than Daniel Glazman (and he's busy).
This means that when someone wants to get reviews on a fundamental piece of Editor architecture, he waits... and waits... and waits...
and waits...
and after long enough, gets tired of waiting and writes a blog entry to beg for help.
Mozilla Composer and our documentation effort appear to be the pariahs of the mozilla.org community. (Coincidence, then, that these happen to be two of my favorite subjects within the community?) It is immensely depressing to see this.
Please, I beg the miniature community of strong reviewers and/or people familiar with Transaction Manager: get me out of this DOM-Inspector-blocking mess and either approve the patch or tell me what I'm doing wrong with the patch. Please, don't leave me hanging, because this noose is getting pretty tight.
Based on my work earlier this year.
The concept is simple, yet highly flexible. I could use some help in figuring out what's required to make it better. The specification I wrote needs work, in particular, and some very careful reviews. I'm calling it 0.6, because although it's very, very stable, I want to leave room for improvement.
If you're going to use it, you'll need the following attribute:
xmlns:http="http://serverpost.mozdev.org/namespaces/serverpost/"
The element can then be referred to as <http:serverpost/>, and fields you designate for the serverpost element have a http:serverpostnames attribute.
I've already filed two bugs against http:serverpost, and there's plenty of room for more. Bug fixers, QA, testers and enthusiasts wanted!!!
(Yes, I know I promised it in twelve hours. It took just under twenty-four. I had other things that came up...)
Ever wanted to have XUL user-interfaces submitting field values like an HTML form? Fear not; I figured out how to do it (and blogged about it earlier this year). So, I'll be launching an official mozdev project for it, complete with XPI. Very likely, you'll see it within twelve hours.
Bug reports, testcases, and suggestions for the specification are most definitely welcome!
In other words, not much. Still, I'm happy with the results.
This is more traction we've gotten on documentation than we have had in a long while. I didn't have any real goals for today, so any accomplishments are a good thing.
I'd say 30-50% of the bugs in Docs are filed against Mozilla's XUL Reference. If the pages are frozen (due to a printed version being published), then we just need an errata page. If they're not frozen, we can use Doctor to create patches. Either way, we can fix a huge number of bugs with just one volunteer taking the time to go through and make patches. I mean it: one person spending three or four hours can cut our bug count by a third, I think.
I did have two targets which no one volunteered for. In a sense, I'm not too disappointed, because these targets I plan on doing anyway.
That's all I've got. Go Seahawks.
Wish has offered us their location for Nov. 20 @ 7:00 P.M. Details on how to get there are forthcoming, pending final confirmation.
http://www.openforce.com/mozparty2/?party=67
I'm not yet ready to commit to a pre-party for the under-21 crowd (zach?). We may just have an informal gathering on a street somewhere.
