Category Archives: cs-wsu

Sprint 2 Retrospective

For this week’s blog, I will be talking about our second sprint working on the open source food pantry project. This sprint was a bit unique as to the first one since it is mostly about communicating with the customer.

In this sprint, I learned a lot about the communication between us, the developers, and the customer. I learned that it is not a simple process. At first, I thought that it would just be a simple interaction, they give us what they want or how it should look like, and then we try to create it and meet their demands. But that is not how it goes at all. There was a lot of interaction that we needed to do since the customer does not know what they really wanted. There is also the issue of communication. Most of the time, it is hard to get hold of the customer and we have to wait for them to respond to us before we could even move on with what we are doing. I also learned that starting a new project is like an open-ended question. while planning on this project and asking the customer questions as to what they want, it just seems like they do not really know what they want.

During this sprint, we have decided to change our focus from making the foodsaver REST API onto making the food pantry software since the other team has already made it. This sprint was mostly about communicating with our customers. The first meeting with the customer is with Serena. Serena works on Thea’s food pantry and knows how the pantry operates.  During the interview, we asked how the pantry operates. They have a google form that is filled out once by every student that goes there. It asks about the number of people in their household, their income level( whether they qualify or not), and what kind of help or services they are already receiving. If they already filled out the form, they only need to swipe their card preferably but for now, they just take note of the student’s ID number. Then they weigh the items that are being taken by the student and record it. They only keep track of how much weight is taken and how much weight is left on the pantry. 

The second meeting that we had was with Joanne, she has been helping guide the student-led-food-pantry initiative. Before our meeting with her, we tried to come up with questions to ask. Most of the questions we came up with was just a clarification on the information we got on the first meeting. In our meeting with Joanne, we asked her again about the forms and what kind of information they are storing. Since they cannot give us private information, we asked if she could just blur out the pieces of information and leave the column headers. This meeting was mostly trying to learn what the food pantry does and how they get food in and out. This meeting also opened the topic with the one card system and how they want it to show information about the student once they swipe.

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Confront Your Ignorance

For this week’s blog, we will talk about confronting your ignorance from the Apprenticeship Pattern book. This will be a continuation from the last blog Exposing Your Ignorance.

Now that you have let your teammates know that you are lacking in some skills, it is now time to deal with your ignorance. There are tools and techniques that you need to master but you do not know where to begin. Some of them are things that are expected knowledge from you that everyone around you already knows.

So what should you do?

The book’s solution is to pick one skill or tool and actively fill in the gaps in your knowledge about it. How should you do it is up to you. Whatever works best for you. For some, the best approach is reading all the introductory articles. Others find that looking at the code is a better way to understand it. They also recommended asking around if anyone is also trying to master these skills or ask a mentor that already have these skills and if they are willing to share what they learned.

I find this chapter interesting since it was tied to Exposing Your Ignorance chapter. To do this pattern, you will need to expose your ignorance first. Using this pattern in isolation might lead to a culture where failure and learning are unacceptable and everybody just keeps to themselves. Also, your employer has certain expectations from you and might not be understanding of your educational needs that would get in the way of the successful delivery of its project.

Confronting your ignorance is probably one of the things that you will be doing over and over again in your workplace. Most likely, your first few months in the job would be a learning curve for you. Figuring out what tools they use, how it works, and how you could use them would be the first challenge you will face.

This pattern changed the way I think about confronting my ignorance. Usually, I do everything alone and try to solve things alone. But that seems like a band-aid solution to the problem. It is better to ask people who have mastery of such skill and see if you are doing it the right way, so in the future, you will be more knowledgable and can be a master of this skill as well.

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

Expose Your Ignorance

This week’s blog is going to be about Exposing Your Ignorance from the Apprenticeship Patterns book. This pattern tackles the problem of not knowing other technologies in the workplace. The people that are paying you are expecting you to know what you are doing at the very least. Your managers and team members need confidence that you can do the job, but you are unfamiliar with other technologies. It happens to everyone. Especially if you are a new hire.

