Category Archives: Week 7

Blog Post Number 1

This week is read a blog post on “design patterns in programming- how and when to use them” this blog post was written by Ajibola Ojo from the blog called DevGenius. He did a really great job in explain it in a way were the reader had an easy way of understanding the concept about the design patterns that make it easier to develop in more suitable solutions to problems. A few of the solutions he included but were not limited to was a  optimal approach for rewriting the same code, he talks about using packages.  He explained that design patterns aren’t rigid, they are like a set of guidelines for solving problems.  In this specific blog post he concentrates a lot of state design pattens. He uses a simple code to show an example of how to use the Finite State Machine. Which is an abstract machine. His example of code has an” idle, receiving, calling and on call” he goes through all the possibility of connecting all the classes. By building and using the stat designs patterns, you can visualize a problem as a finite state machine and then be able to translate that into code. With his classes he ended up with a four possible state which the transitions can happened. He later goes on to show all the connections like example caller A and caller B are idle so if caller a tries to call caller b caller a state moves to calling while caller b moves to receiving. The reason why picked this blog post was that in the midst of reading a lot of blogs post this week, I found that, this one even though it was shorter than most of them, that we were easier reads and straight to the topic, which is something I really appreciate. I liked how the also included diagrams and snips of code which made it easier for me to be able to connect what the writer was talking about and actually visualize everything he was saying. Sometimes when working on coding projects I tend to not diagram. But now looking at the way that it was explained really helped me visualize the importance. Even though it sometimes can be tedious I now can understand how it helps involve interactions between the classes. Hopefully with more practice on using the state design pattern, I will learn to like and appreciate the process and master it.

View at Medium.com

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

Getting better and better

As we have been Progressing through the weeks and we work on the pogils as well as the homework I find myself slowly getting the hang of the work flow as well as utilizing VSCode, I for once understand what is going on in the classes and am eager to continue to learn as it finally is being pieced together in my head. the biggest part would probably have to be the feedback that I receive and probably mostly everyone else gets as well its not some random jargon about how something is wrong but it seems like a guiding hand to get you to the solution that you aren’t to far from. the biggest take away I have gotten as organizing the UML diagrams on the Homework really connected the dots on how these classes and models work together better than it ever has , I can understand paths a little better than I did before.

I only hope I continue to understand the work I continue to do, and im eager to see what work I can get done.

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

Sprint 2 Retrospective:

This sprint ran more smoothly than Sprint 1 did. As a result of having obtained a more detailed specification by coordinating with the goals laid out by Dr. Burge from Nassau Community College and having obtained a better understanding of the individual skill-sets of our team members, we were able to produce an OpenAPI specification that defined 8 of the 9 requested endpoint definitions. The yaml file containing these definitions was then used to write, build, and test these endpoints in our back-end container. These methods were then tested internally within the container by using the Visual Studio Code environment to launch HTTP requests from 2 files (guest.http and qs.http). “Swagger UI” was used as a VSCode extension to facilitate this process.

It was easier this sprint to distribute work among the team, because the Open-API spec was available shortly after the start of the sprint, enabling back-end code to be written and unit tested. As testing progressed, we would modify the spec as we made changes to the back-end code to fix bugs.

Although we did a better job at keeping the Git-lab Epics and Issues boards properly in place than in the prior sprint, this may have been the weakest area of our efforts. Our intention is to improve the ongoing modification of this Scrum material as we progress to sprint 3.

We improved our use and efficiency of GIT to Git-Lab coordination, were able to build semantic versioning, checked the structure of the Open-API definition with Swagger Preview, and started looking into using a secure key. This key will be coordinated as a priority in the sprint 3 effort through communication with the IAM team.

I was able to set up a fork of the NEST Android application with the intention of doing system testing of the REST API. By using Android Studio, my prior knowledge of Android development with Java, and the help of a guiding YouTube video, along with general help from stackoverflow.com community, I was able to write 6 classes in an isolated namespace to the project. This code uses an android library call Volley to facilitate REST API development. This code launches an activity from the main NEST activity which allows the user to make requests to the remote back-end MongoDB database, and returns responses, which are then displayed in a scroll-able text view component.

