MSDN Magazine

A Tentative Content Plan for 2010

msdnmag — Fri, 13 Nov 2009 01:34:52 GMT

Dear readers, while we could yet make some few tweaks to the agenda, these below is for now the most possible content plan for next year.

Month	Theme
January	Cloud Computing
February	Distributed Computing, SOA
March	Modeling and Tools, Application Lifecycle Management
April	Programming and Design Techniques
May	Rich Internet Applications
June	Performance and Scalability
July	Developing for Office 2010
August	Data-access
September	Concurrency and Parallelism
October	Interoperability
November	Security
December	Embedded Devices and Mobile Computing

The magazine is composed by some few featured articles plus several regular columns. In general, the monthly themes affect mainly to those featured articles better than the columns. But exceptions to this rule may happen, why not, in the sense that columns may also be on the monthly theme or eventually a featured article may be on something else, if we also consider that topic relevant enough.

Are you interested in writing for MSDN Magazine? Did you know that you may do it? We are about to post on how you can submit your ideas, what are the kind of articles we are looking for (in order to increase your chances of being accepted), general styles, length and other aspects.

Stay tuned!!

Lining Up Columns

msdnmag — Fri, 09 Oct 2009 04:17:00 GMT

Continuing with this series on my plans for MSDN Magazine, I’ll address here another question that I’m getting often these days.

While a few posts ago I talked about the mindsets on which my content strategy is to be based, it’s now time to talk a bit about the concrete stuff I’m envisioning, in order to turn my editorial line into something more tangible.

The magazine today is composed by certain regular sections, known as columns, and completed with features: extra articles not tied to any of those columns in particular. In practice, as one of my partners made me notice, columns are less regular than expected as they don’t appear on every issue each, but they actually alternate their occurrences.

In that sense, the idea of reformulating the column lineup has as goal to narrow the set of columns in something that covers the whole development scope, but it also is definite, predictable.

The current alternating column lineup comprises:

Toolbox
CLR Inside Out
Basic Instincts
Data Points
Office Space
Cutting Edge
Patterns in Practice
The Polyglot Programmer
Test Run
Service Station
Security Briefs
Extreme ASP.NET
Wicked Code
Under the Table
Team System
Foundations
Windows with C++
Concurrent Affairs
Going Places
.NET Matters
End Bracket

Regarding the thoughts above, what the reader may expect is some merge between columns of similar kind and perhaps the removal of certain columns whose frequency is beeing remarkably low. In that sense, it is not that we’ll stop publishing that kind of stuff forever but will do it as feature articles, not as regular columns.

What you are about to read now it’s not yet consolidated as I’m still working with different stakeholders in order to arrive at by consensus and cross-validation; ensuring that no gaps will remain unclosed in this content strategy and that the overall plan is realistic. Do you want to hear my early conclusion so far? Making this kind of project plans, dear reader, doesn’t differ that much from making software project plans! Indeed, one have to align expectations coming from different parts, with a particular perspective each. As I don’t want to leave you out of this debate, I’m publishing hear my thoughts in order to get your feedback. Don’t miss the chance and get involved. Be part of the magazine you want to get.

And the Winners Are…

Based on the mindsets and the blueprint sketched in the last post…

Figure 1. A typical N-tier, layered architecture.

… this is a tentative column lineup intending to cover all those aspects that must be present in professional application development. Let’s see:

