Monthly Archives: April 2018

Use the Source

Problem

Without exemplars of good practice to study and emulate, the Practice, Practice, Practice pattern only entrenches the bad habits you don’t know you have. If you never walk a mile in someone else’s moccasins, you may come to believe that all shoes are meant to have stones in them. So how do you find out if your work is any good, given that those around you may not have the ability to tell good code from bad?

Solution

The solution the text offers is to seek out other people’s code and read it. Start looking into applications and tools you use every day. It allows to you to learn how other professionals write code, and the thought process behind creating the infrastructure you’re using. When examining open source projects, it’s best to download the most recent version and preferably from the direct source so you can inspect the history of commits and track future updates. Learn the codebase and how the files are structured. Think about how you would have done things differently, and if maybe you should rethink the way you do something because someone might have a better solution.

This pattern has good tips on learning from the source. I liked the idea of starting with tools and applications you work with every day, I think starting with open source projects is a great way to learn how current professionals are writing code and what practices they are utilizing. You may find things you disagree with and things that make you re-think how to approach a problem. I think it’s also good advice to seek out others to read code you’ve written and have them offer feedback. It refreshing to know that so much content is available open source, and it can give people like me access to real working programs that I can learn and possible contribute to in the future. I like the idea of looking into sites like Git, Subversion, and Mercurial and learning how these projects work, and what design patterns and algorithms they are using. I believe reading and understanding open source projects will make me a better programmer, and will help me greatly in my professional career as I continue to add to my toolbox of best practices.

The post Use the Source appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Sustainable Motivations

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

Apprenticeship Pattern: Create Feedback Loops

This week I read the pattern “Create Feedback Loops”. I thought that this pattern was the most one of the most practical of the ones that I’ve read so far because there are so many ways that this could be applied. I also think that this is one of the most crucial patterns that everyone should apply because it has the power of significantly shortening the time it takes to learn, as well as pointing out any potentially catastrophic errors in the way that things get done.

A great thing that this pattern was able to do was telling us some mechanisms that are available for acquiring this feedback. The ways of getting feedback included test driven development (TDD), using type-checked languages, as well as just simply asking a colleague. Of those provided, my favorite is TDD. I am a huge fan of TDD because it gives you instant feedback letting you know that the functionality is implemented correctly, but even more important than that, it lets you catch regressions even faster. I find that TDD is even more effective when someone else has written the tests, and when there are negative tests cases written as well. Fortunately this is something that nearly every tech company practices so I will not have to convince anyone of it’s value. The method of getting feedback that can be the most daunting is asking a colleague or boss, but it can be very valuable. It can be difficult to honestly assess yourself (as this pattern stated), so having the opinion of someone else can help give you a more true vision of your performance. When it comes to asking another for their opinion, the author hit upon a very important idea which is essentially that the given feedback must be “useful”. So if the feedback that you receive is negative and there is no way to grow using this feedback then it is absolutely worthless.

I agree completely with this pattern, and it is one that I intend to use throughout my career. The learning potential using this pattern is extremely high, and if applied correctly will lead to extreme success!

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Find Mentors

This is probably the most important pattern I have checked out in the book by Dave Hoover and Adewale Oshineye. The entire pattern is about finding a mentor/master that helps you walk “The Long Road” with more ease. Allowing you to grow and cultivate your skills into tools that will be used for the rest of your life. The authors make sure to note that since our profession is still relatively young, there aren’t many recognized “masters” of the art. However, your masters don’t have to be physically available to you at all times. Maybe you read a book about someone’s life who really interested you and you begin to develop a passion for the things the author enjoyed, that author will be your master regardless of whether you talked to them or not. They may even be deceased!

The authors go on to emphasize that just because you are the apprentice and your master is the master, doesn’t mean that they are the one and all-knowing god of coding.  No one knows everything. Be free to opportunities and don’t only talk to your master, learn from other masters and expand your mind with knowledge. Lastly, this chapter reassures you that there is no real risk to looking for mentors. While it may be difficult, the payoff would be huge for you. The only risk is getting rejected, which really is not that big of a deal. Most top-notch developers had memorable mentors to help them along the way.

