This guide to Vue vs. React will give you the info you need to make an informed decision about which framework is best for your needs. But first, let’s check out the statistics.

According to a recent w3.techs report, React is used by 2.3% of all websites, giving it a market share of 2.8% for JavaScript libraries.

This graph depicts the percentage of websites that use the selected technologies over time.

While JavaScript frameworks are now required for web app development, many companies and individuals debate whether to use Vue.js or React for their web development projects. This article will compare them in terms of performance, security, popularity, and other factors.

Let’s get the ball rolling!

Similarities

Vue and React are very similar and share many of the same properties and capabilities. The use of a virtual DOM is the most striking similarity.

Furthermore, both React and Vue:

• Work with any web app that already exists.
• Are component-based architectures with lifecycle methods.
• Propose a simple technique for developers to get to work rapidly.
• Have the advantage of Increased flexibility, speed, and performance.
• Provide a diverse set of libraries and tools.
• Have large and active communities.

What Is the Purpose of Using Vue?

Vue is a progressive JavaScript framework for creating user interfaces that is open-source. It supports the component-based approach to web app development, which consists of single-file components that are independent and loosely connected to allow for improved code reuse and development speed.

Advantages of Using React:

You may be aware of some of React’s features, such as the ability to create fully bespoke user interfaces, but the list of perks is far more comprehensive. Here are a few of them:

• Cost-effectiveness
• A fantastic user experience
• Popularity
• Enhancement of performance and speed
• Shortened time to market (TTM)
• SEO-friendly

Vue.js vs. React Native: A Detailed Comparison

Vue vs. React: Popularity

Checking how many stars a framework has in the GitHub repository is one of the most common approaches to determine its popularity. But it’s not the only measure—the kind of developers a firm wants to hire is a measure of popularity, too.

As of 2021, Vue.js has 181K GitHub stars and is the most popular JavaScript framework. React, on the other hand, is still growing, with 165K stars in second place.

According to Google Trends, firms in India were eager to hire React developers in the last 12 months, followed by Vue.

Another element to consider is the number of people who utilize each framework. BMW, TrustPilot, Vice, Adobe Portfolio, and a slew of other companies are among Vue’s users.

The BBC, Facebook, Airbnb, PayPal, Instagram, and many other well-known companies use React.

Winner: Vue 

Vue vs. React: Performance

When it comes to performance, React and Vue are usually equal because they share the same elements. To boost performance rates and shorten loading times, they use slow loading and virtual DOMs.

Both frameworks provide outstanding performance, and each has its own set of advantages. Vue, for example, has a modest benefit in memory allocation and setup time, while React takes the lead at runtime.

However, there are times when there is a significant variation in performance between the two. Consider the following example:

• When a React component’s state is moderated, all elements in its subtree are re-rendered.
• In Vue, however, these dependencies are recorded, preventing wasteful re-rendering.

Vue can manage a higher frame rate than React, which can only handle one frame per second.

Winner: It’s a Tie

Vue vs. React: Scalability

When comparing Vue and React for larger apps, React outperforms Vue due to its superior scalability. Because React apps use JavaScript, you can scale them using typical code organization methods. Furthermore, component reuse improves React’s scalability.

While Vue is scalable due to its large number of versatile tools, it is primarily used in small apps, although an app’s size depends on the architecture.

Due to the dynamic architecture, you’ll need to employ Vue’s frameworks and elements to overcome scalability issues. When comparing Vue.js vs. React Native enterprise apps, React may be the better option for future app development.

Winner: React 

Vue vs. React: Security

Vue.js and React have security vulnerabilities; however, Vue-based applications are slightly easier to secure than React-based apps. Nonetheless, authorizing automatic protection against XSS vulnerabilities is not possible.

To protect against security dangers and attacks, hire Vue.js developers to clean up HTML code before implementation or use external libraries.

React relies on security best practices to protect against XSS vulnerabilities, SQL injection, server-side rendering attacks, and other security threats.

Because React is so simple to use, ensuring that React applications are secure requires a great deal of technical knowledge and experience.

Winner: Vue

Vue vs. React: Documentation

When it comes to documentation, Vue is the clear winner. Vue’s website offers high quality and in-depth descriptions in various languages, and its documentation and API references are usually recognized as the best in the industry.

The documents contain clear answers to a variety of concerns and issues. However, because the Vue community is smaller than React’s, you can have a more challenging time finding the proper answers to questions not covered in the documentation.

Because React’s documentation is nowhere near as good as Vue’s, you’ll be relying on the community to help you solve problems. On the other hand, React has a large, active community and an extensive library of instructional materials.

Winner: Vue

Vue vs. React: Community Support

This is a critical component of any technology, as community guidance provides significant assistance, solutions, and tools.

Facebook built React, which it utilizes in its applications. As a result, it has a large following and an active community continually producing and maintaining new equipment.

Vue did not gain the same level of immediate popularity as React. When Vue.js was first released, many people thought it was arbitrary and were hesitant to use it.

However, Vue has witnessed significant growth and increased popularity in recent years due to the user community’s continued support.

Winner: Vue

Vue vs. React: Use Cases

Vue

As a growing framework, Vue can be integrated into an existing project in stages, depending on the project’s demands. For example, it might be used as a lightweight library to add interaction to a web app.

According to 76% of developers who participated in the 2019 edition of the State of Vue.js research, Vue’s most significant asset is “ease of integration.”

Vue.js also comes with superb auto-completion and features and the official Vue dev tool for debugging Vue apps.

React

Because React Native is designed for large-scale web development projects, using it for simple apps is risky. React Native’s design gradually meets in the long run, even though it simply requires standard code to get a project up and running.

Unlike Vue, React does not have an official routing or state management package. For practically anything, you’ll need to employ third-party solutions to construct complicated applications. Therefore, you can hire a Vue.js development company to get your project done on time.

Many well-known companies use Vue and React; here are some of them:

What Should You Use in 2021: Vue or React?

Each framework has its own set of advantages and disadvantages. Vue, for example, is quick and easy to use, thanks to its template and simplified syntax. React, on the other hand, allows for more flexibility in larger, more complex applications.

There is no apparent winner in this contest. The best framework is the one that fits your use case. Map your needs and requirements to the characteristics outlined in this guide to make the decision that is right for you.

The post Vue vs. React: Which Is the Best JavaScript Framework in 2021 appeared first on Simple Programmer.

As we move into 2021, Git remains relevant for a variety of reasons and likely to maintain its dominance for quite some time, as I’ll show you in this post. Git is a major part of a developer’s routine, and being informed about its current and possible future trends is important to one’s career.

Git’s Current Dominance

The strongest driving factor for Git’s present relevance is simply the fact that it is already the version control system of choice for the vast majority of developers. This means that individual developers, indie teams, academic users, and industry departments will continue to choose it, since that is what the developer community and talent pool is familiar with. The strong get stronger, and the weaker tools fade out of the mainstream.

It also means that teams who have been slow to adopt newer technologies like Git will continue to make the shift, likely at an increasing rate. There are many teams that still operate on more legacy centralized VCS tools like Subversion. This is likely because their organizations have been rooted in that system for many years.

However, more and more of them will be forced by economic factors to upgrade to Git. This is because Git provides more flexible collaboration workflows, and a larger share of their technical employees will be familiar with it. As we’ll see later, it is also extremely easy to migrate to Git a codebase previously tracked with a different tool.

Git’s Brand

The second most powerful predictor of Git’s continued relevance is its brand. When people think of version control and tracking code, they instantly think of Git. Even non-developers are familiar with code hosting sites like GitHub and BitBucket. GitHub especially is in the mainstream eye and consciousness.

A strong brand is important because it allows people in the world to recognize a product or service, participate in the narratives surrounding it, and help influence others to use it. It also allows the product or service to be associated with contextually relevant topics—in this case software development, programming, and collaboration.

This is especially true in our times, where so much influence is driven by Google’s algorithms and crawlers, driving traffic between associated topics. Git is like the Coca-Cola of version control. Ultimately, its brand will help it further engrain existing users while attracting new developers every day.

The Ease of Switching to Git

As I previously mentioned, users knowing about Git and wanting to switch to Git are one thing, but there needs to be a straightforward pathway for migrating legacy projects to Git. Luckily, Git provides thorough documentation for migrating from other systems.

The above guide contains steps on how to migrate code repositories to Git from Subversion (SVN), Mercurial, Bazaar, and Perforce.

Essentially, for each system, Git has a subcommand that allows interaction with that source system. For example, the git svn <subcommand> command set is used to interact with Subversion repositories. Think of each of these commands as a translator between the source system and Git’s backend.

Git even provides a custom importer that you can use to migrate your project from other systems that Git doesn’t support out of the box.

Git’s Minimum Viable Use Case

In general, version control can be a tricky topic for new developers to grasp as they learn programming. It isn’t the most intuitive set of concepts to learn, and it takes real-world practice on a couple of projects before getting the hang of it.

However, in my opinion, the “minimum viable use case” for using Git only requires learning a few relatively simple commands. Although Git is flexible and can support many different team workflows, there is a very simple pathway to learning the basics of Git. This is based around Git’s central concepts of the working directory, staging area, and committed changes.

The working directory is the set of code files and folders that currently exist on your filesystem. These are the files that you open in your code editor and make changes to. All version control systems have a working directory (or equivalent term), so this really isn’t unique to Git.

Once you’ve finished a particular coding task, like fixing a bug or adding a new feature, you can add your changed files to Git’s staging area (also called the staging index or cache) using the git add <file.ext> command. Think of this as a sort of purgatory for your code—it’s code that you are preparing to store permanently in Git once all your changes are placed there together.

The staging area is essentially a concept developed by Git. Other systems tend to skip this step, which in my opinion leaves out an important preparatory step that helps developers commit clean code.

The last part of the process is to commit the changes in the staging area to the Git repository. This is done using the command git commit -m “Commit message”. This takes all the changes that were added to the staging area and creates a new commit object, which is stored in your Git repository. This commit becomes the tip of the current branch, linked to the preceding commit in the chain, or parent commit.

The last three paragraphs essentially outline Git’s core functionality. The learning curve for these concepts is relatively shallow, which will keep onboarding new developers into Git’s ecosystem. Therefore, Git will continue to be an essential coding tool for new developers to learn.

Other Efficiencies in Git

