Seattle Code Camp 2018

September 19th, 2018 | Posted by Vidya Vrat in Architecture | Community - (0 Comments)

This was 3rd years in a row, and on Saturday, September 15 I gave two sessions at Seattle Code Camp 2018

Session slides are available at my GitHub 

The first session was on “How to become a Software Architect”. Many aspirants and practicing architects attended my session and asked various questions on architect career path.

The second session was on “Microservices: what, why and how?”. This session also went very well, and I ran out of time to address all the questions related to many individual’s architecture designs and how to solve a problem they are facing. Hence, few topics were discussed after the session in the lobby.

What some of the participants said

I look forward to Seattle Code Camp 2019.

Seattle Code Camp 2017

I spoke at Seattle Code Camp 2017 on 09/09/2017 and covered two topics.

• AntiPatterns Every Software Development Team Must Know https://lnkd.in/ebEMDBb
• DevOps: What, why and how?
https://lnkd.in/eQf3dFm

Seattle Code Camp started with a Keynote from Microsoft’s Jeremy Foster and he shared a slide with all Microsoft MVP (Most Valuable Professionals) and FTE (Full Time Employee) who were speaking at 09/09/2017 Seattle Code Camp.

Microsoft got separate printed agenda for MVP and FTE Sessions

Session Details

My 1st Session on AntiPattern was in Room#103 at 11 am -12 pm. I had a brief introduction and begin with the presentation. As already set the expectation with the audience, I kept it very interactive and many participated well to share knowledge and experiences with others.

Some of the attendees even spoke to their friends in the lunch break and recommended them to attend my next session. Some of the attendees returned for the 2nd session for DevOps at 1-2pm and some mentioned that it was the best talk they attended. Well, I thank them for their kind words and patience to provide me an opportunity to share my thoughts with them.

What people said after my sessions

Presentation Slides

Slides are available at https://github.com/vidyavrat/SeattleCodeCamp2017

Contact Me

Please connect with my via
LinkedIn : https://www.linkedin.com/in/vidyavrat/
Twiter : https://twitter.com/dotnetauthor

Send me a message using Contact Me tab on the blog.

Abstract

Convention over configuration is a software design paradigm which is used by many modern software framework including ASP .NET MVC and Web API. It’s also known as “Coding by Convention”.  It takes a lot of burden away from developers, which is otherwise required; to handle basic aspects of the application. For example, mapping of database tables with classes, or handling URLs etc.

Introduction

ASP.NET MVC (Model View Controller) very nicely showcases this software design paradigm via Visual Studio’s ASP.NET MVC Project template directory structure. ASP.NET MVC Project have three core folders “Controllers, Models and Views” as shown in Figure- 1 below.

Figure-1 Visual Studio MVC project folder structure

ASP.NET MVC framework’s folder structure is based on “Convention over Configuration” and that’s why practically, a class in Models folder can be safely assumed that there is a table with that name in the database. A Controller can be created with a <Name> with a suffix “Controller” (for example, EmployeeController, ProductController etc.) Similarly, an action method in Controllers folder’s controller class can be accessed with Controller class name (name without suffix Controller) for example, Details action method in EmployeeController by convention can be easily accessed via http://Your-Domain-Url/Employee/Details

Implementation

If there is no “Convention over configuration” paradigm; to make any such behavior work, developers need to specify/code some configuration rules to educate the application about interpreting a url and under which folder or where to look for the resource to serve that request.

Hence, having Convention over configuration is already baked into ASP.NET  MVC, Developers don’t need to write any code to establish communication mechanism among various application components. To have it function properly, conventions need to be followed and developers need to adhere to those conventions.

For example, all controller classes must reside under “Controllers” folder with <Controller> suffix as convention for example, Controller\HomeController, Controller\EmployeeController etc.
Views folder is known to have all the views and convention tells Controller where to look for a View(s) associated with a controller action method; as shown in Figure 2 below, each action method in Controller\HomeController refers to individual cshtml under “Views\<folder with controller name>”

Figure-2 Convention over configuration in Action
Hence, convention over configuration help developers to easily communicate with the ASP.NET MVC web framework by providing the pre-defined conventions as shown in Figure-3 below

