Правильные Atomic свойства

Как-то на интервью меня спросили как сделать правильный atomic класс. Был дан класс, в котором есть свойство с геттером и сеттером. Что с ним не так?

final class Atomic<Value> {
    private let queue = DispatchQueue(
            label: "com.test.atomic"
         )
    private var value: Value
    
    var wrappedValue: Value {
        get { return queue.sync { value } }
        set { queue.sync { value = newValue } }
    }
}

В теории, все ок. Только есть один нюанс. Я помнил о нем. По отдельности геттер и сеттер будут работать нормально, но если будет оператор +=, то начнется гонка.

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

Дополнительно про атомарность:
- Swift Atomic Properties with Property Wrappers
- Atomic Properties in Swift
- Benchmarking Swift Locking APIs

Не зовите джунов и мидлов проводить сложные собесы

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

Мне иногда ставят собесы, чтобы я оценивал тимлидов или техлидов. Хоть я и прошел весь отбор к собесам и провел уже >50 разных, без обучения таким собесам я отказываю. Одно дело собесить разрабов с небольшим опытом… Есть несколько причин:
1. Тимлидов должен оценивать опытный ревьюер тимлид или пара сеньоров
2. У нас с ними будет другой язык

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

Еще хуже, когда собеседование превращается не в лайтовый процесс оценки кандидата, а в стрессовую конкуренцию. Интервьюера может занести не туда и думать, что это интеллектуальная игра "Что? Где? Когда?" в которой он должен быть победителем.

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

MVU для SwiftUI

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

MVU, популяризированный архитектурой Elm. В MVU модель определяет состояние приложения, представление отображает пользовательский интерфейс на основе состояния (модели), а функция обновления изменяет состояние на основе сообщений (таких как действия пользователя или ответы сервера). Этот однонаправленный поток данных обеспечивает предсказуемость пользовательского интерфейса и существенно упрощает отладку.

Еще один однонаправленный паттерн, который нам так не хватало.

вопрос от подписчиков

Flutter RIP?

Как умер один фуллстек разработчик

Нельзя объять необъятное. Эту фразу больше 10 лет назад сказала мой преподаватель по программированию. Она возвращается бумерангом каждые пару лет в разных сферах. В спорте. В жизни. В работе.

Начнем с моего it лора. В проде писал на многих многих языках. Сайты начинал с php и его долларов. Потом ушел в JavaScript и в его динамичную типизацию. Писал фронт, бэк и мобилку. В то время было модно быть фуллстэком, технологий не так много и бизнес хотел сократить расходы. Мода прошла. В итоге все снова пришло к узким спецам, а под словом фуллстэк многие представляют широкого спеца в плохом смысле. Он нахватался поверхностно отовсюду, но толком ни в чем не разбирается. Он хорош на легких проектах или стартапах, но почти бесполезен в по-настоящему крупных и сложных проектах.

На днях мы общались с парой команд из кроссплатформ. Я вел эту встречу и задавал 90% вопросов. Они выбрали натив. Точнее их попросили. Две разные команды. Две разные технологии. Их проблема была не в технологиях, а в людях. В найме. Сложно найти качественного спеца, который одинаково хорошо разбирается в технологиях, не боится алгоритмов, знает глубокие специфики обеих платформ и хорошо шарит за архитектуру. Легче переписать все на натив.

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

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

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

Нужно быть экспертом в одной специфике, а не бежать соперничать со всеми во всем. Каждый должен быть хорош в чем-то одном. Выбирать нужно работу, людей, тренеров, которые улучшают сильные стороны. И не бежать качать слабые.