Voice of the DBA

Tag: SQLServerCentral

SQLServerCentral Design Decisions–Forum Threads

It’s been a long couple of weeks. Almost two weeks ago we cut over from our older, v2 version of the site to the new (and current) v3. Lots of bugs, lots of disruption, and lots of unexpected items.

As a bit of trying to help me understand as well as a catharsis, I wanted to jot a few thoughts on things that I’ve had to make decisions on or work within our framework. This post looks at one small item, the display of forum posts.

The New Look

Here’s the top of a thread in the current site.

A post and two responses, and I think it’s easy to see who’s posted, their avatar, the text and content, I can follow a user or send a message, I can reply or quote a post. My signature is small and a different font from the text.

Here’s another couple posts, which I think are harder to read:

These are older signatures, which don’t format as well, and some of the quoting is a little broken and causing issues.

I don’t think the new format is necessarily more visually appealing to me, but it is less elements and a cleaner look in a more modern style. For everyone that liked the old format, we have people that didn’t.

And vice versa.

In this new format, we took the default bbPress items and tried to aim for less extraneous information. We styled this to have less color and contrast that is distracting while presenting the information that users need to see. We limited the options, of which we had too many and confused people in the older forums.

This also gives us a good codebase on which we can make future changes. While many of those aren’t visible here, the pace and breadth of changes we’ve made in the last two weeks to tweak things is way above anything we went through the last time we touched the forums. I’m amazed at how well we’ve adapted to new areas and requirements as we go along.

That being said, I know there are lots more changes to make and look for more to be coming in the next few months. We’ll change the styles slightly and perhaps redo some of the layout to make things easier.

One thing this project has taught me is that what I think is a simple decision for software isn’t so simple for my users. We have thousands, really hundreds of thousands of users and some days it feels like none of them are pleased. I couldn’t imagine how hard it is when your software or site has 10x or 100x that size.

April 12, 2019
Fun with Dates and Times

The other day I got a Github issue that asked if we here at SQLServerCentral should set our dates as YYYYMMDD in the new SQLServerCentral site. The issue noted that there were some inconsistent dates. Article dates are in a similar format, YYYY/MM/DD, but we do have some DD MMM YYYY and a few places where I think the American MMBBYYYY has lived on.

In any case, I made a joke on Twitter of asking if people were alright moving to YYYYMMDD. Most people were in favor, though someone asked about MMMM DD, YYYY, which is easily read. I have to say that I somewhat like that for reading, but as data, as something I’d work with, I prefer having the year month day format. I do want separators, and while I grew up using slashes ( as in YYYY/MM/DD), I know the ISO format is dashes (YYYY-MM-DD). ISO 8601 has dashes, so I decided to add that to the GitHub issue as a way of formatting.

What about using month names? As I look through various sites, I find inconsistencies. Some use dates, like Jan 11, 2019. Others might use 11 Jan 2019 or 2019-01-11. I find that MSDN uses regional settings, so the en-us version of a page will have 01/11/2019, but if I change to the en-Gb version, I see 11/01/2019. That seems find as a UI enhancement, but I hope that the actual value is stored as 2019-01-11. We don’t need them time

Or do we? There are times involved. While most of us might not care about whether something was published at 8am or 9am, we might care about where it was published and the time. Certainly 8am in Christchurch if far different from 8am in Honolulu. Do we store time zones? Or keep all dates in one? The logical thing is to keep dates in UTC and then adjust based on the client settings to display something that matches their time zone. We’ve been storing data in UTC, though the server time has been the Mountain time zone in the US for historical reasons. I don’t like that dependency, so I’m sure we’ll change that.

Dates and times are both simple and not simple. There are decisions to be made, and far too many of us take them lightly. While the display is of secondary importance, it’s likely that we’ll often use this data in other systems, as a way of marking a change, or even as a way of ordering our data. Having consistent and known date time formats is important as a data professional. I hope you pay attention to how you gather and store this data.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.3MB) podcast or subscribe to the feed at iTunes and Libsyn.

January 16, 2019
Porting SQLServerCentral

