25. December 2013 09:44
I've been involved with Git at work since late May of 2013. Transitioning to Eclipse, Java and Git was a bit intimidating in the beginning. However, after some bumps in the road learning how to utilize Git, I became a convert to this version control system. It's light weight, fast and runs well on Windows Server 2012. I'm slowly migrating my projects off of TFS 2010 to a local Git repository. What really sold me on Git is the ease of branching and merging operations. Then, I discovered the add-in component for VS 2013 works as well or better than Eclipse's integration of Git. About the only thing I am losing when I leave TFS is work item tracking. However, that function will be filled by a $10 copy of Jira for my personal use.
I don't own powerful server hardware. So Git is a Godsend compared to how TFS 2010 and Sharepoint 2010 drag on my outdated servers.
This series of blog posts will cover my experiences installing and configuring GitStack.com's version of Git for Windows:
VS 2013 and Git
- Stuff to download: (Prerequisites)
- First, check out this post on MSDN to make sure your VS 2013 git client is operational. I strongly suggest you make sure you can connect VS 2013 to a github or bitbucket project and clone successfully before you even begin downloading anything else. (I started out using github, but switched to bitbucket. Bitbucket allows me access to Jira functionality (issue tracking) and code reviews (limited.) It's free and allows private projects.
- I like to install a command line git tool. I use Chocolatey to install git command line tools. I've run into some issues getting this to work over SSL, but I've solved all the problems and documented them in this series of articles.
- If you are going to use Git over SSL, you'll may need OpenSSL for Windows. GitStack needs an RSA key file, and OpenSSL is the only way I know to generate this file and create a certificate request tied to the key file.
- You'll need the gitstack.com git installer.
- I generally like to have a copy of Cygwin available. This is completely optional, not required and not really used for this install (unless something goes incredibly wrong.)
- There's probably some other stuff I've forgotten. I'll add downloads here as time and memory permits.
- Configure ports
- Firewall Changes
- Users and Groups
- LDAP/Active Directory
Since it's Christmas morning and the family is waking up, I'll fill in the details later today and tomorrow. I need to go prepare Christmas breakfast for the World of Ware Crack crowd.
23. April 2013 19:00
I was working on a side project to remove http post operations to a web service and replace it with a proxy component. Easy right? I thought it would be. But the service I was looking at didn't utilize a WSDL or SOAP. And Visual Studio 2008 doesn't like that when you set up a service reference. So, I had to look at writing my own proxy. Not so easy, but doable. The real issue is that the group that writes the web services uses VS 2012 and .Net 4.0. The group I work in uses VS 2008 and .Net 2.0 (when we actually use .Net.) These two don't play well together when you need to create references.
It took me a little while to realize the dll's the dev had sent me were targeted at .Net 4.0, and the best I could do was target .Net 3.5. Goodbye project references. (Except, a little magic with managed C++ might do the trick. I'll discuss that in another post.)
"Best laid plans of mice and men" and all that other rot that doesn't really help solve the problem.
20. April 2013 08:07
Here's some results I got while piddling around with webkit's SunSpider benchmark program this morning.
It's not scientific, or even well controlled. I'm using the latest updates for IE 10, Chrome and Firefox as of April 20. Links will take you back to the test results. My laptop is an old dual core machine running Windows 8 64bit, 8GB RAM and a slow 500 GB hard drive.
IE10 - 203.5 ms
Chrome - 280.9 ms
FireFox - 310.9 ms
Just some food for controversy.
18. April 2013 06:17
I've heard just about every excuse in the world why code is not documented. The excuses are bogus. All of them. Documentation must be a part of the corporate culture. Most organizations do not understand the need for effective code documentation. There's no training, no policy and no will to make it happen.
Ignoring documentation at the code level, the application level and the infrastructure level leads to another form of technical debt. An organization that ignores documentation, doesn't train personnel to develop it and doesn't incorporate it into their culture is living for today.
This is one of the better articles I've found on the internet regarding the mechanics of .Net program documentation using Sandcastle. It's long, detailed, and effective. You should read it.
14. April 2013 21:18
Every C++ dev knows a java coder. We're friendly to show we're tolerant.