Category Archives: IT/Desktop

When I Moved Abroad

I grew up in the States. While growing up, and got a pretty good feel for it.

So I moved there. At first, things seemed to go OK. Sure, there was a bit of a language barrier, but I was committed. I had a phrasebook. Some days were great, I did everything I needed to do and felt on top of the world. Some days I felt clumsy just trying to do normal tasks like food shopping. But I kept on going.

One day, I found a group of ex-patriots from the US. I went to the first meeting, a bit nervous, not quite sure what I was seeking out. What I found was relief. I could speak English without worry about how fast I was talking, or that anyone would assume I was a tourist. I could speak broken Garistanese without worrying about my accent and without worrying that I was being judged. I could talk about American things without having to explain it in detail. It was so calming, and it made those hard, clumsy days just a bit easier, because I would go back to the group and talk about struggling for a word, or my embarrassment.

We would also go out together, and there was strength in our numbers. I noticed that we all spoke better Garistanese when we were out with each other. I guess we just felt more comfortable.

Then Christmas came around. And let me tell you, it was unbelievably difficult. I love Christmas. Decorating the tree, baking cookies, shopping, the way everyone is nice to each other for 6 weeks (except when trying to find a parking space). Best of all, I love singing Christmas carols.

My first Christmas in Garistan made me realize just how different I really was. They put cotton candy on their trees to decorate them? What’s with the buckets in front of the fireplace? Tell me again what the traditional Garistan Christmas cake is? There are different songs….and even the familiar ones are sung in Garistanese.

I was out of my element. It was upsetting and frustrating. I could do what I wanted in my own apartment, but venturing forth into the street just reminded me how different I really was. My group of English-speaking US compatriots were the best gift I had that year. They helped me navigate the Christmas differences, and they even pointed out some similarities I was taking for granted. We did our own American-style traditions, including a cookie swap. It was so comfortable, and made that first Christmas really bearable.

But I cannot deny that I felt I was an outsider. I would have moved back to the States if it weren’t for my group, encouraging me and just being the same as me. It was not really the Garistan people that had me feeling so uncomfortable, it was the culture in general. It is not what I am used to, and several times I felt as though I was being treated rudely, though now that I have more experience with the Garistan community, I understand that is the way they interact, and culturally it is not thought of as rude. My Garistan friends would ask me to come out with them, but sometimes I did not want to go to a large crowded party full of all those things that made me feel uncomfortable.

SPOILER: Garistan is a made-up country. This story is an analogy about women in tech. Think of Garistan as a random tech community – maybe it’s MySQL, maybe it’s Python, maybe it’s sysadmins, devops, whatever. The group of US expatriates? That is a women-only space.

It is not sexist to have a women-only space in a community that’s so very male-oriented and has so many men in it. It is (arguably) a necessity if you want more women to be a part of the community. If you want more folks from the US to move to Garistan, wouldn’t it make sense to have comfortable spaces for those who speak English?

Christmas in this story could represent a conference or big event. I read an article that complained about women-only hackathons, because a men-only hackathon would be sexist, so of course a women-only hackathon would be sexist. And it is so utterly and completely wrong. Most men do not need a comfortable space to be among other men during a tech conference, because the conference is already mostly men. Just like most folks in Garistan do not need “Garistanese-only” spaces, because Garistanese is the dominant language there.

Is it the fault of Garistan people, that they have a Garistanese culture? No. And it is not the fault of men that they have a male culture. But if you want to retain those who come from the US, you have to change a little, offer up some more English, maybe acknowledge the Fourth of July in some little way. Same thing with tech culture – if you want to retain more women in the community, you have to make the space a little more comfortable for us.

I would also like to point out that not all women feel this uncomfortable. In fact, I actually do not feel this way most of the time. A mostly-male space does not feel that foreign to me. I always hung out with my two brothers, most of my friends growing up were male, and I actually have to put effort into being friends with other women. You can think of this as someone who moved to Garistan after visiting every year for decades. I know how “male spaces” work and I am comfortable in them.

Some women are comfortable in mostly male spaces. That does not indicate that those spaces are welcoming towards women. Maybe they are, maybe they are not. The presence of a few women means that those women are comfortable enough, but that does not mean that many women would feel comfortable there.

The level of comfort that any one woman has can vary, not just on their own experiences, but also depending on the community, and depending on her own situation. Back to the analogy, someone might be completely comfortable with the Garistanese language, having studied it, but still have a hard time with Garistanese culture. Or maybe that person is fine with everything except the different Christmas traditions. Most of the time, that person would fit right in, but Christmas is a trigger point.

