Category: programming

more JavaScript and TypeScript shenanigans

I’m still working on my fairly ridiculous JavaScript/TypeScript/SharePoint project, which I’ve mentioned previously. I’ve got the Q (promises) stuff all worked out now, I think.

I wanted to be able to read in a standard Microsoft Excel file as part of this project. To handle that, I looked at SheetJS. This looked like it would be pretty straightforward. But I hit a few issues in trying to integrate it into my project. There was a TypeScript definition file for it available via NuGet in Visual Studio. But the way the file was written led me down a rabbit hole of trying to figure out JavaScript modularization standards. This probably isn’t that tough a subject to figure out. I got as far as figuring that I should be using AMD and RequireJS. But, after about 20 minutes of reading RequireJS documentation and some related articles about how to use it in TypeScript, I decided that maybe I was better off skipping the whole thing and sticking with a CSV input instead of Excel.

I assumed I’d be able to read and parse a CSV file pretty easily, with the native JavaScript FileReader and some simple string operations to break up the lines into fields. But figuring out how to parse a CSV file sent me down a rabbit hole too. But it wasn’t a terribly deep rabbit hole. The end result is that I’m using a little library called Papa Parse to deal with the CSV parsing. (It turns out that the kind of CSV files I have will be a little too complex for “string.split(‘,’)”.)

Despite all the little issues, I’m learning a lot on this project. Maybe, most importantly, I’m learning about how far JavaScript development has come since the last time I did any major JS work. I need to do some catch-up work. Time for some more PluralSight videos.

Promised You a Miracle

I’m still working on the JavaScript project that I mentioned last week. I think I’ve nearly got promises figured out now. I’ve switched from using jQuery’s promises to using Q. I’m definitely doing enough weird stuff that the jQuery promise support was never going to work for me.

The documentation for Q isn’t bad. There’s a page on moving to Q from jQuery, and that was helpful, as is the API reference page.

This blog post on promise anti-patterns helped me figure out how to handle collections of promises. Q.all() and Q.allSettled() are very useful, once you figure them out. I get the feeling that, while my code works, I’ve probably still got a lot of anti-patterns in there, or at least some fairly sub-optimal constructions.

While working on this stuff, I found that the old Simple Minds song, Promised You A Miracle, started running through my head. I was really hooked on Simple Minds for a while there, back in the early eighties. I hadn’t listened to them or even really thought about them in years, so I’m enjoying a little nostalgia now, via YouTube. (Eighties music videos do look pretty cheesy now, though, huh?) Here’s a new version of the song, an acoustic version with KT Tunstall. It’s not bad.

JavaScript, TypeScript, Promises, and callback hell

I’m working on a little project right now, where I’m pushing at the edges of my limited JavaScript skills. I’ve written a fair amount of JavaScript code in the past, but it’s mostly been simple DOM manipulation stuff with jQuery, and/or fairly straightforward Ajax calls. This new project requires a lot of nested calls to async functions that might succeed or might fail, and the whole thing is getting pretty confusing. Luckily, it’s not a high-priority project, so I’ve got time to mess around and try new things with it.

To start with, I’ve switched from plain JavaScript to TypeScript. There’s only a little bit of a learning curve there, since TypeScript is a superset of JavaScript. And I’m picking up TypeScript as I go. I’ve got one Packt ebook: Learning TypeScript, which was their free ebook of the day recently. It’s a bit out of date, but it’s a good start. I’ve bookmarked a couple of PluralSight videos on TypeScript too, but haven’t had time to watch them. I don’t like to add a new language into the mix for a real work project without careful consideration, but TypeScript seems to be relatively low-risk. It’s got some momentum right now, it’s got Microsoft behind it, and if it fails, I can always throw out the .ts files, work from the generated .js files, and pretend TypeScript never happened. (Not that I think that’s at all likely.)

I’ve found myself falling into “callback hell” on this project, so this video called “Redemption from Callback Hell” caught my attention. I’d already discovered promises, but I’ve been using the jQuery implementation, which apparently isn’t a great one. I guess I need to look into Q and the Promises/A+ spec. I’ve read a number of blog posts and articles about promises, but I’m still having some issues with figuring out how to handle some stuff with them.

I’m trying to avoid going down too many rabbit holes on this project, but going down a few is unavoidable. One of the reasons I was using jQuery promises is that I already had jQuery in the project and didn’t want to add another library. But I guess I’ll have to consider at least one more.

programming books and videos

We’re snowed in today here in my part of NJ, so today’s probably a good day to review and clean up some of the “independent study” stuff I’ve been working on over the last several months.

