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.