We’ve all been tempted to skip writing the tests. Whether it’s time pressure, business pressure, the complexity of testing, or we just want to get on with something else. We might be tempted to say “YOLO!” and move on. So here’s a list of reasons why you might want to think twice before doing that.
For a while I’ve been looking for a better way to organize the git repos I work with. I’ve tried just dumping them into a single directory, and I’ve tried adding sub folders such as personal, work, and tools. But both of these solutions had the same...
Our front end team at Usabilla had the amazing opportunity to attend JSConf EU in Berlin this year. It was a fantastic experience for us all and we came home having learned a ton. This is just a summary of my key take-aways from the conference.
I recently switched from Jekyll to Middleman for my personal website. After using Middleman for a couple projects I felt that Middleman was much easier to setup and manage than Jekyll, also I really don’t like liquid templating. The one thing I missed from Jekyll was automated deploys to Github pages. It wasn’t very difficult but you have to jump through a few hoops. Since I’m running my own build I decided to add some tests for my static site too. So here’s the how-to.
Today is my last day at Cozy. 😢 My wife and I are flying to the Netherlands to start a new adventure close to my Dutch family. I started at Cozy in January 2014 as a front-end engineer. I have an agency background, and after spending several years working on client websites, I was excited to have a chance to do something different — to work on one product with a cool team.
Twelve months ago I had hardly written a single test. After some encouragement and guidance on how to write tests my world changed. Yes, there’s lots of evidence that says writing tests reduces bug density (which is awesome), but that alone isn’t necessarily going to persuade you to take the time to do them. What made me adopt a workflow where I write tests first? The fact that I enjoyed it!
Lodash and functional programming offers some wonderful ways to make code cleaner and more readable. But they don’t always play nice if you happen to use Knockout observables. I’m going to introduce a way to make handling observables in functional style easier.
I’ve never been big on New Years resolutions. I’ve always leaned towards a ’let my yes be yes, and let my no be no’ mindset, and I’ve never been confident in my ability to keep a resolution so making them just seemed disingenuous for me. But this year I feel different about it. Perhaps it’s due to hitting the big 3-0. So here’s what I’d like to focus on this year:
Often enough you’ll need to reference sensitive credentials in your project, or give an easy way for people using your project to change environment relative information in your project. Normally it’s not ideal to commit sensitive information to a public repository. Neither is it ideal to commit code which only works for your setup. Enter ‘Environment Variables’.
When my shared hosting plan was coming up for renewal I struggled to find a hosting service that I liked. I was hoping for good uptime, something that didn’t break the bank, and preferably something with a decent UI. (Maybe I was asking to much.)
A year ago my wife and I bought our first house. Like any other unprepared first-time homeowners we asked neighbors for advice, tools and a helping hand with projects. A year later we’re a little more confident, own a few more tools and now we get...
It doesn’t take long for a project to get unwieldy if you don’t have a good system for creating your styles. I recently attended Webvisions where Shay Howe ran a workshop titled “Front-end Legos” that gave some pretty good advice on keeping CSS clean...