Category: programming

Five year work anniversary

I hit my five-year anniversary at SHI this week. I don’t really have much to say about that, but I thought I should mark it with a quick blog post. I mentioned SHI in my New Year’s Day post, so that covered my current status pretty well. I first mentioned the job on my blog in March 2013, after I’d been there for a couple of months. My current projects are a mix of straight Dynamics AX work in X++, some .NET stuff, using C#, and some research into Power BI. So it’s a pretty good mix. I think I might see some opportunities to do stuff with Power BI in the cloud and maybe some Azure stuff this year. So that could be fun.

We recently (finally) got current Visual Studio subscriptions at work, so I now have access to VS 2017 Pro and the other random fun stuff that comes with a VS subscription. (Previously, we had some kind of standalone licenses to VS 2012 and 2013.)

I’m always a little worried about stagnating and turning into “that guy” who has been doing COBOL programming for years and hasn’t learned anything new since the Nixon administration. But SHI seems to be giving me enough opportunities to work on new and interesting stuff, and I’m still trying to keep current independently, via services like Pluralsight and Safari, and podcasts like .NET Rocks and Hanselminutes. So I guess I’m still on the right career track.

Learning Power BI

I’ve recently started trying to learn about Power BI, since it looks like we’ll be using it at my job soon. We first started talking about Power BI in 2016; at that time, I looked into it a bit, decided it probably wasn’t something that was going to work out for us, and didn’t really follow up on it. And my boss didn’t follow up with me on it, so I figured it was dead or on the back-burner. I guess it was the latter, since it’s come up again. This time, it sounds like maybe we’re a bit more serious about it than last time, so I’ve been spending a lot more time trying to figure it out than I did back in 2016.

I’ve never really done much BI work, though I’ve done plenty of work around the edges of BI, and have dipped my toes into more serious BI from time to time. I’ve done a lot of ETL work, and that seems to be a big aspect of BI.

To get myself up to speed, I first took a look at what was available on Pluralsight. I started with a course called Getting Started with Power BI, which was a pretty good intro course that just zoomed through a lot of stuff quickly. Then, I watched a course called Introduction to Data Warehousing and Business Intelligence, which helped me get some background info on the current state of BI and data warehousing. (I was already somewhat familiar with the general idea of cubes, but didn’t really know much about them.)

After that, I decided to dig more deeply into the Power BI Desktop tool. This is a free tool from Microsoft that’s actually pretty good, and could be useful as a standalone tool, even if you’re not plugged into the whole Power BI cloud thing. I’m currently reading a book titled Pro Power BI Desktop. It’s covering the product in a lot of detail. (Maybe too much detail. It feels a little like this book doesn’t really need to be 761 pages long. But it’s a pretty good book, overall.)

There’s also a free course on EdX about Power BI. I might give that a try, if I feel like I need to. The course is part of a Microsoft Professional Program in Data Science that’s all available on EdX, and which looks pretty interesting. I’d love to do it all, if I had a lot more spare time than I currently have, and if I wouldn’t miss the $990 it would cost to officially enroll in it and get the certificate from it. The path I’m on now is more about simple BI rather than fancy data science, but I’m really curious about that stuff. I was listening to an episode of Hanselminutes this morning on machine learning and data science, and it was really interesting. I wish I had the time to figure it all out.

Back on the subject of Power BI itself, I was leery about it back in 2016. Microsoft sometimes introduces products like this that don’t last long, or that are overly complicated or expensive, given what they do. Power BI looks like it might actually be a winner though. The Desktop tool is quite versatile and useful even without the cloud service. I’m still trying to figure out whether or not it’s worth buying into the whole ecosystem though. You can do a lot with it for free, but the cost could get pretty high if we start using it for a lot of enterprise-level stuff.

Twelve Days of .NET: Day 13: LINQPad

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

I decided to add one more post to this series, so now it’s a baker’s dozen, I guess.

I went through a little exercise about a year ago, looking at various C# REPL options. I played around with a few options, but never really settled on one as being really useful and, for me, any better than just writing a quick console app.

Somehow, in all of that, I’d completely forgotten about LINQPad. I’d first looked at it all the way back in 2007, and was using it pretty regularly for a while. I stopped using it at some point and forgot about it. I probably stopped using it because I’d switched to Snippet Compiler. Snippet Compiler is pretty much dead now, I think. If I’d been paying attention, I would have switched back to LINQPad years ago, like this guy did.

I saw a reference to LINQPad recently, in a reddit post, and took a look at the current web site. It seems to have matured into a really great, full-featured, product. There are both free and paid versions. The free version is probably good enough for me, but the pro version is only $45 and adds some nice features.

