Today I Learned: Using SCSS in your Vue Components

If you haven’t yet looked into Vue.js, it might be time to. The front-end framework is a powerful, progressive alternative to its main rivals, Facebook’s React and Google-backed Angular, and has been continuously gaining traction among the open source community.

One of the hallmarks of Vue is its use of single file components. It’s a pattern popular among the Vue community for a variety of reasons - among them the increased maintainability and reusability of components in medium to large projects. In Vue’s single file system, a component is defined by three tags: one for HTML, one for JavaScript, and one for styling. A very simple component may look like this:

In this way, the CSS for a given component lives alongside the rest of its code, and with the scoped attribute, will scope all style to only this component - preventing it from bleeding outwards and affecting global styling in unpredictable ways. 

One might notice, however, that throughout much of Vue’s documentation and in countless tutorials, guides, and articles on all things Vue, the language used to this styling plain, vanilla CSS.  In a world where SCSS exists, with it’s support for variables, mixins, and nested styles, can we do better? Yes we can. 

Styling your Vue components with SCSS is incredibly simple - provided you have the right configuration. 

Above is an example webpack.config that makes use of vue-loader. You’ll want to install both the sass-loader and node-sass packages first, however.

npm install -D sass-loader node-sass

Once you’re configured, simply add a lang attribute to the style tags in your components:

And you’re set! Enjoy all the features of SCSS in your Vue components.


Peter Ludlum

Peter is a Software Engineering Intern at Tinfoil Security. A recent graduate of App Academy, he enjoys nothing more than bringing beautiful (and functional) web pages to life. When he isn't coding, Peter is usually lost in a book or strumming out a new tune on the ukulele.


When the unlimited vacation policy doesn’t work

Many of us startups provide what we call unlimited or flexible vacation policies, with the goal being to take as much time off as you need, as long as it’s manager approved and you can get your work done. There are so many pros and cons and I’ve seen so many people ask why to have or not to have an unlimited vacation policy in place. 

via GIPHY

Most people think that unlimited means people will take off all the time. And, yes, we have seen that happen on some very rare occasions. We do have a policy, for example, that interns no longer get vacation during their stint at Tinfoil. Internships are typically 3 months and have a set project. If an intern takes off too much time, they’re less likely to finish the project in the scoped out time. That doesn’t mean if all of their friends are going to Yosemite they can’t, but we don’t advertise vacation for them. 

What we’ve actually found for the flexible vacation policy, though, is that usually we see the opposite of most founders’ concerns: employees don’t take nearly enough time off to avoid burnout. There are lots of different things we’ve implemented in order to make our flexible  vacation policy work. The first thing we implemented was holidays. We try to have one holiday a month. Sometimes those are just fun, silly holidays like Pi Day, and other times they’re your standard federal holidays, like Thanksgiving. On occasion, they’re things we’re going to do together, like Tinfoil’s Anniversary. We try to make sure holidays are spread evenly throughout the year and allow time in conjunction with both weekend and weekdays throughout the year to break up the normal routine.

When we implemented holidays, the policy was that you could still come in to work, but shouldn’t expect anybody else to be in the office. Initially, many employees still worked holidays, but it eventually got to the point where we realized that we should really take those holidays off. We started to and we noticed a drastic drop in stress and burnout levels.

Once we implemented the holidays, we still had a couple of issues where some people were still going to the normal rhythm. They wouldn’t take longer vacation and, though the holidays helped a lot, they didn’t fix the entire problem. Part of what we noticed was that if someone did something outside of their normal routine on a weekend, for example, if they traveled or did something unique that they didn’t normally do, they typically got to the point of burnout way less frequently. This led to a solution: we took a handful of holidays (typically holidays such as Pi Day, that employees weren’t already traveling for or doing atypical events for) and called them special holidays. We’ve been beta testing special holidays for 2-3 years and they work wonderfully. 

For a special holiday, we give you up to $60 to go out and do something outside of your typical routine. This could mean going camping, kayaking, skydiving, getting a fondue as a group… anything you wouldn’t normally do. Of course, we have had to create guidelines over time. We reimburse up to $60. If it’s under $60, that’s ok, but we ask our employees to be honest and we’ll reimburse up to the amount they actually spent. There are some things that we’ve rejected, as well. As always, you have to be flexible and revisit your policy over time. For us, we saw some employees doing the same thing every special holiday. We eventually made the rule of there needing to be at least a 12-month gap between repeating the same event or activity. 

We did have to implement a few guidelines at the beginning, based off of questions employees asked. For example, if you want to host a party, that’s OK, but if you want to play a bunch of board games, you can’t buy six different games on the company and call it good. We wanted this to be for experiences, and not for physical items. We encourage employees to use it in a manner in which they can actually experience something that they wouldn’t usually do. We found that, when people actively partake in this benefit, they tend to come back refreshed and get excited about what they did, whereas those that didn’t do anything new don’t have the same level of “refresh.” People excitedly talk about the things they did and others end up wanting to do that experience the next time, so we have a page on our internal wiki to add fun weekend ideas to share with others. This is great for team bonding, great to make sure that people don’t hit burnout, and it’s one of the few things we’ve added to make sure our unlimited vacation policy works. 

