да есть, и что толку, в линупс сообществе даже с этим не могут договориться, в итоге миллиард вариантов установщиков а пользоваться все так же неудобно как по старинке
Мне удобно, софт ставится одной командой: 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, что удивительно близко к моей интуитивной перестраховке.
Спасибо за ссылку! Когда-то давно краем глаза видел, но я не фуллтайм фронтендер, поэтому не отложилось в памяти. При написании кода это клево, но читать тяжело. Особенно если на проекте много людей которые только иногда заглядывают во фронт. Я имел в виду такие сокращения https://mui.com/system/getting-started/the-sx-prop/#spacing типа pt (который есть в Emmet), my (которого нет в Emmet), ... А потом MUI перейдёт на StyleX и опять переделывать все стили...
Мне привычнее и проще это сделать в браузере. Для меня один из больших плюсов веб-разработки в том, что она практически ничего не требует кроме браузера и любого текстового редактора. Очень легко и просто делается минимальный пример, прямо в браузере можно его поправить, сразу виден результат. Для реальных проектов, наверное, да, без сложного тулинга не обойтись, но иногда ощущение что люди искусственно делают простые вещи сложными. А потом в какой-то момент начинают писать статьи, что мы тут подумали и решили отказаться от TypeScript. Я не удивлюсь если через какое-то время фб откажется от StyleX в пользу обычного CSS.
Обычные переменные в CSS да, но когда всё это замешивается с JavaScript-кодом, то люди начинают там реализовывать просто лютейшую логику с кучей функций разбросанных по всему проекту. А в CSS у них такой возможности нет, приходится напрягать мозг, чтобы описать стили проще. Если в CSS-in-JS писать простые стили с простыми переменными без JavaScript-кода наверное это норм, но чем это лучше обычного CSS с переменными?..
Для меня минусы этой штуки и вообще CSS-in-JS вполне понятны:
Вместо понятного и распространенного CSS добавляется лишняя абстракция. Нужно дополнительно напрягать мозг при написании и чтении стилей. И глядя на какой-нибудь `p: 10` пытаться понять что это значит. Не знаю есть ли конкретно в StyleX такие сокращения, но зачем мне изучать ещё один язык, если я уже знаю CSS?
Изредка хочется использовать относительно сложные селекторы. В StyleX они видимо вообще не поддерживаются?
Информации по CSS просто на много-много порядков больше, чем по очередному CSS-in-JS. Когда находишь какой-нибудь CSS-рецепт каждый раз нужно его транслировать в StyleX или наоборот если у тебя проблемы со стилями, то чтобы задать вопрос их нужно сначала перевести на CSS.
Нельзя за 2 минуты создать HTML+CSS файлик в "блокноте" и по-быстрому отладить стили в браузере. Или поправить стиль в браузере и скопировать обратно
Это неизбежно приведет к появлению сложной логики в стилях - всякие переменные, вызовы функций так что в этих стилях потом сложно что-то понять
Эти фреймвоки бесконечно меняются и запаришься каждый раз мигрировать стили
Генерятся классы с рандомными названиями - их нельзя использовать для какой-нибудь логики на JS, для тестов
В чем вообще смысл всё запихивать в один большой файл? С двумя маленькими файлами проще работать чем с одним большим
Пытаюсь понять плюсы:
Возможно лет 15 назад, когда было много разных браузеров, CSS в них работал по-разному и вообще был очень ограниченный, был какой-то смысл в этих абстракциях, но сейчас зачем это
Решение проблем с наложением стилей, специфичностью. У меня обычно этих проблем не возникает, я просто придерживаюсь единой схемы описания стилей. Но ещё есть же всякие CSS layer, scope, shadow DOM. Они не решают эту проблему?
Людям сложно изучить CSS, а JS они уже знают. Непонятно что StyleX здесь упрощает, CSS всё равно придётся изучить, плюс добавится сложностей по постоянной трансляции стилей между CSS и StyleX в уме
Уменьшение суммарного размера CSS, ускорение загрузки и отрисовки за счет удаления неиспользуемых стилей при сборке, за счет динамической подгрузки стилей. Я в принципе не понимаю как можно написать стилей на десятки мегабайт, но для проекта масштаба фб наверное это возможно... Вообще конечно было бы интересно посмотреть что это за стили, почему их так много
Поддержка стилей не только в браузере, но и в нативных приложениях. В какой доле проектов это требуется?
В общем, к каким проблемам приведет StyleX я понимаю совершенно отчетливо, а преимущества как-то вообще не очевидны.
Мне эта тема очень близка. Я сам работал разработчиком, потом аналитиком, сейчас архитектором, техлидом (по факту одновременно и разработчиком, и аналитиком). На мой взгляд аналитические навыки важны для любого ИТшника. Лично у меня такой топ навыков:
1) Аналитический склад ума - это буквально способность раскладывать сложную задачу на более простые. Это полезно не только для аналитиков, но и для разработчиков, тестировщиков, РП. Например, мне как разработчику нужно реализовать что-то очень сложное. Прежде чем браться за это мне нужно разложить задачу на понятные шаги, выделить какие-то крупные модули будущего приложения. Или, например, есть несколько вариантов реализации задачи, человек с аналитическими навыками достаточно легко перечислит эти варианты, определит критерии для их сравнения и выберет оптимальный вариант. Такой выбор часто встаёт не только перед аналитиками, но и перед разработчиками.
2) Понимание процесса разработки в целом. Какая бы специализация у человека ни была, очень хорошо если он понимает через какие этапы проходит задача:
а) бизнес-анализ - когда задача максимально размыта, непонятно что делать и нужно преимущество собирать информацию, заниматься НИР
б) системный анализ - когда описывается уже конкретное техническое решение (сценарии использования, пользовательские истории, верхнеуровневые подсистемы, их взаимодействие, схема данных, бизнес правила, макеты интерфейсов)
в) разработка
г) тестирование
д) демонстрация заказчику, сдача в эксплуатацию
Например, для разработчиков важно понимать какие этапы задача должна была пройти до того как попала к ним. Если она недостаточно проработана с точки зрения аналитики, то можно не тупо реализовывать как написано, а пойти обсудить спорные вещи с аналитиками. Или если аналитиков на проекте нет, то самому написать и согласовать какой-нибудь минимальный дизайн-документ. Или предупредить заказчика, что реализация может быть не такой как он ожидает или что сроки неопределенные. Также полезно понимать какие этапы будут после того как ты реализовал свою задачу. Можно заранее поставить себя на место тестировщика или пользователя и прикинуть на сколько удобная и понятная получилась реализация. Что человеку будет удобнее - нажать десять кнопок или одну.
Это не значит что каждый ИТшник должен быть человек-оркестром и один выполнять работу за всех, но у него должно быть хотя бы общее представление о всём процессе, чтобы он не упарывался только в код, в документы, в тесты, в сроки. А в случае проблем (которые обычно возникают достаточно часто) он мог пойти к своим коллегам и решить спорные моменты.
3) Затем идёт основной навык специалиста.
Для разработчиков - это безусловно умение описывать и реализовывать алгоритмы. Конечно далеко не на всех проектах требуются сложные алгоритмы. Но, блин, даже в самых простых задачах условно "по перекладыванию JSONов" я часто вижу какой-нибудь поиск по массиву с квадратичной сложностью, какой-то безумный код, в котором просто невозможно ничего понять. Хотя бы базовое знание структур данных, алгоритмов нужно. Но заметьте, что я поставил это на третье место!
Для аналитиков - это умение собирать и обобщать информацию, в сжатом и понятном виде (текстом или голосом) доносить её до остальных участников проекта. Если аналитику приходится что-то объяснять, спорить, предлагать посмотреть ещё какие-то варианты и т.д., то работать тяжело - на мой взгляд это аналитик должен максимально быстро и легко воспринимать любую информацию и складывать её в соответствующую коробочку. Лично я ожидаю от аналитика что-то типа: да, я понимаю о чём ты говоришь, я об этом уже подумал, но это частный случай такой-то ситуации, мы его сможем реализовать потом. А если аналитик наоборот всё усложняет, находит какой-нибудь специфический сценарий, который в реальности не нужен, и выстраивает всё вокруг него, то тяжело.
Для тестировщиков и РП мне лень писать. Иначе этот комментарий рискует превратиться в монографию. Хотя, блин, я не могу удержаться, знания переполняют меня, я на столько преисполнился понимаем этого мира, что просто не могу не поделиться своей мудростью (и наверное во многом болью) с человечеством (по крайней мере с той его частью, которая читает хабр).
Для тестировщиков наверное важно находить неожиданные сценарии, о которых не подумали ни аналитики, ни разработчики. И с минимальным количеством тестов и усилий проверять максимум функциональности.
Для РП на мой взгляд важно фокусироваться на приоритетах и сроках. Я считаю, что любая задача должна оцениваться по двум простым критериям: важность и сложность. В первую очередь делаются важные и простые задачи. Всё остальное делается потом. Я часто сталкивался с ситуациями когда в первую очередь по какой-то неведомой причине делаются самые ненужные и сложные задачи, а под конец в панике и срочно-срочно начинают делаться важные задачи и хорошо если простые, тогда есть шанс успеть хоть что-то. Хотя на мой взгляд этот навык важен не только для РП, но и для всех ИТшников.
Да, на самом деле, все эти навыки важны для всех ИТшников, просто каждый специализируется в первую очередь на своём.
4) Общие технические знания. Мне лень подробно на этом останавливаться. Но для всех не лишне иметь какое-то представление о базах данных и нормализации данных, о форматах данных (чтобы отличать XML от JSON), о протоколах передачи данных, многослойной архитектуре, API и т.д.
5) Специфические навыки, которые появляются с годами задрачивания чего-нибудь. Например, умение дебажить какой-нибудь лютый сторонний код. Когда ты видишь ошибку, понимаешь что она не в нашем коде, а в чужом фреймвоке и ты в отладчике проваливаешься на несколько десятков вызовов вглубь. И понимаешь, ага, понятно почему всё работает так, просто мы неправильно используем этот фреймвок. Или, ага, тут баг, нужно отправить им пуллреквест.
6) Знание конкретных языков и фреймвоков. С одной стороны, конечно если ты раньше использовал C# и Entiy Framework, а на проекте требуется Java и Hibernate с его безумными только запутывающими исключениями, то не получится сразу начать быстро работать, много времени будет уходить на копание во всём этом бессмысленном бреде. Но с другой стороны, я вообще не понимаю зачем на собеседованиях делать основной и единственный акцент на знании какой-то специфической хрени. Типа для JavaScript разработчика написать лапшу из промисов, setTimeout(), queueMicrotask() и спрашивать что будет. Да, инсульт ж...пы будет у любого нормального разработчика, если он увидит такое в коде!
Короче, к чему я всё это пишу. Возможно вам есть смысл ориентироваться не только на аналитиков, но на всех ИТшников. Те же вайтишники наверное не понимают почему так сложно найти работу, они же на курсах капец как прокачали 6-ой пункт, что ещё нужно. Да, блин, первые четыре пункта нужны хоть в каком-то виде. Без них человек может делать только домашки с курсов, когда тебе сначала подробно объяснили как это нужно сделать, показали примеры, и потом ты условно автозаменой превращаешь приложение для управления списком TODO в приложение со списком желаемых подарков на Новый год. Но в реальности задачи другие и даже для джуна недостаточно писать код по шаблону.
В общем это просто идея. Обычно анализ воспринимается как какая-то очень специфическая область деятельности и иногда даже недостойная для труЪ программистов. Но на мой взгляд без этого даже джуну тяжело работать, не говоря уже о росте до сеньоров, лидов, архитекторов. И в реальности эти навыки нужны всем ИТшникам.
Я думаю, что основной смысл - просто сказать всем привет, чтобы люди не забывали голос друг друга и в целом представляли кто чем занимается. Особенно если работают удаленно. Для этого не обязательно рассказывать все детали задачи. Если я услышал знакомые слова и сам занимаюсь чем-то связанным, то могу потом написать человеку и уже обсудить детали.
Ещё смысл в том, чтобы сразу выявить и решить какие-нибудь проблемы. Чтобы люди не уходили в себя на неделю. У нас очень редкие митинги, когда все просто говорят "я всё сделал, занимаюсь тестированием" - такие митинги занимают 3 минуты. Часто люди говорят о проблемах, которые на митинге достаточно быстро решаются.
Например, я всё сделал по задаче, но есть сложное и вроде не очень важное требование, на реализацию которого уйдет ещё неделя - прямо на митинге решаем завести на эту доработку отдельную задачу и сразу отправить её в бэклог с низким приоритетом. Или у меня есть какая-то проблема с задачей, а на митинге оказывается, что эта проблема уже решена другим разработчиком и сегодня он смержит свои изменения. Или я понимаю, что мне нужно перефигачить кучу кода и предупреждаю других людей, чтобы такие-то классы они пока не трогали.
За 15 или в редких случаях 30 минут всё это вполне решается. А если два человека между собой начинают обсуждать какие-то детали, которые другим десяти людям на митинге непонятны и наверное не очень интересны, то лучше сразу предложить им обсудить это отдельно и не тратить время других людей.
Если есть какая-то общая проблема с качеством кода, типовыми ошибками, которые выявляются на ревью, ... и за 15 минут это не обсудить, то можно отдельную встречу сделать.
Нет, не догадываюсь :) А вы же догадываетесь, что нашей планетой управляют рептилоиды?.. Я думаю, что уровень пассивной агрессии и аргументации в моём комментарии вполне достаточен и соответствует вашему ;) Но мне всё-таки стало интересно, решил посмотреть статистику.
1,3 млрд. в месяц - это в среднем 30 тыс. запросов в секунду. В пике наверное бывает и больше. Можно сравнить с другими проектами (источники этой статистики не самые достоверные, но я и не научно-исследовательскую работу здесь провожу):
По сравнению с Google и Яндекс, да, не очень много, но у них и инфраструктура совершенно другого порядка. Кстати, интересно через какое количество микросервисов проходит каждый поисковый запрос, на сколько сложные там распределенные транзакции...
У Авито, на сколько я понимаю, как-раз всё на микросервисах. На 5:20 прикольный момент: если вы не хотите быть маленькой компанией, видите стратегический рост, хотите быть как Авито, то делайте труЪ микросервисы. Хотя цитата конечно вырвана из контекста, и наверное спикер не имел в виду, что всем срочно нужно переходить на микросервисы, а высказывался против shared database, но тем не менее прикольный момент.
Возвращаясь к исходной теме. Да, я считаю, что 30 тыс. запросов в секунду - это достаточно много. И подавляющему большинству проектов такая нагрузка даже близко не светит. Было бы интересно увидеть проект на труЪ микросервисах с распределенными транзакциями, Сагой и этим всем, у которого нагрузка выше. Возможно Amazon, но они пишут достаточно интересные статьи:
Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%
The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.
разные части логики находятся в разных "монолитных приложениях"
У них не разные части логики запущены на разных серверах, там одинаковая логика. Просто stackoverflow самый крупный из их проектов, поэтому для него выделен отдельный сервер. Скорее всего, на втором сервере у них запущены десятки экземпляров этого же приложения (для каждого проекта - math.stackexchange.com, cs.stackexchange.com, ...). Но это всё монолиты, они особо не взаимодействуют между собой.
Например, мы делаем инструмент моделирования. Масштабируется он очень просто - для каждого заказчика или для каждого подразделения или даже для каждого большого репозитория моделей можно тупо запустить отдельный экземпляр приложения на отдельном сервере. Но это не делает архитектуру микросервисной. Обычный монолит. Одна и та же бизнес-логика просто реплицируется на множестве серверов. Вот, если дробить бизнес-логику на части: раздел моделирования, раздел анализа моделей, сервис генерации отчетов и т.д. и они как-то взаимодействуют между собой, то это уже можно назвать микросервисной архитектурой.
Более того, некоторые модули для части заказчиков не нужны. Их можно просто не включать в сборку. Т.е. разные экземпляры этого монолита могут включать разный набор модулей. А чтобы архитектура стала микросервисной нужно сделать очень простую вещь - каждый модуль должен запускаться отдельно. У нас много всего запускается отдельно - СУБД, Keycloak, Grafana и т.д., но это не модули приложения.
Иначе большинство приложений можно назвать микросервисными, практически везде есть СУБД, фронт и бэк запускаются отдельно, для аутентификации, мониторинга и т.д. тоже используются отдельные системы - но это тупо отдельные приложения с разным назначением, разрабатываемые разными компаниями.
На мой взгляд критерий микросервисной архитектуры очень простой - если данные, транзакции, пользовательские сценарии распределены по отдельно запущенным службам и чтобы всё это работало требуется координировать транзакции, то значит это микросервисы. А в stackoverflow все запросы обрабатываются одним монолитным приложением.
И вообще чем дольше я пишу этот комментарий, тем больше прихожу к тому что эта тема "монолит vs микросервисы" - просто высосанный из пальца маркетинговый булшит. Потому что не существует ни монолитов в чистом виде, ни микросервисов, в которых каждая функция запускается отдельно. У меня граница между этими двумя архитектурами проходит по наличию или отсутствию распределенных транзакций. Хотя и в монолитах они бывают.
Чел, да, я на свой 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, что удивительно близко к моей интуитивной перестраховке.
Спасибо за ссылку! Когда-то давно краем глаза видел, но я не фуллтайм фронтендер, поэтому не отложилось в памяти. При написании кода это клево, но читать тяжело. Особенно если на проекте много людей которые только иногда заглядывают во фронт. Я имел в виду такие сокращения https://mui.com/system/getting-started/the-sx-prop/#spacing типа pt (который есть в Emmet), my (которого нет в Emmet), ... А потом MUI перейдёт на StyleX и опять переделывать все стили...
Мне привычнее и проще это сделать в браузере. Для меня один из больших плюсов веб-разработки в том, что она практически ничего не требует кроме браузера и любого текстового редактора. Очень легко и просто делается минимальный пример, прямо в браузере можно его поправить, сразу виден результат. Для реальных проектов, наверное, да, без сложного тулинга не обойтись, но иногда ощущение что люди искусственно делают простые вещи сложными. А потом в какой-то момент начинают писать статьи, что мы тут подумали и решили отказаться от TypeScript. Я не удивлюсь если через какое-то время фб откажется от StyleX в пользу обычного CSS.
Обычные переменные в CSS да, но когда всё это замешивается с JavaScript-кодом, то люди начинают там реализовывать просто лютейшую логику с кучей функций разбросанных по всему проекту. А в CSS у них такой возможности нет, приходится напрягать мозг, чтобы описать стили проще. Если в CSS-in-JS писать простые стили с простыми переменными без JavaScript-кода наверное это норм, но чем это лучше обычного CSS с переменными?..
Для меня минусы этой штуки и вообще CSS-in-JS вполне понятны:
Вместо понятного и распространенного CSS добавляется лишняя абстракция. Нужно дополнительно напрягать мозг при написании и чтении стилей. И глядя на какой-нибудь `p: 10` пытаться понять что это значит. Не знаю есть ли конкретно в StyleX такие сокращения, но зачем мне изучать ещё один язык, если я уже знаю CSS?
Изредка хочется использовать относительно сложные селекторы. В StyleX они видимо вообще не поддерживаются?
Информации по CSS просто на много-много порядков больше, чем по очередному CSS-in-JS. Когда находишь какой-нибудь CSS-рецепт каждый раз нужно его транслировать в StyleX или наоборот если у тебя проблемы со стилями, то чтобы задать вопрос их нужно сначала перевести на CSS.
Нельзя за 2 минуты создать HTML+CSS файлик в "блокноте" и по-быстрому отладить стили в браузере. Или поправить стиль в браузере и скопировать обратно
Это неизбежно приведет к появлению сложной логики в стилях - всякие переменные, вызовы функций так что в этих стилях потом сложно что-то понять
Эти фреймвоки бесконечно меняются и запаришься каждый раз мигрировать стили
Генерятся классы с рандомными названиями - их нельзя использовать для какой-нибудь логики на JS, для тестов
В чем вообще смысл всё запихивать в один большой файл? С двумя маленькими файлами проще работать чем с одним большим
Пытаюсь понять плюсы:
Возможно лет 15 назад, когда было много разных браузеров, CSS в них работал по-разному и вообще был очень ограниченный, был какой-то смысл в этих абстракциях, но сейчас зачем это
Решение проблем с наложением стилей, специфичностью. У меня обычно этих проблем не возникает, я просто придерживаюсь единой схемы описания стилей. Но ещё есть же всякие CSS layer, scope, shadow DOM. Они не решают эту проблему?
Людям сложно изучить CSS, а JS они уже знают. Непонятно что StyleX здесь упрощает, CSS всё равно придётся изучить, плюс добавится сложностей по постоянной трансляции стилей между CSS и StyleX в уме
Уменьшение суммарного размера CSS, ускорение загрузки и отрисовки за счет удаления неиспользуемых стилей при сборке, за счет динамической подгрузки стилей. Я в принципе не понимаю как можно написать стилей на десятки мегабайт, но для проекта масштаба фб наверное это возможно... Вообще конечно было бы интересно посмотреть что это за стили, почему их так много
Поддержка стилей не только в браузере, но и в нативных приложениях. В какой доле проектов это требуется?
В общем, к каким проблемам приведет StyleX я понимаю совершенно отчетливо, а преимущества как-то вообще не очевидны.
Мне эта тема очень близка. Я сам работал разработчиком, потом аналитиком, сейчас архитектором, техлидом (по факту одновременно и разработчиком, и аналитиком). На мой взгляд аналитические навыки важны для любого ИТшника. Лично у меня такой топ навыков:
1) Аналитический склад ума - это буквально способность раскладывать сложную задачу на более простые. Это полезно не только для аналитиков, но и для разработчиков, тестировщиков, РП. Например, мне как разработчику нужно реализовать что-то очень сложное. Прежде чем браться за это мне нужно разложить задачу на понятные шаги, выделить какие-то крупные модули будущего приложения. Или, например, есть несколько вариантов реализации задачи, человек с аналитическими навыками достаточно легко перечислит эти варианты, определит критерии для их сравнения и выберет оптимальный вариант. Такой выбор часто встаёт не только перед аналитиками, но и перед разработчиками.
2) Понимание процесса разработки в целом. Какая бы специализация у человека ни была, очень хорошо если он понимает через какие этапы проходит задача:
а) бизнес-анализ - когда задача максимально размыта, непонятно что делать и нужно преимущество собирать информацию, заниматься НИР
б) системный анализ - когда описывается уже конкретное техническое решение (сценарии использования, пользовательские истории, верхнеуровневые подсистемы, их взаимодействие, схема данных, бизнес правила, макеты интерфейсов)
в) разработка
г) тестирование
д) демонстрация заказчику, сдача в эксплуатацию
Например, для разработчиков важно понимать какие этапы задача должна была пройти до того как попала к ним. Если она недостаточно проработана с точки зрения аналитики, то можно не тупо реализовывать как написано, а пойти обсудить спорные вещи с аналитиками. Или если аналитиков на проекте нет, то самому написать и согласовать какой-нибудь минимальный дизайн-документ. Или предупредить заказчика, что реализация может быть не такой как он ожидает или что сроки неопределенные. Также полезно понимать какие этапы будут после того как ты реализовал свою задачу. Можно заранее поставить себя на место тестировщика или пользователя и прикинуть на сколько удобная и понятная получилась реализация. Что человеку будет удобнее - нажать десять кнопок или одну.
Это не значит что каждый ИТшник должен быть человек-оркестром и один выполнять работу за всех, но у него должно быть хотя бы общее представление о всём процессе, чтобы он не упарывался только в код, в документы, в тесты, в сроки. А в случае проблем (которые обычно возникают достаточно часто) он мог пойти к своим коллегам и решить спорные моменты.
3) Затем идёт основной навык специалиста.
Для разработчиков - это безусловно умение описывать и реализовывать алгоритмы. Конечно далеко не на всех проектах требуются сложные алгоритмы. Но, блин, даже в самых простых задачах условно "по перекладыванию JSONов" я часто вижу какой-нибудь поиск по массиву с квадратичной сложностью, какой-то безумный код, в котором просто невозможно ничего понять. Хотя бы базовое знание структур данных, алгоритмов нужно. Но заметьте, что я поставил это на третье место!
Для аналитиков - это умение собирать и обобщать информацию, в сжатом и понятном виде (текстом или голосом) доносить её до остальных участников проекта. Если аналитику приходится что-то объяснять, спорить, предлагать посмотреть ещё какие-то варианты и т.д., то работать тяжело - на мой взгляд это аналитик должен максимально быстро и легко воспринимать любую информацию и складывать её в соответствующую коробочку. Лично я ожидаю от аналитика что-то типа: да, я понимаю о чём ты говоришь, я об этом уже подумал, но это частный случай такой-то ситуации, мы его сможем реализовать потом. А если аналитик наоборот всё усложняет, находит какой-нибудь специфический сценарий, который в реальности не нужен, и выстраивает всё вокруг него, то тяжело.
Для тестировщиков и РП мне лень писать. Иначе этот комментарий рискует превратиться в монографию. Хотя, блин, я не могу удержаться, знания переполняют меня, я на столько преисполнился понимаем этого мира, что просто не могу не поделиться своей мудростью (и наверное во многом болью) с человечеством (по крайней мере с той его частью, которая читает хабр).
Для тестировщиков наверное важно находить неожиданные сценарии, о которых не подумали ни аналитики, ни разработчики. И с минимальным количеством тестов и усилий проверять максимум функциональности.
Для РП на мой взгляд важно фокусироваться на приоритетах и сроках. Я считаю, что любая задача должна оцениваться по двум простым критериям: важность и сложность. В первую очередь делаются важные и простые задачи. Всё остальное делается потом. Я часто сталкивался с ситуациями когда в первую очередь по какой-то неведомой причине делаются самые ненужные и сложные задачи, а под конец в панике и срочно-срочно начинают делаться важные задачи и хорошо если простые, тогда есть шанс успеть хоть что-то. Хотя на мой взгляд этот навык важен не только для РП, но и для всех ИТшников.
Да, на самом деле, все эти навыки важны для всех ИТшников, просто каждый специализируется в первую очередь на своём.
4) Общие технические знания. Мне лень подробно на этом останавливаться. Но для всех не лишне иметь какое-то представление о базах данных и нормализации данных, о форматах данных (чтобы отличать XML от JSON), о протоколах передачи данных, многослойной архитектуре, API и т.д.
5) Специфические навыки, которые появляются с годами задрачивания чего-нибудь. Например, умение дебажить какой-нибудь лютый сторонний код. Когда ты видишь ошибку, понимаешь что она не в нашем коде, а в чужом фреймвоке и ты в отладчике проваливаешься на несколько десятков вызовов вглубь. И понимаешь, ага, понятно почему всё работает так, просто мы неправильно используем этот фреймвок. Или, ага, тут баг, нужно отправить им пуллреквест.
6) Знание конкретных языков и фреймвоков. С одной стороны, конечно если ты раньше использовал C# и Entiy Framework, а на проекте требуется Java и Hibernate с его безумными только запутывающими исключениями, то не получится сразу начать быстро работать, много времени будет уходить на копание во всём этом бессмысленном бреде. Но с другой стороны, я вообще не понимаю зачем на собеседованиях делать основной и единственный акцент на знании какой-то специфической хрени. Типа для JavaScript разработчика написать лапшу из промисов, setTimeout(), queueMicrotask() и спрашивать что будет. Да, инсульт ж...пы будет у любого нормального разработчика, если он увидит такое в коде!
Короче, к чему я всё это пишу. Возможно вам есть смысл ориентироваться не только на аналитиков, но на всех ИТшников. Те же вайтишники наверное не понимают почему так сложно найти работу, они же на курсах капец как прокачали 6-ой пункт, что ещё нужно. Да, блин, первые четыре пункта нужны хоть в каком-то виде. Без них человек может делать только домашки с курсов, когда тебе сначала подробно объяснили как это нужно сделать, показали примеры, и потом ты условно автозаменой превращаешь приложение для управления списком TODO в приложение со списком желаемых подарков на Новый год. Но в реальности задачи другие и даже для джуна недостаточно писать код по шаблону.
В общем это просто идея. Обычно анализ воспринимается как какая-то очень специфическая область деятельности и иногда даже недостойная для труЪ программистов. Но на мой взгляд без этого даже джуну тяжело работать, не говоря уже о росте до сеньоров, лидов, архитекторов. И в реальности эти навыки нужны всем ИТшникам.
Я думаю, что основной смысл - просто сказать всем привет, чтобы люди не забывали голос друг друга и в целом представляли кто чем занимается. Особенно если работают удаленно. Для этого не обязательно рассказывать все детали задачи. Если я услышал знакомые слова и сам занимаюсь чем-то связанным, то могу потом написать человеку и уже обсудить детали.
Ещё смысл в том, чтобы сразу выявить и решить какие-нибудь проблемы. Чтобы люди не уходили в себя на неделю. У нас очень редкие митинги, когда все просто говорят "я всё сделал, занимаюсь тестированием" - такие митинги занимают 3 минуты. Часто люди говорят о проблемах, которые на митинге достаточно быстро решаются.
Например, я всё сделал по задаче, но есть сложное и вроде не очень важное требование, на реализацию которого уйдет ещё неделя - прямо на митинге решаем завести на эту доработку отдельную задачу и сразу отправить её в бэклог с низким приоритетом. Или у меня есть какая-то проблема с задачей, а на митинге оказывается, что эта проблема уже решена другим разработчиком и сегодня он смержит свои изменения. Или я понимаю, что мне нужно перефигачить кучу кода и предупреждаю других людей, чтобы такие-то классы они пока не трогали.
За 15 или в редких случаях 30 минут всё это вполне решается. А если два человека между собой начинают обсуждать какие-то детали, которые другим десяти людям на митинге непонятны и наверное не очень интересны, то лучше сразу предложить им обсудить это отдельно и не тратить время других людей.
Если есть какая-то общая проблема с качеством кода, типовыми ошибками, которые выявляются на ревью, ... и за 15 минут это не обсудить, то можно отдельную встречу сделать.
Нет, не догадываюсь :) А вы же догадываетесь, что нашей планетой управляют рептилоиды?.. Я думаю, что уровень пассивной агрессии и аргументации в моём комментарии вполне достаточен и соответствует вашему ;) Но мне всё-таки стало интересно, решил посмотреть статистику.
1,3 млрд. в месяц - это в среднем 30 тыс. запросов в секунду. В пике наверное бывает и больше. Можно сравнить с другими проектами (источники этой статистики не самые достоверные, но я и не научно-исследовательскую работу здесь провожу):
Google - 8,5 млрд. запросов в сутки или 6 млн. запросов в секунду
Яндекс - 1,6 млрд. запросов в сутки или 1 млн. запросов в секунду
Авито - 384 млн. наверное всё-таки просмотров, а не пользователей в месяц или 9 тыс. запросов в секунду
По сравнению с Google и Яндекс, да, не очень много, но у них и инфраструктура совершенно другого порядка. Кстати, интересно через какое количество микросервисов проходит каждый поисковый запрос, на сколько сложные там распределенные транзакции...
У Авито, на сколько я понимаю, как-раз всё на микросервисах. На 5:20 прикольный момент: если вы не хотите быть маленькой компанией, видите стратегический рост, хотите быть как Авито, то делайте труЪ микросервисы. Хотя цитата конечно вырвана из контекста, и наверное спикер не имел в виду, что всем срочно нужно переходить на микросервисы, а высказывался против shared database, но тем не менее прикольный момент.
Возвращаясь к исходной теме. Да, я считаю, что 30 тыс. запросов в секунду - это достаточно много. И подавляющему большинству проектов такая нагрузка даже близко не светит. Было бы интересно увидеть проект на труЪ микросервисах с распределенными транзакциями, Сагой и этим всем, у которого нагрузка выше. Возможно Amazon, но они пишут достаточно интересные статьи:
У них не разные части логики запущены на разных серверах, там одинаковая логика. Просто stackoverflow самый крупный из их проектов, поэтому для него выделен отдельный сервер. Скорее всего, на втором сервере у них запущены десятки экземпляров этого же приложения (для каждого проекта - math.stackexchange.com, cs.stackexchange.com, ...). Но это всё монолиты, они особо не взаимодействуют между собой.
Например, мы делаем инструмент моделирования. Масштабируется он очень просто - для каждого заказчика или для каждого подразделения или даже для каждого большого репозитория моделей можно тупо запустить отдельный экземпляр приложения на отдельном сервере. Но это не делает архитектуру микросервисной. Обычный монолит. Одна и та же бизнес-логика просто реплицируется на множестве серверов. Вот, если дробить бизнес-логику на части: раздел моделирования, раздел анализа моделей, сервис генерации отчетов и т.д. и они как-то взаимодействуют между собой, то это уже можно назвать микросервисной архитектурой.
Более того, некоторые модули для части заказчиков не нужны. Их можно просто не включать в сборку. Т.е. разные экземпляры этого монолита могут включать разный набор модулей. А чтобы архитектура стала микросервисной нужно сделать очень простую вещь - каждый модуль должен запускаться отдельно. У нас много всего запускается отдельно - СУБД, Keycloak, Grafana и т.д., но это не модули приложения.
Иначе большинство приложений можно назвать микросервисными, практически везде есть СУБД, фронт и бэк запускаются отдельно, для аутентификации, мониторинга и т.д. тоже используются отдельные системы - но это тупо отдельные приложения с разным назначением, разрабатываемые разными компаниями.
На мой взгляд критерий микросервисной архитектуры очень простой - если данные, транзакции, пользовательские сценарии распределены по отдельно запущенным службам и чтобы всё это работало требуется координировать транзакции, то значит это микросервисы. А в stackoverflow все запросы обрабатываются одним монолитным приложением.
И вообще чем дольше я пишу этот комментарий, тем больше прихожу к тому что эта тема "монолит vs микросервисы" - просто высосанный из пальца маркетинговый булшит. Потому что не существует ни монолитов в чистом виде, ни микросервисов, в которых каждая функция запускается отдельно. У меня граница между этими двумя архитектурами проходит по наличию или отсутствию распределенных транзакций. Хотя и в монолитах они бывают.