Category Archives: Week 11

Sprint Retrospective – Sprint 2

I think that we as a team, as well as me as an individual, improved during this sprint compared to the first sprint. While for the first sprint we had no experience working with scrum sprints or in any sort of team development environment, so the whole thing was completely new to us, whereas at least now with the 2nd sprint we had at least a tiny bit of experience. This means that we were able to improve upon some things from our first sprint, because we could see what we did wrong and could change our plan in order to avoid our previous mistakes and optimize our workflow overall.

The first thing we optimized and improved upon was our sprint planning. From our first sprint, we could better judge what we could get done during a sprint by how much we got done during our first sprint. This way we could efficiently work on items, getting as much done as possible during the sprint and not assigning too much during the sprint to the point that we end up not getting most of it done. We could also better assign weight to each of the items because we could better judge how long it would take for us to get each item done, and better judge the importance of each item to the overall project and current objective.

The second thing we optimized and improved upon was our overall communication. We still did most of our communication in class, but we now made sure to communicate through the issues on GitLab. When an issue required additional clarification or explanation, we could leave a comment on an issue and ask the creator of the issue for more details, and the creator could easily respond right on the issue. This not only improved upon the frequency of our communication, but it also helped us to differentiate and easily see what string of communication was pertinent to what issue, helping other team members to see what was discussed respective to what issues. This way, if a team member was working on an issue similar to or previously worked on by another team member, they could easily see what kind of issues that team member faced while working on it, and that could help them work through it without even requiring more help from the team. This makes the workflow as a whole much more efficient because any communication is saved, categorized, and easily searchable.

For the team as a whole, we could still improve upon our communication. Although it is efficient communicating through GitLab issues, and it does have some benefits, it is also good to have some non-official communication that doesn’t directly relate to a particular issue. Leaving this communication on GitLab would be messy, so it would be better if we did this additional communication through discord. For me as an individual, I think I could’ve helped more with the sprint planning, and better assisted my team members. For the spring planning, I could’ve better helped with coming up with weights for issues and assigning them. Finally, I could’ve better helped my teammates by being more active responding to open issues with comments and helping them finish open issues if I’m done with all of my issues.

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

Practice, Practice, Practice…

The authors of the Apprenticeship Patterns book do an amazing job of capturing my attention. The opening quote that the “Practice, practice, practice” pattern starts off with demanded that I pay attention to what comes next.

“People we know as masters don’t devote themselves to their particular skill just to get better at it. The truth is, they love to practice—“

When I read this quote part of me shimmers with hope because of the proper guidance I was just given to help make it in my future, and another part of me frets because practicing can be difficult and I don’t want to struggle or face the hardship of practicing. Now my issue with practice isn’t that it can be difficult, I don’t mind taking on a challenge. My issue with practice is that I don’t want to be practicing but doing it completely wrong and then feel like I have been wasting my time. The way I picture it is like doing a bunch of push ups but the entire time you’ve been doing them your back was “U-shaped”. You don’t know any better until someone comes along and tells you that you’ve been doing it wrong the whole time. Meanwhile you’ve “mastered” the U-shaped push up but in reality there is no such thing. All the arm strength and muscle memory you built to do that unrecognized form of exercise was for naught, and that’s how I feel I might end up when practicing alone. The pattern does recommend practicing in public places, doing “kata” or finding a coding dojo to code amongst others and have these flaws pointed out as you practice. This sounds like something that would cause my nightmare scenario to never happen but there comes this slight embarrassment when thinking about asking for help or making a mistake in front of others… I suppose it’s a small price you pay while getting better. After all, its better than the former scenario. An old manager of mine once said something to me that still sticks with me today “If you ask once, you’ll only feel dumb once. But if you never ask, you’ll feel dumb forever”. Perhaps I should do more than just think about the profound words and apply them.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

YAGNI, or are you?

