Erratum

There was incomplete information in the directions to view demo of openreports below. I have updated the post to be more clear.

Robert's Rules of Order

I hereby move that if the RADAR Detectors continue to run their meetings according to Robert's Rules of Order and, further, if the associated minutes duly record such formality, said minutes will be refused.

I second the motion.

All in favor.

Aye.

All opposed.

The motion carries.

Some Ideas/Questions/Suggestions, not all original

1. Sketch a domain model
• What are domain classes?
• What are relationships among domain classes?
• What are responsibilities of each domain class?
• Pick the easy ones first.
• Which ones do you need to refine first N (N is small) user stories?
2. Pick a User Story, refine it.
• Design a page layout template. This can be simple because real estate is at a premium, but Rails provides nice support for generalizing a layout across entire application.
• Finalize (conditionally) what each "page" looks like, that is, what fields it contains.
• Build in navigation: implement flow we charted in meeting.
• Ask: What are implications of UI and UI flow on model?

It may not be a bad idea to prototype user story on desktop; get a quick feel for flow.

3. Consider data-flow of report submission.
• One of first goals should be to get an end-to-end pipeline in place from screen to backend. This can be rough but it will provide context for discussion of further design.
• I imagine a Rails SubmissionController on the back-end of this pipeline. Its first implementation is real simple: generate a text file.
• I also imagine some sort of NotificationService for distributing reports (in whatever form). Its first implementation is real simple: print to console.
4. Using Rails scaffolding support, we can very easily build some cheap admin screens for:
• Adding students
• Adding users (ie RA, Hall Directors)
• Defining buildings, etc.
• Adding infractions

I would encourage getting started on this as a way to start to shake out model and as a way to familiarize yourself with Rails.

5. Start asking: How is a report modeled?
• I wonder if something like this would be useful: http://oreports.com/ (http://oreports.com/docs/or-install-guide-3.0.html). This package pulls from relational database.
• If you grab the folder \\csfile\software\openreports\openreports-tomcat and drop it in at C: on a windows machine, you can see some of the capabilities of openreports.
  
  1. Copy folder to c:
  2. Change directory ino openreports, ie. cd openreports
  3. Run startup.bat script
  4. In browser, visit by http://localhost:8080/openreports (assuming you are on same machine)
  5. User/password = admin/admin.

  What you are viewing, of course, is a demo app. Behind the demo is the kind of code we would write to generate reports from sql.
  

• One nice thing about this package is that it can generate either HTML or PDF!

More on REST

Here is a little better explanation of what a RESTful API is.

Remember, there is no REST for the wicked.

Managing Images

From what I have been hearing, one of the most important wishes for RADAR is the ability to browse/search images of students in order to confirm identity and, then, to attach student images to Incident Reports. Additionally, it would be nice--though I have not heard this from ResLife--to be able to attach pictures to Maintenance Reports or pictures of damage to Incident Reports.

In the spirit of decoupling as much as possible from SMU infrastructure, I want to suggest the team look into something like Gallery. Gallery is an open-source image server that provides a RESTful API. It appears quite easy to use and a cinch to install.

I mention Gallery because a CS394 student (Owen Kuemerle) will be using it to support the Android application he will be writing for the course. He has a server installed already and has some familiarity with the API. I think there is a chance for some synergy here. Owen is open to cooperation.

Yes, eventually, we would have to ingest images from SMU photo gallery, but we can figure that out when the time comes. And, if we are serious about thinking beyond SMU, we have to solve the problem of "populating RADAR database" anyway.

Please talk about this as a group.

Beyond RADAR

There has been some justifiable concern that, perhaps, there will not be enough work to for eBusiness folks. So, I got to thinking. I thought: Think beyond RADAR (as a class project).

1. Are there other applications on campus that could benefit from mobile reporting? Security? Maintenance? If we think generally enough about what it means to submit a report, we may be able to solve a more larger problem then we originally intended...as long as primary goals are met. If we want to pursue such questions, maybe the eBusiness people should set out identifying some stakeholders in such an endeavor. Do some "market research." Measure interest. Report back.
2. Build a business plan for building out RADAR such that we could market it to other institutions. What is competition? What, if anything, are other schools doing? What other schools would be interested in something like RADAR?
3. Develop marketing collateral as-if we were going to market RADAR beyond the confines of SMU.

Those are just three ideas. I bet the team can come up with more.

What Do We Know Right Now

Some not entirely random thoughts and questions regarding the RADAR project.

What do we know right now before talking to the "customer" (Brendan Dolan, ResLife)? What can we model now? What detail can we start to sketch in regarding overall system architecture?

Let me take a stab at these questions. Hopefully, my thoughts can jump start your thinking.

You have the reports that ResLife currently uses. They pretty much define what it is we need to produce. They may not be perfect buy they start to tell a lot of the story.

1. How can we model these reports? Is there an abstraction we can apply that will allow us to proceed not knowing precisely what ResLife wants and capable of easily comprehending changes?
   
2. How do we persist report data? Flat file? PDF? XML? Relational Database? Which approach is easiest? Which approach is amenable to post-processing, ie. trend analysis, general queries? Do we need to support such queries? Can we design for such support without committing to it upfront?
   
3. Who are the actors in our system? RAs. Hall Directors. How do they interact with the system? How are they notified of 'events'?
   
4. Can we model students and buildings and areas in a quick way to get something up and running?
5. Basic Question: What can we build NOW with imperfect knowledge?

I think we know most about reports. I think that is a good place to start. How do we model them? How do we move them around? How do we persist them? How do we generate them?

Start thinking in terms of Reports NOT in terms of this report or that report.

Continuous Integration + Ruby + GIT

Here is a post on CI + Ruby + GIT. CI + Ruby + git

and a user story http://elabs.se/blog/7-continuous-integration-testing-for-ruby-on-rails-with-integrity

git

I would suggest checking out

http://git-scm.com/

for version control.