Thinking Like an End User

I am getting ready to deliver a website product that I have been working on for Massachusetts HOSA. Because I’ve been working on the development of the website for the past couple of months, I am familiar with where to find everything. Once the product is delivered, however, it will be updated and maintained by Massachusetts HOSA. While I would be perfectly happy to continue helping out with the website as needed, I would like to minimize the need for my involvement by making the website as self-sustaining as possible.

In previous blog posts, I already outlined the setup of automatic backups. This makes me feel much better about enabling automatic updates for the WordPress installation. With automatic upgrades enabled, the site will be kept secure and up to date as WordPress and plugin or theme developers release new versions. I would be weary of allowing automatic updates if I was unsure of whether or not there were current backups because of the possibility of an update breaking the site. Occasionally there are incompatibilities between different plugin/WordPress version combinations, or simply bugs in a release that could make the site unstable. In case of such a scenario, having a recent backup that can quickly be rolled back to is essential.

The second part of making the site self-sustaining is to write documentation for the use of this specific WordPress installation. While WordPress is already extremely well documented, this vast documentation can sometimes be difficult to navigate efficiently. I would like to pick and choose the essentials to include in a slimmed-down version of documentation to provide to MassHOSA as a guide for the maintenance and updating of the website. This documentation will include guides for use of the WordPress platform, use of the various plugins that are installed, and also references to the locations of various resources such as backups and styling files.

I am extremely thankful for the opportunities that working on this project has granted me. While I may have had some prior experience building WordPress websites, this was quite different. I got a much better idea of the various stages of a design project and experience working directly with stakeholders to turn specifications into a working, real-world implementation.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Dig Deeper

Dig deeper is a very important apprenticeship pattern to remember throughout your career and especially one to pay close attention to early on in your career.  It stresses that just writing a solution that you found online or just guessed until it worked is not good enough. It is important to know why the code solved the problem that you were having.  You should also look as to why was this the chosen solution, why code A over code B. This will help you stand out at work as someone who is a more effective problem solver. This will also help so you don’t submit a project that is only half complete; maybe the question that was answered on stack overflow did not include a test that was specific to your work.  If you do not dig deeper into your solution you may not realize this and turn in an unfinished project. When you only scratch the surface and just barely do enough to get by or even less than that work falls to others. There is a set amount of work that needs to be done for each project. Just because you do less doesn’t mean less work needs to be done, it just means that you are putting a bigger burden on the rest of your team that needs to complete their own work and pick up your slack as well.

When moving on from school I intend to make it a point to set aside time to review all the work that I complete as well as try to fully understand other parts of the program that I have a chance to see before submitting my work.  I think this will be beneficial for a few different reasons. First it will help set an impression with both my peers and superiors that I am a thorough worker who puts extra effort into my code. More importantly though it will allow me to expand my knowledge and provide the best possible solution for the problem that I am presented with.  It will help a well rounded tool kit that I may not only use immediately but could be applied in the future too. Doing this early on will create a solid foundation to build on for the foreseeable future.

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

Sprint 5 Retrospective

This sprint felt much more productive than the previous sprints from my perspective.  I think that is mostly because we did more than research or creating test programs. This sprint we started writing services for the AMPATH project.  We created an encryption service, at this time it specifically focuses on hashing passwords. We also added a test for this method simultaneously, by the end of this sprint though we were unable to run the test successfully.  Moving forward that will have to be one of the focuses is to get this test working, I believe that it is necessary for us to get this test successful in order to use it as a template for creating our other tests. There are two pieces of wisdom that have stuck with me that I believe will really come in handy for this next sprint.  “Slow is smooth, smooth is fast” and “Those who fail to plan should plan to fail”.

If we rush into writing other tests without building a successful one I think that there is a very high chance that we will get in over our head with too many tests that will fail for various reasons and we will start to try and fix different issues at the same time and just creating more issues.  If we take our time and focus on fixing this test first then we will have a clear picture of what is needed to write successful tests. We need to slowly approach this to help the project from a larger perspective move smoothly and at a good pace.

Since we are quickly approaching the end of the semester and the end of the project, everyone participating in the next sprint planning meeting is crucial.  If we do not take the full opportunity to carefully plan out what we will each be doing over the next week and a half the risk of us falling incredibly far behind to not be able to produce any meaningful deliverable to the project and negatively affect the ability for the other teams to effectively move forward on their own projects.

The service we did write however is a good start, we created an encryption directory within src/app.  In this, we created a hashed password service that takes a string and hashes the string. In the spec service for the hashed password, we wrote a test to test if the hashed password does not equal the original string that was used as a test password.  The test originally failed and produced the error that “Cannot find type definition file for ‘source map’.” After doing some research I thought I found a solution for manually adding “@types/source-map” to the package.json folder. After adding this and running ‘npm install sourcemap@latest –save’ the new error that was given was that there were now conflicting definitions for source map.  The solution on stack overflow that I found called for doing both, but I will now try removing the line from the package.json folder and see if that produces any significant changes. Depending on what that produces will determine the direction that we move in from there.

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

