Apprenticeship Pattern Blog 7

 This blog is an extension of chapter 6 of the apprenticeship patterns which talks about creating your own curriculum. The message is that the software apprentice should come up with a plan on how they want to progressively learn and continue with their journey and profession. This is information I sincerely wish I had learnt earlier as I started programming. Over the years, I’ve used different frameworks to solve problems without really going deep into the specifics of those platforms. I just wanted to meet the software requirements of the particular project and move on to something else. Over the years, I have discovered knowledge gaps especially when I participate in projects that I did not build from group up. I've found myself in a situation where I can not confidently state what languages and frameworks I’m truly good at. However, after reading this chapter, I plan on making a “curriculum” of technology stacks I want to learn and master.
 
The writers are very considerate to mention that the number of books we need to read are increasing faster than we can read them. This is so true, and I would also add that the technologies being used are changing by the second as well and we need to stay relevant in this field. They also mention that some knowledge can only be found in physical paper version rather than the world wide web. Paper books require a certain amount of attention if someone is really serious about attaining the knowledge in them. I remember reading my first book on C programming by Paul and Harvey Deitel. I learnt a lot from it because I was excited fully immersed into acquiring the knowledge that was within. After this experience, I moved on to watching YouTube tutorials to enhance my knowledge and actually learnt a lot about other technologies.
 
Software craftsmanship is a journey of continuous learning but also rewarding to when you see the system performing as it was intended in the requirements. The book advises that we should pick books that give a broader understanding of the topic in question and then selecting books that drill down into the specific aspects of our interest. There exists plenty of free sources for some books and videos and it’s within our best interest to put these to use. This is my journey to take and I'm happy to be on it.

Sprint 3 Retrospective

 Sprint 3 was a much better experience compared to the previous two sprints. We had clear focus on what issues and epics needed to be completed to meet our goals. After completing my task of restructuring folders, it was time to move on to other things. I got a chance to learn about testing in chai. Chai is a node js library that can be used with other platforms such as Rails to perform software testing. It’s lightweight and easy to play and experiment with.

 

We were determined to put in all our efforts to achieve the tasks that were ahead of us, and I was given the task of creating a test runner for docker image. I wasn’t quite sure on how to approach this, but I asked for help from the other team that had done something that closely looked like what I would work on. Docker is an open platform for developing, shipping and running applications in a containerized environment. This means that even with different endpoint being used to develop software, they’ll all use the same specifications and environments. This helps to resolve issues whereby dependencies arising from being on a different operating system might cause incompatibilities leading to development delays and other undesirable situations. With docker, all developers use the same version numbers of required dependencies and environment.

 

The test runner runs tests on each commit that’s pushed to the branch via docker before it’s reviewed and merged to the main branch. This test phase helps to catch potential bugs and also ensure that the software meets the standards that have been set. Below is the link to the merged request of the test runner for docker images:

·      https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/merge_requests/19

The next task I had to work on was integrating the test with the pipeline. The pipeline was a major obstacle at first because it wasn’t working so all our tests failed miserably. We later discovered that our own server in the Reporting System was crushing on startup. The database kept running but the server was down. With this in the way, we couldn’t really get far, until one of our teammates got to fix the issue. Also, with the help of the Professor, we found out that our openapi.yaml file was in JSON format instead of YAML format. How did we get here? We were baffled by this but were able to get it under control. The link below is to the merged request of integrating the test to the pipeline:

·      https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/merge_requests/20

Such seeming minor details caused significant delays on how much we could accomplish as we couldn’t tell the reason why the system was behaving the way it did. We have learned to work closely as a group but also open to ask for help from other groups and the professor. Without their input we probably could have given up after a certain time. I congratulate my teammates for such great collaboration. 

 

Apprenticeship Patterns Blog 6

 Chapter 6 of the Apprenticeship Patterns titled Construct Your curriculum was very insightful to me. It teaches ways on how to keep track of the progress that an aspiring software craftsman is making over a period of time. I believe that perhaps if I had received the knowledge shared in this chapter, I would have been better organized and learned much more than I currently do. The chapter starts off by recognizing that one can learn everything at once but instead by making smaller progressive accomplishments to achieve a huge task.
 