It’s true that every so often you’ll see somebody taking advantage of any policy you have in place that’s beneficial to them, but, on average, we believe our employees are honest, faithful, and act with integrity. Often, you’re going to see that unlimited vacation expectations are set by the top. If your management is not taking enough of a break, your employees won’t take enough of a break, and everybody will suffer. There are lots of little things you can do to make this policy successful. What have you found? Have thoughts on how we could improve our policies or new ideas we can try? Email me anytime with suggestions!


Ainsley Braun

Ainsley Braun is the co-founder and CEO of Tinfoil Security. She's consistently looking for interesting, innovative ways to improve the way security is currently implemented. She spends a lot of her time thinking about the usability and pain points of security, and loves talking with Tinfoil's users. She also loves rowing, flying kites, and paragliding.


Pluses and Pitfalls of Repo.stream

Scenario: you are working on a phoenix app that has seen a good deal of use and need to do some transformations of some tables encompassing an exceptionally large number of rows and their relations. Obviously, some amount of considerations for performance are necessary; if you can avoid loading an entire table into memory in order to achieve this, that would be ideal right? Enter Ecto.Repo.stream, turn that giant list into a lazily evaluated enumerable and load rows as needed. Job done, right? Well, depends.

The good news is you will definitely address the issue of memory use, however it does come at the cost of time, which can increase greatly if, for instance, you need to access a number of rows in an associated table for every row you are referencing. For instance:



This might seem like a good idea, if there are large number Bar’s for every Foo entry, but since the stream must be inside a transaction, you have one connection you’re working with to finish enumerating over the stream. This can be adjusted with the :timeout option on Repo.stream which can be relaxed from its default at 15000 milliseconds all the way to :infinity, but if your streaming changes rely on a flaky connection or some other piece of code, you could run into an issue again on that side. Safer to avoid nesting streams if possible, or to find a different way of chunking data.

If memory is a more pressing constraint than time, Repo.stream is a pretty convenient way to manage how much is loaded into memory at a given time. Just remember to choose an appropriate timeout value before you start.


Alex Bullen

Alex is Tinfoil Security's Top-Shelf Programmer (and fetcher of things from high shelves). A former psychology wonk and recent App Academy grad, Alex endeavors to treat every challenge as an opportunity to improve his code-fu. When not busily building blocks of precisely put code, you can find him reading fantasy novels or practicing kung fu.


Dockerfiles for Phoenix

While a lot of our older software was written in Ruby and Ruby on Rails we've been expanding the past couple of years into Elixir and Phoenix (Elixir's batteries-included web framework). Docker remains our preferred mechanism to deliver our software in a well-tested and repeatable format. I'd like to share with you a simple Dockerfile for Phoenix, specifically supporting Phoenix >= 1.4 which uses webpack instead of brunch.

We're using a multi-stage to keep the image slim and nimble. In the first step we get a copy of the Elixir dependencies, mainly for the phoenix and phoenix_html Node modules that are co-located in the Elixir Hex packages. The second build file lets us build and emit the finalized assets with webpack. In the final step we're back to an Elixir base image and we can copy everything over, merge the assets, and set the command for starting the server.

This produces an image around 100MB. Compared to our Slim Dockerfiles for Rails that's a space savings of 50%! We've seen some pure-Elixir applications even smaller when you use Distillery to create an optimized release, which we'd recommend for heavier production use as it gives you a lot more control.

I hope you enjoyed seeing an example of building a slim Docker image for Phoenix. If you'd like to help build next-generation security software and work with Elixir and Phoenix daily check out our open job positions!


Ben Sedat

Ben Sedat is the Engineering Wizard of Tinfoil Security. He's a bit of a blend between a traditional software engineer (builder) and security engineer (breaker). He spends a lot of time thinking about security: both detection as well as creating solutions for the security issues that exist in software and the internet. He also plays lots of video games. Lots.


Awesome Possum

Our team is like a small family. We try to encourage everyone to get to know everyone else. Unfortunately, as with any business, sometimes sales, marketing, engineering, and all the pieces in between don’t collaborate as much as they could. As founders, we appreciate every employee, but sometimes the new engineer doesn’t really know what the new sales person is doing, nor how they can help.


Enter: the awesome possum. For a while, I’ve been thinking of ways to encourage people on our team to collaborate with others they normally might not collaborate with, and how to encourage people to show appreciation for the help they receive. That’s then I came up with the idea of the awesome possum. The awesome possum is a little stuffed possum. If you have the awesome possum, you pass it along to the next person who does something awesome (out of their job scope or truly exemplifying a Tinfoil value) for you or someone else. They, in turn, pass it along. There’s no time limit for holding the possum, so you could have it for a minute or a month.


When I first showed up with the awesome possum everybody laughed. Now, he’s dressed more dapperly than I am and always in a new Tinfoil hat. It might be a small thing, but it’s just one way for each of us to show appreciation across the team. There’s a lot of joy when the possum ends up at the other end of the office, circulating amongst a new team.  A little out-of-the-box thinking goes a long way.


What great hacks have you implemented on your team to encourage collaboration or appreciation? I’d love to hear them!


awesome possum

Ainsley Braun

Ainsley Braun is the co-founder and CEO of Tinfoil Security. She's consistently looking for interesting, innovative ways to improve the way security is currently implemented. She spends a lot of her time thinking about the usability and pain points of security, and loves talking with Tinfoil's users. She also loves rowing, flying kites, and paragliding.