Category Archives: Week 11

Remote Work

     Ever since the pandemic, the modern workplace has gone through many shifts. The realization that workers can still be effective members of the company from their home has changed a lot of people’s perspective on the corporate work environment. Many workers have pushed for remote work to become a staple of the modern job market. It is easy to see the appeal of remote work: No commute, stuffy office, or even stuffier dress code sounds very appealing to me. I personally enjoy the ease of access to one’s job right in their own home. All of that said, the infrastructure for remote work has been in the works for longer than we realized that there was a need for it. In the modern era, cloud computing has become a necessity for almost any job regardless of whether it is remote or not. Services such as AWS, Azure, and Git hub/lab has supplemented developers with the tools to contribute to their workplace from anywhere on the globe. Now teams can be comprised of any developer within the company and can pull from about any talent pool. This comes with its own set of unique challenges though, as remote work moves developers from a singular office space to their respective homes. Balancing time zones, long-distance communication between team members, increased risk to cybersecurity and more come with the territory of all your developers working from their house. Fortunately, Cloud computing answers some of these problems by providing more security and reliability to development teams. Azure and AWS provide secure repositories for teams and reliable access to their work wherever they are. Then there are Applications such as Zoom, which provides communication between team members and can even facilitate daily scrum meetings if needed. Developers have been using git for a long time, and it has served to supplement collaboration in software development. While the pandemic is over and most companies have tried to push their employees to go back to the office, remote work has become a fixture in the modern work landscape. For some companies, it is an economic option since it is cheaper to subscribe to several cloud services than to rent an entire office space. For other companies, it is simply the efficient option. I believe companies should incorporate these innovative technologies to expand their reach, and to shift society further down the path of better work life balance. The past few years have shown us that the old nine–to–five has become outdated, and possibly unsustainable.  

https://socpub.com/articles/how-can-cloud-computing-enable-remote-teams-work-more-productively-17895

https://aws.amazon.com/application-hosting/benefits/

https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-azure

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Remote Work

     Ever since the pandemic, the modern workplace has gone through many shifts. The realization that workers can still be effective members of the company from their home has changed a lot of people’s perspective on the corporate work environment. Many workers have pushed for remote work to become a staple of the modern job market. It is easy to see the appeal of remote work: No commute, stuffy office, or even stuffier dress code sounds very appealing to me. I personally enjoy the ease of access to one’s job right in their own home. All of that said, the infrastructure for remote work has been in the works for longer than we realized that there was a need for it. In the modern era, cloud computing has become a necessity for almost any job regardless of whether it is remote or not. Services such as AWS, Azure, and Git hub/lab has supplemented developers with the tools to contribute to their workplace from anywhere on the globe. Now teams can be comprised of any developer within the company and can pull from about any talent pool. This comes with its own set of unique challenges though, as remote work moves developers from a singular office space to their respective homes. Balancing time zones, long-distance communication between team members, increased risk to cybersecurity and more come with the territory of all your developers working from their house. Fortunately, Cloud computing answers some of these problems by providing more security and reliability to development teams. Azure and AWS provide secure repositories for teams and reliable access to their work wherever they are. Then there are Applications such as Zoom, which provides communication between team members and can even facilitate daily scrum meetings if needed. Developers have been using git for a long time, and it has served to supplement collaboration in software development. While the pandemic is over and most companies have tried to push their employees to go back to the office, remote work has become a fixture in the modern work landscape. For some companies, it is an economic option since it is cheaper to subscribe to several cloud services than to rent an entire office space. For other companies, it is simply the efficient option. I believe companies should incorporate these innovative technologies to expand their reach, and to shift society further down the path of better work life balance. The past few years have shown us that the old nine–to–five has become outdated, and possibly unsustainable.  

https://socpub.com/articles/how-can-cloud-computing-enable-remote-teams-work-more-productively-17895

https://aws.amazon.com/application-hosting/benefits/

https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-azure

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Managing your Licenses

When it comes to sharing your work publicly, there are certain things you have to do in order to protect it, and you. Whether the work is a form of art, product, or even code, you have to put a license on it. The creator can put software licenses on their code to allow users to use it in certain ways, according to the license agreement. 