The first concept shared was creating a reading list. This helps the apprentice to keep track of the books they’ve read, currently are reading and what they plan on reading next. Personally, I’ve read several programming books but never really thought about keeping track of them, however, I plan on maintaining a reading list so I can plan systematically and be able to test myself on the knowledge I acquire in the material read.
 
The author also encourages that we read constantly and focusing our thirst for learning on consuming as much of the written word as possible. Blogs, podcasts, audio books are also good, but emphasis is highly placed on the physical books. I believe having a book in your hand reduces the chances of distraction compared to the other forms especially audiobooks where the listener is tempted to multi-task on activities. This eventually reduces productivity and retention of the information being shared. This concept coupled with creating a reading list look like a great way for me to go.
 
Moving on to digging deeper, I agree with the author that we live in a world of tight deadlines and complex software projects that use a multitude of tools and we find ourselves not having enough time to learn enough a given platform that we are working with. Instead, we resort to selecting a handful of tutorials and libraries to come up with a solution. This works most of the times, but we’re actually limited when other issues arouse from the said solution we created. An example I interfaced was when I worked on a project where we had to access data using an id of the object in the database. The id would be passed into the URL of the http request in plain text which was a security vulnerability for the database. We were successful in accessing the data but exposing the id of the data object was not a prudent idea at all. This amount of technical debt is dangerous but happens too often as project managers want to quickly ship products to the client. The major problem, however, is the difficulty that comes with maintaining such code as it may turn out that corners were cut and simplified complex issues, the author noted. I agree with this, and that things could also turn out worse in case of clients’ data being leaked resulting into unfavorable situations such as lawsuits.

Spring 2 Retrospective

After completing Sprint 1, receiving feedback from my colleagues and learning more about the system, and git I felt more confident with my contributions to the overall project. In line with what I did during the previous sprint which was restructuring the backend folder, this time around I would restructure the API folder. Below is the link to the restructuring issue. You’ll realize that we used the same issue for backend as well. That wasn’t intentional but we stuck with it.
·      https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/97
 
Restructuring is quite a sensitive job and requires special attention in my opinion since the changes submitted would literally affect everyone’s work. I’ll give an example that we went through as a team. During my work, I made a poor judgement about a file named package.json and deleted it. This file contained specifications of some of the development and release dependencies. At the moment, I thought this wasn’t a much-needed file hence the reason I removed it.
 
After several other modifications, moving of files and folders I created a merge request for my branch. This merge request did not pass the pipeline. I shared this with my colleagues, and we mostly thought it was because the pipeline hadn’t been customized to correctly analyze our work. Later on, my work would be merged despite the pipeline failure. This was a terrible mistake and I’ll explain how we got it fixed. We collectively decided to revert this merge and take a closer look into the issue. This was the first step into the right direction. The reason why I had pushed for this request to be merged was because I thought it would be great for everyone to work with an updated file structure.
 
We started taking pipeline failures seriously, and later one, a teammate would figure out how to fix the pipeline and everything worked better from then going forward. This was a great breakthrough even though my commits were failing, it was nice to know that other’s had theirs passed.
 
With further investigation and reading through the logs produced by the pipeline, I noticed that I had skipped a statement that said, “…couldn’t find package.json file…” It was at this moment that I realized that deleting the stated file was a bad idea and now had to reinstate it. All teammates who had pulled in the latest changes except one, had already lost this file because my previous merge had deleted it. It was from him that I got the package.json file again and reinstated it. The pipeline stopped failing and started passing with all my commits that followed. We were in a better position than before where it was completely failing. Below is the link to the merged request;
·      https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/merge_requests/15
 
Moving on, I plan on assisting my teammates who seem to be having a little struggle with their portion of the system. Specifically, I want to participate in the creation of tests using Chai Script. I believe it will be a great learning experience for me.
 
In conclusion, Sprint 2 has been a great experience for me especially by being caution when it comes to restructuring development files and folders.
 

Apprenticeship Pattern Blog 5

