This Sprint was a good one. We gained traction last sprint and kept that that going this sprint as well. The momentum was not fully there as Spring Break was a bit of a speed bump to getting in to the flow of the project, and then afterward many end of semester projects came up that took my time. But either way, by the end we had the basic bare bones of an offline data storage service, a good stopping for next sprint to continue and hopefully finish off.

I continued experimenting with PouchDB this sprint, still on a separate angular project than the ng2-amrs project. This was mostly to avoid the hassle of installing and getting PouchDB working on the ng2-amrs project, as I had seen and heard frustrations from my team and others. This also let me worry solely on getting PouchDB working in a project and creating a successfully working angular project service to handle the logic of the offline storage, with methods for adding and getting documents from the PouchDB database.

I realized after a meeting with my team one day that the formatting of my code was different than the project, and so I copied the ng2-amrs projects tslint.json file into my own to make sure transferring any code I used would be easy and issue free. I fixed my function calls to use the recommended “ => “. After I made the code still work and formatted correctly, I created a new service called simply “offlineStorage”. It had a cunstructor that created a new PouchDB database, and just two methods, one to add a document to the database and one to get a document back.

The code in these methods was reworked code from the examples on PouchDB’s website, with added console logs to see the results. Then to actually test the service, I modified the .spec file for it by adding more tests than the default one. This part was done along with my entire team across two of our in person meetings. We were able to confirm that the service actually created a database, added documents of given data with a given id, and got documents back with a desired id.

The main issue that popped up with the tests were the fact I and my team were wondering how to interact with the documents received by using the get command. When checked the type of the response, it simply stated it was an object. I was not sure how to check the contents of the document and see if it was the correct one. On the last meeting our professor helpfully suggested we see if it was a JSON object, which it was. I felt a bit silly, but now with that issue solved, working with the documents we get from PouchDB and possible ones we add into PouchDB should go much smoother.

During this sprint, occasionally conversations would veer into discussing how we would receive the data from an mrs server and what kind of format the data would be. But after discussing it among ourselves, a helpful diagram drawn up by our team mate Connor showing our role in the overall project and we decided to only worry about our task, offline storage, and nothing else. So we are going to focus completely on fleshing out the service that will handle offline storage tasks using PouchDB. With a narrowing of possible tasks, the division of work for the next step should be very clear.

I feel like it took a bit, but we cleared another hurdle. After this we should speed up next sprint, and hopefully have a completed service that can handle offline storage and a pull request to the master ng2-amrs project by the end of next sprint.

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.

“Dig Deeper” is a pattern that I wanted to apply before I’d read about it. Ever since I started taking computer science courses past the 101 level, I’ve had the persistent nagging awareness that the knowledge I’m gaining is superficial, and there is so much more to be understood. I can feel the difference between knowing how to solve a problem and knowing why the solution is the correct one or the best option within the context of the problem. While deep understanding is a goal for its own sake for me, the writers present this as a goal because of the many problems that arise from only having a shallow understanding: being unable to fix subtle bugs, difficulty maintaining your own code, not realizing a problem you’re trying to solve has a well-known solution or is impossible to solve, and people thinking you’ve misled them about what skills you have. In addition, the lack of awareness of how little you know generates problems of its own.

To gain a deeper understanding of the technologies you use, the writers suggest reading specifications and learning from the original sources to see how the ideas came about.

I subconsciously understood this second method was important. My initial intention in studying computer science was to learn the entire history of computers as a way of discovering why things are the way they are now. I felt like I wouldn’t truly understand until I did that. Additionally, I also heard from several sources while learning C that The C Programming Language, the book co-written by the language’s designer in order to introduce it, is still the best resource there is.

The writers warn that if you apply this pattern regularly, you will naturally end up being given the most difficult assignments. This gives you the opportunity to both fail and succeed spectacularly. You will also likely be the one everyone turns to for code magic when they can’t figure out what they’re doing wrong. They advise you to continue searching for opportunities to be the worst one on a team.

This pattern is probably going to be the one that influences me the most, because it gives so many specific examples to look up of resources that lead to deeper understanding. I’m going to immediately go and apply this pattern, because I’ve been wanting to dig deeper in order to better understand the medical app we’re working on in the Software Development Capstone. Roy Fielding’s PhD thesis on REST sounds promising.

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

Encapsulation is a technique in programming where the programmer hides the internal behavior of the object from the user. Encapsulation hide the inside view of the object from the user such that it only implements the behavior of the object. Usually the client does not need to know the detail of the program and that is exactly what encapsulation does.

Encapsulation hide the data for object and makes the variables as private, and expose only the property to access the private data which would be public. So, when you access the property you can validate the data and set it.

For example, let take a Mobile Phone and Mobile Phone company. Suppose you are a Mobile Phone company and you designed and developed a Mobile Phone design(class), now by using machinery you are making a Mobile Phone(object) for selling, when you sell your Mobile Phone the user only learn how to use the Mobile Phone and not how the Mobile Phone works.

Again, let consider a TV operation for example, the manufacturers encapsulate it with cover and we can only operate it with the remote and have no need to open the TV and change the channel.

In this regard, everything is in private except remote; so anyone can access to operate and change channel and not the things in TV.

Reference:

https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

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

This week’s resource can be found here.

