A priority queue is a commonly used abstract data type, but it is not adequately provided in Python’s standard library.
Many times in Git, we commit some work only to realize that is a mistake, and we should do another way. The easy way to fix that is to revert the previous commit, a process in which Git creates another commit that undoes exactly everything in the last commit. After that, we move on with the other way and check in commits for that. Before pushing everything to the remote branch, as responsible software engineers :), we sometimes want to “squash” the commits to erase the mistake to keep the commit log clean.
We have all seen it before: intermittent unit test failures. It could be agonizing that unit tests pass locally, but then fail in the Jenkins unit test build.
According to this, the right way of automated testing is that we have lots of unit tests as majority of our overall automated tests, supplemented by a smaller set of functional tests and even fewer sets of integration tests (a.k.a., Test Automation Pyramid). However, for that strategy to work, we should pay attention to unit test performance. It is not productive for us developers to wait 30+ minutes to run unit tests locally, especially when we have multiple check-ins per day. In addition, the runtime will get compounded as we add more unit tests. Here, I list out few commonly observed mistakes to avoid and suggestions that frequently improve Java unit test performance.
In the JSON output shown in the last post, the keys are printed out of order since they are unordered in the internal dictionary
In theory, it does not matter to machines when converting to/from JSON.
However, it sometimes makes sense to humans for the keys to be pretty-printed in order, especially when we need to look for two keys in JSON next to each other or one key before another.
In this post, we looks into converting a plain, simple Python object into JSON. JSON serialization in Java is also provided as an example. In the following post, we will look into a more advanced method of conversion with attributes pretty-printed in order, like in the Java example.
In Qualification Round of Google Code Jam 2016, there is an interesting Coin Jam problem. The summarized problem statement is as follows:
A jamcoin is a string of N ≥ 2 digits with the following properties:
1) Every digit is either 0 or 1.
2) The first digit is 1 and the last digit is 1.
3) If you interpret the string in any base between 2 and 10, inclusive, the resulting number is not prime.
Can you produce J different jamcoins of length N, along with proof that they are legitimate?
For example, for the jamcoin 1001, a possible set of nontrivial divisors for the base 2 through 10 interpretations of the jamcoin would be: 3, 7, 5, 6, 31, 8, 27, 5, and 77, respectively.