From chapter 5 of The Apprenticeship Patterns by Dave Hoover and Adewale Oshineye we see that most of the software craftsmanship patterns are inter-related. This chapter is titled ‘Perpetual Learning’ to mean that software developers must continuously work towards gaining and improving practical, crucial skills to build confidence, value and progress in the field. I agree with this approach, and I plan on investing time in the mastery of some of the programming languages we’ve been taught at school such as Java, JavaScript. It’s often said that a journey of a thousand starts with the first step. Therefore, daily practice for me is that first step in my software craftsmanship. The author beautifully lays it by saying, “…concrete skills, an apprentice must also learn how to learn, for the transition to journeyman will certainly not remove the need for learning…” I agree with this approach and as I've mentioned in other blogs, it is challenging sometimes but worth the pursuit.

 

We also see that identifying skills that are required in one’s craftsmanship facilitates setting up clear targets to be achieved. Technical skills can be hard at times to comprehend but with dedication anything can be achieved. For instance, since I’m interested in created in APIs, web systems and user facing applications, it’s relevant to learn Java, JavaScript and VueJS. Knowing that these are the requirements, I can efficiently dedicate my time towards platforms that achieve the set objectives. Practical learning solutions offered include signing up for Google Reader or another blog aggregator, following some software luminaries on twitter, subscription to moderately high-traffic online mailing lists, joining a newly formed local user group that is excited about new technologies. I personally, I'm a fan of the Software Engineering daily, however, adding Google Reader would also be a great addition.

 

We’ve seen in previous patterns that simply taking on simple tasks and fully mastering them before tacking complex projects continues to be very helpful. I'd say that documentation is always the first place to start when it comes to learning a new platform or technology. I intend to use this pattern to learn more about document-oriented databases such as MongoDB since they have faster transaction performance and data persistence. I know that with continuous practice comes resistance but it’s encouraged within the book to retreat into competence by taking a step back from overwhelming challenges and focusing skills in a specific area.

Sprint 1 Retrospective

Sprint 1 was huge learning opportunity for me especially as it incorporated the concept of a scrum master. Leading and working in a small team sounds like an easy task to do but that’s not always the case as we’ve explored throughout this semester. Each individual possessed different skills that we planned to exercise in making contributions to the project. Thea’s Food Pantry, an open source project runs on a micro-services architecture with several components. The three major components include; Reporting, Inventory and Guest Info System. Our group was assigned the Reporting System and I was assigned the task of mostly working on the backend portion.
 
Inside the backend service itself there were other pieces that had to be put in place such as development containers commonly referred to as devcontainers, updating from vanilla JavaScript to modern JavaScript connotations through the ‘use strict’ keyword and changing variable declarations from ‘var’ to ‘let’ or ‘const’ where applicable. Up to this point I had not encountered any significant obstacles as I’m about to elaborate. Below is the link to the issue that I worked on;

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/97 

 
We got introduced to the command ‘git squash’ which combines multiple commits into one. This was something new I had never encountered as a casual user of git. The general commands I had worked with previously included git add, git commit -m “Commit message”, git push, git status, git checkout, git reset –hard, git pull etc. Squash came in pretty handy when working on a branch and submitting multiple changes as one.
 
The next major thing I learned was working with the issues board and merge requests. In the beginning, theses were slightly hard to navigate as far as identifying what part of the code needed to be modified to satisfy and solve the issue at hand so it could be moved from in-process to needs review. Also, identifying what branch or version of the main source to work with was a major obstacle for me that I later learned to do correctly. We discovered that the proper way to contribute to the main project was by creating merge requests. Git merge requests automatically creates a branch that you can work on so you do not need to manually create one. This was valuable information we wish we had learned earlier. However, since this wasn’t the case, we had several manually created branches that ended up being a bit quirky to merge with the main project. Below is the link to the merged request I worked on;

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/merge_requests/16/diffs

 
Something I plan on being better at for this next sprint is to correctly examine and weigh issues and tasks that I assign myself. I had imagined that we would complete this project within three quarters of the semester and use the other quarter to make cosmetic changes to the software, but this hasn’t been the case. I also commit on closely working with my peers, by communicating effectively what and how I’m doing  as far as the project is concerned. My hope is that Sprint 2 will be much smoother and faster compared to Sprint 1.

Apprenticeship Pattern Blog 4