This pattern will certainly affect how I go about things in the future. I had never really thought about going up to someone and asking to be their apprentice or “assistant” but I could actually see it working. I could see someone at a new job being a mentor to me but I could also see myself going to volunteer on a separate project outside of work just to get extra practice and that sense of apprenticeship. I really enjoy the thought of having a mentor, so that may be one of my next steps.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Share What You Learn

I chose this pattern because it is in connection with my previous pattern “record what you learn”.  I also find some useful links to expose your ignorance pattern too. It does made sense to me that after you record what you learn, you share them for other people to benefit from your learning; sharing with others will be easy because you already have them documented. You can share what you learn in many ways such blog post, tutorials and one on one or group discussion with people you think might be interesting in the topic. One on one discussion is sometimes embarrassing if your target group already knows the subject but it is good place to start when you find people interesting in knowing what you learnt.  Sharing is not always easy for me because I always feel like someone has already dealt with what I learnt and no one might need it. But I was proven wrong in one of my presentation as what I shared was straight forward and the people like it very much than what they already knew regarding the subject matter. Also, in the mixed of a team I always try to be first to respond to it if only I have an idea of what is being asked because I know how it helps me in understanding the scope of my knowledge better. This boiled to the point that sharing what you learn will not only make you valuable to the community but will also let you stay on top of your field of study.

Besides, the challenging expect of sharing what you learn is the ethical part of it. Sometimes how to re-factor what you learn into your own work is difficult because it is straight forward knowledge and you can’t go around it to make you own.

After reading this pattern, it has reinforced the power of recording what I learn as it will make it easy for me to share what I learn with others. I also didn’t pay attention to the effects of what I shared in the past and after reading this, it has opened my eyes to look out for the legal, political and financial implication to what I share in the future.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Post #30 – Reflection on the “Sweep the Floor” Pattern

This week, I will be writing a reflection on the “Sweep the Floor” pattern.  This pattern addresses apprentice software developers that are unsure of their place on a new team but want to contribute to the team’s work and earn their trust.  I chose this pattern mainly because the title caught my eye, but also because I think it could come in handy for when I begin my internship, working on a small development team, in June.  Oshineye and Hoover provide solid advice on how to make meaningful contributions to a team by volunteering to perform simple yet necessary tasks.

Some tasks you can complete to promote the early success of the team might be maintaining the build system, setting up the project wiki, updating documentation, code reviews, etc.  They describe these tasks as residing in the “edges” of the project where there is less of a risk of damaging causing damage to it.  The reason that this pattern is called “Sweeping the Floor” is because it refers to the fact that, while sweeping the floor might seem like a mundane and tedious task, it is necessary to the upkeep of any building – and somebody has to do it.  Simple and/or tedious tasks benefit not only the team but also you as an apprentice, because “chores” are often overlooked in academia but doing them fills the gaps in developers’ knowledge.  Oshineye and Hoover raise an interesting point by saying that education means less than college-graduates might think, because everybody starts at square one when they join a new team and, as a developer on square one, taking on mundane tasks is very helpful.

They go on to explain some of the negative consequences that could occur when applying this pattern in the field.  The first negative consequence could be that you might become the team’s “gopher”, the go-to person for mundane tasks, for the duration spent working on the project.  A second negative consequence that could result could be that you no longer feel confident tackling tasks that aren’t like your regular “sweeping the floor” tasks.  There is also the possible negative consequence that you don’t develop an appreciation for the bigger picture while “sweeping the floor” because you aren’t gaining a wider coherence.  Oshineye and Hoover recommend that developers facing any of these negative consequences refer to the “Nurture Your Passion” and “Unleash Your Enthusiasm” patterns.

To implement this pattern, Oshineye and Hoover advise apprentice developers, who are new to a team, to tackle the tasks that everybody else would complain about.  Not only should apprentice developers tackle those tasks, but they should also approach them with creative solutions to exceed their team’s expectations and make the situation fun and rewarding.  I think this pattern will be a useful reference in my repertoire and I hope to implement it in the field, this summer.

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

CS@Worcester – Fun in Function 2018-04-19 23:37:14

This sprint was productive despite lots of small impediments along the way. My main task was to implement the front end of the checkbox we’ll be using to decide whether a user’s credentials will be stored when they log in. I managed to complete this and submit a pull request which got merged by Wednesday.