If I make a “math is hard!” joke among my coworkers, they know I am smart and maybe just having an off day. If I make the same joke and someone’s listening who does not know me, they might get the impression that I really do not know what I am doing.

I will freely admit that I laugh at inappropriate humor on a locked-down IRC channel, because I know the audience, and I know the intention of the person telling the joke. Those same jokes on a public channel or at a party where I did not know anyone or even on Facebook have caused me to speak up and say “that is not funny.” Context is critical.

To the men reading this – you have a male culture. That is perfectly OK, just like Garistan has a Garistanese culture and everyone speaks Garistanese. But if you want more women in a particular space, you have to change the culture in that space. If you do not know everyone who is listening, be more thoughtful about what you say. And try to remember that we women are trying to learn technical stuff (Garistanese) and cultural stuff (Christmas traditions) at the same time.

Keeping IT Positively Visibly Relevant

Back in December in an IT strategy meeting, my boss came up with a great phrase – “keeping IT visibly relevant”. It sums up the long-standing problem most IT teams have in their companies – how can you make it so IT is seen as positive and good? And not just “really great when the fires happen” but day-to-day?

How can we keep IT visibly relevant, in a positive way?

Part of the problem is prioritization (IT is currently understaffed, has been for years, and our headcount for 2013 does not actually bring us up to full staffing). It’s difficult to balance the “must get done” quarterly goals with the day-to-day requests, but we also cannot say “no” all the time. Because at the end of the day, it’s not that “I can’t do this thing for you because I need to do this thing for my team,” it’s really a matter of what’s most important to Mozilla as a whole.

How do you keep IT visibly relevant, in a positive way?

I asked this on twitter and the responses ranged from “shut down printers” to “organize the office pool” to the more helpful “make it to meetings and be involved” and “present at user groups”. See:

Certainly, being forward-moving in technology is something we do. We speak at conferences, we help run http://hangops.com/ all while getting the rest of our jobs done. However, this shows that Mozilla IT is visibly relevant to those *outside* the company. And again, balance is difficult – working remotely definitely is a boon, in the last 6 weeks I presented at Linux.conf.au in Canberra (Australia), RMOUG Training Days in Denver, Scale11x in Los Angeles and Confoo in Montreal. I would have had to take a lot of time off work if I could not work remotely! But time at conferences *is* time away from the office, so there’s another point to balance there.

So, I am looking for your tips and tricks. What has worked for you?

Liveblog: How to Use Puppet Like an Adult

My Mozilla coworkers Ben Kero and Dan Maher gave a standing-room only presentation at Linux Conf AU about “How to Use Puppet Like an Adult”. It was fantastic!

Data != logic
Business DATA does not belong in modules, but business LOGIC is OK.

What are the data sources, then?
Hiera – lightweight pluggable, hierarchical databases. External to the modules, you can use many backends, including MySQL. New feature, standard in puppet 3.0. If you like YAML (and you should), you’ll like this.

$var = lookup('something') # unscoped (complicated)
$var = lookup('namespace::something') # scoped (yay!)

Another data source is puppetdb. This is a bigger topic, but the important thing is that it can be used for high performance store configs.

Where to find pre-built modules for puppet?
Github
Puppet Forge

Or you can write your own module
….but don’t waste time building your own, say, Apache module…someone else has a better one out there.

Is that module right for me?
What to check:
OS/distribution
Complexity – Can you read the module and understand what it does? If not, this might not be the module for you.
Popularity – the more people using/forking it, the more support is probably around. Also age of last commit.
What’s the documentation like?

Recommended pre-built modules – these work, and they’re good. Analyze how they work and learn from them:
puppetlabs/firewall
puppetlabs/cloud_provisioner

When rolling your own modules – if this is going to be a one-off, do whatever you want. If you want to make it open source, know that someone else will use it, and make it more generic.

Use parameterized classes. This allowed you to separate your business data from your business logic. You can avoid having passwords, ssh keys, etc in there, and then you CAN open source it.

Make sure it’s documented.

Module template
puppet module generate author-mod_name – gets you all the files you need with the necessary templares (e.g. README has the sections you need).

module template slide

Note: Everybody should be doing spec testing, not just puppet…..

Parameterized classes
Similar to definitions – they are passed in data. It’s how to separate data from logic. If you don’t get anything else, get this:

parameterized classes slide

These help you write your manifest one time for different nodes. If you have 10 web servers with different node names, write one manifest, and use logic and parameterized classes to instantiate that manifest 10 times. Don’t write 10 manifests.

