I can’t really talk about what I’m doing next as we’re still in a closed alpha. Surprisingly the image above is more of a clue than it seems. I’ll be working as a mostly front end engineer with a very good friend at another tiny startup and this time my goal is to learn. I’m going to be working with some really smart people and I want to soak it all up like a sponge.
Also, I would like to actually post more here. It’s become a bit of a wasteland and I need to figure out how to remedy that. I think my biggest problem is I feel like I need to be super tech professional here and that’s not my life. Well not all of it at least. I also write and knit and play video games and take too many photos of my cats. I tried focusing on that part of me in another place Everything Will Be Amazing but I couldn’t focus on that either. So maybe it’s time to unify. I’ll keep you posted.
This post was originally written for my work engineering blog. Check us out and see some interesting articles from my coworkers at goats.scripted.com.
According to the 2012 U.S. Census, almost 60 million Americans (nearly 20 percent of the U.S. population) have some form of disability. While not all of these disabilities may affect the way people interact with your website, a large population of your potential users probably can’t use your website the way you expect them to. For any company, but especially ones like Scripted that prides themselves on words, this is often an overlooked trap.
Accessibility is not just about making it easier for people with disabilities to interact with your site. Instead, making information easier to consume and understand should be your primary goal. These tweaks can be simple, such as using the appropriate H1 tag versus a stylized div for your main header and having links that are descriptive on their own rather than just saying ‘click me’ or ‘here’. Keeping accessibility in mind also allows you to build a better organized, more SEO-optimized, and easier-to-navigate app for all of your users.
In Scripted’s case, the home page had some warnings about hidden links and was missing some alt tags for images.
Scripted’s order page had some severe shortcomings regarding labeling inputs. Without input labels, many screen readers can only guess what your forms are trying to collect. And as a secret bonus, input labels make the clickable surface of your input bigger. A tiny radio button without a label means the user can only click on the radio dot to choose an option. With labels added, they can click anywhere on the radio or surrounding label to make a choice.
After adding the labels and making some of the other suggested tweaks to both the homepage and the order flow, the report is looking much better, but one file change won’t solve all your problems. Someone on your team might make a change next week and forget to include an alt on an important image without thinking about the impact. You need a plan! Whether it’s running the URL checker on a regular basis or asking the team to keep accessibility in mind during code reviews (and training them on what to look for), figure out a path that will help you maintain the accessibility of your site. For both quick fixes and good basics on accessibility, a great resource to start your team with is the A11y project.
This post was originally written for my work engineering blog. Check us out and see some interesting articles from my coworkers at goats.scripted.com.
The greatest CSS gif of all time
What is flexbox?
Most websites design around grid systems. A long, long time ago, in Internet years, this was done using frames and actual table grids. Then we all moved on to floats and percentage widths. The Holy Grail layout was often a mess of different solutions. Flexbox is a CSS layout mode that gives you complete control over the components you put in your grid, allowing you to keep sizing organized both inside and outside the box, as well as providing a unified layout styling no matter what screen size you view the components on.
How we use flexbox at Scripted
Flexbox is used at Scripted in a number of locations. Most of our marketplace pages are large grids of cards, and each card is itself a grid. In order to accommodate lots of information about each blog idea, we need to be able to keep sizing consistent with inconsistent data. Our CSS is compiled so we are able to make mixins for flexbox that do the heavy lifting (and solve a lot of cross-browser compatibility issues) for us on the fly.
Flexbox in action
On the page above, for example, each card uses our standard flex layout. We added the option of a column direction, meaning information should flow down the page, and each component in an individual card should stack. For the overall grid layout of an unknown number of cards, we use the standard with an additional wrap option so cards flow to new lines when we run out of space (versus trying to crowd them onto a single line).
Why not flexbox?
Unfortunately, like with most newer web standards, support and implementation haven’t had time to unify. For example, Internet Explorer — because it’s always the example with new designs — implemented an outdated flexbox interpretation in older versions. Even with current flexbox standards, different browsers render flexbox styles differently.
Other concerns, especially for sites trying to use flexbox for their overall layout, is the speed of rendering. While it’s a few years old, Ben Frain’s look at the speed of table CSS versus flexbox is a good start. Rerunning the tests now shows some better numbers for flexbox layouts.
We still use table layouts for assets that we want to just work; some of our feature charts are examples of this.
So most of my nerdy friends have already lost their shit over emacs. I’ve avoided it with my tiny little Sublime bubble of comfort, but then more of them switched and suddenly I felt left out of the big kid pool. SO, I’m going to remedy this. So far, I’m just using the EXTREMELY AMAZING ohai-emacs initial setup and customizing from there. But seriously, ohai has a nyan cat (nyan-mode for those who know) to show me how far along I am in a file. I’m. In. Love.
If you’ve never used emacs before I’d recommend starting with a tutorial, but if you want it to look pretty while you start learning get yourself over to the Ohai-emacs github page.
Light on content again today. I’m having a bit of writers block I think. The life is boring but nice, so I don’t have as many existential crises to share with you. As a bit of a carry on to my dialogue last week, I’ve been thinking about the right tool for the job.
I have been wanting to track some stuff I’m working on and I wanted to be able to record a daily log. I spent a week looking at different frameworks and decided what database to use. Then I woke up Saturday morning and absolutely frustrated with myself, I started logging things in a spreadsheet. And my problems were solved. I can keep track of things, use pivot tables if I need more data and write quick charts. Hell eventually I can export it and parse it and put it in a database if I really need to. But do I really need to?
Analogous to this, is that shiny fancy bit of code that you’re super smug about because you figured it out and it’s bitchin’. It may be bitchin’ but it will in fact probably be a bitch for the next person to look the codebase to maintain. By no means should you take the easy way out, but if you are trying to use a slick one-liner in production code that takes a half hour PowerPoint to explain, save it for a blog post. Be kind to your fellow engineers. We’re generally quiet, but we will mentally curse you to the fate of having a problem that’s never been answered on Stack Overflow.
Little late today, I was busy working/running around/watching paint dry, so I’ll keep this brief. I’ve mentioned before that git can be like a game save, it protects your butt if things go wrong and you need to get back to a certain safer place. But I also like to use git commits as a well crafted story, or at least that’s what I want to present to the outside world. Having a lot of why doesn't this work or it does the things or rainbows and ponies (a real pr of mine at a job at one point) doesn’t really mean anything to anyone but me. And unfortunately it probably doesn’t mean much to me if I go back and look at it even a day later. So what’s a girl to do? Tell her own story of course.
First let me say, “rewriting history” in git is a bit of a controversial subject for some people. But at multiple jobs and in my preference I don’t have a problem with it as long as you’re not rewriting master or other people’s history. So what does that leave us? The ability to craft a really well documented pull request. I can explain you through the choices of my work. I can easily split out frontend and backend changes if different people need to look at different parts. I can make changes easier to find if they all happen on one file in one commit.
I’ve gotten lazier about this at my current job, but my goal is to get back in the habit. It’s good hygiene and leaves my mental health intact.
Confession: I haven’t touched code outside of work in weeks. I’ve spent most of my free time recharging. Snuggling cats, hanging out with friends, being a slug on the couch and binge watching tv. All of these things lately have been much more exciting to me than poking at code that isn’t work related. I’m not the only one who feels this way. But I also know that I’m in the minority of people who don’t have a lot of extenuating circumstances surrounding their free time. I don’t have a family to take care of (unless you count my cats and my friends – which I do).
It seems to be that we as engineers are expected to code all the time. I myself used to want to “live and breathe code”, but that takes an awful lot of brain power and I’m not sure the type of person it makes me. You see, I am firmly in agreement that coding feels like a foreign language (side note: I don’t agree with the arguments that coding should count as a foreign language requirement, they definitely fill different niches in that regard). And spending your whole working life translating a foreign language is exhausting. Don’t get me wrong sometimes it’s AWESOME that I can think of something that would be useful for me to have and then I can go build it, but after I’ve spent at least 8 hours in at least one foreign language I just want to go home and let my brain thing in English for a while.
What’s especially hard (for me at least) is that I feel like I’m slacking if I just use technologies and frameworks I already know about in personal projects. If I’m going to be working on a personal project I should be learning something, right? So I get super sidetracked and slowed down learning all sorts of new things and then by the time I get back to the task at hand I’m exhausted and want no part of it.
I think probably the best way for me to handle this is to try to get back into it with just fun projects, projects that I don’t have to research, the just have to get built. But I also have to allow myself the possibility that personal projects might just not be for me. I can get my coding kicks outside of work by mentoring, attending conferences and even just reading about code.
Time to add another weekly to the mix. At my office I generally work from home on Fridays because it was a tradition before me and who am I to break a tradition? At my last job it was Thursdays, but it’s awesome that most eng jobs understand and allow for the space to get shit done with out distractions.
As part of my Fridays from now on, I’d like to carve a bit out of my day and just go down a rabbit hole. Most of them will be tech related (most of which will be frontend) but I’m not going to put a label on this segment other than the fact that it will probably not be quite as detailed (all though I say that now and then this one turned out to be a monster). Some weeks it might even be me just throwing up some links and commenting.
So lets start easy this week by opening the Pandora’s box that is Node.js. In my scant spare time I’m working on a side project that is essentially just an API with some munging of data. HOWEVER, I’ve grown bored with my standard Node/Express workflow and wonder if there’s anything newer or more exciting to play with. Lets find out together shall we?
So I’ve heard of some other alternatives, but haven’t really dove into Node stacks in a while because I’ve been a Python girl up until recently. So, let’s be lame and google alternatives to express.js (what, you were expecting high-tech sleuthing?). Immediately the apparent new darling Koa is all up in my grill. So Koa is all ES6 ES2015 – whatever I’m sticking with ES6, it’s not like we’re all going to magically start using ES2015 in 2015 anyway. The initial footprint is small, but you can’t do much with it without additional middleware.
Koa has always been something that I’ve kinda prodded at with a stick and never done much with. Each time I read about it I find it more and more interesting, but it seems like it would be overly complex for my small personal stuff. Besides being ES6 opinionated, you’re basically free to add whatever you want. You can use established middleware or roll your own without too much effort. For my small side project though, I just don’t have the energy to research yet another step of deciding which middleware to use or creating it all from scratch.
And then there’s the other standard in a trifecta of frameworks that everyone talks about called Hapi. I have never gone beyond looking at the Hapi documentation and going “nope!” but that’s just a personal opinion because I just don’t like the look of using objects everywhere for everything. It gives me Backbone flashbacks and I just can’t handle it. So I don’t have much to say about Hapi, but will take this to an aside that I enjoy how much like art coding is. I can have feelings about the tools I use. It may be amazing for someone else, but if I’m just not feeling it, I generally have other options.
So lets narrow it down, what I really want is an API layer. I don’t care as much about rendering pages. So lets keep going. A couple of new contenders – Restify and Loopback. Both seem decent, but I’m a sucker for not having to do as much work and we use Ruby at my new job so I love it when I don’t have to define all of my routes by hand. Loopback is also a part of something called StrongLoop, which I’ll admit I haven’t heard of before but seems to have some Node enterprise and monitoring apps. Oh… and it’s built atop Express. We have come full circle my old friend.
Alright, lets walk through the tutorial. I have mixed feelings about generators since they usually throw waaaaaay more at me than I will ever need, but FOR SCIENCE!
I told you it was for science. Alright, so before I create any models, I decided to poke around at the code generated. And I am immediately vaguely displeased. It includes a .editorconfig file, which while in sync with the configuration settings I generally use seems annoying to impose on someone. Also it generated a looooot of files. They seem orderly though, so lets press on.
And now I’m lost. This is not in the tutorial. -1 for out of date tutorial! Time to break out the docs!
In general, use PersistedModel as the base model when you want to store your data in a database using a connector such as MySQL or MongoDB. Use Model as the base for models that don’t have CRUD semantics, for example, using connectors such as SOAP and REST.
+5 for helpful docs. The other models are actually pretty cool too and I could see myself using them quite a bit in larger applications, but for now lets stick with PersistedModel.
And there you have it! I now have a person model! It’s some pretty json that’s easy to read and understand. So in summary: Loopback/StrongLoop reminds me immensely of Rails, which I’m OK with. I think I will continue to play with it, but so far it gets a thumbs up from me.
As an aside: For those wondering, I’m using the Peppermint theme with a basic bash terminal, though I do recommend zsh/ohmyzsh and use that at work. I also use Sublime Text with the theme & color scheme itg.flat – Dark.
Last week I helped out at an #ILookLikeAnEngineer event. There have been lots of write ups about the event, but I think my favorite, and not coincidentally the most critical I’ve read, was from Re/code. The last paragraph in particular sums up my mixed feelings about the event.
#ILookLikeAnEngineer was a nice gathering for people with first-hand knowledge of the problem. But having any lasting impact before the next Internet meme sucks all the air out of the room will require a bigger meeting place and a different guest list.
I understand the need to have safe spaces for underrepresented people, because that shit can be draining out in the real world. But if we only ever stand in an echo chamber then we’re just making ourselves feel good and sticking our heads in the sand (to awkwardly mix metaphors).
As a general rule, I have stayed away from women in tech meet-ups that only serve as a place to vent. I would rather spend my free time exhausting myself helping others to learn. To help women get good and get proud of their own accomplishments. I’d rather spend my time mentoring at an all women hackathon or one on one mentorship or helping out our interns.
I say all of this about my mentoring because I worry about coming off as “I got mine” or making it sound like we just all need to “lean in”. I will admit that a lot of my engineering career has involved the lean in philosophy for myself. I worked my ass off at a boot camp that only had 6 women. Interviewed at a bunch of places that were all dudes and ended up by sheer luck at a fairly diverse first engineering job.
Before all of that though, I dropped out of the computer science program in college because I was the last woman standing. I still regret that decision, but it has made me tougher. I’m not willing to compromise now. If I’m the only woman in the room, I’m still going to do my best work. I’m still going to work my ass off as an engineer and continue to help women into the space because I believe in strength in numbers.
I’m not sure where this puts me in the spectrum of engineering feminism, which I think is my main problem. I find dudes easier to talk to in general. My favorite engineer/mentor/friend is a guy. The only managers I’ve ever had an issue with about my role as a woman in tech were other women. So I continue to follow the path I’ve set out for myself. Blogging about culture, mentoring women, learning and being the best engineer I can. Every once in a while I poke my head up to see where other women in tech fall on their paths, but none of their paths look like mine.
So this feels like a lead up to some great revelation, but sorry to disappoint you. I don’t have one. I plan on continuing to “do me”. Helping out where I can, being selfish when I need to be, and continuing to grow as an engineer. Also I really enjoy off-color jokes – does that make me a bad feminist?
We had a super awesome intern working with us over the summer (I often referred to her as “my” intern, which wasn’t 100% true, but as the one on the team who had done a lot of mentoring before, I felt very mamma bear about the situation). She did some cool things and had done some cool work on her own before working with us but when she needed help and was frustrated out of her mind with a problem (like many of us still often are) it usually ended up being easy enough for a fresh set of eyes to spot the problem.
These are the times when having a mentor or even just a partner in crime who’s willing to give a quick code review make all the difference. Unfortunately not all of us get the luxury of a second set of eyes, so we fumble along adding and deleting things until we just throw it all away and start over (been there) or change so many things that one of them magically works but you don’t actually learn anything because what the hell was the problem in the first place (also been there). So for my fresh coder friends, I thought I’d throw together a quick cheat sheet of the things I see most often in my and my mentees code. I bet with any time spent coding you can probably guess a few.
This one hits where it hurts, because it is a stupid mistake. A variable named “container” is not the same variable as “contanier” (and is also an awful, very vague variable name, but that’s a different lesson). This will drive you nuts, I promise – it’s currently driving my spellchecker nuts as I type. Everyone does this. Everyone. Promise. Even that awful person you just had a horrible first interview with and now will never have the job of your dreams, yep, he’s misspelled “first” I bet. The Quick Fix: If you’re using an IDE (think Sublime Text, or Atom or whatever the kids are using these days). It’s pretty easy to spot. When you go to auto complete a variable starting with “cont” you will see two options and one of them will be not what you want. Go head and do a search for that errant misspelling and see where else it’s been used in the codebase and change it (unless some jerk really did have a variable named “contanier” in some obscure file, then change it and mock him for the next year).
This can technically mean a lot of things, but I’m talking about the “if not this or that do this” variety. Unsurprisingly, when you spell it out “If not A and not B” sounds much different from “If not A or not B”, but when quickly writing code it’s easy to forget. The Quick Fix: Say it out loud! Write out your logic flow using words! Do something that’s easier for your brain to see flaws in than the foreign language that is your code.
Blech, straightforward and an oldie but a goodie. Syntax errors are common. Everything from a typo to a misunderstanding of how a function works can lead to them. Thankfully most languages have been nice enough to also make them the easiest to solve. The Quick Fix: Learn how to read those stupid error messages. Each language is usually a little different, but most of them follow a pattern. They generally have a complicated error message and a line number. It’s like they’re giving you the answer for free! Check out that line number, does something look funny? Fix and try again. Does it all look, a-ok? Start googling that esoteric error message. I promise you’re not the first person to accidentally divide by 0.
Incorrectly nested divs
This one is a bit frontend specific but you are a lucky person if you’ve never accidentally had this madness in your codebase, especially frustrating with things like Angular scope. Missing that end div tag or adding one too many in the wrong place can be a nightmare. The Quick Fix: Always always use good HTML hygiene, indent for every new block.
This is a bit of a catch-all and a desperate plea to learn some git basics. Sometimes I’ll go wandering down a rabbit hole and not come up for air until I’ve changed at least four files. This is Not. Good. Do as I say and not as I do kids. This will lead to massive frustration when one part is making the entire thing fail or not compile. But shoot, you just made changes to four major files. So now it will take you at least 4x longer than it took to write to go back and debug. Make incremental changes, save progress with git. It’s like a video game – no one wants to do the boss battle again!
We can all make these same mistakes. In fact, I’m positive we all do, but for those of us who’ve been doing this a few years we can just shrug and groan and move on with our day. And this is probably that single point where I see newer engineers go off the rails. They feel dumb and like they’ll never be as smart as their coworkers or mentors. I know this because I remember it and I’ve seen it in people I mentor. My favorite way of taking the edge off, especially when they come up immediately on the defensive with an “I know this is probably stupid, but..” is to help them but then share a time when I’d done the exact same thing. We all had to learn this shit, some of us have just been learning it for longer (and have the dyed grey hairs to show for it).