Figure-3 Convention over configuration in action.

Note, that if you don’ follow the conventions correctly for example, create a controller class named DefaultController1.cs under Controller folder and build it; then Visual Studio IDE will not report any issues and it will build successfully.

Or simply move HomeController out of Controllers folder, under the project. Hit the route http://locathost/Home/About and you will get 404.

Building solution successfully doesn’t mean, that it will work.

No error was reported because as a developer you are given freedom to name your controller class etc. as per your wish; so you have freedom. But to have it working “Convention needs to be followed strictly” hence, it will not work. But once you adhere to the Convention by renaming DefaultController1 to “DefaultController” or moving HomeController back into Controllers folder; and you hit the route then it will start to function as expected.

Read this on C-SharpCorner

Abstract

Many times this question comes to our mind that is one technology totally replaced by new release or new version of technology. In this article I will try to explain about such and similar issues and I will share my industry experience not only what I have seen in India (largest IT Solutions provider to the world) but also in USA.

I consider this to be a very hot topic and good candidate of debate rather; but I will try to share my thoughts on such a burning topic. In this article I am not going to highlight or defame any technology; I am just going to put my perspective as I have seen, experienced and advised to various clients and software teams.

Why new Versions

“Change is Only Constant” this principle applies very well to the Software Industry, and I respect this over-flow of information. Because this gives me a reason to “Keep Learning and stay ahead of the Curve”. By saying so I didn’t mean that someone has to learn anything and everything you can get your hands on. NO, certainly not, but before I explain this any further let’s take a step back and understand “Why new Versions” keep coming.

We are fortunate that we have seen a complete transition of the software industry from Desktop to Web to Mobile, upcoming generations may not witness this great and life-changing shift. Also, I recall my days when I was working and studying software in 1995, no one imagined that there will be MVC, WPF, WCF, so many versions of .NET and SQL Server etc. The industry was happy with MS-Access, Fox-Pro, C, C++, and Oracle etc. But our needs keep changing, they evolved and then the shell is broken to have huge expansion and today we have all kind of software technology and server products from client side to server side to mobile and hand-held and many more. We moved from on-premise to Cloud, Machine Learning is helping to dictate patterns and suggest needs.

This is why software companies keep building latest and newest technologies to enable and empower the world to build for future. When they release a version of a technology or language and they discover some issues or new features in that then they release newer versions and this in a chain reaction process and it will not stop.

Oh, then I will die Learning

As per Darwin’s Evolution Theory “Survival of the Fittest”,”fit” refers to “best adapted to the current environment.Here you simply replace environment to Software Industry. I am one of you and I don’t recommend that everyone has to learn everything but what I suggest it stick to your technology of choice and have good knowledge on their offered tools and technologies and various versions and when to use which one.

Also, you don’t necessarily have to know every single thing. For example, I only focus on .NET and related technologies, if anything falls beyond this area then I am not bothered. To be more precise, I don’t know Microsoft CRM, SharePoint, System Center, SQL Server Database Administration and few more things like that.

But this is not my weak point because “I continue to build my .NET Muscle” and keep learning about what helps me build Enterprise solutions using Microsoft.NET.

So choose your area of interest and where you have invested and then keep learning in the similar field and then you will no longer find it challenging; because if you observed new versions come after every few years and that has to be otherwise it will be No Fun!

Hmm, so Isn’t MVC Replacing ASP .NET Web Forms

Such decisions are not final and have no concrete answers. Yes, the industry changed their needs and so new technologies such as MVC and WPF takes over. This definitely doesn’t mean that ASP .NET  Web Forms is replaced or it’s dead. If you know the Microsoft Web fundamentals MVC is based on ASP .NET and industry is trying to shift as and when they can from Web Forms to MVC and reap the benefits it offers.

Did you know that MVC is much older than ASP.NET? Yes, ASP .NET 1.0 was released in 2002 and MVC was created in 1979 originally named as “Thing-Model-View-Controller” but later simplified to be known as MVC.

In my view, I consider that there are now two technologies to build Web Solutions using Microsoft and based on your need you can pick one which works well for you. Usually, such technology selections are made by Architects assigned to the project.

