Dennis Gorelik

StackOverflow expertise indicator

2019-09-11T23:00:56Z

~~~~~
https://www.quora.com/What-are-some-signs-that-you-have-become-a-better-software-engineer/answer/Ben-Podgursky
When you start out, you’re confident “bah, any decent answer on StackOverflow has at least 1,000 upvotes”
.....
A few months in, you realize that mostly only the the “help how i code” questions have thousands of upvotes. There are tons of useful answers in the hundreds range
.....
Until you finally become a “senior” engineer. You try to drag one last sip from the StackOverflow Slurpee, and you get nothing but ice and disappointment
~~~~~

comments

Code reuse

2019-03-25T06:52:31Z

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.

comments

Code reuse abuse

2017-08-12T05:43:52Z

--
https://news.ycombinator.com/item?id=14990587
I think it's more likely that your "great programmers" simply understand the difference between the same functionality and accidentally similar functionality. The latter is where you have two use cases that are very similar, so you spend all this time deduplicating. Then one of the use cases changes... The correct response would be to duplicate the code again, because the two use cases are no longer similar. In reality, they should have never been combined in the first case. They weren't the same; they were only accidentally similar.
But instead what you usually see is minor tweaks to the common functions. Pass in a flag here, tweak the inputs there, add an if statement over yonder... And before you know it, it's all a terrible tangled mess that is full of branches and technical debt. The two use cases have the same functions, but don't even follow the same branches within the functions.
--

comments

ElasticSearch Percolator Bloat - the Defense

2017-06-22T14:50:43Z

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

comments

Spark Language vs Apache Spark

2017-06-14T01:19:22Z

Today I learned that Spark programming language has nothing to do with Apache Spark.

That "Spark Language vs Apache Spark" confusion is even worse than "Java vs Javascript" confusion.

comments

Шкафы со скелетами в программировании

2017-02-27T07:32:43Z

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

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

comments

No mistakes - means "too slow"

2017-02-27T06:57:37Z

From "Committing code often" discussion:
It is ok to make mistakes, especially in the first "rapid-fire" version of the code.
There is no shame in it.

Even more: if you are not making any mistakes while coding - that means you are way too careful and are working much slower than you can.
(That does not mean, of course, that you should intentionally do mistakes. Just take greater risks in order to improve speed of programming/coding until you start getting occasional mistakes).

comments

Uri parsing .NET bug

2017-01-26T14:26:20Z

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");
}

comments