Front-end is the graphical user interface where users can interact with on their computers to communicate with the website’s database to view the information they need. To develop the front-end, developers use HTML, CSS, and JavaScript framework; and they also have to be aware of the constantly changing in the tools and techniques to create the front-end of a website.

HTML (HyperText Markup Language) is the most basic markup language (absolutely not a programming language), for documents designed to be displayed in a web browser. Learning HTML is the first step in front-end development. Come after HTML is CSS, stands for Cascading Style Sheet, and is used for formatting markup language, mostly for HTML. Finally, while HTML and CSS creates the structure of the website, JavaScript is what powers its interactivity. Furthermore, learning JavaScript is a never ending process since there are new frameworks coming every year. Let’s take a look at the popularity differences between these web frameworks, according to the Stack Overflow survey in 2019 and 2020 respectively:

We can see that jQuery is losing their numbers to React.js and Angular and React.js looks like they will get that first place this year, but the top three most popular frameworks are all JavaScript. Besides, as I said that there are new frameworks coming every year, it means that when a better framework shows up, front-end developers have to learn it in order not to be left behind. For now, in my opinion, React.js is what you should go for if you want to get a role in this field.

Besides the programming language skills, there are other tasks that front-end developers have to be aware of. From my experience, a method called fake API is really important. For instance, in the process of developing the graphical user interface, front-end developers have to test their work by calling the API from the back-end team to see how the data fit into their blocks. However, in case that back-end team falls behind or somehow is not able to provide the front-end team with the built API, fake API is one useful method to test the front-end. Another frustrating task that I’ve heard about is that the design has to be responsive which means that the website has to run properly on any device, from the smallest mobile device to the largest desktop.

In conclusion, above is what I know so far about the front-end. Also, I found outstanding guidance about the practice of front-end development from Frontend Masters including almost everything we’ll need regarding a front-end topic. Check it out if you want to learn something in the front-end.

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

I have worked before with Docker and Docker Compose, but I am a bit shaky when it comes to networking either of them. I know it is possible, and I know it is often a necessary step in deploying applications. However, I have never had luck trying to network containers together. I wanted to spend some time learning more about this.

Docker comes with several networking drivers: bridge, host, overlay, ipvlan, and macvlan. Bridge is the default networking driver used by Docker and is the most popular. Ranvir Singh’s article “Docker Compose Bridge Networking” outlines how to use that bridge networking driver to network containers together using either Docker or Docker Compose.

A network for Docker containers can be created using the following command:

$ docker network create -d bridge my-network

This creates a network called ‘my-network’ which uses the bridge driver. To add containers to this network, one would run commands similar to the following:

$ docker run -dit --name container1 --network my-network ubuntu:latest
$ docker run -dit --name container2 --network my-network ubuntu:latest

These commands would create ubuntu containers ‘container1’ and ‘container2’ respectively and would add them to the ‘my-network’ network. Singh advises that a network should be dedicated to a single application; this ensures that applications are secure and isolated from one another.

Networking with the bridge driver works slightly differently when using Docker Compose. By default, Docker Compose will create a network with the bridge driver and will deploy the services defined in the Compose file to that network. This network is named after the directory that the docker-compose.yml file is in. This setup does not require ports to be exposed in order for containers to talk to one another; one should be able to call the hostname to reach another container. Calling ‘docker-compose down’ removes and deletes the network created from the docker-compose.yml file.

Instead of using the default Docker Compose network, a network can be defined inside the docker-compose.yml file. This definition happens at the top level of the compose file, similar to how a service is defined. This way multiple networks can be defined and used by a single compose file.

I selected this source because it was something I was interested in. I thought networking was exclusive to Docker Compose, and I was not aware that you could create a network for Docker images to communicate over. This does not help my problem of not being able to get Docker Compose services to talk to each other, but it does help to clarify some information I had been missing. I will internalize the information in this article for future work, but I also want to keep looking into this topic.

Additional Source

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

Christian Shadis

Over the past month, my Software Construction, Architecture, and Design course has shifted gears into a sort of crash-course for full-stack web development. Our initial focus was on the backend of web apps and specifically on APIs. In class I learned how to edit API endpoints for different HTTP methods such as GET, POST, and PUT. I understood how to code the API and I understood the difference between the different HTTP methods, but I still did not understand the very basics of what an API was beyond its acronym. For this blog post, I set out to learn the fundamental nature of APIs to supplement my technical understanding. While it is helpful to know how to code an API, the knowledge would likely be useless without an understanding of what an API is or when to use one.

