Author Archives: mbeqo

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 2 Retrospective

Compared to the last sprint not only did I personally complete much more work, but the team accomplished a lot. As a matter of fact, we got over 17 in weight done in the first week compared to the much lower amount in the first sprint. I noticed that when it came to issues of us needing help or the sharing of information a lot more work was done together, and it allowed us to complete more of the epics and issues. For example, one of the issues me and kelvin both had similar solutions one was for the backend and the other was for the API, once Kelvin modified the commands/build.sh on the API I looked and see what changes he had made so that I could make similar changes to the Backend.

            Much of what was accomplished at the beginning was all of the issues that didn’t involve unit testing such as the verification of collection names in the API as well as Evaluating and Improving the API as a whole. The epics that were finished during the sprint were the API refactoring of file/directory/release structure and infrastructure as well as the conversion of all docker images we are building to multi-architecture images. As I state previously, we completed more epics in this sprint than that of the previous one.

            As for improvements that could be made I think the biggest improvement we can make is to keep focus especially towards the end of the sprint, I’ve noticed once we get into the final week of the spring right before the sprint review the progress tends to slow down and focus lessens a fair amount this mainly do to shifting attention to the review, reflection, and the planning of the next sprint. While all of those steps are very important to the process maintaining the flow that we have the first 2 weeks into the last one will allow us to possibly complete even more and get farther into the project. As for personal improvements I can make I think practicing and taking on even more of a workload would be to my benefit as it will allow me to cover more ground and become more accustomed to the system. The biggest issue I had in the previous sprint was that I spent a lot of time resolving issues that had come up while fixing other issues, as well as trying to delve into the Frontend of the system. I maintained the right of amount of weight completion each week which was a significant improvement over last sprints and I plan to keep that going into the next sprint.

            The best thing to come out of this sprint was that most of the last sprint will be finishing up unit testing and focusing on making sure the system works correctly so that next semesters students don’t have issues with the system and can work on it efficiently Much like how we found it. The most important thing now is to keep the system running and keep Epics organized and unopen so that the next semester can work off those.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/82

Designed Unit test for replaceGuest Endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/76

Implementation of the unit Test designed for the replaceGuest Endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/102

Verification of collection names in the API to make sure they make sense and are correct.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/87

modified commands/build.sh in backend to use context to specify what image to build.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/86

added Pipeline variable with multiplatform string to backend.

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

Your First Language

This pattern focuses on the idea of establishing yourself in one language that you may be able to base your career in the future, to better prepare yourself for when you get to the career you want to obtain. The most fundamental aspect from the pattern was the community side of learning a language as it states that you become a part of a much larger community of programmers who share their knowledge and even their code for the sake of helping each other learn and grow as developers.

            In my Experience I thought if I learned a lot of different languages, I could have the experience needed to land any job I wanted too as I had my foot in more languages than one, but what I didn’t realize is that being a good at one language is better than being decent at many. This was not only reenforced by the pattern discussed here but when I met with a family friend who is a developer at staples, he also dropped that bit of wisdom on me as he too thought that was but as he got closer to starting his career, he focused on mastering java, and it has steered him into a very lucrative job.

            Going back to the community aspect the reading mentions how having such large community that works from the same language allows for beginners to have more experienced programmers share the small tricks that they have learned in their experience to give the newer developers a boost in learning. There is a sense of passing the torch in a community like this which you rarely see in other industries, and it is refreshing the lengths that people will go for the sake of knowledge.

            Another useful aspect in the reading was the use of testing early on into learning a new language, as I was relatively new to coding when I started my degree, I went based on what the curriculum that the classes had for what projects I worked on. If I had started testing my knowledge earlier on and working on my own projects based on the language that we were learning on my own time I would have accelerated my experience with java.

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

Sprint Retrospective- Sprint 1