In addition to the basic functionalities described in the previous section, Git has numerous other design principles and features that make it a more efficient tool than VCS competitors. These include lightweight branching and merging, a flexible reference model, a content-addressable database, and many more.

Before Git came along, existing VCS tools like CVS (Concurrent Versions System) made merging code a nightmare. With CVS, users often ended up with complex conflicting code changes that took a lot of effort to resolve manually. Git popularized the “merge easy and often” paradigm, where developers create new branches often, even for small features/fixes, and Git can usually handle merging the changes back into the main branch automatically.

This is great for developers because it minimizes the time and effort spent manually fixing merge conflicts.

Git also has an efficient reference model that is intuitive for developers without requiring them to get in the technical weeds. Git allows users to create names for their branches and to create tags that mark specific branch commits. Branch names and tags are part of a more general group of objects called references, or refs, that are pointers to underlying Git commits.

In addition, Git manages some refs, such as Git HEAD, to represent the tip of the current branch. These refs allow developers to easily understand which commits they are working with, without having to deal with complex Git jargon.

The last aspect we’ll touch on here is Git’s content-addressable object database. Git stores all of its data about your code in something called the object database. This is a hidden directory in your Git repository. When you track files with Git, add files to the staging area, and create commits, Git creates objects in the object database. These objects are named based on the content that they contain, which is why we call it “content-addressable.”

This allows Git to take advantage of numerous performance efficiencies and run various commands much faster than other tools.

Git Continues To Evolve

One final factor I will note is that Git’s code continues to evolve. Git has a very active open-source development community made up of a core set of developers surrounded by hundreds of other contributors.

Therefore, it is likely that even if other tools build out features that push the envelope of the version control industry, the expertise of Git’s developers will allow them to adapt and integrate similar functionalities into Git.

This gives Git a solid moat that protects the tool from the fast-changing technological competition of the 21st century.

Git’s Future

The factors described in this article form a strong argument for Git’s continued dominance in the future. Even if a new tool does prove to surpass Git from a technology or usability standpoint, it would take years for the majority of developers to switch away from Git to that new tool.

For comparative purposes, we can look at programming languages. Even very old programming languages like Fortran, C, and Perl are still in active use and development today despite the advent of newer alternatives such as Java, JavaScript, Python, Rust, Go, and more.

The key to staying power is that their communities live on. In my view, even if Git is surpassed by another tool, it will still hold a place in the software developer’s toolbox for decades to come.

The post Why Git is Still Relevant in 2021, and Will Be for a Long Time appeared first on Simple Programmer.

So, I prepared a talk and thought, why not make a blog post out of this? And here is the result. 

If you prefer to watch the talk I gave that inspired this post, you can check it out here:

You will learn what DevOps actually means and how you can implement its practices in your daily working routine. Doing so will save your code from the apocalypse, which means not using any of this can cause you to lose your code, get lots of stress at work, and in the worst case, even lose your job. Shall we?

What Is DevOps?

There is no perfect definition for DevOps, but the following quote fits pretty well. DevOps is:

a set of practices that combines software development (Dev) and information-technology operations (Ops) which is intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.

So, we have the development of software on one side and operating or running it on the other. The important factor is that lots of these practices can be automated, hence shortening the software development lifecycle.

Emotions or Motivation?

Before we get into the details of the DevOps practices and how they will benefit you, let’s talk about how DevOps might make you feel—and maybe how it will motivate you.

If you’re not implementing these practices at all, you might get into trouble. There are lots of tools that come with DevOps that will help you a lot when building your application. But if you’re not using any of these tools and practices, then—and believe me, I’ve been there—you might end up looking like this:

No DevOps at all. And ain’t that funny.

But when you do get started with the tools and concepts, the life of a developer gets easier!

You see, you might be more relaxed. Working on a project is fun. Maybe you can also grab a cup of coffee and just chill a little.

This is the most realistic scenario, or at least the most realistic goal.

Of course there’s also the dream where DevOps does everything for us. Everything is automated, you don’t have to do much anymore, and you can just chill on the beach.

But this is a utopia. We are not there yet. Our goal—your goal—should be the second picture.

Theory of DevOps

The theory of every software development life cycle is this: You want to turn coffee into profit.

The interesting part is the area in between. How do you get from coffee to profit?

Currently, that’s magic.

But guess what: It’s the kind of magic you can actually learn—and you don’t even need a magic wand. Keep reading, and by the end of this post, you’ll know how this magic works.

DevOps Magic and Its Benefits

Alright, now what is this DevOps magic?

As you can see here, the process of developing software is not a clean line that moves you from point A to point Z. It’s a recurring process of six stages.

We start on the top left, with planning. You get your tasks and feature requests, and you might have an idea for what your project is all about. Then you should start planning this project. Again, it’s not planning the whole way from start to finish; you iterate through several steps during the development. There are great tools and concepts for that.

Next is the build phase. Now we’re talking about coding. You start your integrated development environment (IDE) and implement the features you planned in the phase before. In this step there are tools to make sure your code is safe, and you can go back if anything goes terribly wrong.

Continuous Integration is a great way to deploy your code automatically. Continuous integration and deploy somewhat go together. We will get to the details later. Just remember, it’s a great way to deploy the code of your whole team.

Apart from that, there are a few great platforms to deploy your code to. If you want to make a web application and use a service where this app is running, pay attention during the deployment part.

Now when your application is running, you might want to monitor it. Is the server always running? Do any errors occur? This is the operate phase. You can use available tools to do that or simply implement a small solution by yourself.

Finally you need feedback. Is your app doing what it’s supposed to do? Is it fun using it? All that can also be done, of course, with tools like bug trackers, and then you use the feedback to go back to the planning step.

All these steps are surrounded by communication. By far the most important part. You have to communicate with your team. The great thing is that you don’t have to leave your home to do that.

In the picture above you can see that there are lots of tools you can use in your software development life cycle. Don’t worry, there is no need to know every single one. I will give some hints as to which tool might be a good choice, though.

You might have heard of git and GitHub, Google Drive, Slack, and so on. Lots of options for you.

One more thing before we get into the details. Why should you bother? Why use even more tools? What are the benefits?

Benefits

Well, it starts with your code. It’s a lot easier to work together with your team using certain tools. The code quality of your team will improve.

You will need less time to develop. Deployment, in particular, can be a pain. You’re much more organized so that you know what to do next and then, simply, do that instead of wondering how to get to a specific goal.

When you use certain practices and tools, you will find bugs that you otherwise wouldn’t have found at all. And finding bugs is always good for profit!

Alright, with these in mind, let’s take a closer look at the details of each phase, thus saving your code from the apocalypse.

Communication

The one thing you will have to do all the time while working on your project is communicate.

Whether it’s about planning, fixing bugs, or monitoring your application, you really should talk to your team about all these aspects—and sometimes to your clients as well. And sometimes even to yourself …

Since it’s not possible to sit in the same office all the time, it’s great to still have a tool where you’re at least available most of the time or where you can check if anything interesting has happened.

Of course, there’s email, but there are definitely better solutions.

That’s where Slack comes in. In essence, Slack is a chat client. You can download and install Slack or use the web client.

Then you can create your own workspace for free and invite all your team members.

After that, you have your own little workspace for your project where you can create different channels for planning, talking about bugs, random chatter, and so on.

Additionally, you can integrate several services with Slack. For instance, if you’re deploying your application, you can automatically send a message into your Slack workspace where everyone can see whether the deployment succeeded or failed. That way you don’t have to watch the deployment process by yourself.

And Slack provides several more features like file transfer and video calls.

I’m not getting paid to say this (as with all the tools I recommend here), but Slack is really a great tool to help you during development.

You can start using Slack absolutely free. So I recommend you go to slack.com and register your workspace right now.

Plan

Planning is a topic you shouldn’t underestimate. It can make or break your project. This is particularly the case if you think you will implement some features on the side that might be put into your project management method of choice.

Have you ever heard of the waterfall model or the spiral model? These are more or less outdated, but it’s still interesting to know how software was developed in the past and … well, sometimes still today. But there are definitely better solutions nowadays.

As you can see below, the waterfall model provides several steps. Every single step should be finalized before you move to the next one.

Can you imagine having all the requirements ready and never talking about them anymore because they should be clear to everyone? Of course, this almost never really works. Same for the design or even the implementations. The waterfall model is highly unrealistic in the real world.

Sure, there has to be a concept, a document, with ideally all the features the application should have. But to expect that there won’t be any changes will get you into trouble. What are you going to say if the customer wants to change something or did not really know what a certain part of the software should look like? “Time’s up, we have to start from scratch again, and it’ll cost another fortune?” I bet you’ll never see that customer again.

The spiral model was definitely better and very similar to the agile processes that are mostly used nowadays.

It’s all about iterations here. You manage your project in a way that you’ll go through each step many times. Again, it’s good to have a rough concept for the software, but details are discussed and implemented in the corresponding iteration. That’s also a great way to handle any change requests. You don’t have to start all over again.

So today, people use a similar approach, so-called agile development processes.

Here’s a quote from Wikipedia that describes agile software development pretty well: “It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.”

So, being agile means that you’re able to react quickly to certain events like change requests or bugs.

Instead of planning the whole development process from A to Z like in the waterfall model, you look at your project on a weekly basis or maybe every two weeks.

Of course you have the big picture in mind, but it’s important to always look at the next cycle, the next iteration, or as they call it in Scrum—one of the software development frameworks mentioned here—the next Sprint.

These software development frameworks—Scrum or Kanban—help you keep using agile development processes. Let’s take a closer look at both of them, starting with Scrum.

Scrum

This is the scrum framework. It looks complicated, but don’t worry; there’s no need to examine every single detail. This paragraph should just give you an overview of how things work and how Scrum can improve your development cycle.

As you can see, on the far left you’ve got your product backlog. In essence these are all the tasks, all the features, simply everything your final product should have when it’s done. These tasks or features are given by the so called product owner. She’s talking to the customer or the stakeholders or simply has her own ideas for the project.

But instead of climbing this whole mountain of things to do at once, you want to move one step after another. That’s what the sprint planning is for. Again, a sprint is one iteration and is usually set for one or two weeks.

In the sprint planning meeting—which might rather be a sprint planning day—you plan all the tasks for the next sprint. The result of this meeting is the sprint backlog: all the tasks that you and your team commit doing in this iteration.