Chapter 4 of the apprenticeship mentions about developing new technical abilities, honing existing ones and building a strong foundation of technical knowledge. The authors mention that “The talented and hard-working apprenticeship must not become self-satisfied with his success”.  It is exciting to be proficient in a technology environment and build things while having fun with it, however, it’s more important that we do not become complacent in our abilities and stop learning about other frameworks. Versatility and flexibility are attitudes the craftsman should always possess. An example where I’m currently applying this is the containerization using Docker. For long I misinterpreted containerization to be the same as git version control but they’re actually different. In basic terms git is more about collaborating with others on a project while docker is more about applying the same development environment specifications across multiple end devices.

 

We also learn that the software craftsman should look out for opportunities to collaborate with exceptional developers in strong teams. Surrounding yourself with developers that are better than you helps identify areas you need to work on and introduces you to new ideas. I plan on attending coding hackathons in order to experience and see ideas other developers are working on.

 

The authors also mention about working on open-source software projects as a vital method for gaining technical knowledge. This also gives the opportunity to collaborate with seasoned engineers, learn about various technologies, and take part in a projects that will actually have an influence on the world. Newcomers start by contributing to simpler tasks as they learn and become more skilled, then slowly graduate to larger, more complex tasks. In Thea’s Food Pantry project, we’re continuing where other students left off. This is giving me an opinion of how future open-source projects could look like. We don’t have to start from scratch as the building blocks have already been put in place.

 

We also learn that humility and exposing our ignorance are great foundations of being a successful craftsman who's open and honest about what we don't know so we can learn from others.

 

To summarize the chapter, it goes like this: it’s important to continually learn and improve to gain the skills expected out of software craftsmen, to seek challenging projects, work on open-source projects and receive feedback and criticism from senior developers.

Apprenticeship Patterns Blog 3

Software development is a long-term pursuit that requires lifelong commitment towards learning and continuous improvements. This is what I learned from Chapter 3 from Dave’s story. His certificates were like medals that he had earned that showed his competence in the job he was doing. It’s interesting how after he collaborated face-to-face with exceptional software developers who were miles ahead of him and discovering that they kept on learning, he too started taking on side projects and reading anything he could get his hands on to be proficient in his crafts. I can relate this with the group that I'm currently working with, the scrum master is clearly ahead of us technically and I'm learning from him things that I didn't learn else where.

 

The chapter goes on to emphasize the importance of patience, persistence and having a long-term vision which I'll talk about later in this blog in the career of a software developer. Overtime software platforms and frameworks change, and this could lead to things breaking in several products. It’s therefore the developer’s responsibility to adapt to these changes and making the user’s experience seamless. An example I’ll give was the release of Angular 2, it was an overhaul of its predecessor Angular 1 which used vanilla JavaScript. Angular 2 on the other hand used TypeScript, a flavor of JavaScript with better performance, readability and easier to learn. I immediately decided to jump on the train and teach myself Angular 2 after hearing a youtuber say it did not make sense to learn Angular 1 since it wasn't going to be useful in the future. Easier to learn does not mean overnight or over a week but rather fewer weeks or months to come up with a relatively medium level application. If we couple this with the ten thousand hours rule which is close to three years taken learn to master a skill, we can agree that it’s traits such as passion that would maintain one’s desire to perfect their craft.

 

Moving on the idea of developers having long-term vision, it also helps developers in making short-term decisions. My interpretation is if you aim to be a Senior C++ developer for example, starting with learning to master how arrays and pointers work would be a great starting point for you. As we all know the wise saying, journey of a thousand miles starts with the first step, so this is that step. Day after day, a new framework is created for instance in the JavaScript world, having a long-term goal of what the craftsman wants to master, it’s easier to stick to a path that leads there with the most reasonable amount of time whether it's back-end or front-end. 

 

Just like the previous chapter, we are reminded again of the importance of seeking mentors to collaborate, guide and give feedback to the software developer. I’ve tried this and it never fails, many times an experienced developer will point you to look in a direction you didn't know was possible in achieving a task and it ends up working in your best interest.

Apprenticeship Patterns Blog 2

Chapter two of the book talks about “Emptying the cup” and what that means in a programming context is our willingness and readiness to put aside our prior knowledge and take in the new that’s being taught or learned. I found the story of the young philosopher meeting with the master zen interesting and of great value. In summary, the young philosopher couldn’t keep his mouth shut to listen to what the master zen was sharing because he believed that he had already been taught those concepts and there was therefore no need for repetition. In my opinion, this is totally wrong that because it eliminates the fact that there could potentially be a newer or better way to achieve something and there always is. One company that has been doing this for quite some time is Apple Inc. Each year during their Word Wide Developer Conference they introduce new concepts and tools in their programming platforms such as Swift programming language that replaced Objective-C for developing iOS applications.

 

