We Keep Coding

Testing legacy ASP.NET Web Form [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I need help figuring out how to test old legacy asp.net web forms.
A lot of web pages in our project are written long time ago and now it is getting to a point where maintaining/adding extra features are a pain in the neck. There are no methods whatsoever. The codes are not modularized and server side code are all over the place at the front pages (.aspx) mixing together with the UI logic.
Rewriting these legacy asp.net web forms seems to be the only way to go for long-term benefits. However, here is our problem. These pages all work fine right now, but no one on our team completely understands the business logic behind them and reading through the code line by line will be very painful. We thought maybe writing some test cases and apply that same test on our newly re-factored, modern web forms and compare the results will be more promising and accurate.
Does anyone know how i can go about this? How to test legacy asp.net web forms if the codes are not organized and madularized? Any suggestion or recommendation will be helpful.
So far i have looked at Selenium but seems like this is more for UI testing than for business logic. My main focus will be what data gets pulled from the database and displayed on the form and what data gets written into database (especially which tables) after the submit.
Also looked at Visual Studio built in Test suite, but seems like this approach requires the code to be organized in methods and functions so I didn't continue my reading.
Another thought i have in mind is monitoring the database and see which tables get changed during the period when i manually open a web page and input/submit some data. Will this be a good option?
Any thought will be appreciated. Thanks!

These pages all work fine right now, but no one on our team completely understands the business logic behind them and reading through the code line by line will be very painful.
Ok, so this is really the crux of your problem. Do you have access to the stakeholders of this application (i.e whoever it was designed for?) They are probably the best people to explain to you how its supposed to work. You need to get access to these folks and have them give you at least a crash-course in the "domain" of the application.
Only when you and your colleagues fully understand how this system works can you test it. If you don't have access to the stakeholders, then don't panic - just take this thing one module at a time and start mapping it out.
You don't have to go all out and learn the whole thing up-front - take it one module or subsystem at a time, make plenty of diagrams about how the various parts of the business domain work from the perspective of the users, and do the same then for how they currently work. Put both diagrams side by side and start planning how you might refactor the code to be organised more like the business flow, and less like the existing flow.
This can be a tricky process for sure but actually once you get going, especially once you know how the system should ideally flow based on the previous point, it's not that bad - bear in mind that you will surely be able to copy/paste a lot of your existing code - in fact, you should probably avoid the temptation to try to fix bugs on the fly at this stage. Focus instead on the organisation of your classes, etc, so as to make then adhere to SOLID - any classes that broadly stick to this will typically be very testable.
Any bugs or really poorly written code can be flagged at this stage for fixing later on; a key point here is reaorganise not re-write!
Armed with that knowledge, the next step is to write a test specification for the various parts of the application, based on the new design of the modules. That means, lots of tests and test methods (using whatever framework you like, MSTest or xUnit, etc). You really can't avoid this but remember, one module at a time!
As DanielMann pointed out, it might be worth looking at something like Specflow that will let you write test specifications in a natural(ish) language form - you may even be able to get he stakeholders on board to help write the tests!
You don't have to have literally every detail specified at first; once you have identified the major "business units" in terms of logic, you can break them down into smaller and smaller chunks of conceptual behaviour
So you may end up with tests like (just an example)
LoginModule_WhenPasswordIsWrong_RedirectswithErrorMessage()
{
//write some code in here that exercises the LoginModule and assert that it behaves as expected
//The really important thing is to write these tests based on the NEW design
//and NOT the existing system.
Assert.Fail("Write the test!");
}
Now, the key thing here - most, if not all of these tests, will not even compile and even the few that do, will probably fail. That's actually a good thing! Because now you have a clear path of what you have to do - which is to make those tests pass by implementing the new design. Best to do this in a branch of the original!
So in the example above, you might not even have a clearly defined login "module" - the code might be scattered across several pages and classes. But by writing your "ideal" tests up-front, based on an ideal design, you now have a target to aim for. And also you don't have to be totally purist about it - there is no sin in bending the rules and making some tests less granular than the ideal case - you can come back and do that later.
Rinse and repeat - every system you do, is one less to do tomorrow!
Once your initial set of test methods is passing, you can then "zoom in" and start refining them, in the process fixing bugs and crappy code (the same thing, in many respects :) you came across earlier.
Best of luck with it!

Protect project from renaming [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I'm currently working on a new project, and I would like to publish it as Open-Source...
The project consists in a server and a client created to emulate a famous 2d game...
There are already 2 or 3 some other projects of this type (Open-Source), but you all know in these days people have the habit to rename the work of other people and publish it under their name etc, so now there are hundreds of renamed versions of the SAME project!...
I already tought about GPL, but also the other projects where under it, and other people just renamed it published without having any problem...
So, I'm currently searching for a way to insert some "default" strings about project name, authors etc in the sources, so that stealers/rippers etc can't just rename the project and maybe sell it etc... So, i was thinking about an external dll that should contains these info and that should print them as console output when server starts, but sincerely, I don't think it's possible (to invoke some methods, in this case the console class of the summoner from the invoked object)...
But if it's possibile, any of you knows how?
And maybe, some of you know other ways to do what I said above (protect from renaming a project) in Open-Source projects?
Thanks for reading and for your answers

You can't "protect your code". By going GPL, you can have legal standing to sue anyone who infringes on the copyright licensing, but you can't do much else.
Maybe if your product was good enough, people would use your version above others. I don't quite think you understand that in true opensource, your original work is destroyed, and something better is produced. If you can't handle this, don't release your source at all.

I don't think you can do that and still be truly open source.
The open source definition dictates that
The license must allow modifications
and derived works, and must allow them
to be distributed under the same terms
as the license of the original
software.
I can't see how you can restrict modification of any aspect of the code (such as strings in the code like a name) and comply.
So you are looking for a non-open-source license. If your primary interest is to be credited, maybe look at Creative Commons Attribution?

Why not just provide the project under a license that prevents this?
That being said, project forking is one of the core, fundamental freedoms that are provided by many open source licenses. Using a license or a mechanism to try to avoid this may impact your acceptance by the community.

The GNU Free Documentation License might be able to do kind of what you're asking for here. At the very least, it requires more thorough change logging for re-distributors. You might even be able to declare the title an "invariant section", though you'd probably need to talk to a lawyer about that, since a lot of the language of the GFDL is specifically about changing the title. They certainly didn't intend for the title page to be an invariant section.
A big part of the trouble is that typically open-source licenses require people to change the title when they fork the code -- so their changes don't appear to be yours. I've never heard of anyone wanting forks to be required to keep the same title. I can't imagine why you'd want this. Even easier than improving your program, they could make changes to make it absolutely terrible, and they'd still be required to keep the same name. (And what happens if they want to re-use just part of it? How much of the original program is required, in order to keep the same name? I don't think this rabbit hole has an end...)
Even if you survive all of that, the GFDL is not designed for source code. It's not GNU GPL compatible. It may not meet the OSI Definition, and it's certainly not DFSG compliant. You'll probably piss off far more potential contributors than you will gain by preventing renaming. I can't think of any upsides to releasing source code under such a license. The restrictions are so strange that programmers wouldn't bother trying to figure it out.
So, I'm currently searching for a way to insert some "default" strings about project name, authors etc in the sources, so that stealers/rippers etc can't just rename the project and maybe sell it etc
How exactly is that different from selling it under the original name? To release something as open-source is to invite people to try to sell it. If they remove your name from the AUTHORS file or pretend that they wrote it, go after them for copyright violation, same as any other composition.

Taking over someone else's code

I am taking over someone elses code. What are some good ways to learn what that programmer did as quickly as possible? I have been running it, stepping through it and looking at the callstack. What else can I do?
Sorry I forgot to mention, but there is little documentation and I have been trying to fix simple problems. Thanks!

Set logging to observe in what sequence things are happening.
Read here: Hired as a developer to maintain and update current code base, no docs!

Start writing unit tests, as that will get you using his classes/methods, and you will do two things, learn it, and either find bugs or have tools ready in case bugs appear.

Usually the best way is to start working on the code fixing small bugs. The more true time you spend with it is the only way to learn the code base. There is no magic way to learn a code base. It will take weeks, months or possibly years depending on the complexity. However for most generic business systems a ramp up time is about 6 months of code knowledge and 6 months separate of industry knowledge to truly understand it all.

Fix a simple problem in it.
Edit:
Then fix bigger problems, and start writing documentation and unit tests, of the areas you understand. Build on those areas, and one day you might understand the whole system.

Documentation? Reading the code itself, without running in the debugger?
Other than that, you're doing what I would do.

There's no silver bullet in how can you understand someone else's code quickly. Specially if it's full of hacks and no documentation is avaiable.
You should try to understand the class structure, and execute the normal flow of the software, with a debugger help.
Don't jump too much code sections "oh, I think I know what this section does". No, you don't. You would be surprised of what "innovation" we may find in code.

Logging is good to see what the code does.
If you have a versioning system you could go and see what changes di the programmer do to what pieces of code, browse some history.
I find it useful sometimes to somehow try to understand the programmers code style, this helps me understand how could he think about a problem and solve it.

The first thing I'd do is take a look at the simplest dialog box and its code, mostly to analyze the coding style and look at how the developer prefers to arrange the code.
Once you know the coding style, and roughly where everything will exist in the file (or if things are put in randomly -- even that is helpful to know), it will be easier to go through everything else.

Talk to the users of the other person's code if you can (either end-users or other developers that had to work with his code). That will give you a sense of the quality of the other persons code - was it released with just a few bugs or did it take 6 months of revisions to get it right? Was the developer careful about making a nicely polished application or was it a mess? That should give you some idea of whether you need to just tune-up the code a bit or start replacing large chunks of it.

I like starting to add tests to the methods of the code, if they are not already there. Figuring out how to cover the code gives you a lot of insight into the codepaths, what the expected output should be, etc...

Everything everyone else has said is accurate in learning what the coder has done.
One other way of looking at it though is to learn the program itself. Play with the application in depth like a user would and understand what the program itself does. Once you understand the final system thoroughly it will be a lot easier to work out how and why it was written.

The first place I start is the database.
In my experience, understanding the datamodel is key to giving you context when you go through the code. (this assumes the data model is not a generic key-value generic entity table)

I find that I wont learn the code completely until I start fixing bugs / modifying it. If the original programmer is still there, then discussing the changes before implementing them would help.

It wouldn't hurt to document what you learn about classes, functions, etc. as well, just so the next guy (or another person who gets hired to work on the same stuff).
Also, when I've done this before, I've found it best to use the program quite a bit before trying to understand the code. May sound obvious, but more of what you see will make sense after that. Unit testing, as other people have suggested, may also help in the same way. (Helpful when you feel confident enough to refactor, as well.)

One thing that helps me learn systems faster is writing the documentation myself.
I get a overview
I will see many bugs/bad design decisions. Which makes it easier to order and prio them. (instead of picking a irrelevant bug and solving it, I will fix those that really matters)
I later on have an documentation.
Documentation will make it easier to justify refactoring/rewrite to the suit's

I think knowing what the code does, the problem it was written to solve at an high level is a good start. With that one can then mentally, at an high level too try to envision how such a problem might be solved with the type tool used.
From then, looking through the code will take on some meaning, and it will help in making it possible to follow the thought of the original developer. In addition, you will quickly spot when you are getting lost.
I also believe the code should document itself as my experience most time is a documentation outside of the code most times is out of sync with the code and could be misleading. So a few comments here and there, class headers, method comment should help too.
First time I inherit another person's code, I had migraine after two days, i was a nightmare.
So have fun.

I've spent most of the last year working on code that I inherited from someone else. There was no documentation and a large amount of what the system was meant to do was not written down anywhere, but in the clients head. The key for me has been to ask as many questions as I could and gather information from every source available. I would recommend compiling your own documentation as you go.
Many people might say don't rewrite code, but that may often be the best way if the code is poorly commented or coded (not self documenting). For code that I struggled with it has often been the best solution.
Another helpful thing to have is some kind of standards document before you begin. The standards doc will help you decipher the code or bring code up to spec and make it easier to understand.

How to write code in Visual Studio faster? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Whenever I start a new software project I spend a good amount of time at the beginning drawing class diagrams and other flow charts to plan out how I see the application working. This part just takes a lot of thinking and testing. But at a certain point when everything is planed out I don't need to think about it so much anymore I just need to code it.
IntelliSense is definitely a godsend, as is being able to generate code from it automatically by hitting the TAB key. But now I'm wondering: what are some other techniques or tools people use to get the code in their head to the screen as fast as possible?

I get a lot of productivity out of Resharper - It's especially useful if you learn all the features and keyboard shortcuts

As everyone else has mentioned, use Resharper or equivalent.
Learn the keyboard shortcuts and use them. Just about every operation you can perform in VS has a keyboard equivalent, and the more of them you know, the less time you'll spend poking around in menus. This is equally important for using Resharper.
Pay attention to anything you have to wait for. Are you waiting for builds to finish? Remove projects that you aren't working on from your solution and reference their assemblies instead. You can always add them back if you need to. Are you waiting for unit tests to run? Maybe you can segment the tests into a set you run several times a day and a set you run before every check-in. Are you waiting for your application to start up every time you test it? Maybe you can define a build configuration that excludes startup code whose functionality isn't involved in what you're working on right now.
Get a solid-state drive and put your OS and development tools on it. Put more memory in your machine.
A simple for tip for dealing with the tedium of editing code that you copy and paste: Don't copy and paste code. I'm sure that there are circumstances under which it's acceptable, even necessary, to copy and paste code, but if it's part of your everyday workflow you need to stop what you're doing and fix it. I wouldn't even mention this if more than one person hadn't suggested it.

I don't want to open a whole CodeRush & Refactor! / Resharper can of worms, but a good quality re-factoring tool like one of these would probably help enormously. I have been using CodeRush and Refactor! for a little over a year, and the time it takes to write robust and maintainable code is way shorter now than it was a couple of years ago.
Of course, there's a learning curve, but the benefits after just a few weeks are enormous.

Make your environment to respond faster.
Slow pc, IDE, build, repetitive tasks that could be automated kills speed seriously.
Every little thing counts. Even increasing Repeat rate in Control panel=>keyboard properties.

You could draw your class/sequence diagrams in a modelling tool like Enterprise Architect that can then generate the code for you.

I hate to be the one to bring this up and I'm no Linux fanboy but I tried an addin called ViEmu a few months back. It took me at least a month to get back up to my usual productivity because learning all the commands and how to chain them is a big ask but now,..I'm easily 5-10 times quicker at refactoring.
It kinda hard to explain how but you get the most work out of it when you come across text editing jobs that are awkward and repetitive it seems,..say you've got 20 lines of code where you need to remove the middle camel cased word from the variable name. It's that kind of thing.
The link for ViEmu is here - http://www.viemu.com/
HTH

Unfortunately for me it's just intellisense, although I do tend to re-bind a number of keyboard shortcuts to help. The context menu (my keyboard doesn't have a context menu button) is one of my most used for adding references etc.
I did read not too long ago about a 'neural headband' for gamers. It was designed to be trained so they could think 'forward' & 'fire' rather than pressing W + Mouse1, and claimed to increase reaction times. I doubt it could be trained up enough yet, but if technology like this could be used so you think 'implement base class Foo and add method Bar()' and the code is generated within VS, then that would be amazing :) Sadly it's a little way off, and I can imagine 'Coffee' being the result of far too many broken builds...