In a perfect world you really have to confirm the tasks that wander into this backlog, because you’ll have to do it, and only you can estimate the time it takes to finish them. At least in theory. But nothing happens if you cannot meet the deadline. Sometimes, problems occur or estimations have been wrong. Usually that’s no big deal. That’s what reviews, retrospectives, and new sprint plannings are for.

During a sprint, there are the daily scrums. This should be a daily meeting that is really short. Every team member is just telling in short, with no detail, what she was working on, what she is working on at the moment, and if there are any problems. If there are problems, then you’ll talk about them after the daily scrum. It really is just for checking the current state of development.

This daily scrum is held by the so-called scrum master. This person asks everybody for their current situation and, if necessary, assigns new tasks. If there are any issues or a team member needs support, the scrum master is the person to contact.

At the end of a sprint comes the review, which is in essence a user acceptance test. This means you show your results to the client or stakeholders or any person that has the right to see the results. Hopefully, these people accept your implementations.

After the sprint, you reflect on what went well and what did not in the sprint retrospective. It’s the perfect meeting to give feedback and suggest any improvements.

That’s it! The next iteration starts.

Again, this was really just a short overview. But it should give you an overall idea how this software development framework works.

Kanban

What’s Kanban? Actually kanban is a scheduling system for lean and just-in-time manufacturing. It was developed by an industrial engineer at Toyota to improve manufacturing efficiency. By the way, the Japanese word “kanban” means “visual signal.” Often times your actual work as a developer is invisible. Using Kanban makes it visible, and you can show it to others, and keep everyone on the same page.

Kanban was brought to the software development world by David Anderson with the kanban board.

A kanban board is what you see above. It’s an example of the tool Trello. The board consists of columns and cards and wants to help your development team get stuff done! A card represents a task and a column a category or the current state of this task.

You can totally combine a kanban board with Scrum. As you can see, there is a column for ToDo cards, one for cards or tasks that you’re currently doing, and one column for finished tasks. 

You could also add a backlog column. In that case you could add all your product backlog tasks into that column. Then, for the upcoming sprint, you move the tasks your team wants to do in the ToDo column. As soon as someone grabs a task from there, it will be moved to the Doing column, and so on. You get the idea.

Another great thing about Trello or a digital kanban board in general is that you can add more information to a card. You can add a description to your card, assign team members, and add a checklist, and you could also add images or write comments. This is very useful if you want to track any bugs in your application—add a screen shot with a description and the debugging can start.

It’s a simple but very efficient project management solution. Of course, there are big tools like asana, monday.com, Basecamp, and more. But a kanban board like Trello can absolutely be sufficient. Again, it’s just a recommendation from my experience.

Build

Now here’s where the actual work is happening.

I cannot really help you with the IDE you are using to write your actual code. There are lots and lots of choices.

I do recommend Visual Studio Code, though, with several extensions if that suits your needs. It’s definitely my favorite IDE for projects in .NET, JavaScript, and TypeScript. You can also use it for Java or Python projects with certain extensions, for instance.

But that’s not what the “Build” part is all about. It is more about managing your code. And for that, you definitely need source control. Now what is source control all about? 

Source control means that you’re tracking and managing changes to code. But not only the code you are writing. It’s about the code of your whole team.

When you’re working on a project all by yourself, you might think you don’t really need source control. You might think you can manage your changes by backing up some files and that’s it. But I really recommend using source control even if you’re working as a one-man army. And even more if you’re working on a team, of course.

There are many benefits of using source control, like having a history of your changes, merging code changes of your team members, and creating feature branches.

Let’s elaborate on all that by the example of the source control system Git.

Source Control With Git

The source control or version control system that fits for most projects is Git.

Git was originally developed by Linus Torvalds, the guy who also created the Linux kernel. It will definitely help you to track and manage changes to your code, in particular when you’re working in a team.

So what does tracking and managing your code changes actually mean?

For starters, if you or one of your team members messed up, you can simply go back to a version of your application that worked. There have been times where people would copy and paste files from one machine to another and hope that everything worked. Believe me, I have been there. It was not a great time. Remember the shocked cat from before?

But not today. Today you have a so-called repository. Everybody in your team commits and pushes their code changes to this repository.

The screen shot you see above is a Git client, in this case called Fork. In essence, you see the Git repository here. You can see the whole history of commits. On the left you can also see that we’re looking at the master branch—let’s say it’s the main version of your code. We’re going to talk about branches in a minute.

When you commit your changes and you haven’t changed the same code someone else has changed, Git will automatically merge your code changes with the changes of your co-workers by itself. Isn’t that great? And it doesn’t even have to be different files. 

Let’s say you and a co-worker are working on the same file but on different functions. Git will manage to merge your changes. No need to copy and paste that stuff anymore. (If you’re new to this, then this might be life-changing!)

If, however, you and one or more of your teammates have made changes to the same code, then you might get a merge conflict.

This means there are already committed changes to the same lines of code you wanted to change. In the screen shot, you can see that Git doesn’t know which version of the code it should choose. Their version or ours?

In this case, you have to resolve this conflict by yourself by either choosing one side, selecting both, or quickly fixing the conflict manually in the editor. There are tools that will help you to resolve conflicts.

Most IDEs, for instance, already manage to do that. So one of the tools might be Visual Studio Code itself. Other tools that are specifically made for Git are TortoiseGit or GitKraken. You have also already seen Fork and Sourcetree. Most Git clients are available for free or at least have a free trial version.

If you’re not a big fan of clients with a graphical user interface, you can also stick to the Git bash, a terminal, or the command prompt—depending on your operating system.

But to make this work, you first have to download Git for your operating system.

After you have downloaded Git, you can either create a repository on your machine or on a server or use one of the free services online and just clone the online created repository to your local machine.

Cloning means that you basically download the repository and that your changes will then be tracked. This way, you can commit and push them—meaning upload—again. We’ll look into these online services in the Continuous Integration section further below.

Whatever you choose, every team member can then use this repository and push changes to it. It’s a wonderful centralized solution.

But that’s not all! Another great thing about Git is the ability to create branches.

Now what are branches, sometimes also called feature branches?

You can grab the current code base and create a copy of the current state. Then make changes to the code and push your changes without touching the copied code base, often referred to as the master branch.

Let’s repeat this because it’s important: You make a copy of the master branch and change your code without touching the master branch. This is great if you want to create a new feature and push your changes for this feature without the risk of destroying the working code base. That way, your code is safe in the repository and not lying around on your hard disk.

You see those colorful lines in the screen shot? These are different branches. Hero_images and google_verification are features that have been developed in their own branch, and after they were tested successfully, they have been merged back with the master branch, and your changes become part of the main code base.

If you don’t work that way, something like the following might happen:

These images have been taken from the trailer of the Sonic movie. Paramount published a trailer for this movie, and the community was not happy with it. You could say the first version represents code changes directly in the master branch without reviewing or testing them.

The second version was using a feature branch that has been tested and then merged into the master branch. Much better, don’t you think?

Containers

One more thing that will help you save your code from the apocalypse is Docker, or containers in general.

Let’s have a look at this quote from Wikipedia:

Docker can package an application and its dependencies in a virtual container that can run on any Linux server. This helps provide flexibility and portability enabling the application to be run in various locations, whether on-premises, in a public cloud, or in a private cloud. Docker […] allow[s] containers to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines.

Put simply, with Docker, you can fire up a kind of virtual machine that grabs everything you need (libraries, etc.) to run your application and just, well, run it. 

That way, you can test your application real quick every single time you make changes and tell for sure that your application not only runs on your machine but also on a completely fresh system. Maybe you want to have a look into that eventually. It might increase your productivity even more.

Continuous Integration

Continuous Integration is big and really useful. But what is it all about anyway?

I think this short description taken from GitLab describes it pretty well.

Continuous Integration is the practice of integrating code into a shared repository and building/testing each change automatically, as early as possible—usually several times a day.

I already referred to this in the Source Control With Git section. Every day you and your teammates work on a project, you might want to commit and push your changes to the code base several times a day.

Without a repository and without continuous integration, you would have to merge the whole code manually—again, several times a day. That would be really time consuming. So you would rather merge your code only once a day, once a week, or even just once a month. This causes lots of problems or at least annoying tasks.

With continuous integration and source control, this stuff is history.

You got your repository, you check your code in, and you don’t have to bother with this administrative work anymore.

Continuous Integration

This image shows what the usual process of developing your software can look like. In the quote from GitLab, they mentioned tests—more precisely it’s about automated tests.

You build your application; after pushing your changes, automated tests will be run; and if they succeed, your app will be deployed to your server, to the cloud, you name it.

Automated tests seem to be the operative element here, so let’s take a closer look

Automated Tests

The most known automated tests are unit tests and integration tests—together with test-driven development, but that’s another kind of development practice, which is outside the present scope.

Take unit tests for instance. As the name already implies, you want to test single units with these tests. Imagine you have a calculator, and you just want to test whether the addition or subtraction works. Then you write tests for only that part.

After you’ve done these tests, you might want to test whether all these units also work together. Is it possible to subtract and add numbers in one calculation? That would be an integration test.

Another example is to write unit tests for back end code but also write integration tests to see if the front end properly works together with the back end.

If you only use unit tests and leave the integration tests, something like that can happen:

You see, the sliding doors and the swing shopping gate work perfectly, but not together. Somebody definitely forgot to do some integration tests here.

As always, there are a bunch of testing frameworks you can use. Above is an example of the Microsoft Testing Framework. In Visual Studio you can see which test failed and which test was successful. If a test fails, you can also have a deeper look and find out what went wrong. Is it your implementation of the unit, or did you write a wrong test?

If you’re in the Java world, JUnit with Eclipse looks quite similar. Test results are on the left side, details or implementations on the right. You can also see that test implementations have their own annotations. So, there are specific rules on how to write your test and how to work with a particular testing framework.

Whatever you’re writing your software with, there will be a testing framework. Just look around. Angular on the front end already has its own test files, for instance.

Automated tests fit perfectly into the continuous integration process, but you don’t have to use them. Just remember, the idea behind continuous integration is that you write your code, push it to your source control repository, your app will be built or compiled on a server, the tests will be run, and after all tests have passed, your application will be deployed.

Continuous Integration Services

