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

Так вышло, что вас окружают дебилы.

Сотрудники не понимают, что от них нужно, хотя это должно быть очевидно даже без объяснений и напоминаний. Заказчик – конченный: не понимает очевидных вещей, ругается на ровном месте и вообще – вместо того, чтобы накинуть бюджета и не вставлять палки в колеса, как ему сказали, ходит и че-то там эскалирует про плохого менеджера на стороне исполнителя.
Ваш линейный руководитель, вместо того чтобы утешить и поддержать вас, тоже встает на сторону заказчика.
Руководство вашей компании тянет ее непойми куда, и создается ощущение, что ваша «компания, как курица без головы: бегает, машет лапами, разбрызгивая кровь, но бегать остается недолго» (реальная цитата одного недовольного, кстати).
Процессов нет и работать совершенно невозможно. Или процессы есть, но их много и они не те. Или они есть и те, но их никто не выполняет потому что см название статьи.

Короче: вы один в кольце дураков, и вас никто не понимает.

Бывало что-то подобное?

Тогда поздравляю, вы – ленивая и эгоистичная задница.

Это очередная статья посвященная софтскилам и лайфхакам в управлении, о которых не рассказывают на курсах по менеджменту. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» и читайте другие статьи здесь, на Хабре.

В разных языках программирования применяется механизм диспетчеризации методов (Method Dispatch), и все разработчики имеют с ним дело. Однако, не все это осознают и не все понимают, как этот механизм работает. Поэтому данная статья будет полезна всем разработчикам на Swift, которые хотят погрузиться глубже в диспетчеризацию методов и понять принципы ее работы, что в свою очередь позволит писать более эффективный код и избежать появления некоторых неочевидных проблем. Также статья будет полезна тем, кто в поисках работы – данный вопрос часто обсуждается на собеседованиях iOS разработчиков.

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

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

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

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

Всем привет! 

Меня зовут Федоров Василий, я руковожу группой Mobile.Speed в компании Aliexpress Россия. Мы стараемся облегчить жизнь разработчиков, пишем утилиты, настраиваем CI, складируем метрики в Grafana — в общем отвечаем почти за все, что влияет на time-to-market и Developer Experience команд. В этой статье я расскажу о том, как мы ускоряем сборку проекта с помощью XCRemoteCache — но обо всем по порядку под катом. 

Многие iOS разработчики не задумываются как работает механизм отрисовки элементов, установки и обновлении constraints в Auto Layout'e. В этой статье я пробую подробно заглянуть внутрь работы the Layout Engine

Меня зовут Саша Терентьев, я из команды ленты ВКонтакте. В этой статье поделюсь мыслями о проблемах кода, где используются enum и сопоставления типов. Часто встречаю такой код в проектах, ресурсах, примерах. Мы обсуждали это с коллегами на внутреннем событии, и из моего доклада выросла эта статья.

Букв будет много. Но, думаю, материал пригодится широкому кругу разработчиков — и не только iOS. Примеры основаны на псевдо-Swift и написаны по мотивам использования UIKit. Но могут пригодиться для работы с разными платформами и в любой области, где возникают сопоставления с образцом, приведения типов, переборы множеств типов.

Привет! Вот и новая часть серии статей про многопоточность дождалась своей очереди (ну вы поняли, да, типа очередь статей последовательная (͡° ͜ʖ ͡°) ). В этот раз мы поднимемся на ступеньку выше, рассмотрим фреймфорк Dispatch, разберем большую часть GCD примитивов, распространенные проблемы и поищем решения.

Причины и симптоматика синдрома запястного канала

(Хабр-Статья представляет собой авторский перевод доклада, представленного автором на Scheme Workshop 2020, проводившегося в рамках Международной Конференции по Функциональному Программированию, 28 августа 2020 года)

Эта статья -- своего рода "отчёт" по самому большому проекту, который я сделал в своей жизни по собственной инициативе. Я сделал полное, исчерпывающее решение всех задач из одной из самых извесных книг по программированию в мире "Структура и Интерпретация Компьютерных Программ" (Structure and Interpretation of Computer Programs -- SICP), за авторством Абельсона, Сассмана и Сассман.

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

• Разбираемся, как на самом деле считаются суммы и проценты в клиентском приложении.

• Собираем все данные по портфелю и по всем операциям через Tinkoff API.

• Строим огромную Excel таблицу со всеми данными.

• Узнаём, сколько комиссий и налогов с нас уже содрали и что нам останется при выводе.

• Пытаемся понять, что нам с этим делать.

Git имеет репутацию запутывающего инструмента. Пользователи натыкаются на терминологию и формулировки, которые вводят в заблуждение. Это более всего проявляется в "перезаписывающих" историю командах, таких как git cherry-pick или git rebase. По моему опыту, первопричина путаницы — интерпретация коммитов как различий, которые можно перетасовать. Однако коммиты — это не различия, а снимки! Я считаю, что Git станет понятным, если поднять занавес и посмотреть, как он хранит данные репозитория. Изучив модель хранения данных мы посмотрим, как новый взгляд помогает понять команды, такие как git cherry-pick и git rebase.

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

Возможно, у многих возникнет вопрос:  “Зачем разбивать с помощью SPM?”. Ведь можно просто создавать подпроекты. Можно, но в использовании SPM для разбиения есть несколько преимуществ:

Unicode