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.

Advertisements

I ran into an interesting Tornado event loop gotcha last week, so I thought I’d blog the issue. At work I’m building a suite of Tornado Python based microservices to implement an FX options booking stack. The message transports in play for comms with other systems are IBM MQ series and AMPS for pubsub messaging. Naturally we use pymqi, which is a thin Python layer on top of MQ series traditional blocking
C API. Blocking APIs don’t play well with the Tornado event loop. In classic single threaded async style Tornado callbacks should complete quickly and not hog the thread, so that new incoming socket events can be seviced. So the MQ PUTs and GETs were in another thread, which used ioloop.add_callback( ) to
send work back to the main thread. For high volume queues, that means a lot of add_callback( ) invocations. And that’s the gotcha: Tornado’s main event loop dispatches pending timeouts and callbacks before looking for new socket events and dispatching to their handlers. If you have a lot of expensive pending callbacks then your code may be slow to fall through to servicing new socket events. And if those socket events are HTTP GET /health hits from your Marathon platform, then
Marathon will conclude your process is dead and bounce it. Exactly what you don’t want when there’s high traffic! In this case the fix was to make the MQ thread more selective about which incoming messages got pitched over to the other thread with add_callback( ).

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.

Last night I got a demo of a brilliantly innovative IR derivatives system from the founder team. It prompted some thoughts on the cyclical nature of the software industry, and the return of the fat client. Back in the 90s, when Microsoft still ruled the world, client server computing and the fat client were the dominant model for application development. Often the server tier was simply a DB,  and all app logic happened in a Windows app built in MFC C++ or VB. The rise of Java and the browser threatened that model, and met with a forceful response from Microsoft. That’s a well-worn story, and I won’t repeat it here. Java never delivered on its promise of zero deploy desktop OS agnostic apps; anyone remember Marimba? Instead the browser began its long march toward becoming the dominant desktop client. After the dot com bust it took time for web 2.0 to emerge. For a while there was a debate about Silverlight vs Flex vs Ajax. Thankfully Ajax – the only one not aligned with a major vendor – won out, despite myriad incompatibilities between browsers and unsatisfactory server push mechanisms. Websockets and HTML5 resolved those issues, setting the scene for thin client zero deploy nirvana. Or so it seemed.

Concurrently with these technical developments on the desktop we’ve seen the rise of SaaS. The advance of the browser as client enabled ISVs, starting with SalesForce, to bypass corporate IT departments and server rooms, and deliver apps direct to users, often with UI quality approaching consumer products, and very low entry prices. Now there’s no end of CRM, budgeting and financial management, project management and industry specific vertical solutions delivered direct from cloud hosting to user desktops. Each browser delivered SaaS may be cheap and compelling, but they exclude the possibility of integration and data sharing across apps. Unless the business users buying those SaaS apps gets their IT department involved again to build integrations across the SaaS REST APIs. But that ain’t gonna happen, because the users bought into the SaaS apps to free themselves from the dysfunctional IT depts in the first place, and because of that the IT depts hate the SaaS apps in the same way they hate Excel.

So how does the integration problem get solved? On the desktop of course! We’re now seeing the re-emergence of 90s style app to app interop on the desktop. This time the enabler is not Microsoft’s OLE (Object Linking and Embedding), but proprietary extensions to the HTML5 container. OpenFin’s Chromium based HTML5 container supports drag and drop between apps, and also provides a pubsub bus. DDE anybody? This trend is writ large with the startup’s IRD options pricing solution, which addresses the financial sector’s rates options trading niche in a fiendishly clever manner. Anyone who’s ever stepped on a trading floor knows about the ubiquity of the Bloomberg terminal. Bloomberg’s terminal comes with desktop interop; their Excel addin enables live ticking market data in spreadsheets. APIs do the same for desktop apps, but license terms mean that data can only be used by apps running on the same desktop. That precludes publishing Bloomberg market data to the server side pricing systems typical in the bigger hedge funds and banks. So this startup’s master stroke is to deliver IRD options pricing in a browser client, as an SaaS, and driven by Bloomberg market data. The analytics – the number crunching special source – are coded in JavaScript and run in the browser. Truly a browser based fat client offering a unique solution enabled by desktop integration.

We’re going to see more and more of this kind of SaaS delivered HTML5 fat client adding value with smart desktop integrations. Proprietary extensions like those in OpenFin, or the startup’s Bloomberg integration, will multiply. Proprietary extensions will inevitably clash, and the benefits of zero touch deployment to a standardised HTML5 browser client will be dissipated. It’s all yet another instance of the endlessly repeating cycle in our industry: standards consolidate, and competition differentiates. Standards are introduced to ameliorate the pain of incompatibility, then vendors differentiate with proprietary extensions until the level of incompatibility becomes too painful and the cycle repeats. Intelligent market participants should think hard about where we are in the cycle, and how to get ahead of it. But not too far ahead of course!

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.