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

Сергей Семёнов считает, что это происходит в основном по двум причинам.

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

И предлагает подход к оценке и контролю процессов на основе объективных данных.

Ниже видео и текстовая версия доклада Сергея, который по результатам зрительского голосования занял второе место на Saint TeamLead Conf.

UPD: По итогам мероприятия мы сделали 8 предложений о работе: 5 – iOS-разработчикам, 3 – Android-разработчикам.

Привет, Хабр! Я Богдан, разработчик в iOS-команде Badoo в Лондоне. Прочитав заголовок, вы можете подумать, что в Badoo совсем с ума сошли публиковать посты на такие темы. Но пост вполне для Хабра. Мы сейчас очень активно расширяем iOS- и Android-команды и ищем разработчиков по всему миру. Естественно, Москву обойти стороной просто не можем (наш второй офис здесь). Мы хотим провести достаточно необычное мероприятие, чтобы после него обзавестись новыми коллегами.

Мы (мобильные команды Badoo) решили приехать на несколько дней в Москву и провести небольшую встречу, после которой несколько разработчиков (iOS и Android) получат предложения о работе у нас (в Лондоне). Чтобы не затягивать эту самую встречу, мы сделали онлайн-тест (он не суперсложный, а скорее чтобы понять ваш уровень и упростить и ускорить личные встречи).

— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.

Детектив по материалам IT. Часть первая

Я осознаю, что писать очередную статью на тему Модель-Вид-Контроллер это глупо и вредно для «кармы». Однако с этим «паттерном» у меня слишком личные отношения – проваленный проект, полгода жизни и тяжелой работы «в корзину».

Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…

И тогда все встало на свои места. Оказалось что фактически на основе принципов мы пере-изобретали «original MVC». А то, что зачастую преподносится как MVC, не имеет к нему никакого отношения… впрочем также как и к хорошей архитектуре. И судя по тому сколько людей пишет о несостоятельности «классического MVC», спорит о нем и изобретает его всевозможные модификации, не одни мы столкнулись с этой проблемой.

Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.

Если верить последним тенденциям, то FRP набирает обороты и не собирается останавливаться. Не так давно я столкнулся с проектом, посвященным FRP — ReactiveX, и его реализацией для Swift — RxSwift. На Хабре уже была небольшая статья, которая будет полезна для начального понимания RxSwift. Я хотел бы развить эту тему, поэтому заинтересовавшимся — добро пожаловать под кат!

Лиха беда начало

И это действительно так. Самое сложное, с чем мне пришлось столкнуться — совершенно другое построение программного кода. С моим опытом императивного программирования было тяжело перестраиваться на новый лад. Но чутьё подсказывало мне, что в этом стоит разобраться; у меня ушло 2 недели паники на то, чтобы вникнуть в суть ReactiveX и я не жалею о потраченном времени. Поэтому сразу хотел бы предупредить — статья требует понимания терминов ReactiveX, таких как Observable, Subscriber и т.д.

Итак, начнем.

Заинтересовавшись темой функционального программирования я встал на распутье, — какой фреймворк выбрать для ознакомления. ReactiveCocoa — ветеран в iOS кругах, по нему вдоволь информации. Но он вырос с Objective-C, и хотя это не является проблемой, но все же в данный момент я в основном пишу именно на Swift, — хотелось бы взять решение изначально спроектированное с учетом всех плюшек языка. RxSwift же порт Reactive Extensions, имеющего долгую историю, но сам порт свежий и написанный именно под Swift. На нем я и решил остановиться.
Но специфика документации по RxSwift в том, что описание всех команд ведет на reactivex.io, а там в основном дается общая информация, руки у разработчиков не дошли еще сделать документацию именно для RxSwift, что не всегда удобно. Некоторые команды имеют тонкости в реализации, есть те, о которых в общей документации нет ничего кроме упоминания.
Прочитав все главы вики с RxSwift гитхаба, я сразу решил поразбираться с официальными примерами, тут то и стало ясно, что с RX такое не пройдет, нужно хорошо понимать основы, иначе будешь как мартышка с копипастом гранатой. Я начал разбирать самые сложные для понимания команды, потом те, что вроде понятны, но задав себе вопросы по ним я понял, что лишь догадываюсь на то как верно ответить, но не уверен.
В общем ничтоже сумняшеся я решил проработать все операторы RxSwift. Лучший способ что то понять в программировании — запустить код и посмотреть как он отработает. Затем учитывая специфику реактивного программирования — очень полезны схемы, ну и краткое описание на русском. Закончив сегодня работу, я подумал, что грех не поделиться результатами с тем, кто лишь присматривается к теме реактивного программирования.
Много картинок и текста под катом, очень много!