USE A STYLE GUIDE
“Who here has written Perl code? Who here has written Perl code that someone else can read? USE A STYLE GUIDE”

Parser Validation
just run:
$ puppet parser validate manifest.pp

Parser validation example

Put this into your commit hook, so that parser errors don’t get committed.

Linting
A way of making sure code meets the style guide. External tool, but stable. Very customizable, you can use your own style guide, and you can have it ignore certain things (e.g. don’t care about quoting everything, so don’t error on that). You can put this into commit hooks too.

Linting slide

puppet-concat
Dynamically build files out of lots of parts. How you can build good config files for daemons that don’t support .d directories. Assume you have puppet-concat installed already, it’s widely used, because pre-built modules use it too.

puppet-concat slide

stdlib
Put out by puppetlabs, not actually part of the standard library, but contains lots of useful functions. This is also widely used. Can check if the variable is boolean, integer, strings, can collide hashes together, can check functions, etc.

Sanity preservation
Set default values for your variables – make sure they’re sane – you can pull variables out of facter.
Verify content – play it safe, don’t blithely act on user data. You can throw an error (e.g. if you have a string instead of an integer)
Mutually exclusive declarations – ensure when you start navigating down one logical path, it can’t go down the other path. This comes down to if/then programming, makes more layers to your manifest, but you can make accurate statements about what you want the module to do and predict what it WON’T do. Being able to predict what puppet will and won’t do is important.

Useful Log Output
Functions for each log level
e.g. notice(); warn(); err();
Make these informative and human-readable. What broke and why, can other people understand what’s going on with this?

Puppet As a Source of Truth
Build an ecosystem around puppet. The more you use puppet, the more it describes your infrastructure. How do you do this, though?
You can use the puppet data library (PDL) – a collection of services with an API so you can query puppet from other services – e.g. inventory system, dashboard, etc. You can also use it from within puppet.

You can build an inventory service to know all the facter information about all the machines. You can use the run report service for dashboards like puppetdashboard.

You can download a .dat file and visualize it with graphviz to see how your logic paths look. This .dat file comes within puppet (you do “gem install puppet” and then puppet with some options and you can get it).

The take-home:
take-home points

Linux in the Flesh: Adventures Embedding Linux in Hardware

This is not quite a liveblog, but a set of notes about the points I found most interesting in this morning’s Linux Conf AU keynote, given by Dr. Andrew “bunnie” Huang, best known for Hacking the Xbox and developing the chumby.

The talk was a fascinating look at how complex developing embedded Linux devices is. Let’s start with the takeaways:

Slide with takeaway points

One of the points bunnie made was that customizing embedded devices is really a frontier at this point (though he did not use the word “frontier”). There are not a lot of folks doing it. The “Sustainability” bullet point emphasizes this – bunnie talked about how people create custom environments for the device and want updates pushed to it, but that’s difficult because the environment may mean special tweaks to the updates.

The cost point was interesting because we often see a feature and wonder why they cannot put a feature that seems low-cost to us. Here is why:

slide with why low-cost features aren't that easy to add

So if the Cost of Goods Sold (COGS) is $30, you want to add some margin so you can earn a living, say $15. The retail markup will be $45, so the total cost to the consumer is now $90. Then there’s a bit of rounding up to the magic price of $99.

Now if you decide to add a $5 feature to it, the COGS is now $35. Your margin becomes $17.50, and the retail markup becomes $52.50. Now the total cost is $105, and gets increased to the magic price point of $149. So there is a lot of argument about *which* $5 features to add with that price point. (Also note that $5 does not seem like much, but when your total COGS is $30, you’re adding 16.67% of the cost)

The tech stack is surprisingly full of old-school standards, I was pretty excited to see MySQL in it:

tech stack including MySQL

One of my coworkers left the keynote looking at the challenge and wanting to take it on. I heard all the complexity bunnie told us about and realized, that’s not a stack I want to spend the time to learn, for what I would do with it. It is not where I want to spend my time…here is a slide that shows where the time was spent on the chumby device design:

time spent on chumby device design

The actual hardware design, encircled by a box on the slide, is 11%. And the 19% in the product and software design is iterative, some of the 11% of time in the hardware design overlapped with product and software design, because they are intimately tied together. In fact, they’re so intimately tied, that the hardware is actually “dominated by software concerns” – this is not something I was aware of, but of course once I think about it, it makes sense:
shape of hardware is tied to software

