Meetings Page - CMPUT301F13T13/StoryHoard GitHub Wiki

Jump to:

Wednesday October 2, 2013

  • first meeting, discussed general requirements of the project
  • task for next time: everyone do some planning on their own on the classes and activities that might be needed
  • decided on weekly meetings every Wednesday at about 3:00/3:30pm.

Wednesday October 9, 2013

  • went over everyone's diagrams/plans
  • first meeting with our TA later on in the lab

Wednesday October 16, 2013

Minutes by Kim Duration:18:03- 18:50 All group members Second Meeting with TA: Josh

Ta: I am going to be running meetings in a scrum style and meeting will be done in this method. We will go through each individual, what are you going to do, what you did the last time we met, and and questions, problems you are running into.You will get a phsical feedback

Steph: divided up the use cases, and the glossary, the word we want to define

Ta: We'll talk about the glossary a bit more

Steph: Worked on the UML diagram

Ta: The uml diagram is going to require a lot of collaboration

Steph: we don't know how to make it MVC

Ta: any other problems you've ran into?

Josh: haven't done much, done use cases

Ta: we'll it's due. I can't makr things early, if you get things done and I'm going to be worried. Do the use cases by Friday and clarify some of the glossary terms.

Ta: accept screenshots from the android editor, am not marking you for photoshop. Your questions will be answered.

Alex: All I did was contribute to the glossary and the use cases. Did a quick storyboard draft with an online application that lets you navigate between screens and activities. The terminology, I suggested we change from fragment to chapter. Finalize the UI componenents and the UML and activities over the weekend and get all the assigned use cases done.

Ashley: set up the first round use cases and did some edit and modifications and do what I'm told.

Ta: Any problems?

Ashley: No

Ta: Now I'm going to give you feedback so you can sit down if you like. Your wiki is good, missing a release planning session, a story board session and a testing session. If you wanna put a testing file and link it to Git or if you can somehow host that program, or put a link to it that would be good. I expect to see an even number of changes and commits from everybody. If you've never commit I assume you've done nothing. I really want to see everyone using Git in a proper fashion. Commit your own work, things like the UML you should commit a sort of sign off. I want everyone to be a part of the UML making process.

UML: second last thing to do. Sort of the idea is that the stories create use cases. Use cases create tests, which I expect to see in Java and Storyboarding.And once you've done those two things you should know what the UML should be. I do expect to see clear MVC and a clear model class, a clear view class and a clear controller class. If it's not obvious from the names in the methods of the classes, just put a UML.

What I don't want to see is hyperdetailed UMLs. For example, like a list view widget and list adaptor and list array and just put one of them in the UML. It should be really clear what each class does. Should not look like it's generated from java code. It's about the organization.

Use Cases: This is fine. This is the level I'm looking for. The one thing is that when you do write tests you will have java identifiers, you might want to mention them in the test cases for the use case. I will be looking for atleast one test per use case and at least one test for major method. Not getters and setters. More like search or add a story. Looking for 1 test per use case and per method. They should be in a java class file that looks like it will compile. But won't actually.

Alex: do you want it in the wiki?

TA: put a hotlink to it from the wiki to the git repo. It doesn't actually have to work. If there's a method in the UML it has to have a test case, and it can serve double duty.

You can break the test cases down to more human verbs. As opposed to inputs, it will be like titles. The author title, input the text. This is fine too but it's more than needed. I don't want to see click the search button, you guys can be like, "Searches for".

There's one more really important thing I wanna talk about: Glossary has no citations. Most of the things in your glossary has citations. It's fine if you copy and paste. I define a user as someone who owns a telephone and the reason I did this is because google did this. And add a little nickname for citation. And in the informaton sources it will be like Nickname,URL and date.

Alex: For the illustration terminology:

Ta: Cite the spec!!

Alex: all the terms that we have used are from spec. Specification, it's on eclass, we looked at it on this day.

Ashley: For chapter and fragments

Alex: Why do we have to cite original content?

Ta: cite URL and Date.

Ashley: You don't care about format?

Ta: I don't care what format it's in. If you cite a book make sure it has an author and a bookname. So like author, find the line in the dictionary and put it in the dictionary. Some of them will be super trivial.

Ashley: Delete would be trivial

Ta: in any case, for example like, define user: A user has lots of definitions.

Ashley: Could we say this is the generic definitions, we are modifying it to this term.

Ta: the reason you ave to justify is that the terms are application specific. Copy and pasting is fine as long as you copy and paste it.

Good cite example: Use quicksort, and decided to sort quicksort yourself, but you're reading wiki, just cite it. Consequences are bad. I prefer you have a cite page.

Release planning: The release plan you start at the beginning of project 3. So this project does not have a plan, it's making aplan for the next project. I suggest Gantt chart. Some teams are using the issue tracker. As long as it's clear of what's being developed, when by whom. Give things a priority. If everything is going to use the chapter class, it's probably going to be hiigh priority and do a time chapter.

