Daily Software Development

I'm serious. If you create a new branch in git, you didn't really do much of anything. All you did was make a pointer. There is no copying of the files. No additional changesets. When you checkout the branch you just created, you still didn't really do anything. It just changes which branch you’re on. The files don’t change at all. That's because git does not need to change the source code at all in order to deal with this new branch.

When you start changing the code, however, you'll be adding new commits that are in that branch. The branch itself isn't really a thing though, since git effectively just makes a linked list of your changesets.

In the example shown here, notice that the blue line for “feature-xyz” does not have a dot until it’s first commit. That is because the branch starts, and it’s just a link pointing nowhere. Once there is a commit, there is some significance, but the branch itself is nothing. Git is primarily just a tree made of these links. This simple example illustrates some basic branching and merging.

I hope this little bit of info about git makes using it easier. If you want to learn more about using GitHub, please check out my Pluralsight course on GitHub.

I’ve got a Pluralsight course about using GitHub that went live on Tuesday, so I thought I would post a few quick tips to help anyone using GitHub or GitHub for Windows and also promote my course.

There are a ton of ways to get a repository into GitHub for Windows to use it to manage your repository. I go over all of these in my Pluralsight course, but one of the neatest ways to add a repository is to just drag and drop the folder or the page.

You literally just need to go to the folder in explorer and drag the folder into GitHub for Windows.

Once you’ve dragged the folder in, it will bring up this “Create” context menu if it’s not already a repository. This will also call “git init” on the folder, so it becomes a repository.

Once it’s done, you’ll have a repository. It will commit an initial .gitattributes and .gitignore file for you.

If you already have a repository on GitHub, you can drag the URL into GitHub for Windows.

Once you drag it in, GitHub for Windows may want to know where to store the local copy. Just choose a location for it.

After it is done cloning the repository, you’ll have a local, connected copy.

I hope these little tricks make it easier for you to set up repositories with GitHub for Windows, and if you want to learn more about GitHub, check out my Pluralsight course.

I’ve got a Pluralsight course about using GitHub that went live on Tuesday, so I thought I would post a few quick tips to help anyone using GitHub or GitHub for Windows and also promote my course.

When you need to use the command line, it’s nice to open it right in your repository instead of having to “cd” your way there. When you’re in GitHub for Windows, you can use the Tools context menu to “Open Shell” like this:

Once open, you’re in a git shell in your repository with context-aware information to help you complete your task.

I’ve got a Pluralsight course about using GitHub that went live yesterday, so I thought I would post a few quick tips to help anyone using GitHub or GitHub for Windows and also promote my course.

One of the main concerns that I hear from businesses about hosting their code off-site is security. While nothing can ever be “completely secure”, you can help yourself a little bit by enabling two factor authentication in GitHub. It uses most two factor authentication apps, so you can set up any device as the second key.

Once you’ve got it set up, GitHub for Windows will even prompt you for that auth token after you type your password. Annoying to have an extra step? Yes. More secure? Yes.

I’ve got a Pluralsight course about using GitHub that went live today, so I thought I would post a few quick tips to help anyone using GitHub or GitHub for Windows and also promote my course.

When you’re running in GitHub or GitHub for Windows, you’ll see some icons that are near the repository name. These tell you a bit about the repository. They can indicate that a repository is a GitHub repository, non-GitHub repository, or a fork of a GitHub repository. They’ll be here when you’re running GitHub for Windows.

This icon indicates a GitHub repository:

This icon indicates a forked GitHub repository:

This icon indicates a repository that is either local-only or connected to a different remote (not GitHub):

I’ve got a Pluralsight course about using GitHub that will be going live this Tuesday, so I thought I would post a few quick tips to help anyone using GitHub or GitHub for Windows and also promote my course.

I thought I would start out these posts with a very simple time saver. When you’re typing your commit message, you can just click enter to commit your changes.

If you’re including additional information in a description, clicking enter will just give you a new line like so.

I hope knowing this will keep you from having to move your hands from your keyboard, and if you want to learn more about GitHub, check out my GitHub course! This tip is not mentioned in my course, so you’ll need to watch it to learn more.

I’ve been working as a developer for quite a few years now, and I’ve had a number of different setups and development rigs. Laptops, desktops, pairing stations, etc. have all been my tools over the years. They all get the job done, some pieces work better than others though. Here is a look at what I am using now.

This is not an intentional selfie. It’s just a picture of the Lenovo Yoga 2 Pro that I’ve been using for development. I was a bit concerned at first, since I am used to using development desktop computers. It’s worked well for me so far. I am not sure if I will need more than the 256GB SSD, but I’ve got plenty of space even with all of my development tools installed. I’ve not had any performance issues, but I am not working on projects with long build times.

Probably the coolest thing that I was issued when joining Clear Measure, was my docking station. I am used to placing my laptop on a docking station using a special docking port on the laptop bottom.

This docking station was super easy to set up and runs both of my monitors, keyboard, mouse, headset, Internet, and I just have to plug in 1 USB cable when I set the laptop down. It’s called a Dynadock, and is a bit more expensive than I would like. It works though! I can even plug in speakers, though I don’t use any. Headsets work better for calls than speakers, so I use these.