Введение в MVP, MVC, MVVM и VIPER. Что между ними общего и в чем разница.

Делаете все по MVC, а получается некрасиво? Сомневаетесь, переходить ли на MVVM? Слышали о VIPER, но не уверены, стоит ли оно того?

В этой статье я кратко рассмотрю некоторые популярные архитектурные паттерны в среде iOS и сравню их в теории и на практике. Больше информации вы найдете при переходе по ссылкам, указанным в тексте.

Что должен знать objc разработчик на уровень middle/senior?
К сожалению, четкой черты на вертикальное развитие нет. Парадокс, но чтобы знать что изучить, нужно знать что ты не знаешь.
Я постарался вспомнить самые интересные вопросы, которые мне задавали самому на различных собеседованиях, а так же расширил их множеством вопросов(тем же уровнем) от себя.
Здесь нет общих вопросов вроде: IoC, design patterns, S.O.L.I.D. и т.п.

ВНИМАНИЕ!!!
Помимо вертикального развития немаловажно и горизонтальное

ВНИМАНИЕ!!! (2)
Не пишите в комментарии ответы на вопросы, это дает возможность людям самостоятельно разобраться.
Однако, если у вас имеются интересные вопросы по теме, я с радостью добавлю их в список.

Конечно, это не заменит живого общения, однако позволит неплохо подготовиться к собеседованиям.

Начинаем

Все мы ходили/ходим на собеседования. Каждый раз при подготовке к очередному собеседованию просматриваем основные темы, вспоминаем вопросы, которые нам задавали в предыдущие разы, или вопросы, которые сами задавали. Ниже хочу представить основные вопросы, которые часто (основано на личном опыте) можно получить на собеседовании на должность middle/senior iOS Developer. Так сказать, шпаргалка. Заодно можно проверить свой уровень знания платформы.

Признак того, что объект не должен быть классом — если в нём всего 2 метода, и один из них — инициализация, __init__. Каждый раз видя это, подумайте: «наверное, мне нужна просто одна функция».

Каждый раз когда из написанного класса вы создаёте всего один экземпляр, используете только раз и тут же выбрасываете, следует думать: «ой, надо бы это отрефакторить! Можно сделать проще, намного проще!»

Перевод доклада Джэка Дидриха, одного из ключевых разработчиков языка Питон. Доклад прозвучал 9 марта 2012 на конференции PyCon US.

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

Картинка для привлечения внимания — скриншот игры.

Hola chicos!

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

Обрел же я его, проработав 5 лет в московском филиале компании Glu Mobile (4.5 лет из них — дизайнером) и 7 месяцев в компании Social Point, где и продолжаю работать на данный момент. Также я общался со многими людьми, которые работали в таких компаниях, как Game Insight, Crazy Panda, Game Garden и другие.

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

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

Ни для кого не секрет, что современные социальные сети представляют собой огромные БД, содержащие много интересной информации о частной жизни своих пользователей. Через веб-морду особо много данных не вытянешь, но ведь у каждой сети есть свой API… Так давай же посмотрим, как этим можно воспользоваться для поиска пользователей и сбора информации о них.

Есть в американской разведке такая дисциплина, как OSINT (Open source intelligence), которая отвечает за поиск, сбор и выбор информации из общедоступных источников. К одному из крупнейших поставщиков общедоступной информации можно отнести социальные сети. Ведь практически у каждого из нас есть учетка (а у кого-то и не одна) в одной или нескольких соцсетях. Тут мы делимся своими новостями, личными фотографиями, вкусами (например, лайкая что-то или вступая в какую-либо группу), кругом своих знакомств. Причем делаем это по своей доброй воле и практически совершенно не задумываемся о возможных последствиях. На страницах журнала уже не раз рассматривали, как можно с помощью различных уловок вытаскивать из соцсетей интересные данные. Обычно для этого нужно было вручную совершить какие-то манипуляции. Но для успешной разведки логичнее воспользоваться специальными утилитами. Существует несколько open source утилит, позволяющих вытаскивать информацию о пользователях из соцсетей.

