Real World Software Architecture

Real World Software Architecture is dedicated to providing information and experiences from the field of Software Architecture.



Subscribe with RSS or ATOM Add to Google

Links

  • Home Page
  • Real World Software Process Engineering
  • Suggested Reading
  • .NET Dev and Arch Collection
  • SEI Essays on SA
  • Software Architecture
  • Bredemeyer
  • wwisa
  • Product Line Engineering
  • PLEES
  • Software Product Lines
  • MSDN Architecture Center
  • patterns & practices






Tuesday, January 29, 2008

Visual Studio 2008 Product Comparison Data Sheet

Microsoft has compiled a very nice product comparison data sheet for Visual Studio 2008.

Overview (from download site)
This data sheet provides a comprehensive product comparison of the Visual Studio 2008 IDE products. It does not provide data about Visual Studio Team System 2008 Team Foundation Server, Visual Studio Team System 2008 Team Explorer, or Visual Studio Team System 2008 Test Load Agent. This data sheet is provided for illustrative purposes only.

Get it here.

posted by tadanderson at 8:14 AM 0 comments

Software Process Dynamics Book Review




Having been around software process engineering for over 15 years it is nice to see it presented with a dynamic view, instead of the common static view.

It doesn't claim to be the next silver bullet, but it does do a great job of putting all the silver bullets to come about over the past several years in their place. It offers a refreshing realistic view on the state of software processes, and then moves into how to capture their essence with simulation software and system dynamics.

The author makes it clear that the book defines system dynamics as a methodology to implement systems thinking and leverage learning efforts. The book also discusses discrete-event simulation, and the trade-offs throughout.


Here
is a good paper on discrete-event simulation and using it to gauge CMMI levels of a given process.

The book also does a great job of relating simulation to the CMM levels.

The overall theme is not one of predictions, but rather one of learning and deeper insight into software processes.

The author clearly defines and explains the different contexts of process model. He explains it as it is used for simulation, life-cycles (waterfall, RUP, WinWin, MBASE, agile, etc.), and frameworks (CMMI, Six Sigma, etc.)

The first chapter of the book is available on the
Wiley web site
. It contains a lot of great information. The author also has
a book site that I have noticed being updated over the past couple of weeks.

The book is very well written and it has a nice logical flow to it. I would recommend this book to anyone involved with software engineering. Project Managers, Architects, and Developers all stand to gain from it's insight.

posted by tadanderson at 4:03 AM 1 comments

Software Process Dynamics Book Review



Having been around software process engineering for over 15 years it is nice to see it presented with a dynamic view, instead of the common static view.

It doesn't claim to be the next silver bullet, but it does do a great job of putting all the silver bullets to come about over the past several years in their place. It offers a refreshing realistic view on the state of software processes, and then moves into how to capture their essence with simulation software and system dynamics.

The author makes it clear that the book defines system dynamics as a methodology to implement systems thinking and leverage learning efforts. The book also discusses discrete-event simulation, and the trade-offs throughout.


Here
is a good paper on discrete-event simulation and using it to gauge CMMI levels of a given process.

The book also does a great job of relating simulation to the CMM levels.

The overall theme is not one of predictions, but rather one of learning and deeper insight into software processes.

The author clearly defines and explains the different contexts of process model. He explains it as it is used for simulation, life-cycles (waterfall, RUP, WinWin, MBASE, agile, etc.), and frameworks (CMMI, Six Sigma, etc.)

The first chapter of the book is available on the
Wiley web site
. It contains a lot of great information. The author also has
a book site that I have noticed being updated over the past couple of weeks.

The book is very well written and it has a nice logical flow to it. I would recommend this book to anyone involved with software engineering. Project Managers, Architects, and Developers all stand to gain from it's insight.

posted by tadanderson at 4:03 AM 0 comments

Saturday, January 19, 2008

Web Application Extension (WAE) ASPX Patterns for SPARX Enterprise Architect (EA)

We have added a new download to the Software Process Engineering site. WAE ASPX Patterns. They are UML patterns created using SPARX Enterprise Architect (EA) and they are indented to be used with the Web Application Extension (WAE) UML Profile.


Click image for larger image.

