Apprenticeship Pattern “The Long Road”

I once watched a video by a self-proclaimed “lifehack guru,” where he talked about what he claimed to be a revolutionary new way to “think stuff done.” I always take ideas like this with a grain of salt, but in this particular video, I thought there was something to the advice he gave.

He said to look at your cluttered desk (or area of your choice) and to imagine it clean. The important part is this: you pause and take some satisfied breaths about how good it feels to have a clean desk. Note you have not done anything yet, but you feel the satisfaction of what it will feel like when you are done. Already, you should find that you have, without meaning to, probably thought of a few steps to achieving it.

That’s a long way of getting around to introduce the pattern, “The Long Road,” but the action that it suggests feels very similar. It suggests to imagine your future ten years from now and further, even the most far fetched version, and use that thought experiment to help plan your future career choices.

The “guru’s” advice was surprisingly helpful for doing something as trivial as cleaning my desk. I keep that advice when I do a lot of tasks now, even years after I have last watched it. However, so far I have only used it for short term and slightly longer term tasks that I need to do. I have not thought about applying it to something as significant as career goals, as the pattern suggests.

The pattern talks about keeping your sights set on the long term. This is something that I have been neglecting. I keep my head down and work hard on what is in front of me, but I don’t often step back to see the big picture. This affects me because when the pressures of school or elsewhere aren’t there, I sometimes don’t know what to do with myself. Without something assigned and a deadline, I can sometimes waste my time because I haven’t set myself goals.

It can be hard to set goals without the long term plan of where you want to take it. Otherwise it seems meaningless. What I liked about the guru’s advice was the pause to meditate on the moment where you accomplished your goals and hold that image. Although that is not mentioned in the pattern, I will use that step as I map out my future.

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

Sprint 4 Retrospective

This past sprint flew by. We did manage to get some work done, although perhaps not quite as much as I would have liked. Still, it was a valuable sprint and we learned quite a bit during it.

Since the last review, we solidified the workflow through which we’re going to be contributing to the project. For each task, we’re going to be creating a branch. Then, after committing it the new branch, we’re going to be creating a pull request for it that we’ll use for development. As we commit, the commit history will appear on the pull request in our GitHub repository, and the progress of the component can be commented on and tracked by others. Once the component is done, we’ll leave a comment saying so, and then it will be be reviewed and pulled into the main branch.

There was a bit of a hold up for some time because we are required to use Google’s Angular Material Design were struggling to identify exactly where to find that. We didn’t entirely realize that the Angular Material Design library was exactly that. Once we did though, we updated the master branch so that all future branches would have compatibility with Angular Material. Our group in particular had already made a branch called Questionnaire-Form before we got it working with Material Design, so we elected to delete this branch and create a new one, named Q-Form.

Also, from what I’ve heard, our back-end plan is currently not going as anticipated. In the beginning, we had plans to either use mocking or to create a server with fake information that we could draw upon. Then, last sprint, we had established that we were going to be using mocking and tying that in to different services that our front end components needed to use. However, it seems as though we don’t fully understand how the back end is currently implemented, and it’s something that we’ll likely need our professor to look even further into before we dive in.

If I could change one thing about how this work has been going, it would definitely be to do more work more often. Currently I think it should be entirely possible to be finishing components almost weekly, and it seems as though no one in the class has been doing that. At least, they haven’t been pushed to the master branch if there has been significant work. However, hold ups with sorting out the development environment and getting material design to function have been a major slow-down, so it is understandable that things haven’t been getting done as fast as we had anticipated.

Going forward, we’re looking to make sure that our new form component on our Q-Form branch works exactly how the Angular Material Form component is designed to work. Right now we have it functioning how it should, with an input field and a submit button, however we’re struggling to get it styled in the exact way that Angular Material is meant to be. Once we cross that hurdle, it’ll be far easier to get components finished, committed, and merged into the master branch.

On to the next one!

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 4

Team Tapmah had a rough go of it this sprint. We started the sprint very optimistic that we would be able to get a few services mocked using nock and working. However as we worked on the project we soon started to develop a sense of confusion and concern. We took the time to trace… Continue Reading →

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective

I am confident that all my group members would agree that this fourth sprint has been by far the most productive sprint to date. We accomplished a lot of work, most notably creating a few different prototype components for our multiple patient list tab structure. We learned more about how to put together our component, as well as began to look at the Ampath specific services so we can adapt our model to their overall system.

The first thing we did was created an empty branch on the main Ampath Github repository which will serve as the connection branch between the master branch and the branch with our code. After we completed the pull request for our empty branch, we were able to use ng generate to create all the necessary files and folders for our tab component.

With all of the setup completed, we were able to start experimenting with angular’s given component materials, and after verifying that we were allowed to use them under the MIT license, we each created a basic model that best fulfilled the design goals of the multiple patient list tab component. While we still are a bit fuzzy on how to implement the tab component for the cards, we definitely have made significant progress in both producing a working model as well as further clarifying the concepts we need to implement.

