Blog Reflections #4 - Project Update

   We have to change our project again because of lack of testing documentation with Express js. Another problem with Express is that it is written in Javascript. We would not be able to run executable tests with any open source project written in Javascript. Express also did not have much documentation on the tests. Whenever we ran the tests it showed the amount that failed, and the amount that passed. It did not say

specifically what was going on in this test. I wanted to choose an open source program with more documentation.

    So I started to look at Firefox. Firefox is a well-known web browser for Windows, Mac, and Linux operating systems. It was created by the Mozilla Corporation. The Mozilla Corporation's site had many resources for developers. This was something I definitely wanted when looking for a new project. Because I have never worked on an open source project before, I wanted a wide range of support in case I had an issue. On the site, they had very clear instructions on how to build and run Firefox. It also had links to websites that explain how to run tests.

Running Tests

   I know that Firefox has many tests associated with it, but I am having troubles finding out how to run these particular tests. I am having issues loading Marionette (an Python test runner for Marionette tests) to my system. I need this in order to run the Python tests on the Firefox system. 

 I am currently reading any online source I can find to build Marionette and have these tests up and running. This is becoming very time consuming, but I feel like I am close to a result. I am excited to see what components of Firefox these built-ins tests test. 

Reading Response, Blog Reflections #3 -Team experience update

Chapter 8

  Chapter 8 of the textbook talks about Development Testing. I learned alot about the benefits of test-driven development. These included:

Code Coverage - every code has one associated test.

Regression testing - a test suite is developed incrementally as a program is developed.

Simplified debugging - the problem should be obvious when a test fails.

System documentation - tests act as a form of documentation of what the code should do.

I never did test-driven development so it was good to see what the benefits of this type of testing is.

Team Update
My team and I decided to choose the Express open source project for our semester project.
Express is a web application framework. It utilizes node.js for execution. node.js is software platform used to build network applications. Express can be used to to design single and multi-page web applications. We had many building issues with our first choices. Express was our third choice.

Our first choice was Evergreen, an integrated library system. However, the instructions for building it were unclear. I think this should have been an aspect we looked at before making a choice on a project.The second choice we had was Amara. Amara is a system that improves videos for people who have disabilities. We also had building problems with this project. It utilized another system called Vagrant. Only one of us were able to load this onto our systems. I did not want anyone to not fully have the project on their computer. We then decided to change our project once more. I tried to look for projects that were written in languages that I know very well so I can help more.

What's Next for our project...
Test planning is a new concept to me. In CSCI 360, we did a project but we not come up with a test plan for it. **Test planning involves scheduling and estimating the system testing process, establishing process standards and describing the tests that should be carried out. My team and I are going to work on our schedule for our project this week. We are also going to start Deliverable #2.

Blog Reflection #2 (Reading Response)

    My group and I decided on working with  The Evergreen Project. This particular project involves an integrated library system. Libraries use this system to "provide their public catalog interface as well as to manage back-of-house operations such as circulation (checkouts and checkins), acquisition of library materials, and (particularly in the case of Evergreen) sharing resources among groups of libraries". I liked this choice. I am very interested to see how we can optimize this system. I like that the work we're doing will have an educational benefit, not only for us but for the libraries as well.

   This week, I also read "Intro to Testing" chapter put on the class site. While reading this, I learned I had many misconceptions regarding testing in software engineering. One of the main things I learned was: the differences between testing and debugging. Testing is the process that finds bugs, while debugging is the actual fixing of these bugs. I also learned a better order for software design while reading this chapter. Dave Gelperin and Bill Hetzel advocate: test, then code. At first, I did not understand this concept, but when they went more in depth on the subject, I got it. The author stated that this is a good model for the phases of software engineering: "design, test design, code, test code, program inspection, test inspection, test debugging, test execution, programming debugging, testing”. Testing is after almost every stage of the development here. Before reading this I did not think testing should be in every stage. 

  I also learned the difference between functional and structural testing:

·         Functional testing

o   Black box

o   Subject to input and outputs. 

·         Structural testing

o   White box

o   Looks at implementation details:

§  Programming style

§  Source language

§  Database design

Blog Reflection #1

Last week we were put into our groups for optimizing H/FOSS projects. My group members are Hannah, Chris,Albert, and Matt (click their name to see their blogs on our progress as well). I'm really excited to pick a project, and see how we can make it better. This project is especially important to me, because I do not have a job that relates to computer science at the moment, but doing this will give me insight on how things will work when I graduate and get a job that does. 

    When picking a project I tried to look for something that was not very mature in terms of coding and function. That way, my team and I could have a big impact on it. I also wanted to pick a project I had a personal connection with.

    I liked the Poet Image Description project. It is a project that wants to add image descriptions to e-books, digital textbooks, and websites so they are more accessible to people with disabilities. I make websites sometimes, and I have always wanted to learn how I could make my sites more accessible to people with disabilities. I think working with this particular project would be a good learning experience. I also liked the FOSSology project. It deals with licencing of the projects we are looking at. I think this directly connects with what we are studying this semester. 

Reading Response #4

