performance tuning surprises

Here’s another blog post about the program I’m currently working on at my job. This is the same program I blogged about yesterday and a couple of weeks ago.

Today, I was trying to fix a performance issue. The app originally ran really fast. It just had to make a few API calls, filter and combine some data, then spit it back out in JSON format. It took less than a minute to run. But then, I was asked to add a new data element to one of the files. An element that I could only get by calling a new web service method repeatedly, once per order, for about 7000 orders. It shouldn’t be an expensive call, but the end result was that my 1 minute runtime was now up to 10 minutes.

The first thing I tried doing was adding some concurrency to those 7000 new API calls. I did that using the first technique described in this article, implementing a ConcurrentQueue. I wasn’t really optimistic that it would help much, but I thought it was worth a try. It didn’t really help at all. The program still took about 10 minutes to run. So I undid that change.

The next thing I did was to look and see if I was repeating any of the API calls. While I was processing 7000 records, there were some cases where the same sales order number was found on multiple records, so I was making extra unnecessary API calls. So I implemented a simple cache with a dictionary, saving the API call results and pulling them from cache when possible. That didn’t help much either. About 90% of the calls were still necessary, so I only got down from 10 minutes to 9 minutes. But that was at least worth doing, so I left that code in place.

Then, finally, it occurred to me to look at how I was calling the API. This new API call was part of the WCF SOAP service that I’ve mentioned previously. Well, the way I wrote my wrapper code for the API, I was creating a new call context and service client for every call. I didn’t think that would be a huge issue, but I went ahead and refactored things so all the calls used the same call context and client. Well, that got the execution time back down to one minute. So really all of that extra time was spent in whatever overhead there is in spinning up the WCF client object (and I guess tearing it down when it goes out of scope).

That was really unexpected. I hadn’t thought about it much, but I assumed the code behind the instantiation of the service client was just setting up a structure in memory. I guess that maybe it’s also establishing communication with the server? Theoretically, I could dig into it, but I don’t really have the time for that.

The moral of this story is that, when performance tuning, some of the stuff that you think will help, won’t, and some of the stuff that seems dubious, might actually make a huge difference!

Trying to debug a .NET Core app as a different user

I’m working on a .NET Core console app at work that, on one level, is pretty simple. It’s just calling a couple of web services, getting results back, combining/filtering them, and outputting some JSON files. (Eventually, in theory, it’ll also be sending those files to somebody via SFTP. But not yet.)

There have been a bunch of little issues with this project though. One issue is that one of the web services I’m calling uses AD for auth, and my normal AD account doesn’t have access to it. (This is the SOAP web service I blogged about last week.) So I have to access it under a different account. It’s easy enough to do that when I’m running it in production, but for testing and debugging during development, it gets a little tricky. I went down a rabbit hole trying to find the easiest way to deal with this, and thought it might be worthwhile to share some of my work.

In Visual Studio, I would normally debug a program just by pressing F5. That will compile and run it, under my own AD account, obviously. My first attempt at debugging this app under a different user account was to simply launch VS 2017 under that account. That’s easy enough to do, by shift-right-clicking the icon and selecting “run as different user”. But then there are a host of issues, the first being that my VS Pro license is tied to my AD/AAD account, so launching it as a different user doesn’t use my license, and launches it as a trial. That’s OK short-term, but would eventually cause issues. And all VS customization is tied to my normal user account, so I’m getting a vanilla VS install when running it that way. So that’s not really a good solution.

My next big idea was to use something like this Simple Impersonation library. The idea being to wrap my API calls with this, so they’d get called under the alternate user, but I could still run the program under my normal account. But the big warning in the README about not using impersonation with async code stopped me from doing that.

So, at this point, I felt like I’d exhausted the ideas for actually being able to run the code under the VS debugger and dropped back to running it from a command-line. This means I’m back to the old method of debugging with Console.WriteLine() statements. And that’s fine. I’m old, and I’m used to low-tech debugging methods.

So the next thing was to figure out the easiest way to run it from the command-line under a different user account. I spent a little time trying to figure out how to open a new tab in cmder under a different account. It’s probably possible to do that, but I couldn’t figure it out quickly and gave up.

