Я заходил в архив хабра, там десятки постов про музыку, здоровье, спорт и строительство.
Я попытаюсь объяснить почему я оставил такой комментарий более развёрнуто: Хабр — это технический ресурс. Статьи на хабре не связанные с IT обычно тем или иным образом затрагивают технологии, к которым сообщество в целом относит физику, математику, производство и менеджмент (включая психологию менеджмента — потому что менеджмент тесно связан с IT сферой).
Ваша же статья не имеет к технологиям и IT никакого отношения: это не значит что она «плохая», но ИМХО ей место на каких-то музыкальных форумах или в соц. сетях — сюда люди происходят общаться про технологии.
Вы/другие участники могут быть не согласны с вышесказанным, тем не менее право плюсовать/минусовать остаётся за каждым — все хотят что бы Хабр был «торт», у каждого «торт» свой, поэтому местная демократия опирается на голосование. Мне лично не хочется превращать Хабр в Medium.
https://youtu.be/kEB11PQ9Eo8 — это просто забавный игровой движок который умеет искривлённые пространства произвольной конфигурации
Обе ссылки, кажется, не умеют в ОТО — но вы можете себе представить как это выглядит — представьте что эффекты на видео/в игре тем сильнее чем быстрее вы идёте (когда вы разгоняетесь, ваша энергия увеличивается и пространство под вами прогибается все сильнее).
Представьте себе воздушный шарик. Мы живём на поверхности (весь наш континуум он на поверхности шарика). Для того чтобы обмениваться информации нам нужно запускать «муравьев» которые «бегают» по шарику и переносят информацию; при этом они «продавливают» поверхность, шарик растягивается и их путь становится длиннее, при чем чем быстрее «муравей» бежит — тем сильнее эффект.
Так вот, возвращаясь к реальности, любой сигнал в нашем континууме это такой «муравей», а шарик устроен таким образом, что максимально достижимая с учетом искривления пространства скорость — это скорость света. Как вы заметили, ОТО не постулирует скорость света как предельную — это артефакт вычислений и искривления пространства под воздействием массы/энергии; кроме того, ОТО не накладывает никаких ограничений на то, как быстро может изменяться геометрия пространства. До тех пор, пока шар только растягивается (а инфляционная теория — она про растягивание) — с точки зрения муравья на шаре, нельзя бежать быстрее скорости света, нельзя даже успеть за инфляцией — поэтому и образуются отдельные «миры» — пространство убегает (растягивается) быстрее чем муравей может по нему передвигаться.
Все было бы интересней если бы пространство сжималось вместо растягивания (гуглить «пузырь алькубьерре» — тогда ситуация была бы обратной — получается что-то вроде варп двигателя; однако, мы не умеем сжимать пространство и я не слышал о том как такое было бы возможно даже гипотетически).
Это все, конечно, притянуто за уши немного, но концептуально — как-то так.
В npm пакет класть бандл — согласен. А в гит зачем?
Ну и ещё «вопросы»:
собирать дебаг или релиз?
а если я очень хочу закоммитить поломанный код в какую-то временную ветку? (решил что-то сделать по-другому, но не уверен и хочу сохранить текущий прогресс, например)
делать ли full clean перед сборкой? А если бандл собирается с нуля 2 минуты?
Но грепать в виндовс лучше все-таки в git bash или в FAR/TotalCommander. Я вот под мак осью пользуюсь консолью а в винде Тотал Командером.
Так уж вышло, что в отличии от линукс, виндовс обычно идёт вместе с UI даже если это сервер — соответственно, «ручное администрирование» заточено под UI. Ну и да, PS оперирует объектами а не потоком символов как баш — из-за этого сложные скрипты писать проще (PS почти как .NET, только синтаксис кривоват), а вот интерактивно грепать сложнее. Справедливости ради, линукс консоль тоже не очень очевидная и требует знаний типичных команд, а также их аргументов на память.
В статье вообще-то не про то что баш лучше или хуже, а про то что под WSL2 баш даже теоретически не видит объекты винды, а винда не видит объекты линукса (процессы, файлы, итп). А под WSL1 они друг друга видели, но поддерживать это оказалось сложно.
1) Expressions в их классическом применении обычно не интерпретируют и не выполняют. Вместо этого, их используют для транспиляции кода на С# в код на каком-то другом языке. Например, вы пишите на С# dataTable.Where(x => x.Parent.Id == 42).Select(x => x.Id).ToArray(), а ваш любимый ORM фреймворк превращает это в SQL запрос к базе и возвращает вам уже отфильтрованный результат: SELECT Id FROM dataTable WHERE Parent.Id = 42. Для этого ORM фреймворк «разбирает» выражение которое вы ему передали и «пересобирает» его используя синтаксис SQL; выражение в таком случае не выполняется напрямую.
2) Никакой «быстрой» рефлексии на самом деле не существует: рефлексия это всегда анализ/поиск методов/свойств/итп по имени или какому-либо другому признаку на стадии выполнения кода. По сравнению с вызовом метода по конкретному адресу вычисленному на этапе компиляции, рефлексия, конечно же, медленней. «Быстрой» она становится, когда вы начинаете кешировать результаты анализа/поиска методов, а также, срезать углы при вызове делегатов разрезолвленных рефлексией. С# это все умеет из коробки, библиотеки просто добавляют немного синтаксического сахара. При этом, сложные конструкции обычно выносят за пределы рефлексии в статические generic методы — сводя рефлексию к вычислению правильного типа для вызова такого метода. Вот пример «быстрых» вызовов: https://github.com/autofac/Autofac/blob/e662b6bace37a569eec1e42335336b3fe015855c/src/Autofac/Core/Activators/Reflection/AutowiringPropertyInjector.cs (внизу). Выглядит немного путано, зато никаких дополнительных зависимостей. Вообще, рефлексия обычно нужна в библиотеках типа ORM/DI/Mock, а их авторы стараются не притащить вместе со своей либой что-либо ещё (многие стараются выпускать библиотеки совсем без зависимостей).
3) В некоторых случаях — рефлексию можно заменить на динамику: пишете код как обычно, но вместо типов указываете dynamic — таким образом вы сообщаете языку, что компиляцию надо отложить до времени выполнения и проводить ее только тогда, когда станут известны конкретные типы входных параметров. Dynamic работает на основе «быстрой рефлексии с кешированием» и вы вряд ли сможете его оптимизировать без архитектурных изменений.
4) Если вам понадобилась рефлексия в большом объёме — возможно, вы делаете что-то не так и вместо рефлексии надо использовать какой-то паттерн проектирования или уже готовую библиотеку.
Вы зря иронизируете, «отрицательная абсолютная температура» вполне себе существует и отлично гуглится. Это как запрет делить на ноль, или запрет на взятие квадратного корня из отрицательных чисел: в школе нельзя, но если обобщить то можно.
напишите функцию замены строки ДНК на другой участок ДНК
Вот это кстати очень похоже не на задачу, а на проверку умения вытягивать из заказчика требования. И в таком контексте вопрос не плох. Я недостаточно знаком с биохимией, но там, скорее всего, есть где развернуться.
Ах да ещё хорошая новость для тех кому не хватало комбинаций с шифтами и F-ми: F клавиши никуда не делись и появляются при нажатии Fn; таким образом, тач бар не отменяет все старые комбинации а, по сути, добавляет новые (ранее модификатор Fn давал доступ к бесполезным в IDE мультимедийным клавишам)
Я тоже так думал, но недавно купил новый мак и оказалось, что если IDE полноценно поддерживает touch bar, то это дело привычки. Я пользуюсь Rider и в общем-то пропажи клавиш не заметил, стало даже удобнее: вместо ничего не значащих F-ок теперь понятные иконки и кнопки с нормальными подписями, которые меняются в зависимости от контекста и прожатых клавиш-модификаторов. Единственное что я заметил из минусов — это 1) нестабильная работа touch bar в условиях некачественной электросети (наблюдал только в поезде такое) и 2) на 13-дюймовой модели с маленькой клавиатурой кнопки на таче поначалу нажимаются непреднамеренно из-за случайно положенных на них пальцев (через месяц я таки привык не складывать пальцы куда попало).
Вот вы вроде бы все верно пишите и так можно работать, но мне кажется слишком многое получается завязанным на вас. Мне в своё время сказали одну фразу, которая сильно изменила мои приоритеты: «работа тим лида заключается в том, чтобы организовать процесс разработки таким образом, который не требует наличия тим лида»
Есть три вида лжи: ложь, наглая ложь и статистика.
Статья вроде бы про резюме, а статистика почему-то приведена на основе успешного прохождения собеседований и получения оффера. Как же так-то? Резюме ведь не влияет на успешность прохождения интервью где отсеивается большинство кандидатов...
Я попытаюсь объяснить почему я оставил такой комментарий более развёрнуто: Хабр — это технический ресурс. Статьи на хабре не связанные с IT обычно тем или иным образом затрагивают технологии, к которым сообщество в целом относит физику, математику, производство и менеджмент (включая психологию менеджмента — потому что менеджмент тесно связан с IT сферой).
Ваша же статья не имеет к технологиям и IT никакого отношения: это не значит что она «плохая», но ИМХО ей место на каких-то музыкальных форумах или в соц. сетях — сюда люди происходят общаться про технологии.
Вы/другие участники могут быть не согласны с вышесказанным, тем не менее право плюсовать/минусовать остаётся за каждым — все хотят что бы Хабр был «торт», у каждого «торт» свой, поэтому местная демократия опирается на голосование. Мне лично не хочется превращать Хабр в Medium.
Вот вам для вдохновления «вид от муравья», ну почти:
http://gamelab.mit.edu/games/a-slower-speed-of-light/ — тут можно даже поиграть — симулятор, который уменьшает скорость света
https://youtu.be/kEB11PQ9Eo8 — это просто забавный игровой движок который умеет искривлённые пространства произвольной конфигурации
Обе ссылки, кажется, не умеют в ОТО — но вы можете себе представить как это выглядит — представьте что эффекты на видео/в игре тем сильнее чем быстрее вы идёте (когда вы разгоняетесь, ваша энергия увеличивается и пространство под вами прогибается все сильнее).
Представьте себе воздушный шарик. Мы живём на поверхности (весь наш континуум он на поверхности шарика). Для того чтобы обмениваться информации нам нужно запускать «муравьев» которые «бегают» по шарику и переносят информацию; при этом они «продавливают» поверхность, шарик растягивается и их путь становится длиннее, при чем чем быстрее «муравей» бежит — тем сильнее эффект.
Так вот, возвращаясь к реальности, любой сигнал в нашем континууме это такой «муравей», а шарик устроен таким образом, что максимально достижимая с учетом искривления пространства скорость — это скорость света. Как вы заметили, ОТО не постулирует скорость света как предельную — это артефакт вычислений и искривления пространства под воздействием массы/энергии; кроме того, ОТО не накладывает никаких ограничений на то, как быстро может изменяться геометрия пространства. До тех пор, пока шар только растягивается (а инфляционная теория — она про растягивание) — с точки зрения муравья на шаре, нельзя бежать быстрее скорости света, нельзя даже успеть за инфляцией — поэтому и образуются отдельные «миры» — пространство убегает (растягивается) быстрее чем муравей может по нему передвигаться.
Все было бы интересней если бы пространство сжималось вместо растягивания (гуглить «пузырь алькубьерре» — тогда ситуация была бы обратной — получается что-то вроде варп двигателя; однако, мы не умеем сжимать пространство и я не слышал о том как такое было бы возможно даже гипотетически).
Это все, конечно, притянуто за уши немного, но концептуально — как-то так.
Вот вам лекция + стенограмма от «первоисточника» https://elementy.ru/video/251/Mnogolikaya_Vselennaya
Что это делает на хабре?
Ну… так делают:
https://github.com/lodash/lodash#download
https://github.com/facebook/react#installation
https://github.com/jashkenas/underscore
https://github.com/zloirock/core-js#installation
Для этого есть README.md где обычно написано как пользоваться библиотекой. А если не написано, то это повод усомниться в качестве библиотеки.
В npm пакет класть бандл — согласен. А в гит зачем?
Ну и ещё «вопросы»:
https://antjanus.com/blog/web-development-tutorials/how-to-grep-in-powershell/
Но грепать в виндовс лучше все-таки в git bash или в FAR/TotalCommander. Я вот под мак осью пользуюсь консолью а в винде Тотал Командером.
Так уж вышло, что в отличии от линукс, виндовс обычно идёт вместе с UI даже если это сервер — соответственно, «ручное администрирование» заточено под UI. Ну и да, PS оперирует объектами а не потоком символов как баш — из-за этого сложные скрипты писать проще (PS почти как .NET, только синтаксис кривоват), а вот интерактивно грепать сложнее. Справедливости ради, линукс консоль тоже не очень очевидная и требует знаний типичных команд, а также их аргументов на память.
В статье вообще-то не про то что баш лучше или хуже, а про то что под WSL2 баш даже теоретически не видит объекты винды, а винда не видит объекты линукса (процессы, файлы, итп). А под WSL1 они друг друга видели, но поддерживать это оказалось сложно.
Потому что:
1) Expressions в их классическом применении обычно не интерпретируют и не выполняют. Вместо этого, их используют для транспиляции кода на С# в код на каком-то другом языке. Например, вы пишите на С# dataTable.Where(x => x.Parent.Id == 42).Select(x => x.Id).ToArray(), а ваш любимый ORM фреймворк превращает это в SQL запрос к базе и возвращает вам уже отфильтрованный результат: SELECT Id FROM dataTable WHERE Parent.Id = 42. Для этого ORM фреймворк «разбирает» выражение которое вы ему передали и «пересобирает» его используя синтаксис SQL; выражение в таком случае не выполняется напрямую.
2) Никакой «быстрой» рефлексии на самом деле не существует: рефлексия это всегда анализ/поиск методов/свойств/итп по имени или какому-либо другому признаку на стадии выполнения кода. По сравнению с вызовом метода по конкретному адресу вычисленному на этапе компиляции, рефлексия, конечно же, медленней. «Быстрой» она становится, когда вы начинаете кешировать результаты анализа/поиска методов, а также, срезать углы при вызове делегатов разрезолвленных рефлексией. С# это все умеет из коробки, библиотеки просто добавляют немного синтаксического сахара. При этом, сложные конструкции обычно выносят за пределы рефлексии в статические generic методы — сводя рефлексию к вычислению правильного типа для вызова такого метода. Вот пример «быстрых» вызовов: https://github.com/autofac/Autofac/blob/e662b6bace37a569eec1e42335336b3fe015855c/src/Autofac/Core/Activators/Reflection/AutowiringPropertyInjector.cs (внизу). Выглядит немного путано, зато никаких дополнительных зависимостей. Вообще, рефлексия обычно нужна в библиотеках типа ORM/DI/Mock, а их авторы стараются не притащить вместе со своей либой что-либо ещё (многие стараются выпускать библиотеки совсем без зависимостей).
3) В некоторых случаях — рефлексию можно заменить на динамику: пишете код как обычно, но вместо типов указываете dynamic — таким образом вы сообщаете языку, что компиляцию надо отложить до времени выполнения и проводить ее только тогда, когда станут известны конкретные типы входных параметров. Dynamic работает на основе «быстрой рефлексии с кешированием» и вы вряд ли сможете его оптимизировать без архитектурных изменений.
4) Если вам понадобилась рефлексия в большом объёме — возможно, вы делаете что-то не так и вместо рефлексии надо использовать какой-то паттерн проектирования или уже готовую библиотеку.
У меня пока что все хорошо, но вам спасибо огромное за пост — добавил в закладки на будущее на всякий случай :)
// без иронии
Вы зря иронизируете, «отрицательная абсолютная температура» вполне себе существует и отлично гуглится. Это как запрет делить на ноль, или запрет на взятие квадратного корня из отрицательных чисел: в школе нельзя, но если обобщить то можно.
https://scask.ru/j_book_mph.php?id=97
Вот это кстати очень похоже не на задачу, а на проверку умения вытягивать из заказчика требования. И в таком контексте вопрос не плох. Я недостаточно знаком с биохимией, но там, скорее всего, есть где развернуться.
Поэтому основные действия должны висеть на тач баре в интерактивном режиме. А Fn — только если не хватило места.
Ах да ещё хорошая новость для тех кому не хватало комбинаций с шифтами и F-ми: F клавиши никуда не делись и появляются при нажатии Fn; таким образом, тач бар не отменяет все старые комбинации а, по сути, добавляет новые (ранее модификатор Fn давал доступ к бесполезным в IDE мультимедийным клавишам)
Я тоже так думал, но недавно купил новый мак и оказалось, что если IDE полноценно поддерживает touch bar, то это дело привычки. Я пользуюсь Rider и в общем-то пропажи клавиш не заметил, стало даже удобнее: вместо ничего не значащих F-ок теперь понятные иконки и кнопки с нормальными подписями, которые меняются в зависимости от контекста и прожатых клавиш-модификаторов. Единственное что я заметил из минусов — это 1) нестабильная работа touch bar в условиях некачественной электросети (наблюдал только в поезде такое) и 2) на 13-дюймовой модели с маленькой клавиатурой кнопки на таче поначалу нажимаются непреднамеренно из-за случайно положенных на них пальцев (через месяц я таки привык не складывать пальцы куда попало).
https://www.jetbrains.com/help/rider/Touch_Bar_Support.html
Вот вы вроде бы все верно пишите и так можно работать, но мне кажется слишком многое получается завязанным на вас. Мне в своё время сказали одну фразу, которая сильно изменила мои приоритеты: «работа тим лида заключается в том, чтобы организовать процесс разработки таким образом, который не требует наличия тим лида»
https://m.habr.com/ru/post/371071/
Есть три вида лжи: ложь, наглая ложь и статистика.
Статья вроде бы про резюме, а статистика почему-то приведена на основе успешного прохождения собеседований и получения оффера. Как же так-то? Резюме ведь не влияет на успешность прохождения интервью где отсеивается большинство кандидатов...