Как я придумал тесты в Instagram раньше чем Instagram

Субъективно. Я имел в виду, что в текущем Instagram формат простой - 1 тест и сразу результат. А в моем варианте, например, можно было пройти 10 вопросов и получить какой-то итоговый результат.

Как работают криптовалюты. С картинками

Не совсем так. Я на самом деле тоже не знал толком, пока не прочитал эту статью. А именно - я не знал как вычисляется хэш и что при майнинге хэши сравниваются. Поэтому перевел и опубликовал.

Как писать условия в JSX

Привет, хорошо, больше не буду.

Я могу подредактировать, если какие-то конструкции бросаются вам в глаза, пишите. Написал в ПМ.

Как НЕ надо учить TypeScript

Пожалуйста https://unsplash.com/photos/KQBE5nFh30k

Как НЕ надо учить TypeScript

Что не так с выделенной частью?

Как разработчику применять принципы лидерства Amazon

В гугле пишут, что Organization and Leadership Review.

Как разработчику применять принципы лидерства Amazon

Я согласен. И одновременно согласен что представить хоть какой-то логичный план на 5 лет покажет что вы подумали о будущем. А это с какой-то вероятностью значит, что во время когда все изменится, вы опять сможете подумать о будущем.

Как разработчику применять принципы лидерства Amazon

Да, вы правы. Но судя по тому что я знаю, от друзей которые работают в Amazon, проверка на прочность тоже подходит :)

Как разработчику применять принципы лидерства Amazon

Ну тут каждый выбирает свое, с одной стороны испытание, с другой большее количество денег. Трейдофф.

Рождественские календари для разработчиков

Спасибо, добавил

Рождественские календари для разработчиков

Согласен, в этом тексте удельный вес про канал и не про канал как-то не в пользу разумного. Уберу последний абзац.

git bisect: путешествие по времени и багам

N все еще количество коммитов. Просто если взять 15 коммитов и все вручную проверить, то на 5-ом начнешь уставать, а к 10-му совсем будешь фрустрирован ?.

А если взять бинарный вариант, то знаешь что за 4 раза справишься ?.

Я так себе объясняю идею автора.

git bisect: путешествие по времени и багам

Я думаю это смелое предположение. Куча людей подходят к куче вещей бессистемно. Поиск бага вряд ли является исключением.

git bisect: путешествие по времени и багам

Я думал автор имел в виду просмотр коммита + запуск тестов + накапливающуюся когнитивную сложность. Но гарантий дать не могу, это перевод.

Храним данные в JSONB, как это влияет на скорость запросов?

Я разворачиваю jsonb в рекордсет при запросе jsonb_to_recordset, согласно документации (https://www.postgresql.org/docs/9.4/functions-json.html) это JSON Processing Function.

Храним данные в JSONB, как это влияет на скорость запросов?

Спасибо за фидбэк

Храним данные в JSONB, как это влияет на скорость запросов?

Спасибо за фидбэк. Отвечая на ваши вопросы:

1. Какая альтернатива? Это может быть частью jsonb_to_recordset?

2. Наверное вы имеете в виду history_a(где JSONB). Верно дописывать было бы не слишком удобно, но у нас данные immutable.

Храним данные в JSONB, как это влияет на скорость запросов?

Я отвечал на такой вопрос - если мы данные храним эстетически красиво и компактно (для меня это вариант с JSONB), будет ли это драматически влиять на производительность? Ответ оказался - нет, не будет.

Храним данные в JSONB, как это влияет на скорость запросов?

Спасибо за комментарий, хочу уточнить, в моем эксперименте я проверял работу по умолчанию. Задачи оптимизировать запросы не было, потому что они не являются сейчас бутылочным горлышком.

Вот полный EXPLAIN реляционного запроса:

Finalize Aggregate  (cost=45949.77..45949.78 rows=1 width=8) (actual time=191.621..191.621 rows=1 loops=1)                                              |
  ->  Gather  (cost=45949.56..45949.77 rows=2 width=8) (actual time=191.490..196.400 rows=3 loops=1)                                                    |
        Workers Planned: 2                                                                                                                              |
        Workers Launched: 2                                                                                                                             |
        ->  Partial Aggregate  (cost=44949.56..44949.57 rows=1 width=8) (actual time=171.319..171.319 rows=1 loops=3)                                   |
              ->  Nested Loop  (cost=0.42..44949.56 rows=1 width=0) (actual time=171.314..171.314 rows=0 loops=3)                                       |
                    ->  Parallel Seq Scan on history_b_results hbr  (cost=0.00..43934.00 rows=124 width=4) (actual time=171.313..171.313 rows=0 loops=3)|
                          Filter: (expiration_date > (CURRENT_DATE - 10))                                                                               |
                          Rows Removed by Filter: 1000000                                                                                               |
                    ->  Index Scan using history_b_pkey on history_b hb  (cost=0.42..8.19 rows=1 width=4) (never executed)                              |
                          Index Cond: (id = hbr.history_b_id)                                                                                           |
                          Filter: ((customer_uuid)::text = '7e240a94-261b-4eeb-b0d3-8c6de47d9557'::text)                                                |
Planning Time: 0.148 ms                                                                                                                                 |
Execution Time: 196.466 ms                                                                                                                              |

Храним данные в JSONB, как это влияет на скорость запросов?

Все верно, как я говорил, в нашем кейсе данные не будут расти и по всем данным выборка тоже не будет применяться. Только с фильтром по customer_uuid (на котором есть индекс), а у каждого конкретного пользователя количество данных маленькое.