Surprise, you probably wont. Lets back up a step first though and talk about what that acronym actually means. YAGNI stands for “You Aren’t Gonna Need It” and is an important acronym to consider for software development applications. I heard about YAGNI from our class, and I wanted to know more about what exactly it consists of, and what its purpose is. Thats where I found a good article by scaleyourapp.com, which did a good job explaining it. In its essence, YAGNI means that you shouldn’t create something until its actually necessary for your application. After all why would you want to waste time on things that might not ever be needed. As many people who have written code know, we often write a function/class expecting to need it in the future, only to never actually use it. This in turn leads to wasted space in the program, wasted time writing the unneeded code, and now you have to think about whether you should bother keeping it or just dump it to save space. I have plenty of personal experience with this in my own projects and work. One particular example that comes to mind is that during a 36 hour hackathon last spring, my teammate and I spent many hours trying to figure out a good way to incorporate a login/user tracking system into the app we were writing. While this feature would EVENTUALLY be needed, for the sake of creating a basic proof of concept app it was far from crucial. Because we didn’t use YAGNI principles we wasted time that could have been spent doing any of the other myriad of tasks we had to do for the rest of the app. These several wasted hours resulted in us not being able to add other needed features, and as such the app was not as complete as it could have been given the time constraints. Even before hearing about YAGNI as an idea, that experience left my partner and I with a realization that there are much more efficient ways to approach writing code than what we attempted. Since then I have been much better about not writing useless code until its needed; however I still have instances where I create a function or class that realistically doesnt need to exist. It can be difficult sometimes to figure out what is needed and what isnt, especially at the beginning of a project. I always assume I am going to need one feature or another, so I begin write it; only to find out a little while later that its not really that important at the moment. While I still started writing it, I have gotten better at stopping before I go too far and waste too much time. That way I can spend more time and energy focusing on more important aspects of the program I am writing.

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

More On APIs

This week I decided to dive more into APIs in general, not just RESTFUL APIs. So let us start at the beginning. API stands for Application Programming Interface, and it is an interface with a set(s) of functions. These functions allow programmers to use specific features or data of an application. A web API is an API that is accessed over the web, like through the HTTP protocol. The web API is a framework that assists in creating and developing HTTP based services.

An API usually works as follows, the client application initiates an API call, usually to retrieve information. This call is also known as a request. This request is then processed from the application to a web server using the API’s Uniform Resource Identifier, and usually has a request verb, like GET or POST, for example, headers, and a request body. After receiving a valid request from the application, the API makes a call to the web server. The server then responds to the API with the requested information, and the API then transfers the data to the initial requesting application.

APIs are often used for many reasons. This includes, but is not limited to, improving collaboration, offering easier innovation, data monetization (as money makes the world go round), and added security. APIs enable integration such that platforms and other applications can easily communicate with each other, allowing easier automation, therefore improving collaboration. They also offer flexibility, allowing connections to new businesses and reaching new markets, offering easier innovation. APIs are also often offered for free, usually initially, to allow the developers audience to grow so they can build relationships with their audience of developers around their brand for the future, securing future business partners, thus offering data monetization. Lastly, APIs create an added layer of security between your data and a server. Developers can also choose to add further security measures like tokens, signatures, and Transport Layer Security encryption, just to name a few.

There are also many types of APIs, some of which include, but are not limited to, SOAP, or Simple Object Access Protocol, XML-RPC, which is a protocol that relies on XML to transfer data, JSON-RPC, which uses JSON instead of XML for its work, and REST, which we have covered in prior weeks blog posts.

Source:

IBM

I decided to use the above source for this weeks blog post because they provided a ton of good information about APIs in general, and IBM is also a very well known company and therefore also a good reputable information source.

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

Visual Code: Docker Extension

We have used visual studio code and docker extensively in our software design learning process. Even though it wasn’t made necessary for us to get the docker extension, I have been using the docker extension for a while now. Since docker is one of the biggest open source platform providing virtual containers, I wanted to further explore what benefits would an extension bring to visual studio code. For this I am focusing on blogpost under microsoft by Mike Morton.

