<p>I have found that it is better to put structure in place around a project before going hog wild on implementation. While I recognize that some practices grow organically, a healthy amount of structure up-front can save a project from technical bankruptcy down the line. The two tools that I use early and often are interfaces and contract classes.</p>
<h2>Interfaces and Contract Classes</h2>
<p>There are a collection of interfaces that I regularly utilize throughout most projects.</p>
<ul>
<li>ICreated
<ul>
<li>VigilUser CreatedBy</li>
<li>DateTime CreatedOn</li>
</ul>
</li>
<li>IModified : ICreated
<ul>
<li>VigilUser ModifiedBy</li>
<li>DateTime? ModifiedOn</li>
<li>bool MarkModified(VigilUser, DateTime)</li>
</ul>
</li>
<li>IDeleted
<ul>
<li>VigilUser DeletedBy</li>
<li>DateTime? DeletedOn</li>
<li>bool MarkDeleted(VigilUser, DateTime)</li>
</ul>
</li>
<li>IOrdered
<ul>
<li>int Ordinal</li>
</ul>
</li>
<li>IEffective
<ul>
<li>DateTime EffectiveOn</li>
<li>bool SetEffectiveOn(DateTime)</li>
</ul>
</li>
<li>IEffectiveRange : IEffective
<ul>
<li>DateTime EffectiveUntil</li>
<li>bool SetEffectiveRange(DateTime, DateTime)</li>
</ul>
</li>
</ul>
<h2>The Obvious — ICreated, IModified, IDeleted, IOrdered</h2>
<p>These four interfaces serve to ensure that all properties are identically named throughout the solution. They also serve as a guide to future developers about what restrictions should be placed on the class. Every class that persists data to storage should implement ICreated — everything was created by someone and at some time.  An object that doesn?t implement IModified should never actually be modified. A class with IDeleted should not have the records actually removed from storage, but just fill in these fields to flag them as deleted. IOrdered means we know to set a default sort on the Ordinal field.</p>
<h2>Instead of Deleting It — Effective It!</h2>
<p>For values where we need historical data to be easily accessible, such as changing schedules or payment information, an interface is created to track the EffectiveOn date. Starting at that specific date and time, the new record becomes effective. There needs to be some way to group the different records, which is usually performed with a header type table. By definition, there can only be one effective record at any given date.</p>
<p>An example of its use is storing the payment information for a recurring transaction. The historical data for payment information is useful when looking into the past, and frequently the patron may want to change the payment option effective some future date. However, at no point will two or more payment methods be active. By implementing the IEffective and ICreated, the details of who made the change (and when) fully replace any functionality that might be lost by not implementing IModified.</p>
<h3>Need Multiple, Overlapping Effectives — Range It!</h3>
<p>When multiple records need to have their history saved or allow for changes effective in the future, the IEffectiveRange comes into utility. For IEffective records, the end of their effectiveness is the beginning of the next record?s effective date. However, for classes where there can be multiple records that come and go, an explicit range is required. This is useful for line items on a gift ? do see when any given detail was the authoritative record, especially useful after the gift has been posted and receipted.</p>
<h3>Contract Classes For</h3>
<p>I battled back and forth with whether to include the shell for code contracts with every interface I write, or to only build it out when needed. I quickly found that I was including, at minimum, a contract invariant method on each interface, so I decided to just make it a standard part of every interface. Even if the Contract Class contains no Contracts, at least the shell is there, and I can easily add them later, as needed.</p>
<p>A quick standard I have put together is that all Contract Classes are contained in the same file as the interface, in a child namespace of ?Contracts,? and named after the interface. Keeping the classes as internal and abstract means it can only be called within the assembly,</p>
<h3>Minimum Viable Framework</h3>
<p>I finally feel that I am at a stage where I have the minimum of a framework on which I can start to build an actual product. From here, I will slowly add and expand modules, slowly drifting towards the user interface, and tool with refactoring, templating, scripting, and finding other ways that I can reduce the complexity of complex tasks.</p>
<blockquote>
<p>Added generic interfaces, and began cleaning up some Code Analysis rules from the ?All Rules? playlist.</p>
<p>—<a href="">Commit 4010e840a8b168a1ab65466fa5c61cc342b56d8e</a></p>
</blockquote>
<blockquote>
<p>Added new Code Analysis rule sets to eliminate rules that I would be ignoring anyway.
Resolved several Code Contracts and Code Analysis issues.</p>
<p>—<a href="">Commit 2b1ff8a55711cb585750d4241df9c97895b7edfc</a></p>
</blockquote>
<blockquote>
<p>Decided I didn?t like having fields for the context, testuser, and now. Put them back as variables in each test method, and added a ContractVerification(false) attribute to the whole class. I think I?m going to find myself adding that attribute to a lot of testing classes.</p>
<p>—<a href="">Commit df9e61081f22471546dd1fd1132c8ecfecc3a26c</a></p>
</blockquote>
<blockquote>
<p>Added Contract Classes for each of the Interfaces.
Created the Identity and TypeBase classes to expand the foundation of classes before working on POCO?s.
Need to add more unit tests to fill out the Code Coverage.</p>
<p>—<a href="">Commit 716da101f6da28158ab0ed52aaba037b4c027676</a></p>
</blockquote>
<blockquote>
<p>Added ExcludeFromCodeCoverage attributes to the ObjectInvariant methods in the interface contract classes.
Added tests for the TypeBase class (via inheritance through a TestTypeBase class).
Filled out the ChangeLogTests tests.</p>
<p>—<a href="">Commit bcc51aeaa46dc8780ffcd9c33f88d8ecb1c2fffd</a></p>
</blockquote>


