Category: all

Catchall for posts.

Trying to Resist

Table with trays of cookies and a large chocolate cake on it.

Today at Confident Coding (women learning JavaScript) I am having to work really hard to stay true to my SuperBetter Challenge to only eat sugar on Sundays.  Tomorrow seems really far away when I’m faced with trays of chocolate chip cookies and a large chocolate cake.  This is practically torture.

Except that it’s not.  It’s the privilege of being in the San Francisco tech community where weekend events come with free food, wi-fi, and great opportunities to learn and network – and there happen to be free cookies a lot of the time. This is one of the ways I try to stick to my self-prescribed challenge to only consume sugar on Sundays.

Distract. Delay. Drink Water.

The D’s above were in some tips for quitting smoking and let me tell you, they work now too.  I walk away from the tray of cookies.  I tell myself that I get to have whatever I want tomorrow, and I have a drink of water.  I’ll get through this day. It’s not the last day there will ever be cookies on this planet.  Usually avoiding something for 10 minutes is enough to get a good few hours free of temptation.  I’m almost there.

SuperBetter: Travel and keeping up with my challenge

This is the first in what I hope will be several blog posts about my SuperBetter challenge, to cut sugar out for 30 days (month of March) and then to switch to only having sugar on Sundays for the next two months (at least).

Most of my sugar-free March went really smoothly.  I have gotten a lot of practice at doing my ’30 days without sugar’ exercise so I have developed plenty of coping mechanisms.  This time around I hardly needed them.  I mostly got through with sticking to mealtimes, being vigilant about preparing ahead for meals, and drinking lots of water.  I think that this is because since my last attempt, I have actually reduced the amount of sugar I keep around me significantly.  However, there’s a big glaring spot in my life where sugar is ALWAYS present – at the office.  Our office has a wall-o-snacks for the taking (this is some Silicon Valley thing I have never experienced before).  I’d wager at least 60% of the snacks are high in sugar, another 20% medium sweet and then there’s a handful of savory things like pretzels, cheese sticks, and V8 — that’s my triad of workplace snack right there :)

The snacks aside, no-sugar March was cruising along and then Jenny and I went to Mexico for her spring break.  We went to Tulum, which is down at the bottom of the Carribean side of Mexico, a place of Mayan ruins and lots of snorkeling.  Mexico (the parts I’ve been to anyway) is a great place to avoid sugar because they don’t seem to do much in the way of deserts.  Sure, if I wanted to I could have bought candy at the store before we headed to our out-of-the-way palapa on the beach but since I didn’t, there wasn’t any temptation at all.  When you have a meal there it’s just the meal – no desert is offered.

The first four nights of the trip were excellent and full of rest and adventure in equal amounts.  I think I really pushed my record for how much time I spent reading in various hammocks.  On the fifth night though, I woke up to an unpleasant illness that wiped me out and left me hollow and dehydrated the next day.  Unable to eat (or really want to try eating) any more of the food provided at our resort, I really had no choice but to have a bit of Fanta orange soda so that I’d at least get a little energy.  This was a bit of a bummer to me because not drinking soda is something I’ve really conquered in my life.  I’m not going to be too hard on myself though, I was sick and in a strange land.  If I could have been at home I could have made myself dry toast that wasn’t WonderBread or I could have had some chicken broth for energy instead of a soda.  The next couple of days were a little bit loose with sugar too because I like to be nice to myself when I’m sick so when we went to the Mayan ruins the next day and the parking lot craziness included a Dairy Queen…well, I’m not the kind of person who easily ignores ice cream :)

In the end, I made it to March 29th without having sugar and then when we got home I re-committed to my epic win where I now only have sugar on Sundays.  It’s Wednesday now and I’ve got a Canadian chocolate bar in the cupboard waiting for me on Sunday.

If anyone is interested, here are a couple of my tips for traveling when I’m trying to work on my eating:

  • Bring snacks you like and can eat.  I bring dried fruits, jerky, and if I’m eating sugar I bring Clif bars as a breakfast option in case there’s nothing good where I’m staying.  They are also useful if I’ll be in hotel with a gym so I can eat something right away after working out and avoid impulse purchases of breakfast pastries.
  • Have a reusable water bottle with you. Fill & drink it empty often, especially on the plane. First of all, it keeps you hydrated (and flying is super dry) but also it helps you feel full and less likely to impulse-shop in the airport gift shop or duty free both of which taunt you with massive amounts of chocolate and candy.
  • Buy a salad (or a sandwich if no salads are appealing) in the airport to take on the plane. Most of the airline food will have sugar in it or sugary parts to the snacks included.  It’s incredibly hard to resist eating while bored/full on a plane because it’s already such an altered state and planes don’t really sell salad.

