Author Archives: mesitecsblog

Revealing Ignorance

Hello, again fellow readers!

Today we will once again be continuing our journey into software apprenticeship patterns. From last week, we will continue on to the next pattern, Expose Your Ignorance.

This pattern is all about once you have gotten yourself onto a team where you can learn more from your fellow teammates, presumably in a job. The problem is that well… you are ignorant. You need to deliver and you have a lack of knowledge in whatever language or technology you need to be able to deliver.

The offered solution is fairly simple, ask questions and don’t be afraid to show that you are ignorant in a particular subject. You should recognize that it is human to want to appear competent and not appearing competent is not a bad thing. It is all part of the learning process. As a software craftsman, you need to know many different subjects and technologies. The pattern suggests that people who are uncomfortable with the learning process of appearing ignorant become experts instead. They seek out expertise in one particular field and never venture too far from it. Experts are important but the journey of a software craftsman is much longer and requires a broader scope of knowledge. You become an expert in one or several subjects along the way but that is not the ultimate goal. For a software craftsman, one of the most important skills is the ability to learn. To solve this problem the pattern suggests writing down a small list of thing you don’t really understand about your work and posting it in public view.

This pattern I find interesting. What I found most interesting was the distinction made between the software craftsman and the expert. The pattern admits that a software craftsman will likely become an expert in a few subjects but that is not the ultimate goal. The goal is not explained in the pattern (I’m sure it is explained at the beginning but I have forgotten it at time of writing) but the difference between the expert and the craftsman is that the expertise is not the goal. A craftsman goes further than becoming an expert and goes on to craft with the expertise of many under his belt where the expert gains expertise and then rests on his laurels. I do also appreciate the part where it states that by admitting ignorance it will increase your reputation greater than “fake it until you make it” will.

That’s it, for now, my fellow readers. Until next time!

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.

Let’s Learn Some Concrete Skills

Hello, again my fellow readers!

This week we shall continue looking at Apprenticeship Patterns. I decided to skip over the Unleash Your Enthusiasm pattern and instead decided to talk about the Concrete Skills pattern this week instead.

The Concrete Skills pattern seeks to solve the problem of joining a team of craftsmen to further your learning opportunities. This could also be the all-important problem of getting a job. The problem keeps on going as you are too much of a risk as you may not be able to directly contribute anything to the team. You may not be able to even indirectly contribute.

The solution proposed is fairly self-explanatory. It’s right in the name of the pattern! Acquire concrete skills that allow you to demonstrate ability with relevant tools and technology. The pattern does suggest acquiring some skills that are geared more towards getting past HR and managers. I do like the proposed idea of “buzzword bingo” that the pattern mentions briefly. The rest of the concrete skills that you learn should be directed at showing your team that you are actually useful and that someone doesn’t need to look over your shoulder constantly to ensure you don’t mess up or break something. It goes on to make a good point. When faced with a hiring manager, they will ultimately be looking for someone who can actually contribute in some way on the first day. Having concrete skills is, as the pattern puts it, a way to meet them halfway. Then as you progress, you will have to rely on these concrete skills less and less. To learn what concrete skills to build, the pattern suggests looking at resumes of people whose skill you respect in the business. Identify some skills from the resume and work on them and of course, keep reviewing your own resume.

This is what drew me to talk about this pattern. It is directly relatable to me as I am in the job hunt as I am graduating soon. I found this entire pattern to be generally good advice for anyone in the software development field seeking a job. It also corroborates what a lot of people have given me advice for job hunting.

That’s all for this week. I wonder what pattern I will get to read about next?

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.

You Must Learn To Unlearn

Hello, again my fellow readers!

Last week we took a look at the beginner pattern, Your First Language. This week we will continue along the path to the next pattern, The White Belt.