So there is no such Golden Rule that every new or existing application has to be either created using MVC or migrated to MVC because MVC is latest and future of the web. Though it is.

Architectural Thinking – Brownfield Vs Greenfield Applications

All software applications you have worked or will work in future are either brownfield or greenfield.

Brownfield Development – When any existing or legacy applications needs to have new features or changes to address business needs; is known as the brownfield. In such situations, unless you are building new module or component you have less  / limited or no scope to use new architecture styles, patterns etc. The very reason of such limitations is because those old applications are build using an old version of technologies and latest versions of one technology/framework may not be compatible with old versions.

Greenfield Development – When a brand new project is being envisioned and no previous work is done in that or related area then it’s called Greenfield. In software industry, it doesn’t happen very often. But whenever it happens its Architect’s responsibility to figure out what is the best technology to address business needs.

Hence, it’s not appropriate to say that because MVC is so new hence every new web application must be made using MVC or if WPF is available in addition to Windows Forms so every desktop application has to be made using WPF. Whatever is the case neither ASP .NET nor Win Forms can be totally ignored.

Why and Why not Latest Technologies should be picked

First, let’s discuss Why Not

  1. Its brownfield and new technology don’t fit anywhere.
  2. If new technology or versions are introduced it will case a lot of build errors due to outdated references of non-supported library references.
  3. Business goals and software quality are not compromised by continuing to use current and available technologies like ASP .NET WebForms over MVC or Win Forms over WPF.
  4. You are not investing money in any extra off-the-shelf tools to handle issues which could have been handled by latest versions of a similar area of technologies e.g., MVC instead of ASP .NET Web Forms, or WPF over Win Forms.
  5. Many times team might not have a certain skill set which allows them to proceed with development using new technology options
  6. Many times budget allocation from a client may impact your decision to use and develop using latest technologies.
  7. If core/bestselling features of new candidate technology (MVC or WPF) are not being used at-least up to 50% then you have not achieved anything.
  8. Considering how soon client and business want to have an application ready, turns out to be major factor o dictate technology of choice.
  9. Client and business don’t bother how you do it; what matters is the end result and a workable/good – enough software.
  10. No way to use old legacy downstream applications with latest available technologies.

Why develop using Latest Technologies

  1. Greenfield software solution and no legacy or old piece of code is being used.
  2. The focus is more on Robustness, Testability, Object Oriented design, and quality. (This doesn’t mean previous technology can’t accomplish these; it’s about ease and inbuilt features and offerings).
  3. An amazing team with great skills to learn new technologies and adapt the changes.
  4. Company’s vision is to showcase products build using latest technologies.
  5. Client themselves want the solution to be developed using latest technologies and have the budget to support that.

Why MVC over ASP .NET Web Forms then

Note- this section assumes that you are aware of MVC benefits and general technical terms used below.

  1. Separation of Concerns is the core of MVC.
  2. Single Responsibility Principle is achieved by default.
  3. Unified and even better framework to work on WebAPI, Mobile, HTML 5, CSS3, Security, and Deployment (including Azure).
  4. Unit testing is easily achieved to have stable, robust and quality software solutions delivered continuously.
  5. Fast screen generation for CRUD operations via Scaffolding.
  6. Convention over configuration.

Summary

Based on my experience as an architect in the industry I would like to summarize that it’s very hard for any organization to keep up with latest version and technologies all the time because by the time you become comfortable with one version the newer is around the corner.

So if you are working on MVC 4, then see if you can learn and try some application being developed on your own. Or if you just happen to be in ASP .NET Web Forms world until now then I would encourage you to try converting that application into MVC for your personal benefit.

This will enforce you to learn new technology and apply those learnings; if you made some progress in that then in next interview you can proudly showcase your MVC knowledge and say that you migrated ASP .NET WebForms to MVC.

“Regardless of what you are using to make a living out of a job, you have to learn new ones to build a Career.”

 

Watch YouTube Video here

Introduction

