Попробовал SteosVoice. На сайте даже нельзя прослушать примеры голосов, бесплатно доступно только 100 символов, чего не достаточно даже для того чтобы два голоса просто послушать. Какое-то неадекватное ограничение. При этом в Телеграм-боте интерфейс гораздо лучше и доступно довольно много символов бесплатно.
Сами голоса к сожалению оставляют желать много лучшего (слушал только английские). Из доступных английских голосов всего один звучал более менее реалистично, но на живых данных он запинался, неправильно читал некоторые слова и ритм речи был явно искусственным. В целом на рынке есть решения намного более качественные и реалистичные.
В данном случае всё ещё проще. У Сушильни точно не может быть десять уровней согласований и описанной Вами бюрократии, это не Майкрософт и не гос. корпорация. Руководителю компании достаточно просто попросить сотрудника-разработчика (или подрядчика) закрыть аутентификацию напрямую. Учитывая критичность ситуации, это вопрос часа работы максимум с учетом всех согласований и необходимых действий.
Вы описали какую-то невероятно забюрократизированную организацию. Современные подходы к разработке подразумевают, что компания может делает вплоть до нескольких релизов в день. А уж на то, чтобы закрыть аутентификацию на сайте достаточно буквально изменить одну строчку кода, если есть на то воля руководства.
Вы сначала закройте дыру оперативно, а потом уже можете думать о том что с этим делать и как задачу правильно решать. Просто кому-то важнее прибыль, а не безопасность данных клиентов.
В целях настоящего Федерального закона используются следующие основные понятия:
персональные данные - любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);
Классическая история, когда проект стартует с одного разработчика. Он что-то делает, заливает по FTP, тестирует и правит прямо на проде.
От плохих практик, которые Вы описываете аж волосы стынут в жилах. Если честно, сам уже лет 10 не сталкивался с тем, чтобы кто-то использовал FTP. Тяжело представить, что в наше время 12-факторных приложений, эфемерных сервисов, Кубернетиса и канареичных деплоев, кто-то занимается чем-то подобным. Надеюсь они увидят Вашу статью и она принесет им пользу.
Нет правила "1 задача=1 ветка в коде"
Создал в трекере 10 задач, но ребята решили делать их в одной ветке. В итоге дедлайн был вчера, но зарелизить мы не можем: в одной из некритичных задач критичный баг, который быстро не исправишь. При этом, если бы не общая ветка, мы без проблем могли бы зарелизить остальные 9 задач - и запустить систему. После разбора команда приняла подход. Но что интересно, когда я переходил в другую команду, нам пришлось проходить подобный “восхитительный” опыт заново.
Конечно, проблема с которой Вы столкнулись вполне объективна, но я бы на Вашем месте не был бы столь категоричным в выборе решения, т. е. в отказе от разработки в одной ветке. Это далеко не панацея. Представьте себе другую ситуацию — несколько разработчиков работают над большими фичами, каждый в своей ветке, в течение некоторого продолжительного времени. Когда приходит время объединить правки — оказывается, что между ветками накопилось столько конфликтов, что смержить их — непосильная задача. При этом первый разработчик кому это удалось сделать может пойти отдыхать, а всем остальным придется разбираться с конфликтами и переписывать свой код. В некоторых особо запущенных случаях (коим я был свидетелем) — работу из отдельной ветки можно было вообще выкинуть и начать писать с чистого листа используя только небольшие фрагменты ранее написанного кода.
У каждого подхода есть сильные и слабые стороны, Вы как CTO должны это понимать и не бросаться в крайности, призывая других однобоко выбрать тот или иной подход, не взвесив все плюсы и минусы.
Альтернативный подход не только существует, но и приобретает всё большую популярность. Называется он — Continuous Integration / Continuous Deployment или CI/CD. Почему-то в сообществе этим термином принято называть автоматизацию сборки приложения и всякие пайплайны, хотя это не совсем корректно и приводит к упущению сути. Адвокатом этого подхода является, например, Dave Farley (https://www.youtube.com/%40ContinuousDelivery).
Суть подхода в том, чтобы объединять правки как можно чаще, по-сути несколько раз в течение рабочего дня. Очевидно, что напилить целую фичу таким образом не получится. По этой причине код пишется таким образом, чтобы не ломать мастер и активироваться только после включения соответствующего фича-флага в конфигурации приложения. Это позволяет всем разработчикам комитить незавершенную работу в мастер небольшими кусочками и при этом этот код можно деплоить в продакшен. А чтобы ничего не сломалось (как в описанном Вами случае) как раз и нужен code review и автотесты. Такой подход позволяет в частности обнаруживать конфликты гораздо раньше и более успешно взаимодействовать с командой. Dave вообще рекомендует использовать техники парного программирования, в чем действительно есть определенный смысл, хотя недальновидным менеджерам такое предложение вряд-ли сильно понравится… :)
Мне этот паттерн сильно напоминает модель Блокчейна, где состояние блока неизменно, а данные имеют выраженный хронологический порядок.
Только не очень понятно, как осуществляется чтение и обеспечение консистентности в такой БД. Вы пишите про "отсутствие конфликтов при обработке транзакций", но как-то не совсем понятно за счет чего это может достигаться. Как к примеру избежать двойного списания стоимости заказа? По идее должен быть некий индекс, содержащий актуальную информацию объектов в системе и должна быть возможность выполнять транзакции или блокировать (lock) эти объекты перед добавлением новых событий, которые могут вызвать конфликт. Соответственно должен быть какой-то формат представления этого индекса и язык запросов к нему.
В целом, складывается ощущение, что это не альтернативный способ хранения данных, а скорее дополнение к традиционным инструментам, которое добавляет хронологическую перспективу работе с данными. Т. е. по-сути когда берется традиционная СУБД и все операции с данными записываются в отдельный лог (таблицу или коллекцию), помимо того, что эти изменения также фиксируются в основных таблицах/документах (snapshot).
Если так смотреть на этот вопрос, то получается, что это усложнение, которое дает два преимущества — возможность ретроспективного анализа событий (история всех операций) и возможность как-раз таки эту историю переписать (но Вы как раз говорите что этого не стоит делать), т. е. добавить/изменить какие-то события, чтобы, например, исправить баг приведщий к повреждению данных в прошлом и после этого пересчитать данные в основной таблице (обновить snapshot). Получится эффект того, как будто бага и не было.
Конечно, хотелось бы увидеть как этот паттерн применяется в конкретных решениях и какие задачи фактически закрывает.
Ну да, накладные расходы, конечно, есть. Хотя мне сложно представить ситуацию и объемы данных когда это было бы критично. Вероятно для таких исключительных ситуаций можно написать/форкнуть собственное супер-оптимизированное решение.
В целом внутрянка парсера позволяет реализовать механизм потокового чтения, думаю это не так сложно сделать.
А что Вы имеете ввиду под "все равно делает парсинг, даже когда это фактически не требуется" и "создаёт массу новых временных объектов"? Не совсем понятно.
Извиняюсь за капитальную задержку с ответом, не заметил среди уведомлений :)
Стоит заметить, что если Вы используете lock-файл, то сама по себе проблема возникнуть не может. Она может возникнуть только после обновления дерева зависимостей.
Первое что нужно сделать в такой ситуации — попытаться разобраться почему возникла проблема. Скорее всего нужно внести изменения либо в Ваш проект, либо в саму библиотеку. Возможны оба варианта — например делаем фикс у себя и пишем жалобу автору библиотеки.
В качестве временного фикса можно запинить зависимость в package.json. Если зависимость прямая, то это делается прямо в массиве "*dependencies", если транзитивная, то в "overrides". Но это не отменяет действий на предыдущем шаге.
На мой взгляд yarn был актуален достаточно давно, когда он только появился и работал в 3 раза быстрее, чем npm. Сейчас npm решает очень многие задачи. Из альтернатив я предпочитаю pnpm, он эффективнее, более строг и позволяет делать монорепы. Возможно у yarn есть какие-то свои преимущества, но у меня не возникала в этом потребность.
Ну, костылём я бы это не назвал. Вполне себе логичное (и ожидаемое) расширение нативного API.
А в чем сложность с json-lines? Сканируешь себе поток и скармливаешь строки парсеру постепенно. Не уверен что эту задачу в библиотеку стоит выделять, хотя, конечно, можно это сделать.
Я больше не сотрудничаю с ДомКлик (компания, которая спонсировала серию) и видимо они решили не развивать это направление.
А поделитесь мнением, что бы Вам было интересно еще узнать на эту тему? Возможно я найду время написать об этом дополнительно. Также, подписывайтесь на мой канал (https://t.me/js_is_not_java), надеюсь сможете найти там для себя что-то полезное.
Справедливо, но дело в том, что другие ЯП дают возможность разработчику самому решить как парсить JSON, в этом случае "implementation" (из вашей отсылки) это код разработчика. А авторы EcmaScript решили это за нас и не оставили нам никакого выбора (строго наложив ограничения IEEE 754). Собственно по этому мы и работает над расширением стандарта :)
А как в Lisp представляются большие числа? Python вот не имеет ограничений в размере чисел, но нужно понимать, что это всегда компромисс, ведь такая реализация всегда будет работать существенно медленнее, чем когда число целиком влезает в регистр процессора.
Отличный пример, спасибо, что поделились! Еще интересный момент, что Dev Tools в Google Chrome также показывает значения в отформатироанном JSON уже некорректно, что иногда сильно сбивает с толку :)
Могу на последней версии Ubuntu подтвердить, что со звуком всё ещё наблюдаются всякие странные чудеса, но в целом система довольно хорошо работает из коробки (Alienware Area 51m). В некотором смысле, аппаратная совместиомсть даже лучше, чем в Windows: например, под виндой M2 SSD-шник входит в какой-то странный режим работы и даже при простое системы начинает разогреваться до 70 градусов, пока система не падает с BSOD. Помогает только включение режима "экономия батареи", что негативно сказывается на производительности. Под Linux такой проблемы нет.
В целом, многие производители впринципе очень плохо относятся к поддержке своих устройств: найти какую-то документацию/драйвера/прошивку для некоторых устройств составляет существенную проблему даже под Windows, а эти устройства поставляются вместе с премиальными ноутбуками американских производителей (например DELL). Как правило, даже американские компании не обновляют ПО для своих устройств, а просто выпускают всё новые модели, про китайских я вообще молчу. В целом ситуация с низким качеством ПО носит системный характер.
Соглашусь с тем, что неопытному пользователю Linux врядли подойдёт, просто не представляю как пользоваться этой OS без использования терминала. Из последнего опыта установки Ubuntu: у меня даже Live USB не загрузилось с флешки: весь экран просто превращался в цветной шум. Чтобы пофиксить это было необходимо найти и прописать ряд параметров ядра в загрузчике GRUB. Назвать это приятным пользовательским опытом никак невозможно.
Ну и из реально критичного для меня — мало того, что установщик Ubuntu до сих пор не умеет использовать шифрование LUKS при установке рядом с Windows, так ещё и старый проверенный способ установки LUKS (через терминал с парой десятков команд), который работал годами, просто перестал работать в последней версии ОС и ни один гайд этого не учитывает, а у меня просто нет столько времени и желания копаться во всех премудростях загрузчиков, чтобы решить эту проблему самостоятельно. Приходится сидеть с "голой задницей" без шифрования диска.
По моим наблюдениям, работы для разработчиков ПО на порядки больше, чем квалифицированых специалистов готовых за неё браться. К сожалению мы живём в такой экономической системе, когда без финансирования практически невозможно привлечь внимание к тем или иным проблемам. Всё держится на OpenSource энтузиастах, которые инвестируют собственное время и на корпорациях (в тех местах где их интересы пересекаются с интересами общества). И стоит заметить, что очень малое количество энтузиастов может позволить себе работать 100% времени над OpenSource проектами, общество просто не готово платить за это и в своей массе привыкло паразитировать и получать всё бесплатно как должное.
Попробовал SteosVoice. На сайте даже нельзя прослушать примеры голосов, бесплатно доступно только 100 символов, чего не достаточно даже для того чтобы два голоса просто послушать. Какое-то неадекватное ограничение. При этом в Телеграм-боте интерфейс гораздо лучше и доступно довольно много символов бесплатно.
Сами голоса к сожалению оставляют желать много лучшего (слушал только английские). Из доступных английских голосов всего один звучал более менее реалистично, но на живых данных он запинался, неправильно читал некоторые слова и ритм речи был явно искусственным. В целом на рынке есть решения намного более качественные и реалистичные.
Использовать FTP для деплоя сайта в 2023 это, конечно, очень сильно…
Техстек и технический уровень статьи примерно на уровне нулевых годов.
В данном случае всё ещё проще. У Сушильни точно не может быть десять уровней согласований и описанной Вами бюрократии, это не Майкрософт и не гос. корпорация. Руководителю компании достаточно просто попросить сотрудника-разработчика (или подрядчика) закрыть аутентификацию напрямую. Учитывая критичность ситуации, это вопрос часа работы максимум с учетом всех согласований и необходимых действий.
Вы описали какую-то невероятно забюрократизированную организацию. Современные подходы к разработке подразумевают, что компания может делает вплоть до нескольких релизов в день. А уж на то, чтобы закрыть аутентификацию на сайте достаточно буквально изменить одну строчку кода, если есть на то воля руководства.
Вы сначала закройте дыру оперативно, а потом уже можете думать о том что с этим делать и как задачу правильно решать. Просто кому-то важнее прибыль, а не безопасность данных клиентов.
Да, Вы правы. Однако в данном случае дыра слишком явная. За 30 дней базу 100% сольют, а так есть шанс, что руководство закроет дыру оперативно.
Я не эксперт в юридических вопросах, но в законе (https://www.consultant.ru/cons/cgi/online.cgi?from=370272-0&req=doc&rnd=ECcSsQ&base=LAW&n=422875#VYdWpXT4y0JtvT581) написано:
От плохих практик, которые Вы описываете аж волосы стынут в жилах. Если честно, сам уже лет 10 не сталкивался с тем, чтобы кто-то использовал FTP. Тяжело представить, что в наше время 12-факторных приложений, эфемерных сервисов, Кубернетиса и канареичных деплоев, кто-то занимается чем-то подобным. Надеюсь они увидят Вашу статью и она принесет им пользу.
Конечно, проблема с которой Вы столкнулись вполне объективна, но я бы на Вашем месте не был бы столь категоричным в выборе решения, т. е. в отказе от разработки в одной ветке. Это далеко не панацея. Представьте себе другую ситуацию — несколько разработчиков работают над большими фичами, каждый в своей ветке, в течение некоторого продолжительного времени. Когда приходит время объединить правки — оказывается, что между ветками накопилось столько конфликтов, что смержить их — непосильная задача. При этом первый разработчик кому это удалось сделать может пойти отдыхать, а всем остальным придется разбираться с конфликтами и переписывать свой код. В некоторых особо запущенных случаях (коим я был свидетелем) — работу из отдельной ветки можно было вообще выкинуть и начать писать с чистого листа используя только небольшие фрагменты ранее написанного кода.
У каждого подхода есть сильные и слабые стороны, Вы как CTO должны это понимать и не бросаться в крайности, призывая других однобоко выбрать тот или иной подход, не взвесив все плюсы и минусы.
Альтернативный подход не только существует, но и приобретает всё большую популярность. Называется он — Continuous Integration / Continuous Deployment или CI/CD. Почему-то в сообществе этим термином принято называть автоматизацию сборки приложения и всякие пайплайны, хотя это не совсем корректно и приводит к упущению сути. Адвокатом этого подхода является, например, Dave Farley (https://www.youtube.com/%40ContinuousDelivery).
Суть подхода в том, чтобы объединять правки как можно чаще, по-сути несколько раз в течение рабочего дня. Очевидно, что напилить целую фичу таким образом не получится. По этой причине код пишется таким образом, чтобы не ломать мастер и активироваться только после включения соответствующего фича-флага в конфигурации приложения. Это позволяет всем разработчикам комитить незавершенную работу в мастер небольшими кусочками и при этом этот код можно деплоить в продакшен. А чтобы ничего не сломалось (как в описанном Вами случае) как раз и нужен code review и автотесты. Такой подход позволяет в частности обнаруживать конфликты гораздо раньше и более успешно взаимодействовать с командой. Dave вообще рекомендует использовать техники парного программирования, в чем действительно есть определенный смысл, хотя недальновидным менеджерам такое предложение вряд-ли сильно понравится… :)
Мне этот паттерн сильно напоминает модель Блокчейна, где состояние блока неизменно, а данные имеют выраженный хронологический порядок.
Только не очень понятно, как осуществляется чтение и обеспечение консистентности в такой БД. Вы пишите про "отсутствие конфликтов при обработке транзакций", но как-то не совсем понятно за счет чего это может достигаться. Как к примеру избежать двойного списания стоимости заказа? По идее должен быть некий индекс, содержащий актуальную информацию объектов в системе и должна быть возможность выполнять транзакции или блокировать (lock) эти объекты перед добавлением новых событий, которые могут вызвать конфликт. Соответственно должен быть какой-то формат представления этого индекса и язык запросов к нему.
В целом, складывается ощущение, что это не альтернативный способ хранения данных, а скорее дополнение к традиционным инструментам, которое добавляет хронологическую перспективу работе с данными. Т. е. по-сути когда берется традиционная СУБД и все операции с данными записываются в отдельный лог (таблицу или коллекцию), помимо того, что эти изменения также фиксируются в основных таблицах/документах (snapshot).
Если так смотреть на этот вопрос, то получается, что это усложнение, которое дает два преимущества — возможность ретроспективного анализа событий (история всех операций) и возможность как-раз таки эту историю переписать (но Вы как раз говорите что этого не стоит делать), т. е. добавить/изменить какие-то события, чтобы, например, исправить баг приведщий к повреждению данных в прошлом и после этого пересчитать данные в основной таблице (обновить snapshot). Получится эффект того, как будто бага и не было.
Конечно, хотелось бы увидеть как этот паттерн применяется в конкретных решениях и какие задачи фактически закрывает.
Ну да, накладные расходы, конечно, есть. Хотя мне сложно представить ситуацию и объемы данных когда это было бы критично. Вероятно для таких исключительных ситуаций можно написать/форкнуть собственное супер-оптимизированное решение.
В целом внутрянка парсера позволяет реализовать механизм потокового чтения, думаю это не так сложно сделать.
А что Вы имеете ввиду под "все равно делает парсинг, даже когда это фактически не требуется" и "создаёт массу новых временных объектов"? Не совсем понятно.
Извиняюсь за капитальную задержку с ответом, не заметил среди уведомлений :)
Стоит заметить, что если Вы используете lock-файл, то сама по себе проблема возникнуть не может. Она может возникнуть только после обновления дерева зависимостей.
Первое что нужно сделать в такой ситуации — попытаться разобраться почему возникла проблема. Скорее всего нужно внести изменения либо в Ваш проект, либо в саму библиотеку. Возможны оба варианта — например делаем фикс у себя и пишем жалобу автору библиотеки.
В качестве временного фикса можно запинить зависимость в package.json. Если зависимость прямая, то это делается прямо в массиве "*dependencies", если транзитивная, то в "overrides". Но это не отменяет действий на предыдущем шаге.
На мой взгляд yarn был актуален достаточно давно, когда он только появился и работал в 3 раза быстрее, чем npm. Сейчас npm решает очень многие задачи. Из альтернатив я предпочитаю pnpm, он эффективнее, более строг и позволяет делать монорепы. Возможно у yarn есть какие-то свои преимущества, но у меня не возникала в этом потребность.
https://www.json.org/json-en.html
Ну, костылём я бы это не назвал. Вполне себе логичное (и ожидаемое) расширение нативного API.
А в чем сложность с json-lines? Сканируешь себе поток и скармливаешь строки парсеру постепенно. Не уверен что эту задачу в библиотеку стоит выделять, хотя, конечно, можно это сделать.
Я больше не сотрудничаю с ДомКлик (компания, которая спонсировала серию) и видимо они решили не развивать это направление.
А поделитесь мнением, что бы Вам было интересно еще узнать на эту тему? Возможно я найду время написать об этом дополнительно. Также, подписывайтесь на мой канал (https://t.me/js_is_not_java), надеюсь сможете найти там для себя что-то полезное.
Справедливо, но дело в том, что другие ЯП дают возможность разработчику самому решить как парсить JSON, в этом случае "implementation" (из вашей отсылки) это код разработчика. А авторы EcmaScript решили это за нас и не оставили нам никакого выбора (строго наложив ограничения IEEE 754). Собственно по этому мы и работает над расширением стандарта :)
Наверное это не совсем соотносится с тематикой статьи, но, тем не менее, рекомендую посмотреть как этот вопрос решается в стандарте JSON Schema (https://json-schema.org/understanding-json-schema/structuring.html) возможно будет полезно.
А как в Lisp представляются большие числа? Python вот не имеет ограничений в размере чисел, но нужно понимать, что это всегда компромисс, ведь такая реализация всегда будет работать существенно медленнее, чем когда число целиком влезает в регистр процессора.
Отличный пример, спасибо, что поделились! Еще интересный момент, что Dev Tools в Google Chrome также показывает значения в отформатироанном JSON уже некорректно, что иногда сильно сбивает с толку :)
Благодарю за подробную статью!
Не знаете, а есть ли сейчас страны, где можно удаленно открыть счёт и банковскую карту без ВНЖ?
Могу на последней версии Ubuntu подтвердить, что со звуком всё ещё наблюдаются всякие странные чудеса, но в целом система довольно хорошо работает из коробки (Alienware Area 51m). В некотором смысле, аппаратная совместиомсть даже лучше, чем в Windows: например, под виндой M2 SSD-шник входит в какой-то странный режим работы и даже при простое системы начинает разогреваться до 70 градусов, пока система не падает с BSOD. Помогает только включение режима "экономия батареи", что негативно сказывается на производительности. Под Linux такой проблемы нет.
В целом, многие производители впринципе очень плохо относятся к поддержке своих устройств: найти какую-то документацию/драйвера/прошивку для некоторых устройств составляет существенную проблему даже под Windows, а эти устройства поставляются вместе с премиальными ноутбуками американских производителей (например DELL). Как правило, даже американские компании не обновляют ПО для своих устройств, а просто выпускают всё новые модели, про китайских я вообще молчу. В целом ситуация с низким качеством ПО носит системный характер.
Соглашусь с тем, что неопытному пользователю Linux врядли подойдёт, просто не представляю как пользоваться этой OS без использования терминала. Из последнего опыта установки Ubuntu: у меня даже Live USB не загрузилось с флешки: весь экран просто превращался в цветной шум. Чтобы пофиксить это было необходимо найти и прописать ряд параметров ядра в загрузчике GRUB. Назвать это приятным пользовательским опытом никак невозможно.
Ну и из реально критичного для меня — мало того, что установщик Ubuntu до сих пор не умеет использовать шифрование LUKS при установке рядом с Windows, так ещё и старый проверенный способ установки LUKS (через терминал с парой десятков команд), который работал годами, просто перестал работать в последней версии ОС и ни один гайд этого не учитывает, а у меня просто нет столько времени и желания копаться во всех премудростях загрузчиков, чтобы решить эту проблему самостоятельно. Приходится сидеть с "голой задницей" без шифрования диска.
По моим наблюдениям, работы для разработчиков ПО на порядки больше, чем квалифицированых специалистов готовых за неё браться. К сожалению мы живём в такой экономической системе, когда без финансирования практически невозможно привлечь внимание к тем или иным проблемам. Всё держится на OpenSource энтузиастах, которые инвестируют собственное время и на корпорациях (в тех местах где их интересы пересекаются с интересами общества). И стоит заметить, что очень малое количество энтузиастов может позволить себе работать 100% времени над OpenSource проектами, общество просто не готово платить за это и в своей массе привыкло паразитировать и получать всё бесплатно как должное.