Очень странно.
На i5 650, а это всего 2c4h 10 года, оно летает, и это с кучей плагинов и на огромном проекте под 100к файлов.
Но когда-то тоже сталкивался с фризами, на более мощном железе. Частично из-за hdd, частично из-за медленной отрисовки графики, частично из-за глючных плагинов.
Одно время это достало, и разобрался с вопросом раз и навсегда.
Сначала разобрался с диском — переехал на ssd, и больше на hdd шторм даже не пытался запускать, потому что это гарантированные фризы. А пока жил на hdd, пользовался рамдиском для кеша индекса: пусть лучше 2 гига памяти сожрет на кеш индекса в оперативке, чем так тормозит.
Потом разобрался с отрисовкой — убедился, что проблема не в gpu, и добавил в vmoptions ключи:
-Dawt.useSystemAAFontSettings=lcd
-Dawt.java2d.opengl=true
-Dsun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
Также разрешил кушать побольше памяти: -Xmx16g
А потом тщательно профилировал плагины: вырубил все, включал по одному, наблюдал за реакцией.
На некоторых плагинах наблюдается некорректная работа со штормом, и оно просто выжирает cpu — такие плагины поотключал, благо их оказалось немного. Большая часть таких плагинов уже упоминается в багрепортах.
«Тяжелые» по ресурсам плагины работают, и, не смотря на старое железо, не тормозят. Тормозили именно некорректно работающие — вмешивались в процессы индексирования, поиска по индексу и анализа кода, и либо падали в циклы, либо сыпали ошибками.
После этого не устанавливаю больше двух незнакомых плагинов за раз, чтобы, если вдруг опять нарвусь на подобное, не проверять все плагины.
С тех пор, как все это проделал, шторм летает.
Попробуй, может и у тебя похожие проблемы.
Ага, жить дальше:) а через год — два новая операционка, которая на старом железе не взлетает, и сразу все программы под новую систему и на старой оси не стартуют и всё. Потому хоть что то отбить — покупать сразу последнюю модель и сдавать предыдушшую. К сожалению следовать не получается.
Исходный код трудночитаемый, но предлагаемое решение выглядит еще хуже.
Я в таких случаях использую таблицы решений (decision tables). Это наглядный метод табличного описания алгоритмов, который описываются большим количеством логических операторов if и switch.
Я ними познакомился в 2000 году во время работы над проектом, который реализовывался по методологии Хэтли-Пирбхаи. С тех пор я регулярно использую их как для написания нового кода, так и для анализа существующего кода.
Это очень давно известная методика. Хорошее описание можно найти в книге издательства "Мир" 1976 года: Э.Хамби "Программирование таблиц решений".
А так ситуативный менеджмент, решают проблемы по мере поступления, планирование — на глазок плюс-минус лапоть и т. п.
А я и не спорю. Я тоже постоянно сталкиваюсь с компаниями, которые не знают что такое цикл Деминга, например. Но когда рассказываю — «так это мы всегда так и делаем, что тут такого?»
И бизнес-процессы они сами придумали, хотя даже не используют таких формулировок, как бизнес-процесс. И продажи и закупки у них планируются в какой-то системе. И только потом, они видят, что эта система — часть функций обычной ERP системы. Криво -косо, но чатсь функций реализована.
Обычно хорошо голову взрывает изучения стандарта ISO/IEC 15288 System and soft ware engineering — System life cycle processes
перевод в ГОСТ Р ИСО/МЭК 15288-2005. Тогда менеджеры и иногда программисты начинают понимать, что «все украдено до нас». Типа все уже давно придумали и реализовали, причем очень качественно. Потом идет черед стандартам ISO. И когда более-менее разобрались хотя бы в самом простом, то становится понятно: все вопросы в бизнесе давно изучены, давно есть масса готовых решений, только подбирай «кубики» из готового конструктора.
А когда менеджеры доходят до стандарта на составление стратегий и планов фирмы, да еще на стандартное представление этих планов и стратегий на специальном расширении XML. То начинают понимать, что и их работа, управление типа, тоже давно описано и переведено в рутинную форму.
Производственники тоже радуются, что вся организация работы периодических процессов, рецептуры, интеграция с разными уровнями оборудования — все тоже давно описано в этих стандартах. А софт разных фирм — только более-менее корректная форма представления и помощи для работы в этих стандартах.
Если же кому-то надо интегрировать весь этот балаган (разнородные бизнес-процессы) — то тоже все придумано в модели GERAM.
Ну а если надо детали реализации — то все есть до уровня событий, структур данных, запросов SQL, причем продумано и очень качественно (книга того же Len Silverston The Data Model Resource Book).
И так по каждому вопросу или по каждому процессу.
А вот как соединить эти процессы, или не много доработать, чтобы работало лучше, чем у конкурентов — это да, это уже реальная работа менеджеров. Да еще чтобы было стабильно во времени.
Пример этот конечно искусственный, и рассчитан он на несоответствие 11 русских времен 12 английским.
А вообще, в английском время выбрать просто:
1. Определяемся с тем, о чем говорим: О том, что есть — Present; о том, что будет — Future; о том, что было — Past.
2. Говорим о том, что знаем или что наблюдаем/чувствуем? Если о том, что знаем, то Simple.
3. Если говорим о том, что чувствуем, то наблюдаем ли мы только признаки или какие-то следы действия или же само действие? Если наблюдаем только признаки, то Perfect.
4. Если наблюдаем само действие, то сравниваем ли мы его с тем, что наблюдали/чувствовали до того? Если не сравниваем, то Progressive; если сравниваем, то Perfect Progressive.
Но в этот плагин же все равно нужно руками вбивать нужные полифиллы? Не использовать ли анализатор кода, который в каждый файл будет сам вставлять полифиллы исходя из того, что в этом файле используется, и затем конкатенировать в отдельный polyfill.js?
Благо на дворе 2020 и такой инструмент есть: browserslist + Can I Use как источник данных, какие технологии поддерживаются в целевых браузерах; @babel/preset-env c useBuiltIns: 'usage' в качестве анализатора кода и инсертера полифиллов; core-js как источник полифиллов; Webpack optimization.splitChunks для вынесения в отдельный кешируемый файл вроде polyfill.somecontenthash.js. Про год шучу, было доступно и раньше.
Этот способ позволяет точно определять необходимые полифиллы для конкретного проекта и соответствует требованиям информационной безопасности. Альтернатива — polyfill.io, внешний скрипт, в который передается вручную набор необходимых фич (например, https://polyfill.io/v3/polyfill.min.js?features=es2017), и их сервер в зависимости от User Agent включит в отдаваемый файл только те полифиллы, которые требуются конкретному браузеру. Так, современным будет отдан с размером менее 1кб, а стареньким — соответствующей возрасту толщиной. Соответственно, как внешний скрипт, на непредсказуемое время может блокировать загрузку страницы и отдавать любой код, крадущий ваши данные (даже доверяя конкретным разработчикам, надо учитывать что и Гугл раз в год бывает взломан). Но многие выбирают именно это решение, да и вообще пользуются опенсорс-пакетами, не валидируют поступающие данные, и… в общем, дело каждого.
В любом случае, думаю что оба решения получше, чем ручной подбор полифиллов (когда я подбирал вручную, ан-нет, а всегда что-то да забывалось, то Date.now забудешь, то .trim(), то Object.assign).
А статья будто из родных 00-х, удивительно сейчас такое читать, как и видеть подобный стиль кода с использованием // startHere Make some forEach
arr.forEach(function() { someLogic; })
// endHere Make some forEach
Будете ли вы дорабатывать свой «автомобиль» или нет
Одназначно буду! Я не вижу хороших альтернатив моему языку(разве что Haskell + декларативное программирование, но такой код очень тяжело скомпилировать в эффективную программу, для этого надо в ghc влить больше денег, чем за всё время в JavaScript влили).
С другой стороны — вероятность того, что вы сможете на этом самодельном автомобиле или даже вашем языке заработать — равна нулю.
Я не пытаюсь на нем заработать, всё бесплатно и по лицензии gpl3 (стандартный модуль MIT).
Но если хотите найти работу — вам нужно, условно, стать слесарем. И как «самодельщик» может искренне считать что «Toyota, по сравнению с моим пепелацем, дерьмо»… при этом искренне… но зарабатывать на жизнь он будет дорабатывая и/или ремонтируя вот это вот «дерьмо»… в программировании — всё точно так же.
Я это понимал и когда создавал язык, я мог легко выучить мэйнстримовые технологии и найти работу, но на это нужно много времени, а я хотел закончить язык, а профиль на гитхаб с компилятором был бы большим плюсом в резюме. Я не плохо знаю go(и в том числе писал на нём многопоточное приложение), возможно выучу SQL и попробую поискать работу.
Здесь дело не в chroot, а в том что мы одну и ту же символьную ссылку маунтим два раза: внутри контейнера мы переписываем ссылку на /etc/shadow, а читаем её уже с помощью kubectl logs. Выхода за пределы chroot jail не происходит.
Прочитать /etc/shadow хоста изнутри пода не получится.
Все дело в том, что не нужно позволять кому-попало маунтить что-угодно с хостов.
Нормальный подход в данной ситуации:
с помощью PodSecurityPolicy запрещаем запуск подов под рутом;
с помощью PodSecurityPolicy запрещаем все volume кроме ConfigMap, Secret, PersistentVolumeClaim + какие вам необходимы, но не HostPath/Local;
с помощью RBAC запрещаем пользователю создавать PersistentVolume, по требованию создаем для него.
Если уж заговорили про безопасность, то добавить к перечисленному еще и ResourceQuota и NetworkPolicy.
Если развёрнуто, то у меня сейчас уже больше 30 статей на тему асинхронного PHP и ReactPHP — sergeyzhuk.me/reactphp-series Правда там всё на англ языке.
Технологичный способ бросить курить не бросая.
Не бросая — это важно.
Проверено на себе и на курильщике со стажем 50 лет (желтые прокуренные пальцы и усы, бегал курить каждые 20 мин)
Способ узнал при загадочных обстоятельствах, автора не знаю. Подскажете, буду благодарен.
Всего 5 обязательных условий:
Не зарекаюсь, что бросаю курить.
Пачка сигарет всегда с собой, при любых обстоятельствах.
Когда захотелось курить, вслух признаюсь, что хочу курить: «Да, я хочу курить».
И продолжаю: — И я выбираю «не курить»/«закурить».
Выбираю закурить: выкуриваю сигарету со всем возможным наслаждением и всей ответственностью за последствия.
Выбираю не курить: тут все просто :) Не курю, однако, помню про пункт 1. Ни на 100 лет, ни на 1 миг вперед не зарекаюсь. Да, сейчас я выбрал не курить, однако не знаю, что выберу через пару секунд.
Быть в состоянии вопрошания.
Пояснения:
Пункт 2: пачка должна быть с собой в любых условиях. Дома в трениках, на пробежке в костюме, в ванной комнате, вышел на секундочку из дома в подъезд или в открытый космос.
Если пачки с собой нет, то добровольный выбор «не курить» сделать невозможно, это уже давление обстоятельств. Отсюда два следствия: курим из другой пачки и стрелкам отлуп (во всяком случае, из этой пачки стрелкам не даем).
Пункт 4а: ни друзья, ни коллеги, ни семья и, главное, ни я сам не в праве себя упрекнуть. Мой выбор – моя ответственность. ну а раз выбор сделан, то наслаждение получить обязан. Иначе нафига.
Пункт 5: состояние вопрошания – это постоянная оценка: откуда взялась привычка, какую цель я достигал в начале начал? А она (старая цель) мне все еще нужна? Могу ли я уже взрослым умом пересмотреть детский выбор. Ну и так далее, умных вопросов найдется много. Главное – быть в состоянии вопрошания по поводу привычки и всего, что с ней связано.
Пункты 3 и 4: да, надо говорить вслух :) Пусть психологи объясняют. Я проверял, без «вслух» не очень работает. Видимо, это для обратной связи надо.
Эффект по моим наблюдениям:
за неделю доза потребления падает в 2 раза, через неделю-две доходит до 1-2 сигареты в неделю. Желтопалый 56-летний курильщик со стажем курения 50 лет мне не верил. Бросил за 3 недели.
Я по привычке носил пачку (см. п.3) еще полгода, хотя перестал курить за 2 недели. Даже на трусах карман пришил, чтоб пачка была с собой в любых условиях :) Через два года проверочно покурил и все. Не курю, но не бросал.
И тут же:
Так как правильно?
На i5 650, а это всего 2c4h 10 года, оно летает, и это с кучей плагинов и на огромном проекте под 100к файлов.
Но когда-то тоже сталкивался с фризами, на более мощном железе. Частично из-за hdd, частично из-за медленной отрисовки графики, частично из-за глючных плагинов.
Одно время это достало, и разобрался с вопросом раз и навсегда.
Сначала разобрался с диском — переехал на ssd, и больше на hdd шторм даже не пытался запускать, потому что это гарантированные фризы. А пока жил на hdd, пользовался рамдиском для кеша индекса: пусть лучше 2 гига памяти сожрет на кеш индекса в оперативке, чем так тормозит.
Потом разобрался с отрисовкой — убедился, что проблема не в gpu, и добавил в vmoptions ключи:
-Dawt.useSystemAAFontSettings=lcd
-Dawt.java2d.opengl=true
-Dsun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
Также разрешил кушать побольше памяти: -Xmx16g
А потом тщательно профилировал плагины: вырубил все, включал по одному, наблюдал за реакцией.
На некоторых плагинах наблюдается некорректная работа со штормом, и оно просто выжирает cpu — такие плагины поотключал, благо их оказалось немного. Большая часть таких плагинов уже упоминается в багрепортах.
«Тяжелые» по ресурсам плагины работают, и, не смотря на старое железо, не тормозят. Тормозили именно некорректно работающие — вмешивались в процессы индексирования, поиска по индексу и анализа кода, и либо падали в циклы, либо сыпали ошибками.
После этого не устанавливаю больше двух незнакомых плагинов за раз, чтобы, если вдруг опять нарвусь на подобное, не проверять все плагины.
С тех пор, как все это проделал, шторм летает.
Попробуй, может и у тебя похожие проблемы.
Выше уже сказали, что есть много разных методов, а я позволю себе немного саморекламы.
Наглядно, хоть видео и ускорено.
Исходный код трудночитаемый, но предлагаемое решение выглядит еще хуже.
Я в таких случаях использую таблицы решений (decision tables). Это наглядный метод табличного описания алгоритмов, который описываются большим количеством логических операторов if и switch.
Я ними познакомился в 2000 году во время работы над проектом, который реализовывался по методологии Хэтли-Пирбхаи. С тех пор я регулярно использую их как для написания нового кода, так и для анализа существующего кода.
Это очень давно известная методика. Хорошее описание можно найти в книге издательства "Мир" 1976 года: Э.Хамби "Программирование таблиц решений".
Методология Хэтли-Пирбхаи, одной из составных частей которых является использование таблиц решений, описана в книге Hatley & Pirbhai "Strategies for Real Time System Specification" https://www.amazon.co.uk/gp/product/0932633110 Есть более свежее издание: https://www.amazon.co.uk/gp/product/0932633412
А я и не спорю. Я тоже постоянно сталкиваюсь с компаниями, которые не знают что такое цикл Деминга, например. Но когда рассказываю — «так это мы всегда так и делаем, что тут такого?»
И бизнес-процессы они сами придумали, хотя даже не используют таких формулировок, как бизнес-процесс. И продажи и закупки у них планируются в какой-то системе. И только потом, они видят, что эта система — часть функций обычной ERP системы. Криво -косо, но чатсь функций реализована.
Обычно хорошо голову взрывает изучения стандарта ISO/IEC 15288 System and soft ware engineering — System life cycle processes
перевод в ГОСТ Р ИСО/МЭК 15288-2005. Тогда менеджеры и иногда программисты начинают понимать, что «все украдено до нас». Типа все уже давно придумали и реализовали, причем очень качественно. Потом идет черед стандартам ISO. И когда более-менее разобрались хотя бы в самом простом, то становится понятно: все вопросы в бизнесе давно изучены, давно есть масса готовых решений, только подбирай «кубики» из готового конструктора.
А когда менеджеры доходят до стандарта на составление стратегий и планов фирмы, да еще на стандартное представление этих планов и стратегий на специальном расширении XML. То начинают понимать, что и их работа, управление типа, тоже давно описано и переведено в рутинную форму.
Производственники тоже радуются, что вся организация работы периодических процессов, рецептуры, интеграция с разными уровнями оборудования — все тоже давно описано в этих стандартах. А софт разных фирм — только более-менее корректная форма представления и помощи для работы в этих стандартах.
Если же кому-то надо интегрировать весь этот балаган (разнородные бизнес-процессы) — то тоже все придумано в модели GERAM.
Ну а если надо детали реализации — то все есть до уровня событий, структур данных, запросов SQL, причем продумано и очень качественно (книга того же Len Silverston The Data Model Resource Book).
И так по каждому вопросу или по каждому процессу.
А вот как соединить эти процессы, или не много доработать, чтобы работало лучше, чем у конкурентов — это да, это уже реальная работа менеджеров. Да еще чтобы было стабильно во времени.
Как на счёт Дженериков? Или допустили ту же ошибку, что и авторы Го?
А вообще, в английском время выбрать просто:
1. Определяемся с тем, о чем говорим: О том, что есть — Present; о том, что будет — Future; о том, что было — Past.
2. Говорим о том, что знаем или что наблюдаем/чувствуем? Если о том, что знаем, то Simple.
3. Если говорим о том, что чувствуем, то наблюдаем ли мы только признаки или какие-то следы действия или же само действие? Если наблюдаем только признаки, то Perfect.
4. Если наблюдаем само действие, то сравниваем ли мы его с тем, что наблюдали/чувствовали до того? Если не сравниваем, то Progressive; если сравниваем, то Perfect Progressive.
Благо на дворе 2020 и такой инструмент есть: browserslist + Can I Use как источник данных, какие технологии поддерживаются в целевых браузерах; @babel/preset-env c
useBuiltIns: 'usage'в качестве анализатора кода и инсертера полифиллов; core-js как источник полифиллов; Webpack optimization.splitChunks для вынесения в отдельный кешируемый файл вроде polyfill.somecontenthash.js. Про год шучу, было доступно и раньше.Этот способ позволяет точно определять необходимые полифиллы для конкретного проекта и соответствует требованиям информационной безопасности. Альтернатива — polyfill.io, внешний скрипт, в который передается вручную набор необходимых фич (например,
https://polyfill.io/v3/polyfill.min.js?features=es2017), и их сервер в зависимости от User Agent включит в отдаваемый файл только те полифиллы, которые требуются конкретному браузеру. Так, современным будет отдан с размером менее 1кб, а стареньким — соответствующей возрасту толщиной. Соответственно, как внешний скрипт, на непредсказуемое время может блокировать загрузку страницы и отдавать любой код, крадущий ваши данные (даже доверяя конкретным разработчикам, надо учитывать что и Гугл раз в год бывает взломан). Но многие выбирают именно это решение, да и вообще пользуются опенсорс-пакетами, не валидируют поступающие данные, и… в общем, дело каждого.В любом случае, думаю что оба решения получше, чем ручной подбор полифиллов (когда я подбирал вручную, ан-нет, а всегда что-то да забывалось, то Date.now забудешь, то .trim(), то Object.assign).
А статья будто из родных 00-х, удивительно сейчас такое читать, как и видеть подобный стиль кода с использованием
// startHere Make some forEach
arr.forEach(function() { someLogic; })
// endHere Make some forEach
Одназначно буду! Я не вижу хороших альтернатив моему языку(разве что Haskell + декларативное программирование, но такой код очень тяжело скомпилировать в эффективную программу, для этого надо в ghc влить больше денег, чем за всё время в JavaScript влили).
Я не пытаюсь на нем заработать, всё бесплатно и по лицензии gpl3 (стандартный модуль MIT).
Я это понимал и когда создавал язык, я мог легко выучить мэйнстримовые технологии и найти работу, но на это нужно много времени, а я хотел закончить язык, а профиль на гитхаб с компилятором был бы большим плюсом в резюме. Я не плохо знаю go(и в том числе писал на нём многопоточное приложение), возможно выучу SQL и попробую поискать работу.
Если вы начинающий, рекомендую «Бухучет за 20 минут» и «Понимаете ли вы бухгалтерский учет?».
Здесь дело не в chroot, а в том что мы одну и ту же символьную ссылку маунтим два раза: внутри контейнера мы переписываем ссылку на
/etc/shadow, а читаем её уже с помощьюkubectl logs. Выхода за пределы chroot jail не происходит.Прочитать
/etc/shadowхоста изнутри пода не получится.Все дело в том, что не нужно позволять кому-попало маунтить что-угодно с хостов.
Нормальный подход в данной ситуации:
Если уж заговорили про безопасность, то добавить к перечисленному еще и ResourceQuota и NetworkPolicy.
http://www.typescriptlang.org/play/#code/MYGwhgzhAEBiD29oG8BQ0PQgFzNglsNALZgDWApgDzQAqAFvjBQB7YUB2AJjNgJ4AHCvABmcRNAB8ACmjZGMAFx0F0AJQp0mbQCcK2AK46O0DhQDuc1ZGgBJDjjAdgFWoOoqmUrRgC+PrFwCIlJKACYaBi9Wdm5ed1FxJBkrL2UomA00bV19IxN5JgA6UIppNQD-f1RQSBgAITAdaBjOHiTNbXwuaABeaABGVGrGnRLyCjDyou7UIA
Не бросая — это важно.
Проверено на себе и на курильщике со стажем 50 лет (желтые прокуренные пальцы и усы, бегал курить каждые 20 мин)
Способ узнал при загадочных обстоятельствах, автора не знаю. Подскажете, буду благодарен.
Всего 5 обязательных условий:
Пояснения:
Пункт 2: пачка должна быть с собой в любых условиях. Дома в трениках, на пробежке в костюме, в ванной комнате, вышел на секундочку из дома в подъезд или в открытый космос.
Если пачки с собой нет, то добровольный выбор «не курить» сделать невозможно, это уже давление обстоятельств. Отсюда два следствия: курим из другой пачки и стрелкам отлуп (во всяком случае, из этой пачки стрелкам не даем).
Пункт 4а: ни друзья, ни коллеги, ни семья и, главное, ни я сам не в праве себя упрекнуть. Мой выбор – моя ответственность. ну а раз выбор сделан, то наслаждение получить обязан. Иначе нафига.
Пункт 5: состояние вопрошания – это постоянная оценка: откуда взялась привычка, какую цель я достигал в начале начал? А она (старая цель) мне все еще нужна? Могу ли я уже взрослым умом пересмотреть детский выбор. Ну и так далее, умных вопросов найдется много. Главное – быть в состоянии вопрошания по поводу привычки и всего, что с ней связано.
Пункты 3 и 4: да, надо говорить вслух :) Пусть психологи объясняют. Я проверял, без «вслух» не очень работает. Видимо, это для обратной связи надо.
Эффект по моим наблюдениям:
за неделю доза потребления падает в 2 раза, через неделю-две доходит до 1-2 сигареты в неделю. Желтопалый 56-летний курильщик со стажем курения 50 лет мне не верил. Бросил за 3 недели.
Я по привычке носил пачку (см. п.3) еще полгода, хотя перестал курить за 2 недели. Даже на трусах карман пришил, чтоб пачка была с собой в любых условиях :) Через два года проверочно покурил и все. Не курю, но не бросал.