Category Archives: CS@Worcester Blog

Week 7 blog

HI everyone, welcome back to my blog. In this post, I will be talking about two patterns from the apprenticeship patterns book that was provided to us in the beginning of the semester. We will be going to go more in depth about how you should reflect as you work and how to record as you work, which I think goes hand in hand in my opinion. First, let’s talk about recording what you learn. There is this saying that my dad always used to tell me was that those who don’t learn from their mistakes are the ones doomed to repeat it. There are a lot of things that you can do to help you with that. For example, you can start recording your journey of what worked and what doesn’t in a sort of blog or personal journal. I know some people who write those things down and never go back and read them ever, what’s the point? Don’t just write it down, try to think about it and review it later, just to freshen up. You never know, you might discover something new or old that will help you and will help you avoid making the same mistakes again. I personally do not write anything down and I have a terrible memory, so I should probably start writing things down, and it will help me get better by giving myself something to look forward to and learn from.

The second pattern I want to go over is the ability to reflect as you work. Ask yourself questions, like how did I get here or how can I improve? It doesn’t have to be questions about yourself, you can say how can we improve as a team? This will make you observe and reflect on things about yourself and the environment around you. I believe that this goes hand in hand with the first pattern because you can observe yourself and ask questions regularly and then write the conclusion down of what you have learned from this experience. Personally, I will start my own daily private journal so I can be constructive with myself and honest to try and improve my everyday life.

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

Sprint Retrospective Blog #1

Hi everyone, my name is Abdullah Farouk, for those who didn’t know, and this is going to be my first sprint retrospective of the semester. First, I will start out by saying, considering this whole thing is brand new to us, we did a great job working with this new style and adapted quickly to all the changes. Don’t get me wrong, there is still a lot of room for improvement from everyone in the team, but we successfully passed through the first sprint. This sprint consisted of us getting familiar with libre food pantry more and to see how this scrum framework actually go. The first thing we did in the beginning of the semester was weighing the different issues and breaking some epics into smaller issues and assigning it to our team. We then organized the issues on which one we wanted to do first and so on. I worked on most of the issues during class time, which worked out nicely because I had my teammates there to help me with things just in case, I got stuck, which I did sometimes. I liked meeting in person instead of virtual meetings, as I think we do more work when we see each other instead of behind a computer screen.

One thing that I would say didn’t work out well was how we weighed the issues in the beginning. Some of the issues took less than what we had anticipated, and some took way longer, to the point that we finished only half of the last issue left for the sprint and therefor had to leave the issue to next sprint. Another thing that we were struggling with was communicating outside of class time. I take some of the blame myself as I do not have discord installed on my phone and therefore, I only check it at night time or when I get home from work. Some of the issues we had made, we didn’t add a description to it, so it was a little harder for me to figure out what they want me to do just from the title, so I had to ask classmate to double check.

Other than those minor issues, I think me, and the team did a great job going through these issues and completing them on a timely basis. To improve as an individual, I will try to check discord more often to communicate better with my team. To improve as a team, I think we should start adding a description of the issue under the title just so we don’t get confused and be more organized I would say.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/issues/33

  • Moved “commands” to “bin” and added a cspell folder to make sure the spelling are right. Merged and pushed the issue.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/issues/32

  • I sat up to work with VS code in Gitpod rather than devcontainer which was a little bit tricky because I didn’t know what gitpod was until that moment.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/27

  • Me and one other classmate looked at the check inventory frontend and examined the code to see what it was missing and what it could get better at.

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

week 5 blog

Individual apprenticeship pattern blog post- Use your title.

Hi all and welcome to my blog where today I will be talking about the pattern “Use your title.” This pattern caught my attention for several reasons that I will go through in this blog post in detail. First, let’s start by explaining the pattern itself and give a little context of where the title comes from. Let’s say you work at a job and they give you a certain title, like “assistant pharmacist”. Some time later they will want to promote you. The title of your position will change but you are still going to get paid the same amount. For example, I was known as “CAD assistant designer” for a little bit in the beginning of my job. I worked hard for like 3 years, then I got “promoted” to “CAD designer” which means I am no longer an assistant designer. My responsibilities changed with it. The pay might be the same but others in the office, or even outside the office, will respect you more because of that title. My responsibilities are much different now.