Like a few of you, I’ve been working with WordPress as a blogging platform. Over the years I’ve tried a few different pieces of blogging software, but I really like WordPress. I’m not alone as there are estimates that 20-30% of all websites run on this platform, including a few you might not expect. I thought UpperCup and Krispy Kreme UK are sites that don’t really look like they’re powered by WordPress. Those make my own blog and T-SQL Tuesday look pretty bland. Maybe I’ll do a little design work at some point on those. That’s after SQLServerCentral moves over to the platform.

SQLServerCentral started as a custom ASP site many years ago, then upgraded to ASP.NET at some point. This was a joint effort from the founders to build in new functionality and features as we needed them, purchasing components (like the forums) where we found a suitable product. This first evolution of the site lasted for many years until Redgate Software acquired the property. We then underwent a second platform shift to NHibernate, which has been underpinning the site for a decade. We now move forward with our third evolution.

We have a project underway that is porting our site to WordPress, for a variety of reasons. Like many of you, I struggle to get resources assigned from my employer for the projects that I’m passionate about if they don’t rise in importance above other things being worked on. There are only so many resources available, and they must be shared by the company. While Redgate values SQLServerCentral, we have a site that works well, and has worked well for many years. Thus, it’s not the same priority as some of the other projects in the company. Since we have some requirements around better mobile support thanks to Google, we had to move in some direction.

We have struggled with skillsets over the years as most of our web developers aren’t well versed in NHibernate as we’ve moved many of our other web projects to WordPress or more basic technologies like React. Building all the various features from scratch would be a big project, not to mention a constant maintenance headache, so after reviewing some responses to our RFP, we decided to go with WordPress, under Project Nami. This is an open source project that replaces MySQL with SQL Server. While I run MySQL on T-SQL Tuesday, one of our key requirements was that we use SQL Server as a database, and Project Nami allows us to do this. Since there are numerous people with WordPress skills, and lots of plugins that can be easily added (or removed), our view is that WordPress will allow us to grow and change the site over time with fewer resource constraints.

The last few months have been a long, drawn out project as we needed a number of custom plugins written, or existing ones adapter for some of the functions on the site. At its heart, SQLServerCentral is a rather unique publishing platform, and we needed to preserve much of this functionality. As with most projects, we’ve run over time and budget a bit, but we’re now getting close. I don’t have a date yet, but I anticipate we’ll add more user testing in January and then make a switch sometime later in the month.

I hope that you’ll find the new platform to be very similar to what we have now. Our goal was to change relatively little in terms of functionality and minimize the look and feel changes. There are some, but I don’t think they are too disruptive. However, we will be looking for feedback and make decisions on what things we’d like to change or adapt for the future. Keep an eye out for more announcements and fingers crossed that everything goes smoothly during the deployment.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 5.6MB) podcast or subscribe to the feed at iTunes and Libsyn.

December 27, 2018
Moving to AWS EC2

SQLServerCentral has been stuck in the past for some time, but we’ve finally decided to move. I’ve been asking for this, and it’s usually a resource issue. However, earlier this year we started to debate and examine the costs, and decided to pursue a move to EC2. We have other infrastructure there, VPNs setup to connect, and this made the most sense.

I was excited. The last time we upgraded, we left SQL Server 2000 for SQL Server 2008 R2. That was a long time ago, and at the time, I wasn’t sure that 2008 R2 was a big change. We used the core engine only, and it didn’t seem that this was that cost effective a move for us. Now I wish we’d delayed another year and moved to 2012.

We’re moving into the current era, choosing to run on SQL Server 2017. I’ll have access to lots of the latest and greatest T-SQL, which will help with some of our complex reporting tasks.

Cutover

I didn’t do the work, but one of our engineers practiced a backup and restore, and then setup log shipping to limit the downtime. After a few days of testing, and a few of us running the new site through our own tests, we made the cutover.

Total downtime, about 35 minutes to quiesce the old system, get the last logs copied over, and then move networking.

And we’re live.

We have six Basic Availability Groups setup. We could potentially have issues with a failover in that it’s possible that a user does something in one BAG that doesn’t make it to the other side, but in practice, it’s not a concern. We don’t deal with sensitive information, and likely any data lots can be manually moved.

This was the most cost effective move for us, roughly equivalent hardware, though we moved from physical db servers at Rackspace to VMs in EC2. However, we’re now on modern versions of Windows, SQL, and more importantly, .NET. That last item was slowing some development items, so we can now start to move forward with future development.

March 28, 2018