DevOps gained a lot of traction last year, with many companies deciding to adopt the increasingly popular software development methodology.

So what is it exactly?

As mentioned before, it’s simply a software development methodology that combines, like its name suggests, Development and Operations. What it does is basically integrate every software development operation from development to deployment and delivery.

The principle behind it is a close and effective collaboration between all the stakeholders who are part of the software development process. It’s just that the emphasis is on combining development and IT operations, which brings us to our subject.

DevOps is all about continuous development, continuous integration, and continuous delivery. This generally gives the users a wrong notion that DevOps culture reduce the need for testers. But that’s not the case. DevOps assures that the product delivered meets the requirements of the customers, and is of the best quality. That means, software testing will be contributing a lot more.
 

DevOps without Integrated Testing

 
Organizations that adopted DevOps did it to achieve smooth and seamless operation of a continuous delivery model. A DevOps environment that doesn’t count on what QA can do will ultimately fail to achieve that ‘smooth and seamless’ operation. If the developers take their time doing just the unit test to check the functions alone, and then pass the responsibilities over to the QA to continue, it clearly creates a rift between development and operations which in turn will hinder the progress to meeting continuous delivery goals.
 

Role of Testers in a DevOps Culture

 
A successful DevOps environment will have testers involved in every phase of the development process. The QA and development operations should be closely knit, i.e. they should operate in parallel. Testers should work with developers during coding itself instead of waiting for the developers to provide a coded product. The developers, on the other hand, will have to share early testing responsibilities with the tester while the QA team determines and acquires the most effective tools and technologies to ensure that early testing is performed with the least disruption.

This approach actually benefits if the team faces challenges and failures. The developers and the testers can work together to overcome the challenges and rectify the issues, while ensuring that the requirements of the customer have been met.

The testers basically:

• Use automation to make their job a bit easier
• Integrate development and QA operations to increase stability in the continuous delivery phase
• Use automated tools for development infrastructure acquisition and provisioning
• Discover defects and evaluate customer requirements

Continuous Testing

 
One of the major benefits of early involvement of testers is that they will be able to implement test scripts and determine test cases while the coding’s being done. Experienced testers can provide immediate feedback to developers on the defects identified during the development phase. In addition, they will also get an idea on the effects of their implementation choices on later stages of the delivery pipeline.

So to conclude, testing should be ubiquitous, as in ‘present’ or ‘integrated’ in all the central processes in a DevOps environment.

Kentico, an esteemed content management and digital experience platform provider, recently released the latest version of its popular ASP.NET CMS platform, Kentico 10, which is more than meets the eye. Karol Jarkovsky, Director of Product at Kentico, talked about the issues the new Kentico 10 can deal with, and what the future holds for the product, over a Skype interview with Laura Myers, a tech reporter of CMS-Connected.

The company is known for the research it does prior to developing and releasing products. According to the Director of Product, their research saw frustrated marketers, content creators, and developers as they are swept over by the sheer complexity of various CMS tools they have to use, while not getting the advertised benefits of those tools.

This was stated as one of the reasons they developed the latest Kentico version as an intuitive tool that solves aforementioned issue by properly aligning both marketers and developers, while allowing them to get their job done faster.
 

Pain points

 
Karol also explained three primary issues or pain points Kentico noticed in the market during its research, which were also considered while they developed a rooted solution in the form of Kentico 10.

• Many organizations want to increase productivity but lack the necessary technology to do just that
• CMS lacks the capability to deliver enough context for businesses to achieve their goals
• CMS either doesn’t scale as needed or demands a price to do so

First pain point – Improving productivity

 
He further stated how the new Kentico addresses each pain point, and emphasized the importance of improving productivity. He explained with an example of how content authors spend about 10-15 minutes searching for the right image, and then spend more time optimizing it for various channels and layouts. Kentico 10 offers a solution for this in the form of responsive images management, which enables users to specifically predefine image variants. The system will only need a command from the user on the variants they want to be created, and the image will be automatically optimized accordingly before upload. This improves productivity, addressing the first pain point.
 

Second pain point – Context

 
Regarding context, Kentico pointed out that marketers struggle the most with three main issues.

• Converting prospects into customers
• Increasing existing customer value
• Attaining an ROI through marketing

