Category Archives: Sprint-3

Sprint 3 Retrospective

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.

The IncreEdibles Sprint 3 Retrospective

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.

Sprint 3 Retrospective

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.

Sprint 3 Retrospective

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.

Sprint -3

In this last sprint my team and I ran into a few complications. We were trying to figure out how to go about creating these components that we are supposed. The class as a whole decided the best route to take was to break the amrs app down even more on GitHub so that each group would have their own component and there would be a ‘master’ branch so in the end we could push and merge everything onto that.

Some difficulties we had to work around included having to know what the layout would utilized because everything was sent over Zeplin but created off another platform (maybe adobe). We definitely are on the right path moving forward for the next sprint.

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.

Sprint Retrospective – 14 March 2018

This sprint, unfortunately, was cleaved in twain by Father Winter. There were multiple white-out blizzards, which resulted in numerous missed class meetings. This proved to be a serious blow to productivity. In the face of nature’s obstacles, however, my group did manage to get more done than we would have anticipated had we known how little we would have been able to collaborate.

This sprint, we solidified much more of our understanding of PouchDB and the structure of our service. Due to the weather, much of our progress was done separately except for during a single impromptu meeting on Discord, so a gap in our respective grasps of the service has begun to form. However, in some capacity, each of us managed to learn and share with each other something new about PouchDB. As for me, I was concerned with the code itself. Much of my time in the first few days of the sprint was spent tinkering with the exercises we had completed during the previous sprint, in an effort to attain more than a working knowledge of PouchDB’s functionality. To this end, I redid the exercises from memory as best I could, but also framed the app in the context of Ampath’s patient data. The result was a rudimentary form of what the final service may look like – albeit without encryption, decryption, login, etc.

Of course, catastrophe managed to strike. As it happens, there are two versions of PouchDB: a JavaScript version, and a TypeScript version. We had been writing our code in the former, and wished to switch to the latter. In terms of syntax for the programs we’d written, this wasn’t all that major of a change, as we only really needed to change the import statement at the top of the file. Installation, however, was another issue. I spent hours with Fuve and Caleb one day, fighting with install errors that would pop up for one of us but not the other, until eventually Fuverion made some breakthrough that fixed everything. Admittedly, I still have no idea what he did, I’m just thankful that he did it.

Due to the inconsistent meeting times, coupled with the headaches brought about by switching to the TypeScript version of PouchDB, this was about as much as we were able to get done in this sprint. We have in fact discussed this already in an in-class retrospective, and have all agreed to make better use of our channels of communication: Slack, Discord, and a group text message thread between the five of us. In doing so, we hope that future unforeseen bouts of meteorological calamity will have far less power over our capacity for progress.

In this sprint, a very critical lesson was taught (or, perhaps a better word may be “reinforced”) to all of us: Do not assume that anything will go as planned. Do not assume that anything will be smooth, or easy. Because in the event that some blizzard comes along to remove two consecutive meeting periods, it’s far better to have modes of communication available for use and at the ready. In future sprints, I will work to ensure that my communication with my team is upheld in the times where I am, or any of them is, unable to be present.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 3

This week’s Sprint retrospective we decided to look up different types of encryption services. Everyone had an encryption service that they were to look up and then write a shorts program see how it works. We decided out of all the encryption service out there we wanted to look at crypto-JS, Forge, web crypto, pouchdb, and bcryptjs. The one I researched was forged encryption service. It did do what we wanted however we decided not to use it because it has not been updated in 4 years so since we are working with sensitive data and did not want it to be leaked forge was out of the picture. Pouchdb was another one that we ruled out because this encryption service was made by someone that did it during their free time so it wasn’t updated regularly. The encryption service that we did decide to use was crypto Js because it was the simplest encryption service that we could have used and is not too old and the last update was not that long ago.

Finally, we decide what kind of encryption service we wanted to use. We started to talk about how we encrypt the data that is given to us. Oran gave an idea that we would encrypt the data as it comes our way so it would act like a blanket. Whenever some data such as a string, array, and any other sensitive information would come through the encryption service. It would take that data and encrypt it. However Oren had a colleague that was familiar with encryption services and he told him that data like that should be encrypted already. So that brought up a good point we want to ask Ampath if they have the data already encrypted or is this encryption service itself supposed to encrypt the data that they have. So for now moving forward we decided that we’re going to act like they need the data to be encrypted. We also need to start working with the other teams to know what data that is going to be given us to us and if cryptojs would be able to work with what they are planning.

So for the next week I will be studying up more on crypto Js and then trying to help the team write a basic program that can take inputs and give outputs of strings, letters, and words. I learned a lot about encryption during the week that we were encryption service in the beginning I did not know how the encryption service works such as what was salt and encrypt a string how would it remember what encryption that use to the string and if you were to send it to another device to be encrypted with that device need that same type of program to unencrypted password

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 3

