Git is an enormously powerful tool, but certainly not the most beginner-friendly. The basic commands are straightforward enough, but until you wrap your head around its internal model, it’s easy to wind up in a jumble of merge commits or worse. Here are three aliases I use as part of my daily workflow that help me avoid many of the common pitfalls.

Have you ever had a channel in an ExpressionEngine installation that required its own set of custom fields, but only needed one entry? Perhaps a homepage or an “About Us” section that needed its own custom content but wasn't a traditional list of posts?  Single Entry can help.

Once configured, Single Entry moves your single entry channels out of EE's standard publish and edit workflow and into a new section of your content dropdown.  From there, you'll have quick access to creating and editing the individual entries in those channels without the hassle of navigating through the standard EE edit workflow or accidentally creating a new entry in a channel that can't use one.

Best of all, your data and development workflow aren't changed in any way. Single entry channels are still completely native and can be assigned custom field groups, category groups and statuses, and used in templates just like always. And through the configuration panel, even the name of the new section in the content dropdown can be customized.

Single Entry is available starting today on Devot:ee for just $5. Grab it here.

I’ve already talked about the EE setup for the new viget.com, but now I want to talk about the code. It took a little longer than I wanted to get to it, but let’s finally talk templates and custom addon development.

Before I started at Viget, I remember thoroughly enjoying the articles by Doug about building Viget.com in EE. That was really some of my first exposure to EE, and from there I’ve come to love it. My hope is that I can recreate some of Doug’s magic and talk through how I built the current iteration of the Viget site in EE. I know, it’s gonna be hard to do. This post is going to be broken into multiple posts, but buckle up, this is gonna be a long one.

Though we might wish otherwise, bugs (or, more generally, defects) are a fact of life in software development. Unfortunately for developers, so are unhelpful and infuriating bug reports.

Bad bug reports waste time and money while everyone goes back and forth to clarify the necessary details. Perhaps worse, bad bug reports tug at developers' sanity and can put strain on the team dynamic.

I know this from experience -- not as a developer, but as a bug reporter who has infuriated plenty of developers in my time as a product/project manager. Because I love my dev colleagues, I've tried hard to improve my bug reporting. Here are some tips I've come up with along the way for writing better bug reports:

• The first step is changing how you think about experiencing bugs, so you can report them in sufficient detail.
• Next, be as specific as possible in providing that detail.
• Finally, always try to reproduce a bug before you report it.

Let's look at each of those tips in depth.