Hello Everyone! Hope all of you are doing well and Goodluck with your finals as we are in the last week of the semester. Today in this blog I want to talk about technical debt, it may sound like a financial term, but in the case of software development, technical debt is the idea that certain necessary work gets during the development of a software project in order to hit a deliverable or deadline. Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code. It is basically the extra coding work that a software development company has to do because they took a shortcut route to finish and deliver the product in time without making sure if it works properly or not.

Is technical debt bad? The simple answer is it’s neither good nor bad, it’s debt. Several software companies today are under pressure from the market and competitive forces to develop and ship fast. Startups especially feel this “ship or sink” pressure. This need for speed leads many product and software development teams to make the tradeoff between taking on technical debt or launching later. There is sometimes unintentional technical debt with various software development teams such as the team who follows Poor practices, this leads the works done during the project to be messy which then makes the teamwork on it later which lead to technical debt, Software development teams being Inexperience with new coding techniques leads to the delay of the coding process or in some cases making the code messy which than later lead to technical debt. For example, a design approach that ends up containing many errors is unintentional technical debt. This sometimes occurs as the direct result of poor communication with the organization or misalignment between the developers and operations teams.

I choose this article because this article gives a very easy definition of technical debt and it also contains a video that explains technical debt in detail, this article also talks about what are the good reasons for technical debt and the bad reason for technical debt which makes the concept clearer. And having a major in Software development, it is important to know about the concept of technical debt as it will help in the future as a software developer.

Article: https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/#

From the blog CS@Worcester – Mausam Mishra's Blog by mousammishra21 and used with permission of the author. All other rights reserved by the author.

Hello everyone, hope you are all doing well. As this is the final week, I would like to wish you all Goodluck with your finals. In this week’s blog, I would like to talk about Refactoring as it is one of the important parts of programming. Refactoring is a process of restructuring code while making sure it does not change the original functionality of the code. The main goal of refactoring is to improve internal code by making small changes without altering the code’s external behavior.

Computer programmers and software developers refactor codes to improve the design, structure, and implementation of software. Refactoring improves code readability and reduces complexities. It also helps software developers find bugs or vulnerabilities hidden in their software. Refactoring improves codes by making them more efficient by addressing dependencies and complexities, becomes more maintainable and reusable by increasing efficiency, makes the code cleaner which then makes the whole code easier to read and understand, these are a few purposes of refactoring.

Refactoring can be performed after a product has been released, this should be done before adding updates and new features to the existing code or it should be done as a part of day-to-day programming. There are several benefits of refactoring like it makes the code easier to read, encourages a more in-depth understanding of code, improves maintainability. It also comes with various challenges like this process will take extra time if the development team is in the rush to finish the product and refactoring is not planned for, without clear objectives refactoring can lead to delays and extra work, Refactoring cannot address software flaws by itself, as it is made to clean code and make it less complex. There is various technique to refactor the code some of the examples include moving features between objects, Extracting, refactoring by abstraction, and composing. The best practices to follow for refactoring include Planning for refactoring when a project starts, Developers should refactor first before adding updates, refactor in small steps, Test often while refactoring, fix software defects separately, Understand the code before refactoring, focus on code deduplication, use of Automation tools make refactoring easier and faster.

I choose this article because it has a clear definition of refactoring and purpose of refactoring, benefits of it, explains different techniques to perform code refactoring, and gives best practices to follow for refactoring and since it is very helpful for software engineers, in the future these practices will help me do my job easier and help me do my job in an effective way.

Article: https://searchapparchitecture.techtarget.com/definition/refactoring

From the blog CS@Worcester – Mausam Mishra's Blog by mousammishra21 and used with permission of the author. All other rights reserved by the author.

Hello everyone! Hope everyone is doing great! In This week’s blog post I want to write about the front end and the back end and what are the differences between them. Front end and back end are the two most popular terms used in web development and they are very crucial for web development and are quite different from each other. Web development is the process of building websites and applications, Unlike UI UX Design, web development focuses more on coding and making sure the website functions well. Both the front end and bank end need to communicate with each other for the website to operate effectively and to improve the website’s functionality.

Front-end development is a style of computer programming that focuses on the coding and creation of elements and features of the website. This is the part of the website that the user interacts with and can be also referred to as the ‘client side’ of the application. This means as a front-end developer your job is to code and bring to life the visual elements of the website. It includes everything that users directly experience such as text colors and styles, images, graphs and tables, buttons, colors, navigation menu, animations, and content organization. The languages used in Front end development are HTML, CSS, and JavaScript. Responsiveness and performance are two main objectives of the Front end. The developer must make sure the site is responsive.

The back-end is also referred to as the “server-side” of the website and focuses on the side of the website user can’t see. It stores and arranges data, and makes sure everything on the client-side of the website works fine. As an example, let’s say you are using a social media website, you need an accessible place to store all the user’s information, this storage is called database systems such as Oracle, SQL Server, and MySQL, these are not seen by users and done at the back end of the website. Back-end uses languages such as PHP, C++, JAVA, Python, JavaScript, and Node.js.

The difference between the frontend and back end is that they work on different sides of a website which is the client-side and server-side, both have different strengths, both work in different languages. I used this article because it makes the front end and back end very easy to understand and In the future if I work as a web developer it’s very important to know about these concepts.

https://www.kenzie.academy/blog/front-end-vs-back-end-whats-the-difference/

