Category Archives: C#

And While I’m Asking For Things

Speaking of requests, I have another quick one. My department has used the Oracle.ManagedDataAccess.dll for quite a while now in our C# (i.e., .NET) deployments, and even though we’ve had some performance issues at times, we’ve created some workarounds and eventually achieved harmony with this miscreant spawn of Oracle (who has been known to be developer-unfriendly). However, we came across a new one the other day:

Value cannot be null.
Parameter name: byteArray
Server stack trace:
at System.BitConverter.ToString(Byte[] value, Int32 startIndex, Int32 length)
at OracleInternal.TTC.TTCLob.GetLobIdString(Byte[] lobLocator)
at OracleInternal.ServiceObjects.OracleDataReaderImpl.CollectTempLOBsToBeFreed(Int32 rowNumber)
at Oracle.ManagedDataAccess.Client.OracleDataReader.ProcessAnyTempLOBs(Int32 rowNumber)
at Oracle.ManagedDataAccess.Client.OracleDataReader.Read()

Basically, if you have a null value in the CLOB column of an Oracle table, you might get this error when you attempt to access that row in the result set. After trying the most recent version of the library (as recommended by Oracle), it became obvious that they still haven’t fixed it. Strangely, the error seems to occur randomly, since it won’t always happen when running the executable against the same data. After spending some time in an effort to diagnose the error, I eventually capitulated, accepted Oracle’s foibles, and simply set all CLOB columns to EMPTY_CLOB(). Problem solved.

But for posterity and all those after me, I implore you, Oracle: can you address this simple problem in your library? I’d ask you to open-source that library, but we all know that’s not gonna happen. So, please go ahead and fix the bug for us. It’d probably take you a whole 15 minutes, the same amount of time that Ellison needs to check the rigging on one of his catamarans. We’d all appreciate it!

Advertisements

.NET and XML: Mortal Enemies

