A little over three years ago the team at UserScape had the idea to start a new light and simple helpdesk application that would later be named Snappy.
Today it was announced that we will be shutting it down. For me, this is a sad day. I’ve spent countless hours on the project, but it’s deeper than that. When you and your team have built something from just an idea on a whiteboard, you have a passion for it that others can’t see. It’s your baby.
There is a popular mantra among programmers, “You are not your code” and it’s true. I don’t want to be defined by any code I’ve ever created, but the code and product as a whole are deeply personal. Saying this is the end is sad.
As with all failed projects all you can do now is look back objectively. Try to grow from the experience and keep pressing forward.
My thanks to everyone involved in the project. It was a fun ride.
MailChimp includes a neat drag and drop email designer, but it lacks the ability to customize your templates outside of just the basics. One such problem is the font choice. By default, it only includes a list of nine web safe fonts.
These fonts are your safest bet if you want to support as many email clients as possible, but I like to make my emails unique. In my opinion, a custom font gives the design a little extra pop and professionalism. In this tutorial, I want to outline a simple way of adding these to MailChimp’s included templates and still keep the nice drag/drop workflow.
In the latest Five-Minute geek show, Matt covers his tips for writing technical blog posts quickly and easily.
I wrote a few of my own technical blog post tips but I like how he focuses on improving your speed. I’ve written more in the past year than I ever have in my life and I’m still slow. However, it is getting easier.
A tip that neither Matt nor I mentioned is, always remember you are the expert when writing about a technical topic. That doesn’t mean you have to dumb it down. Just pay attention to not miss any steps that you think everyone knows.
As developers, we are frequently using the internet to help us solve issues. We run across an error code, a crash, or another type of problem and we usually go to the internet. With the vast amount of knowledge that is available, and the incredible search engines that we have at our disposal, it is pretty easy to find someone else who has already run across the issue. Sites like StackOverflow make it even easier to find other people who have experienced the issue we are running across.
The issue is that we don’t really know if the information being shared with us is accurate. The author of that post, or response, may be guessing. They may have found a hack or workaround that kind of works, for now. They may be completely wrong and are treating a symptom as the actual problem.
I agree with the premise of this whole article. It’s so hard in the ever changing world of tech to know what is still accurate and what isn’t. Just today I had to update a tutorial I wrote back in September. The basics of it was the same, but the dependencies changed enough to make it not work and in turn cause frustration for readers.
I’ve noticed in my own searching habits, that when looking for tutorials I always look for the published date. If it’s over six months old chances are it isn’t even accurate.
A few months back I created a tutorial on Setting up Gulp, Bower, Bootstrap Sass, & FontAwesome. If you had problems with the tutorial I’m sorry. Apparently the gulp-ruby-sass npm module I used is undergoing some changes causing the SASS to error out and never compile. I have updated that post to recommend sticking with version ^0.7.1 until v1 stables out.
I’ve also created a GitHub repo with everything setup. This way you can see the exact versions of dependencies I used in the tutorial.
What I do find odd is I had a similar problem with Laravel Elixir a few weeks back. It uses node-sass but something must be going on with the development of both of these plugins. Hopefully, it will all be sorted out and I can stop pulling out my hair.