Почему или зачем так было сделано можно написать следующими строками, а первой строкой удобнее всё-таки видеть что было сделано, чтобы потом проще анализировать историю коммитов.
Эти префиксы становятся полезны в рамках девопс-процессов. Например, сразу видно, что `hotfix` должен мержиться в релизную ветку, которая, собственно, как `release` помечена. Можно какие-то разные пайплайны в CI/CD запускать в зависимости от префикса (например, автоматически инкрементить минор- или патч-версию — но это не очень хорошо в общем случае).
Помимо идентификатора задачи столо бы также добавлять какое-то краткое человекопонятное описание. Иначе потом вся команда будет иметь дело со списком веток вида
Это как-то вы слишком вольно трактуете текст. В постановлении перечисляются 2 категории ПО: 1) enterprise management software; 2) design and manufacturing software. Для этих категорий запрещаются сервисы техподдержки и облачные сервисы. Разве закон в США определяет «простые» сайты магазинов в категорию EMS? И уж тем более в cloud services for EMS напрямую средства разработки не должны подпадать.
С "проектированием" там сложно, так использованное слово кроме основного смысла "инженерное проектирование" можно перевести ещё и как "разработка" в широком смысле.
«Design and manufacturing software» вообще-то нельзя перевести как «разработку» в широком смысле. Тогда нужно было бы писать «development».
Не менее смешно смотрится линия с доктором Фасск из OCP, которая перепрограммирует Робокопа, дабы сделать его более послушным и family-friendly. Среди сотен бредовых директив, мешавших Робокопу исполнять свой долг, есть и «быть вежливым», и «учить детей хорошему», и «бороться с курением», и чего только нет. Правда, такой служитель закона людям вообще не помогал. Ибо, напомню, во время ограбления Робокоп вместо обезвреживания преступников проводит им моральную лекцию о деструктивности их поведения для общества. Уже тогда понимали, что переделывать взрослые истории в PG-13 — плохая идея.
Эта линия сейчас смотрится неожиданно актуально в контексте попыток ограничить генеративные нейронные сети от выдачи «неприемлемого» контента, в результате чего они начинают жутко галлюцинировать или тупить.
Ну так-то это немного о другом статья, а именно, что disabled = true делает кнопку невидимой для скринридеров. Но никто не запрещает поменять ей стиль, а в обработчике делать проверку на `isSending`. А ещё, как вариант, можно было бы генерировать случайный токен, которым затем проверять запросы на дублирование. Это даже лучше в случае с микросервисами.
Зато реализуют свои буйные фантазии - запилить "классную фичу" - основное.
Для банковских приложений есть независимые рейтинги, в которых тупо сравнивается список реализованных фич. Соответственно, из маркетинговых соображений нужно безостановочно пилить фичи, соревнуясь с конкурентами.
совершенно не задумываются о наиболее частых сценариях их использования
А тут помимо вышеприведённого фичеризма следует помнить, что над одним приложением могут работать десятки продуктовых команд. У каждой свой KPI, свои бизнес-задачи и цели. И даже так: у банка есть десятки команд, которые реализуют заказанные бизнесом фичи в требуемых «каналах» (АРМ сотрудника, веб-приложение клиента, мобильное приложение, мобильное веб-приложение и т.д.). А это значит, что нет возможности остановиться и грамотно уложить все фичи в одно приложение. Их добавляют по мере поступления. Более-менее переосмыслить удаётся только при пересоздании приложения с нуля. И то, даже тут сыграет agile-подход, и сначала реализуют MVP, а потом начнут набивать его фичами.
Мне кажется, данная статья может ввести в заблуждение новичков.
В git можно создавать папки и подпапки. Достаточно добавить / в имени ветки и ваша ветка получит следующую структуру folder/name.
Это не git поддерживает «папки и подпапки», а конкретные инструменты могут обрабатывать отдельные части имени ветки как названия директорий. Для самого git «/» — это просто допустимый символ в имени ветки.
Правильность сортировки задает тип ветки, который ставится в начале ее названия
Опять-таки, приведённый список соответствует префиксам коммитов, а в популярных системах управления кодом или в CI-пайплайнах скорее всего будут другие имена. Вы бы хотя бы gitflow-именование упомянули (feature, bugfix, hotfix, release). Его же скорее всего и на собесе спросят. Да и вообще, выражение «правильность сортировки задаёт тип ветки», как мне кажется, не следует говорить программисту — там же просто группировка и сортировка по алфавиту, а не какая-то особая уличная магия.
Для создания такого коммита достаточно добавить вашему сообщению к коммиту тип WIP - и вуаля! - ваш коммит стал WIP'ом.
Аналогично, никакого специального значения «тип WIP» для git не имеет. Это просто кусочек текста коммита. Теоретически при создании пулреквеста его может использовать система управления кодом, а может и не использовать. Тогда с тем же успехом там могла быть подстрока [Do not merge] или вообще !!!НЕ МЕРЖИТЬ!!!.
Какое отношение Реакт имеет к WebOTP? Напоминает вопрос про плагин для jQuery для сложения чисел.
Похоже, что вы изобрели алгоритм Флажоле–Мартина (1984). HyperLogLog развивает их идею, но с большей точностью.
Фильтр Блума же не про подсчёт уникальных элементов, а про проверку нахождения в множестве.
Почему или зачем так было сделано можно написать следующими строками, а первой строкой удобнее всё-таки видеть что было сделано, чтобы потом проще анализировать историю коммитов.
Эти префиксы становятся полезны в рамках девопс-процессов. Например, сразу видно, что `hotfix` должен мержиться в релизную ветку, которая, собственно, как `release` помечена. Можно какие-то разные пайплайны в CI/CD запускать в зависимости от префикса (например, автоматически инкрементить минор- или патч-версию — но это не очень хорошо в общем случае).
Помимо идентификатора задачи столо бы также добавлять какое-то краткое человекопонятное описание. Иначе потом вся команда будет иметь дело со списком веток вида
File System API?
Это как-то вы слишком вольно трактуете текст. В постановлении перечисляются 2 категории ПО: 1) enterprise management software; 2) design and manufacturing software. Для этих категорий запрещаются сервисы техподдержки и облачные сервисы. Разве закон в США определяет «простые» сайты магазинов в категорию EMS? И уж тем более в cloud services for EMS напрямую средства разработки не должны подпадать.
«Design and manufacturing software» вообще-то нельзя перевести как «разработку» в широком смысле. Тогда нужно было бы писать «development».
Design & Manufacturing software — это то, что в России обычно подразумевают под термином CAD.
Вообще говоря, там оговорено, что на территории России предоставлять гражданам другим государств услуги можно.
Если «закрепить» Simulator в доке, то можно потом запускать его без запуска всего Xcode — это фактически отдельное приложение.
Эта линия сейчас смотрится неожиданно актуально в контексте попыток ограничить генеративные нейронные сети от выдачи «неприемлемого» контента, в результате чего они начинают жутко галлюцинировать или тупить.
Ну так-то это немного о другом статья, а именно, что disabled = true делает кнопку невидимой для скринридеров. Но никто не запрещает поменять ей стиль, а в обработчике делать проверку на `isSending`. А ещё, как вариант, можно было бы генерировать случайный токен, которым затем проверять запросы на дублирование. Это даже лучше в случае с микросервисами.
Вы хотите, чтобы на техническом портале обеспечили идемпотентность запросов? Да ну, бред какой-то :)
Выбросьте свой убогий DeepL. Несмотря на очевидную сложность перевода термина Notarization в данном контексте, сейчас даже Google лучше переводит.
Разве нельзя научиться писать грамотно или нанять корректора?
Там самая большая фича — встроенный AI
Для банковских приложений есть независимые рейтинги, в которых тупо сравнивается список реализованных фич. Соответственно, из маркетинговых соображений нужно безостановочно пилить фичи, соревнуясь с конкурентами.
А тут помимо вышеприведённого фичеризма следует помнить, что над одним приложением могут работать десятки продуктовых команд. У каждой свой KPI, свои бизнес-задачи и цели. И даже так: у банка есть десятки команд, которые реализуют заказанные бизнесом фичи в требуемых «каналах» (АРМ сотрудника, веб-приложение клиента, мобильное приложение, мобильное веб-приложение и т.д.). А это значит, что нет возможности остановиться и грамотно уложить все фичи в одно приложение. Их добавляют по мере поступления. Более-менее переосмыслить удаётся только при пересоздании приложения с нуля. И то, даже тут сыграет agile-подход, и сначала реализуют MVP, а потом начнут набивать его фичами.
Мне кажется, данная статья может ввести в заблуждение новичков.
Это не git поддерживает «папки и подпапки», а конкретные инструменты могут обрабатывать отдельные части имени ветки как названия директорий. Для самого git «/» — это просто допустимый символ в имени ветки.
Опять-таки, приведённый список соответствует префиксам коммитов, а в популярных системах управления кодом или в CI-пайплайнах скорее всего будут другие имена. Вы бы хотя бы gitflow-именование упомянули (
feature,bugfix,hotfix,release). Его же скорее всего и на собесе спросят. Да и вообще, выражение «правильность сортировки задаёт тип ветки», как мне кажется, не следует говорить программисту — там же просто группировка и сортировка по алфавиту, а не какая-то особая уличная магия.Аналогично, никакого специального значения «тип WIP» для git не имеет. Это просто кусочек текста коммита. Теоретически при создании пулреквеста его может использовать система управления кодом, а может и не использовать. Тогда с тем же успехом там могла быть подстрока
[Do not merge]или вообще!!!НЕ МЕРЖИТЬ!!!.