Sprint 4 Retrospective

For this sprint, my team and I continued our work on trying to mock the server aspect of the project so as to give other teams a way to test their code. We had followed the tutorials on nock to make sure we understood the way that it worked and how we would have to translate it over. However when we went to the AMRS code to try to find something to try to mock we ran into some problems. Going through the code, there is a lot of moving parts to each element with the program which made mocking just one thing look like it may not be possible. Not only that but almost everything we found looking through the code, returned html responses from the ng-AMRS server they have set up already. For example one of the main things we looking into mocking was the patient-creation-resource part of the simple App, since it seemed to be one of the smaller files and less requirements/calls to other classes. In trying to mock one of the methods from this, this is where we started to feel that this may be a little too high of a task for us without the AMRS server itself. I feel as though if we had access to their already made server and could have just mocked the tests at that point we would have had much better success. There were just too many moving parts to each thing for our current way that we planned on mocking to be realistic. During this sprint though, I feel we were able to work more on the project and were actually making headway till we hit the wall on what we could actually wind up mocking. At the end of this sprint we also started talking about the possibility that we might not be able to achieve what we set out to do originally, so we also started looking at the bottom navigation bar element that still needed to be completed. We chose this as our backup and I had started to get some of the smaller stuff out of the way for that. I have gotten together all of the CSS and HTML components for the bottom navigation bar with what was provided from Greg Schmidt on the Zeplin app. Since this seems to be the direction we will be heading in the next sprint I felt it was smart to try to get ahead on some of the smaller/easier stuff. What I will need to be looking into and finding out how it works is the button elements that Greg Schmidt wants and how I can recreate them.

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

Apprenticeship Patterns – Craft over Art

This pattern is about the conflict between creating software that is beautiful and creating software that is useful. While you may find opportunities to do something truly fantastic, a craftsman should always focus on delivering value to the customer rather than advancing his or her own self-interests. You must find a way to balance the conflicting demands of creating quality software while still putting your customer’s interests first. Software built for customers can be beautiful, but it must always be useful. Following this pattern means that you must be willing to sacrifice beauty in favor of utility when it becomes necessary.

A craftsman must also produce satisfactory quality even if he or she doesn’t feel like it. Craftsmen can’t wait for inspiration to strike before delivering a product. However, it’s not about simply doing what is fastest. A craft artifact should always display at least a minimal level of quality. This means you must always be making trade-offs between beauty and utility, and sometimes you will make the wrong trade-off. However, by fixing these mistakes, you will learn lessons that are impossible to learn in any other way.

I enjoyed reading this pattern. I have always found it interesting how programming is so technical yet can be incredibly artistic at the same time. This pattern brings up a very valid point that even though you may be able to create something artistic, utility will always be a priority when software is made for a customer. I think the following sentence from the pattern sums it up perfectly: “The things we build for customers can be beautiful, but must be useful.”

As a programmer, it is often tough to decide whether to code something that gets the job done but is ugly, or something that takes more time but is beautiful. It is important to analyze the purpose of what you’re creating to decide which direction you should head in. Reading this pattern made me think a lot about utility vs beauty in software development. I do agree with the main point that as a craftsman creating something for a customer, utility should be prioritized. Overall, I thought this was an interesting and useful pattern.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Sprint 4

This week wraps up our fourth sprint in our software development capstone class. This sprint saw a lot in the way of front end development. One of the large tasks we were able to complete during this sprint was figuring out how to store the data that was entered in the intake form sheet using a local javascript  server that can be run through the terminal using angular. This was developed by Johnny and was attached to the front end file folder where it now lives. At first we were working in the original repository and had the project all together. This seemed fine at first but we quickly realized that not separating the repository into frontend and backend sections would prove to be a major problem down the line. We ended up having to fight with ourselves every time we wanted to run or even open the project because files were crossed and mixed up because we did not have proper file directory setups. One major problem I found right off the bat was not being able to run the front end of the project because I would get an error message in the terminal saying something to the effect of “You must be in an angular project to use angular commands”. I encountered this error after trying to run ng serve –open to get the project running. I was in the root directory for the project, where I should have been. After doing some extensive trial and error testing my groupmates and I figured out that the terminal had to be run in a subdirectory (in this case intake-form-master) which was below the root, scr, and app folders. While I thought this was strange I didn’t think much of it because it ran and it worked. We should have looked into this more because it turns out we had a massive issue. Though our project was in github and therefore a “git” project, we somehow were lacking a git.ignore file on the very top level of the directory. This went unnoticed, and ended up becoming a massive issue. It seemed like every time I pulled the most recent version of the repository I would have to scrap what I had before otherwise I would get all different kinds of error messages. This was annoying due to the fact I would have to wipe all the project files off my local file directory and then clean install from github just in order to get it to run. After a long discussion with the professor and a good hour of troubleshooting and head-scratching, we figured out that our big issue was coming from this missing git.ignore file. The basic gist of this major file is that since it was in a subdirectory and not on the top level of our repository, every time someone pulled or made a change or did anything to/with github, everybody’s local machine paths were being pulled onto your personal machine with every clone or pull of the repository. Since no two path setups are the same between machines, you would get a – for lack of better words – big spaghetti mess of pathing and branching and basically git would freak out and it would give so many errors because it was having trouble figuring out where to push/pull/do anything. To remedy this, we ended up going with the nuclear option and eradicated the old repository, set up a new one with the most current working version of the project, and had our professor merge our new repository with the parent organization. This time around we have a git.ignore file at the top directory to ignore all those different paths and other things that were confusing our terminals, and we separated the project into frontend and backend folders, which are proving to make the workflow process go much smoother. At the very end of the sprint we had planned a meeting with a food pantry representative, which will occur during sprint 5. Next sprint we hope to see some major advancements.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Sprint Review #4