Application Design. (A little disclaimer first: not only this column lineup is not yet final but also column names would be also subject to rework). A division of labor like the one depicted in Fig. 1 is achievable thru different ways. You may define your layers, assigning namespaces to each, defining interfaces to be exposed between layers (usually lower layers expose interfaces to upper ones but not vice versa), and finally implementing those interfaces in concrete classes. Or you may take advantage of any application framework like Castle Project, Spring.NET, CSLA.NET or P&P’s Enterprise Library.
The purpose of this column is to keep you updated on strategies and tactics for application design and application architecture, as a way to help you achieve decoupled components that will be easier to evolve and extend.
We’ll complete this column coverage by explaining patterns and delivering lessons learned on library design.
Regarding the current column lineup, Patterns in Practice seems to be somewhat similar to the idea sketched in this bullet but perhaps this tentative section of the magazine will be a superset of that one. Cutting Edge, when emphasizing patterns usage seems also to be continued in this new column.
Web Applications. This column would be a reincarnation of current Extreme ASP.NET and as long as I was checking the current one, it won’t vary too much. Perhaps a bit more emphasis on infrastructure aspects that a developer must take into account (IIS, session management for performance and scalability, etc.) but I didn’t have to review too much to find that such content has been being published, actually. Just want to remark that no matter what it happened, I’ll make sure that will happen in the future.
Desktop Applications. In this section, the reader will find information pertaining to client-side deployable applications. In most cases in a fully capable workstation (desktop computer, notebook) but eventually we’ll consider in this category other devices like smartphones, embedded systems, etc.
Will cover here not only presentation layer patterns, techniques and technologies like WPF, Silverlight or Office applications, but also deployment considerations, coexistence with other applications, optimization techniques for footprint reduction, runtime resources, some basic infrastructure concepts for monitoring, virtualization, etc., with their related technologies (Windows operating system, App-V, Forefront, and so on).
I believe that there’s no correlated section today in the magazine. Perhaps a smaller portion of Foundations, particular regarding WPF, Wicked Code (that lastly was devoted to Silverlight, but that column doesn’t have any specific technology behind), and Office Space. I should include Going Places too.
Distributed Applications. We could say that, today, between Service Station and a considerable part of Foundations devoted to WCF and WF, we are mostly covering aspects of distributed applications, service-orientation, etc. However, we must consider that distributed applications are not just made on .NET at every party. While our center of gravity will be in .NET, will consider special cases like, to mention one, Java interoperability, etc.
Regarding the mindset about infrastructure background, will also consider BizTalk Server and other products that cover several related aspects (business activity monitoring, etc.)
We’ll also discuss best practices for distributed applications like the coarse-grain pattern, asynchronism, concurrency, federated identities, etc.
For sure, as told, infrastructure matters. With the advent of codenamed Dublin application server, will highlight its features here, and how developers can take advantage of.
There’s one only case in distributed computing that I prefer to leave aside: Cloud Computing, which it seems that deserves its own column.
Data. It will surely include current Data Points and Under the Table columns, but will also span to other data related topics like Business Intelligence. In professional development projects there are other stakeholders beside programmers, and regarding data in particular, there’s a guy called DBA who takes decision on database-access. As told when discussing mindsets of the next editorial line, we’ll take into account factors like conflicts of interest and other team-related issues.
Core .NET. I foresee here a merge between CLR Inside Out, .NET Matters, Concurrent Affairs, The Polyglot Programmer, Basic Instincts and Windows with C++. With this column my intention is to focus on the runtime platform itself (to mention some, the garbage collector and parallel execution among others), and at the same time on its programming features, particularly those related with expressive power and programmer productivity (like the inclusion of anonymous types, lambda expressions, etc., which helped avoid lots of lines of code). Just anticipating the question “what about dynamic languages? will they be consider too?” my answer is “definitively.”
Meta-Development. Remember the mindset “We, the People of the Project Team”. Consider the development process. Consider the development team and the broader team considering the project leader, security specialist, database-administrator, testers, users, IT Management, etc. Consider communication, conflict resolution between the parties, interests… Do also consider tools to make communication more efficient and the process in general more productive. Regarding this last, we’ll base this column in Visual Studio Team System but will also consider its numerous extensions (MS-owned and third-party ones). I don’t believe we have, in the current column lineup, a similar column today but there are lots of Visual Studio-related articles published as featured stuff (I mean, not as regular columns). However, a subset of this column has been coming for several years now. I’m talking about Test Run column. Testing is just one aspect in a broader, more complex software development lifecycle and we’ll keep this kind of stuff. We’ll complement it with the other SDLC aspects, though.
Cloud Computing. As told before, this is actually a special case of distributed applications. However, the latest achievements on its field (several of those yet not launched but just announced) are keeping this topic as a brand new runtime paradigm. Windows Azure promises a programming model that won’t vary substantially from the current, on-premise-based delivery model. However, despite its well-known benefits in lowering IT costs, there still is certain reactive behavior in moving to the cloud. How to make compatible identities in the cloud and identities in the company domain directory server? How to deal with data stored outside and confidential information stored internally? (a survey showed as result that most of companies are not massively going to the cloud because of the issue of confidentiality). Will finally SQL Azure offer a programming model similar to traditional SQL Server programming or not? How about the development environment? … A lot of concerns around Cloud Computing so it won’t be a bad idea, at least for some while, to keep a column on it. This will include interoperability with other cloud platforms and development languages.
Toolbox. It offers insightful information on third-party tools and gadgets. It has been out there for a long while but typically offering new stuff as long as the rest of the partner ecosystem keeps active and releasing new stuff. Let’s keep it, then.
Cross-cutting Aspects. I’m not quite sure about whether it’s convenient to keep a separated column for cross-cutting aspects like security, performance, scalability, manageability, user experience, fault-tolerance and many others. All these aspects require a specific expertise and I’m sure that any matter expert on a given aspect xx any of these will tell me “you must definitively have a permanent column on aspect xx!!” And they all will probably be right. The point is that I can’t allow infinite permanent columns, otherwise the magazine would have infinite pages (it actually sounds nice, but keep in mind that the subscription price would also be infinite ). Since the year 2000 until these days we have a column called Security Briefs. It doesn’t appear every month but it has survived as possibly no other column in the magazine.
My thought, actually, is that cross-cutting concerns, as they are present at any layer, any tier in the diagram of Fig. 1, they all require different tactics depending on the context you are. For instance, in the presentation layer of a web tier, you must take care about potential cross-site scripting while in the database tier you must be concerned about SQL injection. Both kind of threats are similar in nature and their countermeasures are similar too. But while both strategies are analogous, their concrete tactics vary.
We could move to another aspect. Performance for instance. We may decide to implement caching for any inter-tier communication (client-side to server-side, data-access layer to database tier, etc) as a way to reduce response-time of those request whose response very with a rather low frequency. Like the security example, at an architectonic level the strategy sounds the same, but at a coding level, ASP.NET offers caching techniques that are others than the one offered by the Caching Application Block included in the Enterprise Library or the distributed, rollover features that will offer Project “Velocity”. Principles are the same in any case but some special tuning was made for each context.
For the reasons above exposed, I believe that it could make more sense to discuss cross-cutting aspects as part of the other columns. Or, eventually, as featured articles (articles outside regular columns). It’s perhaps too early to decide. The reader must be sure that, given the case that we don’t include this column, it won’t be a signal that we won’t cover cross-cutting aspects: it will be a signal that we’ll do embedded in the other columns and/or as featured articles. In any case, the online version of the magazine will group articles as a consequence of multi-tagging. That way, you’ll be able to retrieve cross-cutting concern articles as easily as pulling the articles of a given column.

