Attach to Process

Thoughts and Notes on Software Development

Update 06/22/2020: Didn't realize that the JavaScript that I talked about in this post, was actually creating a Next link for this post. It thought this was a Journal Entry post, because it found that text in here. That's hilarious, but that is also part of the fun of tinkering. I have fixed it.

Update 04/26/2021: I have since taken down my Journal Entries, so the links on this post won't work anymore. However, the idea and logic described in this post, is still applicable for posts that uses index numbers for post slugs. For a working example of this, check out the posts on my photo-blog.

Finally got full blog post navigation working for my Journal Entries. If you have JavaScript enabled on your browser, you could effectively navigate from Journal Entry – I up to Journal Entry – XVI, then continue on to Journal Entry – 001, all the way up to the latest one (as of this writing), Journal Entry – 060. You can also navigate from Journal Entry – 060, all the way back down to Journal Entry – I.

Getting Post Slug and Index

To make navigation work between blog posts in a series, I made use of a standard format for post slugs/URLs. I call them “indexed” entries because I added an index to the end of the slug/URL. For example, “journal-entry-001”, “journal-entry-002”, “journal-entry-003” and so on. It's really just a way to help me figure out the sequence of posts.

So, first off, here is the JavaScript for getting the post slug from the URL. Then from there, getting the post index from the slug. Without this code, it will be impossible to automatically generate the links to the Previous and Next posts.

var element = document.querySelector('meta[property="og:url"]');
var content = element && element.getAttribute("content");

// Get post slug
var postSlug = content.split('/').pop();
var postIndex = postSlug.split('-').pop();
Read more...

Was playing around with Blazor and created this site. It is a static site that has web apps written in C# instead of Javascript. Why? Because with Blazor, you can.

Next step is figuring out how I can embed Blazor apps.

Tags: #AspDotNet #Blazor #DotNetCore

Discuss... or leave a comment below.

Unintentionally running data manipulation scripts on a Production database is obviously bad. In this post, I'll share some tips for working with Production databases so the same thing doesn't happen to you.

1. Check your Database Connections

Double-check your database connection before running any scripts. Oftentimes, this simple check is all you need to do, to avoid accidentally deleting data in a Production database.

2. Start new instance of SQL Server Management Studio

When connecting to a Production database, start up a new instance of SQL Server Management Studio. The idea is to keep scripts between Production and other databases separate. This helps you distinguish between database connections. And hopefully stop you from running a script that will mess up the Production database.

3. Work off Database Backups

Better yet, if you have the option, restore a backup copy of the Production database on a dev box and work off that. This way, you can mess with the data and not worry about affecting Production.

Note: Make sure restoring database to a local dev box is allowed per your company policy.

4. Use Database Transactions

If the script you are running has the potential to change a databases' data or schema – like if it has the words ALTER, CREATE, DELETE, INSERT, UPDATE, or any other statement that can modify the contents of a database – then you should be wrapping the scripts in a transaction. BEGIN TRAN is your friend. I do this even when I'm running the scripts on a local database instance. It might sound like overkill to use transactions on scripts running on non-PROD databases, and maybe it is. But what's an extra 10 seconds or so of doing that, if it prevents you from accidentally blowing up the Production database? I do it for peace of mind. It's part of routine for me now. Anytime I write a script that has the words ALTER, CREATE, DELETE, INSERT or UPDATE, I wrap them in a transaction. Doesn't even matter what database I'm connected to.

This is how I wrap scripts in a transaction:

BEGIN TRAN

-- ALTER, CREATE, DELETE, INSERT, UPDATE Statements go here

ROLLBACK TRAN
COMMIT TRAN

I use it this way: I highlight the scripts starting from BEGIN TRAN and stop just before the ROLLBACK TRAN statement. I run those and double-check the results. This gives me the opportunity to either ROLLBACK or COMMIT depending on the results.

Also, you'll notice above that I have a ROLLBACK TRAN just before the COMMIT TRAN statement. This is just an extra safety precaution that can be especially useful when you're sending out scripts to someone else. They might accidentally run the scripts in a Production database, but the ROLLBACK TRAN will make sure nothing bad happens.

5. Close Instances of SQL Server Management Studio

Before going home or logging off from work, close any instances of SQL Server Management Studio, especially those that you used to connect to a Production database. You'll want to do this because closing an SSMS instance while you have an open transaction, will cause it to display a warning. An open transaction has the potential to block queries and cause timeouts. This will remind you to either rollback or commit your transactions before logging off.

That's it for today. I hope those tips are helpful. If you have your own tips for working with Production databases, do share them by leaving a comment below or sending me a message.

Tags: #Database #Scripts #SqlServer

Discuss... or leave a comment below.

For the past week or so, I've noticed that my C drive was constantly running out of space. Normally, I have a little over 200 GB of free space on my C drive. I ran the SpaceSniffer tool to figure out what was taking up all the space. It pointed me to a set of temp files used by SQL Server. One file in particular, “templog.ldf”, was taking up 40 GB of space. The other tempdb files were 17 GB each but there were 8 of them. My understanding is that these files should automatically shrink back down, but why won't they?

I know what caused those files to increase in size. I've been restoring large database backups locally. And I've done it many times throughout the week. The stored procedures in those databases do use the temp tables a lot. So, I'm not surprised the SQL Server temp files got so big. But I'm still not sure why those files were not shrinking back down to their normal sizes. They maintain their size even after republishing to an empty database. If that was always the case, then I would have noticed this issue years ago. Yet, it has only been happening recently.