Hello and welcome back to Bendersons blog! This blog post will not focus on an apprenticeship pattern but will focus on the end of my last sprint with my teammates in my software capstone class. Like my last sprint reviews I will be explaining in depth, the process that my team and I took during this sprint and what tasks we got done and what we didnt finish but are working on finishing on the next sprint so it doesnt stay in the backlog for a long time. We only have about three weeks left in the semester so we are trying to crack down on things and get them done for the deadline that is at the end of the semester.

During this sprint, my team and I set out to complete numerous amounts of tasks. The easiest task that we did was transferring everything that we had in our Trello board to our github board that we created. The reason we did this was for one, to be able to label the specific tasks, as epics, stories or tasks based on how big of an importance and work load they were to the project at hand. The second reason was to have it be able to be seen by the other team in the other class that is working on the Food Pantry as well. Just to make sure we ‘ bumping into each other and doing the same tasks which would be redundant to the project. After transferring and labeling all our tasks that we had, we continued to work on the ones that we had to finish from our backlog from the last sprint. Nick was working on the intake form, making sure that it worked and whenever you ran it, it would go to a server and save what the intake form would say. Nate was working on the CSS of the project, making sure the project had that Worcester State logo and Worcester State blue to it to make it pop and look very nice and neat. Andy was continuing to work on the back end of the project, working diligently and making sure it ran perfectly, he even was communicating with another group member from the other class trying to get it done. Johnny was working on the database side of the project making sure that the intake form had somewhere to store the data once it was completed. I was working on coding mini features in the food pantry like for example, if they wanted to ever categorize their foods in the pantry into different food groups but I didn’t finish it as it wasn’t too important to the project. I also made a mock up for what the employees could see when they login in when they are working.

Next sprint we are going to try to get everything that we have left to do done so we are ready to present our project and hand it over to the food pantry. One problem we ran into last sprint that we hope we don’t run into next sprint is sometime out of the blue, our projects wouldn’t run in webstorm and we would have to restart our projects and reopen them. We basically have this last sprint to go with maybe a little quick sprint at the end to tie everything up. We are in the final stretch of the semester and Im looking forward to see what we come up with in the end.

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

Sprint Retrospective – Round Four

            A reflection
on what I learned from this week’s sprint is that a poorly managed repository
will create problems for your team and slow down the progress. After translating
the work done in Java to Angular during our restart from last sprint. The initial
IDE used was an online IDE called StackBlitz however this was abandoned for
WebStorm a week later. This is because we weren’t able to successfully connect
it to any repository so that other members could make changes. At this point,
we downloaded a copy and started to transition into WebStorm.

            During this
transition, we decided to get a working copy into the GitHub so that everyone
from both groups can work on it. 
However, we did not make note that a properly structured repository is
important. In this iteration of the repository, the root folder did not include
all the necessary files needed to function correctly. The necessary files were
not exactly missing from the upload but rather located in the only other
subfolder. This subfolder was generated since we downloaded a copy from StackBlitz.
By placing this subfolder into the original root folder, we had plenty of
workarounds to make the project work normally.

            At this
point in time, instead of importing the root folder to start working on the
project, we imported the subfolder. This was a workaround since it treated the
subfolder like the root, so it functioned normally. In this folder, it also
contained a git ignore file that could not be used since it was located in
there. This meant that the node modules folder was also included to be committed
back into the repository. In the majority of cases, it is not recommended to commit
that folder, but little did we know what was happening.

           In the end, the Professor and another member managed to get a working copy sorted and uploaded to the master. Now it is structured with all the necessary files in the root and two other subfolders, one for backend and one for frontend. It is neat and easy to navigate, which meant that we would be able to easily pinpoint where new services and components can go. At this point, we don’t have to worry that making changes would risk breaking the builds that other members spent time working on. In the future, I will not let this situation happen again and will be more careful when structuring a project!

            During this sprint, I focused my efforts on creating a submission service. Currently, the intake form includes a submit button that only returns what the user has inputted in the form into a new page. I started using an Expressjs server, which has allowed me to get use simpler features to connect the main form with a local server. Eventually, the default url address should be directed to an actual server. In this current iteration of the intake form, it sends the array to the localhost at port 3000. By running both the server and the intake form in WebStorm and submitting a completed form. We can see that the array of data is now retrievable on the server, which can be seen in WebStorm’s terminal for the server. If everything goes smoothly we can most likely store the data into some form of non-volatile memory later on.