The success of marketing campaigns directly influence the chances of achieving these goals. But Kentico identified a workaround which involves tweaking the marketing campaigns. Marketers learn and improve with failures. However, the tools available don’t let marketers tweak the campaigns they are already running based on their new findings. They will have to conclude the campaign, and start a new one from scratch.

As a solution to this, Kentico added a campaign management tool in Kentico 10 which enables marketers to tweak running campaigns on the go, rather than ending it and starting all over again while losing data in the process. Karol also mentioned that they added something similar to an analytics tool to the Kentico 10 in the form of ‘campaign journey tracking’. This basically gives marketers an analysis of the running campaign, enabling them to identify the point in the campaign that got the highest visitor drop outs. This indicates the points of failure and the steps in the campaign that can be improved. Though the solution addresses the context pain point, it also aids in productivity enhancement.
 

Third pain point – Scalability

 
Data sets in organizations today are larger than ever. 53% of the data in these organizations are estimated to be left unanalyzed. 45% of the organizations surveyed were unable to analyze data across disparate sources, and 42% do not feel they can analyze the data enough to gain beneficial insights.

The data will only keep growing. Consider Internet of Things (IoT) as well, and we will have over 20 billion ‘connected devices’ in the world by 2020. This means there could be a great increase in data volume and data fragmentation. A tool that scales itself along with growing data can make a significant difference. Keeping scalability in mind, Kentico made sure that the latest release of its CMS tool is the most scalable version to date.
 

The Future of Kentico

 
Karol also spoke about the future of Kentico in the interview, and what they plan to do now that Kentico 10 is out. He revealed that they have already started working on Kentico 11 which will be featured as an improved ecommerce solution that focusses on integrations. As organizations generally go for reputed, standalone ecommerce solutions, Kentico plans to provide integrations with those popular B2B/B2C ecommerce solutions.

This would be beneficial particularly to organizations in the mid-market as they wouldn’t miss a stable, effective CMS solution that matches their ecommerce functionalities well. The Director of Product also revealed that Kentico plans to work with ecommerce market leaders to develop optimal solutions that deliver the best of both CMS and ecommerce. He added that they will be improving data visualization, and the marketing dashboards as well.

As Kentico’s Bronze Partner, Verbat looks forward to more innovative CMS solutions from Kentico that caters to the needs of the market and help organizations meet or exceed the high level of customer expectations.

Software engineering is an amalgamation of a number of concepts, designs and other factors. You explore a bit, start to understand things, and then you realize there’s more to it than what you just understood. But for now, let’s stick to exploring one unique component of software engineering – design patterns.

Basically, a design pattern is just a contextual reusable solution to a commonly occurring problem in software design. It can also be a template that explains ways to solve a problem, and applicable in many different situations in real-world application development, particularly in .NET development.
 

What design patterns can do

 
In a nutshell, a design pattern:

• Hastens Software Development process by providing tested development paradigms
• Helps prevent issues that are difficult to detect but can cause major problems
• Improves code readability

In addition to this, design patterns can also help enhance flexibility. But when not used wisely, design patterns may degrade application performance while achieving that required flexibility.
 

Classification of design patterns

 
They were originally categorized into three:

• Creational patterns
• Structural patterns
• Behavioral patterns

Another classification was introduced later which proposed the idea of applying design patterns at the architecture level of a software. Model-View-Controller (MVC) pattern is an example.
 

Creational patterns

 
In this part of the blog series, let’s get into the details of the first category – Creational patterns.

They primarily deal with creating objects that are necessary for a particular scenario. They streamline object creation, thereby reducing the likelihood of certain design problems.

They are further classified into Class-creational patterns and Object-creational patterns. Class-creational patterns, like the name suggests, deals with class instances while the latter deals with object creation.

5 of the most popular creational patterns include:

• Abstract factory pattern
• Factory method pattern
• Builder pattern
• Prototype pattern
• Singleton pattern

Here’s a brief summary of each pattern and the purpose they serve.
 

Abstract factory pattern

 
This design patterns provides various ways to capsulize a group of factory objects without specifying their concrete classes. The client software normally creates an abstract factory implementation first, and then uses the generic interface to create concrete objects that are part of the theme without knowing the objects that are created from each factory.

The merit is that the pattern allows interchanging the implementations during runtime. They don’t have to change the code for that either. However, the system can become difficult to debug if the levels of abstraction passes a certain limit.

