Monday, April 27, 2015

CSS3 Animations Are Super Rad, she said animatedly.

Wait. Animation? I though you said AniMOtion...

I don't know if you saw this on the Twitters, but I made a MC Hammer dance party robot*, which you should absolutely check out. If you hate MC Hammer (in which case, we are NOT friends) and/or dance parties and/or robots (in which case, we are not friends, and they will come for you first). Oh, wait. I was in the middle of a sentence, but then I got sidetracked by your horrible friendship. What I was going to say was that the Hammer Bot incorporates a number of different animations - a back and forth movement of the robot, up and down movements of its legs, and flashing eye lights.

So check this - my animations are all motion or color based, but CSS animations are wayyyyy more versatile than that. An animation is essentially defining a change in an element between two styles, so you can animate virtually anything you can style** The motion animations define a change in position, the robots eye animation defines a change in background-color. And, since you can run multiple animations on the same element at the same time, you have an incredible breadth of options. THIS IS SO AWESOME! Check out this fantastic site that shows a ton of effects you can create.

Here's how they work:

There are two distinct steps in creating an animation in CSS. The first is to define the style change itself, the second is to bind it to an element.

Step 1: Defining The Style Change

When defining the style change, you are just defining the beginning and ending state of an element - not timing, not duration, not even which element it applies to, just the change. So let's say you have an image of Odin, the white one-eyed Manx cat who looks like a bunny (I just met this cat in real life, btw) and you want to rotate it 360° forever so that it looks like a merry-go-round with a cat face painted on it. No one would blame you. Defining the style change for this case would be like saying, "I want a thing to rotate 360°."

To do this, you write a keyframe rule in your stylesheet, not nested inside of anything. It would look like this:

@keyframes spin {
  100% { 
    -webkit-transform: rotate(360deg);
  }
}
@-moz-keyframes spin {100% {-webkit-transform: rotate(360deg);}}
@-webkit-keyframes spin {100% {-moz-transform: rotate(360deg);}}


Let's break that down.

1) Notice how the first keyframe takes up a bunch of room and the next two don't? You can write any of those keyframes either way. Condensing does save space, but I it can also be easier to see what's going on if you use the expanded form.
2) That first @keyframes is the basic keyframe rule, and the second two are there so that the animation plays nice with different browsers. 
3) The spin is just the title you designate for this keyframe. It could just as easily be meowmeow or Odin, but spin is nicely descriptive because all this keyframe is doing is telling something to rotate. Nothing implicitly feline about it. 
4) The 100% will apply to a time duration you will set for the animation when you bind it to an element. This is saying that you want it to do this animation for 100% of the time set aside for animation. If you put 50% there instead, Odin would rotate clockwise for half of each spin and would then rotate counterclockwise to reset itself the other 50%. Try putting 25% in there sometime. It's super wacky.
5) And transform: rotate(360deg); is the css style you're fiddling with. 

Step 2: Binding to an element

This is the part where you designate how that motion you just defined will be used. Assuming you gave your image a class of "odin", here's what step 2 would look like:

.odin {
  animation: spin 4s linear infinite;
  -webkit-animation: spin 4s linear infinite;
  -moz-animation: spin 4s linear infinite;
}

Now let's break this down. *Animation* is the property, *spin* designates which keyframe rule to use. 4s says to complete the 360° spin in 4 seconds - decrease that number to make it go faster if you want. Linear means same speed from beginning to end. Infinite means you want Odin to spin forever and ever. This is the shorthand version - you can call these individually if you want, and you have other options too, like setting a delay or direction. (Here's a great breakdown of your options.)

And Bob's your uncle.