There are several services you can use for continuous integration. Some can do more, some less. Jenkins is one of the leading automation servers, for instance. But for your case, other solutions might be better.

In my experience, Jenkins and Hudson do a great job on continuous integration, and you can add more features through extensions. But there are also other platforms that provide complete DevOps solutions.

GitLab, Bitbucket or Azure DevOps (which even uses the DevOps term) want to be all-in-one solutions—and in my experience, they really are. Not only do you get continuous integration, you also get a repository, issue boards, ticketing, deployment solutions, notifications, lots of integration options with other tools, and so on.

Don’t get me wrong. The other services can do this, too, but you might have more work setting things up.

In the end, it’s for you to decide which service, tool, or platform you want to use. The best way to decide is to simply try them out and find the one that you like the most and that fits your requirements.

Continuous Integration Configuration

But let’s have a look at how you make continuous integration work on the example of GitLab.

The first thing you need is a configurations file. In the case of GitLab, it’s a yml file, called .gitlab-ci.yml.

You see that it’s just put into the root directory of your project.

This yml file consists of a script. You can define stages and then add commands for every stage or commands for the moment before or after a certain stage.

In these examples you see deployment scripts for a .NET Core back end and an Angular front end.

In essence, you just enter the commands you would also run when you want to build your application locally on your development machine. And then you add commands to publish the compiled application.

For example, in the .NET Core case, we run the dotnet build and the dotnet publish commands to publish the debug and release version. Regarding Angular, we call npm install to install all dependencies and then run ng build with specific configurations. Both applications, the back end service and the Angular front end, are deployed to Internet Information Services on a Windows Server.

One beautiful advantage of this is that you build the code every time like it’s the first time. Ideally, in case of an error, you never hear the phrase “but it’s running on my machine” again.

As mentioned earlier, there are ways to integrate a DevOps platform like GitLab with other tools like Slack. As soon as code was pushed or a build and deployment process has been finished, a message will be sent to a Slack channel. It will also add the commit message and the result of the deployment.

From there I can click on “Compare changes” or on the pipeline number of the deployment process.

“Compare changes” brings me to the actual commit where I can, well, compare the code changes. In this example you see the changed file with all the differences to the previous version of this file, like the added condition in line 290.

Clicking on the pipeline brings me to the result of the yml script. You see the commands like dotnet publish and the results of these commands. If anything went wrong, you would see the concrete error here, hopefully with hints on how to fix it. If everything went well, you see the “Job succeeded” statement.

That’s how continuous integration works. The code will be integrated in a shared repository; it will be built and tested automatically, several times a day.

We can even go a bit further with continuous deployment or delivery.

Continuous delivery adds that the software can be released to production at any time, often by automatically pushing changes to a staging system.

Continuous deployment goes even further and pushes changes to production automatically.

In essence, this means that you would not only build and test your code, but you would also deploy it to your running production server for that application. No need for manually moving your test or staging version to your production server. DevOps can do all this for you automatically.

Remember the cat on the beach? That’s how we’re getting there.

Deploy

We already talked about deployment while covering continuous integration.

Deployment is the process that moves your code to a server or platform where people can actually use it.

There are several ways to do this. You can rent your own dedicated server or a virtual machine or you use one of the many available platforms like Microsoft Azure, Amazon Web Services, or Google Cloud.

The big advantage of these three is that you don’t need to host and configure your own server. You just pay for what you actually need. You need a database and a little webspace for your web application? Great, just add these, decide how much memory and what processor you want, and you’re done.

Another great thing about these platforms is the option of scaling. If you need more power only for a short period of time, you can add more memory or anything else just for that period. If your application or user count grows, you can also scale for a longer-term.

When you have to rely on a server you manage by yourself, you might have to buy another one additionally or even migrate your application completely.

With GitLab and Bitbucket, you have great DevOps solutions, but you might have to get a server yourself, where your application will then be deployed to.

Of course, services like Microsoft Azure cost money. But, there are free options available, too. In this case, you can test the service for 12 months. You can test and deploy apps to virtual machines and use SQL databases, for instance. 

Mobile apps are also no problem at all, and another great advantage, with a service like Azure, you are able to gain insights from your user data and maybe improve your application and user experience based on that data.

Amazon Web Services is quite similar. There are also free options available, but they are separated in tiers. Some services are free forever, some you can test for 12 months, and others have a more limited trial time like 30 days. But again, you can add just the service you need.

The Google Cloud platform takes a different approach. Here you get a budget of 300 USD, which you can use to build and access anything you want. It’s great that you can also use special Google services and APIs like Firebase or the Google Maps API.

It’s important to note that you won’t get charged any fees automatically after your free trials ends. You have to upgrade to a paid plan by yourself first. This is really nice and customer friendly.

Bitbucket and GitLab look a bit different. There are free plans available as well, and I think, in most cases they are totally sufficient if you’re just starting out.

There’s a typical pricing model for Bitbucket. There are certain features available for free for a small team, including unlimited private repositories, a Trello integration, and continuous integration. If your team grows or you need more features, you have to upgrade to a paid plan.

Again, GitLab is quite similar. In the free plan, you already get unlimited repositories, continuous integration, and lots of integration options, too. It seems that it’s not limited to the size of your team.

With the paid plans, you simply get more and more features.

In the end it is up to you. What do you need? I recommend you compare the services, maybe start with a free plan, maybe even a service with limited features just to get the hang of it, and then switch to something bigger when you need it and when you’re more familiar with all the different features these platforms and services have to offer.

Operate

The next phase in the DevOps circle would be operating. Or in other words, monitoring your servers, logging information and occurring errors, and sending notifications if necessary.

Again, there are a bunch of services available that can help you with all that. Nagios, Loggly, dynatrace, and splunk might be some services you want to have a look at.

Nagios is all about monitoring. It can monitor your Windows or Linux system, any kind of server, your applications, and so on, and it will log the results of monitoring all this.

And, of course, there is a free trial available.

Here’s a structure of what working with Nagios might look like.

You have your objects on the left. These are usually any kind of servers. Nagios can then check whether everything is up and running and working as it’s supposed to work. It can also track performance data.

Then we have the status column on the right. This simply means that Nagios is able to send notification to you whenever and wherever you want them. So if, for instance, an error occurs, you can tell Nagios to send an email or SMS, or you can simply log it into a database or web application where you can check for these errors by yourself.

Again, everything is done automatically, and you don’t have to watch your servers the whole time by yourself.

Dynatrace is taking a different approach. They advertise their services with an AI-powered, all-in-one plattform. Instead of just monitoring and delivering data, they want to also provide interpretations and “answers” to your data. A free trial is also available here.

But for me the big question is, do you really need a service like this? Mostly, this kind of monitoring is necessary for medium to large companies. In most cases, you can try doing some logging and sending notifications by yourself but still automated.

Why not just write a logging service in your back end by yourself? You could write any information you want into a database or even a text file, and if any errors occur or exceptions are thrown, just send an email to yourself or to the development team with certain information like the date and time, the user triggering the error, and the request data.

You can then have a deeper look into the log, try to reproduce the error, fix it, and you’re done.

Feedback

We are slowly coming to an end of the DevOps circle with the last phase, feedback.

Feedback comes in different ways. We have automated status updates, IT service management (ITSM), customer relationship management (CRM) and bug tracking.

Put simply, we can say that ITSM focuses more on feedback for IT departments, whereas CRM focuses on the customer. Issue tracking can be a part of IT service management. But let’s have a look at some of these services first.

Feedback Services

We have services and platforms for IT service management, customer relationship management, and issue tracking here.

Some services are more relevant for customer relationship management. This means they focus on storing information about customers and providing them feedback, and hopefully, they result in increased profit. Because when you’re able to track customer information and give them the right feedback, your customers might be happier, buy more often, and recommend your services.

But I want to focus on IT service management or, more precisely, issue or bug tracking. Mantis, Bugzilla, Jira, and Trello are web applications that provide the option to write tickets and bug reports. Mantis and Bugzilla focus more on tracking bugs.

The purpose of an issue tracker like Mantis is to provide the option to add a description of issues in your application to said tracker. So as soon as an error occurs, you or a tester of your application adds a new issue with a title, a description of what happened, and maybe also what consequences this issue had. Did the app crash, did this bug just result in a strange UI behaviour, or anything else?

With Mantis or Bugzilla, you have a tracker that enables your whole team to collaborate and watch all bugs in your application.

As almost always, you can start a free trial or even have a sneak peek at the service. Because the official tracker of Mantis itself is open to everyone.

As you can see, we have a list of several issues. Some are unassigned, some are resolved, you can see a timeline of issues that have been created, edited, or commented on, and you can also view all the issues in detail.

Then you see properties like the severity, status, or the category of every issue. Of course you also see the date of the last update and the summary of what this issue is all about.

That way you hopefully get your bugs organized, and it will help you to make your software better. Additionally, with enabled notification, your team will know what’s going on all the time.

For instance, if a team member fixes a bug, the reporter of this bug can get a notification and already test the fix. Because thanks to continuous integration and delivery, the code with the fixed bug is already published and deployed to your test system, right? Great stuff!

Jira

Jira is just another example of that kind of software. But where Mantis focuses on bugs alone, Jira is usually also used for feature requests or any kind of tickets in general. But the core functionality is the same. Create tickets, track them, update them, finish them, and send notifications.

GitLab Issue Board

GitLab provides an issue tracking feature as well. You can even decide for yourself if you want to see the tickets or issues as a list or as a board. You can also add categories, severities, different colors, and so on. And this looks really similar to Trello.

And where do we find Trello again? In the planning phase, so right in the beginning of our DevOps circle. Issue trackers like Mantis might look different, but actually you could totally use the software you’re using to plan your development lifecycle to also track your issues.

If you’re using a DevOps solutions platform like GitLab, you don’t even need an additional tool.

You see where I’m going with this? We’ve come full circle. Giving and providing feedback results in planning your next iteration.

Save Your Code, Be a Happy Cat

So we’ve come full circle now. We went from planning to building, then to continuous integration and deployment, and then we entered the Ops part of DevOps where it’s about operating and feedback. Based on that feedback, we are able to plan the next step of development. All this is surrounded by real-time communication.

You’ve seen lots and lots of tools that can help you in every single stage of DevOps. What you use is totally up to you. Choose a tool for every single step, do things by yourself like logging exceptions and sending emails to your team, or grab one of the big DevOps platforms and do everything with one single service.