Preemptively Structuring the Chaos

<p>All of my other marathon posts seem to have the "three parts" theme going, so it probably fits for this writing. On the second of May,
I ran the Wisconsin Marathon in Kenosha. It is combined with a half-marathon, and a delayed start 5k. I had a terrible experience, but I came away with some fantastic personal post-race analysis.</p>
<h2>1) Terrible Marathon Course</h2>
<p>Pre-race logistics were fantastic. There were plenty of port-a-pots that I was in line for less than two minutes, with only fifteen minutes before the race started. Most other races I have been to include extremely long lines that snake out even a half hour before race start. The gear check was easily accessible and close to the start line. The self-seeded corrals were large enough that there was no crowding at any of the pace signs (at least from what I could see between the 7:00/mile and the 10:00/mile corrals). The race started on time, and most people seemed to do pretty well in that first mile at keeping with their selected pace.</p>
<p>The first twelve miles shared the same course as the half-marathon. There were a few gently rolling, small hills, and the pavement was almost always in good condition. Water stops were a little far apart and a little understaffed, but it was a small race and I can accept that. Had the weather been any warmer at this point (and runners thus taking more time at the tables), it would have been a real hindrance to anyone trying to run while grabbing water. The very northern point of the course had a long bend to the right, just before the turn-around, which seemed to stretch on forever - but that's just a mental part of the course, not something I would deduct from the quality score of the course.</p>
<p>However, once the half-marathon turned around to head to their finish, the course took a complete nose-dive. Cheering was already lacking in the northern half, but it became almost non-existent in the southern half. However, I figure that is part of being a small field. One of the worst parts of the course where patches on gravel. Not that nicely packed, small grain gravel - no, this was freshly dumped, large, pointy rocks with sharp edges that jam into your foot through the thin racing shoes. I felt really bad for anyone running in minimal or five-finger shoes. That would have been just disastrous. The worst part was between miles 18 and 20. It was two long miles, at the very southern point in the race, that were completely without shade and on freshly laid, sticky, heat-radiating, jet black pavement $endash; with one water station. Absolute, race killing, misery. My pace was slipping going into that stretch, but that took everything out of me. I had nothing left by the time I pulled out of that awful zone.</p>
<h2>2) Poor On Course Support</h2>
<p>As I mentioned before, the water stations (with Gatorade) were small. They were also spaced a bit farther apart than I was comfortable with. Allegedly, they also ran out of Gatorade at the last two stations shortly after I had passed them (a friend who finished fifteen minutes behind me said they were out of Gatorade). I don't know if this was because of lack of volunteers or not buying enough for the size of the field, but that seems to be a huge oversight. Additionally, there was nothing but water and Gatorade on course, and one table of PowerGel around mile 19. I would have killed for a banana at each hydration station after mile 20, and I'm sure those following me were in even worse shape.</p>
<h2>3) Sad Post-Race Party</h2>
<p>The website advertises "Our race offers everything you can dream of, plus our famous Big Cheese Medal and a brat and beer at our Post Race Party!" Directly after the finish line was water in bottles (good), bananas (great), plain bagels (acceptable), and chocolate milk (the best). However, that was it (well, there might have been Gatorade, but I didn't go looking for it). The Big Cheese Medal isn't all that big - but there's a picture of cheese on it. My pet peeve is that it is the same medal for the full and the half marathon - only the ribbon is different. The brat was less than special, and cut in half and stuffed into a pita - a PITA! Who puts a brat in a pita? It goes in a bun! The only condiment options were yellow mustard and ketchup. This is Wisconsin - brats are a culinary staple. How did they screw it up this badly? And the beer was probably a 6 oz serving. Very weak.</p>
<p>Overall, I would not recommend that marathon. If you happen to be in Kenosha, first ask yourself why you're in Kenosha; then, see if you can run the half-marathon. I would have probably had a very positive race experience if all I ran was the half-marathon; it's a shame the race was so terrible on the back half of the course.</p>
<p>Random footnote: if I had run the 5k, I would have placed first overall for men, possibly first overall. The top three times were:</p>
<ol>
<li>19:25 - Leslie Patterson, 32F</li>
<li>19:54 - Samantha Helgesen, 26F</li>
<li>21:32 - Jeffery Kiekhofer, 31M</li>
</ol>


3:56:58 - 2015 Wisconsin Marathon

<p>Two key library decisions needed to be made this week: choosing the object-relational Mapping (ORM) framework, and choosing a membership provider. To cut right to the end, Entity Framework and ASP.NET Identity were the solutions that I have chosen to utilize throughout the software. This week's commit has been getting the initial implementation created, customized, and tested.</p>
<ul>
<li>Create NotImplementedAttribute</li>
<li>Extend Identity membership classes</li>
<li>Create Interface for data context</li>
<li>Create Data Context</li>
<li>Create minimal tests</li>
<li>Minor Clean ups</li>
</ul>
<h2>NotImplementedAttribute</h2>
<p>Sort of like a TODO in the code, I pepper classes that still need work, or are just a placeholder shell with this attribute. This makes it so I can easily add a Code Analysis rule to mark it as incomplete, or I can add an ObsoleteAttribute to the NotImplementedAttribute. The compiler will issue a warning and I can easily track down any places I left marked as Not Implemented.</p>
<h2>Vigil Identity Classes</h2>
<p>By default, the Identity classes use a string as the primary key. Internally, it is a serialized Guid, but I could not find a good reason why this was masked. Also, I wanted to play with inheriting the classes ? so I did exactly that. For now, the "System" classes are just the Identity classes, with a Guid key, and table names explicitly set to match the class name (thus overriding the <a href="http://stackoverflow.com/questions/29904898/classes-inherited-from-identity-objects-not-included-in-code-first-migrations">IdentityDbContext's default</a> of naming them "AspNet_____").</p>
<h2>Data Context</h2>
<p>Now is when the fun gets to start ? time to start making some actual progress towards real data.</p>
<ol>
<li>Create the IVigilContext interface, to expose the bare minimums.</li>
<li>Create the Database Context: VigilContext</li>
<li>Inherit it from the IdentityDbContext generic class (so I can use those beautiful Vigil____ classes I created).</li>
<li>Inherit it from the IVigilContext interface and implement the "AffectedBy" and "Now" properties.</li>
<li>Create three tests:</li>
<li>Initialize and Create the database ? this runs Entity Framework model validation. I wish I could find a way to do this without actually having to create the database, but I was unable to find a way to expose the EF method that runs the validation.</li>
<li>Verify that the explicit constructor is setting the AffectedBy and Now properties. It is a menial test, but it makes sure no one breaks it in the future.</li>
<li>Assert that the Set method works for at least one model. This serves two purposes ? it makes sure that the Context is calling its base class's Set method, and it makes it so that code gets covered by a test, thus passing Code Coverage analysis.</li>
</ol>
<h2>Minor Clean Up Duty</h2>
<p>I misspelled the name of the core project, spelling it "Vigi.Data.Core". This meant renaming the project, updating the Assembly name, default Namespace, the folder name (which also caused a rename on all files in the project), the namespace in existing classes, and references to the project. Thankfully, I caught it before I was creating objects that referencing those elsewhere.</p>
<p>In order to get complete Code Coverage for unit tests, I created a test just to call the constructor for the NotImplemented Attribute (it throws a NotImplemented Exception). However, the last line in that test is an Assert.Fail, which should never be reached. This causes the Code Coverage to say that line was never executed, and thus not covered. Obviously, I do not care about Code Coverage in the Testing project, so I added a codeCoverage.runsettings file, which explicitly excludes the Vigil.Testing.Data assembly from analysis.</p>
<blockquote>
<p>Added Vigil Users and Roles implementation of the Identity framework, and added two quick tests for VigilContext.</p>
<p>—<a href="https://github.com/drovani/Vigil/commit/9bca8542c5a0f099032631c133215a5bd9c28aae">Commit 9bca8542c5a0f099032631c133215a5bd9c28aae</a></p>
</blockquote>
<blockquote>
<p>Added Entity Framework and Identity Framework.
Customized the Identity objects with Vigil objects, including using a Guid as the primary key, and adding a RoleType enum. Added a .runsettings file to exclude the Vigil.Testing.Data project from Code Coverage reports. Corrected the "Vigi.Data.Core" misspelling to "Vigil.Data.Core".</p>
<p>—<a href="https://github.com/drovani/Vigil/commit/8be35473aa84138f6ee362d083dd424726345089">Commit 8be35473aa84138f6ee362d083dd424726345089</a></p>
</blockquote>
<blockquote>
<p>Added tests to validate that the Vigil* tables have the correct names, since there was a problem with them being overwritten by the IdentityDbContext.</p>
<p>—<a href="https://github.com/drovani/Vigil/commit/4b68465701f111a806a920e7ec4d12de697aeee7">Commit 4b68465701f111a806a920e7ec4d12de697aeee7</a></p>
</blockquote>


Laying the Foundation

<p>After several false starts, the convention for how to organize a solution seems to have come together. This also includes how to change the default project settings, and how to keep everything tidy as the software grows.</p>
<h3>Vigil.Data Solution</h3>
<p>This solution will contain all projects in the Vigil.Data namespace. This includes the central collection of Entity Framework data models, projects for DDD Bounded Contexts, and each project needed for services. There will be future solutions for the web projects, automated routine projects, importing pipelines, export processes, etc.</p>
<ul>
<li>Vigil.Data.Code: where the Entity Framework Code First data models exist, including necessary abstract classes, interfaces, and extension methods.</li>
<li>Vigil.Data.Modeling: contains all of the Entity Framework specific code that pertains to modelling the data into the data store (database), including the DbContext, Database Migrations, DbInitializers, and interfaces. This does not include any bounded contexts that may exist in the future.</li>
<li>Vigil.Data.Services: services (which handle the business rules and workflows), specific-use data models, data mappers, validation, and supporting interfaces will all reside in this project.</li>
<li>Vigil.Testing.Data: all unit tests will be rooted in the namespace Vigil.Testing, with the sub-namespaces reflecting the project(s) they are testing. Thus, this will have all of the tests for the Data projects.</li>
</ul>
<p>Once these projects are created, there are three property pages that I immediately change from the defaults.</p>
<h3>Assembly Information</h3>
<ul>
<li>Check the Company and Copyright information to make sure they reflect the project that I am creating (and not the computer's defaults).</li>
<li>Set the Assembly Version to 0.1.* (default the Build and Revision Numbers)</li>
<li>Set the File version to 0.1.0.0</li>
</ul>
<p>Later, as the project grows and meaningful features are added, I will manually increase the minor version number as appropriate. Maybe even increase the Major Version, too!</p>
<h3>Signing</h3>
<blockquote>
<p>Benefits of strong naming your assembly first:</p>
<ul>
<li>Strong naming your assembly allows you to include your assembly into the Global Assembly Cache (GAC). Thus it allows you to share it among multiple applications.</li>
<li>Strong naming guarantees a unique name for that assembly. Thus no one else can use the same assembly name.</li>
<li>Strong name protect the version lineage of an assembly. A strong name can ensure that no one is able to produce a subsequent version of your assembly. Application users are ensured that a version of the assembly they are loading come from the same publisher that created the version the application was built with.</li>
<li>Strong named assemblies are signed with a digital signature. This protects the assembly from modification. Any tampering causes the verification process that occurs at assembly load time to fail. An exception is generated and the assembly is not loaded.</li>
</ul>
<p>—Why use strong named assemblies? answer by Kyle Rozendo</p>
</blockquote>
<h3>Code Contracts</h3>
<ul>
<li>Set the Assembly Mode to "Standard Contract Requires"</li>
<li>Enable Runtime Checking at "Full"</li>
<li>Set the <a href="http://stackoverflow.com/a/17892803/28310">Contract Reference Assembly</a> to "Build"</li>
</ul>
<blockquote>
<p>Initial projects for the Core data models, data modeling objects, data services, and data testing.</p>
<p>Added public assembly signing, code contracts, application versioning, and copyright notifications.</p>
<p>—<a href="https://github.com/drovani/Vigil/commit/527fabb81ff6383f8ece46848feb2e329c131201">Commit 527fabb81ff6383f8ece46848feb2e329c131201</a></p>
</blockquote>


Vigil.Data Solution and Initial Projects

<p>There are many posts out there for how to configure a database schema to handle scheduling events. The part that I found difficult to find was an algorithm for calculating future dates for each type of recurring schedule. I have started this series on Recurring Gifts as a way to document the process I went through to build the current system. Some features include:</p>
<ul>
<li>Ability to scheduled gifts by daily intervals, weekly intervals, monthly (by date) intervals, and monthly intervals by relative point. From there, it is simple math to do Quarterly, Yearly, or any other multiple.</li>
<li>Ability to place gift generation On Hold until a certain date.</li>
<li>Ability to Cancel gift generation on or after a certain date.</li>
<li>Ability to makes changes that apply on a certain date.</li>
<li>Easy to answer the question of "why was this gift created" because all gifts are linked to the schedule that generated it.</li>
</ul>
<p>A few limitations that may constraint its universe utility:</p>
<ul>
<li>Only one active schedule can be created. Can only do "first Friday of every Month", not "first Friday of every Month, and third Tuesday of every other Month."</li>
<li>Cannot schedule by the phase of the moon (not even joking ? this was an actual request) ? though it could be fudged by using a Daily schedule.</li>
<li>Cannot schedule based on National Holidays (also an actual request).</li>
<li>Schedules can only pause and restart once (via the Header.HoldUntilDate).</li>
</ul>
<h2>Database Schema</h2>
<p>Instead of inventing a database schema from nothing, I did what I do best — stand on the shoulders of giants, and Microsoft's SQL Server team is a pretty huge giant. Turning to their documentation on the <a href="https://msdn.microsoft.com/en-us/library/ms178644.aspx">SQL Server Agent job schedules</a>, I opened up the msdb.dbo.sysschedules table. I adjusted some of the definitions to fit my need and built my schema from there.</p>
<h2>Schedules Data Schema</h2>
<p>There were three major changes that I made to the SQL schedule.</p>
<ol>
<li>Frequency Interval, for weekly recurrences, is a bit flag in the SQL Agent schema. Since there is already an enum in the mscorlib, I changed the schema to use the System.DayOfWeek enum values.</li>
<li>Frequency Interval, for monthly relative recurrences, uses 1-7 for Sunday-Saturday, 8 = Day, 9 = Weekday, 10 = Weekend day. I only need the days of the week, so it made sense to also adjust this to use the System.DayOfWeek enum values.</li>
<li>I dropped all notion of "sub day" scheduling. There is no need to have gifts created at multiple points in a day.</li>
</ol>
<p>A common approach to handling querying the event dates is to store a list of all future dates. I can also use this to determine when
the gift was actually created, and use this as an audit for gift creation. By tying the Audit to the Schedule, it is very easy to find
out exactly why an Audit was created.</p>
<p><img src="/images/recurring-schema.png" alt="Recurring Schema"></p>
<h2>Evolution Path</h2>
<p>There were two mistakes I made in the original implementation of this schema. First, I had the End conditions on the Schedule. The thought was that this would be mildly helpful with knowing why the generation of gifts might have started and stopped. Potentially, a termination point would be reached, gifts would stop being generated, then a new schedule would be added, thus resuming creation. However, the actual hit rate for this situation was zero. All it did was ridiculously complicate the algorithm for parsing the schedules.</p>
<p>Additionally, I previously had the Start Date on the Schedule. This also was confusing, as two schedules could be created and cause a gap in the timeline. It is much more easier to implement one "pause until" setting than try and handle skips. My use case was exactly zero for needing multiple start and stops, which is why I have pulled back on the complexity a bit for this second round.</p>
<h2>Up Next</h2>
<p>The next post is going to start to demonstrate how I implemented various parts of the C♯ algorithm to generate the dates in a schedule. These collections then are combined to provide for a final list of all dates.</p>


Recurring Gifts — Part 1: Database Schema

<blockquote>
<p>There are only two hard things in Computer Science: cache invalidation and naming things.</p>
<p>-Phil Karlton</p>
</blockquote>
<p>To any seasoned developer, this is entirely too true, and <a href="http://www.quora.com/Why-is-naming-things-hard-in-computer-science-and-how-can-it-can-be-made-easier">many</a>
<a href="http://blog.stackoverflow.com/2009/03/it-stack-overflow-update-naming-is-hard/">people</a> have <a href="http://seesparkbox.com/foundry/naming_css_stuff_is_really_hard">written</a>
extensively on why this is so hard. For this particular exercise, I have to decide what to the call the core object that represents a (potentially) giving unit in Vigil. Trolling through existing applications, here some options I have come across, and why I rejected them:</p>
<ul>
<li>Client - feels too impersonal for a DRM, though I know there are non-profits that use this as their preferred term.</li>
<li>Constituent - the term is mostly used with voting system. Also, I am really loathe to type out "Constituent" thousands of times.</li>
<li>Customer - this term is associated more with a point-of-sale system than a donation tracking system.</li>
<li>Donor - not all names in the database are going to be actual donors. Some will just be people that purchased something, many will not even have given (in a system I recent worked on, around 55% of the names were non-donors).</li>
<li>Entity - this conflicts heavily with Entity Framework, where the Entity object is used everywhere.</li>
<li>Patron - this is a compelling term, since it has the dual definition of being both a person who gives financially, and a customer to a store.</li>
</ul>
<p>The other part of the name is that it needs to pair with all of the auxilary tables that will be prefixed with:</p>
<ul>
<li>______Address</li>
<li>______Attachment</li>
<li>______BankAccount</li>
<li>______Code</li>
<li>______ContactBase</li>
<li>______CreditCard</li>
<li>______Date</li>
<li>______Email</li>
<li>______Identifier</li>
<li>______Note</li>
<li>______Number</li>
<li>______Payment</li>
<li>______Person</li>
<li>______Phone</li>
<li>______Relationship</li>
</ul>
<p>And that's just the preliminary list!</p>
<p>I had initially gone with Entity, since that it is what our current system uses. However, I quickly tired of running into the namespace conflicts with EF, and thus went searching for alternatives. I had almost settled on Constituent, until I went to start the re-factoring and after the twelfth time of typing it, realized it was going to cause <a href="http://www.ninds.nih.gov/disorders/carpal_tunnel/detail_carpal_tunnel.htm">CTS</a>. Patron was a late find that I stumbled upon. Thesauruses are my friends. So far, I am really digging it. I figure I get one re-factoring before I hit the point of no return. I am hoping this is the right one.</p>


Naming the Patron Object

<p>I am not sure why I started using <a href="http://knockoutjs.com/">Knockout</a>, but I have had an overall positive experience with the framework.  I was very intrigued with their hands-on tutorials built into the site, which made getting started fairly easy.  I walked through them step-by-step, writing out all of the code examples by hand, and diligently debugging typos when the example would not execute as expected.  From there, I took the simple step of starting a small side-project just to see how it would all interact.  At that point, it became quickly obvious that the tutorials suck and are missing large pieces of information that are vital to get just a basic application going.  I also found that there are two tutorials that are completely worthless in terms of getting start - they are advanced topics that I still have not found an applicable usage.</p>
<p>However, the tutorials were just an hour or two of my time, and at least got me started.  The most bothersome part is the official documentation on the website.  It is terribly incomplete, and just leads to frustration.  There are lots of hidden features and unexplained function arguments that force me to take trips through search engines, which inevitably lead to a question that someone else posted on <a href="http://stackoverflow.com/questions/tagged/knockout.js">Stack Overflow</a>, which might hint at the answer to my problem.  It has been frustrating to have to wade through the tangled mess of tangential questions and obscure answers to maybe find something similar to my problem.  However, it has also been immensely rewarding to discover new methods of working with JavaScript, better tools for debugging, and simpler ways to manage my code.</p>
<p>The <a href="https://github.com/knockout/knockout/wiki">GitHub wiki</a> is sparse and filled with many empty templates.  The information is not reliable - I am not sure how much of is it accurate as of Knockout 3.1.  So, I am working on slowly putting together better documentation.  As I discover something new or expand on something I already know, I am adding it all to a little sidebar of notes that I keep.  My hope is that I will get enough information that I can meaningfully contribute to the wiki.  I like this project, and it is clear that plenty of other people like it.  I just wish the difficulty to realistically get started was a little lower.</p>
<p>I am trying - this is going to be my <a href="http://opensource.com/life/14/1/get-involved-open-source-2014">first little tiny toe dipping</a> in the big ocean of open source development.  We shall see how it goes.</p>


Rovani's Sandbox

Blog Posts - Page 12