PocketNumerix Files

PocketNumerix repository notes (2023-Dec-21):
This repo contains a suite of smartphone scale computational finance tools, their common installer, and some of the web technology (license key generation, Rijndael256 encryption/decryption) behind the online store.
The last time I looked at this code, documentation, web resources, etc. was in December 2009.  I’ve forgotten a lot of the outstanding issues, but a few ‘ToDo’ files sprinkled around may help.
StockMiner and OptionMiner are Windows desktop apps for testing Yahoo Finance scrape & parse. Those capabilities were integrated into NillaHedge.
WebEncodeDecode is a custom extension of a SquirrelCart web store that creates a BillOfMaterials file (with license keys encoded to the email address) that the store emails to the customer. The user would separately download PNMX_Installer, place the BOM file into the installer folder and run it.  Once launched, the installer would download and decrypt the encrypted {signed executable(s)} stored as .crp files in the public_html/Install_Process/Supplies folder, decrypt the ones called out in the BOM and install/register the license keys.
Inconveniently, I forgot how the public_html/Install_Process/mime/*.mime and public_html/Install_Process/cfg/*.cfg files factor into the BOM generation, encryption, and decryption processes, so it will take a little experimentation to recover how I was securing the intellectual property. Hopefully, Android/Google Play and IOS/Apple App Store have all of that institutionalized by now, so maybe superfluous and irrelevant now.  NillaHedge incorporated that same decryption to download from a cloud-resident cache of option chains (to minimize hits on the data source).
So, here’s the beef…
Application folders - BondManager, NillaHedge, StrategyExplorer, and YieldCurveFitter - contain sources (based on the Windows Mobile 5 SDK), Visual Studio 2005 project files, and sometimes revision/ToDo notes.  Migrating to the current Windows App SDK should be doable without horrific pain.  Going backwards to support 2002 and 2003 PocketPC is also possible (given that all four apps ran on PocketPCs before the advent of WM), but similarly not necessarily just a matter of recompiling for another target, due to API evolution/deprecation/revisions.  With those caveats, each application is buildable without any external code.  [Common sources should ideally be migrated to a shared folder.]
Smartphone screen sizes have grown since 2005. At the time, the burden of supporting multiple screen sizes was on developers; I haven’t checked to see if that has changed.  That’s an area where modifications will likely be needed.
Screen size constrains the number of buttons, text boxes, etc. that can be squeezed into the space available.  In the analysis of option spreads, you really hope to be able to handle four (to accommodate butterfly spreads).  2002/3 era PocketPC screen size (240x320 pixels) meant only three options could fit on screen in StrategyExplorer and NillaHedge’s HedgeExplorer.  When Windows Mobile 5 debuted with support for 480x640 screen sizes, it became possible to handle four options.  StrategyExplorer was upgraded to handle four, but NillaHedge’s HedgeExplorer was never upgraded to support butterfly spreads (composed of four options).  The changes needed to support a fourth option are relatively minor (obvious even) - that should be a goal.
All of the code was written prior to the availability of SQLite; NillaHedge and BondManager therefore store data in dense binary files, comprising a crude datastore, unique to each application.  The performance of these embedded ‘databases’ degrade linearly with database size because every ‘record’ is considered on any traversal (search).  Now that working RAM and CPU speeds are so much more accommodating, the smart move would be migrating those applications to SQLite or similar, so indexes can be added (or removed) virtually on a whim, instead of painstakingly woven into application layer code.
Options markets are more dynamic than bond markets, option contracts that were available yesterday might not be available tomorrow, and it wouldn’t be unusual to consider many dozens of options in a day, so the database is very likely to get polluted with contracts that have past their expiration date or are no longer being offered by market makers for other (risk/profitability) reasons.  Culling the local cache of dead and unused options is a ToDo for any reimagining of NillaHedge, better yet, a supporting tool that runs periodically to cull ‘dangling’ (with respect to markets) option definitions when NH doesn’t have the data store locked.  NH tracks the user’s buy/sell transactions so portfolio value can be calculated anytime (based on issue/contract prices in the definitions) and end-of-year tax documentation, so you can only purge the options cache if the user never bought any it.  That’s going to be another opportunity for improvement and could likewise be implemented as a supporting tool that periodically checks market prices and updates the local definitions.
In this (feasibility) implementation, option chains were scraped from Yahoo Finance, but Yahoo is a fast-moving target for a scraper/parser. You will need an alternate source of option chain data or a much smarter HTML parser than used here.
Each application is a computational silo independent of the others, except that YieldCurveFitter writes its last computed RiskFreeRate (RFR) to the registry (every time the value changes) and NillaHedge grabs that ‘published’ value whenever an analysis tool dialog is (re)opened.
Run time footprints are small; only NillaHedge is likely to use more than 1MB of RAM at run-time. 
The public_html folder contains the vestiges of the pnmx.com (and PocketNumerix.com) website including overview marketing materials (at top level) and detailed documentation with example screenshots in the Documentation subfolder.
 - Mike Landis