As I have said, The White Belt is the next apprentice pattern after, Your First Language. This pattern is all about what to do after you have learned your first language and can strut your stuff with it. The problem The White Belt pattern is here to solve is when learning a second language becomes tiresome and tedious. Learning one language is great but, expanding your library is a must to become a software craftsman. What can happen, however, is slowdowns and stalling in learning. The solution to this is to adopt the mindset of a white belt. To quote the book, “Wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.” In other words, while you go about learning a new language, treat it as if it was brand new to you, even if you are learning something with familiar attributes. An excellent example is you have learned Java and now you are learning JavaScript. Both are fairly similar to each other and have overlapping ideas and methodology. Using the white belt philosophy, treat learning JavaScript as if it had no relation to Java. While this may seem counterintuitive (it still does to me),  the pattern claims that it will accelerate your learning. It will also allow you to discover new possibilities, as well as your mind, is open and without preconceived notions.

I understand where this pattern is coming from. I do get that an open mind can, and most likely will, lead to new possibilities. I agree with that. I suppose that my issue is that forgetting to accelerate learning is still something I find a bit backward. Looking at it, I must admit that I have not tried this method. Typically I find that making associations to things you do know is a good memory tactic and can speed up learning. It is entirely possible that the White Belt pattern will work for me. The only thing for it is to try it. I can legitimately say it doesn’t work without trying it for myself now can I?

Looks like I have some unlearning to do in my future.

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.

Going Back To Square One

Good my fellow readers!

Today I will be discussing an individual Apprenticeship Pattern from the book, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The pattern I would like to discuss today is naturally the first one, Your First Language, because where else is there to start but at the beginning?

The pattern starts by defining itself as a pattern for those who have surface knowledge of a couple of languages. It suggests that this particular pattern is for those who need to learn a language to solve a problem at work for example, or need to know a language for a job interview. It then launches into the solution, through execution of the pattern. To put it plainly the pattern is to pick a language and learn it. Having a problem to solve helps the process by giving you a goal to work towards and a drive to keep learning. It is also advised to take things slow and in small steps. It is also suggested to find a community and learn from its members as some methods or teachings may only be spread by word of mouth. It ends by reminding the reader to not get stuck with one language and to spread out into other languages.

I will admit, with this being the first pattern in the book I expected it to be for total beginners but it is aimed at just about everyone. What I find interesting about this pattern is that it seems to cater well to those who have never really picked up coding before or someone who, like myself, have had years of high school and college education in coding. I will admit that the amount I know about all the languages I have learned about is somewhat shallow. Some go deeper but many are probably not that far off from just surface knowledge. I might just try following this pattern after graduation. At first, I would have only recommended this pattern for only beginners who haven’t had formal schooling but after reconsidering, I think even those like myself who have had formal schooling can benefit from this pattern.

That’s all I have to draw from this first pattern and I hope to get more from future patterns. 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.

This Is It, The Final Sprint

Hello, once again my fellow readers! I say this with some sadness as it is my last retrospective for the semester. The final sprint has ended and the team is now in full presentation mode. For the sprint, some of the team decided to keep working on the product and some of the team, including myself, decided to start work on the presentation.

The part of the team that decided to continue work on the presentation worked on small improvements to the product. Small improvements to features we have already implemented and making aesthetic changes.

The rest of the team, including myself, started our presentation work by making a presentation. From here, we decided to break and each of us would start working on our own portion of the presentation. My part of the presentation consists of what happened a few weeks ago with the GitLab to GitHub transfer. You may remember that series of events from my sprint retrospective blog a couple of blogs ago. The main part of this presentation is not just to recount everything we’ve done over the semester, however.

The big part is to recount everything we have learned over the semester. To do this, I needed to go back and reread all of my blog posts. Boy, it has been an interesting ride this semester. Looking back, I have to say that I like Scrum. It took a little set-up but by the end of it all, Scrum worked out pretty well for our team. Everyone in our team was able to step up and take lead when they wanted to and no one person was ever the leader all the time. It definitely led to great teamwork and helped each and every one of us to achieve our individual and team goals. What I find interesting about Scrum, and if anyone wants to replicate Scrum successfully is that I find that Scrum works best as a team that self regulates itself. What I mean by that is, the team is able to find team members that are slacking or behind due to other reasons, and help them get back on the horse. If the team self regulates itself, the team can keep itself on track and make up for momentary weaknesses.

