Для меня веским аргументом для перехода на TypeScript стало как раз сокращение работы по указанию типов через JSDoc - во многих случаях компилятор прекрасно стал определять их сам, а там, где их надо указывать - все равно получалась более компактная запись.
Вот так бы я написал ваш фрагмент на TS - три строчки типы не нужно указывать - они автоматически определятся по типам полей в интерфейсе входящих параметров
константы можно сразу пакетом получить за счет деструктуризации (3 строчка)
PS: это без учета импортов, работу по которым из-за хоткеев в IDE я вообще не вижу
нет разницы, где именно в папках лежат импортируемые пакеты - если они в src, IDE их найдет. Если в node_modules - то может быть понадобится вводить вручную
Современные IDE уменьшают необходимость ручного набора.
Я вставлю тип в код, нажимаю Alt+Enter, у меня появляется список, откуда можно импортировать этот тип. Если есть только один источник - и списка не появляется, сразу автоматически ставится import
Я нажимаю Alt+Shift+O - и неиспользуемые импорты в начале файла исчезают. Так работают современные IDE.
Что касается явного указания export - это происходит по той причине, что нам нужна инкапсуляция, нам нужно открывать для доступа только самое нужное, а кишки прятать.
В Java можно обойтись только public-private, потому что там 1 класс на 1 файл. В JS/TS файле нет таких ограничений. Можно вообще хранить только функции или константы. Поэтому возникает необходимость в export - чтобы отделить внутренние функции модуля от тех, которые мы позволяем использовать.
Есть сложный алгоритм, в котором требуется координация и исполнительность многих участников.
Есть простой, хорошо рассчитываемый алгоритм, который не зависит от других участников компании.
Вот чисто по архитектуре, по принципу модульности и последующих плюшек независимости — я бы выбрал второй. Хотя всегда, конечно, надо смотреть на совокупность. Но координация народа — вещь гораздо более сложная, чем координация систем.
Что это за второй путь с потеплением?
Это выстраивать такие технологии, которые компенсируют потепление. Это разрабатывать дома, в которых одинаково комфортно будет и в Норильске, и на экваторе. Это делать города-сады, которые могут существовать и за полярным кругом, и в Сахаре. А в будущем — и на морском дне, и на Луне, и на Марсе, независимо от внешних условий.
Да, за природой надо ухаживать, а уникальную планету лучше беречь. Тут вопросов нет. Но эта уникальная планета — в ней слишком много факторов.
А вот если мы вкинем очки в компенсационные технологии, то мы устраним сразу кучу возможных будущих проблем. И от вулканических зим. И от падений астероидов. И от обезлюживания неблагоприятных климатических районов. И заодно получим кучу плюшек для будущего — для городов на Луне, для городов на дне океана, для городов где угодно.
Если у нас люди умирают от засухи, от потепления, от морозов (а они умирают, метеоусловия — это реальный фактор) — то как мы собираемся покорять другие миры? Как мы собираемся выращивать картошку на Марсе и яблони там же, если годовое изменение температуры в обычном диапазоне уже сильно сбрасывает наш урожай.
Нет, ребята, нам не нужно тормозить индустрию. Нам нужно включить её на полную мощность.
Потому что хороший дом — это независимый дом. Независимый от внешних условий. Это не гнездо из веток, это убежище и сад в одном многокубометровом флаконе.
Разработка такого флакона представляется гораздо более решаемой и гораздо более просчитываемой операцией, чем международная дипломатия и торможение индустрии.
Плюс, независимо от того, какие там причины, такой флакон дает лекарства сразу от кучи возможных проблем, как я сказал выше.
Делайте модульно, делайте независимо, делайте то, что хорошо рассчитывается и приносит сразу кучу плюсов. Вот золотое правило инженерии. И кода, кстати.
вот с генерацией текста WebGL наоборот может все замедлить, потому что текст часто обновляется, а обновление текстур стоит дорого
поэтому, к примеру, живые (векторные) тексты в Phaser 3 обновляются с заметными тормозами (особенно видно на больших списках). (речь идет об Phaser.GameObjects.Text)
Лечение — пререндер символов или использование растровых шрифтов, тут WebGL дает максимальные преимущества.
Выше есть примеры текстов в цикле, там текст живой и обновляется. Даже без WebGL это можно чудовищно ускорить, если заранее буферизовать все символы.
pS: «живой» — то есть не является статичной картинкой и у него меняются свойства, он создается заново, что требует перерисовки.
Отвечаю сам себе
— публиковать в npm не обязательно, workspaces и так интерпретируются как пакеты — если удалось все включить
Также
У workspaces есть серьезная проблема — любой запуск npm i внутри папки конкретного workspace ломает красивую идею и создает свой локальный node_modules. То есть, может это и не проблема, но декларация workspaces была в том, чтобы иметь один общий node_modules на верхнем уровне — и она не выполняется при npm i внутри папки. Значит, мы имеем сломанное обещание.
PS: попробовал перенести все общие зависимости из пакетов workspaces на самый верхний уровень — да, это работает.
То есть по идее npm i внутри workspace можно вообще не запускать, особенно если все пакеты собираются с очень близкими или одинаковыми зависимостями.
Если же нужна зависимость в отдельном модуле, то алгоритм такой
— записываем зависимость в 'package.json' этого модуля
— запускаем npm i на верхнем уровне
Вуаля — все пакеты в одном верхнем node_modules. Если нужны будут разные версии — просто в 'package.json' их и надо указать.
начало цитаты — «Расходы на производстве делятся на два типа – постоянные, которые не зависят от объема производства и прямые (переменные) – которые напрямую зависят от объемов производства. Кроме того, некоторые (непрямые) затраты будут увеличиваться с объемом производства, но не пропорционально ему.»
Допустим, мы организовали некую компанию «Нанометр» и хотим производить некий процессор «Саяны» размером 256 мм2. Для этого мы закупили оборудования на примерно $1 млрд, которое работает на 200 мм пластинах и способно выпускать 600 000 пластин в год. На одной пластине у нас получится 91 чип и пусть мы добились выхода годных в 70%, то есть с одной пластины мы будем получать 63 чипа. Используя вышеприведенные расчёты, оценим себестоимость производства таких чипов:
То есть, общая себестоимость всех произведенных чипов будет составлять $3.5-3.8 млрд.
Главный вопрос – а есть ли в России рынок для сбыта десятков миллионов процессоров (ну или любых других чипов)?
Мировой рынок полупроводников составлял около $463 млрд в 2016, российский рынок, по разным оценкам, составляет от 0.3 до 1% от мирового, т.е. где-то $2-4 млрд, что примерно равно себестоимости всей нашей продукции, а нам же хочется еще и прибыль, да и на рынке мы не одни.
Получается, что если мы хотим производить чипы для внутреннего рынка, нам нужно либо выходить на мировые рынки (и сбывать там существенную долю нашей продукции), либо загружать фабрику не полностью с соответствующим увеличением себестоимости (ну и цены для конечного потребителя).
я часто ищу универсальные решения там, где можно обойтись копипастой, и это оборачивается для меня срывом сроков
Иногда универсальное решение в принципе недостижимо. Иногда оно бессмысленно, потому что проект внезапно сворачивает в другую ветку эволюции.
Многие участки кода очень похожи, вплоть до копипасты, но у них разная судьба, разный план развития, делаешь универсальный класс и потом начинаешь все равно забивать его кастомизацией, декораторами (в ООП смысле, не в TS), наращивать сложность использования.
Многие функции и методы пишутся для того, чтобы облегчить понимание логики происходящего. Если заменить их на универсальные, читаемость от уровня «технический текст» упадет до уровня «абстрактная формула, которая непонятно что делает в нашем коде»
Некоторые функции очень коротки — настолько, что замена их на универсальную функцию не даст никакого выигрыша.
Вот пример из статьи. На какую универсальную функцию это можно заменить? Насколько короче станет код? В чем выигрыш?
const z=function(){return this};
Но тут я скорее согласен с предыдущим оратором — это похоже на заглушку на будущее, для метода, который хочется вызывать цепочкой с другими.
Но к некоторым примерам вопросов нет, они действительно загадочны. Кто пишет свою обертку для forEach? Почему для читабельности он просто не разносит разные операции над своим массивом по разным методам?
Я полагаю, такой метод может быть оправдан, если кодер думает — «сейчас я использую массив, а потом, может быть, перейду на дерево Меркла, и мне понадобится переписывать проход по нему во всех местах. Сделаю-ка я сразу делегирование прохода в метод — тогда можно будет изменить и коллекцию, и её алгоритм, не повреждая остальной код»
const z=function(a,c){this._array.forEach(a,c)};
Отдельная больная тема — как и откуда брать универсальные мелкие функции? Тащить библиотеку? Добавлять еще зависимость в проект? Потом при обновлении библиотеки проверять, не сломалось ли что-то в билде (или как вариант — сразу чинить, что сломалось)? Вот подумаешь над этим и такой
— Да ну на, лучше я сам скопипащу кодекату с реверсом строки для единственного места, где это нужно, чем буду тащить в зависимости непонятно что с непонятным в будущем результатом. Да, у меня уже есть пара таких копипаст, зато все эти классы легко перебрасываются из проекта в проект, без перетаскивания библиотек, с гарантией работы до тех пор, пока не сломается стандарт самого языка.
Дизайн очень крутой и я раньше даже хотел жить в сферическом доме (проектов на рынке достаточно), пока не послушал рассказы тех, кто пытался в нем поставить мебель, кондиционеры, телевизор.
Вкратце, проблема непрямых стен выглядит вот так
Вот это зеленое — съедется. Это при условии, что вы вообще можете подставить предмет.
По схеме на рисунке можете прикинуть, сколько площади будет отъедать любимый монитор, телевизор, сплит-система, книжный шкаф (площадь, окрашенная зеленым)
если захочется, то можно еще строчку сэкономить за счет той же деструктуризации
Для меня веским аргументом для перехода на TypeScript стало как раз сокращение работы по указанию типов через JSDoc - во многих случаях компилятор прекрасно стал определять их сам, а там, где их надо указывать - все равно получалась более компактная запись.
Вот так бы я написал ваш фрагмент на TS - три строчки
типы не нужно указывать - они автоматически определятся по типам полей в интерфейсе входящих параметров
константы можно сразу пакетом получить за счет деструктуризации (3 строчка)
PS: это без учета импортов, работу по которым из-за хоткеев в IDE я вообще не вижу
нет разницы, где именно в папках лежат импортируемые пакеты - если они в src, IDE их найдет. Если в node_modules - то может быть понадобится вводить вручную
Современные IDE уменьшают необходимость ручного набора.
Я вставлю тип в код, нажимаю Alt+Enter, у меня появляется список, откуда можно импортировать этот тип. Если есть только один источник - и списка не появляется, сразу автоматически ставится import
Я нажимаю Alt+Shift+O - и неиспользуемые импорты в начале файла исчезают. Так работают современные IDE.
Что касается явного указания export - это происходит по той причине, что нам нужна инкапсуляция, нам нужно открывать для доступа только самое нужное, а кишки прятать.
В Java можно обойтись только public-private, потому что там 1 класс на 1 файл. В JS/TS файле нет таких ограничений. Можно вообще хранить только функции или константы. Поэтому возникает необходимость в export - чтобы отделить внутренние функции модуля от тех, которые мы позволяем использовать.
Есть простой, хорошо рассчитываемый алгоритм, который не зависит от других участников компании.
Вот чисто по архитектуре, по принципу модульности и последующих плюшек независимости — я бы выбрал второй. Хотя всегда, конечно, надо смотреть на совокупность. Но координация народа — вещь гораздо более сложная, чем координация систем.
Что это за второй путь с потеплением?
Это выстраивать такие технологии, которые компенсируют потепление. Это разрабатывать дома, в которых одинаково комфортно будет и в Норильске, и на экваторе. Это делать города-сады, которые могут существовать и за полярным кругом, и в Сахаре. А в будущем — и на морском дне, и на Луне, и на Марсе, независимо от внешних условий.
Да, за природой надо ухаживать, а уникальную планету лучше беречь. Тут вопросов нет. Но эта уникальная планета — в ней слишком много факторов.
А вот если мы вкинем очки в компенсационные технологии, то мы устраним сразу кучу возможных будущих проблем. И от вулканических зим. И от падений астероидов. И от обезлюживания неблагоприятных климатических районов. И заодно получим кучу плюшек для будущего — для городов на Луне, для городов на дне океана, для городов где угодно.
Если у нас люди умирают от засухи, от потепления, от морозов (а они умирают, метеоусловия — это реальный фактор) — то как мы собираемся покорять другие миры? Как мы собираемся выращивать картошку на Марсе и яблони там же, если годовое изменение температуры в обычном диапазоне уже сильно сбрасывает наш урожай.
Нет, ребята, нам не нужно тормозить индустрию. Нам нужно включить её на полную мощность.
Потому что хороший дом — это независимый дом. Независимый от внешних условий. Это не гнездо из веток, это убежище и сад в одном многокубометровом флаконе.
Разработка такого флакона представляется гораздо более решаемой и гораздо более просчитываемой операцией, чем международная дипломатия и торможение индустрии.
Плюс, независимо от того, какие там причины, такой флакон дает лекарства сразу от кучи возможных проблем, как я сказал выше.
Делайте модульно, делайте независимо, делайте то, что хорошо рассчитывается и приносит сразу кучу плюсов. Вот золотое правило инженерии. И кода, кстати.
поэтому, к примеру, живые (векторные) тексты в Phaser 3 обновляются с заметными тормозами (особенно видно на больших списках). (речь идет об Phaser.GameObjects.Text)
Лечение — пререндер символов или использование растровых шрифтов, тут WebGL дает максимальные преимущества.
Выше есть примеры текстов в цикле, там текст живой и обновляется. Даже без WebGL это можно чудовищно ускорить, если заранее буферизовать все символы.
pS: «живой» — то есть не является статичной картинкой и у него меняются свойства, он создается заново, что требует перерисовки.
это довольно медленная операция, убирайте ее в продакшене в таких циклах
уже есть x = y = z = 12
то есть подобный смысл у обычного оператора был, надо было просто его расширить
вообще просто можно обалдеть, насколько создатели языков заняты ерундой — прямо хоть садись и пиши свой.
И да, я знаю, что напишу кучу ерунды для стороннего наблюдателя. Такова драма разработки.
Вы как хотите — но за других не решайте, это несвобода.
— публиковать в npm не обязательно, workspaces и так интерпретируются как пакеты — если удалось все включить
Также
У workspaces есть серьезная проблема — любой запуск npm i внутри папки конкретного workspace ломает красивую идею и создает свой локальный node_modules. То есть, может это и не проблема, но декларация workspaces была в том, чтобы иметь один общий node_modules на верхнем уровне — и она не выполняется при npm i внутри папки. Значит, мы имеем сломанное обещание.
PS: попробовал перенести все общие зависимости из пакетов workspaces на самый верхний уровень — да, это работает.
То есть по идее npm i внутри workspace можно вообще не запускать, особенно если все пакеты собираются с очень близкими или одинаковыми зависимостями.
Если же нужна зависимость в отдельном модуле, то алгоритм такой
— записываем зависимость в 'package.json' этого модуля
— запускаем npm i на верхнем уровне
Вуаля — все пакеты в одном верхнем node_modules. Если нужны будут разные версии — просто в 'package.json' их и надо указать.
Допустим, мы организовали некую компанию «Нанометр» и хотим производить некий процессор «Саяны» размером 256 мм2. Для этого мы закупили оборудования на примерно $1 млрд, которое работает на 200 мм пластинах и способно выпускать 600 000 пластин в год. На одной пластине у нас получится 91 чип и пусть мы добились выхода годных в 70%, то есть с одной пластины мы будем получать 63 чипа. Используя вышеприведенные расчёты, оценим себестоимость производства таких чипов:
То есть, общая себестоимость всех произведенных чипов будет составлять $3.5-3.8 млрд.
Главный вопрос – а есть ли в России рынок для сбыта десятков миллионов процессоров (ну или любых других чипов)?
Мировой рынок полупроводников составлял около $463 млрд в 2016, российский рынок, по разным оценкам, составляет от 0.3 до 1% от мирового, т.е. где-то $2-4 млрд, что примерно равно себестоимости всей нашей продукции, а нам же хочется еще и прибыль, да и на рынке мы не одни.
Получается, что если мы хотим производить чипы для внутреннего рынка, нам нужно либо выходить на мировые рынки (и сбывать там существенную долю нашей продукции), либо загружать фабрику не полностью с соответствующим увеличением себестоимости (ну и цены для конечного потребителя).
— конец цитаты
habr.com/ru/post/411995
Есть ли особенности сборки на jenkins?
Можно ли будет рассчитывать на такой мод в будущем? )
Иногда универсальное решение в принципе недостижимо. Иногда оно бессмысленно, потому что проект внезапно сворачивает в другую ветку эволюции.
Многие участки кода очень похожи, вплоть до копипасты, но у них разная судьба, разный план развития, делаешь универсальный класс и потом начинаешь все равно забивать его кастомизацией, декораторами (в ООП смысле, не в TS), наращивать сложность использования.
Многие функции и методы пишутся для того, чтобы облегчить понимание логики происходящего. Если заменить их на универсальные, читаемость от уровня «технический текст» упадет до уровня «абстрактная формула, которая непонятно что делает в нашем коде»
Некоторые функции очень коротки — настолько, что замена их на универсальную функцию не даст никакого выигрыша.
Вот пример из статьи. На какую универсальную функцию это можно заменить? Насколько короче станет код? В чем выигрыш?
Но тут я скорее согласен с предыдущим оратором — это похоже на заглушку на будущее, для метода, который хочется вызывать цепочкой с другими.
Но к некоторым примерам вопросов нет, они действительно загадочны. Кто пишет свою обертку для forEach? Почему для читабельности он просто не разносит разные операции над своим массивом по разным методам?
Я полагаю, такой метод может быть оправдан, если кодер думает — «сейчас я использую массив, а потом, может быть, перейду на дерево Меркла, и мне понадобится переписывать проход по нему во всех местах. Сделаю-ка я сразу делегирование прохода в метод — тогда можно будет изменить и коллекцию, и её алгоритм, не повреждая остальной код»
Отдельная больная тема — как и откуда брать универсальные мелкие функции? Тащить библиотеку? Добавлять еще зависимость в проект? Потом при обновлении библиотеки проверять, не сломалось ли что-то в билде (или как вариант — сразу чинить, что сломалось)? Вот подумаешь над этим и такой
— Да ну на, лучше я сам скопипащу кодекату с реверсом строки для единственного места, где это нужно, чем буду тащить в зависимости непонятно что с непонятным в будущем результатом. Да, у меня уже есть пара таких копипаст, зато все эти классы легко перебрасываются из проекта в проект, без перетаскивания библиотек, с гарантией работы до тех пор, пока не сломается стандарт самого языка.
под каждый радиус — отдельный набор
Вкратце, проблема непрямых стен выглядит вот так
Вот это зеленое — съедется. Это при условии, что вы вообще можете подставить предмет.
По схеме на рисунке можете прикинуть, сколько площади будет отъедать любимый монитор, телевизор, сплит-система, книжный шкаф (площадь, окрашенная зеленым)