That’s  all for this post, thanks for reading.

 

 

PyCon 2012 and a second wind for PyStar

Pystar flaming 160 150px

Yesterday when PyCon concluded (and I sadly did not win a NAO robot), I drove home with a sense of renewed energy for continuing to work on building the python community I want to be a part of.  I had a tremendously good time at this year’s PyCon. It continues to become a more diverse space and a place where I feel connected with people who inspire and motivate me.

I was happy to (finally) meet Dana face to face, and thrilled to see several women who had attended PyStar events also now attending PyCon. It’s one of the reasons we left last year’s PyCon with the dream  of PyStar in our hearts.  After the talk about the Boston Python Workshop (which was wonderful and thanks to Asheesh for the shout-out) I was thinking about what makes PyStar unique and whether there is a need for PyStar now that many other alternatives exist.  Hard to believe that only a year ago it felt like there was nothing for women in Python and now there’s shirts stating “Python is for Girls” for sale at the expo hall.

So, with all these groups springing up (and the BPW continuing to grow) do we need PyStar? My gut says immediately “yes” because the more groups focusing on bringing women into geek/programming space and having it be safer and comfortable the better.  There’s more to it than that though.  The groups are all doing great with their various organizers and events.  PyLadies, Ladies Learning Code, and Women Who Code are all holding sold-out events, getting lots of attention, and we’re all working hard to get more women connected to a community of programmers where they can learn and develop skills in a ‘safer’ space than historically has been available to women. The Boston Python Workshop is doing a great job of promoting Boston (as well as Python and Workshops) but I realized that for me, the reason I got excited (and am excited again) about PyStar was exactly because it was non-geographically named and because the name itself is for “all”.  I’m very happy to be in the mix with all those groups and yet I recognize that I still want to try to nurture and shape PyStar into its own thing.

I am interested in continuing to explore how to work on this project with a distributed team and to have PyStar events spring up in various communities and be customized to specific needs. Just because SF is heavy into startups and web apps doesn’t mean that San Antonio, Texas will be – maybe they’ll be more into big data and hardware hacking.  I like the idea of PyStar developing and hosting a wide variety of curriculum for python-driven projects in a central repo that can be cherry-picked as needed by anyone in any city who wants to lead a workshop day/weekend/afternoon. I especially want to figure out how to repeat what I did in Paris last summer, where I managed to organize a PyStar for when I was going to be there visiting. That certainly required some existing connection to the town (Mozilla/WoMoz) but the idea of traveling and setting up shop anywhere a hacker group/women’s community/library can host – that’s exciting to me and carries forward the DIY/punkrock way I’ve always known how to get things done.

In the talk at PyCon, one of the BPW’s stated goals is to try to build up within existing user groups. I see their logic, and it’s sound, but I was not a member of the BayPiggies (the Bay Area PUG) when I first was inspired to start running PyStar events in the Bay Area and I still don’t see the need to be. There are several places where I can announce upcoming workshops, Baypiggies have a mailing list I’m on, and I can promote PyStar events and make sure other groups are in the loop about what we’re doing.  I think this more than satisfies being eligible to be part of the larger Python community, and yet there’s room for more than one Python-loving group in any community. I’m not always looking to insert myself into an existing group – there is something to be said for creating new things and building them with a certain tone/mission in place at inception. That’s what I get out of PyStar, it doesn’t have a legacy or a way things have always been done – the spirit of PyStar is one of distributed organization, shared responsibility, and communal education.

Here are my specific goals for this upcoming year of PyStar:

1. More curriculum on the PyStar site – workshop material that is discoverable by level (beginner, intermediate, pro) and by time commitment (half day workshop? full day? multi-week?). A new person  interested in organizing a PyStar event should be able to see an easy-to-follow list of what to do to set up their own event based on time and level. This can be accomplished through more research on finding existing curriculum and adapting it, more events where we can test and fine tune those curriculum, and also having curriculum hack nights with PyStar organizers and volunteers (multi-city) where we focus on developing material to fill gaps in our topics

