Category Archives: Week 13

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 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.

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.

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.

Sprint 5 Retrospective

This Sprint led to a frustrating conclusion. Our group essentially completed the offline storage service, which incidentally does much more than just store data, but came upon some sudden issues.

Because the service itself can also store, retrieve, delete, and update data while offline to an offline PouchDB database, that actually just uses IndexedDB on chrome, I floated the idea of renaming it to an offline database service instead. The idea was accepted, but currently renaming is an easy step that can be implemented after we get it working.

The main issue that has appeared is a confusing and somewhat baffling error that suddenly appeared. My team mate, Connor, had made a number of new tests for our service that were much more comprehensive than our previous simple ones. Using the tests we could see if the service worked, not just by the test results but by looking at the database itself in chromes dev tools to see the documents stored when the tests ran. The put and get commands added documents to our PouchDB database and would retrieve a JSON object from the database. However, starting this week, it simply stopped working.

I am still testing our service in isolation from the larger project, while using the same tslint.json to keep the format required the same, to avoid needless complications. Last week, running ng test to run the tests for our service through karma could no longer successfully launch. It would fail to open the browser consistently. Looking up the issue, I decided to reinstall the node modules director of my project. This ended up working, but ever since then, the methods in our service stopped succeeding.

The most baffling part is that there seems to be no feedback or explicit error at all. The commands to put and get documents and such are promises with a catch statement, so any errors should be caught and then logged. No errors are logged and yet the commands themselves also do not succeed. By viewing the database itself, it became apparent that no documents were being put into the database at all. Adding several console log statements throughout the methods to see which parts of it were executing showed that the entire put or get promise is being seemingly ignored. The promise has 3 different outcomes, it being resolves, being rejected, or an error happening. None of the options execute, which was very confusing.

This is still an ongoing issue with our service that once we fix should mean we are done. Frustratingly, this issue has shown up in my team mates projects as well, which means there must be something that happened that made it seem as if it was executing flawlessly earlier or we missed something. More research is required to fix this, it is a road block currently. I also discovered the command used for the ng2-amrs project is ‘npm run test’ instead of using angular cli’s test command ‘ng test’. This seems annoying as difference is that ‘npm run test’ seemingly has to be used every time tests need to be run, while ‘ng test’ can be used once and the tests will reload and be rerun whenever a code change happens.

I also did some more research into promises in pursuit of a fix to the issue in our project. I now understand the format of the then method much more comprehensively. And researching the PouchDB Api some more, I suggested some changes to the tests to make them much better at testing if the methods worked.

As long as we can fix our major issue right now, we can essentially finish our offline database and use is to complete the offline storage task of the project. Also, in my opinion, will somewhat easily allow us or another team to complete the offline form storage task.

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.

Thoughts on “Craft Over Art”

Craft Over Art seeks to solve the problem of a craftsman wishing to create something beautiful, elegant, or resume-padding at the expense of the party that commissioned the project.  The authors strongly advise that the craftsman deliver a product that is useful, functional, and to specification rather than one that is fancy, inspired, or unique.  The craftsman also cannot wait for inspiration, and must deliver a satisfactory product on time.  Speed is also not the only concern; the product must have at least a minimum of quality even if it takes a little longer.  This is an important concept to introduce to the client as well.

Although I do not fully agree with everything in this pattern, the basic concept speaks to me.  There are a lot of things that need to be balanced in a professional product.  I have run into this firsthand when developing software for my job; my boss obviously wants a quality product, but also does not want me to spend excessive time on it.  I have needed to balance doing things the “right” or “perfect” way with just getting things done.  I do think, however, there is still some room in my work for improvement of quality.  Reading Clean Code and trying to put those ideas into practice from the start of a project has been helpful, although my current project will still likely need a good refactoring, if the time to do so is in the budget.

I don’t necessarily agree with the way that the authors dismiss the art of programming (and the process of art in general; it’s not just waiting for inspiration to strike), although I understand it’s somewhat beyond the scope of the book they’re writing.  I think there is room for the unplayable “million-line game that pushes the frontiers of computer science” — even if the craftsman (or artist, I suppose) that developed it does not benefit directly, the whole field might be inspired or lifted up.  I think there is room for programming as an art, room to make decisions inspired partly by aesthetics rather than purely by utility.  Maybe that’s only in personal projects that don’t have hard deadlines, but I think there’s space to be found for artistic merit in the professional world as well.

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