The next idea was to use this runas tool to run the program as the alternate user, but still in a PowerShell window running under my own account. I had a number of problems with that, which I think are related to my use of async code, but I didn’t dig too deeply into it.

So, eventually, I just dropped back to this:

Start-Process powershell -Credential domain\user -WorkingDirectory (Get-Location).Path

This prompts me for the password, then opens up a new PowerShell window, in the same folder I’m currently in. From there, I can type “dotnet run” and run my program. So maybe not the greatest solution, but I’d already spent too much time on it.

One more thing I wanted to be able to do was to distinguish my alternate-user PowerShell session from my normal-user PowerShell session. I decided to do that with a little customization of the PS profile for that user. I’d spent some time messing with my PowerShell profile about a month ago, and documented it here. So the new profile for the alternate user was based on that. I added a little code to show the user ID in both the prompt and the window title. Here’s the full profile script:

function prompt {
    $loc = $(Get-Location).Path.Replace($HOME,"~")
    $(if (Test-Path variable:/PSDebugContext) { '[DBG]: ' } else { '' }) +
    "[$env:UserName] " +
    $loc +
    $(if ($NestedPromptLevel -ge 1) { '>>' }) +
    $(if ($loc.Length -gt 25) { "`nPS> " } else { " PS> " })
}
$host.ui.RawUI.WindowTitle = "[$env:UserName] " + $host.ui.RawUI.WindowTitle

You can see that I’m just pulling in the user ID with $env:UserName. So that’s that.

I’m not sure if this post is terribly useful or coherent, but it seemed worthwhile to write this stuff up, since I might want to reference it in the future. I probably missed a couple of obvious ways of dealing with this problem, one or more of which may become obvious to me in the shower tomorrow morning. But that’s the way it goes.

Calling a SOAP WCF web service from .NET Core

I had a problem at work today that I’d previously solved, almost exactly a year ago. The project I was working on then got almost completely rewritten, so the current version of that code doesn’t have any reference to calling WCF web services at all. I kind of remembered that I’d written up a blog post about it, but couldn’t find it, since I was searching for SOAP instead of WCF. So I’m writing a new blog entry, with “SOAP” in the title, so if I have the same problem again, and I search for “SOAP” again, I’ll at least find this post, with a reference to the previous post. (Having a blog comes in handy, when your present-day self has to solve a problem that your past self has solved, but forgotten about…)

I don’t really have anything to add to that previous post. One thing I will do, though, is post the actual code here, rather than just embed a gist, since I now have a syntax highlighting solution that won’t garble it the way the previous setup did.

// https://gist.github.com/andyhuey/d67f78f6568548f66aabd20eadff8acf
// old way:
        public async Task RunAsync()
        {
            CallContext context = new CallContext();
            context.Company = "axcompany";
            string pingResp = string.Empty;
            var client = new XYZPurchInfoServiceClient();
            var rv = await client.wsPingAsync(context);
            pingResp = rv.response;
            Console.WriteLine("Ping response: {0}", pingResp);
        }
/* app.config:
    <system.serviceModel>
        <bindings>
            <netTcpBinding>
                <binding name="NetTcpBinding_XYZPurchInfoService" />
            </netTcpBinding>
        </bindings>
        <client>
            <endpoint address="net.tcp://myserver:8201/DynamicsAx/Services/XYZPurchInfoServices"
                binding="netTcpBinding" bindingConfiguration="NetTcpBinding_XYZPurchInfoService"
                contract="XYZPurchInfoSvcRef.XYZPurchInfoService" name="NetTcpBinding_XYZPurchInfoService">
                <identity>
                    <userPrincipalName value="myservice@corp.local" />
                </identity>
            </endpoint>
        </client>
    </system.serviceModel>
*/

