weekly update

_posts/mini_posts/2020-04-10-working-with-time.md

@@ -1,7 +1,7 @@
 ---
 layout: post
 title: Работа со временем
-tags: [bestpractices]
+tags: [bestpractices, time]
 ---
 Если у вас есть возможность - никогда не работайте с человеческим временем, когда программируете. Потому что сделать все правильно нереально тяжело. Начиная с високосных годов:
 

_posts/mini_posts/2020-05-29-unix-datetime-converter.md

@@ -1,7 +1,7 @@
 ---
 layout: post
 title: Преобразование unix-timestamp в человеческую дату
-tags: [linux, cli]
+tags: [linux, cli, time]
 ---
 Годами я использовал онлайн сервисы типа [epochconverter](https://www.epochconverter.com/), чтобы из временной метки 1590735600 получить "Friday, May 29, 2020 10:00:00 AM GMT+03:00". На днях узнал, что это можно сделать и в консоли:
 ```

_posts/mini_posts/2020-08-13-java-dates.md

@@ -1,7 +1,7 @@
 ---
 layout: post
 title: Типы дат java.time
-tags: [java]
+tags: [java, time]
 ---
 С java.time жить можно, хотя Joda Time у автора получился поудобнее. Памятка про отличия различных типов.
 TLDR: `LocalDateTime` с большой вероятностью бэкэндщику не нужен, а `OffsetDateTime` покроет большинство бытовых кейсов.

_posts/mini_posts/2021-07-20-hibernate-offsetdatetime.md

@@ -1,7 +1,7 @@
 ---
 layout: post
 title: OffsetDateTime и Hibernate
-tags: [бд, sql, java]
+tags: [бд, sql, java, time]
 ---
 При работе с датами Hibernate стоит быть аккуратным: он все типы конвертирует в java.sql.Timestamp, который по смыслу [идентичен](/2020/08/13/java-dates.html) java.time.Instant. Поэтому информация о временной зоне будет потеряна: при чтении из базы в какой-нибудь OffsetDateTime будет [подставлена системная зона](https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core/src/main/java/org/hibernate/type/descriptor/java/OffsetDateTimeJavaDescriptor.java). Так что проще сразу маппить на Instant во избежание недоразумений. Матерые Java-чемпионы так и [говорят](https://vladmihalcea.com/date-timestamp-jpa-hibernate/), что OffsetDateTime и ZonedDateTime для JPA не очень полезны. И вообще, можно [стрельнуть](https://stackoverflow.com/questions/61656592/offsetdatetime-persisted-by-jpa-differs-by-2-hours) себе в ногу с ними.
 

_posts/mini_posts/2024-05-28-engineering-culture.md

@@ -0,0 +1,26 @@
+---
+layout: post
+title: Инженерная культура
+tags: [teamlead]
+---
+Хороший [доклад](https://www.youtube.com/watch?v=vH3Iphod97s) про то, что такое культура разработки, чем она полезна и с некоторыми идеями, как ее улучшить. Выгодно выделяется хоть какой-то конкретикой на фоне стандартного буллшита про повышение надоев и за все хорошее, который видел в большинстве статей на тему.
+
+Из интересного: 
+- У компании есть (бывает) видение (куда идем), миссия (зачем) и культура: "что мы себе позволяем по пути".
+- Важный аспект культуры — управление ожиданиями.
+- У культуры обычно есть авторы, которым это интересно и которые радеют за все это.
+- Талмуд разводить не надо, но лучше зафиксировать основные ценности для упрощения принятия решений письменно.
+- Есть ссылки на 4 готовых описаний культуры от разных компаний.
+
+Как внедрять:
+1. Написать документ;
+2. Обсудить с инженерами, распространять через агентов влияния;
+3. Поощрять за хорошее и карать за плохое;
+4. Расставаться с несогласными (sic!);
+5. Регулярно пересматривать, чтобы было не как у мартышек.
+
+Под конец печальный вывод: если вы хотите сделать хорошо в одном отделе, а в соседнем глотки грызут — лучше покинуть компанию, потому что это нежизнеспособоно, вы долго сами не продержитесь (кажется я так и ушел из пары мест).
+
+Какие-то полезные мысли по теме есть еще [тут](https://www.insart.com/signals/building-a-winning-engineering-culture). Стоит определить какие-то базовые ценности (например, что важнее, ответить коллеге или доделать свой тикет), неплохо иметь метрики, а двигать все это лучше авторитетным чувакам, т.к. менять подходы людей к работе [весьма](/2024/03/05/capability-trap.html) [тяжко](/2021/11/30/hard-problems-of-development.html).
+
+Вообще по ощущениям если много людей не укладывается в культуру, то лишний в ней — ты. И это ошибка найма :/

_posts/mini_posts/2024-05-30-scheduled-jobs.md

@@ -0,0 +1,9 @@
+---
+layout: post
+title: Долгой круглое время!
+tags: [time, telegram]
+---
+Давненько заметил за телегой не очень строгое следование расписанию: если запланировал пост на 10:00, то он опубликуется обычно в 10:02-10:05, и со временем проблема становилась заметнее: можно посмотреть по истории постов канала. Вполне очевидно, почему так происходит: алгоритм отложек не идеален и все больше людей пользуется фичей. "Вас тут много, а я одна!". И лайфхак для решения проблемы очень простой — поставить в расписании 9:59 (~~по цене 9.99~~).
+
+Он пригодится и в других контекстах. Ни для кого не секрет, что люди по умолчанию выбирают круглые даты и числа. И программисты — не исключение. Поэтому всякие работы по расписанию (например, очистка БД от мусора в ночное время) лучше ставить не тупо на полночь, а на на случайный час со случайными минутами — чтобы была меньше вероятность запуститься с чем-то одновременно. Конечно, в идеальном мире должен быть хороший планировщик, но кого мы обманываем с этими микросервисами?
+

_posts/mini_posts/2024-05-31-reverse-turing-test.md

@@ -0,0 +1,7 @@
+---
+layout: post
+title: Тест Тьюринга наоборот
+tags: [ai]
+---
+Занятный [видос](https://youtube.com/watch?v=MxTWLm9vT_o).
+