If you are using ASP.NET, especially if you are using ASP.NET MVC, you need to be using Glimpse.
What is Glimpse?
Perhaps you haven’t heard of Glimpse yet, or you are just a little unsure of exactly what it is.
Glimpse is basically an open source and free diagnostics platform for the web. Right now it works best with ASP.NET and especially ASP.NET MVC, but it can be extended to other platforms as well. There is already work started for a PHP version and even a Python port.
Out of the box, Glimpse can show you all kinds of information about your MVC application, like what routes are registered, what the flow was through the MVC pipeline and how the models were bound.
(BTW, if you are looking to brush up on your ASP.NET MVC 4 skills or learn about ASP.NET MVC 4, I recommend Professional ASP.NET MVC 4. Great book, top notch authors.)
Here is what the Glimpse window looks like on a page.
Glimpse is also fully extendable.
There are already plugins for Entity Framework, NHibernate, Ninject and many, many more
The best part about Glimpse is how easy it is to get setup.
I’ll walk you through the steps below.
Step 1: Get Glimpse from NuGet
All you have to do to get Glimpse installed is simply either:
- Open up the Package Manager Console and type “Install-Package Glimpse.Mvc4” (or “Glimpse.AspNet” if you aren’t using MVC)
- Or, right click on your references, select Manage NuGet Packages, then search for Glimpse and find the appropriate Glimpse package.
One you’ve done that, Glimpse will automatically add a few entries to your web.config for you.
Step 2: Turn on Glimpse
Turning on Glimpse is super easy.
Just launch your app and navigate to glimpse.axd. Then, click “Turn Glimpse On” to set a cookie that will tell the Glimpse component running on the server to send you Glimpse data.
Go to glimpse.axd
Turn it on!
It’s that simple!
Step 3: Fire it up
Now all you have to do is navigate to any page in your application and you’ll see this little icon at the bottom right hand corner of the screen:
If you click the icon, you’ll see the Glimpse panel, which currently looks similar to the Chrome Dev Tools panel.
Each tab contains different diagnostics information about your application.
This data can be extremely helpful in troubleshooting problems and learning about exactly what is going on inside of MVC.
You can also find plugins that can be easily installed from NuGet.
For example, if you add the Entity Framework plugin, you’ll start seeing a tab that shows data about EF queries, like this:
I’m pretty excited about Glimpse and its future. Anthony van der Hoorn and Nik Molnar, the two creators and main maintainers for Glimpse, have done an excellent job transforming how we get diagnostics information for web applications.
One of the things I find most exciting about this platform is how easy it is to extend.
In my upcoming Pluralsight course, (the course is now live!) I walk you through creating a Glimpse plugin, which is surprisingly easy.
So if you haven’t checked out Glimpse, what are you waiting for? Go do it now, it will take you about 5 minutes to get setup.
What do you think? Are you using Glimpse already? Post a comment and let me know.
My YouTube video for the week: (This is not an ad!)
And here is the weekly Get Up and Code episode:
Today I want to talk to you about a serious mental disorder that affects far too many programmers.
The symptoms of this disease are many:
- Frantically saying “It’ll work this time”
- Randomly adding +1 and –1 to integers
- Inability to see the forest
- Irrational paradoxical statements like “I am sure this is impossible, but I don’t know how it is happening.”
- Spitting at hamsters
- The list goes on…
What I am talking about is the debugger mind set and…
It is a mental disorder
So what is this debugger mindset I am talking about?
It is more than just overusing the debugger, it is thinking and acting in a way that is the same way one tends to think and act when they are stepping through code in the debugger.
I am guilty of it as I imagine many of you are.
And it is a disease.
A debugging tale all too familiar
Picture this… You are just about to check in the final piece of code that you have been working on all week for this awesome feature you are developing and something is wrong.
It is just not working. You can’t figure out why. The behavior of the code seems to defy all logic.
You set a few break points and start stepping through code. (By the way it is 4:00 on a Friday and you were about to check in this code and go home a little early, you deserve it.)
Step… step… step… Check this variable… Check that variable… Evaluate this expression.
Nothing, no clue as to what is going on. You are beginning to sweat. The release is going out on Sunday. You need to get this fixed or the code can’t release.
You look at the clock. It is now 5:03. You glance at your phone and see you have a text from your wife. No time to look at what it says. You are intensely focused. You must solve this bug.
Step… step… step… Check this variable… Check that variable… Evaluate this expression. You begin to sweat more.
You can’t understand why this one little thing isn’t working. It is driving you nuts, it doesn’t make any sense… You start scratching at your head in frustration.
Time ticks by, it’s now 6:30. Your phone rings, it’s your wife.
“Did you get my text? When are you coming home? It’s Friday. It’s the weekend.”
You fumble to get to your SMS program on your phone. You don’t have time for this, you must SOLVE this bug, now! Grrr, you are getting angry and irritated. You try and hide it, but it comes through in your voice.
You’re thirsty, you’re hungry, your eyes hurt from not blinking. You’re tapping your foot like a madman intently focused on the keyboard. It’s now 7:40.
You start frantically changing variables. You’ve lost track of what the code is doing now, instead you’re just watching values in your watch window. It’s getting hard to think, minutes turn to hours.
You finally solve your bug at 11:03 PM, but your nerves are shot. The taste of victory is soured like milk left too long in the fridge. You can taste the chunky curds in your mouth as you think about how even though you fixed the problem, you still don’t understand why your solution worked or what was causing it.
It is very important to avoid this pattern of behavior
And it can destroy your productivity like nothing else.
You don’t actually have to be in the debugger to have this mindset, even though it often occurs when you are.
All developers are susceptible to it. I know I have spent my share of time thrashing around with it. It takes a fairly simple 1-hour-to-solve-problem and makes it take 8 hours to solve because we try to solve it in 5 minutes.
Very few things in life have a 5 minute solution.
When we start thinking this way, we lose all ability to think rationally and actually solve a problem. Instead we start zooming into symptoms and using frustration instead of wit.
This kind of mindset can put us into a downward spiral of burnout and insatiability. We end up wasting time and losing focus. It is the most frequent time in my career when I have made stupid mistakes.
How to avoid the debugger mindset
The is a perfect storm of conditions which tend to cause this kind of a mindset, mix and match these as you will:
- A looming deadline (self-imposed or otherwise)
- Large chunks of almost complete work that can’t stand on its own
- Being in a hurry and looking for a shortcut
- Believing a problem is probably simple
- Believing a problem is probably hard
- Jumping to the debugger too soon
- Being at the end of a marathon session
- Not taking enough breaks
There are many other conditions of course which can contribute to this mindset, but these are some of the ones I find most common. It can only take a few of these in combination to really push you over the edge into no man’s land.
Avoiding the debugger mindset can be as simple as trying to eliminate as many of these precursors as possible.
Here are a few tips I have found to directly counter this list above:
- Don’t impose deadlines on yourself and try to ignore unrealistic ones that are imposed on you. Instead try to focus on doing a good job and being productive. You are much more likely to get fired for being in the debugger mindset and making a stupid brainless mistake than for taking a bit longer to accomplish a task or having to tell your boss that you cannot in good conscious commit to a deadline. Never forget that software development is always going to have a huge “unknowable” factor to it. No one can blame you for that and it is not your fault.
- Try to commit as frequently as possible and divide your work into very small tasks. Smaller is better. Also try to split work vertically rather than horizontally. This means trying to implement a feature in terms of small working pieces that work end to end, rather than trying to implement all the functionality in a single layer at a time.
- There are no shorcuts in programming. When you need time take it. Don’t forget to take time to quietly think about a problem. Quiet contemplation is work. It is not slacking off. Take a walk if you need to. Ask for a second set of eyes before you get into panic mode.
- Do not make an assumption about a problem until you understand fully what the problem is. Don’t tell yourself it is easy, don’t tell yourself it is difficult, instead refrain from making a judgment call until you have enough information to do so.
- Don’t prematurely go to the debugger. Always try to solve problems without the debugger first. Once you have gone to the debugger, you are much more likely to get sucked into the debugger mindset. If you do need to use the debugger, always have a hypothesis of what the problem is and use the debugger to confirm or deny it.
- Do not use the debugger to help you understand what the code is doing. Instead use unit tests for that or refactor to make the code clearer. Divide and conquer the problem into a series of branching hypothesizes. Use the debugger only when necessary to confirm or disprove a hypotheses and then form a new one and repeat all the while remaining calm and understanding that you don’t know how deep a rabbit hole is until you go down it. (This StackOverflow question points out a fairly extreme view of what I am saying here, but I tend to agree with it more than I disagree with it. I won’t say never use the debugger, but I will say that I myself use it too much and jump to it too quickly.)
- Take breaks and don’t work on the same piece of code for too long a period of time. As stated above, break your tasks into smaller tasks so that you are always near a checkpoint. If you are feeling frustrated, take a 5 minute break to clear your head and regain your focus.
What do you think? Have you ever been in the debugger mindset? What are some ways you avoid it?
As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple. Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week. Also, you can follow me on twitter here.
I’ve spent a good deal of my programming life “spinning my wheels.”
I don’t like to admit it, but I have spent countless hours trying to solve problems I didn’t fully understand.
When you sit there trying to fix a defect or solve a programming problem without first reproducing it you are like a bicycle thief hopelessly spinning the dials of a combination bike lock hoping to stumble upon that magical combination.
It is a common ailment after all
Don’t worry you and I are not alone, many programmers share the same kindred spirit of overeager rambunctiousness of trying to solve problems before they know what they fully are.
It is perhaps ones of the greatest killers of productivity and conflagration of the nerves of programmers both experienced and in-experienced.
I’ve learned this lesson a dozen times, but I learned it again this week as I was working with Jesse Taber. We recently instituted a remote pair programming program at my work, and I had the opportunity to pair up with Jesse this week.
See Jesse is the kind of programmer that pretty much always reproduces a problem before working on it. I thought I was pretty good at doing this and insisting it be done, but after working with Jesse I found that I tend to be a little more lazy in this area than I should.
It seems pretty basic, but most of us don’t do it
Most of us tend to jump right into a problem. Dive right into the code without completely understanding what we are up against.
I don’t know how many times I have attempted to solve a problem only to find that the actual problem was not reproducible at all.
A decent majority of problems that we try to solve either are not problems at all or are not anywhere close to the description of the problem we had been given.
I’ve definitely learned that taking that hour of time upfront to properly set up your environment and actually reproduce the problem shaves many hours off the time it takes to solve the problem and verify your solution actually works.
Sometimes problems can solve themselves
It is amazing how when you follow this simple advice problems have the seeming ability to solve themselves.
I’ve found many times in working on a difficult problem that the very act of the reproduction of the problem points to the actual cause.
When you think about it, it makes perfect sense. In order to reproduce a problem, you must cause the problem. If you have caused the problem, you may be able to identify the particular thing you did that caused it.
Sometimes it isn’t that easy, but reproducing the problem is still a great place to start. After I have reproduced a problem, I often find that I can divide and conquer that problem by breaking it into sub-problems.
This technique is very similar to basic troubleshooting. We follow steps that go something like this:
- Reproduce the original problem
- Break apart the problem by determining if any aspects or symptoms of the problem that was recreated can be recreated in isolation
- Once we have a small enough problem to solve, start taking away steps and elements of the recreation of the problem until we have the minimum set of of criteria required to create the problem
- Come up with a hypothesis of the cause of the problem (not the solution), change the cause in the simplest way possible to prove or disprove the hypothesis (many times this will not involve changing any code yet)
Let us make a pact
Let’s hold ourselves to a solemn vow of never again trying to solve a problem before we can reproduce it.
Don’t just take someone’s word for it anymore. Stick your head in the sand like an ostrich and refuse to believe there is a problem until you can see it for yourself.
What do you think? Have you ever tried to solve a problem only to find it does exist? Have you wasted hours of time trying to solve the wrong problem or randomly twiddling bits?
Oh, and if you are in QA or ever write up a defect. This pertains to you also, because you should realize that the most important part of a defect is always the steps to reproduce. A defect that cannot be reproduced is only noise, it cannot be solved, because the solution cannot be verified.
As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple. Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week. Also, you can follow me on twitter here.
You may be wondering what happened to my usual Monday post.
Well, I was having my head rearranged by JQuery. I have to admit, I am pretty late to the party. I haven’t really been using JQuery at all the past few years.
I missed a lot.
Goodbye type safety
This part scares me a little bit. I already made a few typos that were pretty hard to detect.
But, the trade-off just might be worth it.
What we are losing in type safety, we are making up for in productivity and speed. It is really fast to manipulate a page using JQuery and to hook up events.
Perhaps some kind of Script# / JQuery bastard child?
I like the functional thinking paradigm. One of my co-workers was saying that he likes JQuery because it helps him to write Lamba expressions and LINQ queries. I tend to agree with him.
I’ve said it before, but I believe the next high abstraction of programming is thinking functionally.
So many pieces of code that I would have used code generation to produce in the past, I can now produce with Lambda expressions.
It’s not all roses
Bleeding all the way through the stack
The downfall of this is that it is a very leaky abstraction. Abstractions are good because they allow us to think at a higher level.
Leaky abstractions are bad because they force us to context switch from a higher level of thinking down to a lower level.
Think for a second about all the “languages” or technologies you have to know to develop an ASP.NET web page using JQuery and MVC.
- ASP.NET MVC
- C# or Visual Basic
- Web Services / Rest
- HTTP (You need to be able to debug all the coolness you are flinging back and forth.)
When you have it all working, it is pretty slick. Very slick indeed, but it is not a sustainable model. It is complex and sprinkled with errors and gotchas.
Debugging / readability
When I am writing JQuery, although I feel like it is magical and cool, I also feel a little bit dirty.
Well, as clean as you try to write JQuery code, it can be pretty nasty. There is a lot of magic going on and it is not very easily understandable.
Perhaps I’ll get better at expressing my intent clearly in JQuery code, but I am pretty sure it has to due in part with the leakiness of the abstraction layer, and that can’t really be cleaned up easily.
Debugging is also hell. I tried debugging through the validation library to see why my error messages weren’t showing up, and it was no picnic.
One of the things I really enjoyed while writing JQuery code was putting the view logic where it really belongs. It is nice to have a language and a server separating the view logic from the model and presentation.
JQuery really allows you to put all the code that manipulates the view in one place, and on the client side, where it really belongs.
JQuery will make your HTML code so much cleaner and helps to actually plug the leaks in the HTML abstraction layer. (Although it isn’t perfect, especially when working with ASP.NET Web Forms.)
Better late then never at all
So I know I’m really late to the JQuery party, but I’m here now and I am liking it.
Overall, I’d recommend taking a look at JQuery if you are like me and hadn’t really used it until now. It definitely is a valuable skill to develop and is growing at an extremely rapid pace.
You know those tests you like to run? You know what I mean, those test cases that always give you a green bar and never fail?
If you are having a bad day, and you feel like nothing is going right, you can just “right-click” run and you get a nice 100% passing green bar. It is easy to refactor the code those tests are testing, because you know in your heart that no matter how much you change the code, those tests will always pass. What a great feeling. Doesn’t that make you feel like the king of the world?
I like to call those tests Ego Tests, because they are the equivalent of code flattery. An Ego Test always validates you. It tells you your code is pretty when it really has a fat butt. The Ego Test says “you can do nothing wrong.” The Ego Test says that “everything is going to be ok.” That is until you roll the code out to production and everything breaks. Then when you look for the Ego Test, you realize his message of “GREEN IS GOOD” is still blaring at full volume in an endless repeat cycle, like a mantra, or one of those self-hypnosis, “you can quit smoking” tapes. He is not really your friend; he is just a recording stuck in an endless loop. He won’t help you fix your bugs, he won’t even tell you they exist.
He must be stopped!
Identifying the Ego Test
The Ego Test can be any kind of test from unit test to automated functional test and more.
The Ego Test is identifiable by one or more of the following characteristics:
- Does not contain asserts.
- Contains asserts which only assert on conditions which are always true such as: assertTrue(isJohnSonmezCool?true:true);
- Asserts on things which are not related to what you are testing.
- Catches exceptions and eats them so the test will not error out.
- Tests things through a mock, but then does not assert the mocking expectations are satisfied.
- Never fails, no matter what you do to the code.
You would think from this list it would be pretty easy to stop and catch an Ego Test. It is not always so easy. Many Ego Tests appear to be testing the right thing, or seem like they could fail even though they can’t.
One quick way to figure out if you have an Ego Test is to change the input to the test and see if it fails. If you think you are looking for the word “Blue” in a drop down, and you change the HTML being tested to not contain the word “Blue” in the drop down, and if the test still passes, you have a problem.
Avoiding the Ego Test
The Ego Test is fairly easy to avoid. The best way is to make sure your test will fail when you change the input. Most of the time you can do this by changing the source code temporarily to produce a result which should be a failure. Sometimes though, you don’t have the ability to change the source code or doing so would be more work than it is worth. In those cases, you can change the test instead, to test for a condition which should not be true. Be very careful here though, many people are tripped up trying to validate tests the second way because they simply invert an assert statement.
For example, if you have an assert that is
and you try to verify the test does not always pass by inverting the assert to produce
Well, that is just plain dumb. But I have seen it before. Of course it will now fail.
What is valid is to change the assert to be something like:
When you know that “Green” should not be in the drop down. If the test still passes in that case, there is something wrong with the dropDownContains method, or some other assumption you are making about the contents of the data you are testing. Perhaps you are testing the wrong drop down control? Perhaps something else is wrong.
One more tip on avoiding the Ego Test: know what you are testing and test only one thing. If you are writing some code to increase your code coverage and the best name you can come with for the test is the name of the method itself followed by the word “test”, you have no idea what you are actually testing. 100% code coverage is pretty easy to get in unit tests when you aren’t actually testing anything.
By the way, the official name of this kind of testing is called Mutation Testing. I am not sure if it is completely necessary to do full mutation testing on your tests if you actually follow the advice I give to avoid the Ego Test in the first place, but there are actually some pretty cool mutation testing tools out there. One I know of for Java is called Jester. It will randomly change your source code and run all your unit tests. Jester then reports which tests still passed after changing your source. Looks like there is one for C# called Nester. If you know of a good updated one in either language, be sure to let me know.
Disclaimer: This post doesn’t apply to Chuck Norris. Chuck Norris’s tests look like ego tests in that they never fail, but they don’t fail because the code actually changes to conform to the perfect will of Chuck Norris as indicated in his tests, not because his tests are not testing the right thing.
I frequently find myself in the position of having to write fairly complex SQL queries in order to get a list of data that matches a certain criteria. One problem with complicated SQL queries is that it is very hard to know if the result you have is correct, especially when your query involves multi-table joins and sub-selects. Often, a small error in one part of a complex SQL query can go unnoticed because it doesn’t greatly change the count of the results.
Unfortunately, sometimes there is just no way to make a simple query to achieve a certain result. Often, a large amount of the information applied to the data in order to create the query requires outside knowledge that is not found in the relationships directly specified in the database. In situations like these a solid technique for verifying the results of the query is important.
SQL checking SQL
I have started using a technique of approaching a query from two different directions in order to check my results. The idea is that if you can think of more than one way to get the same set of data you are looking for, and each way returns the same set or results, the likelihood of that data being correct is greatly increased.
There was a scene in Apollo 13 where Tom Hanks manually calculated some trajectory and 3 guys in Houston all checked his math to make sure it was correct. When they all came up with the same answer, everyone could be pretty sure the calculation was correct.
That is the idea behind SQL checking SQL. If you can write a second query to get the same data, but from a different angle, there is a pretty good chance that the query is correct. The best way to do this would be to have another person write the second query, knowing nothing about how you are doing the first.
A Practical Example
Sounds good, but how can I actually use it? Let’s say that you have a database which stores job applications and resumes from applicants. Let’s say that you want to create a list of all the applicants last week.
We could approach this problem from two angles.
- Get a list of all the people who had an application where the application date was last week.
- Get a list of all the people who had a resume created.
We have to use some outside information here. We have to know that in our particular program each applicant for a job can only have one resume submitted and they must have one submitted. Then we know that we should see the same list of people who applied for jobs and had resumes created in that time frame.
Of course this is a really simple example and given all the conditions it would be easy to be pretty sure of either of these queries without running both. The problem is when you have a much larger set of tables you are interacting with and shakier sets of relations between the tables and data.
Tips and Tricks
Once you have created both queries to get the same set of resulting data, how can you easily check to see if they contain the same data? The easiest way is to do a difference in SQL. Depending on what flavor of SQL you are using, the syntax is slightly different. You can look up the set operations for your flavor of SQL. Difference is the opposite of union. Difference allows you to see what records exist in the first query and not the second. I like to use difference with the 1st query first and with the 2nd query first, so that I can see what records are in either query, but not in the other. Any records I find, I closely examine to figure out why they are in one and not the other. Each time I do this, I then makes changes to the query that was wrong until all the results match exactly.
This balancing of the two queries helps to highlight problems that could be missed from either viewpoint of the problem. After balancing out both queries to have exactly the same results, there is a really good chance the results are correct. Certainly the chances of your query being correct are increased vs “just winging it.”