Author: admin

In this video, Jatinder talks about Six fundamental principles for improving web application performance. He also talks a lot about how we go about Decreasing CPU time and increasing parallelism on the client machine to achieve faster web performance.

While I went through the video, I captured all the tricks he talks about. And thought will be useful for others while they watch it. Please find below the tricks.

Quickly respond to network request

Avoid 3XX Redirections (63% of top websites use redirect)

Avoid Meta refresh

Minimise Server time for Requests

Use Content distribution Networks (CDN)

Maximise concurrent connections.

Reuse connections – don’t sent connection close.

Know your other servers – you are only fast as your weakest link

Understand your network timing

Minimise bytes downloaded

GZIP Compression Network traffic

Persist application resources locally (Windows 8 applications)

Cache dynamic resources in the application Cache (html5 app cache)

Provide cacheable content

Send Conditional request

Cache Data requests (jQuery AJAX calls)

Standardize File name capitalization convention.

Efficiently structure markup

Load pages in latest browser mode

Use http header to specify legacy IE mode

Link CSS in the top of the page header, never on the bottom.

Avoid using @import of hierarchical styles

Avoid embedded and inline CSS

Only include necessary styles in the page.

Always link JS at the end of the page.

Avoid linking JS in the header (use the defer & async attribute)

Avoid Inline JS

