Even as I study (ever so slowly) for MCPD certification for my own reasons while I'm at home (spare me the biased anti-Microsoft flames on that, I don't care) I'm finding that Microsoft end developers (Morts) and Microsofties (Redmondites) alike are struggling with the bulk of their own technology and are heaping up upon themselves the knowledge of their own infrastructure before fully appreciating the beauty and the simplicity of the pure basics.
This article covers the reality TV show Start-Up Junkies. The show includes lots of .NET goodness and with the power of the internet you get a lot more background information on their partnership with MIcrosoft. There is a lot of information here for anyone working in a Microsoft based startup.
Microsoft's .NET framework on Linux is getting a big boost with the official release Monday of Novell's Mono 2.0.
The Mono 2.0 release is Novell's open source implementation of Microsoft's .NET platform. With the latest version, the gap between the two is getting smaller.
Even though Mono 2.0 is compatible with Microsoft's .NET 2.0, it's not in full compliance with the latest .NET releases from Microsoft (NASDAQ: MSFT). The Mono effort is important as it is intended to enable .NET (define) applications to run on Linux.
In this video Anders Hejlsberg takes a look at the future of programming languages and sees the trends; declarative, dynamic and concurrent. As the chief designer of the C# programming language and a key participant in the development of the .NET Framework Anders Hejlsberg has a lot to say about this development - not just as a wish but also as something that can be realized.
Microsoft’s recent decision to include jQuery in the ASP.NET development stack is pretty exciting news. I’ve been using jQuery for a while now, and all I can say about it is that it makes JavaScript fun. You can use it to add some pretty impressive effects to your web pages with only a couple of lines of code, and you have less to worry about as far as the idiosyncrasies of cross-browser detection are concerned. In the past year or so it’s become pretty popular and even something of a de facto standard in many ways, probably best described as JavaScript’s answer to Linq. If you’re a web developer and you haven’t yet come across it, I really would encourage you to check it out — you’ll love it, even if you hate JavaScript.
Sorry guys, but it's time to rant. I see so many people needlessly complicating their architecture and deployment by insisting on using separate assemblies for every layer of the app or even doing the trick where interfaces are in one assembly and the concrete classes are in another assembly. Stop it! It's a waste of time. Logical de-coupling from UI to business logic to infrastructure to the database is very important, but using separate assemblies doesn't do anything to guarantee that decoupling. You can separate your assemblies all you want, but making the UI depend on the implementation details of the business code in the other assembly is still harmful tight coupling
I am writing this article as a sequel to the Measuring Programming Progress By Lines Of Code article. Let me please talk about another common metric - measuring the amount of extra hours a software developer has done.
At my current client I’ve got to do mainly maintenance on existing applications. This gives me the chance to look into codebases that have been created by other people and that don’t really reflect how I would write things. That is all good though it gives me a chance to learn new ways of doing things and when I think their way is better I’ll surely adopt.
The idea is proposed that "functional" isn't so much a style of programming as it is an expansion of expressive power in defining functions, that FP is an evolutionary step forward (albeit a large and welcome one), not a revolutionary change that requires us to throw out our old programming models.
If you're like me and have been in the IT industry for 5+ years (me 10), you start to realize that the grass is not always greener on the other side in a lot of shops out there. Before I get to the interview questions, I want to start by outlining the general types of shops and types of problems one can encounter in development shops.
Characteristics of when the grass may NOT be greener:
During my entire development career, hell my development life, I've dealt with programming languages and machines that have allowed me to write less than ideal code and get away with it. As I moved into the corporate world of development, I met your old school developers. When I say old school, I mean COBOL developers. You know what they say about COBOL developers: They are either retired or dead (COBOL developers start writing your nasty comments... now!).