References:
https://expressjs.com/

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.

Draw Your Own Map || S.S. 9

csseries281829For my second-to-last individual apprenticeship pattern, I have decided to go with something a little more relevant to my current situation–relating to starting my career post-graduation.

The Draw Your Own Map pattern caught my attention right away with “we might come across situations or colleagues or people in the society who will try to prove that programming will become an unsustainable activity as time passes by.” Throughout my job search process, I asked questions and requested advice from all different kinds of people across different fields (and especially within computer science) on how they knew what job they wanted to start with when given opportunities.

In the end, I must choose what I think is best for me in terms of what I’m looking for. I’ve finally came up with a list and that includes:

  • Having solid mentorship
  • Proper training (no room for imposter syndrome)
  • A company that tries to stay on top of new technology
  • Work-life balance that allows me to continue doing all the things I love to do outside of work and travel often

The Draw Your Own map pattern is very encouraging, reminding us that we have options elsewhere if we feel that our current company is hindering our learning and personal growth. I found that this pattern was interesting because I part of my decision-making process was “what if I am ____ amount of time into my first career and realize that I do not like what I am doing?” How would I move on out of that role to figure out what I may like better in terms of my day-to-day tasks?

The activity to list three jobs that I could do following my next was was really helpful to visualize future career possibilities. I know that we can always learn on the job and at new jobs but it is also important to build up your skills that can be transferred in the first place.

The pattern has helped me feel more confident in the decision I made to start out in software engineering. I will build up my skills starting here and then more onward from there!

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

Sprint 4 Retrospective Blog

For this sprint, I worked on several different tasks to improve the project. Firstly, we needed to get the project hosted onto Heroku, so I added some of the dependencies that Joshua Farrar had created in order to allow it to be deployed directly from GitHub. There were also some minor bugs that needed to be fixed such as typos, missing new line characters, etc. Next I worked on adding build instructions to the readme by working through installing the project on a clean windows install on a virtual machine in order to figure out every dependency needed to be installed. Then I added a landing page to the project which contained a list of all of the available endpoints, however this was a very bare bones solution as it was just a list of the endpoints with no further information. We decided to integrate Swagger 2 and Swagger UI to automatically create more description documentation containing endpoint descriptions as well as a UI to test the endpoints. There was also a minor issue where the example model of the object returned by the endpoint was showing up as empty. This was due to the way the endpoints were returning objects (showing the model of the “Object” class rather than the actual classes being returned).

From what I understand, Swagger gathers the endpoint data in the same way that I did, however, it’s far more detailed and robust. I think if I were to do something differently in this situation I think definitely I would do more research into the possible alternatives to solving each task in order to figure out what the best solution would be before starting to work on it. Had I initially looked into Swagger prior to starting to work on the landing page, I would have saved a lot of time. This is something that I should take into account for the future as it will be important to avoid wasted time whenever possible.

When making the build instructions, I think using a virtual machine to start from a clean slate was definitely the best course of action, as it’s important to see what it’s like for someone who potentially started from that state to get the project up and running. By doing this, even people who already have some of the dependencies installed will be able to follow through the build instructions by skipping steps that they’ve already installed. Although, I hadn’t considered the difference in the installation process between Windows devices and Mac/Linux devices. This project in particular doesn’t require many dependencies to get started, so it’s not difficult to create combined installation instructions, but I think for larger projects it would be smart to separate them. One of the differences I ran into was including the installation of Git Bash while Mac/Linux devices would be able to just use command line.

For the next sprint I’m hoping to automatically update the version number whenever necessary, as it’s definitely bad practice to have to update it in 4 different locations every time. Also, it would probably be a good idea to add an endpoint that gives you a products maximum shelf life and best storage method, given what the data would probably be used for.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Sprint Reflection 4

Our fourth sprint started out a little better, with us fixing the issues, stories and tasks assigned on Git so that our group could be more clear on what was being done and by whom. This also helps us communicate with the other food pantry group outside of class. Narrowing down our stories and tasks helped us more clearly define our goals and what we were working towards. Once we were done fixing the stories and tasks, we discussed who would be taking on what task.

