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.

Stuff Is Happening!

Hello, again my dear fellow readers!

In this blog post, I will be reflecting on the events of these past two weeks or the third sprint and I have some good news to share will all of you; things are happening!

Over the past couple of sprints, or four weeks in real time, things were slow and consisted primarily of simple set up tasks, npm errors, and learning about testing frameworks. At last, we have received communications from our AMPATH representative and we have been given both direction and a task.

The new direction we are headed in is admittedly different than where we thought we would go but that is just fine by me. We will be working with the other AMPATH groups to collectively make a mobile app version of the AMPATH software. From our AMPATH representative, we received a group of 6 different videos. Each detailed a part of the app that he wanted to create and gave an overview of the idea for what they would look and operate like. It was decided that, due to a large number of groups working on the AMPATH project this semester, the work would be divided up into individual screen components. This resulted in our group picking the sidebar or the “burger bar” as the AMPATH representative so colorfully put it (I have honestly never heard that term before). The representative had helpfully set up a Zepplin board with mock-ups of each element that he had portrayed in the videos. However, no one was able to view them due to Zepplin policies. This issue was resolved however it did take a couple of days as the AMPATH representative had to invite each of us one by one. Once, we were in, each of us was able to get a good idea of what was wanted.

This has led our group onto the next step, to learn Angular for mobile development! Now Angular for web page design I have done. Although it was only one semester, it was still experience and thankfully it helped create a base I could jump off of when searching for mobile Angular tutorials. One of our group members found two excellent websites to help visualize and learn mobile Angular. The first was a very helpful demo website called Mobile Angular UI. It is a demo site that aims to demo every aspect of what mobile Angular can do such as scrolling, tabs, touch, swipe, and most importantly, sidebars. While this aspect is not immediately available, all it takes is resizing your browser to see it in action. The useful tutorials and information for how to actually implement sidebars came again from Mobile Angular UI.

From there, our group ended the sprint, discussing how the sidebar would work on each individual page and where it would have to pull the necessary info from to operate properly. Since we just started this part, it will regrettably have to go into my next sprint retrospective. For now, this sprint has left me with more knowledge on overall Angular programming as it is going mobile!

That’s all for now readers. See you at the end of the next sprint!

 

 

 

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

Sprint-3 Retrospective Blog Post

It’s time for Sprint-3 Retrospective Blog Post. As you are probably aware by now during this semester I will be working on a AMPATH project with a team for my Software Development Capstone course . As part of our assignment we are assigned to complete a Sprint Retrospective blog post at the end of each sprint. As of Today, March 26th, 2019, we have completed Sprint-3. During this third sprint we were able to get everything we intended to get done during this third sprint cycle.  For sprint-3 everyone in the team had the same yet individual kind of task. These task were:

  1. As a developer working on ng2-arms I need to watch the provided YouTube tutorials on the #ampathofficial Slack channel, to get a better idea about what kind of web app we’re building.
  2. As a team of developer working on ng2-amrs we need to decide as a team, which part of the ampath mobile project suggested in the tutorial we will be working on.

During this sprint we was able to complete all the task we set, plus a few extra small side task. A few of the side things were to read about  unit testing – mocking for angular testing and read Mobile Angular Docs. The YouTube video talked about few of the simple type of application that can be done to try to make a simple application to deliver healthcare using a more user-friendly application. The video mention a few things each team can work on in order to contribute to this new goal. After discussing with the team about the video and what we are interested in working on. As a team we decided to work on “the left navigation bar”. For the next sprint I believe we will be focusing our time on the what, who’s, and how we going to focus and ensure that are left navigational bar will work.

During sprint-3, I’ve learned a little about mobile angular doc, and a little more about what direction and how I will be contributing to the ampath project. While reading about mobile angular I discovered the different type of possibilities that can be done working with angular. See, with angular we can work on creating androids or OS application. Which I found pretty interested and will be doing further research on it. Another thing is, watching the video provided by one of the official ampath person help me understand and kinda get a mental picture of where this project is heading and what will be expected from my team and I. During this sprint I also, learned that we will be using mocking for our testing instead of going in and using real patients data. In light of everything I learnt there is nothing very special that went on that requires details explanations or strategies that would required for handling things different next time. That being said by the looks of things this project is going to be fun and interesting. I truly hope this project goes without a hitch, without me making things more complicated than it has to be.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Another Sprint, Another Retrospective