// new way:
	CallContext context = new CallContext();
	context.Company = "axcompany";
	string pingResp = string.Empty;
	var client = new XYZPurchInfoServiceClient(GetBinding(), GetEndpointAddr());
	var rv = await client.wsPingAsync(context);
	pingResp = rv.response;
	Console.WriteLine("Ping response: {0}", pingResp);
	
	private NetTcpBinding GetBinding()
	{
		var netTcpBinding = new NetTcpBinding();
		netTcpBinding.Name = "NetTcpBinding_XYZPurchInfoService";
		netTcpBinding.MaxBufferSize = int.MaxValue;
		netTcpBinding.MaxReceivedMessageSize = int.MaxValue;
		return netTcpBinding;
	}

	private EndpointAddress GetEndpointAddr()
	{
		string url = "net.tcp://myserver:8201/DynamicsAx/Services/XYZPurchInfoServices";
		string user = "myservice@corp.local";

		var uri = new Uri(url);
		var epid = new UpnEndpointIdentity(user);
		var addrHdrs = new AddressHeader[0];
		var endpointAddr = new EndpointAddress(uri, epid, addrHdrs);
		return endpointAddr;
	}

PowerShell profiles and prompts and other command-line stuff

I’ve been spending some time at work this week rearranging some stuff between my two development VMs, and I hit on a few items that I thought might be worth mentioning on this blog. I have two development VMs, one with a full install of Dynamics AX 2012 R2 on it, and another with a full install of SharePoint 2013 on it. Both are running Windows Server 2012 R2. And both have Visual Studio 2013 and 2017 installed. My AX work needs to get done on the AX VM, and any old-style SharePoint development needs to get done on the SharePoint VM.

General .NET development can be done on either VM. For reasons that made sense at the time, and aren’t worth getting into, my general .NET work has all ended up on the SharePoint VM. This is fine, but not optimal really, since the SP VM has only 8 GB of RAM, and 6 GB of that is in constant use by the SP 2013 install. That’s leaves enough for VS 2017, but just barely. The AX VM has a whopping 32 GB of RAM, and the AX install generally uses less than 10 GB. And my company is gradually moving from SP 2013 to SharePoint Online, so my need for a dedicated SharePoint VM will be going away within the next year or so (hopefully).

So it makes sense to me to move my general .NET projects from the SP VM to the AX VM. That’s mostly just a case of copying the solution folder from one VM to the other. Back when we were using TFS (with TFVC) for .NET projects, it would have been more of a pain, but with git, you can just move things around with abandon and git is fine.

All of this got me looking at my tool setups on both VMs, and trying to get some stuff that worked on the SP VM to also work on the AX VM, which led me down a number of rabbit holes. One of those rabbit holes had me looking at my PowerShell profiles, which led me to refresh my memory about how those worked and how to customize the PowerShell prompt.

The official documentation on PowerShell profiles is here, and the official doc on PowerShell prompts is here. User profile scripts are generally found in %userprofile%\Documents\WindowsPowerShell. Your main profile script would be “Microsoft.PowerShell_profile.ps1”. And you might have one for the PS prompt in VS Code as “Microsoft.VSCode_profile.ps1”. (Note that I haven’t tried using PowerShell Core yet. That’s another rabbit hole, and I’m not ready to go down that one yet…)

Anyway, on to prompts: I’ve always kind of disliked the built-in PowerShell prompt, because I’m often working in a folder that’s several levels deep, so my prompt takes up most of the width of the window. The about_prompts page linked above includes the source for the default PowerShell prompt, which is:

function prompt {
    $(if (Test-Path variable:/PSDebugContext) { '[DBG]: ' }
      else { '' }) + 'PS ' + $(Get-Location) +
        $(if ($NestedPromptLevel -ge 1) { '>>' }) + '> '
}

In the past, I’ve replaced that with a really simple prompt that just shows the current folder, with a newline after it:

function prompt {"PS $pwd `n> "}

Yesterday, I decided to write a new prompt script that kept the extra stuff from the default one, but added a couple of twists:

function prompt {
    $loc = $(Get-Location).Path.Replace($HOME,"~")
    $(if (Test-Path variable:/PSDebugContext) { '[DBG]: ' } else { '' }) + 
    $loc + 
    $(if ($NestedPromptLevel -ge 1) { '>>' }) +
    $(if ($loc.Length -gt 25) { "`nPS> " } else { " PS> " })
}

The first twist is replacing the home folder with a tilde, which is common on Linux shells. The second twist is adding a newline at the end of the prompt, but only if the length of the prompt is greater than 25 characters. So, nothing earth-shattering or amazing. Just a couple of things that make the PowerShell prompt a little more usable. (I’m pretty sure that I picked up both of these tricks from other people’s blog posts, but I can’t remember exactly where.)

