У нас было две гугл-формы, 75 вопросов в каждой, 5 бизнес-пользователей, которые активно правили эти формы, а еще гугл-скрипт, экспортирующий форму в JSON. Не то что бы его было сложно каждый раз запускать руками, но раз начал автоматизировать свою работу, то иди в этом увлечении до конца.
В официальной документации сам черт ногу сломит, поэтому под катом мы подробно рассмотрим удаленную загрузку и запуск Google Apps Script через REST API, используя Python.
Читать полностью »
Всем привет, на связи Александр Панов, техлид из Pixonic. В компании я отвечаю за межпроектные решения и околопроектную периферию и сегодня хочу поделиться своим опытом и наработками.
Платформы непрерывной разработки и интеграции, или CI/CD, сейчас используются повсеместно в тех отраслях, где решающую роль играет итеративность и отлаженность технических процессов. В этой статье речь пойдёт о CI/CD для реализации наших Unity-проектов для мобильной геймдев-разработки: с какими проблемами мы столкнулись, как их удалось решить, каких улучшений мы добились и как прописан наш пайплайн сборок билдов.
Сразу договоримся, что в качестве сервера CI мы используем TeamCity от JetBrains, в качестве хранилища Git-репозиториев ― GitHub, для хранения артефактов сборки ― Nexus.
Читать полностью »
В данной статье я коснусь вопроса порога входа в проект с устоявшейся архитектурой и дам несколько вариантов ответа на очень часто возникающий вопрос: почему так сложно?
Такой вопрос частенько возникает у новичков, которые приходят на проект. Или же бывают ситуации, когда проект уходит на поддержку и развитие в новые руки, и у нового разработчика также появляется этот вопрос. И редко кто из них пытается разобраться в реальных причинах, почему здесь так, а не иначе. Это может привести к печальным последствиям для бизнеса, например, новый разработчик может настоять на том, чтобы переписать все приложение с нуля.Читать полностью »
Если ваши релизы быстры как молния, автоматизированы и надежны, можете не читать эту статью.
Раньше наш процесс релиза был ручным, медленным и напичканным ошибками.
Мы проваливали спринт за спринтом, потому что не успевали сделать и выложить фичи к следующему Sprint Review. Мы ненавидели наши релизы. Часто они длились по три-четыре дня.
В этой статье мы опишем практику Stop the Line, которая помогла нам сфокусироваться на устранении проблем конвейера выкладки. Всего за три месяца нам удалось увеличить скорость деплоя в 10 раз. Сегодня наш деплой полностью автоматизирован, а релиз монолита занимает всего 4-5 часов.
Читать полностью »
В реальном внедрении ML само обучение занимает от силы четверть усилий. Остальные три четверти — подготовка данных через боль и бюрократию, сложный деплой часто в закрытом контуре без доступа в интернет, настройка инфраструктуры, тестирование и мониторинг. Документы на сотни листов, ручной режим, конфликты версий моделей, open source и суровый enterprise — все это ждет data scientist’а. Но такие «скучные» вопросы эксплуатации ему не интересны, он хочет разработать алгоритм, добиться высокого качества, отдать и больше не вспоминать.
Возможно, где-то ML внедряется легче, проще, быстрее и одной кнопкой, но мы таких примеров не видели. Все, что выше — опыт компании Front Tier в финтехе и телекоме. О нем на HighLoad++ рассказал Сергей Виноградов — эксперт в архитектуре высоконагруженных систем, в больших хранилищах и тяжелом анализе данных.
Когда я думаю о том, как работают наивные RPC клиенты, мне вспоминается анекдот:
Суд.
— Подсудимый, за что вы убили женщину?
— Еду я в автобусе, подходит кондуктор к женщине, с требованием купить билет. Женщина открыла сумочку, достала кошелочку, закрыла сумочку, открыла кошелочку, достала кошелек, закрыла кошелочку, открыла сумочку, положила туда кошелочку, закрыла сумочку, открыла кошелек, достала деньги, открыла сумочку, достала кошелочку, закрыла сумочку, открыла кошелочку, положила туда кошелек, закрыла кошелочку, открыла сумочку, положила туда кошелочку.
— И что?
— Контролер ей дал билет. Женщина открыла сумочку, достала кошелочку, закрыла сумочку, открыла кошелочку, достала кошелек, закрыла кошелочку, открыла сумочку, положила туда кошелочку, закрыла сумочку, открыла кошелек положила туда билет, закрыла кошелек, открыла сумочку, достала кошелочку, закрыла сумочку, открыла кошелочку, положила туда кошелек, закрыла кошелочку, открыла сумочку, положила туда кошелочку, закрыла сумочку.
«Возьмите сдачу», раздался голос контролера. Женщина… открыла сумочку…
— Да убить её мало, — не выдерживает прокурор.
— Так я это и сделал.
Cake — замечательный инструмент для создания конвеера доставки для ваших приложений. Я люблю его, поскольку он позволяет мне писать этот конвеер на языке C#, который я знаю хорошо. Прекрасным свойством Cake, PSake и дургих подобных фреймворков является то, что они создают скрипт, который можно выполнять как на локальной машине разработчика, так и на CI серверах. Здесь я объясню, как организовать взаимодействие скрипта Cake с TeamCity.
Сегодня мы наблюдаем, как во всем мире постепенно отмирает waterfall-модель разработки. Ее не любят за тяжеловесность и плохую реакцию на изменения. Это напрямую влияет на актуальность продукта и увеличивает ТТМ (time-to-market), выливаясь в дополнительные затраты. Разработчики перестраиваются на рельсы agile, и мы здесь не исключение.
Методология agile изначально создавалась для маленьких команд, которые делают продукт под ключ в режиме end-to-end и сами отвечают за его качество. Но как быть, если разрабатываешь высококритичные банковские системы, над которыми трудятся десятки agile-команд? Как достичь той уверенности в продукте, которую дает долгое, исчерпывающее тестирование как в waterfall? В этом посте мы поделимся своим решением этого вопроса.
Laravel — это поистине большая и сложная система, которая старается решить большинство бытовых задач веб разработчика максимально элегантным способом и собрать в себе как можно больше инструментов и, что очень важно — с как можно более человеческим интерфейсом.
И сегодня речь пойдет об одном из таких инструментов, а точнее о его использовании и реализации со стороны программиста. Отсутствие полноценной документации, а также отсутствие русскоязычных статей и очень малое количество статей иностранных — подтолкнуло меня к решению раскрыть некую завесу тайны об этой интересной возможности фреймворка и выбору этой темы в качестве моей первой статьи на Хабре.
Читать полностью »
Дисклеймер: Я не рассматриваю какие-либо алгоритмы и API для работы со звуком и распознаванием речи. Эта статья о проблемах при работе с аудио и об их решении с помощью Go.
phono — прикладной фреймворк для работы со звуком. Его основная функция — создать конвейер из разных технологий, который обработает звук за вас нужным вам образом.
При чём тут конвейер, к тому же из разных технологий и зачем ещё один фреймворк? Сейчас разберёмся.