Factory method pattern

 
Problems arise when objects are created without specifying their class. A design pattern used in class-based programming, factory method pattern uses factory methods to deal with those problems. For this, the pattern creates objects without using constructors by using a factory method.

The objects will either be implemented by child classes after it’s specified in an interface, or implemented in a base class. They can also be overridden by derived classes if necessary. Its reliance on inheritance is quite clear from the way it works, and it doesn’t require initialization. Like abstract factory pattern, the factory method pattern also enables polymorphism. A good example is ‘javax.xml.parsers’ package, which features a lot of factories.
 

Builder pattern

 
To understand Builder pattern, you should know what a telescoping constructor anti-pattern is. When object constructor parameter combinations are increased, the result is a long list of constructors. This is where the telescoping constructor anti-pattern occurs. Builder pattern is meant to find a solution for this, by using a builder. The builder receives each initialization parameters step by step, to return a constructed object. It can also be used for objects that contain flat data (those that can’t be edited easily), and for encapsulating construction and representation codes. The only disadvantage is that the pattern needs a separate ConcreteBuilder for each type of product.
 

Protoype pattern

 
When a prototypical instance is used to determine the type of the objects that are to be created, the prototype pattern is used. The objects created can be cloned to generate new objects. The pattern helps avoid subclasses of an object creator, just like an abstract factory pattern.

In order to implement the prototype pattern, an abstract base class is necessary. This base class should specify a pure virtual clone() method. The client calls the clone() method on the prototype instead of invoking a new operator on some class name. Then a factory method with a parameter is called (that which designates the desired derived class) or invoke the clone() method provided by another pattern.

Unlike factory method pattern, the prototype requires initialization but doesn’t require subclassing.
 

Singleton pattern

 
This pattern primarily serves the purpose of restricting the instantiation of a class to a single object. Singleton pattern is ideal when only one object is required to harmonize actions across the system. What makes singleton patterns unique is the fact they are used by other patterns like abstract factory, prototype, and builder in their implementation. State objects are also often categorized as singletons.

Singleton patterns are often preferred to global variables as well. This is because they permit lazy allocation and initialization, whereas global variables almost always use up a lot of resources.

The right kind of project management methodology can do wonders in software development. However, when it comes to choosing one, people would want a lot of questions answered.

What is this Agile methodology we’ve been hearing about?

I’ve heard it’s quite similar to Lean methodology. Is it?

Does Agile actually mean Scrum?

Agile and Lean have been around for a very long time. But choosing one of two has always been under debate. There is a relationship between the two which is often misunderstood.

This is just a simple analysis of what each means, and how they are connected. But first, their history…
 

Lean

 
Originally derived from ‘Lean Manufacturing’.

Lean Manufacturing, according to Wikipedia, is a method devised for the elimination of waste within a manufacturing system.

The Lean methodology, from a software project management perspective, is basically a set of principles that will help achieve speed, quality and customer satisfaction.

You may have heard something similar about Agile development methodology as well. Therein lies the source of confusion.
 

Agile

 
Back in the days, there were some hardcore methodologies in software development. They were popular all right, but kind of defeated their own purpose. How?

You see, these methodologies started stultifying software projects, preventing them from providing the result they were meant to. Software projects were meant to create software that helped the customer. With those methodologies, things went sideways. At that time, the Agile Manifesto was formulated as a reaction….or better yet – a solution.

So Agile basically refers to the principles proposed in the Manifesto.
 

The confusion

 
A woman named Mary Poppendieck who had worked in a manufacturing plant, worked with her husband Tom Poppendieck, a software developer, to figure out a way to adopt some manufacturing principles in the software realm. That intellectual concoction, ladies and gentlemen, is what we call Lean.

Interestingly, Mary was also the founding board member of the Agile Alliance, that introduced the Agile concept. Strong lean-influenced ideas obviously had a key role in the origin of the Agile Manifesto.
 

Lean and Agile

 
History lesson is over. Time to focus on the topic at hand.

So the ideas from Lean manufacturing has been applied to software development. This kind of defines the way Agile works. Hence the similarity. Both Lean and Agile is based on a combination of customer-centric approach and adaptive planning. As a matter of fact, Lean manufacturing did influence Agile enthusiasts or Agilists as they are commonly called.

