⚙️ git worktree – параллельная работа в нескольких ветках без переключений

Мощная команда, которая позволяет работать с несколькими ветками Git одновременно в разных директориях. Больше не нужно постоянно переключаться между ветками или клонировать репозиторий несколько раз.

📌 Практические сценарии:

1. Параллельная разработка:

# Главная ветка в основной папке
# feature/auth в отдельной папке
git worktree add ../project-auth feature/auth

# Теперь можно работать с main и feature/auth одновременно!

2. Тестирование PR без переключений:

# Создать worktree для проверки PR коллеги
git worktree add ../pr-review-123 pr/feature-123

# Перейти в папку и запустить тесты
cd ../pr-review-123
npm test

3. Долгие операции в фоне:

# Запустить сборку в отдельной worktree
git worktree add ../project-build build-optimization
cd ../project-build
npm run build:production  # Не блокирует основную работу

⚡️ Ключевые преимущества:

• Нет конфликтов индекса – каждый worktree имеет свой собственный .git
• Изоляция изменений – работа в одной ветке не влияет на другую
• Экономия времени – мгновенное переключение между контекстами

📊 Пример рабочего процесса:

# 1. Основная работа в main
cd ~/projects/myapp

# 2. Создаем worktree для нового фича
git worktree add ~/projects/myapp-feature -b feature/new-payment

# 3. Работаем одновременно:
# Terminal 1 (main): git log --oneline
# Terminal 2 (feature): git add . && git commit -m "Add payment"

# 4. После мержа feature
git worktree remove ~/projects/myapp-feature

Pro-совет: Добавьте в .gitconfig:

ini
[alias]
    wt = worktree
    wt-list = worktree list
    wt-add = worktree add
    wt-remove = worktree remove

🔸 Курс «Основы IT для непрограммистов»
🔸 Получить консультацию менеджера
🔸 Сайт Академии 🔸 Сайт Proglib

🐸 Библиотека мобильного разработчика

#буст #JuniorKit

🐸 Библиотека мобильного разработчика

#междусобойчик #JuniorKit #Swift

🎓 Считаем разницу в зарплатах джунов с вышкой и без

Из каждого утюга кричат, что в айти можно войти с улицы, просто выучив Python. Но статистика зарплат и требования топовых компаний говорят об обратном. Давай разберемся, где самоучке действительно рады, а где без профильного вуза (и даже PhD!) твое резюме полетит в корзину сразу после скрининга.

👉 Читать статью

🔸 Курс «Основы IT для непрограммистов»
🔸 Получить консультацию менеджера
🔸 Сайт Академии 🔸 Сайт Proglib

🐸 Библиотека мобильного разработчика

#MadeInProglib

🗓 Новости недели

Приготовили для вас дайджест по актуальному из мира iOS, Android.

🔵 Как я создавал язык для преобразования данных вместе с ChatGPT

Рассказ о том, как используя Codex, за пару месяцев плотной работы по вечерам и субботам спроектировать специализированный ЯП (кодовое имя Branchline), написать интерпретатор, компилятор, виртуальную машину, а затем перевести это всё на Kotlin Multiplatform (KMP), чтобы получить версию под JS для онлайн-песочницы.

🔵 Знакомство со Stencil или уроки шаблонного общения

Что любят все разработчики? Конечно, автоматизировать рутинные повторяющиеся действия! Автор расскажет, как в этом может помочь язык Stencil, широко известный в узких кругах iOS-разработчиков.

🔵 State-менеджмент «из коробки» во Flutter: эффективная альтернатива BLoC и Riverpod

В данной статье автор расскажет про встроенные инструменты Flutter, которые позволяют реализовать надежный и предсказуемый state-менеджмент без сторонних фреймворков. Вы узнаете, как использовать ValueNotifier и Provider для удобной работы с состоянием и когда такой подход является оптимальным.

🔹 Курс «Основы IT для непрограммистов»
🔹 Получить консультацию менеджера
🔹 Сайт Академии 🔹 Сайт Proglib

🐸 Библиотека мобильного разработчика

#свежак

❓ Делегированные свойства (Delegated properties) в Kotlin