If the Job title doesn’t match the description of what you see yourself doing, then there are things that you can do to change that. It stated the job description is a distraction and should be kept on the outskirts of your consciousness, but I don’t think I agree with that. For me, a job title is something that you should be proud of. If I am not proud of my job title, that just gives me more fire to try and work harder to get the job title I deserve. To solve this problem, you should write down a description of your job title and make sure it fits the work you do in the office and try to give details as if a stranger is reading your job description. Sometimes your job title does reflect the work you do, you could be indicated into a position of authority on your team but it doesn’t state that in the job description which is fine as long as everyone respects you and sees the work you are putting in.

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

Apprenticeship Patterns Intro

Dave’s Story

The narrative of Dave’s journey serves as an illustrative example of how apprenticeship patterns can contribute to personal growth in software development. It emphasizes the importance of mentors, the willingness to expose ignorance, and the value of continuous learning and experimentation. Dave’s story underlines the idea that apprenticeship is a dynamic and evolving process, shaped by experiences, challenges, and the pursuit of improvement.

What Is Software Craftsmanship?

It critiques existing definitions of software craftsmanship, drawing inspiration from medieval craft models. While it rejects a rigid hierarchical structure but advocates for a modern craft studio where practitioners are free to innovate. The author also emphasizes the need for a community united by shared values, such as a growth mindset, adaptability, pragmatism, openness to sharing knowledge, and dedication to self-improvement.

Roles in Software Craftsmanship

The passage outlines three key roles in software craftsmanship: apprentice, journeyman, and master. Apprentices focus on personal growth, learning, and building foundational skills. Journeymen expand their responsibilities to include communication, mentoring, and portfolio building. Masters not only excel in their craft but also contribute to the industry’s advancement, mentoring others and creating tools or techniques that elevate the entire community.

What Is Apprenticeship?

The concept of apprenticeship is explored as a way for individuals to learn about professional software development. It is portrayed as a mindset, acknowledging that not everyone has the luxury of a formal apprenticeship and that many must create their own learning opportunities in less-than-ideal situations. The text encourages individuals to recognize their position at the beginning of their career and actively seek opportunities for learning and growth.

What Is an Apprenticeship Pattern?

The authors introduce apprenticeship patterns as guidance for career progression in software development. These patterns, extracted from personal experiences and practitioner interviews, offer flexible solutions to common challenges. The book is structured as a pattern language, allowing readers to choose, combine, and adapt patterns based on their unique circumstances.

Reflection

Through the reading felt very connected to Chapater 6 which focused on the
Idea that there is so much to learn but only one of you. I often find myself overwhelmed trying to learn as much as possible just to be versatile. Whether that be multiple languages, IDEs, frameworks, or anything in between. I finally was able to take some time to create a roadmap that I could follow that would better help me achieve my end goal of becoming a full-stack developer. This map focuses more on understanding over forcing content down someone’s throat and allowing the user time to properly learn and experience the tools needed to reach my goal.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Hi, my name is Abdullah Farouk and this will be my first blog of the semester and it is based on the readings from chapter 1 and the introductions of chapters two through six.

I did not know what apprenticeship actually means until after reading these chapters. From what I understand, It is basically learning from more “experienced” coders on how to be a better developer. Dave’s story was pretty cool and awesome to read as it gives me more motivation and I can see how good it is to get some help sometimes. From the three stages he provided for us in a developer’s career, I think most people are stuck between an apprentice and a journeyman with very few people in the masters category. An apprentice is someone who still has a lot to learn and wants to improve their way of doing things. I believe I am at this level right now because I still have some areas in my field that I need to upgrade or work on with my team or the professor. This gave me extra motivation because I want to be in the journeyman stage, at the very least by the end of this semester. Our professor would be in the “masters” category because he is very advanced in his area, performs the roles of a journeyman and is focused on moving the industry forward by teaching us and advancing the Worcester state pantry website. I do agree with these roles but I do think that there should be another category because there is a lot of difference between a journeyman and a master and that gap should be filled and made its own category. I like the idea of always wanting to improve and adapting based on the feedback people give you. The author talked about “a belief that it is better to share what we know than to create scarcity by hoarding it.” I found this quote very interesting and I 100% agree with him but I feel like this only is true in the computer world since people go off each other’s ideas and make changes to improve it. After reading the introduction for chapters two through six, I think I have found what my next blog is going to be about so it is giving me something to look toward and forward too. I will see you on the next blog, hopefully. 