During sprint 3, I worked more with encryption services and Webstorm trying to create a working an Angular app that encrypts and decrypts data using Webcrypto API. I have been researching the Webcrypto API for some time as it is completely new to me, including Javascript. I learned that there are not many Angular related examples of the Webcrypto API but I did find an example using Crypto JS that I am also interested in and I believe it will help me understand cryptography and how its implemented in Angular.  This resource had a lot of good information including why Webcrypto API is a good choice.

  • WebCrypto offers protection against overwriting (in Chrome), since window.crypto.subtle is read-only. This is good news for security but bad news for usability, because it makes it harder to work with polyfills.
  • Non-extractable keys make it very hard for attackers to steal your keys. Therefore, the “JavaScript is always insecure” issue is mostly resolved. You can create a key, store it at the client, and use it. But if you don’t specify it, you can never read the key, which means that attackers cannot do so. Tip: Use IndexedDB to store the keys.
  • WebCrypto uses SSL only (with the exception of localhost and extensions) which ensures that the data sent between the web server and the browser is encrypted and secure.

I think the team worked well on the day we were together in class. We missed class because of the weather and that was unfortunate because I feel more accomplished when I get to work with my team face to face. I am working hard learning about encryption, how it works, and what the current standard for secure web encryption is so we have a good path to start after getting the o.k. from the AMPATH team on a direction to go. I believe we are all learning something new about web cryptography, as we are all focusing on different javascript libraries. I plan to bring what I learn from the Webcrypto API to the team and allow us to make an informed decision on what encryption library we should choose.

During spring 3, I spend most of my time researching Web Cryptography API, including webcrypto-examples on GitHub. I’ve been using what I learn from the documentation and examples to get a working implementation on an app of my own to help the team move forward in creation of an offline module. I started focusing on the Webcrypto API because it seemed like a good starting point as it’s a popular javascript library that outperforms others significantly. The algorithm I am focusing on is AES-GCM, “the symmetric block cipher ratified as a standard by National Institute of Standards and Technology of the United States (NIST)” During the latest sprint meeting the team, we decided to keep working on our respective projects implementing an encryption service, once we meet after spring break we will began to make a game plan as to what to pitch to the AMPATH team.

The post Sprint Retrospective 3 appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

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

CS@Worcester – Fun in Function 2018-03-16 21:38:34

Our team began work on the offline login service this sprint. We decided to first investigate AMPATH’s current login process, which turned out to be spread over many different components and services. We found where information was sent to the servers for authentication purposes and determined that what we needed to do was to point to an offline database instead of the servers. There would be no point in creating an offline login service from scratch, and in fact we needed to use their implementation if we wanted to meet the requirement of seamless transitions from online to offline and back. We created a mockup on Balsamiq of what we thought the finished login process should look like with both offline and online options. We would use the online tracker being refactored by another team to determine whether there was an internet connection, and send the user’s credentials to a server or an offline database for authentication based on the connection status. We began to think implementing this was dependent on having an offline database to work with, and we weren’t sure how to proceed before the team working on that piece completed their work.

We also learned about the bridge pattern this sprint, which we expect will be used to handle checking the online status for all the pieces of the app which will be able to function in two different modes. George posted some good resources on it to the team channel, which can be found below:

https://www.youtube.com/watch?v=F1YQ7YRjttI
https://www.youtube.com/watch?v=9jIgSsIfh_8
https://sourcemaking.com/design_patterns/bridge

There were a couple of impediments to our progress this sprint. Multiple classes were canceled due to bad weather, and for this reason we weren’t able to collaborate as much or as effectively with the groups handling the encryption service or the offline database service as we had wanted. We did end up learning about some of the difficulties the offline database team ran into which apply to our service. They explained that patient data can’t be encrypted based on one doctor’s login information, because if it is, other doctors won’t be able to access it. They found a workaround, so going forward we’ll have a clearer idea of what’s meant to happen with the login information we send to the offline database.

The cancellations impacted our group’s ability to work together as a team as well. We do better when we can meet with each other in person and update each other on the progress we’ve been making in more detail than the stand-ups. Regardless, all team members answered the stand-ups in good detail and kept each other updated through the team channel, and I think overall our collaboration is getting better with each sprint.

One more impediment was that we discovered that we didn’t have access to server-side code to see what normally happens to the login information once it’s sent, which would inform our offline implementation if we had access to it. We plan ask the people at AMPATH whether that code can be shared with us in the near future. We also plan to make at least a mock of an offline database to use temporarily for our login service, and we might start using PouchDB ourselves if it’s not too involved. If nothing else, we will understand what the offline database team is doing better and be able to integrate our piece into the overall design more cleanly when the time comes.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.