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.