Такого секретного комментария нет. Но, если даже эти «мадамы» пожалуются на кого-то через техподдержку, то служба поддержки проверит этот факт, и всё будет по-честному.
А можете более конкретно пояснить, что вы имеете в виду? Пока не понятен вопрос, непонятно с какой точки зрения вы спрашиваете. Куда бы вы лично положили? ))
1/ У людей должна быть мотивация делать хорошо.
2/ У нас в компании есть ревью. Каждый пишет что сделал, другие пишут хорошо ли сделал.
3/ Руководители общаются с сотрудниками 1:1, выясняют проблемы.
Спустя рукава относится к обязанностям не получится. Это будет сразу видно.
У каждой новой фичи есть хозяин — менеджер проекта по созданию этой фичи. Если поле логина на макетах нигде не будет подписано, то будет огромное кол-во тягомотины. И менеджер не успеет сделать проект в срок.
У вас есть хоть какой-то способ говорить работодателю о проблемах в процессе разработки? Ну а если сообщение о проблеме ничего не меняет, то… кстати, а вы на каком языке программирования пишете?))
А вы внимательный! Видимо, вы успели открыть статью в то недолгое время после публикации (где-то 1 час), когда эти опечатки были. Но сегодня ночью их уже точно не было.
К сожалению, мы пока не используем наши механизмы локализации для создания статей, но мы поработаем над этим!=)
Даже если использовать что-то готовое, то от понимания как это всё работает никуда не уйдешь. В статье говориться о подходе, концепции. Даже если вы что-то стороннее будете использовать, вам все равно придется задуматься о затронутых проблемах.
За присваивание лексемам описаний отвечает представитель команды локализации. Текстов много, но это совсем не проблема. Занесение происходит очень быстро. Да и у нас есть возможность копирования лексем и их настроек, если что-то очень похожее надо создать.
У нас в штате несколько переводчиков, они переводят на основные языки. Другие переводчики — фрилансеры, разбросанные по всему миру. Все переводчики — носители.
Эта автоматика работает, но, как ты помнишь (а другие не знают) она только для шаблонов. Этот подход не очень гибкий, он есть, но мы его никак не развиваем, а всё больше и больше пользуемся вызовом переводов лексем по ключам.
Не бойтесь! Оно работает!)) До сих пор. На хайлоаде в этом году рассказывал про этот инструмент.
Страшнее, когда продакт или клиент присылают скриншот, на котором текст не уместился.
«Не хочу писать, хочу клац-клац», так?)) Текст — это очень гибкая вещь. Написать можно все, что угодно. Нарисовать, например, производную уже сложнее.
Для «клац-клац» нужна не IDE, а набор написанных текстом подпрограмм.
Чем вам любая CMS не IDE c визуализацией? Модель? Модель. Подстраивается под нужды? Подстраивается. Вопрос мержа решен? Решен через блокировки. С текстом работаете? Нет.
Преждевременная типизация? Так не типизируйте, унаследуйте классы от от одного родителя, подцепите трейт и т.д. Создавайте слои абстракции, и ничто вам мешать не будет. Но чем ниже вы опускаетесь, тем более типизированным будет становиться ваш код.
Приведите пожалуйста примеры. Вообще непонятно, о чем вы рассуждаете. Проблемы проблемы проблемы… Пишите программы так, чтобы их было просто рефакторить, тогда и выработаются правильные абстракции.
Жесткий контракт, о котором вы писали, позволяет работать нескольким командам. А как он выражен, текстом или визуальной моделью, абсолютно неважно.
Вы программы для проектирования микросхем или сетей видели? Там прям объекты, протоколы, возможность симуляции работы. Почему это возможно? Из-за жесткой элементной базы, работающей на одном принципе. Предложите эти принципы, тогда и IDE будет проще простого построить. А до этого момента, различные люди будут создавать CMS разного рода, давая миру интерфейс управления определенной моделью.
1/ У людей должна быть мотивация делать хорошо.
2/ У нас в компании есть ревью. Каждый пишет что сделал, другие пишут хорошо ли сделал.
3/ Руководители общаются с сотрудниками 1:1, выясняют проблемы.
Спустя рукава относится к обязанностям не получится. Это будет сразу видно.
У вас есть хоть какой-то способ говорить работодателю о проблемах в процессе разработки? Ну а если сообщение о проблеме ничего не меняет, то… кстати, а вы на каком языке программирования пишете?))
К сожалению, мы пока не используем наши механизмы локализации для создания статей, но мы поработаем над этим!=)
Мы не сделали эту систему вчера, она развивалась и создавалась по мере необходимости очень долго. Она скоро совершеннолетие отпразднует.
И почему вы решили, что делать такую систему это не наше дело? Может всё-таки компания, работающая на 190 стран, знает что-то о локализации?
Бывает так, что в больших компаниях создаются крутые продукты, хотя они и не были целью существования этих компаний. Примеры привести?
А приходите к нам на митап по локализации. Расскажете о своих поисках нужного вам сервиса?
Даже если использовать что-то готовое, то от понимания как это всё работает никуда не уйдешь. В статье говориться о подходе, концепции. Даже если вы что-то стороннее будете использовать, вам все равно придется задуматься о затронутых проблемах.
За присваивание лексемам описаний отвечает представитель команды локализации. Текстов много, но это совсем не проблема. Занесение происходит очень быстро. Да и у нас есть возможность копирования лексем и их настроек, если что-то очень похожее надо создать.
У нас в штате несколько переводчиков, они переводят на основные языки. Другие переводчики — фрилансеры, разбросанные по всему миру. Все переводчики — носители.
Эта автоматика работает, но, как ты помнишь (а другие не знают) она только для шаблонов. Этот подход не очень гибкий, он есть, но мы его никак не развиваем, а всё больше и больше пользуемся вызовом переводов лексем по ключам.
делиться специальными знаниями…
И что же вы, друг мой, упустили другой момент:
Видимо, бомбит вас не по причине проблем с русским языком в статье. ( О, Боже, «вас бомбит». В укрытие!)
Страшнее, когда продакт или клиент присылают скриншот, на котором текст не уместился.
А теперь серьезно: даже ссылки на регистрацию почему-то на картинке.
Для «клац-клац» нужна не IDE, а набор написанных текстом подпрограмм.
Чем вам любая CMS не IDE c визуализацией? Модель? Модель. Подстраивается под нужды? Подстраивается. Вопрос мержа решен? Решен через блокировки. С текстом работаете? Нет.
Преждевременная типизация? Так не типизируйте, унаследуйте классы от от одного родителя, подцепите трейт и т.д. Создавайте слои абстракции, и ничто вам мешать не будет. Но чем ниже вы опускаетесь, тем более типизированным будет становиться ваш код.
Приведите пожалуйста примеры. Вообще непонятно, о чем вы рассуждаете. Проблемы проблемы проблемы… Пишите программы так, чтобы их было просто рефакторить, тогда и выработаются правильные абстракции.
Жесткий контракт, о котором вы писали, позволяет работать нескольким командам. А как он выражен, текстом или визуальной моделью, абсолютно неважно.
Вы программы для проектирования микросхем или сетей видели? Там прям объекты, протоколы, возможность симуляции работы. Почему это возможно? Из-за жесткой элементной базы, работающей на одном принципе. Предложите эти принципы, тогда и IDE будет проще простого построить. А до этого момента, различные люди будут создавать CMS разного рода, давая миру интерфейс управления определенной моделью.