mngatewood/gist:04d78cc41fa395eb8e8d61455615696a

## gistfile1.txt
Rails Engine is a project to develop a JSON compliant API with multiple endpoints using Rails, ActiveRecord and SQL.  I was excited about this project, because my practice developing APIs in Front-End was limited to only a couple projects in Mod 4.

My approach to developing this project was to complete just enough endpoints to be able to execute one or two of the Business Intelligence problems as soon as possible, per a suggestion from the instructor.  It was recommended that we start with Merchants, as that is a pretty straight-forward resource.

I completed Merchants in its entirety with all required endpoints, including nested resources.  The next day, when determining next steps, my planning began to falter.  Not having a solid idea of the resources that would be required for business intelligence, it seemed logical to start on Customers next, with the intent of being able to create an invoice next, then proceed to business intelligence.

I then completed Customers and Invoices in thier entirety, anticipating that I was ready to "struggle" with some business intelligence.  I was wrong.  Upon closer examination of the business intelligence requirements, it became obvious that almost all of the resouces were prerequisite.  So I quickly raced to completed the models, relationships and migrations for the remaining resources, ignoring endpoints and nested resources for the time being.  I managed to get things in order with about an hour to spare to "struggle" with one business intelligence requirement before the Advanced SQL lesson.

With a new strategy in place to tackle SQL problems, I was able to complete all but two business intelligence requirements in the 24 hours following the Advanced SQL lesson.  I thought I was in a really good place.  Then all of a sudden...

Meanwhile, I was shipping code with the notion that Active Model Serializer (AMS) would be used for the project, based on the Turing lesson plan on their website and a video they published to YouTube.  It wasn't until five days into the project that the spec harness was in a usable state.  Once I was able to get the spec harness working, I realized that my serializers were not organizing the data in the way that the spec harness required.  I wasn't concerned about getting AMS to do what I needed it to do, but I didn't want to go too far down a rabbit hole this late in the game; so I asked some classmates what strategy they used.  It was then that I learned about Fast-jsonapi.

With the help of my classmates, I was able to get my Merchants endpoint returning data in the correct format before heading into the weekend.  With the change to serializers, I went from 80/80 passing tests to 20/80 passing tests.  I made the decision to ignore the spec harness in favor of developing an app that bared some semblence of the intended result.  Don't let perfect be the enemy of good.

I would spend the weekend updating my previous work to comply with the newly found data structure; adding the endpoints I had skipped over during the week; and finishing the business intelligence requirements...all but nested resources were developed using Test Driven Development.

I was able to get my project in a reasonable state by Sunday afternoon.  I had all my endpoints, all but the most complex business intelligence requirements, and 130 unit and integration tests (I decided to throw most of the nested resources together without tests in the interest of getting them completed before the deadline).

Now the 800-pound gorilla in the room was the spec harness.  Having paid no attention to it until now, I knew there were going to be issues.  I would spend most of the day before the deadline cleaning up what details I could...changing arrays to JavaScript objects, integers to decimals, decimals to strings, and so on until bedtime approached.  I would manage to get it up to 85/106 tests passing before putting it to bed.  I have the skill and knowledge to get them all passing, I just don't have the time.

Having spent the last week on this project and reflecting on my progress, I wish I would have examined the spec harness much more closely and much sooner.  I tried to run it everyday beginning day 1 and asked my classmates if they had success.  Getting nowhere with getting the tests to run, I pushed it to the side.  In hindsight, I wish that I had been able to examine the inners of the tests and understand them up front.  Doing so would have brought to light my issue with serializers much sooner and saved me precious time.  In future projects, my development will be driven by the spec hardness as opposed to the project requirements.

