Так одно другому не противоречит. Один человек может просто не классифицировать личные ошибки, как какие-то негативные события, так как всегда их воспринимает достаточно трезво. Другой же человек, может воспринимать ровно такие же ошибки, как личные неудачи и повод для самобичевания.
Тут все же речь идет про стиль, а не про принятие ответственности. Например, можно ошибиться, честно взять ответственность, все исправить и не думать больше об этом: простое проходное событие, не хорошее, не плохое, не запоминающееся. Можно ошибиться и долго сокрушаться по поводу собственной рукожопости, даже если все получилось исправить, прежде чем эта ошибка на что-либо повлияла, и прежде чем кто-либо еще успел эту ошибку обнаружить.
UPD. Как я понял, стиль это про то, как человек предпочитает расставлять различные акценты в описании событий. Что впрочем может отражаться и на восприятии. Но не в плане того, что именно воспринимается причиной какого-то конкретного события. А скорее это про то, какие события человек ассоциирует с плохими и хорошими в первую очередь.
Этим мыслям столько же лет, сколько и разработке ПО в принципе, и даже больше. Короткое и простое описание сложных проблем требует много усилий, и нет простого рецепта как это делать.
Когда пишешь счетчик с одной кнопкой и выводом значения на экран, возможно данное объяснение уместно. А когда приходится удерживать в голове какие-нибудь каскады данных со сложными зависимостями и множественными источниками, то начинаешь замечать, что из множества решений простеньких задач по типу получить/сохранить/вывести, простенькое решение общей задачи по работе со всем этим как-то не обнаруживается.
Если честно я не знаю специфики работы на фрилансе, но подозреваю, что если имеется какой-то более менее сложный проект, где порядок различных сущностей хранящихся в бд исчисляется сотнями, то оформлять заказ для фрилансеров на такой проект не самый эффективный способ его реализации.
Тут смотря что понимать по раздельными релизами. Сама модель NX нацелена на отслеживание связей и на кеширование, для максимально эффективной сборки различных частей проекта. Так же есть механизм для создания публикуемых библиотек в рамках монорепозитория. Но в плане CI, скорей всего придется всё тонко настраивать под требуемый рабочий процесс. Плюс в нашем случае NX работает над ангуляровской системой сборки, в которой изначально заложена возможность разделения проекта на части.
Мы в своем опыте пока отказались от отдельных релизов подсистем, так как это порождало слишком много проблем как в плане CI, так и в плане поддержки общего кода. Хотя может со временем вернемся к этой практике, так как в рабочем процессе есть некоторая необходимость этого.
Мы в итоге пришли к NX. Изначально на основном проекте была своя система сборки модулей, на основе вебпака. Потом сделали свои плагины на основе DllPlugin от вебпака, чтобы части приложения можно было подключать через манифесты, в то время module federation еще пока не было. Это позволило перейти в монорепозиторий на лерне, и в дальнейшем на сборку ангуляром с кастомными скриптами под вебпак. Сейчас собираемся перейти на NX, так как в других проектах он себя хорошо показывает. Я правда не знаю, на сколько хорошо NX интегрируется с проектами на реакте, но с ангуляром снимает очень много головной боли.
Я ориентировался на то, что завтра/полгода/год с бухты-барахты заказчик притащит команду ангулярщиков, а мы все пишем на реакте
В этом плане обычно возникает больше проблем с когерентностью, чем со сборкой, чтобы зацепить различный роутинг, туже авторизацию и т. д., но я так понял вы и сами с этим частично столкнулись. Лично для себя, я пришел к выводу, что такие вещи надо закладывать заранее, но по возможности стараться делать приложение на одном стеке. Сейчас в нашем приложении это не так, и по итогу куча самописного кода под какие-то корневые механизмы.
В целом было достаточно интересно почитать про ваш опыт. Спасибо.
Спасибо. А то все что находил это советы по типу переустановите биос, драйвера и прочее. Думал уже, что это какая-то проблема из-за переходной серии ноута.
Да просто все люди разные и процесс образования у всех разный. Помню как мало что понимал на лекциях по мат. анализу на первом курсе, а потом прочитал пару глав Фихтенгоьца, где он рассказывает про рациональные и иррациональные числа, и мгновенно сложил весь пазл про пределы, производные, ряды и интегралы. Получил свою тройку на экзамене, но до сих пор у меня нет существенных трудностей с пониманием каких-то математических выводов, хотя это понимание может быть и своеобразным. При этом легко могу представить тех, кто сдал тот же самый экзамен на отлично, но к настоящему времени уже выветрил все основы за ненадобностью.
Свой диплом я даже не стал забирать из ВУЗа, но чем дольше работаю, тем чаще обращаюсь к каким-то фундаментальным знаниям, которые дал мне ВУЗ и которые вряд ли смог получить где-то еще.
Короче это к тому, что образование -- слишком общий термин, и в разное время его могли интерпретировать по разному, как и сейчас, в зависимости от культурной среды. В России у высшего образования, к сожалению, нет престижа. Думаю тут дело в его относительной доступности, а из этого уже формируется отношение, как к процессу его получения, так и к данному явлению в целом. Факт в том, что сносно работать и зарабатывать можно и без образования. И хоть я с Вами полностью согласен, особенно относительно той пропаганды, которая существует вокруг высшего образования в нашей стране, но для многих оно оказывается действительно бесполезным.
Из личного опыта, каких-то особых предубеждений на счет курсов нет, в любом случае все зависит от человека. Бывали случаи, что молодые люди, еще буквально вчера закончившие курсы, обладали высоким самомнением, но совершенно не ориентировались в каких-то базовых концепциях изученного инструмента. Наводящие вопросы тоже не помогали, и общение не складывалось. Бывало, что человек сильно нервничал на интервью, и на все технические вопросы отвечал что ничего не знает, при этом приемлемо выполнял тестовое задание на практике и мы делали предложение.
Касательно профильного или даже просто технического образования, у меня лично, как-то проще складывается интервью с такими кандидатами. В таких случаях, зачастую, если даже человек чего-то не знает, то может очень хорошо рассуждать за счет своего кругозора.
По пет-проектам, лично мне, интереснее всего смотреть за прогрессом, то есть могу даже посмотреть историю коммитов, если есть такая возможность, чтобы оценить как и к каким решениям приходил разработчик по ходу саморазвития. Да и в целом это помогает оценить в чем и как сильно заинтерисован кандидат в плане развития профессиональных навыков.
Так я никого и не обвиняю. Просто говорю, что в профессиональном сообществе есть разные взгляды на проблему, и чем чаще будут появляться подобные обсуждения, тем быстрее кто-либо возметься за их решения. Возможно даже вплоть до юридического регулирования со сроками за кривой код, например если появятся прецеденты со смертельными исходами, но как по мне это крайне маловероятный сценарий.
Бесплатность не тождественна отстутствию ответсвенности. Возможно именно в этом автор и увидел кризис, по крайней мере в том изначальном смысле этого слова, что обвинения звучат, а каких-то средств регулирования проблемы не существует.
Да зачастую flatMap решает половину проблем связанных с reduce ...spread, и только сокращает количество скобочек. Сам я, стараюсь как можно реже допускать неявное увеличение асимптотической сложности алгоритмов. Spread оператор, мной воспринимается исключительно как средство выразительности языка. Проблема в том, что всё, так или иначе относящееся к стилю кода, обычно имеет множество субъективных критериев оценки. Не в том смысле, что это какая-то прихоть, а в том, что различные измеряемые критерии, могут быть очень важными для одних, и совершенно ничего не значить для других.
Возможно, я сильно ошибаюсь, но по моим впечатлениям Кнут проводит грань между творческим подходом к решению проблем, и постоянным повторением устаревших однообразных практик. Второй подход, как правило, и приводят к зацикливанию внимания на незначительных мелочах, в условиях перегруженной системы.
Поэтому, самое эффективное решение, в случае данной проблемы, я вижу, не в том, что бы определить как нужно, и как не нужно писать код в относительно редких случаях. А скорее, в устранении причин, которые нас подводят к составлению подобных правил. Либо в доказательстве того, что единого хорошего решения не существует, но в этом случае придется заменить экстраполяции, уходящие в бесконечность, на практические и ясные методы измерения пользы.
В остальном же, я согласен с автором на 90%. Просто потому что реальные инструменты далеки от идеальных, и сам произвожу подобные "оптимизации" практически на автомате.
На сколько я помню, Кнут стремился чуть ли не к физическим обоснованиям эффективности алгоритмов. По сути, у него делается упор не на абстрактные алгоритмы и языки, а именно на их непосредственное исполнение в физическом мире. Его слова, наверное, можно трактовать как "минимальная форма частного, зачастую не является тем, что вам действительно нужно". Я не думаю, что эта проблема имеет какой-то временной характер. И действительно, если даже брать разбор с этими спреад операторами, то это легко можно оптимизировать во время интерпретации, при условии, конечно, что прототипы базовых классов не менялись, но это уже совсем другая проблема.
Просто приватные поля, это прям приватные, единственное место где к ним можно обращаться, это в рамках класса. Символ нужен чтобы интерпретатор смог понять, что идет обращение к приватному полю. При этом обращение через obj['#private'] остается валидным, и не является обращением к приватному полю, что позволяет сохранить обратную совместимость.
рендеринг виртуальных фигур полностью контролируется пользователем — при нажатии кнопки Render пользователь осознает возможные негативные последствия, о которых говорилось выше, и готов к ним (снижение производительности является ожидаемым)
Пример показался немного странным. По сути получается, что на момент вызова колбека, уже есть вычисленный макет текущего кадра, что позволяет произвести оценку того, какое влияние оказывает изменения в DOM, на производительность рендера. Таким образом можно добавлять по столько элементов, чтобы пользователь не чувствовал заметных просадок по производительности. Просто какой смысл в пакетном добавлении элементов, если это полностью зависит от действий пользователя, которому необходимо смиряться с негативными последствиями этих действий. А данная функция, наоборот позволяет более точно контролировать эти негативные последствия, без участия со стороны пользователя.
За статью спасибо. Не знал об этой функции, и уже примерно представляю, что и где смогу улучшить с ее помощью.
Возможно имелось ввиду, что если на странице производится какие-то сложные изменения макета с просадкой фреймрейта, то все равно будут моменты с периодами ожидания. То есть даже если вычисления в колбеке requestAnimationFrame, по каким-то причинам длятся несколько фреймов, то после окончательного вычисления кадра, и до вызова следующего requestAnimationFrame, все равно пройдет некоторое время, так как их вызовы этих колбеков синхронизируются через vsync. Собственно, время после вычисления кадра и до непосредственного вывода результата, можно дополнительно загрузить полезной работой.
Вроде как с 3.38 перешли на 40, и одновременно с этим гном переехал на GTK 4.
Так одно другому не противоречит. Один человек может просто не классифицировать личные ошибки, как какие-то негативные события, так как всегда их воспринимает достаточно трезво. Другой же человек, может воспринимать ровно такие же ошибки, как личные неудачи и повод для самобичевания.
Тут все же речь идет про стиль, а не про принятие ответственности. Например, можно ошибиться, честно взять ответственность, все исправить и не думать больше об этом: простое проходное событие, не хорошее, не плохое, не запоминающееся. Можно ошибиться и долго сокрушаться по поводу собственной рукожопости, даже если все получилось исправить, прежде чем эта ошибка на что-либо повлияла, и прежде чем кто-либо еще успел эту ошибку обнаружить.
UPD. Как я понял, стиль это про то, как человек предпочитает расставлять различные акценты в описании событий. Что впрочем может отражаться и на восприятии. Но не в плане того, что именно воспринимается причиной какого-то конкретного события. А скорее это про то, какие события человек ассоциирует с плохими и хорошими в первую очередь.
Этим мыслям столько же лет, сколько и разработке ПО в принципе, и даже больше. Короткое и простое описание сложных проблем требует много усилий, и нет простого рецепта как это делать.
Когда пишешь счетчик с одной кнопкой и выводом значения на экран, возможно данное объяснение уместно. А когда приходится удерживать в голове какие-нибудь каскады данных со сложными зависимостями и множественными источниками, то начинаешь замечать, что из множества решений простеньких задач по типу получить/сохранить/вывести, простенькое решение общей задачи по работе со всем этим как-то не обнаруживается.
Если честно я не знаю специфики работы на фрилансе, но подозреваю, что если имеется какой-то более менее сложный проект, где порядок различных сущностей хранящихся в бд исчисляется сотнями, то оформлять заказ для фрилансеров на такой проект не самый эффективный способ его реализации.
Тут смотря что понимать по раздельными релизами. Сама модель NX нацелена на отслеживание связей и на кеширование, для максимально эффективной сборки различных частей проекта. Так же есть механизм для создания публикуемых библиотек в рамках монорепозитория. Но в плане CI, скорей всего придется всё тонко настраивать под требуемый рабочий процесс. Плюс в нашем случае NX работает над ангуляровской системой сборки, в которой изначально заложена возможность разделения проекта на части.
Мы в своем опыте пока отказались от отдельных релизов подсистем, так как это порождало слишком много проблем как в плане CI, так и в плане поддержки общего кода. Хотя может со временем вернемся к этой практике, так как в рабочем процессе есть некоторая необходимость этого.
Мы в итоге пришли к NX. Изначально на основном проекте была своя система сборки модулей, на основе вебпака. Потом сделали свои плагины на основе DllPlugin от вебпака, чтобы части приложения можно было подключать через манифесты, в то время module federation еще пока не было. Это позволило перейти в монорепозиторий на лерне, и в дальнейшем на сборку ангуляром с кастомными скриптами под вебпак. Сейчас собираемся перейти на NX, так как в других проектах он себя хорошо показывает. Я правда не знаю, на сколько хорошо NX интегрируется с проектами на реакте, но с ангуляром снимает очень много головной боли.
В этом плане обычно возникает больше проблем с когерентностью, чем со сборкой, чтобы зацепить различный роутинг, туже авторизацию и т. д., но я так понял вы и сами с этим частично столкнулись. Лично для себя, я пришел к выводу, что такие вещи надо закладывать заранее, но по возможности стараться делать приложение на одном стеке. Сейчас в нашем приложении это не так, и по итогу куча самописного кода под какие-то корневые механизмы.
В целом было достаточно интересно почитать про ваш опыт. Спасибо.
Смотрели ли на NX, и если да, то почему выбрали webpack module federation?
Спасибо. А то все что находил это советы по типу переустановите биос, драйвера и прочее. Думал уже, что это какая-то проблема из-за переходной серии ноута.
Можете подсказать, что за танцы с регистром?
Да просто все люди разные и процесс образования у всех разный. Помню как мало что понимал на лекциях по мат. анализу на первом курсе, а потом прочитал пару глав Фихтенгоьца, где он рассказывает про рациональные и иррациональные числа, и мгновенно сложил весь пазл про пределы, производные, ряды и интегралы. Получил свою тройку на экзамене, но до сих пор у меня нет существенных трудностей с пониманием каких-то математических выводов, хотя это понимание может быть и своеобразным. При этом легко могу представить тех, кто сдал тот же самый экзамен на отлично, но к настоящему времени уже выветрил все основы за ненадобностью.
Свой диплом я даже не стал забирать из ВУЗа, но чем дольше работаю, тем чаще обращаюсь к каким-то фундаментальным знаниям, которые дал мне ВУЗ и которые вряд ли смог получить где-то еще.
Короче это к тому, что образование -- слишком общий термин, и в разное время его могли интерпретировать по разному, как и сейчас, в зависимости от культурной среды. В России у высшего образования, к сожалению, нет престижа. Думаю тут дело в его относительной доступности, а из этого уже формируется отношение, как к процессу его получения, так и к данному явлению в целом. Факт в том, что сносно работать и зарабатывать можно и без образования. И хоть я с Вами полностью согласен, особенно относительно той пропаганды, которая существует вокруг высшего образования в нашей стране, но для многих оно оказывается действительно бесполезным.
Из личного опыта, каких-то особых предубеждений на счет курсов нет, в любом случае все зависит от человека. Бывали случаи, что молодые люди, еще буквально вчера закончившие курсы, обладали высоким самомнением, но совершенно не ориентировались в каких-то базовых концепциях изученного инструмента. Наводящие вопросы тоже не помогали, и общение не складывалось. Бывало, что человек сильно нервничал на интервью, и на все технические вопросы отвечал что ничего не знает, при этом приемлемо выполнял тестовое задание на практике и мы делали предложение.
Касательно профильного или даже просто технического образования, у меня лично, как-то проще складывается интервью с такими кандидатами. В таких случаях, зачастую, если даже человек чего-то не знает, то может очень хорошо рассуждать за счет своего кругозора.
По пет-проектам, лично мне, интереснее всего смотреть за прогрессом, то есть могу даже посмотреть историю коммитов, если есть такая возможность, чтобы оценить как и к каким решениям приходил разработчик по ходу саморазвития. Да и в целом это помогает оценить в чем и как сильно заинтерисован кандидат в плане развития профессиональных навыков.
Так я никого и не обвиняю. Просто говорю, что в профессиональном сообществе есть разные взгляды на проблему, и чем чаще будут появляться подобные обсуждения, тем быстрее кто-либо возметься за их решения. Возможно даже вплоть до юридического регулирования со сроками за кривой код, например если появятся прецеденты со смертельными исходами, но как по мне это крайне маловероятный сценарий.
Бесплатность не тождественна отстутствию ответсвенности. Возможно именно в этом автор и увидел кризис, по крайней мере в том изначальном смысле этого слова, что обвинения звучат, а каких-то средств регулирования проблемы не существует.
Да зачастую flatMap решает половину проблем связанных с reduce ...spread, и только сокращает количество скобочек. Сам я, стараюсь как можно реже допускать неявное увеличение асимптотической сложности алгоритмов. Spread оператор, мной воспринимается исключительно как средство выразительности языка. Проблема в том, что всё, так или иначе относящееся к стилю кода, обычно имеет множество субъективных критериев оценки. Не в том смысле, что это какая-то прихоть, а в том, что различные измеряемые критерии, могут быть очень важными для одних, и совершенно ничего не значить для других.
Возможно, я сильно ошибаюсь, но по моим впечатлениям Кнут проводит грань между творческим подходом к решению проблем, и постоянным повторением устаревших однообразных практик. Второй подход, как правило, и приводят к зацикливанию внимания на незначительных мелочах, в условиях перегруженной системы.
http://elib.ict.nsc.ru/jspui/bitstream/ICT/882/3/knuth_1974.pdf
Поэтому, самое эффективное решение, в случае данной проблемы, я вижу, не в том, что бы определить как нужно, и как не нужно писать код в относительно редких случаях. А скорее, в устранении причин, которые нас подводят к составлению подобных правил. Либо в доказательстве того, что единого хорошего решения не существует, но в этом случае придется заменить экстраполяции, уходящие в бесконечность, на практические и ясные методы измерения пользы.
В остальном же, я согласен с автором на 90%. Просто потому что реальные инструменты далеки от идеальных, и сам произвожу подобные "оптимизации" практически на автомате.
По сути решает валюта и транзакции. Все что касается долларов, это контролируется законами США, где обход санкций считается коррупцией.
https://www.berlingske.dk/samfund/dansk-politimand-fanget-i-amerikansk-terrornet
https://foreignpolicy.com/2012/08/10/so-you-want-to-be-a-sanctions-buster/
upd. да и в целом, это довольно старая и широкая тема различных исследований, которыми обеспокоены штаты.
На сколько я помню, Кнут стремился чуть ли не к физическим обоснованиям эффективности алгоритмов. По сути, у него делается упор не на абстрактные алгоритмы и языки, а именно на их непосредственное исполнение в физическом мире. Его слова, наверное, можно трактовать как "минимальная форма частного, зачастую не является тем, что вам действительно нужно". Я не думаю, что эта проблема имеет какой-то временной характер. И действительно, если даже брать разбор с этими спреад операторами, то это легко можно оптимизировать во время интерпретации, при условии, конечно, что прототипы базовых классов не менялись, но это уже совсем другая проблема.
Просто приватные поля, это прям приватные, единственное место где к ним можно обращаться, это в рамках класса. Символ нужен чтобы интерпретатор смог понять, что идет обращение к приватному полю. При этом обращение через
obj['#private']остается валидным, и не является обращением к приватному полю, что позволяет сохранить обратную совместимость.Пример показался немного странным. По сути получается, что на момент вызова колбека, уже есть вычисленный макет текущего кадра, что позволяет произвести оценку того, какое влияние оказывает изменения в DOM, на производительность рендера. Таким образом можно добавлять по столько элементов, чтобы пользователь не чувствовал заметных просадок по производительности. Просто какой смысл в пакетном добавлении элементов, если это полностью зависит от действий пользователя, которому необходимо смиряться с негативными последствиями этих действий. А данная функция, наоборот позволяет более точно контролировать эти негативные последствия, без участия со стороны пользователя.
За статью спасибо. Не знал об этой функции, и уже примерно представляю, что и где смогу улучшить с ее помощью.
Возможно имелось ввиду, что если на странице производится какие-то сложные изменения макета с просадкой фреймрейта, то все равно будут моменты с периодами ожидания. То есть даже если вычисления в колбеке
requestAnimationFrame, по каким-то причинам длятся несколько фреймов, то после окончательного вычисления кадра, и до вызова следующегоrequestAnimationFrame, все равно пройдет некоторое время, так как их вызовы этих колбеков синхронизируются через vsync. Собственно, время после вычисления кадра и до непосредственного вывода результата, можно дополнительно загрузить полезной работой.