Category Archives: Programming

Top 10 C# 6.0 features – external link.

Check em out!
http://www.developer.com/net/csharp/slideshows/top-10-csharp-6.0-language-features.html

I like #9 the best for null ref exception protection ūüôā

Advertisements

Debugging multithreaded or recursive operations

Hi all.  I hope everyone is making their day great. I had a scenario where the Watch value of an expression was valuable to see during the recursion of a function. I had a recursive SolveSolution function and it worked with continuously getting the next empty cell and plugging in a trial value in that to see if it was a legal move.

The Parallel Watch window is a great tool in this manner. You can add several watches and they each go in as a column value.¬† Here’s a screenshot to follow along into the recursive method. Take note of the Recursion Depth value as well.Parallel Watch window

Using the output of this tool, the application bug that I’d remaining¬†was a lot easier to resolve and resulted in a quicker resolution. Hope this helps!

References

MSDN –¬†How to: Use the Parallel Watch Window
MSDN –¬†Walkthrough: Debugging a Parallel Application
http://www.dotnetcurry.com/visualstudio/994/debugging-parallel-code-visual-studio

Sharing repros online for code or database

I recently learned of¬†the site http://dotnetfiddle.net from a past coworker, and think the idea is awesome. It’s so cool to be able to code from a mobile phone if an idea comes to mind at a random place or time.

Now today, I found something equally as cool!
http://sqlfiddle.com/

Check ’em out if you didn’t already know. Wow, that’s so exciting and useful for repros.

Striking a balance with Test Drive Development (TDD)

I’ve been working with TDD for about 3-4 years now, and I still feel like it’s a wild-animal to tame. What I mean is, I have to keep in mind to strike a balance: write enough failing tests, one by one making them pass with logic pieces, and two: test only the basics and do your best to mock out other components and isolate their behavior from the test.

I do love it for the testing logical components of a solution and especially for embracing failure first and putting logic in place to get success.¬†From a¬†productivity-viewpoint,¬†I would say generally using it only for mission-critical code and libraries, but not other areas that are more throw-away or don’t have workable test areas (small UI apps without heavy logic). I hope to come to understand the value in UI unit testing as I get deeper into MVC. Note: I haven’t been on the UI side as much in the past 5 years, and I gotta say, I’m missing not having some impact to the world in that way.

Others out there, what are your experiences with TDD and how have you overcome the challenges of avoiding testing the same thing over and over between tests?

What I appreciate in a software program

The perfectionist in me says: Well structured, elegant code, that works flawlessly to meet all of the user’s feature wishes without bugs. ¬†But that’s extreme perfection, and we can rarely reach that point. Not every code file of an¬†app’s code base is going to be¬†robust, but such are the down-to-earth time limits of life ūüôā

The better answer is my¬†realistic side: An app that first does what users need it to do, leaving out unnecessary features or ones that take too much time for their value, and depending on the estimated lifetime of the code base, that it’s appropriately structured into services, layers, and classes.

Now over the past 13 years, with the hundreds of small-large features and apps that I’d created, I’ve had about half of them (apps, reports, and db procedures) that I’m very proud of because they meet the above high standards, and others that I’m also proud of despite meeting those elevated expectations, because of useful¬†features¬†I helped add that benefited the end users and/or how stable the system was.

Examples of perfection based apps were ones that were on the smaller scale in size. Dealing with saving permission to a database, reports, or processing a small about of payments, stuff like that.

The ones where I had and continue to have to be more of a realist for are medium to larger apps where the payload and object graph was larger is where things got complex, as there were a lot of moving parts. The team I was on¬†had made the program operate as needed together. Some features¬†didn’t go out exactly as scheduled, but the best part was the most critical features were pushed out first, as they could be, and it helped the users get a starter of using the app and also able to report any remaining issues outside of dev or qa departments. I’ve moved away from my last position of 7 years as a Services and Database developer to be in a new¬†IT environment to stimulate my mind, and solve business problems via software with users, and am pretty excited in this moment for what¬†good things the future brings.