Так уж устоялось, фильм 1999 года перевели как "Пираты силиконовый долины". Сериал 2014 года перевели как "Силиконовая долина". Имхо силиконовая долина, которая кремниевая, это уже устоявшееся выражение, а о силиконовой долине Сан-Фернардо, никто толком не знает в РФ.
в английском языке, как и в русском, силикон и кремний пишутся и произносятся по-разному
В русском - очевидно, но в английском - они пишутся и произносятся практически одинаково: silicon vs silicone. На слух разница для меня совершенно неуловима при быстрой речи.
почему? Имхо middle name это любое имя которое может быть между given name & surname. И это может быть: patronymic, matronymic, surname of mother, surname of father (если вы допустим берете себе фамилию мамы), или просто secondary name.
А вот называть поле patronymic, и писать туда matronymic, surname of mother, surname of father или просто secondary name - это имхо больший анти-паттерн чем middle_name
Да и вообще вся эта статья это "лучшее враг хорошего". Имхо перфекционизм часто создает больше проблем, чем улучшений.
В ЕС многие системы не поддерживают middle name, и когда ребёнок рождается к примеру в Германии, и ему вписывают отчество в свво о рождении, в очень многих немецких документах возникает "Имя: Александр Сергеевич" . К примеру регистрация по месту жительства, налоговые справки итд итп. Так что я не уверен баг на стороне РФ паспорта, он репродьюсится и внутри Германии в отвязке от российских документов.
Мне кажется ваша статья - это пример "лучшее враг хорошего".
Да, first name, last name и middle name не идеальны - но имхо они самые общеупотребительные. Это как "рогоз" или "мультифора". Не всегда "лучшее" и "правильное" - лучше, так как может вызывать больше вопросов и сложности понимания.
В их (Google) Identity Platform я вообще не вижу компонентов имени, зато есть displayName и screenName
Я с вероятностью 99% уверен, что Гугл разбивает ФИО отдельно. Я думаю просто для фронтового API когда это не нужно они сливают в displayName.
Но вот я смотрю в стандарт OpenID, который повсеместно используется в настоящее время
Given name, middle name, Family name - еще норм и понятно Но, First name, middle name, Surname - понятнее имхо
patronymic, matronymic - имхо ужас. Как вы назовете это поле? patronymic_or_matronymic? Если patronymic - то туда можно вводить matronymic? и тд и тп
не проще ли хранить имя пользователя в виде одной opaque-строки
Если вы хотите не-расширяемый API и из-за бесполезного перфекционизма огрести проблем в будущем, то пожалуйста! А в реальности, делать нужно с точностью наоборот: хранить раздельно, а в API возвращать в виде одной opaque-строки если клиентам не нужно раздельно. И API легко меняется без backward-compatibility-changes если нужно его расширить.
И конфиги - синглетоны, это чистой воды оптимизация ресурсов. Ничего не поменяется если конфиг просто будет Immutable data class, и мы будем создавать новый такой же класс по какому-нибудь чиху.
Если конфиги реализованы синглетоном как предлагают GoF или Effective Java, то это протекание оптимизации ресурсов приложения в бизнес логику. И вообще то, что я считаю анти-паттерном синглетона - это протекание "lifecycle management" в бизнес логику.
На эту проблему можно смотреть с разных углов. Вы ее формулируете так, я бы скорее ее сформулировал, что: "Глобальное требование иметь один инстанс протекает в бизнес логику конкретного сервиса, которому не имеет значение сколько инстансов ранится". Что вытекает из-того, что "догматичная" имплементация синглетона - это double-responsibility: strong-coupling бизнес логики и lifecycle/instantiating management. Если их разделить и сделать single-responsibility, то и не будет проблем протестировать отдельно бизнес логику в столько потоков во сколько душе угодно, и протестировать синглетон в интеграционных тестах, что он синглетон.
Конфиги как синглетон - это проблема для тестирования: одному тесту ты передашь один конгфиг, другому второй, третьему третий. И ранишь все эти тесты параллельно, как это будет работать с синглетоном? Завязывать бизнес логики (конфигов), с их жизненным циклом (синглетон) - это антипаттерн.
Я не говорю, что приложению нужно несколько инстансов конфигов, я говорю что как gof, effective Java, предлагают это делать - это антипаттерн создающий проблемы в тестировании
В том что вы предлагаете также несколько других проблем:
Сломанная семантика: то что мы делаем синглетоном, очень часто никакого отношения к enumeration не имеет
Double responsibility - мы привязываем сервис и его жизненный цикл в один coupled кусок
И теперь его, не думая, пихают везде где нужно и где не нужно.
Это совершенно другой топик
Синглтон - это просто объект-одиночка в рамках, как правило, приложения. Вне зависимости от механизма реализации
Это понятно. Имхо анти-паттерн - это не class-lifecycle-management, а анти-паттерн связывание бизнес-логики (сервиса) и class-lifecycle-management вместе. Поэтому как GoF его преподносит, и как Effective Java рекомендует делать синглетоны - это имхо антипаттерн. А вот именно Spring class-lifecycle-management - это то, что позволяет нормально тестировать бизнес-логику не привязываясь сколько инстансов реально будет в проде.
Легко, потому что все вокруг называли этот паттерн Синглетон, и GoF читалась в оригинале. Это тот же вечный холивар насколько нужно переводить IT термины
С моей колокольни Singleton был очень популярен 15-20 лет назад, потому что очень часто не нужно больше одного инстанса и все писали свои велосипеды: Logger, DB connection pool, Caching, Any State Management, File System Management, etc. И к сожалению написать правильно синглетон, который будет работать в многопоточке - не так уж и просто, от туда и пошли ужасные костыли вида Double-Checked-Locking Singleton о которых меня даже спрашивали на собеседовании в районе 2010. Enum - решает все вопросы многопоточки, где single-instance гарантируется JVM. Более того использовать Enum для синглетона - это рекомендация из книги Effective Java (имхо анти-рекомендация).
Но потом года с 2010 начали говорить про зло Global state, про Testability, и Spring начал становиться довольно популярным - Singleton стал анти-паттерном.
Имхо использование enum для синглетон - это костыль и анти-паттерн, хотя работает отлично.
Также мне нравится концепция Spring, где класс отвечает за то, что он должен делать, а не то как он инстанцируется. Singleton или нет - это вынесено: Spring bean scopes.
Да, и мне кажется это было бездонный разгул для вирусов которые получали доступ к смс. Ну и я даже слышал о мошенниках которые просили телефон позвонить и пытались с него смс-ки отправлять.
За последние несколько недель я переводил с ING -> N26, c DKB -> N26, с N26 -> Vivid - шли рабочие сутки (один раз 4 дня, в пятницу во вторую половину дня отправлено, в понедельник пришло). Видимо все эти банки исключение.
И да и нет. Я знаю людей проходивших тех интервью на софт-скилах, потому что интервью было организовано как "поболтать". И Да - потому что возможно в РФ или в мелких компаниях или стартапах зарубежом могут лояльно относиться к софт-скилам при найме. Но нет - потому что американский энтерпрайз (ФААНГ) и много других компаний копирующих найм с них очень требовательны к софт-скилам при найме на тех позиции. Тот же Амазон известен, что они рекомендуют прочесть кипу книг по Leadership Principles/Behaviroual чтобы пройти их интервью, и в каждом их тех интервью уделяется 10-20% времени на проверку софт-скилов + отдельные раунды интервью выделенные только для софт-скилов.
Но также и работа не заканчивается после найма. В корпорате (и в РФ и зарубежом) без софт-скилов сложно расти или занимать высокие должности. Софт скилы необходимы для борьбы за ресурсы, за бюджеты, для нетворкинга, для повышения и тд и тп. В корпорате софт-скилы необходимы просто чтобы выжить в этой смертной любви.
Софт-скилы помогают найти хорошего репититора через знакомства, который подтянет хард-скилы. А в некоторых случаях софт-скиллы могут помочь поступить и в универ через знакомство, но с таким подходом универ может оказаться бесполезным и тоже пройти на одних софт-скилах :)
Имхо софт-скилы могут предоставить shortcut или лифт для жизненных возможностей, но без хард-скилов будет тяжело воспользоваться этими возможностями.
Умение учиться и разбираться имхо чаще hard-skill. Для меня soft-skill - решение не технических проблем. Hard-skill - решение технических проблем.
Ну и hard-skill умения разбираться в технических проблемах обычно неплохо переносится на не технические проблемы (разобраться в продуктовом домене). От этого "переноса" и пошло же "тыж программист, ты в этом разберешься".
Переводы по IBAN идут рабочие сутки, то есть отправив в пятницу они приходят в понедельник-вторник (что есть в худшем случае 3-4 дня). Есть исключения: N26 за 50 центов может ускорить до мгновенных, и в некоторых банках внутри банка перевод мгновенный - но это исключения. Возможно еще Revolut отправляет мгновенно.
Так уж устоялось, фильм 1999 года перевели как "Пираты силиконовый долины". Сериал 2014 года перевели как "Силиконовая долина". Имхо силиконовая долина, которая кремниевая, это уже устоявшееся выражение, а о силиконовой долине Сан-Фернардо, никто толком не знает в РФ.
В русском - очевидно, но в английском - они пишутся и произносятся практически одинаково: silicon vs silicone. На слух разница для меня совершенно неуловима при быстрой речи.
почему? Имхо middle name это любое имя которое может быть между given name & surname. И это может быть: patronymic, matronymic, surname of mother, surname of father (если вы допустим берете себе фамилию мамы), или просто secondary name.
А вот называть поле patronymic, и писать туда matronymic, surname of mother, surname of father или просто secondary name - это имхо больший анти-паттерн чем middle_name
Да и вообще вся эта статья это "лучшее враг хорошего". Имхо перфекционизм часто создает больше проблем, чем улучшений.
Имхо Patronym - это анти-феншуй, что вы будете делать с middle name не связанными с родителями / родственниками или с matronymic?
name - по немецки это Фамилия, поэтому нет идеала и всем не угодишь
В ЕС многие системы не поддерживают middle name, и когда ребёнок рождается к примеру в Германии, и ему вписывают отчество в свво о рождении, в очень многих немецких документах возникает "Имя: Александр Сергеевич" . К примеру регистрация по месту жительства, налоговые справки итд итп. Так что я не уверен баг на стороне РФ паспорта, он репродьюсится и внутри Германии в отвязке от российских документов.
Мне кажется ваша статья - это пример "лучшее враг хорошего".
Да, first name, last name и middle name не идеальны - но имхо они самые общеупотребительные.
Это как "рогоз" или "мультифора". Не всегда "лучшее" и "правильное" - лучше, так как может вызывать больше вопросов и сложности понимания.
Я с вероятностью 99% уверен, что Гугл разбивает ФИО отдельно. Я думаю просто для фронтового API когда это не нужно они сливают в displayName.
Given name, middle name, Family name - еще норм и понятно
Но, First name, middle name, Surname - понятнее имхо
patronymic, matronymic - имхо ужас. Как вы назовете это поле? patronymic_or_matronymic? Если patronymic - то туда можно вводить matronymic? и тд и тп
Если вы хотите не-расширяемый API и из-за бесполезного перфекционизма огрести проблем в будущем, то пожалуйста!
А в реальности, делать нужно с точностью наоборот: хранить раздельно, а в API возвращать в виде одной opaque-строки если клиентам не нужно раздельно. И API легко меняется без backward-compatibility-changes если нужно его расширить.
И конфиги - синглетоны, это чистой воды оптимизация ресурсов. Ничего не поменяется если конфиг просто будет Immutable data class, и мы будем создавать новый такой же класс по какому-нибудь чиху.
Если конфиги реализованы синглетоном как предлагают GoF или Effective Java, то это протекание оптимизации ресурсов приложения в бизнес логику. И вообще то, что я считаю анти-паттерном синглетона - это протекание "lifecycle management" в бизнес логику.
На эту проблему можно смотреть с разных углов. Вы ее формулируете так, я бы скорее ее сформулировал, что: "Глобальное требование иметь один инстанс протекает в бизнес логику конкретного сервиса, которому не имеет значение сколько инстансов ранится". Что вытекает из-того, что "догматичная" имплементация синглетона - это double-responsibility: strong-coupling бизнес логики и lifecycle/instantiating management. Если их разделить и сделать single-responsibility, то и не будет проблем протестировать отдельно бизнес логику в столько потоков во сколько душе угодно, и протестировать синглетон в интеграционных тестах, что он синглетон.
Конфиги как синглетон - это проблема для тестирования: одному тесту ты передашь один конгфиг, другому второй, третьему третий. И ранишь все эти тесты параллельно, как это будет работать с синглетоном? Завязывать бизнес логики (конфигов), с их жизненным циклом (синглетон) - это антипаттерн.
Я не говорю, что приложению нужно несколько инстансов конфигов, я говорю что как gof, effective Java, предлагают это делать - это антипаттерн создающий проблемы в тестировании
Этот вариант плох тем, что у него double-responsibilty:
бизнес логика сервиса
instantiation/lifecycle management
Это может вызвать проблемы в тестировании, особенно когда тестам не имеет значения синглетон наш бизнес класс или нет.
В том что вы предлагаете также несколько других проблем:
Сломанная семантика: то что мы делаем синглетоном, очень часто никакого отношения к enumeration не имеет
Double responsibility - мы привязываем сервис и его жизненный цикл в один coupled кусок
Это совершенно другой топик
Это понятно. Имхо анти-паттерн - это не class-lifecycle-management, а анти-паттерн связывание бизнес-логики (сервиса) и class-lifecycle-management вместе. Поэтому как GoF его преподносит, и как Effective Java рекомендует делать синглетоны - это имхо антипаттерн. А вот именно Spring class-lifecycle-management - это то, что позволяет нормально тестировать бизнес-логику не привязываясь сколько инстансов реально будет в проде.
Легко, потому что все вокруг называли этот паттерн Синглетон, и GoF читалась в оригинале. Это тот же вечный холивар насколько нужно переводить IT термины
С моей колокольни Singleton был очень популярен 15-20 лет назад, потому что очень часто не нужно больше одного инстанса и все писали свои велосипеды: Logger, DB connection pool, Caching, Any State Management, File System Management, etc. И к сожалению написать правильно синглетон, который будет работать в многопоточке - не так уж и просто, от туда и пошли ужасные костыли вида Double-Checked-Locking Singleton о которых меня даже спрашивали на собеседовании в районе 2010. Enum - решает все вопросы многопоточки, где single-instance гарантируется JVM. Более того использовать Enum для синглетона - это рекомендация из книги Effective Java (имхо анти-рекомендация).
Но потом года с 2010 начали говорить про зло Global state, про Testability, и Spring начал становиться довольно популярным - Singleton стал анти-паттерном.
Имхо использование enum для синглетон - это костыль и анти-паттерн, хотя работает отлично.
Также мне нравится концепция Spring, где класс отвечает за то, что он должен делать, а не то как он инстанцируется. Singleton или нет - это вынесено: Spring bean scopes.
Да, и мне кажется это было бездонный разгул для вирусов которые получали доступ к смс. Ну и я даже слышал о мошенниках которые просили телефон позвонить и пытались с него смс-ки отправлять.
За последние несколько недель я переводил с ING -> N26, c DKB -> N26, с N26 -> Vivid - шли рабочие сутки (один раз 4 дня, в пятницу во вторую половину дня отправлено, в понедельник пришло). Видимо все эти банки исключение.
И да и нет. Я знаю людей проходивших тех интервью на софт-скилах, потому что интервью было организовано как "поболтать". И Да - потому что возможно в РФ или в мелких компаниях или стартапах зарубежом могут лояльно относиться к софт-скилам при найме. Но нет - потому что американский энтерпрайз (ФААНГ) и много других компаний копирующих найм с них очень требовательны к софт-скилам при найме на тех позиции. Тот же Амазон известен, что они рекомендуют прочесть кипу книг по Leadership Principles/Behaviroual чтобы пройти их интервью, и в каждом их тех интервью уделяется 10-20% времени на проверку софт-скилов + отдельные раунды интервью выделенные только для софт-скилов.
Но также и работа не заканчивается после найма. В корпорате (и в РФ и зарубежом) без софт-скилов сложно расти или занимать высокие должности. Софт скилы необходимы для борьбы за ресурсы, за бюджеты, для нетворкинга, для повышения и тд и тп. В корпорате софт-скилы необходимы просто чтобы выжить в этой смертной любви.
Софт-скилы помогают найти хорошего репититора через знакомства, который подтянет хард-скилы. А в некоторых случаях софт-скиллы могут помочь поступить и в универ через знакомство, но с таким подходом универ может оказаться бесполезным и тоже пройти на одних софт-скилах :)
Имхо софт-скилы могут предоставить shortcut или лифт для жизненных возможностей, но без хард-скилов будет тяжело воспользоваться этими возможностями.
Умение учиться и разбираться имхо чаще hard-skill.
Для меня soft-skill - решение не технических проблем.
Hard-skill - решение технических проблем.
Ну и hard-skill умения разбираться в технических проблемах обычно неплохо переносится на не технические проблемы (разобраться в продуктовом домене). От этого "переноса" и пошло же "тыж программист, ты в этом разберешься".
Переводы по IBAN идут рабочие сутки, то есть отправив в пятницу они приходят в понедельник-вторник (что есть в худшем случае 3-4 дня).
Есть исключения: N26 за 50 центов может ускорить до мгновенных, и в некоторых банках внутри банка перевод мгновенный - но это исключения. Возможно еще Revolut отправляет мгновенно.