The layout used by this activity used a relatively new UI component called a Constraint Layout, which improves the efficiency and maintainability of its XML code with the support of a sophisticated design tool allowing “drag and drop” of components, allowing them to effectively present a user interface which will scale properly over the hundreds of different android devices, all with different screen resolutions, aspect ratios, and device sizes.

The system testing was burdened by the fact that calls from Android were producing a Timeout Error on every attempt. With the help of Dr. Wurst, I am in a better position to get these calls working by the first week of the upcoming sprint.

I was impressed with this sprint, because our team accomplished the 2 main goals of this classroom effort, the first being to improve the skill-set of the team members in a “real world” development effort, and secondly, to help with the general progress of the LibreFoodPantry work to produce a product to help those less fortunate than ourselves.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

The Deep End

Chapter Two’s is themed around growing your knowledge. The pattern “Confront Your Ignorance” follows this theme and focuses on working with projects that are outside of your expertise. When you feel as if each project you are working on is like the previous one, it means you are applying your existing knowledge. There is truly little chance to grow as a developer when you work strictly within the areas you are knowledgeable about. The ideal scenario is one where you are working outside of your area of expertise to maximize the amount of new experience you engage with.

In the future, I will be more willing to work on projects where I dive into a topic that I do not fully understand. I also feel that the action for this pattern, to map your projects in a timeline, is a useful way to track your personal development over time. A timeline is a terrific way to see if your learning has stagnated and it is time to jump into something new. This method is also a great way to see where you want to take your professional career and give you an opportunity to map into the future.

I found it interesting how large of a risk the author suggests taking regarding a project outside of your knowledge. It is suggested to work on projects where the possibility of failure to complete them is high. In a private setting, I would gladly challenge myself by deep-diving into a project that I do not feel confident I can complete. In a professional setting, I personally am a bit too risk-averse to immediately want to take on a task where the chance of failure is greater than my chance of success. However, I appreciate that it is a gamble where if I do succeed it will boost my portfolio and whether I succeed or fail I will walk away with more knowledge than I started with. I believe it is human nature to be frightened of failure. This pattern is a great reminder that the journey that led to failure was along the way a great learning experience and the following attempt will be a success based on what you had learned.

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

Week 7: Be The Worst

For this week’s pattern, I chose ‘Be the Worst’ from Chapter 4. I initially chose it because it caught my eye and I was going in order of chapters with the patterns I chose. I thought it would describe in detail to be the worst of your team but it was actually the opposite. The context is after unleashing your enthusiasm, which I assume was a pattern before this one, you take every opportunity to learn new skills. As a result, you outgrow your team and possibly your entire development organization. This was much different from what I originally thought this would be about, I thought this would be to think yourself as the worst to get better as a software craftsman. It kind of follows that pattern of thinking though, basically surrounding yourself with better developers. This in turn, will motivate you to be a better developer and have room to grow as a developer. I thought this was an interesting point, I mean this is something that I sometimes think about and is actually something I’m experiencing right now. I’m in a team that I feel like are all better developers than me which in turn makes me want to be a better developer because sometimes I feel so lost when in team discussions. This pattern really stuck with me because I related to it a lot. I just need to find the motivation to be a better developer, I need an extra push because just a team of strong developers won’t push me hard enough to find that drive to be better than I was yesterday. The pattern also mentions Breakable Toys and Reflecting as You Work as patterns to go back to because they are particularly important if you are the worst on your team, which I am. I guess I’m gonna check those out after this pattern, maybe even write about them. Honestly though, I feel like this pattern kind of reinforces impostor syndrome, which I found out is pretty common amongst developers and probably is common in STEM related jobs, but at least with this book, it puts out a solution for you to follow.

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