2. Have PyStar SingPath tournaments both locally and with other PyStar outposts. While the one I did at PyCon 2012 was a nerve-wracking experience, it was ultimately a confidence-boosting event for me. I encouraged a few women to come try it and it seems to be a pretty fun way to maintain the energy as well as test your new skills between workshops. We can tailor the tournament to be _very_ friendly (prize/badge for all, just for participating). I read/heard something recently about how leaderboard style of competition is not that motivating for women and that beating your own previous results is much more fulfilling.  We can definitely work that into our tournament styles by awarding prizes for most improved and other metrics that a person can get by just doing better than they did in previous tournaments.

3. Incorporate Open Badges into the PyStar curriculum so there is measurable outcome for completing projects and implementing the handing out of badges through the PyStar site. Gregg and I are already talking with Mozilla about their Open Badges project and will continue to keep an ear to the ground on how to implement this into the PyStar site. It would be nice to have a meeting with all interested PyStar organizers to brainstorm on what our badges could be.

4. Find non-profits who need small projects (simple website, automation) done and have no budget – match them with PyStars who would like to learn. Possibly have a connection section on the PyStar site?  Have PyStar leaders be ‘project managers’ and bring a project to fruition through regular PyStar meetups? This is a longer term goal, but one I like to keep floating out there and gauging people’s reactions to. Usually the reaction is “great idea! lots of work!” :(  My vision here is something along the lines of a a template for ‘how to build a (info, fundraising, blogging) site for a small non-profit with a newbie webdev team’ curriculum.

5. A stronger focus on intermediate level programmers. Not to the exclusion of beginners, but to be sure there is room to grow within PyStar This comes up a lot in SF/Bay Area and I know it’s different in each city.  In SF/BayArea it seems really important because there needs to be something to hook in the women who have programmed in other languages or who are CS majors who seem to lack the confidence in themselves now that they are out in the workforce – with many of these participants, it doesn’t take much to remind them how far they are from a newbie – I would like to focus on them a bit more because a) no one else seems to do so b) it provides more volunteer potential and alum/badges c) mentoring opportunities for newbies and job networking for the intermediate level programmers among each other

6. Continue to develop strong connections with PSF, BPW, PyLadies, and __insert_group_here__ organizers. – I should have proposed a BOF at PyCon for organizers to get together and share plans — I would really like to work alongside these other groups in a sustainable way, we all have admirable goals and could share some resources and people-power.

7. PyStar gear & promo materials, fundraising. Set up a cafepress store to sell some PyStar goods and also try to get a few donations to set up an account for PyStar that would allow us to a) pay for the domain name I just renewed b) potentially buy other domain names for side projects we come up with when we work with non-profits  c) cover the costs for creation of handouts, cards, other promo materials to give out at events promoting PyStar

Get involved!  The project currently lives in github and organizers/contributors can reach each other through our mailing list.  If you want to host an event, help with curriculum, or otherwise work on making safer spaces for learning Python happen in your own community, get in touch.

Dare 2B Digital 2012 – Wrap up post

Fox with firefox logo

Better late than never, I will recount Mozilla’s participation in the 2012 Dare 2B Digital conference back in February down in San Jose.  This year we were hosted at the eBay campus and instead of being out in a hallway demoing and playing with open video and universal subtitles (2011) this year Mozilla was all about making, in a large space shared with Microsoft, encouraging the girls to work with a variety of hardware, circuitry, robotics, and creating 3D printer designs for a MakerBot.

Before I go into the details of the kits and the day of the event, there are some very important people to thank:

Tremendous amounts of props must be first given to Emily Lovell whose soft circuits teaching guide I discovered at the 2011 Grace Hopper Celebration of Women in Computing.  Her exercises, diagrams, and lists of resources were at the core the kit I designed to teach the girls about parallel circuits through assembling a felt fox and attaching LEDs to the eyes that are powered by conductive thread and a watch battery.  Thank you to Mozilla for sponsoring the Dare 2B Digital conference again this year, it is such an important space for us to be in as it gives us a chance to promote open source to a young audience that is still undecided about college majors and it’s our chance to encourage them to at least consider a technical career path. I hope that having an early, positive, creative experience with Mozilla and open source technologies provides the girls with an awareness of alternative ways of engaging with technology. Mozilla Reps provided the budget for these kits to be made – not only for the workshop attendees, but also enough kits to put one in every take-home bag for all conference participants.  It is certainly my hope that many girls who couldn’t make it to the workshop due to lack of space will still attempt to make their foxes at home with a parent or sibling.  Finally, I cannot thank enough the various Mozilla employees and other friends who helped me assemble 350 kits for the actual event – my vision for this event could NOT have been done without their generous donations of time and their assistance on the day of the event helping the girls complete their kits. Thank you especially to day-of volunteers: Kate, Vicky, Alex, Christina, the Super Awesome Sylvia and her parents James and Christina,  and the add-hoc assembling factory workers: Mariko, Heather, William, and the entire UX team at Mozilla.  My girlfriend Jenny also helped me assemble some of the first kits at home while I cut all the felt sheets into smaller sizes for the foxes. My most sincere gratitude to you all, it went off without a hitch…except for the handful of batteries that exploded…but that was my fault :)