Hello, again my dear readers! Another sprint has passed and as such, it is time for another sprint retrospective. These couple sprint weeks has left my group and me with a slightly lower than average workload. From the first two sprint weeks, not much has been added to the Trello sprint work board. The bulk of this sprint’s work was funneled into two major setup tasks.

The first of these major setup tasks was ensuring that each member of the team had the ng2-amrs software on our individual development environment. We also had to ensure that each person had it set up so that ng2-amrs could be built and run on each individual development environment. This proved to be a task that would throw more unexpected errors our way than I think any of us could have expected. Of the few in class meetings we did have, many were spent debugging and troubleshooting many of the varied npm errors that rose up to bother each and every one of us. My personal experience with installing ng2-amrs and getting it running was not the worst of all the ones in our group but it was not without its issues. I myself encountered three separate errors that stopped me in my tracks. However, thanks to the knowledge of my fellow peers both in and out of my group, they were solved. The rest of my fellow peers had similar troubles with the same bugs that I experienced and in addition, some new ones as well.

The second of the major setup tasks for ng2-amrs was for each team member to study and get familiar with Protractor and Karma. Protractor and Karma are both testing frameworks for Angular. Thankfully, there were easily accessible, available, and easily understood tutorials that were available right from the web sites of the two respective home pages of Karma and Protractor.

While not much happened these two sprint weeks, I can not say that it was spent lazing around or that it was quite unproductive or fruitless. Setting up the ng2-amrs was a good introduction back in to working with npm and was more than just learn the two basic commands of ng build and ng serve. In addition, I can now say that I am much more in tune when it comes to solving errors that might pop up when building an npm server. I have also learned what to search for on Google when a specific problem does crop up and wherein the error code to look to actually find the error that has actually occurred. Learning both Protractor and Karma was a nice change of pace as well. I remember learning how to test in my 443 class last semester and I remember that it was an interesting and enjoyable experience. Thus, this week two sprint retrospective comes to a close. Hopefully, in the next sprint, we will receive more messages from the project representative and be able to dive into something a little more relevant than just setup.

Until next time readers!

 

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

Software Development Capstone – Sprint 3 Retrospective

As I mentioned in my Sprint 2 Retrospective, this sprint was going to be significantly more exciting than the last sprint. This absolutely proved to be correct, because our team now has a project and a component of the project to work on! This is a very exciting development, because now we can finally start coding! We have been in touch with a representative from the AMPATH team, who has been giving us further information and wireframes/designs. Our final project will eventually start to reproduce these designs, and the remaining sprints will document the progress on that code.

But before that, we have been receiving lots of information about the type of work that we will be doing for the rest of the semester. Our project is the completion of a mobile app that simplifies the AMPATH point-of-care system, which is currently only present in a desktop interface. This app ideally will contain various components, which include: a search bar to find patients with an accompanying results page, a form that would appear when retrieving specific patient information, multiple lists of patients which can be toggled with a side navigation bar, a selection of different form types when choosing a patient to learn more about, a form with multiple tabs that contain different but related information, and a bottom navigation bar for further options. All of these parts of the mobile app were designed by the AMPATH team, and we were able to observe the wireframes of each component on Zeplin, a website which joins the roles of designers and developers. We are also not going to be provided a server, so we also have a team composed of members from different groups starting to work on mocking a back-end server (releasing pre-defined data rather than live data) so that the app can mimic retrieval of real-time information. In order to do this, the team is determining which of the front-end components will require some sort of back-end communication, so that the server can be mocked properly and fully.

Over the course of this sprint, we have mainly been setting up our coding environment with the new knowledge of what our project is going to be, as well as the part of the project that each team will be working on. Every team from Worcester State who is working on the AMPATH project has been connecting to a GitHub repository which only has a blank Angular project and a README/License. From this point, progress on each component of the app will be part of a separate branch in the GitHub project. We have been deciding how to go about diverging so that each part of the work is separate from every other component. Some ideas included individual or team forking, as well as team branches. However, due to possible changes in teams, as well as members of different teams working together, the decision is to work on component or feature branches.