Software licenses are categorized into types, which are ranked from least restrictive to most restrictive. The least is the public domain license, which has no restrictions on your code, meaning anyone can do anything with it. Next is the permissive license, similar to the public domain one, except it has some restrictions on how users can use, modify and redistribute the code. The next one is the copyleft license, which also has restrictions on how to use, modify and redistribute the code, but it also states users must distribute the source code with it. The most restrictive is the proprietary license, which only allows users to use the code if they agree to an agreement, and does not allow them to modify or redistribute the code. Under each of these types, there are licenses that have their own extra requirements, so it is important to look at each one to determine which is a good fit for your code.

In this blog post, Ibrahim Ogunbiyi gives us 7 practices that can help with license management. Step one is documenting your procurement process, document where you purchased software, who did it, when, and other important details. Having documentation on software purchases is important for when you need to look back for information. Step 2, having a central list of all software licenses. If there are multiple departments in your organization, having a central list containing all software licenses is good to have. Step 3, understanding all software license agreements, reading through and understanding the agreements. Step 4, implementing a software license management tool. Having a tool to manage your licenses, tracking use, and optimizing use is really nice to have. This can also knock out step 5, regularly tracking license use, and step 6, keeping licenses accurate and up to date. The tool can do that for you, but sometimes, doing it yourself is nice. Step 7 is training employees about license management, which is important for an organization. Having everyone follow the same methods of management promotes uniformity, which makes things easier.

Although I may not belong to an organization that purchases software, I feel knowing these steps is good. Software licenses, or licenses in general, are scary and confusing. It’s not something you are taught in school, so having learned it in class was nice. I can’t quite relate to this just yet, but it is important to know management tips so that when the time comes, I will be ready. In the future, I know I will be coming back to refresh my mind on it.

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

choosing the right software development mythology: Agile, or Waterfall?

Whether you’re embarking on a new project or contemplating a shift in your development approach, deciding between Agile and Waterfall methodologies can be challenging. Selecting the right approach is crucial for the successful development of your project. In this blog, we will analyze the specifics of Agile and Waterfall methodologies to help you make an informed decision tailored to your project’s needs.

Understanding Agile

Ever wondered about the magic behind Agile Software Development? I have recently come across a blog on Agile development by Martin Fowler, a British software developer, author, and international public speaker on software development, who specializes in object-oriented analysis and design, UML, patterns, and agile software development methodologies, including extreme programming. The blog “Agile Software Guide” by Mr. Fowler takes you on a journey through its beginnings and the core ideas that makes Agile work. Written by someone who was there from the start, this blog unravels the secrets of Agile development. The author shares early memories of Extreme Programming and co-authoring the Manifesto for Agile Software Development that sets the stage for an insightful tour through the world of Agile, coming from a credible source who has seen it from its beginnings. The blog dives into the key concepts of Agile thinking, emphasizing how it differs from traditional software engineering. It breaks it down into two main points: being adaptable instead of sticking to plans, and focusing on people rather than processes. A simple breakdown that makes the essence of Agile clear. Mr. Fowler also talks about Agile plans being like a flexible baseline, changing as the project progresses. Unlike traditional plans that demand sticking to a set path, Agile plans are adjusted based on what’s happening. Success in Agile is all about the value the software brings, not just following a rigid plan. However, with all its advantages, the blog doesn’t pretend Agile is perfect. It talks about the challenges, like some practices being called “Agile” when they really aren’t. This honesty adds a dose of reality, reminding everyone to keep an eye on how Agile is actually being used. Agile methodology is often praised for its customer-centric, and flexible approach to software development. In Agile, projects are divided into small increments with minimal planning, and teams work in short cycles, known as iterations or sprints. The methodology emphasizes collaboration, customer feedback, and the flexibility to adapt to changing requirements in which results in continuous delivery of functional software, close collaboration between cross-functional teams, stakeholders, and the customers.

understanding Waterfall

Unlike Agile, the Waterfall methodology follows a linear and step-by-step approach. the project is divided into distinct stages where each stage build’s upon the previous one. The development process flows steadily downwards similar to an actual waterfall, through stages like requirements, design, implementation, testing, deployment, and maintenance. Each stage must be completed before the next one begins, and changes are discouraged once a phase is underway.

How to choose the right methodology? 