Moving on to your first language, the author advises that one picks a langue, become fluent in it and hone as much skills as possible. They recommend this choice be weighed correctly as it’s upon this foundation that one’s early carrier will be built on. Build a toy project in this language where you can experiment with ideas. There is however a caution to this, and I will quote from the book, “One danger of digging deep into your first language is getting stuck”. It is crucial to consistently improve our skills by taking on smaller projects from different platforms that we may not be familiar with. I agree with this since there are known problems with some programming languages such as memory management above a certain quantity or performance issues that need to be addressed. However, for the most part, there is also work-around these types of events. I hope to use this pattern to learn as much as I can in the languages that I'm currently experimenting with.

 

Object oriented programming concepts are pretty much the same regardless of the platforms and this facilitates the learning of other languages for example if you’re comfortable programming in java, it is relevant to apply those skills in C++. Software craftsmen need to be dynamic in exploring diverse approaches to come up with solution.

 

The authors recommend developers to collaborate on projects with more experienced developers while also receiving feedback from peers. As the saying goes, “birds of the same feather, flock together”, it is imperative that the apprentice spend time working on small projects with senior developers to build their skillsets before moving onto bigger projects. The authors caution on overly depending on experts and rightly so, as this may slow the learning process.

Apprenticeship Patterns Blog 1

The Apprenticeship Patterns by Dave Hoover and Adewale Oshineye is such an interesting book and hopefully a must read for aspiring software engineers, designers, developers or even hobbyists. From computing ethics, I learned that scientists are morally responsible for ensuring that the technology created or software released is aimed at improving the quality of life of humanity rather than destroying it. Creating high quality software not only benefits the current users and developers but also future developers who might need to replace, maintain and build more features. The book teaches the importance of having a growth mindset that comes from dedication and hard work.

 

From chapter one, Dave’s self-taught struggles stood out to me. He wanted to learn Perl at age 12 and later Java at 25 and almost gave up until when he was 26 and found mentors Edventions LLC in Skokie, Illinois at the height of the dotcom bubble. I can relate to this as I’ve taught myself some programming languages through youtube videos. Programming Channels such as FreeCodeCamp.org provide multi-hour video content free of charge and teach high quality materials. It's easy to give up especially when motivation starts to fade out. I've been in similar situations when I learning flask, a light-weight web application development environment using Python.

 

Moving on, I’ll quote from the book, “If you come to me with a cup that is already full, how can you expect me to give you something to drink?” this was the Zen master’s reply to the young philosopher who couldn’t shut up during their conversation. The authors teach that we must be open to learning new programming languages to which I agree and not simply sticking to those we already know or simply thinking in the patterns that we’re comfortable with. Though this is a somewhat painful experience, it’s fulfilling to reach that point where you build something that you can show off because of hard work. When I look at current job descriptions for example, I see most requiring Java or C++ programming skills which means I must be ready and willing to take on the path described by that company as a software developer rather than me dictating what platforms I prefer to work with.

 

I’ll touch on the pattern of constructing your curriculum which emphasizes that concepts or programming languages should not only be learned at surface level but rather on a deeper level. This helps to save time such that the programmer is not reinventing the wheel or working towards an idea that has been deemed academically impossible and instead must refine the problem to make it soluble. Personally, I can relate to this when it comes down to JavaScript where I’ve learned some concepts and can come up with interesting solutions, but deep down I believe there’s always another leaner, faster method to produce the same or better results.

Thea's Food Pantry and LibreFoodPantry

 It's such a great opportunity contributing to a meaningful project like Thea's Food Pantry, an open source program dedicated to Worcester State University students who might find themselves in need of food supplies. The program was established so that students can focus more on their learning rather than worrying about going without food. Food insecurity is a reality that affects a third of Massachusetts college students due to various factors such as hikes due to inflation and heavy financial burdens for instance paying student loans.
