CS448 Retrospective Blog #1

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/8

Here I put links for tutorials and relevant articles for learning MongoDB.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/27

This card shows I was allocated to the event system cross-cutting team.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/16

This is a card I created for learning how to connect the backend to mongoDB.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/18

This card is for an example mongoDB project.

Our first sprint was filled with learning, both about the tools we need and about the sprint process. I think there are many things that worked well. First, I think our team composition right now is good. We all know each other from previous classes, and we are comfortable with talking casually to each other. This is good because there was no initial awkward phase – we were able to get straight to working with each other. Another thing that worked well was asking important questions for each other on gitlab. While we did not use the cards to their fullest potential, having email notifications for gitlab really forced me to pay attention to the cards. My discord does not have notifications turned on, so I must actively check for new messages. On gitlab the email notifications made me extra aware of new comments on cards and any changes to the cards.

There were of course many things that did not go so well. Somethings I failed to realize is that gitlab should be the place where I keep all my work. I followed quite a few tutorials, so I have a few mongodb projects on my own computer. I should have been actively adding them to gitlab as well. My issue was that I did not feel like I had a finished product worth sharing. I should have realized that was okay and posted that anyway.  Another thing that did work so well was communicating mostly on discord. We did a lot of brainstorming and communicating in class through voice chat. Because we did not write down every single thing we spoke about, some things were forgotten or missed. We should definitely be trying to use text chat more, but most of our communication should probably be through gitlab to maintain a permanent record of what is being discussed.

As a team we should definitely work on mostly using gitlab cards for communication. As a team we should also try to contribute more evenly in discussions and with product owner meetings. I know I am not contributing enough and we should all be taking responsibility for our team instead of just letting one or two people do all the talking for us. Overall though I feel like my team is very solid and we work well together.

As an individual I should work firstly on time management. Having sprints like this is almost deceptive in a way. This isn’t the kind of thing you can do all the work right at the end of the sprint. It really isn’t possible to complete most of the cards like that. The work should be spread out, especially since it is cumulative. Some cards need to be completed so you know how to complete other cards. I also have to work on communicating with my group more. As the system is more fleshed out, we are going to have to work together more to combine the parts we have created. Right now we are sort of working independently and just checking in with each other. I will have to share the work I am doing with he rest of my team very frequently by pushing it to gitlab instead of just waiting to show them during class.

I went into this sprint very intimidated by the size of this project. After finishing it I feel a bit better because I know how sprints work now and we have a clearer vision of what we are going to do for this project. The next sprint will definitely be an improvement over our first.

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

Share What You Learn -Apprenticeship Pattern

The “Share What You Learn” apprenticeship pattern, written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009, is about sharing your knowledge. This is for software apprentices who have solely focused on their own growth/improvement. Sharing what you learn can benefit yourself as well as others. This is because it helps you learn to communicate what you know effectively, but also helps people who are on the same path as you, trying to learn the same things.

Maintaining a blog, tutorial channel, etc. during your early apprenticeship years can be great for your growth as a developer. You may feel like you only have a basic understanding of some topics that you have just learned, but this may benefit others more than you would think. As the book states, your basic understanding will translate to an easy to understand, straight to the point article, blog post, etc. that will help other apprentices who are right behind you in the journey to becoming a master. So don’t think that you need to leave it to someone who has an extreme in depth understanding of the topic, often times what they will give back to the community will not be as beginner friendly. You must be careful when sharing knowledge though and make sure that you are not spilling a companies secrets that can ruin your relationship with your team or get you in legal trouble.

I like this apprenticeship pattern in particular because it benefits yourself and others at the same time. Teaching is a great way to learn for both the teacher him/herself, and the student/learner. A certain part of this pattern really caught my attention and that is to not worry about leaving these posts/tutorials to people who have greater knowledge of the topic. Often times when learning something new, I will go to forums rather than tutorials. On these forums you can often find threads where students are asking the same questions about a topic that you are wondering yourself, and a lot of times other students will respond to these questions with their understanding of the topic. This is a great starting point for learning something new because often times there are basic, easy to understand, straight to the point responses that can kickstart your learning of the topic.

Hoover, D. H., & Oshineye, A. (2010). Apprenticeship patterns: Guidance for the aspiring software craftsman. Sebastopol, CA: O’Reilly.

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

Concrete Skills – Apprenticeship Patterns

