Windows Phone

Development trends to watch in 2011

Justin James considers Silverlight, Windows Phone 7, mainstream development alternatives, Web development maturity, and the economy topics worth watching in 2011.

2011 is here! While I don't like to make predictions per se, I do like to explore what topics I think may be important to developers for the next twelve months. Let's jump right into my look ahead for 2011.

Silverlight

2010 was the year that Silverlight (and with it, WPF for apps that need access to local resources) gained real momentum. The more I play with Silverlight, the less it frustrates me, though lots of aspects of the technology still rub me the wrong way. In my opinion, the "patterns and practices" people pollute Silverlight's ecosystem; they waste a lot of time and effort on a million frameworks to do things that address a couple of stylistic and academic concerns at the expense of increased complexity, indirectness of code, and significantly raising barriers to entry.

Fortunately, I learned that you don't need to do things the way these folks push. In fact, the default, out of the box Silverlight development experience is very similar to WinForms (for better or for worse), and the learning curve is not nearly as bad as it appears when you first survey the landscape. This is particularly good news because, in 2011, enough development is moving to Silverlight and WPF that folks who don't have the time and energy to learn new development paradigms will be moving to it.

Windows Phone 7

In my TechRepublic columns about Windows Phone 7 development, I note that the experience hasn't always been pleasant. While aspects of Windows Phone 7 development still frustrate me, it is a much better experience than its competition in terms of writing applications.

I don't know if Windows Phone 7 will be a big hit, but if it's a success, it will be a late bloomer like Android. Remember, Android was anemic until the Droid 1 was released just over a year ago, and now it's a big hit. That said, I think that Android is the odd man out right now. The development experience is tough because of the fragmentation. You never know what resolutions to expect, for example, or baseline phone functionality. Even on a particular model, you can't expect a particular version of Android. With iPhone, BlackBerry, and Windows Phone 7, you do.

RIM has lost an incredible amount of momentum, and none of its recent attempts at regaining it have looked promising. Palm's WebOS is on ice until HP figures out what it wants to do with it. Symbian has huge worldwide success except for the United States. iPhone continues to move crazy unit numbers. If Windows Phone 7 becomes a hit, it will be at the expense of RIM and Android. I think Android has enough problems, and Windows Phone 7 has both enough potential to pull it off. Windows Phone 7 is already quite good in ways that Android isn't, both to developers and users. If I were an Android developer, I would be watching Windows Phone 7 to see where it goes.

Related: My first Windows Phone 7 app development project, The Windows Phone 7 App Hub experience, and Optimize data access for mobile phone apps.

Mainstream development alternatives

The more I see of Java and .NET, the less I am happy with them. Java and .NET work really well for some things; however, both have a lot of problems, not the least of which is the ecosystems. The Java ecosystem isn't sure if it wants to be some open source haven or the next COBOL. The .NET folks are going insane replicating development patterns that were pioneered 30 years ago, but instead of studying the literature and figuring out how to do it right, they get hung up in replicating what was done ages ago, including the workarounds that were needed due to technical limitations at the time. Meanwhile, neither ecosystem is doing much of anything to deliver products that allow typical developers to produce better applications quicker with fewer bugs and security problems.

Frameworks that enable developers to use the latest pattern fads cover up the fundamental problems with both platforms, which is the amount of complexity in the typical application is overwhelming. I hope that the alternatives to these mainstream development platforms get more traction in the future. I haven't talked to anyone who left Java or .NET and was eager to go back, particularly around Web development. If you think there has to be a better way to get apps out the door, 2011 is a great year to check out your choices!

Web development maturity

In the last decade, Web development has really taken off, and there has been a ton of innovation in the space. Going forward, we are going to see a lot more maturity in the market. For better or for worse, HTML5 continues its progress toward being a universal standard for building Web applications. Web browsers are following suit, and even Internet Explorer is trying hard to comply with the HTML5 standard. This means that developers can spend more time getting stuff done and less time figuring out one-off workarounds and clever hacks for problems that shouldn't even exist.

The economy

In 2010, the economy picked up steam for tech workers, but the momentum seems to be more for specialists than generalists. "Plain vanilla" developers are watching their wages remain steady, and entry-level developers are in tough competition with more experienced overseas workers within the same salary range. It seems like not many companies want to make a long-term investment in less-experienced developers who show promise, and even fewer want to put anything into their existing staff.

The trend of hiring to fill knowledge gaps instead of training will only increase. The really bright spots are for people with in-demand, specialized skills, such as Silverlight and mobile developers. It looks like Ruby and Rails will also have more demand as time goes on.

I also think this is a great opportunity for independent consultants. Companies have learned to be choosy enough about projects that their overall need for workers may stay the same in terms of total developers needed, but they are much more likely to need certain skill sets for limited periods of time.

What development topics will you follow in 2011? Let us know in the discussion.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.

About

Justin James is the Lead Architect for Conigent.

59 comments
dreamer2222
dreamer2222

C'mon guys. Silverlight is a joke. Flash won this battle years ago. Even Flash is dying now thanks to Apple. Real trend to watch is server-side JavaScript like node.js The only reason silverligh can get bigger adoption - is because it's usershare now practically noneexistent so there is nowhere to go except forward.

kpthottam
kpthottam

I study trends by merely visiting bookshops around the world to see which languages are getting popular and which are losing steam. Objective-C is taking off thanks to Apple's iGagets. Java will remain in place thanks to the Android and the Blackberry platforms-- In Canada In India on the other hand, I noticed rack after rack of mainframe books. -- validates the article's section on outsourcing

Mark Miller
Mark Miller