The choice depends on several factors, such as project requirements, team expertise, and customer involvement in your development process. If project requirements are clearly defined from the beginning, and changes won’t be necessary during the development process, then the Waterfall methodology could be the right choice for you. However, I personally believe that Agile methodology is usually the right choice for most projects.

In today’s world of constant change, adaptability is crucial in any developmental process. Additionally, based on my experience in various customer service jobs, I’ve realized that customers often don’t know exactly what they want. Therefore, having the ability to adapt if the customers’ needs changes’ slightly is incredibly important.

Agile Software Development: A Concise Overview. (2023). Retrieved from https://martinfowler.com/agile.html

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

software testing

I’ve been coding since around 2017, when I took my first Computer Science course in high school. Since then, I’ve worked on plenty of school projects and a couple of personal projects as well. Software testing had never been a thing I really bothered with meaningfully in this timespan, which is kind of fair considering that most of these projects and assignments weren’t really too complex. I would just print out results for each bit of code as I went along to make sure that the code I just wrote actually works, but I didn’t really go and write actual automated tests.

This semester, I had some exposure to standardized software testing when I worked on a homework assignment in my Software Design and Construction course that required me to adjust some code along with the tests that make sure the code works as intended with intended output. At first, I was sort of confused considering I had never worked with test files, but I appreciated the streamlined nature of this testing. We also had to read up on some software testing methods for a Scrum developer homework assignment we did for this class, Software Process Management.

Today, I wanted to research some software testing basics, and came across a post on IBM’s blog. The post goes over some reasons to software test (the importance of quality control for businesses, what testing even is, etc.) along with types of software tests and practices.

The different types of software tests are fairly easy to understand, and I’ve come across all of them in some capacity before. Acceptance tests ensure the system as a whole functions as intended, integration tests ensure that software components work as intended, and unit tests ensure the smallest testable snippets work as intended. Performance tests evaluate how well software works on different hardware, and stress tests check how much load the software can take without breaking. Regression tests see if new features harm the software at large, and usability tests evaluate how effective the software is for end-users.

Some good testing practices listed in the article are continuous testing, bug tracking, and service virtualization. Continuous testing is the practice of testing each build as soon as it’s available, fairly simple. Bug tracking is, well, bug tracking. The post mentions automated monitoring tools for tracking defects, but I sort of think of this in the sense of keeping an issues list on a git repository, as that’s what I’m more familiar with. Service virtualization is a little more complicated, it simulates functionality that hasn’t been implemented yet to reduce dependencies and test sooner.

What I’m mostly interested in is the applications of these practices, and I’ll likely look into it further at a later time. I understand these concepts fairly well, but the idea of automating tests, at least at my current understanding of it, sounds a bit daunting. I’m sure it saves a lot of time on larger-scale projects, where testing each piece of your code manually for multiple cases will take a lot of time. I’m interested to see what this looks like in an example.

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

anti-patterns

During our Software Construction, Design and Architecture class, we’ve gone over a multitude of different design techniques, patterns and tools to ensure that we write quality code. We’ve also touched on some design / code smells and the concept of technical debt. While design smells can give you an indication of something that might be wrong with your code, whether in a small section or in the overall design, anti-patterns represent a much more obvious, prevalent problem in your code.

Some of the most common examples of anti-patterns I’ve heard in conversations I’ve had with my friends, classmates and even teachers in a joking matter, like spaghetti code, and copying and pasting code snippets from random repos (which isn’t just bad practice for coding, it’d also be possible to infringe upon licenses or the lack thereof placed on that code). I think the reason why these are fairly common among the circles I’ve been in is just because everyone has done it before for a school assignment or something, and it’s just funny to joke about.

Some anti-patterns are a bit more involved with designing software in a meaningful sense, though. In a blog post from Lucidchart, some other anti-patterns found in software development and design are golden hammers, god objects, boat anchors and dead code. What’s interesting about these is that they actually are actual manifestations of design smells, in the most obvious ways.

For example, a boat anchor is a piece of code that isn’t being used yet but might be used in a future version, maybe. This results in needless complexity, an addition that isn’t necessary and makes it harder to read your code. Dead code is similar, code that gets executed but isn’t even used in the output of a program, causing immobility. Using a golden hammer means you are using the same tool for a bunch of different jobs, thinking that it is the best tool for all cases. This contributes to fragility, needless repetition and opacity depending on the implementation one goes about with a golden hammer. God objects are similar in a sense, as they’re objects that do too much and are responsible for too many functions. This violates encapsulation principles that are good practice in software design, while also resulting in immobility, viscosity and possibly even more. Dead code

