Flexbox: Tables of the Future?

Leave a Comment

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 actionFlexbox 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.

Work From Home Friday: Emacs Maybe?

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.

shaq, cat wiggle

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.

If Your Only Tool Is a Hammer Then Every Problem Looks Like a Nail

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?

cat shakes head no

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.

Work From Home Friday: Don’t be Afraid of Rebasing

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.

For better words than mine check out Nathan LeClaire’s Don’t Be Afraid of Git and a good visual tutorial can be found from the amazing Thoughtbot blog.

Engineering Block? – Having Time to Work on Your Own Projects Is a Privilege

Sleeping kitten breathing

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.

Oui kitten with beret

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.

Work From Home Friday: Playing Around With Node

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.

Cat in a box

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.

An Unpopular Opinion: Am I a Good Feminist?

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?

Cat Herding 101: The Things That Really Go Wrong For Beginning Programmers

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.

Cat teamwork

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.

 

Spelling

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).

 

Conditional flaws

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.

 

Syntax errors

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.

1
2
3
4

<div class="outside">
  <div class="inside">
  </div>
</div>

Doing too much

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!

Cat Boss Final Form

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).

No News is Good News? or A Short Discourse on Pair Programming

Things have been quiet here at casa de Lindsey which is good for me, but probably not as exciting for the people who (maybe, sometimes?) read this thing. Since April I’ve been relearning why I love being a software engineer in a supportive and awesome culture at Scripted. It’s a small tight-knit team and I was a little worried about coming in as a newbie to a solid team but they’re amazingly lovely people and I love learning with them and from them. Front-end only land has been so busy I still haven’t had time to really even touch my first love of backend APIs (which would require me to learn Rails to do it justice at Scripted) but I haven’t really mourned that loss. Instead as one half of a front-end team of two I’m running around like crazy helping our backend/full-stack team be better front-end engineers, sitting down with our designer to craft better UX and handholding our marketing team through WordPress template changes when the starts align correctly.

Which brings me to my continued sermon on mentoring/pair programming and how much I luuuuuurve it. I keep reiterating it, but I’ll continue to reiterate. I love mentoring other engineers, I love pairing with people. It can be super awkward at first, because even if you’re the one who is supposed to be mentoring you won’t have all the answers. But that’s not the point! The point is for you to foster learning, for you as well as the other person. Software engineering is not a perfect set of knowledge that you can learn once and then just churn out the same thing over and over, but it’s also not always about going down the rabbit hole of discovery (especially if you have to earn a living writing code for a living). Mentoring and pairing almost feels like cheating to me, because I don’t have to solve all the problems myself. I might not even have to come up with the original idea for something, just help refine it and still get to take partial (but deserved) credit in the end.

Also there are so1 many2 better3 resources than my stream of consciousness musing on pair programming (and a MAJOR SHOUTOUT to a study on the benefits of pair programming for women – hint: it benefits everyone). Please check them out, give it a shot if you can. It is really, really hard at first and it’s definitely not for everyone but for me and most of my pairs it just takes so much stress of the engineering cycle.

Expect more posts soon, I’m thinking of trying my hand at “teaching” since I can never have enough “lemme just show you this one cool thing” moments. If it all works out it will probably be a series of posts a la “I don’t want to make another to-do app in JavaScript to level up my skills”.

 

On to Smaller and Better Things!

My time with Udacity has come to an end. I made some amazing lifelong friends out of it and learned enough to fill a book but I decided it was time for me to trundle along to a new opportunity. So I’m excited to announce that I’m joining Scripted as a JavaScript Engineer! It’s going to be a bit of a brain warp focusing most of my efforts on the front end but I’m ridiculously excited for the opportunity and working with the awesome new coworkers that I’ve met so far. The team is much smaller and very careful to cultivate their culture and I just felt right at home the minute I came on site for my interview with them (as an aside: sort out culture fits first or you will be miserable no matter how potentially amazeballs you think a project is). I really look forward to diving back into my JavaScript roots and being able to geek out about all the upcoming changes.

My other hope in this transition is to get back into mentoring more. Working in Mountain View and attempting to mentor in SF was super draining on me, but now that I’ll be working in SF, I want to pour more of my free time back into mentoring and helping others join this awesome ride that is the tech industry. So I’ll be spending some time to think about how to approach that aspect.