Leaving a job is never easy, especially when you've been a part of moving the company forward.
Recently, I learned that a lot of the frustrations that I had with my previous position were being addressed directly
They are moving forward, implemented Scrum and a lot of the changes I was pushing for, and have turned the development team into a highly motivated, effecient team with a great sense of camraderie.
And that's awesome. I just wish I could be there to see it happen. It's a shame when the changes can only be brought about with a major catalyst, such as someone leaving the company.
Best of luck, team A.D.D. - I know this is going to be great for you all.
Friday, May 18, 2007
Oh, The Places You'll Go
Posted by
Nic Webb
at
8:12 AM
0
comments
Labels: management, personal, satisfaction
Thursday, May 17, 2007
Get XmlDocument from a class
So - I've been trying to find an easy way to add a ToXml() method to a lot of objects lately. Here's what I've come up with:
MemoryStream ms = new MemoryStream();
XmlWriter writer = XmlWriter.Create(ms);
XmlSerializer xs = new XmlSerializer(this.GetType());
xs.Serialize(writer, this);
XmlDocument doc = new XmlDocument();
// Need to start at the beginning of the MemoryStream
ms.Seek(0, SeekOrigin.Begin);
doc.Load(ms);
return doc;
The Seek method took me the longest to figure out. I kept getting a "Root node is missing." exception.
Hope this helps someone.
Posted by
Nic Webb
at
11:04 AM
0
comments
Labels: code snippets, development, xml
Friday, May 11, 2007
CodePlex and Subversion
As I've posted about before, Subversion is a great tool. It's
- Open Source
- Free
- Fast
- Easy
Rob Conery and his awesome SubSonic project are hosted on CodePlex, which uses TFS as it's backend. I'm working with TFS now (at work) and it's a great solution for the teams we have here. But, I don't think it's appropriate for the CodePlex community.
And Rob's losing contributors - something no open source team wants to happen.
So - here's my two cents. CodePlex should switch to Subversion. It's a much more appropriate source control tool (for this type of collaboration) and I'll even go out on a limb here and say that if they do switch, I'll personally see what I can do to start contributing to SubSonic.
Posted by
Nic Webb
at
7:16 AM
0
comments
Labels: development, open source, subsonic, subversion
Wednesday, May 09, 2007
Monday, May 07, 2007
Team Hanselman Fights Diabetes
As I've mentionend before - I'm a Type 1 Diabetic.
And Scott Hanselman is as well. And he's raising money to fight it. Which is awesome.
Posted by
Nic Webb
at
7:28 AM
0
comments
Friday, May 04, 2007
Everything I ever needed to Know about Database Design, I learned from .netTiers
OK - not really. But, it's a good play on words.
I recently evaluated CodeSmith and .netTiers to help me develop the middleware for a project I had been working on. I'd like to talk about some of my experiences, and what I learned.
- .netTiers doesn't like tbl_.
Originally, the database had been developed with the tbl_table_name convention - and although there's a StripTablePrefixes in .netTiers, it seemed like it was being ignored. I remedied this problem by scripting up the entire database, applying Regular Expression Magic™ to change the table names to PascalCase, and then re-created. - Don't name any of your tables anything that might be a type in .netTiers framework - like Entity, for example. Originally, we had thought to have a generic "business entity" table that held customers and system users. This turned out to be a bad idea.
- Relationships and indexes are awesome. .netTiers will generate any "Get" methods based on any index that return strongly-typed Entities or List
collections, depending on if the index is a unique constraint or not. Very cool. Also, you can have GetCollectionFromRelationship() methods that do the same thing.
Plus - you've made a head start on optimizing your database. - If your schema has problems, and .netTiers doesn't compile - better to find out now, rather than later. This was a rather rude awakening for me - I thought I had a grasp on some DB design. I now have a much better one.
Overall - highly recommended. It doesn't come cheap (you need a licensed version of CodeSmith), but if you're already using CodeSmith - definitely give this template a shot.
One other caveat - it's open source, which is great. But, the documentation is a work in progress.
Posted by
Nic Webb
at
2:42 PM
1 comments
Labels: code generation, codesmith, database, design, nettiers
Dynamic Ducks! Dynamically! (Functionally too!)
So - with all this talk about the DLR and dynamic languages becoming first class citizens in the .NET Framework, I'm going to make a commitment. Here. Where about 10 people read.
I'm going to really learn a functional, dynamic programming language. I'm going to really understand lambda's. I'm going to figure out why those Ruby, Smalltalk, Python, and Haskell guys all start frothing at the mouth. I may even figure out this JavaScript thing.
I did get a B.S. in Mathematics - so I'm not too worried. Being a math guy and hearing about these functional languages intrigues me. Plus, with C# 3.0 coming out soon, I might even be able to apply this skill to my day job.
I don't know what I'm going to do yet, but I'm going to do something.
Posted by
Nic Webb
at
8:17 AM
1 comments
Labels: DLR, dynamic language, functional language, haskell, lambda, programming, python, ruby, smalltalk
Thursday, April 26, 2007
Buy me a Pink Cadillac
Today is my last day at Ariamedia. I was recently offered a position developing software for Mary Kay, and I will start on April 30.
It's been a tough decision to leave. I enjoyed working at Ariamedia, and met a lot of awesome, very talented individuals. I'm sure I'll be hearing about all of them in the future. My team has been on a push to get the software development lifecycle more agile (Scrum specifically), and I'm very glad to have been a part of that. I was also a big part of getting our source control moved to Subversion. I'm definitely glad I was involved with that - I'll never go back to SourceUnSafe and now, I don't have to.
Choosing Mary Kay was a big decision for me. I've never worked in a corporate environment. I've never had to wear a tie to work. So, that will be interesting.
I'll be glad to be working with a good friend of mine, as well.
I also had another very enticing offer that, while I didn't accept, I was very flattered to have received, and I'm glad to know that avenue is open to me. However, after looking at the choices that I had, and where I'm at in life, I'm happy with my decision.
Leaving a job is difficult. I've made friends, learned new things, and done a lot of (I hope) good work. You always leave with projects unfinished, but I know that I'm leaving them in very capable hands.
So long, and thanks for all the fish.
Posted by
Nic Webb
at
8:00 AM
2
comments
Labels: personal
Tuesday, April 17, 2007
Automatically insert SortOrder value in SQL
So, the other day I ran into an interesting problem. I've been using CodeSmith and .netTiers to develop all that "boring business/data access code" for an application at work. One of our requirements was to have a list of things with a user-specified sort order.
So, I added a SortOrder column to the table (not sort_order, but more on that later), and ran my code-gen. I didn't want to put the "automatic sort order insertion" into a stored procedure (since they're all generated), but I also didn't want to have to hit the database several times just to figure out what the next value should be.
Then someone showed me that you can have a function for a default value in a column in SQL Server. I knew this instinctively (NEWID() for a uniqueidentifier, or GETDATE() for a "date inserted" column) but I hadn't thought about using my own function.
So, here it is:
DECLARE @newMax int
SELECT @newMax = MAX(SortOrder) + 1 FROM TableWithSortColumn WHERE SomeForeignKeyId = (SELECT SomeForiegnKeyId FROM TableWithSortColumn WHERE Id = (SELECT IDENT_CURRENT('TableWithSortColumn')))
RETURN @newMax
I just created the function, set my default value for the sort column to dbo.GetNewSortOrder() and
Disclaimer: I'm not particularly sure this is really the right place to do this type of thing. If anyone has any suggestions or comments, please let me know. If you think this is a terrible idea and will cause my application to start fires and kidnap small children - definitely let me know. I'd like to avoid any legal entanglements.
Posted by
Nic Webb
at
7:10 AM
4
comments
Labels: development, sorting, SQL
Friday, March 02, 2007
i'm Making a Difference
Just ran across this while doing my morning blog checks.
Basically - Microsoft will donate a portion of the advertising revenue they recieve for every Messenger conversation you participate in to charity. All you have to do is add an emoticon to your display name.
I think it's a great idea - especially if you already use Live Messenger.
Posted by
Nic Webb
at
8:07 AM
1 comments
Tuesday, February 13, 2007
Hello, my name is Nic. And I'm a Diabetic.
Yesterday, I did something I haven't done in quite some time. I went to an endocrinoligist, or what I like to think of as "the hormone doctor".
I'm a Type I Diabetic. Many who read this blog probably already knew that. If you are one of those who's been reading that I don't know personally - please leave a comment. I'd love to know how many people actually read this thing.
I've read a lot of articles and interviews with diabetics, and it seems like so many let the disease become the focus of their lives. I remember reading one where a woman refused to take a 2-week vacation because she couldn't get enough backup supplies to last for a month. In Las Vegas, which is technically in the middle of the desert, but I'm pretty sure they have pharmacies in Vegas.
I feel that having diabetes is part of who I am, but it doesn't define me. Yes, I have to watch what I eat. So should anyone trying to be healthy. I have to take shots before every meal - no big deal. It's over and done with in about 3 minutes. I take Gatorade (or Powerade, or Generic-Sports-Drink-Ade) when I work out in case my blood sugar gets low. Just like most people working out. I wear a medic-alert necklace that would let someone know of my condition, in the case of an emergency.
But that's about it. I don't let it run my life, or ruin my plans. I just have to make adjustments when they come up.
I hadn't gone to the doctor in a while, because I've been without medical insurance for the past 3 years. I finally got insurance and can afford to go to the doctor, and my insulin and supplies aren't going to cost a fortune. It's a good feeling. In fact, paying for my diabetic necessities is now relegated to a financial "annoyance" status, instead of a financial "oh crap I can't afford to fix my car because then I can't buy my insulin" situation. Which is just how I like it.
Posted by
Nic Webb
at
8:13 AM
2
comments
Wednesday, January 03, 2007
Battlestar Galactica and Developing Software
For Christmas this year, my wife got me some really cool gifts. And a few days ago, I read an article that Joel linked to in his Dreaming in Code article. It got me to thinking, especially Joel's Yiddish to English analogy.
The two books, in particular, were very good. The meat of the books focuses on the creation and inspiration for the episodes, including the starting concepts (the episode Scar was initially just an idea: "the Red Baron episode") and their evolution into what I saw when I plunked my butt down on the couch with my wife and friends every Friday night.
There seemed to be a lot of vague ideas that went from brainstorming sessions, to screenwriters, to the producers, back to the screenwriters, to the producers, back to the screenwriters, to the producers, the director, back to the screenwriters (yes, I am repeating myself on purpose), and so on. And once a script was written, the actors would do take after take until the director was satisfied.
It got me to thinking about how many teams approach software specifications, estimates, and that oh-so-fuzzy factor I like to call "Client Satisfaction." This client can be the general public (if you do shrinkwrap software), the big multinational corporation that's going to send your consulting business into the stratosphere, or your professor grading your midterm project.
You start with an idea: We need an "inventory system." If you're like some custom-software consultants, at this point you send a fleet of analysts that "speak customer" to try to figure out how to translate "inventory system" into a 200-page specifications document.
Then, the document goes to the developers to estimate, of if you don't want to use that word as a verb, to give an estimate. Read that last word again. Estimate. Dictionary.com defines estimate as:
to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately
or
a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work
Notice the key word in both definitions: approximate. We all know what that means (as I'm sure you knew what estimate meant, but I'm trying to illustrate something, so bear with me.)
Approximate. Why is it that an approximation in many software shops is treated like a prediction from Nostradamus, and not more like a "I hope it takes this long, but maybe not." If you're someone in charge of scheduling, please don't divide this by some number (usually 8, which is wrong), figure out which day of the week that falls on, and sign a contract with a client gauranteeing that it'll be done on that day. You'll be sorry.
In the past, I've been tasked with estimating very large pieces of software. There's been some with very well-written specification documents, and most of what has been asked of me is not difficult, at first glance. There's been others where it was just an idea.
Usually, when it comes down to giving the final "magic number" of hours, it's not that that number is balked at. It's that several times, scheduling based solely on that number of hours usually results in missed deadlines, frazzled developers, and perhaps most importantly, unsatisfied customers.
Why unsatisfied customers? In my experience, when I've developed larger applications, with a traditional BDUF pattern, the customer won't see a product until about 75% of development is done. By then, they've probably formed some more concrete ideas in their heads of what they want, and since they're (most likely) not developers, it may not be what you give them.
What does this have to do with TV? Many of the roles are analogous. Actors are developers - their performance can be thought of as the actual computer. Screenwriters function as a business analyst. The director is the client. (You could argue they're QA, and the client is the viewer. But it's my blog, so I'm making the analogies.)
There's lots and lots of revisions in this process. The client gets immediate feedback from the program's output, and if he doesn't like it, he asks the developer to try again, "with feeling."
This is something that many need to realize about developing software. The client has a fuzzy idea about what it is they want, and it's hard to nail that down in "specifications documents" or "business requirements." I'm not advocating throwing these documents out the window - well-written specs are invaluable to have. They need to evolve with feedback from the client - and it needs to be sooner, rather than later. And you better schedule that in too - because no client is ever satisfied with the first draft.
That's why good actors are paid lots of money - they start to instinctively know what it is their client wants and can give it to them with the least amount of iterations. I think that people who serve this role in the development world, like free electrons, or business analysts that are "good at dealing with people, can't you understand that?" are who you want on your team. They can get the satisfaction up high with the fewest iterations. They grok what the customer really wants.
So, remember this: clients don't know exactly what they want. They have an idea. Help them shape and mold that idea until they look at you give them and say "YES! That's what I've been after." Be sure to build that into your schedule too.
It would be nice if we could have a "satisfaction requirements" document, though. That's definitely the answer.
Posted by
Nic Webb
at
8:41 AM
1 comments
Labels: development, process, satisfaction, scheduling
Wednesday, December 13, 2006
Subversion Conversion, concluded
Woo! More than a month without posting.
Now that that's out of the way, let's get down to business.
Previously, I covered Subversion and Apache. While this was working great, what I really wanted in the end was to get https (http + SSL) working as a transport for the repository, so that remote developers wouldn't have to connect over VPN to access it.
Well, I failed. I looked and looked, and there's a lot of great tutorials out there, but none seem to work. It may be an issue with our setup (we are getting "This method not supported by your operating system" or somesuch, I'll check it tomorrow at work). We're using Windows Server 2003 R2, which isn't much different from 2003 Original (at least, not that I'm aware of) and I think I'll have to break down and compile the httpd from source, with mod_ssl.so as well. Not something I'm looking forward to.
But, it's working great otherwise. A huge project takes no time at all to Update/Commit, or pull down for new developers. Everyone using it agrees - it's definitely helping us get our work done faster.
Speaking of new developers - we're hiring. Be sure to drop us a line - and tell 'em Nic sent ya.
Posted by
Nic Webb
at
9:29 PM
1 comments
Labels: process, source control, subversion
Friday, November 03, 2006
Scott Guthrie came to Dallas
So, last night Anderson, Zach and I went to the North Dallas .NET Users Group meeting, with a very special guest: Scott Guthrie!
It was a great presentation. From the slides he was showing - looked like a presentation he'd already given at Tech-Ed this year. The information was great, and you can get the slides and source code he demoed last night here (not available yet, but he assured us it would be soon), so I won't go over everything, just what I was excited about.
First, CSS Adapters. Very cool, especially if you have, or you've got some people with the mad CSS skillz. His overview of speeding up build performance and the "new" Web Application project model for ASP.NET websites was good to see too. And of course, server-side comments. He talked about Atlas ASP.NET AJAX (that's a lot of acronym) too, but there's a lot to that and I won't go into it here.
LINQ was great - I see a lot of possibilities there. There were some concerns in the audience about LINQ was trying to "replace DataSets." Personally, I don't see it that way - it's just a new way to strongly-type your data layer. The thing I thoguht was cool was the possibility of doing joins across different data sources - a SQL database and an XML file, for example. That may be more of a "look what I can do" thing to try, but it's interesting to think about. Extending the LINQ provider model was also something that was exciting - apparently, there's already and Amazon LINQ provider out there that lets you search for books directly in C# code without having to wire up the Web Service.
Plus, I won a copy of Quicken 2007. Yay?
Edit: Updated link to Scott's blog post.
Posted by
Nic Webb
at
9:00 AM
1 comments
Labels: ajax, asp.net, css, development, linq
Thursday, November 02, 2006
Take my money, please
I'm going to move away from software development a bit and talk about something that is also near and dear to my heart.
I'm a gamer. You can see my GamerCard on the side there. I bought a launch day Xbox 360 (which was actually my wife's idea) and camped out a full day with my brother and the Imes for the second shipment last year. I consider myself a part of the "hardcore" gamer crowd - except for that I'm not very good. But I do spend a lot of money on the stuff.
That's why things like this really get to me. EA as a games publisher is like the dirty uncle that when he says inappropriate things at the dinner table, everyone gets upset, but no one ever does anything about it because "oh, that's EA. He's just like that. Don't worry dear, he didn't really mean those things that he said about you and your cat."
Need For Speed: Carbon was released on October 31, 2006. Content for this game went up Xbox Live Marketplace on October 31, 2006. Let's count the dollar value of all those "additions." Wait, this is a blog and you've got NADD. I'll do it for you - I was a math major, after all.
49.25. Dollars. Of extras. For a 60 dollar game that doesn't sound super impressive to begin with. I know, some of these downloads would result in duplicates. One of the 10 dollar ones gets you 3 of the 5 dollar ones. I'm lazy, and don't feel like figuring it out.
And it's not as if these were done after the game has been out for a while - this is from Day 1. At least Bethesda has released content after the game had been out for a while. And, they charged the right amout, after a bad first try. (I know, that link is for the PC downloads. I own the 360 version - my PC can barely run Half-Life 2 at a paltry 800x600 resolution. The prices for the PC and 360 downloads are the same.) I've been very satisfied with my Oblivion expansion purchases.
Major Nelson's comment board for this content is flooded with angry comments demanding that Microsoft step up and stop this kind of behavior from EA. Some have suggested a petition, others have suggested a boycott of EA's games. While I wasn't going to buy this game (and certainly not now), I think that's a great idea.
We know EA has dropped the ball several times in the past. (I could come up with several more, but again. I'm lazy.)
Microsoft's Xbox team claims they listen to the community. I believe the community has spoken.
Let's hope they do listen. And more importantly, let's hope they do something about it.
Posted by
Nic Webb
at
8:34 AM
0
comments
Wednesday, November 01, 2006
Message Massagers
This post will not be about Subversion.
Something Anderson talked about recently was how the Provider Pattern wasn't just for ASP.NET. He offered up a good example, but I thought I would expand on it a bit.
Something I've had great experience with is an application that I like to call a "Message Massager" or a "Message Munger" (pronounced mun-jer). Basically, the program flow is:
- Get input from some entity A
- Munge/Massage the input
- Give the input to entity B
- Get response from B
- Munge/Massage response
- Give the respone to A.
- Lather, rinse, repeat.
When I started, I hadn't really thought a lot about how I could make things easier on myself. I created all sorts of classes and schemas, and it never clicked that I was essentially doing the same thing over and over. After reading his post, I saw several ways I could have made my (and the developer who adopted my applications) life easier.
I won't go into the details of implementing a Provider pattern for this type of application - Anderson laid them out pretty well. Something else that I came across recently, though, might also be of interest. Eric Sink recently offered up an implementation of Map with multicore support in C#. Since most of the messages that I was munging (yes, that's the technical term) were independent of each other, this might have sped up performance quite a bit - several times my applications were dealing with 500-1000 messages per iteration. This is all just speculation, since I don't work on those applications anymore, but it's something I'll have to keep in mind for the next time someone hands me a stack of paper that defines an interface for communicating with some huge system.
Posted by
Nic Webb
at
7:37 AM
2
comments
Labels: development, multicore, provider pattern
Tuesday, October 31, 2006
Subversion and Apache
So, yesterday I came into the office with a pleasant surprise.
One of my coworkers turns around and says: "We have Apache up and running. Goto this URL and check this out."
And it's our Subversion repository over http, on Firefox, on a webpage!
When we started our process, we hadn't thought much about it. We initially went with the default svnserve option available in the 1.4 release - it worked out of the box with little to no configuration. The only problems there were the user authentication. By default Subversion authenticates against a file with a pretty simple scheme:
user1 = password1
user2 = password2
Not the most secure option, to be sure. We had talked about getting Apache up and running on the server we were hosting the repository on, but it was something that I thought we might tackle sometime this week. This guy spent his weekend installing and configuring Apache to work with our repository.
He used a couple of existing resources, and we only had to iron out a couple things to get it working right. I'll point these out here.
Here's our httpd.conf:
DAV svn
SVNPath x:/RepositoryPath/
# our user authentication policy
AuthName "SVN Server"
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIDomain DOMAIN
SSPIOfferBasic On
Require valid-user
AuthzSVNAccessFile "x:/PathToOtherConfFile/AccessFileName.conf"
A couple gotchas that we rant into: the SVNPath needs a trailing slash - we had some authentication problems without it. Also, make sure you have SSPIOfferBasic On set. Windows machines with logged in domain users shouldn't have to authenticate manually - it'll pass credentials along for you. Firefox can still browse the repository, it'll just need to authenticate manually. I believe TortoiseSVN users won't need this option, but it's good to have in case you ever need to authenticate using any other client (such as the command-line version).
AuthzSVNAccessFile looks something similar to this
[groups]
developers=DOMAIN\user1, DOMAIN\user2
managers=DOMAIN\bossman
[/]
developers=rw
managers=r
Basically, you have groups of users that you can define, then their repository permissions. The example above gives the developers group read/write permissions to the entire repository ("/") while managers can only read.
You could do some more complicated things, like secure certain projects in the repository. The important thing to remeber is to have the usernames with the domain in all caps, followed by the username it it's correct case. The username passed into the DAV module will be checked against here first, then passed on to the domain controller, and it's case sensitive here.
Also, when you install Apache, it'll give you two options - install as service (Everyone) monitoring port 80, or not as a service, run from the command line (Just Me) and monitoring at port 8080. If you're using IIS, then you'll want to choose the second option. You can reconfigure the port, of course - it's in the httpd.conf file. Just find the part that has
Listen 8080
and change it to whichever you want.
When you finally get it configured correctly, you'll probably want to install Apache as a service. It's simple - just type
apache -k install -n "MyServiceName"
in the console. (Change "MyServiceName" to something else, unless that's what you really want it to show up as. It'll install itself in the Apache service monitor and the Windows Services menu.
One final caveat - you have to use Apache 2.0, not 2.2. The Subversion modules don't load.
Also, install Apache before you install Subversion if you can - it'll make your life much easier. The Subversion installer will detect Apache and copy all the required modules over where they need to go. If you didn't (like us) then you'll have to do it manually.
You'll need mod_authz_svn.so and mod_dav_svn.so, which should be found in your Subversion\httpd directory. Copy them to the Apache\modules directory. Then, get libdb42.bin from Subversion\bin and copy to Apache\bin. I think this is everything - if I've gotten something wrong I'll update this as necessary.
My project today is to get https working on Apache - I'll post later on how that goes.
Posted by
Nic Webb
at
8:23 AM
0
comments
Labels: apache, source control, subversion
Sunday, October 29, 2006
Subversion and the Big Apple
Say you're working in a company with a top-notch creative department. They're excited about your new push for not using SourceSafe. Only one problem.
They're using Macs.
So, what do you do? You could tell them to use the command-line version and leave you alone. You could tell them to use Parallels and use the Windows pretty clients. Or, you could look for other options.
I'm not a Mac guy. Don't get me wrong, I think they make some great machines. The move to Intel processors has sorely tempted to get one for my home computer. My wife loves the Mini. But in a .NET world, Windows is the way to go. So, naturally, that's where I started looking for clients.
But your pretty pictures and shiny stylesheets (mmm... alliteration) don't have to come from a Windows machine. And if they don't, you still need a way to get them from your creative types to your developers.
We're evaluating both options right now. svnX is free, ZigVersion isn't. I'll let you know what our design team thinks.
One more thing. There's a lot of Java Swing based clients out there. We didn't like them for the same reason some people don't like Swing applications - it just doesn't feel right. It's not quite Windows, not quite OS X. That's just a personal preference.
Posted by
Nic Webb
at
3:38 PM
0
comments
Labels: apple, creative, source control, subversion
Saturday, October 28, 2006
The Subversion Conversion
If you've ever looked for a blog on software development, you've undoubtedly stopped off at Joel Spolsky's little corner of the inter-web. And if you have, then you've probably read The Joel Test. That first item on it - "Do you use source control?" is something I'd like to talk about over the next few weeks.
If you use Visual Studio, you've at least heard of SourceSafe. Heck, you've probably used it, or are using it right now. Would everyone reading please raise their hand if they really, really like SourceSafe? Do you feel warm and fuzzy inside knowing your code is "protected" inside of SourceSafe? Anyone?
No? Me either.
So, what do you do? You can either live with it (not a good idea) or you can change it. Now, in an ideal world, you'd be able to either convince your boss/CFO/purchasing department to whip out the credit card and buy everyone Team System. Try it. If they react the same way most would (and to be fair, it is approximately 1 hojillion dollars per developer) then you've got to find something cheaper. Or, dare we hope, free.
Enter Subversion. It's open-source and free-as-in-speech, and best of all, some of the CVS developers that got tired of it work on Subversion. So you know they've got some background on the subject.
"But Nic", I hear you say, "isn't getting this running for a group of developers who are familiar with SourceSafe and doing things Their Way going to be a pain?"
Yes, probably. But, instead of dealing with quirks and worrying about database corruption and that offsite developer whining about how slow it is, my company decided to take a more pro-active approach. I'm a firm believer in Getting Things Done. And if I have to "deal" with my source control system, I'm not Getting Things Done.
So, go ahead and download the latest copy for your environment from here. And if you're using Windows, and if someone tells you that you must have Apache installed before you can use Subversion, they are either a LIAR, or simply confused. You only need Apache if you're going to be doing http/https-based access or want to do some fancy authentication (like Windows Domain). For testing on your local machine, you don't need it.
If you're a Windows user, definitely get TortoiseSVN. It's a Explorer Shell Extension that encapsulates just about everything you'd do with the command-line version into that pretty GUI that we Windows users need. If you're using Visual Studio, then you should also pick up AnkhSVN. It's a plug-in that will enable SVN commits/updates from within Visual Studio, and it knows not to check in your compiled DLL's, or the SUO files.
From my testing, I've found it best if you have all of the projects within a solution in the same working directory. This will probably not be the way that Visual Studio is doing things for you - it defaults to putting ASP.NET websites in one directory, and everything else in another. For both Subversion's sake, and your own, keep everything in the same directory. Cassini can run a website wherever you put it. If you're still building .NET 1.1 websites, you can also setup IIS to have a website wherever your working directory is, and the applications should get created automatically when you pull them down, or when you create new ones. I'm still experimenting with this, so please leave me some feedback if you have any insight on this.
If you're serious about taking this plunge, then I highly recommend you first go pick up Pragmatic Version Control: Using Subversion. It's short, and has a great overview of what someone who likes to Get Things Done should be doing with their source control system. It says version 1.3 on the cover, and 1.4 is the latest version as of this post. Nothing significant from a user's perspective has really changed, it's a lot of internal improvements, API changes, and some administrative enhancements.
Now, as far as a company-wide conversion, we haven't taken that plunge yet. But, we will. We need to figure out some best practices, repository structure/locations, and the general process first. So, stay tuned. We're in this together.
Posted by
Nic Webb
at
9:37 PM
2
comments
Labels: development, process, source control, subversion
Obligatory Introductory Posting-y
Here's my first blog post. I'm supposed to use this to space to introduce myself and why I'm blogging, and why you should care.
I have a beautiful wife named Veronica. We've been married for about 10 months now, and we have two great dogs named Punkin and Dany. I imagine you'll all be able to see pictures and hear all about them. Those three ladies are what I come home to every day - they're very important to me.
I have a degree in Mathematics from the University of North Texas that I obtained after 6.5 years of grueling, diligent studies (at least, that's how I like to think about it.)
I recently got a new job working at Ariamedia in Addison, Texas. I'm their newest developer there. I'll probably spend a lot of time talking about some of my experiences there.
I have a lot of great friends, some that even have blogs of their own.
My name is Nic (no 'k') Webb. My middle name starts with 'C' and depending on whether you ask the Texas Department of Transportation or the Social Security office, the rest of it is either "ameron" or "ahill." It's an interesting story, which I'll elaborate on in a future posting.
I believe that a person's life is a series of experiences, and I like to savor each one. Too often I've found myself waiting for "the big payoff" in life, and I've come to discover that the payoff is the journey.
I hope you'll enjoy these snapshots of my journey.
Posted by
Nic Webb
at
2:08 PM
1 comments