So, I listed ten tentative columns. These are still preliminar and the idea of publishing there was to satisfy the anxiety about what plans I'm envisioning. It will require some reviews, reworks in order to be confirmed. That should happen in the next few weeks.

And, before finishing, what about the featured articles? What will they be on? In principle, they are intended to be based on the monthly theme (I’ll offer a post on upcoming themes soon). That may not be the case for every featured article but, if not, will be just the exception and probably because some of the columns will be also based on the monthly theme. I’ll cover all these in further detail soon.

Thoughts?

Sincerely,

Diego Dagum
Editor Director
MSDN Magazine

A Necessary 101 on Professional Application Development

msdnmag — Thu, 08 Oct 2009 19:25:00 GMT

I’m in the job of establishing partnerships with different stakeholders (authors, readers, vendors, colleagues, etc.) in order to consolidate the vision depicted in my last post about the editorial line I’d like to promote thru this magazine.

In order to defend my ideas about column lineup, editorial style, bill of materials, etc., I need to start from a common ground and that ground is the goal to make this magazine an indispensable reference for success on professional, world-class application development.

This post won’t talk too much about the magazine but about such kind of applications, mainly for those who are not familiar.

Let’s start by checking back the diagram I showed in that post on editorial mindsets:

Figure 1. A typical N-tier, layered architecture.

This diagram shows a typical, modular multichannel architecture at a very high level. With more or less degree of similarity, real-world application architectures look like this one.

Let’s start by saying that these are N-tier applications, in the sense that the application doesn’t comprises a single executable file with its set of libraries but different tiers are executing different parts of a distributed application, each part consisting in an executable process with its associated libraries. This subdivision obeys to the goal of making the application maintainable by keeping cohesion high and coupling low, in a way that components can be easily reused and the impact of later changes is narrowed to a small portion of the application and not the whole.

Technical and Business Channels

From a user perspective, the application is accessed through different channels (see Fig. 1). Channels, at a technical level, are typically web (browser-based channels), desktop (fully deployed applications), mobile, embedded devices, etc., or even third party applications, which access our application by consuming services offered by this latter. From a business perspective, channels are better known as “home banking”, “retail”, “branch”, “POS”, “ATM” and other business-related terms but any of those, at an implementation level, falls under some of the technical categories.

Tiers (Processes)

Users typically see the channel they use as "the entire application", but beyond that front-end we may find a series of one or more physical tiers, running other parts of the application. Some of those tiers could be out of our scope. Typical examples are the database or a service offered by a third party that will be consumed from our application as a black box.

I’m not including those external tiers in this diagram but just (at the bottom layer in Fig. 1) the bound of our application that is responsible to deal with them.

Tiers show the distribution of an entire application at a process-level. In other words, different tiers run in isolated processes that may or may not be in a single physical equipment.

Layers (Modules). Difference with Tiers

Tiers, at once, are composed by layers. Layers show modular, logical distribution of the components. Classes and interfaces in a given layer are supposed to work for an overall responsibility (i.e. user input, presentation, data-access, service delivery and several other ends).

That said, while tiers are defined based on expected workloads, required capacity (both attributes based on the application during runtime), layers are chosen for the sake of application comprehensibility from a development-time (not runtime) perspective.