The Web Application Extension is covered in this book. The author, Jim Conallen, also has a paper posted here on the WAE.

SPARX has the WAE profile available for free download from this page.

The download includes the following files:

HelloWAEPatterns.eap- A start up project used to show some of the features in the WAE ASPX Patterns Readme.doc.

WAE ASPX Patterns Readme.doc- How to get started and an overview of the features.

ASPXWebform.xml- A pattern to generate an ASPX webform. This is explained in greater detail in the WAE ASPX Patterns Readme.doc, and there is a screenshot below.

UserControl.xml- A pattern to generate a user control. This is explained in greater detail in the WAE ASPX Patterns Readme.doc, and there is a screenshot below.

Frameset.xml- A pattern to generate a frameset. This is explained in greater detail in the WAE ASPX Patterns Readme.doc, and there is a screenshot below.


Below are screenshots of each pattern.


Click image for larger image.


Click image for larger image.


Click image for larger image.

We have this available as one of the downloads on this site.

posted by tadanderson at 8:47 AM 0 comments

Friday, January 18, 2008

Moving Up the CMMI Capability and Maturity Levels Using Simulation

My team is currently in the process of purchasing simulation software for use with process engineering. This paper's release was perfect timing for us to show what we are trying to achieve with the new software.

Overview of Paper (from the SEI)
Process Simulation Modeling (PSIM) technology can be used to evaluate issues related to process strategy, process improvement, technology and tool adoption, project management and control, and process design. Recent developments in PSIM tools have drastically cut the costs to develop models for evaluating such issues, and new methods have been developed to apply PSIM, enabling it to provide greater business value. At the same time, trends within the software industry towards improving operations and reducing costs have heightened the need for tools to better plan and manage processes. As a result, organizations regard PSIM as an attractive tool that can provide business value today. This report shows examples of how PSIM has been implemented within industry and government organizations to improve process consistency and results. The report also shows, via many examples, exactly how PSIM supports Capability Maturity Model Integration Process Areas from level 2 through level 5.

Get it here.

posted by tadanderson at 7:14 AM 0 comments

The Customer is not Always Right and Death to the YES Man (Workaholic)

I don't care how many times I hear it, how many authors print it, and how many salesmen preach it, the customer is not always right. They may always get their way, because it is their money, but they are not always right.

If you are not telling your customer when they are wrong, it is not their fault the project is a mess, it is yours. It is not their skills that are lacking, it is yours. Anyone (sales people, managers, software architects, developers, politicians, etc.) who is doing their job right has learned to say no effectively.

The Yes Man (or women) is the type of person who uses their environment as an excuse for always saying yes. Most of the time I have found these people to be workaholics. The book Peopleware says workaholism is not the same as alcoholism (pg. 16), it is more like the common cold, everybody catches it once in a while. That is not true, not even close.