Remove Duplicate code (52% of the web have duplicate code

Standardise on a single framework

Optimise your media usage

Avoid death by too many images

If possible use Image Sprites

Use png image file format

Use Native image resolutions

Replace Images with CSS3 Gradients, border Radius

Leverage CSS3 Transforms

Use Data URI’s for Small Single view images

Avoid complex SVG paths

Video : Use preview images

Minimize media plugin usage

Proactively download Future media

Write Fast JavaScript

Stick to Integer math (Math.Floor)

Minify your JavaScript

Initialize JavaScript on Demand

Minimize your DOM Interactions

Built in DOM methods always more efficient (firstchild, nextsibling methods are faster)

The web optimisation is not easy and needs exhaustive, deep look and hopefully this check list helps while optimising your pages. Enjoy coding high performing applications. If you have more tips please provide them in the comments.

Microservices is a really becoming a famous architectural pattern that most of the new software written these days, just apply them. One of the most important differentiation between the traditional web services and micro-services pattern is the amount of common stuff across different subject areas. This calls for a discussion on how Eventual Consistency pattern is mandatory for successfully implementing microservices.

The micro frontend if gaining lots of popularity. You can read about microservices principles and micro frontends at

Generally, in a micro-service pattern, the API’s are split into small subject areas. For example for a CRM application, the subject areas are

Customer information – like name, address, email, phone

Appointment information – which customer, salesperson, when, where

Relationship management – sales/manager, what products, interests

Campaign data – offers, deals etc

Then micro-services are built for each of the subject areas. The microservices are logically and physically separated from each other. ie there is no sharing (code, database, component etc) between any of these micro-services of these subject areas. Pictorially its looks something like this.

Applying Eventual Consistency Pattern

In Micro-services, there is no data that is shared across the micro services. In order to synchronize the data across these isolated storages of these services, we need to apply the eventual consistency pattern. You can read more about applying the pattern correctly here. The simpler way we can achieve consistency across these micro-services is through Event Sourcing pattern.

Event Sourcing

Event sourcing is a process of capturing application state changes in the form of events. An example of events are customer created, customer updated, Deal created, etc. Other systems listen to these events and they take relevant action. You can read more about event sourcing here.

Conclusion

Event sourcing is the new way of storing changes to systems and help in making micro-services eventually consistent. These patterns together form well maintainable, reliable and scalable systems in the modern world.

This is the second post in the Getting started with MEAN series where we start looking at the Node ecosystem for stable web application frameworks for our application. A brief glance through the Express framework showed that express by itself would be time consuming start off with from scratch. On the other hand, the Express.js website links to a number of frameworks built on top of Express. This looked like a good place to start exploring.

Going through the list of frameworks mentioned there, however, we quickly noticed that a number of options were either targeted only (or primarily) towards APIs, lacked sufficient documentation for our needs, or did not appear to have a sufficiently large community behind them. Mind you, the assessment wasn’t entirely objective, as I did have previous experience with generator angular fullstack.

Why generator-angular-fullstack

Generator angular fullstack is a Yeoman generator that provides an application skeleton as well as sub generators that allow the developer to quickly scaffold various UI and API components. The generator supports a number of customizations through questions asked before generating the app. The ones I found most useful were:

Client Side

Html templating : HTML, PUG (previously Jade)

Angular Router : ngRouter, ui-router

Stylesheets : css, stylus, sass, less

CSS frameworks : bootstrap (with the option to include UI Bootstrap)

Server Side:

Scripts : javascript, Typescript

Databases : none, Mongodb, SQL

Authentication boilerplate

oAuth integration with Facebook, Twitter and Google Plus

Socket IO integration

Phew! That was a lot of options built into the generator itself, stuff that teams and products usually like to customize according to their convenience. This by itself is a strong reason to select the framework, because none of the other frameworks that we evaluated came anywhere close in terms of customizability and out of the box functionality. The generator also comes with built in hooks to deploy your application to Heroku or Openshift, although I found that part to be a little broken (more on that later)

A lot of things have changed though, since my last experience. For one, the guys over at generator-angular-fullstack added support for Typescript. Typescript in fact, is a superset of javascript, but brings a number of enhancements (including transpile time type safety) to the table. On the other hand, the generator still works with Angular 1.x, although the alpha version does support Angular 2. But then, working with the alpha version for a project needing quick turnaround times didn’t sound like an exciting thought.

Anyway, coming back to getting started with the application.

Getting Started

Installing Yeoman

npm install -g yo

Installing the angular fullstack generator and its prerequisites

npm install -g yo gulp-cli generator-angular-fullstack

On a side note, please read node-gyp’s installation guide before going any further to get the application to run successfully. Node-gyp is required to compile native drivers for each platform and on windows, there are a couple of different ways to support the compilation process. Personally, I was able to get option 2 on the link mentioned above working (see: “Option 2: Install tools and configuration manually”)

Initializing the App

Finally! Coming down to the crux of the matter. Initializing the app

Run : yo angular-fullstack

The installer asks a number of questions about customization, including the ones mentioned above, and once the installer has completed, you have a fully functional app (with authentication if you selected it during install) ready for you to work on.

Running the app is as simple as running : gulp serve

You just need to make sure that if you selected a database, it is running on your local box so the node API can connect to it. If the DB is not found, the application will simply crash, but you already knew that would happen 🙂

Stay tuned for the next article about the getting familiar with the code generated by the Yeoman generator

I’ve been helping out some friends with setting up a new site for their endeavors. The basic requirements were

The site needs to be a ‘single page application’ (SPA)

Should be light weight

Should be easy to deploy to one of the many available hosted environments

MEAN stands for the set of technologies used in application development, much like the LAMP (Linux, Apache, MySql and PHP) stack before it. The technologies and frameworks involved in the MEAN stack include Mongodb, Express Js, Angular Js, and Node Js. From a comparative standpoint, I believe that MEAN is popular today, for many of the same reasons that the LAMP stack gained popularity earlier.

Despite their limitations, both development stacks received a strong push from the community, have ubiquitous ‘Hello, World!’ tutorials, are supported on a number of cheap (and sometimes free!) PAAS hosting providers, and required little to no prior experience to get off the ground, giving instant results with minimal effort. They might not be the best dev stacks of their times, but the sheer inertia from their communities has also played a major role in the two being among the most popular web development platforms in the world today.

Why use the MEAN stack

One of the primary advantages of the MEAN stack that the code is written in Javascript, through all layers of the stack. This means that the programmer’s experience with one language (Javascript), is reused for everything, including persistence and server side code (in addition to the usual client side manipulation using a UI framework, which in this case, happens to be AngularJS)

The other big advantage of having javascript at all levels in your dev stack is that objects don’t need to be marshaled and unmarshaled when moving from one layer to another, usually removing the boilerplate code responsible for such conversions. This also helps developers take advantage of Javascript’s loosely typed nature to manipulate data as and when needed. Considering that Mongodb is a document database, and ‘documents’ don’t really *need* to have a fixed schema, this lines up pretty well with Javascript’s the loosely typed nature allowing us to do some really interesting things.

One of the drawbacks that I have personally experienced, however, of the MEAN stack is that developers with prior experience primarily in relational databases tend to continue to think in terms of tables. Relating collections to tables, and documents to records isn’t wrong, conceptually, but the patterns for relational patterns don’t necessarily lend themselves favourably to NoSql databases. Relational databases tend to have long, mature histories with a standardized set of interfaces and features that a developer can reasonably expect to get if he chooses any of the competing options out there.

Sadly, in my experience, NoSql is nothing like that. Different implementations (read databses) have widely differing ideologies on the ‘Right Way’™ of doing things, and they are correct! This is mostly because each implementation seems to be built for a slightly different use case, that needs different trade-offs to make the system function efficiently (for the chosen scenario). This doesn’t mean the databases can’t be used for anything outside their original intended mainline use cases, just that the default settings for the system may not be the best for you. The minor differences in behaviors also means that again, patterns identified for one NoSql database may not be the best for a different one.

While this may change in future as the stack matures and ‘enterprise patterns’ (I hate that term, but it seems apt for this situation) emerge and become ‘common knowledge’ ingrained in a majority of the developers out there, this is not the case today.

There are lots of practices that need to be followed while doing XP as an agile methodology. And one of them is automated testing. However, there is lots of confusion in the tech industry if you want to test the behavior of the system or the subunits/parts of the system. First, lets us understand these terminologies. In this post, we will talk about Test driven development.

TDD (Test Driven development)

TDD or Test Driven development is an approach in which unit tests drive the development of the code. That is, when there is a new feature that needs to be developed, the unit tests corresponding to the feature is developed first before the actual code need to create the feature is coded.

Let’s take an example. Let’s say at a point of sale system, we need to calculate the bill based on the list of products picked by the consumer. Let’s write unit test corresponding to this code. (I have used C# based XUnit as the unit testing framework)

This is the known part of the problem. i.e in mathematical terms, it’s part of the problem. In the example, we have initialized the variables and known things corresponding to the products (selected by the consumer) and the Biller object.

When

This is the business action based on which we are writing the code. In this case its GenerateBill action/method.

Then

The purpose of the tests is to ensure that the code/action does it properly as per the plan. In order to do that, we are asserting the assumptions/result of the method we are testing. In our case, we are asserting the total amount that the bill will have to be generated for.

Running the test

There are three stages of running the test.

Red – When we run the test now, it will fail as there is no code corresponding to the calculate bill functionality.

Green – In order to fix the above test, let’s write the real code corresponding to the above unit test/requirement.

Now, when we call GenerateBill method from the test, it will return the Bill with the total amount.

Refactor – With the above code written corresponding to the test, we are sure the functionality is correct as per the requirement. But the code is not optimal, as the foreach loop can be reduced to a simple C# LINQ expression.

TDD is a foolproof approach to developing software as per the requirement. The test also provides confidence to the developers on the edge conditions and other possibilities in the code. However, there is an alternative thought that TDD could waste developer time. Do you think, TDD is the right approach to software development? Please provide your comments.

AWS Lambda and Azure functions are truly next generational in the sense of the cloud computing. These services simplify the amount of time it takes to move to a cloud-based solution. Following are some of the advantages of running services directly in functions/Lambda.

No infrastructure code

Easy scaling

Easy deployment

Gives focus on the business

In this article, we will explore how to create a simple azure function and execute it in simple 5 steps.

1. Search for Functions in the Azure Portal and select it.

2. Click on “Create” and Create functions form should appear.

3. Enter the App Name, Subscription, Location and select “Create”. After it is created, you should see a page like this.

4. Select “Functions” from the left menu and on the right side select “Webhook + API” and click on “Create this function”.

5. Below screen appears where you can write code for the function and deploy the same. Edit code and select “Run” to update the deployment and run.

That’s all and functions are as simple as that. Hope this article helps in creating functions with Azure simpler. Please feel free to post your questions in the comments section.

Most of the teams in the software world follow Agile process and practices. Following Agile is fundamentally different from being Agile and in this article, we will talk about some of the actions you can take today to be more agile.

do you follow?

Shed Ego: Ego is a big blocker for our progress irrespective of being in the Agile world or not. But this becomes even more evident and blocks our every step in an Agile environment. There are lots of articles about egoless development.

Be open to collaborate : When we are open and talk our mind, we automatically become more agile. The restrictions and mental blocks to speak our mind openly to the team are the biggest bottlenecks to free flow of information and ideas. Psychologists call it emotional security to speak our mind.

Don’t Use communication tools: In this age of technology, the tools are plenty for communication, but none of them provide the connect of the face to face communication. (Agile principle)

Focus on the outcome: Lot many times, the agile manifesto is being misinterpreted (“working code is a measure of progress”). Unfortunately, it does not talk about production. Some teams get very complacent when they get their working code in “QA” or “Stage” environments for example. There is no result when the working code is not in production. At the end of the day outcome matters.

Get things done: Just like any other methodologies, the trap always exists when teams get lost in the process and meetings. The important part of the business and the product is to deliver things. So never move eyes away from the delivery.

These are the few actionable you can take today to be more agile and be awesome developers and technologists. So take action now!

In Agile environment, some of the committed stories may not be completed at the end of the iteration. For example, in Scrum, the stories roll to the next sprint. There could be various reasons why some of the stories could not be achieved. Reasons include (not limited to) blockers, inefficiency, improper sync between team members, missing clarity, support from other teams, priority etc. A casual look on this can make someone think this is normal. But sprint success has a huge impact on the long term success of the team and the product.

Fig: Success

Following are the some of the reasons why sprint success is important.

Morale : The team members self esteem actually gets higher when they achieve their goal. This breads confidence and help them to get better a their game, which can lead to more success.

Habit: Success breads happiness and more success. At the same time, failure breads failure. Also success/failure on one aspect of life can cause ripple effect on the rest of the life. We should be focused on success on every aspect of life so that it can bread in to itself.

Fig: Habit Loop

Fine reputation: More than any thing else, team will be very proud when they are able to successfully achieve the sprint goals consistently. Their reputation and respect around the company can actually go up and they will have to live up to that standard.

High standards: Team starts to set higher standard for themselves when they have high reputation. This helps them to get better at questioning, coding, testing, deploying and showcasing etc and improves their living standards in a holistic way.

Team bonding: When the team have a standard to live up to, they come together and get the things done, keeping aside the petty things. The goal becomes bigger than individuals and deliver thing as a team. This leads to higher team bonding and it reinforces their standards, reputation, habit and morale.

These are some of the main reasons why sprint success is important. When we focus on success, more positive things happen to the team and to the product that they work on.