.NET Client Profile is supported by .NET Versions 3.5 and 4.0. It is designed for client applications like Console Applications, Windows Forms, WPF Applications and so on. As we all know there are many types of applications and hence what is required by one application may not be necessarily required by another type of application. For example, System.Web is only used by ASP.NET / Web apps, this is of no use for Windows Forms app. The Client Profile version of .NET Framework is a lightweight subset of the Framework. This enables quicker deployment and small installation packages.

Let’s see how Microsoft made the .NET Client Profile

Microsoft removed some of the features from the .NET Framework to make the footprints smaller and optimized. Microsoft chose to remove ASP.NET, MSBuild, Advanced WCF features and support for Oracle databases to reduce the framework into a smaller and optimized footprint. Web Applications don’t support the Client Profile version of the framework. Web applications are server-side and so full .NET Framework installation is recommended, unlike client applications. Microsoft has removed the Client Profile from the latest version of .NET Framework 4.5 and hence with .NET 4.5 there is no Client Profile as shown in the image below.

Why .NET 4.5 doesn’t have a Client Profile

Now if you think from a deployment’s point of view, you would want your installer to be as optimized and small as possible, so it takes the minimum required on the client machine and this can be done by the Client Profile flavor of.NET 3.5 and 4.0. .NET 4.5 is already optimized and tuned for quicker deployment and takes a small amount of disk space for all type of applications. Hence, no more .NET 4.5 Client Profile.

 

 

Abstract

In today’s software development world; we are solving complex business scenarios and developing large business applications. Hence, proper designing is the major factor which contributes to the scalability and performance of any .NET application.

Efficient Resource Management

Resources are very critical for the existence and survival of any application. Examples of resources include objects, files, connections, handles, streams etc. Hence proper handling and cleanup of such resources is critical for the better performance of system.

Here are points to consider:

  • Should properly handle the object creation and cleanup if needed.
  • In .NET some objects offer a Close() method to do proper handling of resources. Some of those are db connection, Streams etc.
  • .NET provides proper structured blocks which can be used in your code to enforce the cleanup if situation arises. For example, finally blocks or using statements can be used to ensure that resources are closed or released properly and in a timely fashion.

Considerations for Crossings the Application Boundary

Applications live and run in their own territory which is defined by the Machine, Process or Application Domains they are hosted in or deployed on. I.e. if two applications communicate with each other across machine, process r app domain there is significant impact on performance of the application.

  • Cross application domain. Since in .NET a process is optimized to have multiple application domains which can then host application inside those app domains. This is the most efficient boundary to cross because it is within the context of a single process.
  • Cross process. Crossing a process boundary significantly impacts performance. You should do so only when absolutely necessary. For example, you might determine that an Enterprise Services server application is required for security and fault tolerance reasons.
  • Cross machine. Crossing a machine boundary is the most expensive boundary to cross, due to network latency and marshaling overhead. Before introducing a remote server into your design, you need to consider the relative tradeoffs including performance, security, and administration.

Single Large Assemblies or Multiple Smaller Assemblies

In .NET assembly is the unit of deployment; an application comes to an existence in the form of an assembly only. Any application you have built after compilation produces an assembly only. All the .dlls your project refers to are .NET Assemblies only.

When working on designing and architecting a solution it is critical to consider that different functionalities, classes and interfaces etc. should be part of one single chunky assembly or should be divided across multiple smaller assemblies.

Here are points to consider

  • To help reduce your application’s working set (in simple terms set of memory pages required to host the application in the process) , you should prefer single larger assemblies rather than multiple smaller assemblies. If you have several assemblies that are always loaded together, you should combine them and create a single assembly.
  • Reasons to avoid multiple smaller assemblies:
    • Since you have multiple assemblies consider the cost required in loading metadata for multiple smaller assemblies.
    • JIT compile time will be much more as per count of assemblies.
    • Security checks needed for multiple assemblies.

Continue Reading…

 

Abstract

SOA is a well-known term today, when we think of SOA; WCF comes in mind. Whereas WCF is a Microsoft technology to build SOA based software solutions. This article will help you understand what exactly “SOA” is as per real architectural way, why architects suggest SOA based application architecture and how SOA can be implemented etc.

What is SOA