LibreFoodPanty is the opensource infrastructure on which Thea's Food Pantry operates. It's a template roadmap of principles that we'll be using to build and connect features on Thea's Food Pantry. Going through the docs, LibreFoodPantry (LFP) had an interesting user story map in picture format that shows different roles and responsibilities of users which I found to be interesting. Some of the roles include administration, staff, guest and donor. It's always a good thing to have visual like this before writing any line of code as it creates clarity of what needs to be done.
Thea's Food Pantry also has user stories but in a textual format that shows how the intended users of the software currently work and the guide to the design of the software. They have the same user roles as shown in LPF but detailed such as displaying a blank page when a new guest access the system.
Overall, the two systems are a solid foundation for practicing how to write opensource software products.

Implementation of web systems

This week's blog features content from Geeksforgeeks, a site that features 20000+ Programming Questions, 40,000+ Articles, and interview experiences of top companies such as Google, Amazon, Microsoft, Samsung, Facebook, Adobe, Flipkart, etc
 
Web systems are systems that use internet technologies to deliver information and services. Deliveries might include textual data, multimedia or any other format. There are various ways web systems can be packaged and delivered to users, for instance through websites, web apps and can be embedded into hardware as in internet of things frameworks.
 
For most users, their interaction with web systems is through websites. They are web pages that get served over the internet. A website can either be static or dynamic. Static websites simply deliver data and information and do not perform requests to a backend service. What you see is what you get. On the other hand, dynamic websites will change state based on the user’s interaction with it. Requests are sent to a backend service that returns data and changes the state of the site whereby a user gets to see a different view based on their interaction.
 
Web development can start by building the application from scratch or using a framework that provides a boilerplate (sample code) to start from. There component of web development includes web design, web publishing, web programming, and database management. Frameworks include, AngularJS, ReactJS, VueJS, Laravel etc. There are two sides to bringing a web system to life, the front-end development, and the backend development. Front-end also known as the client side is that part that the user directly interacts with. It could be buttons, lists, cards, or multimedia component. Front-end technologies include HTML, CSS, JavaScript, Bootstrap, JQuery and many more. The challenge associated with front end development is that the tools and techniques used to create the front end of a website change constantly and so the developer needs to constantly be aware of how the field is developing.
 
Backend development is that part of the web system that users cannot see. It receives requests, computes the request, stores (in some cases) and return the result to the front-end to display to the user. It includes writing APIS, creating libraries, and working with system components. Database services and algorithms for instance live on the backend side of a website. Technologies used include NodeJS, PHP, Ruby, Java, Python etc.
 
We’ve used some of these technologies in class and seen their effectiveness and structure. In Thea Food Pantry web system for instance, VueJS is used as well as HML and CSS.
Sources:
1. https://www.geeksforgeeks.org/web-development/
2. https://frontendmasters.com/guides/front-end-handbook/2018/what-is-a-FD.html

REpresentational State Transfer - REST APIS

 For this blog I chose For this blog I chose https://restfulapi.net blog for its well descriptions of terms about Representational State Transfer and how it works. REST was coined by Roy Fielding in 2000. It is an architecture style for designing loosely coupled applications over the network, that is often used in the development of web services.

 

An API (Application Programming Interface) is a set of definitions and protocols for building and integrating application software. It’s the glue between an information provider and information user or a gateway between clients and resources on the web. Clients are users who want to access information from the web, while resources are information that different applications such as backend services provide to their clients. It could be presented in different format such as multimedia, images, videos, text, numbers or any other data type.

 

When a user makes a request via rest api, it transfers a representation of the state of the resource to the requester. The representation comes in several formats via HTTP: JSON (JavaScript Object Notation), HTML, XML, XLT, Python or plain text. JSON is the most common format used due to its well readability by humans.

 

¹Headers and parameters are also important in the HTTP methods of a Restful API HTTP request as they contain important identifier information to the request’s metadata, authorization, uniform resource identifier (URI), caching, cookies etc.

 

²A REST api requires requests to contain components such as Unique resource identifiers, methods, HTTP headers, data and parameters. Some methods include GET, POST, PUT, DELETE. 

GET is used by clients to access resources that are located at a specified URL (Uniform Resource Locator)

POST is used by clients to send data to the server.

PUT is used by clients to update existing resources on the server.

