Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
QA Specialist в Wire
  • «Полювання» на пам’ять. Практичні рекомендації щодо уникнення memory leaks на прикладі Node.js

    Это доступно с версий 0.Х.Х. В галактических рамках десяток лет это конечно же ничто, но все-таки.

    Ну десятка років ще точно немає (нода існує з 2011), але коли я ще починав працювати з проектом, то такої фічі не було.

    Не удивительно. Мало того, что в выбранном логгере куча абсолютно ненужного для журналирования кода, так оно еще и выполняется внутри основного процесса. В идеале в логгере не должно быть ничего лишнего и максимум, что он должен делать — это минимально форматировать переданные аргументы и выводить строку в stdout(err). Остальное должно быть вне основного процесса.

    Цілком можливо, що обране рішення не оптимальне, і, маючи достатньо досвіду, можна обрати щось краще. Проте, модуль робить те, що від нього вимагається. Та й, зрештою, треба було працювати з тим що було. Заміна логера в такому об’ємному проекті не тривіальна задача.
    У Вас є якісь конкретні рекомендації щодо альтернатив?

    Підтримав: Serhii Pavlechko
  • DOU Labs: як у Wire створили власну лабораторію з автоматизованого тестування мобільних платформ

    $299 /month/user
    $3,588 per year/billed annually
    20 Hours ($15 per hour)

    Дорогувато якось виходить. Якщо взяти для прикладу нашу лабу, то буває що за одну добу тривалість тестів більше 8 годин (це разом з нічними регресіями, що містять сотні end-to-end тестів).

  • DOU Labs: як у Wire створили власну лабораторію з автоматизованого тестування мобільних платформ

    Дана стаття з самого початку задумувалась як огляд архітектури самої лабораторії і пов’язаних з нею проблем. Тимбільше, раніше я вже описував наш CI процес в іншому огляді.

  • Continuous Localization — ефективна організація процесу локалізації

    Я постарався максимально узагальнити описання в цих обидвох статтях. Якщо описувати далі, то вже треба буде заглиблюватись в деталі реалізації того чи іншого конкретного проекту/технології: його теперішнього «рівня запущеності», рівноваги в бажаннях маркетологів і користувачів та можливостей відділу розробки і тд.
    І в такій ситуації, напевне, ефективніше буде винайняти професійного консультанта, заплатити йому, і організувати усе оптимальним для вашого випадку чином.

  • Continuous Localization — ефективна організація процесу локалізації

    Мається на увазі Centralized Resource Management system — програмне середовище для централізованого управління та обліку ресурсів, збору і аналізу статистики.
    Про які саме аспекти роботи таких систем ви хотіли би дізнатися детальніше?

  • Continuous Localization — ефективна організація процесу локалізації

    Для Apple ми використовуємо стандартні глосарії — переклади для iOS та OSX для всіх доступних мов. Як я написав вище, їх можна скачати у вигляді .dmg-пакетів з Apple Developer Downloads Area (треба бути зареєстрованим розробником). Для Microsoft Windows ці речі доступні онлайн: www.microsoft.com/...nguage/en-us/default.aspx

  • Continuous Localization — ефективна організація процесу локалізації

    У нас цим займається Jenkins. Головне, щоб формат ресурсів підтримувався TMS. Далі це просто діло техніки — скріпт парсить структуру папки з оригінальними ресурсами. У нього є whitelist, бо не все з тої папки іде на локалізацію. Ті файли, що помічені для відправлення, просто «згодовуються» curl’у (ми використовуємо Crowdin: crowdin.com/page/api. Потім TMS автоматично генерує Email-нотифікації зареєстрованим перекладачам, якщо в оригінальних ресурсах є щось нове або змінене, і вони роблять переклади через веб-інтерфейс. Первинна валідація стрічок також реалізована засобами TMS. Далі їхні переклади будуть автоматично застосовані при збірці інших гілок тим же способом, яким були передані в Crowdin.
    Перекладачі, також, підписані на бета-збірки, тому вони мають можливість першими побачити результати своєї роботи та внести необхідні правки. Крім того, ми запрошуємо їх в спільну групу Wire, де вони можуть задавати питання по контексту, дізнаватися новини про новий функціонал і тд.

    Підтримав: Анатолій Обіцький
  • Підготовка додатків до локалізації

    Тут така справа, що хто платить, той і музику замовляє. Якщо продукт початково робиться для американського ринку, то замовник часто може навіть впертиться на тому, щоб усі метрики в дюймах показувати. Я вже не кажу за час та грошові одиниці.

    Підтримав: Viktor Kryvyziuk
  • Підготовка додатків до локалізації

    Я особисто в таких оказіях, як локалізація гри, участі не брав, — думаю тут є люди, що можуть більше про це розказати. Але в загальному, судячи з прочитаного, усі тексти, які є в звукових діалогах та надписи повинні також дублюватися як стрічкові ресурси. Спочатку перекладаються ці стрічкові ресурси, причому не просто перекладаються, а з врахуванням, по-перше, особливостей конкретного ігрового світу, а по-друге, особливостей ігрової термінології в даній країні, і, частково, термінології ОС. Далі, коли переклади готові, актори озвучування (зазвичай, це native speakers), вичитують ці тексти і роблять запис. Так само і з картинками — зазвичай, вихідні зображення зберігають в векторних або піксельних форматах з розширеною метаінформацією (PSD/CDR/etc). Той же Photoshop та Corel дозволяють застовоувати досить прусунуту автоматизацію. Тобто, дуже спрощено це виглядає так, що скрипт проходиться по всіх цих файлах та заміняє оргінальні стрічки на локалізовані і потім конвертує самі файли у вихідний формат (BMP, PNG, etc). Далі іде вичитка, того, що вийшло в результаті (ігровий інтерфейс), у стрічкові ресурси вносяться необхідні правки, та ітерація повторюється до переможного кінця:).

    Підтримали: Mariia Bielan, Viktor Kryvyziuk
  • Підготовка додатків до локалізації

    Ну, ці поради точно не зі стелі взялися. То все результат досвіду (десь три четвертих з моїх більше десяти років роботи в IT) та перевареного матеріалу з прочитаних книжечок. Сподіваюсь, що ви знайдете більше цікавого матеріалу для себе в наступній статті.

  • Підготовка додатків до локалізації

    Привіт Даші передав:)

    А тепер щодо суті питання: так якраз і йдеться про те, що не потрібно чекати поки команда локалізаторів розпочне диктувати що і як робити. Я до цього повернуся в наступній статті, але як ви думаєте, локалізатори будуть щасливі, коли їм дадуть перекладати сорс-файл .java або .js із купою стрічкових констант, або .xls/.doc? А на скільки буде щасливий потім девелопер, коли йому скажуть вручну скопіювати з перекладеного документа стрічки для кожної з локалей? А потім ще десять раз їх виправити після верифікації (proofreading)? Оце дійсно займе в рази більше часу.

    Мова не йде про ракетні науки, а, всього-навсього, про оформлення ресурсів та форматування і обробку текстів. Це, практично, те ж саме, що і з безпекою, — весь користувацький ввід необхідно ескейпити перед тим, як передавати його в SQL, а сесійна кука має бути HttpOnly. Нібито, елементарні правила, які не потребують абсолютно ніяких втрат в часі, але на скільки важливі для результуючого продукту.

    IMHO, такі речі немає навіть змісту обговорювати з «насяльником», — вони вже мають бути визначені на етапі проробки архітектури, як правила хорошого тону. Сподіваюсь, ми тут говоримо про розробників, які дійсно турбуються про якість, i «херак-херак» не наш варіант ;-).

  • Підготовка додатків до локалізації

    Ви забігаєте далеко вперед — дана стаття тільки про підготовку до локалізації на початкових етапах розробки продукту, коли не те що локалізованих ресурсів, а навіть коду оригінальної версії продукта ще немає або є тільки частина.
    Я намагався узагальнити рекомендації, щоб вони підходили для різних типів додатків — як веб, так і десктоп або мобайл.
    Щодо тестування, то його, можливо, зачеплю в слідуючій статті. Поки що хочеться поговорити про розробку, бо досвід показує, що тестування часто тільки виставляє ребром проблеми, появі яких можна було запобігти набагато раніше.

  • Культура зворотного зв’язку

    Вашу думку всі побачили, дякую. Ще би дуже просив щоб Ви у профілі назву своєї контори відкрили. Така хороша можливість стрімкої кар’єри для всіх, хто горить бажання обізвати колегу мудаком при можливості, що гріх пропускати.

    Підтримав: Infatum
  • Культура зворотного зв’язку

    В кожній правді є доля правди...
    Це дуже нагадує совкові збори, де комсомольців пісочили за справи, які не личить робити справжнім комуністам. Коли людина є всього лише гвинтик системи, а не індивід зі своєю унікальною особистістю, то йому треба постійно на це вказувати. Товариш, ти ніхто, твоя власна думка нікого не цікавить, слідуй за колективом, будь як усі, нормальні люди, кінець-кінцем...

  • Культура зворотного зв’язку

    Люди є дуже різні. Якщо Ваш опонент інтроверт і не дуже схильний спілкуватись, то такого типу звернення з дуже великою імовірністю буде сприйняте «в штики», навіть якщо то було сказано з благородною метою (див. приклад нижче by @Vadim Kopanev).
    В результаті, з меншої проблеми постане ще більша. Мета статті, якраз, щоб «згладити» гострі кути та допомогти знайти той стиль, який, в меншій чи більшій мірі буде підходити для всіх типів особистостей, інтравертів чи екстравертів, не сильно зачіпаючи їхні системи цінностей.

  • Культура зворотного зв’язку

    На мою думку, з усіма і не потрібно домовлятися. Теорія каже про правило Паретто — треба домовитись тільки з 20 відсотками. Після того, як набереться «критична маса» людей, які дійсно намагаються щось змінити на краще, діло повинно піти на поправку.
    А на рахунок «кожен особистість» — в такому вигляді це просто елементарний егоїзм. Якщо людина хоче виділитись, а не здатна це зробити своїми професійними якостями, то цілком можливі і такі варіанти. IMHO, все таки, більшість це роблять несвідомо, без конкретних (поганих) намірів.

    Підтримав: Yura Nakonechnyy
  • Культура зворотного зв’язку

    Тобто, якщо слідувати Вашій логіці, то висловлення своєї думки віч на віч робить тебе «нитиком», а вміння гордо крити матами при всіх, — кльовим пацаном?

    Підтримав: Infatum
  • Культура зворотного зв’язку

    Наступна стаття буде називатись «Хокку для навернення програмістів на шлях джедая» :)

    Підтримали: Anna Kurylo, Oleksandr Zakrevskyi
  • Культура зворотного зв’язку

    Чому б і ні? Якщо мсьє влаштовує така манера спілкування і всі проблеми взаємодії при цьому ефективно вирішуються, тоді на здоров’я.
    Мене б особисто це напружувало — одна справа, коли розмовляєш з бро, з яким разом на пиво ходиш, а зовсім інша, коли з колегою, якого тільки в офісі в основному бачиш. І навіть в такому випадку ще питання чи він це каже наодинці, чи при всіх.

  • Організація процесу CI для швидкої доставки збірок. Контроль якості на його етапах

    Насправді, цей плагін уже працює для iOS — наприклад, для жира-тасків автоматом оновлюється статус на основі стану відповідного Pull Request’a в git. Але такий плагін не сильно допоможе у випадку з колонками Design Review та QA Review, де все-одно потрібна взаємодія з людиною.
    З Андроїдом ще складніше — там Pull Request не закривається, поки не пройде всі стадії перегляду в Git. І якщо вже брати якийсь базис для трігерів, то це будуть кастомні лейби зі своєю особливою логікою.
    Плюс є типи задач, для яких Pull-Request’ів немає в принципі — наприклад, по налаштуванню оточення, дослідженню, створенню прототипів і тд.

← Сtrl 12 Ctrl →