#Пост №1. Introduction.
Приветы.
Как правило, когда человек заводит свой медиа ресурс, хорошим тоном считается представиться и рассказать о себе. Не буду здесь отличаться от других, поэтому давайте познакомимся поближе.
Меня зовут Дмитрий Дерепко. Живу в солнечном Тайланде, работаю разработчиком. В свободное время пытаюсь развиваться, ржу с мемов, из книг предпочитаю профессиональные, между роллами и пиццей – пицца.
Впервые прикоснулся к программированию лет в ~14, когда пытался настроить сервер в контре и поднять бот для аськи. Сейчас мне 26. Не скажу, что всё время осознанно писал код и развивался как программист, но много лет было посвящено веб разработке и около неё.
Еще немного фактов большими мазками:
- В 11 классе сделай школьный сайт, который еще работал пару месяцев назад, а сейчас всё 🙁
- Веб-мастерил на фрилансе, пока был в школе и универе
- Преподавал для детишек HTML, CSS и JS
- Законченный бакалавриат физфака со смесью IT, из магистратуры ушел
- Разработчик, который стал тимлидом и тимлид, который ушел в разработку
- Кодил на PHP, JS, Python, Go, Dart, C++, C# и всякое разное. Где-то больше и осознанно, где-то наоборот
- Написал три статьи в серии Yii Overview (раз, два, три)
- Уже месяц прокрастинирую и пытаюсь записать ролик на ютуб по старту вместе Yii 3 🙂
- Комичу в Open source, состою в тиме Yii 3
——
Писать о том, что функция А быстрее функции Б в языке программирования В я вряд ли буду, ждите больше более полезной информации по развитию себя, как профессионала в разработке, менеджменте и около этого.
Не скажу, что этот канал и информация здесь будет уникальной и лучше, чем у других. Для меня этот канал – средство выражения своих мыслей и структурирования нажитых наблюдений.
——
Кстати, в коментах можете написать написать о себе, чтобы я вас тоже знал.
Приветы.
Как правило, когда человек заводит свой медиа ресурс, хорошим тоном считается представиться и рассказать о себе. Не буду здесь отличаться от других, поэтому давайте познакомимся поближе.
Меня зовут Дмитрий Дерепко. Живу в солнечном Тайланде, работаю разработчиком. В свободное время пытаюсь развиваться, ржу с мемов, из книг предпочитаю профессиональные, между роллами и пиццей – пицца.
Впервые прикоснулся к программированию лет в ~14, когда пытался настроить сервер в контре и поднять бот для аськи. Сейчас мне 26. Не скажу, что всё время осознанно писал код и развивался как программист, но много лет было посвящено веб разработке и около неё.
Еще немного фактов большими мазками:
- В 11 классе сделай школьный сайт, который еще работал пару месяцев назад, а сейчас всё 🙁
- Веб-мастерил на фрилансе, пока был в школе и универе
- Преподавал для детишек HTML, CSS и JS
- Законченный бакалавриат физфака со смесью IT, из магистратуры ушел
- Разработчик, который стал тимлидом и тимлид, который ушел в разработку
- Кодил на PHP, JS, Python, Go, Dart, C++, C# и всякое разное. Где-то больше и осознанно, где-то наоборот
- Написал три статьи в серии Yii Overview (раз, два, три)
- Уже месяц прокрастинирую и пытаюсь записать ролик на ютуб по старту вместе Yii 3 🙂
- Комичу в Open source, состою в тиме Yii 3
——
Писать о том, что функция А быстрее функции Б в языке программирования В я вряд ли буду, ждите больше более полезной информации по развитию себя, как профессионала в разработке, менеджменте и около этого.
Не скажу, что этот канал и информация здесь будет уникальной и лучше, чем у других. Для меня этот канал – средство выражения своих мыслей и структурирования нажитых наблюдений.
——
Кстати, в коментах можете написать написать о себе, чтобы я вас тоже знал.
1🔥7
#Пост №2. Рекрутмент и накрутка опыта
Сижу смотрю свежий выпуск на канале “Мы обречены” про найм и рекрутмент.
Ухо зацепилось за один поинт в обсуждении.
Решил накатать вам телегу здесь, но моя телега не влезла в телегу, поэтому продублировал всё сообщение в телеграф. Рассказал, как устроен процесс найма и около него.
——
Оставлю здесь выжимку своих мыслей по поводу “неточностей” в резюме 🙂
Телеграф: https://telegra.ph/Post-2-Rekrutment-i-nakrutka-opyta-11-15
Сижу смотрю свежий выпуск на канале “Мы обречены” про найм и рекрутмент.
Ухо зацепилось за один поинт в обсуждении.
Решил накатать вам телегу здесь, но моя телега не влезла в телегу, поэтому продублировал всё сообщение в телеграф. Рассказал, как устроен процесс найма и около него.
——
Оставлю здесь выжимку своих мыслей по поводу “неточностей” в резюме 🙂
Честно, мне как нанимающему, совсем не важно у тебя 2 или 5 лет “сухого” опыта. Решает лишь твоя адекватность, умение развиваться и твои скилы, которые нужны прямо сейчас.
…
Поэтому, если мне придется отправить резюме в компанию мечты, в которой требуется больше лет, чем у меня есть, я без зазрения совести накручу себе лет в резюме
Телеграф: https://telegra.ph/Post-2-Rekrutment-i-nakrutka-opyta-11-15
Telegraph
Пост №2. Рекрутмент и накрутка опыта
Сижу смотрю свежий выпуск на канале “Мы обречены” про найм и рекрутмент. Ухо зацепилось за один поинт в обсуждении, но сначала расскажу как работает процесс найма так скажем inside-out. Кто замешан в этом? Сотрудник, который хочет найти работу – соискатель…
1🤔1
Трассировка запросов – это способ отслеживания запросов между сервисами.
Часто такая надобность появляется, когда система состоит из двух и более сервисов, которые взаимодействуют друг с другом.
Давайте представим, что мы имеем следующую конфигурацию нашей инфраструктуры:
- Продуктовое приложение с бекендом и фронтендом (Application)
- Сервис авторизации (Auth)
Помимо сервисов с бизнес логикой инфраструктура также имеет сборщик различных метрик и логов. Например, Sentry, Newrelic или любой другой сервис.
- Пользователь выполняет авторизацию в приложении.
- Продуктовое приложение в процессе обработки запроса собирает какие-то логи и отправляет их в систему логов (сборщик).
- Продуктовое приложение делает запрос в сервис авторизации.
- Сервис авторизации выполняет свою часть и так же отправляет собранные логи в сборщик.
🕵️♂️ Трассировка
Когда что-то идёт не так, хочется понимать откуда запрос пришел изначально, какие данные по этому запросы были собраны и какие процессы были выполнены в рамках этого юзкейса.
Один из способов разметить эти процессы – добавить некий ID запроса, который будет сгенерирован, если другая система его не передала или использовать переданный.
В случае юзкейса выше можно на бекенде сгенерировать уникальный ID и передать его в запрос сервиса авторизации. Если используется HTTP, то отлично подойдет секция заголовков (Headers). Наиболее популярное имя такого хедера X-Request-Id.
В этом случае логер должен уметь захватывать этот ID из заголовков и отправлять его контекстом в сборщик логов, а http client отправлять этот ID в Headers других запросов.
Схематично это будет выглядеть так:
1. Запрос Frontend → Application
2. Application Boot. Парсинг или создание нового Request ID в какое-то локальное хранилище, которое в дальнейшем будет использоваться в Logger, HttpClient и других классах для обогащения контекста
3. Запрос Application → Auth
4. Такой же Application Boot, как в пункте №2
Теперь, когда пользователь сделает запрос в продуктовое приложение, мы сможем найти по ID все логи текущего приложения, http запросы в другие сервисы, их логи и дальнейшие запросы. Цепочка может не заканчиваться только на одном сервисе.
Например, цепочка может быть такой:
App -> Write logs; Call ID, Auth, Billing
ID -> Write logs
Auth -> Write logs; Call ID
ID -> Write logs
Billing -> Write logs, Call Auth
Auth -> Write logs; Call ID
ID -> Write logs
Представьте, как без такого механизма вы бы могли собрать полную картину межсервисного взаимодействия. По User ID, Remote IP или любым другим косвенным метка одного запроса это делать очень больно.
Помимо HTTP запросов можно так же маркировать сообщения в очередях, если они поддерживают подобие Headers.
Если нет, то можно в тело сообщения добавлять Request ID и уже после распаковки сообщения устанавливать глобальный Request ID для всего приложения.
ℹ️Для консольных команд, а также cron задач, тоже стоит сделать такой механизм.
Инициировать создание Request ID может не только продуктовое приложение, а любой из имеющихся сервисов: биллинг по вебхуку от внешних провайдеров, сервис коммуникаций по крону и так далее.
Таким образом, чтобы добавить трассировку межсервисной коммуникации, стоит добавить:
- Механизм генерации ID или получения его от внешних систем при начале работы приложения: http headers, queue headers, queue payload
- Обогатить контекст для подсистем, которые хочется мониторить или которые инициируют запросы в другие системы: http client, queue.
——
Практически под каждый фреймворк есть уже готовые библиотеки, но вы запросто сможете написать свою, под личные ограничения инфраструктуры.
Генерацию http заголовка, кстати, можно делегировать Nginx.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍4🌭1
🤔 #Мысли
Какой раз замечаю, что проф. развитие и мотивация у меня всегда шли и идут “волнами”.
В школьные/универские годы это было в соотношении ~ 3:1 – 3 месяца активно штырит мотивация на изучение и развитие всего и вся, 1 месяц просто не могу и не хочу ничего связанного с IT.
А последние года 3-4 оно всё больше размазывается мелкими порциями: ~ недели активностей и ~ пару дней великая лень и отвержение.
Порой задумываюсь, это прогресс или деградация? С одной стороны я более предсказуем для себя и работадателя, но с другой этот проявляется всё чаще и может утащить на свою сторону.
Какой раз замечаю, что проф. развитие и мотивация у меня всегда шли и идут “волнами”.
В школьные/универские годы это было в соотношении ~ 3:1 – 3 месяца активно штырит мотивация на изучение и развитие всего и вся, 1 месяц просто не могу и не хочу ничего связанного с IT.
А последние года 3-4 оно всё больше размазывается мелкими порциями: ~ недели активностей и ~ пару дней великая лень и отвержение.
Порой задумываюсь, это прогресс или деградация? С одной стороны я более предсказуем для себя и работадателя, но с другой этот проявляется всё чаще и может утащить на свою сторону.
1👍2
💊 #Пост №4. Разбор инцидентов или Postmortem
Упал прод – починили и пообещали больше так не делать?
В современном мире этого недостаточно. Слова нужно подкреплять делом, а обещания тасками и их выполнением.
Если начать ретроспектировать на тему падения в том или ином кейсе, можно не только понимать произошедшее, но и научиться предвидеть и недопускать повторных ошибок в будущем, поднять культуру разработки в команде и даже заработать статус в лице коллег за бравое дело.
Postmortem в IT – это ретроспектива, направленная на тему “что нужно сделать сейчас, чтобы избежать подобной ошибки в будущем”.
Собрал мысли в порядок и написал пост. Текст опять не влез в одно сообщение телеграма, поэтому публикую в телеграфе: https://telegra.ph/Post-4-Razbor-incidentov-ili-Postmortem-12-01
Упал прод – починили и пообещали больше так не делать?
В современном мире этого недостаточно. Слова нужно подкреплять делом, а обещания тасками и их выполнением.
Если начать ретроспектировать на тему падения в том или ином кейсе, можно не только понимать произошедшее, но и научиться предвидеть и недопускать повторных ошибок в будущем, поднять культуру разработки в команде и даже заработать статус в лице коллег за бравое дело.
Postmortem в IT – это ретроспектива, направленная на тему “что нужно сделать сейчас, чтобы избежать подобной ошибки в будущем”.
Собрал мысли в порядок и написал пост. Текст опять не влез в одно сообщение телеграма, поэтому публикую в телеграфе: https://telegra.ph/Post-4-Razbor-incidentov-ili-Postmortem-12-01
Telegraph
Пост №4. Разбор инцидентов или Postmortem
Postmortem – это медицинский термин, который обозначает процесс вскрытия трупа для исследования причин смерти. Postmortem в IT – это ретроспектива, направленная на тему “что нужно сделать сейчас, чтобы избежать подобной ошибки в будущем”. Будет довольно странно…
2👍5
#оффтоп
Согласен с мнениями о вредности пустых моделей, но есть что дополнить ув. тов. Шароватову.
Если переложить пустые модели на кухню разработки, то порой вредно выделять класс ради класса, микросервис ради микросервиса, абстракцию ради абстракции.
Однако это вредно лишь тогда, когда оно наносит какой-то вред.
Например, если создать микросервис проще, быстрее и дешевле, чем интегрировать модуль в работающую систему, то определенно стоит создавать микросервис. Конечно, это чаще всего не так, но не нужно брать идею в максимализм и накладывать на неё весь мир.
В сравнении “иметь плохую модель vs не иметь модели”, всё конечно зависит от контекста, но чаще всего лучше иметь плохую модель. Ведь плохая модель приносит хоть какую-то пользу, по отношению к отсутствующей модели.
Любая абстракция позволяет выполнять меньше действий в каком-то направлении. Мы ведь не рисуем карту межсервисной коммуникации, включая туда все классы, методы, таблицы, колонки, фреймворки, библиотеки и т.п. для того, чтобы посмотреть лишь как сервисы взаимодействуют друг друга в первом приближении.
Лучше иметь плохуя карту сервисов, чем не иметь её и каждый раз вспоминать о всех коммуникациях. Лучше иметь плохую декомпозицию программных модулей, чем её не иметь. Лучше иметь плохую машину, которая вас довозит до работы за 40 минут, чем каждый раз кататься на автобусе, который делает это за полтора часа.
Даже когда модель перестала быть полезной, в какой-то момент польза от неё может вернуться и придется возвращаться к ней, чтобы иметь хоть какой-то бенефит.
Опять же, всё зависит от контекста и максимализировать явно не стоит.
Согласен с мнениями о вредности пустых моделей, но есть что дополнить ув. тов. Шароватову.
Если переложить пустые модели на кухню разработки, то порой вредно выделять класс ради класса, микросервис ради микросервиса, абстракцию ради абстракции.
Однако это вредно лишь тогда, когда оно наносит какой-то вред.
Например, если создать микросервис проще, быстрее и дешевле, чем интегрировать модуль в работающую систему, то определенно стоит создавать микросервис. Конечно, это чаще всего не так, но не нужно брать идею в максимализм и накладывать на неё весь мир.
В сравнении “иметь плохую модель vs не иметь модели”, всё конечно зависит от контекста, но чаще всего лучше иметь плохую модель. Ведь плохая модель приносит хоть какую-то пользу, по отношению к отсутствующей модели.
Любая абстракция позволяет выполнять меньше действий в каком-то направлении. Мы ведь не рисуем карту межсервисной коммуникации, включая туда все классы, методы, таблицы, колонки, фреймворки, библиотеки и т.п. для того, чтобы посмотреть лишь как сервисы взаимодействуют друг друга в первом приближении.
Лучше иметь плохуя карту сервисов, чем не иметь её и каждый раз вспоминать о всех коммуникациях. Лучше иметь плохую декомпозицию программных модулей, чем её не иметь. Лучше иметь плохую машину, которая вас довозит до работы за 40 минут, чем каждый раз кататься на автобусе, который делает это за полтора часа.
Даже когда модель перестала быть полезной, в какой-то момент польза от неё может вернуться и придется возвращаться к ней, чтобы иметь хоть какой-то бенефит.
Опять же, всё зависит от контекста и максимализировать явно не стоит.
1
Forwarded from Sharovatov (Vitaly Sharovatov)
> the essence of a model to be predictive
Ув. тов. Стафорд Бир считает, что любая модель создаётся исключительно для того, чтобы помогать в предсказании чего-то.
Я склонен согласиться с ним: ведь даже аналитические, учебные или там эвристические модели создаются так, чтоб с какой-то точностью представлять моделируемую систему, и представление это нужно исключительно для того, чтобы предсказывать изменение реальной системы.
Если модель не помогает в предсказании, то траты на её создание были оправданы лишь тогда, когда она выкидывается или изменяется так, чтобы таки начинать помогать в предсказании.
Если же модель не помогает предсказывать ничего и помочь не может, то она вредна. Вредна просто потому, что используя негодные модели, мы принимаем неоптимальные решения.
Получается, что "плохая" модель хуже отсутствия модели вообще, ведь в случае отсутствия модели вообще нам-таки придётся скорее всего подумать.
Я знаю такие примеры вредных моделей:
- DORA
- нумерология, френология
- юнгианские психотипы (DISC туда же)
- астрология и всякий human design
- theory x
а какие вредные модели знаете вы?
Ув. тов. Стафорд Бир считает, что любая модель создаётся исключительно для того, чтобы помогать в предсказании чего-то.
Я склонен согласиться с ним: ведь даже аналитические, учебные или там эвристические модели создаются так, чтоб с какой-то точностью представлять моделируемую систему, и представление это нужно исключительно для того, чтобы предсказывать изменение реальной системы.
Если модель не помогает в предсказании, то траты на её создание были оправданы лишь тогда, когда она выкидывается или изменяется так, чтобы таки начинать помогать в предсказании.
Если же модель не помогает предсказывать ничего и помочь не может, то она вредна. Вредна просто потому, что используя негодные модели, мы принимаем неоптимальные решения.
Получается, что "плохая" модель хуже отсутствия модели вообще, ведь в случае отсутствия модели вообще нам-таки придётся скорее всего подумать.
Я знаю такие примеры вредных моделей:
- DORA
- нумерология, френология
- юнгианские психотипы (DISC туда же)
- астрология и всякий human design
- theory x
а какие вредные модели знаете вы?
👍2
#оффтоп
🖼️ PHP Fart / gRPC / Protobuf
Посмотрел стрим ребят из PHP Fart про gRPC и Protobuf.
Как же я был счастлив, когда увидел нормальный генератор PHP классов по proto файлам: с нормальным конструктором, типизацией свойств, без лишних геттеров и сеттеров и без наследования огромного базового класса Message. Такие DTO теперь и не стыдно использовать, и прямых зависимостей от google/protobuf меньше, и вспомогательные инструменты будут считать класс “безпроблемным”.
Несколько лет назад было требование в одном из проектов работать с системой телефонии, которая предоставляла API только в protobuf формате. Тогда я и познакомился с этой штукой лицом к лицу.
Тоже бесили эти громоздкие файлы с кучей комментариев и отсутствием типизации, на которые вечно кричали различные линтеры и шторм. Если теперь и попадётся очередная интеграция с protobuf, то обязательно буду использовать их библиотеку, хоть она и не полностью независимая.
Советую и вам к использованию.
Кстати, надо бы в🖼️ Yii3 сделать поддержку этого генератора в Gii.
---
Теперь осталось, чтобы кто-нибудь написал нормальный генератор PHP классов по Open API спеке, а то там вообще мрак. Может когда-нибудь и сам доберусь до него, чтобы интегрировать в Yii Dev Panel и генерировать контракты несколькими кликами в UI.
---
Ссылка на стрим: https://www.youtube.com/watch?v=E61resEfgUE
Ссылка на канал: https://news.1rj.ru/str/php_fart
Когда досмотрел стрим увидел, что он был 3 месяца назад 😬
Посмотрел стрим ребят из PHP Fart про gRPC и Protobuf.
Как же я был счастлив, когда увидел нормальный генератор PHP классов по proto файлам: с нормальным конструктором, типизацией свойств, без лишних геттеров и сеттеров и без наследования огромного базового класса Message. Такие DTO теперь и не стыдно использовать, и прямых зависимостей от google/protobuf меньше, и вспомогательные инструменты будут считать класс “безпроблемным”.
Несколько лет назад было требование в одном из проектов работать с системой телефонии, которая предоставляла API только в protobuf формате. Тогда я и познакомился с этой штукой лицом к лицу.
Тоже бесили эти громоздкие файлы с кучей комментариев и отсутствием типизации, на которые вечно кричали различные линтеры и шторм. Если теперь и попадётся очередная интеграция с protobuf, то обязательно буду использовать их библиотеку, хоть она и не полностью независимая.
Советую и вам к использованию.
Кстати, надо бы в
---
Теперь осталось, чтобы кто-нибудь написал нормальный генератор PHP классов по Open API спеке, а то там вообще мрак. Может когда-нибудь и сам доберусь до него, чтобы интегрировать в Yii Dev Panel и генерировать контракты несколькими кликами в UI.
---
Ссылка на стрим: https://www.youtube.com/watch?v=E61resEfgUE
Ссылка на канал: https://news.1rj.ru/str/php_fart
Когда досмотрел стрим увидел, что он был 3 месяца назад 😬
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍6
#Пост №5. Про Open source
Open source – это идеология распространения программы таким образом, что любой желающий может увидеть её исходный код, внести изменения в исходный код и даже предложить это изменение авторам.
Open source – это место для тренировки коммуникативных и технических скиллов; место отдыха от рабочих проектов; место изучения новых технологий.
Open source – это желание улучшить мир.
Open source – это то, что ты можешь оставить после себя. Даже уйдя из IT.
Open source – это место обучения других.
Open source – это карма личности, популярность, уважение, открытые возможности.
Open source – это средство получить большую выгоду, жертвуя своей.
---
Как Open source может помочь Вам?
- Изучение новой технологии, с которой вы давно хотели поработать
- Изучение алгоритмов, которые используются в других проектах
- Изучение подходов и правил декомпозиции больших проектов, библиотек, фреймворков
- Подсмотреть лучшую версию компонента, который вы реализовали недавно
Архитектура? Шаблоны проектирования? Шаблоны программирования? Алгоритмы? Тесты? Документация? Системы сборки? Командные процессы? Внутренние договоренности? Всё это есть в открытом доступе, остается лишь дотянуться и начать становиться лучше.
Как вы можете помочь Open source?
- Ответ в Issue
- Проверка гипотезы
- Проверка бага
- Исправить баг
- Сделать Code review
- Написать фичу
- Поправить доку
- Добавить перевод
- Написать интеграцию
- Написать тест
- Предложить улучшения
- Добавить метрики
- Написать CI процесс
- Сделать замеры производительности
- Сделать инфографику
- Поддержите финансово
В Open source вы можете делать всё то, что вы умеете делать хорошо или всегда хотели начать делать.
Начните свою Open source жизнь прямо сейчас:
- Найдите репозиторий технологии / фреймворка / проекта, с которым чаще всего работаете
- Почитайте Issue, изучите проблемы или фича-запросы
- Углубитесь в кодовую базу, дайте ответ на проблему или подготовьте изменения в виде Pull Request
Сделав это несколько раз, могу предположить, вам однозначно понравится. Авторы будут вам благодарны за помощь, а комьюнити за развитие.
Open source – это не только про разработку непосредственно. Можно быть проджект менеджером, дизайнером, переводчиком, писателем документации, визионером или любой другой ролью
---
Если вы еще не знаете куда внести свой вклад, могу порекомендовать Yii3 😉
В Yii3 есть много репозиториев под различные цели. Если вы хотите сделать какую-то новую интеграцию и отдать её на поддержку в Yii, то напишите мне, я помогу вам это сделать.
Open source – это идеология распространения программы таким образом, что любой желающий может увидеть её исходный код, внести изменения в исходный код и даже предложить это изменение авторам.
Open source – это место для тренировки коммуникативных и технических скиллов; место отдыха от рабочих проектов; место изучения новых технологий.
Open source – это желание улучшить мир.
Open source – это то, что ты можешь оставить после себя. Даже уйдя из IT.
Open source – это место обучения других.
Open source – это карма личности, популярность, уважение, открытые возможности.
Open source – это средство получить большую выгоду, жертвуя своей.
---
Как Open source может помочь Вам?
- Изучение новой технологии, с которой вы давно хотели поработать
- Изучение алгоритмов, которые используются в других проектах
- Изучение подходов и правил декомпозиции больших проектов, библиотек, фреймворков
- Подсмотреть лучшую версию компонента, который вы реализовали недавно
Архитектура? Шаблоны проектирования? Шаблоны программирования? Алгоритмы? Тесты? Документация? Системы сборки? Командные процессы? Внутренние договоренности? Всё это есть в открытом доступе, остается лишь дотянуться и начать становиться лучше.
Как вы можете помочь Open source?
- Ответ в Issue
- Проверка гипотезы
- Проверка бага
- Исправить баг
- Сделать Code review
- Написать фичу
- Поправить доку
- Добавить перевод
- Написать интеграцию
- Написать тест
- Предложить улучшения
- Добавить метрики
- Написать CI процесс
- Сделать замеры производительности
- Сделать инфографику
- Поддержите финансово
В Open source вы можете делать всё то, что вы умеете делать хорошо или всегда хотели начать делать.
Начните свою Open source жизнь прямо сейчас:
- Найдите репозиторий технологии / фреймворка / проекта, с которым чаще всего работаете
- Почитайте Issue, изучите проблемы или фича-запросы
- Углубитесь в кодовую базу, дайте ответ на проблему или подготовьте изменения в виде Pull Request
Сделав это несколько раз, могу предположить, вам однозначно понравится. Авторы будут вам благодарны за помощь, а комьюнити за развитие.
Open source – это не только про разработку непосредственно. Можно быть проджект менеджером, дизайнером, переводчиком, писателем документации, визионером или любой другой ролью
---
Если вы еще не знаете куда внести свой вклад, могу порекомендовать Yii3 😉
В Yii3 есть много репозиториев под различные цели. Если вы хотите сделать какую-то новую интеграцию и отдать её на поддержку в Yii, то напишите мне, я помогу вам это сделать.
1👍4❤1🔥1
Не вспомню уже где услышал такую фразу, но звучит очень мотивирующе:
Компания каждый раз проводит перформанс ревью (360, 180 и прочие его подобия) – это некое тестирования тебя, насколько круто ты перформишь. Так почему ты не проводишь “Кеш ревью” – тестирование компании на предмет того, насколько по рынку она тебе платит?
Рост в IT – это не только в отметка CRM “Ваня – джун”, “Саша – мидл”, “Дима – сеньор”.
Рост в IT – это и ответственности, которые ты на себя берешь, и масштабы личности, которые ты растишь, и так же заработная плата, за которую ты тратишь своё личное время на развитие компании.
Развивать себя нужно самому и никогда не забывать про денежную составляющую. Личный рост отдельного человека никому не интересен, если он не придёт и не заберет его сам.
Please open Telegram to view this post
VIEW IN TELEGRAM
1💯2❤1
#оффтоп
Собеседование
Случайно в линке нашел пост, где человек на интервью "Senior React Developer" отказался решать задачки, комментируя тем, что "не знаю как решить".
Как оно там правда было не моё дело, но в комментах случайно зарубились с автором поста на тему следующего:
Я сказал, что считаю неуважением, когда тебе на позицию сеньора задают вопросы уровня джуна и дают соответствующие задачки на лайвкодинге.
Автор пытался меня убедить, что на интервью как раз такое и должно происходить, иначе "как понять, что ты сеньор разработчик, а не джун или сеньор gpt писатель промпта".
---
Бывает такое, что сеньоры валятся на сеньорских интервью, какие тут чат-гптшники уж.
Единственную мысль я бы хотел донести, что на процессе интервью нужно приходить с мыслью и целью партнёрства:
- Не вы должны компании, а вы нужны друг другу
- Не вы должны доказывать вашу компетентность, компания может подвергать её сомнению, а вы можете парировать.
Вы ведь не спрашиваете у компании о её годовых и квартальных доходах, количеству и качеству решенных задач за всё время. Спросить, конечно, вы можете, но ответ получите либо поверхностный, либо никакой.
Уйти с интервью, если вам не нравится общение или процесс интервью – это нормально. Так и нужно делать, если вас что-то не устраивает или вы считаете это неуважением к себе. Уважать нужно своё время, свои силы и навыки.
Если вы хотите пройти в компанию, о которой всегда мечтали, то можно и пожертвовать своим вкладом: и джуновские задачи порешать на интервью на сеньорскую позицию, и потратить ни один день на собесы, и на подготовку потратить месяц.
Не стоит возводить в максимализм это сообщение, но разделять тёплое и мягкое нужно научиться.
Собеседование
Случайно в линке нашел пост, где человек на интервью "Senior React Developer" отказался решать задачки, комментируя тем, что "не знаю как решить".
Как оно там правда было не моё дело, но в комментах случайно зарубились с автором поста на тему следующего:
Я сказал, что считаю неуважением, когда тебе на позицию сеньора задают вопросы уровня джуна и дают соответствующие задачки на лайвкодинге.
Автор пытался меня убедить, что на интервью как раз такое и должно происходить, иначе "как понять, что ты сеньор разработчик, а не джун или сеньор gpt писатель промпта".
---
Бывает такое, что сеньоры валятся на сеньорских интервью, какие тут чат-гптшники уж.
Единственную мысль я бы хотел донести, что на процессе интервью нужно приходить с мыслью и целью партнёрства:
- Не вы должны компании, а вы нужны друг другу
- Не вы должны доказывать вашу компетентность, компания может подвергать её сомнению, а вы можете парировать.
Вы ведь не спрашиваете у компании о её годовых и квартальных доходах, количеству и качеству решенных задач за всё время. Спросить, конечно, вы можете, но ответ получите либо поверхностный, либо никакой.
Уйти с интервью, если вам не нравится общение или процесс интервью – это нормально. Так и нужно делать, если вас что-то не устраивает или вы считаете это неуважением к себе. Уважать нужно своё время, свои силы и навыки.
Если вы хотите пройти в компанию, о которой всегда мечтали, то можно и пожертвовать своим вкладом: и джуновские задачи порешать на интервью на сеньорскую позицию, и потратить ни один день на собесы, и на подготовку потратить месяц.
Не стоит возводить в максимализм это сообщение, но разделять тёплое и мягкое нужно научиться.
1👍4
💾 Ретро 2023
#оффтоп
Этот год уже всё, давайте следующий.
Год подходит к концу и время подводить итоги: личная жизнь, здоровье, доходы, различные активности. Каюсь, в прошлом году было как-то лениво составлять планы, поэтому жил как жилось, но нажилось немало интересного. Расскажу урывками что случилось со мной за этот год:
✈️ Побывал в Турции, Грузии, России, Тайланде. Где-то несколько дней, где-то значительное время жил и живу
🦷 Вырвал зуб 6-ку, который года 3 был в ужасном состоянии
❤️ Завёл этот канал и нашел своих первых подписчиков
⭐ Начал больше времени уделять социальной части и медийки
🏍 Научился кататься на мотоцикле
📱 Купил экшен камеру и айфон
✂️ Научился делать резки и склейки в DaVinci
8️⃣ Поучаствовал в ~ 8-х разных проектах в качестве разработчика
📺 Посмотрел сотни фильмов
🎧 В Яндекс.Музыке прослушал почти 100 тысяч часов музыки
💲 Заработал десятки тысяч $$$
Ретроспектива состоит обычно из двух шагов, поэтому второй шаг будет с планами на новый 2024:
😬 Вставить зуб, а лучше 2
💯 Сделать тысячу подписчиков в телеграмме
📺 Запустить канал про IT мемы в Instagram / TikTok и набрать тысячу подписчиков там
👨🏫 Запустить серию обучающих уроков по приготовлению Yii3 на Youtube
🗺 Определиться с местом для постоянного места жительства
👫 Наладить личную жизнь
💪 Заменить пивное пузо спортивными кубиками пресса
🤑 Найти дополнительный источник заработка, помимо основной работы
🐈 Завести кота
🖼️ Зарелизить Yii3
🤑 Начать зарабатывать $10 000/month
Пока так, дальше буду делить подробнее, приоритезировать, фильтровать и ставить чекпоинты.
А вы ставите цели на год и следите за прогрессом время от времени? 😉
С наступающим новым 2024 годом!
——
Передаю эстафету ретро Александру Макарову и Олегу Мифле
#оффтоп
Год подходит к концу и время подводить итоги: личная жизнь, здоровье, доходы, различные активности. Каюсь, в прошлом году было как-то лениво составлять планы, поэтому жил как жилось, но нажилось немало интересного. Расскажу урывками что случилось со мной за этот год:
⭐ Начал больше времени уделять социальной части и медийки
🏍 Научился кататься на мотоцикле
✂️ Научился делать резки и склейки в DaVinci
8️⃣ Поучаствовал в ~ 8-х разных проектах в качестве разработчика
Ретроспектива состоит обычно из двух шагов, поэтому второй шаг будет с планами на новый 2024:
👨🏫 Запустить серию обучающих уроков по приготовлению Yii3 на Youtube
👫 Наладить личную жизнь
Пока так, дальше буду делить подробнее, приоритезировать, фильтровать и ставить чекпоинты.
А вы ставите цели на год и следите за прогрессом время от времени? 😉
С наступающим новым 2024 годом!
——
Передаю эстафету ретро Александру Макарову и Олегу Мифле
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍6🔥1
Хэндлим тему | Дерепко
💾 Ретро 2023 #оффтоп Этот год уже всё, давайте следующий. Год подходит к концу и время подводить итоги: личная жизнь, здоровье, доходы, различные активности. Каюсь, в прошлом году было как-то лениво составлять планы, поэтому жил как жилось, но нажилось…
This media is not supported in your browser
VIEW IN TELEGRAM
#мем
Пока я отдыхаю и снимаю тиктоки, как могу, нашел мем, который прям в тему.
Надеюсь мем соврет в этом году 😉
Пока я отдыхаю и снимаю тиктоки, как могу, нашел мем, который прям в тему.
Надеюсь мем соврет в этом году 😉
👍1😁1
Календарь, как смысл жизни
#пост №6.
Как-то случайно набрёл на статью одного из моих прошлых коллег про календарь. Статья занятная. Автор крутой.
Как обычно, телега не может засунуть больше 2 тысяч символов в мое сообщение, поэтому выкинул пост в телеграф: https://telegra.ph/Kalendar-kak-smysl-zhizni-01-23
#пост №6.
Как-то случайно набрёл на статью одного из моих прошлых коллег про календарь. Статья занятная. Автор крутой.
Как обычно, телега не может засунуть больше 2 тысяч символов в мое сообщение, поэтому выкинул пост в телеграф: https://telegra.ph/Kalendar-kak-smysl-zhizni-01-23
Telegraph
Календарь, как смысл жизни
Нет, это не мой календарь. Это календарь Миши Донского. С ним мне удалось поработать в Skyeng. Честно говоря, всеми прелестями календаря я начал пользоваться именно там. Тогда я и увидел, как Миша уже начинал это делать. Помимо Миши таким занимались большинство…
1👍4