Из всего того, что я увидел в комментариях, нет ни одного комментария, который бы реально относился к содержанию статьи и был бы от кого-то, кто сам писал на Электроне))) Почему-то у меня сложилось именно такое мнение. Я писал на Электроне, выступал с докладом на конфах и митапах(Secon/Пенза/ и FrontendConf) и был экспертом доклада на TechTrain в прошлом году. Сразу начну с самого начала статьи. Раздел Electron. Допущена грубая неточность: Electron состоит не из двух частей, как это понимаешь из текста раздела, а из трех равно значимых частей: либа Chromium(уже собранная бинарь. Причем, в ряде случаев очень важно смотреть что за версия электрона у вас, и какая версия либы соответствует ей. Но чтоб попробовать электрон для вас это будет без разницы), NodeJS и Electron API(третья, недостающая часть). См. доку! Там говорится, что библиотека хромиума и нода входят в состав электрона и вам не придется ...(и далее по тексту доки). Но это не значит, что электрон состоит только из этих двух частей.))) Теперь смотрим на второй раздел статьи "Electron Forge". Опять вижу грубую неточность. Electron Forge - это не фрейворк. Они, конечно, стремятся стать фреймворком, но пока до этого недотягивают. Именно поэтому в доке форджа четко написано, что это набор тулз, объединенный поверх CLI для запуска полноценного пайплайна по пакетированию и дистрибуции приложения на различные ОС. Это очень важно, т.к. фордж не является полноценной системой тулз, которая обеспечит беспрепятственную разработку. Да и, вообще, Фордж - это лишь один из вариантов, как осуществить подготовку релиза десктопа, и это не самый лучший выбор для любого десктопного приложения. Что еще сразу колит глаз - вы фордж устанавливаете глобально?! Зачем это? Что, репы не хватает и надо глобально ставить? По-моему, и в рамках репы его будет достаточно установить. Теперь про раздел "Структура шаблонного приложения". Пожалуйста, прям, жирнющим текстом выделите, что в данном разделе идет речь именно о том шаблоне, который вы берете для быстрого старта, из имеющихся в фордже. Это, опять же, очень важно! Второй пункт моих уточнений по поводу запуска процессов в рамках ОС - у вас под капотом нода! Вы можете запускать множество фоновых процессов, каждый из которых будет сервисом или микросервисом. Все было верно сказано, что есть Main Process и Render Processes. НО!!! Main Process так называется не потому, что он управляет всеми остальными - эта мысль далека от реальной действительности. Этот процесс так назван потому, что он первый процесс, который запускается при инициализации приложения, и именно тот процесс, который может запускать, но не обязательно, что запускает все остальные. Этот процесс может декларировать для приложения, что в рамках его работы могут использоваться еще и другие. В рамках этого процесса стоит дефайнить ваше апи по работе с процессами вообще. Причем, работа этих процессов должна строиться по мультипроцессной модели, про которую можно почитать хотя бы тут. Упомянутые рендер процессы по факту вам будут нужны лишь для непосредственной отрисовки GUI, и все!) Не стоит из мамы делать папу))) В целом, спасибо большое за статью! Вы заставили меня вспомнить веселые времена, когда я сам разбирал электрон по болтикам, и что-то написать на хабре, хотя бы этот комментарий) И в качестве дополнения скажу еще одно - Электрон может служить и для разработки мобильных приложений. Уже есть попытки такого использования. Там вся суть в том, какие именно тулзы вы используете для подготовки релиза. Но эти попытки пока остаются попытками. Ничего достойного пока не получилось))) У меня был реальный очень успешный опыт в сфере IoT при разработке касс самообслуживания для торговых сетей Перекресток, Пятерочка, Карусель, Дарвин и др. Поэтому могу с уверенностью сказать, что для сферы IoT Электрон будет в полной мере выполнять все, что вам надо) Также, у меня был опыт ковыряний Qt. На Qt можно написать любое приложение c GUI, но пока в нем разберешься, чтоб хотя бы установить этот фреймворк себе на локальную машину, а, тем более, как там можно создавать десктопы - поседеешь парочку раз точно)
Джава и хороша своей строгой типизацией, и в этом же её недостаток, т.к. в ряде случаев приходится писать дополнительные конструкции для соблюдения этой строгой типизации. Впрочем, эта история характерна для любого кода, где присутствует строгая типизация. Я писал на Электроне и скажу так - надо быстро выпустить работающий прототип десктопа - Электрон в помощь! А уже потом или отдельные части, или все приложение в целом переводится на другой язык программирования по мере необходимости и в случаях, где приложение начинает работать нестабильно или с низкой производительностью. Но... Если надо попробовать запустить какую-то бизнес идею и хотя бы проверить ее на прибыльность, то почему надо сразу брать Джаву, нанимать множество разработчиков и пилить серьезный десктоп?
В корне не согласен с этим заявлением. Это заявление не имеет реального обоснования! И если уж говорить про десктоп - то Электрон идеально подойдет для реализации именно графического интерфейса, а вот сервисы, которые понадобятся для стабильной работы приложения - здесь можно делать что угодно и как угодно. Можно хоть на расте написать, скомпилить и запускать в обертке под нодой)
Да, конечно)
Смотрите, сразу конкретизирую категориальный аппарат: инженеры-разработчики в моем понимании — это в первую очередь весьма талантливые, творческие и свободолюбивые личности, способные в полной мере к самоорганизации. Поэтому, изначально названная мою специфика определяет, что результаты исследований в рамках коллектива военнослужащих(в основном, военнослужащий — это исполнитель приказов) не могут быть в полной мере применимы к командам инженеров-разработчиков. Отдельные части — может быть)
Сейчас смогу назвать несколько работ, но постараюсь дать вам и другие)
Старых С.А. Управление мотивацией персонала инновационных организаций. 2020
Работы и исследования Латуха Марины Олеговны. Автореферат ее докторской диссертации можно посмотреть тут
Мондрус О.В. Система управления талантами в российских компаниях. 2018
Полякова Е.Ю. Интеграция работников иностранного происхождения на российском рынке труда. 2017
Рябкова Л.А. Ценностные ориентации личности в процессе карьерного роста. 2019
Цыбикова А.А. Формирование механизма управления конфликтами интересов на государственной гражданской службе. 2011
Цыбова В.С. Разработка модели управления человеческими ресурсами в инновационно-активных компаниях. 2014
Альхазалех Р.М.А. Разработка модели и механизма управления кадровым потенциалом молодежных организаций. 2020
Научная работа является частным случаем творческой работы. Поэтому — Войтикова М.А. Психологические детерминанты эффективного управления кадровой работой научной организации. 2020
Горчаков С.Е. Совершенствование управления организационным поведением в научных организациях.2020
Данилова Н.Е. Формирование стратегий управления персоналом в общественных некоммерческих организациях. 2020
Можно эту работу тоже посмотреть. И эту тут
Пелевина, Ирина Михайловна. Социально-психологическое обеспечение командного взаимодействия в контексте организационной культуры
Халина, Анна Александровна. Командообразование как процесс и технология в организационном управлении
Эти работы свежие. Вместе с тем, каждая диссертационная работа в самом начале содержит актуальность исследования, где указываются исследователи и ранее проводившиеся исследования ;)
В целом, стоит копать на стыке научных направлений — социальная психология, педагогика и психология профессиональной деятельности, менеджмент и научная организация труда)
Ахахахаха))) Дуров прикрывает кормушку, где народ из воздуха подымал приличные деньги))) Это я про рекламу в каналах. Ну, как бы, низкий поклон ему за это нововведение))) Ибо нефиг)))
Александр, здравствуйте!) Спасибо большое за статью! Было весьма и весьма интересно читать. Вы знаете, правда, Брюс Такман не был первооткрывателем опубликованных им результатов исседований по формированию и сплочению команды. В советских силовых структурах команду называли коллективом. Но от этого смысл и суть дела не поменялись)))
Усилиями научных работников ВПА в советкой армии проводилось множество исследований, среди которых можно увидеть массу работ по формированию коллектива, сплочению коллектива, совместному оптимально организованному выполнению служебных задач, развитию коммуникаций между сослуживцами внутри подразделения, развитию положительно влияющей на военнослужащего социальной среды. Было много диссертаций и НИР'ов про формирование психической устойчивости к тяжелым нагрузкам и критическим ситуациям в условиях угрозы жизни человека. И так можно долго говорить о тех направлениях исследований, что проводились и проводятся отечественными учеными. Кроме того, каждое диссертационное исследование любого отечественного ученого-исследователя в целом намного обширнее, объективнее и в плане научной ценности гораздо значимей))) Вместе с тем, подобные исследования никто и никогда в нашей стране не афишировал публично, тем более, на весь мир. Это тоже самое, что и с историей открытия радио. В США свои изобретатели и первооткрыватели, в Германии — свои, а у нас свои))) Поэтому, хотел порекомендовать проанализировать научные работы российских ученых для наиболее ясного понимания данной темы. Открытых диссертаций и научных трудов у нас в стране также очень-очень много ;)
В дополнение к статье) Я думаю, что весь код воркера стоит разбивать на составляющие и, тем самым, параллелить выполнение наиболее затратных операций и методов в самих воркерах. Каждому воркеру стоит назначать не более трех функций. Т.о., весь код, перенесенный в воркеры, будет значительно быстрее отрабатывать.
Т.е. можно запустить целую группу воркеров, которые, в целом, могут быть организованы так, как описывается в микросервисной архитектуре. Я, единственное, не знаю, как множество одновременно работающих воркеров будет потреблять ресурсы)))
Из всего того, что я увидел в комментариях, нет ни одного комментария, который бы реально относился к содержанию статьи и был бы от кого-то, кто сам писал на Электроне))) Почему-то у меня сложилось именно такое мнение. Я писал на Электроне, выступал с докладом на конфах и митапах(Secon/Пенза/ и FrontendConf) и был экспертом доклада на TechTrain в прошлом году.
Сразу начну с самого начала статьи. Раздел Electron. Допущена грубая неточность: Electron состоит не из двух частей, как это понимаешь из текста раздела, а из трех равно значимых частей: либа Chromium(уже собранная бинарь. Причем, в ряде случаев очень важно смотреть что за версия электрона у вас, и какая версия либы соответствует ей. Но чтоб попробовать электрон для вас это будет без разницы), NodeJS и Electron API(третья, недостающая часть). См. доку! Там говорится, что библиотека хромиума и нода входят в состав электрона и вам не придется ...(и далее по тексту доки). Но это не значит, что электрон состоит только из этих двух частей.)))
Теперь смотрим на второй раздел статьи "Electron Forge". Опять вижу грубую неточность. Electron Forge - это не фрейворк. Они, конечно, стремятся стать фреймворком, но пока до этого недотягивают. Именно поэтому в доке форджа четко написано, что это набор тулз, объединенный поверх CLI для запуска полноценного пайплайна по пакетированию и дистрибуции приложения на различные ОС. Это очень важно, т.к. фордж не является полноценной системой тулз, которая обеспечит беспрепятственную разработку. Да и, вообще, Фордж - это лишь один из вариантов, как осуществить подготовку релиза десктопа, и это не самый лучший выбор для любого десктопного приложения. Что еще сразу колит глаз - вы фордж устанавливаете глобально?! Зачем это? Что, репы не хватает и надо глобально ставить? По-моему, и в рамках репы его будет достаточно установить.
Теперь про раздел "Структура шаблонного приложения". Пожалуйста, прям, жирнющим текстом выделите, что в данном разделе идет речь именно о том шаблоне, который вы берете для быстрого старта, из имеющихся в фордже. Это, опять же, очень важно! Второй пункт моих уточнений по поводу запуска процессов в рамках ОС - у вас под капотом нода! Вы можете запускать множество фоновых процессов, каждый из которых будет сервисом или микросервисом. Все было верно сказано, что есть Main Process и Render Processes. НО!!! Main Process так называется не потому, что он управляет всеми остальными - эта мысль далека от реальной действительности. Этот процесс так назван потому, что он первый процесс, который запускается при инициализации приложения, и именно тот процесс, который может запускать, но не обязательно, что запускает все остальные. Этот процесс может декларировать для приложения, что в рамках его работы могут использоваться еще и другие. В рамках этого процесса стоит дефайнить ваше апи по работе с процессами вообще. Причем, работа этих процессов должна строиться по мультипроцессной модели, про которую можно почитать хотя бы тут. Упомянутые рендер процессы по факту вам будут нужны лишь для непосредственной отрисовки GUI, и все!) Не стоит из мамы делать папу)))
В целом, спасибо большое за статью! Вы заставили меня вспомнить веселые времена, когда я сам разбирал электрон по болтикам, и что-то написать на хабре, хотя бы этот комментарий) И в качестве дополнения скажу еще одно - Электрон может служить и для разработки мобильных приложений. Уже есть попытки такого использования. Там вся суть в том, какие именно тулзы вы используете для подготовки релиза. Но эти попытки пока остаются попытками. Ничего достойного пока не получилось))) У меня был реальный очень успешный опыт в сфере IoT при разработке касс самообслуживания для торговых сетей Перекресток, Пятерочка, Карусель, Дарвин и др. Поэтому могу с уверенностью сказать, что для сферы IoT Электрон будет в полной мере выполнять все, что вам надо) Также, у меня был опыт ковыряний Qt. На Qt можно написать любое приложение c GUI, но пока в нем разберешься, чтоб хотя бы установить этот фреймворк себе на локальную машину, а, тем более, как там можно создавать десктопы - поседеешь парочку раз точно)
Hahahaha! Windows must die, Linux forever!
Джава и хороша своей строгой типизацией, и в этом же её недостаток, т.к. в ряде случаев приходится писать дополнительные конструкции для соблюдения этой строгой типизации. Впрочем, эта история характерна для любого кода, где присутствует строгая типизация. Я писал на Электроне и скажу так - надо быстро выпустить работающий прототип десктопа - Электрон в помощь! А уже потом или отдельные части, или все приложение в целом переводится на другой язык программирования по мере необходимости и в случаях, где приложение начинает работать нестабильно или с низкой производительностью. Но... Если надо попробовать запустить какую-то бизнес идею и хотя бы проверить ее на прибыльность, то почему надо сразу брать Джаву, нанимать множество разработчиков и пилить серьезный десктоп?
В корне не согласен с этим заявлением. Это заявление не имеет реального обоснования! И если уж говорить про десктоп - то Электрон идеально подойдет для реализации именно графического интерфейса, а вот сервисы, которые понадобятся для стабильной работы приложения - здесь можно делать что угодно и как угодно. Можно хоть на расте написать, скомпилить и запускать в обертке под нодой)
Смотрите, сразу конкретизирую категориальный аппарат: инженеры-разработчики в моем понимании — это в первую очередь весьма талантливые, творческие и свободолюбивые личности, способные в полной мере к самоорганизации. Поэтому, изначально названная мою специфика определяет, что результаты исследований в рамках коллектива военнослужащих(в основном, военнослужащий — это исполнитель приказов) не могут быть в полной мере применимы к командам инженеров-разработчиков. Отдельные части — может быть)
Сейчас смогу назвать несколько работ, но постараюсь дать вам и другие)
Старых С.А. Управление мотивацией персонала инновационных организаций. 2020
Работы и исследования Латуха Марины Олеговны. Автореферат ее докторской диссертации можно посмотреть тут
Мондрус О.В. Система управления талантами в российских компаниях. 2018
Полякова Е.Ю. Интеграция работников иностранного происхождения на российском рынке труда. 2017
Рябкова Л.А. Ценностные ориентации личности в процессе карьерного роста. 2019
Цыбикова А.А. Формирование механизма управления конфликтами интересов на государственной гражданской службе. 2011
Цыбова В.С. Разработка модели управления человеческими ресурсами в инновационно-активных компаниях. 2014
Альхазалех Р.М.А. Разработка модели и механизма управления кадровым потенциалом молодежных организаций. 2020
Научная работа является частным случаем творческой работы. Поэтому — Войтикова М.А. Психологические детерминанты эффективного управления кадровой работой научной организации. 2020
Горчаков С.Е. Совершенствование управления организационным поведением в научных организациях.2020
Данилова Н.Е. Формирование стратегий управления персоналом в общественных некоммерческих организациях. 2020
Можно эту работу тоже посмотреть. И эту тут
Пелевина, Ирина Михайловна. Социально-психологическое обеспечение командного взаимодействия в контексте организационной культуры
Халина, Анна Александровна. Командообразование как процесс и технология в организационном управлении
Эти работы свежие. Вместе с тем, каждая диссертационная работа в самом начале содержит актуальность исследования, где указываются исследователи и ранее проводившиеся исследования ;)
В целом, стоит копать на стыке научных направлений — социальная психология, педагогика и психология профессиональной деятельности, менеджмент и научная организация труда)
Усилиями научных работников ВПА в советкой армии проводилось множество исследований, среди которых можно увидеть массу работ по формированию коллектива, сплочению коллектива, совместному оптимально организованному выполнению служебных задач, развитию коммуникаций между сослуживцами внутри подразделения, развитию положительно влияющей на военнослужащего социальной среды. Было много диссертаций и НИР'ов про формирование психической устойчивости к тяжелым нагрузкам и критическим ситуациям в условиях угрозы жизни человека. И так можно долго говорить о тех направлениях исследований, что проводились и проводятся отечественными учеными. Кроме того, каждое диссертационное исследование любого отечественного ученого-исследователя в целом намного обширнее, объективнее и в плане научной ценности гораздо значимей))) Вместе с тем, подобные исследования никто и никогда в нашей стране не афишировал публично, тем более, на весь мир. Это тоже самое, что и с историей открытия радио. В США свои изобретатели и первооткрыватели, в Германии — свои, а у нас свои))) Поэтому, хотел порекомендовать проанализировать научные работы российских ученых для наиболее ясного понимания данной темы. Открытых диссертаций и научных трудов у нас в стране также очень-очень много ;)
Т.е. можно запустить целую группу воркеров, которые, в целом, могут быть организованы так, как описывается в микросервисной архитектуре. Я, единственное, не знаю, как множество одновременно работающих воркеров будет потреблять ресурсы)))