We all show behaviors of a workaholic every once in a while (just like everyone drinks to much every once in a while, they don't go on 2 week binges once in a while), but a workaholic does not stop showing the behaviors and those behaviors will wreck your life, and can kill you. I know, it destroyed my step father. He was demoted from VP of a company that he worked 7 days a week for. He work for them for over 30 years. When the company was bought out by a foreign company, they did a clean up. Suddenly he was told he was dead weight. After 2.5 years of deep depression, he drove his car into a wall and was killed in the accident.

Like I said above almost every Yes Person I have met has been a workaholic. They don't say no because of the fear of destroying their identity. The workaholic's identity is their career. Saying no to a workaholic is like a normal person saying no to their family when they ask to be fed dinner. They perceive a no at work in the same light, every task is necessary, every task is important, and every task is a reflection of who I am as a person. They have no value outside of work.

If you are dealing with one of these yes people in your environment, you will notice they spread havoc throughout the organization. Not when they first arrive. When they first arrive they take on all challenges, appearing to be the newest hero on the block. After a while however, when their plate is to full to handle in 75 hours a week, they will spin into chaos mode. Still saying yes to everything, and dropping the ball on almost everything. They show up to meetings unprepared, their meeting schedule consumes their entire day, you start hearing about family problems and working the weekend in the same conversation, and you notice yourself doing your best to not work with them.

If you have a manager that is a workaholic you will hear things like, "the political nature of this office does not allow for saying no", "we need a warm body at this meeting, drop what your doing and go", "I did not have time to review this before the meeting, please take me through it page by page", "we expect you to be professional and work overtime like we do", and "after this emergency we will let you get back to your normal work load".

You will see within the environment projects and work being passed around like a hot potato. Not because the people there are lazy, but because they know the manger does not know when to say, "No, my team is stretched to the limits so we can't do that", or "We don't have anyone available that does that, so we won't have a representative at the meeting". The team has been bombarded with work that has been accepted on behalf of the workaholic for them to do. Work that they should not be doing, but the workaholic can't say no, because that would be identity damage.

You'll find them also very unforgiving in performance reviews. If you aren't supporting their actions, you are not helping them maintain a healthy identity. So if you are not displaying workaholic characteristics, you are not one their identity improvement team. You are actually sending the message, "I don't like who you are". That is at least how, "I can't work the weekends" is heard by them.

The only real solution when faced with this type of environment is to get out. You either get out, or you join the club. So over time, you find the truly talent and balanced people have left, and the place is a chaotic mess filled with disgruntled employees, working mostly on supporting their manager's image by performing the work they are unable to say no too.

If you are faced with this problem, you can do only one thing, leave. This blog ends with me leaving a position because of this same problem. The manager said yes to us (the development team) and yes to the customer on everything. As most workaholics do, they built a wedge between the customer and the technical team, and they did all the communicating. We were told we were not allowed email, or to speak to the customer. The problem they ran into was they were saying yes to conflicting things. It got so bad I emailed the customer claiming it was an accident so they would know what was really going on. The customer exploded, and although the explosion was directed at me, it was worth it, because it got us back on the same page. But only for a little while. Leaving became my only solution.

Most of the time the people in charge of the Yes Person don't see the affect they are having on the environment. They won't easily detect it because the workaholic is good at protecting their identity. It is a matter of survival. If you suspect you may be having this problem, do a survey, but make it an anonymous survey.

Sometimes, but not very often you can help a Yes Person. It is rare enough that you can have any lasting affect with your help, that if they don't accept outside help (employee help programs), you should start working at fire them. At least start reprimanding them for the dropped balls, the poor morale of their people, and step into the communication channels between them and the their teams.

Change usually only comes with pain for these people. Sadly that pain is usually great enough to destroy their life outside of work as well as the career they worked so hard to create. When that dies so does their identity. If they find help, they can rebuild it without work being a factor in it.

I have had my share of long hours that lasted for a long period of time. But in between I make myself take breaks and make sure that my life outside of work is not falling apart. If I am doing life right, my career does not define who I am.

posted by tadanderson at 6:13 AM 0 comments

Thursday, January 17, 2008

New Web Client Software Factory Modularity Bundle from patterns & practices

What is the concept (from CodePlex)?
Modularity is the separation of an application in independent and collaborative modules. You use modules to encapsulate a set of concerns of your application and independently develop and deploy them to your applications. These modules are developed and maintained by multiple teams.

A Web client application that uses the Composite pattern generally involves a shell module, which provides the overall user interface structure. A shell module typically registers user interface components shared by other modules, contains global pages and one or more ASP.NET master pages that module developers can use to create a consistent layout for pages.

Modules contain functionally discrete pieces, but they integrate with the user interface and communicate with each other. The shell module provides access to services required by other modules throughout the application. This means that the modules can use these capabilities instead of having to implement them themselves.

This approach provides a number of advantages in terms of a separation of roles between the developers of the modules and the solution designer/builder. Module developers are typically focused on implementing the business logic required to
provide specific business focused functionality (for example, providing access to the inventory, CRM, ERP, and HR systems). The solution designers are able to define a solution to a business problem at a level that is higher and more broadly focused (for example, providing a call center solution, a bank teller solution, or a document collaboration solution).

Get it here.

posted by tadanderson at 1:55 PM 0 comments

Monday, January 14, 2008

Ajax Data Controls v1.0 Released

The Ajax Data Controls v1.0 have been released on CodePlex.

Overview from CodePlex:
The Ajax Data Controls is a DotNetSlackers project. Developed on top of Asp.net Ajax Extension, the main goal of this project is to provide rich set of data controls for Client Centric Development Model. Since the data controls of Asp.net like GridView, DataList, Repeater etc does not have any Client Side Object Model thus it is not possible to work with these controls with Web Service / Page Methods call. The included controls exposes same API in the client side as the Asp.net version with few more enhancements.

Currently the project contains the following controls:

  • Repeater
  • GridView
  • DataList
  • Pager

You can download them here.
See demos here.
And read the release blog here.
_

posted by tadanderson at 8:04 PM 0 comments

Product Review of Honeywell 7400D Conventional 5-1-1 Day Programmable Thermostat

This is another gadget blog. We live in an older home that was built back around 1880. We decided this weekend we were sick of having to change the thermostat every morning when we got up, when we left for work, when we got home, and when we went to bed.

The old mercury thermostat would be set for 62 during the day and night when we were at work, but it usually had to go down to 52 before it was kicked in and then it would go up to 68 - 70 before starting to cool again.

We had the same problem on the high end. So it seemed like we were always freezing or cooking. Since we have installed the Honeywell it has been right on the noise at 68 for when we are here, and 62 when we are sleeping or at work. We have oil heating water that runs through big metal radiators, and this thing keeps it right on the temperature it is set for.

It will definitely pay for itself this year. We have no more extreme weather inside, and we don't have to remember to change the thermostat 4 times a day, which we forgot have the time.

Installation was really easy. We had a system that was so old the wire diagrams did not match our old set up, but I followed the advice on this blog and had it installed, running, and programmed within 30 minutes.

I'd recommend this thermostat to anyone upgrading any old system.

posted by tadanderson at 6:39 PM 0 comments

Sunday, January 13, 2008

The delusions of an unreal deadline and its deliverables.

I am in the middle of putting together one of the biggest deliverables I have had the pleasure of creating. It is not however an application, it is a Process Repository that will be used to build instances of processes based on a given project's needs.

It is a 6 to 7 month long time frame for the first build. The project was broken into about 20 iterations. There was an extensive proof of concept done to determine the amount of time it was going to take to finish the first release. The first release will be the baseline repository that will allow additional library data to be added in short release time frames.

When determining the time it would take for each content building iteration I had to set the timeframes as hard stops. If I didn't, I could probably spend months on each content library and still feel like I could do better. The time frame set was 1 week per content library. Content is coming from SEI, Microsoft, books, tools, and websites.

OK, so what? Notice I didn't say the iteration's timeframes were set based on budget, they were set by the amount of content we considered to be enough for our first release. In an application, this would be when a module is 100% complete, tested, bug free, documented, and integrated into the application.

This development process is doing with time what any project should do with time. It is being used to help manage the project, but it is not determining when the project will be completed. Time has absolutely nothing to do with the completion of a project unless we allow it to. Yet it is one of the most determining factors that we allow to mess up a good project. We all know why this happens most of the time, budget or politics. Sometimes it is just poor planning, no proof of concepts done to determine real time frames, and promises made on guess-tamations.


Some of the brightest dumbest people I have had the pleasure of working with are living in a delusion that they can control a project's creation with willpower and authority because they have decided there is a deadline that must be met because of budget or politics.

The rest of us know the deadline simply won't be met, but we also know they can't be convinced of that. If it is met, it is always a fake deliverable. Meaning the deliverable was delivered, the check was cut, the party was thrown, and a maintenance contract costing 3 times the original contract cost was signed to get the deliverable running over the next several months or years.

My responsibilities also include architectural reviews and lending a hand designing applications our team helps out with. I had the opportunity this week to see a great architecture and project plan, as well as to see one of the worst architectures and projects plans I have ever seen.

The good review was a pleasant walk through of design artifacts and proof of concept findings. Time lines were based on tasks and the efforts that were going to take place to complete them. It is a very larger system, with a tons of moving parts, and every one of those moving parts went through a proof of concept. If I was a betting man, I'd say there is a 98% chance of successful delivery. On time, within budget, bug free, well documented, and fully functional.

The other project was just nuts. It has been determined on high that this application will be done with a timeframe that is simply silly. There are 2 teams, one building the admin piece, the other the public facing UI.

The admin team was at least honest. They told us, "there will be no time for requirements gathering, analysis, or design, due to the timeframes. We will move directly to coding."

The other team has opted to use the old, "not a problem, we'll build this one with agile practices. We don't need use cases or requirements when we build with agile practices".

In this case politics are driving the deadline, and no one on the development team has access to speak to the people who made that decision. It would not do any good anyway. It was the old, "if you go electronic, you will save millions" feather in the hat promise. Well this is another one of those cases, and I have seen plenty, were they will make the deadline but it will be fake. So the paper process will begin to shut down in anticipation of this application arriving.

Then to every ones surprise, the new application will start having a few problems. There will be no design to turn to, so more developers will be hired and crazy hours of desperate programming will start to depreciate the quality of the system until the paper process is brought back online. The system will then endure a year of maintenance hacking with a team larger than the one that builds it, and in the long run we will spend 3 to 5 times more collecting the data this year. Two times on the paper process because it will cost to take it down, and then cost to get it up, and the rest on an application that did nothing but create a newly needed budget for next year.

So what do you do in this second case? You simply refuse to skip the proper architecture, proof-of-concept, and design phases. The people in charge don't know any better, but we should. Using deadlines as an excuse to skip doing proper architecture and design is just that, an excuse. It is not a reason. In the case above the wasted money is not the fault of the deadline setting politician, it is all the fault of the development teams. They are allowing time to determine the result instead of using time to manage the result.

The only real deadline is determined by the process and the completion of the artifacts determined by the process. If the process determines that a deadline set outside of the process is flawed, then it is not a real deadline and therefore any deliverable associated with that deadline will not be a real deliverable, it will be the delusion of a real deliverable.

posted by tadanderson at 9:27 AM 0 comments

Friday, January 11, 2008

Framework Engineering Video: Architecting, Designing, and Developing Reusable Libraries

Framework Engineering: Architecting, Designing, and Developing Reusable Libraries (from Posting Site)
This session covers the main aspects of reusable library design: API design, architecture, and general framework engineering processes. Well-designed APIs are critical to the success of reusable libraries, but there are other aspects of framework development that are equally important, yet not widely covered in literature. Organizations creating reusable libraries often struggle with the process of managing dependencies, compatibility, and other design processes so critical to the success of modern frameworks. Come to this session and learn about how Microsoft creates its frameworks. The session is based on experiences from the development of the .NET Framework and Silverlight, and will cover processes Microsoft uses in the development of managed frameworks.


Watch it and get the slides here.

posted by tadanderson at 8:23 AM 0 comments

Thursday, January 10, 2008

Over 4 hours of FREE Silverlight Essential Training

I have not gone through this yet, but I did go through the Blend training they offered and it was great stuff.

Overview from the lynda.com site:

Mike Harsh is the program manager on the Silverlight team at Microsoft. In Silverlight Essential Training, he gives viewers an insider's look into this powerful application. Mike teaches each step in the process of building interactive web applications using Silverlight, including how to add video, animations, and interactive features such as drag-and-drop functionality. Exercise files accompany the tutorials.

Get it here.

posted by tadanderson at 1:25 PM 0 comments

Friday, January 04, 2008

.NET Architecture and Development Book Recommendations

***UPDATE***- This post's list has been updated HERE.


We have updated our book recommendations page on our Real World Software Process Engineering site. We have posted a version of what is there below. We will however only make updates to the page on the SPE website.

These are all books we use, or plan to use when they are released. We have reviewed a lot of them here.

Software Process Engineering
Product Line Engineering

Software Architecture

SOA

Component Development

Coding Guidelines

Frameworks

Patterns

OOAD

.NET 3.0 Platform

ASP.NET AJAX and Silverlight

.NET 3.5

posted by tadanderson at 8:52 PM 0 comments

Framework Design Guidelines 2nd Edition In the works!

This is great news!!! I have used this book as a coding standard on all my projects since the release of the first edition. On several projects I have made the companies buy the first edition for every developer on my team.

posted by tadanderson at 4:07 AM 0 comments

Wednesday, January 02, 2008

Proof of Concept your Developers

With the rapid speed at which technology is changing I have found only one way to ensure it works as advertised, Proof of Concepts. The same holds true of your development team when you have no history with them. With the rapidly changing skill sets out there today, there is only one way to ensure your team has what it takes, Proof of Concepts (POC).

This topic starts with a few beliefs that if you don't agree with, just stop reading now.

1. Having the job title does not magically make the skills appear that you need to do the job.

2. Not all people are equally capable of learning.

3. There are people who are classified as non-trainable individuals. You fire them, period. The manager that says "there is no such thing as a bad employee, just bad managers", are in this category by default and should be fired immediately.

4. You can mentor a trainable individual into a certain skillset, but not with knowledge transfer alone. Hands on experience with the ability to learn is a must. Can you imagine a pilot that only read a book on flying a 747 showing up to fly your plane?

The last belief is where Proof of Concepts (POC) plays an important role in not only testing your choice of technology and architecture, but of your development team as well. There is no doubt that people are no where close to being as predictable as software components. Software components are lucky; they don’t have emotions or free will. It is however fairly easy to read a person’s skill levels when what they are making has a predictable outcome.

The last time I ran through this exercise was when I had a team of 3 developers. We were POC’ing a configuration of the Composite UI Application Block (CAB) from Microsoft’s pattern & practices group. I had 3 developers on the team. Each was given an equal workload which included building a complete smart client module from the UI to the DB. The technology proof of concept had already been done at this point, so we knew the technology worked as advertise, well mostly. The first iteration of development was a POC of the development team and of the framework’s architecture. We learned within a week that the team members had different levels of ability.

One of them was able to code all the layers of the application including the DB level, but didn’t like UI work. One was only able to develop the UI forms, and was able to lay them out well. The other was dangerous in a team environment and was locked out of source safe. They worked on the Help documentation, configuring servers, and did a lot of testing.

The initial plan was completely scrapped and the new assignments were made. We hit every estimate. If we had not POC’d the development team, we would have delivered buggy late code with each iteration.

I have been a lot of places that do not make adjustments like this and usually suffer dearly for being so closed minded. Some places I have been are too free spirited and end up suffering as well. They like to pretend everyone is equally talented and capable of every task. That is silly to me. I would rather have 3 experts that are limited to specialized areas, than have 3 generalists that know a little bit about everything, but specialize in nothing.

It is ideal to have a team of well rounded experts, but at the rate technology is changing it is doubtful you will get that very often anymore. Some will be trainable and therefore retainable, but when you get someone who is not and they need to be replaced, you need to learn that as soon as possible in the process. Interviewing is not enough.

The further along in the development process a buggy component is allowed to get, the more it ends up costing your project. The same is true of the defective developer. They ether need to be helped with getting up to speed, or deleted and defragged if you don’t have the time or resources to do so.

posted by tadanderson at 1:48 PM 0 comments

Tuesday, January 01, 2008

Pro LINQ: Language Integrated Query in C# 2008 Book Review




This book claims to be about code, code, and then more code. I completely agree with the author's claim, it is code from front to back.

The book covers every feature of Linq in great detail, but one of my favorite parts of the book is chapter on the C# 3.0 Language features and other parts of the book that show how to take advantage of the Linq language features in everyday application code.

The author goes into great detail in every part of the of the book. The author also has a great companion site that is being updated with the latest new features coming out, like LINQ to XSD.

The accompanying code is very usable and well organized.

The only thing lacking would not be a legitimate complaint, since the authors claim code level detail and not architectural level guidance, but I will mention it anyway. I would have like to have seen more guidance on architecture and how Linq fits into the big picture. That is not covered, but like I said, they didn't claim to, so I can't ding them. The point of the comment…. 2nd edition …hint, hint…..

If you want to get into the guts of Linq, this book is definitely for you. I highly recommend it for every .NET 3.5 programmer.

posted by tadanderson at 7:28 AM 0 comments

Pro C# 2008 and the .NET 3.5 Platform Book Review




Andrew hits the mark again. This is the 3rd version of this book I own. Everyone of them does an excellent job of covering all the new features in the latest release.

I skipped the .NET 3.0 version because there weren't many new features added to the C# language itself. I am glad I got this book for this 3.5 release because there are a ton of new features. This book covers all of them in detail.

If you have never bought one of Andrews books, and you a serious about programming C#, you simply have too. He relates the language features to the pillars of OOP (inheritance, encapsulation, and polymorphism) in great detail. Understanding these pillars is a definite prerequisite to moving into and understanding design patterns.

One of the other things I like about this book is the material on programming with .NET assemblies. The key to good architecture is developing with components. This material teaches you everything you need to know about .NET assemblies which you need to know in order to develop with .NET components.

This is a must have for every C# developer. If you have not read this book, you are definitely not taking advantage of all the C# / .NET 3.5 language features in the language.

posted by tadanderson at 6:56 AM 0 comments

Pro ASP.NET 3.5 in C# 2008 Book Review




This book is an excellent resource for learning ASP.NET 3.5. It also serves as a great reference.

It is a comprehensive book that covers all of .NET 3.5, not just the new features in .NET 3.5, but all the features that have been there over the last several releases.

Matthew includes chapters on Linq, ASP.NET AJAX, and Silverlight. If you only want to learn about the new features in .NET 3.5, buy separate books on ASP.NET AJAX and Silverlight. Matthew does a great job of putting Linq into it proper place within a common ASP.NET 3.5 Architecture. So far he has done this best job of this I have seen in a book.

One reviewer on Amazon pointed out that the book has a lot of material from previous versions. That is to be expected since all the previous version's functionality is included in the technology. Like I said above, this book covers everything.

This book also does a great job of covering the Visual Studio 2008 IDE features.

Matthew does a great job relating everything to real world scenarios. He also provides very usable code samples.

If you are developing in ASP.NET 3.5, this is a must have book.

posted by tadanderson at 6:04 AM 0 comments

Previous Posts

  • DevOps: A Software Architect's Perspective Book Re...
  • Scaled Agile Framework (SAFe) LiveLessons Video Se...
  • Bulletproof Android: Practical Advice for Building...
  • Swift for Programmers Book Review
  • Security in Computing (5th Edition) Book Review
  • Swift in 24 Hours, Sams Teach Yourself Book Review
  • Sparx Systems Releases Enterprise Architect 12
  • Learning Swift Programming Book Review
  • Android Security Internals: An In-Depth Guide to A...
  • Adaptive Code via C#: Agile coding with design pat...



Archives

  • December 2005
  • January 2006
  • February 2006
  • March 2006
  • April 2006
  • June 2006
  • August 2006
  • October 2006
  • November 2006
  • December 2006
  • January 2007
  • February 2007
  • March 2007
  • April 2007
  • May 2007
  • June 2007
  • July 2007
  • August 2007
  • September 2007
  • October 2007
  • November 2007
  • December 2007
  • January 2008
  • February 2008
  • March 2008
  • April 2008
  • May 2008
  • June 2008
  • July 2008
  • August 2008
  • September 2008
  • October 2008
  • December 2008
  • January 2009
  • February 2009
  • March 2009
  • April 2009
  • May 2009
  • June 2009
  • July 2009
  • August 2009
  • September 2009
  • October 2009
  • November 2009
  • December 2009
  • January 2010
  • February 2010
  • March 2010
  • April 2010
  • May 2010
  • June 2010
  • August 2010
  • September 2010
  • October 2010
  • November 2010
  • December 2010
  • January 2011
  • February 2011
  • March 2011
  • April 2011
  • May 2011
  • June 2011
  • July 2011
  • August 2011
  • September 2011
  • October 2011
  • November 2011
  • December 2011
  • January 2012
  • February 2012
  • March 2012
  • April 2012
  • May 2012
  • June 2012
  • July 2012
  • August 2012
  • September 2012
  • October 2012
  • November 2012
  • December 2012
  • January 2013
  • February 2013
  • March 2013
  • April 2013
  • May 2013
  • June 2013
  • July 2013
  • August 2013
  • September 2013
  • October 2013
  • November 2013
  • December 2013
  • January 2014
  • February 2014
  • March 2014
  • April 2014
  • May 2014
  • June 2014
  • July 2014
  • August 2014
  • September 2014
  • October 2014
  • December 2014
  • February 2015
  • March 2015
  • April 2015
  • June 2015
  • July 2015
  • September 2015

Powered by Blogger