Using the extension, we can easily add docker files through command palette and using Docker: Add Docker Files to Workspace command. This generates ‘Dockerfile’ and ‘.dockerignore’ files and adds them directly to our workspace. The command also gives us an option to add Docker Compose files. Extension provides option to build docker file in more than ten most popular development languages and then we can set up one-click debugging of Node.js, Python, and .NET Core inside a container.

Extension has docker commands to manage to manage images, networks, volumes, image registries, and Docker Compose built right into the command palette. So, we no longer must go to the terminal and meticulously type $ docker system prune -a or search IDs of specific container we want to stop, start, remove, etc.

Moreover, the extension lets us customize many of the commands. For example, when you run an image, you can now have the extension put the resulting container on a specific network.

Docker Explorer, another feature of extension, lets us examine and manage Docker containers, images, volumes, networks, and container registries. We can use the context menu to hide/show them on explorer panel.

The best feature is extension’s ability to select multiple containers or images and execute commands on the selected items. For example, we can select ‘nginx’ and ‘mongodb’ container and stop or start them at the same time without affecting other containers and without having to run start or stop command twice. Similarly, we can run or remove multiple images of our choice. Moreover, when running start command through command palette, we can see list of all the containers that can be started with a checkbox next to each.

When we are working on say Libre Food pantry microservices and have multiple development containers running – running commands through command palette is going to be quick and concise, explorer will give us a very simplified and organized way to manage docker assets and executing run/stop commands for multiple containers at the same time will be an extreme time saver. All these features combined are going to increase development productivity exponentially.

Source: https://devblogs.microsoft.com/visualstudio/visual-studio-code-docker-extension-1-0-better-than-ever/

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Frontend vs. Backend

This week will be continued talk on APIs and specifically I wanted to learn more about the structure of our API’s including on the differences between frontend and backend and any extra information on API’s that can be included. I have chosen a website that goes over what exactly these are and gives a good amount of information that could be useful later down in our careers.

In summary, frontend and backend are two very popular terms in web development. The term frontend is usually used for the part of the website that the user directly interacts with like the GUI’s. This is also called the “client side” of the application and use languages that should sound familiar to you such as HTML, CSS, and JavaScript with JavaScript being the most popular language of them all. This is because of several advantages such as flexibility, speed, and extended functionality although it does have some disadvantages in areas such as with debugging. Now if the frontend is what the user interacts with, the the backend should be everything that is kept out of sight from the user such as work with the databases, the scripting, and the API itself while making sure it can connect to the frontend. The languages used include python, PHP, and java all being widely used. The work on the frontend and backend has also become quite specialized over the years in which it is usual for one person to either work with just the frontend or just the backend and people who work on both are called full stack developers.

This resource has given me insight on the work we are doing with the API’s and with the work we are doing on the backend. The work that we are doing with the databases and the API’s is an entirely different area from the frontend that we haven’t even touched yet. The areas that have to be learned are numerous that require different sets of skills and talents to work in. It makes me wonder on whether we will get to work with the frontend in this class or in a future class. The I should prepare myself a bit more if one would want to become a full stack web developer seeing the needed skills in both ends. Although I haven’t done much work on any frontend material so I would have to wait to see on what the experience is like when working on the frontend on deciding if I should focus on one or another in the future.

Source:https://www.interviewbit.com/blog/difference-between-frontend-and-backend/

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

Front end/Back end: Difference

The front end of a website or application refers to the visual elements that users see and interact with. Front-end development, therefore, refers to the programming and management of the front end of a website or application to provide users with a rich interactive experience. They need to create a website’s entire interface and user experience, as well as its design and overall look. They usually work with HTML, JavaScript, and CSS languages to create a basic layout of the website and then add various visual elements to improve its esthetic quality.

Some performed tasks for a front-end developer include:

  1. Creating rough concepts and using HTML, CSS, and JavaScript to materialize them.
  2. Adapting a website’s design to look and function properly on mobile devices
  3. Optimizing the user’s experience on a website and making sure it’s not interrupted by any design or functionality issues.
  4. Developing an easy-to-use and intuitive user interface and gradually improving it based on user feedback
  5. Constantly testing the website’s front end for ease of use and potential errors and optimizing it to ensure a smoother user experience
  6. etc…

