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

Недостаток один — высокий порог входа. Пытаясь разобраться в ФП, я столкнулся с огромным количеством теории, функторами, монадами, теорией категорий и алгебраическими типами данных. А как применять ФП на практике, было неясно. Кроме того, примеры приводились на незнакомых мне языках — хаскеле и скале.

Тогда я решил разобраться в ФП самого начала. Разобрался и рассказал на codefest о том, что ФП — это на самом деле просто, что мы уже им пользуемся в Swift и можем пользоваться еще эффективнее.

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

Примером внешних изменений может быть: Изменение размера окна в macOS, изменение ориентации экрана, различные размеры экранов.

Пример внутренних изменений: Изменение контента в окне, изменения в зависимости от языка и т.д.

Создать свой интерфейс можно 3-мя способами: программно, на основе маски, которая автоматически подстраивается под изменения или использовать Auto Layout.

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

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

Как эффективнее распоряжаться своим временем на работе, помогала разбираться тренер по тайм-менеджменту, HR-специалист Wrike, Дарья Игнатович.

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

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

Привет, Хабр!

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

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

Поучить английский

AJ Hoge. На его канале есть всё: от базовых слов до размышлений о важности языка тела в общении. Чувак пилит видосы уже много лет, материальчик накопился.

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

Год назад я начал работать на полную ставку в Bloomberg. И тогда же задумал написать эту статью. Я думал, что буду полон идей, которые смогу выплеснуть на бумагу, когда придёт время. Но уже через месяц понял, что всё будет не так просто: я уже начал забывать то, чему научился. Либо знания настолько хорошо усвоились, что мой разум заставил меня поверить, будто я всегда это знал, либо они просто вылетели у меня из головы.¹

Это одна из причин, по которой я начал вести дневник. Каждый день, попадая в интересные ситуации, я описывал их. И всё благодаря тому, что я сидел рядом с ведущим программистом. Я мог вблизи наблюдать за его работой, и видел, насколько она отличается от того, что сделал бы я. Мы много программировали вместе, что ещё больше облегчало мои наблюдения. Более того, в нашей команде не осуждается «подглядывание» за людьми, пишущими код. Когда мне казалось, что происходит что-то интересное, я поворачивался и смотрел. Благодаря постоянным вставаниям я всегда был в курсе происходящего.

Я год просидел рядом с ведущим программистом. Вот чему я научился.

Привет! Сегодня я хочу поделиться советами по написанию совершенного понятного кода, взятые из книги Питера Гудлифа «Ремесло программиста // Практика написания хорошего кода».

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

Субъективно: рефакторинг — это юношеское "заболевание". По личным наблюдениям, где-то после 26 лет начинает отпускать. Как в той старой фразе: "Кто в молодости не был революционером — у того нет сердца, кто в зрелости не стал консерватором — у того нет ума". Поэтому, пока окончательно не отпустило, попробую описать юзкейсы рефакторинга и возможные цели, которые можно достигнуть с его помощью.

Ровно 15 лет назад, в этот самый день, своими дрожащими коленками я переступил порог офиса небольшого провинциального интернет-провайдера. Моя первая настоящая работа в качестве программиста. Знаний почти нет. Тонкий испуганный голосок откуда-то из желудка советует развернуться и убежать подальше, пока окончательно не опозорился. Глубокий вдох-выдох, и вот генеральный директор уже ведет меня в небольшую комнатку-подвальчик, показывает на полуразобранный компьютер, видавший лучшие времена: «Это твое рабочее место. Устраивайся». Так началась моя карьера.

Но перенесемся в настоящее. Сейчас я пишу эти строки, сидя в удобном офисе престижного БЦ в центре Москвы. За плечами работа с крупными международными брендами и разработка сложных fintech приложений. Сотни книг прочитано и десятки статей написано. Мания величия давно вылечена. Менеджерские позиции опробованы и отвергнуты. Душевное равновесие найдено. Любовь к профессии сохранена. Однако это не статья из серии “Какой я молодец. Делай, как я и тоже будешь молодцом”. Эта статья о том, какие ошибки я совершал и что можно было сделать лучше. Эта статья — ретроспектива моей карьеры.

1. Научитесь гуглить
Быть программистом, — значит научиться искать ответы на свои вопросы. Научившись эффективно «гуглить», вы сэкономите много времени, затрачиваемого на разработку.

2. Не обещайте много, но делайте больше, чем обещали
Лучше сообщать вашей команде, что выполнение задачи займет три недели, но выполнять её за две, чем наоборот. Следуя этому принципу, вы выстроите доверительные отношения.

Со стороны iOS разработка может казаться закрытым клубом. Для работы обязательно нужен компьютер от Apple, экосистему пристально контролирует одна компания. Изнутри тоже иногда слышны противоречия — кто-то говорит, что язык Objective-C старый и неповоротливый, а кто-то, что новый язык Swift слишком сырой.

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

В этот раз о своем опыте нам рассказали Марат Нургалиев и Борис Павлов — как они учились профессии, как проходили первые собеседования, почему получали отказы. А экспертом выступил Андрей Антропов — декан факультета iOS-разработки в GeekBrains.

Как разработчик, вы услышите много сумасшедших, невероятных теорий о значении «строк кода». Не верьте ни одной. Строки кода — нелепая метрика. В очень редких случаях она что-то говорит, обычно — ничего. Использование строк кода для принятия решений похоже на оценку качества книги по количеству страниц.

Некоторые могут сказать, что чем меньше строк кода в приложении, тем легче его читать. Это только частично верно. Вот мои метрики для читаемого кода:

• Код должен быть последовательным
  
• Код должен быть информативным
  
• Код должен быть хорошо документирован
  
• Код должен использовать стабильные современные функции
  
• Код не должен быть излишне сложным
  
• Код не должен быть неэффективным (не пишите намеренно медленный код)

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

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера


Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.