You only have to pick the most important and quickest half of the things. Save yourself as much work as possible. Copy pasting is great, it's software engineering.

Any questions:

Alex: About the user. Are we expected to do login and user verification?

Ta: That question is about the user stories which emans that it's the customer's deal. I don't care. I'm here to make sure you guys meet customer specifications. Logging in is never mentioned in the user stories assume it's not a requirements. I'll be grading evyerthing but the midterm. Posting in the forums won't be as great. Email me instead.

Alex: Make the UML for you.

Ta: I'm the boss. For the Mockups, tag use cases with requirements. As long as they are readable and neat drawing's it's fine.

Steph: Once we're done with the UML can we send it to you?

Ta: Yeah sure. The only java code that's due doesn't have to work, it's just gotta look good.

Steph: If you're taking a photo, and the includes.

Ta: Yeah just put it in the preconditions. We just want actors, calls, preconditions, post conditions, test case. Avoid exceptions unless it's really relevant to the use case. Don't spend 10 minutes picking ur brain on every possible exception! Look at the slides on use cases. Definately preconditions, postconditions, goals, actors. Try and use real verbs, not clicks, inputs. But likes its better to be like "Searches for titles".

Just be like, "Takes a picture". The point of use cases is to be used in industry and not busy work. The point is that you know what you need, save time, stick to what you need.

Meeting End.

Monday Oct. 21, 2013

Minutes by Stephanie
Members in attendance: Josh, Ashley, Steph

What we discussed:

  • Use cases
  • Release planning
  • Testing (for whoever had some questions)
  • UML diagram

What we did:

  • Got rid of allowPhotos use case (not actually a user story)
  • ordered use cases from most necessary to least necessary
  • Started working on the release planning
  • split of use cases into 3 chuncks. Made dates to get each chunck done by.
  • started dividing up the tasks for the next few weeks, the rest will be done in tomorrow's meeting which will lead to finishing up release planning
  • Rough class diagram, to be modified and completed at our next meeting

Other Notes / to do:

  • update use cases, change their ordering and numbering
  • display author's own stories instead of published stories on main page of app (Kim)
  • include an edit story page to edit story title, author, (description) (Kim)
  • will have to update edit story use case
  • decided that creating a story will also force user to create one chapter. Can't have empty stories.
  • edit create chapter use case
  • cached stories are NOT the same as user's own stories

Tasks for the next week:
Josh: will start work on coding the activities with Alex and Kim
Steph + Ashley: will set up database and write the framework for all major backend classes

Next meeting: Oct 22, 2013 at 2:00pm with Alex, Kim, Steph, maybe Ashley

Tuesday Oct. 22, 2013

Minutes by Stephanie
Members in attendance: Alex, Kim, Steph

What we discussed:

  • class diagram
  • Release planning
  • UI / layout

What we did:

  • recap from last meeting
  • went over all UI diagrams, discussed some transitions and what diagrams we are missing
  • went over all classes for class diagram, the nice version will be up later tonight
  • decided to add an author class
  • discussed missing UI diagrams (create story, create chapter, browse chapters)
  • clarified: cached stories are not the same as author's stories
  • for later (and if time), decided it would be a good idea to add authentication.
  • split up specific classes / tasks in release planning (all changes have now been updated on release planning page)

Other Notes / to do:

  • finish test classes
  • Alex: missing glossary dates
  • Kim: missing UI diagrams
  • Steph: clean up class diagram and post it

Next meeting: Oct 23, 2013 at 3:00pm with everyone

Wednesday Oct. 23, 2013

Minutes by Alexander Members in Attendence Kim Steph Ashley Josh

Ashley: Update usecases, pair programed test cases, helped with Glossary Will setup the database, choice object, choice manager, photo manager

Kim: Updated usecases, modified glossary, done the User Interface and Storyboard Next week will start implementing the front end interface

Steph: Finished the use cases, class diagrams, UML release plan Will begin working on the back end database, creating chapters and chapter manager General questions about testing

Josh: Update usecases and glossary terms, added dates and stuff. Did the test cases for the use cases. Next week will be working on the front end activities.

