Архитектура современных веб-приложений на примере adopt.com.ua
Я разработчик сервиса по пристройству животных — https://www.adopt.com.ua/ Там вы можете найти себе друга—котика или собачку. Хотя сайт простой, я применяю те же подходы для разработки своих коммерческих проектов. Если бы у меня стояла задача делать стартап, то я всё делал бы так же. Расскажу о том, как всё устроено внутри.
Сайт сделан на Ruby on Rails. Это веб-фреймворк который предоставляет всё, что нужно: слой доступа к базе данных, собственно веб, упаковщик статики, кеширование, бэкграунд джобы, письма и многое другое. Если бы я был питонистом то взял бы Django, если пыхером—Laravel.
Приложение разделено на три логических части: пользовательская, админка и API. Пользовательскую вы видите когда заходите на сайт, админка нужна для модераторов которые публикуют объявления, API используется для синхронизации с внешней CMS.
Всё что вы видите, рисуется на сервере. JS почти не используется и сайт по идее даже может работать без него. JS нужен для отображения результатов поиска, галереи фоток, клиентской валидации форм и кроппера фоток в админке. У такого подхода есть большое количество преимуществ—изоморфность, быстрая отрисовка, нет проблем с SEO, сайт быстро работает везде, не нужно держать отдельного фронтенд-разработчика. Я не фанат современного фронтенда и считаю что если вы не делаете Фигму, то все надо рисовать на сервере, оставляя клиенту минимум. Проект был написан до релиза HotWire, поэтому тут больше JS, чем могло бы быть. Для работы с JS используется библиотека Stimulus.
Верстка главной сделана на Bulma. Сейчас я бы смотрел в сторону TailwindCSS. Bulma тащит довольно много стилей и увеличивает размер конечного бандла.
Для админки я использую шаблон AdminLTE.
База данных — PostgreSQL. Постгреса более чем достаточно для наших задач. Данных немного, поэтому фильтрация и поиск работает быстро без дополнительных оптимизаций. А вот в некоторых коммерческих проектах у меня есть таблицы где по много миллионов записей и там уже нужно думать про организацию правильных индексов.
Каждому проекту нужна обработка очередей и бэкграунд джобы. Это код, который выполняется в фоне чтобы не задерживать пользователя. У нас в фоне делаются следующие вещи: отравляются письма о регистрации, ресайзятся картинки, постятся обновления в телеграм-чат для админов.
Для этого используется стандарт в мире Ruby — Sidekiq. Ему нужен Redis, поэтому у меня есть еще и Redis.
Всё это хостится на Heroku: 1 инстанс для веб-сервера, 1 инстанс для Sidekiq-воркера, 1 постгрес, 1 редис. Heroku предоставляет https для платных аккаунтов, тут не нужно дополнительно возиться с подъемом certbot.
Сорцы проекта находятся на GitLab и он же используется для CI/CD. По коммиту в мастер бегут линтеры и статические анализаторы кода JS—ESLint и Ruby—Rubocop, а дальше всё деплоится одной строкой в Heroku. Тестов на этом проекте нет, потому что я фактически единственный разработчик. Rubocop проверяет не только форматирование кода, но еще следит за потенциальными багами, например неоптимальным использованием Rails.
В следующей части я расскажу о внешних сервисах, которые используются для рассылки писем, ресайза картинок, хостинга файлов и CMS.
#работа #проекты #инструменты
permalink | задонатить
Я разработчик сервиса по пристройству животных — https://www.adopt.com.ua/ Там вы можете найти себе друга—котика или собачку. Хотя сайт простой, я применяю те же подходы для разработки своих коммерческих проектов. Если бы у меня стояла задача делать стартап, то я всё делал бы так же. Расскажу о том, как всё устроено внутри.
Сайт сделан на Ruby on Rails. Это веб-фреймворк который предоставляет всё, что нужно: слой доступа к базе данных, собственно веб, упаковщик статики, кеширование, бэкграунд джобы, письма и многое другое. Если бы я был питонистом то взял бы Django, если пыхером—Laravel.
Приложение разделено на три логических части: пользовательская, админка и API. Пользовательскую вы видите когда заходите на сайт, админка нужна для модераторов которые публикуют объявления, API используется для синхронизации с внешней CMS.
Всё что вы видите, рисуется на сервере. JS почти не используется и сайт по идее даже может работать без него. JS нужен для отображения результатов поиска, галереи фоток, клиентской валидации форм и кроппера фоток в админке. У такого подхода есть большое количество преимуществ—изоморфность, быстрая отрисовка, нет проблем с SEO, сайт быстро работает везде, не нужно держать отдельного фронтенд-разработчика. Я не фанат современного фронтенда и считаю что если вы не делаете Фигму, то все надо рисовать на сервере, оставляя клиенту минимум. Проект был написан до релиза HotWire, поэтому тут больше JS, чем могло бы быть. Для работы с JS используется библиотека Stimulus.
Верстка главной сделана на Bulma. Сейчас я бы смотрел в сторону TailwindCSS. Bulma тащит довольно много стилей и увеличивает размер конечного бандла.
Для админки я использую шаблон AdminLTE.
База данных — PostgreSQL. Постгреса более чем достаточно для наших задач. Данных немного, поэтому фильтрация и поиск работает быстро без дополнительных оптимизаций. А вот в некоторых коммерческих проектах у меня есть таблицы где по много миллионов записей и там уже нужно думать про организацию правильных индексов.
Каждому проекту нужна обработка очередей и бэкграунд джобы. Это код, который выполняется в фоне чтобы не задерживать пользователя. У нас в фоне делаются следующие вещи: отравляются письма о регистрации, ресайзятся картинки, постятся обновления в телеграм-чат для админов.
Для этого используется стандарт в мире Ruby — Sidekiq. Ему нужен Redis, поэтому у меня есть еще и Redis.
Всё это хостится на Heroku: 1 инстанс для веб-сервера, 1 инстанс для Sidekiq-воркера, 1 постгрес, 1 редис. Heroku предоставляет https для платных аккаунтов, тут не нужно дополнительно возиться с подъемом certbot.
Сорцы проекта находятся на GitLab и он же используется для CI/CD. По коммиту в мастер бегут линтеры и статические анализаторы кода JS—ESLint и Ruby—Rubocop, а дальше всё деплоится одной строкой в Heroku. Тестов на этом проекте нет, потому что я фактически единственный разработчик. Rubocop проверяет не только форматирование кода, но еще следит за потенциальными багами, например неоптимальным использованием Rails.
В следующей части я расскажу о внешних сервисах, которые используются для рассылки писем, ресайза картинок, хостинга файлов и CMS.
#работа #проекты #инструменты
permalink | задонатить
Таймкоди до стріму з Олександром Соловйовим: Clojure, як стати CTO, складність бізнесу
Саша в Ютубі: https://www.youtube.com/channel/UChAo...
Твітер: https://twitter.com/asolovyov
Телеграм канал: https://xn--r1a.website/bitethebyte
Та сама крутезна доповідь про FRP: https://www.youtube.com/watch?v=R4sTv...
Топ тем для тих у кого мало часу:
00:15:40 Чи виправдане використання Clojure зважаючи на низьку популярність мови?
00:44:39 Які якості важливі для СТО?
01:21:42 Звідки складність та десятки тисяч LoC в e-commerce? Чому Касті не підходять готові рішення (Magento, etc).
01:40:08 Дія Сіті. Думка Саші про Дію та Мінцифри.
Повний список:
00:00:20 Початок, вітання.
00:01:42 Саша розповідає про себе, хто такий, чим знаменитий. Про роботу CTO.
00:04:20 Що думаємо про перееїзд закордон? Чи варто переїжджати. Про дітей.
00:12:44 Якого розробника варто брати без технічної співбесіди?
00:14:05 Наскільки важко знайти розробника на Clojure. Як наймає Каста.
00:15:40 Чи виправдане використання Clojure зважаючи на низьку популярність мови?
00:18:20 Чому на Clojure набагато швидше пишеться код?
00:21:08 Про Python. Дзен Python, чому Clojure краще.
00:22:37 Інфраструктура Касти. Чому каста не буде мігрувати в cloud.
00:25:20 Що думаємо про сертифікації.
00:26:34 Згадуємо часи життя в гуртожитку КПІ.
00:29:55 Як Саша став СТО та що допомогло йому найбільше.
00:44:39 Які якості найважливіші для СТО?
00:44:56 Якість №1: розуміння бізнесу. Чим відрізняється сіньор від джуна.
00:47:40 Якість №2: Технологічний "компас".
00:49:09 Якість №3: Сторітеллінг, вміння розповісти людям бачення.
00:54:09 Що думаємо про golang. Go у Касті.
00:56:41 Хто стоїть за Clojure.
01:01:10 Що ще має вміти СТО.
01:02:43 Книги та ресурси для розвитку навичок проектування та архітектури.
01:05:37 Як вчитися робити великі проекти.
01:12:19 Як програмування заважає кар'єрі керівника. Звідки Саша бере час на програмування.
01:17:13 Що робити якщо раптово потрібно буде масштабуватися? Як правильно робити задачі СТО.
01:21:42 Звідки складність та десятки тисяч LoC в e-commerce? Чому Касті не підходять готові рішення (Magento, etc).
01:27:30 Складність бізнесу.
01:35:07 Чому Каста — продуктова компанія.
01:36:27 Про аудиторію Касту, рекламу, продажі.
01:40:08 Дія Сіті. Думка Саші про Дію та Мінцифри.
01:49:31 Про Гільдію ІТ фахівців.
01:54:12 Весь державний софт повинен бути відкритим.
01:57:00 Про адопт, LoC і ефективність.
01:58:00 Куди інвестувати гроші?
02:01:55 Як пройшов перехід на віддалену роботу у Касті? Про ефективність ремоуту.
02:07:08 Каста — золота клітка?
02:08:08 Як Саша переконав перейти на Clojure: https://www.youtube.com/watch?v=ggjQn...
02:09:11 Що робити після IT? Що би робив Саша якби мав купу грошей.
02:12:15 Про автомобілі. Яка беха у Саші в гаражі.
02:15:00 Як зробити таку круту доповідь як Саша зробив про FRP. Як повторити великий успіх? https://www.youtube.com/watch?v=R4sTv...
Підписати петицію проти Дія Сіті: https://petition.president.gov.ua/petition/114468
#кулстори
permalink | задонатить
Саша в Ютубі: https://www.youtube.com/channel/UChAo...
Твітер: https://twitter.com/asolovyov
Телеграм канал: https://xn--r1a.website/bitethebyte
Та сама крутезна доповідь про FRP: https://www.youtube.com/watch?v=R4sTv...
Топ тем для тих у кого мало часу:
00:15:40 Чи виправдане використання Clojure зважаючи на низьку популярність мови?
00:44:39 Які якості важливі для СТО?
01:21:42 Звідки складність та десятки тисяч LoC в e-commerce? Чому Касті не підходять готові рішення (Magento, etc).
01:40:08 Дія Сіті. Думка Саші про Дію та Мінцифри.
Повний список:
00:00:20 Початок, вітання.
00:01:42 Саша розповідає про себе, хто такий, чим знаменитий. Про роботу CTO.
00:04:20 Що думаємо про перееїзд закордон? Чи варто переїжджати. Про дітей.
00:12:44 Якого розробника варто брати без технічної співбесіди?
00:14:05 Наскільки важко знайти розробника на Clojure. Як наймає Каста.
00:15:40 Чи виправдане використання Clojure зважаючи на низьку популярність мови?
00:18:20 Чому на Clojure набагато швидше пишеться код?
00:21:08 Про Python. Дзен Python, чому Clojure краще.
00:22:37 Інфраструктура Касти. Чому каста не буде мігрувати в cloud.
00:25:20 Що думаємо про сертифікації.
00:26:34 Згадуємо часи життя в гуртожитку КПІ.
00:29:55 Як Саша став СТО та що допомогло йому найбільше.
00:44:39 Які якості найважливіші для СТО?
00:44:56 Якість №1: розуміння бізнесу. Чим відрізняється сіньор від джуна.
00:47:40 Якість №2: Технологічний "компас".
00:49:09 Якість №3: Сторітеллінг, вміння розповісти людям бачення.
00:54:09 Що думаємо про golang. Go у Касті.
00:56:41 Хто стоїть за Clojure.
01:01:10 Що ще має вміти СТО.
01:02:43 Книги та ресурси для розвитку навичок проектування та архітектури.
01:05:37 Як вчитися робити великі проекти.
01:12:19 Як програмування заважає кар'єрі керівника. Звідки Саша бере час на програмування.
01:17:13 Що робити якщо раптово потрібно буде масштабуватися? Як правильно робити задачі СТО.
01:21:42 Звідки складність та десятки тисяч LoC в e-commerce? Чому Касті не підходять готові рішення (Magento, etc).
01:27:30 Складність бізнесу.
01:35:07 Чому Каста — продуктова компанія.
01:36:27 Про аудиторію Касту, рекламу, продажі.
01:40:08 Дія Сіті. Думка Саші про Дію та Мінцифри.
01:49:31 Про Гільдію ІТ фахівців.
01:54:12 Весь державний софт повинен бути відкритим.
01:57:00 Про адопт, LoC і ефективність.
01:58:00 Куди інвестувати гроші?
02:01:55 Як пройшов перехід на віддалену роботу у Касті? Про ефективність ремоуту.
02:07:08 Каста — золота клітка?
02:08:08 Як Саша переконав перейти на Clojure: https://www.youtube.com/watch?v=ggjQn...
02:09:11 Що робити після IT? Що би робив Саша якби мав купу грошей.
02:12:15 Про автомобілі. Яка беха у Саші в гаражі.
02:15:00 Як зробити таку круту доповідь як Саша зробив про FRP. Як повторити великий успіх? https://www.youtube.com/watch?v=R4sTv...
Підписати петицію проти Дія Сіті: https://petition.president.gov.ua/petition/114468
#кулстори
permalink | задонатить
Архитектура современных веб-приложений на примере adopt.com.ua. Внешние сервисы
В предыдущей части я рассказал о ядре. Теперь пройдемся о внешних вещах.
На Heroku эфемерная файловая система. Это значит, что после перезагрузки инстанса, например при редеплое, все записанные файлы пропадут. Основной контент сайта—это фото, поэтому их нужно где-то хранить. Для этого мы используем AWS S3. Файлы прозрачно загружаются на S3 с помощью RoR, для этого не нужно писать дополнительного кода. То же кстати есть и в Laravel и в других фуллстек-фреймворках.
Кроме хранения файлов их нужно еще и раздавать. Можно настроить бакет на раздачу, но это не очень хороший подход по нескольким причинам: показывать имя бакета миру небезопасно, файлы могут находиться далеко от пользователя, тарификция траффика может быть большой на хороших объемах, нужно настраивать заголовки кеширования. Поэтому мы используем амазоновский CDN — CloudFront. У него есть точки доступа по всему миру и файлы будут отдаваться быстро. Кроме CloudFront есть огромное количество других CDN, но амазон меня устраивает.
Вся AWS инфраструктура развернута с помощью Terraform. Вручную в AWS консоли я ничего не конфигурирую, все настраивается через Terraform. Если завтра мне нужно будет поднять клон адопта, то я смогу сделать это за минуту. Состояние терраформа хранится в бакете на том же амазоне, локально ничего нет.
Для рассылки писем я использую сервис Mailjet. Среди кучи других сервисов он выделятеся тем, что можно делать шаблоны для транзакционных рассылок. Транзакционные рассылки—это письма о регистрации, уведомления от сайта и так далее. Они отличаются от маркетинговых писем тем, что там нужно делать подстановки—например вставлять ссылку с токеном для подтверждения регистрации. В подавляющем большинстве сервисов рассылок так делать нельзя или есть ограничения, например подстановка только имени.
Верстка писем—отдельное тайное искусство. Можно было бы отправлять письма сразу из Rails, но тогда нужно было бы делать для них шаблоны в коде и контент нельзя было бы редактировать нетехническим пользователям. Поэтому все шаблоны собраны в конструкторе Mailjet.
Для того, чтобы письма доставлялись как надо и не попадали в спам, нужно чтобы ваш домен содержал DKIM и SPF записи. Для управления всеми своими доменами я использую Cloudflare. Он бесплатный и быстро работает. Еще там есть защита от DDoS и бесплатный CDN, но я их не использую.
В Mailjet можно делать и маркетинговые рассылки тоже, но мы этим пока что не пользуемся. Аналоги Mailjet это Mailchimp, Mailgun, Unisender и так далее и так далее.
Для ресайза картинок я использую сервис ImageKit. Я уже подробно о нём писал. Очень удобная штука. По API вы загружаете фото и тут же можете получить его в любом необходимом размере.
К сайту подключена OAuth2 авторизация через фейсбук и гугл. Для этого в фейсбуке и гугле соответственно созданы девелоперские аккаунты, а для интеграции используется библиотека Omniauth.
Для донатов используется LiqPay. Тут ничего сложного. Правда нам сейчас отключили платежи т.к. надо обновить доки или зарегистрировать юрлицо, точно не знаю, поэтому пока что донаты на карту.
В следующей часи я расскажу про мониторинг, аналитику и CMS.
#работа #инструменты #проекты
permalink | задонатить
В предыдущей части я рассказал о ядре. Теперь пройдемся о внешних вещах.
На Heroku эфемерная файловая система. Это значит, что после перезагрузки инстанса, например при редеплое, все записанные файлы пропадут. Основной контент сайта—это фото, поэтому их нужно где-то хранить. Для этого мы используем AWS S3. Файлы прозрачно загружаются на S3 с помощью RoR, для этого не нужно писать дополнительного кода. То же кстати есть и в Laravel и в других фуллстек-фреймворках.
Кроме хранения файлов их нужно еще и раздавать. Можно настроить бакет на раздачу, но это не очень хороший подход по нескольким причинам: показывать имя бакета миру небезопасно, файлы могут находиться далеко от пользователя, тарификция траффика может быть большой на хороших объемах, нужно настраивать заголовки кеширования. Поэтому мы используем амазоновский CDN — CloudFront. У него есть точки доступа по всему миру и файлы будут отдаваться быстро. Кроме CloudFront есть огромное количество других CDN, но амазон меня устраивает.
Вся AWS инфраструктура развернута с помощью Terraform. Вручную в AWS консоли я ничего не конфигурирую, все настраивается через Terraform. Если завтра мне нужно будет поднять клон адопта, то я смогу сделать это за минуту. Состояние терраформа хранится в бакете на том же амазоне, локально ничего нет.
Для рассылки писем я использую сервис Mailjet. Среди кучи других сервисов он выделятеся тем, что можно делать шаблоны для транзакционных рассылок. Транзакционные рассылки—это письма о регистрации, уведомления от сайта и так далее. Они отличаются от маркетинговых писем тем, что там нужно делать подстановки—например вставлять ссылку с токеном для подтверждения регистрации. В подавляющем большинстве сервисов рассылок так делать нельзя или есть ограничения, например подстановка только имени.
Верстка писем—отдельное тайное искусство. Можно было бы отправлять письма сразу из Rails, но тогда нужно было бы делать для них шаблоны в коде и контент нельзя было бы редактировать нетехническим пользователям. Поэтому все шаблоны собраны в конструкторе Mailjet.
Для того, чтобы письма доставлялись как надо и не попадали в спам, нужно чтобы ваш домен содержал DKIM и SPF записи. Для управления всеми своими доменами я использую Cloudflare. Он бесплатный и быстро работает. Еще там есть защита от DDoS и бесплатный CDN, но я их не использую.
В Mailjet можно делать и маркетинговые рассылки тоже, но мы этим пока что не пользуемся. Аналоги Mailjet это Mailchimp, Mailgun, Unisender и так далее и так далее.
Для ресайза картинок я использую сервис ImageKit. Я уже подробно о нём писал. Очень удобная штука. По API вы загружаете фото и тут же можете получить его в любом необходимом размере.
К сайту подключена OAuth2 авторизация через фейсбук и гугл. Для этого в фейсбуке и гугле соответственно созданы девелоперские аккаунты, а для интеграции используется библиотека Omniauth.
Для донатов используется LiqPay. Тут ничего сложного. Правда нам сейчас отключили платежи т.к. надо обновить доки или зарегистрировать юрлицо, точно не знаю, поэтому пока что донаты на карту.
В следующей часи я расскажу про мониторинг, аналитику и CMS.
#работа #инструменты #проекты
permalink | задонатить
Петиция против "Дія Сіті"
Друзья, благодаря вам за месяц мы собрали больше 20000 голосов. В темы на ДОУ с обсуждениями петиции пришел замминистра Александр Борняков и отдувался за всё министерство.
Петиция подняла небывалый шум, про неё упоминали при голосовании законопроекта в раде. В четверг проголосовали закон в первом чтении, но важно понимать что это еще не конец. Закон поддержали только Слуги Народа (и то не все) и несколько внефракционных.
Минцифры изменило риторику и теперь отвечает так "мы не будем трогать ни ФОП и ВЭД и вообще вступление в Дія—дело добровольное". Неподготвленному человеку кажется что всё так и есть—ведь в законе конечно же не прописан ни запрет ВЭД ни ответственность за работу с ФОПами.
Но нужно понимать что Минцифры—это не всё государство. Кроме них еще есть Минфин и управление по делам труда, которые ждут не дождутся когда можно будет защемить всех кто работает с ФОПами. Дія—это прекурсор, который позволит государству объявить ФОПов "черной схемой" и предложить компаниям или идти в Дію или оформлять людей в штат.
Кроме того, создание отдельного загончика для ІТ позволит независимо регулировать нас от всех остальных.
Если вы еще не подписали петицию: обязательно подпишите и попросите друзей родственников и знакомых.
https://petition.president.gov.ua/petition/114468
Чтобы подписать используйте НБУ ID — в списке скорее всего будет ваш банк.
Максимальный репорст и релайк!
#StopDiiaCity
Друзья, благодаря вам за месяц мы собрали больше 20000 голосов. В темы на ДОУ с обсуждениями петиции пришел замминистра Александр Борняков и отдувался за всё министерство.
Петиция подняла небывалый шум, про неё упоминали при голосовании законопроекта в раде. В четверг проголосовали закон в первом чтении, но важно понимать что это еще не конец. Закон поддержали только Слуги Народа (и то не все) и несколько внефракционных.
Минцифры изменило риторику и теперь отвечает так "мы не будем трогать ни ФОП и ВЭД и вообще вступление в Дія—дело добровольное". Неподготвленному человеку кажется что всё так и есть—ведь в законе конечно же не прописан ни запрет ВЭД ни ответственность за работу с ФОПами.
Но нужно понимать что Минцифры—это не всё государство. Кроме них еще есть Минфин и управление по делам труда, которые ждут не дождутся когда можно будет защемить всех кто работает с ФОПами. Дія—это прекурсор, который позволит государству объявить ФОПов "черной схемой" и предложить компаниям или идти в Дію или оформлять людей в штат.
Кроме того, создание отдельного загончика для ІТ позволит независимо регулировать нас от всех остальных.
Если вы еще не подписали петицию: обязательно подпишите и попросите друзей родственников и знакомых.
https://petition.president.gov.ua/petition/114468
Чтобы подписать используйте НБУ ID — в списке скорее всего будет ваш банк.
Максимальный репорст и релайк!
#StopDiiaCity
petition.president.gov.ua
Стоп Дія Сіті! Зупиніть знищення української IT галузі Електронні петиції — Офіційне інтернет-представництво Президента України
Обсудили на подкасте p_tech_podcast от Postindustria тему выгорания. Давно не выгорали!
- Причины выгорания
- Как перестать наступать на те же грабли
- Что делать чтобы предотвратить выгорание
Послушать можно по ссылкам:
Apple Podcasts https://jo.my/fy0vpd
Google Podcasts https://jo.my/jtbevf
SoundCloud https://jo.my/hgjahz
Deezer https://jo.my/juykfa
Castbox https://jo.my/jxggea
Pocketcast https://jo.my/oordxp
- Причины выгорания
- Как перестать наступать на те же грабли
- Что делать чтобы предотвратить выгорание
Послушать можно по ссылкам:
Apple Podcasts https://jo.my/fy0vpd
Google Podcasts https://jo.my/jtbevf
SoundCloud https://jo.my/hgjahz
Deezer https://jo.my/juykfa
Castbox https://jo.my/jxggea
Pocketcast https://jo.my/oordxp
Гильдия ІТ-специалистов Украины
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 | задонатить