Monthly Archives: March 2019

Sprint 3 Retrospective

This sprint definitely was more productive than the last one, for the main reason that the scope and implementation of our project is beginning to take shape, and we are gaining more clarity about what we have to do to achieve our goals. At the end of the last sprint, everyone on our team decided that the component that we would be building would be the tab system for adding, modifying, and displaying information about patient records for multiple patients.

Early on in the sprint, Sam found some solid resources that angular provides with multiple variations of tab structures to choose from, and the skeleton codes were provided too. We took a little bit to decide which kind of style, animations, layout and otherwise we wanted to go with, taking into consideration that the everyday users for the project will be medical professionals who have to constantly have multiple tabs open and switching around. We didn’t want our component to feel cumbersome, we definitely value having a sleek easy to read style, and fast animations to streamline their workflow as much as possible. This design goal led us into ruling out certain features that would take a long time for animations or had unnecessary clutter.

After getting a consensus on our group’s design philosophy, seeing what tools angular had to offer us, and deciding on a general schema for our tab component, we discussed in class the need to use Ampath’s included services to make our project compatible with Ampath and useful in an electronic medical records system. Thankfully Andrew found all of that information in their core repository, which saved us a ton of investigative work. So what we have to do now is search through each of the services and their specification mocks to find which ones are relevant to our component and then we can begin creating our prototype.

At this point in our development, we have started to plan for creating a wireframe program which applies both the design we want, as well as the services we need to provide that contains the information and formatting that is relevant to the Ampath vision. Beginning the next sprint we all believe we should be ready to start coding and getting some demonstrable progress under our belts. We will have created a file with our skeleton code and we are hoping to push it to our local repository as soon as we can.

I am very pleased about the progress and mode of work with our group. We all seem to reach a consensus about what direction to go in quickly and effortlessly. We are all finding small ways to help further the progress of our team in our own ways, and at some point during the sprint each member of our group was able to contribute something helpful to all of us. We are all understanding and willing to divide and tackle any particular work tasks we need to get done. I definitely wouldn’t change anything about our group dynamics and I am satisfied that we are successful.

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

Apprenticeship Pattern – White Belt

The white belt as an apprenticeship pattern is what it sounds like. You are at the beginning of your journey and have a deep understanding of your first language. The problem arises when you are struggling to learn new material and it is harder to piece things together than when you started learning your first programming language. The author relates the solution back to Star Wars quoting Yoda, “You must unlearn what you have learned”. By doing so, this accelerates the learning process because you don’t try to relate things back to your current language but instead connect neurons together when trying to understand the new concepts you are learning.

I agree with the many things the author taught in this apprenticeship pattern. That too is how I learn new tools and technologies on my own but on the other hand, I always try to relate it back to my strongest, most knowledgeable language, and see if there are similar concepts and if there are ways to carry out a task more efficiently.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Read Constantly

My last blog post for this year will be on the Apprenticeship Pattern ‘Read Constantly’. I felt that this is an area that I need to work on a lot. I was never big on reading growing up, but as I have gotten older, the more I enjoy reading and having some time to read. While I do like reading more as an adult, I am very picky about what I read. I have an even harder time reading things that are assigned to me from school. Especially those that pertain to my major. This pattern emphasized focusing a lot of my thirst for knowledge on the reading material with books instead of blogs. I think that there are some great books out there but personally I have found it very hard to find those that fit best for me. Especially when it comes to the books that are assigned to me for school, I find that they are just very boring. Understanding programming can be really hard and when there is even hard vocabulary that I need to keep looking up that do not even pertain to the information, I find that very unnecessary. I think that as a student it is also very hard to find reading material that does not have anything to do with what I am learning at the moment. If I don’t have time for pleasure reading, I definitely do not have time for learning reading. They also mentioned articles and I think those are extremely important to keep up to date with. Technology as I have said before is changing all of the time and I need to keep up to date with all of that. Staying up to date will make me a better employee in the future. I would like to find books that more up my alley and more of my pace. Books are so useful and I feel as though they really help improve my vocabulary and writing. While on the topic of books I would also just like to point out what a pleasure reading this book was so far. I loved that is was not your typical programming book. With a bunch of code and then information about it. It talked about topics that are not spoken about much when it comes to programming and starting work. The only thing I would have changed was that I would have sourced many more female programming and people in general. I felt that on my journey of reading this, it was heavily male based. Even with quotes that could have been said by a women. Especially now that the COmputer Science field is opening up more, I would have liked to hear from more female programmers. Other than that, I highly recommend this book and the number of patterns it describes.

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

Find Mentors

I feel as though this apprenticeship pattern will apply to most of us who is nearing their graduation date. Most of us only have classroom experience when it comes to developing and soon we will be part of something bigger than just us. We will be joining an organization that has big ambitions and aspiration to see those goals to the end. What should we expect? How do we learn to work through our problems? How do we learn at all?

The author suggests seeking out someone who has been in this position before and strive to learn from them. Eventually someone will accept you as an apprentice and you would remain under their supervision throughout the apprenticeship while working towards becoming a master craftsman. Now this ‘master craftsman’ who will accept you as their apprentice does not have to physically be available. It could be someone in an online community; anyone in the field that knows more than you do. The way to do this may be to pick a community that is active and learn from the individuals there.

