Привет, друзья.

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

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

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

С тех пор, как люди подняли глаза к небу, к планетам, звёздам и галактикам за пределами нашего родного мира, наше воображение наполнялось возможностями жизни на других планетах. Подходя к вопросу с научной точки зрения, мы всё ещё ждём первой подтверждённой информации о наличии жизни за пределами Земли. Сложные и различные формы жизни на Земле являются результатом более четырёх миллиардов лет эволюции, но в космосе ингредиенты жизни встречаются повсюду. Мы начали обнаруживать органические молекулы в других местах Солнечной системы, в межзвёздном пространстве и даже вокруг других звёзд. Как долго нам ещё ждать до обнаружения первых признаков жизни за пределами нашего мира? Есть несколько способов, которые мы используем для поисков жизни, и какой из них увенчается успехом, остаётся только гадать.

«У каждого свой VIPER». Автор неизвестен

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

Со временем языки программирования постоянно изменяются и развиваются из-за появления новых технологий, современных требований или простого желания освежить стиль написания кода. Реактивное программирование можно реализовать с помощью различных фреймворков, таких как Reactive Cocoa. Он изменяет рамки императивного стиля языка Objective-C и у такого подхода к программированию есть что предложить стандартной парадигме. Это, безусловно, и привлекает внимание iOS разработчиков.

ReactiveCocoa привносит декларативный стиль в Objective-C. Что мы подразумеваем под этим? Традиционный императивный стиль, который используют такие языки как: C, С++, Objective-C, и Java и т. д. можно описать так: Вы пишете директивы для компьютерной программы, которые должны быть выполнены определенным способом. Другими словами, вы говорите «как сделать» что-то. В то время как декларативное программирование позволяет описать поток управления как последовательность действий, «что сделать», не определяя, «как делать».

Есть мнение, что Swift — особенно благодаря развитию в опенсорсе — уже сейчас применим за рамками софта для платформ Apple. Наши коллеги из «Рамблера», включая разработчика Самвела Меджлумяна, даже пробуют этот язык в качестве серверного решения. На встрече сообщества CocoaHeads Самвел перечислил готовые продукты для построения сервера на Swift, сравнил их между собой и показал короткое демо.

В последнее время, часто вижу вопрос:

Можно ли в iOS работать с геолокацией, когда приложение свернули и отправлять данные на сервер?

Это действительно возможно и совсем не сложно.
How to вместится в превью статьи.

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

Чтобы была какая-то конкретика, я предположил, что перед нами стоит задача написать вело-трекер. Со стороны пользователя это выглядит так:

1. Скачиваю приложение
2. Запускаю
3. Регистрируюсь
4. Нажимаю куда просят
5. Закрываю
6. Катаюсь
7. Запускаю
8. Вижу результат

p.s. финальный код здесь.

Два года назад я начал негласно исполнять роль iOS-lead в компании Touch Instinct и формированием стабильной работы iOS-отдела. Спустя полгода это трансформировалось в официальную должность. Из-за отсутствия опыта у меня возникало огромное количество проблем, которые вызывали жжение в области верхней части кресла. Это происходило из-за ряда факторов:

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

Если вы стали лидом и первоначальная эйфория сменилась небольшим горением и унынием, то пара советов не будет лишней.

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

• Как делать Get запросы с Retrofit
• Retrofit и Rx
• RecyclerView с Котлином
• Извлечение данных с api

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

В результате, мы получаем целенаправленное обучение, но БЕЗ ступоров, проблем непонимания вида «а где это использовать», а также без скучного и пассивного чтения теории. Совсем.

В рамках статьи представлено 5 учебных задачек, которые покрывают Spring Jdbc/Transactions на 50% от необходимых для сертификации знаний. Главная задача статьи — массово протестировать саму идею, а также вместе с вами разработать большое количество уникальных задачек по всем темам.

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

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