Layers may depend on external APIs to perform their tasks. For instance, a data-access layer could be based on ADO.NET components while a presentation layer could rely on WPF or ASP.NET MVC. However, there is a sacred layer that should not depend on any external API in particular and is the one in the middle, known as domain logic layer. That is the layer that backs the abstract model of our business goal. Its components are typically Customer, Invoice, Product, Address and other real-world nouns; and it’s expected to remain invariable as long as domain rules don’t change. Particularly, it’s expected to remain invariable if tomorrow we modify a data source from XML to ADO.NET, or replace the user interface by adding a RIA channel (i.e. Silverlight, Adobe Air, etc.)

Layers and its contained sublayers are like namespaces that one could explore deeper and deeper. At some point, you’ll find classes, interfaces, structures and other .NET elements. Layers may occasionally span across tiers. For instance, we could find at both margins, server-side and client-side, some domain logic layer. It’s not necessarily that the client-side only contains presentation logic, especially if we want to allow some minimal level of offline capability. You may find other examples in your distributed applications.

All this organization of responsibilities pay off when new end-user functionality (i.e. use cases) needs to be added: it’s easier to determine whether new UI components must be developed, whether the data schema must be updated, new domain logic must be added, etc). It’s also easier to assign the resulting components to be created or recoded to different matter experts, in a way similar than the way graphic designers prototype UI components whose behaviors are coded, asynchronously by software developers. And last but not least, when organized this way, applications are more easy to be tested, as we could test the domain logic without having to set a database for data retrieval, and so forth.

Where to Get More on Application Architecture

Depending on your experience, a blueprint like this one is possibly not new for you. Whether that is the case or not, if you want to get more details on implementations aspects, I strongly suggest you to take a look to the guide published by Patterns & Practices on Application Architecture in January 2009. For the moment, let’s just say a couple of more things:

Cross-cutting Aspects

This model completes with some cross-cutting concerns. Those are aspects that will be present at any level (tier, layer, etc.) For instance, we cannot restrict Security constraints to a lost, final layer in a back-end tier because that way any single request must traverse the whole architecture to confirm that the user was not, actually, authorized to perform certain task. We are certainly applying security measures in the UI when we avoid to show the password that is being typed. We are also applying security measures in the data-access layer when we “purify” input parameters prior to call a stored procedure. We still apply security measures when we confirm, at any tier, that a sensitive request is coming from a trusted source that is also authorized for that kind of operations, and so on.

Like security, there are several other cross-cutting concerns to care about. Performance, fault-tolerance, manageability, health checking, etc., are just some few examples of those.

Software Development Lifecycle and Application Lifecycle Management

The other thing not shown in Fig. 1 is related with the development process. While the center of gravity won’t move from the development phase, it’s not bad to consider other stakeholders in the value chain and our relationship with them. How do we make components that are easy to test in an automated, repeatable way; how do we design our low-level libraries to maximize reusability while decreasing the complexity of the components that will use those; how do we estimate timescales; etc. The process is as important as the outcome that is expected as a result of it because brings predictability to the rest of stakeholders (particularly users and sponsors like the IT management or other non-IT managers).

In that sense, there exist tools that help manage the overall application lifecycle process, while enabling different stakeholders perform their core activities along the different lifecycle instances.

Epilogue

In this post, we have surfaced a blueprint that it has been for a while a comprehensive base for professional development. The way it was presented is a least common denominator as you’ll find variations in real-world implementations (either in the way layers were assigned to tiers, or how tiers were chosen, etc.)

This common denominator set a ground in which the content plan for the magazine (monthly themes, column lineup, etc.) will be stood up.

File > New > Project: Developing a New MSDN Magazine!!

msdnmag — Wed, 07 Oct 2009 14:00:00 GMT

For some while now, my colleagues were asking me about my plans for the magazine. In other words, my editorial line, editorial style.

This post is all about it.

While I’ll plan to keep magazine’s main structure composed by regular columns and featured articles, and I have no intention to touch the current technical depth (explicit coding in articles, downloadable code samples, etc.) I’ll put some emphasis based on five mindsets that I'll explain shortly.

Figure 1. A typical N-tier, layered architecture.

This is a simplified diagram of a typical multichannel architecture. Real-world architecture diagrams share some similarities and possibly some few variations with this diagram. I assume you are already familiar with this schema; if that is not the case or you prefer a more detailed explanation, I posted a 101 here. But the important thing to know here is that when you already have a blueprint to base your application on, adding new end-user functionallities (i.e. use cases) is a straighforward job: the blueprint already prescribes you which spots must be filled, which components must be provided and with which responsibilities each. This makes me come to the first mindset:

1st Mindset: Architectural Consciousness