Website: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch01.html?_gl=1*2xjvhe*_ga*MjYwNDQ1ODc5LjE3MDY1NTY4MTg.*_ga_092EL089CH*MTcwNjU1NjgxNy4xLjAuMTcwNjU1NjgyMy41NC4wLjA.#introduction

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

Copyright and licenses in Software creation.

In today’s technology-driven world, software development has become a cornerstone of innovation. Whether you’re a professional software engineer or just a hobbyist coder, understanding the legal aspects of software creation is crucial. This blog post explores copyright and licenses in the realm of software development, shedding light on how they affect developers and users alike.

  1. Copyright in Software

Copyright law plays a pivotal role in protecting the intellectual property of software creators. When you write code, you automatically gain copyright protection over it. This means that no one else can copy, distribute, or modify your code without your permission.

Key points about copyright in software:

  • Copyright protection is automatic: As soon as you create code, it’s protected under copyright law, without any need for registration.
  • Exclusive rights: Copyright grants you exclusive rights to control how your software is used, reproduced, distributed, and modified.
  • Duration: Copyright protection typically lasts for the lifetime of the author plus 70 years, or for a set period in the case of works created by corporations.
  1. Open Source and Licensing

While copyright protects software by default, developers often choose to use open-source licenses to specify how others can use their code. Open-source software is critical to the tech industry, fostering collaboration and innovation by allowing others to use, modify, and distribute the code.

Key points about open-source licensing:

  • Types of licenses: There are various open-source licenses, including the MIT License, GNU General Public License (GPL), Apache License, and more. Each has its own terms and conditions.
  • Permissive vs. copyleft licenses: Some licenses are permissive, allowing for wide usage, while others, like the GPL, enforce certain restrictions to ensure derivative works remain open source.
  • Attribution: Many open-source licenses require users to give credit to the original author when they use the code.
  1. Proprietary Software Licenses

Not all software is open source. Proprietary software is protected by strict licenses that limit how it can be used, modified, and distributed. These licenses may restrict users from viewing or modifying the source code.

Key points about proprietary software licenses:

  • Closed source: Proprietary software is typically closed source, meaning the source code is not freely available for inspection or modification.
  • End-user agreements: Users must agree to terms and conditions specified in end-user license agreements (EULAs) before using the software.
  • Restrictive vs. permissive licenses: Proprietary software licenses can vary widely in terms of the restrictions they impose on users.
  1. Dual Licensing

Some software developers choose to offer their software under both open-source and proprietary licenses. This approach allows them to provide a free, open-source version while also offering a commercial version with additional features and support.

Key points about dual licensing:

  • Monetization: Dual licensing provides a way for developers to generate revenue from their open-source projects.
  • Flexibility: Users can choose the license that best suits their needs, depending on whether they want a free, open-source version or a commercial one with extra features.
  1. Compliance and Enforcement

Both open-source and proprietary software licenses come with rules and conditions that must be followed. Non-compliance can lead to legal action and damages.

Key points about compliance and enforcement:

  • Legal consequences: Violating a software license can result in lawsuits, injunctions, and monetary damages.
  • Compliance tools: There are tools and services available to help developers and organizations track and ensure license compliance.

Conclusion

Understanding copyright and licenses in software creation is essential for developers and users. Whether you’re contributing to open source, building proprietary software, or using software created by others, awareness of these legal aspects is vital for fostering collaboration and innovation while respecting intellectual property rights. Always be sure to read and adhere to the terms and conditions specified in software licenses to avoid legal complications and contribute positively to the software development ecosystem.

