Dennis Gorelik

From 11 years of maintaining my own codebase I learned that reusing fields is a bad idea that leads to poor code maintainability.
If unrelated methods use the same fields, then graph of field references start looking like a maze that is very hard to understand.
If "UserId" field is called by 19 methods from at least 2 distinct logical groups, then it takes long time to find out if we still need to load UserId from database record in JobAlertRequest().
If count of UserId references was much lower, then such review would take much less time.

Reusing fields (and local variables) is, generally, bad for maintenance.
But reusing methods is, generally, good for maintenance: if we fix bugs in a reused method - all places that use functionality are getting fixed.

ElasticSearch team defends the bloat in ElasticSearch Percolator 5.4
--------
https://github.com/elastic/elasticsearch/issues/25308
If you're not interested in ranking you can easily turn it off, by wrapping the percolate query in a constant_score query.
.....
The percolator tries to tag the queries automatically based on the containing query terms. However it can't do this for all percolator queries, because the percolator doesn't know how to extract meaningful information during indexing for all queries. This is a work in progress and will get better over time. It already has shown a significant performance improvement for cases where the percolator was able to analyze the percolator query correctly at index time.
--------

1) Funny how in order to turn off unneeded feature, application developers have to create an extra wrapper around their query.

2) "work in progress" did not stop ElasticSearch team from breaking backward compatibility and forcing their users to rewrite their legacy code in favor of "work in progress" ElasticSearch 5.4.

3) "a significant performance improvement" is not quantified, and the cases where that improvement happened -
not described.

See also: ElasticSearch Percolator Bloat - part 1

By juan-gandhi:
---
1) Мутабельные ключи в "хашмапе".
2) Стек для регистрации данных для последующей проверки, что мусора не осталось. Т.к. указатель на стек глобальный, а бегают несколько ниток, то чистый абсурд.
3) Класс на 183 метода, 0 тестов.
4) Регулярно, случайным образом, рушащиеся тесты, и святая вера, что "за последние несколько лет у нас ничего не ломалось".
5) Вера в то, что у нас все очень "эффективно" - и регулярные жалобы юзеров, что наш код очень медленный, в отличие от скального конкурента (!)
6) "Оптимистический мерж" - "это не мой тест упал, я тут не при чем, нам нужно релизить.
---

1) Интересно, зачем кому-то понадобилось делать мутабельные ключи в хашмапе?
2) Мне лично не встечалось, хотя при работе в multithread environment каких только ляпов не сделаешь...
3), 4), 5), 6) - мне в том или ином виде встречалось.

Normally, in case of invalid input Uri() code throws UriFormatException. But with really weird input Uri(baseUri, Url) overload can produce NullReferenceException:

[TestMethod]
[ExpectedException(typeof(NullReferenceException))]
public void UriFailureTest()
{
    new Uri(
        new Uri("https://jobs.web.cern.ch/content/cern-jobs-insight/what-are-we-doing-while-you%E2%80%99re-waiting"),
        "https:/jobs.web.cern.ch/content/cern-jobs-insight/what-are-we-doing-while-you%E2%80%99re-waiting");
}

When users open my web site I want to know what JavaScript errors users have (if any).
That's why I append this javascript to almost every page on my web site:

window.onerror = function(errmessage, errurl, errline) {
	var params = {
		list: [],
		add: function(name, value) {
			if (value != null) this.list.push(name + '=' + encodeURIComponent(value));
			return this;
		},
		toString: function() {
			if (this.list.length) return '?' + this.list.join('&');
			return '';
		}
	};
	new Image().src='/jeh' + params.add('errmessage', errmessage)
		.add('errurl', errurl)
		.add('errline', errline)
		.add('r', Math.floor((Math.random() * 10) + 1));
}

That script reports javascript errors from user browser back to our server.
Once per day our server aggregates these errors and emails to developers Javascript Errors report.
This is an example of what that report looks like:


We then review these errors on case-by-case basis and decide whether we want to fix that error or we want to suppress that error from report (because we can not fix it).

Still, there are challenges: sometimes it is hard to separate errors that we can fix from errors we can not fix.
For example, we can not fix the most frequent "Uncaught ReferenceError: google is not defined" error, because it is caused by occasional browsers that do not work well with Google Maps API.
But we do not want to suppress that error either, because sometimes, by mistake, we may introduce problem in our own javascript that would generate the same error messages on mass scale for our users.

See: discussion in ivan-gandhi blog.