ASP.NET won’t prevent you to issue a database command right from the page itself, or it’s code beside however… it’s that good? It may work in small, controlled, non-mission-critical applications but the design principles that are being violated there are a basic two: high cohesion and low coupling. In that sense, dear reader, it's my intention to show you technology usage under the frame of a diagram like the above one. Thus you'll find where is the right place to put data logic, how to deal with cross-cutting concerns like security or quality attributes (performance, user experience, and so forth).

For sure, we’ll still keep code examples lighter in that sense, as samples are to help you focus on a detailed aspect of a given technology. Once you got the point with code samples, we’ll help you understand where that technology or technique fits in a typical world-class scenario. Thus, application architectural consciousness is the first mindset I’m taking into account for my editorial line.

But application architecture is just one aspect. The diagram above is oversimplified and doesn’t show details on how tiers communicate. For that diagram, was intentionally made like that to help you focus on functional aspects. Once you got those, you’ll need sooner or later to be aware about other aspects that are present when you want to put all these pieces together.

Let’s imagine for a while that we are talking about a deployable desktop application (a desktop client-tier above or, simply, a desktop channel). We may focus just on presentation aspects like new Silverlight features or data binding in WPF, but in order to complete the panorama for that kind of applications, we must also consider deployment conditions, subsequent releases, coexistence of different versions, coexistence with other applications in the same workstation (with possible incompatibilities, resource allocation issues, etc.) and a long list of potential issues that may arise.

It may be argued that several of those issues must be solved from the infrastructure, being therefore part of the TO-DO list of an IT Pro, not a developer. I admit it. It’s not my intention to make you an IT Pro expert and we already have a prime magazine for IT Pros: TechNet magazine. But just to broaden your vision about certain tactics beyond the scope of the development camp, that may save you a lot of man-hours in trying to tackle the issue by coding. So, if the first mindset was “application architecture consciousness”…

2nd Mindset: Infrastructure Awareness

We (Microsoft) realized that we were not doing a good job these last years in the strong, all-or-nothing content segmentation we delivered through either MSDN or TechNet but almost never through both. We were segmenting our audience in developers and IT Pros, assuming that any possible intersection between those two sets was, in the best case, pretty thin. Occasional.

In the times to come, dear reader, this won’t keep being the norm as reality has shown that, depending on the size of organization, its IT departments, etc, two or more roles may be played by a same team member (for instance, in my personal case, I played at the same time the architect role while taking care of the IBM WebSphere application server in production).

We won’t merge MSDN and TechNet, for sure. We just want to avoid developers coding low-level components like tracing and monitoring logic in their applications because they ignore that they may generate events to be captured either by the operating system or a system management tool like Microsoft System Center or its competitors. We want you, developer, to know that despite ClickOnce is a smart, easy way to deliver applications, it's not the only one and in certain scenarios it could have limitations. For those scenarios there exist other techniques not-based in Visual Studio but in other products in the Microsoft platform. We won't explain those techniques in detail for you but we make sure that you can find more information about those techniques easily if you want.

In fact, in real-world applications, strategies comprise a series of tactics. Some being developer practices, some being IT pros ones. Which one is easier to apply, more cost-effective, etc. will depend on the context, but being aware about all those is a great starting point to understand your strengths, your limitations and be ready to raise your bar and get ready to grow.

Enough, for the moment, with application architecture and infrastructure. Let’s now talk about about problem solving. It’s pretty common to say “who only has a hammer, thinks that every problem seems a nail”. A friend of mine also told me “if you learn that a developer just read GoF book on design patterns, don’t let him/her design your next applications.” What my friend meant was that the degree of excitement everybody got after reading that one or any other book on application design was a bit damaging in the short term. Indeed, the anxiety to put in practice those concepts just acquired betrayed us pretty soon, making us adopting a supposed solution for what was not exactly a problem. Or at least, not the problem that solution solved.

The GoF is just an example, but this happened with almost every new concept we acquired (AOP paradigm, MVC presentation pattern, Composite Application Block, …) The third mindset, in that sense, is all about taking right technical decisions.

3rd Mindset: When and When Not, Why and Why Not

The problem of applying wrong techniques or technologies is very often complemented with the overdose symptom: applying a right solution but in excess. An example? Web services. They are an adequate solution to make interoperate distributed applications, mainly when they were coded in different platforms. However, calling methods between different tiers implies a reformulation of the communicational model. In other words, while we can make applications “converse” we shouldn’t make them “chat”. Otherwise, message marshalling/unmarshalling, serialization/deserialization steps will undermine the latency and users patience. Worse, we may later extract the wrong conclusion if we end up by believing that we should have get rid of web services.

To avoid misunderstandings, we’ll tell you not just the what and how-to of technology. We’ll now put some emphasis in its when and why. And for sure, we’ll do that same regarding their negatives: what not to do, how not to do, why not, when not.

Enough said regarding architecture, infrastructure and problem solving. Let me share now some thoughts about the environment.

4th Mindset: We, the People of the Project Team

