Привет! Меня зовут Катя, и я работаю тестировщиком мобильных приложений более пяти лет. Последние три года я тружусь в iOS-команде Badoo, и еженедельно мы релизим от трёх до семи новых фич, от трёх до пяти технических тасков и от пяти до 13 багфиксов. Как вы понимаете, приложение меняется с такой скоростью, что поддерживать классическую тестовую документацию (test cases) неэффективно: почти всегда она будет устаревшей.

Опытным путём мы выяснили, что чек-листы в качестве тестовой документации работают лучше, так как их проще создавать и использовать. Тем не менее иногда они могут быть запутанными и слишком подробными, особенно когда есть буквально пара часов на exploratory testing фичи, которая должна попасть в следующий релиз.

В этом случае визуализация позволяет сэкономить кучу времени, поэтому мы решили попробовать использовать mind maps (или «ментальные карты»), которые так же удобны в использовании, как чек-листы, но более наглядны за счёт визуального формата.

Сегодня мы подробненько разберём созданную мной mind map для тестирования iOS-приложения (далее именуемую «моя прелесть»), а также пройдёмся по ресурсам, которые можно использовать при построении mind map для мобильного приложения, чтобы покрыть максимальное количество важных сценариев.

Привет, меня зовут Николай Крапивный, я руковожу отделом server-side разработки в Badoo. В Badoo PHP —  один из основных языков, на нем написана бóльшая часть бизнес-логики нашей системы. Поэтому мы следим за новостями из мира PHP, активно участвуем в развитии языка и стараемся развивать сообщество вокруг PHP.

Сегодня я бы хотел поделиться переводом письма Zeev Suraski, одного из основателей Zend Technologies, которое обрисовывает дальнейшее развитие PHP и проливает свет на то, чего нам ждать в PHP 8.

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

В этой статье мы рассмотрим:

• select()
• poll()
• epoll()
• libevent

Модели машинного обучения нужно уметь не только разрабатывать, но и «продавать» заказчику. Если у него не будет понимания, почему предлагается именно такое решение, то всё закончится статьёй в журнале и выступлением на конференции. Директор компании Loginom Алексей Арустамов обращает внимание на ключевые моменты, которые важно отразить в описании модели. Это выступление прошло пару недель назад на конференции Яндекса из серии «Data & Science».

Если у вас цена ошибки маленькая, то вообще все равно, что там интерпретировать. Дали вы не ту рекомендацию — ну и бог с ней. В поиске что-то вывели — ну и ничего страшного. Но все меняется, когда речь идет о вещах, связанных с большими издержками, где цена ошибки очень большая. И тогда люди не очень любят доверять черному ящику. Это просто здравый смысл.

Классификация должностей в современных, особенно технологических компаниях сбивает с толку не только обилием сокращений и миксом терминов на двух языках, но и нюансами скрывающегося за ними содержания. Этому нигде не учат — понимание тонкостей, наполнения и специфики тех или иных должностей приходит с опытом и передаётся только с опытом. Со временем мы планируем систематизировать наши знания в этой области, но пока поговорим о насущном: в субботу в Москве состоится очередной Hiring Tournament. На турнир — точнее, сафари, — в котором сразу четыре софтверных компании DevFactory, Aurea, Ignite и Crossover вышли на охоту за головами редкого зверя Software Engineering Manager, пытаясь выманить его на годовой оклад в $100 000. Чем не повод поговорить о том, что это за создание и чем в корпоративных джунглях SEM отличается от должности-двойняшки — Team Lead.


Чем совершеннее в компании отлажены процессы — тем больше они напоминают конвейер вне зависимости от её профиля

Team Lead, особенно в небольших командах — это универсальный солдат, который и таски по команде раскидает, и сам за станок может встать, чтобы показать, как надо работать или закрыть собой дыру в ресурсах. В общем, тимлид он во всём тимлид — батя команды разработки.

Однако если в вашей компании имеются Software Engineering Manager, «семы» — то они тоже будут руководить командами разработчиков или инженеров, контролируя и обеспечивая работоспособность команды, и поддерживая рабочий контакт с «соседними» отделами разработки. Так в чём же разница с тимлидами? Мы попросили VP of Technical Product Management компании Aurea Software Максима Винникова помочь внести нам ясности в деталях.

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

Рассказывать айтишникам про психологию то еще дело, некоторые читатели скажут: «Bullshit!», и вообще не поверят, потому что психологию, даже прикладную, нельзя назвать точной наукой. Тем не менее, задача этой статьи — показать и доказать вам, что некоторые модели действительно работают. В основе доклад Сергея Котырева из UMI на РИТ++ 2017, от его лица дальше и пойдет повествование.



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

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