At the end of the sprint, when we were reviewing the features of our prototype components, we committed our branch with out working model to github, and began to discuss with the team working on mocking the server about what types of data structures and Ampath services we need to use to make communication with the server easier. This is our current task, as we need to figure out how to communicate back and forth, so we can move on to the next step of our design. Once we have a clear understanding of what types of data need to be sent back and forth, we will be very close to creating our minimum viable product.

We as a team and me in particular hit a couple of road blocks which hindered our understanding or progress, but ultimately solving them led us to a deeper understanding of the specific needs of implementing our component. The first hiccup I stumbled on was the decision to use Google’s material design or Angular’s built in materials. After finding out that Google needed a wrapper class and a few extra dependencies, we reached a consensus to use the simpler angular materials. And as I said earlier, we are still hung up on deciding on and implementing Ampath’s services. Finally, we are still not sure exactly what type of data is needed to be displayed on the tabs components for each card.

I am very satisfied about the amount of progress that we achieved during this sprint. We not only have an interactive working model, we all also have a much better understanding of not only how to implement the features we desire, but also a clearer picture of our end-game design goals. The roadblocks we hit were only there because of the amount of progress we completed, which is a good sign to me. After we figure out what our next steps are and implementing them, we should be able to communicate with the server and start our later stages of development.

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

Apprenticeship Patterns: Use the Source

Hello and welcome back to Benderson’s Blog, this week we will be discussing another apprenticeship pattern called “Use the Source”. This apprenticeship pattern talks about seeking out other sources of code or mentors to see if what you’re doing is matching or is on the right track compared to other people code. This allows you to understand the thought process of another coder and it may help you grasp what you should be doing with your own code on certain problems or applications. If the code is open source, the pattern suggests downloading the code and inspect its history and see how it has evolved over time with the changes that were made to the code. You can really learn a lot from seeing what other people change and their thought process through the whole thing. When looking through the code you may not agree with everything that the coder did but that helps you question why the user would use that path, maybe there is something you didn’t know about later on in the code that made that person decide to do that specific thing with their code. Not only should you read other peoples code and critique it but you should have people read your code and have them do the same to yours where they read through it and make suggestions to help you be a better programmer down the line. It is kind of like peer reviewing someone’s essay in middle school but with code and people that understand code. I thought it was good that the pattern ended with a quote from Bill Gates himself who basically said you can tell that someone is a good programmer by giving them 30 pages of code and to see how quick they go through it and understand it.

This apprenticeship pattern didn’t really teach me something new but inspired me to try and find outlets to read through their code and understand what is going on. How are you going to be a good programmer, if you don’t know what is going on with what you’re doing? That is a question that has come up in my mind after reading this apprenticeship pattern. Going through open source code and being able to understand like reading through an English sentence is one of the most fulfilling things to a programmer. One day I want to be good enough to be able to do just that with a big program like the Bill Gates quotes states. One day I want to work for Bill Gates which is another thing but that is a little off topic. Learning code has it’s challenges but being able to read others give a person a guideline on how it’s supposed to be done and they will learn from that. Thank you for joining me this week on Benderson’s blog!

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

Throughout this sprint we attempted to get some services successfully mocked and hopefully start the integration process within components. One big issue we ran into was that our team was very confused as to how to continue from the point we were at. It seemed that a lot of the services that we traced just led to more mundane methods that did not really help us at all with any information that we needed for anyone’s components. Some of the patient profile services has some type of data to return. But what we found was that a lot of the services were making calls to URL’s that we had no clue as to where they led. We are pretty much stuck at a wall here. The way that we initially understand was not really completely thought out when it came to execution. Our main issue is that we understand that we need to mock only the important services that other team’s components require, populate them with data, and make it able to ping back to those components. However we are unclear of what to do from here. As I previously stated, it seems that the architecture of the ampath services were far larger and a lot more cryptic than we initially thought. Even though we have hit a big wall, our team is always trying to push through and are really trying to understand every aspect of what makes this issue an issue so that we can hopefully work past it.

Right now, our focus is to reconsider if this was the best choice for us. We have been actively consulting with other teams and Professor Wurst to try and come up with an efficient solution as to not create any unnecessary overhead. Admittedly, it seems as though we bit off way more than we can chew in this instance. What I believe our next plan of action will be is to actually development one of the components so that we can actually have something tangible to work with first, that way we can see if we can recoup for our loss on time of the server by mocking for components that will be directly relevant to us. We plan to work on the bottom navigation bar and sort of leave this roadblock where it is so we can still be efficient with our team. One of the things about coming to a road block like this is that it teaches us that sometimes not fully understanding things could actually be more of an issue than we thought. And this is not to say that we haven’t learned anything from this experience, because we have, rather it’s more of an eye opener to maybe scout out the road ahead a little bit better. But again, we are still going to actively try to work on this but for now we are putting it on the back burner until we can get something figured out so that in the future we can hopefully start compiling other components.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective

Since the last sprint retrospective blog post, our team has begun to work on some of the components described in the first video. We are referring to the template wire frame layouts from the Zeppelin website, and we are working on form 1d in particular. It is still not very clear how to move forward and what to work on; the only way to make any progress is to keep focusing and thinking about what can be done and what to try looking at. The Angular Materials Design seemed to open the way into making progress. It established a much clearer way to begin the actual programming part of making the components. Everything we have done up to this point seems irrelevant now, but now things seem to be picking up in pace.