Are we, the developers, the only people in this world? In world-class projects, aren’t there other stakeholders in the value-chain? Certainly not: there are not only more people but also processes in place, intended to estimate, measure and control the application lifecycle. We, the developers, are a substantial part of that process and without us no software can be delivered. But as we are not alone, we must be conscious that other stakeholders in the value chain might take decisions that could affect the way we develop software.

Examples are several and I’ll tell some here but I can imagine that you will immediately remember your owns.

A DBA prevented me to use an object/relational mapper (those days the most evolved one, with several books written about it) because its lack of support for stored procedures obliged him to open the database security not just at a table level (increasing, thus, the surface attack and consequently the risk) but also accepting commands generated on the fly by the O/R-M. As that data-access strategy was generated by the application on-the-fly (during runtime), he had no chance to tune the commands the same way he did when already enclosed in stored procedures. We had a bitter discussion. Each one, explaining the benefits of his own approach. I told that the O/R-M was helping me save lots of hours of data-access logic development. He said that we were to pay that saved time forever when the application was in production, plus the security risk. We escalated the problem to the management. No matter who was right, he won. If we were discussing about development techniques, the management would have probably supported me. But we were discussing about the database and that guy, coincidently, was the database administrator (where you wondering what "DBA" stood for?).

In that same project I tried to apply an agile approach. It seemed to be the perfect environment to do so: a small team, everybody coding (including me who was playing an architect and project leader role, all at once). Users were fascinated with the dynamics of the methodology: prototypes that were at the same time executable and incrementally incorporated new features (user stories, in the jargon). We were forced to stop and switch back to a waterfall approach. Why? Because despite the support of mid- and low-level users, not just the IT management but also managers in business departments were anxious to get a fully detailed project timeline with deliverables, milestones, etc. To make things worse, one of them swung by one of his subordinated and saw a running prototype. The same that users were excited about. It was just that this guy was not only not excited, but he also made a very bad publicity about the project and myself as a development manager, telling that what we were delivering was tremendously far different than what they were expecting and I had promised during early phases. The more I tried to justify and explain the methodology, the more the board got scared. Checkmate in that scenario.

The moral of the story is not that you shouldn't apply an agile approach: the moral is that whatever you do, you'll find other stakeholders and everything may be subject to a negotiation. So be prepared to negotiate, to convince and to conceal, as clearly we, the developers, are not alone in world-class development projects. MSDN Magazine will provide as part of the coverage on technologies, impact on other stakeholders and potential conflicts of interest.

And last but not least…

5th Mindset: Solutions for Today and Tomorrow

Regarding the timeliness of our stuff, not just the magazine but Microsoft in general, we got some criticism based on the fact that we make extent coverage on technologies that are still evolving, in detriment of the ones that are already out there. As evolving technologies are not yet released, readers can’t do too much but wait until that happened. Coming back to the previous point, in several organizations we, developers, are not allowed to deploy betas, CTPs or any other early-access bundles (at least not in mission critical applications). I'll take that into account so while I won’t completely remove that kind of upcoming stuff (as we want you to get a glimpse about roadmap and future of the .NET platform), I’ll narrow the amount of such kind of information per issue, making sure that most of the core is immediately actionable in your rolled out projects.

Wrapping Up

I told you, dear reader, about the mindsets I’ll apply while directing MSDN Magazine content plan. We’ll try at any time to put technologies under the frame of a broader scope, in terms of application architecture, infrastructure platform and the project team. We’ll do also emphasis on best/bad case scenarios of technologies and techniques, taking care about a reasonable balance between released vs. upcoming technologies.

In upcoming posts, I’ll describe a tentative column lineup, community participation in the content acquisition process and changes in the magazine website.

More to come!! Keep in touch!!

Sincerely,

Diego Dagum
Editor Director
MSDN Magazine

MSDN Magazine Gets New Editor (Introducing Diego Dagum)

msdnmag — Mon, 28 Sep 2009 18:05:00 GMT

Hello, everybody.

Mi name is Diego Dagum and I recently became the new editor director for MSDN Magazine.

After two years of leadership, former editor Howard Dierking decided to accept a new challenge, so we were working together these last weeks in the skill transfer.

I’ll share some facts about me, my background as a developer and as an editor. In later posts, I’ll let you know about my editorial line for your magazine.

About me

