I started last week by meeting with Dr. Wurst (my project advisor) to go over what I had done up until that point and to figure out what I should be doing going forward with my research. We mainly discussed the new proposed candidate workflow that was created during the LibreFoodPantry (LFP) Retreat after I had left. Most of that discussion was about the two main roles in the diagram, the trustees and the shop managers. It was decided that the trustees would be the people who maintain the LibreFoodPantry project and that the shop managers would be instructors who are teaching a course and developing for the project for a semester. The shop managers would fork a copy of the repository they are working on into their own “shop” for their class where it would be worked on by student shop developers (another user role). Finally there is a client / user role that has basic access to the LFP group. We also discussed the GitLab permissions for each of these roles, which is different depending on which GitLab group we are looking at as there is different permissions for the same role in the LFP group and the shop group. We decided that I should be building this workflow out in all 3 platforms (GitHub Free, GitLab Free, and GitLab Gold) and document the process and any issues. We anticipated issues trying to implement this in GitHub as it doesn’t have the same permission levels as GitLab which is what the workflow was created with. I also needed to update the features table as we previously discussed the previous week so that all the features in the same row are related across platforms and that they use the specific naming that the platforms use. Finally, I was to try and create a simple GitLab repository and implement GitLab’s CI in a simple Java Gradle project to see how this worked. We also decided that we would have regular meetings every week on Tuesday for the rest of the summer.
On Wednesday I created a new table using Google Sheets as I found that the rows align much better in a spreadsheet than a Google Docs table. I copied and pasted all of the bullet points from the 3 platforms from the old table into the new one. I then rearranged them in color order. I finally went through each one and started renaming the features to be more consistent with how its respective website names it in its support or documentation pages.
Thursday I finished up with the table and it was nearly done except for a few little questions for Dr. Wurst in our next meeting. I also created a digital version of the proposed candidate workflow diagram using Draw.io as I wanted a cleaner looking version instead of the whiteboard picture from Google Drive. I emailed Dr. Wurst the diagram to check if I created it correctly and had a little question about why one of the branch symbols was located in the diagram. I finished Thursday by creating a GitLab Gold repository and made a GitLab CI configuration file. I cloned it to my desktop and converted it to a Gradle project the way we did this spring in CS348 using some documentation from the course’s Blackboard page. I ran into a problem that others in my class had previously with Gradle not working correctly on Windows.
Friday I fixed the Gradle not working issue using a page from stackoverflow. I then got GitLab CI to work on this project, as it was previously failing due to a fix I implemented to try and get Gradle to work. I found that GitLab’s website provides great documentation to show exactly where the failure occurs in a CI pipeline. On Friday I also received an email from Dr. Wurst that forwarded a document from another professor who had a student that also researched GitHub vs. GitLab. I looked at the document and it compared what they thought were the most important features, some of which I hadn’t seen yet so I looked at them on GitHub and GitLab’s websites and added them into my features table. I did find this document to be helpful as it contained new information I hadn’t come across yet. I decided that the table was done and moved on to testing the candidate workflow. I started this by creating 4 Google Accounts, 1 for the shop developer, 2 for the student developers (so I can have two student local repositories to push and pull from) and 1 client / guest account. I documented the usernames and passwords in a Google Sheet so that others in the LFP group can use them. I then created GitLab accounts for these test accounts and added them to the testing group we created in GitLab Gold (I used my account to add them to the LFP test group and the shop manager to add to the class shop group to simulate how it would actually be done with the trustee and shop manager roles). I am using the test group we created in GitLab Gold as the LFP group and I made a sub-group in this that acts as the shop group. One problem I noticed with this is that if we are going to create sub-groups for the shop classes within the LFP group on GitLab, there would be permissions issues with trustees having access to the shop which would be a course taught at another institution. I used my GitLab account for the role of trustee since I was an owner in the testing group. I then created a test repository in the test LFP group under my account and forked it into the shop with the shop manager account. At this point I stopped for the week as I was unsure of how to proceed with testing the workflow since it involves multiple shop developers cloning, pushing, and pulling to their local computers. This would mean I need multiple local GitLab repositories with different user accounts and I wanted to ask Dr. Wurst the best way to do this, I thought that creating a VM for each account would be the best way of doing this.
From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.
Hi dear readers. Welcome back/all to my next blog post about the next Pattern. The next Pattern I am going to write today is about ‘Reading List’. Yep you heard it right! Reading List! Just because you are a developer doesn’t mean that you got no more reading to do.
This Pattern in the book talks about how to start with a reading list and how to keep up with it. The authors make very good points when they say that its hard to even start a reading list as you might not be sure what to read first. I like how one of the recommendations is to ask your mentor/professor. They would be the people who know your development level better than anyone and will definitely be a great help. Another point to keep in mind is that the initial Reading List you have created might (probably will) change after you have finished one of them. Having a Reading List is great because it also makes you reflect about what you read previously.
As mentioned in the book, we should always think and analyze about the book we just read and try to figure out on our own on what should be the next book to read. Computer Science is one of these field that new things will always keep coming up and what better than books will be describing these new innovations. Indeed these new books should be on top of the list.
I believe that there will be cases where you/me as a reader will be disappointed on one or more books. It’s not right that just because one book was not good enough, we should stop reading other books. I think that when you don’t find a book interesting or good enough, it’s a good sign as you are thinking about the book content. This will give you a better understanding on what you would like to read next and what is your favorite area. For example, for my reading lots of books about programming languages wouldn’t be too much interesting. On the other hand there are people who love reading each and every book about programming languages and this is because they’re passionate about it.
I would recommend to just start somewhere, and then you will be able to figure out on what to jump on next.
From the blog CS@Worcester – Danja's Blog by danja9 and used with permission of the author. All other rights reserved by the author.
On my readings on the patterns, “share what you learn”. By teaching what you already know about your profession, you’ll learn more, make new connections with people, and find new opportunities. And by doing that you will may find it very fun.
From the reading, to my understanding, another reason you shouldn’t wait to start sharing with others is that it will help you learn. Research has shown that when we explain something to other people, we come to understand it better ourselves. The process of teaching or sharing what we have learned to others, helps us recognize gaps in our own understanding and better organize information in our minds.
Also one thing i notice about sharing what you learn with others will give your talents more exposure, thus giving the people you interact with the opportunity to identify you as a valuable expert. Helping others can help you build your reputation. Also sharing what you learn can be a great tool for everyone. All you need to do is to be permanently connected to the hot business topics and offer your expertise every time you can. When people are open to prove their value through their competence, it’s easier to notice the ones likely to organize people and to take initiative.
Let’s take for instance, you are in the team, by sharing what you learn or known and talking about certain decisions and procedures, the new guys or juniors could easily acquire new sets of skills. Create an environment where everybody is encouraged to ask questions, and help professionals in all your locations and job positions stay updated with the latest information in their field. Also by sharing what you learn, increases the productivity of your team. You can work faster and smarter, as you get easier access to the internal resources and expertise within your organization. Projects don’t get delayed, people swimmingly get the information they need in order to do their jobs and your business fills the bill.
I really enjoyed reading the pattern because i got the some main importance of sharing, strategic ways of sharing and things that i do not have to do.
From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.
Hi everyone and welcome to another CS 448 Software Development Capstone blog. Today blog topic is about one of the individual apprenticeship patterns which happen to record what you learn. I wanted to read more about this pattern because I can relate. Ever since last semester I been writing many blogs and didn’t fully understand why I was posting them. At first, I thought this method of recording what I learn was to help us research more information and writing them as blogs would help us understand the material better. After reading this, I realize that it’s just more than blogging once per week. I understand that recording our journey helps keep vital resources, makes our journey explicit, and can be helpful to many others. I feel like after reading this individual apprenticeship pattern I will change the way I work because all this time I was blogging, I didn’t really blog for purpose and just blog because it was assigned so I think I will be more efficient when I blog now. I also picked up a new idea from reading this pattern which is to have two journal that is private and public. I can use the public for sharing what I have learned and gaining feedback and the private one for me, to be honest with my status in programming. I do agree that it best to have both because of the perks that each offer. I like when the record what you learn pattern state that Dave was constantly posting his journey for years and eventually, he had tons of resources that he then later uses later in his career. The reason why I like this statement is that it makes me more motivated when posting these blog assignments because I know that eventually, it will come in handy one day in my career. All in all, I felt like this individual apprenticeship pattern, record what you learn is very informative. I learned that every apprentice should keep a journal for their journey and try to write every day as one day it will help others and even help themselves.
From the blog CS@Worcester – Phan's CS by phancs and used with permission of the author. All other rights reserved by the author.
I learned a lot from this first sprint. A lot of issues were being run into and as a team we were able to overcome these obstacles to all continue. Something that I learned that collaboration can often lead to success because you may learn something about a topic that you may not know. Next I will explain some of the tasks our group has completed. First, we had to make sure all of us had a sprint backlog. These included tasks for our sprint timeframe that we should be able to complete. We setup a group environment on GitHub to clone our ng2-amrs repositories so we could get oiur AMPATH portal up and running. This is where we, and many others, ran into most of our problems. A lot of us had many different errors so it was very confusing trying to find fixes for all of us at first. We coordinated with other groups via slack channels in order to first find out who was having what errors. After posting about the errors and discussing them in the slack channels and amongst each other at our meetings, we started to research for solutions.
The fix fix for this was to run two commands in the node modules folder that fixed the package.json file. After this, we ran “npm run build-prod” and then this fixed the issue.
From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.
Often times we feel as if we may know how to do something, when in reality we may not know. Some problems that arise can may seem familiar but often times need more digging to figure out the answer or solution to. The Expose your ignorance pattern explains this by growing yourself in order to find a solution. The pattern states that we are not going to know every little detail about every software or domain we need to use in our jobs. There are people depending on us to perform a task, but the issue is what exactly do we do when we can’t overcome these obstacles? Even if you don’t know what you are doing or aren’t aware of a certain situation, it is always better to atleast look like or be willing to be competent in whatever the task at hand is. One great point that I think this pattern brought up was conceding your pressure and just telling your clients or colleagues that everything is okay, even when it is not. If you just tell people that thing are okay even though they aren’t this can lead to a massive snowball effect.
For example, maybe you don’t understand how to use the companies’ software that you are working for yet and there is some things you either want clarified or need more time on. If you were to just say that you understand everything, what does this precedent set? It tells people that you are okay to move on to the next thing and most often than not, whatever that “next thing” is, it most likely builds upon the previous task or requirement you should understand. Sometimes it is just better to be honest and let your team understand that although you may not currently understand what is happening now, you will be able to learn it. As long as you show you are able to learn the materials and keep up even when you are behind, you will always be valuable. Ask questions because not only will it help you, but it can often times help whoever is answering the question with something they may not have known about either.
From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.
For this blog post, I will be discussing the Apprentice Pattern, Expose your Ignorance, found in the text Apprenticeship Patterns. This pattern piqued my interest. It discussed how to deal with inevitably not knowing something. It is comforting to hear that I am not the only one who sometimes feels out of their depth.
This pattern gave me a few things to work on. It can feel natural to tell people what they want to hear, but that isn’t a good way to build trust. I know it may seem obvious, but it is very easy to fall into that trap, and I know from experience. I like the idea of building a reputation on my ability to learn rather than what I say I know.
Ignorance isn’t something to hide — it is a chance to grow. This brings to mind a “growth mindset,” which means that instead of seeing challenges as something that sets one back is instead something that can be learned from and used as fuel to grow. It is clear that this book adopts this idea, even if it isn’t necessarily one of the patterns.
The pattern made me think of my ignorance in a new light. Instead of trying to pretend that I know more than I do, I should make it well known what I don’t know. My reputation shouldn’t come from what I know, it is my ability to learn new things.
I also liked how they wrote that being an expert is not the goal. The example of a marathoner having strong legs from running even if that wasn’t the goal seemed like an apt metaphor that being an expert is likewise a byproduct. In addition even if we are experts in one area, we will always be ignorant elsewhere. We should relish in what we do not know. Ignorance is something that should be welcomed because it means we are learning and growing.
I feel this pattern is tougher said than done. It is a simple concept, but it might take years to fully master. That being said, simply being aware of my shortcomings in this area is a huge step forward. This is something I intend to start immediately in every project that I am currently working on and every project in the future.
From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.
On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my forth individual Apprenticeship pattern I have chosen “Practice, Practice, Practice”. I will first summarize the pattern and then I will state my reaction of this pattern.
Practice, Practice, Practice summarized
It is important that you take the time to practice your craft in a comfortable stress free environment where you can make mistakes and learn from them. It is just as important to have constant feedback in order to avoid developing bad habits. According to the book, “The key to this pattern is to carve out some time to develop software in a stress-free and playful environment: no release dates, no production issues, no interruptions. As Dave Thomas says of practicing, “It has to be acceptable to relax, because if you aren’t relaxed you’re not going to learn from the practice.””. This pattern tells you about a good tool to use. That is a coder’s dojo, which is a place where people can perform code katas regularly and publicly within a tight-knit community of craftsman. This tool is also good because it allows constant feedback. Another good tool to use is one of your old programming books. Pick an exercise from the book that is not too easy for you. Then, try to solve it from scratch for once a week for about a month. By doing this it will allow you to see how much your solution has improved and sharpen up your skills.
This pattern shows you that a good craftsman, must constantly practice in order to sharpen his/her skills. It also, tells you to constantly receive feedback of what you practice because it helps prevent you from forming bad habits. Personally, I agree with this idea. I found that this idea is not just interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think because it has made me realize that I need to “practice, practice, practice” on this long road of Software Craftsmanship.
Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.
From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.
For the fourth week’s reading, I chose to read the pattern, Breakable Toys. This pattern focused on the problem where you are introduced into an environment that doesn’t allow you to fail. Even though everyone knows that you are learning from your failures is the best form of learning. There solution is that you create something similar or a private environment where you can create and work around projects that are similar but not replicas of the projects where you work. The goal is to learn from failing in similar projects where you can learn how to work around them and possibly apply concepts learned in the future. An action provided for this pattern is to build a simple wiki while maintaining quality. In effect, you should be able to keep implementing more features by learning and applying them. Concluding this would be, don’t let work constraints prevent you from learning for yourself and take control of what you can learn and apply.
What I found interesting about this pattern would be their example of breakable toys. Which is to re-create known tools to give yourself a deeper understanding about the tool and why it came to be that way. Examples of these are games like Tetris, tic-tac-toe, or other simple software. By being able to successfully recreate such games and software, you can get a feel for the thought process and problems that the first creators may have come across and face long ago. Enabling yourself to have time, experiment, fail, and try again is essential in learning. Another would be the wiki solution, as you may learn much more than expected over a longer period of time.
This pattern has reinforced my current thoughts about my intended profession. I believe that there will be many different environments to face in the future. Some may be welcoming, and some may not be so welcoming. By learning about how to deal with a situation such as this one where failure is not allowed. Being able to adapt quickly and create a workable solution is important in progressing as a person and in the field of software development.
From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.
It’s fair to say that I am nervous about entering a computer science job and working with a professional software development team for the first time. While I will be fortunate enough to graduate with knowledge of agile development, I have a feeling that it will be quite different to participate in development with more experienced coworkers, rather than with classmates with similar skill levels as me. This week’s apprenticeship pattern, “Sweep the Floor,” described various ways that I can potentially overcome this initial worry of fitting in and being able to contribute on the team to the best of my ability.
Sweep the Floor discusses my exact predicament: being the new apprentice on the team and struggling to find my place within it. The solution for this issue is to work on simple and more mundane, or unglamorous, tasks which the rest of the team may find more tedious. Or, the apprentice may focus more on the “edges” of the project (rather than the “core”) to minimize any risks to the project that could come with putting a newcomer on the more difficult parts of the work. These tasks are still necessary for team success, and therefore make great experience for an apprentice who is just starting out in the field. By completing these seemingly unimportant tasks, the apprentice can show the rest of the team that he or she is capable of producing quality work that benefits the whole group.
Before I read about this pattern, I was already aware that as a new member of the software development team, I wouldn’t have as much responsibility or experience as other coworkers who have been on the team for a longer period of time. This pattern gave me a better sense of direction, in terms of more specifics for the kind of work I could expect to complete when first starting out on the development team. I have always found some reassurance in the thought that new employers and colleagues expect fresh college graduates to not have much experience outside of the coding projects they completed for classes. This pattern helped further encourage me that I can make the most of this “newbie” status by finding important tasks to do and still gaining valuable practice.
Thanks for reading!
From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.