По США, сужу по количеству "входящих" в мой ящик от рекрутеров на Линкеде. Пандемия была горячей, всем нужны были люди. 2-3 заявки в день. В конце 2022-го наступил мертвый сезон -- 1 заявка в неделю. Сейчас началось оживление снова, хотя сам процесс с работодателями идет медленно. Но тенденция к перелому заметна.
Паззлы, квизы и прочие олимпиадные задачки на собеседованиях имеют смысл (при определенных условиях!), потому что есть положительная корреляция между умением решать такие задачки и общими программистскими навыками. И такая система удобна всем: и кандидату, так как можно просто потренироваться (все такие задачки -- однотипные и в них быстро можно увидеть систему), и интервьюеру, так как можно просто дать человеку задачу и наблюдать за её решением. И хайринг-менеджеру, так как понятны критерии, по которым интервьюер потом выдает рекомендацию. Они так же хорошо сочетаются с "повесточкой", так как минимизируют риски обвинения в той или иной форме предвзятости.
"Поговорить с кандидатом о его опыте" (как альтернатива "квизам") -- звучит хорошо, но не масштабируется, так как предполагает наличие у интервьюера нетривиальных психологических навыков и хорошей интуиции. И тут тоже легко обмануть систему, так как вопросы тут тоже задают типовые и под них можно подготовить типовые ответы.
По моему опыту, лучшем критерием оценки является опыт работы, отраженный в резюме, предполагая, что каких-то особых и редких навыков не потребуется. Поэтому, всё, что нужно проверить -- это то, что кандидат не "врет" в своем резюме. Компании врут о реальных задачах, которые будут решать программисты, а программисты врут своем реальном полученном опыте за тот или иной ременной промежуток. У нас тут это взаимное, да)
В остальном, найм в IT "почти слепой" и связано это с тем, что сейчас у большинства программистов квалификация избыточная для той работы, которую они реально делают. Поэтому надо создать искусственные проблемы, чтобы смена быстро надоевшей работы не казалась таким уж простым делом. Программист должен изрядно побегать и пострадать за новую работу. Работа, которая легко достается, не ценится. Всем удачи в поисках! Джунам -- терпения и всё будет хорошо!
Junior/Middle/Senior -- это градации профессиональной зрелости, которые не имеют прямого отношения к конкретным скиллам.
Junior требует постоянного наблюдения со стороны старших коллег. В идеале Junior работает строго по тикетам в багтрекере. Больше от него ничего не надо.
Senior -- полностью самостоятельный разработчик, который может проанализировать задачу, составить требования, разбить на этапы, выполнить и сдать. Он так же умеет говорить с заказчиком. Любой senior потенциально может быть техлидом, так как это просто роль в команде.
Middle -- это что-то по середине между. Главное отличие от Senior в том, что Middle всё еще требует супервайзинга со стороны техлида. Но не так плотно, как Junior.
Если брать конкретного Васю, то в одном месте Вася может быть и сеньером, а в другом даже на джуна не потянет. И наоборот. Т.е. эти градации зависят от места работы, сложности используемых технологий и процессов разработки, темпа работы.
Так что когда миддла зовут на позицию сеньера -- это нормально. Над просто смотреть, готов ли ты быть техлидом именно на этом конкретном рабочем месте. Если да, то ты там -- senior level.
Я тут noname, но выскажусь. Эдуард, может быть, неправ по форме (всё — гавно, один я в белом), но прав по существу. Дело в том, что всё, что связано с надежным хранением состояния (будь-то файлы, базы данных или просто NVRAM), не может разрабатываться так, как разрабатывается код, который эти данные в полете обрабатывает. Специалисты по хранению данных обязаны быть параноиками надежности «на долгие времена» и устойчивости «в худшем случае», так как хранение данных — это mission critical. Можете считать это всё профессиональными деформациями. И если такие люди выдавливаются из сообщества по причине их «эмоциональной токсичности» (ну неудобны они в общении, да), то у меня для такого сообщества плохие новости. Да, с такими людьми трудно, да, они друг друга любыт еще меньше, чем окружающие — их. Но те, кто решаться делать их работу и станут параноиками надежности — получат те же профессиональные деформации.
Эдуарду — успехов с его проектом и пожелания перерасти уже формат файловых систем. Он своё уже отжил.
Как поциент-поциенту. С++ тебя не отпустит, бежать куда-то с него бесполезно. Он тебя везде найдет. Всё, что ты можешь сделать — это создать «лучший С++», победив тем самым его в самом себе. Примерно так. Извини, что «на ты». На брудершафт не пили, знаю.
SDS-ки обычно придумываются под «плоскую» модель памяти с равномерным произвольным доступом. Наличие иерархии памяти и асмииетрии в паттернах доступа сильно меняет пространство оптимальных дизайнов (cache-conscious, cache-oblivious и т.п.). Итоговая оптимальная раскладка данных по памяти может сильно отличаться от того, что в пейперах предлагают, а теоретическая O(log N) внезапно стать эффективнее теоретической O(1).
Причина, по которой вщаимно-обратные rank/select определены не совсем «симметрично», в том, что так навигационные выражения, например, для LOUDS получаются короче. SDS десятилетиями оставались чисто теоретическим упражнением для ума, где оптимизировалась красота ассимптотических оценок в научных статьях.
SDS сложны в инжиниринге и требуют сложной операционной «обвязки». Обычно они статические. Хочешь что-то обновить — пересоздавай всё заново, что для больших структур неудобно. Динамические SDS возможны, некоторые, но они имеют гораздо худшее время произвольного чтения: O(log N) против O(1), что на практике может означать «на порядок и хуже». Ну и они на порядок-три сложнее в инжиниринге, чем их статические аналоги. Всё это пока что делает SDS непрактичными за пределами нескольких узких ниш, где без них ну просто никуда (например, биоинформатика). Затраты на разработку будут огромными, а выигрыш с экономической точки зрения — сомнительным. Проще старыми добрыми b-/lsm-tree всё делать.
SDS хороши как индексы и self-индексы. Они могут ускорять выполнение некоторых операций. Хрестоматийный уже пример — суффиксные деревья для полнотекстового поиска по геному, сжатые графы социальных сетей, web-графы. Из более экзотических (пока) применений — кодирование распределений вероятностей. А то вероятностные алгоритмы есть, а вот вероятностными структурами данных, образно говоря, не намазано. Из еще более экзотических применений — «выжимки» структрированной информации из нейронных сетей. Да сколько угодно применений, когда в голове есть тервер и теория алгоритмов (а не только тервер и линейка). Потому что «струтктура данных» — это просто кодирование некоторого многомерного распределения в машинных кодах.
Более жизненный пример. С помощью searchable sequence можно накладывать некую структуру (например, иерархическую) на неструктурированные массивы. Например, с помощью сжатой битовой карты с поддержкой rank/select можно допольно просто отобразить табилицу-построчник на сырой байтовый массив, с возможностью произвольной навигации по с строкам (привет, удобная постраничная прокрутка). SDS можно использовать как строительные кубики для создания практических решений с необходимимы свойствами.
Высокая инженерная сложность не является фундаментальным препятствием. Со временем, компактные (compact), безизбыточные (succinct) и сжатые (compressed) структуры данных займут свое достойное место в инструментарии практикующих программистов.
Не увидел в комментариях. В сборке JDK9+ добавили флаг
--disable-warnings-as-errors
Который делает именно это: не включает режим «предупреждения-как-ошибки».
Ну а в целом — да. Продвинутые джава-программисты в будущем станут еще и С++-программистами. Graal, Panama и всё вокруг будет приятно располагать. Нет, С++ сейчас совсем не такой страшный, каким был во времена создания Java. Это будет просто новый уровень погружения в технологию, который многие захотят пройти.
Решил таки оставить свои 2 копейки по такой животрепещущей теме.
Программировать с файберами не проще, чем с тредами. Файберы сильно упрощают асинхронный код, выполненный в стиле Continuation Passing (CPS), который неудобен во всем, кроме одного. Неудобен потому, что выворачивает наизнанку поток управления. И у него нет стека, из-за чего разбор всяких рекурсивных структур становится не то, чтобы совсем уже проблематичным (можно использовать явный стек), но сильно неудобным. И, что самое плохое, что метод инвазивный: весь код, который так или иначе делает ввод-вывод, должен быть написан в стиле CPS. Т.е. всё.
Файберы именно эту проблему снимают. Линейность, рекурсия, циклы, ветвления при вводе-выводе становятся именно тем, чем мы привыкли их себе представлять. Самое главное, что унаследованный код в такую среду портируется либо автоматически, либо с минорными изменениями.
Однако, при программировании с файберами появляется в явном виде передача управления планировщику, которую теперь надо продумывать. Планировщик теперь должен управлять «миллионами» файберов, что само по себе может оказаться вычислительно-емким. Да, теперь файбер не может быть остановлен в любом произвольном месте, а только на явном или неявном вводе-выводе или yield()-е. Т.е. в общем случае проблема реентерабельности объектов остается. Просто становится меньше точек реентерабельности. Как итог, файберы тоже нужно взаимно координировать, как и треды: блокировочки, семафорчики и всё такое.
Самое главное, что для чего файберы нужны — это перенос планировщика ввода-вывода из ядра OS в приложение. Т.е. приложение может иметь свой планировщик, заточенный под задачу. Интересно это только для IO-интенсивных задач, таких как нагруженные хранилища и базы данных. Потому что статистически идея файбера очень проста: поскольку ввод-вывод очень высоколатентный, то мы дробим его на отдельные мелкие волокна. И в каждый момент времени выполняется то волокно, для которого сейчас есть данные. Самый простой пример — веб-сессии. Они все независимы, низкоинтенсивны и их очень много. Тратить по треду на сессию — это очень расточительно. С диском вводом-выводом всё сложнее, но для больших RAID-массивов SSD ситуация будет точно такой же, как и с сетевым трафиком: нужно параллелить ввод-вывод.
Файбер от корутины (coroutine) отличается только API и, возможно, накладными расходами реализации. Корутины обычно явно передают управление от одной к другой, как подпрограммы. Но это не обязательно.
Файбер же — это корутина, которая реализует API треда.
Стек нативного треда — это 1 MB адресного пространства, а не физической памяти. Память под стек выделяется динамически по мере необходимости. Проблема была на 32-битных архитектурах, где адресное пространство быстро заканчивалось. На 64-битных архитектурах всё не так печально. Однако, у файбера тоже есть стек, и он тоже жрет адресное пространство. Примечание: в Project Loom они хотят пойти по какому-то особому пути, на котором собираются эту проблему обойти.
С другой стороны, большой стек — это антипаттерн. На тех задачах ввода-вывода, где возможна глубокая рекурсия (регулярные выражения, например) нужно использовать соответствующие явные структуры данных. RE2, например, или ICU4C не используют системный стек. В общем, 64K на стек — этого достаточно. 1M файберов сожрет «всего» 64G адресного пространства (не памяти!). Памяти они сожрут под стеки всего лишь 4G, что не так уж много там, где действительно нужен миллион файберов.
В общем, файберы — это хорошо и нужно. Пожелаем Рон Пресслеру удачи и скорейшего релиза!.. Его Квазар был хорош, нустр, но весьма костылен. Появятся файберы, появятся и задачи под них.
По США, сужу по количеству "входящих" в мой ящик от рекрутеров на Линкеде. Пандемия была горячей, всем нужны были люди. 2-3 заявки в день. В конце 2022-го наступил мертвый сезон -- 1 заявка в неделю. Сейчас началось оживление снова, хотя сам процесс с работодателями идет медленно. Но тенденция к перелому заметна.
Выскажусь в поддержку "системы".
Паззлы, квизы и прочие олимпиадные задачки на собеседованиях имеют смысл (при определенных условиях!), потому что есть положительная корреляция между умением решать такие задачки и общими программистскими навыками. И такая система удобна всем: и кандидату, так как можно просто потренироваться (все такие задачки -- однотипные и в них быстро можно увидеть систему), и интервьюеру, так как можно просто дать человеку задачу и наблюдать за её решением. И хайринг-менеджеру, так как понятны критерии, по которым интервьюер потом выдает рекомендацию. Они так же хорошо сочетаются с "повесточкой", так как минимизируют риски обвинения в той или иной форме предвзятости.
"Поговорить с кандидатом о его опыте" (как альтернатива "квизам") -- звучит хорошо, но не масштабируется, так как предполагает наличие у интервьюера нетривиальных психологических навыков и хорошей интуиции. И тут тоже легко обмануть систему, так как вопросы тут тоже задают типовые и под них можно подготовить типовые ответы.
По моему опыту, лучшем критерием оценки является опыт работы, отраженный в резюме, предполагая, что каких-то особых и редких навыков не потребуется. Поэтому, всё, что нужно проверить -- это то, что кандидат не "врет" в своем резюме. Компании врут о реальных задачах, которые будут решать программисты, а программисты врут своем реальном полученном опыте за тот или иной ременной промежуток. У нас тут это взаимное, да)
В остальном, найм в IT "почти слепой" и связано это с тем, что сейчас у большинства программистов квалификация избыточная для той работы, которую они реально делают. Поэтому надо создать искусственные проблемы, чтобы смена быстро надоевшей работы не казалась таким уж простым делом. Программист должен изрядно побегать и пострадать за новую работу. Работа, которая легко достается, не ценится. Всем удачи в поисках! Джунам -- терпения и всё будет хорошо!
Junior/Middle/Senior -- это градации профессиональной зрелости, которые не имеют прямого отношения к конкретным скиллам.
Junior требует постоянного наблюдения со стороны старших коллег. В идеале Junior работает строго по тикетам в багтрекере. Больше от него ничего не надо.
Senior -- полностью самостоятельный разработчик, который может проанализировать задачу, составить требования, разбить на этапы, выполнить и сдать. Он так же умеет говорить с заказчиком. Любой senior потенциально может быть техлидом, так как это просто роль в команде.
Middle -- это что-то по середине между. Главное отличие от Senior в том, что Middle всё еще требует супервайзинга со стороны техлида. Но не так плотно, как Junior.
Если брать конкретного Васю, то в одном месте Вася может быть и сеньером, а в другом даже на джуна не потянет. И наоборот. Т.е. эти градации зависят от места работы, сложности используемых технологий и процессов разработки, темпа работы.
Так что когда миддла зовут на позицию сеньера -- это нормально. Над просто смотреть, готов ли ты быть техлидом именно на этом конкретном рабочем месте. Если да, то ты там -- senior level.
Сразу видно, что ты не дата-сайнтист. Пост барышни, на самом деле, со скрытым (или не очень) мессаджем, который ТруЪ дата-сайнтисты должны распарсить.
Эдуарду — успехов с его проектом и пожелания перерасти уже формат файловых систем. Он своё уже отжил.
SDS хороши как индексы и self-индексы. Они могут ускорять выполнение некоторых операций. Хрестоматийный уже пример — суффиксные деревья для полнотекстового поиска по геному, сжатые графы социальных сетей, web-графы. Из более экзотических (пока) применений — кодирование распределений вероятностей. А то вероятностные алгоритмы есть, а вот вероятностными структурами данных, образно говоря, не намазано. Из еще более экзотических применений — «выжимки» структрированной информации из нейронных сетей. Да сколько угодно применений, когда в голове есть тервер и теория алгоритмов (а не только тервер и линейка). Потому что «струтктура данных» — это просто кодирование некоторого многомерного распределения в машинных кодах.
Более жизненный пример. С помощью searchable sequence можно накладывать некую структуру (например, иерархическую) на неструктурированные массивы. Например, с помощью сжатой битовой карты с поддержкой rank/select можно допольно просто отобразить табилицу-построчник на сырой байтовый массив, с возможностью произвольной навигации по с строкам (привет, удобная постраничная прокрутка). SDS можно использовать как строительные кубики для создания практических решений с необходимимы свойствами.
Высокая инженерная сложность не является фундаментальным препятствием. Со временем, компактные (compact), безизбыточные (succinct) и сжатые (compressed) структуры данных займут свое достойное место в инструментарии практикующих программистов.
--disable-warnings-as-errors
Который делает именно это: не включает режим «предупреждения-как-ошибки».
Ну а в целом — да. Продвинутые джава-программисты в будущем станут еще и С++-программистами. Graal, Panama и всё вокруг будет приятно располагать. Нет, С++ сейчас совсем не такой страшный, каким был во времена создания Java. Это будет просто новый уровень погружения в технологию, который многие захотят пройти.
Программировать с файберами не проще, чем с тредами. Файберы сильно упрощают асинхронный код, выполненный в стиле Continuation Passing (CPS), который неудобен во всем, кроме одного. Неудобен потому, что выворачивает наизнанку поток управления. И у него нет стека, из-за чего разбор всяких рекурсивных структур становится не то, чтобы совсем уже проблематичным (можно использовать явный стек), но сильно неудобным. И, что самое плохое, что метод инвазивный: весь код, который так или иначе делает ввод-вывод, должен быть написан в стиле CPS. Т.е. всё.
Файберы именно эту проблему снимают. Линейность, рекурсия, циклы, ветвления при вводе-выводе становятся именно тем, чем мы привыкли их себе представлять. Самое главное, что унаследованный код в такую среду портируется либо автоматически, либо с минорными изменениями.
Однако, при программировании с файберами появляется в явном виде передача управления планировщику, которую теперь надо продумывать. Планировщик теперь должен управлять «миллионами» файберов, что само по себе может оказаться вычислительно-емким. Да, теперь файбер не может быть остановлен в любом произвольном месте, а только на явном или неявном вводе-выводе или yield()-е. Т.е. в общем случае проблема реентерабельности объектов остается. Просто становится меньше точек реентерабельности. Как итог, файберы тоже нужно взаимно координировать, как и треды: блокировочки, семафорчики и всё такое.
Самое главное, что для чего файберы нужны — это перенос планировщика ввода-вывода из ядра OS в приложение. Т.е. приложение может иметь свой планировщик, заточенный под задачу. Интересно это только для IO-интенсивных задач, таких как нагруженные хранилища и базы данных. Потому что статистически идея файбера очень проста: поскольку ввод-вывод очень высоколатентный, то мы дробим его на отдельные мелкие волокна. И в каждый момент времени выполняется то волокно, для которого сейчас есть данные. Самый простой пример — веб-сессии. Они все независимы, низкоинтенсивны и их очень много. Тратить по треду на сессию — это очень расточительно. С диском вводом-выводом всё сложнее, но для больших RAID-массивов SSD ситуация будет точно такой же, как и с сетевым трафиком: нужно параллелить ввод-вывод.
Файбер от корутины (coroutine) отличается только API и, возможно, накладными расходами реализации. Корутины обычно явно передают управление от одной к другой, как подпрограммы. Но это не обязательно.
Файбер же — это корутина, которая реализует API треда.
Стек нативного треда — это 1 MB адресного пространства, а не физической памяти. Память под стек выделяется динамически по мере необходимости. Проблема была на 32-битных архитектурах, где адресное пространство быстро заканчивалось. На 64-битных архитектурах всё не так печально. Однако, у файбера тоже есть стек, и он тоже жрет адресное пространство. Примечание: в Project Loom они хотят пойти по какому-то особому пути, на котором собираются эту проблему обойти.
С другой стороны, большой стек — это антипаттерн. На тех задачах ввода-вывода, где возможна глубокая рекурсия (регулярные выражения, например) нужно использовать соответствующие явные структуры данных. RE2, например, или ICU4C не используют системный стек. В общем, 64K на стек — этого достаточно. 1M файберов сожрет «всего» 64G адресного пространства (не памяти!). Памяти они сожрут под стеки всего лишь 4G, что не так уж много там, где действительно нужен миллион файберов.
В общем, файберы — это хорошо и нужно. Пожелаем Рон Пресслеру удачи и скорейшего релиза!.. Его Квазар был хорош, нустр, но весьма костылен. Появятся файберы, появятся и задачи под них.