Now for some detail about what was involved in this project in case you want to replicate or improve on it.

A lot of felt foxes

The idea was pretty simple. The kit would be a takeout food box that contained everything needed to make a parallel circuit on a felt fox.  I ended up designing the felt fox myself after attempting to make something work with Lisa Higuchi who does amazing work but as I found myself running out of time I just created a simple pattern that could be held together with felt glue and then sewn/wired up in about an hour – which was the length of the workshop.  The soft circuit guide had the information needed for ordering supplies so in the end the kit’s component list looked like this:

  • 100 9×12 sheets of copper brown felt (400 fox faces)
  • 100 9×12 sheets of white felt (400 fox eye areas)
  • 30 9×12 sheets of black felt (450 nose/eye/inner ears)
  • 10 spools of conductive thread from Adafruit
  • 400 3v batteries
  • 400 battery holders
  • 800 yellow LEDs
  • 400 red takeout boxes
  • 5 bottles of felt glue
  • 400 small ziploc bags
  • 400 needles
  • 1200 pins (intended for holding the felt pieces together for sewing, they ended up being superfluous because of the glue)
  • 400 manual/pattern sheets

 

Shot of the pattern and instructionsThe felt firefox kit contents

I literally threw together a manual and a pattern at the 11th hour, as the UX team was coming to help me assemble the kits one night after work.  The manual leaves out a lot of the detail as to HOW to make the felt fox. Fortunately it includes a picture of a completed fox, so hopefully a resourceful teen at home can determine how to make her fox kit work. I have definitely learned from this experience to make creating the instructional materials a much higher priority next time.  The pattern was done in haste with a sharpie, me tracing around the parts of my prototype fox, I’m actually pretty OK with how that part turned out. When we assembled the kits we put all the small components into a ziploc bag and put said bag, one square each of white/brown/black felt, and a folded up instruction sheet into each takeout box.  The takeout box was a really robust container for kits and yet kept things light. I had no trouble carrying the 350 kits, in various bags and boxes, to my car to take down to SJ on the day of the conference.

The kits are in the bag stuffing lineEarly in the morning on Saturday February 12th, 2012 I drove the 350 kits down to the eBay campus and kept ~70 kits in our Maker room, leaving the rest with the D2BD volunteers who were stuffing bags with swag for the girls: Make magazines, usb bracelet, stickers, notebooks, a water bottle, and (among other things) a Mozilla felt fox circuits kit.  Then back in our room I had two of the Mozilla volunteers for the day make their own foxes so they’d be ready to help the girls when the first round arrived a few hours in.  Kate and Christina did a wonderful job of creating their first parallel circuits and spent the rest of the day being professional felt fox makers :)

Helpers make their foxes

As with last year, I found that out of the three workshops we did that day the first was a bit rough, the second quite smooth and the third was a cakewalk.  We can learn so much in one day about how to improve the process and the set up.  The first thing learned was that we had a bottleneck situation on scissors and glue.  5 bottles seemed like a lot to me but when split between two tables with at least 10 girls at each that was no longer the case.  I had brought in all my scissors from home, which turned out to be a lot (6) for a home, but not enough for the workshop.  We did scare up a few more pairs and optimized for workshop two by keeping the pre-cut paper pattern pieces for the next group of girls to minimize scissor time needed.  Another surprise: some girls did not know how to sew.   This was something I hadn’t thought of ahead of time since I learned to sew at a pretty young age.  This fact leads me thinking that because of time constraints, 1.25 hrs per workshop, using ‘squishy’ circuits might have been a stronger learning experience here.  The sewing is probably more appropriate for a half-day workshop or even full day if possible.

Customization of the fox pattern