Joshua's Feedback:

  • Work so far has beem very good. Stroked ego.
  • Joshua's calling out Josh on not commiting much to the git repo
  • Connect the usecases to the test, please join the usecase tests to the test examples. Can put comments in the code, or put notes in the usecase that say the tests are in 'x' module, etc.
  • Story board isn't up? What is the difference between a story board and the UI?
  • Storyboard is a sequence of what someone sees. This person walks into the room, show the person in the room, lover smacking them in the face, crying, cause and effect
  • Take an image, shrink it down, connect them together with user stories and usecases. Example: in order to get to this user story, go to Screen A > Screen B > Screen C.
  • Release plan is good
  • Glossary is excellent
  • Test cases need to be linked
  • Wiki is organized
  • UML concerns: some of the activities are both views and controllers. Not allowed. Perhaps put some activities into the UML. Make sure that an activity is either a controller or a view. Never both.
  • Steph: The Activities will only ever contain code that will call out to a view or controller.
  • Make sure that they aren't goign to be mixed
  • Suggestion; Use the exact same json code for the server and dump into the phone, don't use a database
  • Simplicity is better. Don't worry abotu requirements that aren't in the user stories, don't worry about things like efficiency, etc.
  • Don't have to change anything for this project. Suggestion is when we actually do the coding, don't use Sqlite. Just use json and dump things into file
  • That's it, good work.

tldr;

  • link the tests and the usecases.
  • split out activities to make it clear how they relate to everything

Tuesday Oct. 29, 2013

Minutes by Stephanie
Members in attendance: Alex, Ashley, Steph

What we discussed:

  • class diagram
  • Backend
  • Release planning
  • UI / layout

What we did:

  • finished up main parts of choice, chapter, and story manager while smoothign out any inconsitencies or confusion.
  • changed the class diagram, particularily the controllers
  • created a use case for searchStory
  • changed release plan according to the changes we made to the structure of code / classes
  • stub controller class so front end people can use the methods
  • decided to get everything working without media for thursday, and thursday start dealing with media (photos / illustrations)

Other Notes / to do:

  • front end people need to get together and discuss the theme / look they will use
  • everyone writing activities needs to know what their "update" method will do
  • REALLY need to work on test cases
  • discuss the broken links with TA tomorrow, they seem to work fine for us

Wednesday Oct. 30, 2013

Minutes by Kim Members in attendance: Alex, Ashley, Steph, Josh

Josh: Don't use git inside the eclipse Josh: You should use a branch, instead of a repo.

Alex: made a branch, put all the story views and activity. Implemented the grid view adaptors, spin view adaptors. Talk to backend.

Josh: Always inherit from activity instrumentation test case 2. It will start the activity. You should never talk to the java garbage collector. Josh: Sync it with the backend stuff. Commit commit commit!!! Use the tool that the other asian TA used.

Code 2: The requirements. I will be grading this as a demo. Compile it and run it. And the version is the one that I pull from the git repo. I will specifically look at your code in the project for me. Set the Memo API to 403. Just a conveniance for me so I can test it on my phone. Please indicate which user stories are meant to be completed so I can try to perform them on your app.

You are required to follow Java coding conventions. I suggest Oracle's coding conventions plus google android's coding convetions. In addition, I expect to see java docs not only in the code but also in their compiled form in the repo.

So if you don't know how to use java docs, I suggest you learn, immediately. It's a system that allows you to write the documentation for the code that's being documented. You are required to have JAVADOCS for this. You are required to use design patterns in JAVADOCS and UML. Like by a class that is implementing a design pattern. Like, this is a whatever, yeah and put the things in a Eemoo??

Your tests are required to compile BUT NOT TO PASS. Just put in Stub methods that throw a not implemented exception. Public type method arguments but the body can just be throw… not implemented and they will show up red in your tests which are now required to compile.

Tests for every single public method. You should have written the methods for the public method. THe UML needs additional detail. If you think you need more methods then add them. Our UML was probably the… JUST light on detail BUTBUBTUBTUBUT it needs to become significatly and SIGNFICANTLY more detailed. That doesn't mean overly rebose, but that does mean it should be really clear.

Maybe summarize getters and setters by using… like youshould defiantely have most public things in it. Don't make it a burden but ut shuld be alot more detailed. I BELIEVE THE DEADLINE HAS BEEN EXTENDED.

That doesn;t have to be UML that already wasn't… but it doesn't have to be UML for the class diagram. Don't have lines that go on top of your classes. Just keep things neat and organized. Group things together that are related. You should do release planning last. But your release planning looks pretty good. Probably LEAVE RELEASE PLANNING FO LAST. Be sure to check description of project part 4 before you did the release planning. YOU HAVE TO ADDRESS ALLLLLL THE FEEDBACK ON THE WIKI.

JUST MOVE IMAGES TO GIT.

November 6

Minutes by Kim

Make sure you list what you need and requirements on the wiki. Instead of having an extra meeting as the assignment specifies, everyone gets a fresh exclipese and do a fresh git pull make sure you can walk through the user stories and make sure you can import a new eclipse and can compile it. Friday, I'm going to pull ur git repos from github, put it in eclipse and build it and go through the list of user stories. The chances of you catching a problems are nearly to none. Make sure u have a product.

