As I’m writing this, it’s January, and I see a steady stream of “working on my annual review” tweets. You want something. (We all do.) It could be a raise or a promotion at your current job, a new job, or a board position at a non-profit you love. How do you get that something? You tell people what you’ve already accomplished, and why you deserve more. Why you need to be the one to tell your story What you need to keep in mind, always, is that you are the only one that knows what you have done. Projects you’ve completed, milestones you’ve reached, and goals you’ve conquered haven’t been noticed by everyone. Your manager can’t know everything (and probably doesn’t write down everything she does know). Your team members are too busy taking care of their own work to notice. Your customers are happy you’ve done the work, but don’t know what went into it. No one else is keeping a list of your accomplishments.

This is part 5 of a 5-part series. Part 1 – Planning Part 2 – The Distributor Part 3 – The Publisher Part 4 – The Subscriber Part 5 – Testing Scenario Publishers: servers SQL2014AG1 and SQL2014AG2, database AGTest Distributor: stand-alone server, SQL2014demo Subscriber: Azure SQL Database – server jessqldb2, database ReplicationTest Time to test! Congratulations, you’ve configured a remote distributor, configured all of your AG replicas as publishers, and configured your SQL Database as a subscriber! Now you want to ensure that transactions are replicating to the database, and that they continue to do so if there is a failover in the AG.

This is part 4 of a 5-part series. Part 1 – Planning Part 2 – The Distributor Part 3 – The Publisher Part 4 – The Subscriber Part 5 – Testing Scenario Publishers: servers SQL2014AG1 and SQL2014AG2, database AGTest Distributor: stand-alone server, SQL2014demo Subscriber: Azure SQL Database – server jessqldb2, database ReplicationTest Setting up the replication subscription This subscription is going to use an Azure SQL Database. Go to the AG primary replica. (In this demo, this is SQL2014AG2.)

This is part 3 of a 5-part series. Part 1 – Planning Part 2 – The Distributor Part 3 – The Publisher Part 4 – The Subscriber Part 5 – Testing Scenario Publishers: servers SQL2014AG1 and SQL2014AG2, database AGTest Distributor: stand-alone server, SQL2014demo Subscriber: Azure SQL Database – server jessqldb2, database ReplicationTest Setting up the replication publisher You’ll need to start by configuring the AG current primary as Publisher. (In this demo, this is SQL2014AG2.) Then, you’ll need to configure the distributor that we set up in step 2 to use the AG listener name, rather than the server name.

This is part 2 of a 5-part series. Part 1 – Planning Part 2 – The Distributor Part 3 – The Publisher Part 4 – The Subscriber Part 5 – Testing Scenario Publishers: servers SQL2014AG1 and SQL2014AG2, database AGTest Distributor: stand-alone server, SQL2014demo Subscriber: Azure SQL Database – server jessqldb2, database ReplicationTest Setting up the replication distributor The first step in this process is to set up the remote distributor. As I mentioned in the first blog, you do not want your distribution database on one of the AG replicas. You need to set this up on a server that is not part of the AG.

Throughout the last few years, I’ve worked with SQL Server Availability Groups, Transactional Replication, and Azure SQL Databases. Recently, I had the challenge and opportunity to work on a project that involved all three at the same time. The goal was to take six databases that were in a SQL Server 2012 Availability Group and replicate them to Azure SQL Databases. Both replication of a database in an AG and replication from SQL Server to SQL Database come with several caveats, limitations, and challenges. In this five-post blog series, I hope to share with you the lessons I’ve learned so you can do this correctly from the beginning.

I’ve been playing around lately with a pure command-line Jasmine runner that doesn’t rely on a SpecRunner file to run tests. I work daily with a largish application that is well over 100K lines of front-end code and greater than 7000 front-end tests. Over time as the codebase and test count has grown, our Continuous Integration environment has continued to get slower. While build servers like Jenkins and TeamCity provide some analytics around slow tests, there is still some digging involved to identify the best targets for improvement, something I’m hoping a local runner can make easier.

We’re living in the future. During a conversational aside the other day, the CEO recounted a story of someone he met that was willing to throw money at a product to make it easy to save an excel file and have it surface as an API. A few years ago that was server provisioning and a couple days to a couple weeks of work, depending on the level of analytics, authentication, identity management, documentation, data entry system, and so on you wanted. With the explosion of tools and services we’re seeing in the cloud, now we can do this in an a few hours or less, with 200 lines of code and no servers.

After initially playing around with text processing in my prior post, I added an additional algorithm and cleaned up the logic to make it easier to perform test runs and reuse later. I tweaked the RAKE algorithm implementation and added TextRank into the mix, with full sample code and links to sources available. I’m also using a read-through cache of the unprocessed and processed files so I can see the content and tweak the cleanse logic.

I’ve tripped over this on 2 machines now and end up at the same out of date StackOverflow post, so maybe this will help someone else. Python 3.5, not 3.6, I had that wrong initially 🙂 Situation When you try to print a string with a Unicode character to the console on Windows in Python, you get: UnicodeEncodeError: 'charmap' codec can't encode characters in position 20-21: character maps to <undefined>