This week I read the first 4 chapter of The Mythical Man-Month. This books is an in-depth analysis of software engineering. The first chapter of The Mythical Man-Month deals with an extensive metaphor for large software engineering projects. Fred Brooks relates large programming projects to “beasts in tar”. The more the large and powerful beast tries to break free from the encompassing tar, the more they are engulfed in it. This relates to programming projects, because the more we try to compact the issue with the programming the bigger the problem becomes. Brooks states that the reasons for this are: we do not fully understand the issues before we try to solve them. We think too much of the program itself, and not enough of the surrounding aspects that come with coding.

            I thought this analogy was very accurate. In programming II, we had to create a user interface for an educational grading system. I felt as though I spent much of my time trying to make sure my code compiled fast, without errors, instead of trying to make a structure that was user-friendly (a topic that Brooks tackles in Chapter 4). I needed to understand, as Brooks stated, that programs are just ONE part of the programming system (a collection of interacting programs) and that it leads to a programming product. I did not see the bigger picture. However, I think I have matured since then.

            I also found the third chapter in the book particularity interesting. In it, Brooks goes over a model of software engineering roles that he thinks would work best when trying to conquer large projects. He calls it the surgical model, because he modeled it after the design of surgeons. These roles included: a chief programmer, a copilot, an administrator, 2 secretaries (for the editor and the administrator), a program clerk, a toolsmith, a tester, and language lawyer. The chief programmer’s job is to design the program, code it, and write it, and provide documentation. The other roles job is to support the chief programmer’s job. For example, language lawyer provides advice on how the chief programmer can produce more optimal code. I completely agree with Brooks model for positions. When I first read the chapter, I thought that having a chief programmer do most of the coding would put too much pressure on that one person. However, as I read on and saw how much the other position can help, I thought this was a good model. I feel when you have many programmers focusing on one issue communication can become convoluted. I feel nothing can get completed is communicate is halted.

            The fourth chapter also caught my attention. Brooks goes over the value of conceptual integrity. As a consumer of technical products, I feel as though this is an issue that needs to be addressed more in software engineering. I have used many software products I have felt were not very user-friendly (ie. Instagram). Whenever I search for something or someone of Instagram, it never finishes what I am typing. I feel if they worked more conceptual integrity this product would be way better. Brooks states this problem can be solved by separating architecture and implementation. I concurred. If most software products did this, users would not have as many problems with the interface.

            Overall, I thoroughly enjoyed reading the Mythical Man-Month. I hope we can have the opportunity to red more of it in the future, or maybe even finish the whole book.

Video Response #1: The Future of Programming

    The Future of Programming video went in depth on a new programming IDE, called Cloud 9, that utilizes program development technology within a cloud. I like how Cloud 9 used successful components of other popular software (Netbeans, Word, Google Doc, iCloud), and put it all together in one place. However, I am not sure how Cloud 9 will do in terms of becoming the next big IDE in terms of wide use by programmers.

There were many aspects to Cloud 9 that I found interesting and useful. Here are some:

• Collaboration support - When I worked on a project for CSCI 360 I found Google Doc's collaborating support very useful. An IDE with this capability is a great idea. 
• "Fully available workspace" on cloud/Safer - because my work would not be on a local drive, it would make me feel safer about my work. As hackers get more sophisticated in their approach this would be a better way to save work instead of on an actual computer. This would also be useful in the unfortunate event that I lose my computer or it crashes. 
• Supports Javascript, CSS3 - I use Javascript  with CSS components quite a bit, so the fact that it supports this is really helpful. 
• Scalability - It was able to process 27,000 files without slowing down. This was impressive. Whenever I work on projects from school they involve many files so an IDE that can handle this would also be convenient. 
• Auto-completion - This is something I found useful in Netbeans. It allowed me to finish code faster. 
• "Ability to work offline" - I thought it was handy that Cloud 9 is able to work both through the cloud, and offline. It has the best of both worlds. 

    Even though Cloud 9 has many useful components, I am not sure it can be considered the "future of programming".  It takes several years (maybe decades) for people to accept new technology. An example of this can be seen in the history of programming itself. In the beginning, programmers only used binary to execute whatever they needed. When abstract, higher level programming was introduced it was not widely accepted for years. 

   I read a few comments under the video as well, and it seemed that some of the  programmers thought the software they use now already does what they need. They named similar programs such as: Vim, Emacs, or Sublime Text. I think they felt Cloud 9 had many features that were unnecessary. The notion that: technology changes fast, yet people change slowly was apparent in these comments. I feel Cloud 9 will be widely used in due time. 

Reading Response #3

Security and Privacy Vulnerabilities of In-Car Wireless Networks

While reading this article, I learned many things about tire pressure management systems. I did not know that tire pressure devices utilize wireless devices and that these devices could be used to track where the driver goes. I also never thought that someone could/would use a tire pressure device to misinform the driver that their tire is low in order to rob the driver. These were both very frightening facts. I like how this article first mentioned the benefits of using more wire in cars, but also went in depth about the vulnerabilities of using this technology.

