Similar to prior weeks, you have a basic set of skills, and your understanding of software development is narrow and small. Expanding your bandwidth allows you to further expand your horizons and learn more. The best step to solve this is to take in new information, but it is important to do so carefully, as it is easy to be overwhelmed in the information intake.

Some examples of ways to gather the new information is through following software development blogs, following software developers on social medias like Facebook and Twitter, and subscribing to a software development mailing list, just to name a few. There are also many hundreds of online courses and videos as well, so there is no shortage of information to be had. Following software developers can key you into new technologies before they become widely popular, which can give you a head start into the game before others. There are also national conferences that you could attend as well, and another great thing to do is to read any books some of the speakers have written in the past, so you can help get an idea of what they will be talking about and their software development history.

However, it is just as important to know when to expand your bandwidth then just how to as I explained above. It is possible to get stuck with the gathering of information, and it can easily happen where you get stuck researching and learning and never go back to creating any software. It is important to use this skill to accelerate your learning, but it is also important to not get stuck with the learning, learning is a means to an end, you must come back when you are done with the learning. Usually it is recommended to not spend more than a few months with this learning process, as that allows you to not get stuck in the learning process, as it is not too long, but it is also not short enough to the point where you do not learn much of anything at all.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

Rest API are a common method for integrating applications in their services to provide more reliability and to be flexible where possible. I chose to use stackoverflow.blog as my blog because they are filled with information in regards to many programming languages, AI, databases, especially Rest Api and etc. The blogs also discuss and provide certain authors that give explained details on the processes and focus on implementing, as well as common problems that may erupt with certain solutions that can lead an aid to a professional career in software development world. As this website have given me a clearer perspective while in my Software Construction architecture class along the way working on our Food pantry project.

As for Rest Api, they are a common web service used in today’s technology. Allowing the client (person making the request) to communicate with the servers (receiving the client requests) with is the Rest Api that is connected to a database. To keep in mind, when creating an API, we use always separate the client from the server to made to interact on one way because due to fact that clients can make requests but not responses, while server can make response but not requests. We use HTTP methods as an action for the client wants to make. GET Method allows the clients to request the information from the backend. POST Method is creating or listing the information. PUT Method is editing the information. DELETE Method allows the deletion of information.

JSON (JavaScript Object Notation) is a basic format to help the programmer to easily read write out code for the computer to understand and generate the output and cache the responses. API endpoints are the end of the communication, which utilizes the services or the response. For example, when making a request on the API rom the browser or an application, the response will then be received that reaching that point will be the endpoint. 

After learning about REST API in my CS-343 class and working along the course. I start to begin to gain more confidence and gain more insight on how the process works. And designing the API which gave me complications for the backend and frontend as well. Realizing even the slightest misspelled command or wrong path can leave you clueless on fixing the problem but understood why the situation erupted. This material could’ve been useful for my database course I have taken previously to implement the databases on the server to be integrated along with providing the appropriate security from the client side with restrictions, while the backend is able to store, modify if allowed. 

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Front end and back end development get thrown around a lot, but I never really understood the difference. Therefore, I decided to do some research and figure out what front end development and back end development are, and what the difference between them is.

Let’s start with front end development. Front end development, also known client side development, deals with the user interface. The user interface, or UI for short, is what the user gets to see and interact with. Front end developers are responsible for designing and creating the user experience elements in a program. Front end developers may find themselves using technologies like Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript to implement features such as buttons, menus, pages, and so on. The goal of front end development is to create attractive, simple, and easy to follow interfaces for users. However, achieving this goal can get quite complicated due to a major challenge. This major challenge is the sheer amount of variance in devices. Not all devices are the same. There are devices that are big and small, fast and slow, and new and old. Guaranteeing a consistent experience across all devices and platforms is a very difficult task but is an essential one. This gets further complicated with the rapidly evolving technologies, standards, and practices.

Now, back end development, as you might have guessed is the complement of the front end development. If front end development deals with things that the user can’t see then back end development deals with things that a user cannot see. Back end development, also known as server side development, deals with servers that provide data on request, the applications which channel those requests, and the databases which organize the information. Back end developers might find themselves using databases such as IBM DB2, MySQL, and NoSQL as well as a bunch of programming languages and frameworks such as Java, Python, and C++. The goal of back end development is to design and create applications that can accurately locate and deliver data to the front end as smoothly as possible.

While developers usually just specialize in either front end development or back end development, sometimes employers need developers who are proficient on both ends. This is known as full stack development, and these highly specialized developers are known as full stack developers. Their job is to use their deep knowledge to suggest ways to make the development process more efficient.

https://www.conceptatech.com/blog/difference-front-end-back-end-development

From the blog CS@Worcester – Fadi Akram by Fadi Akram and used with permission of the author. All other rights reserved by the author.

In class, we’ve been using vue.js. Vue.js seems to have many similarities to React, so I thought it would be informative to briefly discuss how to implement React components. Vue.js seems to also use components, so I thought it would be helpful to explain a common concept that seems to exist between the two.

I open visual studio code, and open the terminal. To create a react app, I typed the following commands:

• npx create-react-app reactapp
• cd reactapp
• npm start

After React finished installing, I changed my App.js to this:

This component’s render() function will display the content on the webpage using JSX¹. There is currently nothing but an empty screen. Instead of writing everything inside a component, we should segregate the information into separate components, that would then be called in this central component.

