Гильдия ІТ-специалистов Украины
https://www.itguild.org.ua
Друзья, мы с Егором Чумаковым (автором петиции) создаем организацию которая будет представлять интересы ІТ-специалистов — ІТ Гильдию.
Наши цели и задачи:
- выражение консолидированной позиции ІТ-специалистов в информационном пространстве
- защита прав и интересов ИТ-специалистов перед государством
- участие в законотворческом процессе
- сотрудничество с другими общественными организациями
- участие в модернизации и улучшении образования
- сотрудничество со СМИ
- оказание юридической помощи членам Гильдии в случаях споров с контрагентами
- борьба с неэтичными практиками со стороны работодателей
- защита членов Гильдии от дискриминации
Организация будет строиться на принципах демократии и прозрачности.
Подключайтесь к телеграм каналу @itguildukraine
Вступить можно через подписку на патреоне https://www.patreon.com/itguildukraine
Поддержите лайком и репостом и оставьте коммент на ДОУ: https://dou.ua/forums/topic/33374/
Гильдии—быть!
#itguildua
https://www.itguild.org.ua
Друзья, мы с Егором Чумаковым (автором петиции) создаем организацию которая будет представлять интересы ІТ-специалистов — ІТ Гильдию.
Наши цели и задачи:
- выражение консолидированной позиции ІТ-специалистов в информационном пространстве
- защита прав и интересов ИТ-специалистов перед государством
- участие в законотворческом процессе
- сотрудничество с другими общественными организациями
- участие в модернизации и улучшении образования
- сотрудничество со СМИ
- оказание юридической помощи членам Гильдии в случаях споров с контрагентами
- борьба с неэтичными практиками со стороны работодателей
- защита членов Гильдии от дискриминации
Организация будет строиться на принципах демократии и прозрачности.
Подключайтесь к телеграм каналу @itguildukraine
Вступить можно через подписку на патреоне https://www.patreon.com/itguildukraine
Поддержите лайком и репостом и оставьте коммент на ДОУ: https://dou.ua/forums/topic/33374/
Гильдии—быть!
#itguildua
Архитектура современных веб-приложений на примере adopt.com.ua. Масштабирование
Предущие части: введение, внешние сервисы
Сейчас вся моя инфраструктура крутится на самых дешёвых и простых инстантсах. 512 мегабайт памяти, редис на 25 мегабайт, какой-то дохлый постгрес. Всего этого хватает чтобы сайт бодро работал.
Что будет, если завтра ко мне придет не 1000 пользователей в день, а 1000000? Чтобы это узнать, нужно проводить нагрузочное тестирование. Для этого есть специальные инструменты: ApacheBench, Apache JMeter, Gatling и другие. Они позволяют заскриптовать нагрузку, например пользователь заходит кликает по фильтрам, потом идет на котика, потом на блог и так далее и запустить это в тысячу параллельных потоков. После выполнения теста будет сгенерирован отчет о среднем времени доступа, квантилях, количестве ошибок и так далее.
Скорее всего, мой маленький сервер упадёт уже от ста конкуррентных пользователей. Или даже от десяти. Каждый запрос идёт в базу, достаёт оттуда данные и генерирует HTML. Учитывая, что данные у нас меняются нечасто, мы можем закешировать как результат запроса в базу, так и уже отрендеренный HTML. Rails предоставляет весь необходимый инструментарий, но в других фреймворках это тоже есть. Таким образом можно положить в Redis или Memcached сгенерированный HTML для всех страниц поиска и отдельных страниц котика и убрать обращение к базе данных и генерацию HTML.
Я предполагаю что это даст существенный прирост в производительности, но всё равно останется проблема слабого сервера—ему просто не хватит ни CPU ни памяти чтобы обрабатывать большое количество подключений. Тут нужно смотреть по стоимости и производительности—может быть будет дешевле добавить еще один такой же сервер, а может быть взять потолще. Так как наши вебсервера не хранят состояния, то можно просто их размножить. Теперь все будет упираться в базу данных. Можно добавить в кластер read-реплик, чтобы распределить нагрузку на чтение или взять сервер потолще, чтобы он смог обрабатывать большее количество запросов. Если и тут мы упиремся в лимиты, то надо смотреть по ситуации. Например, если основная нагрузка идет через поиск, то можно поднять ElasticSearch. Вариантов масса. Пока мы упрёмся в ограничения скорости работы уже самого интерпретатора Ruby, пройдет куча времени.
Естественно, до того как бросаться покупать сервера, нужно оптимизировать приложение до предела—убрать N+1 запросы, привести в порядок индексы в базе, закешировать всё что можно закешировать, упростить HTML-шаблоны. К сожалению обычно разработчики мало внимания уделяют простым но эффективным оптимизациям.
Еще одна важная особенность нашего решения—это Heroku. Он работает поверх AWS который работает поверх реального железа. То есть, просто вычислительные мощности будут снижаться с каждым добавленным уровнем виртуализации. Поэтому если на Heroku уже тесно—надо переезжать или в другое облако или на железные сервера. Но это самая сложная и дорогая оптимизация, потому что теперь нужно будет самому заботиться о серверах, делать там контейнерную оркестрацию, проектировать CI/CD и так далее.
Большинство компаний любят заниматься преждевременной оптимизацией и оверинжинирингом без реальной потребности. Я тоже в своё время был адвокатом микросервисов и реактов, но сейчас—приверженец прагматичного подхода—вначале берем самые скучные и простые технологии, выжимаем из них максимум и только когда этого начинает не хватать—думаем в сторону альтернативных решений.
#проекты #инструменты
permalink | задонатить
Предущие части: введение, внешние сервисы
Сейчас вся моя инфраструктура крутится на самых дешёвых и простых инстантсах. 512 мегабайт памяти, редис на 25 мегабайт, какой-то дохлый постгрес. Всего этого хватает чтобы сайт бодро работал.
Что будет, если завтра ко мне придет не 1000 пользователей в день, а 1000000? Чтобы это узнать, нужно проводить нагрузочное тестирование. Для этого есть специальные инструменты: ApacheBench, Apache JMeter, Gatling и другие. Они позволяют заскриптовать нагрузку, например пользователь заходит кликает по фильтрам, потом идет на котика, потом на блог и так далее и запустить это в тысячу параллельных потоков. После выполнения теста будет сгенерирован отчет о среднем времени доступа, квантилях, количестве ошибок и так далее.
Скорее всего, мой маленький сервер упадёт уже от ста конкуррентных пользователей. Или даже от десяти. Каждый запрос идёт в базу, достаёт оттуда данные и генерирует HTML. Учитывая, что данные у нас меняются нечасто, мы можем закешировать как результат запроса в базу, так и уже отрендеренный HTML. Rails предоставляет весь необходимый инструментарий, но в других фреймворках это тоже есть. Таким образом можно положить в Redis или Memcached сгенерированный HTML для всех страниц поиска и отдельных страниц котика и убрать обращение к базе данных и генерацию HTML.
Я предполагаю что это даст существенный прирост в производительности, но всё равно останется проблема слабого сервера—ему просто не хватит ни CPU ни памяти чтобы обрабатывать большое количество подключений. Тут нужно смотреть по стоимости и производительности—может быть будет дешевле добавить еще один такой же сервер, а может быть взять потолще. Так как наши вебсервера не хранят состояния, то можно просто их размножить. Теперь все будет упираться в базу данных. Можно добавить в кластер read-реплик, чтобы распределить нагрузку на чтение или взять сервер потолще, чтобы он смог обрабатывать большее количество запросов. Если и тут мы упиремся в лимиты, то надо смотреть по ситуации. Например, если основная нагрузка идет через поиск, то можно поднять ElasticSearch. Вариантов масса. Пока мы упрёмся в ограничения скорости работы уже самого интерпретатора Ruby, пройдет куча времени.
Естественно, до того как бросаться покупать сервера, нужно оптимизировать приложение до предела—убрать N+1 запросы, привести в порядок индексы в базе, закешировать всё что можно закешировать, упростить HTML-шаблоны. К сожалению обычно разработчики мало внимания уделяют простым но эффективным оптимизациям.
Еще одна важная особенность нашего решения—это Heroku. Он работает поверх AWS который работает поверх реального железа. То есть, просто вычислительные мощности будут снижаться с каждым добавленным уровнем виртуализации. Поэтому если на Heroku уже тесно—надо переезжать или в другое облако или на железные сервера. Но это самая сложная и дорогая оптимизация, потому что теперь нужно будет самому заботиться о серверах, делать там контейнерную оркестрацию, проектировать CI/CD и так далее.
Большинство компаний любят заниматься преждевременной оптимизацией и оверинжинирингом без реальной потребности. Я тоже в своё время был адвокатом микросервисов и реактов, но сейчас—приверженец прагматичного подхода—вначале берем самые скучные и простые технологии, выжимаем из них максимум и только когда этого начинает не хватать—думаем в сторону альтернативных решений.
#проекты #инструменты
permalink | задонатить
Через полчаса вместе с Егором будем рассказывать про ІТ гильдию.
https://youtu.be/8PR4SNCqKZk
Потом перемещаемся в войс-чат @itguildukraine для общения со зрителями и участниками.
Приглашаю всех.
https://youtu.be/8PR4SNCqKZk
Потом перемещаемся в войс-чат @itguildukraine для общения со зрителями и участниками.
Приглашаю всех.
Архитектура современных веб-приложений на примере adopt.com.ua. CMS. Мониторинг. Аналитика
Так как у меня нет тестов кроме линтеров, то нужно быть готовым быстро фиксить ошибки на проде. Для этого используются логгеры и трекеры ошибок. Логгер я не использую, так как у меня пока что нечего логировать особо. А вот для трекинга ошибок я пользуюсь отличным сервисом Sentry. Как он работает? Вы подключаете SDK в своё приложение, и при возникновении любой ошибки она будет отправлена на сервера Sentry. Дальше, в зависимости от того, что это за ошибка, она или будет съедена, или отправлена вам в виде нотификашки.
Это очень крутая штука, которая экономит прорву времени. О том, что у пользователя что-то сломалось, я узнаю через пару секунд. В ошибке фиксируется не только стектрейс, но и необходимые подробности—например браузер, идентификатор пользователя, параметры HTTP запроса и другое. Раньше для того чтобы понять что что-то упало нужно было копать логи. Сейчас с помощью Sentry и других подобных продуктов это становится очень простым.
Если вы по какой-то невообразимой причине еще не пользуетесь Sentry или аналогом—я строго рекомендую. Сейчас туда подключили еще и APM—Application Performance Monitoring. Эта штука показывает сколько времени занимали запросы к вашему серверу. Тоже очень важная аналитика, которая позволяет найти и тормозящие куски кода.
Для мониторинга доступности я использую UptimeRobot. Это сервис который через определённые промежутки времени ходит по HTTP куда вы скажете и рапортует об ошибках, если таковые возникнут. В бесплатной версии у него есть ограничение—сайте пингуется раз в 5 минут. Но мне этого достаточно. Подобного рода сервисов вагон и маленькая тележка.
Для аналитики пока что подключен google analytics и google search console. Второй я хочу поменять на что-то более вменяемое, но пока руки не дошли. Кроме того хочется прикрутить продуктовую аналитику, чтобы понимать поведение пользователя на сайте и тестировать продуктовые гипотезы. Но это пока только в планах.
Еще одной небольшой частью является CMS. У нас на сайте есть информационный раздел, где редакторы могут публиковать статьи. Вначале я сделал свою CMS на базе встроенного в Ruby on Rails ActionText, но у неё оказались ограниченные возможности. Поэтому я поставил сбоку Ghost который дает полноценные возможности для написания материалов и написал интеграцию—в момент публикации статьи на Ghost она пушится к нам на сайт и я сохраняю HTML, который дальше отрисовывается.
Эта интеграция стала началом моего знакомства с Ghost. Дальше я перевел на него свой блог, написал интеграцию с телеграмом и сейчас делаю маленький продукт для блогеров и инфобизнесменов на базе этой связки.
---
Стоимость всей инфраструктуры: GitLab+Pipelines бесплатно, Heroku Dyno Web + Worker 14$, Heroku Postgres 9$, Heroku Redis бесплатно, AWS S3 0.25$, AWS CloudFront 2.60$, Sentry бесплатно, Uptimerobot бесплатно, ImageKit.io бесплатно, Mailjet бесплатно, Cloudflare бесплатно. Итого 25.85$ за всё.
---
Как видите, даже для такого простого сайта используется прорва сложных технологий. И это не оверинжиниринг, я делал всё по минимуму.
#проекты #работа #инструменты
permalink | задонатить
Так как у меня нет тестов кроме линтеров, то нужно быть готовым быстро фиксить ошибки на проде. Для этого используются логгеры и трекеры ошибок. Логгер я не использую, так как у меня пока что нечего логировать особо. А вот для трекинга ошибок я пользуюсь отличным сервисом Sentry. Как он работает? Вы подключаете SDK в своё приложение, и при возникновении любой ошибки она будет отправлена на сервера Sentry. Дальше, в зависимости от того, что это за ошибка, она или будет съедена, или отправлена вам в виде нотификашки.
Это очень крутая штука, которая экономит прорву времени. О том, что у пользователя что-то сломалось, я узнаю через пару секунд. В ошибке фиксируется не только стектрейс, но и необходимые подробности—например браузер, идентификатор пользователя, параметры HTTP запроса и другое. Раньше для того чтобы понять что что-то упало нужно было копать логи. Сейчас с помощью Sentry и других подобных продуктов это становится очень простым.
Если вы по какой-то невообразимой причине еще не пользуетесь Sentry или аналогом—я строго рекомендую. Сейчас туда подключили еще и APM—Application Performance Monitoring. Эта штука показывает сколько времени занимали запросы к вашему серверу. Тоже очень важная аналитика, которая позволяет найти и тормозящие куски кода.
Для мониторинга доступности я использую UptimeRobot. Это сервис который через определённые промежутки времени ходит по HTTP куда вы скажете и рапортует об ошибках, если таковые возникнут. В бесплатной версии у него есть ограничение—сайте пингуется раз в 5 минут. Но мне этого достаточно. Подобного рода сервисов вагон и маленькая тележка.
Для аналитики пока что подключен google analytics и google search console. Второй я хочу поменять на что-то более вменяемое, но пока руки не дошли. Кроме того хочется прикрутить продуктовую аналитику, чтобы понимать поведение пользователя на сайте и тестировать продуктовые гипотезы. Но это пока только в планах.
Еще одной небольшой частью является CMS. У нас на сайте есть информационный раздел, где редакторы могут публиковать статьи. Вначале я сделал свою CMS на базе встроенного в Ruby on Rails ActionText, но у неё оказались ограниченные возможности. Поэтому я поставил сбоку Ghost который дает полноценные возможности для написания материалов и написал интеграцию—в момент публикации статьи на Ghost она пушится к нам на сайт и я сохраняю HTML, который дальше отрисовывается.
Эта интеграция стала началом моего знакомства с Ghost. Дальше я перевел на него свой блог, написал интеграцию с телеграмом и сейчас делаю маленький продукт для блогеров и инфобизнесменов на базе этой связки.
---
Стоимость всей инфраструктуры: GitLab+Pipelines бесплатно, Heroku Dyno Web + Worker 14$, Heroku Postgres 9$, Heroku Redis бесплатно, AWS S3 0.25$, AWS CloudFront 2.60$, Sentry бесплатно, Uptimerobot бесплатно, ImageKit.io бесплатно, Mailjet бесплатно, Cloudflare бесплатно. Итого 25.85$ за всё.
---
Как видите, даже для такого простого сайта используется прорва сложных технологий. И это не оверинжиниринг, я делал всё по минимуму.
#проекты #работа #инструменты
permalink | задонатить
IDE против текстового редактора
Основной мой рабочий инструмент—IntelliJ IDEA. В нем я делаю вcё.
Основной аргумент сторонников работы в текстовых редакторах—это минимализм, простота, скорость. По поводу производительности всего что сделано на электроне есть вопросы. А вот с минимализмом и простотой сложнее.
Для работы мне нужно несколько вещей: собственно редактор с хорошим автокомплитом и навигацией, дебаггер для java/ruby/python, инструмент для доступа к базам данных, возможность запускать приложения и прогонять тесты.
Все это есть в одном продукте от IntelliJ. Если вы фронтенд программист то вероятно кроме vscode вам ничего и не надо, потому что дебаггер в браузере а база данных не нужна.
Я пользуюсь IDEA еще с 2006-го года. С версии 5.5 вроде. Скоро 20 лет будет :) За это время я привык к интерфейсу, к хоткеям, к инструментам разработчика.
Наверное самое удобное для меня—это возможность в одном месте иметь запущенный сервер и подключение к базе данных. Не нужно переключаться между разными программами, все бесшовно.
Все текстовые редакторы, которыми я пробовал пользоваться, были только текстовыми редакторами. Для нормального автокомплита нужно ставить всякие плагины, базы данных нет, дебаггер подключать тоже через какие-то плагины, короче все сложно и недоступно. Поэтому мне может быть и хотелось бы перейти на минималистичный и быстрый Sublime Text, но потребность в интегрированной среде у меня превышает боли от её использования. А болей вроде как и нет.
Проблема со скоростью индексирования и запуска я решил покупкой NVMe, 32GiB памяти и мощного процессора. Проекты у меня открываются за пару секунд.
Лицензия у меня приватная, купленная за свои деньги, обновляемая ежегодно. Продукт того однозначно стоит.
#инструменты
permalink | задонатить
Основной мой рабочий инструмент—IntelliJ IDEA. В нем я делаю вcё.
Основной аргумент сторонников работы в текстовых редакторах—это минимализм, простота, скорость. По поводу производительности всего что сделано на электроне есть вопросы. А вот с минимализмом и простотой сложнее.
Для работы мне нужно несколько вещей: собственно редактор с хорошим автокомплитом и навигацией, дебаггер для java/ruby/python, инструмент для доступа к базам данных, возможность запускать приложения и прогонять тесты.
Все это есть в одном продукте от IntelliJ. Если вы фронтенд программист то вероятно кроме vscode вам ничего и не надо, потому что дебаггер в браузере а база данных не нужна.
Я пользуюсь IDEA еще с 2006-го года. С версии 5.5 вроде. Скоро 20 лет будет :) За это время я привык к интерфейсу, к хоткеям, к инструментам разработчика.
Наверное самое удобное для меня—это возможность в одном месте иметь запущенный сервер и подключение к базе данных. Не нужно переключаться между разными программами, все бесшовно.
Все текстовые редакторы, которыми я пробовал пользоваться, были только текстовыми редакторами. Для нормального автокомплита нужно ставить всякие плагины, базы данных нет, дебаггер подключать тоже через какие-то плагины, короче все сложно и недоступно. Поэтому мне может быть и хотелось бы перейти на минималистичный и быстрый Sublime Text, но потребность в интегрированной среде у меня превышает боли от её использования. А болей вроде как и нет.
Проблема со скоростью индексирования и запуска я решил покупкой NVMe, 32GiB памяти и мощного процессора. Проекты у меня открываются за пару секунд.
Лицензия у меня приватная, купленная за свои деньги, обновляемая ежегодно. Продукт того однозначно стоит.
#инструменты
permalink | задонатить
Оновлення бібліотек на проектах
"Rotting software" це серйозна проблема. Вибухове зростання індустрії генерує таке ж зростання кількості інструментів розробки та пришвидшує старіння існуючих рішень.
В 2015 для розробки стартапа ми взяли мікросервіси та Spring Cloud Netflix. До 2017 половину з цього стеку сам Netflix перевів у maintenance режим, а деякі рішення просто задепрекейтив у себе та залишив напризволяще. Ми ще не встигли вийти в продакшн, а одна з ключових підсистем уже не розвивається, просто чудово!
Якщо не пильнувати постійно всі залежності, то рано чи пізно є ризик нарватися на багу або вразливість які впливають на твій проект, а оновлення буде складним та дорогим.
На всіх своїх Ruby on Rails проектах перший крок який я завжди роблю перед початком роботи над завданням, це
Завжди є спокуса залишитися на стабільній версії та не оновлюватися. Але далі технічний борг буде тільки накопичуватися. В мене є Spring Boot проект, так версія дворічної давності. Я не можу просто так оновитися, навіть на мінорну, в мене починають падати тести, якісь запити в базу не проходять. Потрібно з'ясовувати що змінилося, переписувати, а це ліниво, довго, дорого і небезпечно.
Є всякі рішення типу ботів які стежать за оновленнями, Renovate, Dependabot і так далі. Я не пробував ними користуватися, але вважаю їх корисними, якщо не ігнорувати рекомендації.
Регулярне оновлення залежностей проекта має бути в базових правилах гігієни.
#работа
permalink | donate
"Rotting software" це серйозна проблема. Вибухове зростання індустрії генерує таке ж зростання кількості інструментів розробки та пришвидшує старіння існуючих рішень.
В 2015 для розробки стартапа ми взяли мікросервіси та Spring Cloud Netflix. До 2017 половину з цього стеку сам Netflix перевів у maintenance режим, а деякі рішення просто задепрекейтив у себе та залишив напризволяще. Ми ще не встигли вийти в продакшн, а одна з ключових підсистем уже не розвивається, просто чудово!
Якщо не пильнувати постійно всі залежності, то рано чи пізно є ризик нарватися на багу або вразливість які впливають на твій проект, а оновлення буде складним та дорогим.
На всіх своїх Ruby on Rails проектах перший крок який я завжди роблю перед початком роботи над завданням, це
bundle update—пошук нових версій бібліотек їх оновлення. Такий підхід дозволяє пом'якшити удар від оноволень та розтягнути його на весь життєвий цикл проекту. В багатьох пакетних менеджерах є схожа команда, наприклад npm update.Завжди є спокуса залишитися на стабільній версії та не оновлюватися. Але далі технічний борг буде тільки накопичуватися. В мене є Spring Boot проект, так версія дворічної давності. Я не можу просто так оновитися, навіть на мінорну, в мене починають падати тести, якісь запити в базу не проходять. Потрібно з'ясовувати що змінилося, переписувати, а це ліниво, довго, дорого і небезпечно.
Є всякі рішення типу ботів які стежать за оновленнями, Renovate, Dependabot і так далі. Я не пробував ними користуватися, але вважаю їх корисними, якщо не ігнорувати рекомендації.
Регулярне оновлення залежностей проекта має бути в базових правилах гігієни.
#работа
permalink | donate
❤🔥1
Веб-скрапинг
Интернет—бездонный океан информации. Часто она не структурирована и требует подготовки, чтобы быть полезной. Множество продуктов строят свою бизнес-модель на сборе и обработке данных.
Веб-скрапинг—это автоматизированный сбор информации с сайтов и других источников: публичных API, файлов с данными и так далее. Скрапинг нужен везде и всегда.
Первый раз я столкнулся с этим в 2010, когда мы были совладельцами маленькой сети зоомагазинов и нужно было искать персонал. Для этого меня попросили сделать сбор или парсинг резюме продавцов. Я тогда еще не умел хорошо искать существующие решения, поэтому не придумал ничего лучше нежели написать Swing-приложение куда оператор бы копипастил текст из сайта, который потом разбирался на запчасти и ложился в MS Access базу. Почему-то я не догадался написать или поискать полноценный краулер. Система естественно была неудобной и не работала, проект забросил.
Несколько лет спустя я пошел работать в proptech-стартап. Там скрапинг объявлений о продаже недвижимости необходимо было делать в промышленных масштабах. Этим занимались наши дата-саентисты (привет Игорь и Игорёк), благодаря которым я изучил инструменты и подходы к скрапингу. Чуть позже один из моих клиентов пришел с большим проектом—аналитика цен в торговых сетях. Там я уже сам с нуля строил скрапинговую инфраструктуру и пайплайны обработки.
Потом было еще несколько коммерческих проектов связанных со сбором данных ну и по мелочам такие задачи всегда возникали.
Например, для adopt.com.ua нам нужно было собрать список ветклиник. Для этого я за 10 минут написал простой скрапер, который ходил по сайту-каталогу и собирал данные.
Для своей читалки телеграм каналов я написал скрапер веб-версии телеграма.
Промышленный скрапинг я очень не люблю. Во-первых, это обезьянья работа—ходить по сайту и писать селекторы. Во-вторых, сайты часто противостоят попыткам собрать данные. Особенно успешны в этом деле большие корпорации—фейсбуки, амазоны, линкедины и так далее. Они зорко бдят и моментально блочат любую подозрительную активность. Нужно применять контр-меры и заниматься grayhat работой. В-третьих, мало получить сырые данные, их потом нужно нормализовать и обработать. Человечество пока что не придумало ничего лучше регэкспов, поэтому это еще один кропотливый и не особо творческий кусок работы.
Ну и самое главное—как только источник поменял дизайн то все падает и надо начинать работу заново. Постоянное противоборство утомляет и надоедает. Скрапинг это не творческая работа, это методичное ремесленничество, поэтому честно говоря я его терпеть не могу.
Но делать все равно надо, поэтому в следующей части я расскажу об инструментах, которые применяю для скрапинга.
#инструменты #работа
permalink | задонатить
Интернет—бездонный океан информации. Часто она не структурирована и требует подготовки, чтобы быть полезной. Множество продуктов строят свою бизнес-модель на сборе и обработке данных.
Веб-скрапинг—это автоматизированный сбор информации с сайтов и других источников: публичных API, файлов с данными и так далее. Скрапинг нужен везде и всегда.
Первый раз я столкнулся с этим в 2010, когда мы были совладельцами маленькой сети зоомагазинов и нужно было искать персонал. Для этого меня попросили сделать сбор или парсинг резюме продавцов. Я тогда еще не умел хорошо искать существующие решения, поэтому не придумал ничего лучше нежели написать Swing-приложение куда оператор бы копипастил текст из сайта, который потом разбирался на запчасти и ложился в MS Access базу. Почему-то я не догадался написать или поискать полноценный краулер. Система естественно была неудобной и не работала, проект забросил.
Несколько лет спустя я пошел работать в proptech-стартап. Там скрапинг объявлений о продаже недвижимости необходимо было делать в промышленных масштабах. Этим занимались наши дата-саентисты (привет Игорь и Игорёк), благодаря которым я изучил инструменты и подходы к скрапингу. Чуть позже один из моих клиентов пришел с большим проектом—аналитика цен в торговых сетях. Там я уже сам с нуля строил скрапинговую инфраструктуру и пайплайны обработки.
Потом было еще несколько коммерческих проектов связанных со сбором данных ну и по мелочам такие задачи всегда возникали.
Например, для adopt.com.ua нам нужно было собрать список ветклиник. Для этого я за 10 минут написал простой скрапер, который ходил по сайту-каталогу и собирал данные.
Для своей читалки телеграм каналов я написал скрапер веб-версии телеграма.
Промышленный скрапинг я очень не люблю. Во-первых, это обезьянья работа—ходить по сайту и писать селекторы. Во-вторых, сайты часто противостоят попыткам собрать данные. Особенно успешны в этом деле большие корпорации—фейсбуки, амазоны, линкедины и так далее. Они зорко бдят и моментально блочат любую подозрительную активность. Нужно применять контр-меры и заниматься grayhat работой. В-третьих, мало получить сырые данные, их потом нужно нормализовать и обработать. Человечество пока что не придумало ничего лучше регэкспов, поэтому это еще один кропотливый и не особо творческий кусок работы.
Ну и самое главное—как только источник поменял дизайн то все падает и надо начинать работу заново. Постоянное противоборство утомляет и надоедает. Скрапинг это не творческая работа, это методичное ремесленничество, поэтому честно говоря я его терпеть не могу.
Но делать все равно надо, поэтому в следующей части я расскажу об инструментах, которые применяю для скрапинга.
#инструменты #работа
permalink | задонатить
Веб-скрапинг. Инструменты
Для скрапинга можно использовать всё что угодно. Вам нужно лишь сделать запрос, получить содержимое и дальше его разобрать. Теоретически, скрапинг можно делать на bash + какой-то программой для работы с xml.
Библиотеки для работы с сетью и парсинга html есть во всех языках. Можете брать любой. Однако скрапинг помимо собственно запроса и обработки включает еще кучу всяких вещей.
Вам нужно ходить по ссылкам и желательно делать это параллельно. Нужно отсекать дубликаты чтобы не было циклов. Если сайт работает медленно или отдает ошибки то нужно делать повторные запросы и ограничивать количество запросов в секунду чтобы не положить его. Все должно работать в куче потоков и асинхронно, потому что это I/O. Нужно прокидывать правильные юзерагенты. Часто для доступа к страницам нужно логиниться на сайт и передавать в запросе печеньку. Если вы работаете с SPA то нужно подключать headless браузер чтобы выполнялся JS. После извлечения нужных данных нужно положить их в базу и дообработать. Если скрапинг делается периодчески, желательно собирать статистику и делать мониторинг—сколько всего страниц обработано, сколько с ошибками и так далее. Как и в любой задаче, как только начинаешь вникать детали то проваливаешься в кроличью нору.
Исторически сложилось, что кроме поисковиков больше всего скрапингом занимаются датасаенс ребята. На мой взгляд, именно у них наиболее развиты инструменты. Я делал большие проекты, пользуюсь сам и рекомендую вам scrapy. Он сделан на python, и из коробки решает практически все задачи, а что не решает—докручивается плагинами. Самая распространённая такая задача—это выполнять JS. Для этого есть проекты splash, scrapy-selenium и другие. У ruby есть неплохой kimurai, node.js тоже богат на инструментарий, но с ним одна проблема—пакеты делаются усилиями одиночных людей и быстро перестают поддерживаться. Puppeteer и его друзья—это не совсем инструменты для скрапинга, это low-level управление браузерами, которое можно использовать в том числе и для скрапинга, поэтому я их не рассматриваю. Возможно в комментариях читатель подскажет реальную альтернативу scrapy, но я такого не видел.
Кроме собственно scrapy, для работы вам нужно будет научиться XPath, чтобы разбирать HTML, который пришел на вход. Есть библиотеки, которые позволяют работать с CSS-селекторами, но я уже привык к XPath и всем советую его изучить.
Но написать скрапер—это только половина, а то и четверть работы. Дальше нужно сделать инфраструкту чтобы он работал по расписанию, подключать прокси, мониторинг, постобработку и так далее и так далее. Есть продукты которые частично решают эти задачи, например Scrapinghub, но чаще приходится городить свой огород, потому что коробочные решения лимитированы. Одна из моих идей для проектов—это как раз сервис который предоставляет такую инфраструктуру, но это непросто сделать, поэтому я пока забил.
Скрапинг это очень популярная задача, поэтому в интернетах есть миллионы туториалов для всех языков. Если вам, например, зачем-то понадобится собрать имена и емейлы депутатов Верховной Рады—вы уже знаете с помощью чего это можно сделать.
#инструменты #работа
permalink | задонатить
Для скрапинга можно использовать всё что угодно. Вам нужно лишь сделать запрос, получить содержимое и дальше его разобрать. Теоретически, скрапинг можно делать на bash + какой-то программой для работы с xml.
Библиотеки для работы с сетью и парсинга html есть во всех языках. Можете брать любой. Однако скрапинг помимо собственно запроса и обработки включает еще кучу всяких вещей.
Вам нужно ходить по ссылкам и желательно делать это параллельно. Нужно отсекать дубликаты чтобы не было циклов. Если сайт работает медленно или отдает ошибки то нужно делать повторные запросы и ограничивать количество запросов в секунду чтобы не положить его. Все должно работать в куче потоков и асинхронно, потому что это I/O. Нужно прокидывать правильные юзерагенты. Часто для доступа к страницам нужно логиниться на сайт и передавать в запросе печеньку. Если вы работаете с SPA то нужно подключать headless браузер чтобы выполнялся JS. После извлечения нужных данных нужно положить их в базу и дообработать. Если скрапинг делается периодчески, желательно собирать статистику и делать мониторинг—сколько всего страниц обработано, сколько с ошибками и так далее. Как и в любой задаче, как только начинаешь вникать детали то проваливаешься в кроличью нору.
Исторически сложилось, что кроме поисковиков больше всего скрапингом занимаются датасаенс ребята. На мой взгляд, именно у них наиболее развиты инструменты. Я делал большие проекты, пользуюсь сам и рекомендую вам scrapy. Он сделан на python, и из коробки решает практически все задачи, а что не решает—докручивается плагинами. Самая распространённая такая задача—это выполнять JS. Для этого есть проекты splash, scrapy-selenium и другие. У ruby есть неплохой kimurai, node.js тоже богат на инструментарий, но с ним одна проблема—пакеты делаются усилиями одиночных людей и быстро перестают поддерживаться. Puppeteer и его друзья—это не совсем инструменты для скрапинга, это low-level управление браузерами, которое можно использовать в том числе и для скрапинга, поэтому я их не рассматриваю. Возможно в комментариях читатель подскажет реальную альтернативу scrapy, но я такого не видел.
Кроме собственно scrapy, для работы вам нужно будет научиться XPath, чтобы разбирать HTML, который пришел на вход. Есть библиотеки, которые позволяют работать с CSS-селекторами, но я уже привык к XPath и всем советую его изучить.
Но написать скрапер—это только половина, а то и четверть работы. Дальше нужно сделать инфраструкту чтобы он работал по расписанию, подключать прокси, мониторинг, постобработку и так далее и так далее. Есть продукты которые частично решают эти задачи, например Scrapinghub, но чаще приходится городить свой огород, потому что коробочные решения лимитированы. Одна из моих идей для проектов—это как раз сервис который предоставляет такую инфраструктуру, но это непросто сделать, поэтому я пока забил.
Скрапинг это очень популярная задача, поэтому в интернетах есть миллионы туториалов для всех языков. Если вам, например, зачем-то понадобится собрать имена и емейлы депутатов Верховной Рады—вы уже знаете с помощью чего это можно сделать.
#инструменты #работа
permalink | задонатить
Как я деплоймент скрипты на JS писал
В одном из стартапов где я работал, я полностью занимался инфраструктурой. Вначале вся наша микросервисная история деплоилась на Elastic Beanstalk, потом решили переехать на ECS. Для CI/CD зарядили Jenkins и кучу баш-скриптов, осталось научиться деплоить это в прод.
Я взялся за эту задачу и зачем-то решил что все деплоймент скрипты у меня будут на JS. Ну как зачем. Я думал что сделаю полноценную ChatOps систему с blue-green деплоем прямо из слака, а работать все это должно было на AWS Lambda, которая в то время поддерживала только JS, Python и Java. Почему я не взял Python это загадка века. Кажется, потому что JS ставил все нужные пакеты локально и это было типа проще чем виртуалэнвы и прочая питонья дичь. Но это не точно.
В общем задача у меня была такая. Взять список контейнеров которые крутятся на стейджинге, взять список из прода, и заменять инстансы по одному, пока полностью все не обновится. В процессе смотреть чтобы ничего не упало.
Все это я свалил в один большой JS-скрипт на тыщу строк, который с помощью AWS SDK ходил и выяснял нужные наборы сервисов и формировал для ECS таск дефинишены где были прописаны нужные секреты. Helm на минималках короч.
Надо сказать что на JS до того я писал не сильно много, с промисами меня никто не познакомил, а async/await тогда еще не было, node 4. Из-за асинхронщины бывало такое что амазоновский API нас троттлил.
Короче получился один сплошной неподдерживаемый callback hell, просто ужасно всё было. Потом я позвал фуллстек дева и он помог переписать все в более удобоваримый вид. Так оно и прожило кажется два года. ChatOps и деплой из слака я конечно же не сделал. Полноценную CI/CD систему типа Spinnaker тоже не сделал, хотя хотелось. Потом один из разработчиков решил что CLI-утилита для редеплоя это отличный способ заняться resume-driven разработкой и переписал тулзу на Go.
Надо было изначально все нормально делать на питоне, тогда и написал бы лучше, и оно бы хорошо поддерживалось, и переписывать на Go не надо было. В общем с тех пор на JS консольных утилит я больше не делаю, и вам не советую.
#инструменты #кулстори
permalink | задонатить
В одном из стартапов где я работал, я полностью занимался инфраструктурой. Вначале вся наша микросервисная история деплоилась на Elastic Beanstalk, потом решили переехать на ECS. Для CI/CD зарядили Jenkins и кучу баш-скриптов, осталось научиться деплоить это в прод.
Я взялся за эту задачу и зачем-то решил что все деплоймент скрипты у меня будут на JS. Ну как зачем. Я думал что сделаю полноценную ChatOps систему с blue-green деплоем прямо из слака, а работать все это должно было на AWS Lambda, которая в то время поддерживала только JS, Python и Java. Почему я не взял Python это загадка века. Кажется, потому что JS ставил все нужные пакеты локально и это было типа проще чем виртуалэнвы и прочая питонья дичь. Но это не точно.
В общем задача у меня была такая. Взять список контейнеров которые крутятся на стейджинге, взять список из прода, и заменять инстансы по одному, пока полностью все не обновится. В процессе смотреть чтобы ничего не упало.
Все это я свалил в один большой JS-скрипт на тыщу строк, который с помощью AWS SDK ходил и выяснял нужные наборы сервисов и формировал для ECS таск дефинишены где были прописаны нужные секреты. Helm на минималках короч.
Надо сказать что на JS до того я писал не сильно много, с промисами меня никто не познакомил, а async/await тогда еще не было, node 4. Из-за асинхронщины бывало такое что амазоновский API нас троттлил.
Короче получился один сплошной неподдерживаемый callback hell, просто ужасно всё было. Потом я позвал фуллстек дева и он помог переписать все в более удобоваримый вид. Так оно и прожило кажется два года. ChatOps и деплой из слака я конечно же не сделал. Полноценную CI/CD систему типа Spinnaker тоже не сделал, хотя хотелось. Потом один из разработчиков решил что CLI-утилита для редеплоя это отличный способ заняться resume-driven разработкой и переписал тулзу на Go.
Надо было изначально все нормально делать на питоне, тогда и написал бы лучше, и оно бы хорошо поддерживалось, и переписывать на Go не надо было. В общем с тех пор на JS консольных утилит я больше не делаю, и вам не советую.
#инструменты #кулстори
permalink | задонатить
Сложности текстовой коммуникации
Пяток лет назад я попал на серию статей Егора Бугаенко об организации работы в распределённой команде. Одной из ключевых особенностей этой системы был запрет на любые коммуникации вне гитхаб тикетов. Проблема потерянных пакетов, отсутствия документации и незафиксированных договорённостей мне очень знакома.
Позже эту же идею, поощрение структурированного текстового общения я увидел в блогах малоизвестной конторы Arkency и более известной конторы Basecamp.
С тех пор меня не покидала идея построить утопию. Утопию, в которой все общение велось бы в рамках тикетов, документация была бы собрана там же, не было необходимости тратить время на созвоны и общение в чатах а сама коммуникация была бы значительно более содержательной.
Я несколько раз пытался построить эту утопию и каждый раз терпел поражение. В основном по неопытности, но так же от отсутствия мотивации у своих коллег или подчинённых. Каждый раз все начиналось с "делай все по тикету" а заканчивалось когда человек подходил лично и спрашивал. Довольно быстро система скатывалась в ad-hoc общение и переставала работать.
Главная причина этого конечно же в доступности. Когда тебе ничего не стоит подойти к коллеге, написать в слак, созвониться в зуме, то нужно приложить особые усилия, чтобы задать этот же вопрос или поставить эту же задачу в структурированном виде в тикете или документе.
Поэтому, вероятно, пока доступны все средства быстрой и дешевой коммуникации, то, вместо составления документов и последующего асинхронного обсуждения, будут собирать зум митинги и час жевать жвачку которая интересна двум из десяти присутствующих.
Ремоут пришел, но асинхронщина не наступила. И неизвестно когда наступит. Хотя мне очень бы хотелось работать именно в таком режиме, но подавляющее большинство работодателей и заказчиков не согласятся.
Хотелось бы в будущем построить компанию, которая будет жить именно по таким принципам.
#работа #продуктивность
permalink | задонатить
Пяток лет назад я попал на серию статей Егора Бугаенко об организации работы в распределённой команде. Одной из ключевых особенностей этой системы был запрет на любые коммуникации вне гитхаб тикетов. Проблема потерянных пакетов, отсутствия документации и незафиксированных договорённостей мне очень знакома.
Позже эту же идею, поощрение структурированного текстового общения я увидел в блогах малоизвестной конторы Arkency и более известной конторы Basecamp.
С тех пор меня не покидала идея построить утопию. Утопию, в которой все общение велось бы в рамках тикетов, документация была бы собрана там же, не было необходимости тратить время на созвоны и общение в чатах а сама коммуникация была бы значительно более содержательной.
Я несколько раз пытался построить эту утопию и каждый раз терпел поражение. В основном по неопытности, но так же от отсутствия мотивации у своих коллег или подчинённых. Каждый раз все начиналось с "делай все по тикету" а заканчивалось когда человек подходил лично и спрашивал. Довольно быстро система скатывалась в ad-hoc общение и переставала работать.
Главная причина этого конечно же в доступности. Когда тебе ничего не стоит подойти к коллеге, написать в слак, созвониться в зуме, то нужно приложить особые усилия, чтобы задать этот же вопрос или поставить эту же задачу в структурированном виде в тикете или документе.
Поэтому, вероятно, пока доступны все средства быстрой и дешевой коммуникации, то, вместо составления документов и последующего асинхронного обсуждения, будут собирать зум митинги и час жевать жвачку которая интересна двум из десяти присутствующих.
Ремоут пришел, но асинхронщина не наступила. И неизвестно когда наступит. Хотя мне очень бы хотелось работать именно в таком режиме, но подавляющее большинство работодателей и заказчиков не согласятся.
Хотелось бы в будущем построить компанию, которая будет жить именно по таким принципам.
#работа #продуктивность
permalink | задонатить
👍2❤🔥1❤1
daliy rozhok №4: Жора
Дайджест канала @daily_rozhok. На этой неделе я рассказываю про Жору — моего товарища который имеет все шансы стать бездомным.
Как становятся бомжами. Жора — интро. Знакомимся с Жорой.
Как становятся бомжами. Такси — Жора пытается заработать деньги в такси.
Как становятся бомжами. Деньги и подарки — Жора едет за тридевять земель с подарком даме сердца.
Как становятся бомжами. Лень — Жора не спешит.
Как становятся бомжами. Помощь — ищу способы помочь Жоре.
Прочтите и предложите свои варианты выходов из ситуации. Забить — тоже выход.
Почему кошки могут ссать мимо лотка? — рубрика "ветеринарные советы". Если вам нужна порядочная кошка — обращайтесь.
Мудрости из интернета, «7 takeaways on how to do things», «Here what I learned» — чему я научился из твитов умных людей (спойлер—ничему).
#daily_rozhok
permalink | задонатить
Дайджест канала @daily_rozhok. На этой неделе я рассказываю про Жору — моего товарища который имеет все шансы стать бездомным.
Как становятся бомжами. Жора — интро. Знакомимся с Жорой.
Как становятся бомжами. Такси — Жора пытается заработать деньги в такси.
Как становятся бомжами. Деньги и подарки — Жора едет за тридевять земель с подарком даме сердца.
Как становятся бомжами. Лень — Жора не спешит.
Как становятся бомжами. Помощь — ищу способы помочь Жоре.
Прочтите и предложите свои варианты выходов из ситуации. Забить — тоже выход.
Почему кошки могут ссать мимо лотка? — рубрика "ветеринарные советы". Если вам нужна порядочная кошка — обращайтесь.
Мудрости из интернета, «7 takeaways on how to do things», «Here what I learned» — чему я научился из твитов умных людей (спойлер—ничему).
#daily_rozhok
permalink | задонатить
ІТ или не ІТ компания?
Мой старый босс мне говорил такие слова: "надо работать в компании, кешфлоу которой завязан на программный продукт. В банках деньги зарабатывают те кто впаривают кредиты а не те кто делают бэкоффис систему. В банках программист это человек второго сорта, после собственно банкира. Поэтому в банки не ходи".
Была ли это ловкая манипуляция чтобы я не ушел в люксофт на проект ubs или действительно правда—мы уже не узнаем.
Но с тех пор эта установка во мне действует. Я считаю что работать нужно только в том месте, где разработчик—это first-class citizen, где деньги делаются на программном продукте, где вы влияете на бизнес. Однако если 15 лет назад эта грань была более четкой, то сейчас всё сложнее.
Например, магазин розетка—это ІТ-компания или нет? А каста.уа? Вот Саша Соловьев говорит что ІТ компания, потому что их продукт это сайт и ERP. Без этого они не могут существовать. Как амазон. Думаю что никто не будет утверждать что амазон—это не ІТ компания потому что они книги продают. А Киевстар или Lifecell — это IT-компании? Ведь они продают трубу. Да, их бизнес не может существовать без соответствующего софта, армии опсов и кучки девелоперов которые это поддерживают, но я например считаю что они не ІТ. А монобанк/тинькофф? Ведь у них нет отделений, вся суть в сайте/приложении/бэкоффисе. Наверное, монобанк это ІТ. Или нет? Есть такая шутка что рано или поздно любая успешная компания превращается в банк. А ракета или глово — это ІТ? Вроде как да, ведь вся суть тоже в приложении. Хотя деньги идут с оплаты работы курьеров-бегунков.
Кто не вызывает вопросов—это аутсорс да аутстафф. Тут все понятно—набрали гребцов, наша задача—сделать клиенту софт. Наши деньги правда не всегда связаны с клиентскими, мы продаём разработку. Точно ІТ, не ошибётесь. Благо, последнего типа компаний у нас большинство, поэтому можно сказать что почти все мы работаем в правильных компаниях.
Еще точно можно сказать что ІТ это то что не выходит в реальный мир, какой-нибудь SaaS. Электронная почта. Управление инфраструктурой и мониторинг. Документооборот.
По возможности я бы работал в чистых ІТ компаниях чтобы иметь прямое влияние на бизнес. И вам советую.
#лайфстайл
permalink | задонатить
Мой старый босс мне говорил такие слова: "надо работать в компании, кешфлоу которой завязан на программный продукт. В банках деньги зарабатывают те кто впаривают кредиты а не те кто делают бэкоффис систему. В банках программист это человек второго сорта, после собственно банкира. Поэтому в банки не ходи".
Была ли это ловкая манипуляция чтобы я не ушел в люксофт на проект ubs или действительно правда—мы уже не узнаем.
Но с тех пор эта установка во мне действует. Я считаю что работать нужно только в том месте, где разработчик—это first-class citizen, где деньги делаются на программном продукте, где вы влияете на бизнес. Однако если 15 лет назад эта грань была более четкой, то сейчас всё сложнее.
Например, магазин розетка—это ІТ-компания или нет? А каста.уа? Вот Саша Соловьев говорит что ІТ компания, потому что их продукт это сайт и ERP. Без этого они не могут существовать. Как амазон. Думаю что никто не будет утверждать что амазон—это не ІТ компания потому что они книги продают. А Киевстар или Lifecell — это IT-компании? Ведь они продают трубу. Да, их бизнес не может существовать без соответствующего софта, армии опсов и кучки девелоперов которые это поддерживают, но я например считаю что они не ІТ. А монобанк/тинькофф? Ведь у них нет отделений, вся суть в сайте/приложении/бэкоффисе. Наверное, монобанк это ІТ. Или нет? Есть такая шутка что рано или поздно любая успешная компания превращается в банк. А ракета или глово — это ІТ? Вроде как да, ведь вся суть тоже в приложении. Хотя деньги идут с оплаты работы курьеров-бегунков.
Кто не вызывает вопросов—это аутсорс да аутстафф. Тут все понятно—набрали гребцов, наша задача—сделать клиенту софт. Наши деньги правда не всегда связаны с клиентскими, мы продаём разработку. Точно ІТ, не ошибётесь. Благо, последнего типа компаний у нас большинство, поэтому можно сказать что почти все мы работаем в правильных компаниях.
Еще точно можно сказать что ІТ это то что не выходит в реальный мир, какой-нибудь SaaS. Электронная почта. Управление инфраструктурой и мониторинг. Документооборот.
По возможности я бы работал в чистых ІТ компаниях чтобы иметь прямое влияние на бизнес. И вам советую.
#лайфстайл
permalink | задонатить
Мои карьерные ошибки—долго засиживаться на одном месте
Если бы я перечислял все косяки в карьерном развитии, то первым бы шла длительная работа на одном месте.
Человек вообще склонен сопротивляться изменениям, и это очень часто вредит в стратегической перспективе. Вот так и я сидел на жопе ровно, пока часики тикали, а потом оглянуться не успел—годы прошли, время потрачено впустую, деньги не заработаны.
Моим первым проектом на первой работе была штука, которая никому не нужна. Руководство посадило двух студентов под присмотром писать новый модуль для большой системы. Но дело в том что клиента под модуль не было, требования высасывали из пальца, и как только закончился демо-бюджет, то мы пошли на реальные проекты, а тот код положили в стол. Достали его оттуда через три года, когда клиент нашёлся, то есть работа была не совсем бесполезно, но допиливали всё уже совсем другие люди.
Этот проект длился пару-тройку месяцев, после чего я переехал на саппорт адового легаси. Нужно было добавлять статические методы в классы на 10 000 строк, и это не шутка. Это был именно тот момент, когда нужно было задуматься о смене работы. Мой однокомнатник в этот момент работал в разработчике казуальных игр и писал маджонг на свинге. Стоит ли говорить, что его деятельность была в тыщу раз интереснее. Но я остался, потому что можно было парттаймить а я хотел получить диплом.
Так незаметно прошло семь с половиной лет. Из них самыми продуктивными было всего несколько месяцев, когда я реально чему-то научился, а не просто пассивно тянул лямку.
Конечно, ретроспективно понимаю что я не воспользовался миллионом возможностей, сидел на бесперспективных проектах, отказывался от командировок, не требовал повышения, не ходил по собесам и вообще всячески сопротивлялся карьерному росту.
Поэтому дело не совсем в том что я держался за одно место. Скорее я держался за один и тот же набор задач и компетенций. Сидел в зоне комфорта. Оправдывался тем что нарабатывал доменную экспертизу. Как известно, доменная экспертиза разработчику хоть и полезна, но не особо нужна. Вот и мне 7 лет работы с телекомами почти никак не пригодились в последующем.
А мог бы за то же время поработать на куче совершенно разных проектов, набраться опыта с разными технологиями, поработать в разных командах по разным методологиям. Стать нормальным T-shape человеком.
Так что меняйте проекты почаще. Или если не проекты то хотя бы наборы задач внутри них.
#карьера
permalink | задонатить
Если бы я перечислял все косяки в карьерном развитии, то первым бы шла длительная работа на одном месте.
Человек вообще склонен сопротивляться изменениям, и это очень часто вредит в стратегической перспективе. Вот так и я сидел на жопе ровно, пока часики тикали, а потом оглянуться не успел—годы прошли, время потрачено впустую, деньги не заработаны.
Моим первым проектом на первой работе была штука, которая никому не нужна. Руководство посадило двух студентов под присмотром писать новый модуль для большой системы. Но дело в том что клиента под модуль не было, требования высасывали из пальца, и как только закончился демо-бюджет, то мы пошли на реальные проекты, а тот код положили в стол. Достали его оттуда через три года, когда клиент нашёлся, то есть работа была не совсем бесполезно, но допиливали всё уже совсем другие люди.
Этот проект длился пару-тройку месяцев, после чего я переехал на саппорт адового легаси. Нужно было добавлять статические методы в классы на 10 000 строк, и это не шутка. Это был именно тот момент, когда нужно было задуматься о смене работы. Мой однокомнатник в этот момент работал в разработчике казуальных игр и писал маджонг на свинге. Стоит ли говорить, что его деятельность была в тыщу раз интереснее. Но я остался, потому что можно было парттаймить а я хотел получить диплом.
Так незаметно прошло семь с половиной лет. Из них самыми продуктивными было всего несколько месяцев, когда я реально чему-то научился, а не просто пассивно тянул лямку.
Конечно, ретроспективно понимаю что я не воспользовался миллионом возможностей, сидел на бесперспективных проектах, отказывался от командировок, не требовал повышения, не ходил по собесам и вообще всячески сопротивлялся карьерному росту.
Поэтому дело не совсем в том что я держался за одно место. Скорее я держался за один и тот же набор задач и компетенций. Сидел в зоне комфорта. Оправдывался тем что нарабатывал доменную экспертизу. Как известно, доменная экспертиза разработчику хоть и полезна, но не особо нужна. Вот и мне 7 лет работы с телекомами почти никак не пригодились в последующем.
А мог бы за то же время поработать на куче совершенно разных проектов, набраться опыта с разными технологиями, поработать в разных командах по разным методологиям. Стать нормальным T-shape человеком.
Так что меняйте проекты почаще. Или если не проекты то хотя бы наборы задач внутри них.
#карьера
permalink | задонатить
Продолжаем борьбу против Дія.Сіті
Завтра будет встреча министра Федорова с президентом Зеленским по поводу Дія Сіті. В этой связи минцифры попросило компании которые входят в ІТ-ассоциацию поддержать письменно законопроект 5376 (это самый важный закон из всего пакета Дія).
Поэтому просим руководителей ІТ компаний не бояться и поддержку не оказывать.
На эту тему есть наш пост на фейсбуке: https://www.facebook.com/itguildua/posts/124176489814715 просьба поддержать лайком и репостом.
Желающие продолжить общение приглашаются в тему на ДОУ: https://dou.ua/forums/topic/33645/
#StopDiiaCity
Завтра будет встреча министра Федорова с президентом Зеленским по поводу Дія Сіті. В этой связи минцифры попросило компании которые входят в ІТ-ассоциацию поддержать письменно законопроект 5376 (это самый важный закон из всего пакета Дія).
Поэтому просим руководителей ІТ компаний не бояться и поддержку не оказывать.
На эту тему есть наш пост на фейсбуке: https://www.facebook.com/itguildua/posts/124176489814715 просьба поддержать лайком и репостом.
Желающие продолжить общение приглашаются в тему на ДОУ: https://dou.ua/forums/topic/33645/
#StopDiiaCity
Facebook
Log in or sign up to view
See posts, photos and more on Facebook.
Первый митап Гильдии
Сегодня в 18:00 собираемся на первый оффлайн митап Гильдии ІТ-специалистов. Я там буду и зову вас.
Место проведения: Киев, ул. Богдана Хмельницкого 19/21, БЦ Леонардо, Платформа.
На митапе будет пара коротких докладов и Q&A. Среди выступающих: Егор Чумаков, Вова Кожаев и другие.
Детали: http://xn--r1a.website/itguildukraine/92
Сегодня в 18:00 собираемся на первый оффлайн митап Гильдии ІТ-специалистов. Я там буду и зову вас.
Место проведения: Киев, ул. Богдана Хмельницкого 19/21, БЦ Леонардо, Платформа.
На митапе будет пара коротких докладов и Q&A. Среди выступающих: Егор Чумаков, Вова Кожаев и другие.
Детали: http://xn--r1a.website/itguildukraine/92
Telegram
Гільдія ІТ-Фахівців
Напоминаю, что в эту субботу, в Киеве, в 18.00, в БЦ Леонардо, в ко-воркинге Плаформа пройдет митап Гильдии.
Регламент:
18.10 - 18.20 - Выступит Егор Чумаков, президент Гильдии, скажет свое "Вводное слово"
18.20 - 19.00 - Владимир Кожаев. Сделает доклад…
Регламент:
18.10 - 18.20 - Выступит Егор Чумаков, президент Гильдии, скажет свое "Вводное слово"
18.20 - 19.00 - Владимир Кожаев. Сделает доклад…
Комьюнити решает
Люблю играть в арена-шутеры. Quake и подобные игры. Но вот незадача — таких как я очень мало. В шутаны катает немного людей, а среди тех, кто катает — очень много киберкотлет, с которыми нет никакого смысла играть.
Зато очень много людей играет в доту. Или в лол. Или в вов. Или в ксго. Там стабильно высокий онлайн и серьезное коммьюнити. Можно без проблем найти себе соперников по уровню, или за тебя это сделает нейросеть матчмейкинга.
Какой бы классной не была игра, если там будет низкий онлайн, то рано или поздно она станет уделом маргиналов. И киберкотлет. Поэтому я играю не в quake а в ксго. Хотя quake мне нравится гораздо больше.
Какой бы хорошей не была технология, без поддержки людей она так и останется нишевым продуктом. Мы часто плюемся на инструменты и языки которыми пользуемся. Но они стали успешными в том числе благодаря тому, что вокруг каким-то образом сформировалось мощное ядро людей, которые реинфорсят своим присутствием этот самый продукт или технологию. И даже если разработчик или создатель подзабьет, комьюнити не даст технологии сдуться.
Даже если технология сама по себе не очень удачная, но у нее есть поддержка людей — то это все будет успешно двигаться, несмотря ни на что.
Люди это главное.
Вообще я больше люблю всякие непопулярные и эзотерические вещи. Но какими хорошими бы они не были, рано или поздно гиганты победят. Сейчас мне надо делать выбор между разными технологиями для одного проекта. Первая довольно сложная и громоздкая, зато очень-очень популярная. Другая — намного проще и делает всё что мне нужно, но за ней стоит лишь одна компания и очень маленькое комьюнити. Еще год назад я однозначно думал о выборе в пользу вторых ребят. Но сейчас мое мнение пошатнулось. Размер сообщества, количество контрибьюторов, количество материалов будет всегда большим у более популярных вещей и наверное разумнее делать выбор в их пользу.
С другой стороны, прыгать в поезд хайпа просто потому что все остальные запрыгнули и отказываться от других классных решений просто потому что они не такие популярные? Нужно искать баланс.
#лайфстайл
permalink | задонатить
Люблю играть в арена-шутеры. Quake и подобные игры. Но вот незадача — таких как я очень мало. В шутаны катает немного людей, а среди тех, кто катает — очень много киберкотлет, с которыми нет никакого смысла играть.
Зато очень много людей играет в доту. Или в лол. Или в вов. Или в ксго. Там стабильно высокий онлайн и серьезное коммьюнити. Можно без проблем найти себе соперников по уровню, или за тебя это сделает нейросеть матчмейкинга.
Какой бы классной не была игра, если там будет низкий онлайн, то рано или поздно она станет уделом маргиналов. И киберкотлет. Поэтому я играю не в quake а в ксго. Хотя quake мне нравится гораздо больше.
Какой бы хорошей не была технология, без поддержки людей она так и останется нишевым продуктом. Мы часто плюемся на инструменты и языки которыми пользуемся. Но они стали успешными в том числе благодаря тому, что вокруг каким-то образом сформировалось мощное ядро людей, которые реинфорсят своим присутствием этот самый продукт или технологию. И даже если разработчик или создатель подзабьет, комьюнити не даст технологии сдуться.
Даже если технология сама по себе не очень удачная, но у нее есть поддержка людей — то это все будет успешно двигаться, несмотря ни на что.
Люди это главное.
Вообще я больше люблю всякие непопулярные и эзотерические вещи. Но какими хорошими бы они не были, рано или поздно гиганты победят. Сейчас мне надо делать выбор между разными технологиями для одного проекта. Первая довольно сложная и громоздкая, зато очень-очень популярная. Другая — намного проще и делает всё что мне нужно, но за ней стоит лишь одна компания и очень маленькое комьюнити. Еще год назад я однозначно думал о выборе в пользу вторых ребят. Но сейчас мое мнение пошатнулось. Размер сообщества, количество контрибьюторов, количество материалов будет всегда большим у более популярных вещей и наверное разумнее делать выбор в их пользу.
С другой стороны, прыгать в поезд хайпа просто потому что все остальные запрыгнули и отказываться от других классных решений просто потому что они не такие популярные? Нужно искать баланс.
#лайфстайл
permalink | задонатить
Кадило крутится лавеха мутится
Когда работаешь фуллтайм то тебя не особо беспокоит эффективность. Каждый месяц тебе положена котлета, твое дело—появляться на дейли митингах и не быть уж совсем тунеядцем. Надо минимально работать.
Организм привыкает к занятости от звонка до звонка и помышляет о пятнице и выходных, которые следует хорошо провести после работы над интересным проектом.
Когда работаешь почасово или по-проектно, то рано или поздно подымается вопрос эффективности часа. Сколько я зарабатываю за час потраченного времени? Следующим идет вопрос "что можно сделать, чтобы поднять эффективность часа?". Когда и этот вопрос ±решен, приходит понимание — "если я не работаю, то теряю деньги".
Так легко можно попасться в ловушку погони за упущенной прибылью, стремиться работать больше и занять все время "продуктивной" деятельностью. Естественно, это путь вникуда. Всех денег не заработаешь.
Недавно я как-то сидел посреди дня и не делал ничего полезного. По какой-то причине осознание того, что прямо сейчас я теряю зеленые бумажки и просто просиживаю своё время пришло ко мне особенно ярко. Буквально — если я конкретно сейчас не делаю ничего для решения задач за которые получу деньги — значит я эти самые деньги теряю. Эта простая мысль вгоняет в депрессию. Это означает что как только ты отвлекаешься — печатный станок останавливается. Это означает что твой заработок и успех напрямую привязан ко времени которое ты тратишь на работу.
Будучи наёмным батраком в любой форме, хоть на галере, хоть на апворке, хоть джуном, хоть CTO, совершенно нет никакой возможности разорвать связь между временем и прибылью.
#лайфстайл
permalink | задонатить
Когда работаешь фуллтайм то тебя не особо беспокоит эффективность. Каждый месяц тебе положена котлета, твое дело—появляться на дейли митингах и не быть уж совсем тунеядцем. Надо минимально работать.
Организм привыкает к занятости от звонка до звонка и помышляет о пятнице и выходных, которые следует хорошо провести после работы над интересным проектом.
Когда работаешь почасово или по-проектно, то рано или поздно подымается вопрос эффективности часа. Сколько я зарабатываю за час потраченного времени? Следующим идет вопрос "что можно сделать, чтобы поднять эффективность часа?". Когда и этот вопрос ±решен, приходит понимание — "если я не работаю, то теряю деньги".
Так легко можно попасться в ловушку погони за упущенной прибылью, стремиться работать больше и занять все время "продуктивной" деятельностью. Естественно, это путь вникуда. Всех денег не заработаешь.
Недавно я как-то сидел посреди дня и не делал ничего полезного. По какой-то причине осознание того, что прямо сейчас я теряю зеленые бумажки и просто просиживаю своё время пришло ко мне особенно ярко. Буквально — если я конкретно сейчас не делаю ничего для решения задач за которые получу деньги — значит я эти самые деньги теряю. Эта простая мысль вгоняет в депрессию. Это означает что как только ты отвлекаешься — печатный станок останавливается. Это означает что твой заработок и успех напрямую привязан ко времени которое ты тратишь на работу.
Будучи наёмным батраком в любой форме, хоть на галере, хоть на апворке, хоть джуном, хоть CTO, совершенно нет никакой возможности разорвать связь между временем и прибылью.
#лайфстайл
permalink | задонатить
Аутсорс нация
Среди разработчиков распостранено мнение, что не имеет значения на какую компанию работать: продуктовую, сервисную, аутстафф, стартап, не-ІТ. Лишь бы платили денег и желательно побольше.
Согласно опросу ДОУ, 65% разработчиков заняты в аутсорсе, остальные—в продукте и стартапах. Рискну предположить, что в "настоящем" продукте работает гораздо меньше 35%—под "настоящим" я понимаю компанию которая была создана у нас и содержит основную часть рабочей силы у нас. Потому что я например тоже работаю в продукте, но заказчик зарубежный. Добавочная стоимость и все деньги остаются за рубежом, я получаю только свой рейт.
Опять же, можно спорить о том, что такое настоящий "отечественный" продукт, например Grammarly это настоящий продукт если все деньги остаются в Делавере, а сюда приходит только зп людям? В чем разница между кучкой фопов работающих по ВЭД напрямую на британский стартап и теми же фопами которые работают на Grammarly? Вопрос.
Чем плох аутсорс? Ведь благодаря аутсорсу отрасль растет каждый год, зарплаты растут, открываются новые компании и все хорошо. Я считаю что аутсорс плох тем же, чем плоха работа наёмным батраком—прибыль прямо завязана на затраты времени а вся добавочная стоимость уходит клиенту. Как только гребцы уходят домой из "коворкинга"—печатный станок останавливается и компания перестает получать деньги. Утром—запускается обратно.
В то же время, когда все инженеры Grammarly пошли спать, люди продолжают оформлять подписки и пользоваться сервисом. Конечно, за этой денежной машинкой нужно смотреть, держать её на плаву и так далее, без труда не вытащишь и доллар у лоха, но добавочная прибыль на каждого инженера Grammarly просто несоизмерима с добавочной прибылью которую генерит гребец Люксофта.
Окей, предположим что аутсорс низкомаржинальный и малоприбыльный, но какая разница нам, инженерам, если деньги нам платят что там что там соизмеримые, и какая разница государству если что там что там заходит ровно денег на зарплату?
Я считаю, что разница в культуре.
Во-первых, у нас нет культуры выдачи сотрудникам акций и опционов. Оставим в стороне законодательный вопрос, но в принципе какие могут быть акции у аутсорс-шараги? Епам вышел на IPO, ребята оттуда вроде даже говорят что выдают акции и даже профит на этом есть. Но это единичные случаи. Массовой культуры нет и не будет, фаундеры не видят в этом смысла а люди вообще не понимают зачем оно надо. Лучше кеш. А вот на западе бонусы от акций могут легко составлять половину тотал компенсации.
Во-вторых, как ни крути, даже если деньги заходят в страну по минимуму, условный успешный продукт делает хотя бы своих фаундеров богаче. Богаче ли коллег-по цеху—фаундеров аутсорс шараг—вопрос. Но чем больше в стране богатых людей, тем лучше для всех нас.
Но это всё такие аргументы, ерундовые. Самый главный это в принципе отсутствие культуры продуктового мышления. Когда есть возможность срубить легкие деньги на апворках и аутсорсе на западных господ, то этот способ выбирается как основной, ты привязываешься ко времени и всё, приехали, мозг застревает в этой парадигме и фантазии вчерашнего гребца ограничиваются только желанием открыть еще одину аутсорс шарагу да выбить рейт повыше.
По сумме факторов я считаю что лучше бы у нас было меньше аутсорса пусть и ценой меньших зарплат. На длинной дистанции это было бы выигрышнее для всех.
А как вы считаете? Аутсорс нам друг или тормоз развития?
#работа
permalink | задонатить
Среди разработчиков распостранено мнение, что не имеет значения на какую компанию работать: продуктовую, сервисную, аутстафф, стартап, не-ІТ. Лишь бы платили денег и желательно побольше.
Согласно опросу ДОУ, 65% разработчиков заняты в аутсорсе, остальные—в продукте и стартапах. Рискну предположить, что в "настоящем" продукте работает гораздо меньше 35%—под "настоящим" я понимаю компанию которая была создана у нас и содержит основную часть рабочей силы у нас. Потому что я например тоже работаю в продукте, но заказчик зарубежный. Добавочная стоимость и все деньги остаются за рубежом, я получаю только свой рейт.
Опять же, можно спорить о том, что такое настоящий "отечественный" продукт, например Grammarly это настоящий продукт если все деньги остаются в Делавере, а сюда приходит только зп людям? В чем разница между кучкой фопов работающих по ВЭД напрямую на британский стартап и теми же фопами которые работают на Grammarly? Вопрос.
Чем плох аутсорс? Ведь благодаря аутсорсу отрасль растет каждый год, зарплаты растут, открываются новые компании и все хорошо. Я считаю что аутсорс плох тем же, чем плоха работа наёмным батраком—прибыль прямо завязана на затраты времени а вся добавочная стоимость уходит клиенту. Как только гребцы уходят домой из "коворкинга"—печатный станок останавливается и компания перестает получать деньги. Утром—запускается обратно.
В то же время, когда все инженеры Grammarly пошли спать, люди продолжают оформлять подписки и пользоваться сервисом. Конечно, за этой денежной машинкой нужно смотреть, держать её на плаву и так далее, без труда не вытащишь и доллар у лоха, но добавочная прибыль на каждого инженера Grammarly просто несоизмерима с добавочной прибылью которую генерит гребец Люксофта.
Окей, предположим что аутсорс низкомаржинальный и малоприбыльный, но какая разница нам, инженерам, если деньги нам платят что там что там соизмеримые, и какая разница государству если что там что там заходит ровно денег на зарплату?
Я считаю, что разница в культуре.
Во-первых, у нас нет культуры выдачи сотрудникам акций и опционов. Оставим в стороне законодательный вопрос, но в принципе какие могут быть акции у аутсорс-шараги? Епам вышел на IPO, ребята оттуда вроде даже говорят что выдают акции и даже профит на этом есть. Но это единичные случаи. Массовой культуры нет и не будет, фаундеры не видят в этом смысла а люди вообще не понимают зачем оно надо. Лучше кеш. А вот на западе бонусы от акций могут легко составлять половину тотал компенсации.
Во-вторых, как ни крути, даже если деньги заходят в страну по минимуму, условный успешный продукт делает хотя бы своих фаундеров богаче. Богаче ли коллег-по цеху—фаундеров аутсорс шараг—вопрос. Но чем больше в стране богатых людей, тем лучше для всех нас.
Но это всё такие аргументы, ерундовые. Самый главный это в принципе отсутствие культуры продуктового мышления. Когда есть возможность срубить легкие деньги на апворках и аутсорсе на западных господ, то этот способ выбирается как основной, ты привязываешься ко времени и всё, приехали, мозг застревает в этой парадигме и фантазии вчерашнего гребца ограничиваются только желанием открыть еще одину аутсорс шарагу да выбить рейт повыше.
По сумме факторов я считаю что лучше бы у нас было меньше аутсорса пусть и ценой меньших зарплат. На длинной дистанции это было бы выигрышнее для всех.
А как вы считаете? Аутсорс нам друг или тормоз развития?
#работа
permalink | задонатить
Когда олимпиадники могут. ClickHouse
На одном из самых старых проектов которые я разрабатываю начала тупить отчетность. Как только я поставил клиенту BI (напоминаю, это было самое быстрое и самое эффективное решение задачи которое я когда-либо делал), то аналитики сразу начали городить кучу дашбордов и отчетов. В основном все работало бодро, но некоторые запросы изрядно тупили.
Проблему довольно долго удавалось игнорировать, но в какой-то момент данных стало уж слишком много чтобы ими мог ворочать маленький MySQL сервер (4Гб памяти). Основную трудность составляли группировки по low cardinality колонкам. Представьте что у вас есть таблица с событиями где есть куча полей одно из которых может иметь всего три значения. Если вы хотите группировать выборку по этому полю, но кроме того еще и по куче других полей, то база не может подобрать подходящий индекс, берет какой попало и если данных достаточно много, то все это превращается в full scan.
В моем случае на таблице из всего лишь 6M записей такие запросы становились просто неподъемными. Внимательный читатель с навыками DBA предложил бы сделать композитные индексы, но мне пришлось бы делать их 20 штук, потому что кроме low-cardinality поля есть еще и другие по которым тоже нужно делать фильтрацию. Сложность вращения OLAP кубов это известная проблема RDBMS и не решается она в общем случае никак. Даже банальный
В этот момент кто-то вспомнил про ClickHouse. То ли я, то ли аналитики клиента, уже не помню. Договорились сделать PoC. Подняли самый простой сервер, я сделал экспорт данных из mysql в csv и вгрузил в ClickHouse чтобы понять как оно вообще будет работать.
Первым моим удивлением была скорость вгруза. 3M записей заехали буквально за несколько секунд. Я вначале даже подумал что не нажал где-то кнопку, и пошел перепроверять. Однако все данные были на месте.
Вторым удивлением оказалась скорость выборок. Запросы которые mysql не мог переварить, отрабатывали за доли секунд. Оно конечно логично, ведь это колоночная база сделанная как раз для группировок по куче колонок, но такой скорости на сервере с 2 Гб памяти я не ожидал.
Третье—полная поддержка SQL синтаксиса. Нам практически не понадобилось переписывать запросы дашбордов, просто поменяли датасорс в Metabase и всё заработало. Очень круто когда решение интегрировано со всем с чем можно.
Главная идея ClickHouse—высокая скорость работы на гигантских объемах данных. Логично, если в Яндексе приходится ворочать петабайтами, то мои смешные десятки гигабайт будут работать очень быстро.
Недавно я писал пост про олимпиадные задачи, алгоритмы и зачем они нужны. Вот результат, пожалуйста. Сам ClickHouse достигает такой скорости за счет хитрых структур данных и многочисленных оптимизаций.
Конечно же не все прошло так гладко как я стелю. Об этом в следующей части.
Используете ClickHouse? Делитесь своим опытом в комментах! 👇
#инструменты
permalink | задонатить
На одном из самых старых проектов которые я разрабатываю начала тупить отчетность. Как только я поставил клиенту BI (напоминаю, это было самое быстрое и самое эффективное решение задачи которое я когда-либо делал), то аналитики сразу начали городить кучу дашбордов и отчетов. В основном все работало бодро, но некоторые запросы изрядно тупили.
Проблему довольно долго удавалось игнорировать, но в какой-то момент данных стало уж слишком много чтобы ими мог ворочать маленький MySQL сервер (4Гб памяти). Основную трудность составляли группировки по low cardinality колонкам. Представьте что у вас есть таблица с событиями где есть куча полей одно из которых может иметь всего три значения. Если вы хотите группировать выборку по этому полю, но кроме того еще и по куче других полей, то база не может подобрать подходящий индекс, берет какой попало и если данных достаточно много, то все это превращается в full scan.
В моем случае на таблице из всего лишь 6M записей такие запросы становились просто неподъемными. Внимательный читатель с навыками DBA предложил бы сделать композитные индексы, но мне пришлось бы делать их 20 штук, потому что кроме low-cardinality поля есть еще и другие по которым тоже нужно делать фильтрацию. Сложность вращения OLAP кубов это известная проблема RDBMS и не решается она в общем случае никак. Даже банальный
select count(*) from table со временем начнет тупить на смехотворных 10M записей. Вам надо или делать дополнительные таблицы, или грузить всю таблицу в память, то есть добавлять железа, или ограничивать выборку по первичному ключу или еще как-то изощряться. Железо я в силу разных причин добавить сейчас не могу, костыли в виде дополнительных таблиц уже есть, городить что-то еще не хотелось.В этот момент кто-то вспомнил про ClickHouse. То ли я, то ли аналитики клиента, уже не помню. Договорились сделать PoC. Подняли самый простой сервер, я сделал экспорт данных из mysql в csv и вгрузил в ClickHouse чтобы понять как оно вообще будет работать.
Первым моим удивлением была скорость вгруза. 3M записей заехали буквально за несколько секунд. Я вначале даже подумал что не нажал где-то кнопку, и пошел перепроверять. Однако все данные были на месте.
Вторым удивлением оказалась скорость выборок. Запросы которые mysql не мог переварить, отрабатывали за доли секунд. Оно конечно логично, ведь это колоночная база сделанная как раз для группировок по куче колонок, но такой скорости на сервере с 2 Гб памяти я не ожидал.
Третье—полная поддержка SQL синтаксиса. Нам практически не понадобилось переписывать запросы дашбордов, просто поменяли датасорс в Metabase и всё заработало. Очень круто когда решение интегрировано со всем с чем можно.
Главная идея ClickHouse—высокая скорость работы на гигантских объемах данных. Логично, если в Яндексе приходится ворочать петабайтами, то мои смешные десятки гигабайт будут работать очень быстро.
Недавно я писал пост про олимпиадные задачи, алгоритмы и зачем они нужны. Вот результат, пожалуйста. Сам ClickHouse достигает такой скорости за счет хитрых структур данных и многочисленных оптимизаций.
Конечно же не все прошло так гладко как я стелю. Об этом в следующей части.
Используете ClickHouse? Делитесь своим опытом в комментах! 👇
#инструменты
permalink | задонатить
ClickHouse. Нюансы
Вообще это очень трендовая база. На хайлоад++ и других конференциях вы можете посмотреть множество докладов посвященных ClickHouse. На хабре куча статей. Материалов очень много. Вся эта движуха прошла мимо меня потому что я предпочитаю использовать проверенные инструменты до последнего. Ну и хайлоад++ не посещаю.
После PoC я прикинул, что нужно сделать для синхронизации основного хранилища в ClickHouse, и приступил к доработке продакшн-решения.
Неожиданность подстерегала меня в самом начале. Сущности которые хранятся у меня в основной таблице могут меняться. Соответственно, мне нужно было обновлять их и в ClickHouse. Первая задача—растыкать везде, где меняется эта сущность, вызов синхронизации. Вторая—собственно обновлять данные. Оказалось, что ClickHouse очень хорошо умеет записывать данные. Но не очень хорошо умеет изменять и удалять 😅.
Пришлось засесть за документацию и разобраться как это работает. Оказывается для каждой таблицы можно выбирать свой "движок", они есть разные и для каждой задачи можно подобрать самый подходящий вариант. Конкретно для дедупликации данных есть ReplacingMergeTree, это структура которая в фоне удаляет записи с одинаковым первичным ключом. То есть вы просто два раза инсертите одну и ту же запись и когда таблица будет оптимизироваться, то она уберет старые записи. Проблема в том, что непонятно когда это произойдет, а это значит, что в отчетах могут выводиться неверные данные. Для того чтобы попросить ClickHouse брать во внимание только нужные строки, используется ключевое слово
Вторая штука была уже приятной неожиданностью—ClickHouse умеет на ходу проксировать запросы к куче источников данных, в том числе
Третий прикол это типа OOM на запросах. Если ваш запрос по какой-то причине возвращает слишком много данных, то сервер может поднять лапки и сказать "сорян на этот запрос памяти нет". Такая ошибка вываливалась в стандартном просмотре таблицы Metabase потому что он делает
Несмотря на кажущуюся простоту решения, я превысил изначальный временной бюджет в два с хвостиком раза. Будет мне наука.
Решение работает в продакшене пару недель, пока все ок. Будем смотреть. ClickHouse мне очень понравился, я уже вижу еще несколько мест куда его можно применить. Очень легковесная и быстрая штука. Советую попробовать всем.
#инструменты
permalink | задонатить
Вообще это очень трендовая база. На хайлоад++ и других конференциях вы можете посмотреть множество докладов посвященных ClickHouse. На хабре куча статей. Материалов очень много. Вся эта движуха прошла мимо меня потому что я предпочитаю использовать проверенные инструменты до последнего. Ну и хайлоад++ не посещаю.
После PoC я прикинул, что нужно сделать для синхронизации основного хранилища в ClickHouse, и приступил к доработке продакшн-решения.
Неожиданность подстерегала меня в самом начале. Сущности которые хранятся у меня в основной таблице могут меняться. Соответственно, мне нужно было обновлять их и в ClickHouse. Первая задача—растыкать везде, где меняется эта сущность, вызов синхронизации. Вторая—собственно обновлять данные. Оказалось, что ClickHouse очень хорошо умеет записывать данные. Но не очень хорошо умеет изменять и удалять 😅.
Пришлось засесть за документацию и разобраться как это работает. Оказывается для каждой таблицы можно выбирать свой "движок", они есть разные и для каждой задачи можно подобрать самый подходящий вариант. Конкретно для дедупликации данных есть ReplacingMergeTree, это структура которая в фоне удаляет записи с одинаковым первичным ключом. То есть вы просто два раза инсертите одну и ту же запись и когда таблица будет оптимизироваться, то она уберет старые записи. Проблема в том, что непонятно когда это произойдет, а это значит, что в отчетах могут выводиться неверные данные. Для того чтобы попросить ClickHouse брать во внимание только нужные строки, используется ключевое слово
final. Естественно это замедляет выполнение запросов, потому что базе нужно на ходу выбросить из результата все лишнее. Пока что все работает достаточно быстро, посмотрим как оно будет дальше. Данных у меня не терабайты, поэтому думаю что все будет ок.Вторая штука была уже приятной неожиданностью—ClickHouse умеет на ходу проксировать запросы к куче источников данных, в том числе
mysql. То есть ему можно сказать: сделай мне таблицу из вот этого конекшена к mysql. Таким образом, для части таблиц с небольшим объемом (десятки тысяч строк) мне не нужно было писать код синхронизации а достаточно просто запроксировать. Не знаю как это работает внутри, для т.н. "словарей" там точно есть кеш, а вот такие запросы будут ходить скорее всего каждый раз напрямую. Посмотрим как оно будет.Третий прикол это типа OOM на запросах. Если ваш запрос по какой-то причине возвращает слишком много данных, то сервер может поднять лапки и сказать "сорян на этот запрос памяти нет". Такая ошибка вываливалась в стандартном просмотре таблицы Metabase потому что он делает
select * from table, а если данных много и сервер слишком мал, то запрос просто не выполнится. Нужно или делать группировки или ограничивать колонки.Несмотря на кажущуюся простоту решения, я превысил изначальный временной бюджет в два с хвостиком раза. Будет мне наука.
Решение работает в продакшене пару недель, пока все ок. Будем смотреть. ClickHouse мне очень понравился, я уже вижу еще несколько мест куда его можно применить. Очень легковесная и быстрая штука. Советую попробовать всем.
#инструменты
permalink | задонатить
Как оверсинкинг и перфекционизм мешают мне заканчивать проекты
Перфекционизм—ближайший друг прокрастинации. Я часто страдаю желанием сделать все "как надо", но неожиданные препяствия, возникающие на этапе делания как надо а не как попало часто тормозят работу, убивают мотивацию и приводят к затягиванию сроков и перерасходу бюджета.
Рассмотрим мой недавний микропроект с ClickHouse. Задача была довольно простая—взять данные из одного места и положить в другое. Всё. Что может быть проще? После завершения PoC клиент дал добро на продакшн-реализацию и я пошёл копать.
Началось всё с базы. Я же девопс, поэтому негоже создавать ресурсы вручную. Все должно разворачиваться с помощью терраформа. В качестве managed решения для ClickHouse было выбрано облако Яндекса. В этот момент я вспомнил, что нужно делать синхронизацию через очередь, потому что может быть такое что сервер перезапустится, умрет, получит таймаут. Все должно быть надежно, поэтому давайте вначале запушим в очередь сообщение с нужным нам объектом, а воркеры будут обрабатывать эту очередь и писать данные. Если вдруг случится таймаут, то сообщение останется на месте и будет обработано позже. Никто не забыт, ничто не забыто.
Яндекс предоставляет свой SQS-совместимый сервис для очередей. Я подумал—раз мы уже делаем кусочек инфры в Яндексе, то может и очередь туда засунем? Сказано-сделано, давай изучать как сконфигурировать очередь через терраформ. Вроде там всё просто, давай делать. Но тут возникает проблема—состояние терраформа надо где-то хранить! На своих других проектах для этого я использовал S3, но тут получается как-то тупо—стейт на S3 а облако в другом месте. У Яндекса ведь есть свой S3! Может быть там развернуть? Я застрял на этой мысли. В итоге попрокрастинировав, я решил для стейта взять terraform cloud. Зарегался там, всё как положено.
Пошел писать очереди. Вроде написал вроде все ок—делаю apply—а не работает! Еще несколько часов трачу на выяснение что не так с моей конфигурацией, ищу примеры в интернете. Ничего не помогает, забиваю и ложусь спать. Перед сном приходит идея—а может ну его, очередь в яндексе? Ведь у меня в приложении уже есть обработка других вещей через AWS SQS и она отлично работает. Потом, для интеграции используется Spring Boot Cloud который позволяет сделать чтение SQS одной аннотацией. Если я хочу делать яндексовую очередь—хоть она и SQS-совместима, надо будет как-то по-другому передавать ключи. Учитывая проблемы с разворачиванием очереди на яндексе через терраформ лучше просто завести еще одну очередь на амазоне и не парить себе мозг.
Следующим утром я быстро добавил еще одну очередь, скопипастил код который делает обработку, растыкал её по нужным местам и был таков. Ах да, все же начиналось с ClickHouse. Его я без проблем развернул через терраформ.
В итоге задача съела в 3 раза больше временного бюджета чем я думал и на неделю затянула релиз. А все потому что я тупил как же мне сохранять стейт, как же мне делать очередь и стремился делать "по-правильному" вместо того чтобы пойти проторенным путём. Вручную это все конфигурится буквально за минуту.
Это один маленький пример, как ловко я умею затягивать проекты. Выбирать технологии, возиться с какой-то ерундой, вместо того чтобы просто взять и сделать. В конце-концов можно было даже без терраформа обойтись и поднять все вручную и уйти в закат. Но это не наш путь.
#инструменты #кулстори
permalink | задонатить
Перфекционизм—ближайший друг прокрастинации. Я часто страдаю желанием сделать все "как надо", но неожиданные препяствия, возникающие на этапе делания как надо а не как попало часто тормозят работу, убивают мотивацию и приводят к затягиванию сроков и перерасходу бюджета.
Рассмотрим мой недавний микропроект с ClickHouse. Задача была довольно простая—взять данные из одного места и положить в другое. Всё. Что может быть проще? После завершения PoC клиент дал добро на продакшн-реализацию и я пошёл копать.
Началось всё с базы. Я же девопс, поэтому негоже создавать ресурсы вручную. Все должно разворачиваться с помощью терраформа. В качестве managed решения для ClickHouse было выбрано облако Яндекса. В этот момент я вспомнил, что нужно делать синхронизацию через очередь, потому что может быть такое что сервер перезапустится, умрет, получит таймаут. Все должно быть надежно, поэтому давайте вначале запушим в очередь сообщение с нужным нам объектом, а воркеры будут обрабатывать эту очередь и писать данные. Если вдруг случится таймаут, то сообщение останется на месте и будет обработано позже. Никто не забыт, ничто не забыто.
Яндекс предоставляет свой SQS-совместимый сервис для очередей. Я подумал—раз мы уже делаем кусочек инфры в Яндексе, то может и очередь туда засунем? Сказано-сделано, давай изучать как сконфигурировать очередь через терраформ. Вроде там всё просто, давай делать. Но тут возникает проблема—состояние терраформа надо где-то хранить! На своих других проектах для этого я использовал S3, но тут получается как-то тупо—стейт на S3 а облако в другом месте. У Яндекса ведь есть свой S3! Может быть там развернуть? Я застрял на этой мысли. В итоге попрокрастинировав, я решил для стейта взять terraform cloud. Зарегался там, всё как положено.
Пошел писать очереди. Вроде написал вроде все ок—делаю apply—а не работает! Еще несколько часов трачу на выяснение что не так с моей конфигурацией, ищу примеры в интернете. Ничего не помогает, забиваю и ложусь спать. Перед сном приходит идея—а может ну его, очередь в яндексе? Ведь у меня в приложении уже есть обработка других вещей через AWS SQS и она отлично работает. Потом, для интеграции используется Spring Boot Cloud который позволяет сделать чтение SQS одной аннотацией. Если я хочу делать яндексовую очередь—хоть она и SQS-совместима, надо будет как-то по-другому передавать ключи. Учитывая проблемы с разворачиванием очереди на яндексе через терраформ лучше просто завести еще одну очередь на амазоне и не парить себе мозг.
Следующим утром я быстро добавил еще одну очередь, скопипастил код который делает обработку, растыкал её по нужным местам и был таков. Ах да, все же начиналось с ClickHouse. Его я без проблем развернул через терраформ.
В итоге задача съела в 3 раза больше временного бюджета чем я думал и на неделю затянула релиз. А все потому что я тупил как же мне сохранять стейт, как же мне делать очередь и стремился делать "по-правильному" вместо того чтобы пойти проторенным путём. Вручную это все конфигурится буквально за минуту.
Это один маленький пример, как ловко я умею затягивать проекты. Выбирать технологии, возиться с какой-то ерундой, вместо того чтобы просто взять и сделать. В конце-концов можно было даже без терраформа обойтись и поднять все вручную и уйти в закат. Но это не наш путь.
#инструменты #кулстори
permalink | задонатить