Я надеюсь, что как грамотный разрабочик, вы имеете представление о unit-тестировании и сделаете себе в голове пару мысленных отметок о том, чего надо избегать при написании тестов. Знакомьтесь:

Лжец (The Liar)

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

Если вы хотите добиться UI отзывчивости вашего iOS приложения, выполняя такие затратные по времени куски кода, как загрузка данных из сети или обработка изображений, то вам нужно использовать продвинутые паттерны, связанные с многопоточностью (сoncurrency), иначе работа вашего пользовательского интерфейса (UI) начнет сильно замедляться и даже может привести к полной его «заморозке». Вам нужно убрать ресурсо-затратные задачи с main thread (главного потока), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI).

В текущей версии Swift 3 и ближайшей Swift 4 (осень 2017) это можно сделать двумя способами, которые пока не связаны с встроенными языковыми конструкциями Swift, начало реализации которых будет только в Swift 5 (конец 2018).

Один из них использует GCD (Grand Central Dispatch) и ему посвящена предыдущая статья. В этой статье мы покажем, как достичь отзывчивости UI в iOS приложениях с помощью таких абстрактных понятий, как операция Operation и очередь операций OperationQueue. Мы также покажем в чем различие этих двух подходов и какой из них в каких ситуациях лучше использовать.

Код для этой статьи можно посмотреть на Github.

­­ 

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

С недавних пор мы взялись за внедрение UI-тестирования в iOS для iFunny. Путь этот тернист, долог и холиварен. Но все равно хочется поделиться с умными людьми своими первыми шагами в этом направлении. На истину не претендуем – всё примеряли к собственному продукту. Поэтому под катом немного информации о том, что такое iFunny на iOS и зачем нам понадобился UI + много фидбека по инструментам и примеров кода.

Здравствуй, Хабр! Данная статья предназначена для тех, кто приблизительно шарит в математических принципах работы нейронных сетей и в их сути вообще, поэтому советую ознакомиться с этим перед прочтением. Хоть как-то понять, что происходит можно сначала здесь, потом тут.

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

Предисловие

В ходе разработки ios-приложения, перед разработчиком может встать задача unit-тестирования кода. Именно с такой задачей столкнулся я.

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

Зачем решать экстремальные задачи

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

К сожалению, не всегда можно положиться на интуицию. Допустим Вы сотрудник коммерческой фирмы и отвечаете за рекламу. Затраты на рекламу в месяц не должны превышать 10 000 денежных единиц (д.е). Минута радиорекламы стоит 5 д.е., а телерекламы 90 д.е. Фирма намерена использовать радиорекламу в три раза чаще чем телерекламу. Практика показывает, что 1 минута телерекламы обеспечивает объём продаж в 30 раз больший чем 1 минута радиорекламы.

Все началось с Kotlin. Случайно попалась статья про новый язык, что на нем можно писать под Android. Соприкоснувшись с темой, узнал что изначально приложения под Android пишутся на JAVA. Решил узнать на сколько трудоемко писать приложения под Android, в чем преимущества платформы на практике. Ведь по сути приложения JS и приложения Android выполняют одну и туже функцию. Заодно решил провести эксперимент. Что можно сделать за 12 часов, не зная что такое JAVA и тонкости разработки под Android, используя как помощник только Google. Пришла идея, которую развил в постановку задачи.

Только что я столкнулся с еще одним проявлением синдрома самозванца: «Я правда разработчик — или просто хорошо гуглю?»

Далее следовал ответ, в котором я, однако, не увидел главного — поэтому ответить придется мне: слишком уж многие боятся без каких-либо оснований.

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

Если информацию легко найти, это не делает человека глупым

Частенько мне доводится слышать одну историю — полагаю, подлинность ее сомнительна, но, как бы там ни было, суть такова. Когда у Эйнштейна попросили номер телефона, он полез его искать и сказал: «Зачем запоминать то, что можно найти менее чем за две минуты?»