Мне кажется, о поведении и предсказании поведения спиральных галактик мы знаем больше, чем о том, как поведет себя человек, например, моя жена, сотрудник, или особенно сотрудница моего отдела маркетинга, не говоря уже о пиарщицах. О том, что ближайшая к нам Галактика летит, и через сколько-то миллиардов лет столкнется с нашей, мы уже знаем точно.

Услышал в московском метро предупреждение, что полеты дронов над Москвой запрещены. Разъяснение на Официальном сайте Мэра Москвы mos.ru ссылается на Приказ Министерства транспорта от 09 марта 2016 года №48, в котором в таблице даны координаты запрещенных для полетов областей. Штраф за нарушение запрета для физических лиц составляет от 3000 до 5000 рублей.

Поскольку пользоваться таблицей скорее всего неудобно, я решил ее визуализировать на Яндекс-картах.

Рекомендую заранее перед полетом убедиться, что при несчастливом стечении обстоятельств вы не нарветесь на штраф. Да и просто интересно посмотреть, где у нас что :)

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

Всем привет! Меня зовут Алексей, я тимлид команды Vimbox (платформа для обучения в Skyeng). Не так давно я выступал на конференции с докладом об удаленной работе и особенностях распределенной команды. Неожиданно темой заинтересовалось много людей, хотя я думал, что хайп уже прошел и никого не удивить. Поэтому я решил поделиться и с вами наработками, полученными за четыре года функционирования в этом формате. Поскольку у нас в компании из 55 разработчиков 51 человек постоянно работает вне офиса, да и сам я живу в Калининграде, думаю, наш опыт многим может пригодиться.

Движущая сила микросервисов

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

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

Однако, когда дело доходит до тестирования (или, чего похуже, разработки) микросервисов, выясняется, что большинство компаний по-прежнему испытывает привязанность к допотопному способу тестирования всех компонентов вместе. Создание сложной инфраструктуры считается обязательным условием для проведения сквозного (end-to-end) тестирования, при котором набор тестов для каждого сервиса обязательно должен быть выполнен — делается это для того, чтобы убедиться, что в сервисах не появилось регрессий или несовместимых изменений.

Привет, дорогой читатель!
В этот раз я хочу поделиться своим результатом настройки персонального окружения для работы с различными PHP-based проектами с использованием Puppet. В данной статье описываются результаты, которые были получены в процессе изучения и написания Puppet конфигурации.

Данная статья написана с целью показать один из способов это сделать. Я не хочу призывать к действию, а только делюсь тем, с чем я столкнулся, что сделал и как использую.

Статья будет очень длинной с уклоном в техническую сторону. Прошу под «кат».

Этот список появился как личная памятка по темам, которые я обсуждал с коллегами и друзьями и в которых хотел разобраться поглубже…

Я не большой любитель задавать технические вопросы на собеседованиях: по мне так лучше посидеть с кандидатом (или кандидаткой) за клавиатурой над каким-то реальным кодом, реальной проблемой — и целый день заниматься парным программированием, желательно поочерёдно с остальными членами команды. Но я считаю, что некоторые технические вопросы могут быть хорошей отправной точкой для начала увлекательного и приятного разговора и позволят глубже узнать друг друга.

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

Всем бобра!

Наш курс «Разработчик С++» потихоньку растёт и ширится: присоединился новый преподаватель с очень богатым опытом — Юрий Авраменко. И он уже провёл у нас первый открытый урок по диаграммам UML, на котором разбирались: виды диаграмм, инструменты построения схем и диаграмм, варианты представлений и прочее.


Ждём вопросы тут или на Дне открытых дверей.

О книге «Программист-прагматик. Путь от подмастерья к мастеру» Эндрю Ханта и Дэвида Томаса знают, наверное, все, кто занимается программированием, причем многие — в основном из упоминаний в подборках и цитат в более современных статьях. Учитывая, что этот сборник практических советов для разработчиков скоро отметит двадцатилетний юбилей, тот факт, что его до сих пор приводят как источник ценной информации, вызывает уважение. Секрет прост: авторы, хоть и делали акцент на практической применимости своих подсказок, говорили по большей части о фундаментальных принципах построения рабочего процесса. Многие технические моменты, которые упоминаются в тексте, действительно давно устарели, но базовые подходы к разработке, тестированию, взаимодействию внутри команды и с аудиторией остаются актуальными.


