SpreadServe will be at the Develop Excel conference in London on 18th October. If you build spreadsheets for the trading floor with XLLs you should be there too. I’m especially excited about the session with Govert, Mr Excel-DNA.

Windows EOL

June 14, 2018

Could Windows die as an enterprise OS? Could it disappear in the same way as desktop  workstations from Sun, SGI & Next? Could it vanish from the datacentre just like Solaris?

Twenty years ago Open Source advocates pushed the Linux desktop as a means to break Microsoft’s stranglehold on PC computing. At the same time Sun promoted Java applets as desktop OS agnostic. In reality it was the iPhone launch in 2007, and the rise of the smart phone that broke Microsoft’s dominance in the consumer space; Android & iOS are the leading phone and tablet OSes and have driven the shift from Windows being the primary GUI to HTML5. But despite the primacy of the HTML5 GUI for new systems, Windows position on the corporate desktop still seems secure. Why?

There are good reasons Windows persists in the business environment when it has receded in the consumer space: corporate knowledge workers need desktop computing, and Windows is still the best option: cheaper than MacOS, easier to use than Linux and more compatible with legacy apps than either. It’s still the best platform for running MS Office, naturally. But maybe ReactOS – an Open Source Windows clone, could eventually change that. With no license fee that makes it cheaper than Windows, so the question becomes: could ReactOS form the basis for a RedHat style play that would eliminate desktop Windows in the same way RedHat Enterprise Linux finished off Solaris? For that to be happen possible ReactOS would need to achieve higher levels of compatibility. Currently it can run a lot of apps including Excel Viewer, but not Office itself. That could be addressed by industry consortia. How much do large enterprises spend on Windows licensing? Potentially, that cost could be taken out in favour of funding consortium efforts to raise ReactOS compatibility, package it for corporates and supply support.

It’s an intruiging prospect, but there are good reasons why it would be hard to execute. Firstly, the sheer technical difficulty of troubleshooting without source code access for MS Office, .Net and other legacy apps. Debugging is a hell of a lot easier with source code access. Secondly, Microsoft’s competitive response; they could drop the cost of Windows volume licensing to zero or near zero. And they could engineer Office and .Net for ReactOS incompatibility. However, both responses could invoke resistance from anti monopoly regulators.

I’ve just updated my Netty based TransFICC web socket server to work with version 330cb31-3670 of the TransFICC API and service. TFWebSock enables web socket clients to subscribe to TransFICC sourced market data. Those web socket clients could of course be browsers, but in the case of this demo the client is the SSAddin Excel addin. Which means that you can use TFWebSock and SSAddin to pull live ticking ICAP iSwap swap rates into Excel on your desktop. And if you want to automate and serverize that spreadsheet you can do so with SpreadServe.

I should point out that the ticking rates in this demo are from the iSwap test system, and are not live production rates. Many thanks to the teams at TransFICC and ICAP for making this data available!

SpreadServe and TransFICC

August 11, 2017

Earlier in the summer I did a POC integration of SpreadServe with TransFICC. For those unfamiliar, TransFICC has an ex-LMAX founding team, and is a new entrant in the ECN gateway space. Technically their key differentiators are cloud hosting and high performance engineering techniques. For Transficc clients the only thing running on premises is the Java API, which puts the same orthogonalised interface on all the usual fixed income ECNs, and connects to the cloud hosted gateway processes.

It’s been a while since I built anything non trivial in Java, so I was pleasantly surprised by how improved the Java ecosystem has become. Gradle has transformed dependency and package management. And the single threaded async approach popular in the Python and C++ worlds has finally made it to Java with Netty. You can find the code on GitHub here.

 

Back in April I read a great post by Jaakko Piipponen on the SaaS financial model he’d built as an Excel spreadsheet. I’m interested in spreadsheet financial models, so I enjoyed Jaakko’s run down on how his model covers PnL report, operating expenses, payroll and revenue. Jaakko describes how you only need to spend 30 mins a month downloading reports from the Baremetrics dashboard and pasting it into Excel to keep it up to date. The post is titled an “SaaS financial model you’ll actually update”, because the value of the model is such that 30 mins of manual handle turning a month is more than justified. Now I’m the first to advocate Excel for business agility; it’s a great tool that enables sales, marketing and finance people to solve problems for themselves without the bottleneck of a software development team. But the downside of Excel is manual operation like the download and paste Jaakko spells out. Wouldn’t it be great if the Baremetrics data in the spreadsheet downloaded and updated automatically? Then the model would always be up to date, and no tedious and error prone download’n’paste operations are necessary.

So I built it by adding Baremetrics functions to my open source XLL Excel Addin SSAddin. Here’s a spreadsheet that strips Jaako’s model down to just the revenue parts of the model…

https://github.com/SpreadServe/SSAddin/blob/master/xls/flight_bare_model2.xls

It uses SSAddin functions to automatically download the revenue numbers every 10 minutes into the MRR Export sheet via the Show Summary API so the Revenue Model sheet will update every 10 minutes with the latest new customers, subscriptions, cancellations, upgrades and downgrades. All you need to do is download SSAddin 32 or 64 bit .xll binaries from here…

http://spreadserve.com/s3/downloads.html

Then install the addin in Excel and fire up the spreadsheet. Don’t forget to ensure that auto calc is on, and that you’ve got a copy of SSAddin.xll.config from the download page and put it next to SSAddin.xll on your PC. You’ll need to edit the .config to add your Baremetrics license key.