I chose this resource on code review because we’ll be doing a code review ourselves this week, and it not only outlines several types of code review but also includes interesting additional information like statistics about which code review practices produce the best results.

There are a few unexpected benefits of reviewing code. Situations that foster communication between programmers about the code they’ve written help distribute the sense of ownership over any particular piece of code, which is useful because blaming each other for faults in the code doesn’t help anybody. Code review can also serve as a good educational tool for newer developers, as more experienced developers can point out ways to write cleaner code and shortcuts to solve common problems. A more obvious benefit is that human inspection is the best way to find complicated problems in the software’s requirements, design, scalability, error handling, and other non-code aspects like its legibility. Lastly, knowing your code is going to be reviewed demonstrably improves the quality of your code.

There are several methods of lightweight code review that fit in with modern development. Code review can be done in an email thread, for example. The benefit to this is its flexibility, as it doesn’t require everyone meeting at the same time. The downside is that the original coder ends up with a bunch of different suggestions that they have to sort through instead of the group reaching a consensus on what should be done.

Another lightweight method is pair programming, where two programmers work on the same piece of code and check each other’s work as they go. The benefit to this is that code review happens automatically during the development process. The downside is that the coders can’t get much distance from their project, so they lose the advantage of a fresh set of eyes looking at it.

Third is the over-the-shoulder method, in which someone reads your code while you explain to them why you wrote it that way. This is intuitive and very lightweight, but problems can arise if you don’t document what happens at this meeting.

Tool-assisted code review involves using software to help with the review process. Programmers can contribute reviews at different times and without being in the same location using this method, which offers the flexibility of reviewing by email thread with more organization. You still miss out on the benefits of meeting and discussing in person, however.

In addition to making me aware of several different code review options, this resource has provided statistics on how best to use these methods. Code should be reviewed in chunks of under 400 lines, as defects stop being uncovered with anything more. Reviewing 300 lines of code per hour or under and a total review time of under an hour results in the best defect detection. Defect detection drops significantly after 90 minutes of review time. These are very useful things to keep in mind.

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

In this blog post, Justin Albano talks about the Factory Method Pattern and gives us an example.

The Textbook Definition

According to the Gang of Four book that defined the technique, the intent of the Factory Method pattern is as follows:

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Using the Factory Method involves creating two sets of interfaces: “(1) the product interface that constitutes the object to be created and (2) the creator interface that constitutes the object that will instantiate the product.” The UML diagram for the Factory Methods is below:

The author explains the UML diagram as the following:

Using the general pattern, we build a Creator interface, which includes one or more Factory Methods, as well as any number of other methods. This interface may also be an abstract class with defined methods or even a default implementation of the Factory Method that returns a default instance of Product. From this interface, a set of ConcreteCreator classes are created that return desired ConcreteProduct instances that implement the Product interface.

An Example in Java

In the end you should be able to do something like this:
PersistedFile file =
   new PersistedFile("/foo/bar/text.txt", "Hello, world!", new Sha256Encryptor());
View complete example here

Colloquial Definition

A method whose sole responsibility is to abstract the creation process of an object and return that object.

I chose this resource because I am interested to learn new implementations of popular design patterns such as the Factory Method. This resource gave a detailed explanation along with other patterns that can be good alternatives to the Factory Method pattern like the Template Method pattern and Strategy Pattern. I believe the content of the article is very detailed and informative. The example they used is very interesting and I’m going to implement the code myself to test it out. I plan to use this and many other design patterns in the future. I learned more about the Factory Pattern method and when it is appropriate to use it.

The post Java: The Factory Method Pattern 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.

Episode 10 by Brent Jenson and Allen Page.

In this week’s testing podcast episode, Brent and Allen begin by discussing changes that Microsoft made during the absence of Allen in the testing department. Microsoft decided to shift their focus to a quality assurance based system instead of emphasizing on a testing based platform. Although these concepts are closely related in the field of software testing, they each specifically represent something different. Software testing is usually the process of executing a system with the intent of finding defects. By process of testing, we are able to assess or evaluate the capabilities or attributes of a software program’s ability to adequately meet the applicable standards and customer needs but quality assurance on the other end refers to a set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives. These new implementations by Microsoft forced engineering managers to move between teams and successfully understand the overall product specifications that need to be accomplished. After this talk, they moved over to duties and abilities of a manager the drives a QA team into either being successful or a failure. Inadequate technical skills and bad manners often lead to the demise of a team according to Brent. He believes that a manager that falls into this category only knows how to “demand more from the sausage crank”. This not only damages the crank but also shifts the focus of the operation. Increasing the fire under the meat provides more desired result. The fire is resource and help that is needed to get the task accomplished. The sausage is the software and the crank is the team members. To be a good testing and QA manager, you have to task the team members with things you would do yourself if you were the worker. Understanding that consistency and confidence in you by your employees pushes the team momentum forward. Another big factor is that product quality directly relates to the team adequacy. The best products more likely than not comes from the best QA and testing teams. Understanding that the well being of a team affects the product they are able to produce is one of the first steps to succeeding in creating a great QA and testing team. Good organizational health has to be the focus of every organization that supplies products and services to users.

Sources

https://testingpodcast.com/category/ab-testing/page/7/

http://www.mosaicinc.com/mosaicinc/rmThisMonth.asp

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.