Предыстория

Любой сервис для конечных пользователей должен быть гибким, отражающим их текущие потребности. Бизнес развивается, качество сервиса тоже должно расти. Если этого не происходит, рано или поздно уровень услуг, заданных на старте проекта, перестает устраивать потребителей. Поэтому хочу поделиться с вами своим опытом внедрения новых методов работы в нашей команде Сервис Деск (SD).

В конце 2012 года мы запустили в работу услугу SD для одного из наших клиентов в режиме 24/7/365. Полноценной службы SD у заказчика до этого не было, вся поддержка оказывалась силами внутренних подразделений. Под этот проект была подобрана и обучена новая команда, состоящая из 7 сотрудников, включая меня. Сервис стартовал активно — передача знаний, знакомство со спецификой работы. У команды было много идей и энтузиазма. Сервис заработал как часы.

Хей, а кто у нас тут самый умный? Вы — начальник и не самый умный в комнате? Вы — очень большой босс и не самый умный в здании? Так это легко исправить! Сейчас поделюсь бесценным опытом.

1. Врите

Сейчас вы прочитаете увлекательную историю моего превращения из разработчика в тимлида. Это было долгое путешествие со множеством шагов назад, которое всё же закончилось уверенным шагом вперёд. Устраивайтесь поудобнее, берите попкорн… Поехали!

"Конечно отдельная!", — ответит большая часть читающих. Такой ответ укладывается в их картину мира, потому что “так работали всегда”. 

Так работали всегда

Эта фраза обычно означает наличие продукта, уже работающего на продакшене или только готовящегося зарелизиться, но написанного без модульных и интеграционных тестов. Без страховочной сети из тестов, изменения вносятся долго, дорого и с большим количеством новых багов. Такой проект в мире разработки принято называть “легаси”. 

Компания понимает, что обойтись без страховочной сети нельзя, поэтому создается QA-отдел, который обычно не обеспечивает качество продукта, а лишь контролирует его. С QA-отделом разработчик может спокойно заниматься любимым делом — писать код, ведь ответственность за качество теперь несет выделенный отдел! Происходит классическое “перебрасывание кода через стену” в отдел тестирования:

На прошлой неделе мы запустили эксперимент – бесплатную дизайнерскую помощь. Все желающие помечали хэштегом #logomachine_help дизайн, который нуждается в совете или доработке, а мы выбирали, кому мы можем помочь и играли шрифтами, подбирали цвет, улучшали компоновку. Сразу скажу — это не полноценный дизайн, а скорее визуальные советы, поэтому они делаются на ходу в фотошопе и допускают неточности и упрощения. Но эти примеры помогут каждому понять проблемы в своем дизайне и улучшить его в пару кликов.

Так уж сложилось, что последние несколько лет я занимал самые разнообразные руководящие должности в полудюжине компаний, занимающихся разработкой программного обеспечения разного рода. Довелось побывать и тимлидом, и менеджером проекта, и группы проектов, руководителем отдела и руководителем технического направления; подопечных бывало от двух до ста пятидесяти человек, да и размеры компании варьировались от трёх до двухсот тысяч работников. Неизменным оставалось только одно: чисто управленческая работа, постепенный и окончательный отход от технических задач.

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.

Пятую статью курса мы посвятим простым методам композиции: бэггингу и случайному лесу. Вы узнаете, как можно получить распределение среднего по генеральной совокупности, если у нас есть информация только о небольшой ее части; посмотрим, как с помощью композиции алгоритмов уменьшить дисперсию и таким образом улучшить точность модели; разберём, что такое случайный лес, какие его параметры нужно «подкручивать» и как найти самый важный признак. Сконцентрируемся на практике, добавив «щепотку» математики.

UPD 01.2022: С февраля 2022 г. ML-курс ODS на русском возрождается под руководством Петра Ермакова couatl. Для русскоязычной аудитории это предпочтительный вариант (c этими статьями на Хабре – в подкрепление), англоговорящим рекомендуется mlcourse.ai в режиме самостоятельного прохождения.

Видеозапись лекции по мотивам этой статьи в рамках второго запуска открытого курса (сентябрь-ноябрь 2017).

Я люблю две вещи: Intellij IDEA и чистый код (Clean Code).
IDEA создана для чистого кода. Многие настройки по умолчанию уже стимулируют вас писать как надо.


Но она всё ещё не идеальна.
Когда я устанавливаю новую копию IDEA, я пробегаю по настройкам и выставляю свои любимые галочки.
Хочу ими с вами поделиться в надежде, что когда-нибудь и они станут стандартом.

Что не так с тестированием вёрстки

Мы часто им пренебрегаем. Написание функциональных, интеграционных и юнит-тестов давно стало повсеместной практикой. Вёрстке мы обычно уделяем гораздо меньше времени.

Проблема тестирования вёрстки в том, что только живой человек может сказать, хорошо свёрстан блок на странице или нет. Поэтому чаще всего мы тестируем HTML и CSS вручную: проверяем, как будет вести себя блок, если в нем будет слишком много (или слишком мало) текста или дочерних элементов; смотрим, чтобы все возможные варианты отображения блока смотрелись корректно; помним о том, как блоки должны адаптироваться к разным устройствам и разрешениям экрана.

Статья публикуется от имени Батеевой Екатерины, Neifmetus



Мир не стоит на месте: еще десять лет назад пользователи выходили в интернет с помощью компьютера, а сегодня по статистике большая часть посещений приходится на мобильную версию сайта или мобильные приложения. Поэтому требования к стабильности и удобству использования этих приложений становятся выше.

В нашем банке мы тоже наблюдаем эту тенденцию: мобильное приложение по сравнению с интернет-банком используют на порядок больше пользователей. Поэтому остро встал вопрос автоматизации тестирования мобильного приложения. Несмотря на повсеместное использование мобильных приложений, средства для их автоматизированного тестирования далеко не идеальны. Кроме того, мы предъявляем к ним высокие требования. Например, самый популярный фреймворк Appium — open-source решение, поддерживающее платформы Android и iOS, — нам не подошел. Наши разработчики использовали много модных библиотек, и взаимодествовать с приложением иногда приходилось на более низком уровне. UI Automator и UI Automation оказались более сложными в развертывании, каждое приложение использовало свой язык для написания тестов, из-за чего возникали проблемы при перераспределении между платформами в команде автотестирования.

Сегодня предлагаю поразмышлять о том, как искать паттерны в биржевых данных и как их использовать для успешной торговли.

Будем получать биржевые данные Forex от одного из брокеров, сохраним в базу данных PostgreSQL и попробуем найти закономерности при помощи алгоритмов машинного обучения.

В статье есть несколько приятных бонусов в виде кода на Python — Вы сможете сами проанализировать любые (почти) биржевые данные (или значения индикаторов), запустить собственного торгового робота и проверить любую торговую стратегию.

Все условия и определения паттернов в статье приведены для примера, вы можете использовать любые критерии.

Статья публикуется от имени Перфильева Алексея, akaaxel

Gatling – это framework для проведения нагрузочного тестирования. Он основан на трех технологиях: Scala, Akka и Netty.
В этой статье мы:

1. Посмотрим, как установить и начать использовать Gatling.
2. Разберем синтаксис скриптов Gatling на языке Scala.
3. Напишем небольшой тест, где используем основные функции Gatling. Запустим тестовый скрипт при помощи sbt и сохраним отчет.