Меня более всего воодушевляет идея добычи полезных ископаемых на отличных от земли небесных телах. В долгосрочной перспективе, при полной автоматизации процесса воспроизводства средств производства и транспортировки, можно будет сильно интенсифицировать процесс освоения космоса, имея неограниченные ресурсы
Мне кажется, что к тому моменту когда все эти желающие отуячатся, тренды сменят свое направление, к примеру в сторону художников визуализаторов. И придется за ного в 30 лет осваивать новые знания.
По моему опыту наблюдения за собой, который прошел через пяток компаний и моим другом который всю жизнь фрилансил. Скажу что все его изменения были связаны с тем что я его толкал. Так как получал ценный опыт от внутри компаний.
Китайцы говорят, что им не о чем разговаривать с тем, кто думает меньше чем на 50 лет вперёд. Какая разница будет новый шах и будет новый ишак, а система будет работать
С чего то надо начинать. Гораздо правильнее изучить существующий мировой опыт, поработать с существующими инструментами производства, выпустить продукт, основанный на этих проприетарных продуктах, а уже после этого, там где возможно заниматься постепенно замещением своими инструментами точечно. Даже если удастся в результате этой деятельности выпустить несколько собственных программных продуктов для проектирования микроконтроллеров, которые заменят собой иностранные это уже будет огромным прорывом. Процесс импортозамещения в такой интеллектуально ёмкой отрасли может спокойно себе растянуться на десятилетия это надо понимать
Ждем когда RN переведут на движки рендеринга. Тогда и посмотрим что лучше. Dart перегружен чрезмерно, и при всем этом почти полностью повторяет архитектуру JavaScript, за исключением наличия «правильного ООП». Если абстрагироваться от формы то он напоминает JS 10 летней давности. Мы уже во всю используем await, а Dart юзает Future. Я к тому, что сейчас JS становится все дружелюбнее, а Dart нет. TypeScript привычен и более гибок в настройке глубины типизации.
тогда бы уж лучше горутины (именно ГО) с каналами взяли от Go, они как поновее чем EventLoop. Вопрос конечно останется за тем будут ли они в реализации Php такими же легковесными чем в Go. Я могу ошибаться, но EventLoop -ом в этом случае становится системный планировщик задач
встроенные в язык «green threads» (аля корутины), но они есть уже даже в python
Треды суперлегкие. + Приложения с одной и та же логикой реализованные к примеру на node.js, python от 100 до 10 раз потребляют больше ресурсов (оперативная память, утилизация процессора) чем программа на Go
Всё ещё не понятно, как этот пакетный менеджер работает.
Предполагалось изначально централизованное хранилище пакетов для всех приложений на машине. Да с версиями они изначально «протупили», но уже как год, полтора в механизм управления зависимостями включено версионировании и возможность хранения зависимостей непосредственно локально с приложением.
После обновления начались проблемы с темами оформления кода. TypeScript + React, плывет форматирование элементов. (члены класса, константы, функции). Вчера несколько раз сбрасывал кеш приложения.
Да а ещё есть mobx-state-tree и даже mobx-keystone. Все опробовано в проде.
Пусть так и будет, за то зарплаты хоршие
Ещё задачи гораздо сложнее, относительно отражения ответов REST в HTML
Очень прогрессивные идеи организации системы, которых ни где больше не встретишь
Как то некрасиво звучит "веб-просмотры", webview, веб страницы встроенного браузера...
Да есть такое.
Меня более всего воодушевляет идея добычи полезных ископаемых на отличных от земли небесных телах. В долгосрочной перспективе, при полной автоматизации процесса воспроизводства средств производства и транспортировки, можно будет сильно интенсифицировать процесс освоения космоса, имея неограниченные ресурсы
Мне кажется, что к тому моменту когда все эти желающие отуячатся, тренды сменят свое направление, к примеру в сторону художников визуализаторов. И придется за ного в 30 лет осваивать новые знания.
Вот здесь сразу напрашивается изменение системы таким образом, чтобы у каждого голоса был свой вес. Осталось систему сертификации затащить )
По моему опыту наблюдения за собой, который прошел через пяток компаний и моим другом который всю жизнь фрилансил. Скажу что все его изменения были связаны с тем что я его толкал. Так как получал ценный опыт от внутри компаний.
Китайцы говорят, что им не о чем разговаривать с тем, кто думает меньше чем на 50 лет вперёд. Какая разница будет новый шах и будет новый ишак, а система будет работать
С чего то надо начинать. Гораздо правильнее изучить существующий мировой опыт, поработать с существующими инструментами производства, выпустить продукт, основанный на этих проприетарных продуктах, а уже после этого, там где возможно заниматься постепенно замещением своими инструментами точечно. Даже если удастся в результате этой деятельности выпустить несколько собственных программных продуктов для проектирования микроконтроллеров, которые заменят собой иностранные это уже будет огромным прорывом. Процесс импортозамещения в такой интеллектуально ёмкой отрасли может спокойно себе растянуться на десятилетия это надо понимать
Ну вот так судить прям говно. Может просто воспитание плохое. Ему надо к психоаналитику и коррекцию делать
.
Берите React-ioc и будет вам счастье. На 2х проектах опробован. Один с код сплиттиггом, а второй React Native
У меня, как существа проживающего в своей вселенной остался только один вопрос: "Как все это монетизировать"
нет все таки управляются Go
Треды суперлегкие. + Приложения с одной и та же логикой реализованные к примеру на node.js, python от 100 до 10 раз потребляют больше ресурсов (оперативная память, утилизация процессора) чем программа на Go
Предполагалось изначально централизованное хранилище пакетов для всех приложений на машине. Да с версиями они изначально «протупили», но уже как год, полтора в механизм управления зависимостями включено версионировании и возможность хранения зависимостей непосредственно локально с приложением.