Update README.rdoc

README.rdoc

@@ -1,2 +1,70 @@
 == ListPush 3.0.0
 
+
+The Statement:
+    To create an application that would allow Client Services to submit business search listings to multiple search engines.
+
+What we have to work with:
+    Intake Forms, UBL, Localeze.
+
+
+Describe Intake Forms
+
+Giant Application that members of the Client Services use when ever they get a new client.
+Data on Intake forms has information about every product.
+Each Product, Listings, Responsive, Mobile, etc, has questions tagged to it.
+CS members, when signing up a new user, would need to copy this information to Localeze and UBL manually.
+This is nightmare, because one of the Two, (I don't remember which now) disallowed copy pasting anything in their form.
+The problem with this is that you need the two listings to look exactly the same because if they are not, they will be listed twice.
+
+Enter List Push
+
+Part 1 - Validation
+
+Needed a site that would allow the users to copy the information into one place that would then push the data to UBL and Localeze.
+The challenges:
+* UBL and Localeze both had different restrictions of what data they would take, so I had to manually go through their
+two PDF instruction manuals, and see which fields both contained. These were added to the Intake form, and created in my api.
+* UBL and Localeze not only had different fields, but each had different limits, qualifications, etc on their fields. So I had to always take the most restrictive of the two for my validations.
+* e.g: Business Description for Localeze was limited to X length characters, but on UBL it was limited to Y length with only allowing certain characters.
+* The first most memorable, and the one I customized the most, was the way they handled their credit card types.
+* One of them required you to send them a base 10 representation of a binary value where each power of 2 corresponded to a different company.
+* e.g.: 1(Cash)+8(MasterCard)+16(Diners) = 25 and send this value
+*  The other, required you to send them a comma separated list of a two letter abbreviation for each type they supported, 
+* e.g.: CA,MC,DI (this one was a little bit easier)
+* So I did this with a checkbox, and during the preparation of each of the two services, converted the list that was sent in to the proper format before making the api calls.
+* The second memorable modification was how they represented Hours of Operation
+* One of them needed to take the data in the format of open day, come day represented by two letters, then the hours, then H to signify that the day is done
+* e.g. MM09000500HTT09000500HWW09000500HRR09000500HFF09000500H which is 9-5 week days or MN00000000H for 24/7
+* The other, I don't recall because I don't have the source code for that anymore.
+
+
+
+Part 2: API Calls
+
+* UBL was pretty straight forward, I think it was just a rest api call with the body being a JSON object. 
+* I would post to the create endpoint and it would return a success or fail status. 
+
+* Localeze was tricky. SOAP tricky.
+* Every time I needed to make a new listing I would need to create an XML document.
+* This required a call to the API with Query Key ID (ids mapped to api functions) of 2935 to get the freshest list of categories.
+* After this, I needed to make an api call to Localeze with the Query Key ID  of 3722 to see if the listing existed, if it does, I needed to return an error. IF not, I could proceed with the next part of the process.
+* The next part was creating the actual posting, I would follow the same procedure as Querying, but with the key of 3700. (I used the same function for both, just changed the query ID)
+* Assuming all worked, I would be done.
+
+
+Part 3: Bringing it all together.
+* This was fine and able to launch to the new users, but the next step loomed closer.
+* I needed a way to get this data from ListPush
+* The problem "The Hammer". 
+* Every project at Propel had something that was meant as a "lets use this initially and remove it later after launching the first time"
+* For this project, it was the cvs importing. We had this massive cvs file that was constantly changing that we would reimport all the fields once every week or two as needs changed, which means they also changed the names of the fields.
+* I had the manual step of needing to make a lookup table of what the fields were named (later I asked the maintainer to NOT change the field names of the Listings products, which they stopped)
+* There was a button that would create a new listing in the list push database, and then open that page for the user. could only be used once to create, but every time it would bring you to the page for the listing.
+
+
+Part 4 - Testing
+* During this project, I was the sole owner of the project, and I was learning how to write tests. This application at one point had 98% test coverage for unit testing and pretty comprehensive integration tests.
+
+
+