DELETE is used to request to remove resources from the server.

 

HTTP Headers display the http method request or response that passes additional context and metadata about the request or response.

 

Data

Information that is passed into POST, PUT and other HTTP methods

Parameters in a request include path to specify URL, details, information about the resource.

 

³Below are 6 architectural constraints which make any web service a truly restful api:

1.    Uniform interface : 

2.    Client-server : Client applications and server applications much st be able to evolve separately without any dependency on each other.

3.    Stateless : The server will not store anything about the latest HTTP request the client made.

4.    Cacheable : For performance improvement, data can be temporarily be stored on client side

5.    Layered system : Data can be stored on server A, authentication on server B and accessed via server A

6.    Code on demand : Data can be XML or JSON format or executable code to support part of the application

 

Sources

1.    https://aws.amazon.com/what-is/restful-api/ accessed on 12/2/2022

2.    https://aws.amazon.com/what-is/restful-api/ accessed on 12/2/2022

3.    https://restfulapi.net/rest-architectural-constraints/ accessed on 12/2/2022

 

YAGNI (You aren't gonna need it)

For this blog, I chose techtarget’s blog. The definitions are kept simple, concise and easy to understand. YAGNI ( You aren’t gonna need it or You ain’t gonna need it ) is a practice in extreme programming associated with software development which states that features should only be added when required. Most developers including myself have included code that is believed will be needed in the future to perform a specific cool task. It could be a feature collects the user's age so we can determine which age-group is mostly using a piece of software. However, YAGNI teaches against this, developers don’t have to waste time writing source code that is assumed will be needed in future. The extra wasted effort is unnecessary and can hinder or slow the development process.
 
Features are expensive, both to develop and maintain, and for users to learn and navigate around. This could result into delays that may give competitive advantage to rivals.  Features that aren't necessary at the time of production are a huge waste. YAGNI can be compared to the Just-In-Time manufacturing where rather than ordering a bunch of parts based on what you think you might need, you wait for actual customer orders and ensure your process is lean enough that you can pull orders through your supply chain quickly enough to satisfy the customer.
 
On the other side, it may be necessary to think about future features and fashion current features in a way that integration will be seamless. This does not mean shipping those features in the current release.
By avoiding adding features and complexity until it's needed, the overall design of the system can remain simpler and makes it easy for debugging as well. The feature you thought you would need usually turns out that you either didn't need it, or that when you do need it, your understanding of how best to design it will be different than earlier imagined in the project.
 
The YAGNI concept helps avoid spending time on features that won’t actually be used. For instance, in developing a calculator app, the system doesn’t need access to the user’s contacts, location data, or reading emails and showing adverts. These are unnecessary features that make the user interaction with the application undesirable. Most users will simply not use a calculator application that requests for their contacts, location, or bluetooth connection. This renders the application unusable and therefore dead.

Design Smells

I chose alpharithms blog to get definitions as they were well defined and short. After the English and alpharithms' definitions, I add a small example of how the concept are applied in software development. These are classifications of poorly written code making it hard to understand, maintain or modify. They include Rigidity, Fragility, Immobility, Viscosity, Needless complexity, Needless Repetition and Opacity.

Rigidity means to not easily bend. In software that means the code cannot adapt or be open for changes occurring around it. An example, we have an authentication module in our app. Later on we decide to determine the user's online status and display it to other users. This could be a challenge especially if we don't have parameters in the module that capture the exact time the user was authenticated and when they went offline.

Fragility means easily broken or damaged. In software this means a piece of code is delicate such that any slight modification to it could lead to breaking changes elsewhere including areas that have no direct relationship with the change. The programmer is locked between leaving it as it is which could potentially expose the system to vulnerabilities or remove it completely leaving other components broken because they depend on it.

Immobility means unable to move. In software, this means we cannot export this code to other parts of the system. There could be several reasons for that, including being platform specific or requiring a particular version of dependency to be met.

Viscosity, a term associated with flow of liquids. In software development it means the code cannot flow to other parts of the system and often it’s hard to do the right thing when faced with different situations.

Needless complexity. This is an easy trap to fall into especially when copy and pasting code that performs “cool” operation. Let’s say you’re developing a note taking app, you shouldn't need access to user’s GPS location, phone call records, and text messages.

Needless repetition. Instead of repeating source code, we could create shareable components and state management stores that hold data centrally such that it can be availed to other components without rewriting the source code. Repetition sometimes leads to inconsistencies in data especially if the components do not effectively communicate and update each other.

Opacity which means hard to see through. This means the code has arrived at a point where it's hard to understand what's going on due to several modifications. Let's say we build a calculate application that adds two numbers, next we add on computing the logarithms, then we add on computing the squares of multiple numbers. It just keeps on evoving until no one fully understands how to make modificaitons to the code.

Object Oriented Programming

For this week I chose 'The story of object-oriented programming", by medium.com. The blog dives right into the topic by stating that any developer who wants to build a high quality software out to master object-oriented programming concept. I learnt that object-orientation was intended to be closer to the real world and also making it easier. Objects in the real world, could be anything such as a house, car, bike, books etc. Objects have attributes and behaviors, that's how we identify them. Attributes are the properties of a particular object. For instance some attributes of the human race are having a nose, having eyes, having legs and so much more. Behaviors on the other hand are actions that the object performs. It could be displaying a message that is useful to the user, sending and delivering an email when a button is pressed, playing certain theme songs when new levels are reached in a game. Objects do not generate themselves, they come from classes througha process known as instantiation. A class is the home or blueprint where attributes and behaviors live. When an object is made out of a class, it is safe to say that it contains the exact content of that parent class.

In relevance to Software development, there exists four expressions to object oriented programming (OOP) namely, Abstraction, Encapsulation, Polymorphism and Inheritance. Abstraction means hiding the implementation details of a particular class. Basically, data and information that is irrelevant to the user is not presented to him/her.  A commonly used example is  about cars and their technical functionality such as burning oil in the combustion engine. As the car executes its source code, the driver does not need to know what events are happening under the hood in full detail.

Encapsulation means having an another object within another object. Sticking to the car metaphor, we can see the idea of encapsulation in car seats or tires. They (seats or tires) could be of different colors, material and from various manufacturers as long as they meet requirements of a particular car. Combined together, they serve the purpose of a car as whole unit.

From the word 'Poly' meaning 'many', Polymorphism is the ability of an object to be inherited by multiple classes. With polymorphism, it's easier to have consistency in data because child cases are reflecting data that comes from parent classes. Errors and inconsitencies are reduced.

Inheritance is the ability to share attributes with other classes. We do not need to repeat source code to execute a particular task. With inheritance, we can generate other classes that have the same properties and behaviors. For instance, a student and a professor both inherit their properties from the class human. They both have physical attributes and behaviors such as speaking, reading and moving.

Don't Repeat Yourself - DRY

I chose thevaluable.dev's example on Don't Repeat Yourself because it well demonstrates the concept. It talks about a shipment class on an e-commerce platform that's used to ship products to customers. First, it's configured for a single warehouse, but is later required to ship to 76 different warehouses with different details such as location and product amounts. Loops and other repetition logic are not the best as far as efficiency is required in this scenario. The programmer would have to re-write the code to meet the new demands. That is a lot of time wasted that could have been employed to fixing bugs or testing the code. This problem could simply have been fixed by creating a single abstraction capable of taking in different values yet delivering similar desired results without code duplication.

The blog also highlighted that the DRY concept was not only to be used in writing source code but also to anytthing that related to your project. "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation". Whether it's database interaction to store or retrieve data in different parts of the code, a single component that performs this task should be used instead of copy/paste the source code.

When writing software, it's common to come across situations where the same functionality might be required. It's common to copy and paste the same code to varying locations to achieve the same task. Take an example of a coffee ordering system, the system captures a user's identity, financial data and their desired coffee type then generates an order number. Some customers may require that a receipt of their orders be printed out.

How and where would we get the data to print out on the receipt? There is a high possibility that we copy the code that identifies the user and their desired coffee type and then print it out. This is repetition and possible trap that we might find hard to get out of later. Instead, we could create a single user functionality such that printing a receipt is an option instead of making printing a stand-alone functionality. This way, we can also create other stores that use the same logic and we won't have to worry about making changes that only support one store and not the other.

I hope to use this concept in my future projects to avoid unnecessary repetition and time wastage. Clean code is easy to clean-up, refactor and update.