Retreat Into Competence

This weeks second pattern can be considered a bit of a counterpart to the first. The Deep End described going headfirst into a new challenge to get yourself out of a rut and advance your skills. But what happens if you go too far, like the pattern cautioned? What if you bite off more than you can chew?

This is where the pattern, Retreat Into Competence, comes in handy. It is in essence , as the name states, is a retreat from the challenge. If you take a challenge that seems to be impossible or you can not make any headway into, then the wisest course of action might be to simply take a break. Gives yourself a breather, but not just that. You want to not only take a break, but also invigorate yourself and bring back your confidence if you were close to throwing in the towel. So once you retreat, do something you are competent in. Change course for a moment and do something you know you are good at or enjoy. Then once you have realized how good you actually are, dive back into the problem with more energy.

By taking a step back, you can fling yourself back at the problem with much more strength. And by taking a step back and giving yourself some space, that allows you to talk to mentors or others you know that can help you. With advice, tips, and renewed confidence, actually solving the challenge before you becomes much more likely than continuing to bash your head against it over and over again.

Overall, this pattern makes a lot of sense to me. Throughout my life, taking a a respite from something that had me in a frustrated loop of failure, and then coming back, led to me succeeding soon after. This does not just apply to software craftsmanship, it is a pretty universal tip for problems. Retreating can even provide a new perspective that would be impossible to gain with the tunnel vision that usually comes about when focusing on a challenge for a very long time. I have also had times where the retreat becomes me giving up and never coming back too, like the pattern warns. It can definitely be a double edged sword, so take caution.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

The Deep End

This weeks first apprenticeship pattern is The Deep End. The main issue this one is trying to solve is essentially getting into a rut. When one is just competently doing their job for a while, they are not preparing themselves for the next step or improving themselves. They are not advancing themselves as a craftsman, but simply doing a competent job and nothing else. As it states pretty succinctly, bland competence eventually decays into mediocrity .

A software craftsman has to improve their skills and their confidence, they need challenges. By not taking challenges, advancing in ones career becomes difficult. This is something I myself have experienced, especially during my college career. This is mostly due to the varied classes taking up both my focus and time, making it difficult to fully devote myself to advancing my software skills. This fed into a bit of a negative feedback loop where I would get down on myself for not working hard enough on challenging myself or being productive enough, which would definitely not encourage me to do more.

As the pattern states, a solution to this is to simply force oneself into a challenge, that requires ones full attention and learning new skills. By forcing an ultimatum, essentially, where one either grows and succeeds or fails, growing becomes much easier. Also, in my opinion, having a new project in and of itself is a very motivating thing. Something new that you might not even know how to begin solving is very exciting. It is akin to a new toy, playing with it can be much more appealing. It is a bit shallow, but it is true. Also, by being challenged, it can rouse the pride of a software craftsman inside that might have slowly faded in the rut.

I agree with the text, it can be dangerous to go head first into a challenge or big change without any help or guidance. While a big, new project can be a change of pace that allows one to break out of a rut, it can also cause them to fail and further entrench them or worse. It is important to throw oneself into the deep end, but make sure there is a lifeguard present.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

This week I read the section called Expose Your Ignorance. This sections is something i can relate to very well. I am a senior in college and by that time many people would think that you would be able to program thing by yourself.  You should know about at least 2-3 languages by now and have the knowledge to work in the real world however just like the section “White Belt” there are always going to be people better than you and you don’t know everything yet. It is still a learning experience and for me in the class that we are taking now the section we are doing for the project. Which is encryption services is still something I don’t know much about at all. Just saying that you know nothing about something would be better then you hiding and saying nothing. That is what a team is about. To help and encourage each other to do what you can do and that way you can help them when they need help. During hackatons that i go to when meeting new people if we wanna work on a project we all have to introduce ourselves to each other. We also have to tell people what we can and can’t do because if we depend on someone to the most important part of the project and they don’t have the knowledge to do it in the end we would not have a project to present. Also just because you don’t have the knowledge to work on the project you should not just sit around and do nothing. Take this time to learn a new language, download the library’s needed to work on the project, watch videos, and work with a project partner to see if there is anything you can do. Just like the section says people are more inclined to make themselves look competent then just to tell others that you don’t know what you are doing because there are people looking up to you for advice or employers looking to you for the knowledge. That is why this section teaches you that you that lying about knowledge inst worth it and to accept your faults and work on them another day.

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.

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.