Customizations happened.  I loved that girls immediately took to hacking the fox pattern as designed by me; adding bows, crowns, and eyelashes to their foxes.  It made me glad I hadn’t found time to pre-cut the fox parts.  The back of the fox head is easy to draw a circuit path on and see/experience polarity – using sharpies on felt was a great way of going over the concept of a circuit, right on the material about to be used.  I am really happy with the overall teaching experience here.  Several girls showed incredible tenacity in the face of adversity.  One young woman in particular, having a very hard time with the sewing, went out and got her lunch and then brought it back to the table to continue her work – she re-did the sewing and managed to get it working.  The whole time she was silent and focused and I really wish I had pointed out to her that her attitude was the most impressive, hire-able skill I can think of.  I’m sure she’s going to do well in whatever field of study she pursues.  One young woman cracked me up when she became frustrated with threading her needle, exclaiming “This is why women revolted!”.

In conclusion – the event was a tremendous success – both the conference as a whole and the Mozilla workshop flourished this year. The conference does a great job of pulling feedback from participants, as they must hand in a form to get their swag bag at the end of the day.  We see in the feedback that we did a wonderful job of getting the young women excited about and considering career paths in technology. In the summary from the feedback forms “87% thought the robotics workshop (Mozilla/Microsoft) was great or good”. Also 100% of respondents would recommend this conference to a friend or another parent.

I really look forward to dreaming up something next year to top this.  I have no fixed idea yet because part of the fun of doing this conference/workshop is waiting and seeing what exciting new open technology would be a good fit at the time. I’m definitely going to keep the issues from this year in mind when formulating a plan for next year, and pay attention to minimizing participant wait times in order to increase overall satisfaction with the project.  When I initially came up with this idea, I was worried that it didn’t have a strong tie to Mozilla’s mission, but as I continued to develop and finally executing it I felt more and more like the way we work on projects like this is such a product of how we work on keeping things open on the web.  It was thanks to the web that I found the guide which helped me with planning, it was thanks to the spirit of the open web that people I work with (and some with whom I don’t) came out and volunteered to help make this happen. Getting your hands on a building block of technology, modifying it to make it your own, sharing the results – that too is the open web, and it’s what the day provided for all the young women in our workshops. I look forward to seeing what the future holds with these potential hackers in it.

Group shot with completed foxes

Lukas helping with fox making

 

 

 

 

Try results to the bug(s) of your choice upon completion

The TrySyntax helper and TryChooser wiki docs have both been updated to reflect the new option when pushing to try where you can now ask to have your complete summary of results (and a link to the tbpl page for your revision) posted as a comment to the bug on completion.  Here’s a live example to check out:

Sample comment in a bug when using –post-to-bugzilla in your syntax.

Now you have more control over how you get your try results and how noisy a try push is.

Please send comments and issues to the bug tracking this work.  Thanks for trying it out!

A quick morning rant about “gender” and data collection

This morning I read that Google+ is going to make your name and “gender” required to be public if you want to participate.  This bothers me for several reasons:

Web sites and forms notoriously say “gender” when they mean “sex” and only put M/F or Male/Female as options. When this type of choice is required but called “gender” it erases many people who do not feel that those options cover their gender since that is actually something way more mutable than your assigned sex at birth.  Solutions: Call it “sex” which is really what those two categories are or don’t make something that is not in fact binary into a required choice of two options.

Google are so proud of being all scientific and data driven and I’m frustrated that they would not take the opportunity on their new potentially game-changing social platform to re-vamp data collection. Don’t they have the processing power to allow people to put in whatever they like as “gender” and let the power of the search sort things out in the end?  If a small number of people want to put “jedi” or “dog” let those people find each other!  Who cares if there are some people who don’t feel like Male/Female defines them?  Why Google? Why do you want to act like two boxes can cover the breadth of human experience as it relates to gender in this world?  Why can’t you innovate on the small things as well as the big things that affect human interactions?

I’d really like to see a shift in how we collect data where there is more trust that the user knows who and what they are and that they want to share this information at their comfort level and that those on the other side, let’s call them advertisers (cause isn’t that what it all comes down to?), be the ones to deal with the outliers and uniqueness of human experience instead of trying to bash everyone into a two-party system.

Sidenote: When I have collected data recently for PyStar and allowed the gender field to be a text box I have found that the expected percentage (98%) of people entered “typical” information like woman, girl, female and that those who needed to express a different response appreciated the ability to do so by entering something else.  Leaving this field to user input choice did not result in a messy, chaotic list of random words or unidentifiable descriptors.  I fear not that most people will suddenly start to be something else when given more autonomy on forms.

