Hello dear readers. Welcome again to my blog. This blog won’t be for the patterns I have been writing about, but for the progress of me and my team in our Capstone Class. It is exciting to see that things are progressing and we are moving forward with this project.

As I mentioned at the end of the last blog, (AMPATH-WSU Sprint 2 Retrospective) we received videos and actual output samples of how the new application should look like. I think that this is a very important step and want to say that I think it should have been sent earlier to us, as for a long time we kept researching about the tools we were gonna use and to be honest it got a little bit boring as I was really was looking forward to this part of the process. It’s true that in order for you to start working on a project you should know the tools and systems but I also believe in the theory where you also learn while working on it.

So during this sprint we took our time to watch the videos and after we made sure we all had seen and understood the videos and the requirements, we created Zeplin accounts. For all of you who don’t know Zeplin, Zeplin is a collaboration tool for UI designers and front end developers. It goes beyond the design workflow and helps teams with the design. I had never used Zeplin before but I found very useful in sorting the project and handling off designs. Recommended if you ever do front end development!

A Github section was created for all WSU participating in this project and each of the teams created their own branch. We discussed if each of us should have their own branch but we ended up in the conclusion that it would be very messed up for each of us to have their own branch pulled from master, so a branch per team was the final decision. However, each one of us could create its own branch from the team branch and that would be great in case any of us wanted to experiment. we left the option available  to whoever wanted to do so.

After we created our branch we choose our task to do, which is a search bar.  Something I really would like to point out is the team environment we have. We all are very communicative and express ourselves and our opinions. For us it was easy to agree on the search bar as a start up to do task for this project.As a lot of steps on this process don’t depend on us I would say that everything is going fine and I wouldn’t change anything if I was back in the same situation.

While working on the search bar we keep checking with our teammates and how is the progress going. I am really glad we haven’t really been facing any major issues and our team is working strongly together. I am really looking forward to getting the search bar done and move on to the next task. Stay tuned for my next blog post to see what happens. Until then..Have a good time

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

In our third sprint, we ended up having to revisit some of our previous work and recreate it, but better. After having a lot of difficulty with the previous way of doing it, using some old code from an old project, I decided to go with a more structured approach and read the guide on making template driven forms on angular.io. This guide was incredibly helpful in creating the form, as it has step-by-step instructions, example code and is very descriptive in the how’s and why’s of doing things.

Using the guide and their code as a template, I began to customize the intake form to the necessary specifications. I pretty much tried to recreate the “Thea’s Food Pantry Intake Form” given to us by the food pantry representative. I had to make different types of input for the text and the button input, and this time I was able to get some error-handling working, such as required certain fields before submission. Instead of using WebStorm as my IDE this time, I developed everything on Stack Blitz, a free online IDE and Angular editor that displays your application in real time. It was really useful to use, and hopefully once our group figures out its intricacies and how we can use it to collaborate within it, we can use it more in the future.

I was able to use some of the lessons learned in my Software Process Management class to make sure I maintained the clearness and readability of my code as well. I tried to use good spacing and white-space in the form so that it is clear where one module of the code ends and another begins. I also tried to keep my names both clear and consistent, so that variables containing the same information are named the same throughout the program. This is an issue that caused me much confusion last semester when I was developing a different web based form.

A unique issue I ran into while making the form was the compiler getting confused about the format Student IDs at Worcester State University have. Because my ID number is “0662077” the compiler kept thinking I was trying to use an octal, which would be something like 0x662077, and would not compile. I had to accept the Student ID as a string instead of text to fix this issue. Another issue with accepting Student IDs is that the program tries to get rid of unnecessary 0’s, which ends up making my ID Number different from what is desired. It took me a while to solve this issue, as I had no idea what was going on at first, but it was interesting to see how it could misinterpret my input data because of a preceding 0.

Overall, this Sprint was relatively productive for me, and I hope to continue going forwards. I have to find out what my next goals and challenges are and figure out what I’m doing next. Hopefully it will be something I’m familiar with.

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

A reflection on what I learned from
this week’s activities is that sometimes it’s best to restart. Our initial two
sprints brought us up to a point where the current delivery is usable but could
not be built upon. We had trouble trying to incorporate features from each of
our own work loads that was divided in Trello. The main issue from the scrapped
delivery is that it is written in Java and missing fundamental components that
would make it difficult to create a webpage with. As such, the problem resolved
after deciding to focus our efforts on Angular and using it’s features to make
our lives easier.

Another lesson learned from this week’s
activities is that having more than one repository between two GitHub and GitLab
is a nightmare. It was a mix between each of the members uploading to our own
repositories to share mockups of things we have created during the sprint. This
choice is backed by us not feeling up to upload mockups directly to the repository
made by the professor since we weren’t “feeling ready” yet.  Then there is the issue with having two different
food pantry repositories which further confused everyone. However, this issue was
eventually resolved when the professor and some students came up with another idea
for handling the repositories. The new system creates a fork from the main
project to the class repository. There are a couple other things mentioned
about incorporating “stories” using this setup that I have yet to fully
understand.

The third lesson learned from this
week’s activities, is that it is very easy to get lost and sidetrack from the
main goal. This lesson is mainly for myself as I was working on the database
but took me an entire sprint to realize that I was working on the wrong portion
of the project that was unneeded at the moment. Focusing unnecessary resources towards
a feature that should be left for later. The other members were focused on the
intake form and had created the front-end of it but needed a place to store the
information later on. This is the area I should have tackled, in which our
members would have been working in unison.

During this sprint, I focused my efforts on mainly establishing a connection to the SQLite database created from the previous sprint with the current project. Using JAVA and the available JDBC library found on the web, I was able to successfully connect to the database. However, when it came to transfer what I learned into the main project we were working on gave plenty of errors. There were missing libraries and many unused and preplanned files that needed deletion. Although this was a problem, the next problem is mentioned earlier in the blog. We needed a clean slate to work with since the project was in an unworkable state. After we got back to the point where we were in JAVA, now in Angular, I had to find a new way to get the SQLite database to work in Angular. Now that we are back on track, I can see where the project is likely headed!

References:

http://www.sqlitetutorial.net/sqlite-java/sqlite-jdbc-driver/

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

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.

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.

            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.

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.