In the end, I'm pleased to have a working API to share with potential employers (they don't need to know that it doesn't pass the spec harness).  I also got a ton of reps with rails components, tests, AR/SQL and serializers.  My immediate plan for the project is to fill in the gaps with tests for all of the nested resources, after which I may update according to tests failing
in the spec harness.
	Rails Engine is a project to develop a JSON compliant API with multiple endpoints using Rails, ActiveRecord and SQL. I was excited about this project, because my practice developing APIs in Front-End was limited to only a couple projects in Mod 4.

	My approach to developing this project was to complete just enough endpoints to be able to execute one or two of the Business Intelligence problems as soon as possible, per a suggestion from the instructor. It was recommended that we start with Merchants, as that is a pretty straight-forward resource.

	I completed Merchants in its entirety with all required endpoints, including nested resources. The next day, when determining next steps, my planning began to falter. Not having a solid idea of the resources that would be required for business intelligence, it seemed logical to start on Customers next, with the intent of being able to create an invoice next, then proceed to business intelligence.

	I then completed Customers and Invoices in thier entirety, anticipating that I was ready to "struggle" with some business intelligence. I was wrong. Upon closer examination of the business intelligence requirements, it became obvious that almost all of the resouces were prerequisite. So I quickly raced to completed the models, relationships and migrations for the remaining resources, ignoring endpoints and nested resources for the time being. I managed to get things in order with about an hour to spare to "struggle" with one business intelligence requirement before the Advanced SQL lesson.

	With a new strategy in place to tackle SQL problems, I was able to complete all but two business intelligence requirements in the 24 hours following the Advanced SQL lesson. I thought I was in a really good place. Then all of a sudden...

	Meanwhile, I was shipping code with the notion that Active Model Serializer (AMS) would be used for the project, based on the Turing lesson plan on their website and a video they published to YouTube. It wasn't until five days into the project that the spec harness was in a usable state. Once I was able to get the spec harness working, I realized that my serializers were not organizing the data in the way that the spec harness required. I wasn't concerned about getting AMS to do what I needed it to do, but I didn't want to go too far down a rabbit hole this late in the game; so I asked some classmates what strategy they used. It was then that I learned about Fast-jsonapi.

	With the help of my classmates, I was able to get my Merchants endpoint returning data in the correct format before heading into the weekend. With the change to serializers, I went from 80/80 passing tests to 20/80 passing tests. I made the decision to ignore the spec harness in favor of developing an app that bared some semblence of the intended result. Don't let perfect be the enemy of good.

	I would spend the weekend updating my previous work to comply with the newly found data structure; adding the endpoints I had skipped over during the week; and finishing the business intelligence requirements...all but nested resources were developed using Test Driven Development.

	I was able to get my project in a reasonable state by Sunday afternoon. I had all my endpoints, all but the most complex business intelligence requirements, and 130 unit and integration tests (I decided to throw most of the nested resources together without tests in the interest of getting them completed before the deadline).

	Now the 800-pound gorilla in the room was the spec harness. Having paid no attention to it until now, I knew there were going to be issues. I would spend most of the day before the deadline cleaning up what details I could...changing arrays to JavaScript objects, integers to decimals, decimals to strings, and so on until bedtime approached. I would manage to get it up to 85/106 tests passing before putting it to bed. I have the skill and knowledge to get them all passing, I just don't have the time.

	Having spent the last week on this project and reflecting on my progress, I wish I would have examined the spec harness much more closely and much sooner. I tried to run it everyday beginning day 1 and asked my classmates if they had success. Getting nowhere with getting the tests to run, I pushed it to the side. In hindsight, I wish that I had been able to examine the inners of the tests and understand them up front. Doing so would have brought to light my issue with serializers much sooner and saved me precious time. In future projects, my development will be driven by the spec hardness as opposed to the project requirements.

	In the end, I'm pleased to have a working API to share with potential employers (they don't need to know that it doesn't pass the spec harness). I also got a ton of reps with rails components, tests, AR/SQL and serializers. My immediate plan for the project is to fill in the gaps with tests for all of the nested resources, after which I may update according to tests failing
	in the spec harness.