Good tools help a lot. I especially like Visual Assist X: http://www.wholetomato.com/

Have you thought about creating and using code snippets for things you do regularly? These can be a real time saver as you just dump them straight in and can easily refactor the variables used within them.

Well, no doubt I'm an oddball, but for desktop apps (not web) here's what I do. I consider almost any app as just a glorified editor. That is, it has a data structure that needs to be persistent, and a UI to let the user put information into that data structure and get it out.
For the data structure, keep it simple, simple, simple. I consider it just a repository for information, with as little redundancy as possible. I do not want to build data structure that exists for the purpose of being a visible manifestation of the underlying data, such as tree controls, etc. because then that needs to be kept in agreement with the underlying data, and you get into all the issues of how to keep redundant data consistent. (Example: for graphics, don't build it, draw it.) If I cannot avoid creating redundant data structure, I stay away as much as possible from notification-style programming that tries to keep redundant data structure in tight agreement. Much of the buglist and performance issues arise from that. Rather I prefer loose coupling, where a certain amount of inconsistency can be tolerated and is managed by processes that run once in a while to propogate changes.
For the UI, I was a big believer in OOP and MVC-style UI coding, until I discovered this in 1986. Now I'm spoiled, and I can get complex UIs coded in a fraction of the time possible by the usual control-event-handling style, and they are trivial to modify as requirements change. But so far, I'm in the company of maybe only 3 people in the world who use it, because it is definitely not mainstream.

It seems to me that I see two things:
You don't have a full keyboard. I can't recommend getting a new keyboard enough.
You could use templates to make it easier. I gather that you have to do a lot of programming before you ever get started on your project. If you would use templates, you could make a template containing all your exception handlers, .NET references, and so forth. Then when you want to code, you just open the template, edit the namespace (which might be automatic) and your good to go.

You may try Resharper.
Other option - you can try Telerik's Just Code.

I learned the dvorak keyboard layout, which is much faster for English and a little bit faster for programming. It took me three months to get back to my old qwerty speed, but I continued improving. I think it saved me a lot of time in the long run.

In addition to Resharper, I've found Hawkeye saves me enormous amounts of time tracking down source code for a particular widget, or trying out properties and their visual effects in real time. Highly recommended.
It's kind of like FireBug for .NET rich clients.

Read Zain Naboulsi's excellent "Coding Faster: Visual Studio Tips & Tricks".

Personal Project Planning [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I want to design a 2D game idea with C#/XNA. Between school, project inexperience, limited resources, and other things that may cause me to bail on the project I am going to try to plan it out before I jump in:
What are some key aspects you've noticed in a successful personal project?
How did you (successfully) draw revenue the project (besides asking for donations)?
(Note: this is not the main purpose of my project but would be nice!)
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
How do you bring an abstract idea of a game and making into a real product. What tools do you use in your sketching and planning?
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?

What are some key aspects you've noticed in a successful personal project?
I suppose this largely depends on your definition of success. I consider a game project successful if:
It's fun. Enough that I want to play it after I've finished.
I learn something in the process of making it.
I actually complete the project, where complete is defined as having art, audio, and any other assets adequate for the style of game that I'm making.
It works under 'field conditions', rather than simply on my own machine/hardware configuration.
In my case, every project that I've considered successful has been one that I've done some serious planning on and committed to seeing through to completion. That's the biggest step for me to get past. A casual project that is the product of a bored weekend usually won't get finished.
How did you (successfully) draw revenue the project (besides asking for donations)? (Note: this is not the main purpose of my project but would be nice!)
Heh. Haven't managed this yet. But then, that hasn't been a concern of mine enough to do the work required to support it. Someone already mentioned the potential revenue from XBLA for XNA projects, which is a very easy avenue to success if your project is the sort of thing that translates well to the console. I've looked into it, but it isn't really appropriate for my projects so far.
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
Pen. And paper. I draw a lot of screenshots as guides and I'll usually have some kind of artistic theme in mind to go along with the gameplay. Rapid prototypes help here too; everything from making mockups of menus and various screens in a drawing program to making some simple interactive stuff in a throwaway project.
Write everything down. I take lots of notes and I've been known to have a laptop with notepad open on it sitting next to my development machine, to save me the trouble of alt-tabbing away from my code to type a quick note on what I'm doing. Some great ideas come out of the process of trying to make other things work and if you don't write it down, it didn't happen.
How do you bring an abstract idea of a game and making into a real product. What tools do you use in your sketching and planning?
Work iteratively as much as possible. I hate to sound cliche, but the whole agile model works really well for games. Start with that core 'fun' idea you have that inspired you to make a game in the first place and get that working in code. Maybe it's a single mechanic that you want to build puzzles/levels around or maybe it's more of a look/feel that you can capture in a single environment/level/whatever. Either way, if you can get a single example of it working right, it becomes a good check on whether the idea is actually viable and will likely give you some ideas of the different ways it can be implemented. That might seem kind of vague, but more specific advice would depend on any number of other factors (your choice of genre, audience, the specific ideas you have in mind, etc.).
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Peter Molyneux of Lionhead has said that he used to prototype all of his games with ascii art. If they were fun with that limited level of graphics, then they were worth continuing. While you might not be able to get that simple with some genres (and an ascii 3d shooter might be novel for it's own sake...), certainly worrying about finished art, audio, or other assets is something that can be saved for much later. In the end, if the game is fun to play, then getting an artist willing to work with you becomes a lot more trivial. I have, on many occasions, used copyrighted assets during my prototyping phase when I just couldn't stand to look at my own art any longer. Just be sure that you have anything like that replaced before you start distributing your project...
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?
Not sure exactly what you're thinking about here, but breaking barriers is what writing code is all about really. You're finding creative solutions to interesting problems. The web is a great resource for general knowledge, but in the end, it's your own time and perseverance that will create something interesting.
Best of luck.

What are some key aspects you've noticed in a successful personal project?
Don't worry about how it will turn out
Do it for fun
Don't plan it
Start small, don't think big
Actually code instead of procrastinating on so or other similar sites

If you want somebody else to use this game, make it non personal. Get somebody else who you can give demos to and get feedback from. Make the game very very simple. Build that first before moving onto something very simple. Then go for simple!
not sure :)
Plan with pen and paper sketches for window layouts and game flow. For look and feel, browse the web for slick looking sites you can take inspiration from.
Use notepad, and write the shortest list of things that need doing to make the simplest working demo. Only work on the things you wrote down otherwise you can get carried away on some detail and end up not producing anything useful.
Art is an important part of a game, and you can't have a finished product without it. How about searching the web for a collaborator who'd be interested in doing it for you.
If your stuck with something in your code, ask for help on StackOverflow! :)

Key aspects: Primarily, something that you are excited about. Make a game that REALLY gets you going, and you'll be motivated by your desire to share the finished product with others -- your end product's quality will probably be improved by your passion, as well.
Profitability: Well, since this is XNA and all, if you release a version on Xbox Live, you will earn 70% of the sales revenue that your game earns. Games can be priced for 200, 400, or 800 points (roughly $2.50-$10).
UI/Usability: For this, I typically go through a lot of playability testing...booting it up, seeing how things "feel," then tweaking things if they just don't feel right. I came across a lot of things that I never really thought about before (fade-ins/fade-outs for menus, repeat rates for keys, and so forth), and play-testing is one of the more effective ways that I've been able to identify issues like that. If you've got friends, you can ask them to give you feedback as well.
Planning Tools: Truthfully, I just make a list of the things that I want to include in the overall game concept, then slowly get more granular as I iron out more and more of the fine details. Certain ideas inevitably change after playtesting may reveal them to not be as fun as you had imagined they would be, of course. I haven't ever seen a huge need for any formal tools for this process, though, but I will give the disclaimer that all of my projects have been fairly small in scope and have not been professional-sized undertakings or anything.
Art: This may not always be an option for you, but I have a few friends online that are gifted with art skills -- I solicited interest, and got some volunteers. I presented the option to earn a cut of whatever royalties may come in, but most of them were happy with an attribution in the credits and a chance to see their work in a game that's playable by people all over the world. Regarding small things (icons, etc), stock/royalty-free art can do the job in certain cases, too, but I wouldn't recommend relying on it.
Breaking Barriers: Not sure what's quite meant by this question, but generally speaking if I've come up against some sort of unforeseen issue (technical/implementation challenge,
gameplay-related, or what-have-you), I'm able to either solve the problem or come up with a suitable work-around if I put my mind to it for long enough. Did you mean something else by this?

Some great thoughts given in these articles:
http://www.flatredball.com/frb/docs/index.php?title=Tips_for_Completing_an_Independent_Project
http://makeitbigingames.com/2006/06/five-realistic-steps-to-starting-a-game-development-company/
http://makeitbigingames.com/2006/02/five-foundational-steps-to-surviving-as-a-game-developer/

First of all - I know universities don't tend to teach this but you really must do it... get source control going. I would suggest installing TortoiseSvn from here: http://tortoisesvn.net/downloads
With TortoiseSvn (a subversion client) - you can create a repository on your USB Flash Drive and carry it around with you, so you always have a copy of your project files. More importantly you can have more confidence when you make changes - because it keeps a history of the changes you've made. So if you break something, you can revert to the most up to date version on your usb flash drive... or even an earlier version if you wish. It also provides ways of showing differences between file revisions, all from the explorer shell extension.
For a personal project the key thing is to keep motivated. You keep motivated by setting yourself attainable tasks. Aim for something attainable. Always make sure you can build your project. Concentrate on adding new functionality while keeping the old stuff still working rather than building up huge nicely designed framework that might end up going no where. If you write your code well, you can refactor and abstract later after you figured out what game it is you actually want to build.
I would advocate a todo list of some kind... something like the spreadsheet found here on Joels site: http://www.joelonsoftware.com/articles/fog0000000245.html
If you want to get fancy, I would suggest something like Trac: http://trac.edgewall.org/
Trac is a wiki, to-do / bug list and repository viewer all in one. If you get someone else working with you on a project, collaboration with source control and a shared wiki becomes more useful. It's also good to work with others... you can keep each other motivated.
The Wolf fire blog recently had some interesting design ideas and cited serval sources here: http://blog.wolfire.com/2009/02/design-principles-from-tufte/
As for getting money, others have already covered the community games thing.
Art assets - there are a few places to find these. Scout the forums at www.gamedev.net. Def look at this blog here for some excellent art (and game design ideas) http://lostgarden.com/
Others have suggested keeping tools simple - I would agree. The simplier and more accessible things are when it comes to project planning, prototyping and design - the more likely you are to use them. As long as you can communicate with yourself when you revisit something... or other people when collaborating, it's a good tool. Set yourself attainable goals, and get on with it :-)

What are some key aspects you've noticed in a successful personal project? Focus on something that actually works.
How did you (successfully) draw revenue the project (besides asking for donations)? Not directly. However, skills get you a job. Build skills.
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
Build the inside -- the core data model first. If the data model works, everything else is far simpler.
Build unit tests for the model to be absolutely sure it always works.
Work out "flow" and other control issues based on that model.
Build the GUI later, once you have a solid foundation.
How do you bring an abstract idea of a game and making into a real product? What tools do you use in your sketching and planning?
I do the following.
I use Argo UML for technical UML diagrams.
I write documents with my end-state in mind. What the API will be like. How it will work. As part of writing the documents, I clarify my thinking.
I write code in pieces, with unit tests, and refactor ruthlessly.
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Find an artist who wants to help.
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?
Build the inside -- the core data model first.
Spike elements of the technology separately from the main development. Build separate proofs of concept for each new technology. Do not try to integrate unknown technology into the final product. (Many of my customers try this and it doesn't work.)

Having had an experience with game development in my teenage years what I can suggest is the following:
Make sure you have the story ready, or at least the basic points before you start implementing. Also make sure that you do not change the genre of the game while in dev stage. (yeah, I know, this is stupid, but could happen ;-) )
We actually drew some revenue when we managed to sell the game to a software house, however because we had already spent too much in the dev process, we just broke even (i.e. to little profit). So be careful what you spend beforehand
From what you said, you're still in school, so take advantage of that. There will surely be folk out there with artistic talent, most probably friends of yours. Make a team. That's what we did and it was all the way back in 1993! At that time it was even harder. We introduced our talented friends to 3D-Studio (v3 back then) and some even to computers in general, and believe me, before you knew it they were making brilliant art out of it!
Use pen and paper to create the story boards (even better with the friends mentioned above. Decide on the development approach. I.e. what libraries will you use etc. Read a lot about game dev. Make a plan of the project. Give it your best ;-)
Unlike us back then, you have the web to help you. For whatever problems you have with your code it is easy to look it up. StackOverflow didn't exist back then!
And of course make sure you have fun in the process otherwise it will eat you alive!

What are some key aspects you've
noticed in a successful personal
project?
Just do it!