An API (Application Programming Interface) is a technology developed as a solution for multiple applications needing to communicate despite their incompatibility. For example, a person running Google Chrome trying to view the available items on a store website requires their web browser and the store’s server to be able to communicate. This is unlikely to be possible without an API. The API allows Chrome to send a request for information to the server, and then allows the server to return the requested data (or an error message) in a particular format such as JSON. The API facilitated the exchange of information between a client application and an unrelated server. This example illustrates the necessity of APIs. Without them, communication among devices built differently would be impossible. Web browsing as we know it would not exist, nor would web-based phone applications.

In What is An API and How Does It Work?, Thomas Davis first describes the omnipresence of APIs in everyday life even for non-programmers, and contrasts that ubiquity with the fact that few people understand how an API works, let alone what it does. He describes the API as an intermediary between two parties that do not speak each other’s language, and provides everyday examples of situations in which one would desire two computers to communicate. Once he explained the base concept of an API, he described different types of APIs such as the REST API, the SOAP API, and the XML-RPC API, comparing and contrasting each.

Knowing how to code APIs is an important aspect of backend development, but I feel much more confident in my ability to code an API now that I more fully understand the concept. I expect to build backends for web applications in the future, so this knowledge should be helpful in my development career.

References:

https://towardsdatascience.com/what-is-an-api-and-how-does-it-work-1dccd7a8219e

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

In the blog linked above by John Au-Yeung and Ryan Donovan, they look at “how to design REST APIs to be easy to understand for anyone consuming them, future-proof, and secure and fast since they serve data to clients that may be confidential.” The blog post starts off with an intro detailing how REST APIs are one of the most common kinds of web services today, describes a REST API’s function and addresses the problem of designing it right so the API consumer and API maintainer don’t run into any problems down the road.

The blog post is sectioned off into 7 different sections. These sections all address a good practice for designing a REST API as well as a block of code to set an example of what they mean. The 7 sections consist of Accept and respond with JSON, Use nouns instead of verbs in endpoint paths, Handle errors gracefully and return standard error codes, Allow filtering, sorting, and pagination, Maintain Good Security Practices, Cache data to improve performance, and Versioning our APIs.

To summarize the 7 sections,
Accept and respond with JSON: REST API should accept JSON for request payload and also send responses to JSON.

Use nouns instead of verbs in endpoint paths: Since verbs are already in the HTTP request, we should use nouns.

Handle errors gracefully and return standard error codes: Eliminates confusion for API users by handling errors neatly via HTTP response codes that indicate what error has occurred, this allows API maintainer to have enough info to understand problem that’s occurred.

Allow filtering, sorting, and pagination: Allowing these 3 features will increase performance by reducing usage of server resources.

Maintain Good Security Practices: Use SSL/Load a SSL certificate onto server and add role checks for users.

Cache data to improve performance: Add caching to return data from the local memory cache instead of querying the database, this would lead to getting data faster but data could be outdated.

Versioning our APIs: Version your API semantically like most apps do today.

From reading this blog post, I’ve learned more about the good practices for REST APIs. I was interested in learning more about REST APIs since it was the first time I was working them when we went over in class activity 12. Also, the blog post’s title mentioned REST API design which I thought was relevant to our class due to the class being aptly named Software Design and Architecture.

Admittedly, I didn’t learn the most helpful stuff from this article since I had learned most of it in class and by going over the in class activity with my group but I thought this blog post helps reinforce good practices if I do eventually work on REST APIs in my CS career. I’d also say that I looked into the article because of the making of endpoints for homework 4.

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

In addition to learning about design patterns that should be referenced when programming, I wanted to learn about bad software design, which led me to anti-patterns.

A wonderful source covering anti-patterns that I learned from can be found at: https://www.freecodecamp.org/news/antipatterns-to-avoid-in-code/.

Anti-patterns are bad software designs that show how not to solve problems in programming. The source covers 6 different anti-patterns: Spaghetti Code, Golden Hammer, Boat Anchor, Dead Code, Proliferation of Code, and the God Object.