The main focus of this apprenticeship pattern called concrete skills is to have a fundamental base. A person can’t just rely on having the ability to learn something, but they need to show that they already have some skills that they have learned and improved on over the years. Also, these skills directly relate to software constructing such as being familiar with a certain programming language and implementing different features that can be useful for a company. While it is important and recommended to have many soft skill qualities, you can’t solely rely on this to land a job relating to software. You need to be able to showcase technical skills and so this pattern talks about taking actions to improve skills that are needed for the certain job criteria. It recommends to look at cover letters of individuals who are currently doing the job you hope to seek and copy down discrete skills listed on it that you can use to improve yourself.

I think this pattern has a really great concept that software apprentices can use to improve their knowledge for programming and other aspects of engineering. We can’t just have the mindset that we can learn new things when the time is right and just try to learn it then. We need to do some more research on our own and try our best to not be relying on others to carry us to learn fundamentals. People in work and a team don’t want a team member who they constantly have to monitor and essentially babysit for them to complete their work. We need to learn the essentials for the required job and practice to implement those skills on our own to show a boss or team members that we are capable of doing the work. This will prove that you are in fact able to learn and down the line will be capable of learning a new software or process that is often the case with the technological advancement of the world at a rapid pace. Overall, I think once we follow this pattern in a practical sense and change our mindset, we will see vast changes in our skills as well as the way we look at learning.

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

Dig Deeper

For this week I want to talk about the Dig Deeper apprenticeship pattern. This is a pattern that everyone in computer science understand it well and doesn’t need to many words. The main point of this pattern is that no matter what tool you decide to explore, learn to dig deep into it. Acquire the depths of knowledge to the point that you know why things are the way they are.

In today’s world there are so many tools that is so hard to keep track with. I’m sure anyone can learn a tool or language if they have enough time to explore and understand it. If that’s not the case then you only ever learn the parts of a technology that you need to get your portion of the system working, and you depend on other members of the team to learn the other parts. So, with what you end up is a superficial knowledge of a thousand tools and you’re not even aware of how little you know until something or someone puts you to the test.

Another thing that I like, and I don’t like at the same time is depend on other members of the team to learn other parts. There are serious students or coworkers who will do their job but also, we have the other side of coin. There are people who don’t take it seriously, so you end up doing all the work by yourself or have misunderstanding. Solution to this is to hope you have time to learn and explore more of the tool and finger crossed to have someone driven to learn new things working with you.

Another advantage of digging deep into a technology is that you can actually explain what’s going on beneath the surface of the systems you work on. The book explains how in interviews, this understanding will distinguish you from other candidates who can’t describe the software they’ve helped build in a meaningful way because all they understand is one little portion. Once you’re part of a team, it’s the application of this pattern that separates out those who are making random piles of rubble. So, you don’t have to fake it till you make it. If you invest your free time to learn something new you going to add more points to yourself.

References:
Apprenticeship Patterns by Dave Hoover; Adewale Oshineye

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Behavior Driven Development

https://cucumber.io/docs/bdd/

            Since my last blog post for CS-443 focused on test driven development, I thought I was appropriate to talk about behavior driven development, also known as BDD for short, for this blog post. The reason I chose to write about this topic aside the reason just mentioned is because BDD is one of the topics covered in this class according to the syllabus. The article linked above acts as a tutorial for this type of development going through the specific procedure of BDD. According to the article, behavior driven development works as a three-step iterative process. The first step is to take a small upcoming change to the system, also known as a user story, and form concrete examples of new functionalities until they’re generally agreed upon. The second step documents those examples in a way that can be automated and checked for agreement. The final step implements the behavior described in the documents written in the previous step and begins with an automated test to guide the development of the code. This process continually adds a new behavior to the system each iterative loop.

            Before I wrote this blog post, I assumed that behavior driven development would have been a new concept to me unlike test driven development. However just like TDD, BDD is actually a concept I’m familiar with on some level. As I’ve taken computer science classes in WSU, I got into the habit of writing out what specific functions a program I’m working on needs. I wouldn’t go as far as create a user story for each task I’d have to do; that’s still a fairly new concept for me. But, just like the iterative nature of behavior driven development, I would document what behaviors a program needs to function and implement them into the code with some tests to guide development. Another thing that caught my attention is the last step of BDD which utilizes tests to give direction to the development of the code. Because of this, you could say that behavior driven development implements test driven development in its own way.  I don’t have much to add to this point, I just thought It was interesting enough to point out.

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

Apprenticeship Patterns Blog – Unleash Your Enthusiasm