Anyway, this is all stuff that I’m doing in the “normal” PowerShell prompt. I also have cmder set up, which applies a bunch of customization to both the cmd.exe and PowerShell environments. Honestly, the default prompt in cmder is fine, so none of the above would be necessary if I was only using cmder. But I’ve found that certain things were only working for me in the “normal” PowerShell prompt, so I’ve been moving away from cmder a bit. Now that I’m digging in some more, though, I think some of my issues might have just been because I had certain things set up in my normal PowerShell profile that weren’t in my cmder PowerShell profile.

Cmder is basically just a repackaging of ConEmu with some extra stuff. I don’t think I’ve ever tried ConEmu on its own, but I’m starting to think about giving that a try. That’s another rabbit hole I probably shouldn’t go down right now though.

I’d love to be able to run Windows Terminal on my dev VMs, but that’s only for Windows 10. (It might be possible to get it running on Windows Server 2012 R2, but I haven’t come across an easy way to do that.) Scott Hanselman has blogged about how to get a really fancy prompt set up in Windows Terminal.

And at this point, I’ve probably spent more time messing with my PowerShell environment than I should have and I should just settle in and do some work.

WordPress syntax highlighting

I started writing a blog post about PowerShell today, then got caught up in an issue with the code syntax highlighting plugin that I’ve been using on this blog since 2017. I’ve been using WP-Syntax since then, and I’ve generally been happy with it, but there are a few things that bug me, so that set me off looking into other options. One issue I noticed is that WP-Syntax hasn’t been updated in four years, and hasn’t been tested with recent versions of WordPress. So that definitely got me looking for a good alternative.

My search led me to SyntaxHighlighter Evolved, which seems to be under active development and worked well in my testing. It uses a special shortcode for highlighting, which means that I’m going to have to go through all of my old code posts and replace <pre> tags with “code” tags. I did a search to find those, and apparently I only have about 40 posts on this blog with code in them. That’s a little embarrassing, considering that I have more than 2000 posts on this blog. I always want to write more programming-related posts with real code in them, but I never get around to it. Well, maybe this will motivate me.

moving and resizing windows in AutoHotKey

One of the minor little issues I’ve had since this whole “work from home” thing started is that I frequently need to switch back and forth between using my laptop on its own vs. remoting into it from my desktop PC. I always need to be connected to our work VPN, and we’re not allowed to install the VPN client on personal PCs. And I don’t have an easy way to connect my personal monitor, mouse, and keyboard to the laptop. (Yes, I know there are a bunch of reasonably easy ways to do that. I just haven’t made the effort.) So I spend most of the day remoted in to the laptop via RDP from my desktop PC. But I disconnect and use the laptop directly whenever I need to be in a meeting, so I can use the camera and microphone. (And, yes, there’s probably a way for me to use the camera and mic while remoted in, but I haven’t bothered to try figuring that out either.)

Anyway, the issue with all that is that the change in resolution between the laptop screen and my desktop monitor confuses things, so my window sizes and positions are generally all screwed up when I do that. So I wanted to write a little AutoHotKey script to automatically move and resize the windows for my most commonly-used programs. (In my case: Outlook, OneNote, and Firefox. I do my actual development work via RDP into a VM, not on my “real” computer, so it’s just the productivity stuff running on the laptop.)

Of course, given the way these things tend to go, I just lived with it until June, when I finally got around to writing the script. And, again, of course, I found issues with the script, but didn’t bother correcting them until… today. So here’s a script that looks at the current monitor’s resolution, then moves and resizes Outlook, OneNote, and Firefox so they’re tiled and just the right size for my preferences.

SysGet, Mon1, Monitor
;MsgBox, screen dimensions: %Mon1Right% x %Mon1Bottom%

X := 70
Y := 32
Width := Mon1Right - 240
Height := Mon1Bottom - 150
;MsgBox, X=%X%, Y=%Y%, Width=%Width%, Height=%Height%