This pattern is very interesting to read. Normally, we do not show our weaknesses to others. We tend to keep it in even when we are having a hard time dealing with something. I would assume it also happens in the software development industry. No one wants to be seen as ignorant and be looked down upon that is why sometimes you try to hide these weaknesses. But this pattern is different.

This pattern suggests that you show what you are lacking.  Telling people what they want to hear is not a good way of building relationships and them having an impression on you. Tell people the truth. Let them know that you are getting the hang of it and are still in the process of learning. Reassure them with your ability to learn and not by lying to them that you know how to do it.

The most effective way to do this is by asking questions. There are no stupid questions. That is what every teacher would tell you. But it is not easy. Sometimes, people have expectations from you and it can be hard to ask “stupid” questions. There is also a sense of pride when asking a question. Sometimes you would look around you to see if you are the only one who did not understand.

I personally have this problem. I almost never ask a question. I always thought that I do not want to bother the whole class asking a question that seems like only I have a problem with. I would usually just tell myself that I would just look it up online and answer the question myself. After reading this pattern, I would definitely try to change that habit of mine.

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

Sprint Review I

As we started the capstone class, we got the teams set up and started to prepare ourselves to participate in the project. Each team got assigned to one of the two projects, and I and my team are going to work in the AmPath EMR project. The professor, who is going to play the Product … Continue reading Sprint Review I →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

In this blog, I will be talking about our first sprint retrospective. My team is working on making free food pantry software.  In the first few days of class, we were doing research on different food pantry software. There was not much we could find that is open source and free which kinda sucks since food pantries are not for profit. Since these softwares are not free, we could not even demo them, therefore it was hard to get an idea on what this software should look like and what functionalities it should have.

After getting assigned into teams, our first sprint started. The first day we all sat together, there was some initial set up that we had to do so that we could communicate with each other and have tasks assigned to each of the members. We set up a task board using trello, joined the slack group for our team, and shared everyone’s contacts and git usernames. In our second meeting, we were trying to figure out where to start. We know that we were working on a food pantry software but we were not sure as to what we should actually be doing since other colleges are working on the same software as well. Then I saw on the slack channel that the other channel that they needed a REST API. So we started planning.

The first thing that we talked about is what functionality this REST API would have. The only thing we know is that we need this API to read a JSON file from the USDA’s website. After looking through the file, there was a lot of information about food and their expiration and some other stuff like tips on cooking or if they need to be refrigerated. Since we know that we are gonna be hosting this API we discussed on where to host it. There were a couple of options but we settled with Heroku since there is a free tier option although it might be a slower service since it has a thirty seconds time out when your API is not being used. Then we talked about which language we are gonna use. Researching about reading a JSON file, most of the tutorials were in Java and since we all have experience using Java, we have settled on it. The next thing was setting up an initial commit on gitlab for our project. Most of it was done by Sean and he was handling most of the task board as well. While the others work on figuring out how to host our API on Heroku.

To host a Java application on Heroku you need three things:

  1. Java 8* 
  2. Maven 3*
  3. Heroku CLI and an Account

After that, we researched how to read and write a JSON file. We are using JSON.simple to parse the foodkeeper.json file.

Steps I took:

  1. Download JSON.simple jar file
  2. Import the jar file into Eclipse by adding it to your project’s build path
  3. Added json.simple dependency into the pom.xml file
    1. <dependency>
          <groupId>com.googlecode.json-simple</groupId>
          <artifactId>json-simple</artifactId>
          <version>1.1.1</version>
      </dependency>

There are a few tips on reading the JSON file.  JSON file consists of array and objects so you just have to create an object or an array depending on what you are trying to get.

ex. Array [], Object {}

A JSON file might have something like this:

“sheets”: [
{
“name”: “Version”,

“data”: [

That means that there is an array called sheets, and an object inside the array called “name”. You can get to it by creating a JSON object first and then creating a JSON array like this:

Object obj = new JSONParser().parse(new FileReader(“foodkeeper.json”));

JSONObject jo = (JSONObject) obj;
JSONArray sheets = (JSONArray) jo.get(“sheets”);

We still have a lot to do, so hopefully, on the next sprint we could implement and get all the necessary information from the JSON file and have methods to return them as an object or as a JSON file.

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

Sprint 1 Retrospective

This past week has been about trying to get the ng2-amrs environment working, and trying to get through the errors that show up when running the npm start command. I have learned a lot of the steps to take in order to approach this problem, although I am still not finished with it. I am not sure that I would proceed differently, I just think it would have been better if these problems were already known, since everyone is having them, and it would have been better if there were more instructions to deal with these expected problems. Most of the approach involves googling error messages, which can definitely be applied in other situations.

Most of the week was spent looking up different npm, ng and node commands, googling error messages, and trying different combinations of the commands and re-installing things after nothing worked. The reason that I took these steps is because I really do not know what I am doing and running through permutations of commands seems to be the only way to move forward to get the program to run without errors. A lot of the process involved referring to the slack channels, where teammates and other teams have run into the same problems and found solutions.

The ng2-amrs readme on the github page says to run the ng serve command for a dev server. What it does not say is what to do when this does not work. A guess at the problem involves version issues with angular, npm and node. Different versions were attempted to try to solve errors. Most of the steps involve googling the error message, which leads to a stackoverflow post that says to install a certain thing that solves the problem. When it does not solve the problem, it becomes very unclear what to do next. Changing versions and re-installing things has not seemed to work.

I have deleted and re-cloned the ng2-amrs folder from github. When I run the ng serve command, I currently see an error Could not find module “@angular-devkit/build-angular”. I google this and stackoverflow tells me to run npm install –save-dev @angular-devkit/build-angular. After I do this and re-try ng serve, a few more errors show up that do not seem to be as easy to deal with. One teammate found npm-check that will list missing things and things that are out of date, so I installed and ran that and had it automatically install everything it found using npm-check -y. After that finished, I re-tried ng serve, and it came back with a new error about styles.scss. I searched the error and found a command npm rebuild node-sass to deal with it. Running ng serve again, now I get some typescript errors. I check the group slack channel and see the command npm start, so I try that, and the next error I see is Error: Can’t resolve ‘pouchdb/dist/pouchdb’. I try running npm install and that brings back the scss error, but this time the same command that fixed it before does not fix it anymore, and it complains that I use a 64-bit operating system. I downgraded to node 8.12.0 and re-tried fixing styles.scss and running npm start. It actually seems to be working now. It says compiled with warnings, I open localhost:3000 in my browser and the ampath page comes up.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Use Your Title

While you work in the software industry, you can be promoted, formally or informally, to some high position that sometimes do not fit to your knowledge. You can be promoted to senior or lead positions, but on the other hand you have to explain away tue difference between your skill level and your job description. … Continue reading Use Your Title →

From the blog cs-wsu – Kristi Pina&#039;s Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Concrete Skills

This week’s blog is about Concrete Skills from the Apprenticeship Patterns book. It talks about what to do when you are looking for a role on a talented team that will provide you with better practice and enhances your learning, but sometimes these teams do not want to be bothered. Sometimes, having a new hire means you are going to be teaching them again from the beginning and these new hires do not offer anything to the company or team yet since they do not know how things work. This section of the book talks about how to deal with it.

In this section, they talked about concrete skills. They said that it is important to have some concrete skills so that you will be trusted to contribute indirectly until you start to gain their trust. It will help reassure your team members that you can be put to good use rather than being a burden that they have to babysit. They added skills like writing build files in various languages, basic web design, JavaScript, and knowing some standard libraries in the language of choice.

I find it interesting that the book suggests that you look at the CVs of the people whose skills you respect and identify the skills noted on the CV and determine which of these skills would be useful on the team that you want to join. Implement these skills on your own project, make sure that you know how to do them and how they work.

I completely agree with this pattern. I think knowing some concrete skills will come a long way when looking for a job or when starting one. You can’t always rely on your team to teach you stuff and they can’t also just ask you to do things that you have never done before right away since they are also working on stuff and not just there to babysit you. They will expect you to work and you have to prove to them that you are capable of being on the team. That’s why I think having concrete skills is good.

 

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Why Doctors Hate Their Computers Blog Post

I am writing this blog post in response to the The New Yorker article “Why Doctors Hate Their Computers” by Atul Gawande. I thought that it was an interesting story. In general it seemed to be a look into how doctors and other medical healthcare workers are fed up with the poorly designed software that they are being forced to use. Some shorter stories about scientists and engineers are also included, and they have similar complaints, which shows that this is not just a problem among doctors using electronic medical records systems.

The main problems that seemed to make the doctors’ jobs harder was the fact that the programs required them to fill out excessive amount of detailed information before they are able to move forward. Their workflow is being interrupted and they are unable to do their job in the same way that previously worked well. The new computer interface may have streamlined some of the process, but it became too bureaucratic and inflexible. The fact that some of them decided to work with the I.T. department to hack the system and write their own better interface was not surprising given how much complaining came before that. It is obvious that the users of the system are not the real customers. The real customers – the people who made the decisions about how the program should control how the doctors work – seem to be the hospital administrators. They worked with the software engineers to design a program that forces the doctors to pay more attention to what they need the doctors to do for them, instead of what the patients need.

I do not think this article will change how I work or how I think about the things I make at the moment, but that is just because I am not making any sort of widely used software for important applications like medical records systems. In the future, though, I might recall this article if I happen to be working on some software application that has a variety of different users with different needs and I am given only one perspective. I imagine the developers of the system that the article is referring to might have been wondering about some of the user experience details. If they recognized that the users of their software are not the same people as the ones telling them how to make the software work, then they might have already had some concerns of their own that they were not able to address because the users, the doctors, are not the ones in charge of how the program they are going to be using is going to work. Something I do wonder because of this article is about how these problems can be avoided.

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

Unleash Your Enthusiasm

For this week’s individual apprenticeship pattern, I chose Unleash Your Enthusiasm. This pattern talks about how to handle the enthusiasm you have for work. As a software developer, you will most likely work as part of a team. Most teams are not as passionate or overly enthusiastic about technologies anymore. Most of them are focused on delivering the next project and trying to improve aspects of the development life cycle that are causing them hindrances. That is why sometimes, unleashing your enthusiasm can get people rolling their eyes on you. Some teams are particularly not welcoming of newcomers. You should be careful when unleashing your enthusiasm. It is best to observe the team first.

I found it interesting that unleashing your enthusiasm is in the pattern. I was never really an enthusiastic person, I am more on the analyze first before I do anything side when it comes to enthusiasm. I am actually envious of enthusiastic people since they just speak their minds out and seem to not care what would happen. I always thought that being an enthusiastic person was really great but after reading this pattern it makes sense that you should be careful when unleashing your enthusiasm. Some people do not want to get bothered while working and can get easily annoyed by people asking them questions all the time. But there are also the opposites who loves hearing questions and giving you advice on what to do.

This pattern has caused me to think about ways to approach different people in the team. I think most teams have a diversity of behaviors and some would be welcoming than the other. I think that trying to get the feel for your team before you unleash your enthusiasm would be the best solution to this problem.

I totally agree with this pattern. I think it is good to know that not everybody is willing to listen to you and that you should approach the team carefully. I think you should still be enthusiastic, just be mindful of others. This pattern would definitely help anyone, not just software developers in their life.

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