June in Paris – 2011

One of my favourite paintings at the LouvreScammers at the LouvreJust one of the many Native appropriation images in ParisClassy BMW ScooterRuffneck Hip HopDon't you want to be tan?
Turbo DraineWarnings for food commercialsMounir est guardien des biscuitsPascal and the Mozilla Paris office treat cupboardEscargots "Papa"Salade gargantuesques Boyarde "complète"
Who needs a bell?2 Croque-MadamesSpeculoos Panna CottaAmerican Money to patch your pantsLost Unicorn in ParisJenny & the Moulin Rouge
Montmartre cemetery warning #2Montmartre cemetery warning #1Social Assistance in Paris?Jenny, Montmartre cemeteryJenny in a crypt at the Montmartre cemeteryIMG_20110611_172239
June in Paris – 2011, a set on Flickr.

So here’s the most recent set of images from our last week in Paris. We’ve been settling in, and while there have been some low points where things seemed too overwhelming here we’re really having a great time getting into a little routine here and finding fun things to do at night when I’m done working.

The pics have some stories and descriptions but let’s see what else I can tell you.

We’re adjusting to our tiny apartment which I have been lovingly calling “our bathroom”. People laugh and think it’s cute that we’re so shocked by the tiny apartments but I really don’t think anyone grasps how our rental is not an apartment at all – I’d be fine with a tiny apartment and understand the limits of space in Paris and the high price of real estate. We are in a bathroom however with the cheapest curtain in front of the toilet, and everything else furnishing the place is also the cheapest possible stuff from IKEA. The person who rents this 12 sq m room has basically done the bare minimum to make it rentable. I’m not going to spend a whole blog post complaining about the rental though – we’re making it work. Also, my co-worker William lent us his place last weekend and will again in another week so we’ve had a respite and have enjoyed some space and some more comfortable living on occasion.

Let’s talk about food, one of my favourite subjects. The food here is generally pretty good if you don’t care much about salad. In the past few years I have started to care much more about eating greens and vegetables so it’s been a challenge to basically eat bread/meat/cheese/sugar all day, every day, without any salads in there. There are salads but they are often either a) tiny and covered in mayonaise or b) topped with potatoes/meat/cheese (and maybe some mayonaise too!). So I’m definitely missing fresh fruits & vegetables in my diet. However, last night we went to a place William recommended called “Entre les Vignes” (Between the Vines). It’s a cute little bistro near Gare de Lyon and it had the most delicious steak tartare ever. We will definitely go back for another round of that before leaving town. I have had a very fresh and tasty crepe on the street, a ham & cheese one so I still need to do the sweet kind at some point. I’ve had some South-West cooking at a place called Chez Papa which involved the above-mentioned “salad with meat and potatoes on it” as well as escargots in cream sauce with tomatoes and mushrooms and also a lamb cassoulet. I love cassoulet and want to go home and make some of my own. We also cooked at home a few times and just did some simple pasta dinners to accompany wine & reading.

Life in Paris was hard the first week because of technical difficulties. The internet in our room is incredibly slow and unreliable and Jenny relies on my laptop sharing internet so that her iPad (which does not have an ethernet port) can get connected. This means her internet window when not at school (French classes) is about 15 minutes before I go to work in the mornings. This means she has to know ahead of time everything she might want to do so she can map it out. Our cell phones here required some intensive signing up procedures including sending copies of our passports to some email address, and then getting them refilled is a whole other pain in the butt. Also, the Vélib rentable bike system wouldn’t accept our credit cards at the stations so we learned the hard way that we need to buy them online ahead of time. We’re starting to laugh at how often we’ll try to do something only to find (regardless of the level of planning we put in ahead of time) that things are closed, we’re too late (or on the wrong night), or things are sold out. Metro stations, restaurants, concerts, canal boat rides. The internet has both made it easier to make this kind trip and also removed the ability for spontaneity in travel.

We have gone to see two movies: Tomboy and X Men First Class. Tomboy was all in French and Jenny was able to follow along pretty well. I loved that movie and highly recommend it. It will probably do the rounds of the queer film festivals this summer. X Men was lots of fun for me, Jenny had a nice nap. I love the X Men mythology so much and spend a lot of time trying to decide which mutation would be the best fit for me. After last night I’m mostly leaning towards the telepathy cause it seems appropriate for a slightly controlling personality who wants to help lots of people.