For this week’s blog post, I read the section  “Unleash Your Enthusiasm” from chapter two of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about how software developers especially the newcomers find themselves self-holding back the enthusiasm you have towards the work than your colleagues. Mainly due to the fear of making a poor impression on your coworkers. As I was reading the pattern, I feel like it has a personal connection to me because I see myself in the same situation of holding back on certain circumstances, Mainly I do not want to make a bad impression. The author states that ” Most teams are not hyper passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain”  I completely agree with this statement, I see many people nowadays in the field of technology are not passionate about the work they do daily.

However, I think it is important especially for a team member to be Optimistic, enthusiastic, and eager to learn.  For us, this is the perfect time in your career when it makes the most sense to take risks and speak your mind. Ultimately, we have very little to lose. Also, I believe that ideas and passion will add diversity and energy to a team. One of the risks the author talked how “unleashing your enthusiasm on an established team. If morale is low or if the team is not welcoming of newcomers, you will likely get some eye-rolling behind your back.” I agree with this but on a team that is open to excitement and contributions, you will provide some unique qualities that stand you out. Ultimately, unleashing enthusiasm or some excitement into your team is great because as a newcomer you will have a fresh perspective, which should allow you to offer some useful suggestions for improvement. Overall, this pattern was very interesting, and moving forward I should not be holding back, instead, I should show my enthusiasm qualities towards something and should speak up for what I think is right.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Blog #2 Weak vs Normal (Equivalence Class Testing)

I wanted to look more into equivalence class testing after working with it on some of the class activities and having some trouble understanding some of its aspects, specifically the differences between weak and strong, and single fault assumption vs multi fault assumption.

Equivalence Class Testing-Black Box Software Testing Techniques

Weak and Strong testing come in two forms each, Normal and Robust. Weak testing is meant to work with the single fault assumption, where one variable from each class is tested. With Weak Normal, only valid values are tested, while Weak Robust tests valid and invalid. Strong Normal testing works with the multi fault assumption, meaning that each valid possibility is tested, and Strong Robust testing works with each valid and invalid possibility.

Where I was getting confused and had to look more into equivalence class testing was the difference between working with one variable from each class and working with all possibilities, or more specifically, the single fault assumption and the multi fault assumption. When I was first looking at it and tried working on problems about this, they seemed the same to me because with each entry in the table I was making and other examples I looked at. It looked to me that both worked with multiple values of the variables that are in the range, so I got caught up on trying to see where I was making a mistake in my understanding.

Where I think I was making my mistake, and what I think the difference between the two is, is that with Weak test cases, one of the variables stays constant while the other goes through its different values. Then after several of those test cases, the latter variable stays constant at the nominal and the former changes values. Through this, one of the variables is getting testing at a time with the other values of the other variable, which is where the idea of testing one variable from each class comes from. I may be wrong about this, and this is just how I understood it.

Distinguish between single and multiple fault assumption

So with Strong testing, this is where you can use any combination of valid values for the two variables for the test cases. This would increase the number of cases due to more possibilities. Then with Weak Robust and Strong Robust, you mostly do the same but include the invalid values with the valid ones from the Normal testing. In Weak Robust, one variable stays at the nominal while the other goes through a range of valid and invalid values, then do the same for the other variable. In Strong Robust, all valid and invalid possibilities for the variables are tested, leading to the highest amount of test cases out of the four techniques.

I think I have a better understanding of the differences between them after delving more into equivalence class testing and the different techniques associated with. My misunderstanding was how variables were being tested with the two assumptions because they seemed the same at first, but I can see how they are different now in their test cases and methods.

https://www.professionalqa.com/equivalence-class-testing

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Concrete Skills: Building a Baseline Skillset

When looking into opportunities for employment, a vast majority of posted openings or advertisements for positions include a list of requirements or preferred traits in prospective applicants. More often than not, this will include a minimum required degree in a related field (ie: BA in Computer Science) and a certain amount of experience in a certain language or languages, ability to work with specific frameworks and tools, and oftentimes a certain level of “work experience” in a related position.

While this often makes it relatively clear the sort of attributes employers are searching for when hiring, there is still the case of needing to stand-out, and prove your potential worth to a company. The pattern discussed in chapter 2 of Apprenticeship Patterns (https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch02s04.html), “Concrete Skills” discusses the idea of building up a central “concrete” set of skills which can be demonstrated to possible employers or managers as a way to showcase your skills and ability to contribute. This ties into the pattern “breakable toys” which I discussed previously, where the benefits of building practice projects solely for your own benefit and experience is showcased.