I took on the task of adding a weight counter component to the intake form. We first had to determine exactly why the weight was being kept track of and what changes needed to be logged to better implement the weight system the food pantry needed. After determining some of the needs of our clients, I started working on making the new component. However, our group quickly ran into issues as we had a lot of difficulty in maintaining our git repository. We spent a good class period trying to fix some of the issues we were having just getting the working code onto our local machines.

As it turned out, our git.ignore file was located in the wrong place, and a lot of the local files that aren’t supposed to be uploaded and committed were being placed on the group repository. NPM and NG commands were not working properly and things were pretty disorganized. It was hard to get a working version of the front end so that I could begin to make my changes to it. After a long class discussion with the Professor, we discussed better ways to make sure the repository isn’t getting dirtied with unnecessary files, and talked about how to add changes to the main branch and utilize pull requests accordingly.

Now that we finally have a working copy of the form back on the repository, I have begun work on the weight counter again. It is going to be a new component that tracks a current weight, and can add/remove to the weight depending on user choice. Other considerations are storing the time and date that changes are made to the weight, and making descriptions for weight changes. Other future things to consider are logging which Student ID takes out weight so that customers can only receive from the food pantry once a day.

This sprint was very stressful as our group fully realized some of the issues that can arise from git repositories. Although it was mind-racking to try to figure out what the problem was, it was very useful exposure and practice to some of the mechanisms of git, as it will doubtlessly be very important in the future. Although I am still wary that I can use git commands perfectly, I am definitely much more equipped to deal with repository related issues in the future, and am more aware of some potential issues that can arise from a misplaced git.ignore file. Hopefully I can avoid some of these problems in the future, as git problems can get annoying fast.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Expose your ignorance

The apprenticeship pattern “Expose Your Ignorance” refers to the scenario in which you’re assigned a project but you are unfamiliar with some of the technologies that are required. Under the expectations of your colleagues, you may feel pressured to hide your ignorance so as not to seem incompetent as a developer. The best course of action, however, is to tell people the truth.

I can see why people might be uncomfortable with the idea of exposing their ignorance. However, I think that anyone who is more interested in actually becoming a better developer rather than focusing on what kind of developer they’re perceived as would be able to agree with this pattern. Sure, you could choose to pretend that you have the knowledge to complete any task already and then try to learn those technologies on your own, but there’s no guarantee that you’ll be successful. If you promise to deliver something and then later have to admit that you’re less knowledgeable than you initially let on, then you’re going to end up worse off. By admitting that you’re inexperienced with certain required technologies and asking questions, you’re able to show that you’re capable of learning while also being able to learn much faster with the assistance. One common phrase that I see commonly used is to “fake it till you make it”. I don’t doubt that there are some people who will look down on you for exposing your ignorance, but as long as you continue to focus on learning as effectively as you can, then you’ll be much better off in the long run.

One of the things I found interesting in the excerpt was to write down five things that you really don’t understand about your work and to put it where others can see it. This is definitely an extreme way of exposing your ignorance, but if people who see it are able to answer your questions and cross off an item on the list, then you’ll improve far faster than if you were to try to do the research alone. I’m not saying that you shouldn’t try to solve problems on your own, but it’s in everyone’s best interest to seek advice whenever they feel like they lack knowledge.

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

Apprenticeship Blog: Use Your Title

Hello and welcome back to Benderson’s blog! This week we will be discussing another Apprenticeship Pattern that is important to anyone getting a job and is afraid of being ridiculed for your lack of information to work in a computer science job. This pattern is called “Use Your Title” and it discusses being promoted into a role such as “Senior/Architect” of a business and how to approach such a role in a job. You may feel like that you don’t deserve this job or you’re not right for the job but you got to believe in yourself to succeed and be the best you can be. The pattern talks about not letting the title affect you from your performance and just keep doing you and if you doing you gets the job done than that is all that matters in the end. The pattern also talks about the other side of the coin where if you have an unimpressive job title but all your buddies have a cool upper job level and are succeeding, don’t let that distract you from working hard at your job and feeling like you deserve better. You’re doing the best you can and when your time comes, you will be called up and if it doesn’t happen then just find another job that appreciates you as much as you think you deserve. The pattern suggests in the end that you write down a long and descriptive version of your job title and reflect on it and what it means to you and you will see if you’re right for the job.

This apprenticeship pattern really hits home to me as I feel like I won’t know enough to get a job at any level and hold it long enough to make myself big in the business. That could me just not having enough confidence in myself which is probably the case. This pattern is helpful for any kid in my position who is fighting themselves mentally trying to psych themselves out of a job that they could easily do. You’ve gone through four years of college education in the field of Computer Science for this job, don’t let yourself put you down and make you think you will not be able to do it. Also no matter the job title you get, it is still a job and if you work hard enough you will be able to climb the ladder and get to where you want to be. Thank you for joining me this week on this inspiring edition of Benderson’s blog!

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