Очень интересно прочитать про опыт работы с библиотекой компонентов. Подскажите, пожалуйста, при обновлении версий библиотеки элементов для конечного потребителя, вы используете тесты — например snapshot / visual regression? Или кодмоды для обновления использования компонентов?
Попробую рассказать подробнее про ускорение разработки на TypeScript и про Prop-types в React UI компонентах :)
Сразу скажу, что примеры будут из личного опыта, полученного на проектах разного масштаба и в различных командах.
Prop-types — это проверка в run-time. То есть, чтобы проверить, что интерфейс компонента актуален при внесении изменений в ветку у нас есть, как минимум, 2 стратегии:
1) открыть браузер и проверить в консоли каждую страницу. Если мы поменяли интерфейс базового компонента и он используется в 100 страницах? Или для показа компонента надо будет выполнить определенные условия (кликнуть на третьем экране вниз, загрузить фото, ввести пароль). Это будет очень затратно по времени. Это становится явной проблемой, когда необходимо поддерживать и обновлять UI-библиотеки на средних и больших проектах.
2) Запустить песочницу/библиотеку компонентов с документацией. Допустим, что у нас все компоненты и их интерфейсы видны и описаны и их можно проверить либо руками, либо через visual regression tests сравнить изменения. Это может быть быстрее первого способа, но все равно займет какое-то время и не гарантирует однозначного результата.
Оффтоп про конлфикты типов в UI компонентах
Тут можно подробнее углубиться в конфликты типов при отображении UI компонентов, если будет интересно, то отдельно приведу примеры.
Если интерфейс компонента на TypeScript, то проверка на типы будет при сборке проекта и также по запросу введением одной команды в консоли. Мы сразу получаем все возможные конфликты и проблемы в отчете проверки при автоматическом проходе по всем компонентам. Это самый быстрый способ. Это ощущается и в масштабе, когда один разработчик работает над проектом и когда в команде 10+ разработчиков, которые параллельно доставляют различные фичи.
Априори мы исходим из того, что проверка типов при разработке — это минимальная и быстрая проверка на явные баги. А так как эта проверка в TypeScript работает сразу из коробки — мы снижаем нагрузку на разработчиков и у нас появляется больше времени на разработку нового функционала, так как цикл разработки ускоряется без риска потери качества.
Более детальный пример — это проверка типов при конфликтах веток. Решение конфликтов занимает меньше времени за счет автоматической проверки и всплывающих подсказок в редакторах. В обоих примерах смена типов также может быть автоматизирована.
И главный момент — Prop-types не гарантирует строго соблюдения правил.
Явный пример
Казалось бы — в текущем примере мы ничего не испортили. Потому как внутри UI компонента простой render. Однако если в компоненте были какие-то изменения текста — убирания пробелов, строка с большой буквы), то в этом случае мы потратим значительное время на проверку типов или рискуем пропустить код с ошибкой на Production. А в случае с TypeScript — мы в момент сборки знаем о проблеме
Тем самым TypeScript позволяет ускорить разработку и поддержку приложений в части UI, даже если мы говорим об очень простых компонентах.
Конечно, внедрение TypeScript потребует определенного времени для команды, но это уже другой аспект, который я уже описал в статье)
В нашем случае это помогло обеспечить стабильность кодовой базы, безопасное переиспользование компонентов, что позволило нам ускорить работу над проектами.
Что касается доставки фичей — за счет распределения задач мы не замедляли темпы: пока часть команды занималась продуктовыми задачами м сразу писали код на typescript, а другая часть команды — переводила код на TypeScript. Грамотный баланс в данном случае достигался за счет планирования нагрузки и еженедельной оценки прогресса. C технической точки зрения в любой момент любого участник проекта мог переключить на другие задачи, остановить процесс перевода и возобновить работу, когда появлялось время.
Также мы изначально выделили время на техническое планирование, чтобы сразу определить, насколько можно разделить проекты на этапы и впоследствии изолировано выполнять их.
Также в продолжении — существует открытая библиотека для распознавания номеров — openalpr — github.com/openalpr/openalpr — написана на c++, работает с C#, Java, Node.js, Go, и Python — ее можно применять как для автоматизации ворот и шлагбаумов, так и для других целей, связанных с распознаванием номеров автомобилей. Подчерпнул из комментариев к оригинальной статье.
Мнение переводчика: техническая часть статьи мне показалась увлекательной и вдохновляющей для тех людей, кто делает инди-разработку или изучает возможность сделать iot/web-проект своими руками.
Вместе с тем, я постарался снизить эмоциональный тон автора, поправив заголовок. Все-таки это именно прототип системы. Здорово, что автор смог его быстро собрать и начать использовать — это вызывает только позитивные эмоции.
Вместе с тем, большинству читателей ресурса явно бросилась в глаза достаточно своеобразная манера сравнения экономических процессов в оригинальном тексте. Так как это перевод, я сохранил авторские абзацы, но не соглашусь с возможностью сравнения стоимости прототипа и ИТ-системы.
Во-первых, сложно оценить «некодовую» часть нагрузки по внедрению прототипа в работу. Когда это выполняется сотрудником предприятия — это его рабочее время. Как правило, подобным занимается проектный коллектив. Это очень упрощенное представление. Но для примера предположим, что так. Его можно конвертировать в зарплату и получить цифры. Но это будут разные цифры для разных компаний — в зависимости от их скорости принятий решений, опыта в сфере, ресурсной базы и прочих параметров.
Во-вторых, те, кто внедрял прототип в рамках стартапа, понимает сколько времени и сил требуется для обеспечения перехода от прототипа к масштабируемому решению, готовому к продаже. Это определенные расходы, которые затем требуется покрыть. Не буду перечислять весь пулл, но это, как минимум, юридическое и бухгалтерское сопровождение.
В-третьих, важный компонент любой компании — это ее люди, для них должны быть выделены рабочие места. Любая компания платит зарплату своим сотрудникам. А это обязывает ее получать регулярный доход. А если представить, что компания выпускает только одно решение и продает только его, то стоимость системы уже не будет казаться астрономической. Особенно, если она сразу включает стоимость обслуживания на определенный период времени всей системы. Но это тоже звучит достаточно абстрактно без документации системы.
Это неполный список того, почему сравнение прототипов и готовых проектов — не очень полезная практика. Вместе с тем подобная статья может вдохновить читателей именно на diy-проекты и самостоятельное изучение технических проектов и их реализации.
А что касается идей по несостоятельности самой системы видеонаблюдения — это достаточно открытый вопрос. Думаю что многие технические специалисты в области видео-распознавания и создания подобных систем скажут, как обойти те или иные ограничения и проблемы. Конечно, прогресс будет идти «с обеих» сторон, то есть способы угона могут также усложнятся. Но так как знания — это не просто набор статических неизменных представлений, думаю, что технический прогресс поможет решать проблемы, связанные с угоном и другими проблемами — было бы желание.
Надеюсь, что в целом статья вдохновит читателей на дальнейшее изучение современных технологий и создание своих веб-проектов.
Согласен по данному поводу. К сожалению, достаточно часто принято упрощать видение многих достаточно комплексных вопросов до уровня обывателя. В оригинале заголовок статьи был явно «кричащим»: что за ним терялась хорошая идея: возможность оптимизации тех или иных технологий техническим специалистом. Подобные оптимизации могут быть взяты в работу или обсуждены на публичных площадках — это полезно для всех участников процесса.
Возможно, но это означает, что мы делаем очень серьезное обобщение о том, что можно использовать один универсальный способ. Если такой способ выравнивания существовал, то он уже применялся в графических редакторах и в работе.
Эта идея явно не работает для ряда фигур. Не буду обобщать, что она вообще не работает: я попробовал этот метод на разных иконках и получилось, что соотношение положительных и отрицательных результатов примерно равно 50/50. Я специально оставил этот метод и написал свое мнение в виде рекомендаций, так как в интернете нет явной критики или обсуждения этих методов.
Думаю, что причина кроется в том на кого ориентирована статья. Метод изначально ориентирован на людей с дизайн-опытом, который понимает, когда его можно применять, а когда — нет. Для верстальщиков и разработчиков без опыта в дизайне подобный метод превращается в «рисование совы». Поэтому я попробовал добавить более универсальные решения в статью,
Это самый интересный эпизод. Дело в том, что чем больше людей будет участвовать в процессе дизайна / верстки / разработки, то тем больше разных мнений может быть по поводу, как правильно выравнивать. Проблема возникает, когда каждый участник понимает этот вопрос по-своему и в итоге на проекте могут быть иконки с разным выравниванием.
Для коллектива даже из 2 человек лучше всего договорится об использовании одного подхода к оптическому выравниванию.
Согласен, для многих разработчиков такой способ затратен по времени и обладает рядом ограничений, которые я упомянул в статье перед блоком с теорией.
Но для ряда специалистов он будет оптимален, например, для web-дизайнеров и тех, кто совмещает их функции в своей работе. И по моему мнению им имеет смысл знать об ограничениях, которые имеют данные способы, о чем я писал в примерах использования метода вращения в этой статье.
Да, это определенным образом облегчит задачу. В случае, если мы не можем менять дизайн, то для выравнивания следует обратиться к дизайнерам. Я попробую разобрать такой случай более детально в другой статье.
В первом случае, к сожалению, нет. Фигура алмаза в статье является таким примером. Возможно я смогу собрать достаточно материала, чтобы дать четкое определение для таких фигур на этапе знания только их координат. Это будет материал для следующей статьи.
Во втором вопросе важно сделать коэффициенты поправки на цвет. Достаточно много исключений: прозрачность, пересекаемость цвета фигуры и фоны. Думаю, что это тоже можно будет описать отдельной статьей.
Да, это опечатка с моей стороны. Дело в том, что при разборе теории я собрал способы для плоских и трехмерных фигур, затем при верстке статьи я оценил её масштабы и убрал блок про трехмерные фигуры. Данное уточнение осталось с тех самых пор.
Спасибо! Соберу всю обратную связь и постараюсь её отразить в дальнейших статьях, как пример — применение разных методов поиска барицентра для одной сложной фигуры.
Про алмаз — согласен в первых двух пунктах. Но третий пункт не совсем корректен, он слишком сильно обобщает большой пласт фигур. Я стремился показать, что есть разные способы для разных фигур.
Я вижу это так:
1) Автоматический способ выравнивания в графических редакторах — его область применения и ограничения.
2) Распространенные в сети ручные способы выравнивания из области графического дизайна — их область применения и ограничения.
3) Наиболее общие ручные способы выравнивания из области геометрии — опять же область применения и ограничения.
4) Способ выравнивания из области геометрии, который можно автоматизировать. И вновь говорю, что он не панацея.
Я рассматривал этот вопрос с точки зрения разработчиков, не дизайнеров. Мой вывод заключался в том, что автоматизировать можно не все и в ряде случаев — стоит обращаться к дизайнерам.
Здесь скорее вопрос с какой стороны взглянуть на проблему. Со стороны опытного дизайнера, например, вопросов в том, как выполнять оптическое выравнивание — нет. Ему не нужны подходы из области геометрии, указанные статье, он будет применять другие способы. А для разработчиков в большинстве случаев можно решить вопрос самостоятельно.
Согласен, если добавить единый пример, то он станет отличным визуальным лейтмотивом статьи. Так получилось, что именно форма алмаза показала наиболее противоречивые результаты. С одной стороны — визуальные способы показали определенный прогресс в сравнении с автоматическим выравниванием на её примере. С другой стороны — формулы поиска барицентра не дали однозначного, даже с погрешностью, положения фигуры по вертикали, хотя по горизонтали прослеживается явная симметрия и там автоматическое выравнивание работает правильно. И с третьей стороны — могло создаться впечатление, что на примере одной фигуры ситуация с выравниванием сильно упрощается — как будто для одной фигуры нам потребуется один точный метод.
Поэтому я отказался от этой идеи, сделав статью более абстрактной, но сохранив её практическое направление: применение методов оптического выравнивания. Для простых фигур использую одни методы, для сложных — другие, максимально автоматизируя процесс, сокращая время для решения задач. Тем самым каждый заинтересовавшийся читатель сможет самостоятельно сделать выбор, как именно ему стоит поступать в такой ситуации и какой способ решения задачи применять: обратится к дизайнерам, провести один раз ревизию иконок вручную или применять автоматизированные способы.
Спасибо за интересную идею! Я попробую рассмотреть в дальнейшем способы автоматизации такой формулы для разных платформ. Я достаточно хорошо сейчас представляю, как на входе можно передать параметры из градиента, заданного в svg или css в качестве фона для фигуры. Это подойдет для svg-обработчика на уровне сборки проекта. Для графических редакторов — Adobe Photoshop, Sketch — надо будет поэксперементировать со значениями на входе.
Ростислав, спасибо за статью!
Очень интересно прочитать про опыт работы с библиотекой компонентов. Подскажите, пожалуйста, при обновлении версий библиотеки элементов для конечного потребителя, вы используете тесты — например snapshot / visual regression? Или кодмоды для обновления использования компонентов?
Сразу скажу, что примеры будут из личного опыта, полученного на проектах разного масштаба и в различных командах.
Prop-types — это проверка в run-time. То есть, чтобы проверить, что интерфейс компонента актуален при внесении изменений в ветку у нас есть, как минимум, 2 стратегии:
1) открыть браузер и проверить в консоли каждую страницу. Если мы поменяли интерфейс базового компонента и он используется в 100 страницах? Или для показа компонента надо будет выполнить определенные условия (кликнуть на третьем экране вниз, загрузить фото, ввести пароль). Это будет очень затратно по времени. Это становится явной проблемой, когда необходимо поддерживать и обновлять UI-библиотеки на средних и больших проектах.
2) Запустить песочницу/библиотеку компонентов с документацией. Допустим, что у нас все компоненты и их интерфейсы видны и описаны и их можно проверить либо руками, либо через visual regression tests сравнить изменения. Это может быть быстрее первого способа, но все равно займет какое-то время и не гарантирует однозначного результата.
Если интерфейс компонента на TypeScript, то проверка на типы будет при сборке проекта и также по запросу введением одной команды в консоли. Мы сразу получаем все возможные конфликты и проблемы в отчете проверки при автоматическом проходе по всем компонентам. Это самый быстрый способ. Это ощущается и в масштабе, когда один разработчик работает над проектом и когда в команде 10+ разработчиков, которые параллельно доставляют различные фичи.
Априори мы исходим из того, что проверка типов при разработке — это минимальная и быстрая проверка на явные баги. А так как эта проверка в TypeScript работает сразу из коробки — мы снижаем нагрузку на разработчиков и у нас появляется больше времени на разработку нового функционала, так как цикл разработки ускоряется без риска потери качества.
Более детальный пример — это проверка типов при конфликтах веток. Решение конфликтов занимает меньше времени за счет автоматической проверки и всплывающих подсказок в редакторах. В обоих примерах смена типов также может быть автоматизирована.
И главный момент — Prop-types не гарантирует строго соблюдения правил.
Казалось бы — в текущем примере мы ничего не испортили. Потому как внутри UI компонента простой render. Однако если в компоненте были какие-то изменения текста — убирания пробелов, строка с большой буквы), то в этом случае мы потратим значительное время на проверку типов или рискуем пропустить код с ошибкой на Production. А в случае с TypeScript — мы в момент сборки знаем о проблеме
Тем самым TypeScript позволяет ускорить разработку и поддержку приложений в части UI, даже если мы говорим об очень простых компонентах.
Конечно, внедрение TypeScript потребует определенного времени для команды, но это уже другой аспект, который я уже описал в статье)
В нашем случае это помогло обеспечить стабильность кодовой базы, безопасное переиспользование компонентов, что позволило нам ускорить работу над проектами.
Что касается доставки фичей — за счет распределения задач мы не замедляли темпы: пока часть команды занималась продуктовыми задачами м сразу писали код на typescript, а другая часть команды — переводила код на TypeScript. Грамотный баланс в данном случае достигался за счет планирования нагрузки и еженедельной оценки прогресса. C технической точки зрения в любой момент любого участник проекта мог переключить на другие задачи, остановить процесс перевода и возобновить работу, когда появлялось время.
Также мы изначально выделили время на техническое планирование, чтобы сразу определить, насколько можно разделить проекты на этапы и впоследствии изолировано выполнять их.
Вместе с тем, я постарался снизить эмоциональный тон автора, поправив заголовок. Все-таки это именно прототип системы. Здорово, что автор смог его быстро собрать и начать использовать — это вызывает только позитивные эмоции.
Вместе с тем, большинству читателей ресурса явно бросилась в глаза достаточно своеобразная манера сравнения экономических процессов в оригинальном тексте. Так как это перевод, я сохранил авторские абзацы, но не соглашусь с возможностью сравнения стоимости прототипа и ИТ-системы.
Во-первых, сложно оценить «некодовую» часть нагрузки по внедрению прототипа в работу. Когда это выполняется сотрудником предприятия — это его рабочее время. Как правило, подобным занимается проектный коллектив. Это очень упрощенное представление. Но для примера предположим, что так. Его можно конвертировать в зарплату и получить цифры. Но это будут разные цифры для разных компаний — в зависимости от их скорости принятий решений, опыта в сфере, ресурсной базы и прочих параметров.
Во-вторых, те, кто внедрял прототип в рамках стартапа, понимает сколько времени и сил требуется для обеспечения перехода от прототипа к масштабируемому решению, готовому к продаже. Это определенные расходы, которые затем требуется покрыть. Не буду перечислять весь пулл, но это, как минимум, юридическое и бухгалтерское сопровождение.
В-третьих, важный компонент любой компании — это ее люди, для них должны быть выделены рабочие места. Любая компания платит зарплату своим сотрудникам. А это обязывает ее получать регулярный доход. А если представить, что компания выпускает только одно решение и продает только его, то стоимость системы уже не будет казаться астрономической. Особенно, если она сразу включает стоимость обслуживания на определенный период времени всей системы. Но это тоже звучит достаточно абстрактно без документации системы.
Это неполный список того, почему сравнение прототипов и готовых проектов — не очень полезная практика. Вместе с тем подобная статья может вдохновить читателей именно на diy-проекты и самостоятельное изучение технических проектов и их реализации.
А что касается идей по несостоятельности самой системы видеонаблюдения — это достаточно открытый вопрос. Думаю что многие технические специалисты в области видео-распознавания и создания подобных систем скажут, как обойти те или иные ограничения и проблемы. Конечно, прогресс будет идти «с обеих» сторон, то есть способы угона могут также усложнятся. Но так как знания — это не просто набор статических неизменных представлений, думаю, что технический прогресс поможет решать проблемы, связанные с угоном и другими проблемами — было бы желание.
Надеюсь, что в целом статья вдохновит читателей на дальнейшее изучение современных технологий и создание своих веб-проектов.
Думаю, что причина кроется в том на кого ориентирована статья. Метод изначально ориентирован на людей с дизайн-опытом, который понимает, когда его можно применять, а когда — нет. Для верстальщиков и разработчиков без опыта в дизайне подобный метод превращается в «рисование совы». Поэтому я попробовал добавить более универсальные решения в статью,
Для коллектива даже из 2 человек лучше всего договорится об использовании одного подхода к оптическому выравниванию.
Но для ряда специалистов он будет оптимален, например, для web-дизайнеров и тех, кто совмещает их функции в своей работе. И по моему мнению им имеет смысл знать об ограничениях, которые имеют данные способы, о чем я писал в примерах использования метода вращения в этой статье.
В первом случае, к сожалению, нет. Фигура алмаза в статье является таким примером. Возможно я смогу собрать достаточно материала, чтобы дать четкое определение для таких фигур на этапе знания только их координат. Это будет материал для следующей статьи.
Во втором вопросе важно сделать коэффициенты поправки на цвет. Достаточно много исключений: прозрачность, пересекаемость цвета фигуры и фоны. Думаю, что это тоже можно будет описать отдельной статьей.
Я вижу это так:
1) Автоматический способ выравнивания в графических редакторах — его область применения и ограничения.
2) Распространенные в сети ручные способы выравнивания из области графического дизайна — их область применения и ограничения.
3) Наиболее общие ручные способы выравнивания из области геометрии — опять же область применения и ограничения.
4) Способ выравнивания из области геометрии, который можно автоматизировать. И вновь говорю, что он не панацея.
Я рассматривал этот вопрос с точки зрения разработчиков, не дизайнеров. Мой вывод заключался в том, что автоматизировать можно не все и в ряде случаев — стоит обращаться к дизайнерам.
Здесь скорее вопрос с какой стороны взглянуть на проблему. Со стороны опытного дизайнера, например, вопросов в том, как выполнять оптическое выравнивание — нет. Ему не нужны подходы из области геометрии, указанные статье, он будет применять другие способы. А для разработчиков в большинстве случаев можно решить вопрос самостоятельно.
Поэтому я отказался от этой идеи, сделав статью более абстрактной, но сохранив её практическое направление: применение методов оптического выравнивания. Для простых фигур использую одни методы, для сложных — другие, максимально автоматизируя процесс, сокращая время для решения задач. Тем самым каждый заинтересовавшийся читатель сможет самостоятельно сделать выбор, как именно ему стоит поступать в такой ситуации и какой способ решения задачи применять: обратится к дизайнерам, провести один раз ревизию иконок вручную или применять автоматизированные способы.