Just remember to implement DevOps in your software development life cycle. You don’t want to look like the shocked cat in the beginning, do you?

Try out different tools, and then find a way that suits you best. There are so many solutions out there that I think there is a right way for every team, every company, and every kind of software you want to build.

I hope you learned something and you got some new insights. If you have any questions, feel free to ask!

The post DevOps – Saving Your Code From The Apocalypse appeared first on Simple Programmer.

These days, TFS supports two types of source code management systems: Team Foundation Version Control (TFVC) and Git.

On the surface, both systems are very similar. You can commit your code changes, you can view the history of who changed what, and you can revert back to a previous state of your source code.

However, a more in-depth look shows you some crucial differences in the design of the systems—most notably, TFVC offers a centralized repository, while Git builds on a decentralized model.

These days, almost all newly started software projects use Git for source code management. Even Microsoft says that you should use Git for version control unless you have a specific need for centralized version control features in TFVC. Therefore, Git is also default for new projects in TFS.

Initially, TFS supported only TFVC, and support for Git as a source code repository was added later in TFS 2013.

I am sure there are a lot of software projects out there that were started with TFS before Git support was available. Therefore, those projects had to choose TFVC as the source code management system. And as nobody migrated them to Git, those projects have been stuck with TFVC since then.

For example, in my company we have at least half a dozen active software projects, which are using TFVC. For a long time, we haven’t seen the need to migrate them to Git.

If you are used to TFVC and have never really worked with Git, then you don’t know about the small but crucial differences.

There are a lot of benefits when you use Git instead of TFVC as a source code repository. In this post, I will give you four not-so-obvious reasons why those projects should be migrated from TFVC to Git.

The Benefits of Using Git Compared to TFVC

1. Git Supports Joint Work on the Same Feature

Imagine you want to implement a new feature, which requires a new table in the database, some changes in the back-end service, and also some new pages on the front-end. Only if all of these changes are finished will the new feature be complete and ready for production.

These tasks require different skill sets—some database knowledge, experience as a back-end developer, and some front-end skills. Often, these skills are not possessed by a single person and therefore are split among multiple people who have to work together to complete that feature.

This means that multiple people work on the same feature simultaneously and have to share their piece of the work at some point. So everyone holds a piece of the puzzle and only if you put them together will your feature be complete.

Sharing Work With TFVC

If the team uses TFVC, it is quite tricky to share incomplete work easily. Nevertheless, there is a way to create a so-called “shelveset” and share it with another developer.

A shelveset is just a specific version of your code that is not committed to a branch yet but can be shared with another developer. However, if you share a shelveset with your teammate, they will not be able to continue their work based on that shelveset. They can look at it, but cannot integrate their piece of work with it. This is just not possible with TFVC.

The usual workaround is to commit your piece of incomplete work to a branch—let’s call it the “dev” branch. Now your teammate, who is working on the same feature, can fetch it and integrate their piece with yours.

In this scenario, your commit will most likely contain incomplete and probably untested code, because the tests can be performed only when the other pieces of the feature have been developed.

And this is not a nice position to be in—especially for other developers on your team, who are working on a completely different feature. They will fetch your incomplete and untested code as well and therefore might experience some bad behavior of the software—even though they are working on a completely different feature.

Sharing Work With Git

In contrast, teams working with Git usually use some version of the feature branch model. For each feature, you create a separate branch and share that branch only with other developers who are also working on that same feature. Each developer commits to that feature branch, adding their part of the changes necessary to complete the feature.

Only when everyone has added their piece of work, and the feature is tested and complete, will the whole feature be merged to the dev branch. So your dev branch will never contain untested or incomplete code.

Therefore, when multiple developers work together on the same feature, it is very complicated to share incomplete work when using TFVC, but it is straightforward when using Git.

2. Git Allows You to Update an Existing Pull Request

Code reviews are a very important step in the development process, because they ensure better code quality and also make better teams.

Of the different types of code reviews, a lot of development teams use the asynchronous type by default. This review process is supported in Git as well as in TFVC.

In the world of Git, people use so-called “pull requests” to request feedback on a code change.

And TFVC supports “review requests,” which are, to some extent, similar to the pull requests in Git.

Both have the same purpose, which is to share code changes with another developer so they can review the code and give feedback for improvements.

However, there is a very crucial difference between a review request and a pull request, which has a very big impact on the process. Let me explain.

Updating a Review Request With TFVC

In TFVC, the developer working on the coding—or the coder—can send code changes that are not yet committed to a branch, to the reviewer. In essence, the coder is sharing a shelveset with the reviewer.

The reviewer then can make comments to improve the code and mark the review as “Needs work.” After that, the coder makes the necessary changes and has to create another review request.

The big downside here is that this second review request doesn’t have any connection with the first one. This means that the reviewer has to review all the changes, not only the last improvements. So for each improvement, the reviewer gets a new review request and has to review the whole thing again.

Updating a Pull Request in Git

In contrast, in Git it is possible to add improvements changes to an existing pull request.

When you have to make improvements based on the feedback from the reviewer, you commit those changes again to the same branch. These changes then end up in the same pull request and the reviewer has to review only those last improvements.

This fact makes the whole code review process a lot simpler when using Git, especially when the coder is a junior and the reviewer has a lot of suggestions to improve the pull request.

In such a case, you will have multiple code review cycles until the pull request is good enough and the reviewer is happy. In each of these cycles, the coder changes the existing pull request and the reviewer just has to review these changes instead of reviewing everything from scratch.

So, in contrast to the review requests in TFVC, the pull requests in Git support multiple commits. If an existing pull request is changed, another commit is simply added to the pull request and the reviewer needs to review only that additional commit. That’s why Git will save you a lot of time and effort during the review process, and therefore makes the team more productive.

3. Git Allows the Reviewer to Merge

When the reviewer approves the changes made to the code, those changes can be merged to the main line, usually the dev branch. In the Git world, you merge the pull request, while in the world of TFVC, you merge the shelveset. Although both processes seem very similar, there is a crucial difference:

In TFVC, the reviewer marks the review request with “Looks good” to approve the changes. But that’s all they can do. The reviewer is not able to merge the review request to the dev branch by themselves. This has to be done by the coder as a separate step.

As soon as the review request is approved, the coder has to check out the shelveset and then commit the approved changes to the dev branch. This means that, while the coder has probably already started with their new task, they are interrupted to perform that extra step by themselves.

In contrast, in Git the reviewer can merge the pull request immediately when they approve it. The coder doesn’t have to be involved in the merge at all unless there are any merge conflicts, which is more of the exception than the rule.

If you imagine that an experienced coder might produce a couple of pull requests per day, then the simplified Git flow makes the team more productive compared to the workflow with TFVC.

Git saves an unnecessary step for the coder and therefore makes the development workflow simpler.

4. Git Avoids Big Review/Pull Requests

Imagine you are working on a simple feature and you are extending the functionality of an existing class. It is an easy task; you just have to add a new method to that existing class and then you’ll be finished.

However, this additional method adds new responsibilities to that class. Therefore, you decide to rename the class to make it easier for other developers to understand what that class is doing.

Of course, you use the tooling of your integrated development environment (IDE), like Visual Studio, to rename the class. So, it is quite easy and the renaming is performed automatically everywhere in the code where the class is used.

But as the class is used in many different locations in the code, you end up with changes in 20 code files. But only one contains the important logic that needs to be reviewed.

If you have such a scenario while using TFVC, then you create a review request, which contains all the changes in one shelveset. This means the reviewer is forced to review all the files in the same detail, because they do not know where to focus. This is not necessary and wastes a lot of time.

Conversely, in Git you start with a new feature branch. Then you implement the new method and commit those changes. After that, you rename the class and commit again before you finally create the pull request.

When the reviewer is starting the review, they will see two different commits in the pull request. This results in two major benefits.

First of all, by reviewing the commits separately, the reviewer can easily follow the steps the developer took to create the feature.

For instance, if the pull request is really big, let’s say it consists of 10 commits and 30 changed files, then the reviewer can go through each commit one by one to follow the thinking of the developer. That’s of course way easier than having to look at each of the 30 changed files one after another without knowing which changes in different files belong together.

Secondly, the reviewer can also easily figure out which commit is important to focus on for the review.

For instance, if the commit message says, “Rename of class X to Y,” and contains 20 modified files, then the reviewer can safely assume that the rename has been done correctly by the IDE tooling and they do not need to focus the review there.

This means pull requests, which are split up in separate commits, can be reviewed a lot easier. This is because the reviewer can also follow the logical steps of the developer by looking at each commit in chronological order. They can also filter out changes, which have been triggered by the tooling of the IDE.

The fact that a pull request in Git can consist of multiple commits is the biggest benefit of all from my list. It just makes the whole code review task much more efficient and saves a lot of time for the reviewer.

And the lack of support for multiple commits for a big review request in TFVC is a major drawback. As the reviewer has to review the same piece of code over and over again, they don’t pay attention to details anymore and might miss a bug. That’s why even the quality of the code decreases.

This is the most crucial reason why you should move from TFVC to Git.

Moving From TFVC to Git

The good news is that, from a technical perspective, the move from TFVC to Git is quite easy. The bad news, however, is that you need to have your team on board with that decision, but people generally don’t like change very much.

I have covered the technical procedure in a separate blog post, so let’s focus here on the human side of the migration.

As I mentioned earlier, I am currently working on a team that is using TFVC. This is due to historical reasons, as the main coding projects have been started around 10 years ago—at a time when TFS didn’t have support for Git.

And as nobody on my team has ever worked with Git in a former job, they never had to get used to TFVC after working with Git. That’s why I believe that people don’t see these “minor” differences between TFVC and Git.

However, I am in the lucky position that I have worked with Git in my former job and therefore I do see these “minor” differences.

So I am currently in the middle of helping my team to migrate from TFVC to Git. For this migration, we are using the following five-step approach that you can follow in your own migration process as well:

Step 1: Involve People in the Migration

The people on your team should be involved early in the whole process of the migration. If you plan and perform all the tasks without your team, and then finally just drop the results on them, it is very likely that you will get a negative response.

There is the nice stone soup story, or the story of the boiling frog, which basically explains why you should involve your team while the water is still comfortable, as each team member can make their own contribution to the change.