From the blog cs@worcester – A Journey through CS by mgl1990 and used with permission of the author. All other rights reserved by the author.

Learn How you Fail – week 13

This pattern focuses on being able to identify why and the ways you make mistakes to learn from them. The big message of the pattern is that you will naturally not be good at everything and sometimes you will have to spend a lot more time on something just to only be a little bit better at it which is ok, as long as you are making advancements to improving something you lack or feel needs work than do as much as you can.

In my experience I find it difficult to start new projects as I feel I am not yet qualified or experienced enough to finish or even make a large dent in the project. Not only is this a issue with the confidence I have in my work but moreover how I view how difficult the projects and issues tend to be, however eventually when I build up the courage to finally start I notice that I am much more capable than I thought I was. Even when I do end up making a mistake, I can see what I made a mistake on and work around it in order to be able to fix it and prevent it from happening in the future. The best way to go about it is like the pattern says, be conscious of the mistakes that I make and on what parts I make them on. A method the pattern speaks of is creating test classes for a method before you run the method at all so that you can look at all the mistakes at its raw form without testing. This will give you a good idea of what you fresh work looks like and where you seem to fumble. One method that I know still needs work on is my documentation especially on larger projects. Making more notes and comments of work I have done will allow me to keep better track and organize my thoughts.

While it sounds like being over critical about what kind of work you can accomplish being aware of what you can handle will allow you to better understand you limits so you can make a effort to move past them and be even better than you once were.

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

Sprint-3

This is my final blog for the university, where I work hard for four years, hoping to become a software developer. The team and I finished most of the tasks for the project “Reporting. System”; it was challenging for our learning experience. There are struggles and realizations from mistakes and trials of multiple attempts that help and benefit understanding for further the learning experiences. Those learning experiences from the tasks were interesting and challenging to complete becoming more difficult than others for unexpected.

I am currently making a presentation and adding details from looking back at the tasks that the group and myself for how much we accomplished. Also, looking forward to graduation. After the team and I adjusted to the issue board required for the work and practice. I have done these issues over the semester for weight assignments that have been changed with a total weight of 2-3 is reasonable and practicable. Some are easy to do and understand, but others are challenging.

The Issue:

  • Remove MongoID leftover – Backend (changes). There are still MongoIDs available, and I will investigate this further. After I asked for feedback or assisted in making certain adjustments, the result seemed to be an improvement, and the team concurred.
  • backend — Write a test suite for API (changes); This activity writes tests in Chai, ensuring that the backend works with the API while ensuring you get a file back in .xls format (get the simple tests working).

My still challenge concerning one of these tasks is researching the topic of “Chai.” the topic is still questioning the existence of a library written in JavaScript with different test frameworks. It provides that your code continues to work as intended by attaching to the assertions set up. Like npm install chai, chai-HTTP, chai-as-promise, etc. Those additions make the process simpler, but it doesn’t look good. It has already gone through the potentially functional aspects, even after the review, code addition/construction, and code comparison phases.

After I got the chai working correctly, I learned the backend server kept shutting down due to missing files, leading to some codes not passing. The team and I backed up the system by going back to find those files and running for testing; the first half is working (the version number), and the second half won’t. (missing data from the database). 

For improvement, I prepare to find information about this issue from my group members and others by asking others who have had this experience issue before. Even though the team and myself ran into more mixed technical problems during the development process, like missing files, which resulted in more delays that shifted the focus on the specific problem. Even that problem can help us better comprehend and learn new specialties to avoid misleading and repeated attempts. 

In conclusion, in the third and last university sprint, our team had a good time discussing and executing the tasks, though we tried to do some things to perform wildly well after the second-Sprint. We still faced some obstacles that became a fun learning experience for new topics.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Sprint-3

This is my final blog for the university, where I work hard for four years, hoping to become a software developer. The team and I finished most of the tasks for the project “Reporting. System”; it was challenging for our learning experience. There are struggles and realizations from mistakes and trials of multiple attempts that help and benefit understanding for further the learning experiences. Those learning experiences from the tasks were interesting and challenging to complete becoming more difficult than others for unexpected.