WinRestore, ahk_exe OUTLOOK.EXE
WinMove, ahk_exe OUTLOOK.EXE,, X, Y, Width, Height
WinRestore, ahk_exe firefox.exe
WinMove, ahk_exe firefox.exe,, X*2, Y*2, Width, Height
WinRestore, ahk_exe ONENOTE.EXE
WinMove, ahk_exe ONENOTE.EXE,, X*3, Y*3, Width, Height

Nothing fancy, but it does what I need, and I thought it might be useful to post it here. It’s using the SysGet command to get the screen dimensions, and the WinMove command to move the windows.

I also considered using PowerShell with WASP for this, but I’m more familiar with AHK.

still learning React

I’m still trying to learn React, and a bunch of the stuff that goes along with it. I’m almost done with the Learning React book that I’ve been reading. It’s been helpful, but there are still a bunch of things I need to work on.

As previously mentioned, I’ve set up my MacBook for React development, by installing Node.js via Homebrew, with VS Code as my editor/IDE. I still haven’t gotten around to setting up a dev environment on my new Lenovo laptop. I did, though, decide today to take a shot at setting up my work laptop for some minimal development. I wouldn’t ever do “real” production development on my work laptop; we have dev VMs for that, and I’ve got a dev VM that will work for React dev. But it’s useful to have some dev tools on the laptop, just to work through sample projects and stuff like that. I can’t go too far with dev stuff on the laptop, since, from a security standpoint, it’s basically an “end-user” machine and a lot of software installs are blocked. But I thought I’d try to install a few mostly harmless tools. So I managed to get VS Code installed, no problem, and Git. Then I tried to install Node, via the standard Windows installer. That worked fine, up to the point of installing node-gyp which seems to have failed. I don’t think that I actually need that, so I’m probably fine. But that was a reminder of how these things can get confusing when you’re trying to install dev tools on a locked-down laptop. (If I want to install Node on my personal Windows laptop, I should probably look at this MS doc that walks you through installing nvm first.)

In reading about React stuff, I’m hitting a lot of issues with figuring out what’s current and what’s out of date. And also in figuring out how to do stuff in TypeScript (vs. “plain” JS). There are a lot of blog posts, and Medium articles, and videos, all showing you how to build a basic React app. But most of them are a little messy. I keep hitting stuff that doesn’t seem to work, either because React (or some dependency thereof) has changed since the article was written, or because the article was poorly edited and the code in the article doesn’t really work. And even when the code does work, sometimes it’s not being done in the “right way,” given current standards. So I guess I’m stumbling my way into becoming a semi-competent React / TypeScript developer.

more odds and ends

I’m kind of exhausted now, and I kind of want 2020 to just be over. But it’s not. I’m doing my best to stay positive and keep working and exercising and eating right (and I am doing all that), but I’m getting a little frayed around the edges. Anyway, here’s another round-up of (mostly) bad news. Writing helps me process things and clear my head. I don’t necessarily expect anything here to be useful to anyone else, but writing it down helps me.

More #MeToo

Well, the #MeToo stuff in comics is really starting to snowball. After Cam Stewart, Warren Ellis, and Charles Brownstein, now it’s Scott Allie’s turn. Allie was an editor and writer at Dark Horse. He was the editor on all the Hellboy and Hellboy-related books for a long time. And he’s written a few also. I’ve been a Hellboy and BPRD fan since Hellboy #1 from back in the 90s. I didn’t really know anything about Allie, other than just knowing his name from the credits and letter columns. So I can’t say much about him. I don’t think there’s any indication that Mike Mignola knew anything about this, so that at least is something. I’d hate to have to lose my respect for Mignola. (And I do have a good bit of respect for him.)

And back to Brownstein: He was apparently involved in another incident, about ten years ago, involving a CBLDF employee, who was then essentially forced to sign an NDA. So things are looking worse for them. I’m not quite ready to burn my CBLDF t-shirts, but I’m not going to be wearing them in public anytime soon either.

New Toys

I don’t think I’ve even turned on my new laptop yet this week. I’ve been doing a bunch of React stuff on my MacBook, and all of my actual work on my work machines, of course. So I haven’t had time to do any setup on the Lenovo.