Before my time, data was what ruled in IT, from what I understand. Computers and software were just a means of processing it. In some ways this "hierarchy of needs" is still true. A few years ago I heard a discussion saying that "data is king," because it's the only thing a business can keep proprietary. Talent comes and goes, and software can be duplicated or reverse-engineered, so your competitive advantage is more vulnerable in these areas. Perhaps the complexity of what needs to be done with data has made functionality become, if not king or queen, at least "duke" or "duchess" in IT (no pun intended towards the Java camp). Language and framework is not that relevant to the concerns of business (again, I make a distinction between concerns and needs), in and of themselves. What makes them valuable is that certain languages and frameworks became intimately linked with certain categories of functionality, which business values. In addition there are skilled workforces associated with them, who are in effect "technology operators," though they're called engineers because solving problems is part of their job description. As long as nobody offers an alternative that deals with the functionality business wants (and wants are not necessarily the same as needs. Even if they want it, it may still hinder them), and at the same time reduces the complexity of using it, then I think businesses are not going to be concerned with how ham-handed the language and/or the frameworks are in doing what they think they need to do, because their competitors are dealing with the same issues. As long as complexity and inefficiency are shared, then "it's just how things are," and nobody's the wiser. This goes back to Nicholas Carr's thesis, "IT Doesn't Matter."

aswidener
aswidener

"In my opinion, the ?patterns and practices? people pollute Silverlight?s ecosystem; they waste a lot of time and effort on a million frameworks". Amen to that - for both .net and java (per your later observations). A salty greybeard PM once chided my .net team about why it required more developers and time to deliver buggier products that do essentially the same things that his COBOL/DB2 teams cranked out in the early 90s. A lot of it I would attribute to feature/framework bloat and mentality. I once took over a team charged with writing a client/server app in winforms; they'd been working for four months choosing caching and data management framework(s). The sponsors were going out of their minds and about to cancel the project. We finished the whole thing in less time by simply writing simple code. In many endeavors simplicity and dedication are all that it takes. The framework guys seemingly forgot that long ago.

TexasJetter
TexasJetter

I also feel that the Silverlight learning experience is convoluted. Additionally the design experience in Blend is not intuitive either, at least from a non-graphical designer background. There seems to be multiple barriers, from design, to data access, to publishing that continue to limit my efforts, albeit minimal, to move forward in Silverlight. You mention that you have found that you don?t need to do things the way the ?patterns and practices? people push, can you elaborate on your discovery? I am also concerned with Silverlight for general use due to the lack of installed client support. I know the Silverlight client install is fairly small, but it does require an effort, and requires administrative privileges. Unless I have something that the viewer really wants I am concerned that they will just go somewhere else. TR Users, what are your thoughts on this?

Justin James
Justin James

When I saw SL as a competitor with Flash in the browser plugin market, I agreed. Microsoft is not positioning it as such, and for what they are using it for now (stuff like WP7, distributed, zero install desktop apps) it is excellent and getting very good adoption. Good call by Microsoft to reposition it when it was clear that Plan A wasn't working. J.Ja

kashyap.bikram
kashyap.bikram

I have visited many shops, mainly in Assam, Kolkata and Bangalore. The shops which have mainly mainframe books have old stock which did not get sold. Most of the new stocks are Java and .NET related. Never saw a book of SilverLight. And it seems India mainly being an outsourcing destination, there are a lot of maintainance projects and migrations. And most of them use Java or C/C++. And also most of the web applications are in Java. At the same time there is also a lot of development work in Java, specially in the big companies like TCS, IBM, Acc, Wipro, Infosys. Also there seems to be a large demand of moderately experienced testers.

Justin James
Justin James

You are right about the fact that, at the end of the day, the users don't care WHAT you implemented it in. But I will say, it's hard to meet user expectations without using rather up-to-date tools in many cases. For example, you can spot apps that started as old Delphi apps and never got a refresh because they carry this Windows 3.1 vibe to them... even though its purely cosmetic, it looks outdated to users. Ditto for a lot of apps ported from X11 to Windows. They look outdated, and users don't like them as a result. J.Ja

Justin James
Justin James

The original poster you replied to said, "We finished the whole thing in less time by simply writing simple code." Some frameworks (like the IRC one you mentioned) do just that. Libraries do that too (indeed, that's the whole point of a library, to roll a zillions LOC into a few simple calls). But too many of the frameworks out there, specifically, the ones that try to impose a particular development pattern on a system that definitely does not use that development pattern (like MVVM frameworks for Silverlight, MVC frameworks for J2EE and ASP.NET, stuff to make C# a "declarative" language, etc.) tend to make things worse. They require massive amounts of plumbing and abstract the development so far that debugging is a nightmare. The paradigms look foreign to the folks who didn't write the framework or who are not familiar with it. It's one more thing to have to train people on. It often feels like trying to stuff a mastiff into a leather coat to keep them cool in the summer time (there's an analogy for ya). In those cases... it's a mess! J.Ja

apotheon
apotheon

> In many endeavors simplicity and dedication are all that it takes. The framework guys seemingly forgot that long ago. There's a flip side to that: sometimes, a simple framework provides the basis for more simplicity of project design. The kind of complexity you bring up is the reason that I have tended to shy away from Rails even when doing Web development in Ruby, and it's why I have in recent days shied away from the bigger IRC bot frameworks for Ruby when I decided I needed to write an IRC bot. On the other hand, I found a delightful little IRC bot framework that allowed me to create an IRC bot in a matter of minutes that was essentially bug-free. I'm planning to write an article about that framework for the Programming and Development column here at TR. It's incredibly simple to use; it just provides an elegant domain-specific language for interacting with the IRC protocol. Writing the same thing using nothing but direct access to sockets and the like would have actually taken much longer and been far more bug-prone. The difference, of course, is that I chose a framework depending on what I needed it to do and no more, and that I did not write a whole framework for something I was only going to do once -- a framework that would probably never be used again, by anyone. The people who put too much into their frameworks and not enough into writing, simple, robust code are making a mistake not because they use frameworks, but because they either write their own generalized frameworks for a one-time, simple job, or choose a framework based on how many features it has and how often it is mentioned in BusinessWeek rather than how closely it matches their actual needs.

Justin James
Justin James