Делегированные свойства — это свойства, которые не хранят своё значение напрямую, а делегируют это значение другому объекту, который реализует интерфейс Delegate. При доступе к свойству, его значение запрашивается у делегата, который может выполнить какую-то дополнительную логику, а затем вернуть требуемое значение. Пример:

class Example {
    var p: String by Delegate()
}

Ключевое слово by используется для обозначения свойств, методы чтения и записи которых реализованы другим объектом, который называют делегатом.

Синтаксис выглядит так: val/var <имя свойства>: <Тип> by <выражение>. Выражение после by — делегат, потому что обращения get(), set() к свойству будут делегированы его методам getValue() и setValue(). Делегат не обязан реализовывать какой-то интерфейс, достаточно, чтобы у него были метод getValue() (и setValue() для var'ов) с определённой сигнатурой.

В Kotlin существуют несколько встроенных делегатов для работы с делегированными свойствами:

🔘 lazy() — позволяет создавать лениво инициализированные свойства
🔘 observable() — позволяет реагировать на изменения свойства
🔘 vetoable() — позволяет отклонять изменения значения свойства на основе заданного условия
🔘 notNull() — гарантирует, что свойство не будет иметь значение null
🔘 map() — позволяет хранить значения свойств в словаре (Map)

Кроме того, в Kotlin можно создавать свои собственные делегаты, реализуя интерфейс ReadOnlyProperty или ReadWriteProperty. Это дает возможность создавать кастомные поведения для свойств, например, кеширование значений или логирование операций чтения/записи.

🔹 Курс «Основы IT для непрограммистов»
🔹 Получить консультацию менеджера
🔹 Сайт Академии 🔹 Сайт Proglib

🐸 Библиотека мобильного разработчика

#буст #JuniorKit #Kotlin

✨ Принудительная перезагрузка представления в SwiftUI

В SwiftUI представления являются декларативными и автоматически перестраиваются при изменении их базового состояния. Однако бывают ситуации, когда требуется принудительно перезагрузить представление. Один из распространённых способов добиться этого — использовать модификатор .id(_:) в сочетании с управляемым состоянием идентификатором.

🔹 Пример реализации

Вот минимальный пример того, как можно принудительно перезагрузить представление:

struct DemoView: View {
    @State private var viewId = UUID()

    var body: some View {
        VStack {
            Text(viewId.uuidString)
                .id(viewId) // forces SwiftUI to recreate this view

            Button("Retry") {
                viewId = UUID()
            }
        }
    }
}

В этом примере при каждом нажатии на кнопку Retry viewId заменяется на новое UUID. Поскольку .id(viewId) прикреплено к тексту, SwiftUI считает его новым представлением и уничтожает старое поддерево, заменяя его новым.

🔹 Преимущества

Гарантированный сброс

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

Полезно для сценариев восстановления

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

Предсказуемое поведение

Поскольку SwiftUI в значительной степени полагается на идентификацию для согласования представлений, явное управление с помощью .id(_:) делает перезагрузку предсказуемой и понятной.

🔹 Недостатки

Снижение производительности

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

Потеря локального состояния

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

Решение, ориентированное на симптомы

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

🔹 Когда использовать

Принудительную перезагрузку представления следует рассматривать как крайнюю меру, а не как предпочтительное решение. Это полезно для повторных попыток, очистки поврежденного состояния или создания прототипов. В рабочем коде старайтесь моделировать поток состояний так, чтобы обновления SwiftUI происходили автоматически. Если вы часто прибегаете к .id(_:), возможно, стоит пересмотреть свой подход к управлению состоянием.

🔹 Заключение

Использование .id(_:) в сочетании с изменяющимся значением, например с UUID, — это простой способ принудительно перезагрузить представление SwiftUI. Это надёжный механизм для сброса настроек представления, но он имеет свои недостатки с точки зрения производительности и потери состояния. Как и большинство методов, его лучше применять выборочно, в тех случаях, когда требуется настоящий «сброс» настроек, а другие подходы менее эффективны.

🔸 Курс «Основы IT для непрограммистов»
🔸 Получить консультацию менеджера
🔸 Сайт Академии 🔸 Сайт Proglib

🐸 Библиотека мобильного разработчика

#PixelPerfect #MiddlePath #Swift