I actually like this pattern because I feel as though all of us need a mentor when we are in the field to help us progress through our development. I hope to apply this to myself and learn as much as possible.

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.

Practice, Practice, Practice.

We all want to get better at something but we often don’t really know what to do to get better. Sometimes, we can find ourselves repeating the same mundane tasks in hopes that something will just magically change or snap and we will be better at whatever it is we are doing. However, this couldn’t be further from the truth. When trying to get better at programming, you often have to practice things that you are not comfortable with. That’s just how learning works. In order to learn something new or get better at something that you need to improve on, you need to step out of your comfort zone in an environment that you feel safe doing so. Although practice may not make perfect, it does make permanent. Even if you are trying something new and you don’t quite get it right away, all that practice beforehand and grinding will not be of waste. You will just be reinforcing your skills, enhancing you previous knowledge. This pattern is great because it tells you to just keep working at whatever task you want to get better at. It also points out that just because you are repeating the same thing, that doesn’t mean you are not getting better at it. Choosing the right thing to practice every day is just as much as a skill as repeating something a lot. They are both important in that you are learning and reinforcing at the same time. Some of the books that the article pointed out that are good ways to ensure you have interesting exercises are Programming Pearls, More Programming Pearls, and Etudes for Programmers. The authors of these books understand that getting fundamentals deeply ingrained does not stop being useful. Practicing anything, as long as you understand what you need to do, you will always get better at something. That is just how practice works. Even if you think you are not getting better, you are still simply reinforcing already known ideas. This pattern is a great example that you can still try something without the fear of failing, because you just get better at it regardless of the outcome.

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

In all honesty, this sprint was definitely the one where we’ve made the most progress. During this sprint we were finally able to get access to the input form and sample output from Joanne and her graduate assistant, Michelle. It took several weeks of continuous emails and a face to face meeting to finally get access to the documents. This has been the story of this project for this semester at this point. From my experience during my internships, the length of time to get a response from someone can vary and maybe it is different because of the many different projects and classes that everyone involved is responsible for, but this seems a little outside what is reasonable.

Our biggest problem to this point in the semester has been a lack of communication between our customers and the other necessary parties that can get us moving with the key details of our project. We were warned at the beginning of the semester that our customers likely didn’t know what they wanted and this couldn’t be more accurate. They have the best of intentions but lack the technical foresight to think about how to organize their project to make it any bit future-proof. We’re doing our best to find a happy medium between a complete rework that makes it more scalable and continuing to follow the flows that they are just becoming familiar with.

The other group working on the food pantry project is doing more of the heavy lifting at this point as they’ve already started working on the interface for what will hopefully one day be the new food pantry software system. It is difficult to communicate with them as we’re basically on opposite schedules and everything is on a two day delay for the most part but we are making the most of what we can do.

My role for the last two weeks has been more of a product owner compared to a developer and it has for the most of this semester. I’m not upset about this as it has been a different experience than what I am used to. I’ve been our point of communication with Joanne and the food pantry workers as well as often the one organizing our Trello board and conducting the planning meetings. There is definitely some overlap between product owner and scrum master responsibilities but I haven’t done almost any code writing this semester. I honestly think what we’re doing better as a group as the semester continues to roll on, is rolling with the punches. We’re getting better at reacting faster to the curveballs that are being thrown our way. We’ve been told that everything that needs to be on the current intake form is already there, but after mere minutes of review, we’ve noted several questions that are missing based on the reports we are being asked to output for the final project.

We’re also getting better at splitting up the work between our group. The roles have yet to see much change as the semester progresses but again, I’m not upset about this and it doesn’t seem like anyone in my particular group is. We’re assigning stories/tasks better so everyone has something to work on throughout the sprint and we’re documenting who is working on what in our Trello board. Hopefully we’ll be able to utilize the issues system on Github as soon as our repository situation is resolved but we’re making the most of what we can do with the tools we are given. We’re noting down which particular project each issue/task/story belongs to by noting “[project name]” at the start of the blip on Trello. Overall, organization has improved and hopefully we’re developing a standard that can be utilized well after we are handing off this project at the end of the semester.

I would provide links to the projects we’ve worked on but they are exclusively private. This includes our private group Trello, Slack, and the access link to our newly acquired mock form/output.

 

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Toying Around

Breakable Toys was an interesting pattern to read about. The premise is that in order to develop your skills, you should spend some time single-handedly developing small software projects. The example the text gave was maintaining a Wiki, which over time develops many skills in different areas. Ideally you will be able to find enjoyment in your toy so you can continue to grow from it. This toy is also something you can take with you, and something you can continue to learn from.

The idea of Breakable Toys was one I’d never really thought of before, but after reading it I can say that I’ve probably used the pattern to some extent. I can recall a time where I was learning HTML and CSS just to customize a web-page on an online game. At first, I had no idea what I was doing, but after some research and a lot of experimentation and trial and error, I began to have a much better concept on designing a web page. Meanwhile, I was enjoying the learning experience and the progress towards building something of my own. The ability to find enjoyment in what you learn is what eventually lead me to where I am in the first place.

