Модель не предсказывает будущее. Она просто более дисциплинированно следует правилам, чем человек в 3 часа ночи.
А знаете, что ещё более дисциплинированно следует правилам? If-else.
Очень смешно читать, как всю статью из LLM пытаются сделать обычный if-else скрипт, героически решая собственноручно созданную проблему, что забить гвоздь микроскопом.
Мой посыл в том, что не только у меня, а почти у всех проектов, даже больших, Swift Dependencies и так залетит. А это решение - как раз для 5% (только сомневаюсь, что эти компании из 5% не пойдут свое писать тоже)
во-первых, если забыть это сделать, то в проде будет использоваться testValue
Если использовать структуры вместо протоколов и макрос @DependencyClient , где testValue будет пустым инитом без параметров – тогда приложение не крашнется, а напишет в логи, что можно отследить и автоматизировать проверку забываний (и эту проверку написать гораздо проще статического анализатора из статьи)
во-вторых, если вдруг будет два конформанса в разных модулях с разными liveValue то получится неуточнённое поведение (unspecified behavior), какая реализация выберется, зависит от реализации компилятора, линковщика и их флагов сборки.
Во-первых, эти все параметры должны быть стабильны. Вы не библиотеку под пять архитектур двумя компиляторами и тремя системами собираете, это iOS приложение. Скорее всего у разработки и CI всегда одинаковый тулчейн с точностью до микроверсии.
Даже если это не так, то опять же гораздо проще написать build step проверку на то, что два liveValue для одного ключа в коде нет. Я имею в виду гораздо проще, чем описанное в статье графохождение + макросы.
Иначе говоря – да, у swift-dependencies тоже не всё идеально, но описанные минусы проще поправить, чем писать своё. Не говоря уже о том, что я на проекте не сильно меньше ни разу не встречал описанные возможные ошибки.
попробуйте заинжектить в модуль А реализацию из модуля Б так, чтобы А не зависел от Б, и вы увидите что liveValue должен быть определён при объявлении ключа
Это неправда. Можно законфрмить TestDependencyKey в модуле Б (он требует только testValue), liveValue написать в корневом модуле, а модуль А будет лишь экспортировать интерфейс, адаптером к которому этот liveValue и будет. Корень зависит от А и Б, а сами А и Б друг от друга не зависят. С интерфейс-модулями тоже совместимо (у них в документации этот подход как раз используется для реализации интерфейс-модулей). Короче, библиотека ничего не навязывает.
не видно какие зависимости нужно переопределять, они скрыты внутри вызываемого кода, и если что-то забыли — узнаете только в рантайме.
withDependencies и переопределение вообще не нужны за пределами тестов и перезапускаемых (не-синглтон) зависимостей, которых в обычных приложениях почти нет. Про это и был мой комментарий в общем-то. Если вы пишете браузер – проблема. Но браузер почти никто не пишет.
Про Swift Dependencies от Pointfree - сказано, что необходимо объявлять значения явно, и это подано как минус. Я думаю, это для большинства приложений это плюс, потому что лишает необходимости в статическом анализаторе типа такого из статьи (код может упасть только при циклической зависимости).
Где это реально мешает - это при трансформации и/или переопределения зависимостей по ходу графа или в рантайме. Я вообще считаю, что так лучше не делать - большинство приложений может обойтись без этого, там нет режима инкогнито или каких-то перезагружающихся движков не с самим приложением целиком. А если есть, я бы их вручную прокинул (и делал так).
Потом сказано, что у Swift Dependencies графа не видно. Не очень понятно, как он становится виден из параметра scope. Как бы скрытие явного графа в коде и есть одна из главных целей. Может, имеется в виду, что граф видит статический анализатор и его можно распечатать в рандомном месте в коде - тогда это круто (правда я ни разу не сталкивался с желанием это делать, даже потребляя 20-30 параметров - граф полезно бы глянуть если что-то не так с переопределением, но про это уже писал выше).
Я к чему - 95% приложений могут использовать Swift Dependencies для зависимостей типа долгоживущих сервисов и вручную прокидывать все остальное, даже если там миллионы строк кода.
В метро очень много подсказок: рекомендуемые вагоны и с какой стороны откроются двери, надземные пересадки и автобусы на карте. А ещё приложения в Китае показывают твоё местоположение на маршруте в общественном транспорте. Правда, в метро оно очень примерное.
В Google Maps в Японии тоже есть эта пачка функций. В Европу ее завезли не везде, особенно вариативны автобусы на карте, которые есть, например, в Сан-Франциско и Сингапуре, но скажем, не в Лондоне.
Да и про Нидерланды тут лукавят, оффер должен быть не простой, а от компании из списка recognised employers (понятно, что другие вряд ли вообще 55к дадут, но все же).
В том же UK так же, но планка по зарплате ещё ниже - в евро около 45к. Да, нужно еще сдать английский, но порог смешной и без него и так вряд ли оффер получишь.
Так что ничего особо уникального в Нл нет. Даже рулинг есть в Дании или Италии, если на то пошло
Если доходы чистые и переводить в UK в твердой крипте типа USDT и сразу вывести в банк - никаких налогов не попросят и репортить ничего не понадобится (государству). Что попросят банки при вводе или солиситоры при попытке применить эти деньги на первый взнос - уже другой вопрос, но это частные лица, могут что угодно просить
Валютного контроля и налогообложения при получении валюты из-за рубежа нет в UK, так что тут не сложнее. Но это, как и предыдущие сообщения в треде, не такс адвайс.
Она является криптой, под нее отдельные правила. В них есть элементы и правил для товаров, и правил для валют.
Про приколы с скачками курса, комиссиями и эскроу все описано подробно на gov.uk в разделе про налогообложение крипты. Конкретно про ваш случай не скажу, но обычно на весь рост цены к фунту кажется надо платить налог (с некоторыми исключениями), по-моему для эскроу исключений нет
В декларации ничего раскрывать не надо, но HMRC может запросить документы из цепочки в любой момент.
Крипта не признается в этом случае (британской налоговой) ни валютой (потому что не действуют всякие правила как при торговле, скажем, долларами, и добавляется куча своих), ни товаром (потому что не действуют правила на disposal товаров)
Налоги (Capital Gains) платятся при продаже (или трате, переводе другому лицу) крипты в плюс за пределами лимитов, или Income Tax (если крипта получена в качестве зарплаты), на gov.uk есть отличный гайд по тому, как считать курс и все такое и как отмечать в декларации. Есть и сторонние сервисы, которым даешь свои адреса и они сами посчитают налоги по всем disposal по британским правилам, останется только зарепортить и оплатить.
Я скорее не про вопросы, а про решение конкретных задач. Вот представьте, приходит литкод хард, там в середине где-то внезапно требуется список. Ты тянешься за списком, а его... нет в языке. Представили? А мне и представлять не надо.
Ага, и вставку с удалением накидывать каждый раз? Просто структура с указателем на next малополезна, а на собесе надо за 35 минут два медиума разбить, а не реализовывать структуры с первого курса.
Самое смешное, что есть языки, где нет linkedList в стандартной библиотеке или самых популярных сторонних. И разработчиков этих языков тоже спрашивают литкод на интервью.
Офлайн нет построения маршрутов ни на чем, кроме автомобиля
В справочнике в карточке места есть только название и рейтинг. Даже времени работы нет, не говоря уже о рубриках и контактах
Поисковый индекс невероятно скудный, и даже если точно писать названия места - он найдет его только если гугл счел его достаточно важным для упаковки в офлайн-пакет
и это я умалчиваю о фичах, которых у гугла даже онлайн нет, типа поиска входа, списка подъездов и квартир, провайдеров дома, туристического слоя, и т.д.
А знаете, что ещё более дисциплинированно следует правилам? If-else.
Очень смешно читать, как всю статью из LLM пытаются сделать обычный if-else скрипт, героически решая собственноручно созданную проблему, что забить гвоздь микроскопом.
Мой посыл в том, что не только у меня, а почти у всех проектов, даже больших, Swift Dependencies и так залетит. А это решение - как раз для 5% (только сомневаюсь, что эти компании из 5% не пойдут свое писать тоже)
Если использовать структуры вместо протоколов и макрос
@DependencyClient, где testValue будет пустым инитом без параметров – тогда приложение не крашнется, а напишет в логи, что можно отследить и автоматизировать проверку забываний (и эту проверку написать гораздо проще статического анализатора из статьи)Во-первых, эти все параметры должны быть стабильны. Вы не библиотеку под пять архитектур двумя компиляторами и тремя системами собираете, это iOS приложение. Скорее всего у разработки и CI всегда одинаковый тулчейн с точностью до микроверсии.
Даже если это не так, то опять же гораздо проще написать build step проверку на то, что два liveValue для одного ключа в коде нет. Я имею в виду гораздо проще, чем описанное в статье графохождение + макросы.
Иначе говоря – да, у swift-dependencies тоже не всё идеально, но описанные минусы проще поправить, чем писать своё. Не говоря уже о том, что я на проекте не сильно меньше ни разу не встречал описанные возможные ошибки.
Это неправда. Можно законфрмить
TestDependencyKeyв модуле Б (он требует толькоtestValue),liveValueнаписать в корневом модуле, а модуль А будет лишь экспортировать интерфейс, адаптером к которому этотliveValueи будет. Корень зависит от А и Б, а сами А и Б друг от друга не зависят. С интерфейс-модулями тоже совместимо (у них в документации этот подход как раз используется для реализации интерфейс-модулей). Короче, библиотека ничего не навязывает.withDependenciesи переопределение вообще не нужны за пределами тестов и перезапускаемых (не-синглтон) зависимостей, которых в обычных приложениях почти нет. Про это и был мой комментарий в общем-то. Если вы пишете браузер – проблема. Но браузер почти никто не пишет.Про Swift Dependencies от Pointfree - сказано, что необходимо объявлять значения явно, и это подано как минус. Я думаю, это для большинства приложений это плюс, потому что лишает необходимости в статическом анализаторе типа такого из статьи (код может упасть только при циклической зависимости).
Где это реально мешает - это при трансформации и/или переопределения зависимостей по ходу графа или в рантайме. Я вообще считаю, что так лучше не делать - большинство приложений может обойтись без этого, там нет режима инкогнито или каких-то перезагружающихся движков не с самим приложением целиком. А если есть, я бы их вручную прокинул (и делал так).
Потом сказано, что у Swift Dependencies графа не видно. Не очень понятно, как он становится виден из параметра scope. Как бы скрытие явного графа в коде и есть одна из главных целей. Может, имеется в виду, что граф видит статический анализатор и его можно распечатать в рандомном месте в коде - тогда это круто (правда я ни разу не сталкивался с желанием это делать, даже потребляя 20-30 параметров - граф полезно бы глянуть если что-то не так с переопределением, но про это уже писал выше).
Я к чему - 95% приложений могут использовать Swift Dependencies для зависимостей типа долгоживущих сервисов и вручную прокидывать все остальное, даже если там миллионы строк кода.
В Google Maps в Японии тоже есть эта пачка функций. В Европу ее завезли не везде, особенно вариативны автобусы на карте, которые есть, например, в Сан-Франциско и Сингапуре, но скажем, не в Лондоне.
Да и про Нидерланды тут лукавят, оффер должен быть не простой, а от компании из списка recognised employers (понятно, что другие вряд ли вообще 55к дадут, но все же).
В том же UK так же, но планка по зарплате ещё ниже - в евро около 45к. Да, нужно еще сдать английский, но порог смешной и без него и так вряд ли оффер получишь.
Так что ничего особо уникального в Нл нет. Даже рулинг есть в Дании или Италии, если на то пошло
Для галочек на O1 и Global Talent, очевидно
Япония - не знаю, но из Сингапура лично отправлял в конце 2022 и все доходило
Да вроде только в США такие проблемы и есть. Южная Америка, Европа (почти вся), Азия - все доходит. USPS че-то совсем странные
Если доходы чистые и переводить в UK в твердой крипте типа USDT и сразу вывести в банк - никаких налогов не попросят и репортить ничего не понадобится (государству). Что попросят банки при вводе или солиситоры при попытке применить эти деньги на первый взнос - уже другой вопрос, но это частные лица, могут что угодно просить
Валютного контроля и налогообложения при получении валюты из-за рубежа нет в UK, так что тут не сложнее. Но это, как и предыдущие сообщения в треде, не такс адвайс.
Про отмыв не могу ничего сказать.
Она является криптой, под нее отдельные правила. В них есть элементы и правил для товаров, и правил для валют.
Про приколы с скачками курса, комиссиями и эскроу все описано подробно на gov.uk в разделе про налогообложение крипты. Конкретно про ваш случай не скажу, но обычно на весь рост цены к фунту кажется надо платить налог (с некоторыми исключениями), по-моему для эскроу исключений нет
В декларации ничего раскрывать не надо, но HMRC может запросить документы из цепочки в любой момент.
Крипта не признается в этом случае (британской налоговой) ни валютой (потому что не действуют всякие правила как при торговле, скажем, долларами, и добавляется куча своих), ни товаром (потому что не действуют правила на disposal товаров)
Например, в UK - договор о продаже квартиры.
Налоги (Capital Gains) платятся при продаже (или трате, переводе другому лицу) крипты в плюс за пределами лимитов, или Income Tax (если крипта получена в качестве зарплаты), на gov.uk есть отличный гайд по тому, как считать курс и все такое и как отмечать в декларации. Есть и сторонние сервисы, которым даешь свои адреса и они сами посчитают налоги по всем disposal по британским правилам, останется только зарепортить и оплатить.
Я скорее не про вопросы, а про решение конкретных задач. Вот представьте, приходит литкод хард, там в середине где-то внезапно требуется список. Ты тянешься за списком, а его... нет в языке. Представили? А мне и представлять не надо.
Ага, и вставку с удалением накидывать каждый раз? Просто структура с указателем на next малополезна, а на собесе надо за 35 минут два медиума разбить, а не реализовывать структуры с первого курса.
Самое смешное, что есть языки, где нет linkedList в стандартной библиотеке или самых популярных сторонних. И разработчиков этих языков тоже спрашивают литкод на интервью.
Навскидку:
Офлайн нет построения маршрутов ни на чем, кроме автомобиля
В справочнике в карточке места есть только название и рейтинг. Даже времени работы нет, не говоря уже о рубриках и контактах
Поисковый индекс невероятно скудный, и даже если точно писать названия места - он найдет его только если гугл счел его достаточно важным для упаковки в офлайн-пакет
и это я умалчиваю о фичах, которых у гугла даже онлайн нет, типа поиска входа, списка подъездов и квартир, провайдеров дома, туристического слоя, и т.д.
Как это нет? Софт работает, железо работает. Вот в Китае его реально нет, нам дотуда ещё далеко.