While I don't exactly have an explanation for why those files remained huge, I did find a way to shrink them back down. The solution was simple: restart the SQL Server service. Once I did this, the temp files went back to their regular sizes. Restarting the PC would also work, but I haven't done it in awhile since I've started working from home. I believe that contributed to the issue of files maintaining their huge sizes. So, going forward I will restart my work PC every weekend.

Tags: #Database #SqlServer

Discuss... or leave a comment below.

Interesting read on “the Spotify model”, why Spotify themselves don’t use it and neither should you.

While Spotify gave teams control over their way of working, many people did not have a basic understanding of Agile practices. This resulted in teams iterating through process tweaks in blind hope of finding the combination that would help them improve their delivery. People lacked a common language to effectively discuss the process problems, the education to solve them, and the experience to evaluate performance. It was not really agile. It was just not-waterfall.

Huh, this seems awfully familiar.

When Agile Scrum introduced new meanings to a bunch of words like burn-down and sprint, it did so because it introduced new concepts that needed names. Spotify introduced the vocabulary of missions, tribes, squads, guilds, and chapter leads for describing its way of working. It gave the illusion it had created something worthy of needing to learn unusual word choices. However, if we remove the unnecessary synonyms from the ideas, the Spotify model is revealed as a collection of cross-functional teams with too much autonomy and a poor management structure.

When I first learned about “the Spotify model”, I loved the idea of getting to work in a tribe, squad or guild. I thought it sounded pretty cool. I bet it appealed to most developers who've played MMOs before.

Link: Failed #SquadGoals

Tags: #Bookmarks #Agile #SoftwareDevelopmentManagement

Discuss... or leave a comment below.

I was playing around with Visual Studio 2019 and the open source ASP.NET Core blog engine Miniblog.Core. I cloned it to my local, opened it in Visual Studio 2019 and tried to build the solution. I immediately ran into the error below:

Error CS8630 Invalid 'nullable' value: 'Enable' for C# 7.3. Please use language version '8.0' or greater.

So, I looked up the error message and every Stack Overflow page I ended up on, says that I have to set the Language Version in Visual Studio. Okay, so how do I do that? I eventually found this answer, which gives you the steps to get to the Advanced Build Settings dialog box for the project.

  • Right-click YourProject, click Properties
  • Click Build if it's not already selected
  • Change Configuration to All Configurations
  • Click Advanced...
  • Change the language version

When the dialog box showed up however, it didn't give me an option to set the Language Version.

Visual Studio 2019 - Advanced Build Settings

Solution

The solution I ended up with involved manually editing the project file and adding an entry for the Language Version. So, I opened up the Miniblog.Core.csproj file and added <LangVersion>preview</LangVersion> under the <PropertyGroup> settings. It looks like this:

Setting the Language Version manually

Tags: #DotNet #VisualStudio #MiniblogCore

Discuss... or leave a comment below.

Updated: 4/26/2021

Coney complained to me this morning that the YouTube videos on my latest music log entry were getting cut off when viewed from her phone. I've known about this issue for awhile, but didn't really try to find a solution for it. Well, today I did and it turns out to be really easy.

The issue stems from the fact that I have to use iframes to embed videos on write.as sites. To make the YouTube videos I embed on write.as sites responsive, I simply followed the instructions from this Responsive Youtube Embed post. Specifically, these are the changes I added to my journal.

Read more...

If it ain't broke, don't fix it.

The most important software development principle that everyone should be following is “If it ain't broke, don't fix it.” I know, I know, it's not really a principle coming from the realm of computer science or software development, but it should be. Adhering to this sage life advice is just as beneficial when writing code, as it is in everyday life. Forget about trying to master the five SOLID design principles if you can't even follow this one.

If you're constantly trying to fix stuff that wasn't broken to begin with, you're in for a lot of headaches in your software development career. Not to mention, headaches for other developers in your team. If you find a piece of code that is working, that is not causing bugs, that is not causing performance issues, you best leave that piece of code alone.

Tags: #SoftwareDesignPrinciples

Discuss... or leave a comment below.

I was reading this article about Xamarin and Swift when I noticed this useful piece of information at the end:

If Swift continues to take the iOS world by storm, more such documentation may be needed. The February 2020 TIOBE Index, which measures programming language popularity, shows Swift at No. 10, having moved up a full 10 positions from the February 2019 ranking, making it the biggest mover in the top 20. C#, used for Xamarin coding, is at No. 5, moving up from No. 7 last year.

Interesting. That bit of info led me to this, the TIOBE Index.

The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.

The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system.

I see this as a very useful tool for software developers, not just in figuring out what programming language to use when building a new application, but also in figuring out what programming language to learn or focus on to improve your career as a software developer.

I'm glad to see C# making its way up on the list. I thought Python would be on top, but I guess Java is still too popular nowadays. Also, I keep reading about Rust in the dev blogs/websites that I follow. I wonder when it will break into the Top 20 list? Either way, I think this index is a good list to keep our eyes on as software developers.

Tags: #Bookmarks #ProgrammingLanguages

Discuss... or leave a comment below.

This is a great resource for anyone who wants to get started with C# and .NET Core.

Link: Hundreds of practical ASP.NET Core samples to learn the fundamentals

Tags: #Bookmarks #AspDotNet #DotNet #DotNetCore

Discuss... or leave a comment below.

Enter your email to subscribe to updates.