I am very excited to see what kind of development process we will make over the course of the next sprint! Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Sprint three lasted a week longer than the other sprints due to spring break, resulting in a lot more work getting done compared to other sprints. Starting on March 6 until March 26, in our sprint backlog we planned on covering some posted videos and coming up with things to do as we went along.

The videos were posted in a slack channel by the owner of the AMPATH project, Gregory Schmidt. Greg commentated a walk through of what the app should look like, helping us get familiar with the various stages of the user interface. This also helped us understand what was being done on the backend when searching for patients or clicking on a patient profile. Greg also posted a shell of the project using a site called zeplin, which we all signed up for to view gregs content.

Once our research was done, we decided to clean up the backlog process a bit by moving everything we had on trello to a github project. The layout of both sites is similar and easy to transition to, we just copied and pasted the relevant planning information. Each team in the class picked a certain feature of the app to work on, we chose to tackle the navbar functions.

Since each member watched the youtube videos, we added a few things to our ongoing tasks while we moved them to github. Since our project is a mobile angular program, we found a link (provided below) with a lot of useful information. The site includes examples of how to get started on our navbar, we added that task to our planning board and aim to make a lot of progress towards a built prototype during the next sprint.

http://mobileangularui.com/docs/

In our last meeting, our group brainstormed some ideas of what our navbar would look like, what it will do, and who will be using it. Currently we only have a few sketches, but it seems like we’ve decided for sure that we are going to include a home button and a sign in button. We discussed each group member working on at least one button, therefore we would have 5-10 buttons and the work is evenly distributed. One concern of mine is thinking of that many buttons to develop, the project seems not complicated enough to warrant that much work.

The home button is a simple starting point, it simply takes the user to the upper most page. The sign in button idea is still a work in progress, but hypothetically it should prompt the user for some information and filter a list with data pertaining to that user. In the hands of doctors or clinicians, this would display patients names with an appointment date and the condition of the patient.

Further ideas revolve around the concept of filtering down a patient list based on specified parameters, however this idea is still foggy and might not come to fruition. The same function could be done by searching for a patients name in the search bar, a component taken by another team. We still have time though, and we are fairly ahead of schedule considering the remaining work load of the project. By the end of the semester, the 15th of may, we should have a working navbar with multiple useful buttons on it.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

WSU x AMPATH || Sprint 3 Retrospective

Sams Ships (11)Hey guys! This sprint retrospective will cover what the WSU Coders Without Borders team has done from the week before spring break and up until this week.

As the project is propelling forward even more than before–due to us having more concrete plans to begin working on the project, it has been an exciting transition. We saw our options from Greg’s wireframes and explanations through his YouTube videos. From there, we created Zeplin accounts so we could visually understand and remember certain parts of the app in progress.

Since it was my first time using Zeplin, I wanted to add a little review of it. As someone who loves to organize things, I found that it is a great tool to have for sorting projects and handing off designs and style-guides to other users. It seems like an effective way to share ideas directly with people.

The overall WSU team now has a GitHub section for dividing up the components and issues we will be working on. So far, my team is going to tackle the search bar and everything else it would entail to create. It was nice being able to collaborate amongst one another to find a component that we agreed to work on (and the fact that a few other components had already been assigned to some teams helped our decision be made faster).

From there, we were figuring out what we need to do and how we can get things done. We discussed some potential ideas with Professor Wurst and from there continued to brainstorm for the search bar. There is nothing that comes to my mind that I would have chose to proceeded differently with if I could go back.

We are continuing our meetings as they have been scheduled and are actively participating in our stand-ups. I like being able to scroll through the log of my team’s answers because it shows our progression throughout the semester as well as serving as a reminder of when we did something specifically. I am happy to say that my team does not seem to have run into any issues or potential miscommunication among one another. It really shows how we are all working to achieve something together and effectively communicate what is happening.

In this sprint retrospective I also wanted to discuss how what we learned may be applied in other situations like in the workforce. We have to make sure we are checking in with teammates to have them understand the project more and be able to express their opinions and concerns when they arise. Similar to the bystander effect in psychology, if there is no direct communication between members when it comes to getting things done, how will there be any progression versus just observing what is happening? All it takes is being comfortable to ask different individuals if they have anything to share or add to the open conversation.

Overall, I am excited to move forward and see what is in store for me and my team during these weeks up until the end of the semester!

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