This is just one example of what you can do with CSS3 animations. Not only can you animate just about any property in a number of ways, but you can also add multiple different animations to the same element. (Like if you wanted Odin to get bigger and smaller or bounce around the screen while he's spinning, you could totally do that.)

And I return to my thesis: CSS3 Animations Are Super Rad. The end.



*The Hammer Bot started from a really fun Dash tutorial, which I then hijacked for my own sinister purposes
Sinister Porpoise
**I just tried animating a font-family change and couldn't get it to work, but that's the only limitation I've found so far. Also, I cannot imagine a time when I would actually want my font to go from Times New Roman to Comic Sans and back - although...that could be a cool practical joke.

Tuesday, March 31, 2015

Tale of Two Hackathons: In Which I Juxtapose


This is a longer post, which means it’s got even more awesome in it than usual! But, in case you’re short on time, I’ll outline it for you first so you can skip to the best parts if you want. It goes like this:

  1. Overview of hackathons
  2. Treatise on my experience at the Lesbians Who Tech hackathon
  3. Treatise on my experience at Hack The Commute
  4. Lessons learned

Onward!

Never having done anything like a dance-a-thon, like in that one episode of Gilmore Girls when Rory and Dean break up (sorry not sorry for that spoiler), it is unsurprising that I would be attracted to the mythical allure of the Hackathon phenomenon. In the last 30 days, I have made the myth reality (for myself – certainly it is still mythical to other non-me people).

In the last 30 days, friends, I have participated in two hackathons. I have followed their strange customs and tasted their lavish foodstuffs, and now I have returned to regale you with tales of adventure and woe.

A primer on hackathons:

Hackathons seem to vary greatly in a number ways, but there are some commonalities. A hackathon is when many people come together to create entire projects over the course of (usually) about two days. Participants have a wide range of experience (from neophyte to expert) and skills (program management, graphic design, front end, back end, UX, mobile devs, data scientists, and more). Often there is a theme of some kind – it could be themed around a particular issue, such as transit, homelessness, health, entrepreneurship and startups; around a particular technology, such as the Internet of Things; or around a particular population to create an intentionally safe space for folks from marginalized communities, for limited example, LGBTQ folks, People of Color, youth, and/or folks with intersectional identities. (By “intersectional identities”, I mean that many people are not just LGBTQ or people of color or youth or working class or people with disabilities, for instance. Many people belong to many of these populations at the same time – that is to say populations overlap and personal identities overlap, and this is an important thing to recognize and hold space for.)

The overall structure of a hackathon is to start off with pitches, where a bunch of people have a small amount of time to explain their ideas, after which participants form into teams. Not all projects move forward from the pitch phase, depending on whether they garner enough interest. Teams then retire to their corners to work until some abnormally late hour, only to return at 8 or 9 the next morning and continue working through the next day. The point is to create a prototype of the app in time to present a demo at the end of day two. In some cases, judging and prize awarding happens next, as some hackathons are competitivee.

Be advised: also true of all hackathons is that you will be awash in a glorious sea of snacks and catered meals! 

I had very different experiences in my two hackathons, so let me run through a couple of case studies in how hackathons can differ, and how this can affect the experience.


Hackathon #1: Lesbians Who Tech

My first hackathon was part of the Lesbians Who Tech Summit (or LezzieCon, as I like to call it), and it was hosted at the Mozilla offices in SF, which a) are right on the water, and b) house a truly magnificent fantasy snack island paradise. Seriously, I approximate 60% of my conversations were about the amazingness of the snack area.

There was no competitive aspect to this hackathon, and it had a broad theme of social justice. I was really excited for this hackathon as a way to try it out in a safe context. As a butch queer fat lady, you never quite know what you’re gonna get at broader tech events. And, as a generally nervous person, taking out a key piece of potential stress was really helpful. I might not know what I was in for, but I sure know lesbos!

Team Selection Process:

After some facilitated icebreakers and the traditional exchange of personal pronoun preferences, folks gave pitches on somewhere around 15-20 projects, and a piece of paper for each project was taped to the walls, distributed throughout the room. We were then bestowed with two votes – circulated around the room, and marked our two votes on the projects we wanted to see happen. After eliminating a number of projects for low interest, we then were to choose the remaining project we wanted to work on, by standing next to their sign. At this point, a few more projects were eliminated, again for lack of interest. Within our groups, we talked about our respective skillsets, and were then given the opportunity to address the entire group and ask for help with any holes we anticipated (e.g. – a group full of product managers might need some coder help)

Team Selection – How it went down:

I chose my team based almost entirely on the project I felt most passionate about. The app was to track immigration paperwork for folks who have navigate the labyrinthine process applying for visas. It was a relatively small group, with five people total, and when we discussed our skills briefly, it seemed like we had things pretty well covered. We had a database person, a person with Rails experience, me with a little bit of Rails and some front end, a person with some graphic design background, and the person with domain knowledge about the visa process. It turns out we would have benefitted from getting into a bit more detail about this.

