Comments

The art of asking “coding” questions

One question (or more accurately, comment) that I frequently get on my YouTube videos is:

… is not working!

Examples: “npm install is not working”, “interpolation is not working”, etc.

“It’s not working” is not helpful! It doesn’t tell me or others about the problem you’re facing.

What error do you get? Have you tried to Google the exact same error message? If not, did you know that if you do that, 90% of the time, you can find the answer to your question within minutes? In fact, 90% of the time, the first link on Google search result is a link to a page on StackOverflow, where someone else faced the exact same problem!

3 tips that make you a better developer

Tip 1: Learn the art of asking ‘programming’ questions. Be specific about why “it’s not working”!

Tip 2: Learn to find the answer to your question yourself. You cannot always reach out for help every time “it’s not working”. Successful programmers are independent. Linus Torvalds, the creator of Linux, even wrote his own editor and assembler! Now, you don’t need to do this to be independent, but a Google search takes only a few seconds and helps you become less dependent on other developers in your team.

Tip 3: Read about rubber duck debugging. It works!

If you enjoyed this article, please share it with others.

Comments

6 Essential VSCode Extensions for Angular Developers

In this post, I’m going to list my top favorite Visual Studio Code (VSCode) extensions for building Angular applications. If you know a great extension that is missing here, please let us know using the comment box below the post.

Installing an Extension

If you know how to install an extension in VSCode, feel free to skip this section. Otherwise, launch VSCode, and open the Extensions tab from the left side bar. Here, you can see the list of installed extensions. You can also search for other extensions. Once you find an extension, simply click the Install button. Then, reload VSCode and you’re good to go.

TypeScript Hero

This is by far my absolute favorite extension! You no longer have to manually import types in TypeScript. TypeScript Hero automatically imports the types for you as you write code. When pasting some code from somewhere else, you can also add all the missing import statements in one go!

Another useful feature of this extension is that it allows you to sort and remove the unused import statements. You also get code completion and several other useful features. Highly recommended!

Angular Language Service

This extension provides a rich editing experience for Angular templates. Imagine you have a field in your component as follows:

course = { 
   title: 'The Complete Angular Course', 
   author: { 
      name: 'Mosh Hamedani'
   }
}

With this extension, you’ll get auto-completion in your HTML templates:

Autocompletion

Bracket Pair Colorizer

This extension allows matching brackets to be identified with colors.

Bracket

Move TS

As your application grows, you may want to break it down into smaller and more maintainable modules. You’ll have to move files and folders around. But what happens to all your import statements? They break! So, that’s what this extension is for. With Move TS extension, you can simply move files/folders around and this extension will automatically update your import statements.

Material Icon Theme

Do you like to have pretty icons in the project explorer? Install this extension!

Angular TypeScript Snippets

Another useful extension developed by John Papa that boosts your productivity when building Angular applications. It gives you a bunch of code snippets that allow you to quickly generate code. There are snippets for creating a component, service, directive, etc. You may argue that now we can easily create these artifacts using Angular CLI and that is absolutely right. However, this extension gives you some useful HTML snippets as well:

Angular TypeScript Snippets

You can find the complete list of snippets provided by this extension here.

What is your favorite extension that you frequently use? Use the comment box below and let us know.

If you enjoyed this article, please share it with others.

Tags: ,
Comments

Get paid to work with Me!

I constantly get requests about creating new courses and with 24-hour days I’m constantly behind my schedule. There are courses that many of you have been awaiting for a long time!

So, to speed things up, I’m looking for a passionate teaching assistant who can help me produce new courses faster and support my existing students. This will be a part-time job with the potential to go full-time.

 

Requirements

In order to be considered for this position:

  • You should be a US citizen
  • You should be fluent in English and have excellent writing skills
  • You should be a great communicator
  • You should have a passion for learning and teaching new things

 

Responsibilities

As a teaching assistant, you’ll help me with one or more of the following tasks. This depends on your capabilities and interests.

