Представьте: вы матерый созвонщик. У вас по три созвона на каждый день недели, и все на русском. Вы знаете все фразы наизусть: «Коллеги, меня слышно?», «Давайте я расшарю экран», «Кто еще не подключился?». Эти формулировки срабатывают на автопилоте, вы даже не задумываетесь.

А теперь по стечению обстоятельств вы оказываетесь в англоязычном коллективе. Те же самые созвоны, та же повестка, но теперь все на английском. И вот тут начинается самое интересное. Мозг следует привычным скриптам и начинает переводить фразы дословно: “Colleagues, do you hear me?”, “Let me share my screen to you”, “Who else didn't connect?”.

Привет! Это команда курсов английского в Практикуме. Давайте разберем, когда такой «рунглиш» может проявиться на созвонах, и узнаем, как звучать естественно. Если вам английский уже абсолютно понятен и таких ошибок вы не допускаете — пролистайте хотя бы ради подборки полезных фраз. Их здесь много.

В распределённых базах данных YDB, CockroachDB по умолчанию используется уровень изоляции SERIALIZABLE. В PostgreSQL, Oracle Database, MySQL по умолчанию используется READ COMMITED. В стандарте SQL указаны только три аномалии. В статье приводится пример аномалии потерянного обновления в задаче "списания средств" и рассматривается, почему уровень READ COMMITED и ограничения целостности достаточны для решения задачи.

Если с данными (строками таблиц) работает одна сессия в базе данных, то разницы между уровнями изоляции транзакций нет, так как нет транзакций, от которых нужно изолироваться. Если есть несколько транзакций, которые пересекаются во времени, то нужно обращать внимание на то, что параллельно с теми же данными  работают другие транзакции. Другими  словами, учитывать особенности (феномены, аномалии) "конкурентного доступа".

Очередной пост по личным впечатлениям, написанный в минуты отдыха (читай: прокрастинации). И, конечно, снова о работе! (irony mode:on) На этот раз — про рабочие инструменты. (irony mode:off) Основано на реальном опыте: когда-то я выстраивал систему работы с контентом в стартапе с нуля.

Когда я пришёл в новую команду, сперва просто впал в ступор: задачи разлетались по чатам, созданным непонятно кем, дедлайны плыли, контроль держался исключительно на напоминаниях. А мне в этом всём предстояло наладить выпуск материалов.

Разбирался я поэтапно, но в детали вдаваться не буду — специфические нюансы контент-менеджмента вряд ли пригодятся разработчикам, тестировщикам или дизайнерам. Зато вот этап, который применим в любой команде — выбор системы управления задачами.

Так как я за этим рынком постоянно не слежу, пришлось порядочно походить по сайтам систем и пересмотреть с десяток обзоров. После всего этого понял простую вещь: идеальной системы нет. Все они строятся вокруг одной концепции — канбан-доски.

Но какие из них действительно стоят внимания? И причём тут вообще кофе?

Пожалуй каждый программист, который сталкивался с вопросом: "А как устроиться на работу в FAANG?" - получал ответ, что ему нужно разобраться с алгоритмами, со структурами данных и прорешать порядка 300-400 задач на leetcode по алгоритмам.

Однако вслед за этим советом тут же появляются люди, которые говорят, что это никоим образом не делает тебя лучше, как программиста. Да и вообще - просто пустая трата времени.

Поэтому, в этой статье я постараюсь дать ответ, насколько это может быть полезным для работы и развития, и как может сказаться на карьере.

Любая деятельность генерирует данные. Чем бы вы ни занимались, у вас наверняка на руках кладезь необработаной полезной информации, ну или хотя бы доступ к его источнику.

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

У вас есть свой бизнес? Или может… хотя, не важно. Сам процесс добычи данных бесконечен и увлекателен. И даже просто хорошо покопавшись в интернете можно найти себе поле для деятельности.

Вот, что мы имеем сегодня – Неофициальная XML-база раздач сайта RuTracker.ORG. База обновляется раз в полгода и содержит в себе информацию о всех раздачах за историю существования данного торрент-трекера.

Что она может рассказать владельцам рутрекера? А непосредственным пособникам пиратства в интернете? Или обычному юзеру, увлекающемуся аниме, например?

Цитата анонимного тимлида о том, как он обычно готовит текст:

«Написание статьи технические специалисты обычно воспринимают так: автор сформулировал тему, немного подумал, сел и выдал текст сразу на чистовик.

Естественно, в реальности все работает по-другому. Из-за этого — разрыв идеализированного шаблона, разочарование, депрессия и вообще тепловая смерть вселенной.

Я пытаюсь научить ребят из своей команды другому подходу. Но получается так себе, потому что еще сам нормально не освоил метод и постоянно соскакиваю на «сел и сразу написал».

У обычного смертного нет понимания, из каких этапов состоит задача «написать статью». Точно так, как многие в общих чертах уверены, что написать картину — это всего лишь взять краски и холст, а не сделать сто экскизов и тысячу попыток.

С редактурой черновика все то же самое — я сажусь и вычитываю наискосок весь текст, пытаясь заметить «кривые моменты», и долго думаю, как сделать ровнее (устаю и бросаю)».

За 4,5 года работы редактором в блоге Netpeak я помогла специалистам компании написать и опубликовать сотни постов для корпоративного блога. Поделюсь личным опытом, как, несмотря на приступы перфекционизма, довожу черновики до публикации.

Краткое содержание предыдущих частей

Коммиты и конструктивная критика приветствуются