Twelve Days of .NET: Day 12: Getting Started

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

OK, so the last day is a weird place for a “getting started” post, but I’m just about out of other stuff, and I remembered a good article on this. The .NET ecosystem is getting pretty complicated, with Visual Studio Pro vs Visual Studio Code and .NET Framework vs .NET Core and a bunch of other decision points along the way. Here’s a good blog post with a flowchart for figuring out which direction you should go in, if you’re starting a new project and you’re kind of clueless.

Twelve Days of .NET: Day 11: HttpClient

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

The standard way to call a REST API in .NET is to use HttpClient. I don’t think HttpClient existed yet when I first needed to interact with REST web services, several years ago. I remember using something called RestSharp, which, I now see, still exists and appears to still be actively maintained, with some fairly recent commits. (Including several on Christmas Eve!)

Here’s a good overview article on how to use HttpClient. And here’s an important blog post on how NOT to use it.

And here’s another interesting blog post, that goes a lot deeper into disposal and finalization with regard to HttpClient. (I have to admin that I’ve only skimmed this post. But I should really read it.)

One surprising thing I discovered while working on my current project is that HttpClient doesn’t have a PatchAsync method. The workaround is pretty easy, and can be found in that linked GitHub issue, and in a number of StackOverflow answers.

Twelve Days of .NET: Day 10: Pluralsight

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

I’ve used Pluralsight a lot over the last few months, to try and learn some of the new stuff I needed to know to get my current project done. I went ahead and renewed my membership recently, so I’m set through 2018. We’ll see how much use I get out of it in 2018.

Here are a few courses I finished recently:

That last one didn’t really have anything to do with my current project, since I used VS 2017 and not VS Code, but I was thinking about using VS Code for it, initially. I like VS Code as a tool, but, given a choice, I’ll stick with the full VS 2017.

And I’ve started this course: Web API v2 Security by Dominick Baier

I actually have a lot to learn about security and authentication/authorization for Web API, but it’s not that important for my current project, since it will only be used internally.

I have a lot of other videos bookmarked in Pluralsight. I’ll probably get around to watching a few of them, but I haven’t really been spending much time on that lately. At work, I’ve been busy programming, and at home, I’ve been busy watching Netflix and reading comic books.

Twelve Days of .NET: Day 9: Git and TFS

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

At work, we have a TFS 2012 server for version control. We’re pretty much stuck with that, because the TFS integration in AX 2012 can be a little finicky, and we don’t have a really compelling reason to upgrade anyway. I know that recent versions of TFS (starting with 2013 maybe?) support hosting Git repos, but I think I’d be stuck with TFVC anyway, for a variety of reasons.

For my current .NET project, for which I’m using VS 2017, I started out with a local Git repo, intending to kill it and switch to TFVC when it was ready to go into test. I’m liking Git enough, though, that I’ve stuck with it, and have come up with a somewhat kludgey workflow, where I use Beyond Compare to periodically copy changed code files from my “work” project to a copy of the project that’s bound to TFS. So I code and test locally in the Git version of the project, committing often. Then, when I’m ready to deploy to my test server I follow a workflow where I copy to the TFS project, check my changes into TFS, then deploy to our test IIS server. As I said, it’s a bit of a kludge, but it works for me.

I thought about trying to use git-tfs, but I didn’t want to go down any rabbit holes so I stuck with the simple (but ugly) solution. And I’d love it if we could just switch to VSTS, but I don’t think that’s going to happen either.

Twelve Days of .NET: Day 8: Async

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

Since I’d been away from .NET for a while, I hadn’t really had an opportunity to dig into the new (to me) async stuff. Here’s a good article from 2016 that delves into it.

Six Essential Tips for Async on Channel 9 is also really good.

Twelve Days of .NET: Day 7: Json.NET

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

Json.NET has been around for a long time, since 2006; I remember using it at my previous job. Since then, it’s become the default Json serializer/deserializer for .NET. I think there’s a way to deal with Json in .NET without it, but I can’t imagine why you’d do that. I don’t have much to say about Json.NET, just that it works great and I’m glad it exists.

Twelve Days of .NET: Day 6: Fiddler

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

I can’t emphasize enough how useful Fiddler is for testing a REST API. My project is essentially a REST API calling another REST API, so Fiddler is doubly-useful for me. I can test my own API, and I can see what the external API is returning to me. I even went as far as buying Eric Lawrence’s Fiddler book. I’ve read about half the book so far, and I’ve learned a lot from it, both about Fiddler, and about HTTP in general.

I used to use curl for testing REST APIs, but Fiddler’s composer tab is much nicer. (Having said that, I’m still glad to hear that curl is going to be available in the standard Windows 10 install soon.)