Server Setup

[Abhiroop Bhatnagar]

As Cliff mentioned, we need to start setting up the server. How should we proceed with that?
Also, I need some guidance on how to decide where to begin writing code.

[Cliff Ingham]

For the SMS to Open311 proxy application, you're going to need some sort
of datastore and at least some user accounts to start with. Do you have
a web server you can develop on and test things out?

I don't know what language you're most comfortable with, or what you
were planning to write it in. We can work with most anything, however,
if it's all the same to you, our preferred language is PHP.

We have a scaffolding framework that is the beginning of all the PHP
apps we do here in Bloomington.

https://code.google.com/p/php-blossom
https://code.google.com/p/php-blossom/wiki/Home

This is the same scaffolding I started from for the uReport server. So,
installation and configuration is going to be the same.

[Abhiroop Bhatnagar]

No, I don't have a web server. PHP is my preferred language too. So, I will start setting up the scaffolding on my local server instead.

[Cliff Ingham]

Okay. What frameworks are you comfortable in? Even if you don't use
ours, you should definitely use a framework. You shouldn't need to
start this from scratch.

[Abhiroop Bhatnagar]

I am comfortable with LAMP stack and I think Zend will do fine for me although I don't have a lot of experience with Zend. So this weekend I will try to dive into its details.

[Cliff Ingham]

I can populate the Github Repository with an initial export of the Bloomington scaffolding, if you like.  Then, you'd be able to work on it from there.

--
You received this message because you are subscribed to the Google Groups "open311-mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open311-mobil...@googlegroups.com.
To post to this group, send email to open311...@googlegroups.com.
Visit this group at http://groups.google.com/group/open311-mobile.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Abhiroop Bhatnagar]

Yes, I think that will help because I observed that it differs with the basic one that Zend suggests so I was getting confused.

[Abhiroop Bhatnagar]

Also, I did not understand what you meant by issue tracking in GitHub? Will issues mean code specific to each required feature?

[Cliff Ingham]

I do use Zend for a few things....Database, Access Control Lists, and Pagination.  The rest of the implementation is all code there in the application.

Because Zend is linked up, you can decide to use Zend functions for other stuff as well, as needed.  For instance, I have started making calls to Zend_Mail, instead of writing all the mail code myself when needed.

[Cliff Ingham]

If you haven't worked with Issue Tracking that was linked to the code repository, here's the idea....

All of what would be feature requirements should go into the Issue tracker as "enhancements".  You might need to break them up into smaller steps such that they can be tackled in shorter amounts of time. 

This way, everyone can see what's planned.  Questions and discussions about the issues themselves can take place in the comments in the issue tracker.

Working on code means choosing an issue to work on, and writing code to implement or fix that issue.  When the feature is implemented, or the problem is fixed, you commit the code.  When you commit, you include a comment that updates the issue.  An example comment might be:

Handle parsing of XML from Twilio

Fixes #32

Git hub will link this code commit to the Issue in the issue tracker. 

Doing things this way leads to a few benefits:

Linking code implementation directly to the discussions about the feature or bug is a very good thing.   The code not only shows how the feature was implemented, but we can also link over to why it was needed, the history of the problem, and all the discussions about this feature.

It forces developers to take things in small, incremental steps, instead of trying to tackle everything all at once.  This can speed up development by avoiding all the confusion of not know what state the code is in.

Everyone can follow progress.  This is especially true if you take the time to try and map out the feature requirements into issues ahead of time. (Which you should).  Then people can see progress towards completion by watching each issue get implemented.  Now, progress to completion is certainly not exact.  More issues are going to be added all the time as new things are discovered about the features.  Things that were not thought of will be discovered and will need to be added to the issue tracker and dealt with.  But it still gives everyone a sense of how far along we are.

[Cliff Ingham]

Oh, and you want to try to break up the features into issue small enough that they can be completed in only a day or two.  This type of progress tracking is best when developers are committing frequently.

[Abhiroop Bhatnagar]

I have come up with some broad set of issues that need to be tackled:
1. Design of database to be used for storing queries
2. Setting up the Configuration File
3. Routing
Instead of URI, routing will be based on the SMS text received and database lookups of the previous queries from the same phone number.
4. Template Design
Templates will have to designed for both HTML and XML responses. A special template for Twilio integration can also be included.
5. Controllers
Each interaction mode will require a controller of its own.
6. Models
These will contain functions for parsing SMS text, accessing database, querying the open311 server and parsing the XML received, text modification and optimization among others.
7. Unit Tests
8. Documentation
Is this a good approach? Let me know if this is fine, I will then create issues in GitHub by further breaking them in smaller chunks. Meanwhile I will start working on database design.
Also, I will not be needing very elaborate functionality which is required for a whole website. So, I have decided to stick with the scaffolding itself instead of the whole of Zend. It will help keep things light.

[Cliff Ingham]

All of this sounds good.  It seems like you have a good sense of where to get started.