I have had time to mess around with my Echo Dot a bit though. I’ve discovered that it’s pretty good as a speaker (given it’s small size), but not if you’re using it via Bluetooth. So if you’re playing stuff over it via the usual Alexa route, it sounds pretty good. But it’s not really worth trying to use it as a Bluetooth speaker. So I’ll yell “Alexa, play WQXR” if I want to hear some classical music while I’m working and that works out fine.

React

Speaking of React, I’ve been reading the second edition of Learning React via my ACM O’Reilly subscription. It’s an “early release” version, so it’s a little rough, but it’s more up-to-date than any other book on React that I’ve seen. I’m at a point now where I’m not sure if I should keep working my way through books and videos or if I should stop reading/watching and start actually working on a project. I think I might need to finish the Learning React book at least. I’m still having trouble getting at the big picture with React. I’m learning little bits and pieces, but they don’t all fit together in my head yet.

Reopening NJ

Somerville is really hopping this week, and I’m not sure how I feel about that. Mostly nervous, I guess. All the restaurants are doing outdoor dining, which means that they’ve annexed about 90% of the sidewalks. So a walk down Main St right now is kind of an obstacle course. And the obstacles are people sitting at outdoor tables, talking, eating, and not wearing masks. My early morning walks are still OK, since there are only one or two places open that early. But I’ve been avoiding Main St on my afternoon walks. Still, though, it’s kind of fun to see the outdoor dining. And it’s nice to hear people talking and laughing and all that. I just wish I could shake the idea that one of them is going to spray COVID-19 all over me.

Meanwhile, the Bridgewater Commons is going to reopen on Monday. I don’t think I’ll be going back there any time soon though. Maybe I’d risk a trip to the Apple Store if I really needed something, but only as a last resort. I just ordered two new pairs of shorts from the Macy’s web site, and I think that’s all the new clothes I’ll need between now and the end of the year. Macy’s and the Apple Store are really the only places at the mall that I frequent, so I don’t think I’ll be tempted to go over there.

And Yestercades is reopening too, on July 2. This seems like an even worse idea that reopening the mall. There’s no way they can keep all those arcade machines clean. And that place is really too cramped for social distancing. I don’t know, maybe they’ve figured out a way to make it work. I can definitely say that I’m not going back in there anytime soon either.

I may be more stressed now than when I started writing this post, which is not how I wanted this to turn out. Maybe I should spend the next hour listening to this public domain recording of the Goldberg Variations. That’ll help me calm down.

 

odds and ends

OK, after this morning’s depressing Warren Ellis post, here’s some lighter stuff. Just a mix of stuff I’ve been meaning to mention, for one reason or another.

Google AdSense

I added Google AdSense to my blog back in 2010 and removed it in 2016. But I never closed out my account. So I did that this week. Now, I can finally get the $15 that Google owes me. (Normally, they don’t pay out until you hit $100, but if you close your account, they’ll pay out any balance, if it’s over $10.) I wonder how many small bloggers like me are still bothering with AdSense. For a while, a lot of people thought they could make good money by running a blog and putting AdSense on it. I’m wondering if any of them really did.

New Toys

I haven’t made much more progress in setting up my new laptop. I was too busy yesterday to even turn it on. Hopefully, I’ll have time to do some stuff with it this weekend. I did also just get a new Amazon Echo Dot (with clock). I don’t really have a good excuse for buying it. I had an old iHome alarm clock / iPhone dock on my nightstand that I couldn’t really use anymore, since it doesn’t fit the newer iPhones. And that was fine, really, since I don’t really need a clock on my nightstand. These days, I just plug my iPhone in, and use Sleep Cycle as my alarm clock. But, I don’t know, I guess I just wanted a small clock there that could play music or NPR or whatever. And it was only $35. I already have some experience with Alexa, since it’s supported on my Sonos speakers, but I turned off the mics on those, since it was getting accidentally triggered too often, and I didn’t really find it that useful. I’m going to play around with it some more on the Echo and see if there’s anything fun or useful that I can do with it.

Learning New Stuff

I finished the SharePoint Framework course that I was working through. That’s given me a good start, but there’s still a lot I need to figure out. I’m almost done with the React course on SharePoint that I’ve been watching and working through. Most of that course uses an online JavaScript environment, found at jscomplete.com, so you don’t need to set up your own dev environment. But I’m now at the point where I really do need to set up a dev environment to get any further. I considered a lot of options, but settled on using Homebrew on my Mac to set up Node.js. And I’m using Visual Studio Code as my text editor. So that’s good enough for now.