Spaghetti Code is when there is barely any structure to the code. Files are thrown in random directories and it is difficult to follow the flow of the program. This would produce many issues when needing to modify the code, because the program can break and it would be difficult to tell what caused it. It would also be difficult to estimate what may break after you make a change.

Golden Hammer is when you repeatedly use an architectural approach in your code that does not exactly fit the program you are making. Despite the fact that it doesn’t exactly fit the program, it is still utilized because it gets the job done eventually. Problems arise from the fact that it does not fit the program, and can cause longer runtimes.

Boat Anchor is when programmers leave code in the codebase that has no purpose at the moment, and is kept incase it is needed in the future. This code acts as an anchor because it holds the program back– it increases build time, and can make code reading difficult when programmers have to discern between code used and the code saved for later.

Dead Code is when programmers cannot tell which parts of code are currently necessary for the program and which parts of code are no longer needed.

Proliferation of Code is when objects in your codebase only serve to create a more important object. This makes the code more difficult to follow.

God Objects are objects that have too many responsibilities. The code should be broken down more so that objects do not have to undergo functions that other, smaller bits of code can cover.

The Boat Anchor anti-pattern reminded me of YAGNI (“You aren’t gonna need it”). YAGNI is the principle that you should not add functionality to the program until it is actually needed. Adding the functionality in advance may end up messing with schedules and requirements may be changed in the future where that functionality is not even needed. The God Object anti-pattern reminded me of the single-responsibility principle (which the article briefly mentions). These anti-patterns will be very useful to apply to my code to prevent the program from being too complex and hard to follow.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

            Although I dedicated my previous post to introducing REST and RESTful API writing, I feel that it is important to briefly return to talking more about Docker, given how much I have come to using Docker containers for a significant part of my studies recently. In this blog, I have talked about containerization as a concept overall and not exclusive to Docker, as well as some of the things that can be done when using Docker. Namely, I discussed data management through use of volumes and mounts and container networking through port mapping. Such  features can be rather straightforward and easy to use individually and with enough practice during application development, however as development becomes more complex and demanding, having to repeatedly run commands to enable further functionality can be rather cumbersome for individual developers and overwhelming for the entire development team overall. This is not exclusive to Docker; certain utilities or commands used in development that are used especially frequently may overcomplicate the development process. Thus, often, a certain degree of automation or simplification is needed.

In my experience, I have used scriptwriting in order to speed up parts of my development process. In Docker, where it is possible to have to manage multi-container applications at once, having to manually define ports and volumes for each service individually can be extremely inconvenient for complex application development. Therefore, docker-compose YAML files  are often utilized to manage multiple services, volumes, and networks at once and in a more organized manner. Though a docker-compose file is not exactly a script file when it comes to defining container services, they can still help condense the entire process to create a service into one file. Moreover, to utilize a Docker container for application development, a docker-compose YAML file is not enough, as a Dockerfile is also needed in order to build the container’s image. However, for simplicity, I will only focus on the compose file.

Like I mentioned, a compose file is not necessarily a script file, not at least from my experience of writing script files. Despite this, there is a certain structure that needs to be followed when writing docker-compose files in order to ensure the proper functionality of the application. One resource that I found in my research regarding writing docker-compose files is an article named Introduction to Docker Compose posted on Baeldung.Com by Andrea Ligios. In this article, Ligios begins by briefly introducing the theory YAML configuration files and why using such a configuration file is preferable for development. Moreover, they proceed to illustrate the basic structure of a docker-compose file by highlighting the services, volumes, and networks to be used for the multi-container application, before they go into further detail on how to set up each of the previously mentioned sections and provide examples.

While it is important to understand how each part of a docker-compose configuration works individually, when it comes to larger-scale development and deployment, simplifying the process through use of docker-compose files can be extremely helpful.

Direct link to the resource referenced in the post: https://www.baeldung.com/ops/docker-compose

Recommended materials/resources reviewed related to :
1) https://www.tutorialspoint.com/docker/docker_compose.htm
2) https://docs.docker.com/compose/
3) https://dockerlabs.collabnix.com/beginners/difference-compose-dockerfile.html
4) https://phoenixnap.com/kb/docker-compose
5) https://runnable.com/docker/docker-compose-networking

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