Back-end development refers to creating and ensuring the well-running of a website’s internal operations, which are hosted by a server. A website’s back-end is its server, application, and database, so a back-end developer focuses on setting up and maintaining databases, scripts, and the overall website architecture. 

The tasks of a back end developer include:

  1. Understanding what the website’s main objectives are and finding various ways to facilitate them
  2. Making sure that data is properly stored and that users who want to access it can do so quickly and easily
  3. Managing application programming interfaces and making sure they work across devices
  4. Organizing a website system’s logic and optimizing it to run properly on multiple devices
  5. Creating website architecture that can easily be modified with future upgrades
  6. etc…

What are some differences between front end and back end development:

  1. The front end refers to the graphical user interface required for navigating a website, including its overall layout, videos, images, text, buttons and every other visual element, whereas the back end solely refers to the way the website should function.
  2. Back-end development typically focuses on the application of logic to solve various functionality and user experience issues, while front-end development focuses on making the website look good and provide a positive user experience.
  3. Front-end development collects user input, while back-end development processes user inputs.
  4. Issues like search engine optimization and user accessibility are handled by front-end developers, while those related to the website’s security and backup are the responsibility of back-end developers.

I chose this topic because I was curious to learn more about the front end and back end and their importance in software development. Being a computer science major, and doing both concentrations, this is important information I need to know to be a good programmer. and develop my computer skills

Back-End vs. Front-End vs. Full-Stack Development: What’s the Difference? | Indeed.comWhat are front end and back end? Definition from WhatIs.com (techtarget.com)

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Anestiblog #5

This week I read a blog post that I thought really related to the class about agile software development. The blog is about the phases of the agile software development lifecycle. The blog starts off explaining Agile and why it is used. It is being used because of its flexible, iterative, and incremental character. The blog then goes into the phases, and some agile techniques and tools. The phases are requirements, design, development and coding, integration and testing, implementation and deployment, and finally review. Some of the tools and techniques are spiral SDLC, and waterfall SDLC. The blog then goes into the pros and cons of agile software development. A pro is that there are flexible working hours around the clock, and a con is that all communication takes place on the internet, so it might be harder to connect with fellow developers. The blog ends by summarizing the cycle of agile software development, and describing it as aiming to build and deliver flawless working software on a tight schedule.

I selected this blog post because software development is my dream job, and I thought it would be interesting to read about a possible way I might be working using the agile method. This blog has a great way of showing how agile software development works, and how useful it could be, and I think every CS major should read it since we have to take another class similar to the things in this blog with software process management.

 I think this blog was a great read that I recommend for many reasons. One reason I would recommend this blog is because of how deep it goes into explaining the cycles of agile software development . The blog gives a description for every phase, and explains what to do at every phase, what others are going to do while you are on that phase, and what tools to use when you are on the phase. Another reason I would recommend this blog is because a lot of jobs that we will be looking for in the future will be using the agile method, and if we are not good at using it, then we are at a disadvantage to be hired. The last reason I would recommend this blog is because it is focused on teamwork, and teamwork is important for every job, and not just computer science related jobs. Agile could be used anywhere. 

This blog taught me about all the phases, and that if they are all done correctly by a team of developers, they could really work productively as a cohesive unit. The material affected me heavily because it showed me what skills to learn, and what to expect if I want my future dream of software development to come true as many jobs might be using the agile method, so I must be prepared. Now that I know about the agile software development method, I will try to look for more different methods.

link: https://relevant.software/blog/agile-software-development-lifecycle-phases-explained/#Output

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

Unified Modeling Language (UML): Class Diagram Relationships

The Unified Modeling Language (UML) is a standard for diagramming the design of a computer program. UML class diagrams illustrate the classes and relationships of an object-oriented program. The five fundamental class relationships are dependency, aggregation, composition, inheritance, and realization. When my professor introduced UML, he provided instruction on inheritance and realization. Because an understanding of the five relationships is essential to reading and building UML class diagrams, the goal of this post is to familiarize myself with dependency, aggregation, and composition as well as their applications. To achieve the goal, I will be reflecting and adding to the blog, “Association vs. Dependency vs. Aggregation vs. Composition,” written by Niraj Bhatt, an enterprise architect at Advent eModal. In the post, Bhatt defines and applies the relationships.

