Time for me to announce I’m starting a new job! My time at Scripted was wonderful. I learned some really good life lessons and understand myself more as an engineer and a person. I’ve discovered I’m really interested in bridging that engineer to the world communication that is so necessary for both internal employees and translating your product to your audience. I’ve shifted from being a mostly backend engineer to a mostly front end engineer (as an aside is anyone else bothered by the fact that the accepted spelling for front end has a space but backend is one word???) and I feel like the topsy-turvy nature of the JavaScript ecosystem allows me to keep experimenting but also not take myself or my fellow engineers too seriously.
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.
I’ve been continuing to spend a lot of time outside of work not even thinking about programming. I’m not sure if that’s a good or bad thing in the long run, but for my mental health and happiness, it’s been amazing. I’ve been cycling through old hobbies and trying out new things, but they’ve mostly been duds. Knitting was always big for me but since I moved to California it’s a little harder to delight in making beautiful woolen things to keep me warm when I can count on one hand the number of times I’ve even seen rain this year.
So I went searching, reaching back into the depths of things I enjoyed. What kept coming up was back in college when I spent four years studying Chinese and how much I regretted losing most of my knowledge over the last eight or so years ago. So I went back to skool, started taking a night class in beginning Chinese and it came back to me much quicker than I expected. I’m not amazing at it or anything but I’m really enjoying it.
That’s how you all remember hanzi right?
Now, circling the wagons, I’m reflecting on my hobbies again. When I first decided to try to find a job as a software engineer, I had the very real fear that taking programming from a hobby to a job would make me lose my love of it. In some ways, I have to admit it has. Actual software engineering work, when you don’t try to be the 10x asshole, can sometimes be a little boring, when it’s just helping out marketing or maybe doing the same thing in the same routine.
Other times though programming feels a bit like flying. Everything clicks and time melts away. I wish I knew how to make myself feel like that more but I think the secret might be that most of us feel that way. We don’t hear about us because we’re just there doing our job, not making waves, or keynoting conferences, or releasing yet another JavaScript framework.
Or maybe I’m just a slacker and should run off to China and teach English. Thoughts?
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.
Other resources
While it still has some quirks, depending on your project and your commitment to polyfills, flexbox is a powerful tool to build some really nice layouts. To get started building your own, Sketching with CSS has the ultimate flexbox cheat sheet. And of course, Mozilla Developer Network has a full rundown of flexbox layouts and links to many tutorials.
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!
How Cute
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?
Flexbox in action