In this Sprint the Biggest take away I had was coming to the realization that every aspect of working in the class either it be doing the research required or diving directly into the code itself it must be recorded and accounted for was time spent working. Being able to properly weigh the tasks that we had to do on the first time around was tricky as we always seemed to spend much more time on issues that we thought would take only a couple of minutes, but the beautify of it was that we could always go back and adjust the weight of the issues afterwards.

            The thing that worked the best for us was being able to delegate issues to ourselves and others who had the capacity to solve those issues relatively quickly and with little to no support required from others that would take away from the time that they would spend on their own work. The other big aspect that worked for us was being able to come together and support one another when we had issues in our separate tasks. I can think of many times where kelvin offered his support when I was having Problems with my committing in the backend issue I was working on during the sprint, and I can say that others in the group stumbled at moments when someone else came and gave input that allowed for the issue to be solved.

            The biggest change we would need to make as a team would be to definitely work on creating more issues when we are planning our Sprint, when we started this one we were under our target weight at around 28, in order to make sure we hit out goal weight we need to make issues no matter how simple we think the solution to issues may be. When we looked over all the issues, we had on our boards we realized that some of the issues we created could be broken up into more issues and some could even be weighted more.

            The change I would make as an individual is to focus more on the smaller issues as well as doing research on the bigger overarching issues that require more attention. Front end was the longest I had spent on issues during the sprint was looking over the front end as it was the one aspect the GuestInfoSystem that I had not touched, even in the previous class. I spent most of one week just doing as much research into VUE as well as how to navigate the front end and it was still difficult to wrap my head around what needed to be done for the issue. While this research was important and necessary I could have also spent time completing issues on other aspects of the System of which I had more experience on, however I was interested in seeing if I would be up to the task of taking on the FrontEnd.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/69

This issue was solved removing any of the Get/guest parameters from the GuestInfoAPI, which was found primarily in the listGuests.yaml

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/69

This issue was solved by removing many parts of the guest.js file as well as using the updated API from the other repository and importing it into this backend.

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

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

In the Reading I see the path that I had put myself on when I originally switched to Computer science, I found myself not only lost, but hopeless for a long time but I persevered through the years while making at-least some progress in understanding concepts as well as learned basic coding languages. the Biggest thing I took away from the reading was Dave’s story, I seen myself in Dave’s shoes as he didn’t get the hand of learning computers and learning perl with little to no luck until he found himself people to learn under, who showed him a better way of learning and better resources to follow rather than the ordinary path.

            The biggest thing I have learned while studying computer science is that essentially like in most classes you must teach yourself and take the time to understand the concepts and practice on your own. Much like how Dave did when he started out, in my case I began to understand the coding much more when I finally got to my first class with Professor Wurst. It seemed like the shift to more practical use of Coding as well as system designs it finally clicked in my mind how all of the concepts began to flow together. While I don’t consider to be a Direct Apprentice in this example but being a pupal of someone who is actively developing an working on their own projects and someone I can actually contact and study under.

            One other individual I have been learning under is one of my Sisters Friends who actually is a Engineer over at staples that I have been trying to learn under and get guidance from, he began to show me the ins and outs of what actual Software engineering work looks like as well as what steps to undertake in order to better prepare for when I gradate and begin my job search, one of the first things I started was converting my resume into a more project and software oriented template rather than the Business one I have.

This aspect of learning what I can from people in Positions that I would want to be in is a important as rather than going through the setbacks I can see the tricks of the trade directly from people who were in my shoes in the past, sending me directly to where I want to be faster and more informed.

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

Blog Week 14 (Token)- Abstraction and Composition

The Two of the fundamental aspects of coding, Abstraction and composition, are discussed thoroughly in this blog as well as the overall impact these processes can have on the code as a whole, we discussed these two towards the beginning of the classes and how they have there rolls in being able to not only code better but to understand and lay out the structure of the code.