Problems building the app stopped me from making much progress in the beginning. At first it would just take a very long time, but after pulling changes, the user settings page I was meant to be modifying wouldn’t show up. I had initially placed the checkbox on the login page, which had been easier and made more sense to me, so I asked AMPATH to deviate from our mockup by switching the location of the checkbox to there and they agreed this seemed like the more intuitive choice. Getting a checkbox in the right place was easy once the app would load. The slightly more complicated part was getting the checkbox to appear only if there was an internet connection, since the option to store credentials shouldn’t be available in the offline state. I used an ngIf directive connected to a boolean value, and had the boolean update based on whether the app was online according to the online tracker service. However, the boolean appeared to be updated after the page’s HTML had already loaded, meaning the boolean was always read as its default false value. The checkbox therefore never appeared and the page didn’t update when the boolean changed. I wasn’t sure how to proceed at first, but I ended up deciding that the code controlling the online tracker dot was close enough to what I needed that I could use similar code to control the checkbox. This worked well enough, though the checkbox will simply disappear from the page if internet connection is lost in its current implementation.

Our team also restructured how we wanted to manage the branches on our repository from now on this sprint. The master branch is now a direct copy of AMPATH’s code. The branch which incorporates all our team’s edits is the offline-login branch. When we want to edit the code in the future, we’ll make our own branch for the change, push, then make a pull request to merge the branch into the offline-login branch. I’d made some edits on the offline-login branch by the time I wanted to push my changes, so I made my own branch and used git reset –hard to change the offline-login branch back to the way it had been in compliance with these new guidelines.

The teamwork keeps getting better in every regard, as with this new policy which will improve our organization and with communication. Team members answer requests for help or feedback quickly, getting back to each other within the day and sometimes within minutes.

Going forward, I want to complete the backend of the checkbox, ensuring that a user’s credentials are stored when it’s checked and that they aren’t when it’s unchecked. Both Luigi and I are assigned to this task. We also want to create documentation of our current offline-login implementation to help the AMPATH team and whoever works on our code next to understand what we’ve done so far. I have hope that we can get a decently functional implementation of the offline login done by the time the course ends.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retro

This week marked the end of sprint 5, and so far this one was by far one of the most informative sprints for me as well as the most productive. This week I got the opportunity to dig much deeper into typescript because I needed to implement some back-end code. I got a chance to actually implement some of the basics that I had been reading up on, such as declaring new variables and making variables visible from one class to another. I know these are some very basic things, but this was an important thing to do because it is fundamental to every programming language and having this foundation will help me build and implement more advanced functionality that we will soon need. I also learned that Ampath has some very strict code style settings. I had the build complain because I declared a public variable after a private one, and also because I had left an extra new line between two of my methods. I of course realized this after I had already pushed my changes up to later receive a message telling me that I had broken the team build. Had I known in advance that these rules were so strict, I would have checked the state of the build before pushing up my changes because even though this did not hold our team back long, this is something that could’ve wasted tons of time and should be avoided in the future.

The team worked very well together during this sprint, I would go as far as to say that this was the best sprint that we’ve had teamwork wise. I was having a few build issues and my team members quickly helped me resolve them so I could get back to work. The later on another teammate was having an issues that I previously had, they asked for help and I was able to quickly get them back on track. Even the way that we split our tasks was efficient, we had individual tasks that we would later link together. We would definitely like to keep this very high level of teamwork going forward and improve on it if at all possible.

During this week, the main focus was to get a checkbox or switch that could be toggled to decide if the user would like to save their credentials for later storage and let that determine what happens going forward. We were able to get that done, I was in charge of writing the back-end code (which was fairly simple) and Dominique was in charge of the UI aspect. That however was not the only work that was completed this sprint. There were improvements made to the offline detection that our code used. Previously we would know that we were offline because of a failed API call and our logic would run from there, now we use the service that was written by another group. We have also run some of our proposed changes by Ampath to ask for their approval.

This sprint, we have accomplished a whole lot and the coming sprint we plan on tidying up most of what we did. I believe that after the coming sprint, we will essentially have a nearly have the offline functionality exactly how we want it and we can shift gears and focus on other things like encryption, but in the meanwhile we will continue building on the progress we’ve had.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 4