Excellent questions! I agree about Blend. I haven't worked with it, but I've looked at it. It makes sense to me, but only because I invested a lot of time ages ago learning Flash, and it shares many of the same concepts. Blend is NOT a tool for the uninitiated. Luckily, the Silverlight designer in VS2010 is significantly improved. Let's look at the major barriers to entry on Silverlight: XAML: You need to know XAML to do the really cool stuff. Luckily, the typical app doesn't need "really cool stuff", it needs text areas and drop down boxes, etc., and that stuff is drag and drop, even in VS2010. So you don't need to know as much XAML as the typical SL tutorial says that you do (thankfully). Blend: The SL designer in VS2010 is enough for typical business application development. Blend does some awesome stuff, but for mainstream development, it's overkill (this was not the case with VS2008). Data Access: SL doesn't do ODBC or other direct DB access methods. What it *does* do is LINQ-to-XML (if you have something providing an XML representation of your data), SOAP, and OData (aka "WCF Data Services") very well. I know, who wants to write a Web service to provide basic DB access? Luckily, a WCF Data Services thing can be created VERY quickly via wizards, and basically act to expose your DB as if you had ODBC access to it, and SL can then quickly build proxy classes to it, giving you strongly typed access. Problem solved. :) MVVM and other buzzword "patterns": Not needed, flat out. Do they make your life easier? If everyone on your team understands them well, I can see some good points to them. To a WinForms developer, they are a total mystery. The out-of-the box SL experience is nearly identical to ASP.NET WebForms (similar to WinForms), in that you have controls that are declared in a separate file which you rarely touch by hand if you don't want (in this case, XAML), and everything can be done as event handlers in code behind. The biggest adjustment I found, is that SL (at least, as implemented on WP7) demands the Asynchronous pattern for a lot of operations (like WebClient.Download()), which is not a hard adjustment to make. Hope this answers those questions! In terms of the client deployment... something like 70% of PCs on the general Internet have SL, as of a year or so ago. It's higher now. For internal apps, this isn't an issue because you can push out the SL client via WSUS or Group Policy. Feel free to ask any more follow up questions. Maybe this would make a good article in the near future? J.Ja

apotheon
apotheon

Unfortunately for Silverlight, dreamer2222 is right -- JavasScript on both ends of the channel seems to be an approach with much more promise right now. This is not something inherent to JavaScript itself, of course; it is dependent upon the way JavaScript is being used to advance the state of the art for event-driven development on the server with tools like Node.js and its historically mandated positioning on clients. ECMA's abandonment of a major version update for ECMAScript a couple years ago seems to be the only fly in the ointment.

Mark Miller
Mark Miller