At first I didn’t really understand how reducing a problem to its most basic form could help when I need to make code to very Specific actions and work a certain way, however after utilizing those processes in order to simplify the problem, then follow up by building up from those basic models allows me to utilize basic code to solve my more advanced problems. This opened up my thought Process when it came to Writing code as now I could think of all of the previous Projects I had where I had to create multiple objects and set Attributes for each specific one, and now I could seamlessly do it on a larger scale reusing other basic code.

For abstraction, it is the process of reducing all of the but the most important details in the code and leaving all of the extra out, it is important as it all owes for the most basic process to be worked on, and then subsequent work can be delegated to the more advanced versions of that the problem. an Example would be to rather than making multiple functions for different things, we could makes basic function that can be implemented repeatedly and reused. We can look at an example of the duck Project where we looked at different models of these classes and we noticed that certain ducks needed specific flying actions or squeaking actions, so rather than making multiple classes for multiple different types of ducks we made a basic duck class and created specializations for them In order to better the overall structure and reduce clutter. Then the using Composition you may make the connections to the different Objects in order to share information. Using the Duck Project Again, we made different types of ducks with Connections being made to the main Duck class with all of the Parameters, then we made connections for the squeak and Fly behaviors.

The Writer Focus on some key Traits for Good Abstractions, that being Simple, Concise, and Reusable. These are the things to look for when you want to simplify the work you do.

Elliott, Eric. “Abstraction & Composition.” Medium, JavaScript Scene, 28 May 2020, https://medium.com/javascript-scene/abstraction-composition-cb2849d5bdd6.

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

Blog Week 14- Good Software Technical Writing

One of the most Relevant and important aspects of programming that I have neglected for a while is commenting and proper technical Writing, when I first started out I figured I would just remember all of the changes I would make to my code and didn’t require the small notes in-between methods. later on I began to understand the importance when I began working with many different files that needed to work in tandem and couldn’t remember what each method I wrote did or how it worked in the system as a whole.

In this blog the author Goes over many of the different aspects of technical Writing from either commenting on each method to adding context to the code overall, the biggest take away I got from it is that code without Comments is Worthless, by reading the documentation you should be able to understand why the previous engineers made changes or added functionality to the code. this allows for other developers to come in and quickly understand what is going on and be able to delete or insert sections of code in order to continue the development cycle.

the Writer goes on to show many different examples with one being a sequence diagram that gives the step by step explanation of what the Sequence of the systems in play, much like the different design architectures we discussed in a previous class where it shows the link between user and the database. The Importance of this kind of writing is that it can convey the was the system is supposed to work together so if another developer were come along and look over the schema they would understand the process and be able to work off of that.

Oliveira, Vincent. “HOW TO WRITE Good Software Technical Documentation.” Medium, Medium, 15 June 2022, https://medium.com/@VincentOliveira/how-to-write-good-software-technical-documentation-41880a0e7814.

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

Week 12- Design Smells

The blog I reviewed this week delves deeper on the topic of design smells and the classifications of some of them in different situations, some of which we had discussed in previous classes and some new ones that prove to be important to know in the long run. this article focus on design smells in the UI/UX side of programming and more specific to this side but still very much important.

The first discussed is “Documentation for Power users” which is the separate documentation used on portals to different sights when users click hyperlinks, or the different section on a Website or application. the issue comes from the formating and the flow of said website many look very cluttered and the flow of information is jumbled up. One specific example that is used for this smell is the Use of Microsoft Excel, the main focus being that it is a universally used application and thus has universal tools that the users disposal, the issue with such a great tool as without distinct tools being separated from the ones a user might not use in order to optimize the users experience it overwhelms them. this goes for all users as there is no case by case optimization, one solution brought up would be to dissect the application into separate products in order to better organize the UI for consumers in different situations, such as one made for educational use and one for corporate.