SOA (Service Oriented Architecture) is an Architectural Design Pattern / Approach, under which distributed and decoupled applications can interact with each other. SOA is NOT a Technology or a Language.

SOA provides the infrastructure to the idea of how two different business entities communicate and work together. E.g. your bank offering Stock services, a travel site with feature to book a flight, a hotel, a car or even a holiday package etc., weather updates and currency rates etc. All such activities take place due to B2B integration; and SOA is the oxygen for such type of business activities.

Before a service can be consumed, a request message needs to be sent to the service (the provider, or callee) by its client (the consumer, or caller). A request message contains information about the operation the service is being asked to perform, and any additional data that the specific operation needs to have before executing. For example, a service that shows you a currency exchange rate needs to have two currency types and how much money you want to convert. E.g. 100 USD to INR

Why SOA

In today’s world we heavily rely on software systems for example a bank’s system communicates to various other software & database systems.

This usually cause Software applications to face following challenges:

  • Applications are becoming more and more distributed.
  • Business needs are changing very often.
  • Collaboration with other systems is becoming key to success of application. E.g. B2B scenario.
  • Operation costs need to be reduced.
  • Scalable, secure and reliable systems are needed by business.

SOA resolves these challenges by defining standards for interaction between decoupled systems and technologies based on policies and contracts.

SOA Objectives

SOA is intended to provide loosely coupled interaction between applications. Benefits offered by SOA are as follows:

  • Agility. Enables your business to adapt changes quickly.
  • Productivity. Can implement complex applications using SOA more easily than with other architectural styles.
  • Reusability. Able to reuse your services across systems instead of rewriting the same modules again and again in every system or specific to an individual system.
  • Reduced cost. Software Architects think of Build vs. Buy vs. Reuse, SOA based approach allows to either buy or reuse this feature/functionality; hence in most of the cases cost is saved by reusing the existing services, a lot of commonly used services are available for free.

Communicating with SOA based Service

SOA based services communicate with outside world via EndPoint(s). Hence, EndPoint is required to communicate with a Service.

  • An EndPoint is the access point to the service.
  • Accessing internal assets can be done only through the EndPoint.
  • The EndPoint controls who can access the service, what operations they can perform, etc.
  • Services may expose multiple EndPoint for various reasons (technology, topology, etc.).

Properties of SOA Architecture

Service-Oriented Architecture is based on four tenets:

Services handle data, not objects

Objects are known to have direct dependency on a particular technology, while XML data is not technology-specific. Hence, services communicate by exchanging data as long as they use the same standards by which the service operates.

Services are autonomous

In order to utilize a Service, client does not need to know the implementation technology and various other internal/implementation details. What all a client requires is the service’s address (I.e. EndPoint) and the information to send the data to.

Services have explicit boundaries

The service is responsible for exposing its information. Everything inside the service’s boundary is only accessible through the service EndPoint. The service’s boundaries are explicit, meaning that the service specifies precisely which messages it can receive and what the messages need to contain; messages that are not compliant with these specifications will be rejected with an error message.

Services expose contract and policy

The contract of the service defines the data which client needs to use when calling a service. Service contract also define the response that the service sends back to the client as result of call made to service.
The service’s policy defines additional information about the data that is being sent. For example, a policy can state that the data needs to be encrypted etc.

SOA Benefits

Productivity

  • Services are autonomous. Services have explicit boundaries. Services can always be moved to some other location.
  • Services depend on data. There is no dependency on the technology that creates the data.
  • Service autonomy simplifies testing
  • All major development frameworks (Microsoft.NET, Java) embraced SOA.
  • Development tools like Microsoft Visual Studio provide an excellent environment for building SOA applications using WCF, ASP .NET WebAPI or ASP .NET WebServices.

Agility

Continue Reading

 

 

 

Proper design is a major factor that contributes to the scalability and performance of any application.
Topics: 
* Efficient Resource Management
* Considerations for Crossings the Application Boundary
* Single Large Assemblies or Multiple Smaller Assemblies
* Code Refactoring by Logical Layers
* Threads are a Resource worth Sharing

My article on C# .NET Application Design Considerations can be read here