Work Process:

In truth, the first day was pretty frustrating. We talked in circles a lot, trying to bridge the gap between technical and non-technical lexicons, not entirely successfully. I felt like I didn’t know either well enough to bridge them, and I couldn’t quite nail down what anyone was trying to say, much less how to bridge those gaps. As a result, I often felt like I had no idea what we were trying to do. We ended up using a prefab frontend template from Wix, since the woman with design background was comfortable working with that, but it ended up to not have the ability to connect to a database. Our main Rails person hadn’t worked in Rails in a while, it had been a while for me as well and I hadn’t know that much to begin with, and our database person wasn’t familiar with web development at all. What’s more, we could barely move around in our tiny tiny room – our tiny hot room. What I’m saying is, the first day was a hot mess.

Day two was better. We got out of the awful small hot room, and worked in a big main room with couches and a/c. We knew we were going for some small goals: 1) get the skeleton of the project GitHub so other folks can keep contributing moving forward, and 2) create an unembarrassing demo presentation. With the nicer work space and the narrowed focus, we had much more of a calm and productive working day. And, at the end of the day, we did accomplish those two goals. Our presentation worked out, folks were supportive, and I was mightily relieved and grateful for the Rails person, who had really taken the brunt of the work. After that, it was great to support other people in their presentations. Even better, I talked with a lot of really cool people after the demos. Many cards were exchanged, many efforts applauded. More than anything else, this made the experience worth it.

Upon reflection, I formed a few hypotheses about how to approach the next hackathon.
My first hypothesis was that a larger group would reduce the pressure on any one member (not to mention myself). My second hypothesis was I should place higher importance on understanding the skills of other in a potential team, and choose based less on the project itself, and more on whether I would be able to get help from teammates.

Hackathon #2: Hack The Commute

The second hackathon was Hack The Commute (HTC), a hackathon put on by the City of Seattle and partner businesses. Seattle is growing fast, which is aggravating preexisting traffic and transit problems, so the goal of HTC was to put the talents of a thriving tech city into the problem. This hackathon was judged, with winners moving on to compete at an event in late April, and was hosted at the Moz offices in downtown Seattle. HTC had a ton of resource people on hand to help, so every group knew what data was available to them, and had help crafting their final presentations. There was quite a bit of effort and attention put into creating smooth and safe infrastructure for the event, and it showed. It was impressively well run.


Team Selection Process:

HTC – We were told a number of different subjects for which experts were on hand to talk about (e.g. parking, accessibility), and these folks camped out at different tables in the giant main room. The rest of us then circulated throughout the room to have conversations with these folks and other interested participants about project ideas and available data. After about 45 minutes, people then did pitches on project ideas that came out of those conversations (though some folks came in with set project ideas, as well). After this, we again broke out to form teams by talking to folks whose ideas we liked. This process happened on Friday night, so that we could leave after forming teams and be ready to start working from the get go the next morning.

Team Selection – How it went down:

HTC – I was determined to test my hypotheses on team selection, so I knew that I wanted to get on a team with enough people so that nobody has to take the brunt of the work, with enough expertise that I could get help, and with enough of a good vibe that I would have fun. My main passion was for accessibility, but I hadn’t gotten a good sense of the skill level of the other folks in that group, and it seemed like available data might be problematic, and the group was small.

Instead, I and a couple of friends joined a team working on an app that would crowd source and make a game of identifying open parking spaces downtown. We had heard a statistic that roughly 30% of the traffic downtown at any given time was people circling, looking for a parking space – this app was to make the process easier and hopefully cut that figure down. What drew me to this team was the charisma and inclusiveness of the guy who pitched the idea, and my group size and skill criteria were met. Downtown parking may not be a great passion, or my life’s work, but it is a problem and this project could be an interesting and engaging solution.


Work Flow:

HTC – Overall, this went much better than my first hackathon, and I would say that my hypotheses were supported. Nevertheless, it was not without it’s own hitches. I had pre-arranged to arrive late the first day, and by the time I got there, the team was cruising. This was really cool to see…and I was intimidated trying to find where to jump in.