Do the migration for test purposes and give your teammates access to the Git repository (repo) for testing and reviewing. While you still use TFVC, you can already create the Git repo and migrate your code, so everyone can see what the new repo looks like and play around with it.

Step 2: Host a Workshop to Introduce Git Features

Some people on your team probably haven’t worked with Git before. It’s a great idea to facilitate a workshop and show them how to use the most important features of Git. This will make it clear what a developer needs to know in their daily job in order to use Git.

A great tool to visualize the concepts of git is http://git-school.github.io/visualizing-git/.
With this tool you can easily explain how commits are always linked to a parent. You can also show that a branch is just a pointer to a specific commit, and so on.

You can’t expect everyone to spend time learning Git by themselves. Everybody has a lot of other work to do and won’t find the time, so you should plan a dedicated time to get the knowledge actively in the team.

Step 3: Hand Out a Git Cheat Sheet

As there are a few commands that are quite hard to remember, especially if you’re learning Git from scratch, it is a good idea to hand out a list of Git commands that a developer needs to use in their day-to-day work. This way, your teammates can look up important Git instructions easily.

Step 4: Set a Date for the Migration

After the workshop, everyone on your team should have some basic knowledge about Git. But you should give them some time to apply their knowledge on the migrated test repository before you really switch from TFVC to Git in your production repo.

Two weeks should be enough time so that people can play around in the test repo and ask questions in case something is not clear. Ask for their feedback; maybe you missed teaching them some critical parts.

Step 5: Switch to Git When Everyone Feels Confident

A couple of days before the migration date, bring your key people of the team together for a last session. In that session, you can discuss whether they foresee any blocking issues for the go-live. Then you can decide whether you have a “go” or “no go” for the migration.

If you decide it’s a “go”, then you have your key people on board for the migration. And if everything works out as planned, you will switch to Git a couple of days later. After that, you will enjoy the new power of the best version control system out there.

Migrating to Git: Not as Hard as It Seems

The migration from TFVC to Git is not as difficult as you may think. Actually, I was quite surprised by how easy and straightforward it is. By running just a few commands in your console, you can migrate your TFVC repository to a Git repository.

The new Git repo will be within the same TFS Team Project. Therefore, you can keep all your related functionality, like your user stories or builds.

For instance, you don’t need to do anything with your user stories, as they stay in the same TFS Team Project. Of course, you need to adapt your builds a bit to use the new Git repo, but the main parts of your configuration in TFS stay the same.

For testing purposes, you can run the TFVC repo and Git repo simultaneously side by side. When you feel confident that the team has the knowledge to work with Git, then you simply lock the TFVC repository by removing some permissions and continue your development on the migrated Git repository.

As you have seen, there are some major benefits when you migrate from TFVC to Git. The most important one is the fact that you can have multiple commits to a single pull request, making the whole review process much easier and more effective. What you will gain is simply higher code quality.

You can also work easier together on a feature and merge to the main branch only when the feature is tested, reviewed, and builds successfully.

If you already went through the process of migrating from TFVC to Git, please share your experience in the comments. I would be very eager to hear how difficult or smooth the transition went for you.

OK, if your team is still using TFVC, I hope I was able to convince you to make the switch to Git. And hopefully, in a couple of weeks, you and your team can enjoy the benefits of the most powerful source control system on the market.

Stay tuned and HabbediEhre!

The post 4 Not-So-Obvious Reasons Why You Should Migrate From TFVC to Git appeared first on Simple Programmer.

Why is this such big news? To get into that, we have to look at Microsoft’s history. For a long time, Microsoft had a negative reputation as being a closed shop, so to speak, and not being developer-friendly. The negative attitude that Microsoft had toward open source software (OSS) development (particularly the Linux development community) was revealed in a leaked internal memo that was widely circulated in 1998.

Clearly, Microsoft felt that their dominant market position was threatened by Linux and the open source community. This attitude, along with Microsoft’s near-monopoly position, and related wranglings with the U.S. Justice Department, made it clear that OSS would never be welcome at Microsoft.

That’s why its acquisition of GitHub may have been an unwelcome surprise.

To this day, there are members of the software development community who very much dislike Microsoft. But this sentiment is from 20 years ago. Is the negative reputation toward Microsoft among some people still deserved?

Let’s examine what Microsoft has been doing with and for developers lately.

In 2015, Microsoft launched Visual Studio Code, a free version of their full Visual Studio product. It’s an Integrated Development Environment (IDE). While it is slimmed down, the capabilities of Visual Studio Code can be enhanced with the many extensions available for it. And many of these extensions are developed by community members, much the way OSS is improved on, iteration after iteration.

Visual Studio Code is now the most popular IDE, according to the 2018 Stack Overflow Developer Survey.

Microsoft has recently contributed to significant open source projects, such as Node.js. The company also purchased Xamarin, a platform for developing mobile apps on both iOS and Android; Microsoft then open-sourced the Xamarin SDK (Software Development Kit). You can read John Sonmez’s post about Xamarin.Forms here, and you can read Jason Lowenthal’s post on why to contribute to open source projects here.

Why?

So why? Why did Microsoft start shifting away from its reputation as a monolithic, proprietary, and allegedly monopolistic company? Why the about-face to open-source-loving, community-driven, and sharing? Why the purchase of GitHub?

One key reason is Microsoft’s new leadership.

In 2014, Satya Nadella succeeded Steve Ballmer as CEO of the company. Before becoming the Microsoft CEO, Nadella was a key figure in developing Microsoft’s cloud infrastructure and services. Nadella was highly influenced by his time spent working in the cloud computing field. Seeing as most Apache servers run Linux, Nadella would have pressed Microsoft to accept open source and Linux.

Nadella’s influence has led to a Microsoft that is no longer primarily an operating system/software company. Instead, it’s now primarily a cloud company. In Q4 2015, approximately 20 percent of Microsoft’s revenues came from its cloud service, Azure. While Microsoft does have revenue from other sources, cloud services are the single largest source of Microsoft’s revenues.

In Q3 2017, Microsoft reported that Azure revenue grew by 93 percent: Azure revenues, as reported, were $15.2 billion at that point.

It’s hard to miss where Microsoft needs to direct its energies if its wants to keep making this kind of money in the future.

The GitHub Strategy

It seems apparent now that Microsoft is much friendlier toward developers and the idea of open source products than in previous years. And it looks like they’re more of a cloud company than anything else. Still, what’s the strategy behind buying GitHub? Microsoft is no nonprofit, looking to help the open source community. GitHub makes $110 million annually, and while that is not an insignificant amount for a small company, it’s peanuts compared to Microsoft’s annual revenues.

One possibility is that GitHub will be used as an onboarding platform for Azure. Microsoft will likely nurture GitHub and attempt to encourage enterprise clients to sign up for it, and then coax them onto Azure. One powerful possibility is that Microsoft will potentially integrate Github into Windows directly. Windows 10, with its free update from Windows 8, can essentially be seen as an advertising platform for Azure.

Instead of just reacting to open source and Linux, Microsoft has developed a nurturing strategy for open-source-inclined developers. It’s essentially been a steady drip campaign of development and influence. Promoting goodwill and providing value can be a very compelling marketing strategy—this type of behavior is much better received than that of punitive measures and combativeness.

This is the new era of Microsoft.

The Future

These are interesting and immensely rewarding times for Microsoft, and the company is looking to invest in the future. In addition to leveraging their cloud infrastructure to power SaaS platforms such as Office 365 for business consumers, Microsoft is eyeing future trends. Products using the hybrid cloud (a mix of data center and on-premises hardware), artificial intelligence, and the Internet of Things could all be in its line of sight.

Microsoft’s plan seems to be to make itself an indispensable service provider for major developers and enterprise alike. Heralded by its embrace of things it once rejected, the GitHub purchase cements Microsoft’s new era.

The post The Microsoft Myth and the Fate of Github appeared first on Simple Programmer.

However, when used in the wrong place, they can do more harm than good. It’s imperative that we learn how to use them correctly.

Since a design pattern is a predefined solution to a specific kind of problem, proven over time and known by the software community, you may be tempted to apply it as soon as you have a chance.

When you learn a new technique, it’s good to try it out in the wild as soon as you can. However, having the mindset of “looking for the slightest opportunity to introduce a pattern into the code” seems like a bad idea to me.

How can I know when it’s best to use a design pattern? As we’ll see below, assessing the likelihood of changes in different parts of our code and understanding the intent of the pattern we’re using are crucial to making the appropriate decision.

I’ve come to this conclusion by considering three things. Let’s take a look at them.

If you know and apply object-oriented design principles, design patterns will come out naturally

I believe that knowing object-oriented design principles and applying best practices like SOLID, KISS and YAGNI are far more important than design patterns themselves. If you apply these principles, patterns will come out naturally.

Let’s see it with an example. Suppose that we’re working on a small app that displays a music sheet. For the sake of simplicity let’s assume that, for now, we’ll just draw half and quarter notes.

Among the different classes of our system, we have this one:

As you can see, there’s a clear duplication here. The only difference is in the parameter applied to the drawNoteHead method.

After some consideration, you’ll likely come to the conclusion that a good way to get rid of the duplication is to do the following:

1. Create a generic drawNote method and copy the body from one of the existing functions.
2. Transform the parameter of the drawNoteHead method into a new method. Then, this method can be overridden by children classes, so the father class holds the basic logic and the children classes hold the differences.
3. Replace all callings to drawHalfNote and drawQuarterNote with the new drawNote method of the appropriate child class.

All right, let’s do it:

There might be other solutions, but we got what we wanted: we eliminated the duplication of the code.

Well, guess what?

You just applied the Template pattern.

Just like that. Without thinking about it. That’s the beauty of object-oriented design principles.

You may not know all the design patterns in the world, but as long as you know good object-oriented design principles, you don’t have to.

Of course, if you knew the Template pattern, you would have seen it coming right away. You would say “this is the perfect scenario for the Template pattern” and apply it. That’s the right way of applying patterns: when you clearly see that they fit and they make your life easier.

This brings me to my second point.

You might not need it at all

Sometimes we look at a piece of code, we cringe at how ugly it is, and we notice instantly that a pattern may make it better.

But what if it works and you don’t need to change it?

For example, let’s go back to our music sheet displaying app, but with a slightly different scenario. Imagine that we want to create one class for each type of clef. Our app is going to support all clefs based on the 3 basic ones: the C, the F and the G clef.