First, I decided to finally finish up a book that I started reading about a year ago, Real-World Functional Programming. I’d been reading it a little bit at a time for quite a while. I started in on a program to learn F# back in 2014. I read a few books, and learned a bit, but I never really got a chance to apply any of that knowledge on a practical project. So I skimmed through the last couple of chapters of that book today, marked it as “read” in Goodreads, and decided that my F# experiment is over for now.

I started (and finished) reading a book on JavaScript this week, Object-Oriented JavaScript. I’m doing a bit of JavaScript programming at work right now, but I’m rusty, since I haven’t used it much lately. I got this book for free at some point from Packt, so I thought maybe it would be a good way to brush up and refresh my memory. It was a good refresher, and even had some stuff in it that I hadn’t stumbled across before.

On the video front, I’m still working my way through SharePoint videos on Pluralsight. I’ve completed Andrew Connell’s “SharePoint 2013 Developer Ramp-Up” series, and Sahil Malik’s “Understanding SharePoint 2013” series. Now I’m working on David Mann’s “Developing SharePoint 2013 Solutions with JavaScript,” which is helping me out with the SharePoint/JavaScript stuff that I’m currently working on. When I paid for a year’s worth of Pluralsight, I wasn’t sure if I’d get my money’s worth out of it, but I think I’ve been making good use of it so far this year.

I’ve also now been sidetracked into messing around with TypeScript. I read a book on CoffeeScript a few years back, but CoffeeScript never really took off (at least in the .NET community), while TypeScript seems to be very popular right now. (Take a look at this Google Trends graph.) So I’ve been experimenting with using TypeScript and JSOM together in a SharePoint project. I’m not sure if it’s worth the effort, but it’s interesting. I haven’t devoted too much time to TypeScript yet, but I’ll probably watch a Pluralsight video or two on it and see if I can persuade myself into using it.

Finally, I feel like I should get back to Ruby on Rails at some point. I started learning Ruby back in 2015, and learned the basics (of both the Ruby language and the Rails framework) but really didn’t get as far as I wanted. I got partway through Michael Hartl’s book/tutorial, but I guess I got off track at some point, since I haven’t touched it since June 2015. As with F#, I never had any real project in mind, or work-related reason to learn Ruby, so I probably abandoned it in favor of something else I needed to learn.

So I guess I’ve got some goals for the rest of 2017: keep working on SharePoint, brush up on my JavaScript some more, look into TypeScript more deeply, and maybe get back to Ruby on Rails, if I have time.

WordPress syntax highlighting

I occasionally post code here, and I’ve never been entirely satisfied with the various ways that one can post nicely-formatted code on a blog. This blog has been around for so long that I’ve gone through several approaches. Recently, I’ve been putting all my code snippets in Github Gists, and then embedding those Gists here.

That looks pretty good, and works pretty well, but I’ve discovered a couple of downsides to that method. First, the code itself is not actually in my posts, so it doesn’t show up in searches, either here at the blog or (presumably) in Google or other search engines. I realized this a while back when I tried to search for a past post, using a bit of code that I knew was in the post. When I didn’t find it, I realized that of course the code wasn’t in the post, it was only out on Github. So I wanted to fix that, and get the code itself into my post database.

Second, the company I work for has started blocking the Gist site. I’m not sure why, but I guess maybe it’s occasionally used to post malicious code? Regardless, it’s a problem, since I sometimes want to bring up an old post of mine at work to remind myself of how I solved a problem in the past. When I do that now, the post is visible but the embedded gist is missing. And if my company is blocking gists, other companies are probably doing it too, so other people looking at my blog might be confused when they see a post with missing code.

So there are some good reasons to include actual code in my posts, rather than relying on Github. I could go back to just wrapping the code in <pre> and/or <code> tags, but I wanted to have something that would look at least as good as the embedded gists. So I started looking at syntax-highlighting plugins for WordPress.

I looked at Enlighter and WP-Syntax. Enlighter looks pretty cool, but I decided to go with WP-Syntax in the end. It uses GeSHI, which I’ve used before (in Drupal), and supports a lot of languages, including X++, which is a pretty obscure language. I installed it about a week ago. Today, I decided to spend a little time editing some of my old posts to move code from gists to WP-Syntax. It worked out pretty well. (And I’m still linking to the gists, so if the code gets scrambled, it’ll still be there on Github.)

To some extent, I guess this is just pointless busywork. My old posts don’t really get a lot of hits, and I really don’t refer back to them that often. But it was a nice little way to spend an hour on a cold Sunday afternoon, and it gave me a sense of accomplishment.

Getting master page URL in SharePoint 2013 with JSOM