So by having a set of core skills, (comprehensive knowledge of a favored programming language, knowledge of common frameworks and adjacent technologies, web development and front-end development skills) you are able to better standout to employers, and can use these skills in making examples or “breakable toys” to showcase the extent of your abilities and what you can bring to a team.

I would say that the “concrete skills” pattern discusses a simple concept, but one which has value especially when looking to start a career or move on to a new position. Being able to visibly demonstrate proficiency to a prospective employer can showcase an ability to learn new things and improve self-sufficiently. As you would need to have somewhere to get practice or experience working with these concrete skills beforehand, using breakable toys in conjunction with the concrete skills pattern can work as a synergy, the breakable toys serving as examples to demonstrate the concrete skills to others.

Text Referenced:

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch02s04.html

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

Craft over Art

            This week I read the section “Craft over Art” which is found in chapter three of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section focuses on a software developer’s struggle in balancing their own personal want of making something with artistic merit and a client’s need of a product fulfills their requirements. The developer might add components that may be impressive but could also be pointless to or be an outright hindrance to the client’s wants. The developer may also want to polish up a project to a mirror sheen that deadlines would simply not allow for. And additionally, a software developer is a craftsman and not an artist. That doesn’t necessarily mean that a developer can’t produce something with beauty; a craftsman creates beauty by fulfilling a request to their utmost abilities. It just means that the client’s wants should be balanced with the software developer’s personal standards.

            The whole “Craft over Art” concept I agree with and in fact, I’ve thought of the concept on some level before through a practical point of view. Like why would I add features to software that wouldn’t benefit the user in some way? I’d just be wasting time I could use to polish up the existing components of the software. For example, If I were to work on a program that kept track of the transactions of a business and I added an option to play chess, that’d seem kind of pointless. If I really wanted to make a chess program, then I’d set that aside as a side project that I could do for fun. That doesn’t conflict with the “Craft over Art” concept since there have been plenty of craftsman who’ve worked on personal side projects in between their main commissioned projects. Even when just talking about software, I’ve heard of a fair number of programmers who’ve made little side projects like a game for example on their off time. And when working on main projects, I at the very least try to fulfill the minimum requirements so I can go back and polish it up as much as I feel the need to. But even then, there are time where the circumstances don’t allow for much polish so I just have to suck it up.

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

Sprint #1 Retrospective Blog Post

After the first month of my final semester, my capstone course has proved to be an interesting experience so far.  As much as we are working in groups to create a database dedicated for the food pantry, I believe we really are striving to strengthen our skills with using the SCRUM method of group work.  Our first sprint went very well in my eyes.  We have not gotten much done in terms of making the frontend and backend of our database, but we accomplished a lot when it came to getting tasks done that we chose to try to complete at the beginning of the sprint.  Our team worked very well together and it seemed as though everyone was contributing heavily towards finishing our tasks quickly and completely.  Personally, I thought I contributed a lot of research, work, and extra effort for the team to help everyone out.  We decided to make me the team’s SCRUM Master which in all honesty did not force me to have much more responsibility at all, but it was helpful for me to learn from the product owner and relay back to the team.  I tried keeping helpful information posted both on discord and on gitlab for the team and for myself.  This proved very helpful.  In the future (for later sprints and for in similar situations in real life), I believe we could have done a better job communicating outside of our class periods.  It may have help our group get things done even smoother than how we already did if we had been running a better communication system.  This however was not really anyone’s fault as we were still able to get most of our tasks done and because of the fact that everyone is taking a lot of classes right now and not just this one.  On a personal note, I think it would have relieved some stress for me if I could have tried spacing my work for this group out throughout the week rather than getting things done in one or two sessions per week.  This would have made it easier for me to communicate problems if I had had any and would have reflected better on my final completions at the end of the sprint.  Again though, it is more difficult when I am taking other courses and not having this project as my main job or focus.  The main issue that I think my group and I will run into for the next sprint is that we will have more tasks related to building the database now rather than the more learning and reviewing bases tasks we had in sprint one.  Like I stated earlier, this sprint seems more like one in which we get familiarized with how the rest of the sprints will be done and how to work as a group with SCRUM.  However, I think we picked up on what we needed to do very fast, and everyone seemed to have put in a lot of good work and dedication.  Because of this, I know that even if the tasks in the next sprints become more difficult, we will still be able to get great work done and have a successful product in no time!

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