Monthly Archives: March 2019

Sprint Retrospective #3

During our third sprint we finally got an idea of what we will be coding for this project. Greg Shmidt from AMPATH sent us videos that showcased wireframes of the electronic medical record system that they are requesting. The main thing that I did during this sprint was watch these videos and start planning with my team what we will be working on and how we will go about coding it.

After watching all of Greg’s videos, my team decided that we wanted to work on the tab functionality. The tab is one of Google’s standard material design elements, and Greg showed a few examples of apps such as Google Music and Twitter that incorporate tabs similar to the way that we will be for this project. Each tab will contain a form that displays patient information. The tab bar must also be able to scroll to show additional tabs.

During this sprint my team began planning how we are going to go about designing and implementing the tab system. A link was posted on the Slack channel to documentation about coding mobile Angular user interfaces. This was helpful to read through as it gave me a better idea of what we will actually have to do to code the tab system. I also found a page on tabs on the Angular site that was useful to read through: https://material.angular.io/components/tabs/overview

One challenge in implementing the tab system will be making it so that it functions with the systems that the other groups are developing. To do this we will have to figure out which services we will need to use. Luckily, a member of another group found where all the services are located in the ng2-amrs project. During this sprint I began looking at these services to figure out what they do so that we will know which ones we will have to implement when creating the tab functionality.

After this sprint I believe that my team is ready to actually start coding. We now have clear instructions on what to do and have done preparation work that let us get a better understanding of how we are going to proceed. During this sprint I learned what is expected from us for this project and gained a conceptual understanding of how to implement a tab system in Angular. It is exciting to finally know what we are working on and I’m glad that we can now begin to make progress on this project.

Overall, I would say that this was a successful sprint and I would not proceed differently in light of anything that was learned throughout the sprint. I am satisfied with the way my team is working together and I believe we will begin to make a lot of tangible progress during the next sprint. I think that the tab component we are working on will be a lot of fun and am glad that we chose it. This project is definitely going well and I’m excited to continue working with my team.

 

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

At the beginning of this Sprint, we all watched the videos that AMPATH shared with us for ideas for projects they would like to incorporate into their app. It was really encouraging to make contact with them. I was wondering how much they would ask of us, but I was glad that they seem to value what we’re going to do. I like that it looks like we will be able to do some interesting projects. I hope we are able to get through as many stories as possible because I want to do a good job on this.

After watching the videos they provided, and we all decided that we wanted to start by trying to implement the story which was to creating tabs in the app so more than one form for multiple patents could be open at once.

After a quick google search, I found some good resources from the official Angular site. It provided with some examples of different ways to implement it. It also showed the code behind it in an interactive app that showed how all the components work together. Within the app, I was able to modify the code and see in real time the changes I made to the example.

I shared what I found with the team. It is very exciting because this was exactly what we wanted, and it was laid out in a way that was really intuitive and makes it straightforward to  see what we need to do next.

I think what may be our next biggest hurdle is getting something concrete started. After we have done that, I think it will be pretty straightforward assigning roles and dividing up tasks. When we have finished the first story, I think I will have enough of a feel of how things are done to branch out and form a sub-group so we are able to cover more ground.

Andrew was a huge help to our group. He pointed us in the direction of a lot of resources, especially how to interpret the code we have been provided.

I think a good goal for this upcoming sprint is to finish this one story that we have chosen. I think it is something that we can realistically do, and I don’t foresee that it will be all that challenging. It’s still early to say for the sprint after, but I would like to at that point do what I mentioned earlier and split up into smaller groups and between the four of us, tackle two more stories with two of us working on each.

Of course, I have coded enough to know that there will be unforeseen obstacles that we will have to overcome. There is a chance that one or several might cause quite a bit of delays, so I should not get too ambitious right out of the gate. After all, we have not done any real work of substance yet.

