2,323 reputation
623
bio website erraticdev.blogspot.com
location Slovenia
age 40
visits member for 4 years, 8 months
seen May 25 at 18:12

I'm an analyst web developer and development consultant on Microsoft technologies. My main focus is in Asp.net MVC, CSS3, HTML5, Javascript, jQuery, C#, and T-SQL. I'm a contractor by nature working around EU.


May
12
awarded  Citizen Patrol
May
4
revised What if the client needs the ability to retrieve passwords?
added 31 characters in body
May
4
comment What if the client needs the ability to retrieve passwords?
@sharptooth: I know you're right. Sometimes one thinks of extreme measures when approached with such a stupid upper management. I wouldn't do it myself either. But to convince this boss I might do it in front of him and try to logon to some site. Just for the proof of concept so he would be convinced. But smart person would stop being so stubborn when telling him all these facts. One answer was particularly interesting that talked about selling info.
May
4
comment What if the client needs the ability to retrieve passwords?
+1 for sell data.
May
4
revised What if the client needs the ability to retrieve passwords?
added 870 characters in body
May
4
comment What if the client needs the ability to retrieve passwords?
You could of course log in as the stubborn boss that can't be convinced about security threat and do something overly stupid just to prove him what could happen. Do something that will not hurt business but will act as an example of security and much harder way of tracking who did it. Try to do this from his computer if you can as well. So you can't be tracked down. Or from some admin's machine that thinks the same as that particular boss.
May
4
comment What if the client needs the ability to retrieve passwords?
Yes private keys should be on admin machines (behind firewall), or even better if they are on USB keys that only Admins have and personally use. But they shouldn't be allowed to take these keys home, because they could get stolen.
May
4
answered What if the client needs the ability to retrieve passwords?
May
4
comment What if the client needs the ability to retrieve passwords?
Please provide the web address of this application, so we can take a look at those accounts ;)
Apr
15
comment Classic ASP to ASP.net or ASP.net MVC
Routing is more natural and easier to understand than the state-full-ness implementation and inner workings in WebForms. WebForms abstract too much away. Asp.net WebForms were developed to make a smooth transition of primarily desktop developers to start writing web applications. They were exposed to the same event driven model and full state of the page. Asp.net MVC on the other hand was written with web developer in mind (Classic ASP devs are full web devs). No transitions (ok.. there was one... testability, but it doesn't have so much to do with app architecture).
Apr
15
comment Classic ASP to ASP.net or ASP.net MVC
+1 This is a very good question JPReddy. I've never had such a long time lapse on any of my projects so I can't even think to imagine your problem.
Apr
15
comment Classic ASP to ASP.net or ASP.net MVC
+1 for recomending MVC. It would definitely be a much much easier transition.
Apr
15
comment Classic ASP to ASP.net or ASP.net MVC
I would strongly disagree on the MVC statement. I think Asp.net MVC would be a much better transtion path than web forms. Heck you could use existing pages to post back to Asp.net MVC controller actions if you wanted to. And model bind to strong types as well (gaining server validation automagically). This kind of thing would be second to impossible using WebForms. The good thing is if they're versed in Classic ASP it will be much MUCH easier to step up to MVC than WebForms. MVC is suited to HTTP protocol just the way the old ASP was, Webforms on the other hand are not. Not at all.
Apr
4
revised How to code on a very tight schedule?
added 729 characters in body
Apr
4
comment How to code on a very tight schedule?
If this project has been chaotically going on for three years I suppose the tech dept phase is going to be few months long. They should first stop developing new features solve 20% of most problematic issues (because 80% of them are hopefully seldomly bumped against) and then start with refactoring. When that's done you can start touching other 80%. But don't start develping new features until you've solved all current issues. Why? The sooner you resolve a bug the cheaper it is to solve. Even though in your case nothing seems cheap any more.
Apr
4
comment How to code on a very tight schedule?
@Jeff O: I totally agree. But since this has been going on for 3 years seems expected to answer calls at those inhumanly hours.
Apr
3
answered How to code on a very tight schedule?
Apr
3
revised How to code on a very tight schedule?
grammar changes
Apr
3
suggested approved edit on How to code on a very tight schedule?
Mar
22
awarded  Nice Answer