Подготовка к интервью в Тинькофф
В крупные ИТ-компании приходит большой поток желающих трудоустроиться. Эти компании вынуждены формализовывать процесс найма, в рамках которого требуются как реально важные в работе скиллы, так и сопутствующие навыки, часть из которых нужна только в рамках собеседования. Сюда относится и вопросы уровня "почему люки круглые", программирование у доски и всякое такое.
Посмотрим на процесс найма в Тинькофф. На странице описан общих ход ИТ-собеседований в компанию и детали по каждому из направлений — frontend, backend, мобильная разработка, SRE, машинное обучение, QA и BI-аналитика.
Ценность представляют материалы для подготовки. Например, для backend техническое собеседование состоит из трёх секций:
– секция по платформе или языку
– алгоритмы
– дизайн распределённых систем, он же system design
На странице даны ссылки на классические сайты типа leetcode / hackerrank / codeforces, ссылки на качественные курсы по алгоритмам на coursera, классические книжки: Кормен по алгоритмам и Cracking the Coding Interview. По system design даны и те ресурсы, о которых мы уже писали, и другие: Architectural Katas и "Высоконагруженные приложения" Мартина Клеппмана.
Для подготовки к SRE даны ровно те же источники. SRE – это Site Reliability Engineering, такие ребятки, которые отвечают за бесперебойную работу высоконагруженных сервисов. Такая смесь девопса, админа и разработчика, в результате чего под SRE понимают очень широкую область работы и в каждой компании свою. Несмотря на те же источники, секции несколько отличаются:
– алгоритмы
– system design
– выявление и устранение проблем. Дана архитектура и описан сбой. Цель – выявить проблему и предложить фикс
– общие технические вопросы – Linux, сети, базы данных
Для machine learning специалиста три секции:
– алгоритмы
– ML
– ML-design
Начало по литкоду и алгоритмам такое же, но дальше добавляется специфика ML. Тут платные и бесплатные книги по статистике, pattern recognition и глубокому обучению, подборка
awesome-machine-learning и сайт по deep learning от Ian Goodfellow, который создал GAN и о котором мы писали. Тут же ссылки на 4 проекта с набором вопросов к собеседованию по ML и ссылки на пачку бесплатных материалов курсам: яндексовые deep learning, reinforcement learning, NLP, он же Natural Language Processing, курс от Catalyst, битая ссылка на курс Machine Learning for Data Analysis на курсере (вот правильный линк) и подборку курсов по ML. Есть отдельный блок по дизайну ML-систем с набором ресурсов.
#skills #резюме
В крупные ИТ-компании приходит большой поток желающих трудоустроиться. Эти компании вынуждены формализовывать процесс найма, в рамках которого требуются как реально важные в работе скиллы, так и сопутствующие навыки, часть из которых нужна только в рамках собеседования. Сюда относится и вопросы уровня "почему люки круглые", программирование у доски и всякое такое.
Посмотрим на процесс найма в Тинькофф. На странице описан общих ход ИТ-собеседований в компанию и детали по каждому из направлений — frontend, backend, мобильная разработка, SRE, машинное обучение, QA и BI-аналитика.
Ценность представляют материалы для подготовки. Например, для backend техническое собеседование состоит из трёх секций:
– секция по платформе или языку
– алгоритмы
– дизайн распределённых систем, он же system design
На странице даны ссылки на классические сайты типа leetcode / hackerrank / codeforces, ссылки на качественные курсы по алгоритмам на coursera, классические книжки: Кормен по алгоритмам и Cracking the Coding Interview. По system design даны и те ресурсы, о которых мы уже писали, и другие: Architectural Katas и "Высоконагруженные приложения" Мартина Клеппмана.
Для подготовки к SRE даны ровно те же источники. SRE – это Site Reliability Engineering, такие ребятки, которые отвечают за бесперебойную работу высоконагруженных сервисов. Такая смесь девопса, админа и разработчика, в результате чего под SRE понимают очень широкую область работы и в каждой компании свою. Несмотря на те же источники, секции несколько отличаются:
– алгоритмы
– system design
– выявление и устранение проблем. Дана архитектура и описан сбой. Цель – выявить проблему и предложить фикс
– общие технические вопросы – Linux, сети, базы данных
Для machine learning специалиста три секции:
– алгоритмы
– ML
– ML-design
Начало по литкоду и алгоритмам такое же, но дальше добавляется специфика ML. Тут платные и бесплатные книги по статистике, pattern recognition и глубокому обучению, подборка
awesome-machine-learning и сайт по deep learning от Ian Goodfellow, который создал GAN и о котором мы писали. Тут же ссылки на 4 проекта с набором вопросов к собеседованию по ML и ссылки на пачку бесплатных материалов курсам: яндексовые deep learning, reinforcement learning, NLP, он же Natural Language Processing, курс от Catalyst, битая ссылка на курс Machine Learning for Data Analysis на курсере (вот правильный линк) и подборку курсов по ML. Есть отдельный блок по дизайну ML-систем с набором ресурсов.
#skills #резюме
Telegram
DevFM
Как сдвинуть гору Фудзи
Классическая книжка про подготовку к собеседованиям в Microsoft. Написана аж в 2003 году, но по факту покрывает практику собеседований примерно с 2000 по 2015 годы в компаниях из FAANG (Facebook/Meta*, Amazon, Apple, Netflix, Google/Alphabet)…
Классическая книжка про подготовку к собеседованиям в Microsoft. Написана аж в 2003 году, но по факту покрывает практику собеседований примерно с 2000 по 2015 годы в компаниях из FAANG (Facebook/Meta*, Amazon, Apple, Netflix, Google/Alphabet)…
🔥7❤3👍3🌭2⚡1
The Lesson to Unlearn — Вредные уроки
Мы уже вспоминали эссе Пола Грэма о хорошей и плохой прокрастинации. Рекомендуем прочитать его эссе "Вредные уроки". Ниже дадим ряд выдержек.
Самый вредный навык, привитый вам учебными заведениями — умение получать хорошие оценки. Важны знания, а не оценки. Автор вспоминает, что в студенческое время максимум усилий в учёбе он прилагал только во время подготовки к экзаменам. В теории, вы получаете знания по предмету на лекциях, при чтении дополнительных материалов и выполнении заданий, а экзамен потом показывает, насколько хорошо вы эти знания усвоили. На практике же интенсивная подготовка идёт только к экзаменам и почти никогда — во время семестра.
Следующая проблема вытекает из предыдущей. Время подготовки ограничено, поэтому нужно выбрать, что именно ботать. Во время подготовки можно пропускать все темы, которые не встречаются в билетах, всё дополнительное и интересное. Более того, преподаватели склонны иметь любимые вопросы, значит, можно готовиться только к ним. Если мы говорим о тестах, то вообще нужно готовиться строго по вопросам. Привет, ЕГЭ!
Автор идёт дальше, утверждая, что любые формы оценки знаний заменяют цель "научиться" на цель "научиться проходить оценку успешно". Поэтому поступление в ВУЗ превращается в попытку угодить вкусу определённой группы людей — приёмной комиссии.
Хуже всего в системе образования то, что она учит вас достигать успеха за счёт хитрости. Эту проблему автор иллюстрирует собственным опытом из консультирования стартапов, где начинающие бизнесмены пытались найти "уловку, чтобы привлечь финансирование в проект". Автор раз за разом объяснял им, что главное для инвестора — это перспективность стартапа в виде будущего роста, а не какие-то формальные признаки успешности.
После этого автор очень тесно переплетает проблемы стартапов и образования, сравнивая старую и новую модели общества. В старой модели общества во главе угла стояло продвижение по карьерной лестнице путём соблюдения правил. Чем дольше человек был на одном месте, тем ценнее он считался. Сейчас всё изменилось. Появилась масса способов разбогатеть, работая на совесть, и частично поэтому люди стали больше стремиться к тому, чтобы разбогатеть.
Умение взломать неэффективный тест становится всё менее важным по мере ослабевания взаимосвязи между работой и вышестоящими инстанциями.
Наше видение: в ИТ индустрии мало обращают внимание на дипломы и сертификаты. При этом вокруг собеседований сложилась дикая ситуация, когда задаваемые вопросы нередко очень далеки от реально выполняемых задач. Годы идут, а ситуация не выравнивается — подготовка к собеседованию превратилась в отдельную отрасль, и решения этой проблеме не видно.
#edu
Мы уже вспоминали эссе Пола Грэма о хорошей и плохой прокрастинации. Рекомендуем прочитать его эссе "Вредные уроки". Ниже дадим ряд выдержек.
Самый вредный навык, привитый вам учебными заведениями — умение получать хорошие оценки. Важны знания, а не оценки. Автор вспоминает, что в студенческое время максимум усилий в учёбе он прилагал только во время подготовки к экзаменам. В теории, вы получаете знания по предмету на лекциях, при чтении дополнительных материалов и выполнении заданий, а экзамен потом показывает, насколько хорошо вы эти знания усвоили. На практике же интенсивная подготовка идёт только к экзаменам и почти никогда — во время семестра.
Следующая проблема вытекает из предыдущей. Время подготовки ограничено, поэтому нужно выбрать, что именно ботать. Во время подготовки можно пропускать все темы, которые не встречаются в билетах, всё дополнительное и интересное. Более того, преподаватели склонны иметь любимые вопросы, значит, можно готовиться только к ним. Если мы говорим о тестах, то вообще нужно готовиться строго по вопросам. Привет, ЕГЭ!
Автор идёт дальше, утверждая, что любые формы оценки знаний заменяют цель "научиться" на цель "научиться проходить оценку успешно". Поэтому поступление в ВУЗ превращается в попытку угодить вкусу определённой группы людей — приёмной комиссии.
Хуже всего в системе образования то, что она учит вас достигать успеха за счёт хитрости. Эту проблему автор иллюстрирует собственным опытом из консультирования стартапов, где начинающие бизнесмены пытались найти "уловку, чтобы привлечь финансирование в проект". Автор раз за разом объяснял им, что главное для инвестора — это перспективность стартапа в виде будущего роста, а не какие-то формальные признаки успешности.
После этого автор очень тесно переплетает проблемы стартапов и образования, сравнивая старую и новую модели общества. В старой модели общества во главе угла стояло продвижение по карьерной лестнице путём соблюдения правил. Чем дольше человек был на одном месте, тем ценнее он считался. Сейчас всё изменилось. Появилась масса способов разбогатеть, работая на совесть, и частично поэтому люди стали больше стремиться к тому, чтобы разбогатеть.
Умение взломать неэффективный тест становится всё менее важным по мере ослабевания взаимосвязи между работой и вышестоящими инстанциями.
Наше видение: в ИТ индустрии мало обращают внимание на дипломы и сертификаты. При этом вокруг собеседований сложилась дикая ситуация, когда задаваемые вопросы нередко очень далеки от реально выполняемых задач. Годы идут, а ситуация не выравнивается — подготовка к собеседованию превратилась в отдельную отрасль, и решения этой проблеме не видно.
#edu
dsent.me
Вредные уроки (The Lesson to Unlearn) | Переводы | dsent.me
Перевод эссе The Lesson to Unlearn by Paul Graham. Самый вредный навык, привитый вам учебными заведениями — умение получать хорошие оценки.
❤8👍5🌭3👎1
You Suck at Excel with Joel Spolsky
В почти часовом видео Джоэл Спольски покажет, как много классных фич есть в экселе. Сам Джоэл руководил разработкой Excel и спроектировал VBA для Excel.
Если вы каким-то боком касаетесь работы с табличными данными, то видео просто маст-хев. Сможете производить впечатление на не-айтишников своими познаниями. Ещё обратите внимание, как динамично Джоел проводит демонстрацию. Хороший пример, чтобы научиться выступать. В видео есть
– базовые вещи вроде объединения столбцов, копирования значений вместо формул, растягивания формулы вниз разными способами вроде двойного клика или ctrl+D и прочие штуки
– авторазмер ширины колонки/столбца по двойному клику, выставление одинаковой ширины у множества колонок/столбцов
– мощные внутренности в виде RC-значений. Теперь понятно, как внутри организованы ссылки на ячейки в экселе. RC это RowColumn-нотация, и запись вроде RC[-1] означает текущий Row и Column минус один. То есть каждая ячейка содержит относительную ссылку
– выделение строки для циклического перехода по enter, удобно для перехода вправо по заголовку. Работает с произвольным выделением, а не только со строкой или колонкой
– продвинутые фишки вроде заполнения выделенных диапазонов с помощью ctrl-enter, продвинутая работа с диапазонами на примере арифметических операций сразу с диапазоном значений, копирования форматирования
– создание доп таблички со константами на примере процента налога и фиксированные $-ссылки в формулах для вычислений. И есть хот-кей F4 для замены относительной ссылки на абсолютную, не нужно руками вписывать знак доллара
– удобная горячая клавиша F4 для повтора последнего действия. Прямо как точка в vim :) Интересно, что F4 применительно к формуле меняет относительную ссылку на абсолютную, а применительно к ячейке применяет последнее действие
– совсем продвинутые вещи вроде создания хитро вычисляемых полей с помощью vlookup (ВПР в русифицированной версии) на примере вычисления налоговой ставки в зависимости от локации, подбора значений в экселе (goal seek) на примере поиска нужного процента премии сотрудникам при заданном общем бюджете, сводных таблиц (pivot tables) для визуализации многомерных данных. Нагляднее в видео
В середине видео начинается бомба, которую вынесем вне списка. В экселе есть таблицы – такая хитрая сущность, которая умеет из коробки фильтровать, сортировать, и вообще много что. И в таблицах можно ссылаться на столбец по названию вместо номера, и это прямо сильно повышает читаемость формул. А к столбцам можно прикручивать аггрегации типа суммы или среднего. При добавлении новых строчек таблица автоматически расширяется. Это настолько удобно, насколько и малоизвестно. Пользуйтесь!
Есть занятная история, как Джоэл прошёл строгое ревью Билла Гейтса My First BillG Review. В то время степенью успешности ревью было число слов fuck, которые Гейтс произнесёт во время встречи. Спольски хвастается всего 4 fuck на своём ревью, что было рекордом в то время.
Джоэл Спольски известен за классический Закон дырявых абстракций. Интересные мысли про переписывание проекта есть в статье Грабли, на которые не стоит наступать.
#skills
В почти часовом видео Джоэл Спольски покажет, как много классных фич есть в экселе. Сам Джоэл руководил разработкой Excel и спроектировал VBA для Excel.
Если вы каким-то боком касаетесь работы с табличными данными, то видео просто маст-хев. Сможете производить впечатление на не-айтишников своими познаниями. Ещё обратите внимание, как динамично Джоел проводит демонстрацию. Хороший пример, чтобы научиться выступать. В видео есть
– базовые вещи вроде объединения столбцов, копирования значений вместо формул, растягивания формулы вниз разными способами вроде двойного клика или ctrl+D и прочие штуки
– авторазмер ширины колонки/столбца по двойному клику, выставление одинаковой ширины у множества колонок/столбцов
– мощные внутренности в виде RC-значений. Теперь понятно, как внутри организованы ссылки на ячейки в экселе. RC это RowColumn-нотация, и запись вроде RC[-1] означает текущий Row и Column минус один. То есть каждая ячейка содержит относительную ссылку
– выделение строки для циклического перехода по enter, удобно для перехода вправо по заголовку. Работает с произвольным выделением, а не только со строкой или колонкой
– продвинутые фишки вроде заполнения выделенных диапазонов с помощью ctrl-enter, продвинутая работа с диапазонами на примере арифметических операций сразу с диапазоном значений, копирования форматирования
– создание доп таблички со константами на примере процента налога и фиксированные $-ссылки в формулах для вычислений. И есть хот-кей F4 для замены относительной ссылки на абсолютную, не нужно руками вписывать знак доллара
– удобная горячая клавиша F4 для повтора последнего действия. Прямо как точка в vim :) Интересно, что F4 применительно к формуле меняет относительную ссылку на абсолютную, а применительно к ячейке применяет последнее действие
– совсем продвинутые вещи вроде создания хитро вычисляемых полей с помощью vlookup (ВПР в русифицированной версии) на примере вычисления налоговой ставки в зависимости от локации, подбора значений в экселе (goal seek) на примере поиска нужного процента премии сотрудникам при заданном общем бюджете, сводных таблиц (pivot tables) для визуализации многомерных данных. Нагляднее в видео
В середине видео начинается бомба, которую вынесем вне списка. В экселе есть таблицы – такая хитрая сущность, которая умеет из коробки фильтровать, сортировать, и вообще много что. И в таблицах можно ссылаться на столбец по названию вместо номера, и это прямо сильно повышает читаемость формул. А к столбцам можно прикручивать аггрегации типа суммы или среднего. При добавлении новых строчек таблица автоматически расширяется. Это настолько удобно, насколько и малоизвестно. Пользуйтесь!
Есть занятная история, как Джоэл прошёл строгое ревью Билла Гейтса My First BillG Review. В то время степенью успешности ревью было число слов fuck, которые Гейтс произнесёт во время встречи. Спольски хвастается всего 4 fuck на своём ревью, что было рекордом в то время.
Джоэл Спольски известен за классический Закон дырявых абстракций. Интересные мысли про переписывание проекта есть в статье Грабли, на которые не стоит наступать.
#skills
👍6🔥4❤3🌭2
Очереди – что сложного то?
Знание и понимание очередей очень важно для разработчика. Очереди обеспечивают распределение ресурсов, репликацию сообщений, отказоустойчивость, надёжность передачи, гарантию доставки и коммуникацию микросервисов.
Подождите, очередь – это когда с одной с стороны положили, а с другой стороны кто-то забрал? Почти, но всё немного сложнее. Особенно в распределённых системах, особенно когда сообщений десятки тысяч в секунду.
В статье Соседняя очередь всегда движется быстрее автор со всех сторон рассматривает очереди. Очень захватывающее чтиво, наталкивающее на множество размышлений.
Начинается всё с базовых понятий, какие вообще бывают способы организации очередей: put/take, pub/sub, request/response.
Для применения очередей существует множество инструментов.
– Apache Kafka реплицируемый шардируемый лог сообщений для стриминга. Мы кафку очень любим, и о ней были отдельные посты (раз, два)
– RabbitMQ – традиционный pub/sub broker. В отличие от Kafka, у кролика нет ограничений на количество потребителей. Кролик часто используется как шина данных между сервисами
– NATS обеспечивает быстрый неперсистентный обмен сообщениями, высокую производительность и масштабируемость
– Tarantool – это in-memory db, которая может быть использована для организации очередей. Примечателен тем, что можно написать свою очередь на стероидах, со своим процессингом, логикой и приоритетами
На самом деле очень важно знать особенности и отличия этих инструментов, чтобы применять их к месту. На этот счёт в конце статьи у автора также есть размышления.
Напишите в комментариях, какие системы очередей вы знаете или используете на практике. За что их любите или не любите?
Говоря о проблемах – они у очередей есть.
– на уровне алгоритма важно решить, что делать при отказе консьюмера, который уже взял сообщение. Best Effort – просто вернуть сообщение обратно. Но не во всех брокерах так можно. В таком случае можно настроить dead letter queue – отдельную очередь со своей логикой обработки таких сообщений.
– а ещё бывают проблемы приоритизации, когда из-за множества задач с высоким приоритетом консьюмер может никогда не добраться до задач с низким.
– на сетевом уровне существует undefined behavior, то есть сообщение отправлено, но мы не знаем, оно дошло и получено или потерялось
– помимо сети есть диск, который влияет на пропускную способность и задержку в обработке, которая может оказаться не предсказуемой
Чтобы обеспечить доступность (avalability) и надёжность (durability) применяются разные топологии:
– single instance – самый простой вариант. Один брокер, одна очередь, продюсер и консьюмер. Немасштабируемо, низкая доступность и надежность.
– multi instance – можно масштабировать и ставить столько очередей сколько нужно. С надежностью и доступностью получше, но если одна из очередей грохнется, то данные из нее потеряются.
– идём дальше и дублируем уже сами очереди
– автор не останавливается на этом и рассказывает о реплицировании, реплика-сетах, кворумах, кворумных очередях.
Познакомившись с различными сложностями понимаешь, что хорошо бы всё это мониторить. Существуют следующие метрики: размер очереди, время обработки сообщения, количество потерь и отказов.
И всегда нужно быть готовым к самому худшему – к падению. Для этого существуют политики отказа, например, можно отказаться от приёма новых сообщений. Если нельзя, то можно уничтожать старые сообщения и продолжать принимать новые. Как вариант, когда часть сообщений ещё живая, а часть старая, можно попробовать обрабатывать живые, а потом вернуться к старым.
Напоследок ценная мысель: если вы не знаете, как ваша система падает и поднимается, быстро вы её не поднимите.
#skills
Знание и понимание очередей очень важно для разработчика. Очереди обеспечивают распределение ресурсов, репликацию сообщений, отказоустойчивость, надёжность передачи, гарантию доставки и коммуникацию микросервисов.
Подождите, очередь – это когда с одной с стороны положили, а с другой стороны кто-то забрал? Почти, но всё немного сложнее. Особенно в распределённых системах, особенно когда сообщений десятки тысяч в секунду.
В статье Соседняя очередь всегда движется быстрее автор со всех сторон рассматривает очереди. Очень захватывающее чтиво, наталкивающее на множество размышлений.
Начинается всё с базовых понятий, какие вообще бывают способы организации очередей: put/take, pub/sub, request/response.
Для применения очередей существует множество инструментов.
– Apache Kafka реплицируемый шардируемый лог сообщений для стриминга. Мы кафку очень любим, и о ней были отдельные посты (раз, два)
– RabbitMQ – традиционный pub/sub broker. В отличие от Kafka, у кролика нет ограничений на количество потребителей. Кролик часто используется как шина данных между сервисами
– NATS обеспечивает быстрый неперсистентный обмен сообщениями, высокую производительность и масштабируемость
– Tarantool – это in-memory db, которая может быть использована для организации очередей. Примечателен тем, что можно написать свою очередь на стероидах, со своим процессингом, логикой и приоритетами
На самом деле очень важно знать особенности и отличия этих инструментов, чтобы применять их к месту. На этот счёт в конце статьи у автора также есть размышления.
Напишите в комментариях, какие системы очередей вы знаете или используете на практике. За что их любите или не любите?
Говоря о проблемах – они у очередей есть.
– на уровне алгоритма важно решить, что делать при отказе консьюмера, который уже взял сообщение. Best Effort – просто вернуть сообщение обратно. Но не во всех брокерах так можно. В таком случае можно настроить dead letter queue – отдельную очередь со своей логикой обработки таких сообщений.
– а ещё бывают проблемы приоритизации, когда из-за множества задач с высоким приоритетом консьюмер может никогда не добраться до задач с низким.
– на сетевом уровне существует undefined behavior, то есть сообщение отправлено, но мы не знаем, оно дошло и получено или потерялось
– помимо сети есть диск, который влияет на пропускную способность и задержку в обработке, которая может оказаться не предсказуемой
Чтобы обеспечить доступность (avalability) и надёжность (durability) применяются разные топологии:
– single instance – самый простой вариант. Один брокер, одна очередь, продюсер и консьюмер. Немасштабируемо, низкая доступность и надежность.
– multi instance – можно масштабировать и ставить столько очередей сколько нужно. С надежностью и доступностью получше, но если одна из очередей грохнется, то данные из нее потеряются.
– идём дальше и дублируем уже сами очереди
– автор не останавливается на этом и рассказывает о реплицировании, реплика-сетах, кворумах, кворумных очередях.
Познакомившись с различными сложностями понимаешь, что хорошо бы всё это мониторить. Существуют следующие метрики: размер очереди, время обработки сообщения, количество потерь и отказов.
И всегда нужно быть готовым к самому худшему – к падению. Для этого существуют политики отказа, например, можно отказаться от приёма новых сообщений. Если нельзя, то можно уничтожать старые сообщения и продолжать принимать новые. Как вариант, когда часть сообщений ещё живая, а часть старая, можно попробовать обрабатывать живые, а потом вернуться к старым.
Напоследок ценная мысель: если вы не знаете, как ваша система падает и поднимается, быстро вы её не поднимите.
#skills
Хабр
Соседняя очередь всегда движется быстрее
Вы не используете очередь? Вы просто не умеете её готовить. Но прежде чем этому научиться, нужно разобраться, что это вообще такое и где это применяется. Потому что большинству достаточно 10 000...
🔥12❤3🌭3👍1
Backup: февраль
В этом месяце мы много говорили о проектировании, деплое и инфраструктурных технологиях. Не забыли о собеседованиях, питоне и софт-скиллах
Архитектура проекта и деплой
Design distributed cache
Стратегии деплоя
GitOps – все ли так классно?
За всё хорошее, против всего плохого
Важные инструменты
Практикуем Kubernetes
Как kafka хранит данные
Очереди – что сложного то?
Нестареющая классика, шпаргалка по SSH
Интересное по Python
Многопоточный Python на примерах: избавляемся от дедлоков
Мемоизация и каррирование в Python
Введение в logging на Python
Подготовка в собеседованиями
Правильная структура ответа на собеседовании
Как сдвинуть гору Фудзи
Подготовка к интервью в Тинькофф
PostgreSQL
Буфферный кеш в PostgreSQL
NULL в PostgreSQL
Нетехнические навыки:
Моё разочарование в софте
The Lesson to Unlearn — Вредные уроки от Пола Грэма
Упрощаем жизнь руководителю
Необычное для нас: You Suck at Excel with Joel Spolsky
Если пропустили, то подборка за январь
#backup
В этом месяце мы много говорили о проектировании, деплое и инфраструктурных технологиях. Не забыли о собеседованиях, питоне и софт-скиллах
Архитектура проекта и деплой
Design distributed cache
Стратегии деплоя
GitOps – все ли так классно?
За всё хорошее, против всего плохого
Важные инструменты
Практикуем Kubernetes
Как kafka хранит данные
Очереди – что сложного то?
Нестареющая классика, шпаргалка по SSH
Интересное по Python
Многопоточный Python на примерах: избавляемся от дедлоков
Мемоизация и каррирование в Python
Введение в logging на Python
Подготовка в собеседованиями
Правильная структура ответа на собеседовании
Как сдвинуть гору Фудзи
Подготовка к интервью в Тинькофф
PostgreSQL
Буфферный кеш в PostgreSQL
NULL в PostgreSQL
Нетехнические навыки:
Моё разочарование в софте
The Lesson to Unlearn — Вредные уроки от Пола Грэма
Упрощаем жизнь руководителю
Необычное для нас: You Suck at Excel with Joel Spolsky
Если пропустили, то подборка за январь
#backup
Telegram
DevFM
Design distributed cache
Хочется порекомендовать замечательный youtube-канал System Design Interview. Автор вещает на понятном русском английском :)
Канал посвящён вопросам построения архитектуры. На нём мало видео, но каждое из них заслуживает внимания.…
Хочется порекомендовать замечательный youtube-канал System Design Interview. Автор вещает на понятном русском английском :)
Канал посвящён вопросам построения архитектуры. На нём мало видео, но каждое из них заслуживает внимания.…
🔥5❤3🌭2👍1
Пятничное развлекательное
Почему я идиот. Чудесный клип Александра Пушного, созданный на основе интернет-запросов пользователей почти 10 лет назад.
Пушного я люблю за многое. И старая-добрая программа Галилео, и Апож. Кстати, забавный факт из интервью Пушного — руководители хотели убрать детей от Галилео, и Пушной добавил брутальности. А детям зашло, и программа стала очень популярной среди детей и взрослых. В пандемию Пушной записал приятные rock-титры к Галилео.
Пушной был камео в обзоре BadComedian, о чём есть тоже забавная история. А совсем в старые времена Пушной выступал в КВН в роли Стинга. Приходите в комменты с ностальгией :)
#fun
Почему я идиот. Чудесный клип Александра Пушного, созданный на основе интернет-запросов пользователей почти 10 лет назад.
Пушного я люблю за многое. И старая-добрая программа Галилео, и Апож. Кстати, забавный факт из интервью Пушного — руководители хотели убрать детей от Галилео, и Пушной добавил брутальности. А детям зашло, и программа стала очень популярной среди детей и взрослых. В пандемию Пушной записал приятные rock-титры к Галилео.
Пушной был камео в обзоре BadComedian, о чём есть тоже забавная история. А совсем в старые времена Пушной выступал в КВН в роли Стинга. Приходите в комменты с ностальгией :)
#fun
YouTube
Почему я идиот. Пушной.
КЛИП (песня основана на реальных запросах людей в интернете) video homemade style
Что больше всего на свете
Волнует людей в интернете:
Что сожрать чтобы похудеть,
Почему слаще редьки хрен,
Почему хотеть вредно не хотеть,
Как легко увеличить член?
Как…
Что больше всего на свете
Волнует людей в интернете:
Что сожрать чтобы похудеть,
Почему слаще редьки хрен,
Почему хотеть вредно не хотеть,
Как легко увеличить член?
Как…
🔥10😁5🌭3
Постигаем gRPC
Классический вариант межсервисного взаимодействия – REST. Но есть альтернативы, например, gRPC.
В своём докладе ребята из Яндекса рассказывают об опыте применения gRPC. Сначала, конечно, о проблемах, которые хотелось бы решить. Не просто же так тащить новую технологию в прод.
Среди хотелок автор выделяет:
– наличие клиентов на разных языках, да ещё чтобы не нужно было самим писать, а ещё чтобы клиент мог быть и синхронным, и асинхронным
– поддержка обратной совместимости сервисов, что особенно важно для множества параллельных релизов разных сервисов
– удобная обработка ошибок без нагромождения своего велосипеда
– управление таймаутами со стороны клиента, чтобы можно было отменить запрос
Далее автор переходит непосредственно к gRPC и рассказывает, как именно эти хотелки удовлетворяются.
На практическом примере показывает реализацию unary call – классического запроса/ответа и streaming для длительного соединения. Если с unary call всё ясно, то streaming может быть полезен для скачивания и загрузки больших сообщений частями или для отправки серверных пушей.
В статье затрагиваются темы: как избежать частых проблем, если вы начинаете использовать gRPC после REST, как возвращать ошибки, реализовать трассировку, отлаживать запросы и тестировать вызовы клиентов.
Если первая статья больше концептуальная, то для любителей питона есть замечательное практическое руководство Python Microservices With gRPC. Можно брать и делать. Сначала рассматриваются теоретические вопросы микросервисов, gRPC, когда применять. Далее практика – реализация микросервиса, деплой и тестирование. В конце приводится набор практик, которые стоит применять при использовании gRPC.
#skills
Классический вариант межсервисного взаимодействия – REST. Но есть альтернативы, например, gRPC.
В своём докладе ребята из Яндекса рассказывают об опыте применения gRPC. Сначала, конечно, о проблемах, которые хотелось бы решить. Не просто же так тащить новую технологию в прод.
Среди хотелок автор выделяет:
– наличие клиентов на разных языках, да ещё чтобы не нужно было самим писать, а ещё чтобы клиент мог быть и синхронным, и асинхронным
– поддержка обратной совместимости сервисов, что особенно важно для множества параллельных релизов разных сервисов
– удобная обработка ошибок без нагромождения своего велосипеда
– управление таймаутами со стороны клиента, чтобы можно было отменить запрос
Далее автор переходит непосредственно к gRPC и рассказывает, как именно эти хотелки удовлетворяются.
На практическом примере показывает реализацию unary call – классического запроса/ответа и streaming для длительного соединения. Если с unary call всё ясно, то streaming может быть полезен для скачивания и загрузки больших сообщений частями или для отправки серверных пушей.
В статье затрагиваются темы: как избежать частых проблем, если вы начинаете использовать gRPC после REST, как возвращать ошибки, реализовать трассировку, отлаживать запросы и тестировать вызовы клиентов.
Если первая статья больше концептуальная, то для любителей питона есть замечательное практическое руководство Python Microservices With gRPC. Можно брать и делать. Сначала рассматриваются теоретические вопросы микросервисов, gRPC, когда применять. Далее практика – реализация микросервиса, деплой и тестирование. В конце приводится набор практик, которые стоит применять при использовании gRPC.
#skills
Хабр
gRPC в качестве протокола межсервисного взаимодействия. Доклад Яндекса
gRPC — опенсорсный фреймворк для удаленного вызова процедур. В Яндекс.Маркете gRPC используется как более удобная альтернатива REST. Сергей Федосеенков, который руководит службой разработки...
👍5🔥4❤2🌭2
Микросервисы. Очередное рассуждение
В последнее время активно исследую вопросы, связанные с микросервисной архитектурой. Наткнулся на статью-рассуждение Микросервисы и неизбежная боль?
Автор начинает с того, что сам термин "микросервис" неоднозначен и приводит разные определения. Я с ним согласен. Думаю, что чересчур много внимания уделяется микро. Мне же нравится обобщённое определение, что микросервисная архитектура – это стиль проектирования, который разбивает приложение на отдельные сервисы с разными функциями. И важно, что в нём ни слова о размере.
Далее по классике микросервисы сравниваются с service-oriented architecture (SOA) и монолитом. Тут нет ничего нового. Выделю отличия микросервисов от SOA:
– в SOA, как правило, сервис – это крупное монолитное приложение. Возможно, даже ставшее отдельным сервисом не по архитектурной задумке, а в силу исторических причин
– в SOA используется глобальная модель данных и общая БД
– в SOA для межсервисного взаимодействия используются умные и тяжеловесные протоколы вроде SOAP
Доходим наконец-то до боли, обозначенной в заголовке. Автор говорит о том, что часто видел:
– огромное количество разрозненных, отличающихся друг от друга репозиториев, созданных разными людьми
– большие усилия на поддержание обратной совместимости api, невозможность определить во всем зоопарке сервисов, кто это api использует и нужно ли оно вообще
– размывание технологического стека среди команд и сервисов, разные системы сборки и деплоя
– новые сервисы на каждый чих, дублирование кода
Что ж, у меня двоякое отношение к сказанному. Могу лишь сделать вывод, что любую архитектуру можно испортить. Ничего удивительного, микросервисы – не золотая пуля, они несут в себе набор проблем и ограничений. Важность перечисленных проблем в том, что о них нужно знать заранее, тщательно отслеживать и вовремя реагировать. Предупрежден – значит вооружён.
Возвращаясь к проблемам, для организации микросервисной архитектуры должны быть выстроены процессы и инженерная культура, созданы шаблонные сервисы, особое внимание должно уделяться CI/CD и observability.
Рассуждая о золотой середине, автор даёт, как мне кажется, вредные советы. Всё сводится к тому, что делаем условно монолитно, но, когда понадобится, легко сможем разбить на микросервисы. Предлагается использовать единый репозиторий с делением на директории посервисно, одну базу данных без связей между таблицами разных сервисов.
Не думаю, что это хорошая практика. Применение таких половинчатых мер незаметно приведет к появлению распределенного монолита, которому будут присущи проблемы как микросервисов так и монолита.
В конце банальный, но, кажется, работающий совет: перед принятием решения – думайте, приземляйте на свои реалии, не следуйте просто написанному в умных книгах. Помните о плюсах, которые предоставляет микросервисная архитектура, и думайте о том, чтобы не потеряться их, принимая то или иное решение. Хорошим примером может служить пост о том, как сложный паттерн Сага был адаптирован в более простую версию, исходя из требований конкретной задачи.
#skills
В последнее время активно исследую вопросы, связанные с микросервисной архитектурой. Наткнулся на статью-рассуждение Микросервисы и неизбежная боль?
Автор начинает с того, что сам термин "микросервис" неоднозначен и приводит разные определения. Я с ним согласен. Думаю, что чересчур много внимания уделяется микро. Мне же нравится обобщённое определение, что микросервисная архитектура – это стиль проектирования, который разбивает приложение на отдельные сервисы с разными функциями. И важно, что в нём ни слова о размере.
Далее по классике микросервисы сравниваются с service-oriented architecture (SOA) и монолитом. Тут нет ничего нового. Выделю отличия микросервисов от SOA:
– в SOA, как правило, сервис – это крупное монолитное приложение. Возможно, даже ставшее отдельным сервисом не по архитектурной задумке, а в силу исторических причин
– в SOA используется глобальная модель данных и общая БД
– в SOA для межсервисного взаимодействия используются умные и тяжеловесные протоколы вроде SOAP
Доходим наконец-то до боли, обозначенной в заголовке. Автор говорит о том, что часто видел:
– огромное количество разрозненных, отличающихся друг от друга репозиториев, созданных разными людьми
– большие усилия на поддержание обратной совместимости api, невозможность определить во всем зоопарке сервисов, кто это api использует и нужно ли оно вообще
– размывание технологического стека среди команд и сервисов, разные системы сборки и деплоя
– новые сервисы на каждый чих, дублирование кода
Что ж, у меня двоякое отношение к сказанному. Могу лишь сделать вывод, что любую архитектуру можно испортить. Ничего удивительного, микросервисы – не золотая пуля, они несут в себе набор проблем и ограничений. Важность перечисленных проблем в том, что о них нужно знать заранее, тщательно отслеживать и вовремя реагировать. Предупрежден – значит вооружён.
Возвращаясь к проблемам, для организации микросервисной архитектуры должны быть выстроены процессы и инженерная культура, созданы шаблонные сервисы, особое внимание должно уделяться CI/CD и observability.
Рассуждая о золотой середине, автор даёт, как мне кажется, вредные советы. Всё сводится к тому, что делаем условно монолитно, но, когда понадобится, легко сможем разбить на микросервисы. Предлагается использовать единый репозиторий с делением на директории посервисно, одну базу данных без связей между таблицами разных сервисов.
Не думаю, что это хорошая практика. Применение таких половинчатых мер незаметно приведет к появлению распределенного монолита, которому будут присущи проблемы как микросервисов так и монолита.
В конце банальный, но, кажется, работающий совет: перед принятием решения – думайте, приземляйте на свои реалии, не следуйте просто написанному в умных книгах. Помните о плюсах, которые предоставляет микросервисная архитектура, и думайте о том, чтобы не потеряться их, принимая то или иное решение. Хорошим примером может служить пост о том, как сложный паттерн Сага был адаптирован в более простую версию, исходя из требований конкретной задачи.
#skills
Хабр
Микросервисы и неизбежная боль?
Сегодня трудно себе представить более переоцененный подход к созданию архитектуры программных решений, чем микросервисы. В сети доступно огромное количество статей и видеолекций, в которых авторы...
👍9🌭3❤2🔥1
ngrok
Бывают случаи, когда хочется расшарить функционал, ещё не доставленный в девелоперский контур, что-то протестировать. И вообще могут быть разные причины, когда нужно обеспечить доступность извне вашей машинке или сервису.
Для этого есть замечательная утилита ngrok. Одна команда и готово.
У ребят всё сделано по-человечески – можно поднять в докере и настроить end-to-end шифрование. На этом возможности не заканчиваются. Есть качественная документация, можно узнать, как воплотить в жизнь самые разные хотелки.
Не пугайтесь раздела pricing на сайте. Для подобного базового использования – всё бесплатно.
А чтобы объединить разные устройства на хозяйстве в одну сеть и иметь отовсюду к ним доступ, пользуюсь еще одной замечательной утилитой tailscale. Примечательно, что у ребят тоже хорошая документация и блог, где они описывают различные хитрые сценарии применения. Например, как кодить на айпаде в vscode.
#tools
Бывают случаи, когда хочется расшарить функционал, ещё не доставленный в девелоперский контур, что-то протестировать. И вообще могут быть разные причины, когда нужно обеспечить доступность извне вашей машинке или сервису.
Для этого есть замечательная утилита ngrok. Одна команда и готово.
У ребят всё сделано по-человечески – можно поднять в докере и настроить end-to-end шифрование. На этом возможности не заканчиваются. Есть качественная документация, можно узнать, как воплотить в жизнь самые разные хотелки.
Не пугайтесь раздела pricing на сайте. Для подобного базового использования – всё бесплатно.
А чтобы объединить разные устройства на хозяйстве в одну сеть и иметь отовсюду к ним доступ, пользуюсь еще одной замечательной утилитой tailscale. Примечательно, что у ребят тоже хорошая документация и блог, где они описывают различные хитрые сценарии применения. Например, как кодить на айпаде в vscode.
#tools
Ngrok
Secure Tunnels
Your connection to upstream services running anywhere.
👍7🌭3❤2
Следим за Postgres
Иногда что-то случается в Postgres, и с ходу даже не знаешь, куда смотреть. Начинается брожение по специализированным ресурсам в поиске хитрого запроса на получение необходимых диагностических данных.
Автор провел большую работу и собрал в статье набор полезных запросов для postgres. Статья будет отличной шпаргалкой, потому что многие запросы без пол литра не разобрать.
Для отслеживания размера БД автор приводит запросы для получения:
– размера табличных пространств
– размера базы данных
– размера схем в базе данных
– размера таблиц
Это всё цветочки и, как правило, можно посмотреть в любом клиенте.
А когда не проходит какой-нибудь запрос или миграция виснет, тут уже становится интереснее. Где-то что-то блокируется.
Для отслеживания блокировок автор приводит запрос для получения заблокированных запросов и снятия блокировок.
Для отслеживания эффективности можно узнать:
– коэффициент кеширования, показывающий долю чтения из кеша по сравнению с общим количеством операций чтения как с диска, так и из кеша
– процент времени использования индексов по сравнению с чтением данных без индексов и, таким образом, найти кандидатов на добавление индекса
– наоборот, неиспользуемые индексы
– величину раздувания базы. Это когда дисковое пространство использовалось таблицей или индексом, доступно для повторного использования, но не было освобождено. Для решения этой проблемы есть команда VACUUM.
Также среди полезных запросов автор приводит получение:
– количества открытых подключений
– выполняющихся запросов и их длительность
Рекомендуем также заглянуть в комментарии, там делятся интересным опытом. Например, запрос для отладки блокировок. Или совсем специфичное – запрос, который позволит прикинуть сколько занимает одна запись на диске.
#skills #database
Иногда что-то случается в Postgres, и с ходу даже не знаешь, куда смотреть. Начинается брожение по специализированным ресурсам в поиске хитрого запроса на получение необходимых диагностических данных.
Автор провел большую работу и собрал в статье набор полезных запросов для postgres. Статья будет отличной шпаргалкой, потому что многие запросы без пол литра не разобрать.
Для отслеживания размера БД автор приводит запросы для получения:
– размера табличных пространств
– размера базы данных
– размера схем в базе данных
– размера таблиц
Это всё цветочки и, как правило, можно посмотреть в любом клиенте.
А когда не проходит какой-нибудь запрос или миграция виснет, тут уже становится интереснее. Где-то что-то блокируется.
Для отслеживания блокировок автор приводит запрос для получения заблокированных запросов и снятия блокировок.
Для отслеживания эффективности можно узнать:
– коэффициент кеширования, показывающий долю чтения из кеша по сравнению с общим количеством операций чтения как с диска, так и из кеша
– процент времени использования индексов по сравнению с чтением данных без индексов и, таким образом, найти кандидатов на добавление индекса
– наоборот, неиспользуемые индексы
– величину раздувания базы. Это когда дисковое пространство использовалось таблицей или индексом, доступно для повторного использования, но не было освобождено. Для решения этой проблемы есть команда VACUUM.
Также среди полезных запросов автор приводит получение:
– количества открытых подключений
– выполняющихся запросов и их длительность
Рекомендуем также заглянуть в комментарии, там делятся интересным опытом. Например, запрос для отладки блокировок. Или совсем специфичное – запрос, который позволит прикинуть сколько занимает одна запись на диске.
#skills #database
Хабр
Топ полезных SQL-запросов для PostgreSQL
Статей о работе с PostgreSQL и её преимуществах достаточно много, но не всегда из них понятно, как следить за состоянием базы и метриками, влияющими на её оптимальную работу. В статье подробно...
👍9❤3🔥3🌭2
Teamlead roadmap
В разработке нужны не только разработчики. В зависимости от размера, для проекта могут требоваться тимлид, CTO, PM и ещё десяток разных аббревиатур. Чёткого деления по задачам нет, и в разных компаниях разное видение ответственности каждого из работников. И один человек может брать одновременно тимлидом и CTO.
В итоге тимлиды в команде часто выполняют достаточно уникальный набор задач, являющийся миксом из множества ролей. В предлагаемом роадмапе детализированы личные навыки тимлида и различные управленческие роли:
– administrator, ответственный за управление циклом разработки проекта
– integrator, понимающий потребности бизнеса и его долгосрочной стратегии, способный донести эти потребности до команды
– people manager, занимающийся людьми, организацией работы команды в самом широком смысле включая найм, мотивацию, поддержку процесса работы и увольнения
– product owner, способный стратегически мыслить в рамках продукта
– technical lead, стратегически отвечающий за техническую часть
Каждое из направлений состоит из множества навыков. По большинству навыков есть подробное описание и дополнительные материалы для изучения, статьи и книги. Например, мы обсуждали code review из роли technical lead.
Топовый роадмап для разработчиков был раньше.
#edu
В разработке нужны не только разработчики. В зависимости от размера, для проекта могут требоваться тимлид, CTO, PM и ещё десяток разных аббревиатур. Чёткого деления по задачам нет, и в разных компаниях разное видение ответственности каждого из работников. И один человек может брать одновременно тимлидом и CTO.
В итоге тимлиды в команде часто выполняют достаточно уникальный набор задач, являющийся миксом из множества ролей. В предлагаемом роадмапе детализированы личные навыки тимлида и различные управленческие роли:
– administrator, ответственный за управление циклом разработки проекта
– integrator, понимающий потребности бизнеса и его долгосрочной стратегии, способный донести эти потребности до команды
– people manager, занимающийся людьми, организацией работы команды в самом широком смысле включая найм, мотивацию, поддержку процесса работы и увольнения
– product owner, способный стратегически мыслить в рамках продукта
– technical lead, стратегически отвечающий за техническую часть
Каждое из направлений состоит из множества навыков. По большинству навыков есть подробное описание и дополнительные материалы для изучения, статьи и книги. Например, мы обсуждали code review из роли technical lead.
Топовый роадмап для разработчиков был раньше.
#edu
👍5❤4🔥3🌭1
Пятничное развлекательное
Есть такое хобби – экстраполировать. В шуточной статье Python 3.14 Will be Faster than C++ демонстрируется результат бенчмарка производительности питона от версии 3.5 до версии 3.11. Изложение приправлено изрядной долей юмора, have fun.
#fun
Есть такое хобби – экстраполировать. В шуточной статье Python 3.14 Will be Faster than C++ демонстрируется результат бенчмарка производительности питона от версии 3.5 до версии 3.11. Изложение приправлено изрядной долей юмора, have fun.
#fun
👍16😁5🔥3🌭3❤1
Работаем с аудиторией на выступлении – TEDx
Вы уверены, что лучше всего использовать технологию А, но команда планирует использовать технологию Б. Сможете ли вы донести свою мысль до коллектива?
Выступить даже на митапе для несколько человек непросто. А от качества выступления зависит степень донесения мыслей. Недостаточно быть просто правым, надо хорошо донести мысль и увлечь людей за собой. Если посмотреть шире, то площадки бывают разные:
– люди на конференциях делятся результатами, технологиями и опытом
– бизнес презентует что-то новое, можно вспомнить WWDC от Apple
– преподаватель на лекциях доносит знания
Для создания хорошего выступления нужен опыт, и с этим всё сложно. Мы не встречали годного материала про выступления. Поделимся своими мыслями. Как обычно, следует тянуться за лучшими практиками.
TED (technology, entertainment, design) – это известный организатор крутых конференций, и у него есть дочерний проект TEDx. TEDx создаёт локальные конференции в стиле TED.
В коротком видео How to use one paper towel докладчик рассказывает о важности экономии бумажных полотенец для сохранения деревьев. Предлагается простая схема – 12 раз стряхнуть влагу с рук (shake), после чего сложить полотенце вдвое (fold) и вытереть руки им. Очень круто поставлено взаимодействие с аудиторией – половина зала по указанию выступающего повторяет shake, вторая половина fold.
Выступление построено классически:
– формулировка проблемы
– презентация решения, обоснование и сравнение результатов
– связь результатов с проблемой
Внутри презентации решения много интересного:
– оценка результата "даже с одним полотенцем руки сухие"
– рассмотрение вариантов на примере "почему именно 12"
– шутки для повышения внимания к докладу
– технические внутренности "interstitial suspension" для демонстрации важности складывания полотенца вдвое
– пример из жизни "получить половинку полотенца из автоматического диспенсера"
Всё это в сумме образует очень крутое выступление по форме и содержанию, с которого можно брать пример.
У вас есть любимые TEDx-выступления?
#edu
Вы уверены, что лучше всего использовать технологию А, но команда планирует использовать технологию Б. Сможете ли вы донести свою мысль до коллектива?
Выступить даже на митапе для несколько человек непросто. А от качества выступления зависит степень донесения мыслей. Недостаточно быть просто правым, надо хорошо донести мысль и увлечь людей за собой. Если посмотреть шире, то площадки бывают разные:
– люди на конференциях делятся результатами, технологиями и опытом
– бизнес презентует что-то новое, можно вспомнить WWDC от Apple
– преподаватель на лекциях доносит знания
Для создания хорошего выступления нужен опыт, и с этим всё сложно. Мы не встречали годного материала про выступления. Поделимся своими мыслями. Как обычно, следует тянуться за лучшими практиками.
TED (technology, entertainment, design) – это известный организатор крутых конференций, и у него есть дочерний проект TEDx. TEDx создаёт локальные конференции в стиле TED.
В коротком видео How to use one paper towel докладчик рассказывает о важности экономии бумажных полотенец для сохранения деревьев. Предлагается простая схема – 12 раз стряхнуть влагу с рук (shake), после чего сложить полотенце вдвое (fold) и вытереть руки им. Очень круто поставлено взаимодействие с аудиторией – половина зала по указанию выступающего повторяет shake, вторая половина fold.
Выступление построено классически:
– формулировка проблемы
– презентация решения, обоснование и сравнение результатов
– связь результатов с проблемой
Внутри презентации решения много интересного:
– оценка результата "даже с одним полотенцем руки сухие"
– рассмотрение вариантов на примере "почему именно 12"
– шутки для повышения внимания к докладу
– технические внутренности "interstitial suspension" для демонстрации важности складывания полотенца вдвое
– пример из жизни "получить половинку полотенца из автоматического диспенсера"
Всё это в сумме образует очень крутое выступление по форме и содержанию, с которого можно брать пример.
У вас есть любимые TEDx-выступления?
#edu
YouTube
How to use one paper towel | Joe Smith | TEDxConcordiaUPortland
R. P. Joe Smith served as a District Attorney in Umatilla County and nearly won a race for Oregon Attorney General without taking a single contribution over $99.99. He is a former chair of the Oregon Democratic Party and is active with several local nonprofits.…
👍8🌭4❤3
Проектируем БД в DB Designer
При проектировании архитектуры приложения часто нужно набросать схему базы данных. Хочется такой инструмент, где это можно сделать быстро и удобно. Думать только о сути, а не о том, как добавить поле или как соединить таблицы.
Для себя давно нашел такой инструмент – DB Designer.
Из приятных штук могу выделить:
– всё делается в браузере
– очень просто накликать нужные таблицы и связи
– стрелочки-связи между таблицами красиво и понятно располагаются
– явно видно, по каким полям соединяются таблицы
– можно работать в коллаборации с коллегами, оставлять комментарии
– для дальнейших экспериментов схему можно экспортировать в SQL-файлик
Если пользуетесь чем-то подобным – делитесь в комментариях.
#tools
При проектировании архитектуры приложения часто нужно набросать схему базы данных. Хочется такой инструмент, где это можно сделать быстро и удобно. Думать только о сути, а не о том, как добавить поле или как соединить таблицы.
Для себя давно нашел такой инструмент – DB Designer.
Из приятных штук могу выделить:
– всё делается в браузере
– очень просто накликать нужные таблицы и связи
– стрелочки-связи между таблицами красиво и понятно располагаются
– явно видно, по каким полям соединяются таблицы
– можно работать в коллаборации с коллегами, оставлять комментарии
– для дальнейших экспериментов схему можно экспортировать в SQL-файлик
Если пользуетесь чем-то подобным – делитесь в комментариях.
#tools
👍10❤4🌭3🔥1😁1
Делай нейминг как сеньор
Все мы знаем, что нужно правильно и понятно именовать переменные. Правильно, понятно – а это как?
Ребята написали отличную статью, где комплексно, с разных сторон подошли к вопросу нейминга.
На самом деле проработанный, качественный нейминг очень важен. Один раз где-то, что-то плохо назовешь, а через месяц-другой эти наименования просочатся в документацию, аналитику, тесты, внешние api.
Неправильно именование приводит к неправильному пониманию, а дальше – к некорректному использованию.
Чтобы детальнее разобраться, автор выделяет несколько распространенных проблем: слишком общие название, избыточные названия, названия без контекста, названия с некорректным переводом или калькой со своего языка, абстрактные названия. Каждая из проблем сопровождается примерами.
К решению проблемы автор также подходит комплексно, отталкиваясь от понимания предметной области и того, как выстроить работу с неймингом на уровне команды и продукта.
Заканчивается статья набором конкретных практических советов, которые можно брать и применять.
#procode
Все мы знаем, что нужно правильно и понятно именовать переменные. Правильно, понятно – а это как?
Ребята написали отличную статью, где комплексно, с разных сторон подошли к вопросу нейминга.
На самом деле проработанный, качественный нейминг очень важен. Один раз где-то, что-то плохо назовешь, а через месяц-другой эти наименования просочатся в документацию, аналитику, тесты, внешние api.
Неправильно именование приводит к неправильному пониманию, а дальше – к некорректному использованию.
Чтобы детальнее разобраться, автор выделяет несколько распространенных проблем: слишком общие название, избыточные названия, названия без контекста, названия с некорректным переводом или калькой со своего языка, абстрактные названия. Каждая из проблем сопровождается примерами.
К решению проблемы автор также подходит комплексно, отталкиваясь от понимания предметной области и того, как выстроить работу с неймингом на уровне команды и продукта.
Заканчивается статья набором конкретных практических советов, которые можно брать и применять.
#procode
Хабр
Делай нейминг как сеньор
В чём разница между сочинением третьеклассника и статьёй в крупном таблоиде? Любой из нас сходу определит, что есть что. Даже если оба текста описывают одно и то же событие. А чем отличается код...
👍8🌭6❤2
Пятничное развлекательное
Захватывающее пятничное чтиво INSIDE PORNHUB о внутренней кухне от лица бывшего сотрудника.
Быстрый рост компании, конфликты внутри индустрии. Проблемы, с которыми сталкивались и как решали. Особое внимание уделяется тому, как модерировался контент.
Почитайте, очень любопытно :)
#fun
Захватывающее пятничное чтиво INSIDE PORNHUB о внутренней кухне от лица бывшего сотрудника.
Быстрый рост компании, конфликты внутри индустрии. Проблемы, с которыми сталкивались и как решали. Особое внимание уделяется тому, как модерировался контент.
Почитайте, очень любопытно :)
#fun
The Verge
Confessions of a Pornhub moderator
I wasn’t even supposed to be a moderator. It’s what I was doing in between writing tweets.
🌭8👍3😁2❤1
Итерируем всякое
Статья с кликбейтным названием – 10 итераторов, о которых вы могли не знать и реально интересным содержанием.
Автор начинает по классике, объясняя, что такое итератор, как реализовать собственный итератор, проходится по генераторам, протоколу последовательностей и перечислениям.
Кстати, бывают собеседования, где реально просят реализовать свой итератор. Ситуация неоднозначная: с одной стороны, знать внутреннее устройство итератора полезно, и вопрос может быть подходящим для выявления понимания у джуна. С другой стороны, на практике редко требуется лезть туда ручками. Если нужно – всегда можно посмотреть в доку, запоминать смысла нет. В итоге по бесполезности напоминает вопрос о тестировании карандаша.
Из действительно любопытного отметим:
– iter может принимать два аргумента. Второй аргумент – элемент, на котором будет сгенерировано исключение StopIteration
– можно итерироваться по стандартному потоку ввода. Объект stdin итерируемый
– можно итерироваться по содержимому каталога. В модуле pathlib есть итератор iterdir
– можно итерироваться по строкам csv-файла, применив функцию iter к объекту csv_reader
Итераторы окружают питонистов. Даже если постоянно используете Python в профессиональной деятельности, найдете что-то интересное. Статья исключительно практическая. Бери и используй.
#python
Статья с кликбейтным названием – 10 итераторов, о которых вы могли не знать и реально интересным содержанием.
Автор начинает по классике, объясняя, что такое итератор, как реализовать собственный итератор, проходится по генераторам, протоколу последовательностей и перечислениям.
Кстати, бывают собеседования, где реально просят реализовать свой итератор. Ситуация неоднозначная: с одной стороны, знать внутреннее устройство итератора полезно, и вопрос может быть подходящим для выявления понимания у джуна. С другой стороны, на практике редко требуется лезть туда ручками. Если нужно – всегда можно посмотреть в доку, запоминать смысла нет. В итоге по бесполезности напоминает вопрос о тестировании карандаша.
Из действительно любопытного отметим:
– iter может принимать два аргумента. Второй аргумент – элемент, на котором будет сгенерировано исключение StopIteration
– можно итерироваться по стандартному потоку ввода. Объект stdin итерируемый
– можно итерироваться по содержимому каталога. В модуле pathlib есть итератор iterdir
– можно итерироваться по строкам csv-файла, применив функцию iter к объекту csv_reader
Итераторы окружают питонистов. Даже если постоянно используете Python в профессиональной деятельности, найдете что-то интересное. Статья исключительно практическая. Бери и используй.
#python
Хабр
10 итераторов, о которых вы могли не знать
Одним из главных достоинств Python является выразительность кода. Не последнюю роль в этом играет возможность удобной работы с коллекциями и последовательностями различного вида: перебор элементов...
👍13🌭3🔥2⚡1❤1
Где бы ещё сохранить данные?
Greenplum – распределённая база данных на основе postgres с открытым исходным кодом.
Статья Introduction To Greenplum Architecture будет отличным введением для понимания, что это за зверь такой.
Автор начинает с довольно скучного введения, так что сразу переходите к разделу Greenplum Overall Architecture.
По сути, Greenplum – это кластер баз данных, состоящий из отдельных Postgres. Кластер состоит из:
– master-ноды, которая является входной точкой для всей БД и обеспечивает единый интерфейс для взаимодействия с кластером
– standby-ноды – резервного мастера для обеспечения высокой доступности
– нескольких segment-нод – рабочих лошадок, где хранятся и обрабатываются данные
Статья расскажет, как это всё вместе взаимодействует. Затрагиваются вопросы:
– физической организации хранения данных
– порядка и способов взаимодействия всех участников кластера
– выполнения запросов с различными джоинами
– обеспечения атомарности и изоляции
– механизма двухфазного коммита для подтверждения распределённых транзакций
Вводная статья, конечно, не расскажет о практическом применении гринплама и не подсветит проблемные места. Чтобы изучить, как эта махарайка применяется на практике, рекомендуем прочитать статью Как мы используем Greenplum в платформе данных Тинькофф
#skills #database
Greenplum – распределённая база данных на основе postgres с открытым исходным кодом.
Статья Introduction To Greenplum Architecture будет отличным введением для понимания, что это за зверь такой.
Автор начинает с довольно скучного введения, так что сразу переходите к разделу Greenplum Overall Architecture.
По сути, Greenplum – это кластер баз данных, состоящий из отдельных Postgres. Кластер состоит из:
– master-ноды, которая является входной точкой для всей БД и обеспечивает единый интерфейс для взаимодействия с кластером
– standby-ноды – резервного мастера для обеспечения высокой доступности
– нескольких segment-нод – рабочих лошадок, где хранятся и обрабатываются данные
Статья расскажет, как это всё вместе взаимодействует. Затрагиваются вопросы:
– физической организации хранения данных
– порядка и способов взаимодействия всех участников кластера
– выполнения запросов с различными джоинами
– обеспечения атомарности и изоляции
– механизма двухфазного коммита для подтверждения распределённых транзакций
Вводная статья, конечно, не расскажет о практическом применении гринплама и не подсветит проблемные места. Чтобы изучить, как эта махарайка применяется на практике, рекомендуем прочитать статью Как мы используем Greenplum в платформе данных Тинькофф
#skills #database
👍6🌭3❤2🔥2
Как ускорить приложение на FastAPI
Важно понимать потенциальные узкие места вашего приложения, и что можно подкрутить в том или ином случае.
Отличная практическая статья, показывающая, как можно ускорить своё приложение. Примеры из статьи выложены на github, поэтому можно потрогать ручками.
Ребята не открывают ничего супер нового, просто берут приложение на fastapi и показывают набор классических приёмов для ускорения работы.
Рассматриваются:
– многопоточность
– асинхронность
– redis для кеширования
А в качестве бонуса – статья о KeyDB, интересной альтернативе привычному всем редису, на которую стоит посмотреть.
#python
Важно понимать потенциальные узкие места вашего приложения, и что можно подкрутить в том или ином случае.
Отличная практическая статья, показывающая, как можно ускорить своё приложение. Примеры из статьи выложены на github, поэтому можно потрогать ручками.
Ребята не открывают ничего супер нового, просто берут приложение на fastapi и показывают набор классических приёмов для ускорения работы.
Рассматриваются:
– многопоточность
– асинхронность
– redis для кеширования
А в качестве бонуса – статья о KeyDB, интересной альтернативе привычному всем редису, на которую стоит посмотреть.
#python
👍10🌭5❤2🔥2
Пятничное развлекательное
Уже давно существует тренд на механические клавиатуры. Приятный звук, тактильные ощущения. Хочется стукать по ней всеми пальчиками. Но, даже если механической клавиатуры нет, в интернете всегда есть кто-то неправый и хочется побыстрее ему объяснить.
monkeytype – замечательный сервис, с отличным дизайном где можно позалипать и потренировать слепую печать.
#fun
Уже давно существует тренд на механические клавиатуры. Приятный звук, тактильные ощущения. Хочется стукать по ней всеми пальчиками. Но, даже если механической клавиатуры нет, в интернете всегда есть кто-то неправый и хочется побыстрее ему объяснить.
monkeytype – замечательный сервис, с отличным дизайном где можно позалипать и потренировать слепую печать.
#fun
Monkeytype
Monkeytype | A minimalistic, customizable typing test
The most customizable typing test website with a minimal design and a ton of features. Test yourself in various modes, track your progress and improve your speed.
👍9❤4🌭4🔥1
Реверс инжиниринг для самых маленьких на практике
Не ограничиваем область своих интересов только разработкой, поэтому совместно с нашим хорошим другом и подписчиком подготовили статью на тему реверса.
В статье мы берём все наши скромные знания, дизассемблер, несложную задачку и идём в бой.
В процессе разбираем, какие инструменты использовать, с какой стороны подходить к решению подобных задач, где-то углубляемся в теорию и даём полезные ссылки для более детального изучения.
Если посматривали на реверс, но не знали с чего начать – велкам.
#devfm
Не ограничиваем область своих интересов только разработкой, поэтому совместно с нашим хорошим другом и подписчиком подготовили статью на тему реверса.
В статье мы берём все наши скромные знания, дизассемблер, несложную задачку и идём в бой.
В процессе разбираем, какие инструменты использовать, с какой стороны подходить к решению подобных задач, где-то углубляемся в теорию и даём полезные ссылки для более детального изучения.
Если посматривали на реверс, но не знали с чего начать – велкам.
#devfm
Хабр
Реверс инжиниринг для самых маленьких на практике
Скомпилированное приложение является «чёрным ящиком». Чтобы туда заглянуть, восстановить алгоритм работы применяется реверс‑инжиниринг. Это непростой навык с высоким порогом входа. В статье...
🔥9👍5❤2⚡1🌭1