I have not begun writing any code myself, so my goal for the next sprint is to start writing code and finish an actual component. With the new angular materials design tool we are using now, this should be doable, since a lot of the code just comes from there, and it’s just a matter of implementing it by changing some small details. Progress has been slow, but progress is being made.

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

Sprint RetroSpective 4

This past sprint flew by in all honestly, seems like last week we just started. This sprint we accomplished a few goals we set out to do. Our main goal/issues to solve were the branching situation and what our exact task was. Next was setting up pull requests for our user stories correctly. Took us a little bit but I think we got it situated at the moment. With only some angular issues popping up here or there but nothing we couldn’t solve. Harry has set up a few wire frames over the past few weeks, even if they weren’t stuff we were working on giving a better idea on what we were working on. For the coming Sprint we are reaching the Endgame time period, where we are going to have to actually power through as a team and accomplish our goals. I have faith in my team, as when it comes to brass tacts we all can pull through. Essentially I am looking forward to once again setting forth with my team and accomplish our goals.

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

Sprint 4 Retrospective (Capstone)

This sprint, in my mind, one of the most important things that I was able to figure out was getting connected to AMPATH team through the Zeplin app. It seems that someone, perhaps accidentally, disconnected me from the group. Once reconnected, I was able to connect the rest of my group.
Although it hardly was a difficult task, it is hard to overstate how important it is to be on the same page as the team you are building the product for. It could have prevented a lot of wasted time on our end, and it makes it more likely that they get the end product they want.
Probably the most important thing I did in terms of learning about the tools we will be using was creating a “spike.” It is a new term I’ve learned that I will add to my lexicon, meaning to build a prototype of a product, diving deep to learn as much as you can. I touched upon it in my last apprenticeship patterns blog post, on “breakable patterns.”
I failed to make a successful working prototype that did everything I wanted. It seems that I have less knowledge of how all these work together than I thought. This brings to mind the apprenticeship pattern mentioned earlier, “breakable patterns” — I leaned through failing.
I will return to the Angular “Tour of Heroes” the next day or two to fill in the gaps in my knowledge. I don’t think there’s very much that I’m missing, but what I am is important to making it work. I would like to do this as soon as possible to be as much of a useful contributing member of the group as I can be.
Last retrospective, I was optimistic about how much we would be able to do this sprint. In truth, I am a little disappointed that we were not able to complete as much as I hoped. I am still optimistic about what we can accomplish coming up, but I have to bear in mind there are only two sprints left.
I am hopeful we will get a lot accomplished, but I have to be realistic that it might not be as much as I would like. This is the time where I should be thinking about buckling down and dedicating several more hours per week on top of what I already dedicate to this class.
I do have to keep in mind the learning curve we are experiencing when working on a team project like this. It took us a long time to just get the program to build and run on our computers. We didn’t hear what we wanted the final product would look like from AMPATH until relatively recently.
However, I think we are approaching the end of the end of that learning curve. Once our scrum team gets one component finished, I am confident the second will come a lot easier. It is reasonable to hope we are able to do a third, and maybe a fourth if we we split up into smaller scrum teams. Anything beyond that might not be wishful thinking, but I learned my lesson for setting my expectations too high.

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

Sprint Review Blog # 4

          Our fourth sprint laid the first real groundwork for the project design and coding. The AMPATH developers have given us more information as to how they want the simple app to look like. It should have a simplistic design within the flow and written code of the app to make sure it works properly. We created a new repository from a more updated version of the original files given to us. The original files were lacking in certain angular development modules so importing certain components and data became an issue quite quickly. The updated files now have those development modules which we have just cloned onto our computers and created a QForm component for the questionnaire form. We had to delete our previous branch known as questionnaire-form because it wasn’t up to date with the new files. We decided it would be easier to create a new branch from the new files and start over in this manner. We created the new QForm component and have laid the groundwork skeleton for how the design should look within our CSS and HTML files. The CSS is giving us issues however, because the form that we imported was vertical in format while the one that shows up when we ng serve is horizontal and slightly unformatted. We will continue to work on these issues to make sure they are ironed out and looking as proper as possible. We debug any issues we come across separately on our own and then bring it to the team if we can’t seem to figure it out. The option of multiple people debugging a problem is comforting and it allows a fresh look onto an engaging topic. I personally enjoy group debugging because it makes the learning experience much more enjoyable. I still 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. We’ve already started collaborating with other teams on what information we all will be needing from a mock server. It will be necessary for the future so I think we should discuss how this server will be setup and which development tools will be used. We should also understand how data types will be formatted within this database so as to hold only meaningful information. It would be interesting to see how patient data types are handled at AMPATH but we’ll just have to make our own version based on guessing. I’m now more worried about connecting the CSS and HTML for the final application to make sure everything looks nice and simplistic since we had issues with our own CSS. 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. The most important aspect of this design that we decided on seems to be simplicity with functionality. We want to incorporate that using the imported modules while also gaining knowledge on how they designed their app.

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