I am currently making a presentation and adding details from looking back at the tasks that the group and myself for how much we accomplished. Also, looking forward to graduation. After the team and I adjusted to the issue board required for the work and practice. I have done these issues over the semester for weight assignments that have been changed with a total weight of 2-3 is reasonable and practicable. Some are easy to do and understand, but others are challenging.

The Issue:

  • Remove MongoID leftover – Backend (changes). There are still MongoIDs available, and I will investigate this further. After I asked for feedback or assisted in making certain adjustments, the result seemed to be an improvement, and the team concurred.
  • backend — Write a test suite for API (changes); This activity writes tests in Chai, ensuring that the backend works with the API while ensuring you get a file back in .xls format (get the simple tests working).

My still challenge concerning one of these tasks is researching the topic of “Chai.” the topic is still questioning the existence of a library written in JavaScript with different test frameworks. It provides that your code continues to work as intended by attaching to the assertions set up. Like npm install chai, chai-HTTP, chai-as-promise, etc. Those additions make the process simpler, but it doesn’t look good. It has already gone through the potentially functional aspects, even after the review, code addition/construction, and code comparison phases.

After I got the chai working correctly, I learned the backend server kept shutting down due to missing files, leading to some codes not passing. The team and I backed up the system by going back to find those files and running for testing; the first half is working (the version number), and the second half won’t. (missing data from the database). 

For improvement, I prepare to find information about this issue from my group members and others by asking others who have had this experience issue before. Even though the team and myself ran into more mixed technical problems during the development process, like missing files, which resulted in more delays that shifted the focus on the specific problem. Even that problem can help us better comprehend and learn new specialties to avoid misleading and repeated attempts. 

In conclusion, in the third and last university sprint, our team had a good time discussing and executing the tasks, though we tried to do some things to perform wildly well after the second-Sprint. We still faced some obstacles that became a fun learning experience for new topics.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Sprint-3

This is my final blog for the university, where I work hard for four years, hoping to become a software developer. The team and I finished most of the tasks for the project “Reporting. System”; it was challenging for our learning experience. There are struggles and realizations from mistakes and trials of multiple attempts that help and benefit understanding for further the learning experiences. Those learning experiences from the tasks were interesting and challenging to complete becoming more difficult than others for unexpected.

I am currently making a presentation and adding details from looking back at the tasks that the group and myself for how much we accomplished. Also, looking forward to graduation. After the team and I adjusted to the issue board required for the work and practice. I have done these issues over the semester for weight assignments that have been changed with a total weight of 2-3 is reasonable and practicable. Some are easy to do and understand, but others are challenging.

The Issue:

  • Remove MongoID leftover – Backend (changes). There are still MongoIDs available, and I will investigate this further. After I asked for feedback or assisted in making certain adjustments, the result seemed to be an improvement, and the team concurred.
  • backend — Write a test suite for API (changes); This activity writes tests in Chai, ensuring that the backend works with the API while ensuring you get a file back in .xls format (get the simple tests working).

My still challenge concerning one of these tasks is researching the topic of “Chai.” the topic is still questioning the existence of a library written in JavaScript with different test frameworks. It provides that your code continues to work as intended by attaching to the assertions set up. Like npm install chai, chai-HTTP, chai-as-promise, etc. Those additions make the process simpler, but it doesn’t look good. It has already gone through the potentially functional aspects, even after the review, code addition/construction, and code comparison phases.

After I got the chai working correctly, I learned the backend server kept shutting down due to missing files, leading to some codes not passing. The team and I backed up the system by going back to find those files and running for testing; the first half is working (the version number), and the second half won’t. (missing data from the database). 

For improvement, I prepare to find information about this issue from my group members and others by asking others who have had this experience issue before. Even though the team and myself ran into more mixed technical problems during the development process, like missing files, which resulted in more delays that shifted the focus on the specific problem. Even that problem can help us better comprehend and learn new specialties to avoid misleading and repeated attempts. 

In conclusion, in the third and last university sprint, our team had a good time discussing and executing the tasks, though we tried to do some things to perform wildly well after the second-Sprint. We still faced some obstacles that became a fun learning experience for new topics.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.