We have a function in our code that returns the correct instance of our clef. It looks like this:

Now that’s some ugly code. You’re probably feeling the urge to refactor it, right? Perhaps you’re thinking of applying the Factory Method pattern, and, yes, it would fit and definitely make the code cleaner.

But… what if I tell you that this code is not going to change… ever?

I’m not a musician, so I might be wrong, but it seems unrealistic to me that new notes are going to be invented in the future. If there are no notes added, then there is no need to change this code. It’s so unlikely that it’s simply not worth it to touch this code at all.

No matter how ugly a piece of code is, if it works and you don’t need to change it, refactoring the code (with a design pattern or any other technique) has a needless cost.

This brings me to my third point.

The cost of adding a design pattern

There are many different design patterns, but most of them have something in common: when you apply them, you need to lay out some structure. In other words, you need to add classes and/or interfaces to the code.

In the first example, this structure consists of an abstract class extended by two children classes. What’s more, in order for the old code to use these new classes, you also need to make some updates not directly related to the design pattern itself.

The moral of the story is: if you’re thinking about applying a design pattern, consider the cost of doing so and the potential benefit. Doing it only for the sake of doing it will make your code more complex than it needs to be.

How can I know when it’s best to use a design pattern?

That’s the million dollar question. It depends on two things: how likely a piece of code is going to change in the future, and the intent of the pattern.

The likelihood of changes in different parts of our code

The examples that we saw in this post showcase the importance of considering changes in order to decide whether to include a design pattern or not.

In the first example it was absolutely necessary to include a pattern. After all, we’re not going to settle with music sheets that only have half and quarter notes, are we? Since adding more types of notes would make the duplication problem worse, a pattern is needed in order to avoid that.

In the second example it’s exactly the opposite. Since we can safely assume that no clefs or notes will be added, this piece of code doesn’t need to be changed and therefore, there’s no need to include a pattern.

The intent of the pattern

It’s not enough to know how a pattern is implemented; we also need to know the reason behind the existence of the pattern.

In other words: we need to know what the pattern is made for.

We need to perfectly understand the kind of problem that it solves. If we know this, it will be easier for us to know the proper time to apply a pattern.

On making these types of decisions, two books come to my mind:

• Head First Design Patterns: if you’ve never heard of design patterns before, or you’re just starting out, this book is a must. It explains the most frequently used design patterns in a very friendly and easy way.
• Design Patterns: Elements of Reusable Object-Oriented Software: this is a classic and a must-read as well. It’s written as a catalog of the most common design patterns, which are organized into three main categories: creational, structural, and behavioral.

Unfortunately, there’s yet another problem we must face: recognizing and applying patterns in the wild.

When you’re writing new code from scratch, it’s fairly easy to recognize the need for a pattern as you go along. However, taking old code and making it use a design pattern is more challenging.

You need to be sure that you fully understand what the code does before touching it. Figuring this out can be the easiest or the most painful experience, depending on how convoluted the code is.

Luckily for us, there’s another book that can help with this problem: Refactoring to Patterns. This book tells you how to actually take existing code and integrate design patterns into it.

These books, along with many other ones, are featured in John’s ultimate list of programming books, which I highly recommend.

Conclusion

Design patterns are not the holy grail of programming. In fact, I don’t think such a thing exists.

They are simply a mechanism that can make our code much cleaner and easier to understand and maintain… when applied correctly.

So, when do you think it’s appropriate to use a design pattern, and when it’s not? Tell us in the comments below.

Do check out our Simple Programmer course — How to Market Yourself as a Software Developer for tips and tricks on progressing your career.

The post Don’t Get Obsessed With Design Patterns appeared first on Simple Programmer.

Transpilation vs. Compilation

\n\nA programming language is really just a human-friendly syntax. We already have programs that interpret or compile that syntax into something a computer can run. Instead of compiling our program into machine code, we could compile it into another programming language.\n\nThis process is known as transpilation because it’s converting one programming language to another. It lets programmers write code in their favorite language, then rely on the transpiler to turn it into JavaScript, which the browser can execute on the web page.\n\nThis isn’t a particularly new idea, and there are several programming languages that transpile into JavaScript; two notable ones being ClojureScript (Clojure to JavaScript) and Google Web Toolkit (Java to JavaScript).\n\n

JavaScript is Too Dynamic

\n\nWhen you create a class in JavaScript, you can give it fields and methods just like other object-oriented programming languages. Normally, an interpreter could read a class definition and allocate some storage for the fields based on what type they are, and therefore predict how much space is needed.\n\nBy predicting how much space is needed and laying out objects in memory efficiently, the interpreter or compiler can optimize the code execution. This works well in programming languages like C, or Java, because you can’t change what fields a class has, or their types after you define it.\n\nNot so with JavaScript!\n\nBecause JavaScript is a very dynamic language, you can add/remove and modify variables at run-time, even changing a field from a Number to a String halfway through.\n\nFor instance, in the below code, you can see that we can modify fields on class instances and even completely change the methods even after the objects are created!\n\n\n\nMost browsers these days will attempt to optimize JavaScript code by assuming that classes won’t change, but if that assumption is broken, they have to fall back to much slower, but more general algorithms for executing the code. They can never rule out the possibility that the user will invoke obscure and complicated features of the language at any point, which causes additional interpreter complexity and slowdowns in speed.\n\nIf JavaScript was less dynamic, it would be easier to optimize and less complicated to make other programming languages transpile into it.\n\nIn fact, because of this, attempts have been made to define a subset of the JavaScript language so browsers could pretend certain invariants are upheld (like not changing a class dynamically, and not making a variable change types).\n\nThis language is known as asm.js.\n\n

Asm.js is a More Optimized Subset of JavaScript

\n\n\n\nAsm.js is a restrictive subset of the JavaScript programming language meant to be compiled to.\n\nIt doesn’t have any of the frills of JavaScript, but because it is a subset of the language, it can still be run by regular JavaScript browsers. The functionality it supports is a lot more like C code, and you specify the types of your arguments in certain ways.\n\nFor instance, in JavaScript, a number is always a double-precision floating point value, which is really inefficient if you want integers. In asm.js, you can signal to the interpreter that you want an integer by writing x = x|0;. This is still valid JavaScript code (doing a bitwise OR on any number with zero just returns the same number), but it lets asm know it can use fast integer math.\n\nHere’s an example of what asm.js code looks like if it was written by hand (it looks much crazier when machine generated).\n\n\n\nSince it’s still valid JavaScript, regular browsers can run it with identical behavior to the compiled version. Browsers that support asm.js can make extra optimizations and run much faster (like Firefox).\n\nThe downside is that it’s really a hack on top of JavaScript. It’s a text-based format, so it takes a long time to parse, and there are many syntactic contortions necessary to make it compatible with JavaScript—so it’s hard to reach native (i.e. C-like) speeds.\n\nEnter WebAssembly.\n\n

WebAssembly is a Compile Target for the Web

\n\n\n\nWebAssembly is a low-level language format explicitly designed to be compiled to by other programming languages. We’ve been talking about transpilation this whole time, but since WebAssembly is sufficiently low-level compared to JavaScript, we could really call it compilation.\n\nAnd the best part—it’s not being designed in 10 days!\n\nIt is based on asm.js, but the spec is being built from the ground-up to be an efficient and general-purpose compile target. It is not a subset of JavaScript, so it doesn’t need to make contortions to support being run by old engines.\n\nHere’s an example of some WebAssembly code in textual format. The main format is binary, but it can be freely converted to a text format more suitable for reading by humans. This is just one potential text syntax, as the official format hasn’t yet been decided.\n\n\n\n

It’s Fast

\n\nWebAssembly is a binary format.That means it’s much more compact than JavaScript or asm.js, making it faster to download. It’s also built to be extremely fast to parse (in fact, in some early benchmarks, it’s 20x faster than regular JavaScript!). This is especially awesome for mobile devices, which are battery and CPU constrained.\n\nBecause it doesn’t have to be a subset of JavaScript, it doesn’t have garbage collection. This means code written in C and C++ that manage memory manually can run directly in native speeds without any built-in GC trying to get in the way, and other programming languages are free to implement their own custom garbage collector. (Note that an optional built-in garbage collector is also planned at some point.)\n\nIt will also support hardware-accelerated features of modern processors like Single Instruction, Multiple Data (SIMD). This would let you write code that could potentially do a calculation on multiple variables at the same time, really speeding up certain applications like live video processing or games.\n\nLast, but not least, it will even eventually support multithreading, which is something that is simply not possible in JavaScript.\n\n

It’s Safe

\n\nSince it is built for the web, it will be safe to run in browsers from day one. What does “safe to run in browsers” mean?\n\nFor one, it’s memory safe, which means you can’t crash your computer just by going to some website with an allocation bug.\n\nSecondly, code will have to abide by the existing browser-based security restrictions like the same-origin policy to prevent malicious sites from stealing user’s data without their permission.\n\n

It’s Portable

\n\nLastly, WebAssembly will be portable, so there are no platform specific aspects of the format. This means it can run on many different devices including regular web browsers, mobile, or even Internet of Things (IoT) devices. Technically it doesn’t even have to run in the context of a webpage!\n\nAnd just because WebAssembly won’t have platform specific aspects, a given host may decide to provide additional APIs on top of what’s available normally. For instance, if Android had a native host for WebAssembly, it could provide an API to access native Android features that aren’t normally available to websites.\n\n

This is Great for Other Programming Languages

\n\nWhat does all this mean for you?\n\nIt means we’ll have a solid platform for optimizing lower level code, and a great vector for implementing programming languages that run in a cross-platform way. Among other things, it makes other programming languages first-class citizens of the web.\n\nBecause there isn’t a built-in GC, and the overhead will be minimal, any language under the sun can be compiled. We can think of the web as a new operating system, capable of running on any device imaginable—and now we don’t have the limitations of JavaScript to worry about!\n\nThere are already communities forming around languages like ClojureScript, but I can see higher-performance languages really starting to become mainstream.\n\n

Will we Kill JavaScript?

