Don’t ask me why you find yourself working in ASP.NET. I know there are more effective ways to build a site.
Don’t ask me why you’re maintaining an app written in the style of 2005. I know, but it happens occasionally frequently.
Don’t ask me why your ASP.NET app is using the MembershipProvider system. I know it’s a poor match for the needs of almost all apps and encourages security holes by design.
Don’t ask me what reason could possibly explain needing to change some passwords. Why isn’t this functionality built in to the app? I know, I know…
But you’re there. Your app is using the MembershipProvider system, which saves the passwords in the database in some kind of encrypted form. And now you have to change some passwords quickly, probably for multiple embarrassing reasons, yet the app doesn’t offer you the functionality to do so, and you don’t have the time to add that functionality and re-build and re-deploy the app.
If only it were possible to go into SSMS and change the passwords using only T-SQL.
The intent of this article is to approach development and debugging of Ruby on Rails applications from the perspetive of a C++ developer. In Part I I discussed some of the fundamental differences between Ruby on Rails and C++ development.
I started a simple "blog with comments" example to step through and showed how to use the ruby console to debug the model and what some of the exception messages returned to the view are telling us.
Where are the exceptions?
While we know the model is right (we debugged it already) sometimes there is no exception information being displayed. Where do we turn then? In this part of the article I am going to expand on our example and go deeper into what to look for there are no meaningful exception messages.
If you already know why C++ and Ruby on Rails are fundamentally different and just want to see the example, you can skip to The Example.
I’ve been developing software for many years but, for the most part, have stayed in the C++ world. I made the transition to web applications development with C# ASP.NET MVC applications, which I felt is a fairly easy transition. Adjusting to the MVC design pattern took a little change in thinking but it’s not a terribly difficult pattern to understand. It’s been a few years now and I am quite comfortable in that world.