This reinforces the idea of checking for code smells and refactoring code as needed, because otherwise you will build upon a foundation that was fundamentally problematic, and the rest of your code will reflect it no matter how much better it is. This all ties into technical debt, and brings all of the software design principles, concepts and ideas together into a picture that says: please maintain your code cleanly!

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

The Art of Future-Ready REST API Design

Best practices for REST API design: https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

In today’s digital landscape, REST APIs play a pivotal role in facilitating seamless communication between various clients and services. However, designing these APIs requires careful consideration of factors such as security, performance, and ease of use for consumers. In this blog post, we will delve into the key best practices for designing REST APIs that are not only easy to understand but also future-proof and secure.

Summary: The selected resource outlines essential guidelines for designing REST APIs. It covers crucial aspects like choosing the right data format (JSON), using nouns instead of verbs in endpoint paths, logical nesting for hierarchical objects, handling errors gracefully with standard error codes, and implementing features such as filtering, sorting, and pagination. The article also emphasizes the importance of maintaining good security practices, caching data for improved performance, and versioning APIs to manage changes effectively.

Reason for Selection: This resource was chosen because it directly aligns with the course material, providing a comprehensive guide to REST API design principles. The clarity of the content and its relevance to common challenges in API development makes it a valuable reference for anyone involved in creating robust APIs.

Comments on Content: The guidelines presented in the resource offer practical insights into building effective REST APIs. The emphasis on using JSON for data exchange aligns with industry standards, ensuring compatibility across various technologies. The recommendation to avoid verbs in endpoint paths simplifies API readability and adheres to the RESTful principles of using HTTP methods for actions. The article’s discussion on error handling and status codes enhances the overall robustness of API implementations.

Personal Reflection: As a developer, this resource reinforced the importance of consistency and adherence to best practices in API design. The concept of logical nesting for related resources provides a structured approach that can enhance both API usability and maintainability. Learning about caching strategies and the significance of versioning in API development has broadened my understanding of how to address performance and compatibility concerns in real-world scenarios.

Application in Future Practice: The insights gained from this resource will significantly influence my future API development projects. I plan to implement the recommended practices, especially in areas like error handling, security, and versioning. Additionally, the emphasis on caching strategies will be integrated to optimize data retrieval and enhance the overall performance of the APIs I develop.

In conclusion, the resource serves as a valuable guide for both beginners and experienced developers, offering practical tips for designing REST APIs that stand the test of time. By incorporating these best practices, developers can create APIs that not only meet current requirements but also adapt seamlessly to future changes in technology and user needs.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

Week 11: CS-343

Software Frameworks

What is a framework?

A framework is a platform providing a foundation for creating software development projects. Frameworks can be thought of as a template of a working program where developers can modify the program by adding code. Because frameworks are essentially templates, there are shared resources that are bundled into one package. Some of these resources include libraries, image files, and reference documents. The package can be customized to match the needs of the project.

Different types of frameworks

Backend Web Frameworks

Backend Web, or also known as simply Web Frameworks, are the most commonly used. These frameworks help developers create web applications and dynamic websites. The use of web frameworks has streamlined the process of web development by automating common tasks of web developers such as database access and session management. Rather than using HTML, JavaScript and CSS, backend frameworks use programming languages to access a database, hosted on a server. A common backend framework is Django.

Frontend

Unlike backend where frameworks are loaded server-side, frontend frameworks are executed in the user’s browser. Frontend frameworks allow developers to customize and design the way the web application looks to the user. Popular frontend frameworks are Angular JS and React.

Mobile Development

Nowadays mobile applications are extremely common resulting in mobile development frameworks. Similarly to desktop frameworks, these give developers a foundation to build their mobile applications while allowing full customizability. There are two types of mobile frameworks, native and cross-platform. Native frameworks are for applications that are built specifically for a particular operating system (iOS or Android). Alternatively cross-platform frameworks are for apps that are built to be compatible with any phone. A commonly used mobile framework is Flutter.

What makes a good framework?

