TheDarkTrumpet.com

“We can thus say that anger is caused by the discrepancy between what we expect and what we get.” – Source

This is a very similar quote that goes through my head that I heard elsewhere. The general idea is that when we expect something, and what we get doesn’t match up with what we want – we feel anger. Anger isn’t the only emotion that suffers this, though. Frustration, is very similar to anger in this sense. I’ve met a number of programmers who meet a situation in coding where the code they are looking at is not as they would have wrote it – they may not even understand it – but after some time (maybe even hours), they feel frustrated. Frustration is very common with large problems, but they don’t need to be.

First a bit of a story. I’m working at my 2nd full time job right now. In my first job, I worked with PHP code in a enterprise environment. My job was to maintain, fix, diagnose, enhance, and so on – the centerpiece of the main application. The only other person working on this was the lead developer. In an effort not to bother him too much – I took it upon myself to try to spend a lot of time trying to learn more about their programmer. In my 2nd job, the lead developer left, leaving a very difficult and complex project needing work done – so adjusting is the name of the game.

I want to go over a few different ways that I went about learning to debug, as some others coined – flashlight debugging. Generally speaking when you debug something you need to remember that while tools are just that – tools, don’t make it a crutch. A lot of my ideas are very very language inspecific and should hopefully make sense.

• Pretend you’re the only developer – It’s a hard thing sometimes not to want to just go up and ask for help on something right off the bat. The problem with this is that we need to be able to strugle about a problem for awhile to really understand it. Remember, you have the internet, books, newsgroups, and so on to help you out when researching it. The key part is help from another human – either through IRC, chat, or whatever..best to use it last, even if it saves time.
• Debug in your one place, and spread out – The problem with very large systems is trying to understand too much at one time. Some people feel it’s important to learn the entire system and then fix the specific problem. The problem with this methodology is that the system may be too complicated, and too little documented to bother doing that. Instead, focus on your one small area and spread out from there.
• Be sure to research

  - Check existing tickets in your ticket management system, look at the log of the file, who edited it and why (subversion, or whatever), read wiki articles on the business process, and learn about the problem you’re solving and not just the problem itself.

• Diagram and keep your own documentation – Whenever I start a problem that I feel will take a bit of doing, I usually will either use graph paper, or a whiteboard to diagram out my thoughts and needs. The key of this is don’t be afraid to go to multiple files, write stuff out, go to others write those out, and link them together. The diagrams may not be of use to others, but will be helpful for you. For your own documentation, I highly recommend your own wiki. Personally, I use emacs wiki, which is fantastic for keeping personal documents in. It’s easy and fast to come up with an idea, and note it down there as well. It’s an extra place to search, but it’s your own library. Little notes on links and ideas you find on the net can go in this as well.

The part that’s really important to keep in mind is that the world is rarely perfect, and neither is code. It’s easyto get trapped in the idea that code should be perfect, either in coding style or whatever. For some ideas I think that may help groups out are:

• Documentation in Code:

  Documentation is a tricky thing since too much documenting and it’s going to make the code harder to read. Too little documentation, and that’s not really good either. The “perfect amount” I’ve found is only in areas where you see that if you came back a month later that you may not understand what was done. Keep them simple, keep them short though.

• Document in SVN:

  Subversion is more than just a place to track changes, but also commenting what issue/bug/defect/feature you fixed/implemented will go a long ways toward making what you change match up with the official logs.

One last bit of advice I want to make is to approach solving a computer programming problem much like you’d solve a math problem. With a clear head, calm and collected – patience and diligent, write out the problem. Don’t be afraid of making mistakes, create new projects to test ideas and integrate them in. Break stuff, fix it up again, and break it again. Lots of learning comes from fixing stuff, and making mistakes. Don’t be afraid of making mistakes, use it as a learning opportunity.

Edit: I wanted to add a few resources that will possibly help out a bit.

• 43 Folders (Blog) http://www.43folders.com/ Basic time management, definitely worthwhile to learn about.
• Chapters 2 – 4 in The Art of Software Modeling – This book is fairly good from a system analysis standpoint to learn tips on how to debug code or to learn very complex systems. I’ve used nearly every method they described, and it works well. I don’t cover most of that information here, but the book is available on Books 24×7 to those who have access to it.

I wanted to discuss how to create a login-type app today. I’m working on a project for work and came across the need for a login page (well, and logout too). Now, while I may change this to the built-in method, I wanted to share the knowledge I gained in dealing with some oddities of the forms setup in general.

When you’re creating a login form, it’s generally best in my opinion to use the forms portion of Django instead of straight calls. It’s more DRY compliant, and you have a lot of stuff taken care of for you when it comes to the output. The problem I came across with was about data as it’s sent back.

So…I won’t concentrate much on how to use the forms setup (maybe I should create a tutorial maybe), but your general authentication setup may look something like mine:

def auth(request):
if request.method == ‘POST’:
form = LoginForm(request.POST, error_class=LoginErrorOverride)
if form.is_valid():
username = form.cleaned_data['username']
password = form.cleaned_data['password']
user = authenticate(username=username, password=password)
if user is not None:
if user.is_active:
login(request, user)
return render_to_response(‘auth/loginsuccessful.html’)
else:
return render_to_response(‘auth/logindisabled.html’)
else:
form.errors['login'] = ‘unsuccessful’ #Adds an error, so we can raise it later.
form.data = {‘username’: form.data['username']} #Clear our data, except for the username.
else:
logout(request)
form = LoginForm()
return render_to_response(‘auth/login.html’, {‘form’: form})

So this basically tries to keep as little logic as possible needed for the forms. I create the object from my forms class, check validation, then check login. If it’s invalid, or if it’s an incorrect login, I want to redisplay the login web page with giving them a try again.

The problem I had was that reloading the page meant that the password was entered as a “default field”. Now…in my opinion, the password widget really should somehow override this behavior because it’s absolutely stupid. For the most part, password fields should really never be outputted back to the user. That’s where the line:

form.data = {‘username’: form.data['username']} #Clear our data, except for the username.

takes care of the situation. I’m not fond of this solution, but it does work. The optimal solution is that for a password widget, we should have it automatically clear the data for us.