Да забудьте вообще про эти градации. Главное польза приносимая продукту, и каждый как умеет, так и вкладывает свои усилия и навыки. Кто-то лучше, кто-то хуже в силу отсутствия опыта. Вот и вся формула.
Я видел проекты где "мидлы" лидили проект, и наоборот, где лиды работали на позиции разработчика, и всё было нормально.
Важна не градация, а средний уровень разработчиков и как они работают в команде. Опыт дело поправимое, важны сами люди, и как они работают. У нас есть ребята которые были стажеры, но быстро учатся и местами за ними не успеваешь, шустрые пацаны, за пару лет так натаскались что уже знают такие штуки, про которые старики уже не знают.
Поэтому, люди... Важны именно люди, как они работают, их подход, а опыт дело приходящее.
Мне лично нравится пример разговора через Авито, когда звонишь, спрашиваешь что как почем, и тебе открыто говорят сколько стоят работы, как работают, всё рассказывают. Мол Вася, экскаватор есть, свободны завтра, стоит столько, доедем куда надо, но техника хреновая, поэтому рвать особо не будем, выбирайте сами, звоните.
Когда дело про найм в IT, это тайны и муть сплошная. Зарплаты не озвучивают, на людей не выводят, информации про проекты почти нету, примеров нет, и этот список можно долго продолжать. Я помню звонишь, даже название проекта не хотят говорить. Дичь вобщем.)
Просто пишите вакансии для людей, рассказывайте. Чем проще, точнее, и ближе к людям, тем лучше.
Нужен программист, пишем на TS, используем React и такие-то библиотеки, проект такой то, посмотреть можно там то, платим столько, мы есть на Github смотрите код, плюшки такие, команда большая, там те то и те то, нужен новый человек потому что растем, тестирования нет но стараемся, всё что не рассказали спрашивайте, расскажем. Не дословно, понятно что написать нормально, правильно подать, формулировки более формальные, но посыл именно такой, должна быть информация.
Есть целое море причин почему нужно использовать библиотеки и фреймворки на коммерческих проектах: скорость найма кадров, порог входа в проект, обучение и обмен опытом, скорость разработки, качество решений, наличие документации, наличие огромного количество собранных граблей решенных вопросов на SO, и прочее, и прочее.
Как сказали выше, если проект из серии написать и больше не трогать, то можно сделать как угодно, да.
Язык это просто инструмент. Если один язык позволяет эффективно решать задачи для разных платформ, это отлично. Никто не говорит про Юнити что игры собираются под N-платформ включая ВЕБ.
Все проблемы с производительностью идут от архитектуры. Или ошибки кодирования по части эффективности алгоритмов. Этим ошибка подвержены все языки, но на вебе это заметнее поскольку язык не компилируемый.
Так вот, вместо того чтобы говорить "Электрон-электрон", вероятно, надо развивать культуру программирования, поднимать подготовку кадров, и тогда и софт нормальный будет.
В JS программистов очень много, думаю что сильно больше чем в остальных ЯП, и порог входа крайне низкий, типизации мало (TypeScript вещь, но до того же C# далеко, насколько я понимаю), свободы в реализации решений очень много, вот на выходе и получаем море ошибок.
Вобщем, надо просто поднимать уровень кадров и инструментов, вот и всё.
Увольнение допустимо по закону и договору, а я говорю про риски безопасности, риски нанесения ущерба репутации компании, и прочее, и прочее, что не допустимо как по договору, так и из этических соображений.
Я думаю что в целом правило простое – никакая информация про компанию не должна утекать наружу без согласования с самой компанией.
А вот про описание проекта нужно понимать, что NDA обычно не распространяется на технологический стек. Если вы работали в аутсорс-компании над проектом крупной компании, вам может быть запрещено называть заказчика или раскрывать детали имплементации, но можно рассказать, что вы работали с web-сокетами или делали сложный UI на Jetpack Compose. То есть описать, какого рода вы задачи решали, а не что конкретно делалось в рамках этих задач.
И если вы разрабатывали внутренний мессенджер, то обычно можно в целом сказать «разработка закрытого корпоративного мессенджера для 10 000 пользователей», не конкретизируя дальше.
С чего вдруг? Любая информация может нанести вред работодателю, включая стек, и информация о внутренних продуктах.
Добавлю, что собеседование это просто большое слово. Фактически это просто разговор, обмен информацией, попытка решить головоломку (или даже типовую задачу), а на выходе будет примерно понятно что каждая сторона из себя представляет.
Поэтому кандидатам советую вообще не переживать, и выкинуть из головы куда и зачем они собеседуются. Представьте что вы звоните знакомым чтобы поговорить про условный Реакт, а те вам скинули прикольную задачу на посмотреть. Всё. Получилось, значит получилось. Не получилось, ну и ладно, в другой раз.
Если вдруг со стороны компании сидят ребята которые высокомерно тестируют, и проявляют своё "фу" к отсутствию опыта кандидата, то просто забейте на них, вам точно не в такую компанию.
Когда работал с ffmpeg, была задача видео разных форматов приводить к одному формату, прожигать субтитры, изменять размер видео, склеивать видео из разных форматов, и так далее.
Вобщем, швейцарский нож да, инструмент огонь, но пытаясь собрать в одно целое видео разных форматов это как та картинка про CSS из грифинов. Постоянные артефакты, ограничения, дропы кадров, искажения, и прочее, и прочее, целое море всевозможных косяков с кодированием вылезло. Может быть готовить не умею.
Я к тому, что круто оно круто, но как и любой инструмент который пытается собрать воедино всё и сразу, это не просто взять и использовать, это всё-равно море работы по исследованию совместимостей, отладке, и прочему.
Но ffmpeg огонь в любом случае. Титаническая работа сделана.
Оно бы да, и спорить не берусь, конечно, но смотришь на Китай на рынке, где всё вкривь и вкось, химия на химии, кромки грязные не зачищеные у пластика, но это решает задачу на 100%, и поэтому создается ощущение что всё что вы написали, это про хорошее производство, а по факту детали можно и на коленке производить.
Поэтому предполагаю что эти $5000 это для хорошего производства, но задачу где значительное качество не требуется можно решить очень значительно дешевле. Скажем, коробка под разводку проводов это пластик который монтируется "где-то там", и мне без разницы немного кривой ли он, ровные ли кромки, и всё остальное по мелочи, пока оно выполняет свою функцию.
Причем таких примеров море: крепления проводов, технические розетки, электрические коннекторы, да почти любой пластик-расходник.
P.S. Случайно минусанул, промазал по кнопке ответить, а отменить нельзя.
Расскажите, почему копирование корпуса стоит так дорого?
Не зная как это устроено, создается ощущение что создание 3D-модели корпуса обойдется очень сильно дешевле, чем $5000 за один корпус. Дома люди с принтерами сидят, делают сами модели и печатают, причем куда более сложные модели, а здесь просто коробки, и $5000. Чем обоснована такая цена, если не секрет?
Бесшумный системник для работы (текстовые редакторы, браузер, небольшая нагрузка) = корпусные, видео, и БП кулера отключаемые без нагрузки, плюс основной кулер с пониженной частотой от хорошего известного бренда, и SSD / NVMe. Всё.
Это как сказать. Есть люди которые у кулера могут по 20 встреч в день проводить на уровне поговорить про не связанное с работой, и в день они работают по 2-3 часа. Кому нужна такая производительность?
Технологии и инструменты появились не на ровном месте. Да, 20 лет назад HTML и CSS было достаточно, но сейчас, когда нужен интерактив, когда нужно решать значительно более сложные задачи чем просто вывод информации, нужны и другие, более сложные инструменты.
Современные сложные и тяжелые инструменты это попытка решить новые технические вызовы, и Электрон не исключение. Любые велосипеды со словами "нам это не нужно" в конце концов приведут к реализации аналога уже существующего инструмента, просто потому что готовые решения от сообщества уже прошли эти 1000 грабель и создали возможность решить весь спектр задач, а новый велосипед только поехал по этому пути, и поэтому он пока проще и легче, но для любого развивающегося продукта это временно.
Вопрос лишь в правильности реализации, архитектуре, и как и любое сложное решение, неправильная архитектура может приводить к серьезным просадкам по производительности, поэтому я бы сказал что не время такое, а общая техническая сложность современных задач такая, что простыми средствами её уже не реализовать, а любой рост сложности требует соответствующих навыков и инструментов.
Отсюда и растут ноги и просадок по производительности, и роста приложений.
Если программист 20 лет назад мог открыть блокнот и сделать страницу, и это было достаточно, то сейчас программист должен знать и уметь оперировать сразу N-инструментами с самого начала, и это только базис для старта.
Обычно теряется зерно методологии – тесное взаимодействие и помощь разработчикам, проекту, и заказчику. Всё делается чтобы двигать проект и деловые отношения вперед, и методология, метрики, они помогают это делать, но это не цель. Можно работать и без них.
Проблема в том, что это очень общие слова, и наличие процессов часто начинает преобладать над реальной пользой от них. Вот поставили спринт две недели (как обычно), а от этого накрылся релизный пайп, ребята не успевают, и начал разваливаться обычный процесс. Вот зачем такой процесс нужен? Начинайте изучать процессы, делать инкрементальные изменения, отлаживайте, но не рушьте.
Поэтому я воспринимаю методологии как набор идей, как можно двигаться к лучшую сторону, как отлавливать проблемы по ходу и решать их, а не набор принципов которые можно применить и "все пойдет бодрячком". Нет, потому что первичен проект, и если есть проблемы, то хоть 1000 раз наложи правила, ничего не взлетит, потому что проект в них не вписывается, и поэтому правила диктуются проектом, а не проекту диктуются правила. Корень – проект.
Я правильно понимаю что вместо того, чтобы нажать на системник, они предлагали нажать на эту кнопку, чтобы она через интернет "попросила" другую машину "нажать" на кнопку за вас на вашей машине?)
Да забудьте вообще про эти градации. Главное польза приносимая продукту, и каждый как умеет, так и вкладывает свои усилия и навыки. Кто-то лучше, кто-то хуже в силу отсутствия опыта. Вот и вся формула.
Я видел проекты где "мидлы" лидили проект, и наоборот, где лиды работали на позиции разработчика, и всё было нормально.
Важна не градация, а средний уровень разработчиков и как они работают в команде. Опыт дело поправимое, важны сами люди, и как они работают. У нас есть ребята которые были стажеры, но быстро учатся и местами за ними не успеваешь, шустрые пацаны, за пару лет так натаскались что уже знают такие штуки, про которые старики уже не знают.
Поэтому, люди... Важны именно люди, как они работают, их подход, а опыт дело приходящее.
Да блин, всё сильно проще.)
Пишите информацию ДЛЯ ЛЮДЕЙ. Всё.
Мне лично нравится пример разговора через Авито, когда звонишь, спрашиваешь что как почем, и тебе открыто говорят сколько стоят работы, как работают, всё рассказывают. Мол Вася, экскаватор есть, свободны завтра, стоит столько, доедем куда надо, но техника хреновая, поэтому рвать особо не будем, выбирайте сами, звоните.
Когда дело про найм в IT, это тайны и муть сплошная. Зарплаты не озвучивают, на людей не выводят, информации про проекты почти нету, примеров нет, и этот список можно долго продолжать. Я помню звонишь, даже название проекта не хотят говорить. Дичь вобщем.)
Просто пишите вакансии для людей, рассказывайте.
Чем проще, точнее, и ближе к людям, тем лучше.
Нужен программист, пишем на TS, используем React и такие-то библиотеки, проект такой то, посмотреть можно там то, платим столько, мы есть на Github смотрите код, плюшки такие, команда большая, там те то и те то, нужен новый человек потому что растем, тестирования нет но стараемся, всё что не рассказали спрашивайте, расскажем. Не дословно, понятно что написать нормально, правильно подать, формулировки более формальные, но посыл именно такой, должна быть информация.
Работа это про людей, а не про шаблоны вакансий.
ВСЁ)
Есть целое море причин почему нужно использовать библиотеки и фреймворки на коммерческих проектах: скорость найма кадров, порог входа в проект, обучение и обмен опытом, скорость разработки, качество решений, наличие документации, наличие огромного количество
собранных граблейрешенных вопросов на SO, и прочее, и прочее.Как сказали выше, если проект из серии написать и больше не трогать, то можно сделать как угодно, да.
Язык это просто инструмент. Если один язык позволяет эффективно решать задачи для разных платформ, это отлично. Никто не говорит про Юнити что игры собираются под N-платформ включая ВЕБ.
Все проблемы с производительностью идут от архитектуры. Или ошибки кодирования по части эффективности алгоритмов. Этим ошибка подвержены все языки, но на вебе это заметнее поскольку язык не компилируемый.
Так вот, вместо того чтобы говорить "Электрон-электрон", вероятно, надо развивать культуру программирования, поднимать подготовку кадров, и тогда и софт нормальный будет.
В JS программистов очень много, думаю что сильно больше чем в остальных ЯП, и порог входа крайне низкий, типизации мало (TypeScript вещь, но до того же C# далеко, насколько я понимаю), свободы в реализации решений очень много, вот на выходе и получаем море ошибок.
Вобщем, надо просто поднимать уровень кадров и инструментов, вот и всё.
Увольнение допустимо по закону и договору, а я говорю про риски безопасности, риски нанесения ущерба репутации компании, и прочее, и прочее, что не допустимо как по договору, так и из этических соображений.
Я думаю что в целом правило простое – никакая информация про компанию не должна утекать наружу без согласования с самой компанией.
С чего вдруг? Любая информация может нанести вред работодателю, включая стек, и информация о внутренних продуктах.
Добавлю, что собеседование это просто большое слово. Фактически это просто разговор, обмен информацией, попытка решить головоломку (или даже типовую задачу), а на выходе будет примерно понятно что каждая сторона из себя представляет.
Поэтому кандидатам советую вообще не переживать, и выкинуть из головы куда и зачем они собеседуются. Представьте что вы звоните знакомым чтобы поговорить про условный Реакт, а те вам скинули прикольную задачу на посмотреть. Всё. Получилось, значит получилось. Не получилось, ну и ладно, в другой раз.
Если вдруг со стороны компании сидят ребята которые высокомерно тестируют, и проявляют своё "фу" к отсутствию опыта кандидата, то просто забейте на них, вам точно не в такую компанию.
Закину кирпич, пока не знаю в чей огород.
Когда работал с ffmpeg, была задача видео разных форматов приводить к одному формату, прожигать субтитры, изменять размер видео, склеивать видео из разных форматов, и так далее.
Вобщем, швейцарский нож да, инструмент огонь, но пытаясь собрать в одно целое видео разных форматов это как та картинка про CSS из грифинов. Постоянные артефакты, ограничения, дропы кадров, искажения, и прочее, и прочее, целое море всевозможных косяков с кодированием вылезло. Может быть готовить не умею.
Я к тому, что круто оно круто, но как и любой инструмент который пытается собрать воедино всё и сразу, это не просто взять и использовать, это всё-равно море работы по исследованию совместимостей, отладке, и прочему.
Но ffmpeg огонь в любом случае. Титаническая работа сделана.
У Havit есть офигенная низкопрофильная механика. Пользовался пару лет.
Брал на али, тогда за 3-4 тысячи.
Нашел её, модель HAVIT HV-KB390L
<Удалено>
Deleted
Спасибо за ответы
Оно бы да, и спорить не берусь, конечно, но смотришь на Китай на рынке, где всё вкривь и вкось, химия на химии, кромки грязные не зачищеные у пластика, но это решает задачу на 100%, и поэтому создается ощущение что всё что вы написали, это про хорошее производство, а по факту детали можно и на коленке производить.
Поэтому предполагаю что эти $5000 это для хорошего производства, но задачу где значительное качество не требуется можно решить очень значительно дешевле. Скажем, коробка под разводку проводов это пластик который монтируется "где-то там", и мне без разницы немного кривой ли он, ровные ли кромки, и всё остальное по мелочи, пока оно выполняет свою функцию.
Причем таких примеров море: крепления проводов, технические розетки, электрические коннекторы, да почти любой пластик-расходник.
P.S. Случайно минусанул, промазал по кнопке ответить, а отменить нельзя.
Расскажите, почему копирование корпуса стоит так дорого?
Не зная как это устроено, создается ощущение что создание 3D-модели корпуса обойдется очень сильно дешевле, чем $5000 за один корпус. Дома люди с принтерами сидят, делают сами модели и печатают, причем куда более сложные модели, а здесь просто коробки, и $5000. Чем обоснована такая цена, если не секрет?
Бесшумный системник для работы (текстовые редакторы, браузер, небольшая нагрузка) = корпусные, видео, и БП кулера отключаемые без нагрузки, плюс основной кулер с пониженной частотой от хорошего известного бренда, и SSD / NVMe. Всё.
Это как сказать. Есть люди которые у кулера могут по 20 встреч в день проводить на уровне поговорить про не связанное с работой, и в день они работают по 2-3 часа. Кому нужна такая производительность?
Ну... Была массовая гонка велосипедистов )
Инструменты неизвестны, статей нет или почти нет, а дела делать надо.)
Я как сейчас помню как день слил на выравнивание div'а по центру до того как узнал про inline-block, про который могли бы подсказать на... SO! )
Технологии и инструменты появились не на ровном месте. Да, 20 лет назад HTML и CSS было достаточно, но сейчас, когда нужен интерактив, когда нужно решать значительно более сложные задачи чем просто вывод информации, нужны и другие, более сложные инструменты.
Современные сложные и тяжелые инструменты это попытка решить новые технические вызовы, и Электрон не исключение. Любые велосипеды со словами "нам это не нужно" в конце концов приведут к реализации аналога уже существующего инструмента, просто потому что готовые решения от сообщества уже прошли эти 1000 грабель и создали возможность решить весь спектр задач, а новый велосипед только поехал по этому пути, и поэтому он пока проще и легче, но для любого развивающегося продукта это временно.
Вопрос лишь в правильности реализации, архитектуре, и как и любое сложное решение, неправильная архитектура может приводить к серьезным просадкам по производительности, поэтому я бы сказал что не время такое, а общая техническая сложность современных задач такая, что простыми средствами её уже не реализовать, а любой рост сложности требует соответствующих навыков и инструментов.
Отсюда и растут ноги и просадок по производительности, и роста приложений.
Если программист 20 лет назад мог открыть блокнот и сделать страницу, и это было достаточно, то сейчас программист должен знать и уметь оперировать сразу N-инструментами с самого начала, и это только базис для старта.
Кто-нибудь может перевести для не финансистов?
Что сейчас может быть с нашим рынком, без эмоций?
Обычно теряется зерно методологии – тесное взаимодействие и помощь разработчикам, проекту, и заказчику. Всё делается чтобы двигать проект и деловые отношения вперед, и методология, метрики, они помогают это делать, но это не цель. Можно работать и без них.
Проблема в том, что это очень общие слова, и наличие процессов часто начинает преобладать над реальной пользой от них. Вот поставили спринт две недели (как обычно), а от этого накрылся релизный пайп, ребята не успевают, и начал разваливаться обычный процесс. Вот зачем такой процесс нужен? Начинайте изучать процессы, делать инкрементальные изменения, отлаживайте, но не рушьте.
Поэтому я воспринимаю методологии как набор идей, как можно двигаться к лучшую сторону, как отлавливать проблемы по ходу и решать их, а не набор принципов которые можно применить и "все пойдет бодрячком". Нет, потому что первичен проект, и если есть проблемы, то хоть 1000 раз наложи правила, ничего не взлетит, потому что проект в них не вписывается, и поэтому правила диктуются проектом, а не проекту диктуются правила. Корень – проект.
Я правильно понимаю что вместо того, чтобы нажать на системник, они предлагали нажать на эту кнопку, чтобы она через интернет "попросила" другую машину "нажать" на кнопку за вас на вашей машине?)