Creating a Local Subversion Repository

A little known feature of TortoiseSVN,The coolest Interface to (Sub)Version Control, is the ability to create local Subversion repositories anywhere you can create a folder. I use this feature all the time both at work and at home when working with any source code to take advantage of all of subversion's powerful features. It is also a great way to replicate Microsoft's Briefcase feature with all the cross-platform abilities of subversion and features.

To Create a Repository

1. First ensure you have installed TortoiseSVN (Free/Open Source Software).
• This can be found here. Ensure that if you are running 64-bit Windows that you download and install the 64-bit package, otherwise you will not see any context menus.
2. Navigate to the folder in which you want to store your local repository.
• I usually put all my repositories in a folder called Subversion just to keep them neat and to serve as a reminder that you should never modify these folders unless you are using a Subversion client.
3. Create a new folder and give it a name.
• I have called mine CLRHook. Its a good idea to give a descriptive name to this folder that way you can quickly look at the folder name to determine its contents as opposed to having to use Repo-browser. Remember that because you're creating an actual repository you must use subversion tools to interact with the files contained within this folder.
4. Right click on this new folder, Navigate to TortoiseSVN and select Create repository here.
   

   

   Create repository here
5. You should now have a repository that you can commit to, just like you would any other repository. Except instead of using the svn:// protocol to access the repository you will use the file:/// protocol.
• In this example the repository was created at file:///G:/Subversion/CLRHook.
• One more thing to note is that TortoiseSVN will use the the username of the currently logged on user when committing to the repository.

In this blog post I have shown you how you can quickly make a subversion repository, go forth and keep on VCS'ing.

You Have Already Got Your Mind Made Up

The problem with ideology is, if you've got an ideology, you've already got your mind made up. You know all the answers and that makes evidence irrelevant and arguments a waste of time. You tend to govern by assertion and attacks.

Life is rife with debates arguing over Ideologies, the phenomenon is known on the Internet as flaming/flame wars. Everything from politics and religion, right down to your choice in soft drink. Anywhere where people can communicate you are bound to find a thread along the lines of X is Better Than Y And If You Don't Agree You are Wrong. I am not here to try and persuade anyone one way or another but I thought I would start a series with a few of my thoughts and opinions on some famous flame baits within the development community.

To start off we have to start with what I consider the most notorious and in my personal opinion pointless flame bait:

PC v Mac
First off I think the debate is wrong from the start for the following reasons:

1. It is usually poorly defined what this means, in most modern contexts it usually refers to the choice of Microsoft Windows or Apple's MacOS. Although in recent years it appears to have shifted (along with the Apple business model) to Apple's Offering (iPod, iPhone, Mac) vs Every other equivalent or perceived equivalent (aka The iPod Killer).
2. It also doesn't take into account alternative operating systems such as Distributions based around Free/Open Source Software (F/OSS) such as Debian or any of its derivatives.

A few years ago this debate held a little more weight in my mind because the debate would usually center around the choice of hardware. PC generally being touted as IBM PC Compatible/x86/Wintel and Mac being one of Motorola, and later Apple-IBM-Motorola's Brain Child. However with Apple's transition to Intel and the official support of Boot Camp  the point became moot in my mind.

Therefore the real debate circles around Software and usability of said Software. In my personal opinion I have found Microsoft Windows to meet my needs much better than OSX. I have always felt that Apple's software tends to hide too much from the user or make assumptions about how the user should interact with said software.

For example the concept of Right-Clicking to bring up a context menu (or left click if you are a lefty) is still treated as a second class citizen on OSX, delegated to a Secondary click non-standard option with even Apple's latest mouse.

Another example is XCode, while I admit the last time I used XCode as a development environment I was back in College running on OS 10.5 on a dog slow second generation Intel Mac Mini (or at home using my even slower G4 MDD), I remember that it was nothing to write home about. Specifically the lack of good refactoring abilities, such as those available in NetBeans, Eclipse, and Visual Studio. Refactoring is something we as developers do everyday, and anything that can help automate the process should be done. Sure one could argue search and replace, but why introduce a human element into it? This is a process that has obviously been solved and automated by others, why not do the same?

All of the above being said and taken into consideration, I understand that some people see these as non-issues, and are willing to live with that. I completely understand that, after all I've owned my fair share of Mac's and still do. What it really boils down to is usability by the end user, if you as a user can be productive on a Mac then use a Mac. I myself find that I am much more productive on a Microsoft Windows based computer, and therefore use one.

However there is something about the Mac Mentality that prevents most Mac users from coming to the above conclusion. While I am sure an entire magazine could be written on the subject that is a subject for another day.

Sufficed to say You have already got your mind made up.

Thoughts On SQL Injection Attacks

While this post doesn't cover how to prevent SQL Injection Attacks (there are plenty of well written articles on the subject already) This is more a response to a blog post from Cameron Pitt that started as a comment on his blog and turned into a little more. You will probably want to read the blog post or none of this will make any sense.

This was one of my beefs with PHP back in the day, and I'd say even still: How easy it was (is) for amateur developers to put themselves into a really bad place and not even know it. A lot of these SQL Injection issues have changed with the introduction of mysqli bringing in the concept of prepared statements, but there is just so much legacy code out there its insane.

Even without legacy code a quick Google Search and then scan of the results for php mysql tutorial shows that all of these tutorials are using mysql as opposed to mysqli, and if they are using mysqli most are not using the Object Oriented Style and they are not taking advantage of prepared statements. Therefore you have new people coming in learning the language from Tutorials on the web that frankly in my opinion are giving out what is now considered Bad Practice.