Sweep the Floor

The context of this pattern is that you are a new apprentice on a project. However, the problem is that you don’t know what your role is in this team. You don’t know how to contribute to the team and help them in any way necessary. The solution is to volunteer for simple, unglamorous, yet necessary tasks for the team. This way, you can earn team member’s trust, and you also get to show the team members how quality of work you can do. The tasks may be such as maintaining the build system, production support, responding to maintenance requests, bug fixing code review etc. The tasks can be anything, but it cannot have any high risks. Starting a core tasks and failing puts you into a bad side of a team, so it is better to start off with an easy tasks and actually finish it to have good relationship with everyone on the team. These short takes benefits the team, but it will also benefit your apprentice because such chores are often skipped in academic courses and by doing them you can fill in the gaps in your knowledge. After all, if no one sweeps the floor, then the glamorous work can’t be done because the team is hip-deep in dirt.

This pattern kind of reminded me of our group for the capstone project. When we first formed the group, I was assigned to the frontend part of the project. I was ready to do the first task from the GitLab issue board, but my main question was how can I convince the team that I can do this project together with the team and can actually make some contribution. In this computer science major, I feel as if I am always a step behind from everyone and have to add in extra effort to be on the same level as everyone else. So to show my skill, my first task was to connect two components and load one component only on click, which in my opinion is not an easy task but also not a hard task and I think I managed to do that, and the team seemed to love the way it turned out to be.

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

Apprenticeship Pattern “Familiar Tools”

For this week’s blog post, I decided to pick a topic that I think is very important and is something that we should remind ourselves time and time again. The topic I wanted to go over this week is on the topic of familiar tools or using things that we are familiar or comfortable with. How the author defines familiar tools in this section is a familiar tool is something that we can use without needing to look at the documentation. We have seen it enough times to know the ins and outs of whatever we are using. In the beginning of the chapter, it talks about how when we use familiar tools, it gives us peace of mind because we can give clients rough estimates or timelines of when they can expect something to be done. It is also because of this peace of mind that the author says that it may increase productivity. While there are advantages to using familiar tools, the author also cautions us to be careful. Using familiar tools may make us feel too comfortable and cause us to lean back on these tools and use them to try to solve every problem. So, the important reminder that author gives us at the end of the section is that we need to remember there will come a time in which our familiar tools will become obsolete and that we should not be unmovable. When the time comes, we need to be ready to adjust and throw away our familiar tools.

I found this section to be interesting because a while back, I was having this conversation with my team. We were talking about how when were learning introduction to programming, we were taught that our default branch on GitLab is master and when GitLab made the change to their naming convention from master to main, it threw everyone in the group off. Reading this chapter made me realize that everything we are learning now is mostly relevant now and that in a couple years, everything we learn may just become an artifact of the past. The principles may stay the same but the naming or software we may be completely different. Reading this chapter also reminded me of something that my R professor once told me. She once said something along the lines of, “Right now, we may be standing on solid ground but in a year from now or even in 6 months, the floor may disappear from beneath us.” When she told me this, she was referring to how our libraries may quickly become obsolete and when the time comes we should not be resilient to change.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm

Back when I was a kid (actually until now), I have been really into playing video games. It could be the reason why I chose Computer Science in order to be able to create games, a popular reason just as many of my colleagues. I somehow was able to land a spot at Ho Chi Minh City University of Technology, a flagship in technology teaching and research activities in Vietnam, after the high school graduate exam.

By the start of the school year, I had nothing but excitement, my only experience was some rough foundations of Pascal taught in high school and I barely remember anything from it. On the other hand, my colleagues were students from the very top high schools with a program concentrating in what they desire, which were mostly computers and the others had extra programming courses outside the class. Besides, the program was designed for students who already had experience with programming since the syllabus of my programming introduction class is a C++ class consisting of both functional and OOP methods with two huge projects. As a result, I was totally “destroyed” in this intro class while my colleagues, having a hard time, but managed to get through it.

