Знаете почему Дима получил повышение и бухает с начальником, а герой статьи получил только выгорание? Потому что, когда Дима гуглил "как тестировать API", наткнулся на рекламу Minervasoft, воспользовался их решениями и его дела пошли в гору. 😎
Касаемо тегов согласен. Наверное надо было пояснить какие случаи имею ввиду.) Например, если мы разрабатываем плагин для какой-нибудь CMS, то всё-равно придётся проставлять версии в основном файле плагина или каком-нибудь манифесте иначе CMS банально не увидит изменения версии. Я про такие случаи, для которых тегирование так же никто не отменял.)
Ситуация, когда взял задачу в обед, комит сделал вечером иногда может быть, при сложной задаче, где изменяется всего 1-2 файла. Например, при оптимизации или фиксе не очевидного бага с внешними сложными зависимостями. Понимаю, что имел ввиду автор, не нужно делать огромный комит с многими изменениями, лучше разбить его на несколько. Как по мне, это проще определить по названию. Если у вас в названии идут перечисления, например Fix account and add permissions явно видно, что это 2 комита, а не один. Если хочется назвать комит в стиле "Save changes", "State changes". То скорее всего изменений в нём столько и по разным задачам, что даже лень описывать и это ужасно. Почему так происходит? Самый банальный пример программист решает задачу, по ней появляется срочная подзадача. Часть кода по задаче уже написана, но пока не рабочая, а правки подзадачи нужно сделать сейчас. По итогу и задача, и подзадача идёт в один коммит. Этого можно избежать, используя git stash.
Очень желательно писать названия комитов всегда на английском языке. Даже если ваша команда работает только в России, даже если никто кроме вас код не увидит. Имхо, но это важно для единообразия. Если вы смените работу на интернациональную, то вам же проще будет привыкнуть писать комиты по новому. Так же с названиями комитов иногда бывают технические баги, когда например сервера со специфичными дистрибутивами линукса не поддерживают кириллицу.
Не согласен, что если работаешь один над проектом, нужно каждую задачу оборачивать в отдельную ветку. При работе в команде это правильно, но имхо когда ты один разработчик, проще вести 2 ветки (dev и main например) и/или использовать версии через теги. Понимаю, что "одна задача, одна ветка" это база, но мне кажется при работе одного разработчика с одним репозиторием немного избыточно.
Думаю стоит сказать о вроде очевидной, но частой проблеме. Если вы меняете окружение проекта или версию, всегда делаете это отдельным комитом. Даже если поменяли одну циферку, всегда это должен быть отдельный комит. Потому что на практике встречал такие моменты, когда истрия ветки скажем такая:
Change version 1.0.1
Fix smth
Change version 1.0.0
И вот ты решил откатиться до версии 1.0.0, думая что разница между версиями всего в один какой-то фикс, а оказывается, что в комит Change version 1.0.1 помимо изменении версии добавлено ещё дофига правок, которые тебе придётся изучать в коде. Хорошая история комитов - когда её можно скопировать почти без изменений в Change log проекта.
Ещё момент. Иногда нужно передать не рабочий код скажем коллеге. Порой проще и быстрее это сделать через комит. Делайте это только через unstable ветку (даже если в ней всего один комит), которую потом удалите. Если так вышло, что вы работаете в одной ветке вместе, то лучше прекращайте так работать и используйте принцип (одна ветка - одна задача), а на данный момент обязательно пометьте в названии комита, что он содержит проблемный код. Потому что сегодня вы сделали комит с поломанным кодом и проблему потом решили, через год вернётесь к коду и будете недоумевать почему, при загрузке комита ничего не работает вы же точно помните, как фиксили проблему. Опять же, эту проблему можно избежать при помощи CI/CD. Совет скорее маленьким командам в 1-3 человека, где часто git flow пренебрегают.
Либо у вас путаница в голове, либо вы слишком скомкано пишите.
Event loop (ноды), управляет асинхронными задачами в рамках одного потока, а менеджер потоков, что понятно из названия, управляет потоками (паралелит, балансирует, обеспечивает передачу данных между ними и т.д.). Как человек, который много писал на C# и хорошо знаком с работой потоков (не путать с асинхронностью, это не одно и тоже), немного не понимаю ваш тейк, что якобы event loop делает менеджер потоков, не нужным. Это 2 разных инструмента, которые используются на разных слоях приложения. В той же наде насколько я помню, потоки под капотом тоже используются, например для работы с файлами.
Так же для организации асинхронности event loop не всегда используется в разных яп. У C#, C++ и Java для асинхронности используются другие инструменты и подходы. Даже в Go о котором в статье речь используется насколько помню goroutine manager или как-то так.
Опять же почему личные данные парсят, вместо того, чтобы обратиться к рекрутинговым сервисам напрямую и не запросить официально обезличенную информацию для обучения нейронки? Всё же речь о взаимоотношениях юридических лиц идёт.
А так да, требования к сбору и хранению ДП в России довольно жёсткие. Сам с этим по работе сталкивался. Например, сервисы, хранящие определённые данные (например паспорта) должны получить для этого аккредитацию.
Во всех остальных случаях - против удалёнки только неадекватны, не имеющие видения, боящиеся что сотрудник недорабатывает, либо менеджеры, которые боятся остаться на улице за ненадобностью.
Причём именно на удалёнке толковые менеджеры намного более востребованные, чем в офисе, т.к. работы на удалёнке у них обычно больше.
Про эффективность тоже особо страхов не понимаю. Мне кажется в офисе куда проще держаться за рабочее место с плохой производительностью, чем на удалёнке. Видел разных работодателей. От тех, кто буквально поминутно просил трекать работу, до адекватных с подходом, чуть ли не со свободным графиком (т.к. международные команды, сильно разные часовые пояса). По моим наблюдениям работники во втором случае показывали результаты лучше, т.к. есть задача, есть дедлайн и есть всё для её решения при этом ничего лишнего. Обычно если человек не справляется с работой, на удалёнке это видно сразу. В офисе по моим наблюдениям это не так, хотя многое зависит от организации работы, если в офисе следят за каждым чихом, то понятное дело тоже быстро выявят.
Касаемо последнего тезиса, то он применим и к офису. Если человеку нравится работа, он будет работать с энтузиазмом, а если не нравится, то будет отлынивать, а зумеры просто убегут при удобном случае.
Команда из сениор-джавистов/дотнечиков с 15+ лет опыта набирается за месяц.
Команда из сеньоров это что-то странное, но видимо сейчас для части компаний это стало нормой. Причуды смещения грейдов по навыкам.
Да, это всё так, но мой вопрос был немного про другое. Условно я знаю gRPC на уровне просмотра 10 часового стрима и небольшой личной практики, а компания требует хорошее знание gRPC, то разве не будет враньём, если скажу на собеседовании, что знаю эту технологию твёрдо и чётко? По идее, это обман работодателя, чего лучше делать не стоит исходя из статьи.
Моё мнение, что лучше никогда не обманывать работодателя, касаемо хард скилов. Касаемо опыта, софт скилов и т.д. можно, т.к. это второстепенно, а вот хард скилы для программистов важнее всего.
Банальный пример с тем же Юрой, если бы он честно сказал на собеседовании, что плохо знает gRPC, то наверное работодатель не стал бы ему давать сложные задачи, с которыми он явно справится и Юре не пришлось "убегать после обеда". Я вот про это. 😊
Что-то многие сервисы сейчас подобное разрабатывают. Имхо но включение только платных комментариев для своего тг канала - это буквально совершить его суицид. Единственное, как можно было это грамотно реализовать, например сделать так, что платные комментарии всегда будут первыми в списке, это ещё как-то может жить, в остальном не вижу реализации, которая бы имела хоть какую-то пользу.
кандидат видел вакансию и знал, куда он идет. И почему тогда, уделив всего 10–15 минут своего времени, он не мог ознакомиться с этой технологией?
Обычно в вакансиях пишут строго требуемый стек и желательный стек. Подразумевается, что если человек не знает технологию из абзаца "будет плюсом", то он должен быть готов с ней быстро разобраться.
Имхо, но за 10-15 минут невозможно изучить материал, чтобы даже наврать мол "я знаю эту технологию". Личный пример. Я неоднократно разворачивал кафку на серверах и настраивал под php, писал консьюмеры, у меня есть понимание того, как работают брокеры и где их использовать, но я на собесе честно скажу, что мало знаю кафку и опыта работы с брокерами сообщений у меня нет. Потому что это правда, а быстренько почитать статейки за 10-15 минут, потом наврать, что знаю технологию и завалиться на первом же простом вопросе, мне кажется не очень хорошей идеей.
Оу, при помощи AI можно создавать приложения/игры/сайты не написав ни единой строчки кода. Даже ребёнок справится. Никогда такого не было и вот опять. Конструкторы приложений на любой вкус и цвет существуют ещё с 90-ых. Более расширенные nocode решения пояаились чуть позже. Сейчас в nocode решения интегрируют функционал нейронок. На протяжении всего этого времени слышу, что программисты станут не нужны, но по итогу всё совсем наоборот.
Опять же подобные сервисы с нейронками, что описаны в статье появились давно и уже никого не удивляют.
Ну я недавно экспериментировал. Заставил GPT делать простенький шутер на Tree.js. Создал отдельный проект а gpt, задал глобальные промпты для всех чатов проекта, сделал скрипт что все исходники минифтцирует и бьёт по файлам, чтобы их можно было загруить проект GPT. И казалось бы у GPT есть все данные и контекст, но описанных мной ошибок, хоть и стало меньше, но они есть. Более того, даже с учётом правильно настроенного gpt проекта, он с каждым новым чатом проекта теряет контекст и забывает что было в предыдущих чатах проекта.
Да, пользоваться можно любой моделью, хоть llama обучить самостоятельно документации по нужному стеку, но проблемы эти никуда не денутся. Недавно была новость о создании AI разработчика, что состоял из множеста агентов и конкретно агент, отвечающий за кодинг, чуть ли не на уровне джедаев код пишет. По итогу ai разраб при работе с реальным проектом смог успешно выполнить только 15% задач. Так что для полноценной разработки проектов только средствами AI ещё далеко.
LLM вполне могут писать банальный код и даже построить какой-то простой проект более-менее адекватный. Однако в плане поддержки они просто ужас. Помню в проектах, где специально заставлял кодить только GPT, меня задолбало ему писать уточнения, т.к. сам он всегда идёт по пути наименьшего сопротивления. Если можно весь код обернуть в один файл, он его обернёт. Если ему говоришь сделать 2 правки он делает всегда только одну за ответ. Он обожает тупо удалять важные куски кода. Он обожает писать странные решения, а так же обожает вложенные if и elseif. LLM любая, банально не способна вести проект. Они круты, в написании муторного кода (например просчёт коллизий для 3д объектов), но маленького по размерам. Они хорошо работают с классами в 100-200 строк кода, но требуют постоянного контроля, т.к. обожают нести отсебятину.
Ну и главная проблема LLM для бизнеса. Представим ситуацию, что компания решила написать простой интернет-магазин и каким-то чудом нейронка с этим справилась, а менеджер, что задавал запросы нейронке отдалённо, что-то понимает в кодинге. И вот ситуация, на сайте нашли баг-блокер, бизнес теряет клиентов, надо фиксить, а серваки GPT, опять упали, после того, как восстановили работу GPT из кода выкинул важные блоки, менеджер не знает, что делать, сам он поправить не может, не хватает скилов. И что делает бизнес в такой ситуации? Правильно идёт к кодерам за помощью.
Касаемо указателей, то вроде есть и явно же, но урезано. Я про алиасы &$var. По идее, когда мы, передаём скалярные типы данных или массивы, то передаётся копия переменной. Если переменная является объектом, то алиас не нужен и по умолчанию передаётся ссылка на объект.
Знаете почему Дима получил повышение и бухает с начальником, а герой статьи получил только выгорание? Потому что, когда Дима гуглил "как тестировать API", наткнулся на рекламу Minervasoft, воспользовался их решениями и его дела пошли в гору. 😎
Касаемо тегов согласен. Наверное надо было пояснить какие случаи имею ввиду.) Например, если мы разрабатываем плагин для какой-нибудь CMS, то всё-равно придётся проставлять версии в основном файле плагина или каком-нибудь манифесте иначе CMS банально не увидит изменения версии. Я про такие случаи, для которых тегирование так же никто не отменял.)
Как говорится это классика, это знать надо.)
От себя могу добавить:
Ситуация, когда взял задачу в обед, комит сделал вечером иногда может быть, при сложной задаче, где изменяется всего 1-2 файла. Например, при оптимизации или фиксе не очевидного бага с внешними сложными зависимостями. Понимаю, что имел ввиду автор, не нужно делать огромный комит с многими изменениями, лучше разбить его на несколько. Как по мне, это проще определить по названию. Если у вас в названии идут перечисления, например Fix account and add permissions явно видно, что это 2 комита, а не один. Если хочется назвать комит в стиле "Save changes", "State changes". То скорее всего изменений в нём столько и по разным задачам, что даже лень описывать и это ужасно. Почему так происходит? Самый банальный пример программист решает задачу, по ней появляется срочная подзадача. Часть кода по задаче уже написана, но пока не рабочая, а правки подзадачи нужно сделать сейчас. По итогу и задача, и подзадача идёт в один коммит. Этого можно избежать, используя git stash.
Очень желательно писать названия комитов всегда на английском языке. Даже если ваша команда работает только в России, даже если никто кроме вас код не увидит. Имхо, но это важно для единообразия. Если вы смените работу на интернациональную, то вам же проще будет привыкнуть писать комиты по новому. Так же с названиями комитов иногда бывают технические баги, когда например сервера со специфичными дистрибутивами линукса не поддерживают кириллицу.
Не согласен, что если работаешь один над проектом, нужно каждую задачу оборачивать в отдельную ветку. При работе в команде это правильно, но имхо когда ты один разработчик, проще вести 2 ветки (dev и main например) и/или использовать версии через теги. Понимаю, что "одна задача, одна ветка" это база, но мне кажется при работе одного разработчика с одним репозиторием немного избыточно.
Думаю стоит сказать о вроде очевидной, но частой проблеме. Если вы меняете окружение проекта или версию, всегда делаете это отдельным комитом. Даже если поменяли одну циферку, всегда это должен быть отдельный комит. Потому что на практике встречал такие моменты, когда истрия ветки скажем такая:
И вот ты решил откатиться до версии 1.0.0, думая что разница между версиями всего в один какой-то фикс, а оказывается, что в комит Change version 1.0.1 помимо изменении версии добавлено ещё дофига правок, которые тебе придётся изучать в коде. Хорошая история комитов - когда её можно скопировать почти без изменений в Change log проекта.
Ещё момент. Иногда нужно передать не рабочий код скажем коллеге. Порой проще и быстрее это сделать через комит. Делайте это только через unstable ветку (даже если в ней всего один комит), которую потом удалите. Если так вышло, что вы работаете в одной ветке вместе, то лучше прекращайте так работать и используйте принцип (одна ветка - одна задача), а на данный момент обязательно пометьте в названии комита, что он содержит проблемный код. Потому что сегодня вы сделали комит с поломанным кодом и проблему потом решили, через год вернётесь к коду и будете недоумевать почему, при загрузке комита ничего не работает вы же точно помните, как фиксили проблему. Опять же, эту проблему можно избежать при помощи CI/CD. Совет скорее маленьким командам в 1-3 человека, где часто git flow пренебрегают.
Либо у вас путаница в голове, либо вы слишком скомкано пишите.
Event loop (ноды), управляет асинхронными задачами в рамках одного потока, а менеджер потоков, что понятно из названия, управляет потоками (паралелит, балансирует, обеспечивает передачу данных между ними и т.д.). Как человек, который много писал на C# и хорошо знаком с работой потоков (не путать с асинхронностью, это не одно и тоже), немного не понимаю ваш тейк, что якобы event loop делает менеджер потоков, не нужным. Это 2 разных инструмента, которые используются на разных слоях приложения. В той же наде насколько я помню, потоки под капотом тоже используются, например для работы с файлами.
Так же для организации асинхронности event loop не всегда используется в разных яп. У C#, C++ и Java для асинхронности используются другие инструменты и подходы. Даже в Go о котором в статье речь используется насколько помню goroutine manager или как-то так.
Опять же почему личные данные парсят, вместо того, чтобы обратиться к рекрутинговым сервисам напрямую и не запросить официально обезличенную информацию для обучения нейронки? Всё же речь о взаимоотношениях юридических лиц идёт.
А так да, требования к сбору и хранению ДП в России довольно жёсткие. Сам с этим по работе сталкивался. Например, сервисы, хранящие определённые данные (например паспорта) должны получить для этого аккредитацию.
Потому что реальные проблемы LLM не решат, а вот "умный" фильтр сделать при помощи них, это пожалуйста.
Да и видимо тренд нейронок, только сейчас стал добираться до российских компаний, в то время как забугром уже все с ними "наигрались".
Причём именно на удалёнке толковые менеджеры намного более востребованные, чем в офисе, т.к. работы на удалёнке у них обычно больше.
Про эффективность тоже особо страхов не понимаю. Мне кажется в офисе куда проще держаться за рабочее место с плохой производительностью, чем на удалёнке. Видел разных работодателей. От тех, кто буквально поминутно просил трекать работу, до адекватных с подходом, чуть ли не со свободным графиком (т.к. международные команды, сильно разные часовые пояса). По моим наблюдениям работники во втором случае показывали результаты лучше, т.к. есть задача, есть дедлайн и есть всё для её решения при этом ничего лишнего. Обычно если человек не справляется с работой, на удалёнке это видно сразу. В офисе по моим наблюдениям это не так, хотя многое зависит от организации работы, если в офисе следят за каждым чихом, то понятное дело тоже быстро выявят.
Касаемо последнего тезиса, то он применим и к офису. Если человеку нравится работа, он будет работать с энтузиазмом, а если не нравится, то будет отлынивать, а зумеры просто убегут при удобном случае.
Команда из сеньоров это что-то странное, но видимо сейчас для части компаний это стало нормой. Причуды смещения грейдов по навыкам.
Да, это всё так, но мой вопрос был немного про другое. Условно я знаю gRPC на уровне просмотра 10 часового стрима и небольшой личной практики, а компания требует хорошее знание gRPC, то разве не будет враньём, если скажу на собеседовании, что знаю эту технологию твёрдо и чётко? По идее, это обман работодателя, чего лучше делать не стоит исходя из статьи.
Моё мнение, что лучше никогда не обманывать работодателя, касаемо хард скилов. Касаемо опыта, софт скилов и т.д. можно, т.к. это второстепенно, а вот хард скилы для программистов важнее всего.
Банальный пример с тем же Юрой, если бы он честно сказал на собеседовании, что плохо знает gRPC, то наверное работодатель не стал бы ему давать сложные задачи, с которыми он явно справится и Юре не пришлось "убегать после обеда". Я вот про это. 😊
Что-то многие сервисы сейчас подобное разрабатывают. Имхо но включение только платных комментариев для своего тг канала - это буквально совершить его суицид. Единственное, как можно было это грамотно реализовать, например сделать так, что платные комментарии всегда будут первыми в списке, это ещё как-то может жить, в остальном не вижу реализации, которая бы имела хоть какую-то пользу.
Deep помню очень любил. До сих пор подобной игры с схожей задумкой не встречал.
Я использую j2me loader)
А потом эти же HR жалуются на гостинг от зумеров, хотя сами ровно так же поступают.
Обычно в вакансиях пишут строго требуемый стек и желательный стек. Подразумевается, что если человек не знает технологию из абзаца "будет плюсом", то он должен быть готов с ней быстро разобраться.
Имхо, но за 10-15 минут невозможно изучить материал, чтобы даже наврать мол "я знаю эту технологию". Личный пример. Я неоднократно разворачивал кафку на серверах и настраивал под php, писал консьюмеры, у меня есть понимание того, как работают брокеры и где их использовать, но я на собесе честно скажу, что мало знаю кафку и опыта работы с брокерами сообщений у меня нет. Потому что это правда, а быстренько почитать статейки за 10-15 минут, потом наврать, что знаю технологию и завалиться на первом же простом вопросе, мне кажется не очень хорошей идеей.
Оу, при помощи AI можно создавать приложения/игры/сайты не написав ни единой строчки кода. Даже ребёнок справится. Никогда такого не было и вот опять. Конструкторы приложений на любой вкус и цвет существуют ещё с 90-ых. Более расширенные nocode решения пояаились чуть позже. Сейчас в nocode решения интегрируют функционал нейронок. На протяжении всего этого времени слышу, что программисты станут не нужны, но по итогу всё совсем наоборот.
Опять же подобные сервисы с нейронками, что описаны в статье появились давно и уже никого не удивляют.
Да, так и есть.)
Ну я недавно экспериментировал. Заставил GPT делать простенький шутер на Tree.js. Создал отдельный проект а gpt, задал глобальные промпты для всех чатов проекта, сделал скрипт что все исходники минифтцирует и бьёт по файлам, чтобы их можно было загруить проект GPT. И казалось бы у GPT есть все данные и контекст, но описанных мной ошибок, хоть и стало меньше, но они есть. Более того, даже с учётом правильно настроенного gpt проекта, он с каждым новым чатом проекта теряет контекст и забывает что было в предыдущих чатах проекта.
Да, пользоваться можно любой моделью, хоть llama обучить самостоятельно документации по нужному стеку, но проблемы эти никуда не денутся. Недавно была новость о создании AI разработчика, что состоял из множеста агентов и конкретно агент, отвечающий за кодинг, чуть ли не на уровне джедаев код пишет. По итогу ai разраб при работе с реальным проектом смог успешно выполнить только 15% задач. Так что для полноценной разработки проектов только средствами AI ещё далеко.
LLM вполне могут писать банальный код и даже построить какой-то простой проект более-менее адекватный. Однако в плане поддержки они просто ужас. Помню в проектах, где специально заставлял кодить только GPT, меня задолбало ему писать уточнения, т.к. сам он всегда идёт по пути наименьшего сопротивления. Если можно весь код обернуть в один файл, он его обернёт. Если ему говоришь сделать 2 правки он делает всегда только одну за ответ. Он обожает тупо удалять важные куски кода. Он обожает писать странные решения, а так же обожает вложенные if и elseif. LLM любая, банально не способна вести проект. Они круты, в написании муторного кода (например просчёт коллизий для 3д объектов), но маленького по размерам. Они хорошо работают с классами в 100-200 строк кода, но требуют постоянного контроля, т.к. обожают нести отсебятину.
Ну и главная проблема LLM для бизнеса. Представим ситуацию, что компания решила написать простой интернет-магазин и каким-то чудом нейронка с этим справилась, а менеджер, что задавал запросы нейронке отдалённо, что-то понимает в кодинге. И вот ситуация, на сайте нашли баг-блокер, бизнес теряет клиентов, надо фиксить, а серваки GPT, опять упали, после того, как восстановили работу GPT из кода выкинул важные блоки, менеджер не знает, что делать, сам он поправить не может, не хватает скилов. И что делает бизнес в такой ситуации? Правильно идёт к кодерам за помощью.
Да, я и говорю что раньше спрашивали мало где.) А сейчас про О спрашивают вообще везде, потому что на хайпе)
Касаемо указателей, то вроде есть и явно же, но урезано. Я про алиасы &$var. По идее, когда мы, передаём скалярные типы данных или массивы, то передаётся копия переменной. Если переменная является объектом, то алиас не нужен и по умолчанию передаётся ссылка на объект.
Это как с вещественными и ссылочными типами в C#)