I’m only just starting to learn JSOM (after previously learning the server-side object model, and CSOM, via C#). There are some slightly weird requirements and limitations that are constantly tripping me up. Here’s today’s waste of time: trying to get the current site’s master page URL.

Here’s what I came up with:

$(document).ready(function () {
            $('#divMain').text('Hello World.');
            getMasterUrl();
        });
        function getMasterUrl() {
            var myCtx = new SP.ClientContext();
            this.site = myCtx.get_site();
            this.web = myCtx.get_web();
            myCtx.load(web);
            myCtx.executeQueryAsync(
                Function.createDelegate(this, this.onSucceededMasterUrl),
                Function.createDelegate(this, this.onFailed)
                );
        }

        function onSucceededMasterUrl() {
            $('#divMain').text('Master URL: ' + web.get_masterUrl());
        }
        function onFailed(sender, args) {
            $('#divMain').text('Failed: ' + args.get_message());
        }

This just kept failing. I tried a bunch of random stuff to get it to work. In the end, I made a fairly minor change that got it to work. But then, I changed the code back, and it still worked. So this was going to be a post about a minor quirk of JSOM, but now it’s more of a “WTF” post. I’m sure I did something to make it work, and I just lost track of what it was. Well, either way, I’m having some fun with JavaScript.

SharePoint: plain text, rich text, AutoHyperlinking, and Markdown

I’m just about finished with the SharePoint project that I’ve been working on for the last few months. One requirement for the project was to allow arbitrary “comments” on the main documents for the project. There are some built-in ways to accommodate comments in SharePoint, but I gave up on those after experimenting a bit. Instead, I created a new list that would act as a child table to my main list, in a simple one-to-many relationship. And I decided to use plain text (rather than rich text) for the comment field itself.

I’ve had problems with SharePoint rich text fields in the past, and I wanted to put some constraints on the users, so they wouldn’t go nuts with the vast array of bad things rich text fields in SharePoint let you do. And I didn’t see any reason why plain text wouldn’t be “good enough” for this particular case. However, for this application, a lot of URLs and email addresses are going to get posted in comments, and I wanted to be able to “linkify” them. I almost wrote my own code for that, but then found the SPUtility.AutoHyperlinking method. It works pretty well, and also translates quotes, angle brackets, and other possibly confusing characters into their corresponding HTML entity codes.

I also got a little interested in the idea of supporting some limited formatting (like bold, italic, etc.) without going full-on rich text. My first thought on that was to look into the SharePoint wiki functionality. I was hoping for a function like SPUtility.AutoHyperlinking, but which would convert some simple wiki markup into HTML. But SharePoint’s wiki capabilities are limited, and really only support links.

So I then gave Markdown some thought. There’s obviously no built-in support for Markdown in SharePoint, but I figured that I could find a .NET library that would let me handle the MD to HTML conversion on the back-end. There are, indeed, several libraries available for Markdown conversion. I found two that stood out as probably the best, for my use:

  • CommonMark.NET is a pretty popular one that’s been around for a while.
  • Markdig looks like it’s probably newer and slightly less popular than CommonMark.NET, but it has some interesting extensions, including an auto-linking extension that would have been useful for me.

In the end, I decided that it was pretty unlikely that the user base for this project would embrace anything as nerdy as Markdown, so I didn’t bother adding it to the project. But I had some fun messing around with it.

And I should mention that I figured out, at some point, that SharePoint 2013 supports two levels of rich-text: one that is the “full” rich text mode, allowing pretty much anything and everything, and one that is limited to a pretty reasonable subset (bold, italic, text alignment, links, and stuff like that). In retrospect, I probably should have gone with the limited rich-text, though even that might have caused unexpected issues. (I have learned to trust SharePoint only as far as I can throw the server on which it’s running…)

C# source code analysis

Something came up at work today that got me thinking about source code analysis tools. Since I’m currently working on two C# projects, both of which are close to done and working reasonably well, I decided that maybe it would be cool to try running some source code analysis tools against them and see if there was anything I could clean up.

I started with something fairly simple: StyleCop. I installed the Visual Studio extension for it, ran it and went through the results. It found a ton of stuff, much of which I didn’t entirely agree with. But it did find quite a few things that made sense to me, so I cleaned them all up. With the VS extension, StyleCop only identifies issues; it doesn’t do any automated fixes. And it’s not doing any deep analysis; it’s just finding stuff like issues with naming conventions, missing comment headers, too much or too little whitespace, and similar style issues. But I’m a sucker for that stuff, and I like my code to be consistent with accepted conventions (for the most part).

I also looked at CodeMaid, which looks like it does a lot of stuff that’s similar to StyleCop, but it also automates fixing the issues. I didn’t get around to trying it, but I’d like to play with it when I get a chance. It’s open source, so I can try it without having to worry about spending any money.

I’ve been aware of some of the fancier commercial tools for a long time. Specifically, ReSharper and CodeRush. I’m curious about them, but they’re both too expensive for me to really justify. If I ever find myself in a job where I’m doing a lot more C# work than I’m doing now, and I have a budget to work with, I’ll try one of those.

Fun with TLS 1.2

At work, I’ve somehow wound up being the “credit card expert” in my group. I don’t mind, really, since the work is reasonably interesting, most of the time. I had occasion to go down a bit of a rabbit hole this week that I thought might make for a good blog post.

PayPal, starting in mid-2017, is going to require that all communication with their APIs happen via TLS 1.2 and HTTP/1.1. TLS 1.1, at minimum, is a PCI requirement, so I’m sure that’s what motivated PayPal to make these changes. (Further info on the PCI requirement can be found here and here.)

I’ve been working on a project that uses PayPal’s Payflow Pro API. There is a .NET library for this API that hasn’t been updated by PayPal in years, but (for various reasons) it’s the only one we can use right now. So PayPal is requiring TLS 1.2, but apparently not updating this library accordingly or really offering any guidance about using it. So it’s been up to me to research this and figure out if we’re in trouble or not.

The library itself is offered as a DLL only. PayPal has been posting a lot of their source code to GitHub lately, but this particular API is only downloadable in binary format. It’s a non-obfuscated .Net DLL, though, so I’ve been able to poke around inside of it with JetBrains dotPeek. I can see that they’re using the standard HttpWebRequest class in the .NET Framework, so that’s a good start.

I also tried looking at the actual calls being made from this DLL, using Fiddler, but I had some problems with that. I thought about trying Wireshark instead, but it looks like I won’t have to bother with that.

Looking at several Stack Overflow questions led me to add the following line to my code, prior to calling the PayPal API:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

And I found a web site that has a simple API that can give you an indication of your SSL/TLS status. So I plugged in some calls to this API (using simple HttpWebRequest calls), and I think that the above line does, indeed, fix things for me.

Here’s some sample code to call that API (which I found here):

//ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
var response = WebRequest.Create("https://www.howsmyssl.com/a/check").GetResponse();
var responseData = new StreamReader(response.GetResponseStream()).ReadToEnd();
Console.WriteLine(responseData);

The API returns a block of JSON, which I’m just dumping to the console here, but you could also use JSON.NET and do something fancy with it.

PayPal is going to change their “pilot” endpoint over to support only TLS 1.2 in mid-February. So, at that time, I can run some tests and see if my guesswork holds up, or if there’s something I missed. I won’t be at all surprised if I do run into a “gotcha” or three. My understanding of this stuff is really not that deep, and who knows if PayPal is going to do something weird in their server implementation that breaks my code.

SharePoint – fun with fonts

I hit another weird little problem on my SharePoint project today. This one’s a bit different from the previous ones I’ve blogged about recently. A key point to start: I’m developing my solution on a VM running Windows Server 2012 R2. But the end-users are all using Windows 7.

I have one big detail page for this  project that’s got a lot of information on it. It’s a regular Web Forms ASP.NET page, in a SharePoint farm solution. I’ve tried to get everything on the page looking reasonably nice, while staying within the default look and feel of SharePoint 2013. So I’ve just got some CSS tweaks to get everything laid out right and looking good. And the page does look reasonably good on my dev VM. But I’ve noticed that certain text looks pretty bad when viewed on a Windows 7 machine.

The default font in SharePoint 2013, for most stuff, is something called “Segoe UI Light”. This is a Microsoft font that they, apparently, use for a lot of internal stuff. If you look at this page, you’ll see something interesting: Windows 7 uses version 5.00 of the font, while Windows 8 uses version 5.27. Checking my desktop Win 7 PC, I can see that it is indeed on version 5.00. (And I have version 5.36 on my Win 2012 R2 VM.)

This blog post goes into the differences between these font versions in a bit more detail. Here’s the one line that really caught my attention: “Microsoft’s fonts team has also worked on improving the hinting of Segoe UI, especially the Light variant which was never properly hinted.” So, yeah, that “never properly hinted” thing is probably why my page title looks horrible on Windows 7.

I don’t want it to sound like I’m bashing Microsoft’s font too much. It’s actually pretty nice, especially if you have a recent version on your PC and not the 5.00 version. But, for my project, it’s a problem. So I looked into switching to a Google web font. I choose Open Sans as a replacement for Segoe UI. I’d seen it suggested somewhere, and it seems to work well, and is free to use.

I’ve used Google fonts before, but had forgotten how to use them. It’s pretty easy. Just Put this in your page head:
<link href="https://fonts.googleapis.com/css?family=Open+Sans" rel="stylesheet">

And use this for your CSS:
font-family: 'Open Sans', sans-serif;

This has worked out pretty well for me. The page now looks good on Windows 7 and on more recent versions.