не знаю, ребят. отметился - посмотрим, во что это выльется. а про свой стартап я напишу тоже на хабре - только сначала про тексты расскажу - как обещал )
да, тут я лажанулся - исправлю. занимаюсь серверными приложениями, десктоп - линукс и макось, а виндой пользовался последний раз лет 15 назад.. спасибо!
насчёт NFC для галочки - тут ноги растут вот откуда: мне не нужна была изначально полноценная библиотека - замена ICU - была практическая задача NFD/сопоставления для embedded-бд и NFKD для внутреннего поиска в проекте.
насчёт того, что алгоритм один - да, в курсе. я начал писать статьи не на ровном месте - у меня всё это дело реализовано (NF(K)D по бенчам - быстрее ICU4X, в некоторых кейсах - вдвое). вот NFC у меня скорее для галочки реализована, и причина, почему думаю её вынести отдельно - хочу сначала поэкспериментировать с оптимизациями именно в композиции.
а так - да, совершенно согласен - рассказать про стартеры, вот это всё. исключения композиции, оптимизации используемые в бд, что где применяется.
вопрос хороший, и, если честно, я не нашел на него ответа. исторические причины - хотели изначально как-то сгруппировать значения ССС, чтобы можно было использовать битовые маски для определения этих групп, а потом забили? или оставляли промежутки на всякий случай?
мне здесь больше не даёт покоя такая мысль - неужели нельзя было быть экономнее, и уложиться в 6 бит? дело в том, что если прочитать UnicodeData.txt из UCD (Unicode Character Database), содержащую определения свойств всех заданных символов Unicode, то можно увидеть, что используется ТОЛЬКО 56 различных значения Canonical Combining Class.
у меня вся почта на своих доменах. домены - в зонах ру и tech. если введут белые списки почтовиков, вроде mail.ru (а именно о таком подходе ходят слухи), я - в пролёте?
в разработке софт, который планирую зарелизить в конце года. там по-любому для клиентов нужна регистрация. мне теперь не ориентироваться иностранный рынок, иначе атата? это вообще не вредительство?
а если я на своем домене, где храню гит-репы, зарегистрируюсь по своему-же емейлу, который относится к тому же домену - это я вдвойне нарушаю, но как-то под-одеяльцем?
как можно назвать лучшего или худшего работодателя, не поработав там? это какой-то странный вопрос, - даже если предположить, что человек, отвечающий на вопрос поработал в 2-3 компаниях из списка представленных - как он может сравнивать их с остальными, какую выборку в результате вообще хотите получить?
насчет индексов, выборок в базе - это прям больное. такое впечатление, что ребят учат SQL, писать запросы различной сложности, но ни слова не говорят про то, что там под капотом - как хранятся данные, как устроены индексы.
сейчас делаю наброски серии статей про юникод - нормализация, сопоставления(collation) строк.. ну и поспрашивал окружающих - "а вы знаете, как вообще это происходит? как в бд, например, строятся индексы текстов?".. результаты - максимум есть понимание, что есть ключи, которые каким-то неведомым образом строятся из строчек, для одних локалей одни, для других - другие...
касательно статьи непосредственно - лучше-бы мухи отдельно, котлеты отдельно - описание методов запросов и кодов http-ответов (ну этого-то и так предостаточно прям везде!) как-то отделить от использования инструмента было-бы замечательно.
имхо, конечно, но когда-то постман был удобным и небольшим - прикладной комфортный в использовании инструмент для того, чтобы набросать апи и поделиться с коллегами. сейчас это какой-то перегруженный комбайн, по которому уже нужны туториалы, чтобы проникнуться всеми фичами.
постмановский подход сейчас хорош только для команд с большими комплексными апи их сервисов, или когда предполагаются разные сценарии использования, разные окружения и нагрузки.
в остальных случаях, как по мне, он избыточен: - тесты можно писать на том же стеке, на котором написан основной код. это зачастую много быстрее. - дробление тестов - относящиеся к апи - в одной парадигме, остальные тесты - в другой.. а есть ещё, наверняка, куча других инструментов, используемых в команде. и вот разрастание этого зоопарка может стать избыточным, требовать всё больших и больших трудозатрат, в то время когда время на непосредственно разработку уменьшается. - понятно, что идея делегировать тестировщикам апи-тесты звучит неплохо - но непосредственно разработчику перед этим всё-равно нужно описать методы перед передачей в тестирование, всё-равно нужно набрасывать какие-то тесты при отладке. т.е. нужно посмотреть, насколько выгодно по человекочасам. - где больше людей, инструментов, технологий - всегда больше ошибок. ну вот такие вот мы, люди, разработчики - пишем одни ошибки исправляя другие. большее количество ошибок увеличивает время до выкатки - если в одном случае разработчик тратит большее количество времени на начальном этапе - набросав тесты для проверки корректности исполнения запросов, нагрузочные и передав это в тестирование - уже полдела сделано. а так - итерация за итерацией с футболом тасками.
собственно, хотелось-бы услышать мнение - где мои аргументы не катят, и в каких кейсах постмановский подход реально вас выручал?
мискузи, ни плюс, ни минус. у всех разный опыт. всё.
очень классно, когда сможете сказанное ощутить не непонятностью, а звуком. мне это хорошо помогло в азии - звуки
не знаю, ребят. отметился - посмотрим, во что это выльется. а про свой стартап я напишу тоже на хабре - только сначала про тексты расскажу - как обещал )
насчёт дотнета - ну, логично, раз у него ноги растут из майкрософта. а вот насчёт Java - не знал, спасибо за комментарий!
да, тут я лажанулся - исправлю. занимаюсь серверными приложениями, десктоп - линукс и макось, а виндой пользовался последний раз лет 15 назад.. спасибо!
исправил, спасибо!
насчёт NFC для галочки - тут ноги растут вот откуда: мне не нужна была изначально полноценная библиотека - замена ICU - была практическая задача NFD/сопоставления для embedded-бд и NFKD для внутреннего поиска в проекте.
спасибо, статья - замечательная!
чтобы не быть голословным - опубликую в следующей статье
сейчас - нет, но сделать несложно
насчёт того, что алгоритм один - да, в курсе. я начал писать статьи не на ровном месте - у меня всё это дело реализовано (NF(K)D по бенчам - быстрее ICU4X, в некоторых кейсах - вдвое).
вот NFC у меня скорее для галочки реализована, и причина, почему думаю её вынести отдельно - хочу сначала поэкспериментировать с оптимизациями именно в композиции.
а так - да, совершенно согласен - рассказать про стартеры, вот это всё. исключения композиции, оптимизации используемые в бд, что где применяется.
спасибо за совет, постараюсь исправиться - давно не писал чего-либо связного - больше комментарии в коде.
интересно, всё-таки белый список почтовых сервисов или со своего домена в зоне .ru письмо тоже пройдёт?
спасибо! на оптимизации упор начнётся именно в нормализации :)
вопрос хороший, и, если честно, я не нашел на него ответа. исторические причины - хотели изначально как-то сгруппировать значения ССС, чтобы можно было использовать битовые маски для определения этих групп, а потом забили? или оставляли промежутки на всякий случай?
мне здесь больше не даёт покоя такая мысль - неужели нельзя было быть экономнее, и уложиться в 6 бит? дело в том, что если прочитать UnicodeData.txt из UCD (Unicode Character Database), содержащую определения свойств всех заданных символов Unicode, то можно увидеть, что используется ТОЛЬКО 56 различных значения Canonical Combining Class.
у меня вся почта на своих доменах. домены - в зонах ру и tech. если введут белые списки почтовиков, вроде mail.ru (а именно о таком подходе ходят слухи), я - в пролёте?
в разработке софт, который планирую зарелизить в конце года. там по-любому для клиентов нужна регистрация. мне теперь не ориентироваться иностранный рынок, иначе атата? это вообще не вредительство?
а если я на своем домене, где храню гит-репы, зарегистрируюсь по своему-же емейлу, который относится к тому же домену - это я вдвойне нарушаю, но как-то под-одеяльцем?
как можно назвать лучшего или худшего работодателя, не поработав там? это какой-то странный вопрос, - даже если предположить, что человек, отвечающий на вопрос поработал в 2-3 компаниях из списка представленных - как он может сравнивать их с остальными, какую выборку в результате вообще хотите получить?
с мясом, примерами и оптимизациями :)
насчет индексов, выборок в базе - это прям больное. такое впечатление, что ребят учат SQL, писать запросы различной сложности, но ни слова не говорят про то, что там под капотом - как хранятся данные, как устроены индексы.
сейчас делаю наброски серии статей про юникод - нормализация, сопоставления(collation) строк.. ну и поспрашивал окружающих - "а вы знаете, как вообще это происходит? как в бд, например, строятся индексы текстов?".. результаты - максимум есть понимание, что есть ключи, которые каким-то неведомым образом строятся из строчек, для одних локалей одни, для других - другие...
грустно это всё.
это какое-то вредительство.
спасибо за статью!
касательно статьи непосредственно - лучше-бы мухи отдельно, котлеты отдельно - описание методов запросов и кодов http-ответов (ну этого-то и так предостаточно прям везде!) как-то отделить от использования инструмента было-бы замечательно.
имхо, конечно, но когда-то постман был удобным и небольшим - прикладной комфортный в использовании инструмент для того, чтобы набросать апи и поделиться с коллегами. сейчас это какой-то перегруженный комбайн, по которому уже нужны туториалы, чтобы проникнуться всеми фичами.
постмановский подход сейчас хорош только для команд с большими комплексными апи их сервисов, или когда предполагаются разные сценарии использования, разные окружения и нагрузки.
в остальных случаях, как по мне, он избыточен:
- тесты можно писать на том же стеке, на котором написан основной код. это зачастую много быстрее.
- дробление тестов - относящиеся к апи - в одной парадигме, остальные тесты - в другой.. а есть ещё, наверняка, куча других инструментов, используемых в команде. и вот разрастание этого зоопарка может стать избыточным, требовать всё больших и больших трудозатрат, в то время когда время на непосредственно разработку уменьшается.
- понятно, что идея делегировать тестировщикам апи-тесты звучит неплохо - но непосредственно разработчику перед этим всё-равно нужно описать методы перед передачей в тестирование, всё-равно нужно набрасывать какие-то тесты при отладке. т.е. нужно посмотреть, насколько выгодно по человекочасам.
- где больше людей, инструментов, технологий - всегда больше ошибок. ну вот такие вот мы, люди, разработчики - пишем одни ошибки исправляя другие. большее количество ошибок увеличивает время до выкатки - если в одном случае разработчик тратит большее количество времени на начальном этапе - набросав тесты для проверки корректности исполнения запросов, нагрузочные и передав это в тестирование - уже полдела сделано. а так - итерация за итерацией с футболом тасками.
собственно, хотелось-бы услышать мнение - где мои аргументы не катят, и в каких кейсах постмановский подход реально вас выручал?
кстати, именование, проверенное временем - запись в шахматах не даст соврать. e2-e4.