Here, we are using Kafka streams in our applications. We are done with the implementation but again, the most important thing left is testing. This blog is about how to test the application we have created. For this, I’ll be taking the sample app I created in my previous blog for both high-level DSL and low-level processor API.
Traditionally, we test our Kafka application with an integration test for which we need to create a ZooKeeper and a real Kafka broker. After that, we need a mock producer and mock consumer for our app to produce the inputs and receive the outputs. That makes it such a big hassle just to test our app. Testing it for real scenarios and for the actual integration test, this is needed without a doubt.
Click through for an example.
The second point I think is particularly interesting. It means:
Ruser who does not consider themselves an expert programmer could be maintaining code that they understand, but could not be expected to create from scratch.
Let’s have some sympathy for the part-time
This is the point we will emphasize in our new example.
Read on for a particular example. I think this is good advice to generalize: write your code to make it as easy as possible for “part-time” users. This applies to custom code you write as well, as unless you are constantly in a particular part of the code base, you’ll forget the details later and have the same problems that a part-timer would have working with a different language.
Recently I needed to create a date dimension for a Power BI model as there was not one in the source database. There are two different ways that I could do this, using DAX from the Modeling Tab within the Data View or using M via the Query Editor window. As a general rule, when it is possible data manipulation should be done in M as it offers a greater level of compression. In this case though I am using a function in DAX, which is not the same as creating a calculated column.
Read on to see code examples for each method, as well as Ginger’s analysis.
Sometimes when a VM is cloned from a template (VMware or Hyper-V) the CID can be duplicated between the two machines. Evidence of this can be seen in the Event Viewer (Event ID 4101). This means the two MSDTC services will not be able to communicate with each other.
A possible error message is:
The Microsoft Distributed Transaction Coordinator (MS DTC) has cancelled the distributed transaction
The MSDTC feature of the Windows operating system requires unique CID values to ensure that MSDTC functionality between computers works correctly. Disk duplicate images of Windows installations must have unique CID values or MSDTC functionality may be impaired. This can occur when using virtual hard disks to deploy an operating system to a virtual machine.
This burned me in the past. Jeff has several scenarios that he walks us through, so if you’re using the Distributed Transaction Coordinator, definitely check this out.
In this example we use a signal color for the past too. Do you notice how the usage of green distracts from the current week which is a red? This suggest we are doing great overall even though at this time, we are doing not so great. It is up to you to decide what you want to communicate. If you are a sports team showing the rank during the season, only the current position would be important. In sales, having 30 weeks of outstanding sales above the target and the current week selling slightly under, it would make sense to show the signal color for the past.
Not to mention making it easier for people with CVD to read your report, something with which the red-green scheme does not do great.
Do you use RIGHT JOINs? I myself rarely use a RIGHT JOIN, I think in the last 17 years or so I have only used a RIGHT JOIN once or twice. I think that RIGHT JOINs confuse people who are new to databases, everything that you can do with a RIGHT JOIN, you can also do with a LEFT JOIN, you just have to flip the query around
So why did I use a RIGHT JOIN then?
Don’t be lazy; switch out those right joins. The trick is that for every RIGHT JOIN statement, there is an equivalent statement which does not use RIGHT JOIN. The percentage of the time that you might benefit from RIGHT JOIN is so low that the fixed costs of mentally processing what’s going on tend to overwhelm the slight benefit of that style of join.
The Challenge: I am going to write about a way to move from Azure SQL Database (Platform as a service) back to a local SQL Server. I did encounter errors on the way but more importantly I have written how to avoid/solve them.
Another key point I made sure that there were no connections to the database when doing the below as I didn’t want in-flight data movement whilst doing it. If you can’t do this, then you should create a copy of the database and work from that.
It’s not a trivial operation, but Arun does walk us through the steps.
In this script you can play with total number of iterations (@i), with increment value [email protected] or with width of a line (STBuffer), but generally, you will have always the same “Archimedean” type of a spiral.
Slava shows us how to build a half-dozen different types of spirals, providing sample code for each.
So, like a dog when it sees a squirrel, when I found out about the problems with
ANSI_WARNINGSI got distracted and started checking out what else I could break with it. Reading through the docs, because I found that it does help even if I have to force myself to do it sometimes, I found a little gem that I wanted to try and replicate. So here’s a reason why you should care about setting
These are two settings where the default value makes a lot of sense.