Creating materials for my future courses
I’ll give you some direction about a course topic and your job will be to come up with the structure for a course as well as the detailed materials for each lecture. This includes the script, slides, examples, and exercises. I’ll use these materials to create new videos.

In order to be considered for this, you should have a fair amount of understanding of the given topic and have excellent writing skills (for writing the script).

Writing blog posts
This involves writing a clean, professional and properly formatted post on a given topic. You should have excellent writing skills and pay great attention to the readability and formatting of these posts.

Answering the questions on the discussion boards
You should have a fair amount of experience on a given topic (e.g. C#, Angular, etc) and be able to answer students’ questions. You don’t have to be an expert in the given topic but willing to research and guide students in the right direction.

Reviewing the upcoming courses
Once I record and edit my videos, you’ll have to watch each lecture and make sure all the videos are edited properly, all the supplementary materials are there and the course is ready to go live.

 

Apply

To apply, fill out the following this Google Form. Since I may be receiving a large number of applicants, I won’t be able to respond to each of you individually. So, I’ll reach out only to eligible applicants.

Comments

Common Angular Errors

In this post, I’m going to list the most common errors you may encounter while getting started with Angular. For each error, I’m going to explain what it means and how to solve it.

This post is a work in progress and I’m planning to add more errors. If there is an error you encounter often, please let us know by dropping a comment.

Error 1: ‘ng’ is not recognized

When creating a new project with Angular CLI, you may receive the following error:

'ng' is not recognized as an internal or external command.

This error is simply telling you that Angular CLI is either not installed or not added to the PATH. To solve this error, first, make sure you’re running Node 6.9 or higher. A lot of errors can be resolved by simply upgrading your Node to the latest stable version.

Open up the Terminal on macOS/Linux or Command Prompt on Windows and run the following command to find out the version of Node you are running:

node --version

If you’re running an earlier version of Node, head over to nodejs.org and download the installer for the latest stable version.

Once you have installed Node 6.9+, you need to install Angular CLI globally:

npm install -g @angular/cli

Note the -g flag here. This tells NPM that you want to install this package globally so you can run it from any folders on your machine.

Error 2: node_modules appears empty

When you run ng serve, you may receive the following error:

node_modules appears empty, you may need to run `npm install`.

Our Angular applications use a bunch of 3rd-party libraries. These libraries are stored in the node_modules folder inside your project folder. When you create a new project using Angular CLI, these third-party libraries should be installed automatically. However, if you’re using a corrupted or a buggy version of Angular CLI, these libraries are not installed. So, you need to manually install them.

To solve this error, run npm install from the project folder. This command will look at package.json in your project folder. This file includes the list of dependencies of your project. NPM will download and store these dependencies in the node_modules folder.

 

If you found this post helpful, please share it with others.

If there is an error you’d like me to add to this post, please let me know using the comment box below.

Tags:
Comments

Layered Architecture in ASP.NET Core Applications

One of the viewers of my YouTube channel asked me an interesting question. He mentioned in a typical layered architecture, he sees ASP.NET MVC building blocks (Controller, View, and Model) as part of the presentation layer. These days, however, a lot of modern applications are built with Angular/React on the client and ASP.NET Core (Web API) on the server. So, what is the presentation layer in this kind of architecture? Let’s see!

With this stack, we have the following layers:

  • Presentation
  • Service
  • Business Logic/Application Core
  • Data Access/Persistence

Presentation Layer

Your Angular components, their templates, and the models you define in your Angular app are all presentation layer artifacts.

Service Layer

The confusing thing about this layer is that the term “service” is overloaded and it means different things to different people. In the context of a layered architecture, it wraps an application and exposes the application functionality in terms of a simple API that the user interface can talk to. This is the classic definition. Think of it as the glue between the presentation and business logic layers.

Now, in our modern stack, our logical service layer is physically composed of two parts: one part is on the client (Angular HTTP services) and the other part is on the server (ASP.NET Core controllers). These Angular services and ASP.NET Core controllers are very cohesive. The methods on these services (eg CourseService.getCourses()) talk directly to the endpoints exposed by your ASP.NET Core controllers.

Business Logic Layer

In your ASP.NET Core controllers, you often use repository interfaces (ICourseRepository), domain classes (Course) and services (PhotoService). All these are part of the business logic layer. They represent the core of an application irrespective of any presentation or persistence frameworks.

Note that here I’m talking about repository interfaces and not their implementations. These implementations are part of the data access/persistence layer.

Also, note that the services we have here are responsible for orchestration. For example, when adding a photo to a course, first, you need to store that photo in the file system (or some other kind of storage), and then you need to add it to the database (using a repository interface). Here is an example:

// Store the file first 
var uploadsPath = Path.Combine(host.WebRoot, "uploads");
if (!Directory.Exists(uploadsPath))
    Directory.CreateDirectory(uploadsPath);

var fileName = Guid.NewGuid().ToString() + Path.GetExtension(file.FileName);
var filePath = Path.Combine(uploadsPath, fileName);

using (var stream = new FileStream(filePath, FileMode.Create))
{  
    file.Copyto(stream);
}

// Add a record to the database
var photo = new Photo { FileName = fileName };
repository.Add(photo);
unitOfWork.Complete();

You wouldn’t write all this logic inside an ASP.NET Core Controller. Imagine, tomorrow you decide to use a different framework. You want to re-use as much code as possible. By encapsulating this code in a service (PhotoService.AddPhoto()), you can switch from ASP.NET Core to a different framework with less effort.

But wait for a second…

Now, that strongly-opinionated developer comes and says: “But who does replace ASP.NET Core with something else? How often does that happen?” Let’s say never! By moving all this logic from a controller into a service, you put the responsibility where it really belongs. The result is cleaner, slimmer, easier to read and easier to test controllers.

Imagine a restaurant where the chef does it all. He’s at the door, welcoming guests, giving them a table, taking their order, then going in the kitchen, chopping the vegetables, cooking, washing the dishes, then coming out and giving the bill to the guests. Would you go to that restaurant? I hope not!

In a good and organized restaurant, there are a few people each focusing on only one job. The waiters/waitresses are purely responsible for welcoming the guests and giving them the bill. The chef is purely responsible for cooking. He or she doesn’t wash the dishes! By the same token, you should have classes that do only one thing and do it well. This is what we call separation of concerns. You should put the responsibility where it really belongs, even if you’re never going to change the presentation or persistence framework of your application.

So, once again, all your domain classes (Course), repository interfaces (ICourseRepository) and application services (PhotoService) are part of the business logic layer. They represent the core of your application completely decoupled from any presentation and persistence frameworks. This is what Uncle Bob defines as Clean Architecture.

Data Access Layer

This layer is all about persistence. Here we have implementations tightly coupled to Entity Framework (or other frameworks) for persisting and retrieving data. If you’re using Entity Framework, your DbContext belongs in this layer. So do UnitofWork and Repository implementations.

Splitting a Project

Now, a common (and bad) practice I’ve seen some developers do, is that they blindly split an ASP.NET project into multiple class libraries, one for each layer. And with this, they assume just because they have a class library called MyProject.BLL or MyProject.DAL, they have properly layered their application. But that’s not necessarily right.

What matters is the direction of dependency and coupling between classes, not folders or projects. You can easily organize your classes into folders and projects but these classes can be poorly coupled to each other, which results in spaghetti architecture. Read my blog post on the topic:

Should you split your ASP.NET MVC/Core projects?

 

If you learned something from this post, please share it and drop your comments/questions below.

Tags: , , , , ,
Comments

4 Common Mistakes with the Repository Pattern

As part of my new ASP.NET Core course, I’ve been encouraging my students to post their code to GitHub. While reviewing various solutions, I’ve encountered a few common mistakes in the implementation of the repository pattern.

One repository per domain

You should think of a repository as a collection of domain objects in memory. If you’re building an application called Vega, you shouldn’t have a repository like the following:

public class VegaRepository 
{
}

Instead, you should have a separate repository per domain class, like OrderRepository, ShippingRepository and ProductRepository.

Repositories that return view models/DTOs

Once again, a repository is like a collection of domain objects. So it should not return view models/DTOs or anything that is not a domain object. I’ve seen many students using AutoMapper inside their repository methods:

public IEnumerable<OrderViewModel> GetOrders() 
{
     var orders = context.Orders.ToList();

     return mapper.Map<List<Order>, List<OrderViewModel>(orders);
}

Mapping is not the responsibility of the repository. It’s the responsibility of your controllers. Your repositories should return domain objects and the client of the repository can decide if it needs to do the mapping. By mapping the domain objects to view models (or something else) inside a repository, you prevent the client of your repositories from getting access to the underlying domain object. What if you return OrderViewModel but somewhere else you need OrderDetailsViewModel or OrderSnapshotViewModel? So, the client of the repository should decide what it wants to map the Order object to.

Save/Update method in repositories

Yet another very common mistake! As I’ve explained in my YouTube video before, your repositories should not have a Save() or Update() method. I repeat: think of a repository as a collection of domain objects in memory. Do collections have a Save() or Update() method? No! Here’s an example:

var list = new List<int>();
list.Add(1);
list.Remove(1);
list.Find(1);

list.Save();    // doesn't exist!
list.Update();  // doesn't exist!

Another reason your repositories should not have a Save() method is because sometimes as part of a transaction you may work with multiple repositories. And then you want to persist the changes across multiple repositories in one transaction. Here’s an example:

orderRepository.Add(order);
orderRepository.Save();

shippingRepository.Add(shipping);
shippingRepository.Save();

Can you see the problem in this code? For each change, we need a separate call to the Save() method on the corresponding repository. What if one of these calls to the Save() method fails? You’ll end up with a database in an inconsistent state. Yes, we can wrap that whole thing inside a transaction to make it even more ugly!

A pattern that goes hand in hand with the repository pattern is the unit of work. With the unit of work, we can re-write that ugly code like this:

orderRepository.Add(order);
shippingRepository.Add(shipping);
unitOfWork.Complete();

Now, either both objects are saved together or none are saved. The database will always be in a consistent state. No need to wrap this block inside a transaction. No need for two separate calls to the Save() method!

If you want to learn how to implement the repository and unit of work pattern together, watch my YouTube video here.

Repositories that return IQueryable

One of the reasons we use the repository pattern is to encapsulate fat queries. These queries make it hard to read, understand and test actions in ASP.NET MVC controllers. Also, as your application grows, the chances of you repeating a fat query in multiple places increases. With the repository pattern, we encapsulate these queries inside repository classes. The result is slimmer, cleaner, more maintainable and easier-to-test actions. Consider this example:

var orders = context.Orders
    .Include(o => o.Details)
        .ThenInclude(d => d.Product)
    .Where(o => o.CustomerId == 1234);

Here we are directly using a DbContext without the repository pattern. When your repository methods return IQueryable, someone else is going to get that IQueryable and compose a query on top of it. Here’s the result:

var orders = repository.GetOrders()
    .Include(o => o.Details)
        .ThenInclude(d => d.Product)
    .Where(o => o.CustomerId == 1234);

Can you see the difference between these two code snippets? The only difference is in the first line. In the first example, we use context.Orders, in the second we use repository.GetOrders(). So, what problem is this repository solving? Nothing!

Your repositories should return domain objects. So, the GetOrders() method should return an IEnumerable. With this, the second example can be re-written as:

var orders = repository.GetOrders(1234);

See the difference?

What are the other issues you’ve seen in the implementation of the repository pattern? Share your thoughts!

If you enjoyed this article, please share it.

Tags: ,
Comments

Should you split your ASP.NET MVC project into multiple projects?

“Should I split my ASP.NET MVC project into multiple projects?” That’s a question that I get a lot! Almost every week! The short answer is: NO!

I’m not entirely sure how this trend started but I’ve seen some developers split an ASP.NET MVC project into multiple projects: a web project containing the presentation logic, plus two additional class libraries, often named [MyProject].BLL and [MyProject].DLL.

Tiers?

Also, it’s often incorrectly assumed that this structure makes an application multi-tier or 3-tier. What is a multi-tier application? It’s an application whose parts are physically distributed to different computers in a network. Web applications are often inherently multi-tired. In a web application we often have the following tiers:

  1. Client/Presentation Tier: That’s the piece running inside the user’s browser.
  2. Middle/Application/Logic Tier: That’s the part built with ASP.NET MVC (or other similar server-side frameworks) running in a web server.
  3. Data Tier: That’s the database, file system or any other kind of storage.

When we’re talking about ASP.NET MVC, we’re only talking about the application or middle tier. Separating an ASP.NET MVC project into three projects does not result in addition of new tiers in your architecture. You don’t deploy the DAL class library to a different computer! Most of the time (if not always) all these 3 projects (Web, BLL and DAL) are compiled and deployed in the same process on one machine; that is your web server. So, when someone visits your web site, these three DLLs are loaded inside a process (or more accurately an AppDomain) managed by IIS.

Layers vs Tiers

Layers and tiers are used interchangeably by some but they are fundamentally different. Layers are about logical separation, tiers are about physical separation: distributing pieces of a software application to different computers.

Layer is something conceptual in a developer’s head. A class library is not a layer, neither is a folder. You can put classes in a folder or a class library that belong to different layers and be dependent upon each other. This is a sign of bad architecture and coupling. Putting these classes under a folder or a class library like BLL and DAL does not immediately result in software with clean architecture and good separation of concerns.

Despite that, my argument is that these folders (BLL and DAL) can and should reside in the main web project and moving them into a separate class library does not add any values. It doesn’t magically create layers in your applications.

There are 2 cases for splitting a project into smaller projects: reusability and independently deploying those projects.

Reusability

One reason for separating a project into multiple class libraries is re-usability. I’ve yet to see the BLL or DAL part of a web application re-used in another application. This is what text books from 90s used to tell us! But most if not all modern applications are too specific and even in the same enterprise I’ve never seen the same BLL or DAL parts re-used across multiple applications. Most of the time what you have in those class libraries is purely to serve what the user sees in that particular application, and it’s not something that can be easily re-used (if at all).

Deployability

Another reason for separating a project into multiple class libraries is about deployability. If you want to independently version and deploy these pieces, it does makes sense to go down this path. But this is often a use case for frameworks not enterprise applications. Entity Framework is a good example. It’s composed of multiple assemblies each focusing on different areas of functionality. We have one core assembly which includes the main artefacts, we have another assembly for talking to a SQL Server database, another one for SQLite and so on. With this modular architecture, we can reference and download only the parts that we need.

Imagine if Entity Framework was only one assembly! It would be one gigantic assembly with lots of code that we won’t need. Also, every time the support team added a new feature or fixed a bug, the entire monolithic assembly would have to be compiled and deployed. This would make this assembly very fragile. If we’re using Entity Framework on top of SQL Server, why should an upgrade because of a bug fix for SQLite impact our application? It shouldn’t! That’s why it’s designed in a modular way.

In most web applications out there, we version and deploy all these assemblies (Web, BLL and DAL) together. So, separating a project into 3 projects does not add any values.

Use Cases for Physical Separation

So, when do you actually need to physically separate a project into multiple projects? Here are a couple of scenarios:

1- Multiple presentation layers: Let’s say you’ve built an order processing application. This application is a desktop application used by staff at your organization. You decide to build a web interface for this application so the staff can access it remotely. You want to re-use the existing business logic and data access components. As I explained earlier, one reason for physical separation is re-usability. So, in this case, you need to physically separate this project into three projects:

  • OrderProcessing.Core (contains both the BLL and DAL)
  • OrderProcessing.Web
  • OrderProcessing.Desktop

Note that even here I don’t have two projects (BLL and DAL). I have one project, OrderProcessing.Core, that encapsulates both the business and data access logic for our order processing application.

So, why didn’t I separate this project into two separate projects (BLL and DAL)? Because the whole purpose of this DAL is to provide persistence for what we have in BLL. It’s very unlikely that it’ll be used on its own in another project.

Also, following the dependency inversion principle of object-oriented design, the dependency should be from DAL to BLL, not the other way around. So, this means, everywhere you reference the DAL assembly, you should also reference the BLL assembly. In other words, they’re highly cohesive and inseparable. When you separate things that are cohesive, you run into issues later down the track.

2- Multiple applications under a single portal: Another use case that one of the readers suggested is where you have multiple small applications that are hosted in a single portal. So, from the end user’s point of view these applications are not separate; they are all different domains of the same application. But from development point of view, each application is independent from the others. Each application can have its own persistence store; one can use Excel, another can use SQL Server, and the other can use Oracle.

In this scenario, it’s likely that these applications are developed by different developers/teams. They’re often independently developed, version and deployed, hence the second reason for physical separation.

For this scenario, we could have a solution with the following projects:

  • OrderProcessing.Core (a class library)
  • Shipping.Core
  • CustomerSupport.Core
  • MainPortal (an ASP.NET MVC project)

Once again, you don’t see the BLL/DAL separation here. Each class library (eg OrderProcessing.Core) includes both the business and data access logic for its own domain.

The Bottom Line

Here are a few things I hope you take away from this article:

  • Layers are not tiers.
  • Tiers are about physical distribution of software on different computers.
  • Layers are conceptual. They don’t have a physical representation in code. Having a folder or an assembly called BLL or DAL doesn’t mean you have properly layered your application, neither does it mean you have improved maintainability.
  • Maintainability is about clean code, small methods, small classes each having a single responsibility and limited coupling between these classes. Splitting a project with with fat classes and fat methods into BLL/DAL projects doesn’t improve the maintainability of your software.
  • Assemblies are units of versioning and deployment.
  • Split a project into multiple projects if you want to re-use certain parts of that in other projects, or if you want to independently version and deploy each project.

 

As always, keep it simple!

If you enjoyed this post, please share it with your friends.

Tags: , , ,
Comments

Announcing my upcoming Xamarin Forms course

I’m excited to let you know that I’ve recorded and edited 7.5 hours of high quality content for my upcoming Xamarin Forms course.

Xamarin logo

In this course, I’ll take you on a pragmatic and step-by-step journey and teach you how to build native mobile apps for Android, iOS and Windows using Xamarin Forms and C#.

In particular, you’ll

  • Learn and understand the fundamentals of Xamarin Forms and its architecture
  • Build user-interfaces with XAML and code
  • Work with images
  • Present data in beautiful, interactive lists
  • Implement multi-page apps with navigation, tabs, master/detail pages
  • Build form and setting pages
  • Store and retrieve data from a variety of sources (file system, SQLite database and RESTful services)
  • Implement Model-View-ViewModel (MVVM) architectural pattern

This course, just like my other courses is packed with real-world examples, exercises and best practices. Not only will you learn how to use Xamarin Forms, you’ll also learn first-class tips to make your code cleaner and more maintainable.

Lectures also have downloadable source code so you can code-along with me while watching the videos.

 

Prerequisites

All you need to know in order to take this course is C#. At a minimum, you should be comfortable with classes, interfaces, events, delegates, lambda expressions and a bit of LINQ. If you struggle with any of these features, I highly recommend you to take my following C# courses to strengthen the fundamentals:

C# Classes, Interfaces and Object-oriented Programming

C# Advanced Topics

If you have any familiarity with XAML-based frameworks (such as WPF or Silverlight) it’s a bonus but not a requirement.

 

Get the course with a huge discount

The price for this going to be $150 but my subscribers can get it for only $20. If you’ve received this post in your mailbox, that means you are a subscriber. So you don’t have to do anything further. Otherwise, simply join my mailing list to get my upcoming Xamarin Forms and any of my other courses with big discounts.

 

Frequently Asked Questions

Do I need a Mac to take the course?

Not at all! You can use use Visual Studio on Windows to build and deploy apps to Windows and Android. You need a Mac only to build your app for iOS. And this involves simply adding a new project to your Visual Studio solution, setting it as the start up project and building it. That’s it! You don’t need to write any extra code.

So, no, you don’t need a Mac to take this course or learn Xamarin Forms in general.

 

Do I need to know about Xamarin.Android and Xamarin.iOS libraries?

Again, no! Xamarin Forms provides a simple, unified API for you to build cross-platform mobile apps. When you build your app for Android or iOS, it will internally use Xamarin.Android or Xamarin.iOS to map the common user interface elements to their corresponding native equivalent.

You need to know about Xamarin.Android or Xamarin.iOS only if you want to build custom user-interface elements.

 

When this course is coming out? I’m impatient and can’t wait! 

It’ll be live in mid September or a bit earlier.

 

So, if you want to get the course for only $20, join my mailing list now. Once the course goes live, I’ll send you an email with a coupon.

 

Preview

Tags: ,
Comments

Should you learn ASP.NET MVC 5 or ASP.NET Core 1?

A common question that I get a lot lately:

Mosh, I’m not familiar with MVC. I have some background in [ASP.NET WebForms, Classic ASP, etc]. Should I learn ASP.NET MVC 5 or ASP.NET Core 1?

A variation of this question is:

I’m confused about what to learn. What is the difference between ASP.NET MVC 5, ASP.NET MVC 6, ASP.NET 5 and ASP.NET Core 1?

So I thought to turn this into a short blog post.

ASP.NET x

ASP.NET Core 1 is the next version of ASP.NET MVC 5. Yes, the version number is confusing! It has gone through a few name changes. It started as ASP.NET vNext, then changed to ASP.NET 5, next was renamed to ASP.NET MVC 6 and eventually became ASP.NET Core 1.0. You’re not the only one frustrated about these name changes!

Scott Hanselman has explained the rationale behind these name changes perfectly in his post.

The Simple Answer

If you have little or no experience with ASP.NET MVC (any versions), and you’d like to learn it from me, your best source is my Complete ASP.NET MVC 5 course.

ASP.NET Core 1 is based on the same principles you learn in that course. More than 90% of what you learn is the same in the new ASP.NET. There are some improvements in the framework and the tooling. None of these are revolutionary! You can get up to speed with them by reading a few tutorials or watching a few videos. I’m planning to create a short (1 – 2 hour) course that helps developers with knowledge of ASP.NET MVC 5 transition to the new ASP.NET.

Having said all that, in my opinion, ASP.NET Core 1 is not quite production yet. There are still hiccups with Entity Framework 7 and unless you work in a very adventurous team, most teams and projects out there are based on ASP.NET MVC 5 or earlier.

Hope that answers your question.

Tags: , , , ,
Comments

Why coders should work 5 hours a day!

I have a strong opinion:

Programmers should work 5 hours a day.

Without knowing you or the kind of projects you’re working on, I can guarantee that 80% of what you deliver in a given day comes from the first 5 hours of your day. In fact, most likely within the first 3 – 4 hours, before your lunch break.

If I had a software development company and I was to employ you, I’d pay you the same salary as someone working 8 hours a day, but you’d work only 5 hours a day. I’d let you go home and enjoy whatever you like!

Unfortunately, despite living in the modern era, our workplace is still following a traditional system: the typical 9 to 5 working hours. While this may work for many industries, I don’t find it optimum programmers.

You’re at risk for RSI

There was a time I used to code for 12 hours a day, sometimes including weekends! Guess what happened? I started to feel pain in my wrists. Many know this as Carpal Tunnel Syndrome, which falls under Repetitive Strain Injuries (RSI) umbrella term.

My pain started in my wrists, and then travelled to my palms and forearms. At some point, I was in so much pain that some days I could only code for 1 or 2 hours and then I had to leave work. I used to be a contractor, so leaving work meant I was not getting paid! You can imagine how stressful this was, which made my pain even worse. Plus, coding has been one of my passions and thinking that I could not code like before was very depressing.

A lot of programmers develop this kind of pain at some point in their life. Some (like me) manage to recover (not 100% though), but for others, this remains a challenge for the rest of their life.

Many others develop pain in their forearms, neck, shoulders or lower back. All this can be due to stress, bad posture and working long hours without having regular breaks.

A simple solution

So, now you know that as a coder, you’re at risk for pain in your wrists, forearms, neck, shoulders and lower back. And you also know that most (if not all) companies out there still follow the traditional 9 to 5 system. So, what can you do to keep a healthy body?

Code for 45 minutes and then have a 5 – 10 minute break

Not only will this prevent you from developing all sorts of pains due to excessive use of keyboard, but it’ll also help you increase your productivity significantly.

Now, this formula sounds pretty simple but there are exceptionally few programmers who actually practice it. I personally think perhaps 1 out of 100 programmers take regular breaks when coding, maybe even fewer! But why?

I’m going to list a few “excuses” that most programmers give for not taking regular breaks. Read and see if you can relate to them.

Excuse 1: My employer thinks I’m wasting time

If your employer has problem with you taking a 10-minute break every 45 minutes, you need to look for a different job. I’m dead serious! Do you care about yourself and your body? If you’re reading this post up to this point, you certainly do.

You either need to educate your employer or leave them. Taking regular breaks not only helps you maintain a healthy body, but it also increases your productivity significantly. All this means, as an employee, you’ll perform better for that employer. You’ll write better code in less time. So, your employer should in fact encourage you to take frequent breaks.

Send this blog post to your manager and peer programmers and try to establish this culture in your company so everybody get up and have a 5 – 10 minute together. Make it fun. You can start work at 9am and have a break at 9:45am. Everybody gets up, do a few stretches or go for a short work.

Remember, break means detox from technology. If you’re still sitting at your desk but browsing Facebook on your PC or mobile, you’re not on a break. Get up and go for a short walk around the block. You’ll feel 10 times better when you get back.

Excuse 2: I’ll lose focus if I have a break

You won’t! It’s all in your head. When you leave your desk and go for a short walk or something else, your subconscious mind is still working on the problem even if you’re not actively thinking about it. When you get back to your desk, you’ll be fresh and ready to do another 45 minutes of ninja coding.

Also, just before leaving your desk, you can write down the stuff you want to remember. That helps too.

Excuse 3: I forget to have a break!

I can totally relate to you on this. It’s quite easy to lose track of time when you’re coding. The simplest solution is to set a timer on your phone.

You should discipline yourself, so as soon as you hear the alarm, you get up and leave your desk. Do NOT say to yourself: “No, I’m going to finish this in a minute and then I’ll go”. That one minute becomes five minutes and then eventually becomes hours.

So, one more time: discipline yourself so the moment you hear the alarm, you get up and leave your desk.

 

Share your thoughts

What are your excuses for not taking regular breaks? Share them in the comments section and I’ll see if I can help you with them.

Did you enjoy this post? Please share it with your colleagues and friends.

 

Tags:
%d bloggers like this: