LAST BLOG POSSSSSST OF THE SEMESTER!

We had another team meeting yesterday.  We are planning to meet on Wednesday once again to practice our presentation.  Diana and I talked to Professor Bowring about our deliverable thus far.  It needed a lot of work.  I spent most of last night polishing it up even more.  We still have some loose ends to tie up, but we should be well prepared for Thursday!

Reflections

Not as prepared as I would like to be for this practice presentation.  Thought we would have all 25 test cases ready, BUT that is not the case.  Hopefully people prepare ahead of time next time.

Progress Yet Again!

We have come a long way since our last presentation.  Our framework is in good shape and our main script and helper scripts work well together to produce a test report.  We hope to be prepared for the presentation on Thursday.

Stress.

Thanksgiving is right around the corner as are due dates for projects and...dun dun duuunnnn FINALS.  To say that I'm stressed is an understatement.  Thankfully I'm not alone.  I've gotten a good start on the deliverable, it now has a lengthy introduction, a detailed framework description, and I've started writing a detailed description of Weka.  I still have a long way to go and the goal is to get that accomplished over the weekend.

Deliverable

Our deliverable needs a lot of work.  We got ours back with comments last week.  "How many pages should we have?"  We asked.  "Around 50 pages."  He replied.  Our response: ?!?!?!?!  I'm now in charge of making the deliverable more "verbagey".  Be prepared to be awestruck by the verbage.

Reality Check

After presenting our project, reality hit.  We are a lot more behind than I initially thought.  Every little bit of progress feels like such a great accomplishment, but in reality- compared to everything else we need to accomplish- it's slow going.

Piecing the Project Together

The script has been expanded to work with the framework and sends inputs to the java files from their corresponding testCase files.  I think everything is slowly coming together.  Our next hurdle will be to figure out how to output the outcome to a specific folder and compare this with the oracle.  It will be nice to get feedback today after our presentation to make sure we are on the right track.  

Joseph the MVP

Joseph has been killing it with this project.  He is our fearless leader.  I have never felt so useless in a group, but I'm trying.  However, nothing I'm trying is working. Luckily, Joseph has had success.  We now have a python script that compiles each of the Driver files, places their class files in the correct directory, and runs those class files.  Diana and I are now going through the code and finding methods that we would potentially test.  I'm hoping we'll be properly prepared for Tuesday and our presentation for Deliverable #3.

Step-By-Step

We had another team meeting yesterday.  Not everyone was on the same page about what needed to be done, so we wrote down step-by-step what we needed to accomplish.

This is our general understanding:

Script:

#1 Script will count # of folders in test case directory

#2 For each folder, count the number of text files in that folder

#3 Open each text file and (store as a variable) each line in the text file

#4 Script needs to take second variable (method) send to driver

TestCase.txt:

#1 Driver

#2 Method

#3 Input

#4 Oracle

#5 Output

#6 Requirement

#7 Class Path

Take variable #1 and run javac#1#7 (compiled)

java#1#2#3 (takes number #2 and #3 as arguments)

main{

string methodName = args[0];

int input = args[1];

Script then needs to pipe output to a file that script specifies (output.txt)

Script compares output.txt and oracle.txt

Fall Break In NYC

Fall Break did not go as planned.  I packed so many school books into my carry-on imagining all the work I would get done and how stress-free I would be on my return home.  Did I pick up a book in NYC?  Nope.  Was I productive at all?  Not one bit.  I did, however, have an amazing fall break in NYC- packed with lots of walking, sight-seeing, shopping, and eating.  

Diana Luu sent me the design for our team logo.  I love it.

We have planned to meet quite a bit next week to hammer out the details regarding the next deliverable.

Test Plan

After class on Tuesday, TeamInfiniteLoop has a much better understanding of what is expected from the Test Plan.  One part that we completely disregarded was the presentation poster, so we'll have to adjust the schedule for that.  Fall break will be spent in NYC, but I'll have to find some time to work on this beast of a project- sometime between exploring and eating I'm assuming.  Bring on the much needed fall break- this semester is not playing nice.

TeamDoomed?

TeamInfiniteLoop has seriously been considering changing our team name to TeamDoomed.  Why you ask?  Josh's laptop said farewell to us all at the very beginning of this project, his computer was closely followed by Diana's mac (which was especially sad since she had copied about 4 back-up Ubantu's- just in case). The day after we found out about Diana's mac, Joseph got a flat tire on the way to the team meeting.  Josh is now working from his desktop at home, Diana bought a new mac, and Joseph's tire is fixed (he even made it on time to the team meeting).  All of this disaster led to the first productive team meeting we've ever had.  We cranked out Deliverable #2 and have a much better understanding of the project as a whole.  I was pretty impressed that we were able to turn things around.  For now we will remain TeamInfiniteLoop.

Update

Most of the beginning of this week was spent studying for the 362 test.  As predicted- it was long and horrible.  This past Sunday, Team Infinite Loop met at the library to work out some project details.  We spent all of our time trying to get all the tests running, we have the core tests running, but running all tests has thrown us for a loop- literally.  Our current plan is to focus on the core tests and not worry about all the tests.  Our tests will be based on the core tests.  

The framework for the  SVN repository is set-up, but that is as far as we have come.

Time management was something I was excellent at in nursing, but time management and computer science is something completely different.  It is difficult to predict how much time will be needed for certain tasks and I am struggling to keep up.

Hours of Frustration Followed by Success!

Update:  If you can't tell by the WEKA logo up above, let me spell it out- we changed projects...again.  

Last night was spent trying to compile and run tests on Weka (something that should have been accomplished last Tuesday).  Weka aka "Waikato Environment for Knowledge Analysis" is a tool used for data analysis and predictive modeling.  Their logo is a weka bird, a bird endemic to New Zealand.  Somewhere that I would like to backpack someday, but I digress...

The first issue I ran into was committing the weka code to the team1 repository.  Apparently you can't commit the .svn files of one subversion repository into another subversion repository  it causes .svn conflicts. So the first step was to remove the .svn's I did this through the command line entering: find . -name .svn -exec rm -rf {} \.  This successfully allowed me to remove all the .svn's and I was able to commit the code to our team1 repository. 

I wasted a lot of time trying to compile the code through eclipse.  I kept getting "type" errors.  So I decided to ditch that plan and move on to another.  I wasted more time trying to google commands for the command-line   Nothing worked.  If I wasn't already frustrated, I am now.

Then I worked in terminal and used ant.  This is what I entered:

ant -f build.xml compile...SUCCESSFUL BUILD. *whew* finally getting somewhere.

Then more time was spent trying to figure out how to run the tests.  After giving the wrong command many times, finally something worked- and this is what I entered:

ant -f build.xml run_tests_core

There were 3643 tests and they all passed. It did this very quickly too- in about 1 min and 40 sec.

And now I'm stuck...AGAIN...

I tried to run "tests_all" BUT it fails...it says "hotSpot does not exist".  No idea what this means- maybe my internet was acting up- I'm not sure, but a quick google search did not shed any light on the issue and speaking of lights- mine should be off.  It's bedtime.

But before my head hits the pillow- I need to commit all this progress-

svn status

svn add copy and paste wekareports

svn add copy and paste weka/build

svn commit

.......................................................(many many many dots and 45 min later everything was committed).

We now have two new cool folders "build" and "reports". 

The ball has finally started rolling...please keep rolling!

The Back and Forth

Tor or FrontlineSMS...we keep flip flopping.  Luckily everyone else is as well- walk into the Computer Lab and that's all you'll hear.  Rampant indecision and confusion.  We are a little worried about Tor being written in C...a language none of us have worked with before, so currently we are leaning more towards working with FrontlineSMS which is written in Java.  After talking with Professor Bowring, we were lead in a clearer direction.  Since we are all novices, we don't know all the lingo associated with this project.  Professor Bowring suggested finding a resource that will walk us through how to compile a java program on the command line (something we've never done).  We are off to a sloppy start, having wasted a lot of time going around in circles.  Hopefully things get better.

Testing and Debugging

I am completely new to testing, as are all the "Loopers" (team members).  We chose to work with Tor for our project.  We have a vague idea of what is in store for us.  We are meeting this Sunday and I hope to see the "bigger picture" then.

I thought testing and debugging were synonymous, but according to this article, they are not.  The purpose of testing is to show that a program has bugs.  The purpose of debugging is to correct and find solutions to these bugs. So testing is finding the bugs and debugging is fixing the bugs.  One leads to the other.  I found it interesting that the objective of testing is to prove that the program is free of bugs- but this is an impossible objective to reach.  There will always be bugs, we just have to decided the amount of bugs that are "acceptable"- which is a judgement call.  Human error is inevitable.  At the hospital I worked it, we had protocols in place to prevent human error, but accidents/errors still happened.  We aren't perfect and neither are the programs that we will write.  

The Creation of Team Infinite Loop

Our software programming teams were chosen last week.  The class counted off one through five and that was it- we had our five teams.  I counted the number one which put me in a group with four other lovely team members- Diana, Joseph, Josh, and Alex.  We did a small team building exercise which I thought went pretty well.  It was apparent after the first thirty seconds into the team building exercise that Joseph would be the team leader.  It will take some more time to see where all the other team members fall- as far as team roles go.  Our number one goal for the first team exercise was to come up with a solid team name.  After turning down Alex's- "Team Panda" suggestion and a few others, the team opted to go with "Team Infinite Loop" with the slogan of "We'll never stop."  I think it has a nice ring to it.  I now have four new shiny Facebook friends and four new numbers in my phone.  So far this teamwork thing might actually be enjoyable...but we shall see...

Homework #9

Response to The Mythical Man-Month

Frederick Brooks is an author our class has read before- if you go to my first blog post there is a little snippet about him.  He wrote an article about the silver bullet of programming and I distinctly remember werewolves being all over his article- now there are dinosaurs all over this article and programming is being related to a sticky tar pit.  I like this man's style.

A quick Wiki search informed me that this article was written about Brooks personal experience as manager of the development of IBM OS/360.

The first chapter talks about the joy's and woe's of programming.  I could relate to most of the good and bad of programming, but the one I ended up highlighting was a paragraph talking about perfection and programming:  "If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program."  Syntax.  I'll go through an emotional roller coaster at times when my code is not compiling and I'm trying to fix the problem- a half hour later, I realize there's a comma missing.  Syntax.

The second chapter introduces Brooks law:  Adding manpower to a late software project makes it later.  The first and last sentences in this chapter is the same sentence:  "More software projects have gone awry for lack of calendar time than for all other causes combined."  Adding more men, causes problems with communication.  Also managers have to consider that adding men will require training as well.  Time management and software engineering are difficult to keep in sync.  Brook suggests that "We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on." to get a better handle on project time estimates.  I found myself giggling out loud when Brooks says "The bearing of a child takes nine months, no matter how many women are assigned."  He relates this to software because of the sequential nature of debugging. 

The third chapter tries to answer this question:  "For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance. How can these two needs be reconciled?"  Brooks suggests working as a surgical team would to tackle the software project.  Everyone has a role and the surgeon makes the final decisions that everyone else on the team helps support.  I have heard of employees working for large software companies who "get by" with contributing little to no work.  Since their corporations are so big, it is hard to keep track and make sure everyone is doing their part.  I think this surgical team approach would be very beneficial to companies.

The fourth chapter.  Brooks believes that  "conceptual integrity is the most important consideration in system design."  Brooks shares a costly mistake he made with the IBM project - what he learned was that more man power degraded the conceptual integrity of the project- which took more time and more money to rebuild and fix.

I enjoyed reading about Brooks personal experiences with the IBM project- the mistakes he made, his "Aha" moments, his advice.  Learning how to work the most efficiently and productively as a team while creating software is something that we need more intel on.  As a former nurse, I remember being taught how a hospital team works in the midst of an emergency- who has what role, and what is expected of you.  There were diagrams, there was research, we play-acted our roles- we knew the proper way to respond.  In time, I think software engineering teams will have a similar look.

Homework #8

500+ word essay on where you think programming and software engineering are headed; do you agree with the Future of Programming - why or why not?

After watching this video, I decided to visit the Cloud9 IDE website.  Their slogan is "Your code anywhere, anytime".  The introduction video they provide is very cute, informative, and to the point. 

I definitely do NOT have extensive experience with IDE's.  I have used two- NetBeans and ECLIPSE.  I use Sublime Text2 as my text editor and that is what Cloud9 IDE reminds me of- visually speaking.  

I think one of the most exciting features of this web browser IDE is the real time collaboration support.  This will help communication between engineers by leaps and bounds.  It's pair programming, but one programmer can be in China and the other in America.  Also if you are experiencing an error or problem, another engineer can see what the problem is in real time and the two of you do not have to fight to keep in sync- so the problem will most likely be resolved much faster.  There is even a chat button.  They say on the site's intro video that "it's like google docs, but for coding".  This real time collaboration will save so much time and frustration.  After all, time is money.

Software engineering as a profession is already decentralized, but with advances coming in (especially from a communication standpoint), you'll be able to work for companies in other countries in the comfort of your own home (not that you can't already- it might just become more common).

I also really liked the idea of accessing my code from wherever whenever...or as they put it "Your code anywhere, anytime".  Convenient.  

Another feature that I really liked was how you can zoom out of your code very easily.  I have probably mentioned before that I am a very visual person and, spatially, I get very confused/ lost in my code at times.  This feature is very slick, and I dig it.  

Three minutes into the video, the journalist interviewing mentions that Apple came out with a faster browser...yadayadayada...and the man being interviewed explained that faster browsers is what is making his work possible.  It will be exciting to see the advances that bring progressive change to different areas of software engineering.  

Like we keep mentioning in class- soon everything in our daily life will involve a computer- more so than now.  Hardware and software will keep evolving and keep improving, bringing forth lots of exciting advances. 

I agree with the video article.  Life is continually becoming more convenient- so why not coding?  Like I said, I don't have much experience with IDE's, but watching that video got me really excited.   Small things like fixing bugs always annoy me when my teacher or classmates aren't having the same problems and they can't explain why/fix the problem- now it doesn't seem like that will be a time consuming issue anymore.  These advances- thanks to the communication aspect especially- will help so much with teaching and mentoring (which is an exciting thought for us new grads).  Cloud9 IDE is something I will consider in the future...if not near future.  The only thing that makes me nervous is the security, even though they say it's "secure" in the video...is it really?

Reading Response

Today's readings:

The Magical Number Seven, Plus or Minus Two

This wikipedia entry is about an article written by George A. Miller, a cognitive psychologist.  He proposed Miller's law.  A law that states that an average human can retain 7 (plus or minus 2) objects in working memory.  Since this article, there has been further research that disagrees with the "magical number 7", suggesting maybe it's a "magical number 4", but others say this is also too high.  The wiki entry concludes by stating that further research shows that it might be the size, rather than the number of objects that make a difference in enhanced memory.

It was an interesting read, but I'm not sure how this relates to the other articles...

Security and Privacy Vulnerabilities of In-Car Wireless Networks:  

A Tire Pressure Monitoring System Case Study 

This article, as the title implies, goes through the security and privacy vulnerabilities of wireless networks within an automobile.  Specifically they do an in-depth look at the tire pressure monitoring system, or TPMS.  It's interesting that this feature was first added to automobiles for increased safety and efficiency, but as shown in the article, it can actually be a tool for wrongdoers.  It can help wrongdoers track automobiles and enable them to trick a driver to pull-over and check their tires (giving them an opportunity to attack and pillage).  This article covers the analysis of two popular TPMS systems used in many vehicles in the US mainly for security and privacy issues.  They test the systems, find flaws within the systems, and recommend changes that can make these systems more private and more secure.  

It's a bit scary to think that a tool that was intended to increase security and efficiency can actually make you more vulnerable to security and privacy issues because proper security and privacy testing was not done by the engineers.  This article was written in 2010 and it mentions that starting in 2012 the European Union is mandating that all new vehicles have TPMS.  I hope they made these more secure.

Planning for Failure in Cloud Applications

The author, Mike Wood, talks about inevitable failure and how to deal with it.  He recommends lots of failure assessment testing, finding all the faults, and deciding how to deal with them.  

I think it's important to remember that "there are a lot more possible failure points than the ones you have caught gracefully as exceptions in your code."

In the TPMS article, there is much security and privacy testing done, which lead to suggested solutions to these problems.  Also in the cloud applications article, the author recommends plenty of testing to find and resolve "holes" in the system.   Trying to tie in the magical number seven article- maybe the fact that with further research, other conclusions/ results were reached about working memory.  The magical number 7 article was not taken as fact just because one researcher reached that conclusion.  Failure/misuse of systems will happen, there needs to be thorough testing to enable engineers to find resolutions to the problems.  Using the scientific method during testing, can decrease problems within the system.