Уууу… Это еще сложнее. Если он хочет мультиплатформенное приложение, видимо для мобильных (коль скоро в списке Google Play) — ему надо будет к студии доставить еще и рантайм Xamarin-а, ознакомиться с разницей между .NET Portable и .NET Client profile. В случае с MS Store — придется познакомиться с UWP и с XAML-разметкой (там уже WinForms не используется) — а это автоматом тянет за собой MVVM-фреймворк и IoC-контейнер (хотя без последнего можно и обойтись). А если он хочет писать игрушку — то тут уже Unity. А это отдельная песня.
Тут даже профессиональные компании предпочитают что-то простое делать на JS — том же React Native. Потому что проще :)
Редкий случай, когда я признаю частичную ущербность .NET в каком-либо вопросе :) Но с другой стороны зависит от сложности приложения. Что-то по-сложнее калькулятора комфортнее делать на строго типизированном языке с кросс-платформенными билдами.
Воот! Народ именно так и думает. Точнее не думает, а просто разделяет код на несколько потоков и довольный идет пить кофе.
Ну дык и как смена технологии спасет вас от тупого разработчика, который ею пользуется? Тут народ надо обучать, а не предлагать супер-технологии, которые избавят от всех проблем. И это, кстати, одна из проблем JS-а: он скрывает проблему, говоря "вот пишите как мы, а о потоках не думайте". Мне не кажется что такой подход может довести до добра.
Он переключает контексты, но не в основном потоке
Простите великодушно, но переключение контекста не может происходить "в потоке". Оно происходит между потоками или между процессами. Вы что-то путаете. Если я правильно понял исходники nodejs — то там все еще веселее: в рамках якобы "однопоточной" модели у вас с каждой операцией запускается (берется из тредпула, но я для простоты говорю "запускается") неопределенное количество потоков, на которых просто висят коллбеки. И это еще бОльший ад чем использование многопоточности явно — в последнем случае у вас хотя бы есть контроль над ситуацией. Для сравнения: C# использует для тех же целей I/O completion ports, которые не создают лишних потоков.
Ну тут знаете ли, первое с чем столкнется студент — что такой калькулятор можно написать как минимум тремя разными способами — WinForms, WPF и напрямую вызовами WinAPI — как нетрудно заметить, охват знаний будет очень и очень разный :)
WinForms — это безболезненный способ, на WPF студенту сорвет крышечку от порога входа, про WinAPI я даже говорить не буду :)
Если этот код разбить на два потока (не в js кончено, в другом языке) и добавить синхронизацию между потоками, а как без нее, я даже боюсь предположить во сколько раз возрастет время исполнения.
Простите, а зачем этот код вообще выполнять в 2 потока? Если вы думаете что многопоточность — это такая волшебная таблетка, которая просто все ускоряет — вы очень сильно ошибаетесь. Я подскажу: если перед операцией sum+=i вы добавите, например, скачивание картинки — то я даже боюсь предположить во сколько раз сократиться время исполнения, если это делать в 2 потока. :)
Не соглашусь, если вы хотите скорости и многопоточности одновременно, общие данные между потоками зло
Очень даже добро, если правильно выстроить обращения к общим данным. Кроме того, выше вон человек заметил про что существуют механизмы неблокирующей синхронизации (wait-free), с которыми работа с общими данными становится дюже быстрее. Погуглите по слову "concurrency".
Так js — это отличный выход, получить высокую производительность, но без явной многопоточности
Я открою для вас секретик: любой асинхронный вызов в nodejs так же — вы будете смеяться — переключает контексты. Откройте исходники и почитайте — там внутри тредпул, если я правильно врубился. Так что js в данном случае — как раз плохое решение. Хорошее — это C с posix-тредами. Но, повторюсь, это только в случае если проблема действительно в переключениях контекста, во что я по-прежнему не верю. :)
Мы уперлись в недостаточно быструю операцию записи в файл, запись в сокет рабита ничем не быстрей.
Сомнительное утверждение. Запись в сокет не приводит к движению магнитной головки диска (если у вас обычный HDD, а не SSD).
Ну и потом — на C# можно много чего писать — не только оконные приложения. Так что порог входа туда уже тем выше, что новичку надо определиться с тем, что именно он хочет получить с помощью C#. И поставить студию, да, познакомиться с чисто студийными примитивами — проект, солюшен. Без этого никак. Дюже сложнее чем просто создать файл и написать в нем console.log('hello world'); :)
Странное у вас представление о C#. Студия — это просто IDE, которая правильно запускает вам компилятор и позволяет писать код на любом выбранном языке. Невозможно "написать программу на Visual Studio". Можно на C#, на VB.NET, на плюсах и на всем, что вы в студию доустановите. И кто вам сказал, что программирование на C# сводится к набрасыванию компонентов мышкой? Вот найдите того, кто сказал — и в глаз ему плюньте :) Я уже 11 лет на нем пишу и как-то даже не припомню когда последний раз набрасывал компоненты мышкой куда-либо.
А вот программирование на javascript — таки да. Сводится к написанию кода на javascript, что можно делать хоть в обычном блокноте без всяких доп. инструментов и получать какой-либо осмысленный результат.
Само собой многопоточность — это сложно. Ну так а никто и не говорит что в принципе программирование — это просто. Всегда надо думать головой и просчитывать варианты.
Касательно непосредственно вашего примера — я не думаю что
а) вся проблема была в переключениях контекста (ибо тогда бы вам пришлось поубивать изрядную долю процессов на своем сервере для оптимизации)
б) что однопоточная модель, скажем, nodejs, спасла бы вас от переключений контекста, ибо как контексты бы все равно переключались, ибо как, скажем, nginx, стоящий перед вашей нодой — будет создавать новые процессы. Вы бы не решили проблему, а просто перенесли её на другой уровень или же вообще спрятали её в нерешаемые дебри.
А вот как раз вменяемая многопоточная модель с shared-данными вас могла бы спасти (отдельный поток на запись логов, да). Но то ж нет. То ж надо синхронизацию писать, ведь так? :) На крайний случай — асинхронный сервер для логов и какой-нибудь rabbitmq, чтобы не было проблем с логами в случае крэша основного процесса.
Господа, я может что-то путаю, но в мою молодость умение писать многопоточный код, знание примитивов синхронизации и (желательно) идиоматических задач многопоточности (обедающие философы, читатель-писатель и т.д.) входило в базовый набор навыков программиста, который проверялся на собеседованиях еще до конкретных вопросов по языку/технологии. Это вроде как было общей теоретической базой, которой обучали во всех вменяемых IT-ВУЗах.
Ууу… Знаете сколько у нас людей, которые приняты на работу с навыком писать маленькие галактики внутри тега script и вызова getElementById?.. :) Вот то-то же.
Я JS в свое время так и изучил — методом тыка. Я не пишу на нем профессионально (ну один фреймворк с клиентской частью на TypeScript не в счет :) ), но вполне в курсе разворачивающихся вокруг него баталий.
На самом деле IDE у C# конечно же 3: VS, Mono Develop, Rider. А еще C# есть в Unity и для мобильного Xamarin-а. Синтаксис не отличается, но может отличаться рантайм. А еще есть .NET Core, который немного отдельная песня. И Portable, и с недавних пор .NETStandard. И популярных фреймворков там до черта — одних только IoC-контейнеров вон как собак не резанных. Так что не рубите сплеча. :)
А низкий порог вхождения у JS берется с того, что можно начать на нем программировать просто открыв консоль хрома или же создать HTML или js файл в блокноте.
Вставлю 5 копеек: бизнес-логика-то похожая, но на черт побери не та же самая! Реально общего между бэком и фронтом по коду — это модели, которые туда-сюда пересылаются. Ну может еще кусочек валидации. В остальном — бэк прибит гвоздями к контексту источника данных, а у фронта такой радости нет. Как следствие — обязанности и код довольно сильно разделен и имеет не так много общего, как кажется.
Единственный аспект, в котором изоморфный подход себя оправдывает — это шаблонизация. Круто когда на сервере и на клиенте можешь срендерить одинаковый HTML не дублируя кода. Реально, без шуток круто. Но выворачивать это обстоятельство чуть ли не в отдельную идеологию — попахивает распилом проектных бюджетов :)
Кстати, раз уж на то пошло. Хочу обратить внимание еще на парочку этюдов, связанных с хайпом.
Все в курсе, что у JS низкий порог вхождения. Начать писать просто, никакого инструментария не нужно (блокнот да браузер). Базовый синтаксис прост до безобразия. И вот мальчик пубертатного возраста берет в руки этот набор инструментов, делает какую-нибудь пакость за пару дней. А дальше? А дальше предается упоенному самопиару — пишет про это статьи, записывает видео, публикует в npm, вероятно даже выступает на конференциях. В общем получает удовольствие от процесса, удовлетворяя свое эго, а не занимаясь, черт побери, развитием технологий. Нет, ну а что? Представьте что вам 20, вы занимаетесь поддержкой сайта какого-нибудь интернет-магазина ООО «Рога и Копыта», на плюсах не писали, в базы данных умеете на уровне phpMyAdmin, не знаете структур данных и алгоритмов. И тут у вас появляется возможность сделать не хвост собачий, а ажно целый opensource-проект, о котором всем можно рассказывать и с которым вас будут воспринимать всерьез. Красота! Вы когда-нибудь пробовали указать пубертатному подростку на то, что он занимается какой-то фигнёй? Если нет — то я вам сразу скажу что в ответ вас обольют весьма утонченными и изысканными оскорблениями. Поразительно похоже на реакцию JS-адептов на критику. :) Кстати, как не трудно догадаться, заканчивается это пиршество духа какой-нибудь забавной историей с left-pad.
Предположу, что в крупных конторах происходит примерно то же самое. Группа программистов пишет какой-нибудь фреймворк для решения какой-нибудь внутрикомпанейской задачи. При том делает это чуть ли не из интереса (все же должны получать удовольствие от работы, так? Ох уж этот либеральный подход к менеджменту!) или из имитации бурной деятельности. А потом начальству надо отчитаться куда ушли деньги и как это все поможет бизнесу заработать. В такие моменты рождается байка про «да мы же тут сделали инструмент, который превосходит аналоги!», «изобрели штуку, которая сделает мир лучше», «открыли новый подход к проектированию/рендерингу/модулям/чемуугодно». И вот уже становится как-то неловко говорить, что отдел потратил время впустую, разработчики сделали нерелевантную штуковину, которая интересна только им и вообще сожгли бюджет. Начинаются поездки по конференциям. Чем это заканчивается все итак понимают.
Ну и кулстори на десерт: я был лично знаком с человеком, который сделал небольшой фреймворк для изоморфных приложений за несколько месяцев (в рабочее время, сидя на зарплате!) и потом несколько лет занимался тем, что за деньги компании катался по конференциям, рассказывая про свое творение — и заодно про то, как хорошо работать в этой компании. А на его фреймворке, тем временем, было сделано ровно 2 работающих сайта. В итоге: фреймворк всеми забыт, компанию все итак хорошо знают, человек уволился и работает сейчас где-то в США. Только потом мне поведали что это называется «технопиар» и задумка была не сделать хороший инструмент, а разрекламировать компанию как идеальное место работы.
А я вот согласен с автором. Блин, ребята, вся история программирования — это история о строгой типизации. О борьбе человека против никак не регламентированных кусков памяти в попытках обуздать эту стихию и сделать её хоть сколько-нибудь структурированной.
И тут мне в личку приходят обезумевшие JS-фанаты и заявляют что «строгая типизация — говно, все скоро от неё откажутся и будут писать на нетипизируемых языках», после чего вываливают еще тонны личных оскорблений как на меня, так и на мой любимый C#.
Далее. Хочу дополнить автора тем фактом, что судя по разброду в JS-технологиях и отсутствию одного стандартного решения хоть в каком-либо аспекте (возьмите хотя бы 5 популярнейших пакетных менедж… стойте, пока я писал этот пост — сделали шестой) — проектированием фреймворков на JS заняты люди без опыта проектирования и умения договариваться. Нуу… ладно, положим какой-то опыт проектирования у некоторых людей из JS-коммьюнити все же есть, но все эти спецы работают на крупные корпорации и делают штуки навроде React-а (надеюсь, у них-то нет времени кричать что строгая типизация скоро вымрет). С ними наверняка конкурирует еще кто-то. Все остальное развивается мягко говоря, хаотично. И это тот случай, когда рыночная «здоровая конкуренция» как раз-таки не приводит к выбору оптимального решения, а скорее засоряет эфир кучей разнокалиберных поделок неизвестной степени пригодности к использованию. Почему? Ответ прост — хайп.
И вообще, слово этого года — «хайп». Очень, очень понравилось выражение автора «хайп дривен девелопмент». Корпорации вкладывают миллионы долларов в пиар, конференции с печеньками, трансляции и книги, блогеры пишут пресс-релизы — и все это вместо того чтобы просто дать попользоваться технологией всем тем, кто желает ей попользоваться и уже на месте решить хороша она или плоха, какие задачи она решает хорошо, а какие плохо. Но нет, вместо естественного процесса смерти неэффективных решений мы имеем толпы хомячков, которые услышали про React/Angular/nodejs/ватевер и бездумно на него молятся, без разбору поливая шоколадного колера субстанцией всех, кто посмеет им возразить и указать на недостатки. Вот примерно таким макаром JS-фанаты мне давеча заявили, что «писать в многопоточных средах в 2017 — это **ня полная».
В общем, что хочу сказать. Читающий, должно быть, уже заметил что сама технология тут ни при чем. JS — нормальный язык для своих задач, с некоторыми… скажем так, архитектурными особенностями. И эта тема стала бы максимум — местом в документации, с которым ознакамливается всякий, кто начнет разрабатывать на JS. Но тут пришли люди, которые сказали, что архитектурные особености JS — это не баг, а фича, а все кто не согласен — должны идти лесом. Чуете о чем я? Проблема не в технологии, а в людях и сообществе вокруг этой технологии (ИМХО именно на этом в статье надо было сделать акцент). Я еще никогда не встречал более слепо верующего и агрессивного сообщества чем JS-разработчики. Я еще никогда не встречал более агрессивно продвигаемых технологий чем JS-стек.
Да да да! Еще важный совет. Надо давать больше заданий а-ля «что выведет на экран этот код?». Недостижимый идеал здесь — дать код, запускающий несколько потоков с подозрением на мертвую блокировку, но по факту содержащий синтаксическую ошибку (не компилирующийся). Ведь вы нанимаете не программиста, вам нужен профессиональный решатель ребусов. Здесь профессионалы порекомендуют дать соискателю поразгадывать кроссворд, но пока что эти технологии никем не освоены — станьте первым!
… ну или ограничьтесь шаблонной и унизительной формулировкой вроде «наши руководители проектов сочли ваш уровень квалификации недостаточным» (особенно эффективно работает если соискатель окажется бородатым сениором с 15-летним стажем и текущим окладом выше чем зарплата рекрутера за полжизни). Это очень позитивно повлияет на имидж компании — наверняка после такого соискатель порекомендует вашу компанию друзьям. Никогда не признавайтесь что не смотрели резюме, или было лень, или планы поменялись, или вам просто не понравился соискатель. Оставайтесь окутанными пеленой тайны.
Я добавлю:
— звоните соискателю, обещайте золотые горы и пропадайте. Вообще. Капитально. Соискатель сам напишет если вдруг что — у вас есть дела и по-важнее
— ни в коем случае не смотрите на github и прочую опенсорсную активность кандидата. А если вы и уделяете этому внимание — то контрольными вопросами должно быть «сколько человек пользуется вашей поделкой?» и «как часто вы выпускаете новые релизы и общаетесь с коммьюнити?». Что ж это за соискатель такой, что даже не может раскрутить свой проект водиночку. Вам же нужен разработчик с навыками маркетолога, ведь правда?
— не доверяйте соискателю. Вообще. Он — грязное и хитрое создание, которое пришло похитить у вас деньги. Поэтому лучше вообще не говорите ему чем занимаетесь до подписания NDA, которое лучше заставить подписать прямо с порога. Помните что соискатель абсолютно ничего не понимает ни в своей профессии, ни в вашей системе, поэтому любые его предложения относительно, например, архитектуры систем надо рассматривать свысока, цокая языком, а еще лучше — обсмеивая.
— выше уже было про рассылку писем-автоответов. Я хотел бы добавить изюминку: обязательно дописывайте в конце, что по всем возникшим вопросам соискатель может не стесняться писать или звонить вам. Укажите что вы всегда готовы ответить на все вопросы. Желательно дать несуществующий e-mail и неактивный номер телефона.
— отличным ходом является дать соискателю ссылку на автоматический входной тест знаний. Сделайте его в самой убогой системе тестирования — в Moodle например. К вопросам особых требований нет. Спросите про его настрой, психологический профиль, дайте задачку на решение уравнений, накидайте вопросов по сетевым технологиям и программированию. Само собой, тест по времени стоит ограничить — ибо нефиг. Соискателей, отсеенных по результатам автоматического тестирования сразу добавляйте в бан-лист и больше никогда не рассматривайте. Автоматизация-с! И да! Ни в коем случае не предупреждайте соискателя о тесте и не предоставляйте подробностей о вопросах. Интригу надо сохранить, а хороший соискатель должен быть всегда ко всему готов. Как пионер. Больше чем пионер.
— неплохим ходом кстати является автоматическое тестирование на знание английского языка. Найдите в гугле первый попавшийся тест — их там много. Соискателя можете не предупреждать — он всегда обязан быть готов.
И помните главное: рекрутерами должны быть только женщины. Их образование, стаж работы, адекватность и психическая сбалансированность не важна. Сиськи — залог успешного найма! Ведь соискатели идут только за этим, правда?
Абсолютно верно — важна середина между качеством и business value. Чтобы одно не уничтожало другое. У меня (Паша скромный, да) это чувство например развито — я могу сделать немного в ущерб качеству, а местами занять технического долга, если это даст существенный прирост в скорости. Но я не знаю как обрел этот скилл и уж тем паче не ведаю как его можно передать, например, подрастающему поколению. На словах-то оно просто звучит, а на деле далеко не всегда понимаешь где кончается реальная польза для бизнеса и начинается качественная выдрочка (НЛО, здесь имеется в виду маленькая выдра!).
Уууу… Это еще сложнее. Если он хочет мультиплатформенное приложение, видимо для мобильных (коль скоро в списке Google Play) — ему надо будет к студии доставить еще и рантайм Xamarin-а, ознакомиться с разницей между .NET Portable и .NET Client profile. В случае с MS Store — придется познакомиться с UWP и с XAML-разметкой (там уже WinForms не используется) — а это автоматом тянет за собой MVVM-фреймворк и IoC-контейнер (хотя без последнего можно и обойтись). А если он хочет писать игрушку — то тут уже Unity. А это отдельная песня.
Тут даже профессиональные компании предпочитают что-то простое делать на JS — том же React Native. Потому что проще :)
Редкий случай, когда я признаю частичную ущербность .NET в каком-либо вопросе :) Но с другой стороны зависит от сложности приложения. Что-то по-сложнее калькулятора комфортнее делать на строго типизированном языке с кросс-платформенными билдами.
Ну дык и как смена технологии спасет вас от тупого разработчика, который ею пользуется? Тут народ надо обучать, а не предлагать супер-технологии, которые избавят от всех проблем. И это, кстати, одна из проблем JS-а: он скрывает проблему, говоря "вот пишите как мы, а о потоках не думайте". Мне не кажется что такой подход может довести до добра.
Простите великодушно, но переключение контекста не может происходить "в потоке". Оно происходит между потоками или между процессами. Вы что-то путаете. Если я правильно понял исходники nodejs — то там все еще веселее: в рамках якобы "однопоточной" модели у вас с каждой операцией запускается (берется из тредпула, но я для простоты говорю "запускается") неопределенное количество потоков, на которых просто висят коллбеки. И это еще бОльший ад чем использование многопоточности явно — в последнем случае у вас хотя бы есть контроль над ситуацией. Для сравнения: C# использует для тех же целей I/O completion ports, которые не создают лишних потоков.
Потом
Ну тут знаете ли, первое с чем столкнется студент — что такой калькулятор можно написать как минимум тремя разными способами — WinForms, WPF и напрямую вызовами WinAPI — как нетрудно заметить, охват знаний будет очень и очень разный :)
WinForms — это безболезненный способ, на WPF студенту сорвет крышечку от порога входа, про WinAPI я даже говорить не буду :)
Простите, а зачем этот код вообще выполнять в 2 потока? Если вы думаете что многопоточность — это такая волшебная таблетка, которая просто все ускоряет — вы очень сильно ошибаетесь. Я подскажу: если перед операцией
sum+=iвы добавите, например, скачивание картинки — то я даже боюсь предположить во сколько раз сократиться время исполнения, если это делать в 2 потока. :)Очень даже добро, если правильно выстроить обращения к общим данным. Кроме того, выше вон человек заметил про что существуют механизмы неблокирующей синхронизации (wait-free), с которыми работа с общими данными становится дюже быстрее. Погуглите по слову "concurrency".
Я открою для вас секретик: любой асинхронный вызов в nodejs так же — вы будете смеяться — переключает контексты. Откройте исходники и почитайте — там внутри тредпул, если я правильно врубился. Так что js в данном случае — как раз плохое решение. Хорошее — это C с posix-тредами. Но, повторюсь, это только в случае если проблема действительно в переключениях контекста, во что я по-прежнему не верю. :)
Сомнительное утверждение. Запись в сокет не приводит к движению магнитной головки диска (если у вас обычный HDD, а не SSD).
Ну и потом — на C# можно много чего писать — не только оконные приложения. Так что порог входа туда уже тем выше, что новичку надо определиться с тем, что именно он хочет получить с помощью C#. И поставить студию, да, познакомиться с чисто студийными примитивами — проект, солюшен. Без этого никак. Дюже сложнее чем просто создать файл и написать в нем console.log('hello world'); :)
Странное у вас представление о C#. Студия — это просто IDE, которая правильно запускает вам компилятор и позволяет писать код на любом выбранном языке. Невозможно "написать программу на Visual Studio". Можно на C#, на VB.NET, на плюсах и на всем, что вы в студию доустановите. И кто вам сказал, что программирование на C# сводится к набрасыванию компонентов мышкой? Вот найдите того, кто сказал — и в глаз ему плюньте :) Я уже 11 лет на нем пишу и как-то даже не припомню когда последний раз набрасывал компоненты мышкой куда-либо.
А вот программирование на javascript — таки да. Сводится к написанию кода на javascript, что можно делать хоть в обычном блокноте без всяких доп. инструментов и получать какой-либо осмысленный результат.
Касательно непосредственно вашего примера — я не думаю что
а) вся проблема была в переключениях контекста (ибо тогда бы вам пришлось поубивать изрядную долю процессов на своем сервере для оптимизации)
б) что однопоточная модель, скажем, nodejs, спасла бы вас от переключений контекста, ибо как контексты бы все равно переключались, ибо как, скажем, nginx, стоящий перед вашей нодой — будет создавать новые процессы. Вы бы не решили проблему, а просто перенесли её на другой уровень или же вообще спрятали её в нерешаемые дебри.
А вот как раз вменяемая многопоточная модель с shared-данными вас могла бы спасти (отдельный поток на запись логов, да). Но то ж нет. То ж надо синхронизацию писать, ведь так? :) На крайний случай — асинхронный сервер для логов и какой-нибудь rabbitmq, чтобы не было проблем с логами в случае крэша основного процесса.
Сейчас что-то изменилось? Я что-то пропустил?
И еще у меня ощущение, что вы путаете многопоточность и асинхронность.
Я JS в свое время так и изучил — методом тыка. Я не пишу на нем профессионально (ну один фреймворк с клиентской частью на TypeScript не в счет :) ), но вполне в курсе разворачивающихся вокруг него баталий.
Вот лично для меня порог входа в JS — низкий.
А низкий порог вхождения у JS берется с того, что можно начать на нем программировать просто открыв консоль хрома или же создать HTML или js файл в блокноте.
Единственный аспект, в котором изоморфный подход себя оправдывает — это шаблонизация. Круто когда на сервере и на клиенте можешь срендерить одинаковый HTML не дублируя кода. Реально, без шуток круто. Но выворачивать это обстоятельство чуть ли не в отдельную идеологию — попахивает распилом проектных бюджетов :)
Все в курсе, что у JS низкий порог вхождения. Начать писать просто, никакого инструментария не нужно (блокнот да браузер). Базовый синтаксис прост до безобразия. И вот мальчик пубертатного возраста берет в руки этот набор инструментов, делает какую-нибудь пакость за пару дней. А дальше? А дальше предается упоенному самопиару — пишет про это статьи, записывает видео, публикует в npm, вероятно даже выступает на конференциях. В общем получает удовольствие от процесса, удовлетворяя свое эго, а не занимаясь, черт побери, развитием технологий. Нет, ну а что? Представьте что вам 20, вы занимаетесь поддержкой сайта какого-нибудь интернет-магазина ООО «Рога и Копыта», на плюсах не писали, в базы данных умеете на уровне phpMyAdmin, не знаете структур данных и алгоритмов. И тут у вас появляется возможность сделать не хвост собачий, а ажно целый opensource-проект, о котором всем можно рассказывать и с которым вас будут воспринимать всерьез. Красота! Вы когда-нибудь пробовали указать пубертатному подростку на то, что он занимается какой-то фигнёй? Если нет — то я вам сразу скажу что в ответ вас обольют весьма утонченными и изысканными оскорблениями. Поразительно похоже на реакцию JS-адептов на критику. :) Кстати, как не трудно догадаться, заканчивается это пиршество духа какой-нибудь забавной историей с left-pad.
Предположу, что в крупных конторах происходит примерно то же самое. Группа программистов пишет какой-нибудь фреймворк для решения какой-нибудь внутрикомпанейской задачи. При том делает это чуть ли не из интереса (все же должны получать удовольствие от работы, так? Ох уж этот либеральный подход к менеджменту!) или из имитации бурной деятельности. А потом начальству надо отчитаться куда ушли деньги и как это все поможет бизнесу заработать. В такие моменты рождается байка про «да мы же тут сделали инструмент, который превосходит аналоги!», «изобрели штуку, которая сделает мир лучше», «открыли новый подход к проектированию/рендерингу/модулям/чемуугодно». И вот уже становится как-то неловко говорить, что отдел потратил время впустую, разработчики сделали нерелевантную штуковину, которая интересна только им и вообще сожгли бюджет. Начинаются поездки по конференциям. Чем это заканчивается все итак понимают.
Ну и кулстори на десерт: я был лично знаком с человеком, который сделал небольшой фреймворк для изоморфных приложений за несколько месяцев (в рабочее время, сидя на зарплате!) и потом несколько лет занимался тем, что за деньги компании катался по конференциям, рассказывая про свое творение — и заодно про то, как хорошо работать в этой компании. А на его фреймворке, тем временем, было сделано ровно 2 работающих сайта. В итоге: фреймворк всеми забыт, компанию все итак хорошо знают, человек уволился и работает сейчас где-то в США. Только потом мне поведали что это называется «технопиар» и задумка была не сделать хороший инструмент, а разрекламировать компанию как идеальное место работы.
Такие вот дела.
И тут мне в личку приходят обезумевшие JS-фанаты и заявляют что «строгая типизация — говно, все скоро от неё откажутся и будут писать на нетипизируемых языках», после чего вываливают еще тонны личных оскорблений как на меня, так и на мой любимый C#.
Далее. Хочу дополнить автора тем фактом, что судя по разброду в JS-технологиях и отсутствию одного стандартного решения хоть в каком-либо аспекте (возьмите хотя бы 5 популярнейших пакетных менедж… стойте, пока я писал этот пост — сделали шестой) — проектированием фреймворков на JS заняты люди без опыта проектирования и умения договариваться. Нуу… ладно, положим какой-то опыт проектирования у некоторых людей из JS-коммьюнити все же есть, но все эти спецы работают на крупные корпорации и делают штуки навроде React-а (надеюсь, у них-то нет времени кричать что строгая типизация скоро вымрет). С ними наверняка конкурирует еще кто-то. Все остальное развивается мягко говоря, хаотично. И это тот случай, когда рыночная «здоровая конкуренция» как раз-таки не приводит к выбору оптимального решения, а скорее засоряет эфир кучей разнокалиберных поделок неизвестной степени пригодности к использованию. Почему? Ответ прост — хайп.
И вообще, слово этого года — «хайп». Очень, очень понравилось выражение автора «хайп дривен девелопмент». Корпорации вкладывают миллионы долларов в пиар, конференции с печеньками, трансляции и книги, блогеры пишут пресс-релизы — и все это вместо того чтобы просто дать попользоваться технологией всем тем, кто желает ей попользоваться и уже на месте решить хороша она или плоха, какие задачи она решает хорошо, а какие плохо. Но нет, вместо естественного процесса смерти неэффективных решений мы имеем толпы хомячков, которые услышали про React/Angular/nodejs/ватевер и бездумно на него молятся, без разбору поливая шоколадного колера субстанцией всех, кто посмеет им возразить и указать на недостатки. Вот примерно таким макаром JS-фанаты мне давеча заявили, что «писать в многопоточных средах в 2017 — это **ня полная».
В общем, что хочу сказать. Читающий, должно быть, уже заметил что сама технология тут ни при чем. JS — нормальный язык для своих задач, с некоторыми… скажем так, архитектурными особенностями. И эта тема стала бы максимум — местом в документации, с которым ознакамливается всякий, кто начнет разрабатывать на JS. Но тут пришли люди, которые сказали, что архитектурные особености JS — это не баг, а фича, а все кто не согласен — должны идти лесом. Чуете о чем я? Проблема не в технологии, а в людях и сообществе вокруг этой технологии (ИМХО именно на этом в статье надо было сделать акцент). Я еще никогда не встречал более слепо верующего и агрессивного сообщества чем JS-разработчики. Я еще никогда не встречал более агрессивно продвигаемых технологий чем JS-стек.
Очень надеюсь, что скоро это все закончится.
— звоните соискателю, обещайте золотые горы и пропадайте. Вообще. Капитально. Соискатель сам напишет если вдруг что — у вас есть дела и по-важнее
— ни в коем случае не смотрите на github и прочую опенсорсную активность кандидата. А если вы и уделяете этому внимание — то контрольными вопросами должно быть «сколько человек пользуется вашей поделкой?» и «как часто вы выпускаете новые релизы и общаетесь с коммьюнити?». Что ж это за соискатель такой, что даже не может раскрутить свой проект водиночку. Вам же нужен разработчик с навыками маркетолога, ведь правда?
— не доверяйте соискателю. Вообще. Он — грязное и хитрое создание, которое пришло похитить у вас деньги. Поэтому лучше вообще не говорите ему чем занимаетесь до подписания NDA, которое лучше заставить подписать прямо с порога. Помните что соискатель абсолютно ничего не понимает ни в своей профессии, ни в вашей системе, поэтому любые его предложения относительно, например, архитектуры систем надо рассматривать свысока, цокая языком, а еще лучше — обсмеивая.
— выше уже было про рассылку писем-автоответов. Я хотел бы добавить изюминку: обязательно дописывайте в конце, что по всем возникшим вопросам соискатель может не стесняться писать или звонить вам. Укажите что вы всегда готовы ответить на все вопросы. Желательно дать несуществующий e-mail и неактивный номер телефона.
— отличным ходом является дать соискателю ссылку на автоматический входной тест знаний. Сделайте его в самой убогой системе тестирования — в Moodle например. К вопросам особых требований нет. Спросите про его настрой, психологический профиль, дайте задачку на решение уравнений, накидайте вопросов по сетевым технологиям и программированию. Само собой, тест по времени стоит ограничить — ибо нефиг. Соискателей, отсеенных по результатам автоматического тестирования сразу добавляйте в бан-лист и больше никогда не рассматривайте. Автоматизация-с! И да! Ни в коем случае не предупреждайте соискателя о тесте и не предоставляйте подробностей о вопросах. Интригу надо сохранить, а хороший соискатель должен быть всегда ко всему готов. Как пионер. Больше чем пионер.
— неплохим ходом кстати является автоматическое тестирование на знание английского языка. Найдите в гугле первый попавшийся тест — их там много. Соискателя можете не предупреждать — он всегда обязан быть готов.
И помните главное: рекрутерами должны быть только женщины. Их образование, стаж работы, адекватность и психическая сбалансированность не важна. Сиськи — залог успешного найма! Ведь соискатели идут только за этим, правда?