Transitioning

After meeting to discuss the current status of the website, there are only a few tasks that remain. Although I am still waiting on some of the design content such as images and social media links to be provided, I think that the website design will soon be wrapped up. Once this happens, the next step will be education and training on the use and maintenance of the site. This should not be too intense because of how intuitive WordPress is to use.

Part of this training will likely involve the transfer of the hosting off of my personal virtual server to a permanent host. While I do not mind hosting the site for the time being, I do not want to be responsible in the case that my server goes down. When using a well known hosting provider, you are paying for someone to take on this responsibility. I have prepared the site to be migrated, and I do not anticipate any issues with migration. WordPress is rather portable, not requiring much more than a few directories and a small database.

One item that still needed to be addressed was the size of the font used on the website. Although it appeared appropriate on my screen, it was difficult to read from a distance on higher resolution monitors. While I had tested the website in a few different browsers and even on my mobile phone, none of these allowed me to view the site as if I were using a higher resolution monitor. During the meeting, when viewing the site at a higher resolution, the text appeared to be “zoomed out” and was difficult to read in some of the lower contrast areas of the page.

The next thing that I will be looking at for the MassHOSA project is QuickBase. I am familiar with the platform because of an internship where I am currently auditing and validating user access to QuickBase. Despite this familiarity, there may be a few obstacles to making the desired changes. After a quick inspection of the application, many of the features required to make the desired changes to the application are blocked due to the QuickBase tier in use. I will be looking for workarounds and discussing the potential solutions during my next meeting.

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

Data Flow Testing

http://www.ques10.com/p/2192/what-is-data-flow-testing-explain-feasible-paths-1/

Finally, for this week I decided to write about Data Flow Testing. I found a blog site called Ques10 and there was a question about what is data flow testing. The blogger Ramnarth ansered the question by explaining what Data Flow Testing is. Data Flow Testing is a test that tells us that a programmer can perform a number of test on data values which are collectively known as data flow testing. With data flow testing it can be performed at two levels static and dynamic. Static testing is performed by analyzing the source code and doesn’t involve in running the source code. It is performed to reveal potential problems in the programs which are also known as a data flow anomaly.  And with dynamic testing it looks at the path of the program from the source code and with this you would draw a data flow graph of the program select a critical testing area, then identify the paths in that data flow and test the derive inputs. He talks about how testing critical section on the data flow chart by breaking it down into paths and tests such as how we did it in class. Were we would look at the DU-Paths and look at all the edges and nodes to see if they make sense. I like this blog because it does involve some of the things that we did in class such as DU-Path testing, edges, and node testing. I like that the things I learned in class is also reflected into real life things we can do. I think data flow testing is just something we could be doing because it is just a bunch of tests that you run through so that way you do multiple test at the same time.

 

 

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.

Don’t Repeat Yourself (DRY)

Source: https://dotnetcodr.com/2013/10/17/the-dont-repeat-yourself-dry-design-principle-in-net-part-1/

For my last week I decided to write about Don’t Repeat Yourself design principle. I found a blog called dotnetcodr and there was this blog about (DRY) written by Andras Nemes where he talks about (DRY). The idea behind (DRY) is that you should not add repetition of logic in multiple places in the code. He talks about the motto that you should be following “Repetition is the root of all software evil.” Repetition does not just refer to writing the same piece of logic in two different places but also the repetition testing, debugging, deployment, ect.

He then gives an example of repetition where he writes out the person and then where the live as well. In this code he hard codes everyone’s name and address. This way it is a very good example of reputation because since he is just copy and pasting whenever he would need to add or remove a person or address he would have to go back into the code and manually change it himself.

I found this blog to be very informative because it is very true you do not want to repeat yourself and the logic of a certain code in multiple places and multiple times. There are times where I do this a lot because I find it much easier to repeat the code since it is going to be the same every time I want to call something. I think the thing I get out of this the most is that I will start to try and not repeat myself when writing code. Also I can use this for future knowledge when I do write things that do call things multiple times and like it shows in the blog we can make stings that have getter and setters that would make a 40 line code down to a 10 line code which would save much more space and time as well.

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.