Another Smell that is discussed and closely relates to the previous is “Excessive Iconography”, this smell focuses on the use of unclear icons to display information in large loads, if we look at the example used in the blog of Xcode on Mac with many of the icons and labels out all on the same display to overwhelm the developer, making the tasks more difficult. the issue isn’t that the Labels or the Icons are not clear, but there are to many options and features present on the same screen. one way to combat this is to structure the application into smaller instances including all features that are connected together, allowing for clearer labeling and better overall experience for users. one personal example of this kind of structure I found was on Jira which structured its features according to what the user needed, allowing for a seemless UI and better experience. it did this but hiding features entirely that were not necessary and clearly labeling its tools.

Yodaiken, Aaron. “Ux Smells.” Medium, UX Collective, 7 Feb. 2017, https://medium.com/user-experience-design-1/ux-smells-fa971feef820.

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

Week 11-Software Architecture patterns

The Blog I read this week focusses on the the different Types of software architecture that we had discussed in previous classes as well as the different situations that these different patterns are useful and for what type of situation they would be ideal for. One of the important ones discussed and the most interesting ones that applies to my everyday life is the client server pattern.

In this pattern a central server offers one or more services are offered to one or more clients, allowing for all of the work to be done at the central server while all of the users can use the Data independently. This is very relevant for the world at large as many of the sites that we use on a day to day basis use this type of pattern such as twitter, where the Application provided the under interface for the user and the servers to interact. this type of pattern is used for many different applications we use today such as facebook and many other types of social media, where the user takes the information from the server and the selections made on the users side will then be sent to the server and update the information on that side of it. it is interesting how our small interaction impacts the overall system as a whole and how the entire process occurs for something so simple as updating your twitter bio.

Another pattern discussed in the blog is the layers pattern, which we discussed in both classes related to Cohesion as well as design patterns. it is described as the most widely used and promotes low coupling and high cohesion, much of what we discussed before hand in class is gone over such is how it is utilized for the most part smaller projects with different teams working on different parts of the project in parallel with other departments in order to keep the system active for users as well as allowing for updates to be spit out more often without shutting down the rest of the system. this was an important aspect of release principles as allowing for these releases to happen frequently in order to push updates to users as often as possible while other developments were also in progressed proved beneficial to the user but strained the developers, with the different teams it allows for less stress on devs to release patches or updates in select parts of the projects.

O, Williams. “Fundamental Software Architectural Patterns.” Medium, Medium, 14 June 2022, https://medium.com/@liams_o/fundamental-software-architectural-patterns-663440c5f9a5.

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

Week 8-What is an API

For this week I wanted to dive a little deeper on the APIs that we has begin to work with in the previous lab, it interested me how these systems work and wanted to see how different examples out in the world worked and how it related to how we interact with the systems themselves.

In the blog the author goes deep into how the API System are very apparent throughout the world and how they work, the best example I saw was a calendar system on google. The user would send a request to googles remote server and then the server would respond with the site to allow the user too book on the calendar, one the user set the date the request would be sent back to the server and a response would be sent back to the user. As someone who uses other systems like booksy to book haircuts with my barber its interesting how the API allows me to book it on my end while it does all of the work for me interacting with the server and changing my barbers calendar to integrate my appointment.

In the case of the work we did in the lab it is interesting to see how the API used for the pantry relates to some of the APIs discussed in the blog, when we worked we saw the all of the different actions in that API which led to either the collection as a whole or individual students when we looked to post new details or retrieve details. It is interesting to see how similarly the example we worked on works with the blogs APIs, where ours is more adding students taking food or putting food in the pantry, while also logging what is taken or what is put in, there examples is access to a Weather API to check weather in certain areas or the facebook API to give the user their profiles information.

One part that the Blog focuses on heavily is Object Oriented design, where there is a large list of objects and each object has an API which allows the objects to interact with one another, much of what is said leads back to our earlier lab seasons focusing on the different design models and which ones work better, the API aspect of it is now made relevant on how these objects interact with each-other on the users side.

Gazarov, Petr. “What Is an API? in English, Please.” Medium, We’ve Moved to FreeCodeCamp.org/News, 10 Oct. 2016, https://medium.com/free-code-camp/what-is-an-api-in-english-please-b880a3214a82.

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