Born in Argentina, I got my bachelor degree in Computer Sciences in the University of Buenos Aires (UBA).
I started as a developer for professional, enterprise projects in the early 90’s, almost twenty years ago. I can tell you, dear reader, that I have coded in a large variety of programming languages. Since relics like FORTRAN or Clipper (and other xBase dialects), living-deads like COBOL (I had been told in the University those years that was not being used anymore in the industry… allo? ), complex but politically correct like C-Language and, closer to these days, C# and Java.
In fact, before joining Microsoft, I was a Java developer with a very active participation in the Java community. I’m proud of having presented a paper in the 1st Conference “Principles and Practices of Programming Java”, in Dublin, Ireland, in 2002.
You may imagine, dear reader, that having been involved in enterprise, often mission-critical development projects made me, as the time went by, not just a senior developer but an application architect. I promise you, dear reader, that in the new course of MSDN Magazine you’ll learn not just about the latest development techniques on the MS and particularly .NET platforms but I’ll help you plan your career in order to think as an architect in your next projects. The application architect role is the natural evolution in the developer career path, after senior developer or developer lead.
I’m a MS employee since the end of 2004 and I started as a technical evangelist, fostering .NET adoption for world-class, mission-critical projects. While .NET had been out there for two years by then, in the enterprise sector didn’t have yet massive adoption and IT managers were, therefore, not yet decided to use it for line of business applications. This has a lot to do with my story as an editor, so I’ll start covering it in the next bullets.
I started compiling every month the 10 most important news, relevant for application architects no matter the platform they were working for, and sending that as a newsletter. As a value-added, I started blogging every week explaining certain architecture trends in my own words and exclusively for my own audience (a few corporate accounts in Latin America).
When the news was told in Microsoft headquarters, I soon became content strategist for the Architecture Center in MSDN. The experience was something new for me, as my main background still was in application development, not content creation.
However I was learning all the tricks of the trade by not just managing the content plan for that website but also as content owner for the Architecture track at North America TechEd conference.
Working with authors, technical writers, and other content-related professionals for some few years opened for me the doors to the editor role in The Architecture Journal, a Microsoft magazine on architecture trends, based on community contributions. The Journal comes every quarter and despite I took now this responsibility, there are –for the moment- no plans to remove the Journal duty from me. In other words, I’ll lead both magazines.

This is, in brief, my story as a developer and as an editor. In subsequent posts, dear reader, I’ll reveal details on my editorial plans. I hope you get easily excited when you learn about these!

Sincerely,

Diego Dagum
Editor Director
MSDN Magazine

brownfield development – other ideas?

hdierking — Thu, 03 Sep 2009 02:21:38 GMT

If you haven’t been following it over the last couple of months, we’ve been running a series of articles about brownfield development – authored by James Kovacs, Kyle Baley, and Donald Belcham. The big idea here is that rather than have yet another article or set of articles about implementing some new technology from the ground up (and usually in some kind of contrived scenario), we wanted to show how you can drive incremental improvements into existing codebases (hence the term “brownfield” as opposed to “greenfield”).

For the first of these series’, we wanted to address Web development – traditional ASP.NET development to be more specific. Therefore, we have taken an existing open source project, ScrewturnWiki, and have systematically refactored it along a bunch of different dimensions to produce the following.

Getting Your House in Order	This is part one of a multipart article series about improving an existing "classic" ASP.NET Web application. This first part helps to get your house in order with good development practices on an existing codebase, including version control, issue tracking, and automated self-contained build scripts. ASP / ASP.NET; Test / Debug; Web
Testing	This is part two of a multipart article series about improving an existing "classic" ASP.NET Web application. This second part focuses on automated testing. ASP / ASP.NET; Test / Debug
XHTML and CSS Improvements	This is Part 3 of a multipart article series about improving an existing "classic" ASP.NET Web application. This third part focuses on XHTML and CSS. XML / XSL; Web; ASP / ASP.NET
JavaScript improvements	This article will focus on refactoring ScrewTurn Wiki’s JavaScript using jQuery, and testing it with QUnit.
Improvements Using jQuery and jQuery UI	This is part 5 of a multipart article series about improving an existing "classic" ASP.NET Web application. This fifth part focuses on jQuery and jQuery UI. ASP / ASP.NET; Web
Separation of Concerns	This is part 6 of a multipart article series about improving an existing "classic" ASP.NET Web application. This installment focuses on improving separation of concerns in Web applications.
Death of a Singleton	In part 6, we moved away from the UI a little and worked more in the code behind the pages. In this article, we’ll continue that work and focus on a specific pattern that is used through the codebase: the Singleton. ASP / ASP.NET
Disentangling Our Tangled Web	This is part 8 of a multipart article series about improving an existing "classic" ASP.NET Web application. This installment focuses on better ways to wire together loosely-coupled applications using dependency injection and an inversion of control container.

So as we bring this particular series to a close, I have 2 areas where I would love to get your feedback.

First, what about this particular series worked – what didn’t? Did you like the intermingled videos – was it helpful that you could also read the articles on Channel9 – did you even notice?

Second, I think that the whole “brownfield” series concept is a repeatable one. What other series’ would you like to see? Some things that come to mind include:

Breaking a monolithic architecture in to something more service oriented
WinForms refactoring – could go a bunch of different ways here
Leveraging the cloud in existing apps
Bring exposing workflows as first class citizens
etc?

Thougts?

2010 Column Planning

hdierking — Sat, 08 Aug 2009 02:54:41 GMT

It’s that time of year once again where I go through my column lineup to see how individual columns are performing and then use that data, along with various other inputs (like what topics I think are emerging and want to get ahead of, etc.) to determine next year’s column lineup. I want to extend my process to you and get your feedback on which columns are working well and which ones aren’t. Additionally, just to give you a bit of additional insight, here is some of the data that I’m looking at as I go through the process. Obviously, this is just one dimension of performance, but it’s also one that has a pretty large sample size so I generally trust it more than I do other measures, such as the “5-star” ratings.

So give me your thoughts. If it were up to you, which columns would you run more frequently? Which ones would you cancel? Or more generally, is there anything on this chart that surprised you?

Announcing a New Series: From Web Dev to RIA Dev

hdierking — Thu, 19 Mar 2009 09:29:04 GMT

I’m sitting here in my hotel room at MIX 2009, where a ton of really huge announcements were made today. In a much more scaled down attempt at continuing that tradition, I want to announce that starting in May, we are launching a 9 week series focused on introducing ASP.NET Web application developers to creating rich internet applications – and introduce a few other patterns along the way to help create better Web software.

The approach will take an existing Web application that has been written in classic ASP.NET and refactor parts of it based on the goals of each installment. Some of the specific details are still being worked out, but I wanted to take this opportunity to introduce you to James Kovacs, the guy who’s going to be working them out, hopefully with some help from you. I’ll let James post separately on his thoughts and initial items that he would like feedback on, but wanted to at least be the first one to tell you all how excited I am about this upcoming series!

ASP.NET Presentation Patterns

tdorsey — Fri, 19 Dec 2008 18:00:00 GMT

In a layered Web app, the presentation layer is just as important as navigation logic, business logic, and data access.

In the December 2008 issue of MSDN Magazine, Dino Esposito examines some design patterns for building an ASP.NET presentation layer, starting with the Model-View-Controller (MVC) pattern—the root of all patterns specifically targeted to the UI.

How Connection Manager Connects

tdorsey — Fri, 19 Dec 2008 05:31:00 GMT

Without Connection Manager, for all but the simplest network environments, the only way an application could choose a connection would be by presenting the user with a list and asking him to select one.

In the December 2008 issue of MSDN Magazine, Marcus Perryman explains why the correct use of Connection Manager is vital when a Windows Mobile application requires network data and shines a light on some of Connection Manager's inner workings.

x64 Debugging With Pseudo Variables

tdorsey — Tue, 16 Dec 2008 05:48:00 GMT

For many years, Visual C++ has included a set of pseudo variables and format specifiers for use in debugging.

In the December 2008 issue of MSDN Magazine, Kenny Kerr shares some of the pseudo variables and format specifiers that he’s found most useful for debugging C++ applications in the x86 and x64 processor architectures.

Check the magazine archives for previous installments of the Windows With C++ column.

Configuration Testing With Virtual Server

tdorsey — Fri, 12 Dec 2008 10:00:00 GMT

In the September 2008 issue of MSDN Magazine, Dr. James McCaffrey introduced you to software configuration testing with Microsoft Virtual Server.

In the December 2008 installment of the Test Run column, he walks you through the process of automating software configuration testing using Virtual Server and Windows PowerShell.

For more articles on testing, be sure to check out our MSDN Magazine archives.

Claims-Based WCF Services with Geneva Framework

tdorsey — Wed, 10 Dec 2008 10:00:00 GMT

The "Geneva" Framework, formerly called "Zermatt," is the code name for the new framework for building claims-based applications and services, and for implementing federated security scenarios.

In the December 2008 issue of MSDN Magazine, Michele Leroux Bustamante describes how to approach claims-based WCF services using the Geneva Framework, and compares to WCF claims-based security without the Geneva Framework.

Rendering Text On A Path With WPF

tdorsey — Mon, 08 Dec 2008 10:00:00 GMT

Text is more than just its literal meaning. By treating text characters as graphical objects, the programmer can make text dance and fly on the screen.

In the December 2008 issue of MSDN Magazine, Charles Petzold shows you how to position text characters along a curved line with Windows Presentation Foundation (WPF) and animate the individual points defining the path to watch the characters bounce around in response.

You can browse the sample code online.

Design Patterns for Testability

tdorsey — Fri, 05 Dec 2008 20:39:53 GMT

Testability is both as an important quality of your designs and another tool you can use to create and think through designs.

In the December 2008 issue of MSDN Magazine, Jeremy Miller examines the design issues, patterns, and principles that can enhance testability in your apps.

For more articles on testing, be sure to check out our MSDN Magazine archives.