As a perfectionist and lifelong Really Smart Person™, one of the reasons I came to this second hackathon was to get practice sucking at things in front of people – and this is exactly what I slammed into right away. I didn’t know where to jump in, we were using a number of things I had never seen before (e.g. Koa and Jade), and I was far and away the least experienced person in the room. I was convinced that I was going to hold the group back and that the people in the group I already knew would realize I was dumb. But, instead of running away crying, I asked for help. It turned out that the group was a bunch of really nice people, very willing to help. They went over the high level view of the app with me, and helped me figure out a niche that worked with my skills. So, even though I still had lots of questions, and even though Git made me its bitch over and over, I came away from the experience feeling like I had contributed. We made a wicked cool app, and it looks darn nice if you ask me.

(The app is called MeterQuest. Check out the repo!)


Lessons learned:

  • Hackathons are worth doing, even if they don’t go exactly how you want.
  • Do what you gotta do. If you need to sleep in or leave early, fine. Do it. Need to walk around the block or cry in the stairwell for a minute, fine. Do it. If you need to have a snack and chat with people from other groups, that’s fine, too. Do it. You’re there to make things, yes, but also to have fun and to meet people in your field. You are definitely not there to be miserable. Do whatever you need to do to keep yourself moving forward and having fun. You can also just leave if you need to.
  • Team selection is stressful. It just is.
  • Consider more than just your subject interests as you select your team. Also choose based on the vibe of the team, the skill level and skill sets of others in the teams, and anything else that is important to you. For me right now, this means choosing a team based on their likelihood of being fun and the likelihood there will be folks who can help me with coding obstacles.
  • Hubris is thinking Git can no longer make you cry.
  • Prepare for a bit of a roller coaster. There will be terror, regardless but there will be adrenaline upswings, too.
  • People are really supportive about your projects and presentations. Nobody’s there to tear you down.
  • You may need to deal with microaggressions, though, so maybe think about how to prepare yourself for that – what your needs are, what you will want to do if they happen, maybe even reach out to the organizers ahead of time.
  • EAT ALL THE SNACKS!


Monday, March 16, 2015

In Which I Freak About How Cool Two-Way Data Binding Is


I’ve done a bit of a pivot in the last few weeks, focusing more on front end projects than Rails. In so doing, I’ve started working in AngularJS and you know what? I like it. I like it a lot. In fact, you might say I’m really gaining a lot of – wait for it – Angular momentum! ANGULAR MOMENTUM! Ha! Let me furnish you, gentle reader, with the salient hashtags to commemorate this moment:  #physicsjokesarehilarious #somuchlolz #micdrop


This video is the key to unlocking the physics hilarity, if angular momentum is new on you. 


Okay, back to business. There are a ton of things that are really interesting to talk about with regard to Angular (not the least of which is, “What is Angular?” My apologies. I am writing out of order. I’ll say more later about what Angular actually is/does. For now, let’s go with a gigantic oversimplification and say it’s kind of like Rails, but faster and prettier and is only kind of like Rails.)

Today I’m just gonna talk about one of the features of Angular that is, IMHO, seriously rad. What am I talking about? Two-way data binding! And so now you’re like, “That’s dumb. That just sounds like stapling a spreadsheet to some walkie-talkies.” Okay, first of all, I love stapling, spreadsheets, and walkie-talkies, so nothing about that sounds dumb to me.

More importantly, though, if you squint at that sentence while thinking of metaphors, you might see that two-way data binding maybe kind of it is that. Let's put a pin in that.



Ah. Once again, I discuss the thing without explaining the thing. What is two-way data binding, you ask? 1) It is rad. 2) It allows the model and the view to be constantly talking to each other – when a user makes a change, it goes right into the model, and when the model changes, that is reflected in the view. 

This is how you feel right now, but it totally gets awesomer.

If you think back to the old restaurant metaphor, where you’re at a restaurant, and you’re ordering up some delicious serving of data, and your controller says, “Oui. One moment please,” then brings your request to the kitchen, where they get the data out of the walk-in, and they make it look nice, and then the controller returns to your table and says, “Et voila!” Every time you send that controller to the kitchen and back, your entire page reloads. You have an entirely new plate.

Now imagine if you didn’t have to wait for that trip back and forth. Imagine you can still order (add/retrieve some data to/from the walk-in) without sending someone alllll the way to the kitchen and back. Imagine you could order, and the contents of your plate would simply change, right there in front of you.