Lean is about eliminating waste right? So in the software realm, the idea is to eliminate anything that doesn’t have value, and work on only that which is absolutely necessary. That ‘anything’ could include documentations, meetings, certain tasks etc. Inefficient ways of working will also be eliminated, thereby delivering results faster.

Here’s what one can derive from Mary Poppendieck’s words.

Lean = Rapid Response + Quality + Discipline + Speed-to-market

Agile, on its own, focusses on short iterations. A functional software will be delivered in the end after thorough testing, scrums, sprints and a lot of other facets.

The Poppendiecks’ approach was to blend Lean with Agile. This Lean-Agile combo will include the iterations of Agile development, and the validation practices of Lean. They are deeply entwined when applied to a software development environment. One isn’t exactly an alternative to the other. So, in a nutshell, if you are using Agile, you are using Lean as well…and vice versa.

The point of interest is where you decide to use the ideas from Lean manufacturing in your Agile methodology. So there isn’t actually a victor in this face-off.

To conclude, there isn’t a big difference between two except at the core. Lean software development focusses on elimination of waste so as to improve the processes, while Agile software development methodologies adhere to the principles in the Agile Manifesto (eg: Scrum).

With that said, a good Agile development team will adopt the best technical and management practices (which will include the principles of Lean as well) that work best for them, and leave their customers satisfied in the end.

Technology plays a critical role in web stacks. Web stacks have always evolved in parallel with technology, over the years. We will be discussing LAMP stack and MEAN stack today.

LAMP stands for Linux, Apache, MySQL, and PHP/Python/Perl.

MEAN is an acronym for MongoDB, Express.js, Angular.js, and Node.js

There still seems to be a confusion when faced with a choice of MEAN or LAMP stacks for web development. The backend languages, server environment and databases are different for both.

Let’s discuss the pros and cons of MEAN and LAMP stacks with respect to 3 key areas – Web server, database and operating system.
 

The Web Server

 
Apache provides the web server for LAMP stack while Node.js holds that responsibility in the MEAN stack. LAMP stack has been there for a long time. And that is also one of the reasons why Apache is considered a mature technology, where you can get new extensions when they are available.

As for Node.js, it’s a relatively new technology. While you still get quite a few active plug-ins, you will still have to write your own plug-ins to cover those areas missing necessary functionalities. Node.js is event-based and also locks codes on the web server into JavaScript. This can complicate things when you try to convert a sophisticated back-end program.
 

Database

 
LAMP uses MySQL or other relational databases while MEAN works with MongoDB, a non-relational database. If you are in a situation where you have to translate the data in an existing SQL database, you will soon find it tiresome to remove redundant object attributes, and may have to rely on a custom software for this purpose.

Relational databases are comparatively easier to work with but is on the verge of becoming outdated. MongoDB features faster data retrieval and is more scalable though.
 

The Operating System

 
LAMP stack locks the operating system to Linux and its variants. There are no such restrictions in MEAN, as you can run it in any OS compatible with Node.js. Linux isn’t your only option if you are using MEAN stack, though it is still considered to be the best OS for a server environment.

Both LAMP and MEAN have pros and cons in all 3 key areas. Let’s assess a few more facts before concluding.
It is said that you can only master MEAN stack once you have mastered JavaScript. It’s going to be a tad tedious, but worth it. However, LAMP stack works with front-end JavaScript and back-end PHP, just comfortable enough for developers to develop an application without much worries.

While MEAN stack is faster and more scalable, LAMP is a tried-and-tested web stack with a secure infrastructure and a large support community.
 

Conclusion

 
Although many developers claim that MEAN stack will eventually replace LAMP stack, there are others who still believe in the latter’s potential. LAMP is time-tested, stable and sturdy, with tons of online tutorials and support availability. Its back-end architecture allows you to do whatever you want to do on the front-end. MySQL is still one of the most widely used databases.

MEAN stack features a single language from top to bottom, in addition to flexible deployment and faster data retrieval capabilities. You are free from micromanaging schemas and migrations in the database as it uses a non-relational NoSQL database. With JavaScript gaining popularity, MEAN stack is attracting more developers every year.

Deciding between LAMP and MEAN will mostly depend on the organizations you work for and the projects under development.