As far as detecting SQL Injection attacks, I cannot think of a way for a web-host to implement this without becoming cumbersome to the developer. At some point the developer has to take responsibility for what code is executing and follow good practices. The following apply to just about any modern programming language: 

1. Use Prepared Statements
• This really is the answer, in this day and age there is no reason not to use them. Most modern languages have support for this (PHP-mysqli, .NET/C#-SqlCommand.Prepare())
2. If the above is not possible for some reason, Make sure you have some way to Sanitize all inputs.
• One of the 10 Commandments of C (specifically 5 in the linked version) states that you should ALWAYS validate user input, therefore 'Never Trust The User'
3. Use the Rule of Least Privilege
• Don't assign more privileges to the service account being used to insert data. If they don't need write permissions, don't give them write permissions. On numerous occasions I have seen developers simply set the GRANT ALL permission or running as the sa user when doing data access. While its debatable if this is even 'OK' for development work, it is absolutely unacceptable in any production code.
4. If you are at a large enough development shop don't allow your UI programmers to write Data Access Logic.
•  This goes back to my Core Belief of Specialization, the UI Programmers should do one thing and do it well: Program amazing front ends for your customers to deal with. The Database guys know their stuff and know all the little ins and outs of SQL Injection and can combat against it in their Data Access Layer.
• In the very same breath I say while you don't need to be an expert if you are not a DBA you should at least be aware of the issue.
5.  If you are a Mom and Pop Shop perhaps you should be looking at using Frameworks for your data access needs.
• It has been awhile since I have done any serious PHP work, but back in the day I seem to remember PEAR being all the rage, and that the days of writing your own Data Access Layer are dead.
• While I have some strong opinions on statements such as that above (which I'll save for another blog post) for a development shop that cannot afford to have a DBA this might prevent you from completely shooting your foot off.

Following best practices in general will stave off most unsophisticated attacks, but its hard to teach best practices to someone just learning the language now is it not?

What is the meaning of 'No Tribal Knowledge'?

To answer your question we first need to define what I define as Tribal Knowledge

From Wikipedia's 'Tribal knowledge' page:

Tribal Knowledge is a term most often associated with a process step of the Six Sigma process. It is often referred to as knowledge 'known' yet undocumented such as information that has been handed down generation to generation with no documentation. Knowledge contained within a group that is assumed to be factual but has no known data or analysis to verify that it is factual. The Six Sigma community has adopted the term to use the description of 'tribe' as an analogy of a company.

Anyone who has ever worked with me knows that I always ask for the why of any process. One of my core beliefs circles around understanding why the process is being done, as opposed to the how the process is being done or even the end result of the process. My logic lies in the idea that if you can fully understand why the process was done, then you gain a deeper understanding of the process, and in most cases are able to derive the how on your own.

To bring this back down to a development perspective: I am a stickler for documentation and commenting of code. I truly believe that any quality code should be documented; such that should another developer need to re-implement your code they can do it from documentation alone. This, in my opinion, by definition excludes Tribal Knowledge, as you now have a written account of this information.

This belief also includes the concept of well documented Application Programming Interfaces (API). I feel that in any development project of size is more successful when API is well understood by all on the development team. Its advantages are that is cuts down on duplication of work, and also extraction/encapsulation of logic to areas of specialty.

I look to Microsoft's lead with the MSDN Library. Here is a wealth of information that allows any developer to easily reuse well documented, well tested, well supported, and well understood libraries to develop applications that the original Library designers probably never even imagined. Further more the fact that, if you had followed the documentation to the T and not relied on undocumented functionality or behavior, that you can take a program that was written for Windows 95 and run it in Windows 7 and beyond. That fact alone is staggering and in my opinion (and apparently others as well) the reason that Microsoft has continued to dominate the Industry in the ways it has.

But back to the topic at hand (the above will probably be covered in a future blog post), because my believes directly counter the concept of Tribal Knowledge I have chosen to make my rally cry 'No Tribal Knowledge', and therefore thought it was the perfect name for a blog on development.

Share the Knowledge

First let me welcome you to No Tribal Knowledge. This blog is dedicated to sharing my personal coding experiences, challenges, and triumphs. Along the way I hope to use this blog as both a learning and teaching tool. At times I will also dive into a bit of personal history, and how these experiences have shaped me as a Developer.

A little bit about myself. My name is Ace Olszowka, I am a Programmer/Build Master for a large software development company in Billings, Montana. I am a native of Hawaii, and the oldest of two children. I graduated from the Kamehameha Schools Kapalama Campus in 2006. From there I moved to Billings, Montana to attend school at Rocky Mountain College and graduated in 2009 with a Bachelor of Science in Computer Science with a Minor in Business Management.

My interest in computers started at a young age with my first computer being a Macintosh Classic II which I received back in the Summer of 1995. However this Apple Computer detour did not last long, because in Christmas 1996 I received my first ‘Real Computer’; A Sony VAIO PCV-90, a Pentium 133mhz with 32mb of RAM and 2gb hard drive running Windows 95, a monster of a machine at the time.

My interest was really more ‘Information Technology’ oriented in my youth. I received great pleasure in repairing and taking apart systems, and helping others. It wasn’t until my Senior year in high school that I began to take a real interest in the Software Development aspect of the Industry. This has continued to flourish in the past few years, and while I still enjoy using my IT skills on the side to help friends, family, and co-workers, Code is what will continue to put food on my table for the foreseeable future.

I hope that this blog will prove useful to any of those who stumble across it on the vast expanse of the Internet. I encourage you to comment and subscribe, and look forward to ongoing feedback and interaction.