A good framework should be simple to understand and easy to implement. It should also follow design principles such as:

  • Being extendable, adding new functionality by adding code rather than modifying
    • Framework cannot be modified at all, but only extended
  • Allows developers to create components that can be reused
  • Should have a default behavior and be useful. No redundant code that is unnecessary

Why use a framework?

Frameworks greatly reduces the time spent on developing. When starting a new project, there are steps that need to be done regardless the project. Using frameworks helps streamline that process by already providing those details. This allows developers to focus their time on extending the functionality specific to their application’s needs.

Reflection

This article was chosen because it broke down the different parts of a framework such as what it is, the different types, and why one might use a framework. Prior to reading this blog, I had a somewhat unclear understanding of what frameworks are. Now I understand that they are useful tools that speeds up the development process by providing essentially a template of a working program. What was learned will be applied to future, larger projects that could benefit from a framework.

Resources:

https://codeinstitute.net/global/blog/what-is-a-framework/

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

An Accurate Assessment?

There is currently nothing that reigns truer than the “Learn How You Fail” pattern in the Apprenticeship Patterns. Essentially this chapter identifies the role in which failure plays in your career development. I have often heard that failure is not something to be feared but instead embraced and this chapter mirrors that same sentiment. It offers the idea that if someone has not failed then they have actually “avoided pushing the boundaries of their abilities”.

I think this idea heavily resonates with me. I’ve learned that I need to look upon what I am doing with a realistic lens and to be able to recognize the truth in my actions and decisions. The more objectively I can view things the greater the ceiling for growth and further expand the boundaries of my abilities. The chapter puts it as “the goal is to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead you to failure”.

I think that one of the major things that is hampering my success is procrastination.

For a long time, I have been “wallowing in self-pity” from the consequences of my procrastination. There has been a bit of a perspective change as of late that allows me to recognize my strengths through an accurate self-assessment all in an effort to remove the focus on the self-pity and shift it to self-improvement.

I find that from my procrastination I’ve learned how to handle my own self sabotaging self. I have seen that it is something I can improve on as I find myself having instances of being proactive, so I know that it is something that I am capable of overcoming. With consistent effort I can see myself overcoming this barrier to achieve whatever it is I want to achieve. From all my criticization of the education system it wouldn’t be without this system that has allowed me to recognize my strengths and abilities and has enabled me to look upon my weaknesses not as an impossible barrier but as something that I can overcome and climb. On the other hand, even though I can recognize this pattern within myself I learned that nothing is going to be accomplished without a disproportionate amount of time, so that is why it’s going to take consistent effort and not all be accomplished within a day. This kind of self-assessment seems very valuable and is something I actively believe I can improve on and may even somehow adopt as a core value.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Breakable Toys

With the breakable toys pattern, the learner conducts experiments and observes the work of others to improve their own understanding of how to build complex systems. Apprenticeship Patterns suggests a few ways to go about this. You might build a simplification of an existing problem that you’re already facing. By reducing uncontrollable variables or emulating a single possible case, you can come to understand one key interaction, tool, or data flow at a time until you become capable of composing a solution to a broader problem.

Another possibility is building your own projects that are not focused on understanding one specific issue you are already facing. Doing so can build a familiarity with your tools, and can lead to unexpected creativity or interest in learning how others achieved problems you might never have otherwise encountered.

The third variant of this pattern is the analysis of external source code. The abundance of open-source projects provides an effectively infinite learning resource for studying how others design systems and resolve issues.

I think that this pattern is a very important part of long-term learning. It can be easy to build habits when programming: you can usually come to a desirable result either by brute-force trial and error from the bottom up, or by drawn-out requirements planning that gets done before any prototype is built. But I’ve found myself spending far more time invested in one of these two methods than I should have, when remaining flexible and incorporating aspects of the other would have led me to a better solution faster.

In general, I think it’s a shame how often the daily work of software development can feel detached from the playful curiosity of the scientific method. Much of the most rewarding learning happens as a result of developing a question and finding a finding out how you can reach a confident answer to it. Considering we’re working in the one field where rapid iteration and near-zero cost to entry makes the scientific method universally accessible, I’d like to hope I’d take advantage of that by putting myself in many situations that generate spontaneous curiosity.

That’s what I like about making a breakable toy. It’s usually more fun to play with than the projects that we have real responsibility for, and that fun makes us want to understand everything about the toy and how the toy could grow into something else.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.