The Magical Number Seven, Plus or Minus Two

The magical number 7 states that the most the human brain can remember is around 7 items at a time. This is helpful information for any student. I tend to get frustrated with myself if I cannot remember many things all at once. Now I know that there is a natural reason for this. I liked this article. I found it interesting to read about the limits of the human brain. I'm also interested to see how this will relate to software engineering. 

Planning for Failure in Cloud Applications

            In this article, Mike Wood talks of a notion mentioned in Chapter 11 of the textbook: survivability. Wood goes in depth on how to keep systems running even when they fail. I learned about many preventive techniques to combat software failure in this article. Automation was something I did not know about before reading this article. I did not know that if you tried to recover a system manually that the recovery time would increase. I feel the idea of automation would be very useful. It is almost as if you are coding the system to treat itself. I also did not know scripts can be utilized in this. I thought scripts were just for managing directories not for restoring  full systems. I did not know they were this powerful. I also learned how to deal with transient errors by using re-try code. I never thought to add a re-try to my code before. This article was very insightful. 

Book Exercises #3

    Chapter 4 is about requirements specification.

4.5 (these are examples of one function that these systems are expected to perform)

• Petrol gas pump with card reader. 
• The user expects the system to cease pumping the fuel whenever the amount specified is reached. 
• The cash-dispensing function in a bank ATM. 
• When a user touches the button containing the specified amount of money they need, the ATM's cash-dispenser should give out that amount of money.
• The spelling-check function in a word processor. 
• When a user spells a word wrong within the context of their sentence, the system should recognize this error and alert the user. This alert can be done by making underlining the word, or automatically changing the word to the correct one. 

4.6 

    To keep track of the relationships between functional and non-functional requirements, a software engineer can create a requirements document. In the system requirements specification section, they can specify the both the functional and non-functional requirements. Defining both in the same section will also define their relationship. The software engineer could also draw a simple diagram linking non-functional requirements with their corresponding functional requirement. 

4.7 

    Withdraw allows account holder to get money from their personal accounts at any location an ATM is present. The user initiates this transaction by inserting their debit card into the ATM . Then, they verify their credentials on the system by entering their pin. The user then species which account they would like to take the money from. The user then specifies the amount of money they would like to take out. The system then dispenses this amount. The last thing the system does in this particular transaction is asks if the user wants a receipt to keep track of the transaction.

   Actors:

• Account Holder
• Bank

   Other possible use cases:

• Transfer money between accounts
• Deposit money into account
• Inquire about an account

Experience Report (Subversion/VMware Player)

    This week I also learned how to use subversion and VMware Player. This marked the second time I have used the Linux terminal. The first was this summer. I found that writing out the commands and what they do helped me finish this assignment a little bit faster. I feel as though the command shell in Linux just looks like it is more challenging than it is in actual execution. 

   Using VMware Player was challenging at first. I could not get it to work. I kept getting a boot error. To get this to work, I just needed to boot from the iso file. I like using VMware Player because it is allowing me to explore an operating system I rarely use (Linux). Even though all of this took some time, I learned a wide range of things.

Reading Response #2

The theme of this week's reading is software failures. There were many aspects of the failures that we read about that surprised me. The main things that caught my attention were: the apathy after the software failure occurred the costs of the software, and the lack of proper testing.

One of these things was the reactions to the software failure by the people who played an important role in the function of the software. When the New York Times’ article about radiation overdoses stated that Alabama officials said that there was "no such thing as overdoses", I was astonished. I always thought that when the lives of others were on the line that the people that could help would react in a more urgent matter. I thought that they would try to fix the problem as fast as they could instead of avoiding the problem by stating there wasn't one. Some even denied their responsibly. An example of this was when the GE spokesman stated that the scanners were "programmed by the user not the manufacturer." I feel even if the user does make a mistake some of the responsibility falls in the software engineer’s lap. This is because in good software there are hazard avoidance attributes that can prevent human error from happening.

Another common characteristic I saw in these articles that surprised me was the amount of money used in the construction of these software projects. The Mars Climate Orbiter cost $193 million dollars, and the duration of the project was about 280 days because of a software failure. The FBI’s Sentinel project has a $451 million dollar budget. This shocked me. I tend to associate large amounts of money with good quality. However, while reading these articles proved to me that this is not the case.

The last re-occurring problem that I saw in all the articles was the lack of in depth testing before putting the finished product out to the public. This can be seen in the Therac-25 incidents. There was a disconnection between the operator interface of the program and the setup of the program. This problem could have easily been avoided if proper testing was practiced.  Another assumption I made was about software that involved medical devices was that they were almost full-proof and well-tested. This was another association that was proven to be incorrect.

Because software engineering has such a wide appeal and is integrated in so many facets of life it is more likely that there can be failures. Nevertheless, I think this face should empower software engineers to make better software because they already know its effect will have a huge impact. I liked reading these articles so I can see what issues may occur when I am creating software in the near future, and I can avoid these problems. Even though a lot of the things I read surprised me, it was interesting to see how anyone can make mistakes at any level of software engineering. This was a scary, yet reassuring detail.