However, I believe it is important to set our goalposts high. If we don’t achieve all of our goals, we can just append it to the next sprint. I think we will achieve more of our goals if we are more ambitious setting them.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Sprint retrospective – 3

On sprint 3, as i said on sprint 2. which i was working on getting my angular to work and also getting more understanding on the angular. I finally made it worked with the help of a team member. During our sprint 3, a lot of things needed to be changed. New kind of a project had to be done. The project called simple app.

doing the process of figuring how to start the new project called the simple app, we were getting all the prerequisite for the new project. we needed to install or create an account on Zeplin. That is were all what we have to do, and the design made. which include the type of programming we need like CSS, HTML, JavaScript and so more.

During our meeting, we discussed more about the Zeplin. We check whether we all on point as to see if we were all on point with the Zeplin. It was a little bit strange for me. But with time i got the understanding and it is very very helpful for our project. So upon all the split tasks, we the team chose the search button. As I look through, i thought it will be very simple to do. Because all we need to do it to get a text field and a small button after that we label them as a search field and that will be all. If my thought is right, then we probably we should be done within a hour if we get it started. If not and my second guess is, we might need a back end to work with. Something like getting an information from a database, a file and any source of data or information. So at least the search field can be useful by playing the role as a search engine pulling out info from any data source. Either ways, we will go through all the step by step, dealing with the issues on github and wait for what the prof will have to say to us. Whether to add or changed something.

i also notice our styling of the project will be from google. It is good for us in the case of fast project be done. the only problem with that is i have no idea of were to start or begin with.  So the plan is to learn or search on tutorial on it so i can get more understanding on it. And if anything, hope the team up me get through.

For as we the team, we are planning necessary stuff/tools as in the type of IDE we will all agree to be working with so in case a team member has a coding problem or wants help with the use of the IDE, we will be able to help him or her. Also getting the understand of the whole project. Getting to know the main types of languages that will be needed. We are also checking who will be working on a particular part of the project. The reason is so we all can get something to contribute and also make the work more faster rather than leaving it for one person or a few people in the group.  We hope the next sprint which is sprint 4, we should be able to be half way or almost done with project.

 

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective Blog

