ASP.NET: officially unmaintainable
posted by offwhite(975) 4 years ago 0
These sorts of posts about ASP.NET being unmaintainable are an exaggeration to me. I have seen time after time new frameworks created because some developers did not like a feature in the widely popular framework. And either they did not like the feature because it really had some problems or they did not understand how to work with it properly. I personally put very little code into my pages and code-behinds and export the vast majority of functionality to class libraries that I can unit test. No development pattern (MVC, MVP) will automatically prevent me from placing code where it should not be if I do not commit to keeping my code organized for maintainability. The over-reaction and false perception here is that ASP.NET is not 100% unit testable. In fact, if you do export most of your moving parts to class libraries, perhaps modular by their purpose, you can create a very maintainable web site with pretty complete code coverage. What MVC is sacrificing now is many benefits on the other end of the spectrum, like powerful server controls, productivity benefits of the design surface, etc. I hope that ASP.NET MVC does not swing too far on the side of the spectrum for unit testing and forget that many developers still want to leverage all of the existing productivity features. I do not want the .NET framework and platform to start fragmenting like Java has done the last 10 years. There are many MVC frameworks in Java. How do you hire someone for your team that happens to know the one you are using? One major benefit of ASP.NET is that you pretty much all have the same IDE (VS) and if a developer has worked with the PostBack model they can be productive on day one. When I was working with Java and other languages I found that taking up maintenance for existing web sites started as a research project to figure out how it was built and then try to learn that framework and understand all the nuances of it. At least with ASP.NET it is the devil I know.
Reply
Try-catching in a single line of code
posted by offwhite(975) 3 years, 11 months ago 0
And where do you place a breakpoint so you can step through this? I see absolutely no value in placing 6 steps of execution onto a single line of code. Are we trying to save on disc storage? Are we you trying to fit more code onto our 19 inch screens? I do not thing lambdas have been around long enough for this to be considered readable. Developers know the try...catch coding style and are comfortable with it. This in no way is more efficient code when it comes to the runtime. Either way it will unfold it into the same set of CLR instructions so you gain nothing by reducing 6 lines of code to 1.
Get Vista to Boot faster
I prefer not to have to reboot.
The 20 most kicked “top-10 stories” for Developers
posted by offwhite(975) 3 years, 10 months ago 0
Well, he did bring the content back to DNK and did the work to summarize the top 10.
Would you put cartoons on your software startup's website?
My initial reaction was that this was just a marketing link, but after I read it through it does cover some good topics. I once had a sales guy at the company take over the web site and drop tons of stock photography onto the site and start selling .NET Nuke installations. It was all very cookie cutter even though our business was to do consulting with custom software development. I think the point made with this posting is very helpful. A shop that does custom software development should not have a bland web site.
Google Chrome is here
posted by offwhite(975) 3 years, 8 months ago 0
M.Gorney you seem quite biased. You may be surprised to know that the IE8 team is doing something very similar with tabs to isolate crashing pages in those tabs from crashing the other tabs and the browser. I look forward to more stability. But the best feature of Chrome that I plan to use it to create Application shortcut links to launch apps like Google Mail in an independent "application" to run by itself. With that feature combined with local storage with Gears you basically have a Smart Client. That is going to catch on as a killer feature combination.
Mono 2.0 Released
posted by offwhite(975) 3 years, 7 months ago 0
I think WCF has been the most used when compared to WPF and WF. I use WCF quite often but sometimes I have to go back to .NET 2.0 which means using .asmx services. WCF is a big beast though with many very precise features. It would be great to see that supported fully in Mono because WCF really is just a WS-* implementation which is meant to work well with Java and other platforms. The other technologies do not present the save cross-platform value. Being able to deploy a WS-* service under Mono (and vice versa with .NET to Mono) which is consumable by other languages and platforms would serve the Linux/Gnome platform in a positive way. And being able to consume WS-* services in the cloud which are published with Java, .NET or other platforms would allow for more cloud integration.
AJAX Text Box Watermark Extender
posted by offwhite(975) 3 years, 6 months ago 0
I created a simple jQuery plugin last week to do this with much less effort. http://www.smallsharptools.com/Downloads/jQuery/ Look at the title watermark page. Just two lines of code for the whole page.
LINQ To SQL is Dead - Read Between the Lines
You can always move to SubSonic. The 3.0 release is coming.
Compressing JS files as part of your build process
posted by offwhite(975) 3 years, 4 months ago 0
You may find that Packer for .NET is a better option with more features. http://brennan.offwhite.net/blog/2008/11/23/packer-for-net-401-released/ It provides a simple MSBuild task to shrink your files in various modes like Packer, JSMin and CSSMin. You can also use the assembly as a dependency to shrink your files at runtime.
Visual Studio 2010 == Visual Studio 2008 + ReSharper
Do not bother with ReSharper. I stuck with it through a couple of versions and constantly had problems. Sure it saved me some time, but it also lost me plenty of time due to falls warnings and errors where the functionality of C# was beyond what ReSharper understood. I also found the support for MSBuild was incomplete and when I opened support tickets to fix the deficiencies they closed them saying they were not bugs. One example was not supporting the "import" feature in MSBuild scripts. Their release marketing claimed full support for MSBuild but their support team said that they were not going to support this functionality which was essential for me to use MSBuild Community Tasks which many people do use. I did not like way the support team handled the bugs I came across and when I went back to just Visual Studio 2008 I was much better off. Maybe the ReSharper team has come a long ways, but I think their problem was technical as much it was about their attitude. I strongly suggest you avoid this extension. And if you do try it, keep in mind that it does not uninstall completely. It breaks a good deal of standard Visual Studio functionality. You will want to set yourself up so that you can revert to your environment before installing ReSharper.
WCF Features in .NET Framework 4.0
posted by offwhite(975) 3 years, 3 months ago 0
Just what we need for WCF, more configuration options along with XAML to make it so much more simple. Really?
Use T-SQL to script the Definition of all Stored Procedures in a DB
posted by offwhite(975) 3 years, 2 months ago 0
You do not see "T-SQL" and "cool" in the same sentence that often. ;) Now can you do the same for tables, foreign keys and indexes?
string.Empty versus ""
posted by offwhite(975) 3 years, 1 month ago 0
This is a disappointing headline on DNK. Developers need to write maintainable code that works. That should be the top priority. Performance is a secondary concern, but it is still important. Now if you have to loop over a million times to find a measurable difference between "" and String.Empty I am going to say this is not an optimization I will ever make. The reason to use a constant for values like an empty string and 0 is that someone reading your code (or perhaps yourself several months or years later) knows that you intended that value. string url = String.Empty; That clearly sets the variable to an empty string. string url = ""; Here the developer may have intended to put a value in here later, but never came back to fill it in. Remember, code is for people and machine code is for machines. Do not think that by reducing the syntax down by a few characters or lines of code that it compiles down to even more efficient code. It just makes it harder to read and maintain. Write verbose code that you can read and can verify is working as intended. This headline justifies the "kick down" feature. Without it DNK will be encouraging bad coding practices.
This blog post completely ignores the fact that I/O is usually the performance issue and String.Empty versus "". And the time saved in using "" is so minimal that is not going to be significant in nearly every case. Now if you are a building real-time application which has code running in a loop many times, like in this example, then you may have a case to use "". But at that point, you should not be using C# to be writing a real-time application. No language/framework that uses Garbage Collection should likely be used for such an application, like a missile guidance system. Are you writing a missile guidance system? I doubt it. And do you think that users on your ASP.NET web site will notice the difference of 0.00000002ms because you are using "" instead of String.Empty? Your efforts are better spent in optimizing the I/O bound parts of your system by tuning caching or SQL. Instead of saving 0.00000002ms you could save 100ms or more. If you go over your code and replace String.Empty with "" you are wasting your time and making your code less readable.
Code Generation Should be the Nuclear Option
posted by offwhite(975) 3 years ago 0
Yet another inflammatory rant without any solid examples to foster a productive discussion. Please stop voting for content that is not well thought out and thorough. It is a waste of our time to read rants.