Tonight we’ll go see some art at Georges Pompidou where a modern art gallery lives. Also we just found out about this Claude Cahun retrospective from Onya – yay!  This weekend we might go to Versailles and try again to do the canal boat ride that takes you under the city in these cool tunnels.

That’s it for now.  Gotta get to work!  Which reminds me. The Paris office has been great to me and so awesome to work out of. I really do want to see if, over time, I can work out of every Mozilla office at least once so that I can get a feel for all the different customs and office atmospheres in our very dispersed company.

Tree Closing Downtime Notice – 4am – 8am PDT Thursday June 16, 2011

Trees will be closed for downtime so that we can land the following:

1. https://bugzilla.mozilla.org/show_bug.cgi?id=662396 — Fix time on dm-wwwbuild01

2. https://bugzilla.mozilla.org/show_bug.cgi?id=600980 — Set journal_mode = WAL for dirty places profiles — This mean new performance numbers will start on Thursday morning after the downtime

3. https://bugzilla.mozilla.org/show_bug.cgi?id=649123 — Run ANALYZE on dirty places.sqlite files –  This mean new performance numbers will start on Thursday morning after the downtime

4. https://bugzilla.mozilla.org/show_bug.cgi?id=663568 — reboot the DNS and DHCP servers in scl1 — Rebooting these servers has been shown to burn builds in the past, requires a short (~5min) outage to reboot these servers to allow updates to take effect.

5. https://bugzilla.mozilla.org/show_bug.cgi?id=663963 — change LDAP to see if that speeds up mercurial — This change should be entirely transparent.  Hg processes that are running at the time that the change was made will have already loaded the NSS LDAP module and will continue to use it until they exit.  The only issue to be aware of is that changes to hg access (group membership, or the creation of a new account) will not automatically propagate to the hg servers the way they do now.  If any hg access changes need to be pushed urgently, we can do that manually.

If anyone has a reason not to proceed with this downtime, please let me know.

Thoughts on cultivating an “Everyone is Remote” attitude

As I write this I am working from Paris and our team timezone spread looks like this:

  •  Rangoria, New Zealand: UTC (+12)
  •  Bucharest, Romania: UTC (+3)
  •  Istanbul, Turkey: UTC (+3)
  •  Paris, France: UTC (+2) <--- ME!
  •  Ottawa, ON: UTC (-4)
  •  Toronto, ON: UTC (-4)
  •  Philadelphia, PN: UTC (-4)
  •  Clifton Park, NY: UTC (-4)
  •  Chicago, IL: UTC (-5)
  •  San Francisco, CA: UTC (-7)
  •  Mountain View, CA: UTC (-7)

I’m going to go out on a limb here and say this: Release Engineering does a good job of working remotely with each other. We are 15-16 people (with a few more contractors/fte on the way) and it doesn’t matter where you live for you to work with us. Here we are in our meeting yesterday:

Releng Weekly Meeting – June 2011

Quite the impressive Brady Bunch layout, right?

Here’s what we do that I think works well for working remotely:

* We meet once per week as a whole group on Mondays. This starts the week off with a status update on our major projects and also a chance for individuals to speak up about anything they’re working on that they’d like people to be aware of.

* We are always having conversations in IRC amongst ourselves and with others in several channels. We use #mozbuild as a backchannel for our inter-team discussion, #build for access to a larger group of fellow Mozillians (like philor, Kairo, and ted for example, who often need to liaise with us), #developers is also a place we frequent and then there are some IT/mobile/QA/release-specific channels we hang out in as needed. I think this helps us have a presence in many areas of engineering/dev/IT and even with some of the non-technical teams at Mozilla where inter-team communication needs to happen. It keeps us in the loop on what various teams are up to and also provides the IRC equivalent of being able to overhear water-cooler chat and participate as well.

* We keep wiki pages for most everything. From “how-to” pages for our own release process, automation details, and project planning all the way to pages for outside-releng folks like the Try Syntax. While I find wikis frustrating the minute the information is out of date, the fact that I can update them and find them in my awesomebar quickly when I need them is very valuable to me.

* We email our group with important notices and changes to how things are done. There are not often times when someone will say “Oh I didn’t know about that” and the response is “It came up in the hallway when I was talking with so-and-so”. More often than not, the person driving a particular upgrade or change to current practices will send out an email to the group with details of : a) what the change is b) what it means going forward c) how the message has been disseminated to a wider audience (if needed) and finally d) where the wiki pages (and bugs, if needed for reference) can be found. This allows any of us to find the information N time units later when the change actually comes up in your daily work and you’re wondering “What was I supposed to do when trying to use the new X again?”

