For this week, I have finished up Sprint 3 and I would glad to be talking about it.
What I wish I could done throughout this sprint was to finding
Links:
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
In this sprint, our group was divided into the Food Pantry project and the Foodsaver REST API project. Joshua was mainly working on hosting the Foodsaver REST API in Heroku. While the others were focused mainly on the Food Pantry software. I, on the other hand, was kind of in between both projects, trying to help out on the Foodsaver and at the same time help with planning the Food Pantry project. Our first meeting was pretty much figuring out what are some stuff that we are going to need to proceed on building software for the Food Pantry. We have decided that we are going to need the forms that they were using. This form is the one students would fill out during their first visit in the pantry. Since they were using Google Sheet to store all the information about a student that visits the pantry, we have also decided to take a look at a way to use Google Sheet API to connect to the software we are going to make. We have also decided to make our own Google Form mock just to see if that was all the information that we needed.
In our second meeting, it got a bit interesting. Remember how we were waiting for them to send the Google sheet mock with the attributes they want to collect? Well, we never received it before the break, and then they probably forgot about it during the spring break. After the break, I got occupied with trying to run the Foodsaver API and helping Joshua dealing with Heroku. Since Andy was the one who wrote the code for it, we weren’t quite sure how he set it up, but the Heroku hosting seems to be working. The Foodsaver API would appear when you go to the address Heroku gives, but when you click on the API, it does not return anything.
This sprint was somewhat uneventful for us I might say. There was a lot of waiting for the client, and a bit of miscommunication. This sprint was about patience. I learned that communication is really key to working on successful projects. There are going to be times when you would have to wait for the client to get back to you since they keep on forgetting to send things that you need to even get started. There was a lot of wait time for us, and we just kept on planning, trying to figure out ways to proceed with the food pantry project. If something like this ever happened again, I would probably not stop bothering the customers until we get what we want so that they can get what they want, and hopefully come to an agreement.
From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.
At the beginning of the third sprint we had some direction on what we were going to do finally. Of all the components we looked at we began to find the most interest in the bottom navigation bar. Our plan was to look at what might be needed to accomplish this component, and what direction… Continue Reading →
From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.
This is Sprint 3 blog post for the IncreEdibles team. Since we have changed our direction of the project. We moved our focus to WSU Food Pantry, we thought that creating smaller scale is more effective to learn. We are trying to understand how the food pantry operating. We also need to know more about how our costumer operating. It is not simple, we had some difficulty on the communication. We don’t have direct communication to the costumer.
Since this project is new, even for our customer. It’s still updates and revolving. Our costumer doesn’t know how to implement technology to their project. We need to know what they are looking for, and what feature they are going to need in the future. We got to the first meeting with the costumer recently. That clear a lot more with our understanding with the project. Though our first meeting, we learned how our costumer set up. Although its simple, their way is not as effective. Which is good for us, we can help and problem solving. We run into few problems, as planning. First, our costumer problem with the technology as I mentioned. Second is the Onecard system, we want to know how to implement to our program. What happen when the card swipe? How to get that information to work with our program. It is difficult because it is also sensitive information. It deals with people information; the school don’t want this information to wrong doing. We want to build our program to be more effective and convenience. When person with one card come in, swipe the Onecard will display their info and make easy to input their food outtake. We hope the IT department with help us with that. Third, we still have question about the operation. After the 2nd visit we got more comfortable with your costumer. We feel we can ask our customer. Other food pantry team on other session is also working on similar project. We need to have communication with them, so we have work together. It is also not easy, since they have different timeline. And the online communication, Slack, is not as effective as in person.
In our next meeting we are planning into what are the next step. We will wait the team-fig response, so we know what teams are working on. And how to divide our work and who to help each other. I want to fully understand the food pantry operation. Then we have implemented important feature correctly. The next steps are design and build interface for the website. We want to have an interface design that simple and effective. We want to learn about manage database and print out report as customer want. We want to learn how developers work together in team and on project.
From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.
This sprint definitely was more productive than the last one, for the main reason that the scope and implementation of our project is beginning to take shape, and we are gaining more clarity about what we have to do to achieve our goals. At the end of the last sprint, everyone on our team decided that the component that we would be building would be the tab system for adding, modifying, and displaying information about patient records for multiple patients.
Early on in the sprint, Sam found some solid resources that angular provides with multiple variations of tab structures to choose from, and the skeleton codes were provided too. We took a little bit to decide which kind of style, animations, layout and otherwise we wanted to go with, taking into consideration that the everyday users for the project will be medical professionals who have to constantly have multiple tabs open and switching around. We didn’t want our component to feel cumbersome, we definitely value having a sleek easy to read style, and fast animations to streamline their workflow as much as possible. This design goal led us into ruling out certain features that would take a long time for animations or had unnecessary clutter.
After getting a consensus on our group’s design philosophy, seeing what tools angular had to offer us, and deciding on a general schema for our tab component, we discussed in class the need to use Ampath’s included services to make our project compatible with Ampath and useful in an electronic medical records system. Thankfully Andrew found all of that information in their core repository, which saved us a ton of investigative work. So what we have to do now is search through each of the services and their specification mocks to find which ones are relevant to our component and then we can begin creating our prototype.
At this point in our development, we have started to plan for creating a wireframe program which applies both the design we want, as well as the services we need to provide that contains the information and formatting that is relevant to the Ampath vision. Beginning the next sprint we all believe we should be ready to start coding and getting some demonstrable progress under our belts. We will have created a file with our skeleton code and we are hoping to push it to our local repository as soon as we can.
I am very pleased about the progress and mode of work with our group. We all seem to reach a consensus about what direction to go in quickly and effortlessly. We are all finding small ways to help further the progress of our team in our own ways, and at some point during the sprint each member of our group was able to contribute something helpful to all of us. We are all understanding and willing to divide and tackle any particular work tasks we need to get done. I definitely wouldn’t change anything about our group dynamics and I am satisfied that we are successful.
From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.
The white belt as an apprenticeship pattern is what it sounds like. You are at the beginning of your journey and have a deep understanding of your first language. The problem arises when you are struggling to learn new material and it is harder to piece things together than when you started learning your first programming language. The author relates the solution back to Star Wars quoting Yoda, “You must unlearn what you have learned”. By doing so, this accelerates the learning process because you don’t try to relate things back to your current language but instead connect neurons together when trying to understand the new concepts you are learning.
I agree with the many things the author taught in this apprenticeship pattern. That too is how I learn new tools and technologies on my own but on the other hand, I always try to relate it back to my strongest, most knowledgeable language, and see if there are similar concepts and if there are ways to carry out a task more efficiently.
From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.
From the blog mrogers4836 by mrogers4836 and used with permission of the author. All other rights reserved by the author.
I feel as though this apprenticeship pattern will apply to most of us who is nearing their graduation date. Most of us only have classroom experience when it comes to developing and soon we will be part of something bigger than just us. We will be joining an organization that has big ambitions and aspiration to see those goals to the end. What should we expect? How do we learn to work through our problems? How do we learn at all?
The author suggests seeking out someone who has been in this position before and strive to learn from them. Eventually someone will accept you as an apprentice and you would remain under their supervision throughout the apprenticeship while working towards becoming a master craftsman. Now this ‘master craftsman’ who will accept you as their apprentice does not have to physically be available. It could be someone in an online community; anyone in the field that knows more than you do. The way to do this may be to pick a community that is active and learn from the individuals there.
I actually like this pattern because I feel as though all of us need a mentor when we are in the field to help us progress through our development. I hope to apply this to myself and learn as much as possible.
From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.
We all want to get better at something but we often don’t really know what to do to get better. Sometimes, we can find ourselves repeating the same mundane tasks in hopes that something will just magically change or snap and we will be better at whatever it is we are doing. However, this couldn’t be further from the truth. When trying to get better at programming, you often have to practice things that you are not comfortable with. That’s just how learning works. In order to learn something new or get better at something that you need to improve on, you need to step out of your comfort zone in an environment that you feel safe doing so. Although practice may not make perfect, it does make permanent. Even if you are trying something new and you don’t quite get it right away, all that practice beforehand and grinding will not be of waste. You will just be reinforcing your skills, enhancing you previous knowledge. This pattern is great because it tells you to just keep working at whatever task you want to get better at. It also points out that just because you are repeating the same thing, that doesn’t mean you are not getting better at it. Choosing the right thing to practice every day is just as much as a skill as repeating something a lot. They are both important in that you are learning and reinforcing at the same time. Some of the books that the article pointed out that are good ways to ensure you have interesting exercises are Programming Pearls, More Programming Pearls, and Etudes for Programmers. The authors of these books understand that getting fundamentals deeply ingrained does not stop being useful. Practicing anything, as long as you understand what you need to do, you will always get better at something. That is just how practice works. Even if you think you are not getting better, you are still simply reinforcing already known ideas. This pattern is a great example that you can still try something without the fear of failing, because you just get better at it regardless of the outcome.
From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.
In all honesty, this sprint was definitely the one where we’ve made the most progress. During this sprint we were finally able to get access to the input form and sample output from Joanne and her graduate assistant, Michelle. It took several weeks of continuous emails and a face to face meeting to finally get access to the documents. This has been the story of this project for this semester at this point. From my experience during my internships, the length of time to get a response from someone can vary and maybe it is different because of the many different projects and classes that everyone involved is responsible for, but this seems a little outside what is reasonable.
Our biggest problem to this point in the semester has been a lack of communication between our customers and the other necessary parties that can get us moving with the key details of our project. We were warned at the beginning of the semester that our customers likely didn’t know what they wanted and this couldn’t be more accurate. They have the best of intentions but lack the technical foresight to think about how to organize their project to make it any bit future-proof. We’re doing our best to find a happy medium between a complete rework that makes it more scalable and continuing to follow the flows that they are just becoming familiar with.
The other group working on the food pantry project is doing more of the heavy lifting at this point as they’ve already started working on the interface for what will hopefully one day be the new food pantry software system. It is difficult to communicate with them as we’re basically on opposite schedules and everything is on a two day delay for the most part but we are making the most of what we can do.
My role for the last two weeks has been more of a product owner compared to a developer and it has for the most of this semester. I’m not upset about this as it has been a different experience than what I am used to. I’ve been our point of communication with Joanne and the food pantry workers as well as often the one organizing our Trello board and conducting the planning meetings. There is definitely some overlap between product owner and scrum master responsibilities but I haven’t done almost any code writing this semester. I honestly think what we’re doing better as a group as the semester continues to roll on, is rolling with the punches. We’re getting better at reacting faster to the curveballs that are being thrown our way. We’ve been told that everything that needs to be on the current intake form is already there, but after mere minutes of review, we’ve noted several questions that are missing based on the reports we are being asked to output for the final project.
We’re also getting better at splitting up the work between our group. The roles have yet to see much change as the semester progresses but again, I’m not upset about this and it doesn’t seem like anyone in my particular group is. We’re assigning stories/tasks better so everyone has something to work on throughout the sprint and we’re documenting who is working on what in our Trello board. Hopefully we’ll be able to utilize the issues system on Github as soon as our repository situation is resolved but we’re making the most of what we can do with the tools we are given. We’re noting down which particular project each issue/task/story belongs to by noting “[project name]” at the start of the blip on Trello. Overall, organization has improved and hopefully we’re developing a standard that can be utilized well after we are handing off this project at the end of the semester.
I would provide links to the projects we’ve worked on but they are exclusively private. This includes our private group Trello, Slack, and the access link to our newly acquired mock form/output.
From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.