For the third sprint, I was assigned to create a REST API for the USDA’s Food Safety Inspection Service’s FoodKeeper Data (located here:
https://catalog.data.gov/dataset/fsis-foodkeeper-data). Prior to starting this assignment, I felt I had a poor understanding of what a REST API was, let alone how to go about making one. Fortunately, the resources that Professor Wurst sent me were a very helpful step in understanding what one looks like. I also read several other resources and followed many other tutorials while making it. By the end I had over complicated things by storing the data into a MongoDB database and ended up switching to data stored in memory, but despite this I think it was still very useful to work with MongoDB as well integrating it with the REST API. I had also considered trying to use a relational database such as PostgreSQL, as the data seemed to lend itself well to it given that each data type already contained keys relating to the other data, however it was a bit harder to set up when compared to a document database.

This sprint began before spring break, and during that time I felt that the project was at a much earlier point than was initially assumed, so I spent a good chunk of my break working on it. As I said I started with a poor understanding of REST APIs so I felt that there was some catching up that needed to be done. By the end of the break I had something that was mostly working but was a bit complicated to set up since it required installing MongoDB locally at the time. I imagine we may have run into similar issues when trying to host it in Heroku, but fortunately it’s since been simplified. I don’t think that it would necessarily be a bad thing to store the data in a separate database, however, given the relatively small set of data as well as the fact that changes aren’t made very often, it didn’t really make much sense to go that route. Changing the code that I had already written to no longer use MongoDB was pretty trivial, as not many changes needed to be made. At this point, the REST API Order System example (located here: https://gitlab.com/worcester/cs/kwurst/rest-api-order-system) that was sent to me was particularly useful, as the was it was set up was almost one to one, with a few changes here and there.

Currently the project is almost at a point where it’s ready to be used, as far as I’m aware at least. I feel that it was much simpler than I had originally thought it would be, but since I hadn’t had any experience with doing something like this before it took longer than it should have. I think one of the most important things that I’ve learned from this is how to start working on a task in which I’m unfamiliar with. It was definitely useful to learn how to make a simple REST API, but I’d say being able to work on something you’re uncomfortable with is a skill that will help me greatly in the future.

Links:
https://github.com/LibreFoodPantry/FoodKeeper-API
https://github.com/cs-worcester-cs-448-sp-2019/FoodKeeper-API

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

Sprint Review Blog # 3

            Our third sprint enlightened the path the group planned to take with the other groups for the splitting of objectives. The AMPATH administrators were able to give us more information based on the project specs that included wireframes of each component that we needed to create. The team heavily benefited from the clearer explanation by being able to divide the work out to our team members in a productive manner. We were able to understand what the project generally asked for and began working on our first component for the angular project. This sprint also gave us more time to look at the code AMPATH had given us for reference material on variable naming and options when creating the components. We compiled ideas on our first component and finalized that we would work on the form component. We analyzed the videos that were related to that component and realized that it could be made fairly easily but there were more questions that needed to be answered. We found that the question fields for the form were not stated, so we decided to create their names based on their question number. We would like to implement real questions, but we can only do that once we confirm this is needed with AMPATH. I think that we should proceed to understand the AMPATH format for their angular code and look into understanding how we will possibly setup the Mockito style of testing we are aiming for. A better understanding of the project will be needed to further enhance the user experience so as to create a flow within the program that seems seamless to the backend user. We want to continue to understand how we should edit and evolve the code already given to us and turn it into the final product that they want. I think that the hardest part for the future will be to connect each component together and bind them into one final app with the other groups. This is going to take a good amount of proper communication to achieve. It will be necessary for the future so I think it would be a good idea to start talking to the other groups about this now. This will keep them on alert and conscious of the code they write to make sure it can be understood properly by someone on another team. This app will be used by back end users for simplistic tasks such as filling out questionnaires and taking notes on patients based on their medications. It seems that another team has also found some Mockito code within the files given to us by AMPATH that could be useful in creating our own data to be fed into the application. I’m uneasy about the lack of information we have based on variables in play when looking at patients between our version of the application and the AMPATH application. I hope that the transition of data between the two applications would go smoothly but it doesn’t seem reasonable to think that this process would go without hiccups.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Sprint 3

This week wraps up sprint 3. During sprint 3 we accomplished a decent amount of things. Most of the stuff that occurred this sprint was done on the backend and setting up of git repositories for both the font end and back end. Over the past two sprints we have been able to complete most all of our sprint backlog tasks. This sprint was no different. We decided to use this sprint as a stepping stone to try and figure out if we could handle some more complex product backlog objectives such as developing a REST API and figuring out how to work on features such as food expiration tracking and timing (this is based off of a federal calculation and standard). For this sprint I took on the task of working on some front-end related stuff. At the beginning of the sprint we had a back end and a very sparce front end. I decided to take into my hands the task of designing the front end using HTML and CSS elements. A large advancement that I feel we made as a group this sprint was getting the google docs intake form for Thea’s Food Pantry translated over onto an HTML format so that we can connect it up with out front end and host it on our repository. From last sprint I had a worker screen mockup done completely in HTML with no CSS elements as well as just locally on my machine and not able to be seen/shared with the group. This was a major issue for me as I wanted to be able to share my progress with the group so that they could comment, contribute, or discuss any potential areas of concern. What I had hoped to do this sprint was add a task onto the sprint backlog to have us figure out how to transfer all my HTML worker screen work over to the repository that hosts all of our front end stuff. Unfortunately I was not able to complete this task this sprint as more front end design tasks came up that I felt were more important than transferring over a mockup file. One very interesting thing I learned about this sprint was online CSS editors. I can make my way around from scratch in an HTML file but CSS is a different story. CSS is a more complex almost add-on type language for basic HTML files. I was told about this online editor called Zeppelin.io that supposedly let you draw up wireframes within the application and then translated it to CSS for you so that all you needed to do was copy and paste into your actual project. Unfortunately, this application is a mac application and thus didn’t want to work with my windows machine (even though it had options for a windows download, I was unable to create any files from scratch without photoshop!). My next solution was this editor called stackblitz. Unfortunately it’s quite the opposite of the idea of zeppelin.io and is instead a real time online CSS HTML editor (things that you code are automatically compiled and displayed on a terminal). So even though it doesn’t give the CSS code, I was easily able to google how to write different CSS methods (buttons, how to call CSS methods in the HTML doc, etc) and it has been good so far. Now we have a wireframe to show the customer without having to commit it and push it to our repository. The best part is that stackblitz also works hand in hand with github so our repository is connected up to stackblitz and we can commit our changes to our repo without having to migrate all our front end files!

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.

Apprenticeship Pattern Blog: Practice, Practice, Practice

Hello and welcome back to Benderson’s blog, I know it has been a couple weeks but I’m finally back after a little vacation. This week we will be continuing our topic on apprenticeship patterns and focus on one section titled “Practice, Practice, Practice”. This pattern focuses on exactly what the title says it does, which is practicing until you get good at the craft. The problem that could arise though is that, yes you rely on a mentor to help you, but what if the mentor can’t provide all the solutions for you or can’t see where you’re getting at. That is why they talk about the martial arts of computer programming and how there are spots in the world where people come together to work together and get over learning humps that may come about in your practice. This is a great solution to keep practicing and getting better so when you get a job, you will have a lot of knowledge to bring to the table.

The “Coding Dojo” part of the pattern was intriguing to me, that a bunch of people meet up at a location and just code together and help each other out. It is a good way to learn and better your self for future employment opportunities. Like me, I know I’m not perfect at coding in any language, probably no one is perfect at coding in every language which means that you will need people to help you along the way so you can learn and that is what practicing is all about. The saying “Practice makes perfect” is what this pattern is striving, keep working at it until you think you have enough knowledge in it and maybe even help someone else out along the way. A job obviously knows that you aren’t going to be perfect in coding and won’t know everything a language has to offer but if you practice before a job and learn a decent amount of information to the table, you may be getting promoted sooner rather than later and will probably beat out some people with the same type of resume as you. Thank you for joining me this week on Benderson’s blog, I will try to keep posting once a week and keep information coming!

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

This past sprint was a good one, even if we didn’t manage to get a tremendous amount of actual development work done. We divvied work up amongst our different groups and had a lot of discussion regarding how to start our project and what approaches to take while doing so.

We got in contact with Gregory Schmidt, a development lead with the official AMPATH team. Mr. Schmidt provided us with a fantastically detailed outline for the rest of our project. It included an interactive wireframe built using zeplin.io as well as a series of videos describing the project plan and the objectives behind the wireframes. Originally we had intended to clone and develop components as branches on our forks from the original ng2-amrs project. However, once we realized we were essentially making our own small to supplement AMPATH’s, we restarted by making our own repository for a GitHub organization for the whole class. The organization is split up into the different development teams we’ve organized ourselves into as well. Inside of this organization is the repository we’re using now, which contains a small blank angular project, and we intend to use it in the upcoming sprint to build off of.

Not only did we figure out how to host the project we’re working on, but there was a lot of initial discussion regarding how to manage the progression of components during development. For example, we had originally intended to use Trello as a scrum-like “task board”. Although it was later decided that, since we can introduce issues into GitHub’s issue tracking board, we would use that. By using Github’s issue tracker, we can set up an issue for each component, and even have several issues per component for teams to adopt and develop. On top of this, we can more easily display to the class which teams are developing what components, and who is within each team. Having all of this data reside in one place streamlines the development process and makes it significantly easier to determine what has been finished and what needs to be worked on in the future.

Our professor has been doing a lot of work in trying to figure out what the development process will actually look like. The class was trying to discuss how we wanted to handle branching — I proposed the idea that we would have one branch per component being developed that would get merged into the final project once that component was completed. Come tomorrow in class, the professor will tell us exactly how we’re going to start the development, however he has already said that instead of one branch per component, we’re likely going to do one branch per user story. Then, of course, we can branch off of those into sub-branches if need be. I believe there was talk of also using GitHub’s Milestones functionality as “Epics”, which if I’m not mistaken are essentially larger, more broad issues to be completed. For example, if we need a page of our application that has both a menu and a search bar, there might be more than one component that goes into that. This page might be considered an “Epic”, because it would involve many stories being implemented at once. Having Epics would be really helpful to guide the overall development process, so implementing them as Milestones could potentially be very useful.

We’ll have more information regarding what we’re doing in the next sprint come tomorrow, and we’ll be starting some legitimate development this next sprint, which will be great. I’m excited to get started!

From the blog CS@Worcester – James Blash by jwblash 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-3

Compared to last sprint, my group and the other AMPATH groups have gotten a lot more done. At the beginning of the sprint we were fortunate to get some information and feedback from Gregory Schmidt. Greg created videos that pretty much described what he wants from this project. Link: https://www.youtube.com/playlist?list=PL7e8VJ_ZN6eo13AmOMnvXgUEZ38J9pygN) The first video is pretty much an overview of what the layout will be as a whole. Here he explains what he wants for the main components. This included a form page, a patient list, left navigation bar and multiple patient lists. From there he goes in depth on each of the components. The first component is the selection cards and tab rows. This video was especially helpful because Greg mentioned apps that include the tab piece. Along with the other parts, he used Google Mail a lot to reference which helps us have a visual idea of what he wants. The last two videos that were included in the playlist of videos included what he wanted for the navigation elements. After watching all of the videos and figuring out the main components needed for the project we split them up and each was assigned to a team.
The one my group and I decided on was the tab rows. We were thankfully given a link that goes through a demo for mobile angular app development by Kathleen Law. (Link: http://mobileangularui.com/demo/#/tabs) There were a number of different kinds of components and tools that that were listed. Kat also gave us the link to the documentation too. (Link: http://mobileangularui.com/docs/) Of these, a tab component was given, which helped us out greatly. Sam also found a link that pretty much gives us skeleton code for the tab component. (Link: https://material.angular.io/components/tabs/overview) All three of these links will help us out when it comes to actually writing the code.
The last thing that was done during the sprint was kind of a group effort between all of the teams. Professor Wurst created a repository for all of the teams. (Link: https://github.com/cs-worcester-cs-448-sp-2019/amrs-simple-app). In this repository there is the whole entire AMPATH project. Professor Wurst also created all of the teams that are contributing to this project. While getting everything set up we also figured out that we will need to find all of the services that will be needed for each part of the project and mock the services that will be needed for each component. Andrew Finneran created a group on Slack called ‘ampath-server’ and gave us an example which was in the ng2-ams file. In that file you find the src file and then go into it and then find the app file and go into that. From there you look for two kinds of folders, one names etl-api and the other was names openmrs-api. Both of these offer all kinds of services. When you clicked into a server that you needed you will see a bunch of code but specifically a url that goes to the server and then the functions of each of the codes call that url. This is helpful because we will need to in the future mock up these function to return values.
We as a class also decided to created a ampath-frontend slack group which consists of us talking about how we will start the project. We decided that we will push up a blank angular project in the github repository that i listed above. The master branch was set to protected so no one could push it directly and for each story that we work on within our groups we will make a separate branch to work on it.

From the blog mrogers4836 by mrogers4836 and used with permission of the author. All other rights reserved by the author.