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.
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!
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.
Well…I might be a little “tricksy” in that announcement, since it might not be exactly what you think. No, I haven’t yet ported the solution to Swift. (After playing with a few projects pulled from Github, I noticed how different Objective-C and Swift are from the state of iOS development 5 years ago. Seems like there might be a little bit of a learning curve there.)
However, the good news from Microsoft with .NET Core keeps coming. So, on top of delivering the port to Linux, they released the preview of Visual Studio for Mac only a few weeks ago. And the reaction seems to be generally positive! Now, all Mac-centric companies that deal with book data can make use of my ONIX Data Library. We just welcomed another 7 people to the fold!
The ONIX standard…huh? Am I right? What…you’ve never heard of it?!?
Yeah, well…I guess that makes sense. However, if you’ve worked on any project regarding the publishing industry, then there’s a good chance that you have heard of it. Basically, it’s the international standard for representing electronic data regarding books (along with other select media formats). Titles, prices, commentaries…most of that data is passed between companies in the ONIX format. It can be frustrating to work with at times…but work with it you must.
Strangely, though, there aren’t many tools or libraries out there which focus on it. Now, you might be saying, “Of course there are no libraries or tools out there…there are more people that you use Sanskrit than use this standard.” Well…that might be true; I’m not sure. However, there are enough people out there (including developers) who work with it; there should be something out there to help us brave few. And when I found nearly nothing for the .NET platform, I decided to make one of my own.
It was a little awkward at first during development, since I found a few platform issues regarding XML in my adventures. However, after a few weeks of work, I finally had something substantial. So, I am proud to introduce the world’s first open-source serialization/parser library for ONIX in C#, complete with a few pretty ribbons attached! It’s bound to be of some use to somebody…all 5 people who happen to use both ONIX and the .NET platform. Everyone else may say “blah”, but those scant few are going to be ecstatic. We’re going to throw a pizza party just for us, and everybody else is going to be soooo jealous.
Over a year ago, I published an article that proposed the possibility of creating a system that could be configured to systematically download snapshots of records via a data API, catalog them for auditing purposes, and then apply that data to relational tables used in production. At the time, there was only the article about the subject matter, but there wasn’t a working example to accompany it. In order to further demonstrate the feasibility of the article’s proposal, I decided to go ahead and remedy that particular dearth.
So, after taking a few minutes out of each day to incrementally build the project, I think that the project has come along well enough to be let loose upon the world. I’ve uploaded the project to GitHub, so that it may endure for posterity. For the purpose of inspiration or amusement through ridicule, only time will tell. 🙂
Years ago, I dabbled with the idea of developing a platform that would present trivia about literature to interested bibliophiles, like which popular songs were inspired by famous books. Specifically, I thought that it would make an entertaining mobile app. (At around the same time and unknown to me until much later, a company called Small Demons had a similar idea and a much better implementation in the form of a robust web site. Unfortunately for them and for me, though, the general idea never found a core demographic.) After creating an iOS version, I decided to target something more appropriate, and I chose an eBook platform that I was fairly familiar with: the Nook. Taking some lessons from creating my first version of it and teaching myself the Android platform, I was able to create a much more user-friendly implementation for our Nook store (though obviously still novice). It didn’t exactly turn me into a millionaire, but I was still proud of it nonetheless.
A few weeks ago, I happened to stumble on the original source code, and I decided that it was time to find it a good home, somewhere other than my old hard drive. I’ll admit that it wasn’t designed all that well, but since this was also my first real Android project, I’m inclined to forgive myself. I’ve uploaded the project to GitHub, so that it may endure for posterity. For the purpose of inspiration or amusement through ridicule, only time will tell. 🙂