Put a link to coding conventions. Normally you don't commit build products. Did you add atleast one design pattern? Do your tests compile? Test failure is when the assert is not met but the code runs. Test that they actually have the data. Adaptor.getarray.item[0] is a good example. You wrote code in that activity. You don't have to do things for simulated. You just need some code you've written inside that activity class to run. Does the adaptor have a string in it? That's fine.

Wednesday Nov. 13, 2013 PART 1

Minutes by Stephanie
Members in attendance: Alex, Ashley, Steph, Josh, Kim

what we did: Decided on our 5 use cases, the 3 that we will actually implement, talked about what still needs to get done and delegated tasks.

Game plan for next time is as follows.

Josh:

  • will implement gui part of new requirement "allow random choice"
  • permissions use case

Ashley:

  • implement backend for "allow random choice"
  • backend for permissions
  • camera manager class
  • random choice use case

Kim:

  • front end for 'i'm feeling lucky/get random story"
  • only for server
  • random story use case

Steph:

  • backend for i'm feeling lucky
  • get server working (permissions in manifest)
  • jpg to .jpg name change
  • resizing image use case

Alex:

  • front end for permissions
  • multimedia use case

Ongoing issue:
Images: Make PhotoManager class.

Sequence diagram scenario:
user creates a story with two chapters, each with a photo, one from camera and one from gallery, and choices.

Wednesday Nov. 13, 2013 PART 2

What's due for project 4: Drop serializable and replace it with Json object conversions. Use the stuff that Victor presented. No serialized blob.

Add built in help in the app. (Like guiding)

Refactor and document it on the wiki.

Improve your docs. Just devoid of examples. Make sure each class has an introduction and tiny little guide on how to use that class. Make sure ur design patterns are in ur java docs.

All your tests should pass. Most should pass. Document at least 5 more use cases and implement 3.

Uml needs sequence diagram and need a new release plan. Like… what you would do if you were to do another release.

NO specific intense feedback.

Weird doc problem. I rebuilt them and that's fine. Be careful of importing junit. Don't need that. Delete import and the @before to get it working.

Local mirroring: complete copy of something that we could resubmit to its entirety. Test: can you get it from the server delete it on the server and reupload it on the server.

###Wednesday Nov 20 Notes by Josh(Not TA)

  • Ashley: Did work on the backend, made method for random choices and random choice use case, going to do documentation,
  • Alex: Refactored entire activity application, broke tests, questions about updating, going to do lots of debugging
  • Steph: Got server working, bugs, random story, going to do more testing.
  • Kim: Started beautifying the GUI, going to fix edit story and other activities.
  • Josh: random choice in GUI, going to do more testing and implementations

Josh(TA):

  • Work on UML -Steph: Were starting on the sequence diagram -BUilt-in help: -Were going to use a button to deal with that
  • Refactoring: -Alex: Needed to get rid of serializables, made an object directly
    • Add notes to what you refactored
    • Broke tests, use those as checklist to figure out what you refactored and why
  • Documentation:
    • Steph: Were getting there..
    • Ashley: I started on some for edit
    • Kill parrot docs
    • Give examples of arguments, what methods return.
  • Design Patterns
  • Presentation:
    • Two options: Emulator or Laptop with webcam
    • Test it with machine at front of lab
    • If Laptop, make sure you know how to do it in lab
    • Tips: Look at Hindle's notes
    • If you decide to use a video, and you also want to do bonus, you can't use one video for both
    • Bonus video should be longer than demo video.
    • Don't go over 8 minutes. You have 10 minutes but that includes questions and problems
    • Different audiences for the two movies
  • Make a lot of progress

###Wednesday Nov 27 Notes by Josh

  • Josh: Help guide, still working on it
  • Steph: Refactoring, testing, sequence diagram
  • Kim: Finished layouts, beautifying GUI
  • Alex: Fixed bug, fixed hard coded strings, added a check for downloading/caching story, did unpublished button
  • Ashley: Did a use case, and troubleshooted random choice

Josh (TA):

  • For testing, add a story with specific name and check that that specific name is not in the server still
    • Ex) When testing with files, use a temp folder, check if its in there.
    • Save title in the test, delete it, and check to see if its been deleted
    • Don't assume that the server is in perfect state every time
  • So last week,
    • GSON: No more serializable
    • Random choice: fixed
    • Documentation: Working on it, got most of it
    • All five use cases up? Yes
    • Tests running better? Yes
    • Parrot documentation? Getting rid of it...
    • Class descriptions? Working on them
    • Refactoring notes? We got most of them done, still working on them
    • Design patterns: Communication most important facet of design pattern
    • Did you use JDeoderant? Yes, done.
    • Sequence Diagram? Create a story use case.
      • Josh: Like the way it looks, but some things don't make sense
    • Other UML? In progress, adding some controller classes.
    • GUI Consistency? All the overlapping stuff has been dealt with.
    • Release planning? We just put it up today.
      • Josh: Extend it out a month, I'd go another two weeks (up to January)