Another thing I learned was quite a bit about Git. When the git repository transfer had to happen as you may remember, I had to transfer our project from our GitLab repository to the min GitHub repository. This process that I went through taught me two things. The first was that we should have planned a bit further in advance when we first created our part of the project. We created our part in GitLab, without a thought. Thinking ahead, we would have definitely chosen to make it in the main GitHub branch we had created. The second thing I learned was about Git itself. During the process of moving, I thought that I could just simply copy paste our files in. That was not the case, and I had to enter in lines of code in some files, to preserve the work that other groups had done. I also had to deal with numerous merge conflicts that I had to deal with as well. I learned from that process how to better deal with those merge conflicts, and with moving files and things into a git repository.

Well, this is it, readers. That’s all I have to say on this semester and I definitely I can say that I got something out of it. This will be the last farewell as not just the semester is ending but I am graduating as well. No more blog posts for me… for now. I may return to writing blogs as they did help me reflect but we will have to see in the future whether I return. I must end sometime, so for the final time farewell my dear 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.

Another Sprint, Another Retrospective

Good day to you again, my fellow readers! Well, the time has marched on and I have once again found myself at the end of another sprint and you know what that means; time for another sprint retrospective.

This sprint has been a bit slower than the previous sprint was. With the trials and tribulations of relearning or learning angular (in the case of some of our group members) behind us, many members of the group were able to excel and start knocking items off the backlog. With each item off the backlog, my teammates were even able to add on extra features and improvements. Content for the left navigational bar was established and each was given an appropriate button. We then added submenu buttons, for items that belong under a certain category and not on their own. A home button was added to take the user back to the main screen, return from the left navigational bar and close it. Many aesthetic changes were made as well. Buttons were moved, spaced out more, colors were changed to make it more aesthetically appealing and less harsh on the eyes, the font size was increased for better readability, and the text that confirmed a button press was moved to be centered on the page. The latter was simply for testing purposes so that button presses could be confirmed that a button press would actually register and change to the appropriate page.

On the last day of the sprint, our manager/professor informed us that another team working on the search bar function for the AMPATH application wanted to push their work to the Github repository and we needed to push our work as well because we had made a base application in addition to making the left navigational bar.  As one could expect, there was a problem. The issue was that our group had made a repository and were not working off of the branch we had created. Now, this may not seem like a problem however, the repository we made was not on Github, but in Gitlab! Remembering the Git lessons I had just had earlier in the day, I suggested simply setting a remote upstream to the branch in the main Github repository from our Gitlab repository. We could then simply push from out Gitlab repository to the Github repository and all would be well. With approval from the professor, I made sure to pull all changes from my team members, set the remote and attempted the push. Error. Of course, things can’t be easy. The error was a permissions error that would not allow the push if I remember correctly. After conferring with the professor again, he determined that the best course forward would be to simply copy over the needed files and make changes where needed to other files and push those changes to the branch. Then request a merge with the master branch to make the changes available to the teams that needed them. This was not terribly fun as while some files could be copy-pasted in, there were many files that I had to manually edit and add in lines that we had added. Before attempting a push, I made sure that the application actually ran, which it did after installing npm. After pulling all changes and completing the manual edits, I attempted to push the changes. Error.  I was missing files from the master branch. I pulled from master and tried again; same error. I wasn’t sure what was going on as I had just pulled and there were no updates. I pulled again to receive a no changes message. This had stumped me. This left me with only one option, sleep on it. After waking up, I came back to the issue and had a random thought to pull from the branch, and it worked. When I went and attempted the push, I had one more error, but that was because I forgot to check the master for updates. One final pull from master and I had done it. I was able to successfully push to the branch. To end this saga, I made a pull request to merge our branch into the master branch. That saga was great practice with Git and solving its many errors.

That’s it, readers. Another sprint comes to a close. We have only about one or two more sprints left so the time we have left is quickly coming to a close.  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.

Let’s Sprint, Into This Retrospective

Good day my fellow readers! Welcome back to another sprint retrospective. This is the fourth sprint in the AMPATH project. With things kicking off last week, we are into the thick of things working on the project.