\n\nSo the big question is, since JavaScript was created in 10 days and has lots of haters, does this mean everyone will jump ship once other languages are available?\n\nJavaScript has a lot of momentum behind it, so it’s not going anywhere. It will likely continue being the dominant language on the web, for many years to come.\n\nDespite how much people like to bash it (myself included), there have been many improvements in the last couple years, thanks to EcmaScript 6. It will always be a great language when you want high flexibility and fast prototyping, or the most choices for frontend work.\n\nHowever, if you want to build something like a video encoder, security encryption software, or need to carefully manage memory, now you can use a low-level language suited to the task.\n\nOr if you really care about catching bugs at compile time, you could use something that is statically typed with a fancy type system like Haskell. You could even theoretically mix them in a single app.\n\n

It’s Still Early Days

\n\nSo where is WebAssembly now?\n\nIt was first announced in June 2015, and as of writing this post (May 2016), it’s still being designed. However, they have been hard at work, and already there’s a spec and reference interpreter, a draft of the binary format, and even a playable 3D game by Unity called “angry bots” compiled from C++. Everything is open source, so you can check out their implementations and designs in the github repos.\n\nWe should all feel excited to be living in a time with this kind of innovation and potential. The web has already proven to be the most useful and accessible platform ever, and WebAssembly will take everything to the next level.\n\nI’m extremely excited for what the future brings. Long live the web!

The post WebAssembly: Finally Freed from JavaScript? appeared first on Simple Programmer.

Pre-requisites

\n\n

\n\nI am making the assumption that you have or know the following:\n\n

\n
1. \nSome flavor of Visual Studio installed\n\n-Although I will teach using C#, most of the concepts and ideas here can be applied to other bindings like Java, Ruby, and so on.\n

\n

2. General knowledge of C#

\n

3. Basic understanding of Selenium Webdriver

\n

4. Understanding of element locators using HTML

\n

\n\n

What Application Will we Test?

\n\n

\n\nThis is the AUT that we will be working with today. A Selenium guru by the name of Dave Haeffner uses this application to teach Selenium Webdriver. The goal of the test is really simple:\n\n

\n
1. Navigate to the page

\n

2. Click button with id = “start”

\n

3. Make sure that element with id = “finish” is present on the page

\n

\n\n

Improper Synchronization Example

\n\n

\n\nI wrote a quick test to give you an example of what can happen when your synchronization strategy isn’t up to par. Take a look at this code:\nIf you try to run the test in your Visual Studio, you will probably receive a similar message like in the image below.\n\n\n\nSo why did this test fail? Take a moment to think about it and walk through the application or step through the code.\n\nThe automated check failed because of improper synchronization. After pressing the “start button”, there is a loading screen that we must wait for 5 seconds. However, in our automated check, we don’t have such a synchronization point. Therefore, when our test executes the line of code below, the Webdriver API comes back within 500ms and says that this element is not visible. Of course, it’s not visible, there is a stupid loading icon that we didn’t account for:\n\nTo resolve synchronization problems, I will teach you 3 types of techniques to apply to your tests.\n\n

What is an IMPLICIT Wait in Selenium Webdriver?

\n\n

\n\nAn implicit wait in Selenium came from Watir’s implicit wait idea. Here we are telling the Webdriver to poll the DOM for a specific amount of time when trying to find an element or elements. The default setting is 0 seconds. Once set, the timeout is set for the life of the driver, until it is changed again.\n\n(Selenium HQ)\n\n

How do you use an Implicit Wait?

\n\nOnce you create a type of driver, you will have access to the ImplicitlyWait() method. This method takes a TimeSpan object which you can use to specify the maximum of time that you want the driver to wait before throwing a NoSuchElementException.\n\n

What are the Advantages and Disadvantages of Implicit Waits?

\n\nAdvantages\n\n

\n
• It’s really easy and quick to create these type of synchronizations

\n

\n\nDisadvantages\n\n

\n
• The timeout lasts for the life of the driver. There are instances where you want your automated checks to fail right away when they cannot find an element. Therefore, you will need to reset the wait during that time and remember to set it back to the original value after you are done because the rest of the tests will now use the new value

\n

• Tests can be flakier or run longer as a result

\n

\n\n

What Exception is Thrown by an Implicit Wait?

\n\nOpenQA.Selenium.NoSuchElementException\n\n

What is an EXPLICIT Wait in Selenium Webdriver?

\n\n

\n\nAn explicit wait is code you define to wait for a certain condition to occur before proceeding further in the code. The worst case of this is Thread.Sleep(), which sets the condition to an exact time period to wait. There are some convenience methods provided that help you write code that will wait only as long as required. WebDriverWait in combination with ExpectedCondition is one way this can be accomplished. (Selenium HQ)\n\n

How do you use an Explicit Wait?

\n\nExpectedConditions\n\nThese are a set of common conditions that can be used with the WebDriverWait class to check on the state of an object.\n\nSome of the most common ones include:\n\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n\nA full list of all the ExpectedConditions can be found here.\n\n

What are the Advantages and Disadvantages of Explicit Waits?

\n\nAdvantages\n\n

\n
• The explicit wait is dynamic and great for locating elements in between transition points. It will wait the maximum amount of time specified, but only if necessary

\n

• Selenium Webdriver provides built in ExpectedConditions class out of the box so that we can check our web applications for different conditions with 1 or 2 lines of code

\n

\n\nDisadvantages\n\n

\n
• A larger barrier to entry exists as compared to implicit waits because we need to learn all the different ways that we can apply an explicit wait

\n

• If using Thread.Sleep(), this can make our functional tests really brittle and slow

\n

\n\n

What Exception is Thrown by an Explicit Wait?

\n\nOpenQA.Selenium.NoSuchElementException\n\n

Don’t mix Your Implicit and Explicit Waits

\n\n

\n\nA word of caution is to make sure that you do not mix implicit and explicit waits. The main problem is that implicit waits may be baked into the different components that are utilized by Selenium Webdriver, all the executables like ChromeDriver.exe, IEDriverServer.exe and so on. Therefore, when you are making multiple hops between the different implicit waits, you can stray into “undefined behavior” (Jim Evans).\n\nI strongly recommend that you just use the Explicit Waits.\n\nThis post does a good job of conveying the undefined behavior when mixing waits.\n\n

DefaultWait

\n\n

\n\nA Default Wait, also known as a Fluent Wait in Java is a type of wait that utilizes the DefaultWait class of the C# Webdriver bindings to set the synchronization timeouts. In Java, the WebDriverWait class inherits from the FluentWait class. However, in C#, the WebDriverWait class inherits from the DefaultWait class. Hence, the difference in nomenclature. Remember, the WebDriverWait class is the one that we use to construct our sexy explicit waits. Take a look at this snippet:\n\n

How do you use a DefaultWait?

\n\nThe DefaultWait class exposes all of the functionality to us to construct really controlled synchronization points. For example, we can set the polling interval, the exceptions to ignore, and even write our own custom message.\n\n

What are the Advantages and Disadvantages of DefaultWaits?

\n\nAdvantages\n\n

\n
• Provides us a really fine tuned way of controlling everything about a Selenium Webdriver wait

\n

\n\nDisadvantages\n\n

\n
• You need to define your own Expected Conditions to be able to use these functions

\n

• Too much code required to create a simple synchronization point

\n

• Most of the functionality is already exposed through the 2 constructors that the WebDriverWait has

\n

\n\nConclusions\n\nI created the table below to help you easily understand the difference between the three synchronization techniques that you can use to improve your test.\n\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n

\n\nThe Selenium community recommends that you use Explicit Waits above all others because they provide the most benefit to your tests. However, using something like Thread.Sleep() is almost never acceptable. In my career, I have had only a handful of instances where I hardcoded my wait time. Rather, you should utilize WebDriverWait and ExpectedConditions for your explicit waits.\n\nThe DefaultWaits are nice to know, just to keep it in your back pocket. However, I have never had the need to use them. In fact, the most time that I spent with them was for this tutorial. In my opinion, the WebDriverWait class does an excellent job of exposing all of the relevant functionality to me without having to move up to the DefaultWait class. However, this does not mean that it won’t work for you.\n\nMaybe you will find some awesome use for this class. If you do, let me know, I would love to learn how you use this class.\n\nFinally, don’t forget that the entire goal of this tutorial is to make your automated checks more stable to deliver higher value to your employer. So, go and make your checks better. Until next time automation enthusiasts!\n\nAs you continue to learn more skills and concepts, do take a look at our Simple Programmer course: 10 Steps to Learn Anything Quickly.\n\n

Extra Resources

\n\n

\n\n

\n
• Selenium Webdriver synchronization video tutorials

\n

• Selenium Webdriver Timeouts

\n

• Selenium Webdriver WebdriverWait class in C#

\n

• Selenium Webdriver WebdriverWait class in Java

\n

• Selenium Webdriver Explicit and Implicit waits

\n

• Selenium Frameworks by John Sonmez

\n

The post Selenium Tutorial appeared first on Simple Programmer.

There is one major problem that I have been running into though.  Switch statements and dictionaries are not functionally equivalent for one major reason…

Switches allow for default

I kept struggling with this when I would implement a dictionary to replace a switch.  How can I deal with the default case?

There are of course many ways to deal with the default case in a dictionary or map, but I didn’t really like any of the solutions because they either required me to remember to check to see if my entry was in the dictionary before looking it up, or to rely on catching an exception.

Let me give you an example:

Converting this to a dictionary we get something like:

So clunky, just to handle the default case.

Would be much better do something like this:

Well now you can!

Enter DefaultableDictionary!

Also the first thing I ever put on GitHub!

The idea is pretty simple, I am just creating a decorator for IDictionary.

The DefaultableDictionary has a constructor that takes an IDictionary and a default value.

It then delegates all of the methods to the passed in IDictionary reference.  For the methods that look up a value, it handles returning the default if the key doesn’t exist in the dictionary.

I created an extension method that lets you just put a .WithDefaultValue() on the end of your dictionary declaration in order to auto-magically give you a DefaultableDictionary back with that default value.

Sleep well my friend

Knowing that you can not create a dictionary that has a default value which is returned instead of throwing an exception if the key passed in is not found.

I have no doubt that in 3rd world countries children are still starving, but in 1st world countries children with VS Express hacking away at iPhone applications using MonoTouch will not have to catch exceptions from dictionaries that do not know how to just return a default value.

So now there is no excuse!  Refactor those switches!

The post Making Switch Refactorings Better – Defaultable Dictionary appeared first on Simple Programmer.