Задача второй части — внести наибольший вклад в открытые Rust-проекты. Под вкладом подразумевается добавление/изменение кода на языке Rust путем публикации Pull Request с указанием участия в конкурсе и ссылки на RustCon Russia.
Это выглядит как требование рекламного спама, а ля "репостни запись и тегни друзей". Не уверен, что это будет хорошей рекламой вашей конференции.
Насколько понял из описания, суть jj в том, что если у коммита поменять родителя - то это все еще будет тот же коммит. В отличие от git, где это уже новый коммит с новым хешем.
Поэтому обычно как раз-таки удобнее считать коммиты в git не патчами, а именно снепшотами. Один хеш - одно состояние кода.
Если не секрет: почему вы обратились к таким паттернам вместо того, чтобы просто попросить пользователя убрать галочку в настройках? Мне кажется, ваши пользователи вполне в состоянии понять, почему оповещения от вашего приложения не нужно разрешать приостанавливать.
А в текущем варианте - особенно из-за пункта "умышленно сделаем неинформативно" - я вот для себя решил, что вашим приложением пользоваться не буду.
Проблема в том, что для юзкейса "просто база данных" у блокчейна, по сравнению с обычными СУБД, есть только недостатки. Из преимуществ - разве что +1 buzzword для маркетинга.
В случае Power Ledger ситуация аналогична. У них реализована платформа TraceX, которая использует блокчейн для хранения информации о всех данных, в том числе о транзакциях. Работает это не как в крипте и не требует для записи данных "жечь килловат-часы" :)
Вы себе противоречие. Блокчейн - он же, по определению, считает кучу хэшей. Если не так - то это не блокчейн, а что-то ещё. Если переубедите меня - буду рад, но пока что не верю.
Большие объекты никогда не удаляются сборщиком мусора.
Это очевидная неправда, или, по крайней мере, сформулировано слишком уж криво. Проверить достаточно просто - запустите цикл, создающий большие массивы или Bufferы, но не сохраняющий на них ссылки, и посмотрите на потребление памяти этой программой.
Правда в том, что они, разумеется, удаляются сборщиком - но лежат в отдельном месте памяти, и никогда за время жизни не перемещаются. Интуиция в том, что из-за того, что эти объекты большие, перемещать их дорого. Но из-за их размера, их обычно не так много - поэтому в этом их отдельном пространстве фрагментация будет меньшей проблемой.
Но если мы просто загоним все ноды в список, а потом их всех автоматически соединит for-цикл, мы получим очень удобный формат для манипуляций с нодами внутри списка
На самом деле, A.connect(B) всегда возвращает B. Поэтому можно ещё и вот так:
Как я понял, в вашей библиотеке именно клиент зависимости управляет тем, как она будет создана, с помощью вот этой сложной системы идентификаторов. Но мне кажется, что от DI скорее ждут того, чтобы клиент получал уже готовую зависимость. То, как ее можно создавать - фабрикой или конструктором, например - могла бы сообщать контейнеру сама зависимость. А синглтоном она будет или нет, кажется, должно решать само приложение, тот его код и конфигурация, которые собирают все модули воедино.
Более того, насколько вижу, у вас структура этих идентификаторов получается привязанной к пути к файлу с реализацией зависимости - а как при этом зависеть от интерфейса, а не конкретной реализации?
В итоге, ваши примеры кажутся полностью идентичными просто обычным импортам, без каких-либо преимуществ. Мы все так же просто указываем файл с реализацией зависимости и как ее создать - просто теперь почему-то в виде отдельного DSL.
А какой в таком ядре будет pid у idle-таска? Тоже 0?
В целом, я был бы рад, если бы вы подробнее расписали, в чем автор не прав, как именно распределяются pid, и при каких обстоятельствах он может быть 0 (почему-то же в том коде стоит = 1 вместо = 0).
А какой ущерб в итоге можно нанести такой атакой? Без этой детали статья походит на возмущения хакера по поводу солонки из известной байки.
Это выглядит как требование рекламного спама, а ля "репостни запись и тегни друзей". Не уверен, что это будет хорошей рекламой вашей конференции.
Насколько понял из описания, суть
jjв том, что если у коммита поменять родителя - то это все еще будет тот же коммит. В отличие отgit, где это уже новый коммит с новым хешем.Поэтому обычно как раз-таки удобнее считать коммиты в git не патчами, а именно снепшотами. Один хеш - одно состояние кода.
Если не секрет: почему вы обратились к таким паттернам вместо того, чтобы просто попросить пользователя убрать галочку в настройках? Мне кажется, ваши пользователи вполне в состоянии понять, почему оповещения от вашего приложения не нужно разрешать приостанавливать.
А в текущем варианте - особенно из-за пункта "умышленно сделаем неинформативно" - я вот для себя решил, что вашим приложением пользоваться не буду.
А нарисуйте. Мне теперь даже интересно понять, в каком именно месте там будет ошибка.
Как профессионал, вы должня знать о UTF-8, UCS-2, UTF-16, и о том, на каком из них основан API строк в Java.
Я понимаю, что по заголовку статьи это не так понятно, но в ней идет речь именно про ключевые слова
typeиinterfaceв TypeScript.Насколько понимаю, это было вынужденно - нужно было натянуть статические типы на очень динамические интерфейсы уже существующих JS-библиотек.
A & B- это объединение известных утверждений про типы A и B (вида "у этого типа есть поле А), но пересечение множеств значений этих типов.Разность множеств значений можно выразить через встроенный тип
Exclude<A, B>. Симметрическая разность - это, соответственно,Exclude<A | B, A & B>.А ещё "ИИ", как мы видим, может писать статьи на Хабр.
Проблема в том, что для юзкейса "просто база данных" у блокчейна, по сравнению с обычными СУБД, есть только недостатки. Из преимуществ - разве что +1 buzzword для маркетинга.
Вы себе противоречие. Блокчейн - он же, по определению, считает кучу хэшей. Если не так - то это не блокчейн, а что-то ещё. Если переубедите меня - буду рад, но пока что не верю.
К половине из примеров, если не больше, есть вопрос: почему не просто база данных?
А Power Ledger выглядит вообще как-то даже цинично - жечь киловатт-часы, считая хеши, но во имя оптимизации потребления электричества.
Алгоритм подбора выглядит интересно, спасибо. Надо попробовать реализовать для Флиппера.
Упоминание JVM тоже выглядит довольно странно. Насколько я знаю, V8 и JVM - совсем не родственники, и я не уверен, насколько похоже у них устроены GC.
Это очевидная неправда, или, по крайней мере, сформулировано слишком уж криво. Проверить достаточно просто - запустите цикл, создающий большие массивы или
Bufferы, но не сохраняющий на них ссылки, и посмотрите на потребление памяти этой программой.Правда в том, что они, разумеется, удаляются сборщиком - но лежат в отдельном месте памяти, и никогда за время жизни не перемещаются. Интуиция в том, что из-за того, что эти объекты большие, перемещать их дорого. Но из-за их размера, их обычно не так много - поэтому в этом их отдельном пространстве фрагментация будет меньшей проблемой.
На самом деле,
A.connect(B)всегда возвращаетB. Поэтому можно ещё и вот так:Как я понял, в вашей библиотеке именно клиент зависимости управляет тем, как она будет создана, с помощью вот этой сложной системы идентификаторов. Но мне кажется, что от DI скорее ждут того, чтобы клиент получал уже готовую зависимость. То, как ее можно создавать - фабрикой или конструктором, например - могла бы сообщать контейнеру сама зависимость. А синглтоном она будет или нет, кажется, должно решать само приложение, тот его код и конфигурация, которые собирают все модули воедино.
Более того, насколько вижу, у вас структура этих идентификаторов получается привязанной к пути к файлу с реализацией зависимости - а как при этом зависеть от интерфейса, а не конкретной реализации?
В итоге, ваши примеры кажутся полностью идентичными просто обычным импортам, без каких-либо преимуществ. Мы все так же просто указываем файл с реализацией зависимости и как ее создать - просто теперь почему-то в виде отдельного DSL.
А какой в таком ядре будет pid у idle-таска? Тоже 0?
В целом, я был бы рад, если бы вы подробнее расписали, в чем автор не прав, как именно распределяются pid, и при каких обстоятельствах он может быть 0 (почему-то же в том коде стоит
= 1вместо= 0).https://who.is/whois/crop-image-online.com
Похоже на просто спам ссылками на свои сайты. Рассказали бы лучше, как вы их разрабатывали, например, или что там под капотом.
Steam Deck - это портативная консоль вроде Nintendo Switch с поддержкой почти чего угодно :)
Плюс есть нишевые вещи вроде Playdate, которые специально делают ставку, в том числе, на удобство разработки.