I may need to play with Node Version Manager at some point, but for now, I think that would be an unnecessary complication. And, on Windows, I want to look into setting something up under WSL2 at some point. Microsoft, helpfully, has a guide on how to do that. But, again, I’m probably not ready to dive into that just yet.

So that’s my “odds and ends” post for today. I could write up a bunch of other stuff, but it’s probably best if I stop for now and go eat some lunch. Then maybe take a nap.

SharePoint, React, Laptops, and so on

I mentioned a while back that I’m trying to learn about the (relatively) new SharePoint Framework (SPFx), for a project at work. I’ve made some progress with that, but I still have a way to go. I’ve done 5 of the 8 modules in this course from Microsoft. And I’ve watched a couple of Pluralsight videos, one from Sahil Malik and one from Danny Jessee. I’ve been doing that mostly on work time, since it’s specific to a work project.

SPFx relies on a number of related technologies, some of which I know and some of which I don’t. (And the ones I know, I don’t necessarily know that well.) So I decided to start digging into some related stuff, on my own time. I know pretty much nothing about React, and it looked interesting, so I decided to start learning that. I’ve watched one short Pluralsight video, that just gives an overview without getting into specifics. And now I’m working through a four-hour video course that goes into a little more detail. There’s a whole skill path for React on Pluralsight that would take about 40 hours to watch, if you went through it all. (And of course it would be much longer than that, if you actually followed along and worked through projects on your own.)

I got side-tracked off of React at one point when I was watching one of the Pluralsight videos on my old ThinkPad, and the battery suddenly died. I’ve had that laptop since 2011, and it’s starting to show its age. I’d only been watching the video for about 30 minutes, and the battery should have had a full charge when I started. So I started thinking about either replacing the battery on it, or just getting a new laptop. Replacing the battery on that particular model is really easy. And there were a bunch of options for a replacement battery on Amazon (though most of them looked kind of sketchy). But I started thinking about how old the laptop was, and how iffy off-brand replacement batteries can be. And I also started wondering if that laptop was going to be able to handle some the stuff I’m going to want to try out soon, like WSL 2. I’ve been hearing about that for a while, and it’s now been released as part of the Windows 10 2004 update. The old ThinkPad, surprisingly, has been able to keep current with Windows 10 updates so far, up to version 1909. But I have my doubts about whether or not it’s going to be able to deal with 2004. So, reluctantly, I started shopping for a new laptop.

This is a pretty common thing with me: I start trying to learn a new technology, and I get side-tracked shopping for a new laptop, or some new piece of software, or something. Anyway, I spent way too much time on that yesterday. This morning, I finally settled on the Lenovo Flex from Costco, for $750. It’s a bit of a compromise, since I’ll need to upgrade it to Windows 10 Pro, but I can still do that for $40 with my Microsoft company store access, which should still be good for the next week or two. Also, it’s a 2-in-1, which I don’t really need or want, but most Windows laptops seem to be touchscreen 2-in-1 models now, so I’ll give it a try. On the positive side, it’s got 16 GB of RAM, a 512 GB SSD, and an AMD Ryzen 7 CPU. (I haven’t really been keeping up with CPU news lately, but it looks like the AMD Ryzen 7 4700U is pretty good.) So I think it should be able to handle my fairly modest needs. I always feel a little guilty when I spend money on new hardware, but I’m trying to remember that, this year, I’ve spent nothing at all on travel, and I’m not likely to. If I’d gone to WonderCon this year, that would have cost me well over $1000, for hotel and airfare alone.

I was going to remark that I’d made it through a whole post without referencing COVID-19, but the travel comment above kind of does reference our current situation, so I guess that’s not true. COVID-19 definitely did affect my laptop shopping. In normal times, I probably would have gone out to Costco yesterday to see what laptop models they had on display. And I might have taken a trip to Best Buy too. Costco is still open, but I don’t really want to go there unless I have to. And Best Buy of course is still closed. So I settled on a mail-order laptop from Costco. They have a good return policy, if I need it.