I know that both Microsoft and Richard Stallman have gotten a little older and a little wiser…but I certainly never expected a meeting of these two minds.
Plus, there’s another addition to the family. In order to demonstrate its abilities when integrated into web services, there’s also now the new project WonkaRestService, a ASP.NET REST service that showcases how to use the Wonka library. Perhaps, one day, it might even become an Azure Logic App Connector. I know, it’s a lofty goal…but let a kid dream.
Most of the time in tech, you can stand on the shoulders of giants and reuse great works to your benefit, whether those things be algorithms or engineering methods. But, sometimes, as you venture towards the edge, you realize that you’re now somewhere completely different. You find yourself floating in some unknown ether, and you need to reorient yourself to this new dimension. And the more I play with the Ethereum platform, the more I find myself in that position.
For example, when I first started to create the Wonka rules engine, I had a few plans in mind, with one being to possibly use the Rete algorithm within the project. After all, it provides an efficient solution for a dynamic situation. Specifically, this dynamic situation could be one where a rule at the end might change the data, and then the whole set of data would need to be reevaluated by the rules due to that change. In this case, the Rete algorithm provides a performant method for this possibly recursive set of reevaluations. But that’s in the normal world, not the Ethereum one.
Within most standard computing, there’s minimal cost to using a system’s resources. At worst, you’re paying a cloud provider for cycles; in order to run a limited set of rules, you’re still talking pennies. But in a blockchain environment like Ethereum, where you have a massively distributed database of decentralized shared resources, every execution is an expensively coordinated effort. In order to change the state of the system, the cryptocurrency of the system, Ether, is used to cover the cost of a transaction, which is described as the ‘gas’. And even though the market value for Ether keeps sliding down, it still means that every rule that changes the system is another line item on your ‘gas’ bill. That’s difficult to predetermine since it’s always based on context. Yes, you can run your own private Ethereum blockchain within your own network (instead of the mainnet), and that means you’re not paying real Ether at all…but, in the end, people using blockchains generally still want accurate measures of impending execution.
Which brings us to the ultimate question for anyone using a rules engine within a blockchain like Ethereum: how much is this damn thing gonna cost me to run? Since the answer could be “a lot”, we have to abandon our beautiful, time-proven algorithms and go back to the drawing board. Which is why when you’re dealing with nascent platforms, you have to go back to KISS (i.e., Keep It Simple, Stupid). So, in this MVP version of a rules engine, I did just that, creating a straightforward implementation that just gets the job done. In this current state, its destiny will more than likely be as unwept, unhonored, and unsung. However, at the very least, such a prototype can be used by others to evaluate and perhaps validate the existence of a rules engine in this new space. And, maybe, just maybe, it can serve as the first iteration of something that will eventually become worthy of note.
On a side note, it turns out that getting a ticket to DevCon is a lot harder than I thought.
Never mind the fact that it drools a little bit. As Marty Feldman might say, we’ll just refer to it as “Abby Normal”.
In any case, since the rules engine had been written in Solidity contracts for deployment to an Ethereum node, I had already considered superimposing a managed language layer on top. That way, a developer could utilize this rules engine within Ethereum without having to know Solidity. And since I’ve been working with C# for decades now, wouldn’t this project fit perfectly under the umbrella of Nethereum, using its very framework to be the essential link? Excited, I contacted Mr. Blanco with that very idea, and he was gracious enough to agree and kind enough to accept my proposal. Planted under the protective aegis of Nethereum, the project has sprouted and blossomed into its first healthy iteration. Behold, the Wonka engine! It’s a rules engine that can exist in both a .NET instance and an Ethereum network, and using a proprietary markup, you can write business rules that are assembled in .NET, passed into the Ethereum node, and then executed within the blockchain. Of course, that’s an incredibly brief synopsis of all the functionality, and there’s a great deal to explain…but, for now, I just wanted to make introductions. You’ll get to know more about it later!
For now, though, I’m concentrating on getting a ticket for DevCon 4 in Prague, which has been way more difficult than expected. Hopefully, I can get one in the third wave. The tension is building!
Since I’m in the process of porting our MDD framework to Red Hat Linux, I was curious about the various new tools available to me. (It also feels good to get dirty with another environment again, especially an old friend like Linux. It’s refreshing.) I found some interesting new packages, including OpenShift (which could be useful if we decide to consolidate applications to only a few servers.) However, personally, the most interesting package was something that I’ve been seeking for a while. Behold MatterMost!
A couple months ago, I had complained that bots weren’t generally useful. However, I had found one useful scenario for myself, if only a given platform would support it. Basically, I’d like an interactive bot that could give me status information about my distributed system (currently running processes on multiple machines, database row contents, etc.), all through a secure messaging client on my phone. And apparently, MatterMost is just that platform! According to the site, I can install the software onto RHEL, run my own messaging service (with native mobile clients), and then integrate bots into that running instance of the service. And at a fairly modest price…Now I just need to get the brass to sign off on it, in terms of both budget and network integration. It’s a long shot, but at least it’s now a distinct possibility.
So, there’s been so much talk about AI lately, and in particular, there’s a great deal of interest in bots. No, not the Mirai kind (which hopefully isn’t plentiful in the future, despite its Japanese translation). No, I’m talking about the friendly, enterprise kind. You know, the chatbots on Facebook that are supposed to be helpful snippets of AI, capable of booking hotel rooms for you. Of course, I don’t really understand the usefulness of these bots, since there’s no way that a bot could help me find the ideal room faster than my own investigation. In fact, they seem kinda…well…dumb. But these bots are probably not aimed at a self-appointed pariah of social media like myself. Instead, it’s probably meant for those people who are younger (i.e., millenials) and who are more predictable (troves of available marketing data via Facebook, less variety of purchases, etc.). In that case, I suppose that it’s useful for some but not for myself…or is it?
Similar to my reaction to chatbots, I never quite understood the newfound love for Slack. It’s a messenger app…so what? However, as I started to delve more into it, I started to understand its appeal through its extensible functionality, especially to developers. I can create a simple bot (or a basic web service) on my public-facing servers, so I can use Slack to talk with it on my phone and get the status of machines and processes? Okay…that’s kinda cool. (Assuming that your company and networking department embraces the idea of allocating machines just for this purpose. Trust me, I know…that can be a hard sell.) So, maybe, must maybe, I could be down with these chatbots. That way I could use Slack (or Skype) and be hip like the cool kids!
Hmmm…so how I could I actually pitch this one to the brass? Curious, I looked to see if there was already an enterprise version of such a solution, and though I did find one or two, they seemed to be costly and less flexible than desired. So why not just build one cheaply on my own? Since I recently read something about Microsoft’s nascent bot framework and its integration with Skype, I figured that I could start there as a quick way to prototype. After proceeding through a few quick tutorials, it became obvious that a chatbot is nothing more than a tailored RESTful web service, and with that realization, I quickly assembled and got working the prototype that I had in mind.
However, over the next few weeks, I started to realize that it wasn’t viable. One, since this framework is too young to even stand on its own wobbly legs, Microsoft keeps updating the framework and breaking my stable prototypes. As with previous experiences when dealing with a Microsoft gestation, I wondered again if Redmond’s new projects (along with their frenetic and seemingly bipolar updates) are victims of Conway’s Law…Two, I read about how Skype does not and will not support third-party bots that are not publicly registered in their Bot Directory. I’m fairly sure nearly all of the company brass would have a problem with a publicly available chatbot that tells the status of our internal servers. Just a hunch.
After taking a quick look at other platforms, I came away with similar impressions. In the end, I’d say that chatbots are like a lot of new tech these days: lots of potential but some distance away from ultimately being practical.
While reading Slashdot news the other day (I know, I know…all the cool kids read Hacker News), I stumbled upon some news about RethinkDB that didn’t seem all that relevant to me at first. However, upon reading some of RethinkDB’s documentation, I realized that such a database might be another useful tool in a MDD-constructed engine for XML schema evolution. From time to time, I still think about an engine capable of enabling complex translations between different versions of a XML schema; essentially, this engine would generate and then use XSLT files based on the metadata inside certain database tables. If we put this metadata inside tables of a RethinkDB database, RethinkDB’s functionality of posting messages to a queue (when a table’s structure or data has been changed) would be a neat way to trigger the rebuild of these XSLT files!