Ah, good excuse for a rewrite. Outdated interface? Sorry, you can't get the new interface without a rewrite. That'll be $1.4 million and we'll have it for you in a couple years! I know that's not the pitch, but I've seen this reality play out. I came into a company in the middle of a C++/MFC project that was WAAAYY overdue. They had overshot their delivery date by more than a year, and their cost estimate. In fact the cost of the project had doubled. I finally heard the story of it towards the end of my time there, and it was a mess. The whole goal was to take a 16-bit Windows app. (Windows 3.1) and rewrite it for 32-bit Windows, with a few feature additions. The concern the customer had was not that the interface looked old, but that they had been keeping track of court decisions involving Microsoft, and they said they saw the writing on the wall: Microsoft was not going to support 16-bit apps. on 32-bit Windows indefinitely. That was the story, anyway, and based on my own personal experience with Windows XP, that sounds right. The problem was the customer really didn't understand what information a software project required. From what I could tell, the customer rep. we dealt with didn't understand how to run a software project, period, which would've been helpful, because he basically expected us to reverse-engineer the old app. He had information about it that he would not disclose, which made it really difficult for us! The common refrain we heard from him was, "Why can't you just make it work like the old app.??" We kept telling him, "We can, but we need a description of how the old app. works!" They had given us a copy of the old app. (compiled and runnable), but no source code, and they assumed that was basically enough (yeah, I suppose we could've disassembled it and tried to figure it out that way!). Fortunately they gave us a two-page description of how the search engine was supposed to operate, which was a critical piece, but that was the only spec. we got from them. Fortunately the team that had worked on it before I got there had made significant progress on it, but there were still some loose ends that hadn't been resolved. As I recall, we were able to fill in the functionality/algorithm gaps through e-mails and phone conversations with the customer rep. I heard one story that the project languished for a year under a project manager that had been hired by my employer (long gone by the time I got there). All he did was have these delightful golf conversations with the customer rep., but his team barely got anything done on the project itself. Projects like that are a crying shame to me. Thankfully it seemed like that wasn't the norm, though the division I was in did a lot of rewrites, translating apps. from 16- to 32-bit. Some of them were old Delphi apps.

ExEm2SS
ExEm2SS

It depends on what your needs are. If you are building a simple application, then MVVM/MVC are overkill. However, if you are building a complex mission-critical application then good design/abstraction is absolutely important...for testing, maintenance, and scalability reasons. Often, this involves the very frameworks/patterns that you dislike. My current company processes several thousand foreclosures and evictions per day. Bugs are simply not an option, as any mistake on a foreclosure and/or eviction can be costly. Unit tests are mandatory. The only proper way to fully test an application through unit tests is abstraction.

TexasJetter
TexasJetter

Unfortunately from what I have seen this means SQL 2005 or above. Our corporate data is still on SQL 2000 so it is difficult to explore. I have set up a Dev copy of SQL 2008 for testing and have seen a little of what you are referring to, although I have a strange issue of the app breaking when retrieving over 1,000 records :( Which leads me to my next question, I have heard from several different sources that the Web Services model is not highly scalable. The statement I have heard most often is that the performance is just not up to par when dealing with large scale data consumption. I have to admit that I don?t know what level they considered large scale, but I continue to hear that Web Services is not the best approach. Is this different from what you are describing? As far as follow up articles, I try to read everything I can about Silverlight. Everyone seems to agree that Silverlight is where MS is heading and since I am mostly a MS guy I feel the strong need to keep on top of it.

robalexclark
robalexclark

I'd go along with that - I started trying to do things the "right way" i.e. doing as much as possible in xaml with full on data binding and MVVM but to be honest I don't think it makes things any simpler a lot of the time and I actually find that sometimes the separation between gui/xaml and code behind means its difficult to understand what is actually going on. This is surprising considering this separation is supposed to be the "right way".

Mark Miller
Mark Miller

[i]Data Access: SL doesn't do ODBC or other direct DB access methods. What it *does* do is LINQ-to-XML (if you have something providing an XML representation of your data), SOAP, and OData (aka "WCF Data Services") very well. I know, who wants to write a Web service to provide basic DB access? Luckily, a WCF Data Services thing can be created VERY quickly via wizards, and basically act to expose your DB as if you had ODBC access to it, and SL can then quickly build proxy classes to it, giving you strongly typed access. Problem solved.[/i] I remember using SOAP web services with .Net 1.x. They were convenient to set up. I may be remembering incorrectly, but I recall one reason they were convenient is you could configure data access to your database quickly with them. However, I was uncomfortable with web services, because they were just open "portals" into your data. The database connection was managed by the web service, but anyone who knew the URI to it could access that data, unless each web service entry point explicitly asked for a passcode with each request, code for which the developer had to put in themselves. I was working with ASP.Net at the time, and I preferred to write up my own data access code (using ADO.Net) that would be run directly by the web app. This way, literally the only way to access the data was through the web app., unless of course someone managed to hack into the database server. Back when I was doing this stuff I remember reading about how Microsoft and IBM were jointly working on a secure web service standard, though I never heard how that turned out. How does the .Net stuff handle web service security now?

apotheon
apotheon

> something like 70% of PCs on the general Internet have SL, as of a year or so ago. It's higher now. I have to wonder how we arrived at "70%". I'm skeptical about the accuracy of that number. I think maybe 20% of the nontechnical computer users I know have Silverlight installed, and fewer of the more tech-savvy. Is that 70% measured in the US only? Is it based on Microsoft's own numbers -- which are based on Microsoft's numbers for MS Windows market penetration, Microsoft's numbers for IE market penetration, and Microsoft's assumption that everybody who has downloaded an installer must be using the software? Even if the 70% is accurate, it's a dangerous thing to just take it at face value. 70% makes it sound like for any given user, that user is 70% likely to have Silverlight installed. That's not really the case, though. The truth would be that 70% of users are 100% likely to have it, and 30% are 0% likely to have it. The next step after figuring that out is to try to figure out what demographics fall most into which category -- and figure out which categories are important to you. If your core user base is about 60% made up of people in that 30%, it doesn't matter that 70% of the Internet has Silverlight because for your purposes, only 40% of them do. . . . but wait, there's more! Let's say your userbase is a perfect cross-section of the Internet, just for argument's sake -- even though that's almost certainly not the case. Saying "70% of the Internet uses Silverlight -- we're totally in the clear!" is exactly the wrong way around. Instead, you should be looking at the situation and saying "If we use Silverlight, we're telling 30% of our customer base to go somewhere else." Here's a thought: essentially 100% of Web browser users, no matter what browser they use, have software that renders (X)HTML, which means that server-side development doesn't hurt your customer base at all. It's likely that at most 2% of users don't have JavaScript, if you really need client-side dynamic capabilities. Never use a technology that limits your customer base unless you have to, or unless you have a captive audience whose system configurations are controlled such that they must support the technology you want to use. This means that, for the most part, technologies like Silverlight should be a necessary part of the user experience only in cases like intranet deployments -- same as ActiveX, Flash, and browser-based client side Java. Otherwise, you're telling would-be customers you don't want their business.

Justin James
Justin James

"So, if ASP.NET MVC is a good implementation of the concepts of Rails, that would mean that ASP.NET MVC would be a Good Thing (tm), irrespective of how it was actually implemented (written in Assembly from scratch or bolted on top of a bad model)." In terms of a development model yes. Assuming that I was in love with Rails, which I'm not. Not because I tried it and liked it, but because I haven't tried it. I don't have an opinion on Rails one way or another. "So, is ASP.NET MVC just something bolted on top of ASP.NET and is the real ASP.NET shining through? In my opinion, not at all." This is where we differ. I see ASP.NET shining through ASP.NET MVC, at least if you don't use an alternate view engine. The "out of the box" experience looks (to me) like a hacked up version of Web Forms. In fact, in many regards, I never got into Web Forms because they were so ugly, and my ASP.NET looked like ASP.NET MVC, without the fancy router code. "I don't see the ASP.NET in ASP.NET MVC. Nowhere. There is no code-behind, there is no ugly state being passed between browser and server. There are Controllers, there are Views. Conceptually, quite like Rails." This is true, but the view engine (out of the box) is the ASP.NET engine (ugh) and there are code behinds, if you want to. You can use state, if you really wanted to. Basically, there isn't a real clean break with Web Forms... it's just a minimalist approach. Indeed, you don't need code behind or state with ASP.NET either. You can write it like PHP if that's why you really want! "I am of course also spending time with IronRuby and Rails, but customers currently do not want Yet Another Programming Language introduced. In many cases that would be much better of course, but at the end of the day it may be politically impossible." I just started some light IronRuby work myself. If it turns out to be a winner (I hope it is!) I may try some Rails experiments with it. I'm probably going to try IronRuby on WP7 first, though. :) J.Ja

terjeb
terjeb

>>That's not to say that the model-view-controller pattern is bad. It can be a wonderful thing. It should not, however, be implemented as a framework layer of abstraction over a conflicting model for application development

AnsuGisalas
AnsuGisalas

...with a pencil through it's nose" That's probably a profound observation... your subconscious must have simply "corrected" the input to match what it perceived... (Why did I read "stylus" instead of pencil?)

santeewelding
santeewelding

I watch you. Not only here, but in another place. The only reason I broached you hard in the recent past in this place was because you impressed me. You impress me, still.

Justin James
Justin James

I *just now* realized that santeewelding's picture is an anvil with a hammer on it. For the last year or so (or however long he's been using it), I thought it was a stylized Easter Island stature looking up, viewed from the ground, with a pencil through it's nose. I am not making this up. I'd been looking at it for months thinking I was nuts (apparently I am), because I knew it wasn't what I thought it was, because that made no sense. J.Ja

santeewelding
santeewelding

Are of approximately the same age. Approximately, too, of the same male hormonal advancement level. Too, of same need for prevalence. Take it from an old guy: knock it off. Master theology, or something.

AnsuGisalas
AnsuGisalas

The ones who fight for conflict will get no conflict out of me. I'll do what can be done to make them no longer be a problem. "En garde" has nothing to do with that. Its opposite, in fact. I hope that I won't have to of course. And if I have to, I hope that I can let them live and learn. To fight - has too much of that dojo smell.

apotheon
apotheon

. . . you die at the hands of those who fight for conflict.

AnsuGisalas
AnsuGisalas

why are you adding fuel when the course is wrong? Once you see it going somewhere you don't want to go, just politely extricate yourself and add the fuel where you have something constructive to say. It's really that simple, the whip is useless, the carrot - golden. Especially when the recipient can decide for themselves, like you, to simply call that "nuh-uh, you fumbled and whipped your own ass!!!". It does not diminish you to say "Oops" or "Ow, you got me". In fact, in a world of "Nuh-uh" -people, the "Ow" -people tend to get more respect. Fighting for peace is like flucking for virginity - but, potentially, less enjoyable.

apotheon
apotheon

I admitted my error -- terminology and a fuzzy memory for specifics. The fact that I did so in the face of what amounted to an implicit claim that I'm a liar, as a distraction from my actual point (which was utterly ignored in favor of using pure pedantry to derail discussion), seems to have escaped the two biggest current pseudo-intellectuals (or are they merely ivory-tower intellectuals?) on the site. I've been "had" because I made the mistake of being incautious with phrasing, thus somehow invalidating my point which -- by the way -- is in no way dependent upon my phrasing. This is why I effing hate you people sometimes. Good points, good discussion, a good effort toward achieving understanding, good progress, and so on, are derailed by a bunch of damned intellectual wanking. This has nothing to do with a passion for subject relevant ideas and the advancement of, well, anything other than an inflated sense of self-worth. Yes, that pisses me off. It's pointlessly destructive, with only one obvious aim: propping oneself up at the expense of others. If this isn't the very definition of trolling, it is a pretty effective facsimile in terms of its counter productive aims and effects. Yeah. It pisses me off. Go screw yourselves.

AnsuGisalas
AnsuGisalas

Chad, when the red lights starts flashing and the Big Alarm Horns go off... That's when you need to hover, and take possession of the immutable - not lash out in seeming frustration. It's unbecoming. It's something I sometimes forget to do too, but I always regret it. Needless use of force is a sad thing. But it's not just that - an attack should be carried out only from the stillness of the void. Not plinked off arbitrarily a'huffing and a'fretting. It does you good to have your ass handed to you once in a while... I'm not up to that task, but it seems you found a haymaker to stumble into ;) Congratulations.

apotheon
apotheon

Okay, for the pedants: Recast what I said in the correct professional language so that it makes sense in context. That, or just ignore it, and I won't deal with your crap any longer. edit: Yes, I used the wrong terms. No, I did not make things up, or imply that you actually are santeewelding. No, you did not bother to meet me halfway and acknowledge that I might have said something in English. I wasn't addressing you anyway. Kindly reorient yourself toward having a discussion or go screw yourself. I don't care, either way.

herlizness
herlizness

> the FAA does not make such determinations; the NTSB does ... the NTSB does not make those kinds of subjective evaluations in their reports and certainly did not in the report on USAIR 1549. This was not a "safe landing." It was a ditching with a good survival outcome; there is a disinction. One board member commented that in his opinion it was a "forced water landing." > I intend the MIT definition when I use the word "hack;" however, under these circumstances, the captain's behavior was actually within the bounds of conventional; to call it "new and beautiful" is quite the stretch; it was purely pragmatic. > yes, I'm aware of the etymology of "amateur" and have generally had a longstanding disdain for the use -- and overuse -- of the word "professional." My strong suspicion, however, is that Captain Sullenberger would call himself a professional.

apotheon
apotheon

The FAA determined that a key factor in the safe landing of the aircraft was the fact that, as an enthusiastic, passionate pilot who logged more hours flying on his own time than he did professionally, he had far more skill as a pilot than the average airline pilot would ever ever have. Whether it was a "hack" landing depends on your definition of "hack". If you define it the way those early hackers at MIT did, as an unconventional approach to something that exposed principles of the field previously unknown (or poorly understood) and achieved something new and beautiful, then yes, it was definitely a "hack" landing. If you define it as those who derogate such hackers define it, as something only an amateur who doesn't know what he is doing would do, then no, it was not so much a "hack". Ironically, "amateur" comes from the French for love. An amateur is someone who loves what he or she does -- a passionate practitioner of a craft. So-called amateurs are, often enough, better than the professionals who mock them. edit: Who do you think you are, taking this vaguely contentious and topic-skewing approach to things, anyway -- do you think you're santeewelding?

apotheon
apotheon

There's another problem with MVVM: it's basically just MVC redesigned to satisfy people with a deep-seated desire for bureaucratic micro-management, as far as I've been able to determine so far.

herlizness
herlizness

> could it be that Sully had a passion for staying alive? do you consider this to be a hack landing? It was a great application of loose coupling principles; never bind the landing procedure to concrete airstrips.

herlizness
herlizness

> Amen. I have no idea how it survived beyond version 1.0.

apotheon
apotheon

As so aptly demonstrated by US Airways pilot Chesley Sullenberger III when he saved all 150+ people on his A320 passenger aircraft when a flock of geese took out both engines and he made an emergency landing in the Hudson River, people who are passionate about what they do tend to be better at it than people who are just there to punch a clock and collect a paycheck. That passion involves doing it on your own time, learning more about it for the sheer enjoyment of it, and sometimes even arguing about it with other people who have similar passions. What you get out of it is software developers who care about their craft, and -- hopefully -- produce better software as a result. The people who care about their craft are the people who advance the state of the art of software development, who help push us toward better software, that improves our quality of life and aids in the development of more advanced technologies, which then also improve our quality of life. Two of the most important human endeavors right now involve advancing the state of the art of computer hardware design and advancing the state of the art of computer software design. This is because these two endeavors provide a multiplying effect for the rate at which we can advance the state of the art for almost everything else we do. Automation is what frees us up for intellectual pursuits, after all, helps us organize those pursuits, allows us to engage in them with others across tremendous distances in near real-time, and saves us the time we would otherwise spend beating our clothes with rocks at the riverside, instead of pondering the imponderables. Whether you recognize it or not, then, I think "all this freneticism" actually helps you out more than you are likely to ever know.

Mark Miller
Mark Miller

When the web was becoming the dominant app. platform I looked at how it worked, and I hoped I would never have to work on one of those apps. for the reason you described: Http was not designed to maintain state. The only kind of app. that was really appropriate for it was something that could satisfy a submit-response scheme, such as a search engine, or a simple data entry/retrieval app. I agree with the discussion about the ugly hack that is ASP.Net. There was a time when I convinced myself that ASP.Net was a good idea, but the moment I had to design a complex form, I got totally disgusted with it, because everything in ASP.Net was designed for simple forms, where there would be a single submit entry point into the "code-behind" code. The customer wanted several submit forms on one page, and there were several editable tables of data on it. No matter what submit button was hit, ALL of the state on that page was sent to the server, and the "code-behind" for that one page had to sort it all out. I made it work, but it was a real doozy, and I pitied the poor fellow who'd come after me to work on it! When I had to do something similar later, I decided to come up with my own small class framework to make it something sane I could deal with. It wasn't ideal, but it was a lot nicer! Basically, I created a "model" layer to contain my data, and I did some custom data binding to display it on the client. This was in the .Net 1.x days. I would've done this right off in the first instance if I could've anticipated it was going to turn into that mess, but the thing was it didn't turn into the hairball it became until I was well into it, and by then, with the deadline I had, there was no turning back. I know this is an old complaint, but it seems like we developers would benefit a lot by the development of a new, stateful protocol for the apps. that need it, and possibly a new internet-enabled client standard that would allow the kind of UI features we need. I hedge a bit with the latter because I don't know how the RIA thing is going.

santeewelding
santeewelding

All of you: how does all this freneticism help the rest of us?

apotheon
apotheon

The key is to not think of HTTP as being part of the application. It's just another mechanism for shuttling data around. Period. You run server software that can communicate with a client over HTTP. The client runs client application software -- and the client-side scripting is part of that, in a sense. Anything that tries to obscure that too much starts running into the law of leaky abstractions really hard, and problems will arise. That doesn't mean you can't use tricksy hobbitses techniques like AJAX to provide a smooth, pleasant interface for users; it means that the developer, of all people, should know what's going on when two parts of his or her complete software ecosystem are communicating over HTTP, rather than just editing a configuration file and letting the actual software development get handled by dumb software.

Justin James
Justin James

"The real problem, however, is the implicit framework for the basic toolset, an event-driven implicit framework, that insulates a model-view-controller framework from the actual core technology." This IS my point. Stuff like ASP.NET MVC is a disgusting hack, not because the MVC pattern is so awful... but because it is sitting on top of ASP.NET WebForms. ASP.NET WebForms is a disgusting hack in and of itself. They both are totally revolting. Scott Guthrie should be ashamed of himself for inflicting the world with this plague. It's the same issue I have with MVVM in Silverlight. In and of itself... good idea. But it's layered on top of the code behind/event driven model. That's a mess, and it's why the debugger and the tools have no idea what they are doing, because they weren't designed with that paradigm in mind. So yes, while MVC and MVVM may be good patterns, as implemented in the .NET universe they suck, because they sit on top of a sucky tech. I also agree about the HTTP part. Give cares what verbs HTTP supports? Why should I rearrange my world because the HTTP folks TWENTY YEARS AGO, with *an entirely different set of goals in mind* (hint: the "HT" stands for "HyperText"... HTTP is designed to be similar to FTP, specific to delivering documents over the Web... NOT as a programming paradigm!). Read the spec, and you'll see that it is clearly not made for apps. Heck, look at the architecture of Apache to see what HTTP is supposed to do... J.Ja

apotheon
apotheon

> There is no state in HTTP. There are no events. There are four verbs and that is it. GET PUT POST and DELETE. HTTP is just a protocol. It is not a programming language or framework. The lack of sophistication you lament is due to the fact that if you want something elegantly programmatic with which to build applications you need a lot more than just a protocol. Your complaint that an event-driven model mapped to a particular protocol is an "ugly hack" seems to be based on an expectation that a simple protocol should be a lot more than it is, and I find that odd. Things get into the range of a dirty hack when you start building development models on top of conflicting development models, which is pretty much what Justin described. ORMs are dirty hacks made necessary by the requirement for relational performance behind a programming paradigm that makes development sustainable; the current "secret sauce" Microsoft development frameworks layered over an event-driven model are dirty hacks made "necessary" by faddishness. That's not to say that the model-view-controller pattern is bad. It can be a wonderful thing. It should not, however, be implemented as a framework layer of abstraction over a conflicting model for application development. In fact, I think you're both missing the key problem here. You think there's no problem; Justin thinks the problem is the framework. The real problem, however, is the implicit framework for the basic toolset, an event-driven implicit framework, that insulates a model-view-controller framework from the actual core technology. This is the danger of technologies like Silverlight and Flash as development tools; a core toolset and a development model are mixed together, then treated like a general purpose development toolset. Eventually, Adobe started learning the error of its ways, and exposed more and more of the underlying development toolset. Silverlight is still trying too hard to be both a single integrated entity from foundation all the way up to development model, while serving as all things to all people via the mechanism of frameworks as layers of abstraction over its inherent, implicit framework. The reason the model-view-controller model works well for Rails is that Rails is the only framework involved. The reason Microsoft's model-view-controller model framework is kind of a mess that insulates the programmer from his or her own work is that it's layered on top of another model, with some dangerous impedance mismatches between the two. > The original developer is long gone, you are given the task of adding the newly acquired company data to the existing app. > > PRAY that the original developer didn't use WinForms. PRAY that he used patterns like MVC and MVVM. If he did, you can probably finish in days rather than months. I have a better idea. Pray he used something that doesn't require the kinds of dirty hacks that are necessary to get a good development model in place. Pray, for instance, that he used Rails, or Catalyst, or Django, or Merb, or something else that isn't a layer of abstraction built on a layer of abstraction with almost diametrically opposed goals. At least . . . that's my take on it, mostly as an outsider. Hopefully I didn't fundamentally misunderstand something here, 'cause it'd make me look like an ass in this case.

terjeb
terjeb

I'll leave MVVM for another time, but I would like to comment on MVC, which is currently my second preferred framework for web dev. You say that MVC is a hack on top of the code-behind stuff from ASP.NET and the event-driven model. I think you are 180 degrees off. The event model is an UGLY hack on the HTTP model. There is no state in HTTP. There are no events. There are four verbs and that is it. GET PUT POST and DELETE. ASP.NET MVC is built on this simple fact and it makes for an very maintainable, extensible and joyous framework to develop for. Web-forms encourages, and over time mandates you develop unmaintainable messy applications that nobody can modify except the original developer. There are hacks and patterns that will alleviate this somewhat, but only to a tiny amount. ASP.NET MVC on the other hand is easily maintainable, anyone who has done any MVC work can jump into the code of any other MVC developer and INSTANTLY understand the overall workings of said application. That is not possible in Web-forms. Requiring proper patterns for development, and MVC is a proper pattern is a good thing. MVC is a very good pattern, which is why it has survived for decades as the preferred pattern for this type of applications. Ruby on Rails, ASP.NET MVC and other tools that not only encourage, but basically require the use of a good pattern will save companies millions in the long run. Application maintenance cost is many orders of magnitude higher than the development cost. Using proper patterns reduces maintenance cost. ASP.NET MVC, Rails, Spring MVC etc, significantly reduces the investment needed to use patterns that enforces application maintainability. Typical enterprise scenario: - Developer puts together a quick solution for a specific problem, interfaces with one other enterprise app and MS SQL. - A year later the quick solution has grown to be a mission critical application with a number of features. It still interfaces with one enterprise app and MS SQL. - Two years later the company acquires another company. Suddenly the mission critical app has to interface with another enterprise app over another interface and also an Oracle DB and a My SQL DB. - The original developer is long gone, you are given the task of adding the newly acquired company data to the existing app. PRAY that the original developer didn't use WinForms. PRAY that he used patterns like MVC and MVVM. If he did, you can probably finish in days rather than months. I just finished a task like this, we added the new data with ZERO changes on the client and ZERO changes in the business layer.

herlizness
herlizness

Strictly speaking, my comment has nothing to with the thread at all. It was just a moment of levity, grafting CS terminology onto the language of finance; foreclosure and eviction are indeed "patterns" ... routinized methods for dealing with payment delinquencies. But, whenever possible, the "workout pattern" actually is more efficient for lenders and servicers. Put simply, it's nothing more than modifying the terms of repayment via changes in interest rate, principal reductions, backloading of payments, etc. I know you're not in control of the business patterns; all the same, I've always found it useful to have as full a knowledge of the client's business as I can reasonably attain. In some cases, when I understand the business of the client, I decline their business entirely; as a matter of principle, I don't wish to be involved in it. That is not to suggest that you should do so in this case as I would not presume to know anything about your company or personal situation.

Justin James
Justin James

... I looked into becoming a repoman or a bondsman. At the time, they had some appeal to me, but then I remembered that here in SC, folks like to shoot the repoman under the "assumption" (wink wink) that he's a car thief. J.Ja

Mark Miller
Mark Miller

I took it to mean, "Workout," as in, "Renegotiate the mortgage," or, "Work out a payment plan that both parties find amicable." It sounds like implementing the "workout pattern" is up to your bosses. In one sense it sucks that an economic downturn can result in more work being needed in an area that involves people losing their livelihoods. I say this because I assume in normal circumstances your particular project wouldn't be needed, because the number of foreclosures that needed processing would be small enough for a paid staff to handle without the aid of a machine, beyond record entry and retrieval, perhaps. At least you have the right goal in mind of avoiding errors. Foreclosure errors were in the news back in the autumn of 2010, and they were occurring because banks were using overworked employees to process them. On the other hand, I see what you're doing as one of the beauties of market economics, because it is by different groups trying out different ways of solving a problem that the economy will ultimately recover, and right now one of the big problems is how to deal with people who aren't making their mortgage payments. It's too bad that right now it seems like a zero-sum game. Even in better times it can be like this, though, with improvements in IT efficiency displacing workers.

ExEm2SS
ExEm2SS

Hi Justin: I think it sounds like we agree on many points. It sounds like you are referring to the Passive View pattern which works for just about any application.

ExEm2SS
ExEm2SS

Not sure what your response has to do with this thread, but I will respond. The foreclosure business is not pretty and not something to be proud of, but it is necessary. That said, it is my job to build an application that ensures the foreclosure is carried out legally and properly. My worst nightmare is for the wrong person to be evicted, or to be evicted after they made a payment because of a bug in our application. This is why there is no margin for error. People's homes and lives are at stake in our business. This is not something I take lightly. I'm not sure I understand your workout pattern reference. I

herlizness
herlizness

> tsk tsk ... foreclosure and eviction are both inefficient patterns; people need a place to live ... try the workout pattern instead

Justin James
Justin James

... isn't the concepts. I agree, they are good ideas. The problem is when they are a hackish overlay on top of a system that flatout does not support them. ASP.NET MVC is hackish. MVVM frameworks on SL are hackish. The reason is that they are trying to work around a system that is based on the code behind system (the event driven model). By the by, there is no reason in the world that you can't run unit tests with a straight code behind system. If you've been writing your code correctly, the event handlers in the code behind don't do much of anything other than collect data from the UI and pass it to a separate function which can be easily tested. In fact, that's why much of the rah-rah-rah around MVVM in SL and ASP.NET MVC baffles me: the address issues that in large part don't exist in well-written code, even with the event driven, code behind model. I was taught very early on in my programming life to write code with strict separations of concerns. I was taught refactoring before it was popular. I knew about dependency injection long before people were calling it that. These were all taught to me in languages like BASIC, COBOL, Pascal, and Scheme running on mainframes... in the early 90's. And that's a lot of the reason why I don't get it. There's a way to write good code, and there's a lot of ways to write bad code. It seems like everyone I talk to who pumps up these things is trying to work around a lot of bad code written by mediocre developers. And again, I have NOTHING against MVVM and MVC as concepts per se. But I do feel that, as implemented by various frameworks as overlays on other systems, they feel like a kludge. You talk about maintenance and debugging issues, they bring along plenty of baggage of their own, because the tools don't cooperate with them too well. This is one of my fundamental issues with LINQ (a tech that I really like, incidentally). If you want to know *why* the results look the way they do, you can't step through and see what happened. It's like trying to debug regex's (a former specialty of mine). All you can do is stare at it until something "clicks". SQL is the same way. Technologies based on state machines are cool, until something goes wrong if you don't have the right tools to inspect the state machine, and with these bolt-on frameworks and systems, the tools just are not there yet. J.Ja

TexasJetter
TexasJetter

I remember having some of the issues you describe with ODBC as well, but ours was with an ODBC link to a FoxPro database. Glad those times are long gone. The issue I was describing was actually filtering the dataset down. It was just a simple test Silverlight app that looked at our project table and filtered the results based on the Project Manager. If I picked a PM that only had a couple of hundred projects it worked just fine. But as soon as I selected one that had more than 1,000 projects it broke. A little research led me to believe that Silverlight has a setting in the app configuration file that set a size limitation (like the ASP.Net file size upload limit setting), but my short research did not resolved the issue. Since it was just a test app, and I had other things I need to get done I dropped it. At some point I may have to resurrect the issue?

Mark Miller
Mark Miller

[i]I have set up a Dev copy of SQL 2008 for testing and have seen a little of what you are referring to, although I have a strange issue of the app breaking when retrieving over 1,000 records[/i] This was some years ago. I forget which tool I was using. It was a utility that came with SQL 2000 (SQL Explorer?). I could execute a query in it against the database, but if the query drew upon too many records (say, maybe 1,000), I would get an error dialog saying that the request timed out. I recall it mentioning this had to do with ODBC. Anyway, it seemed like the technology could only handle a transfer of so many records, and then it would just crap out. So it was best to keep the request down to a relatively small number of records. I agree with Justin's comment. Retrieve the data in batches. Maybe there's a way to do this using ranges of record counts in the request? Anyway, I remember when I first encountered this limitation with SQL Server I was really surprised. I had worked with Oracle's RDBMS for a few years before that and never ran into this limitation. I could request as many records as I wanted without a hiccup. I know you said you're a Microsoft shop, so you'd probably rather find a way to deal with your issue using SQL Server, but in case you're curious, the thing with Oracle is you have to know where to go to develop your knowledge base, or else you're SOL. For me, the best resource was the Osbourne series of books on Oracle technologies and strategies.

Justin James
Justin James

Yes, you do need up end versions of SQL Server... still being on SQL Server 2000 is scary, by the way... I would not expose that to the Internet in any way, shape, or form if I could help it. Web Service scalability, in general, depends on what you are doing with it. The more you can keep your I/O short and sweet, the better. Why? It has to do with Web server architecture. Web servers like to handle a low ratio of requests per core, simply because a ton of context switching is really counter productive. So the quicker you can get your data in and out, the more requests you can handle. This is one reason, for example, that you'll see some services set up to "page" data (ie: "I request results 100 - 200 for this query I ran"), or consumers do a form of late loading for long requests (where the service will give them an index of the results, and as they actually need results, they request the items one by one or in batches). The other scalability issue is statefulness. If your Web Service needs to maintain state between sessions, and that state can't easily be put into a central store, your options on load balancing are much more limited. So... the upshot here, is that while Web Service can have scalability concerns, they are greatly mitigated with architectural prudence. J.Ja

Justin James
Justin James

Sometimes, I think concerns can get a little TOO separated! That's what makes all of this binding stuff, MVVM, etc. difficult to debug. When you aren't getting the value you expect, it is really impossible to track down where the value is coming from, for example. J.Ja

Justin James
Justin James

Web services have come a long way on the security front. Some of your choices (at least with WCF Data Services): * HTTP level authentication (which includes the use of client certificates) * SOAP level authentication (not 100% sure how different that is from HTTP authentication, I haven't read the SOAP protocol) * In-app authentication (pass credentials as part of the request, the application verifies) That's a pretty good selection, with enough flexibility to do what you want. WCF Data Services lets you set permissions as fine grained as a DB would (on a per-call, per record/column basis if that's what you really want). J.Ja

apotheon
apotheon

I wasn't really disagreeing with you in any way or attacking your statements; I was just trying to provide some context. You're right about organization internal application development, and I said something to that effect in my own ramble on the subject, too.

Justin James
Justin James

I *didn't* say that 70% meant "go ahead and use on the public Internet". I simply put that out there as a reference so others can make decisions. I wish I knew the reference I got that number from to inspect the methodology; I'm sure that, like any other usage stat, it's highly subject to your sample audience. What I *did* say, though, is that for internal applications, deployment rate is irrelevant, because sys admins have tools for pushing out installs and do it all the time. J.Ja