Но у аудитории всегда есть возможность минусовать.
Не всегда. У меня, например, нет права минусовать, но есть право плюсовать. И я такой не один. Иными словами: сейчас авторам плохих статей намного легче получить плюсы (легально или нет), чем утонуть в минусах, ведь для плюсов хватит аккаунта с +1 кармы, а для минусов и выражения несогласия со статьёй нужна карма повыше.
многие сильные авторы стали тимлидами, руководителями компаний, у них много крутых задач и писать тупо некогда
Может некогда, а может ушли на другие площадки. Я не автор, но как давний читатель уже не первый раз думаю о том, что возможно я больше не целевая аудитория хабра, когда смотрю на количество отобранных для прочтения статей из десятков появившихся.
Картинка колеса жизни начинающих может запутать, т.к. дает иллюзию, что возможно выбрать всё (а ведь так и хочется). И только когда ресурсов начинает не хватать, переходишь от выбора "что хочется" к "чем не готов пожертвовать".
У меня дневник не зашел, может еще не дорос. Вместо этого ближе оказалась ретроспектива: раз в 1-2 недели сверяюсь насколько приближаюсь к целям и что нужно подкорректировать.
Хабр не балует своих читателей разнообразными механизмами реанимации поиска статей, «мотивируя» посетителей на перелопачивание максимально большего количества материалов. С позиции SEO это, наверно, правильно
Правильно ли? В 14 лет я мог подобным заниматься, а сейчас просто не буду тратить время на перелопачивание. В итоге на хабре посмотрю 0 статей, а мог бы что-то еще глянуть.
В компаниях-гигантах обычно проблем нет. А вот в средних компаниях, если hr вовремя не запустил процесс "поставьте нам оценку позязя", 5-10 актуальных отзывов останутся недоступными, т.к.необходимый лимит не набрался. Это прям очень раздражает, потому что чаще всего интересуют отзывы за прошлый и текущий годы, а они из-за этой системы оказываются скрыты.
У меня с последних собесов обратная картина: компании дают нормальные офферы для senior php на позиции senior php+go. Помимо своего стека просят показать знание общей базы, даже если она не представлена в php-стеке. Лиды на собесах жаловались, что даже на приличные бюджеты сложно искать людей, потому что приходит senior php и не знает что такое асинхронный запрос, треды, какую работу делает ОС, как работает БД, отладку ниже уровня xdebug не видел, а самым большим недостатком php называет "ну, там функции названы неконсистентно". И тут нанимающие понимают, что соискателю и без go еще пахать прилично.
Если же речь о переходе с php на чистую go-позицию (т.е. go без php), то не понимаю зачем. Хватает же компаний со смесью технологий, где можно переходить постепенно, без потери грейда и денег.
Расписание исключительно для тех дел, которые крайне важно сделать в конкретный день и конкретный час. Например, визит к стоматологу попадет в календарь. Стараюсь максимально избегать привязки к календарю, т.к.:
чувствую себя роботом, которым управляет календарь, и теряю радость от жизни
в назначенный час у меня может не быть сил или вдохновения сделать указанное
К гугл-календарю так и не привык. Использую напоминалки в слаке. Там же смотрю список этих напоминалок на день.
В списки идет все остальное, они более заполненные и в них есть градация по важности и срочности. Это позволяет более гибко выбирать время решения для срочных задач, и абсолютно не страдая двигать несрочное/неважное хоть сто раз, при этом не забывая об этих делах (т.к. они в списке), если звезды сошлись сделать что-то из менее приоритетного.
Есть еще важный момент: списки дел можно написать по-разному и в зависимости от этого они либо будут помогать, либо будут бесполезными. Писать работающие списки мне очень помогла вот эта статья https://habr.com/ru/companies/oleg-bunin/articles/348714/, которая заодно и вопросы по прокрастинации закрыла.
Этот KPI тоже обходится легко. Опытные ребята с порога просят разбить даже маленькую задачу на пачку микрозадач. В результате будет и много закрытых задач, и много пулл-реквестов, и много коммитов. По графикам — незаменимый человек.
Гуглим значение taxpayer-id: 7707083893 — это ИНН от ПАО Сбербанк Москва. Сравниваем со значением в org. Смотрим на VERIFIED.
Повеселили, спасибо :) Кдпв бы еще вставить после абзаца про низкую соц ответственность и две строчки на картинке выделить, тогда текст в голове сразу сойдется при чтении и шутки не потеряются.
Было бы здорово добавить и английские субтитры. Когда увидел заголовок, то сразу подумал об использовании для учебы: смотреть без субтитров, где нужно — включать английские, а для новых слов — английские субтитры менять на русские.
Звучит как то, что было у меня при выгорании на прошлой работе, когда работал слишком много. Позиция была хорошая, переработки оплачивались.
Но я, наоборот, нарушил рекомендации статьи: ушел с работы в никуда, 3 месяца ничего не делал (смотрел видосики, проходил старые игры, разбирал вкладки в браузере). Срок на отдых никакой не ставил. Решил, что если нужно будет год, то буду год бездельничать (была финансовая подушка). Через 3 месяца работать захотелось так сильно, что сидеть без дела стало невыносимо. Нашел работу, которая оказалась лучше прошлой.
Спустя два года полет нормальный. Вариант с перерывом между трудоустройствами понравился.
Из рекомендаций: обязательно договаривайтесь со второй половинкой, чтобы она не переживала, что вы решили вообще никогда не работать. Поддержка близких в этот момент очень важна.
руководителю подразделения сегодня компании готовы платить примерно 286 000 рублей. Доход эксперта в этой же области будет меньше в среднем на 100 000 рублей, но все равно достаточно внушительный — порядка 175 000 рублей
Мы ведь говорим про тимлида и senior-специалиста? У меня что-то цифры раза в 2 не сходятся, причем это будет еще не верхняя граница.
Работодатели в ходе опроса hh.ru отмечали, что главная причина, почему они отказывают в трудоустройстве потенциальным соискателям — это завышенные зарплатные ожидания. Об этом заявили сразу 82% опрошенных компаний.
Опытные соискатели не сильно расстраиваются и уходят в те компании, которые готовы платить по реальному рынку, а не "давайте пока поработаете за Х/2 и мы обсудим повышение через 6 месяцев по результатам работы".
Для меня основной причиной стало удобство. Хотя когда смотрел на vim первый раз, слово "удобный" — последнее, что приходило в голову.
Менее недели периодических посиделок в vim и мысли "зачем я тут страдаю" сменились на "как же приятно работать". Начинал с короткого vimtutor, затем посмотрел популярные плагины под язык, взял за основу чей-то конфиг, подобрал симпатичную тему и уже несколько лет пользуюсь.
Локально он у меня не заменил IDE, но хорошо дополнил. Удаленно на машинах стал главным редактором, там в nano и mcedit вообще не хочется возвращаться.
в JS async/await не решит этот придуманный сценарий, так как доходя до await выполнение "приостанавливается" и дальше ждет, что вернет вызов
Это касается только асинхронной функции, в которой находится апи-вызов. А вот основной тред не блокируется и в нем можно продолжать работать.
не могу придумать сценарий, когда мог бы спокойно выполнять какой-то код без полученных данных из внешних источников
Мы не всегда получаем, иногда только отправляем и позже лишь хотим убедиться, что запрос ушел без ошибок и не упал. Это не какая-то редкая/экзотическая операция.
Когда получаем данные, то далеко не всегда знаем в одной точке все запросы, которые нам надо сделать в течение всего жизненного цикла. И тут PHP не дает удобного способа сделать эти вызовы из разных мест, сохранив асинхронность.
Эти моменты и пытаются решить асинк-фреймворки
В описанном частном случае сразу указано, что запросы отправляются не одновременно. Эти запросы разнесены, т.е. нет возможности отправить их из одной точки разом. Нужно отправить один запрос, не блокироваться в ожидании ответа и делать другую работу (которая не в апи-клиенте расположена), но обработать ответы как можно раньше при их получении
Расскажите поподробнее, пожалуйста. Например, нужно отправить 2 http-запроса без блокировки, но не одновременно: сначала первый запрос, затем вернуться что-то повычислять, и отправить второй, а при получении ответов обработать их.
В JS это решается легко через async/await, в GO — тоже через горутины. Есть ли встренный аналог в PHP? Т.е. без установки swoole/amp/reactphp, без расширения parallel, без написания своего event loop на сокетах. Если такого нет, то дальше встает выбор во что вложить усилия: в изучение нового async-фреймворка на PHP, или в изучение нового языка, и по моим наблюдениям новый язык чаще побеждает
Согласен, тут некорректно выразился: под "как угодно" подразумевалось только менее строгое следование стилю оформления кода/форматированию. Т.е. часть, которая относится к переносам/отступам, и на которые обычно прикручивают чекеры/автоформатеры. Благодаря автоформатерам эту часть можно откладывать на попозже и поддерживаемость системы не сильно пострадает, если мы во время хакатона сэкономим время на этом этапе, т.к. настроенный позже инструмент легко приведет все файлы к нужному стилю
как сделать так чтобы Shemas генерировались с Entity
Я пару лет уже не писал, но помню брали тег @Model, и с ним работало.
Не минусил, но если интересуют замечания, то могу немного набросать из того, что сразу бросилось в глаза:
private ApiFrontendService $apiFrontendService;
Вы используете новую версию PHP, там можно свойство в конструктор внести, чтобы было меньше бойлерплейта. И apiFrontendService можно сразу на вход конструктора запросить, резолв зависимостей — задача фреймворка, симфони эту работу хорошо делает.
Request $request
Возможно для описанных примеров был бы удобнее doctrine-конвертер, он позволяет подать на вход контроллера сразу сущность.
Запросы к бд прямо в сервисе или контроллере, логика изменений в контроллере (editDepartament) вместо сервиса — эти моменты могут вызвать расстройство у опытных читателей, но тут можно оговориться, что у нас логики мало, сущности единообразные, плюс у нас хакатон, поэтому мы не выносим запросы в классы-репозитории и где-то ленимся еще сильнее и не выносим обработку в сервис. Такая оговорка также подскажет новичкам, что не стоит код копировать как есть в свои тестовые.
А вот возврат JsonResponse из сервиса, на мой взгляд, более грубое действие. Формат отдачи, как и код возврата — это работа контроллера. Сервис лучше держать удобным для обращения из других внешних точек: вызовов из консольной команды или из консюмера, а не только из контроллера. К тому же это довольно быстрая правка даже в контексте хакатона.
И последнее: на хакатоне можно писать как угодно, т.к. мы спешим, и инструменты настраивать некогда, но для статьи код желательно причесать под PSR-12: добавить strict_types, поправить отступы (первые строчки разные даже у приложенных двух файлов), скобки ")]" у OAT где-то на одной строке, где-то отдельно на разных. Это мелочи, но с ними код читается приятнее и выглядит более привычно.
За статью спасибо, легко читается. Взять новый для себя язык и фреймворк для хакатона — смело, справиться — вообще круто, видно опыт в IT. Отдельно хочется отметить swagger-аннотации: приятно видеть, что сделана не только апишка, но и дока к ней для удобства участников команды.
Не всегда. У меня, например, нет права минусовать, но есть право плюсовать. И я такой не один. Иными словами: сейчас авторам плохих статей намного легче получить плюсы (легально или нет), чем утонуть в минусах, ведь для плюсов хватит аккаунта с +1 кармы, а для минусов и выражения несогласия со статьёй нужна карма повыше.
Может некогда, а может ушли на другие площадки. Я не автор, но как давний читатель уже не первый раз думаю о том, что возможно я больше не целевая аудитория хабра, когда смотрю на количество отобранных для прочтения статей из десятков появившихся.
Картинка колеса жизни начинающих может запутать, т.к. дает иллюзию, что возможно выбрать всё (а ведь так и хочется). И только когда ресурсов начинает не хватать, переходишь от выбора "что хочется" к "чем не готов пожертвовать".
У меня дневник не зашел, может еще не дорос. Вместо этого ближе оказалась ретроспектива: раз в 1-2 недели сверяюсь насколько приближаюсь к целям и что нужно подкорректировать.
Не обязательно. Есть вариант со стрелочными функциями:
using variables from the parent scope is always automaticПравильно ли? В 14 лет я мог подобным заниматься, а сейчас просто не буду тратить время на перелопачивание. В итоге на хабре посмотрю 0 статей, а мог бы что-то еще глянуть.
В компаниях-гигантах обычно проблем нет. А вот в средних компаниях, если hr вовремя не запустил процесс "поставьте нам оценку позязя", 5-10 актуальных отзывов останутся недоступными, т.к.необходимый лимит не набрался. Это прям очень раздражает, потому что чаще всего интересуют отзывы за прошлый и текущий годы, а они из-за этой системы оказываются скрыты.
У меня с последних собесов обратная картина: компании дают нормальные офферы для senior php на позиции senior php+go. Помимо своего стека просят показать знание общей базы, даже если она не представлена в php-стеке.
Лиды на собесах жаловались, что даже на приличные бюджеты сложно искать людей, потому что приходит senior php и не знает что такое асинхронный запрос, треды, какую работу делает ОС, как работает БД, отладку ниже уровня xdebug не видел, а самым большим недостатком php называет "ну, там функции названы неконсистентно". И тут нанимающие понимают, что соискателю и без go еще пахать прилично.
Если же речь о переходе с php на чистую go-позицию (т.е. go без php), то не понимаю зачем. Хватает же компаний со смесью технологий, где можно переходить постепенно, без потери грейда и денег.
Использую и расписание, и списки дел.
Расписание исключительно для тех дел, которые крайне важно сделать в конкретный день и конкретный час. Например, визит к стоматологу попадет в календарь. Стараюсь максимально избегать привязки к календарю, т.к.:
чувствую себя роботом, которым управляет календарь, и теряю радость от жизни
в назначенный час у меня может не быть сил или вдохновения сделать указанное
К гугл-календарю так и не привык. Использую напоминалки в слаке. Там же смотрю список этих напоминалок на день.
В списки идет все остальное, они более заполненные и в них есть градация по важности и срочности. Это позволяет более гибко выбирать время решения для срочных задач, и абсолютно не страдая двигать несрочное/неважное хоть сто раз, при этом не забывая об этих делах (т.к. они в списке), если звезды сошлись сделать что-то из менее приоритетного.
Есть еще важный момент: списки дел можно написать по-разному и в зависимости от этого они либо будут помогать, либо будут бесполезными. Писать работающие списки мне очень помогла вот эта статья https://habr.com/ru/companies/oleg-bunin/articles/348714/, которая заодно и вопросы по прокрастинации закрыла.
Этот KPI тоже обходится легко. Опытные ребята с порога просят разбить даже маленькую задачу на пачку микрозадач. В результате будет и много закрытых задач, и много пулл-реквестов, и много коммитов. По графикам — незаменимый человек.
Смотрим на два поля у картинки в начале поста:
Гуглим значение taxpayer-id: 7707083893 — это ИНН от ПАО Сбербанк Москва. Сравниваем со значением в org. Смотрим на VERIFIED.
Повеселили, спасибо :) Кдпв бы еще вставить после абзаца про низкую соц ответственность и две строчки на картинке выделить, тогда текст в голове сразу сойдется при чтении и шутки не потеряются.
Было бы здорово добавить и английские субтитры. Когда увидел заголовок, то сразу подумал об использовании для учебы: смотреть без субтитров, где нужно — включать английские, а для новых слов — английские субтитры менять на русские.
Звучит как то, что было у меня при выгорании на прошлой работе, когда работал слишком много. Позиция была хорошая, переработки оплачивались.
Но я, наоборот, нарушил рекомендации статьи: ушел с работы в никуда, 3 месяца ничего не делал (смотрел видосики, проходил старые игры, разбирал вкладки в браузере). Срок на отдых никакой не ставил. Решил, что если нужно будет год, то буду год бездельничать (была финансовая подушка). Через 3 месяца работать захотелось так сильно, что сидеть без дела стало невыносимо. Нашел работу, которая оказалась лучше прошлой.
Спустя два года полет нормальный. Вариант с перерывом между трудоустройствами понравился.
Из рекомендаций: обязательно договаривайтесь со второй половинкой, чтобы она не переживала, что вы решили вообще никогда не работать. Поддержка близких в этот момент очень важна.
Мы ведь говорим про тимлида и senior-специалиста? У меня что-то цифры раза в 2 не сходятся, причем это будет еще не верхняя граница.
Опытные соискатели не сильно расстраиваются и уходят в те компании, которые готовы платить по реальному рынку, а не "давайте пока поработаете за Х/2 и мы обсудим повышение через 6 месяцев по результатам работы".
Для меня основной причиной стало удобство. Хотя когда смотрел на vim первый раз, слово "удобный" — последнее, что приходило в голову.
Менее недели периодических посиделок в vim и мысли "зачем я тут страдаю" сменились на "как же приятно работать". Начинал с короткого vimtutor, затем посмотрел популярные плагины под язык, взял за основу чей-то конфиг, подобрал симпатичную тему и уже несколько лет пользуюсь.
Локально он у меня не заменил IDE, но хорошо дополнил. Удаленно на машинах стал главным редактором, там в nano и mcedit вообще не хочется возвращаться.
Это касается только асинхронной функции, в которой находится апи-вызов. А вот основной тред не блокируется и в нем можно продолжать работать.
Эти моменты и пытаются решить асинк-фреймворки
В описанном частном случае сразу указано, что запросы отправляются не одновременно. Эти запросы разнесены, т.е. нет возможности отправить их из одной точки разом. Нужно отправить один запрос, не блокироваться в ожидании ответа и делать другую работу (которая не в апи-клиенте расположена), но обработать ответы как можно раньше при их получении
Расскажите поподробнее, пожалуйста. Например, нужно отправить 2 http-запроса без блокировки, но не одновременно: сначала первый запрос, затем вернуться что-то повычислять, и отправить второй, а при получении ответов обработать их.
В JS это решается легко через async/await, в GO — тоже через горутины. Есть ли встренный аналог в PHP? Т.е. без установки swoole/amp/reactphp, без расширения parallel, без написания своего event loop на сокетах. Если такого нет, то дальше встает выбор во что вложить усилия: в изучение нового async-фреймворка на PHP, или в изучение нового языка, и по моим наблюдениям новый язык чаще побеждает
Согласен, тут некорректно выразился: под "как угодно" подразумевалось только менее строгое следование стилю оформления кода/форматированию. Т.е. часть, которая относится к переносам/отступам, и на которые обычно прикручивают чекеры/автоформатеры. Благодаря автоформатерам эту часть можно откладывать на попозже и поддерживаемость системы не сильно пострадает, если мы во время хакатона сэкономим время на этом этапе, т.к. настроенный позже инструмент легко приведет все файлы к нужному стилю
Я пару лет уже не писал, но помню брали тег @Model, и с ним работало.
Не минусил, но если интересуют замечания, то могу немного набросать из того, что сразу бросилось в глаза:
Вы используете новую версию PHP, там можно свойство в конструктор внести, чтобы было меньше бойлерплейта. И apiFrontendService можно сразу на вход конструктора запросить, резолв зависимостей — задача фреймворка, симфони эту работу хорошо делает.
Возможно для описанных примеров был бы удобнее doctrine-конвертер, он позволяет подать на вход контроллера сразу сущность.
Запросы к бд прямо в сервисе или контроллере, логика изменений в контроллере (editDepartament) вместо сервиса — эти моменты могут вызвать расстройство у опытных читателей, но тут можно оговориться, что у нас логики мало, сущности единообразные, плюс у нас хакатон, поэтому мы не выносим запросы в классы-репозитории и где-то ленимся еще сильнее и не выносим обработку в сервис. Такая оговорка также подскажет новичкам, что не стоит код копировать как есть в свои тестовые.
А вот возврат JsonResponse из сервиса, на мой взгляд, более грубое действие. Формат отдачи, как и код возврата — это работа контроллера. Сервис лучше держать удобным для обращения из других внешних точек: вызовов из консольной команды или из консюмера, а не только из контроллера. К тому же это довольно быстрая правка даже в контексте хакатона.
И последнее: на хакатоне можно писать как угодно, т.к. мы спешим, и инструменты настраивать некогда, но для статьи код желательно причесать под PSR-12: добавить strict_types, поправить отступы (первые строчки разные даже у приложенных двух файлов), скобки ")]" у OAT где-то на одной строке, где-то отдельно на разных. Это мелочи, но с ними код читается приятнее и выглядит более привычно.
За статью спасибо, легко читается. Взять новый для себя язык и фреймворк для хакатона — смело, справиться — вообще круто, видно опыт в IT. Отдельно хочется отметить swagger-аннотации: приятно видеть, что сделана не только апишка, но и дока к ней для удобства участников команды.