This week’s Sprint retrospective we had many issues. Most of the group could not open ng2-amrs program. So, for some of the sprint we were trying to get it working. When we first saw the projects, we are all able to download and able to run ng2-amrs program without any issues. However, for some reason four out of the five people’s program were not working. We sent messages to Ampath to see if it was something that they would be able to help us fix. However they were no help. We were also asking other students in the class of they were having similar issues but no one else was having the same issues. Most of us tried uninstalling and reinstalling the program and it did work for a few. While we were trying to work on fixing the ng2 we were also thinking of ideas of how to get this encryption service into the website. First we were thinking that they wanted only an encryption for the password. But from talking to Jonathan this encryption service was meant to encrypt everything from data coming in, going out, passwords, and files. We were looking up research about other encryption services that might have done this before but most of the encryption service are not done offline. This is because we would not be able to save the hash password and the salt on the tablet because if we did they would be saved on the tablet they are using. That is not really safe a encryption especially because it is patient data. At this point we are confused with what we must do. Unlike other projects that give us specifications and an end goal of what they want. The ampath project is different for us because you cannot just message them and expect a response right away because they live on the other side of the world and most of the times when we are brainstorming ideas on what we want to do. We don’t know exactly what they want and when we do ask they gave us a “yeah that seems fine.” kind of answer. Most of times we just want exactly what they want. For me this project has been difference because for other classes and other products that I have been working on such as personal project and project for classes I would be told what the final expectation for this project would be. Since this project for Ampath is such a huge project and many of us are just learning new stuff just for this project. We don’t know much of what they want or what to do. Once we understand that they wanted a websites that would be able to hold all the patient data offline so that they would be able to meet patients where they would have no cellular service. But part of the problem with that is when doing encryption services from the standpoint of view of programmers we want this to be perfect so that way and path would not have any troubles but I’ll find encryption to us feasible or possible we hope that the next Prince able to get a lot more work done we would try and get something so that they can work off of this or maybe the next project for the next class would be able to take the coat that we have now and work off of that

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective

Summary

Once again, i think we had a successful sprint this round. Once again we increased team communications and continued to form better team bonds. This is specifically because this sprints task required us to consult each other for things we have expertise in so we could build together what we needed to build. I this sprint we took upon quite a few tasks to get accomplished. Some of these tasks included taking the offline checking of the current ampath build and moving it to the outside of error checking and by doing that, figure out a way to fix the OnlineTrackerComponent bug we found in the program. Another that that needed to be done was establishing communication mediums with the AMPATH group and addressing some development issues we wanted to discuss with them. We needed to know if we had to worry about storing secondary and additional user login credentials offline. Knowing this would prove pivotal to our developmental Sprint. We were also able to create a backend of the new UI we were implementing using Balsamiq. Another task that was sought out this sprint was to update the HLD with local storage approach and add a checkbox to the user settings page to give option to store credentials locally. This task was taken by one of our teammate and although they were working on it alone, collaboration between the individual groups was needed because there were a lot of dependency issues. 

Reflections 

From this sprint i learnt that sometimes not all the task we seek out to accomplish during the sprint planing is able to make it through the entire sprint. During the initial sprint planning, we had a talk about implementing a local database that would store and keep user credentials so for the few days into the sprint i began building the database base but as the sprint progressed and our team was able to communicate with the Ampath people, we realized that that extraneous part of building the database was not necessary needed. Instead understanding the encryption method of the user credentials would better suit us in our task of creating an offline login. Needless to say, i had to clear the drawing board and start again.

Lesson Learnt

Overall i felt like this was the biggest lesson i could take from this sprint because i started building and spending time on it but since it was ruled out as not necessary, it almost seemed like i had wasted that sprint time. IT made me realize that in this software development industry, the product owner and the businessman have the keys and unless you ask them for it often you will develop and code in a backdoor without even realizing that your design grew old in the specifications. Establish a good and frequent communication method with the people overseeing the demands and design of the project serves as key in become a good program develop. It makes no sense to design and solve a problem with no longer exists in your scope of work. 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.