In an effort to better document FG LOS software, primarily for developers working directly with the code, I was tasked to find a PHP documentation generator that would work well for our codebase. We were mainly interested in ease of use, but were also keen on a solution that offered decent default styling.
The user story goes something like this: As an admin, I want updates to FinanceGenius LOS admin settings to propagate to the customer-facing LG portal so loans funnel in seamlessly.
The fine folks at *terrible contractor we were using that I will not call out by name* decided that if a lead funneling in from LoanappGenius (LG) did not transmit to a client’s FG LOS correctly, a cron would try again five minutes later. With any application, things can go wrong. With LG, things do go wrong. I start by interpreting mysterious and totally ambiguous error status codes. If I haven’t hooked you by this point, keep reading anyway.
The Military Lending Act was amended in September 2015 to place limits on how high an APR lenders could set for active military personnel. The real difficulty came after realizing the logic surrounding loan products and fees was now lacking. Their inclusion or exclusion affects MAPR values, and thus MLA rules. A refactor was in order because these can be updated in so many ways across the system.
A simple goal of fixing the mapping of a few fields in a customer-facing application to properly transmit their values through a non-trivial API network essentially became a sprint-long debug session because the contractor we hired was insane.
Motivated by a need to honor discounted rates for current members, we needed to update the way we allow lenders to specify a borrower’s credit union member id. The new functionality would let the lender specify that id instead on the edit application page at the start of the loan process.
At the start of this relatively straightforward epic, there were a number of “terminal” loan statuses already in existence: abandoned, expired decision, expired contract, and finalized. Somehow missing from this list was a way for lenders to withdraw a loan in the FG LOS. We had to integrate this functionality with many other services across the site including user permissions, the automatic decision engine, the decision status cron, and application queues.
After botching my local Homebrew development environment, I decided to create a virtual instance to facilitate FG development. This way, no matter what crazy things I decide to do on my Mac in the future, nothing will affect my ability to contribute to the project. And if I screw up my virtual environment, I can quickly recover it. My documentation provided a template for the steps required to build a local environment programmatically using Ansible so that current and future developers have only to clone the software repo, download VirtualBox and vagrant, and `vagrant up` to begin coding.
Symitar, a software system powering hundreds of credit unions, uses collateral codes for all loan types regardless of whether they are secured or unsecured. In an effort to comply with industry standards, we needed a Symitar integration to provide options to allow the user to supply a collateral core code for every loan type defined in their system. The newly defined collateral code can now be sent to the Symitar core on loan approval, thus allowing banks another way to distinguish loan types.
The task to be solved consisted of enforcing a 4-digit max size to Symitar core codes. It sounded easy enough, but a quick run through the domain revealed that core id fields were spread across eight different admin pages, each uniquely structured, implemented within their own context. I had to extend existing jQuery Validation library functionality to accept custom messages and errors returned from Ajax requests to the back-end. My eventual solution was done in a way to be easily extendible to future core implementations.