For this example, we’ll create a webpage with four parts: a header, a navbar, a side pane, and a main pane. Each component will contain its own js file. Since we’re making a very simple web page, the header will be a simply designed bar. I created a blue bar in Paint, and I imported it using CSS. The header will contain a title, and compose the top of the web page.

Below the header should be the navigation bar. For the sake of example, the navbar here will just display the formatted text on it. The navbar would in practice function as a transition between web pages.

Next is the side pane. This side component on a website could function as a way to automate section traversal, as is done on a wikipedia page. If the main section has a title such as “Lorem Ipsum”, it would list “Lorem Ipsum” with the ability for a user to highlight and click on it. Like the navbar, we’ll only create a very simple display.

The final component is the main component. This component will be where we put our text. I created a title called “Lorem Ipsum”, with some body text.

We now need to add our components into our previous App.js file. The top will contain the header and the navbar, and the body will contain the side pane and the main pane.

Finally, we need to create the CSS. For my design, I am using this inside of the App.css file, which is then imported into App.js.

For our product, we get this (the bottom part was cut in the screenshot for space):

While it’s not winning any awards, it’s a draft of a simple website design. This illustrates how components work together, in a library like React, and I hope this helps with understanding vue.js too.

Link:

1. https://www.youtube.com/watch?v=w7ejDZ8SWv8 (For discussing how components and JSX work, so I could make this guide!)
2. https://reactjs.org/tutorial/tutorial.html (ditto)

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

In my previous post I linked an article I read about some basic things that I should know about JavaScript in my attempt to get more familiar with the programming language for my computer science course this semester. This post is a continuation of the last and necessary to getting me up to speed with JavaScript and how my course is using it. So far I have only programmed in languages like C, C++, Java and not a typescript based language. The languages I used were more object oriented and I came across this article below that caught my attention. That you shouldn’t use classes in JavaScript.

https://javascript.plainenglish.io/why-you-should-not-use-classes-in-javascript-ca960d13c625

Funnily enough the article starts off with a mention to Scheme, the first programming language I learned in a college education setting and a language I never touched again after that semester. It turns out according to the article that JavaScript itself was supposed to be based on Scheme. So, here’s hoping some of what I learned from Scheme will be beneficial down the line when I learn more about JavaScript.

One of the main issues described in the article relate to binding. That with JavaScript even referring to an object that was class defined requires the exact context in relation to it’s call. In his example it shows ‘this’ being used three times just inside the constructor method for creating the function. I haven’t really ever seen a class defined yet in JavaScript so all the humorous jokes about the language I have seen so far are starting to make a bit more sense (like an endless chain of this.myfunction.this.myclass etc etc).

Another Issue raised in the article is the fact that you apparently cannot create private variables in JavaScript. In the example shown it makes it pretty clear. I was honestly kind of shocked considering it is such a common thing used in every other language I have learned. This is definitely something I need to remember about JavaScript to avoid future errors if I ever have to create a class and intend to use encapsulation.

This article ends on the note that the author has a preference for factory functions, a topic I had only heard of and learned during this semester. While the list of reasons to not use a class are I feel minimally an issue it does help me understand that JavaScript is generally less focused on class based structures and more focused on just using objects to avoid some issues from JavaScript and issues from OOP in general.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

When my instructor introduced technical debt, he described it as poor design choices that delay the productivity of a development team. When I was learning about how unclean code can slow down the software development process, I asked myself, “Is unclean code technical debt?” To answer the question, I am going to explore and compare the meanings and consequences of unclean code and technical debt. I will be using chapter 1 of Clean Code, written by Robert C. Martin to support the discussion. Chapter 1 explores the meaning of clean code and its value.

Unclean code is code that cannot be read and enhanced by a developer other than the original developer. Some qualities of unclean code include uninformative names, redundant comments, and multi-purpose functions. Some reasons for unclean code may include making a deadline and having inadequate skills. Unclean code is consequential because it slows down the development process. When code becomes unclean, it becomes difficult to read. When it is difficult to read, it becomes to develop.  Martin reinforces the value of clean code by talking about how unclean code killed a company in the 80s: “As they added more and more features, the code got worse and worse until they simply could not manage it any longer. It was bad code that brought the company down.” In other words, bad code tempts bad code and as bad code piles up, the application eventually becomes unusable, unmaintainable, and not worth fixing.  Unclean code hampers the capacity of an application to be developed.

Technical debt is the time a developer needs to use to refactor the code of a piece of functionality from a previous release because the functionality was implemented hurriedly. In software development, developers may deliver an application faster by using a convenient course of action to implement a piece of functionality. When they tell themselves they are going to refactor the code and add even more functionalities in the next release, they are putting themselves in technical debt. The debt becomes consequential when it is never paid. If developers do not pay the debt by refactoring the code, it may be difficult to understand. The lack of understanding may tempt developers to pile on the mess with unclean code and unintuitive implementations. As the mess grows, the application may become unusable, unmaintainable, and not worth fixing. Technical debt hampers the capacity of an application to be developed.

While unclean code functions like technical debt, I do not think unclean code is technical debt. Unclean code describes code, whereas technical debt describes the extra time a developer needs to use to refactor code. I think the two concepts have a cause-and-effect relationship, where unclean code is the cause and technical debt is the effect. The loss of productive time from unclean code may sway teams to take shortcuts. Understanding unclean code as a cause of technical debt will encourage me to become more aware of the way I write my code.

Martin, Robert Cecil. “Chapter 1: Clean Code.” Clean Code, Apogeo, Milano, 2018, pp. 33–46.

From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.