Ниже вы найдете конспект первых четырех глав; речь в них идет об авторской концепции самообразования, основах прагматического подхода в программировании и правилах подбора инструментов. Книга очень удобна для «точечного» чтения: материал представляется в виде отдельных параграфов-подсказок, снабженных перекрестными ссылками. За рамками этого конспекта остались примеры из конкретных языков, разбор кейсов из авторской практики, те самые ссылки, упражнения на закрепление и некоторые забавные аналогии, оживляющие текст — так что рекомендую ознакомиться с оригиналом, если какие-то из тезисов вас заинтересуют. Приятного чтения!

В первой части были рассмотрены: структура, топология, функции активации и обучающее множество. В этой части попробую объяснить как происходит обучение сверточной нейронной сети.

Обучение сверточной нейронной сети

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

В прошлой части

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

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

Мы начинаем публиковать курсы лекций Технополиса — образовательного проекта команды Одноклассников в Санкт-Петербургском Политехническом университете Петра Великого. Создание высоконагруженных приложений — это не только проектирование и написание кода, но и огромное количество других аспектов на всём протяжении жизненного цикла продукта. Мы пройдём по всему процессу создания и использования высоконагруженной системы. Особое внимание будет уделено особенностям эксплуатации, сетям, балансировке нагрузки, иерархии памяти, повседневным инструментам. Также поговорим о мониторинге, аудите и многом другом. Лекции курса читает команда экспертов под руководством ведущего разработчика в Одноклассниках Вадима Цесько.

Список лекций:

1. Введение (Вадим Цесько incubos)
2. Типовые архитектуры (Александр Христофоров)
3. Эксплуатация (Илья Щаников)
4. Сетевой стек (Дмитрий Самсонов dmitrysamsonov)
5. Балансировка (Андрей Домась)
6. Процессоры и память (Алексей Горбов)
7. Хранилища данных (Сергей Егоричев)
8. JVM (Андрей Паньгин apangin)
9. Мониторинг (Сергей Шарапов Sharapoff)
10. Облака (Леонид Талалаев)

В конце декабря на площадке Райффайзенбанка состоялся Рождественский Agile MeetUp. В предновогоднем настроении участники поговорили о том, сколько нужно программистов, чтобы оценить фичу, развеяли мифы об Agile и трансформации, и, конечно, затронули больную тему дедлайнов. О том, как это было, читайте под катом.

Генеральные цели перехода на #Ускорение4X мы обсудили. Теперь нужно сделать еще более важную штуку — учесть цели каждого участника команды. Мы же ускоряемся сами для себя, а не для начальника.

Кстати, спасибо, что заминусовали публикацию про генеральные цели. Минусы освобождают от необходимости пытаться вам понравиться, т.е. от зла. Остается чистое намерение дать информацию. Чем и займусь.

Итак, зачем кастомизировать цели? Вроде нормально они звучат — ускориться, научиться работать на форсаже, научиться переводить на форсаж.

Неприятность в том, что цели звучат слишком нормально. Банально звучат, пошло и неискренне. И в них не слышно ничего вашего. Вам как будто опять ставят чужую цель, и говорят, что вы должны хотеть ее достичь.

Такое сплошь и рядом есть во всех компаниях, от всех собственников и менеджеров. Что они там обычно говорят? Давайте увеличим продажи вдвое! Наша цель — войти в список Forbes! Мы хотим через 5 лет выйти на IPO! Наша цель — 5 новых продуктов через год! Ну и т.д. Еще там непонятные миссии добавляются,ценности сейчас модно стало писать, и подобную ересь.

Что с ними не так, вы уже понимаете — там нет вас. Ни про вас, ни для вас, ни про ваше будущее. Вы как были винтиком, шпунтиком или целой шестеренкой, а может быть редуктором/мультипликатором, так и останетесь, пока не выкинут, или сами не уйдете. Никому нет до вас никакого дела. Все корпоративные культуры — искусственная хрень, все похлопывания шефа по плечу — прием из книги по менеджменту (вроде этой), чтобы вы себя лучше почувствовали, квартальная или годовая премия — кусочек колбасы для собаки, чтобы с еще большей радостью делала апорт. Всем на вас насрать. И вам на свои цели давно насрать, потому что вы привыкли к чужим идти. Доходить, постоять, как пел Высоцкий, хмельным на вершине, и ползти на следующую гору, нужную кому-то, кроме вас. Ладно, вы и так это все знаете.