bunnie got these times by going back to e-mails, so this is more like the phases of the project. The bulk of the time is the marketing and business development plus the mass-production ramp-up. bunnie talked about the tooling, which was also quite interesting. After showing us all the steps and explaining that a tool run takes 6 weeks and can cost around $20k (I assume USD, that was not specified), this slide came up:

startup vs. Apple tooling costs

What a startup will do is try one design, spending the time and money, and if it’s not right they’ll have to spend the time and money again, in a serial way. Apple can put down $100k and have 5 different tooling runs happen simultaneously, and they pick the best one, so at the end of 6 weeks, Apple has a great design, whereas a startup only has their first design.

And with that being said, Apple re-tooled the iPhone 3G at least 3 times. So that’s why Apple stuff looks so much nicer than what a startup can come up with – that and they have brilliant designers.

The software design is not easy, either:

Why software design is so tricky

The code has to be extremely optimal, binaries have to be stripped, so the UI is responsive, stable, and your gadget succeeds.

The last takeaway on that first slide I showed was “Ship or Die”. Most folks know about this concept, but this slide made it pretty clear:

Ship or Die slide

As bunnie explains it, most gadget sales (with some exceptions) happen between Black Friday [the day after US Thanksgiving] and Christmas [the Dec 25th one]. If you are aiming to release in mid-November, and your deadline slips a few weeks, you are now missing your huge window of sales, and you will have to wait until next year to really sell your product.

There was much more content than I am able to put here, and I am glad I got the chance to see this keynote!

Liveblog: Think, Create and Critique Design

At Linux Conf AU, “Think, Create and Critique Design” by Andy Fitzsimon…

HTML slides
design checklist

Elements and principles of design.

Design is like cooking
Ingredients create flavors that influence a meal
in that way:
Elements create principles influencing a composition.

Some definitions….
Elements are:

  • Line: A continuous path between 2 points. Can also be a process, or a story plot.

  • Shape: When a line joins to cover an area, it evolves into a shape. “Bottleneck” and “pyramid scheme” are ways we use geometry as a metaphor.

  • Space: area between and inside things. Positive space/negative space.

  • Size: physical scale, bigness or smallness.

  • Color: perceived mixture. Color can be additive/subtractive or a mood. Or a metaphor, colorful personality.

  • Value: Static measure. lightness, darkness, volume.

  • Texture: structure and feel, rough/smooth, soft, etc.

Principles are the methods applied. They influence composition, but they’re not composition. They can be made with elements and also other things.

  • Proportion – divided measure of a relative whole

  • Pattern – using the same element(s) multiple times. Can be a template.

  • Graduation – Incremental changes to one element over another

  • Balance/Harmony/Unity – one or more elements creating a cohesion.

  • Contrast

  • Emphasis – a significant use of one or more elements in a single place to distinguish.

  • Form – the ‘whole’ that a sum of parts becomes – Gestalt – German for ‘form’ but in a mind-blowing way.

    If you’re creating something, you look at the elements and see if they form principles. (e.g. cooking, ingredients)

    If you’re appraising, you start with the whole and try to figure out what the elements are. (e.g. “this is great curry, let’s see if I can taste what’s in it).

    Can apply these checklists (elements + principles defined above) to anything – songs, poems, CSS, a movie, whatever.

    Visual Design and Typography tools:
    baseline grid – so easy you can check it with a ruler. A baseline grid always follows a vertical rhythm.

    Varied scale – Robert Bringhurst (god of typography) – 1 unit, 1 metric, scale up by a proportion. How you can create and measure things too.

    Symbolics are a great tool – they follow typographic tools – graphical glyphs treated as type.

    Art nouveau is ornate, decorated, and hard to create. But if you try to create ornate styles, “there’s plenty of places to hide” – you can mess up some details, people won’t necessarily notice. It’s a good aesthetic but hard to communicate well because it’s so busy.

    Style tiles and brand guides – if you have a set of rules, it’s easier to follow. It also creates consistency, and it lends itself to a balanced piece of work.

    Interactive Design tools:
    Fantastic field, UI is hot right now. Be wary of abstracted tools.

    Patterns are intuitive, isolated and repeatable. Patterns don’t dictate a complete success, they need to be interpreted in context.

    Wireframe – the problem with wireframes is that anyone can do one and if it’s not done well, when people execute it, they follow the wireframe. If you start with a bad template that doesn’t take things into consideration, you’ll end up with a bad implementation. Who makes the wireframe has to know what they’re doing.

    Workflow – “a procedure so hard to remember, you write it down”. Really a series of steps in order to produce a result.

    Persona – “a compromise for never meeting real stakeholders – written by gamblers and liars” – So often a persona doc is just punting. Does the person comes from a set of data (the average person has one breast and one testicle) or are they a real person?

    So be wary of abstracted tools but also be wary of abstracted results!

    Analytics – “metrics that justify slavery” – you check what metrics you check, and those tell you what to do. Pick them carefully!

    Instrumentation – “you do it to yourself” – You implement analytics yourself. You’re creating your own enslavement rules.

    Surveys – “the bored, attention-starved periphery of your audience” – don’t forget that it’s a self-selecting audience.

    Reviews – http://xkcd.com/937/ – you have to read the text to figure out why the good is good and the bad is bad

    User Testing – “more like zombie testing – Why won’t they smile?”

    Hyper-realism looks like something real
    skeu reminds you of something real, doesn’t have to be high fidelity (e.g. clock/watch to evoke time)
    Experience design:
    – deliberate design – a dog with tiger stripes – bad tiger, cute dog. Have deliberate differences, be something different.
    – think, make, become. Empathy is a currency now. Take ownership – win empathy, forgiveness and support.

    Now he puts up Maslow’s heirarchy of needs – Then there’s Aaron Walter, who has designing for emotion and design personas

    love, meaning, pleasure, convenience, predictabiilty, purpose – these are the goals in design. If you hit half of these this is great.

    Easy to observe (easy/logical/predictable) vs. hard to tell (lovable/loyal/trusted)

    Now let’s talk about process – the process creates a product, but the design itself is a process. Design thinking is huge.

    Design for Hackers – Andy says “it is great if you can stomach the Apple stuff and the chapter on Web 2.0.”

    Pragmatic Thinking and Learning: Refactor your Wetware is also great.