From the blog CS@Worcester – Mausam Mishra's Blog by mousammishra21 and used with permission of the author. All other rights reserved by the author.

For this week’s blog, I was looking more into API since we covered this in the class to know more about it. Application programming interfaces (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software. API enables companies to open their applications data and functionality to external third-party developers, business partners, and internal departments within their companies. This allows service and application to communicate with each other and leverage each other’s data and functionality through a documented interface, developers do not need to know about how the API is made because they will simply use the interface to communicate with an application and web services.

How an API works: API stays between an application and web server, acting as an intermediary layer that processes data transfer between systems.  APIs are sometimes thought of as contracts, with documentation that represents an agreement between two parties, if one party sends a remote request structured a particular way, this is how party two’s software will respond.  For example, imagine a medical equipment distribution company. The distribution company could give its customers a could app that lets the hospital’s employee check a certain equipment availability with the distributor. The app could be expensive to build, limited by platform, and require long development times and ongoing maintenance. This has several benefits like it lets the customer access data via an API which helps to check information about their inventory in a single place saving time, The distributor can make changes to its internal systems without impacting customers, with a publicly available API it could result in higher sales for the business.

In short, APIs lets you open up access to your resources while maintaining security and control. How you open access and to who is up to you. There are four main types of API those are Open API, Partner API, Internal API, and Composite API. Open APIs are open-source application programming interfaces you can access with HTTP protocol. Partner API are application programming interfaces exposed to or by strategic business partners. Internal APIs are application programming interfaces that remind hidden from external users. Composite API combine data or service APIs. I used this article because it explains API in an easy way, explains about it giving an example which then makes it’s more clear. And in today’s world innovation is very important as technology is increasing day by day so knowing about API is helpful in the future as it helps in fast innovation.

From the blog CS@Worcester – Mausam Mishra's Blog by mousammishra21 and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome to my blog! This week I decided to write a blog on design smells. In programming, we write a lot of code and even a small mistake in the code tends to break the whole program which brings down the efficiency of the code. Design smells refer to the mistakes in the code that had to do with the way the programmer wrote the code which then tends to make a lot of problems due to the design on how the code is written. Design smells are structures in the design that indicate a violation of fundamental design principles and negatively impact design quality. If a programmer focuses less on code design, later the program tends to break easily even if a small feature needs to be added to it. In the article, Mr. Fowler says code smell is a surface indication that usually corresponds to a deeper problem in the system. Design smells are easy to spot if we know about them and what they are, hence, some of the common design smells are:

Rigidity: The program breaks if a single change is made in the code, hence had to go back, and make several changes to make the code work.

• Immobility: the parts of the code if can be used in other system can’t be moved because of the high risk of breaking the original code.

• Fragility: changes in the code that could make error in the different unrelated parts to the program, hence making it difficult to even change small section of the code.

• Viscosity: Making the changes in the program in a right way is harder hence, code is easy to be broken.

• Needless Complexity: having the code that is not useful and make the code hard to understand.

• Needless Repetition: Various Repetition of functions in the code can be removed by refactoring the program.

• Opacity: The functionality of a system or feature is unclear, or the code is unclear and very difficult to understand.

I choose this article because as a programmer above things are something we don’t want in our code, by learning about design smells one can know where to find it in the code and once you find it following the best practices such as refactoring can help solve design smells. As a programmer in the future knowing about these design smells helps me later in my everyday task in my job.

Links used:

https://martinfowler.com/bliki/CodeSmell.html

From the blog CS@Worcester – Mausam Mishra's Blog by mousammishra21 and used with permission of the author. All other rights reserved by the author.

This week I researched more about docker to know what it exactly is and what are the applications of it. I had never heard or used docker before I joined this class and since we use docker for almost every class I was just curious to learn more about it and from the things learned during the class, it looks like docker is one of the useful software and very versatile in the field of software development.

Docker is a set of platforms as a service product that uses OS-level virtualization that delivers different software in packages and they are called containers or Docker can also be referred to as an open-source platform for building, deploying, and managing containerized applications. Since docker is open-source, it enables developers to package their application into containers, these containers simplify the delivery of distributed applications and has become popular as different organizations shift to could-native development and hybrid multi-cloud environments. A docker file contains simple textile that starts with every docker container and contains instructions for how to build a Docker container image, that file automates the process of Docker image creation. Docker image contains executable application source code as well as all the necessary libraries, tools the application code needs to run the container properly. Docker images are made up of layers, and each of those layers corresponds to the version of the image. Docker containers are the live, runner instances of the Docker images and this helps users to interact with them, thus one can adjust their setting according to their preferences. Docker hub is a public repository where Docker images are stored and can be used by all Docker Hub users. The advantages of using Docker are they are cost-effective with fast Deployment, Able to run anywhere, Flexibility, and so on, the disadvantages are its advances quickly thus but lack documentation that makes some developers hunt for information which then wastes time for those developers, some developers find switching to docker is a quite a steep learning curve thus making it hard to understand for some people.

I choose this article because it explains Docker and its tools in the simplest way which helped me understand more about docker since it’s the first time I have ever used this application. It explains the advantages of using docker and this article provided clear information on different aspects of docker such as Docker File, Docker images, Docker containers. And since its one of the most used application throughout the software developers it will be important for me too in the future as a software developer.

Article: https://www.ibm.com/cloud/learn/docker

From the blog CS@Worcester – Mausam Mishra's Blog by mousammishra21 and used with permission of the author. All other rights reserved by the author.