This is the cable to recharge my headset, and it nicely coils around this station with the wireless dongle plugging into the top.

This is my Logitech G930 headset that I’ve been using for all of my video calls. It works great, fits comfortably and has very clear audio for me and everyone listening to me. I’ve had to unmute a couple of times and it will turn off automatically if you’re not using it for a while. I’ve run into that a few times with James Shaw on the call. He gets a good laugh about it. The headset is super comfortable, so I’ve got no complaints.

I like a high DPI Logitech G400 mouse, so I can quickly move the cursor while barely moving my mouse. This mouse is adjustable, so I keep it as high as possible. I’ve got others with these types of features, but this one is more comfortable and remembers the high DPI setting. On my others, I have to turn up the DPI setting after booting my computer.

You may also notice my highly stylish Pluralsight mouse pad. I’ve got a course that will be coming out soon.

One of many reasons I am glad to live in Ohio is that I am able to make it to Stir Trek every year. It’s a great annual conference in Columbus. It takes place in a movie theater, and is wrapped up by a movie. I have a bunch of these USB keys from them, and I keep one on my desk for quick, sneakernet transfers.

I don’t know about you, but some things just need to be written on paper. I’m not a tablet and stylus user, so I grab this fancy Lake Quincy Media pen and write quick notes on this pad of paper or on my Moleskine notebook if it’s something more permanent.

Speaking of swag that I have around, I’ve got this nice ASP Alliance coaster that I use. I’m a former ASP Alliance author, editor, and developer. I haven’t written articles for them in years, but I do have some nice swag from my time working there.

The last thing I want to point out about my setup is this window AC unit that I have in place to regulate the temperature in my office. Yes, I have central air conditioning in my house, but I often keep my door closed. My cat is a bit of a trouble maker, so I only occasionally allow him in. My south facing windows also keep the room warmer than the rest of the house with me, computer, and nowhere for the air to go. I also love keeping it quite cool while I work.

If you didn’t notice it, our “flag” month was the same month as Independence Day in the United States. We celebrate that day with flags, fireworks, and a lot of cookouts. Notice anything in the picture? Yep. We’re missing the fireworks. Anyway, the topic of Flags Over Objects is an important one.

Flags Over Objects is the Software Craftsmanship Calendar’s anti-pattern topic in July 2014. As a developer, I am sure that you’ve come across code where boolean values (flags) were used far too much. This is often a misuse of state. Plenty of times there is a better, simpler way of handling the state of objects.

In this image, you might notice (looking carefully) a few obvious (and common) issues with using flags. First, you’ve got a whole list of checkboxes even though some of those can only ever be one at a time. You might also notice that there are a lot of repeats of the same checkbox.

You are correct. I don’t usually do recruiting posts on my blog, however, I am guessing that my blog readers are people who might be interested in working with me. I joined Clear Measure a couple of months ago, which is a company started by Jeffrey Palermo and Mark Stavrou. Primarily based in Austin, we are starting to build a pocket of developers in Northeast Ohio. Our team up here is currently remote, but we are hoping to get enough people to merit some suburban office space for our team.

Let me know if you’re in the Northeast Ohio area and want to play buzzword bingo with this card:

We all love buzzword bingo! Right? right?

You can always check here for Clear Measure’s current openings. Even when we don’t have a listed position open, contact me anyway, because I firmly believe that a company should always be hiring. The best people don’t come along every day. That’s how I ended up working with Todd Ropog and Kevin Kuebler years ago. They were the right people to join NimblePros.

As software developers, we have to make a lot of assumptions about things. It goes with the territory, however, we try to avoid making assumptions whenever we can. One of the values that we hold up is Communication, and that means that we need to communicate with our users. June 2014 is Assumption Driven Coding month according to the 2014 Software Craftsmanship Calendar Anti-Patterns edition.

The calendar (as always) takes a more visual approach to this software development issue.

Obviously, we’re supposed to notice that Eric is missing a hand, so he cannot use this newly installed palm scanner. Whoever decided to put in this new interface should have thought of a backup system for Eric or used a different authorization mechanism.

If we step back and think of this in terms of software, we’re talking about making an assumption about our users, data, or how interaction with the system will happen. An example of this would be assuming that your users “all use the start menu”, “all search for programs”, “all use the quick launch bar”, or “all use the desktop”. Each of those is an assumption that Microsoft could make when developing its next version of Windows. Each of those assumptions would be a bad one. Heck, even assuming that I named all of the possibilities already is a really bad assumption. What if someone uses “Run” or PowerShell?

When we’re writing our software, we take a lot of guesses about how the users will use our systems. Don’t! As you’re building, watch them use it. See how they use the system. Ask the user to perform their daily routine in the new software and see what they do. Ask them some questions. And make sure that you check different types of users. Sure, you will not catch every case, but you can avoid a lot of headaches. You might not even have realized that certain users would use the feature you’re building if you don’t ask.

Let’s focus on avoiding this issue for the rest of June.

SPOILER ALERT: Eric has both a right hand and a left hand… This photo is fake.