DO YOU KNOW WHAT THIS MEANS?!?!?! Do you see it? I can’t even – I mean – do you know what it means – I mean – omg –

What it means is this:

TWO-WAY DATA BINDING IS LIKE EATING IN THE DINING HALL AT HOGWARTS! 


This is me when I realized.

You tell your plate that you want some bacon mac & cheese (would that I were at Hogwarts right now…), and the house elves just magic it onto your plate right there. You don’t need to reload the page (of your app – in the non-Hogwarts context). You’ve got house elves.

Dobby is most pleased to be serving the users, he is.








Friday, March 6, 2015

Lesbians Who Tech: On Speakers and Surprises

Previously on…“This Blog”, Lesbians Who Tech (LWT) Summit was discussed, with particular attention to networking and the overall value of being in a giant room chock-a-block with lesbos.

Tonight on…“This Blog”, the speaker lineup is discussed. Worry should not be felt, as it is only in the first two paragraphs that the passive voice used. 

Spoiler alert: The speakers were great. Diverse subject matter, and diverse speakers.

I knew virtually nothing about the speaker lineup going in. I mean, the names and titles and blurbs from the program, but that doesn’t do much to get me psyched. What happened next will blow your mind! (Apologies. I got a sudden attack of Upworthy-itis. My bad.)

The thing is that what happened next actually did kinda blow my mind.

The summit opened with a “fireside chat” (though neither fire nor FDR were in attendance), essentially a sort of roundtable discussion with Aliya Rahman (Code for Progress) and Tina Lee (Mother Coders), moderated by Danielle Moodie Mills and Aisha Moodie Mills, how badass women are solving tech’s diversity problem. I don’t remember a ton of this because brain, but I do remember that all four of these women were, in fact, badass and hilarious and brilliant. Oh! And I inexactly remember a quote, the gist of which was “it’s easier to teach syntax than it is to teach racial consciousness.” Indeed. Nice kick off, ya’ll. Hats off.

Overall, the talks surprised me. And that was – wait for it – surprising. I think my main surprise was how much focus on federal government there was. There was no explicit theme around this, and I suspect there was no particular intention by the organizers around that (or maybe there was, I don’t know), but the focus was there.

I am not at all a rah-rah government kind of person, nor am I at all a rah-rah military kind of person, so it also caught me by surprise how engaged I was with all of these talks. But, man, those were some really engaging and compelling talks.

Here’s a brief rundown:

First, Pia Carusone, former chief of staff for Congresswoman Gabby Giffords, spoke about the state of technological steps toward ending gun violence. This talk was alternately moving, as Carusone told the story of Giffords’ – and others’ – shooting, and interesting as she went through some tech hardware innovations to the firearms themselves.

Later, Vanessa Vinson spoke about how her experiences transitioning from years of military experience into a tech career. I was nervous for this talk – nervous about the potential for a jingoism that I do not feel – but my nerves weren’t merited. Instead, this was a really eye-opening talk about an experience incredibly different from my own. And really eye-opening to learn about the ways that the military has (and hasn’t) prepared her for her career, and what assumptions people and employers make about veterans. I’m very glad to have heard her story.

Hillary Hartley, Deputy Executive Director and Co-founder of 18f, spoke about how the debacle of the healthcare.gov site galvanized the federal government into action, in terms of equipping itself with user-centered means of interacting with government, and being able to provide user-friendly digital services. Out of this, 18f, an internal government consulting body, was formed to help agencies throughout the government be able to do this. I gotta say, I think that’s pretty badass.

Closing the day was the last government-y talk, another fireless fireside chat, this time with Megan Smith, CTO of, y’know, the whole entire country. In truth, I hadn’t thought much about the fact the country’s Chief Technology Officer is a lesbian – the extent of my thoughts on the subject thus far were something like, “Huh. Cool.” But hearing her, I was really moved by the significance of this (because, dude. The CTO of the US is a lesbotron. Appointed by the president). And I was really moved by how truly genuine and integrous Megan Smith seems to be. She seemed like someone I would like and respect and trust in real life, and this in turn makes me feel good that she is advocating for tech at the highest level. Jesus, listen to me. I sound like a 12 year old at a One Direction concert. “OMG, MEGAN SMITH!!!!! Will you sign my boob  president obama paper dolls book  wonder woman t-shirt  very sober and normal autograph book?!?!?!