With the new sprint, and a new goal in mind, the group decided to tackle the side navigation bar in pieces. As a group, we all sat down and discussed what are the components of a navigational side bar and, what components we should prioritize. As a group, we decided to prioritize the skeleton, button tasks, design, scaling, content, and web view. This, of course, lead to more learning about Angular. The sprint continued on with the group working off of a dummy app that one of the members had made. This is a concept where one makes a dummy or a toy of sorts. This dummy or toy serves no purpose to the project but, acts an environment to learn and mess around in. This way, one can learn in depth about say, for example, an Angular app, without impacting the real and important app in a negative way. You can make mistakes on the dummy or toy, and learn what not to do when working with the real thing. This was quite helpful to everyone on the team. Thanks to the dummy, by the end of the sprint, we had a working side navigation bar with working buttons. We had even worked out a nice design for the side navigation bar. While I was researching scaling, a fellow team member brought up that scaling might not be an issue that we need to tackle at the current moment. Taking time to look at his opinion I came around and began to agree with them. At the stage we were in development, we were developing for one kind of screen, our computer screen. However, we did not realize this until the end of the sprint. During the sprint review in class, we decided to look at the side navigation bar in the current state that we had it. Looking at the side navigation bar, the group started discussing on what devices the app would be used. Doing some quick changes to the side navigation bar, we quickly found that if we wanted to have the side navigation bar used on multiple varied devices, we would need to have the side navigation bar adapt to the screen size of the device. I will admit that after discussing how needless scaling was earlier in the sprint, now finding out made me a little embarrassed. For about half of the sprint I was doing a little less work than I should have been, thinking that my assignment was not useful and I would not need to learn this. This has left me with egg on my face and a bit of catch up work to do.

At the end of the sprint I have come out learning two important things. The first is that while it may not contribute to the project directly, making a dummy to learn about a component is a great learning method. The second is that even if something seems, useless in the current sprint, it is best to continue working on it, as it may be useful later on in the sprint.

That brings us to the end of another sprint review. See you 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.

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.

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.

My First Sprint: A Retrospective

Good day my fellow readers. Today I will be writing a retrospective on my first Sprint. For this Sprint, we were tasked with mainly setup tasks from our Product Manager. The first task we as a group decided to conquer was the simple task of reviewing the README for the AMPATH software we would be editing. It appears that, from the last time our Product Manager worked with AMPATH, there was a contributing section that was removed in the current iteration. The next task tackled was to create a Github organization, fork the ng2-amrs software to the organization, and clone the software our machines. We then needed to ensure that npm, Insomnia, and a Typescript compatible IDE were all installed on our machines. I believe that we will need to install Gradle as well for some of the testing packages but, due to the pains that come with installing Gradle, as a group we decided that we can put off installing Gradle until it is determined that Gradle is actually needed. With all that situated, we then installed and played around in OpenMRS, a demo of an EMR, or electronic medical record system. The point of this was to gain a feel for an EMR first hand and it was neat to play around with one. The next task was to actually get ng2-amrs running on our units. This was the troublesome part of this sprint. During this part of the Sprint, I got sick and regrettably, did little towards getting it running on my unit at first. During that time, however, others in both my group and the other AMPATH groups did solve many of the issues that would crop up. This created a wealth of troubleshooting resources and made it much easier for everyone to get their ng2-amrs software working. At the end of the Sprint, our group did have a couple tasks left that we did not accomplish and had to push to our next Sprint. These tasks were to install both Karma and Protractor and learn more about both of them. They are both testing software that we will eventually be used for testing our changes to the AMPATH ng2-amrs software. We also pushed having everyone up and running with ng2-amrs due to some members, including myself still having issues getting it running. Thankfully, two members of our group have the software fully up and running.

This Sprint has forced me to dive back into some work from a previous class to remember how to work with npm and Insomnia. While I did not need Insomnia, in particular, this sprint, it was collateral learning. I also got a chance to learn about electronic medicals records as well and get a, “peek behind the curtain” as it were. We not only had to mess around with the OpenMRS software, but we also had to listen to an article called, “Why Doctors hate Their Computers”. This article, in summary, told the story of doctors struggling with their new EMR software and investigating the cause of this hatred. In the end, I came to the conclusion that the cause of the pain of doctors was that the EMR software was directed to the patient as the customer, rather than the doctors who actually use the software. This did put a thought into my mind that while working on the AMPATH software I should not only keep the doctors in mind but keep the patients in mind as well.

That is what happened, and what I learned on my first of many sprints to come. See you 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.