Dependency is a relationship between two classes where one class uses the object of another class as a parameter of a method. One can represent it by drawing a dotted arrow from the user class to the class being used. Bhatt exemplifies the relationship in a program that simulates a turn-based game. The program acquires a Player class with a TakeTurn method that expects a Die object. Bhatt’s example is effective because, in many turn-based games, a player uses a die during his or her turn.

Aggregation is a relationship between two classes where one class owns the object of another class as an attribute. If an instance of the owner class ceases to exist, the object of the other class would still exist. One can represent it by drawing a line with a hollow diamond from the owner class to the class being owned. Because Bhatt exemplifies the relationship in an unfamiliar type of game, I will be providing another example. Another application of the relationship is in a course management system where the Course class owns Student objects. The application is effective because students will exist when courses do not.

Composition is a relationship between two classes where one class needs to have an object of another class as an attribute. If an instance of the former ceases to exist, the object of the latter class would cease to exist too. One can represent it by drawing a line with a filled diamond from the owner class to the class being owned. Because Bhatt exemplifies the relationship in an unfamiliar type of game, I will be providing another example. An application of the relationship is in an online shopping system where the Customer class has Order objects. The application is effective because orders would not exist without customers.

If I continue to pursue a career as a software engineer, my newfound understanding of class relationships will help me carry out my responsibilities. Many companies use UML to illustrate their software systems. I may need to apply the relationships to blueprint software or understand them in existing software to implement new features.


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.

Two sides of web development coin

Frontend

A front-end developer takes the mockup of a website that a web designer has made and converts it into a functioning web solution that users can interact with. To do this, the developer divides the mockup into individual web components, such as buttons, sliders, photos, menus, forms, and so on, and then uses JavaScript to give these pieces specific behavior. Frontend developers achieve this split into discrete web page components using a variety of methods, with HTML: A Web Page’s Skeleton. Hypertext Markup Language is the abbreviation for HTML. It offers the framework for a website. To give a web page a certain structure, HTML includes several element identifiers called tags. Every web element has its own tag and place on the page. CSS: The flesh and blood of the web page. CSS is a technology that enables frontend developers to describe the style of each web page component using certain properties organized into rules. JavaScript is the most popular. This is one distinction between a front-end and back-end developer, each of whom works with a separate technological stack.

Backend

The engine of a website is the back end. On a site with simply a front end, click the Submit button under a form. Nothing is going to happen. Your website won’t be able to add new users or dynamically update content. The back end of a website comprises three important components. A database is a collection of data tables that are linked. Backend developers use a variety of database management systems (DBMS) to handle databases (Database Management Systems). MySQL and Oracle are two examples. The database is stored on a server, which is a computer. A web server is a particular program that operates on a physical server that sends data from a database and receives requests from a website. Apache HTTP Server is one example. The primary goal of a backend developer is to guarantee that the data flow is seamless and error free.

Conclusion

Web development is a multi-faceted process with a lot of activity components. While web developers have a variety of responsibilities, we may divide them into two groups. Frontend developers are in charge of the user-facing aspect of a web application. Backend developers, on the other hand, work with the hidden component of the system, which includes a database and a server. These two large teams collaborate to build aesthetically appealing and engaging websites and online apps.

Why this topic?

In my mind, the distinction between frontend and backend was hazy. I was aware of them, but I had the impression that if someone asked me what the difference between frontend and backend was, I would be unable to respond. So far, the best way to explain the distinction between frontend and backend is to use an automobile as an example. The frontend of an automobile should be created and shaped attractively, but without the engine, the car is meaningless. The engine, on the other hand, is the backend that brings all of the beautiful designs and colors to life on the road.

Link: https://www.psd2html.com/blog/a-frontend-vs-backend-developer-two-sides-of-the-web-development-coin.html

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.