Since my excitement was demolished, I had a hard time thinking about my major choice. I did not have any problem doing the required calculus, linear algebra, physics classes but my computer introduction class was a disaster. I was not able to unleash my enthusiasm, I did not know what it was, what I did at that time was grinding myself painfully to be “better”. In my opinion, we tend to be afraid of discussing or expressing something we are not familiar with, and for my case, I cannot show my professor my problem because of it.

After a few years since then, I would say that the syllabus for that intro class was still overwhelming for new students. However, for students who already had their based knowledge before taking that “intro” class, it’s a good opportunity for them to review before going into the main courses. If only I knew how to inject my excitement into my work to ask my professor about my problem, my learning would have been much better, wouldn’t it?!

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

Craft over Art- blog 6

For this week, I read the pattern of Craft over Art. This pattern occurs when beauty takes precedence over utility. However, as a craftsman, you need to make your crafts become useful instead of beautiful.  One of the most important factors of being a craftsman is accepting that you are not an artist. Your job is not to create beautiful and fantastic things to satisfy your artistic creations. Your job is to create a craft which can serve the needs of others and meet the minimum standards of quality. The higher the quality, the more time it takes. Each level of quality always require the trade-off between beauty and utility. So, you have to know what to do with the customers’ requests; and you must be able to balance their desire on the products by telling them what to prioritize in a particular period of time. Moreover, as a craftsman, you need to ensure that you are always willing to deliver the best products to satisfy your customers’ needs. That willingness does not depend on your current feelings or inspiration because you are not an artist, you are “supposed to earn a living at your craft”.

In my opinion, I totally agree with the idea of this pattern, Craft over Art. I like this pattern because it is practical, it tells me what I have to do to create value as a craftsman, which is to make my crafts useful, not beautiful. If you are an artist, you have to create beautiful things for people to admire your creations; but if you are a software developer, who will admire your creations, but useless? When your code does not even work, how will people know the beauty of your creations.

Therefore, I always prefer a simple program, “fifty-line game that makes someone smile”, over a complex program, a million-line game but unplayable. I have also used this pattern when starting to learn something new. My real life example is that when I learned to write a game in python language, I chose the simplest game to imitate and learn from. That is because I know exactly what my goals are. I just want to understand all the basic steps to write a game. The simpler the game, the easier it is to learn. I chose to learn the basic but useful for my understanding instead of the complicated stuff but I learned nothing from it.

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

CS 448 Post 2

For my next post, I wanted to move on to the first problem in chapter 3, The Long Road. I liked this problem because it deals with a situation where you are stuck between wanting to continue learning more about computer science and improving your skill at it, and moving on to “the highest-paying job and the first promotion you can get your hands on”. It comes down to this because it can take many years to master your skills, and you may never fully master them because technology continues to advance and that there is so much to learn.

The quotes at the beginning of the problem, and the problem itself support the idea that improving yourself at and even mastering something will likely take your whole life. Apprenticeships, such as computer science in this case, are journeys that are based on long term growth, and improving yourself is meant to be the main purpose of what you do. I can see that specifically with computer science, trying to completely master it may never be possible because not only is there already a huge amount of technology in the world to learn and work with, advances are constantly being made. While this means that there will be plenty of jobs and responsibilities for computer scientists, there may also never be some kind of finish line in terms of mastering computer science and technology. However, the same could be said for other fields of learning because advances are also being made in those fields that may or may not be linked to technology, and we always have our and other people’s experiences to learn from. There is always more to learn from, and computer science is just one example of that.

One more thing I want to mention and that I liked is that it is reinforced multiple times going over this problem that the path of focusing on mastering skills over your whole life is not the only path. Other paths for computer scientists such as settling in on a job like tester or project manager, entering jobs early in your life, or even leaving the field and going into other fields are also valid. These paths are not the focus of this book, but there are not wrong paths to take either.

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