You can see flight_bare_model2.xls running online and driven by spreadserve.com data here…

http://sscalc0.online/flight_bare_model2.xls/0

http://sscalc0.online/flight_bare_model2.xls/MRR%20Export

This online spreadsheet takes automation to the ultimate level. When you run a spreadsheet model automated with SSAddin on your desktop or laptop you still have to start Excel, load the spreadsheet and hit F9 before auto updates can start. With SpreadServe hosting, you can move the spreadsheet onto a cloud server. All manual operations are eliminated, and everyone sees the same auto updating numbers in their browsers.

I’ve mentioned SSAddin on this blog before, but not given much detail about it. SSAddin is an XLL Excel addin exposing APIs for Google Analytics, Baremetrics, Quandl, Tiingo as worksheet functions. It’s distributed under a permissive Apache 2.0 license, so you can use, repurpose or redistribute however you like with no fees so long as you include license and copyright notices. You can download 32 and 64 bit .xll binaries from here: http://spreadserve.com/s3/downloads.html

Don’t forget to take a copy of SSAddin.xll.config too and put it next to SSAddin.xll on your PC. You’ll need to edit the .config to add your license keys for Google, Baremetrics, Quandl and Tiingo. There’s documentation here, but I suggest you start by playing with example spreadsheets from GitHub: https://github.com/SpreadServe/SSAddin/tree/master/xls

Don’t hesitate to ask questions in the comments here, or on the download page, or to raise an issue on GitHub.

 

Recently I’ve been using the Enron spreadsheets to test SpreadServe, simply because it’s good testing practice to expose any codebase to a high volume of diverse inputs. Felienne made them available on figshare, but they’re in a slightly obscure zip format, so I posted them on github to make them more accessible. SpreadServe posts information about the formulae used in each sheet into the spreadserve.com DB, so I did a simple analysis of Enron formula use. The results are on github here. To summarise: there are 15927 sheets, and only 8421 use formulae. 152 different functions are used across all sheets, and only 170 sheets use maths funcs that go beyond arithmetic. So the Enron spreadsheets weren’t as diverse as I’d hoped. They made for a good volume test though. Here’s a short video about exploring the Enron spreadsheets with SpreadServe…

 

The SpreadServe 0.4.2b AMI is now available in the US West Oregon region: just search for SpreadServe in public images. There’s a now YouTube video on launching a SpreadServe AMI.

Two points of interest came up in preparing the AMI: Admin password persistence, and the region bound nature of AMIs. This blog from 2013 suggests that Admin passwords don’t persist in AMIs, but I’ve found they do now. So the Administrator password for a SpreadServe 0.4.2b AMI is SpreadServe042b. If you launch your own SpreadServe instance using the AMI, then I suggest you change the password!

The SpreadServe 0.4.2b AMI is only published in the US West Oregon region. Only AMI owners can copy to another region, so if you want a SpreadServe AMI in another region you’ll need to do a simple workaround: start an image in US West Oregon, stop it and create your own image, then copy to your preferred region.

This week I’ve been testing the SpreadServe addin with Tiingo’s IEX market data. I was checking performance on my sscalc0.online AWS host for a group of SpreadServeEngines executing various test and demo spreadsheets, including one that subscribes to IEX tickers for AAPL & SPY, via Tiingo API websockets. That API gives us real time top of book as well as last trade price and size for the cash equity traded on IEX. In my test scenario I was running five engines, two of them idle, three running spreadsheets, one of which was a simple IEX market data subscriber. Using Process Explorer I saw some odd CPU spiking on the idle engines. Zooming in with Process Explorer I could see the busyness was on a thread that should have been idle, sleeping inside a WaitForSingleObject call, waiting for a signal to check its input queue. The event object waited upon was created by some generic code invoking win32’s CreateEvent and also used in another thread. Reading the docs I found that CreateEvent’s fourth param, the event object name, implies that the caller will get a handle to a previously created event object if the names match. And I was using a hardwired name! So my thread was being repeatedly woken by events from another thread. A quick fix to make the names unique produced idling engines with no unnecessary CPU burn. All very instructive, partly because running on AWS makes one very aware of paying by the CPU hour.

SpreadServe AMI part II

January 17, 2017

The core component in a SpreadServe deployment is the SpreadServeEngine, a headless C++ server binary that implements the Excel compatible calculation engine. The engine discovers its hostname through the win32 API using GetComputerNameExA( ComputerNameDnsFullyQualified, …). On AWS this was giving me hostnames like WIN-THU4IQNRN6F, when what I wanted was the fully qualified domain name, like ec2-54-186-184-85.us-west-2.compute.amazonaws.com. Harry Johnston helpfully advised on StackExchange that, since the host is not joined to a domain, GetComputerNameExA will only return the FQDN if I explicitly set it via Control Panel. Naturally I want to avoid manual fixes on a SpreadServe AMI so I settled on using Amazon’s EC2 instance metadata. The FQDN hostname can be discovered with an HTTP GET on this URL from any EC2 host: http://169.254.169.254/latest/meta-data/public-hostname. I built a small helper server process to query instance metadata using Tornado’s async HTTPClient and write it to the localFS, where SpreadServeEngine can read it. Result: any new SpreadServe AMI will automatically discover its public DNS.