Recently had need of a SQL Server script that can tell me if there are open transactions on the database. The script below worked for me:
DB_NAME(s.dbid) AS DatabaseName,
CR.TEXT AS Query
FROM sysprocesses s
CROSS apply sys.Dm_exec_sql_text(sql_handle) CR
WHERE open_tran = 1
Finished work on the WriteFreely Archive Page Generator Blazor app. While it does say WriteFreely, you can still pass in Write.as as the instance name and your Write.as alias, and it will work just the same.
While working on a Blazor WASM project last week, I noticed that no matter what changes I make to the index.html and app.css files, they were not reflected whenever I open up the site on IIS Express. It turns out to be a caching issue. All I needed to do, was hit CTRL + F5 after the site loads, and it will pull in my changes.
When I try getting posts from a Write.as blog using a Blazor WASM app, it works. When I try getting posts from a WriteFreely instance blog, using the Blazor WASM app, it won't work. But when I try getting posts from a WriteFreely instance blog, using a .NET Core console app that uses the WriteAs.NET library I wrote, the same library that the Blazor WASM app uses, it works. Something weird is going on.
My research into the issue indicates a possible limitation with WebAssembly apps. There must be some security setting on the WriteFreely instance I'm testing, that's blocking my Blazor WASM requests. The Write.as API is obviously not blocking my requests, so something is going on with that WriteFreely instance.
I dug into it some more and found that it is a CORS related issue. But at this point, there's nothing else I could on my end to fix it. I created a thread on discuss.write.as to talk about it.
Was supposed to create an “Unpopular Posts” Blazor WASM app, but ended up creating the opposite. Anyway, I managed to make the app flexible by having it use query string parameters. That means that you can use the app and embed it into your own Write.as page/site. Just follow the instructions in the readme.
I purchased a new domain, nowlisteningto.com for my Now Listening to... music blog. Prior to buying the new domain name, I didn't realize how big of a pain it was going to be to set up redirection. Turns out, you can't setup a 301 redirect using just DNS records. It has to be done on a web server level, or via your domain registrar. My issue is that I can't use my domain registrar for redirects, because I use Netlify to manage the DNS records for my domains. And from what I can see, Netlify doesn't have a menu option for redirecting from one domain to another.
During my second digital declutter, I found that I had a lot more time to tinker with my websites. And so I did. Here are some of the updates I've made to this site during that time.
Blazor WASM Search App
I've got a new Search app for this journal. It is a Blazor Web Assembly app. So, basically a .NET app written in C# that runs as a client-side web application. And it loads much faster than my previous Search app hosted on Glitch. That's because it is a static site hosted on Netlify. Which means it's always up and running. There is an initial load where your browser downloads the .NET DLLs. But after that, it should load pretty quickly next time you use it.
I took away the link to get a Random post from this journal. I did so because it had a slot machine feel to it. Watching The Social Dilemma reminded me of the slot machine nature of it. But my main reason for removing it, was because it took so long to load at times. This stood in stark contrast to how fast this Write.as powered site loads. I can redo it as a Blazor Web Assembly app, but that's not a priority right now. Maybe something to tinker with in the future.
I went from an Archive Page that used an embedded Glitch app, to a static Archive Page.
Previously, I used an embedded Glitch app to dynamically create the contents for my Archive page. It worked well, but it was also slow. It was slow because every time you visit the page, the Glitch app had to wake up, then pull all my write.as posts and finally display them in a list. The slowness was a stark contrast to other pages on this site — most of which load very quickly. I also didn't like the idea of depending on a third-party service to serve up the contents of my Archive page.
So, I've been wanting to switch to a static Archive page for awhile now. My problem was that I already had over 350 posts on this site. To get me started, I needed a way to quickly generate a list of all posts on this site. For this, I created a .NET Core console app. This app would get all my posts using the write.as API. Then the app would spit out the list of all posts in HTML format. My first pass actually had it spitting out text in Markdown. But I quickly ran into issues with Markdown and <div> elements not playing well together. So, HTML it was. Anyway, once I had the output on a text file, all I had to do was copy over the HTML and paste it into my Archive page.
Elevator.js fixes those awkward “scroll to top” moments the old fashioned way.
I know it goes against Write.as' minimalistic design, but it would be totally cool if we could get it implemented on here haha.
In Part 1, I covered how I generated links to the Previous and Next post for my “indexed” journal entries. In this post, I'll talk about how I generated the links for non-indexed journal entries.
Handling Old Journal Entries