Other Views: By Month | By Category | By Tag Cloud
Syncing your forked repository to the original repository is an important step before submitting any pull request to the original repository for the changes in your forked repository. Even if you are not going to submit a pull request to the original repository, there are times that you want the additional features and/or bug fixes that have been done since you forked the original repository.
You could do a pull request but this adds an additional commit into your forked repository instead of making your forked repository match the original repository. In order to sync the forked repository without adding any additional commits as part of the process you need to configure the original repository as an upstream remote, merge in the changes from the original repository and then push the merged version back to Github.
Throwing away exceptions in your code is just a bad practice and makes it harder to support your application. It may make it easier for you as a developer to get something working but in the long run it cost way more money to do the maintenance and troubleshooting then if you had just put in proper exception handling to start with.
I have worked on several codebases recently where methods returned false if either a business rule failed or an unexpected exception occurred with no logging of the error anywhere. This made it extremely difficult to figure out what the issue was. In several cases, even when you hooked up a debugger there was no way to get at the exception details since the exception was not passed into the catch block.
As part of my demo during my Vagrant talk, I use the opentable/win-8.1-enterprise-amd64-nocm vagrant base box with the virtualbox provider. This vagrant base box unfortunately has an issue with the vagrantfile that is included with it looking for the old/unneeded vagrant windows plugin to be installed and trying to port forward the WinRM and RDP ports without detecting if the port is already in use.
Luckily, it is really easy to fix the included vagrantfile so that you can create vagrant machines but you have to do some prework before running a vagrant up using this base box.
Syncing your forked repository to the original repository is an important step before submitting any pull request to the original repository for the changes in your forked repository. Even if you are not going to submit a pull request to the original repository, there are times that you want the additional features and/or bug fixes that have been done since you forked the original repository.
You could do a pull request but this adds an additional commit into your forked repository instead of making your forked repository match the original repository. In order to sync the forked repository without adding any additional commits as part of the process you need to configure the original repository as an upstream remote, merge in the changes from the original repository and then push the merged version back to Github.
I am doing an Ionic Framework presentation and I wanted to use the Visual Studio 2015 Cordova Tooling.
I have done this presentation twice in the past couple of months using my Intel Nuc machine with the Visual Studio 2015 RTM Cordova tooling but it is kind of pain to do this since the Nuc is a desktop machine and doesn’t have a monitor so I have to look at the projector screen or being a laptop to use as well. Setting up 2 machines in 15 minutes as well is a pain and hoping that the remoting from the laptop to the Nuc is stable just asking for trouble even with a travel router that I have.
Welcome the continuing series on using Jekyll. In this tutorial we are going to go through how to create the series listing like you see for this blog series.
Sometimes a blog post gets too big and you need to split it into multiple articles or you want to do a series like this one that builds upon each other but you don’t want to have to manage a listing of all of the post in the series. Instead you can easily create a liquid template that does all of the work for you.
Welcome the continuing series on using Jekyll. In this tutorial we are going to set it up so that we can do draft posts that we can check into our repo but not have them show up on the production site.
In the last couple of articles, we installed jekyll locally but we didn’t talk about editing existing blog post or adding in new ones. There will be times where you will start a blog post but not have time to finish it all in one sitting. You could just create all of the files in the post directory and set the publish flag to false but over time it will become harder and harder to tell which articles have actually been published.
Welcome the continuing series on using Jekyll. In this tutorial we are going to setup your MAC (OSx) computer to be able to edit your blog on your computer.
Up to this point we have been using the Github web site to edit all of our files but the downside to this is that any chances you want to make show up live in your blog before you have had a chance to test them.
Welcome the continuing series on using Jekyll. In this tutorial we are going to setup your Ubuntu Linux computer to be able to edit your blog on your computer.
Up to this point we have been using the Github web site to edit all of our files but the downside to this is that any chances you want to make show up live in your blog before you have had a chance to test them.
Welcome the continuing series on using Jekyll. In this tutorial we are going to setup your Windows computer to be able to edit your blog on your computer.
Up to this point we have been using the Github web site to edit all of our files but the downside to this is that any chances you want to make show up live in your blog before you have had a chance to test them.