* We all meet up face to face approximately once per quarter. Twice a year for Releng work weeks and twice a year at Mozilla all-hands/summit gatherings. We take these as opportunities to discuss larger topics with lots of brainstorming, whiteboard scribbling, and animated opinion-sharing. Notes from meetings like this turn into wiki pages (often during the meeting itself) and those can become specs for projects/bugs to carry the work that needs doing to the next level.

I think that gives a good idea of our team practices. Now here are some thoughts I’ve been having about lately with regards to working remotely in Mozilla as a whole. It helps that I’m currently working in Paris right now and am pretty much completely opposite of the PDT work day but some of this was on my mind even when I was in SF.

I think Mozilla has an amazing opportunity to set trends in how to work with distributed teams. We already have people in every time zone! Even with the incredible advancements we’ve made with our use of video/audio/irc tools (airmozilla/vidyo), there are some ways in which MV is still the eye of Mordor for the company.

I would like to see us shake that up so I think we should try:

* Not having meetings in large groups in MV (except at all-hands). Instead, put small groups of people in various rooms around the building so that “we are all remote” is a reality for everyone so that the clarity of the communication channels are taken seriously. This means we all become just as invested in the quality of audio/video feeds, using tools like Etherpad for public collaboration, and advocating best practices for the speakers/presenters as those who are not in MV. I bet we’d see an increase in contributions to new tools & meeting practices if we were all experiencing meetings remotely on a regular basis.

* Rotate the hosting of the Monday meeting so that over a series of Mondays it would be run from various remote Mozilla offices and this would mean that it moves in time (which could be scheduled in advance) but it also means that all offices get a chance to feel special and be the center of attention. We’ll have an opportunity to get to know our co-workers from other offices better as they present the meeting and I even imagine some friendly competition could develop for who can run the most energetic and engaging meeting.

I’m really interested in trying that second one. The most MV-centric thing we do is have our 11am PDT meeting on Mondays be a locked-down time. What if it rotated around each week and just happened somewhere in the 9-5pm spectrum of your timezone? We could create a schedule for it so folks could have lots of notice for scheduling their other Monday things around it. Also, maybe sometimes you might miss one Monday meeting because it’s just not at a good time for you but that’s something some of our remote workers might say is just par for the course.

I know the idea needs more work, but there’s the nugget of it. Curious to know what others think. I’ll be continuing to talk this up – maybe we can have a larger discussion at the all-hands in September. Eventually I’d like to see us get to a point where we all think of ourselves as remote since if you look at Mozilla as a whole there does not really need to be a “hub” where one would be “local” compared to everyone else – there’s just planning for timezones/meetings and then all the people we work with doing their amazing stuff.

Use Try? Read this.

Two updates to Try are about to go into effect which enforce asking for what you want using the try syntax and configuring how much email you want to get with your results.  Read more below.

Bug 661409 – Now that this has landed, a push to try only generates email about a particular try builder’s results if it does not succeed.  You can adjust this to be more verbose by adding a -e/–all-emails to your try syntax if you miss getting over all those emails, or you can just shut off the emails completely with a -n/–no-emails in your commit syntax. Note that you must be using the “try: ” syntax for these email flags to be picked up which leads quite handily to…

Bug 649402 – Try syntax use is about to be mandatory as soon as this bug is fixed and the hg hook is enabled on the try repo. We’re doing this to encourage developers who use try to take an extra moment and request only the resources they absolutely need on their push.  This should reduce the test/talos load that has been increasing wait times across all branches during busy periods.  One additional psychological change is that the “try: -a” syntax has been removed and in order to ask for a mozilla-central matching run you must be more explicit: “try: -b do -p all -u all -t all”. I’ve updated the docs to reflect this change as well as the TryChooser syntax helper webpage. We’re really not trying to make your life harder with this change, approximately 50-60% of pushes to try currently use the try syntax and if you push to try without it you will get a helpful message pointing you to docs and syntax builder.  Check with #developers for tips and tricks from the folks who’ve been using this since the beginning, I know they have many including using the newly-minted Mozilla-Inbound repo where a push will get the complete set of tests/talos if you’d like to let your patch bake for a bit after doing a selective try run.