In the past, I’ve had my issues when dealing with the compatibility between C# and XML, so much so that I’ve been inspired to write prose. At this point, I feel that it’s my duty for posterity to document the various instances where Microsoft drops the proverbial XML ball:

  1. As stated before, DTD validation of XML files (with the C# XmlReader) is broken. And when I say broken, I mean that it performs as well as a thirty-year-old VCR pulled from the ocean and then placed in a vat of hydrochloric acid. Now plug that VCR in. You’re going to get the same results.
  2. If you’re hoping to create a XSD from available XML or classes with the Visual Studio Tool (i.e., XSDT), good luck. For one, it doesn’t allow you to specify any complex rules. Also, if you’re generating a XSD schema from classes, you should know that it doesn’t work with Nullable types or any Dictionary properties, since they couldn’t budget it into their schedule.
  3. “Hey, I have a container that’s set to null. So I’ll tell C# not to mention that tag at all upon serialization, since it’s just wasted space and since I might not want that tag visible in certain cases.” It is possible…but under specific circumstances. If you plan on serializing your class as is and if you plan on not using any C# attributes on your properties, maybe. Otherwise? Nope. C# says “No soup for you!”
  4. If you want to serialize an array of strings, you get a free bonus upon serialization: all of the tags will be prefixed with a namespace (i.e., the namespace for array serialization). If you don’t want that ugly prefix, just create a wrapper container for a string array. Now do this for every literal type you can think of.
  5. Let’s say that you have a XML doc with a string that is a HTTP link. You now want to parse that XML and read that value. Of course, if that link contains a query string, all of those ampersands are already converted into instances of “&“, in order to be compatible with XML standards. “But I want my data to be read incorrectly!” Well, you’re just in luck, friend! Because when you use XmlDocument.Load() to deserialize that XML, that query string will contain “amp;” and not “&“, essentially turning the link into garbage. Huzzah!

These are only a few instances, but there’s more. (Don’t even get me started on deserializing payloads from a ASP.NET web service.) If anyone out there has their own experiences to add, I’d love to hear them.

You Might Be Doing Too Much at Once, Microsoft

WARNING: This post is a commentary. If you’re looking for anything technically insightful, you might be disappointed.

Out of curiosity, I attended an Azure training event a few days ago with a group of colleagues at Microsoft’s Reactor in NYC. Though I’ve played with Azure a few times, I could definitely use more insight. (Since it’s been ages I’ve been to a training event, I also wondered if I was missing out on anything. I’ll admit that the food has gotten better.) Before I start, I commend Microsoft for having made leaps and strides in various respects, particularly with Linux and open source. Also, I should commend the staff who conducted the event. They were very helpful and considerate, and I can only imagine the difficulty in a situation where you are dealing with a room full of disgruntled developers. So, they performed well despite given constraints. Now, the actual event on other hand…that’s a different story. In many ways, it reminded me of my general impression of Microsoft these days: sometimes getting a little too ahead of themselves.

So, the general idea was a good one, introducing people to Azure using a hypothetically fun scenario. In this case, the scenario depicted was one where you help save astronauts on Mars, all through a series of printed-out “classified” tutorials on contemporary topics (IoT, serverless computing, etc.). Okay, decent concept. But the devil is in the details…First, the event space didn’t have enough bandwidth to accommodate the laptops of several dozen people. (As soon as I saw that there were no LAN jacks and that it was WiFi-only, I knew that we were in trouble. It’s common knowledge that between Windows updates and NuGet packages for project builds, you’re gonna need plenty of bandwidth.) Second, the presented materials were sometimes confusing (hyperlinks on printed paper, etc.) and were loosely tied to the general theme. For example, one exercise had us utilizing their face recognition API, which is separate from Azure for some reason. Exactly how this helps stranded astronauts and why we were using pictures of college students, I couldn’t tell you. Finally, the tutorials themselves were simple exercises of copying code and hitting menu options in order to showcase certain technological features.

However, there was no tutorial that gave a general idea of what Azure is really about: being a cloud platform. The basic framework was ignored (spinning up a VM instance, loading a new database, etc.) in order to tout its more niche features. Personally, though, I think that the goal of the marketing team should have been more practical and focused when planning this event. For example, use a theme of a skunkworks team within a larger organization. How could such a team leverage Azure to become innovative? In other words, provide inspiration and ammunition to your base of enterprise users that doesn’t currently use the cloud yet. Though I understand the marketing team’s goal: to appeal to both enterprise AND startup customers for Azure. Obviously, management has envisioned that as the strategy to overtake AWS.

Which, obviously, I think might be a mistake. For example, how many people with Arduinos and Raspberry Pis are looking to create IoT products with .NET Core? True, I’m not an expert, but after spending a few minutes with it, I still can’t see it winning too many hearts and minds. Instead of spreading their resources too thin, it might be beneficial to double-down on their bread and butter, especially since there’s already so much competition in other verticals. After all, there are plenty of enterprise customers to still win over. In fact, I can think of one or two opportunities in niche spaces that are hidden among enterprise users. I know that I don’t have the mile-high vantage point, so I’m not privy to certain details…but since I’m leery of wobbly ladders, I tend to prefer low-hanging fruit. 🙂

Oh Well, I Guess that It’s TTJT (Time to Join Them) with IFTTT

Well, I was patient, and I waited a year to see how Xamarin would integrate with Office 365. I was hoping for some new libraries and some new tutorials, so that I could eventually build that killer enterprise Xamarin app. Honestly, it would be nice to have a METAmessage for Android, which could offer the ability to customize the alerting functionality on your phone…but, alas, it seems that I’ll asphyxiate myself if I keep holding my breath.

So, I capitulated and just reverted to using IFTTT, so that it’ll just call me in specific cases. It’s not the ideal alert system, but it’s better than nothing. (Though I will admit that it’s fun to hear the automated voice of IFTTT as it reads my ridiculous excuse of an alert.)

Quick Tangent: Dumb Bots

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.