Posted: 5/20/2010 11:04:50 AM EDT
|
Can anyone recommend any good books or websites that would be suitable for an entry level software dev?
MSDN is looking like a better reference than a place to get my feet wet... |
|
Nice. .net really hasn't changed a whole lot since it came out.
I will say that there are a couple schools of thought when it comes to asp.net development: 1. Classic ASP+. In this one, fuckheads use inline asp.net statements to control HTML output flow. I think we can all agree that this is fucking retarded. Example: <body <% if (x == "red") { %> bgcolor="#FF0000"<%}%> ... and just extend the concept to loops and tables. 2. Certified Must-Call-Someone-Experienced object oriented microsoft .net guru mastery. This is where everything, and I mean everything, is cut up into ridiculously convoluted pieces. Example (and I'm making up all the objects and members because I don't give a shit): Page_Load... { login_page_overhead lpo = new login_page_overhead(); lpo.Init(); Page.Body.Bgcolor = lpo.get_bgcolor(); ... } class login_page_overhead : public HttpWebPage { session_parser sp; color bgcolor; public Init() { sp = new session_parser(); sp.Init((HttpWebPage)this); bgcolor = sp.get_login_page_bgcolor(); } color get_bgcolor() { return bgcolor; // Sure, they'd actually implement proper get/set functions here and "save time" } } class session_parser : protected object_parser { private session_string get_session_value(HttpWebPage current_page, session_string variable_name) { session_string s = new session_string(); s = Session["variable_name"]; return s; } public String get_login_page_bgcolor(HttpWebPage current_page) { session_string variable_name = new session_string("login_page_bgcolor"); session_string variable_value = get_session_value(current_page, variable_name); string return_value = variable_value.ToString(); return return_value; } } And they have a session_string object to "make sure things go okay". And then they sit back and smile at another good day's work. Obviously, my contempt for these guys and their completely impenetrable coding style ranks right about on a level with my contempt for trust fund babies. These also tend to be the drag-and-drop powerpoint guys whose solution to every logical problem is to vigorously apply the "add a class" button. 3. Middle-of-the-road guys like me. I hate code-behind because it's a synonym for code-hidden, and hidden code is code that you can't logically follow. At the same time, inline code is FUBAR. So I use Prosise's technique of dumping the server side functions at the bottom of each .aspx file, following the HTML (client and server) tags. The most important point is to resist the Must-Call-Someone-Experienced habit of clicking "Add A Class" every time you need to do something. Instead, I follow the DRY approach of eliminating any duplicate work, where reasonable, by offloading it into a common page class which every one of my pages derives from (using the "inherits" page tag attribute), by making extensive use of custom- and user- controls for common tasks such as navigation or grid display, by using inline parameterized queries to avoid having to hunt and peck through extraneous stored procedure libraries, by relegating stored procedures to SQL tasks which exceed 10 lines or so, and, my favorite trick of all, by using HTTP "include" directives to control page display. Implementing a class is something you do when the lines you end up typing will be less than the lines they will save, or when the logic involved is so damned convoluted that there's serious risk in duplicating it. So nearly all of my pages look something like this: <%@page inherits="JB_page"... <!––#include file="library/header_preonload.aspx"––> // preonload terminates in the { opening of a "do_onload" javascript function called by the body tag in postonload user_login.focus(); // postonload begins with the } closure of that function, though I can put a } in this file, declare a new function and open it with {, and it'll close that instead <!––#include file="library/header_postonload.aspx"––> <!––postonload also displays a custom control somewhere ala <JB:JB_site_menu runat="server"> Username: <asp:textbox runat="server" id="login"...> Password: ... submit button... <!––#include file="library/footer.aspx"––> <script runat="server"> void Page_Load(Object sender, EventArgs e) { bgcolor = Convert.ToString((object)Session["login_page_bgcolor"]); // login pages don't usually do much else in onload, except maybe log a user out by clearing the session, depending on context. Obviously, CRUD pages or whatever will do much more in onload, and reports pretty much only work in onload (or, of course, additional worker functions and classes). } void OnSubmit(Object sender, CommandEventArgs e) { error.Text = ""; if (IsValid) { // check it out. } } </script> I find that a simple approach, easy to maintain, and yet exceedingly powerful. If I don't want to bother with a custom control or user control, I can just throw a label into the HTML, generate HTML within Page_Load or wherever and append that to a high performance StringBuilder, then dump the SB output into the label. Or I can generate everything in a StringBuilder and response.write that, then response.end to prevent any extraneous crap from appearing, allowing me total control over the output HTML, not just the parts within the <form runat="server" tag. I'm taking an old-school C/C++ approach in using the capabilities that I find advantageous and ignoring the capabilities that I don't. Shit, I don't even use the GUI editor, I do nearly all of my coding in my own text editor, and when necessary I can hit a button to run scripted command-line compilation instructions to generate .dll's. Okay, this is all more than you care about, but it should give you some idea of how powerful asp.net is, in that it can easily handle all three of those paradigms. |
|
Quoted: I'm taking an old-school C/C++ approach in using the capabilities that I find advantageous and ignoring the capabilities that I don't. Shit, I don't even use the GUI editor, I do nearly all of my coding in my own text editor, and when necessary I can hit a button to run scripted command-line compilation instructions to generate .dll's. Okay, this is all more than you care about, but it should give you some idea of how powerful asp.net is, in that it can easily handle all three of those paradigms. I would guess that someone new to .net will just use code behind & Visual Studio... having started with asp in notepad, I can't say I'd blame them! |
|
Programs run sequentially, so I like it when the code is sequential as well. Code behind is a little VB-esque to me, where it moves code... laterally.
Actually, I like to think that I'm being curmudgeonly about this, but three days ago I was debugging a problem in code written by a Must-Call-Someone-Experienced. He had a code-behind file for the page itself that contained about 25 functions, and they were in no order whatsoever. So, I opened the file, intending to just throw a "Response.Write" wherever a certain SQL statement or stored procedure was getting called, and I swear it took me 30 minutes just to figure that out. The fucking problem was occurring when the page loaded, but it was hidden inside some event that wasn't even in the same file. I cannot fathom what would compel a programmer to put critical page-specific code somewhere other than in the files directly associated with that page. I just can't get my head around it. |
|
I would say that if you're starting out with asp.net, don't use Visual Studio at all.
Just use a text editor and learn the compile commands for "cl.exe," which is the C# command line compiler that VS uses. It comes with the .net SDK. ASP.NET is much more organized and readable in plain text than ASP ever was. |
Thanks for the replies. 
More than likely I'll be doing code-behind and will try to take your advice and give it a go w/o visual studio. I completely agree that inline code is pretty retarded and I try to avoid it except when I'm doing "one off's". My first ever professional project (which is being put on pause) has me working on a 100% javascript xforms engine. The code is broken up into 78 .js files that cross reference the hell out of each other... trying to figure out where stuff is happening makes me want to claw my eyes out sometimes. I vow to never make a program like this. Ever. |
|
Quoted:
I would guess that someone new to .net will just use code behind & Visual Studio... having started with asp in notepad, I can't say I'd blame them! So does Visual Studio still breed mediocrity and reinforce letting the tool do all the hard work for you without requiring or expecting any understanding of what's going on under the hood? 
|
|
Quoted: Quoted: I would guess that someone new to .net will just use code behind & Visual Studio... having started with asp in notepad, I can't say I'd blame them! So does Visual Studio still breed mediocrity and reinforce letting the tool do all the hard work for you without requiring or expecting any understanding of what's going on under the hood? Yes. (If you don't know what you're doing in the first place!) I use VS when I need to do some coding (which is getting less and less now) - but I resist using all the "latest ways of doing things that render everything you've done in the past obsolete"... I think the OP actually has two learning tasks - learning about the language, and then learning about the various tools available. (Code behind using notepad seems to be the worst of all combinations!) |
|
Quoted:
I think the OP actually has two learning tasks - learning about the language, and then learning about the various tools available. That's a good point. I was going to also ask why the need for .NET. What's the driving force behind that versus another language? |
|
Quoted:
Quoted:
I think the OP actually has two learning tasks - learning about the language, and then learning about the various tools available. That's a good point. I was going to also ask why the need for .NET. What's the driving force behind that versus another language? .NET is a framework, not a single language. It's a runtime engine similar to java's, with its own unique API. It supports numerous languages, although C# seems to be the favored one. .NET is ideal for web-enabled development, such as web applications or windows forms applications that rely on web services or remoting or such. And I disagree with t-h, code-under with notepad (or, at least, a real text editor) seems to be the best mix of capabilities. The full power and enterprise capability of Visual Studio with the cleanliness, ease of maintenance, and straightforwardness of plain-text development. There's a reason that many of the .net writers, not just Prosise, use code-under for examples. |
|
Quoted:
.NET is a framework, not a single language. True enough. .NET is ideal for web-enabled development, such as web applications or windows forms applications that rely on web services or remoting or such. We're currently using GWT to build our front-ends. I can't say much about it, though. I hate front-end work and prefer to work behind the scenes with the data itself. I don't care what you do with it. 
|
|
Yeah, it's hard to explain. Consider that ADO.NET is a component of .NET which replaces all the old ADO/activex bullshit in classic asp or the fucking nightmare that database access might become in straight win32 api development.
So you're talking about a framework that includes a very powerful and robust database access technology as one of its branches. There are, of course, things that .NET can't do very well, but I haven't found many of them. AJAX has been a little rough, though they're getting better, and third party drop-in libraries abound. ASP.NET tries to wrap HTML output, but my experience with it as such is... middling. Realistically, it just offers a bunch of condensed controls that wrap HTML output, and allows you to add your own as you like. So, if you find yourself generating the output code for, say, some kind of CSS/Javascript spreadsheet view, you can build that into a control and simply drop it in to any pages you need it in, using object properties and methods to control its display, content, and whatever else happens to be page or context specific. So, you don't want to think of ASP.NET as adding any previously unknown client-side features to your user's web experience. Far from it, everything that ASP.NET can spit out to the client can be replicated in straight HTML or classic ASP or PHP or whatever you like. Rather, ASP.NET provides a powerful framework which enables you to, among other things, wrap all that old shit into easily organized and managed containers. Try to visualize object-oriented web development, and you're sniffing around the right tree. A better approach is probably this: Describe a programming task that you find yourself spending a lot of time on, and I'll tell you what would be involved in doing it in .NET, or if it's possible at all, to the best of my knowledge. |
|
Microsoft has free express versions of Visual Studio http://www.microsoft.com/express/ |
|
Quoted:
Describe a programming task that you find yourself spending a lot of time on, and I'll tell you what would be involved in doing it in .NET, or if it's possible at all, to the best of my knowledge. Hmm, that's hard to say. I spend my days writing web services so I suppose the closest thing would be executing RPCs and parsing/generating SOAP XML. |
|
You write web services without .NET?
Weird, but here's one way to do a web service in .NET: http://www.w3schools.com/webservices/ws_example.asp |
|
Weird? There's life outside of .NET.
Interesting example. To be honest, my impression of .NET comes from the dev teams I know that use it and it isn't pretty. One of our products' developers haven't had a day off since last Memorial Day. The product is crap from what I understand. Apparently they follow the Agile methodology. I don't know if it's a problem of the tool, the methodology, or the implementation of either or both but I'm less than impressed with how they seem to do little more than cause problems for themselves the way they work in a shared environment and step all over each other between dev and prod. I'm sure it's more how they do it than what they do it with but the consensus is the same regardless of the product. None of the .NET products I'm aware of seem to be successful compared to our Java stuff. At the beginning of the year we became McDonald's with over a billion transactions and we consistently have minimal issues. |
|
Quoted:
Weird? There's life outside of .NET.
Interesting example. To be honest, my impression of .NET comes from the dev teams I know that use it and it isn't pretty. One of our products' developers haven't had a day off since last Memorial Day. The product is crap from what I understand. Apparently they follow the Agile methodology. I don't know if it's a problem of the tool, the methodology, or the implementation of either or both but I'm less than impressed with how they seem to do little more than cause problems for themselves the way they work in a shared environment and step all over each other between dev and prod. I'm sure it's more how they do it than what they do it with but the consensus is the same regardless of the product. None of the .NET products I'm aware of seem to be successful compared to our Java stuff. At the beginning of the year we became McDonald's with over a billion transactions and we consistently have minimal issues. There are a million ways to program poorly, I've found. I suspect they're the guru type, but who knows. Anyway, that example should illustrate the simplicity and integration that .NET affords. And the benchmarks between .NET and java seem... comparable, if not leaning toward .NET, though it's hard to be sure. |
|
Quoted:
All my stuff lately is ASP.NET MVC 2. I am so done with Webforms. Yep. Automated unit testing of your presentation layer without having to maintain easily broken test scripts is a godsend. JBlitzen would have a cow if he used MVC 2.0 I think. 
JaxShooter, any bad dev team can take a perfectly good tool and misuse it. I've seen teams screw up Java and I've seen teams rock with .NET. I have seen the reverse. Poor implementation by a team shouldn't be a judgment on the technology. Visual Studio is a great IDE. It's one of the best features if you're in the .NET favor. If you're not using it, you're spending a lot of wasted time writing repetitious code which given enough hours will have a certain amount of bugs/errors that you'll have to log tickets, track, fix, verify, QA, and deploy. Automate that and go home at 5pm already. |
|
Quoted:
JaxShooter, any bad dev team can take a perfectly good tool and misuse it. I've seen teams screw up Java and I've seen teams rock with .NET. I have seen the reverse. Poor implementation by a team shouldn't be a judgment on the technology. I'm not judging the tech on the team. I think they're horribly mis-managed and they do things I've never seen an experienced team do. It's just my only experience with it. Well, not really. I've had to jump through hoops more than once to accommodate .NET users (clients). Apparently MS's XML parser doesn't give a rat's ass that you're WS-I compliant. I've created schemas/WSDLs that every tool in the world approves of except for MS. They don't seem to handle complex unions well at all when it comes to binding a .NET app to a WSDL. Visual Studio is a great IDE. It's one of the best features if you're in the .NET favor. If you're not using it, you're spending a lot of wasted time writing repetitious code which given enough hours will have a certain amount of bugs/errors that you'll have to log tickets, track, fix, verify, QA, and deploy. Automate that and go home at 5pm already. I agree that it's a great IDE with the caveat that you know what you're doing in the first place. Most of my early work was done in VB and I saw a lot of code where the developers relied too much on the tool and the code it was generating for them. They couldn't debug their way out of a wet paper bag because they didn't understand what the code was generating or why. Need to provide custom error handling? Forget about it. Go home at 5? I'm gone before that!
I wouldn't mind toying with .NET. I just need to find some time. |
|
Quoted:
Quoted:
All my stuff lately is ASP.NET MVC 2. I am so done with Webforms. Yep. Automated unit testing of your presentation layer without having to maintain easily broken test scripts is a godsend. JBlitzen would have a cow if he used MVC 2.0 I think.
JaxShooter, any bad dev team can take a perfectly good tool and misuse it. I've seen teams screw up Java and I've seen teams rock with .NET. I have seen the reverse. Poor implementation by a team shouldn't be a judgment on the technology. Visual Studio is a great IDE. It's one of the best features if you're in the .NET favor. If you're not using it, you're spending a lot of wasted time writing repetitious code which given enough hours will have a certain amount of bugs/errors that you'll have to log tickets, track, fix, verify, QA, and deploy. Automate that and go home at 5pm already. http://dotnetslackers.com/articles/aspnet/a-first-look-at-asp-net-mvc-2.aspx 
|
|
Heh, see? I knew it!
Actually, even though it violates your rule #1, it helps your rule #3 by putting all related code for a page in one location. There is no code-behind. There's a controller but once it feeds the model to the view, it's done and it's not part of the presentation when it's being rendered. Other things you'd like about MVC is no viewstate, better support for AJAX and JSON, and finer control of HTML output. The one thing that you'll hate (and it bugs me too) is it reminds me of asp.old too much. |
|
Not sure why everyone is gaga over templeted helpers. I've found little use for them myself. |
I hate to say it but I'd be dead in the water without Visual Studio. 
Right now they have me working on web controls that rely extensively on SOAP services... I'm finding IntelliSense rather invaluable. Especially since the only "documentation" I have is object names and object variable names. All in all though, I can see myself enjoying this career path 
|