After having read the chapter on Breakable Toys, I think I will try to be more intentional with my use of interesting and fun things that simultaneously develop my programming skills. One idea would be to develop a game in a new language, that way I can learn a new programming language and do something I enjoy.  Eventually, I can also develop the same game for any new programming language I wish to learn, as an interesting way to see some of the differences and similarities between them.

Something I’m learning about a lot of these patterns is that they are all sort of things that people just tend to do naturally to try and aid their own development. I guess that’s the whole point of the patterns, but it is really insightful to have some of these ideas put into words.

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.

“Practice, Practice, Practice” Apprenticeship Pattern

I am writing this blog post about the “Practice, Practice, Practice” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about the desire to improve and learn despite not having the opportunity to do so while working. The obvious solution that the book presents is to practice on your own time, while not working. Practicing something is certainly important; the process of practicing working with some idea is actively developing experience with that topic, rather than just reading about it and recognizing it. I have spent a lot of time reading about many different algorithms, and a lot of it does not really stay until I make it relevant by directly implementing it myself. The only consequence of doing this is educational, though; doing this while working would not be the appropriate time. Practice generally does not yield some purposeful product, whatever it is that is created in the end is only for the sake of experience. The book brings up a point about practicing the wrong things. I think this can be important. I have spent a lot of time practicing trying to write programs using the fewest amount of characters possible, which for obvious reasons is not a good way in general to go about programming. The result is typically a barely readable mess of what amounts to glorified machine code. I became good at it, but certainly the time would have been much better spent practicing something more practical than code golf. After gaining a lot of experience with different topics that I found interesting, I have been able to recognize situations where things I have practiced in the past are relevant and knew how to implement them as a solution. What I have noticed along the way is that now I would rather spend my time applying what I know than taking the time to practice something new and not produce anything meaningful. I still am interested in learning about a lot of things, but practice takes a lot of time, so the only way to learn is to take the extra time.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

The Deep End

For this weeks blog post I will be looking at the pattern called “The Deep End”. The context behind this one is that taking small safe steps leaves you unsatisfied and you are beginning to fear that you may be in a rut. Instead of diligence that could attain the next level you are in a rut where bland competence eventually will decay into mediocrity. The problem with this is that you need to grow your skills, confidence and portfolio of successful work. Challenging yourself with bigger things like bigger projects, larger teams and more difficult and complex tasks, new workplaces and more. This will again help you grow as a developer instead of settling for a rut. The solution to this is to jump in at the deep end, taking it head on almost. Waiting until you are “ready” can turn into a disaster or a pattern of never doing anything. When offered a higher profile role or a more difficult problem grab onto it with both hands take it head on. Personal growth will only occur if you are doing something out of your comfort zone and doing things that stretch your boundaries. This of course will have its risks without a doubt. If you get it wrong and way in over your head you could drown. But thankfully in the business there are many places where you can take risks without destroying your career if you were to fail. These risks are opportunities that will help you grow. It means taking a foreign assignment when its offered, even if the possibility of failure is staring in your face. Acting on this will be extremely beneficial to you when in a rut. Thinking of the biggest projects you have worked on and then writing down the answers to these questions pertaining to the difficulty of other projects is a good way to start. Using metrics to measure every project, in a sense, of your own projects. I find this pattern to be very on par with the be the worst mentality. In a sense you are putting yourself in an environment that may or may not cause you to fail miserably but if you succeed you will grow immensely.

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

nurtured your passion

Hello everybody and welcome to another CS 448 apprenticeship patterns blog post. After coming back from spring break which was a relaxing week, the pattern that I will be discussing today is nurtured your passion. This blog covers how to protect your passion for software craftsmanship. I agree with this article when it goes over that the environment can disrupt your passion for software craftsmanship. This article gives good advice on how to keep your focus on becoming software craftsmanship like finding something at work that interests me and that I can enjoy. Also, it’s important to find the time to work on a project that is more enjoyable. I agree on this because during the beginning stage of my programming journey I would work on learning the fundamentals of programming and problem solving which was not really enjoyable and at times I felt like quitting but when I eventually move to the more advanced classes I found that I was working on more application based projects so that made me more passion to learn more but if I was just working on the fundamental stuff than I would probably quit programming because it wasn’t as enjoyable like creating applications. One of the other tips that it gives is studied the classics which was to learn the fundamentals which I understand is important, but I figure it’s better for me to learn the classics and work on the enjoyable project at the same time. I like that tip that you should find an environment that is comfortable to work in because certain stuff can bother you like co-employees, the rate of pay etc. and this can affect your passion for software craftsmanship. All in all, I think this pattern is helpful like all the rest but there were some things I didn’t think we have control of sometimes because yes, we could also leave an annoying situation but many jobs I know from experience always has its flaws but finding a job that provides more enjoyable work it more reasonable. I think this pattern is great and it inspires me to be more in control of my journey.

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