CenturyLink’s gigabit service is pretty awesome, but their provided routers are pretty average when it comes to configurability and simply raw performance. The problem with this is that the way CenturyLink’s Gigabit service runs, you need to do a little more work to configure just any normal router to work with the service. For me, it took a little bit of digging and experimentation to figure out the right way to get a third party modem to work with CenturyLink; in my case a high performance Asus AC-3200, previously used with my Wave gigabit internet service due to it’s high performance routing backplane.

Ubiquiti WiFi gear is becoming well known as the go to brand for nerds wanting to have home WiFi that competes with commercial set ups. The Ubiquiti AC-PRO access points in particular are in the category of “next level” consumer gear, and after installing them i’ve never looked back. Being commercial gear the Ubiquiti APs do have one annoying requirement: you need to run controller software on your network to monitor and control the access points through Ubiquiti’s cloud based controller software. Luckily you can run this software on a range of hardware – and a $35 Raspberry Pi is just the ticket.

Recently I’ve been updating the configuration of a bunch of personal servers to match the 2016 PCI requirements. One of the 2016 PCI requirements requires you to disable TLS 1.0 as it is now considered insecure. One of the problems with doing this of course is the fact that WebDeploy uses SSL and by default won’t allow connections and deployments to occur with TLS disabled. Luckily the fix is rather simple.

A few years ago the Gmail team began experimenting with the concept of interactive extensions to email messages, with the release of Gmail Actions (now called Gmail Email Markup). These simple additions to your HTML email allow developers to add call-to-action type links to your emails, without customers even needing to open your email.

One of the first things you figure out when working with Git is that like other source control providers, you want an easy way to exclude files from ending up on your source control to save yourself uploading items such as binaries and local user files (here’s looking at you Resharper!). By adding a .gitignore file to your repository you easily make this possible (if you’re using Windows, feel free to take a look at my post on creating these files successfully in Windows). The problem you have next is when you add a gitignore rule that’s a little too aggressive and your new project files fail to be picked up by Git, but you’re not quite sure which rule is the cause – this post shows you how you can troubleshoot these issues.

Depending on who you talk to, one of the coolest parts of the new Windows Phone OS coming to devices in the next few months is the ability to run Android apps. Yes, you heard me correctly: you will be able to run Android apps on your Windows Phone 10 device. With the preview releases coming out on a regular basis lately it’s good to see we’re getting a little bit closer to having this ability in everyone’s hands soon, but in the meantime the question really is: how do I get to try this now?

So you’ve got your own personal Git use dialled in, you’ve got a server environment configured with commits flying into your project like crazy, now you’re ready to start leveraging the power of Git with others. New workflows exist for distributed version control systems that offer big gains in terms of developer workflow, interaction, quality assurance and overall delivery process. Let’s take a look at one of them – GitFlow, so we can turn your team’s Git usage up to 11.

So you’ve got got your source code into Git, you’ve learned how to work with your repository in a basic fashion and you’ve pushed it onto another server for safe storage. There are a few more tricks to using Git that will make the journey easier and are worth looking at before continuing.  Although you’ll become more confortable with Git’s approach to source control over time knowing that the following features exist and how to use them will save you a lot later.

Centralised Version Control (VCS) providers like TFS and SVN always rely on a central server to store and maintain your project’s source control assets. While Git is an example “distributed” version control (DVCS) it is still most commonly used with developers relying on a central store for everyone to push and pull commits to and from. There are a number of options are your disposal so let’s take a look.

Few generations get to see as many epic battles for mindshare as our recent generations – in the 80’s it was VHS and Betamax and this decade we’ve seen Git and Mercurial duking it out. Developers have voted with their commits, and I’m pretty sure Git won the war. When setting our to use Git there are lots of basic tutorials, but none that approach it from a zero-to-hero in a team environment. In this blog series I am going to trying to set out to change all that by walking you through the steps from working in a non-Git source control environment to using DVCS with other people.