Run the program and see if it crashes

I don't have a lot of patience for constructing test cases when it comes to testing my code's functionality. When it comes to GUI-oriented applications, my preference is to run the program and see if it crashes (or behaves in some way contrary to what I had intended). At which point, I would go to whichever section of code is most likely the offending code and get trigger-happy with the logging statements.
This may not be the most effective debugging method for some people, but it has largely worked for debugging my Android apps. "Largely worked" because every now and then I'd have a bit of code that looks like it would  work in the way I wanted it to, but doesn't.

Improvements in debugging?

Is it a sign that you're becoming a better programmer when you notice that you're relying more on error logging to tell you what's wrong with your code, instead of trying to brute force a solution and raging about it when you can't figure it out?

I've only ever encountered one error logging framework before: log4net. I started using it at work when the team wanted to convert the their old error logging framework over. To be fair, log4net was a bit too complex for my liking.

I only started to take error logging a little more seriously when I started learning Android development. I started doing databases a few weeks into Mobile Applications Development - we weren't scheduled to learn it until week 5. It only when I hit a snag in incorporating a database into the class exercise for that week, that I finally began to see the value in using error logging.

Error logging

It was only recently that I started to take the whole debugging process a little more seriously.
Before that, I used to brute force solutions to my programming woes. This wasn't exactly the best approach, in hindsight.
Maybe it had something to do with the Mobile Apps Development tutor nagging us about using logging to check that our code works.
That leads to the question of: what is the most effective approach to error logging?
Getting trigger-happy with the logging statements? Or just putting them where the code looks like it needs to be monitored?
My personal approach was to only put the statements where I thought the code looked like it needed to be watched.
For me, logging statements tell me more about a piece of code than setting breakpoints and stepping through the dodgy code.

C#: Read a file in reverse

Here is the method I use to display a file's contents in reverse.

// The declaration of the list object should specify that it is a list of strings but Blogger won't let me type in the angular brackets
List list = new List();
// Replace filePath with the full path of the file being read from
StreamReader read = new StreamReader(filePath);
while (!read.EndOfStream)
{
   list.Add(read.ReadLine());
}
read.Close();
list.Reverse();

My foray into WPF Development

Late last year I came across WPF when I was working on a work project. I found out pretty soon that WPF wasn't suited to that particular project, as the WPF framework doesn't  have an equivalent of the DataGridView (not that I know of anyhow). So I ended up using Windows Forms.
Now that I'm not studying anymore, I've got a bit more time to experiment. I'm trying to make a simple calculator in WPF. Not the most original of ideas, I know. But its one of the safer options for learning a new language that I know of.

This is what the calculator looks like at the moment. One thing I'm loving about work with WPF is no messy "designer" code that one gets with Windows Forms applications. The only "behind the scenes" code one will ever deal with when working with WPF is the XAML code itself. Having the GridPanel also makes designing a consistent layout a lot easier because I don't have to fiddle around with the C# code as much. The downside to this that I've discovered so far is that one cannot add controls programmatically like in Windows Forms (i.e. via C#). I think I can see one reason why WPF wouldn't support controls being added programmatically: you can't have oddly-sized controls (see picture) if you're adding your form controls with an for loop.
In case you're wondering how I got the buttons to "fill" the cell, I simply didn't specify a height and width and just set the Grid.Row and Grid.Column property for the button. In the case of the "0" button, I also set the button's Grid.ColumnSpan property to 2.
Anyhow, back to the programming lab for me.

Programming languages to date

VB .NET
This was the first programming language came across (if I recall correctly). I learnt how to program in VB.NET through a combination of Home & Learn's tutorials and following examples in a reference book. It was a good beginner's language, in a way, as its syntax closely resembled the English language. Looking back, VB.NET got me into a lot of bad programming habits. *cringe*

Java
Java was the first language I had any formal instruction in, as it was the language that Programmming Fundamentals worked with. I remember that I struggled a fair bit with the syntax because it was completely different to VB's. But in the end I enjoyed it a fair bit and even managed to get a Distinction for PF.

C++
I started learning C++ as part of Data Structures and Algorithms. The language was a complete and utter nightmare. The syntax was the main thing that cheesed me off. The lecturer I had for DSA, whom I shall only refer to as the "Toadmaster", only exponentially increased my dislike of the language. After that particular semester, I thought I'd seen the last of C++. But no, Introduction to Computer Graphics used C++ as well. The lecturer for ICG did almost exactly what the Toadmaster did where C++ was concerned.

C#
I remember I started experimenting in C# during the holidays sometime last year. I developed an interest in it upon hearing that the syntax was a cross between VB.NET and Java. Again, I took to the Home & Learn tutorials to 'learn' the basics of programming in C#. As I grew more comfortable with the language, my experiments became more adventurous. At one point I developed a Pokedex application that used a database. One used SQL statements to search through the Pokedex (which was in National Dex mode). I think it was kind of lucky, in a way, that I acquired an interest in C# because I work with the language on a daily basis in my cadetship.

Introduction to Computer Games Programming: a semester of hell

When I took up my cadetship, I decided I was going to keep only one subject. Which subject did I keep? Introduction to Computer Games Programming. I enrolled in the subject to begin with because I honestly thought that I was going to be learning about the basics of games programming. I never imagined that I was going to be dealing with an inconsistent subject. Instead of focusing on games programming for noobs, the lecturer drones on for an hour every Wednesday night about advanced physics concepts that are largely beyond the understanding of 80-90% of the lecture room, polished off with a demo of some obscure games programming concept. If that isn't enough, he neglects to put up the dropbox for the last assignment (which accounts for the largest part of the final mark). (I checked just a few minutes ago and still no loving dropbox)
You could very well envision my joy when I got around to filling out the Student Feedback Surveys. *cue evil laugh*

Latest programming project - remake of Collapse

I rather liked the original online game, so I decided that, for my latest programming endeavour, I would re-implement it in XNA. I think I have the "grid" drawn correctly; now I need to get the scoreboard drawn. After that I can focus on the game logic. In theory, it's quite simple: click a block and check if it is part of a chain of 3 or more. *sigh* Logic is not one of my strong points.

End of ED.NET

Just got home after the ED.NET exam. I thought it went alright. I am a trifle annoyed at the institution's insistance that all students remain in the exam room for the first 90 minutes and the last 15 minutes.