Идеальный вариант — это разделить сгенеренный и написанный вручную код. Есть разные способы это сделать:
Например, генерим Java‑классы для ORM или ещё какие‑нибудь и всё, руками в них ничего не правим, только ссылаемся на них. При перегенерации эти файлы просто полностью заменяют предыдущие версии
Если всё‑таки нужно что‑то править, то типовой подход — унаследовать от сгенеренных классов свои и реализовать в них какие‑нибудь методы, которые не могут быть сгенерены. В этом случае мы тоже можем полностью заменять перегенеренные файлы и нет сложностей с синхронизацией изменений
Ещё хорошая идея хранить сгенеренный код отдельно в папке src‑gen или generated. Или в папке target, если он генерится при сборке
На мой взгляд, для большинства случаев этого достаточно
Более сложный вариант — это отметить в сгенеренном коде защищенные области исправленные вручную. И кодогенератор не будет их переписывать. Например, Acceleo это поддерживает:
Incremental Generation
Whether you are considering it or not, you will one day have to modify manually your generated code and you want to keep your modification even if you are regenerating your code. Acceleo lets you define protected areas in which you can safely modify the generated.
Ещё более замороченный вариант — это вообще не генерить код, а интерпретировать модели в runtime. Но это гораздо сложнее с точки зрения отладки, сгенеренный код хотя бы посмотреть можно, а что там в runtime происходит не узнаешь пока не запустишь приложение. Плюс сгенеренный код обычно гораздо проще, чем код такого интерпретатора. Ещё в этом варианте дополнительные накладные расходы на интерпретацию модели
Потому что всегда нужно хранить дополнительные параметры модели, которых нет ни в БД, ни в коде
В принципе и в коде (например, в аннотациях) можно хранить дополнительные параметры или в базе данных в комментариях. Но потом захочется хранить в аннотациях названия названия сущностей и атрибутов на разных языках. Потом захочется хранить в аннотациях только ключи, а сами локализованные строки в properties‑файлах. Потом захочется запилить DSL для описания модели данных. Потом захочется описывать ещё какие‑нибудь модели (машины состояний, процессы). Проще уж сразу для всего этого использовать отдельный инструмент моделирования, где всё хранится в простом и удобном виде.
Ещё модели можно хранить рядом с кодом, не обязательно отдельно
Состояние БД сравнивается с моделью и генерируется DDL, который приводит БД к состоянию модели
Можно так или можно в инструменте моделирования хранить версии моделей и сравнивать их между собой
Если разрабам неудобно напрямую в таком редакторе менять структуру - хоть что делай, они будут работать в другом инструменте, и иногда синхронизировать модель
Здесь вопрос кто отвечает за модель данных. Если аналитики и архитекторы, то им может быть удобнее работать в инструменте моделирования, где у них остальные модели.
Например, на наших проектах было неудобно редактировать SQL‑скрипты и Java‑код руками, потому что модель данных достаточно большая, всё это правилось разными разработчиками. Во-первых это просто муторно править этот boilerplate код, причём в нескольких местах и ещё документацию обновлять. Во-вторых несмотря на обилие правил линтеров, архитектурных тестов на ArchUnit и т.д. всё равно этот код оскорблял мои чувства перфекциониста. Проще поправить в одном месте, перегенерить всё и получить идеальный код, соответствующий всем соглашениям.
На мой взгляд процесс разработки должен быть выстроен так что правится только модель данных, остальное генерируется и не возникает проблемы, что что-то хочется поправить в коде минуя модель. Плюс, согласен, и инструмент моделирования должен быть удобным, например, поправил модель в той же IDE, в которой работаешь с кодом, перегенерил код и всё
Да, у нас тоже model‑first, в этом и смысл модельно‑ориентированного подхода, что модель — это основной артефакт, а всё остальное — производное от модели. Но при этом у модели могут быть разные формы представления. Например, у нас можно открыть модель одновременно в текстовом и диаграммном редакторе, вносить изменения в любом из них, при этом будет обновляться второе представление:
Наличие текстового редактора для моделей не делает наш подход code‑first.
Насчет поддержки актуальности, да, проще всего вносить изменения только в модель, остальное перегенерировать. Это позволяет в том числе версионировать модели, оценивать обратную совместимость изменений в каждой версии, генерить SQL‑скрипты, которые вносят изменения в базу данных, а не пересоздают её.
Обратная задача (reverse engineering — создание или обновление модели по коду) может быть уже немного сложнее, хотя в принципе тоже имеет право на существование. Особенно если есть legacy‑проект, где просто база данных, код и нет никаких моделей
Насчет Python. Вообще, несмотря на то, что в этой области есть много разных DSL для преобразования моделей, генерации кода и т. д. Python тоже достаточно популярный, например, есть Python‑плагин для Capella, ещё есть такая библиотечка для работы с MOF‑моделями в Python. Мы к своему инструменту моделирования тоже планируем прикрутить Python, чтобы не пугать людей QVTo, Acceleo и т. д.
Спасибо! Я думаю проектированию ПО много где обучают, но в основном там используются готовые языки, методики, инструменты моделирования. Не слышал о специальностях, где рассказывают про метамодели или разработку своих DSL, хотя может они и существуют. В целом это достаточно специфическая область, не так много компаний, которые занимаются разработкой своих языков моделирования или инструментов моделирования. Например, мы занимаемся и у нас есть внутренний курс для сотрудников и заказчиков с лабораторными работами и т.п.
Лично мне просто всегда было интересно моделирование и повезло с проектами. Но вообще я уверен, что эта область знаний могла бы быть полезной во многих проектах и компаниях, а не только каких-то специфических. Возможно статья получилась не очень удачная, попробую это учесть :)
Я периодически с этим сталкиваюсь когда люди боятся трогать существующий код, пишут поверх всё больше и больше каких-то костылей. Даже строил графики по коммитам в Git, на которых видно, что подавляющее большинство людей только добавляют код и почти ничего не удаляют. А один-два человека пытаются бороться с этим хаосом и удаляют тысячи строк, при этом умудряются добавить новую функциональность или починить баги
Достаточно сложно вовлечь всех разработчиков в этот процесс уничтожения кода, но в принципе это возможно. На самом деле ИТ отличается от науки или искусства тем, что все задачи здесь вполне формализуемые, декомопзируемые. И если в какой-то момент разработка просто останавливается из-за сложности, то это вполне решаемо
Это полный офтопик, но когда читаю такие статьи задаюсь вопросом на каком языке они написаны, почему в оригинале их читать на много проще чем в переводе. Видимо чаша терпения переполнилась и я решил порефлексировать на эту тему...
Например, фраза "В React 19 мы добавляем поддержку использования async-функций..." по-русски звучит проще "В React 19 добавлена поддержка async-функций...". В русском языке пассивный залог позволяет избавиться от лишней информации. В этой статье чуть ли не в каждом предложении "мы добавили", "мы улучшили" и т.д. И так понятно, что это сделали вы, зачем это постоянно повторять? С другой стороны, верно и обратное, когда переводишь с русского на английский, то нужно избавляться от пассивного залога, он усложняет понимание английского текста.
Или фраза "Для получения дополнительной информации смотрите документацию по use" проще звучит "Дополнительная информация доступна в документации по use".
"... чтобы упростить эту задачу, мы добавили новый хук useFormStatus" - проще звучит "... для упрощения этой задачи добавлен новый хук useFormStatus".
"В прошлых версиях использование пользовательских элементов в React было затруднено, поскольку React рассматривал нераспознанные пропсы как атрибуты, а не свойства" - проще "В прошлых версиях React было сложно применять пользовательские элементы, т.к. нераспознанные пропсы считались атрибутами". Тоже звучит коряво, но, на мой взгляд, мозг запинается немного меньше.
И практически весь текст такой. Причём не только здесь, но и в большинстве переводных статей на хабре. В любом случае, спасибо и автору за этот перевод, и другим авторам за другие переводы. Но хочется в целом подсветить эту проблему. Если её в принципе увидеть, то исправить не так сложно.
А потом люди начинают писать код и при его чтении у меня снова возникает ощущение, что они его получали от инопланетян из параллельной вселенной. На столько замысловато он иногда сформулирован. Вот, люди начитаются переводов, а потом и код пишут так же, например, строят лестницы в ад из Java-стримов:
Если напрячь мозг, то конечно можно понять что имелось в виду. Но в ИТ и так достаточно вещей, над которыми можно напрягать мозг. Зачем создавать сложности искусственно? Текст должен читаться легко.
Короче пока меня не понесло дальше и я не начал разгонять, что язык определяет мышление, все проблемы нашей вселенной лежат в языковой плоскости, та же математика в значительной степени про язык, а не что-то ещё, и при этом она в основе всех наук... закончу сей пафосный трактат о судьбах человечества фразой из классиков: ты должен был бороться со злом, а не примкнуть к нему ИТшник, ты должен был упрощать всё, а не умножать сложность
да есть, и что толку, в линупс сообществе даже с этим не могут договориться, в итоге миллиард вариантов установщиков а пользоваться все так же неудобно как по старинке
Мне удобно, софт ставится одной командой: apt-get install vlc
Есть надстройки типа aptitude. Есть визуальные надстройки. В целом у большинства Linux дистрибутивов есть очень большое количество софта, который ставится одной командой или грубо говоря одной кнопкой. Для Windows аналог этого появился гораздо позже - это магазин приложений. Для меня такой подход на порядок удобнее, чем шарашиться по каким-то сайтам, качать какие-то непонятные дистрибутивы, потом отвечать на кучу вопросов, внимательно смотреть не поставлены ли какие-то лишние галочки, чтобы до кучи не установилось что-то ещё.
я кстати все еще удивлен что за кучу лет в линуксе так и не пришли к одному более менее стандартному способу установки приложений как в венде или макоси
По-моему всё ровно наоборот. В Windows только недавно пришли к тому, что в Linux было давным давно - репозотрии/магазины софта. И то, установщики в Windows обычно мучают какими-то лишними вопросами.
Я пытаюсь как-то объективно смотреть на эту тему. Но чем это неудобно в Windows я описал, а чем это неудобно в Linux я реально не понимаю, мне нужен какой-то пример.
Справедливости ради в Linux софт может устанавливаться и сложнее, может понадобиться добавить какие-нибудь сторонние репозитории. Или собрать из исходников, но я не помню когда делал это в последний раз. Хотя недавно мне понадобилось запустить Pentaho, это реально ад, у них нет ни Docker-образов, ни сочувствия к пользователям их продукта, ни желания чтобы их продуктом в принципе кто-то пользовался. Но это исключение и я просто вместо Pentaho возьму какой-нибудь Apache Superset, который запускается одной командой в Docker.
Flatpak и snap ещё упрощают и унифицируют процесс установки.
Скорее всего у меня специфические требования, весь софт, которым я пользуюсь изначально писался под Linux и там с ним проще работать. Я не ставлю какой-нибудь Photoshop или AutoCad под Wine, потому что они мне просто не нужны. А единственная игра, в которую я играл за последние много лет - это Baldur's Gate 3 и она вполне норм работает под Linux. Если людям нужен преимущественно Windows- или MacOS-софт, тогда, да, Linux наверное не удобен для этого.
И в целом насчет UI, это очень субъективно, но раньше мне больше нравился Gnome по сравнению с интерфейсом Windows, теперь больше нравится KDE. Есть и другие варианты, короче есть выбор. А интерфейс Windows, особенно в последних версиях мне вообще не кажется приятным и удобным, и не мне одному, но и многим пользователям Windows. Плюс у меня ощущение, что панель управления и кнопку "Пуск" переделывают чуть ли не в каждой версии Windows так что после этого они становятся только запутаннее. И вообще ощущение, что панель управления - это куча разрозненных приложений. В Gnome или KDE панель управления по-моему на порядок проще, хотя я редко туда заглядываю.
И вообще я установил и настроил всё что мне нужно, очень редко приходится что-то донастраивать. Да, я даже могу месяцами не перезапускать систему! А под Windows у меня конечно нет такой роскоши, она сама перезапустится в самый неподходящий момент.
Вдвойне абсурд, что за свои страдания на Windows я должен ещё и платить кому-то деньги. Блин, да, если бы мне платили по 10 тысяч в месяц за пользование Windows, даже в этом случае я не перешёл бы на неё.
Это не призыв к чему-то, просто личное мнение. У всех свои задачи и требования
Переиспользовании проверенных, протестированных и доказавших свою надежность решений вместо написания своих велосипедов
Другая крайность - это вместо велосипеда получить франкенштейна. Навтягивать из разных библиотек однострочных функций. На мой взгляд уж лучше написать у себя эти функции в едином стиле, чем тянуть лишние зависимости в проект
Можно вместо горизонтальных лифтов сделать метро как в Линии. Если сделать город не очень высоким, то вертикальные лифты может особо и не нужны. Либо вертикальные лифты могут загружаться в метро как вагончики или как капсулы внутри вагонов. Чтобы получались такие корованы, которые можно грабить, шутка :)
Можно обойтись без лифтовых шахт. Допустим на внешней стене города установлены солнечные панели, пушки, чтобы отстреливаться от зомби и просто сомнительных элементов, живущих за кольцом (хотя вряд ли там кто-то будет, говорят, что за кольцом жизни нет). А внутренняя стена с видом на парк прозрачная, там входные двери. На каждом этаже вдоль стены круговой рельс, по которому перемещаются платформы. Для перемещения платформ вверх-вниз наверное проще всего сделать отдельные вертикальные рельсы. Платформа может быть достаточно большой как и входная дверь в квартиру, поэтому не будет проблем с доставкой грузов любых размеров.
Такой дом может быть достаточно высоким, не будет проблем с перемещением. Можно сделать его не цилиндрическим, а замкнуть сверху купол. Тогда в парке будет полностью контролируемый климат
Был ли хоть какой то вклад, обратно в проект или его небыло
Понятно, что мой комментарий немного не в тему и ваш вопрос о другом.
Но по моему опыту не всегда легко сделать этот обратный вклад в проект. Pull реквесты могут очень долго рассматриваться и не приниматься. И дело не в том, что они недостаточно качественные или нужные, а просто у мейнтейнеров нет времени и мотивации их рассматривать.
На мой взгляд, более предпочтительно как-раз отправить pull реквест, а не делать свой форк, потому что запаришься потом обновлять форк из исходного репозитория.
Словом не всегда такая ситуация, что люди берут открытый код, улучшают его и не хотят ни с кем делиться. Бывает наоборот, что очень хочется поделиться, чтобы упростить себе работу, но для этого много препятствий
Вот мы уже имеем минимум 5 интервью по часу. Эти 5 интервью (а то и больше, в зависимости от сложности технической области) нужно встроить в общий рабочий процесс
У нас нетривиальная предметная область (разработка инструментов моделирования) и часа вполне достаточно, чтобы понять технический уровень специалиста, впишется ли он в проект, на сколько ему самому всё это будет интересно и комфортно, рассказать ему про проекты и т.д. Естественно для этого нужно не грузить его задачами с литкода и т.п., а поговорить с ним.
Многоэтапные собеседования наверное норм для каких-то компаний, но я не вижу смысла делать такое у нас. Если кандидат подходит, то нужно сразу делать оффер. Мне сложно представить, что можно морозить человека 2 месяца и он всё ещё будет хотеть у нас работать и не найдёт за это время что-то другое.
С другой стороны, у меня самого в качестве кандидата были интересные собеседования, когда мне предлагали подготовиться к алгоритмическому собеседованию (пройти пару курсов по алгоритмам каждый длиной больше месяца, порешать задачки на литкоде), потом назначить дату этого собеседования, потом пройти ещё несколько этапов и... после всего этого они расскажут мне про проекты! Отличный план! Я выполнил первый шаг, прошёл эти курсы, они были реально прикольные, я об этом не жалею, потом решил сотню задачек на литкоде. Но пока я всё это делал, естественно я забыл о существовании этой компании.
Блин, я задумался... Если я сам не хочу проходить 5 этапов собеседований в течение месяцев, то для меня совершенно естественно, что и другие люди этого не хотят. У меня нет цели просто устроиться в компанию, чтобы меня там прокачивали, растили до сеньора, тимлида и хз кого, давали разные бонусы и т.п. Я хочу работать над интересным проектом, хочу самореализоваться. Например, на мой текущей работе, мы пообщались на собеседовании, я отметил для себя определенные ключевые слова, потом за пару недель реализовал прототип будущего продукта просто потому что мне захотелось это сделать, потом пару недель походил в офис, мы общались, допиливали прототип, а потом мы оформили трудовые отношения. Не было этих душераздирающих историй, когда люди по два месяца только доступы получают, а через год начинают полноценно работать.
Для меня это оптимальный подход, когда ты сразу вовлекаешься в проект и вы оба с работодателем понимаете нужно вам всё это или нет. А многоэтапные собеседования - это прямая противоположность, просто изначально отрицательный отбор.
Наличие "Я" делает невозможным находиться в "состоянии потока", что очень сильно снижает вашу продуктивность.
Это что-то плохое? Я большую часть жизни провожу в этом пресловутом состоянии потока, супер-продуктивно работая. Только в выходные или в отпуске получается отвлечься на более важные для меня вещи.
Я реально не понимаю в чём проблема войти в это состояние. Куда сложнее из него выйти.
Повышать продуктивность ради чего? Чтобы мной восхищались коллеги, чтобы зарабатывать много денег, чтобы помогать кому-то? Я считаю, что лично я вполне продуктивен, меня больше волнует направленность этой продуктивности.
Из иллюзорности "Я" выходит, что все страдание и все счастье живых существ представлены в реальности одномоментно. В целом это ожидаемый вывод, если мы исходим из материализма, а не из концепции "уникальности" (а следовательно - отделенности) души или "Я". Ведь если мы признаем самостоятельность реальности, что она за спиной не исчезает, то значит и чувства других живых существ тоже не исчезают от того, что мы их не чувствуем внутри себя.
Это очень важный момент, потому что он позволяет обосновать мораль на рациональных предпосылках, а не на мифах о наказании после смерти или на важности соблюдения правил перед сверх существом. Появится понятие, очень похожее на "карму", но которая делает плохо не когда-то потом, а в тот момент, когда ты причинять боль другому.
По-моему для этого не нужны никакие концепции и обоснования. Если человек наделен эмпатией, то он чувствует страдания или наоборот радость другого. Если не наделен, то он социопат и вряд ли ему помогут рассуждения об иллюзорности "Я".
Проблема в том, что рассказ был про бинарность и ригидность мышления, нежелание понимать и принимать другие точки зрения, про разделение общества. Про то, что во всём этом нет никакого смысла. Нет смысла в спорах Windows vs Linux, Intel vs AMD, 1 vs 4, эльфы vs орков и т.д. Если человек придерживается иной точки зрения по любому вопросу, то можно оставить ему право "заблуждаться" или, если очень хочется, то попробовать разобраться почему он думает иначе. На мой субъективный взгляд это важная проблема, я надеялся этим рассказом сделать мир немного лучше.
Ещё хотелось насыпать немного кринжа про ежедневную рутину, когда условные коммиты в Git или любая другая работа съедают всё время человека. И только в выходные у него появляется возможность задуматься о действительно важных для него вещах. Но он этого не делает, потому что вокруг то чума, то война, то санкции, то голые вечеринки, то Пугачёва разводится с Галкиным, то ещё что-то. На мой субъективный взгляд, эта проблема особенно актуальна для ИТ, когда вся жизнь превращается в работу. Плюс СМИ ежедневно поддерживают информационный фон абсолютной жести и ада. И при всём этом гораздо комфортнее плыть по течению, закопаться в работу, строительство дачи и т.п. Очень страшно остаться наедине со своими мыслями, внутренней пустотой.
Но похоже никому не зашло. В следующий раз попробую подобрать более интересную тему, типа удаления WordPad из Windows или как лучше проходить собесы :)
Это подходит, если зп - основной приоритет. А если работа даёт самореализацию, у тебя интересный проект, то так просто не начнёшь ходить по собеседованиям. Иногда бывают разные предложения и я думаю какая минимальная сумма за которую я перешел бы к ним. Наверное я начал бы задумываться только при предложении x2 - x3 относительно текущей зп и то не факт. Понятно что никто столько и не предложит, поэтому какой смысл вообще идти на собеседование. Что самое смешное в некоторых компаниях наотрез отказываются рассказывать о твоём будущем проекте пока ты не пройдёшь 7 кругов собеседований. Ради чего? Чтобы просто попасть в вашу компанию и заниматься чем угодно?
С другой стороны, иногда я переходил даже с понижением зп просто потому что мне это было очень интересно и я боялся, что мне откажут, если я начну торговаться. Хотя это конечно другая крайность относительно подхода, который описали вы. Ничего хорошего в такой зацикленности на текущем проекте нет, обычно новый проект оказывается не таким уж плохим и гораздо более интересным.
В целом деньги наверное не такой плохой ориентир. Если ты просил повысить зп и тебе отказали, то может действительно ты не на столько нужен на этом проекте или проект не на столько востребован и перспективен.
Я иногда чувствую себя ChatGPT, у меня в каждом комментарии запускается бесконечный поток рефлексии. Основное отличие от искусственной нейронной сети наверное в том, что я отвечаю не на любой промпт, а на то, что триггерит лично меня и опираюсь преимущественно на личный опыт, а не на усредненный общечеловеческий. Интересная идея для стартапа - создать много разных нейронных сетей, которые опираются преимущественно на свои прошлые диалоги, могут узнавать собеседников, вспоминать какие-то факты из прошлого, которые те им рассказывали или наоборот могут рассказывать какие-то новые факты, которые будут интересны конкретному собеседнику. Интересно можно ли считать, что у такой нейронной сети будет личность, индивидуальность...
Вот, идея ещё для одного стартапа. В принципе, мой комментарий - это наверное не такой уж безумной поток случайных фактов и ассоциаций как выглядит на первый взгляд. Я очень часто начинаю с того, что пишу что-то совершенно противоположное тому, что пишет собеседник, например, "деньги не главное, интересный проект важнее". Потом путём долгой рефлексии, случайных ассоциаций, кулл стори из жизни я прихожу к тому, что, блин, наверное деньги всё-таки важны и в чём-то мой собеседник прав. Затем пытаюсь всё обобщить и подытожить, что наверное и то, и то важно и вообще в жизни нужен баланс. Потом мне становится душно от собственных пафосных нравоучений. И я начинаю иронизировать над собой "типа я как ChatGPT выдаю потоки безумия только по форме похожие на осмысленный текст". Потом включаются детские травмы и я пытаюсь доказать всем какой я замечательный, уже идею для второго стартапа описываю, хотя вроде ничего не предвещало, а представляете сколько идей я на работе генерю! Возьмите меня пожалуйста кто-нибудь на крутую работу с большой зп, ну, или хотя бы похвалите! Короче, если я не сверну сейчас этот поток саморефлексии, то наверное открою портал в ад (это как если два зеркала друг напротив друга поставить). В общем изначальная идея стартапа была добавить в ответы искусственной нейронной сети подобные паттерны, типа сначала не соглашаемся с собеседником, потом в итоге соглашаемся, а затем всё обобщаем. Хотя, блин, пока я это описывал придумал третий стартап - саморефлексирующий ИИ. И четвертый - ИИ, иронизирующий над разными вещами, например, над стартапами... Ой, минуту, у меня в комнате почему-то заиграла музыка Мика Гордона, в полу появилась полупрозрачная вибрирующая мембрана и кто-то см...
Теоретически наверное есть, но практически это почти полностью зависит от того сколько человек сам попросит. Нет никакого смысла надеяться, что кто-то поймёт и оценит вашу способность решать сложные задачи. Более того, лично у меня на всех работах корреляция зарплаты с масштабностью проектов была обратная, потому что я и так был замотивирован ей заниматься. Плюс если проект интересный, то сложнее от него отказаться и сменить работу с повышением зп.
На мой взгляд на 31:47 описан абсолютно типичный подход к оценке труда:
Вольная цитата: "Допустим, на проекте есть два человека, которые одинаково работают. Одному из них платишь мало, но ему хватает на еду, его прёт от работы и т.п. А если другому, нужно в 2 раза больше на отпуск на Бали 4 раза в год, новую машину и т.д., ну, просто у него такие потребности и он о них сообщает, то совершенно норм платить ему больше. Какая разница, если всех всё устраивает?.. А всех всё устраивает пока они не знают зп друг друга."
Например, я видел проекты, где техлид делает самые сложные задачи, работает больше всех и при этом получает в 2 раза меньше, чем рядовой разработчик, который за полгода самостоятельно закрывает ноль задач. При этом последнему не повышают зп, только переводят на ещё более простые задачи, он капец как недоволен этим и уходит в следующую компанию с повышением зп опять ничего не делать. А техлиду единственному на проекте даже годовую премию не выплачивают и он всё равно продолжает работать.
Да-да-да, конечно он сам дурак, просто у него не прокачены софтскилы и вообще возможно он не так хорош, обычный джун случайно попавший на позицию техлида - на мой взгляд всё это очередная пачка штампов распространенных в ИТ. У человека могут быть прекрасно прокачены софт-скилы, он понимает процесс разработки в целом, очень быстро разрешает любые вопросы с аналитиками и разработчиками, у него может быть отличное понимание создаваемого продукта, он разбирается в этой предметной области, легко декомпозирует сложные задачи, точно оценивает сроки, не боится браться за исследовательские задачи, менторит других разработчиков и т.д.
Но умение просить повышение зп, вовремя менять компании, понимание рынка, адекватная оценка себя и т.д. - на мой взгляд это совершенно отдельный навык, который не имеет отношения ни к хард, ни к софт скилам.
В общем, если подытожить всё это излияние, то на мой взгляд нужно концентрироваться не только на своих хард и софт скилах и ждать что кто-то их оценит. Нет, никто и никогда их не оценит, ровно наоборот, все будут абсолютно уверены, что вам и так норм, вам не нужен отпуск, а нужно ещё подкинуть работы, потому что вы прётесь от неё. А если хочется какого-то баланса в жизни, адекватной оценки своего труда, то это совершенно отдельный скилл. И если для человека это действительно важно, то наверное есть смысл осознать это, а не тупо отмахиваться: 1) о, да, просто у тебя компания плохая, в нормальных компаниях зп сама повышается 2) да наверное ты просто не так хорош как думаешь, был бы хорош получал бы больше. Меня триггерит от таких установок, я считаю их капец вредными.
Если Teams открыт и на компе, и на телефоне, то уведомления о новых сообщениях всегда приходят на телефон, даже если уже прочитаны на компе. Это выглядит совершенно базовой функциональностью, в телеграме почему-то работает. Чтобы включить эти уведомления тоже понадобились дополнительные настройки на телефоне, хотя в телеграме всё работало из коробки. Это на столько раздражает, что я отключил звук уведомлений на телефоне и вообще хочу удалить это приложение. С одной стороны, это плюс, потому что после удаления мобильного Teams станет только лучше. Но с другой стороны удивительно как можно сделать на столько раздражающее приложение... Может я единственный, человек, кто установил Teams и на комп, и на телефон? В моём рейтинге самых плохих приложений Skype и Teams делят первое место.
После звонка не отключается микрофон - это видно по значку микрофона в области уведомлений. Немного напрягает.
Нет полнофункционального клиента для Linux, например, чтобы поменять фон при видео-звонке. И в целом ощущение, что клиент для Linux не особо обновляется, хотя может в нём на самом деле используется обычный веб-клиент, поэтому нечего обновлять. И в веб-клиенте вроде тоже нельзя поменять фон. Не понимаю, почему на разных платформах возможности отличаются.
На Linux нельзя кликнуть по ссылке в письме и открыть звонок в десктопном приложении, открывается только в браузере. Раньше это работало, сейчас перестало. Может у меня что-то не так настроено, но почему с телеграмом нет таких проблем?
На Windows некоторые коллеги говорят, что из-за глюков перешли на веб-клиент. И у меня тоже иногда бывают баги, на днях шарил экран, попытался в чат отправить сообщение, Teams полностью завис, пришлось перезапускать.
При первом запуске часто не видны чаты, приходится перезапускать.
Команды - это какой-то неудобный ад, приходится пользоваться обычными чатами.
Мобильное приложение почему-то занимает в 3 раза больше, чем телеграм.
В целом работает ощутимо медленнее, чем телеграм.
Поиск в чатах и прокрутка - это какая-то жесть, всё перескакивает. Хотя, проверил сейчас, вроде стало нормально, ура! Ещё недавно этим было невозможно пользоваться.
Для большого количества задач фактическое время совпадает с оценкой с точностью до дня. В целом я обычно завышаю оценку на 1-2 дня:
Хотя я делаю это осознанно, интересно какое было бы распределение в противном случае. Возможно не получается нормальное распределение из-за того, что люди склонны перестраховываться или давать другим людям запас времени на задачу.
В сумме у меня получилась перестраховка на 42% - я реально посчитал, а не взял это число из Автостопом по галактике :). Правда это по мелким задачам. Возможна ситуация, что задачу завершили раньше, но завели по ней ещё несколько багов, которые тоже исправили раньше. Но если посмотреть в сумме за год, то эта перестраховка в итоге выходит примерно в ноль.
Кстати, что интересно я от разных людей слышал про коэффициент риска равный квадратному корню из двух - sqrt(2) = 1.41, что удивительно близко к моей интуитивной перестраховке.
Идеальный вариант — это разделить сгенеренный и написанный вручную код. Есть разные способы это сделать:
Например, генерим Java‑классы для ORM или ещё какие‑нибудь и всё, руками в них ничего не правим, только ссылаемся на них. При перегенерации эти файлы просто полностью заменяют предыдущие версии
Если всё‑таки нужно что‑то править, то типовой подход — унаследовать от сгенеренных классов свои и реализовать в них какие‑нибудь методы, которые не могут быть сгенерены. В этом случае мы тоже можем полностью заменять перегенеренные файлы и нет сложностей с синхронизацией изменений
Ещё хорошая идея хранить сгенеренный код отдельно в папке src‑gen или generated. Или в папке target, если он генерится при сборке
На мой взгляд, для большинства случаев этого достаточно
Более сложный вариант — это отметить в сгенеренном коде защищенные области исправленные вручную. И кодогенератор не будет их переписывать. Например, Acceleo это поддерживает:
Ещё более замороченный вариант — это вообще не генерить код, а интерпретировать модели в runtime. Но это гораздо сложнее с точки зрения отладки, сгенеренный код хотя бы посмотреть можно, а что там в runtime происходит не узнаешь пока не запустишь приложение. Плюс сгенеренный код обычно гораздо проще, чем код такого интерпретатора. Ещё в этом варианте дополнительные накладные расходы на интерпретацию модели
В принципе и в коде (например, в аннотациях) можно хранить дополнительные параметры или в базе данных в комментариях. Но потом захочется хранить в аннотациях названия названия сущностей и атрибутов на разных языках. Потом захочется хранить в аннотациях только ключи, а сами локализованные строки в properties‑файлах. Потом захочется запилить DSL для описания модели данных. Потом захочется описывать ещё какие‑нибудь модели (машины состояний, процессы). Проще уж сразу для всего этого использовать отдельный инструмент моделирования, где всё хранится в простом и удобном виде.
Ещё модели можно хранить рядом с кодом, не обязательно отдельно
Можно так или можно в инструменте моделирования хранить версии моделей и сравнивать их между собой
Здесь вопрос кто отвечает за модель данных. Если аналитики и архитекторы, то им может быть удобнее работать в инструменте моделирования, где у них остальные модели.
Например, на наших проектах было неудобно редактировать SQL‑скрипты и Java‑код руками, потому что модель данных достаточно большая, всё это правилось разными разработчиками. Во-первых это просто муторно править этот boilerplate код, причём в нескольких местах и ещё документацию обновлять. Во-вторых несмотря на обилие правил линтеров, архитектурных тестов на ArchUnit и т.д. всё равно этот код оскорблял мои чувства перфекциониста. Проще поправить в одном месте, перегенерить всё и получить идеальный код, соответствующий всем соглашениям.
На мой взгляд процесс разработки должен быть выстроен так что правится только модель данных, остальное генерируется и не возникает проблемы, что что-то хочется поправить в коде минуя модель. Плюс, согласен, и инструмент моделирования должен быть удобным, например, поправил модель в той же IDE, в которой работаешь с кодом, перегенерил код и всё
Да, у нас тоже model‑first, в этом и смысл модельно‑ориентированного подхода, что модель — это основной артефакт, а всё остальное — производное от модели. Но при этом у модели могут быть разные формы представления. Например, у нас можно открыть модель одновременно в текстовом и диаграммном редакторе, вносить изменения в любом из них, при этом будет обновляться второе представление:
Наличие текстового редактора для моделей не делает наш подход code‑first.
Насчет поддержки актуальности, да, проще всего вносить изменения только в модель, остальное перегенерировать. Это позволяет в том числе версионировать модели, оценивать обратную совместимость изменений в каждой версии, генерить SQL‑скрипты, которые вносят изменения в базу данных, а не пересоздают её.
Обратная задача (reverse engineering — создание или обновление модели по коду) может быть уже немного сложнее, хотя в принципе тоже имеет право на существование. Особенно если есть legacy‑проект, где просто база данных, код и нет никаких моделей
Насчет Python. Вообще, несмотря на то, что в этой области есть много разных DSL для преобразования моделей, генерации кода и т. д. Python тоже достаточно популярный, например, есть Python‑плагин для Capella, ещё есть такая библиотечка для работы с MOF‑моделями в Python. Мы к своему инструменту моделирования тоже планируем прикрутить Python, чтобы не пугать людей QVTo, Acceleo и т. д.
Спасибо! Я думаю проектированию ПО много где обучают, но в основном там используются готовые языки, методики, инструменты моделирования. Не слышал о специальностях, где рассказывают про метамодели или разработку своих DSL, хотя может они и существуют. В целом это достаточно специфическая область, не так много компаний, которые занимаются разработкой своих языков моделирования или инструментов моделирования. Например, мы занимаемся и у нас есть внутренний курс для сотрудников и заказчиков с лабораторными работами и т.п.
Лично мне просто всегда было интересно моделирование и повезло с проектами. Но вообще я уверен, что эта область знаний могла бы быть полезной во многих проектах и компаниях, а не только каких-то специфических. Возможно статья получилась не очень удачная, попробую это учесть :)
Я периодически с этим сталкиваюсь когда люди боятся трогать существующий код, пишут поверх всё больше и больше каких-то костылей. Даже строил графики по коммитам в Git, на которых видно, что подавляющее большинство людей только добавляют код и почти ничего не удаляют. А один-два человека пытаются бороться с этим хаосом и удаляют тысячи строк, при этом умудряются добавить новую функциональность или починить баги
Достаточно сложно вовлечь всех разработчиков в этот процесс уничтожения кода, но в принципе это возможно. На самом деле ИТ отличается от науки или искусства тем, что все задачи здесь вполне формализуемые, декомопзируемые. И если в какой-то момент разработка просто останавливается из-за сложности, то это вполне решаемо
Это полный офтопик, но когда читаю такие статьи задаюсь вопросом на каком языке они написаны, почему в оригинале их читать на много проще чем в переводе. Видимо чаша терпения переполнилась и я решил порефлексировать на эту тему...
Например, фраза "В React 19 мы добавляем поддержку использования async-функций..." по-русски звучит проще "В React 19 добавлена поддержка async-функций...". В русском языке пассивный залог позволяет избавиться от лишней информации. В этой статье чуть ли не в каждом предложении "мы добавили", "мы улучшили" и т.д. И так понятно, что это сделали вы, зачем это постоянно повторять? С другой стороны, верно и обратное, когда переводишь с русского на английский, то нужно избавляться от пассивного залога, он усложняет понимание английского текста.
Или фраза "Для получения дополнительной информации смотрите документацию по use" проще звучит "Дополнительная информация доступна в документации по use".
"... чтобы упростить эту задачу, мы добавили новый хук useFormStatus" - проще звучит "... для упрощения этой задачи добавлен новый хук useFormStatus".
"В прошлых версиях использование пользовательских элементов в React было затруднено, поскольку React рассматривал нераспознанные пропсы как атрибуты, а не свойства" - проще "В прошлых версиях React было сложно применять пользовательские элементы, т.к. нераспознанные пропсы считались атрибутами". Тоже звучит коряво, но, на мой взгляд, мозг запинается немного меньше.
И практически весь текст такой. Причём не только здесь, но и в большинстве переводных статей на хабре. В любом случае, спасибо и автору за этот перевод, и другим авторам за другие переводы. Но хочется в целом подсветить эту проблему. Если её в принципе увидеть, то исправить не так сложно.
А потом люди начинают писать код и при его чтении у меня снова возникает ощущение, что они его получали от инопланетян из параллельной вселенной. На столько замысловато он иногда сформулирован. Вот, люди начитаются переводов, а потом и код пишут так же, например, строят лестницы в ад из Java-стримов:
Если напрячь мозг, то конечно можно понять что имелось в виду. Но в ИТ и так достаточно вещей, над которыми можно напрягать мозг. Зачем создавать сложности искусственно? Текст должен читаться легко.
Короче пока меня не понесло дальше и я не начал разгонять, что язык определяет мышление, все проблемы нашей вселенной лежат в языковой плоскости, та же математика в значительной степени про язык, а не что-то ещё, и при этом она в основе всех наук... закончу сей пафосный трактат о судьбах человечества фразой из классиков:
ты должен был бороться со злом, а не примкнуть к немуИТшник, ты должен был упрощать всё, а не умножать сложностьЧел, да, я на свой Emacs конфиг больше лет потратил, у меня глаза краснее!
Мне удобно, софт ставится одной командой: apt-get install vlc
Есть надстройки типа aptitude. Есть визуальные надстройки. В целом у большинства Linux дистрибутивов есть очень большое количество софта, который ставится одной командой или грубо говоря одной кнопкой. Для Windows аналог этого появился гораздо позже - это магазин приложений. Для меня такой подход на порядок удобнее, чем шарашиться по каким-то сайтам, качать какие-то непонятные дистрибутивы, потом отвечать на кучу вопросов, внимательно смотреть не поставлены ли какие-то лишние галочки, чтобы до кучи не установилось что-то ещё.
По-моему всё ровно наоборот. В Windows только недавно пришли к тому, что в Linux было давным давно - репозотрии/магазины софта. И то, установщики в Windows обычно мучают какими-то лишними вопросами.
Я пытаюсь как-то объективно смотреть на эту тему. Но чем это неудобно в Windows я описал, а чем это неудобно в Linux я реально не понимаю, мне нужен какой-то пример.
Справедливости ради в Linux софт может устанавливаться и сложнее, может понадобиться добавить какие-нибудь сторонние репозитории. Или собрать из исходников, но я не помню когда делал это в последний раз. Хотя недавно мне понадобилось запустить Pentaho, это реально ад, у них нет ни Docker-образов, ни сочувствия к пользователям их продукта, ни желания чтобы их продуктом в принципе кто-то пользовался. Но это исключение и я просто вместо Pentaho возьму какой-нибудь Apache Superset, который запускается одной командой в Docker.
Flatpak и snap ещё упрощают и унифицируют процесс установки.
Скорее всего у меня специфические требования, весь софт, которым я пользуюсь изначально писался под Linux и там с ним проще работать. Я не ставлю какой-нибудь Photoshop или AutoCad под Wine, потому что они мне просто не нужны. А единственная игра, в которую я играл за последние много лет - это Baldur's Gate 3 и она вполне норм работает под Linux. Если людям нужен преимущественно Windows- или MacOS-софт, тогда, да, Linux наверное не удобен для этого.
И в целом насчет UI, это очень субъективно, но раньше мне больше нравился Gnome по сравнению с интерфейсом Windows, теперь больше нравится KDE. Есть и другие варианты, короче есть выбор. А интерфейс Windows, особенно в последних версиях мне вообще не кажется приятным и удобным, и не мне одному, но и многим пользователям Windows. Плюс у меня ощущение, что панель управления и кнопку "Пуск" переделывают чуть ли не в каждой версии Windows так что после этого они становятся только запутаннее. И вообще ощущение, что панель управления - это куча разрозненных приложений. В Gnome или KDE панель управления по-моему на порядок проще, хотя я редко туда заглядываю.
И вообще я установил и настроил всё что мне нужно, очень редко приходится что-то донастраивать. Да, я даже могу месяцами не перезапускать систему! А под Windows у меня конечно нет такой роскоши, она сама перезапустится в самый неподходящий момент.
Вдвойне абсурд, что за свои страдания на Windows я должен ещё и платить кому-то деньги. Блин, да, если бы мне платили по 10 тысяч в месяц за пользование Windows, даже в этом случае я не перешёл бы на неё.
Это не призыв к чему-то, просто личное мнение. У всех свои задачи и требования
Есть flatpak, snap, docker
Другая крайность - это вместо велосипеда получить франкенштейна. Навтягивать из разных библиотек однострочных функций. На мой взгляд уж лучше написать у себя эти функции в едином стиле, чем тянуть лишние зависимости в проект
Можно вместо горизонтальных лифтов сделать метро как в Линии. Если сделать город не очень высоким, то вертикальные лифты может особо и не нужны. Либо вертикальные лифты могут загружаться в метро как вагончики или как капсулы внутри вагонов. Чтобы получались такие корованы, которые можно грабить, шутка :)
Можно обойтись без лифтовых шахт. Допустим на внешней стене города установлены солнечные панели, пушки, чтобы отстреливаться от зомби и просто сомнительных элементов, живущих за кольцом (хотя вряд ли там кто-то будет, говорят, что за кольцом жизни нет). А внутренняя стена с видом на парк прозрачная, там входные двери. На каждом этаже вдоль стены круговой рельс, по которому перемещаются платформы. Для перемещения платформ вверх-вниз наверное проще всего сделать отдельные вертикальные рельсы. Платформа может быть достаточно большой как и входная дверь в квартиру, поэтому не будет проблем с доставкой грузов любых размеров.
Такой дом может быть достаточно высоким, не будет проблем с перемещением. Можно сделать его не цилиндрическим, а замкнуть сверху купол. Тогда в парке будет полностью контролируемый климат
Понятно, что мой комментарий немного не в тему и ваш вопрос о другом.
Но по моему опыту не всегда легко сделать этот обратный вклад в проект. Pull реквесты могут очень долго рассматриваться и не приниматься. И дело не в том, что они недостаточно качественные или нужные, а просто у мейнтейнеров нет времени и мотивации их рассматривать.
На мой взгляд, более предпочтительно как-раз отправить pull реквест, а не делать свой форк, потому что запаришься потом обновлять форк из исходного репозитория.
Словом не всегда такая ситуация, что люди берут открытый код, улучшают его и не хотят ни с кем делиться. Бывает наоборот, что очень хочется поделиться, чтобы упростить себе работу, но для этого много препятствий
Подскажите, если не секрет, какую JDK вы используете? OpenJDK или другую? Какую версию (11, 17, 21)? Должна ли JDK тоже иметь сертификат ФСТЭК?
И как реализовывали аутентификацию? Использовали ли что-нибудь типа Keycloak?
У нас нетривиальная предметная область (разработка инструментов моделирования) и часа вполне достаточно, чтобы понять технический уровень специалиста, впишется ли он в проект, на сколько ему самому всё это будет интересно и комфортно, рассказать ему про проекты и т.д. Естественно для этого нужно не грузить его задачами с литкода и т.п., а поговорить с ним.
Многоэтапные собеседования наверное норм для каких-то компаний, но я не вижу смысла делать такое у нас. Если кандидат подходит, то нужно сразу делать оффер. Мне сложно представить, что можно морозить человека 2 месяца и он всё ещё будет хотеть у нас работать и не найдёт за это время что-то другое.
С другой стороны, у меня самого в качестве кандидата были интересные собеседования, когда мне предлагали подготовиться к алгоритмическому собеседованию (пройти пару курсов по алгоритмам каждый длиной больше месяца, порешать задачки на литкоде), потом назначить дату этого собеседования, потом пройти ещё несколько этапов и... после всего этого они расскажут мне про проекты! Отличный план! Я выполнил первый шаг, прошёл эти курсы, они были реально прикольные, я об этом не жалею, потом решил сотню задачек на литкоде. Но пока я всё это делал, естественно я забыл о существовании этой компании.
Блин, я задумался... Если я сам не хочу проходить 5 этапов собеседований в течение месяцев, то для меня совершенно естественно, что и другие люди этого не хотят. У меня нет цели просто устроиться в компанию, чтобы меня там прокачивали, растили до сеньора, тимлида и хз кого, давали разные бонусы и т.п. Я хочу работать над интересным проектом, хочу самореализоваться. Например, на мой текущей работе, мы пообщались на собеседовании, я отметил для себя определенные ключевые слова, потом за пару недель реализовал прототип будущего продукта просто потому что мне захотелось это сделать, потом пару недель походил в офис, мы общались, допиливали прототип, а потом мы оформили трудовые отношения. Не было этих душераздирающих историй, когда люди по два месяца только доступы получают, а через год начинают полноценно работать.
Для меня это оптимальный подход, когда ты сразу вовлекаешься в проект и вы оба с работодателем понимаете нужно вам всё это или нет. А многоэтапные собеседования - это прямая противоположность, просто изначально отрицательный отбор.
Это что-то плохое? Я большую часть жизни провожу в этом пресловутом состоянии потока, супер-продуктивно работая. Только в выходные или в отпуске получается отвлечься на более важные для меня вещи.
Я реально не понимаю в чём проблема войти в это состояние. Куда сложнее из него выйти.
Повышать продуктивность ради чего? Чтобы мной восхищались коллеги, чтобы зарабатывать много денег, чтобы помогать кому-то? Я считаю, что лично я вполне продуктивен, меня больше волнует направленность этой продуктивности.
По-моему для этого не нужны никакие концепции и обоснования. Если человек наделен эмпатией, то он чувствует страдания или наоборот радость другого. Если не наделен, то он социопат и вряд ли ему помогут рассуждения об иллюзорности "Я".
Проблема в том, что рассказ был про бинарность и ригидность мышления, нежелание понимать и принимать другие точки зрения, про разделение общества. Про то, что во всём этом нет никакого смысла. Нет смысла в спорах Windows vs Linux, Intel vs AMD, 1 vs 4, эльфы vs орков и т.д. Если человек придерживается иной точки зрения по любому вопросу, то можно оставить ему право "заблуждаться" или, если очень хочется, то попробовать разобраться почему он думает иначе. На мой субъективный взгляд это важная проблема, я надеялся этим рассказом сделать мир немного лучше.
Ещё хотелось насыпать немного кринжа про ежедневную рутину, когда условные коммиты в Git или любая другая работа съедают всё время человека. И только в выходные у него появляется возможность задуматься о действительно важных для него вещах. Но он этого не делает, потому что вокруг то чума, то война, то санкции, то голые вечеринки, то Пугачёва разводится с Галкиным, то ещё что-то. На мой субъективный взгляд, эта проблема особенно актуальна для ИТ, когда вся жизнь превращается в работу. Плюс СМИ ежедневно поддерживают информационный фон абсолютной жести и ада. И при всём этом гораздо комфортнее плыть по течению, закопаться в работу, строительство дачи и т.п. Очень страшно остаться наедине со своими мыслями, внутренней пустотой.
Но похоже никому не зашло. В следующий раз попробую подобрать более интересную тему, типа удаления WordPad из Windows или как лучше проходить собесы :)
Это подходит, если зп - основной приоритет. А если работа даёт самореализацию, у тебя интересный проект, то так просто не начнёшь ходить по собеседованиям. Иногда бывают разные предложения и я думаю какая минимальная сумма за которую я перешел бы к ним. Наверное я начал бы задумываться только при предложении x2 - x3 относительно текущей зп и то не факт. Понятно что никто столько и не предложит, поэтому какой смысл вообще идти на собеседование. Что самое смешное в некоторых компаниях наотрез отказываются рассказывать о твоём будущем проекте пока ты не пройдёшь 7 кругов собеседований. Ради чего? Чтобы просто попасть в вашу компанию и заниматься чем угодно?
С другой стороны, иногда я переходил даже с понижением зп просто потому что мне это было очень интересно и я боялся, что мне откажут, если я начну торговаться. Хотя это конечно другая крайность относительно подхода, который описали вы. Ничего хорошего в такой зацикленности на текущем проекте нет, обычно новый проект оказывается не таким уж плохим и гораздо более интересным.
В целом деньги наверное не такой плохой ориентир. Если ты просил повысить зп и тебе отказали, то может действительно ты не на столько нужен на этом проекте или проект не на столько востребован и перспективен.
Я иногда чувствую себя ChatGPT, у меня в каждом комментарии запускается бесконечный поток рефлексии. Основное отличие от искусственной нейронной сети наверное в том, что я отвечаю не на любой промпт, а на то, что триггерит лично меня и опираюсь преимущественно на личный опыт, а не на усредненный общечеловеческий. Интересная идея для стартапа - создать много разных нейронных сетей, которые опираются преимущественно на свои прошлые диалоги, могут узнавать собеседников, вспоминать какие-то факты из прошлого, которые те им рассказывали или наоборот могут рассказывать какие-то новые факты, которые будут интересны конкретному собеседнику. Интересно можно ли считать, что у такой нейронной сети будет личность, индивидуальность...
Вот, идея ещё для одного стартапа. В принципе, мой комментарий - это наверное не такой уж безумной поток случайных фактов и ассоциаций как выглядит на первый взгляд. Я очень часто начинаю с того, что пишу что-то совершенно противоположное тому, что пишет собеседник, например, "деньги не главное, интересный проект важнее". Потом путём долгой рефлексии, случайных ассоциаций, кулл стори из жизни я прихожу к тому, что, блин, наверное деньги всё-таки важны и в чём-то мой собеседник прав. Затем пытаюсь всё обобщить и подытожить, что наверное и то, и то важно и вообще в жизни нужен баланс. Потом мне становится душно от собственных пафосных нравоучений. И я начинаю иронизировать над собой "типа я как ChatGPT выдаю потоки безумия только по форме похожие на осмысленный текст". Потом включаются детские травмы и я пытаюсь доказать всем какой я замечательный, уже идею для второго стартапа описываю, хотя вроде ничего не предвещало, а представляете сколько идей я на работе генерю! Возьмите меня пожалуйста кто-нибудь на крутую работу с большой зп, ну, или хотя бы похвалите! Короче, если я не сверну сейчас этот поток саморефлексии, то наверное открою портал в ад (это как если два зеркала друг напротив друга поставить). В общем изначальная идея стартапа была добавить в ответы искусственной нейронной сети подобные паттерны, типа сначала не соглашаемся с собеседником, потом в итоге соглашаемся, а затем всё обобщаем. Хотя, блин, пока я это описывал придумал третий стартап - саморефлексирующий ИИ. И четвертый - ИИ, иронизирующий над разными вещами, например, над стартапами... Ой, минуту, у меня в комнате почему-то заиграла музыка Мика Гордона, в полу появилась полупрозрачная вибрирующая мембрана и кто-то см...
Теоретически наверное есть, но практически это почти полностью зависит от того сколько человек сам попросит. Нет никакого смысла надеяться, что кто-то поймёт и оценит вашу способность решать сложные задачи. Более того, лично у меня на всех работах корреляция зарплаты с масштабностью проектов была обратная, потому что я и так был замотивирован ей заниматься. Плюс если проект интересный, то сложнее от него отказаться и сменить работу с повышением зп.
На мой взгляд на 31:47 описан абсолютно типичный подход к оценке труда:
https://www.youtube.com/watch?v=5-8rnwvZv7A&t=1907s
Вольная цитата: "Допустим, на проекте есть два человека, которые одинаково работают. Одному из них платишь мало, но ему хватает на еду, его прёт от работы и т.п. А если другому, нужно в 2 раза больше на отпуск на Бали 4 раза в год, новую машину и т.д., ну, просто у него такие потребности и он о них сообщает, то совершенно норм платить ему больше. Какая разница, если всех всё устраивает?.. А всех всё устраивает пока они не знают зп друг друга."
Например, я видел проекты, где техлид делает самые сложные задачи, работает больше всех и при этом получает в 2 раза меньше, чем рядовой разработчик, который за полгода самостоятельно закрывает ноль задач. При этом последнему не повышают зп, только переводят на ещё более простые задачи, он капец как недоволен этим и уходит в следующую компанию с повышением зп опять ничего не делать. А техлиду единственному на проекте даже годовую премию не выплачивают и он всё равно продолжает работать.
Да-да-да, конечно он сам дурак, просто у него не прокачены софтскилы и вообще возможно он не так хорош, обычный джун случайно попавший на позицию техлида - на мой взгляд всё это очередная пачка штампов распространенных в ИТ. У человека могут быть прекрасно прокачены софт-скилы, он понимает процесс разработки в целом, очень быстро разрешает любые вопросы с аналитиками и разработчиками, у него может быть отличное понимание создаваемого продукта, он разбирается в этой предметной области, легко декомпозирует сложные задачи, точно оценивает сроки, не боится браться за исследовательские задачи, менторит других разработчиков и т.д.
Но умение просить повышение зп, вовремя менять компании, понимание рынка, адекватная оценка себя и т.д. - на мой взгляд это совершенно отдельный навык, который не имеет отношения ни к хард, ни к софт скилам.
В общем, если подытожить всё это излияние, то на мой взгляд нужно концентрироваться не только на своих хард и софт скилах и ждать что кто-то их оценит. Нет, никто и никогда их не оценит, ровно наоборот, все будут абсолютно уверены, что вам и так норм, вам не нужен отпуск, а нужно ещё подкинуть работы, потому что вы прётесь от неё. А если хочется какого-то баланса в жизни, адекватной оценки своего труда, то это совершенно отдельный скилл. И если для человека это действительно важно, то наверное есть смысл осознать это, а не тупо отмахиваться: 1) о, да, просто у тебя компания плохая, в нормальных компаниях зп сама повышается 2) да наверное ты просто не так хорош как думаешь, был бы хорош получал бы больше. Меня триггерит от таких установок, я считаю их капец вредными.
Если Teams открыт и на компе, и на телефоне, то уведомления о новых сообщениях всегда приходят на телефон, даже если уже прочитаны на компе. Это выглядит совершенно базовой функциональностью, в телеграме почему-то работает. Чтобы включить эти уведомления тоже понадобились дополнительные настройки на телефоне, хотя в телеграме всё работало из коробки. Это на столько раздражает, что я отключил звук уведомлений на телефоне и вообще хочу удалить это приложение. С одной стороны, это плюс, потому что после удаления мобильного Teams станет только лучше. Но с другой стороны удивительно как можно сделать на столько раздражающее приложение... Может я единственный, человек, кто установил Teams и на комп, и на телефон? В моём рейтинге самых плохих приложений Skype и Teams делят первое место.
После звонка не отключается микрофон - это видно по значку микрофона в области уведомлений. Немного напрягает.
Нет полнофункционального клиента для Linux, например, чтобы поменять фон при видео-звонке. И в целом ощущение, что клиент для Linux не особо обновляется, хотя может в нём на самом деле используется обычный веб-клиент, поэтому нечего обновлять. И в веб-клиенте вроде тоже нельзя поменять фон. Не понимаю, почему на разных платформах возможности отличаются.
На Linux нельзя кликнуть по ссылке в письме и открыть звонок в десктопном приложении, открывается только в браузере. Раньше это работало, сейчас перестало. Может у меня что-то не так настроено, но почему с телеграмом нет таких проблем?
На Windows некоторые коллеги говорят, что из-за глюков перешли на веб-клиент. И у меня тоже иногда бывают баги, на днях шарил экран, попытался в чат отправить сообщение, Teams полностью завис, пришлось перезапускать.
При первом запуске часто не видны чаты, приходится перезапускать.
Команды - это какой-то неудобный ад, приходится пользоваться обычными чатами.
Мобильное приложение почему-то занимает в 3 раза больше, чем телеграм.
В целом работает ощутимо медленнее, чем телеграм.
Поиск в чатах и прокрутка - это какая-то жесть, всё перескакивает. Хотя, проверил сейчас, вроде стало нормально, ура! Ещё недавно этим было невозможно пользоваться.
Ради интереса посчитал свою статистику :)
Для большого количества задач фактическое время совпадает с оценкой с точностью до дня. В целом я обычно завышаю оценку на 1-2 дня:
Хотя я делаю это осознанно, интересно какое было бы распределение в противном случае. Возможно не получается нормальное распределение из-за того, что люди склонны перестраховываться или давать другим людям запас времени на задачу.
В сумме у меня получилась перестраховка на 42% - я реально посчитал, а не взял это число из Автостопом по галактике :). Правда это по мелким задачам. Возможна ситуация, что задачу завершили раньше, но завели по ней ещё несколько багов, которые тоже исправили раньше. Но если посмотреть в сумме за год, то эта перестраховка в итоге выходит примерно в ноль.
Кстати, что интересно я от разных людей слышал про коэффициент риска равный квадратному корню из двух - sqrt(2) = 1.41, что удивительно близко к моей интуитивной перестраховке.