Git Style Guide is a GitHub project aimed at helping you improve your Git practices. Or if you are like me it shows that everything you’ve been doing is wrong.
I’m probably showing my age here, but I remember using CVS, Concurrent Versions System, and how horrible it was. Every time I attempted to branch and merge I’d break the whole system. Now with Git I feel like you can’t really mess it up.
Have you seen a public repo that you think has a great Git log and branching pattern?
If you’ve used Laravel’s form validation for any length of time, then you know it’s a powerful system. It makes the tedious task of validation very simple while still keeping the door open for complex rules.
In this tutorial, I want to show you a simple and easy way of validating forms that contain dynamic fields. A common use case for these types of forms is when you would like to allow a user to add more fields to a form.
Shuttle is a simple SSH shortcut menu for Mac. It’s designed to take the pain away from remembering all your SSH shortcuts and directly from your menu bar you can visually see all the SSH connections you have available.
I’ve been using it and love the simplicity of the app. Adding new shortcuts is easy and defined in a JSON file. However, if you already have connections defined in ~/.ssh/config it will automatically pull those in.
The project is open source and created by Trevor Fitzgerald and inspired from SSHMenu from Linux. If you have trouble remembering your connections or shortcuts definitely give this little app a try.
I’ve been running a weekly Laravel newsletter for almost a year now and it’s been a lot of fun. When I first started, after each send I would watch the unsubscribes, subconsciously using that as a metric to see if what I was doing was any good.
A year later and my outlook is completely different. I now enjoy unsubscribes. When someone leaves it tells me they didn’t care what I had to say or lost interest in the topic and it prevents me from getting bumped up to the next pay grade.
Looking at it from the angle removes so much stress. I’d trade high subscriber numbers for high open rates any day.
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.