Всем привет. Сегодня я продолжу рассказывать вам о внутреннем устройстве Objective-C Runtime, а конкретно — о его реализации на уровне языка C.

В прошлых статьях мы с вами подробно разобрались с селекторами и механизмом посылки сообщений объектам и классам. Сегодня я хотел бы закончить с сообщениями и рассказать о принципах работы некоторых встроенных возможностей языка Objective C.

Тем, с кем мы ещё не знакомы, я предлагаю для начала прочитать первую и вторую части, а прочитавших и заинтересовавшихся прошу под кат.

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

Я уже делился советами по разработке кастомной клавиатуры, а также опытом продвижения приложения до и сразу после релиза — статья. На этот раз хочу рассказать о процессе разработки и дать пару подсказок о том, что делать после загрузки приложения в App Store.

Автор оригинальной статьи Ali Mese добавил ещё 100 новых бесплатных сервисов. Все 400 потрясающих сервисов доступны здесь. И еще подборку +500 инструментов от 10 марта 2017 г. смотрите здесь.

A. Бесплатные Веб-Сайты + Логотипы + Хостинг + Выставление Счета

• HTML5 UP: Адаптивные шаблоны HTML5 и CSS3.
• Bootswatch: Бесплатные темы для Bootstrap.
• Templated: Коллекция 845 бесплатных шаблонов CSS и HTML5.
• Wordpress.org | Wordpress.com: Бесплатное создание веб-сайта.
• Strikingly.com Domain: Конструктор веб-сайтов.
• Logaster: Онлайн генератор логотипов и элементов фирменного стиля (new).
• Withoomph: Мгновенное создание логотипов (англ.).
• Hipster Logo Generator: Генератор хипстерских логотипов.
• Squarespace Free Logo: Можно скачать бесплатную версию в маленьком разрешении.
• Invoice to me: Бесплатный генератор счета.
• Free Invoice Generator: Альтернативный бесплатный генератор счета.
• Slimvoice: Невероятно простой счет.

Резюме

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

Персональные рекомендации позволяют познакомить пользователя с объектами, о которых он, возможно, никогда не знал (и не узнал бы), но которые могут ему понравиться с учетом его интересов, предпочтений и поведенческих свойств. Однако, часто пользователь ищет не новый объект, а, к примеру, объект A похожий на объект B («Форсаж 2» похож на «Форсаж»), или объект A, который приобретается/потребляется с объектом B (сыр с вином, пиво с детским питанием, гречка с тушенкой и т.д.). Построить такие рекомендации позволяют неперсонализированные рекомендательные системы (НРС).


Рекомендовать похожие/сопутствующие объекты можно, ориентируясь на знания об объектах (свойства, теги, параметры) или на знания о действиях, связанных с объектами (покупки, просмотры, клики). Преимуществом первого способа является то, что он позволяет достаточно точно определить похожие по свойствам объекты («Форсаж 2» и «Форсаж» — похожие актеры, похожий жанр, похожие теги, ...). Однако данный способ не сможет порекомендовать сопутствующие объекты: сыр и вино. Еще одним недостатком этого способа является тот факт, что для разметки всех объектов, доступных на сервисе, требуется не мало усилий.

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

Под катом описан метод ассоциаций, позволяющий построить неперсонализированные рекомендации, основываясь лишь на данных о действиях над объектами. Там же код на Python, позволяющий применить метод для большого объема данных.

Среди задач мобильного разработчика, помимо самой частой (написания, собственно, приложений) периодически появляется и такая, как создание sdk.

Примерами такой задачи может быть создание sdk, использующего REST API какого-либо сервиса (реклама, аналитика, погода), библиотека реализаций алгоритмов, обработка изображений… Список практически неограничен.

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

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

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

Все разработчики для iOS мечтают попасть в Топ-10 App Store. Профессиональная локализация — путь к успеху. Проблемы, которые могут повстречаться на пути, самые разнообразные — забытая на старте проекта локализуемость, плохой переводчик, “кривое" тестирование локализации.

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

Переведено в Alconost.