The section “Concrete Skills”, found in chapter two in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye discusses the issue of needing some quality that will convince hiring managers to choose you over other candidates. In particular, this issue centers around the question “If we hire you today, what can you do on Monday morning that will benefit us?”. The solution the authors suggest is that one should develop concrete skills. What they mean by concrete skills is abilities that show that you don’t need to be babysat such as writing build files in popular languages or having knowledge of popular open-source frameworks. Skills like these show people like hiring managers that you have something of worth outside the basic skills expected of an entry level position. In the long term, the specific skill doesn’t matter too much as it’s just a stepping stone to the path to journeyman.

A concrete skill isn’t something that I’ve put too much thought into. I guess some could say that skills I’ve learned in class like knowing how to use docker or SQL would count as concrete skills, but that depends on the position I apply to. There’s also the projects and work connected to my GitLab account which I could show to a potential employer. Still, I have this feeling that it won’t be enough since most of my peers have a similar advantage if not more. That’s why I feel that I should do some independent study, not an internship mind you, something that I can do on my own time.

I feel like I could showcase a concrete skill by working on a personal project which I’ve been toying with but haven’t settled on a specific plan. I’d like to make a simple chess program, partly just as an excuse to learn the game but it would also be something to show to say “this is something I’m able to do and contribute”. I don’t know what exact skill this would convey; it could be that I’m proficient in so and so language or I can make a program by myself even if it’s on the simpler side. Despite my lack of direction right now, I feel it’s still worth a shot.

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

This chapter’s opening quote was a very insightful one for me. It says: ” Tomorrow I need to look stupider and feel better about it. This staying quiet and trying to guess what’s going on isn’t working so well.” The whole point of this chapter is that there are going to be times when you do not understand what is happening, what you need to do, or how to accomplish the task at hand. This is ok. Even if there are people depending on you to just know the right answer you will not always. You must ask questions and show that you are capable of learning how to do your job. That is how you grow as a craftsman.

“Expose your ignorance” is a pattern I have a lot to learn from. The opening quote talks about staying quiet when you do not know what is going on and that is something I am often guilty of. Just like the author says, I am afraid of looking incompetent. I often feel this way despite knowing I am not yet expected to be a competent programmer; if I were then I probably would not be in this class (I would consider some of my peers to be pretty competent though). As I student I am surrounded by professors who are literally being paid for me to expose my ignorance to, and they are happy to hear it. I am confident all the faculty in the CS department would love to hear more students ask questions and admit they do not have any idea what is going on. Most classes are silent though, especially in online courses. I am not sure if it is from a lack of interest in the course, the difficulties of online courses, or a fear of asking questions (it is probably a combination of the three.)

Moving forward I will really keep this pattern in mind, both as I finish this course and as I go out into the workforce. Not knowing everything does not mean you are not good enough. It simply means you are not good enough yet. Asking questions and actively working to improve shows that you are willing to put in the effort to become better.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

What this apprenticeship pattern talks about is completely different from a typical software architect approach. This pattern talks about what you should do if as you go on the long road and your journey as a software developer, you stumble on something different that you feel would be beneficial towards. It gives an example of how some software developer completely left software development to teach surfing half way across the world. There are many examples and situations as to why someone may not want to be software architect anymore. However, no matter the situation, this pattern talks about how it isn’t a good decision to just burn bridges and forget everything you learned on your journey in developing code and all these other technologies that you put in time to learn. You had many systems that you learned to do things and implemented them in order to do things faster and be able to learn many new things at a faster. Instead of just leaving all this behind, the pattern says to use all that knowledge and move forward to apply it in your new field whichever direction that may be. It is never helpful to just forget everything if you start something new but to learn from your experiences.

This pattern may seem kind of odd to software developers and architects since they want to develop code, but this can be helpful down the line. I would say if there is something you like differently down the road then this pattern will be very helpful. It does not need to be specifically about completely changing fields and you entire lifestyle till then. It can also be related fields in computer science and the direction you want to take. Let’s say you were a software developer for many years, but there comes a time where you are more interested in the big data field and want to make a switch. You feel it will be more beneficial to your life so whatever the reason be, you can still hold on to the principle as a full time coder and applying to the other field. In this way a lot of things are connected and it will be helpful to manage change. The main thing I would say in life is to be comfortable with the idea that you may not be familiar with the change at the moment but you have to trust the path you will take to find those solutions.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.