Да шуршит, особенно на старых ноутбуках, где SSD нет. Там это особенно долго происходит, иногда по нескольку часов. Только я ничего не придумал, что с этим сделать: запускаешь монитор ресурсов, там на вкладке "Диск" делаешь сортировку по колонке "Всего" по убыванию и видишь... что в топе какой-то MsMpEng.exe, System c файлом C:\$Logfile, или .NET обновился, и чего-то там перекомилирует своё, непонятно что. То есть это системные процессы, если их принудительно прибить, то, скорее всего, что-нибудь сломается.
Нда, вспомнились прям старые дни, когда действительно в шароварной индустрии, казалось, можно прям заработать прилично денег и стать независимым предпринимателем. Это были ранние двухтысячные, и это время было полно энтузиазма, причем у некоторых энтузиастов, которым я имел честь помогать в то время на подсобных ролях, все-таки получилось. И в то время, для расширения кругозора, я читал книги и блог Руссиновича (где он, между всем остальным, рассказывал, как он, не имея исходников, изучал ntoskrnl и через некоторое время стал ориентироваться в этом коде чуть ли не лучше его авторов), и еще Мэтт Питрек запомнился, тоже из Microsoft, который вытворял что-то суперхитрое с компиляторными технологиями и с линкерами, что у него exe-файлы, те, которые под Windows и с MZ начинаются, весили то ли по 15, то ли по 30 килобайт, и при этом работали.
Process Explorer и Autoruns до сих пор на каждом компьютере нужны. Regmon, Filemon уже давно не приходилось запускать.
Меня вот статьи Дмитрия заставляют сначала пойти почитать комменты, как его там хейтят, а потом - задуматься. Как с лауреатами игнобелевской премии - вроде делают что-то смешное, несерьезное, получают какие-то ненужные результаты, а потом оказывается, что и работа, и результаты, хоть на первый взгляд и выглядят как-то легкомысленно, несерьезно и смешно, а на самом деле дают очень даже серьезный материал для размышлений.
Здесь, как я понимаю, предлагается задуматься о штуках, которые еще не дошли даже до мэйнстрима, и только-только доходят. Исторически мэйнстримом сначала было то, что называется сейчас "системным программированием" (ассемблер и машинные коды), потом было процедурное программирование (Си и Паскаль), потом так называемое "объектно-ориентированное" в виде Java (это вот 1996+ года), потом до мэйнстрима добралась символьно-фукнциональная парадигма (в виде (Java | Type ) Script-а, который внутри лисп), и вот сейчас начинает быть понятным, что хочется еще более удобную в использовании парадигму, которая вроде бы называется "nonmonotonic dataflow programming" (http://lambda-the-ultimate.org/node/2710#comment-40546, где по сути смешиваются функциональная и декларативная), и именно ее пытаются с разной степенью пряморукости реализовать эти библиотеки, о которых идет речь - "менеджеры состояний". Именно она может в перспективе прийти то ли на смену, то ли в дополнение к символьно-функциональной. А видели мы это еще в MS Excel в далёком 1995 году, где программирование выглядит именно так: в ячейку вводишь либо ее значение ("состояние"), либо формулу, описывающую ее зависимости от окружения, и при изменении окружения вся таблица должна пересчитаться, желательно оптимальным способом. Причём Excel проектировали люди, которые об оптимизации всего чего можно думали с самого начала (там даже формат ранних xls-файлов был двоичный, и их не надо было парсить, достаточно было прочитать в память, и нужные структуры данных после этого уже сразу располагались на своих местах, поэтому оно открывалось приемлемо быстро даже на 486-х машинах). И, имхо, именно благодаря именно Excel у пакета MS Office оказался такой потенциал, задел, и запас прочности. Word явно хуже спроектирован и сделан, не говоря о Power Point и остальном, идущем в нагрузку.
я же хочу, наоборот, поблагодарить за этот перевод. По мне, он выполнен на высоком уровне, который соотвествует уровню оригинальной статьи. (хотя, все-же, побрюзжу немного: "раскройте, чтобы увидеть текст боковой панели" - по-русски так не говорят и не пишут).
Если же немного попытаться прокомментировать по-существу, то я увидел, что в этой статье затронуты два важных взаимосвязанных момента - один практический, а другой - теоретический. Практический - что состояние P на практике хоть и возникает иногда, но очень редко, и для подавляющего большинства систем будет нормально рассматривать его как форс-мажор, когда какие-то пользовательские данные потеряются, но их будет очень мало, и, в общем, ими можно поступиться. Для остальных 2% есть, ну, например, Git, где состояние P - штатное, и вся система сконструирована под то, чтобы адекватно функционировать в этом режиме, хоть и с постоянным ручным вмешательством (которым является решение конфликтов).
Теоретический же момент, который можно усмотреть в этой статье, гораздо сложнее и интереснее. Он состоит в том, что возможно усмотреть параллель между скоростью распространения изменения в распределенной компьютерной системе и скоростью распространения света в физической реальности, описанной в СТО Эйнштейна. Эту аналогию впервые описал Лесли Лемпорт в своей известной статье "Time, Clocks, and the Ordering of Events in a Distributed System" от 1978 года, и там же он ввел понятие отношение упорядочения "happens before", которое, возвращаясь к практической стороне вопроса, первым делом всплывает в любом обучающем материале по JMM (Java Memory Model)
Хм, а ведь в Древней Греции было такое наказание - остракизм, когда человека приговаривали к изгнанию из полиса, что в те времена было почти равнозначно смертной казни. И голосование так и выглядело - собравшиеся на Агоре горожане складывали белые камни (плюс в карму) и черные (минус), и потом подсчитывали, какая чаша перевешивает. Нет, получается, ничего нового под солнцем.
Что же касается хабра, то тут, навскидку, встречаются участники, которые, скажем так обтекаемо, в общении не всегда соблюдают общепринятые конвенции. Причем не потому, что специально, с намерением оскорбить собеседника, их нарушают, а, как-будто, просто не знают о существовании этих "правил вежливости". Но они при этом прекрасные инженеры, и в сфере профессионального мастерства мне до них расти и расти. Разве буду я им ставить "минус" в карму? Минус в карму - это значит что-то вроде "Вы здесь неуместны", а профессиональные инженеры здесь как раз уместны, хоть и из-за их особенностей стиля общения не сразу получается их понимать.
Я тоже собирал бесшумный комп с дорогущим безвентиляторным сисоником, но спустя 5 лет этот БП просто стал отказываться запускать систему. То есть пока работает, всё хорошо, но если выключить, то потом может включится, а может нет. Гарантия по чеку 12 лет, но в текущей ситуации непонятно, сработает ли она. И глюк к тому же плавающий - иногда оно всё-таки работает. А поиск в интернете позволил найти только какую-то тему на форуме электронщиков, где рекомендуют уменьшать сопротивление какой-то цепочки резисторов, чтобы "компенсировать дрейф характеристик компаратора", а лезть с паяльником туда я не хочу, потому что в моем случае это будет случай "я что-то делаю, и не понимаю, что".
У вас там описочка: Наглядно показано, как различаются алгоритмы с единичной, линейной, логарифмической, квадратичной и экспоненциальной сложностью. Рассказано, почему первые — самые лучшие, а вторые — самые худшие алгоритмы.
Имелось в виду, не "вторые", а "последние" - с экспоненциальной сложностью. Да, я программист и зануда, придирающийся к деталям. Ну а как, не скомпилируется же )
Ну и упоминание Кнута в конце выглядит как некоторый снобизм. Ни разу в жизни не встречал лично разработчика, который бы этот талмуд прочёл и проработал, а в интернете видел только какие-то комментарии, один был вроде от разработчика memcached, что мол, да, теоретически работа очень основательная и академическая, но сейчас её использовать для обучения компьютерщине уже поздно, потому что далеко ушла вперёд железячная часть. Что обращение к ячейке памяти во времена Кнута было всегда O(1), а сейчас обращение к L1, L2, L3, RAM, диску или сети - это шесть совсем разных вещей, что во времена Кнута были актуальны алгоритмы сортировок для данных, которые в одну сторону прочитывались с магнитных лент, а сейчас везде используются SSD, где рандомный доступ к ячейкам не представляет проблемы, и те старые алгоритмы уже не всегда актуальны; что гипотетический компьютер MIX - это, конечно, такой прообраз понятия "виртуальная машина", но что настоящая виртуальная машина вроде JVM состоит на 80% не из интерпретатора байт-кода, а из Memory Model, GC и JIT, и поэтому обосновано хвастаться "вот я читал Кнута и понял" могут, не знаю, 20 человек из Академии.
Хехе, в результате вы в JSON-е описываете "условия" (EQUALS / NOT / AND / OR / LESS) и "операции" (HIDE_FIELDS / SET_VALUE / ...) и у вас там получается по сути описано синтаксическое дерево, которое вам надо на фронте парсить, обходить и все эти условия проверять, а операции выполнять. Можно под это дело сразу маленький диалект LISP-а запилить, или вообще присылать с бэка не JSON, а сразу Javascript :) Ещё можно сразу на WebView делать, но там UI, к сожалению, не даёт той отзывчивости, как нативные компоненты.
А так этот паттерн постоянно все переизобретают (что я и сам делал тоже). Видимо, все существующие "велосипеды", включая из них самый грандиозный (я имею в виду HTML + JS + CSS) где-то чем-то не устраивают.
Дотумкал, на что это похоже. Это как я получал один из первых загранпаспортов. Там сначала надо было прийти в 4 часа утра к ФМС чтобы разобрать номерки, на которых был написан тайм-слот, когда прийти к инспектору с документами, чтобы их подать. При этом обеспечивалось условие, что номерков ровно столько, сколько и тайм-слотов. Поэтому номерки можно было раздавать вообще рандомно, а инспектора в любом случае были равномерно весь день загружены работой.
Чтобы так не было, используйте, пожалуйста, следующие простые правила:
Если работаете с Oracle, то повесьте на таблицу триггер, который будет генерировать значение синтетического первичного ключа, используя выделенную последовательность (sequence)
Если работаете с MS SQL, используйте свойство IDENTITY на столбце с синтетическим первичным ключом прямо во время создания таблицы.
Всегда, когда нету очень веских причин против, используйте в каждой таблице синтетический первичный ключ целочисленного типа.
А если использовать конструкции вроде newId = SELECT MAX(ID) FROM MyTable + 1, рано или поздно проблемы возникнут. Потому что генерация первичного ключа - слишком важная часть логики, чтобы отдавать её любому постороннему коду. Этим должна заниматься сама СУБД.
Сам грешен, иногда на батниках разные скрипты делаю, для личного использования. Правда, если скрипт разрастается, то код становится очень непонятным, и тогда приходится переписывать его на Java, Python или другом "нормальном языке программирования".
А статья хорошая, спасибо. Про %date% и %cd% вот я даже не знал. Можно ещё добавить про shift - это способ, когда в батник надо передать больше 9 аргументов командной строки (%1, %2, вот это вот)
Я думал, как с этим бороться, но ничего лучше чем скопировать стабильную версию себе, отладить сборку на ней и следить, чтоб ничего не сломалось, не придумалось. При этом, конечно, переезд на следующую версию чего угодно (java, gradle, node, "ваш любимый фреймворк") превращается в приключение.
Например, я вот пробовал собрать JDK под Windows. Ниасилил. Там cygwin, и всё нужно каких-то определённых версий, со специфичными багами, которые компенсируют другие баги )
А я вот, хоть и люблю бухтеть "молодёжь отучилась читать, отучилась думать, куда катится мир", но вот здесь, мне показалось, тенденция уловлена верно: по степени вовлечённости общение вполне себе градуируется по шкале "живое общение нос к носу" - "видеозвонок" - "телефонный разговор" - "переписка в чате" - "обмен дипломатическими нотами" - "обмен угрозами". И чем меньше эта степень вовлечённости, тем меньше шанс прийти к консенсусу, и тем больше шанс разругаться.
Поэтому, я думаю, и образовательный процесс в норме происходит в очной форме, а "заочные" и "удалённые" форматы имеют, конечно, право на существование, и они занимают свою нишу, но они возникают не от хорошей жизни, а, что называется, "от бедности".
При этом я совсем не противник книжной формы, и читать люблю.
Спасибо, попробую.
Да шуршит, особенно на старых ноутбуках, где SSD нет. Там это особенно долго происходит, иногда по нескольку часов. Только я ничего не придумал, что с этим сделать: запускаешь монитор ресурсов, там на вкладке "Диск" делаешь сортировку по колонке "Всего" по убыванию и видишь... что в топе какой-то MsMpEng.exe, System c файлом C:\$Logfile, или .NET обновился, и чего-то там перекомилирует своё, непонятно что. То есть это системные процессы, если их принудительно прибить, то, скорее всего, что-нибудь сломается.
Нда, вспомнились прям старые дни, когда действительно в шароварной индустрии, казалось, можно прям заработать прилично денег и стать независимым предпринимателем. Это были ранние двухтысячные, и это время было полно энтузиазма, причем у некоторых энтузиастов, которым я имел честь помогать в то время на подсобных ролях, все-таки получилось. И в то время, для расширения кругозора, я читал книги и блог Руссиновича (где он, между всем остальным, рассказывал, как он, не имея исходников, изучал ntoskrnl и через некоторое время стал ориентироваться в этом коде чуть ли не лучше его авторов), и еще Мэтт Питрек запомнился, тоже из Microsoft, который вытворял что-то суперхитрое с компиляторными технологиями и с линкерами, что у него exe-файлы, те, которые под Windows и с MZ начинаются, весили то ли по 15, то ли по 30 килобайт, и при этом работали.
Process Explorer и Autoruns до сих пор на каждом компьютере нужны. Regmon, Filemon уже давно не приходилось запускать.
Меня вот статьи Дмитрия заставляют сначала пойти почитать комменты, как его там хейтят, а потом - задуматься. Как с лауреатами игнобелевской премии - вроде делают что-то смешное, несерьезное, получают какие-то ненужные результаты, а потом оказывается, что и работа, и результаты, хоть на первый взгляд и выглядят как-то легкомысленно, несерьезно и смешно, а на самом деле дают очень даже серьезный материал для размышлений.
Здесь, как я понимаю, предлагается задуматься о штуках, которые еще не дошли даже до мэйнстрима, и только-только доходят. Исторически мэйнстримом сначала было то, что называется сейчас "системным программированием" (ассемблер и машинные коды), потом было процедурное программирование (Си и Паскаль), потом так называемое "объектно-ориентированное" в виде Java (это вот 1996+ года), потом до мэйнстрима добралась символьно-фукнциональная парадигма (в виде (Java | Type ) Script-а, который внутри лисп), и вот сейчас начинает быть понятным, что хочется еще более удобную в использовании парадигму, которая вроде бы называется "nonmonotonic dataflow programming" (http://lambda-the-ultimate.org/node/2710#comment-40546, где по сути смешиваются функциональная и декларативная), и именно ее пытаются с разной степенью пряморукости реализовать эти библиотеки, о которых идет речь - "менеджеры состояний". Именно она может в перспективе прийти то ли на смену, то ли в дополнение к символьно-функциональной. А видели мы это еще в MS Excel в далёком 1995 году, где программирование выглядит именно так: в ячейку вводишь либо ее значение ("состояние"), либо формулу, описывающую ее зависимости от окружения, и при изменении окружения вся таблица должна пересчитаться, желательно оптимальным способом. Причём Excel проектировали люди, которые об оптимизации всего чего можно думали с самого начала (там даже формат ранних xls-файлов был двоичный, и их не надо было парсить, достаточно было прочитать в память, и нужные структуры данных после этого уже сразу располагались на своих местах, поэтому оно открывалось приемлемо быстро даже на 486-х машинах). И, имхо, именно благодаря именно Excel у пакета MS Office оказался такой потенциал, задел, и запас прочности. Word явно хуже спроектирован и сделан, не говоря о Power Point и остальном, идущем в нагрузку.
я же хочу, наоборот, поблагодарить за этот перевод. По мне, он выполнен на высоком уровне, который соотвествует уровню оригинальной статьи. (хотя, все-же, побрюзжу немного: "раскройте, чтобы увидеть текст боковой панели" - по-русски так не говорят и не пишут).
Если же немного попытаться прокомментировать по-существу, то я увидел, что в этой статье затронуты два важных взаимосвязанных момента - один практический, а другой - теоретический. Практический - что состояние P на практике хоть и возникает иногда, но очень редко, и для подавляющего большинства систем будет нормально рассматривать его как форс-мажор, когда какие-то пользовательские данные потеряются, но их будет очень мало, и, в общем, ими можно поступиться. Для остальных 2% есть, ну, например, Git, где состояние P - штатное, и вся система сконструирована под то, чтобы адекватно функционировать в этом режиме, хоть и с постоянным ручным вмешательством (которым является решение конфликтов).
Теоретический же момент, который можно усмотреть в этой статье, гораздо сложнее и интереснее. Он состоит в том, что возможно усмотреть параллель между скоростью распространения изменения в распределенной компьютерной системе и скоростью распространения света в физической реальности, описанной в СТО Эйнштейна. Эту аналогию впервые описал Лесли Лемпорт в своей известной статье "Time, Clocks, and the Ordering of Events in a Distributed System" от 1978 года, и там же он ввел понятие отношение упорядочения "happens before", которое, возвращаясь к практической стороне вопроса, первым делом всплывает в любом обучающем материале по JMM (Java Memory Model)
Хм, а ведь в Древней Греции было такое наказание - остракизм, когда человека приговаривали к изгнанию из полиса, что в те времена было почти равнозначно смертной казни. И голосование так и выглядело - собравшиеся на Агоре горожане складывали белые камни (плюс в карму) и черные (минус), и потом подсчитывали, какая чаша перевешивает. Нет, получается, ничего нового под солнцем.
Что же касается хабра, то тут, навскидку, встречаются участники, которые, скажем так обтекаемо, в общении не всегда соблюдают общепринятые конвенции. Причем не потому, что специально, с намерением оскорбить собеседника, их нарушают, а, как-будто, просто не знают о существовании этих "правил вежливости". Но они при этом прекрасные инженеры, и в сфере профессионального мастерства мне до них расти и расти. Разве буду я им ставить "минус" в карму? Минус в карму - это значит что-то вроде "Вы здесь неуместны", а профессиональные инженеры здесь как раз уместны, хоть и из-за их особенностей стиля общения не сразу получается их понимать.
Что-то напоминает, кажется принцип наименьшего действия. Даже с Википедией сверился, вроде так:
Только не "Data-Driven", а "Designing Data-Intensive Applications". Великолепно написанная книга, кстати.
Я тоже собирал бесшумный комп с дорогущим безвентиляторным сисоником, но спустя 5 лет этот БП просто стал отказываться запускать систему. То есть пока работает, всё хорошо, но если выключить, то потом может включится, а может нет. Гарантия по чеку 12 лет, но в текущей ситуации непонятно, сработает ли она. И глюк к тому же плавающий - иногда оно всё-таки работает. А поиск в интернете позволил найти только какую-то тему на форуме электронщиков, где рекомендуют уменьшать сопротивление какой-то цепочки резисторов, чтобы "компенсировать дрейф характеристик компаратора", а лезть с паяльником туда я не хочу, потому что в моем случае это будет случай "я что-то делаю, и не понимаю, что".
У вас там описочка: Наглядно показано, как различаются алгоритмы с единичной, линейной, логарифмической, квадратичной и экспоненциальной сложностью. Рассказано, почему первые — самые лучшие, а вторые — самые худшие алгоритмы.
Имелось в виду, не "вторые", а "последние" - с экспоненциальной сложностью. Да, я программист и зануда, придирающийся к деталям. Ну а как, не скомпилируется же )
Ну и упоминание Кнута в конце выглядит как некоторый снобизм. Ни разу в жизни не встречал лично разработчика, который бы этот талмуд прочёл и проработал, а в интернете видел только какие-то комментарии, один был вроде от разработчика memcached, что мол, да, теоретически работа очень основательная и академическая, но сейчас её использовать для обучения компьютерщине уже поздно, потому что далеко ушла вперёд железячная часть. Что обращение к ячейке памяти во времена Кнута было всегда O(1), а сейчас обращение к L1, L2, L3, RAM, диску или сети - это шесть совсем разных вещей, что во времена Кнута были актуальны алгоритмы сортировок для данных, которые в одну сторону прочитывались с магнитных лент, а сейчас везде используются SSD, где рандомный доступ к ячейкам не представляет проблемы, и те старые алгоритмы уже не всегда актуальны; что гипотетический компьютер MIX - это, конечно, такой прообраз понятия "виртуальная машина", но что настоящая виртуальная машина вроде JVM состоит на 80% не из интерпретатора байт-кода, а из Memory Model, GC и JIT, и поэтому обосновано хвастаться "вот я читал Кнута и понял" могут, не знаю, 20 человек из Академии.
Хехе, в результате вы в JSON-е описываете "условия" (EQUALS / NOT / AND / OR / LESS) и "операции" (HIDE_FIELDS / SET_VALUE / ...) и у вас там получается по сути описано синтаксическое дерево, которое вам надо на фронте парсить, обходить и все эти условия проверять, а операции выполнять. Можно под это дело сразу маленький диалект LISP-а запилить, или вообще присылать с бэка не JSON, а сразу Javascript :) Ещё можно сразу на WebView делать, но там UI, к сожалению, не даёт той отзывчивости, как нативные компоненты.
А так этот паттерн постоянно все переизобретают (что я и сам делал тоже). Видимо, все существующие "велосипеды", включая из них самый грандиозный (я имею в виду HTML + JS + CSS) где-то чем-то не устраивают.
Хабр - торт! Был.
Такая хорошая статья, а всего 12 плюсиков.
Дотумкал, на что это похоже. Это как я получал один из первых загранпаспортов. Там сначала надо было прийти в 4 часа утра к ФМС чтобы разобрать номерки, на которых был написан тайм-слот, когда прийти к инспектору с документами, чтобы их подать. При этом обеспечивалось условие, что номерков ровно столько, сколько и тайм-слотов. Поэтому номерки можно было раздавать вообще рандомно, а инспектора в любом случае были равномерно весь день загружены работой.
Чтобы так не было, используйте, пожалуйста, следующие простые правила:
Если работаете с Oracle, то повесьте на таблицу триггер, который будет генерировать значение синтетического первичного ключа, используя выделенную последовательность (sequence)
Если работаете с MS SQL, используйте свойство IDENTITY на столбце с синтетическим первичным ключом прямо во время создания таблицы.
Всегда, когда нету очень веских причин против, используйте в каждой таблице синтетический первичный ключ целочисленного типа.
А если использовать конструкции вроде newId = SELECT MAX(ID) FROM MyTable + 1, рано или поздно проблемы возникнут. Потому что генерация первичного ключа - слишком важная часть логики, чтобы отдавать её любому постороннему коду. Этим должна заниматься сама СУБД.
Сам грешен, иногда на батниках разные скрипты делаю, для личного использования. Правда, если скрипт разрастается, то код становится очень непонятным, и тогда приходится переписывать его на Java, Python или другом "нормальном языке программирования".
А статья хорошая, спасибо. Про %date% и %cd% вот я даже не знал. Можно ещё добавить про shift - это способ, когда в батник надо передать больше 9 аргументов командной строки (%1, %2, вот это вот)
Я думал, как с этим бороться, но ничего лучше чем скопировать стабильную версию себе, отладить сборку на ней и следить, чтоб ничего не сломалось, не придумалось. При этом, конечно, переезд на следующую версию чего угодно (java, gradle, node, "ваш любимый фреймворк") превращается в приключение.
Например, я вот пробовал собрать JDK под Windows. Ниасилил. Там cygwin, и всё нужно каких-то определённых версий, со специфичными багами, которые компенсируют другие баги )
это так не работает, писали в своё время на dirty
пожалуйста, не усложняйте жизнь. она и так сложная
"если ничего не помогает, прочтите инструкцию" )
А я вот, хоть и люблю бухтеть "молодёжь отучилась читать, отучилась думать, куда катится мир", но вот здесь, мне показалось, тенденция уловлена верно: по степени вовлечённости общение вполне себе градуируется по шкале "живое общение нос к носу" - "видеозвонок" - "телефонный разговор" - "переписка в чате" - "обмен дипломатическими нотами" - "обмен угрозами". И чем меньше эта степень вовлечённости, тем меньше шанс прийти к консенсусу, и тем больше шанс разругаться.
Поэтому, я думаю, и образовательный процесс в норме происходит в очной форме, а "заочные" и "удалённые" форматы имеют, конечно, право на существование, и они занимают свою нишу, но они возникают не от хорошей жизни, а, что называется, "от бедности".
При этом я совсем не противник книжной формы, и читать люблю.