Liveblog: Secrets and Success in the Style of GLEE

Today and tomorrow I am at CodeConnexx – An Open Source Technology and Life Conference. There are some great talks…the first talk this morning is Secrets and Success in the Style of GLEE – a bunch of songs and how they relate to being successful. By Jennifer Marsman of Microsoft.

Taylor Swift, if you have an idea, do not be shy about it. In an interview, “don’t stop talking” – meaning show them your passion – but don’t force it, of course. Ask lots of questions, do not make assumptions. And if you get stuck in a problem, you can reason your way through it by talking out log.

Bonnie Raitt – “Let’s Give Them Something To Talk About”. Communicate! Let your manager know what’s going on and what you are doing. “Give them stories to tell about you” – and good ones too! Trip reports if you go on a trip, summary status e-mails, one-on-one meetings, etc.

Aretha Franklin – “Respect”. At the end of the day, diversity of opinion, education levels, backgrounds, is key to having successful business ideas. You can learn something from everyone. You can go around at a party, meet people and figure out what they are better than you at.

Frank Sinatra – “Luck Be a Lady”. At some other conference, Jennifer saw a formula for success: Success = hard work + intelligence + luck. She did not like that, because luck is a bunch of randomness, and if we work hard and are smart, we should be successful, right? But it’s completely true that luck is part of the equation. For example, in an interview. You can control working hard and you can control learning, and you will be well-positioned for when opportunity knocks.

Bette Middler – “Wind Beneath My Wings”. Role models – people that you worship from afar, perhaps stalk on Twitter, but probably won’t have a relationship with. Mentors are folks that are actively helping you grow, which you have a relationship with. You can choose a mentor to help you work on a skill or set of skills, and you can choose different people based on what they are good at. Someone who is good at MySQL might not be good at blogging or work/life balance. Jennifer challenges all of us to be role models to other people by speaking and blogging, because those folks are seen as industry experts, so you will become a role model.

Brittany Spears – “Oops I Did It Again”. The importance of making mistakes – making mistakes is good. Take big risks, because when a mistake does happen, you can learn from them. When a panel of successful tech women were asked what they would do differently, they said they would have taking more big risks.

Bill Withers – “Lean on Me”. Delegate if you need to. Ask people for help. Out of time, health and money, you can have any 2 of the 3. Young folks usually have time and health but not money. In your 30′s, you might have health and money but not time. And when you get older, you have time and money, but not health. Optimize for what you do not have. If you do not have time, then make it so you have more time – e.g. buying pre-made salad or getting a cleaning lady is a money/time tradeoff.

Journey – “Don’t Stop Believing”. Believe in yourself. Imposter Syndrome at Wikipedia. If you do not know, say you do not know something.

Conference Tips

As many folks know, !