Разбирался с git - как организовать тестирование кнопок-компонент и не пушить на GitHub тестовые экраны.
Вроде разобрался:
- Создать компонент в ветке разработки компоненты
- Создать ветку тестирования
- Создать в ветке тестирования экраны для тестов кнопок
- Внести изменения в компоненты кнопки
- Сделать commit изменений
- Перейти обратно в ветку разработки компоненты
- перенести только нужные файлы компоненты из ветки тестирования:
- делаем commit изменений в ветке разработки компоненты
- пушим изменения на GitHub
Вроде разобрался:
- Создать компонент в ветке разработки компоненты
- Создать ветку тестирования
- Создать в ветке тестирования экраны для тестов кнопок
- Внести изменения в компоненты кнопки
- Сделать commit изменений
- Перейти обратно в ветку разработки компоненты
- перенести только нужные файлы компоненты из ветки тестирования:
git checkout ветка-тестирования -- путь/файл.swift путь/файл.swift
- делаем commit изменений в ветке разработки компоненты
- пушим изменения на GitHub
Взаимодействию с ИИ надо тоже учиться
Должно быть хотя бы базовое понимание принципов работы ИИ и разницы в моделях.
Получать адекватный ответ от ИИ без получения навыков взаимодействия с ИИ самонадеянно.
Вот хороший сайт, чтобы получить базовые представления о промптинженерии:
https://www.promptingguide.ai/ru
UPD: ресурс большой, решил добавить себе в программу обучения.
Должно быть хотя бы базовое понимание принципов работы ИИ и разницы в моделях.
Получать адекватный ответ от ИИ без получения навыков взаимодействия с ИИ самонадеянно.
Вот хороший сайт, чтобы получить базовые представления о промптинженерии:
https://www.promptingguide.ai/ru
UPD: ресурс большой, решил добавить себе в программу обучения.
www.promptingguide.ai
Руководство по промпт-инжинирингу | Prompt Engineering Guide
A Comprehensive Overview of Prompt Engineering
Please open Telegram to view this post
VIEW IN TELEGRAM
🍾3
Подключение к App Store Connect
Хронология
6 дек 24 - Регистрация Apple Developer Account
10 дек 24 - Apple Developer Program Enrolment
13 мар 25 - Заказ
18 мар 25 - Письма нет
19 мар 25 - Что-то пошло не так, попробуйте еще раз
20 мар 25 - Welcome to the Apple Developer Program.
UPD: 24 мар 25 - Соглашение о платных приложениях
Хронология
6 дек 24 - Регистрация Apple Developer Account
Все требования выполнил, но...
"We are unable to process your request.
An unknown error occurred."
Написал в поддержку
10 дек 24 - Apple Developer Program Enrolment
Поддержка ответила, что было бы неплохо проверить соответствие кода страны проверенного номера телефона с регионом аккаунт Apple.
Проверил, исправил...
13 мар 25 - Заказ
App Developer отправлял на сайт, там жамкнул оплатить ($99), ввёл карту, получил письмо "Order Acknowledgement" - ждите пару дней.
18 мар 25 - Письма нет
Письма подтверждения нет, деньги с карты НЕ списались. Написал в поддержку.
19 мар 25 - Что-то пошло не так, попробуйте еще раз
Пришел ответ: ваш платеж не был успешно завершен. Для решения этой проблемы с оплатой мы рекомендуем вам отправить новую регистрацию с помощью приложения Apple Developer.
Видимо что-то подкрутили, и появилась возможность оформить подписку через приложение.
Но цена стала 119,99 US$
20 мар 25 - Welcome to the Apple Developer Program.
Пришло письмо добро пожаловать и открылся доступ на сайте.
UPD: 24 мар 25 - Соглашение о платных приложениях
👌1
(Курс Angela Yu)
Для базового понимания - ок.
Для нормальной работы - надо больше, в тч практики. А практики в Git сейчас у меня навалом в проекте "iOS по взрослому".
Сегодня например с git merge разбирался, особенно когда он получился не очень и пришлось откатывать в состояние до.
Сегодня в одном из чатов прислали годный пост совет по сообщениям в коммитах, ниже поделюсь.
Please open Telegram to view this post
VIEW IN TELEGRAM
Если ты только начинаешь работать с Git, коммиты могут казаться просто формальностью.
Но представь: через пару месяцев нужно понять, почему именно ты изменил этот кусок кода.
Или коллега ищет, где починили баг, а в истории — только “fix” и “123”. Разберёмся, как писать коммиты, которые будут понятны и тебе, и команде.
Лаконичный коммит лучше длинного, но "fix bug" или "update" ничего не объясняют. Даже через месяц должно быть понятно, что именно изменилось:
✔️ "fix: исправил баг с расчётом скидки в корзине"
Громоздкие коммиты, в которых и рефакторинг, и баг-фикс, и новая фича, — головная боль для команды. Разделяйте изменения:
❌
"Обновил стили, поправил баг с кнопкой, добавил валидацию формы"
✔️
"fix: исправил баг с кнопкой отправки",
"feat: добавил валидацию формы",
"style: обновил стили формы"
Лучше договориться о едином формате.
Например, часто используют:
тип: краткое описание
• feat: новая функциональность
• fix: исправление бага
• refactor: улучшение кода без изменения логики
• style: правки форматирования
Если фикс сложный или решение неочевидное, добавьте пояснение:
✔️
"fix: исправил баг с расчётом скидки (в 3% случаев неправильно округлялась сумма)"
❗️ А если я только начинаю?
Привычка писать осмысленные коммиты помогает быстрее разобраться в проекте и выработать аккуратный стиль работы.
Команда (и ваше будущее "я") скажет спасибо!
Please open Telegram to view this post
VIEW IN TELEGRAM
После выполнения большой задачи надо просмотреть быстрые идеи во входящих, возможно найти решение или отказаться.
Идея работать со ВХОДЯЩИМИ повышает продуктивность:
- во время работы приходят идеи что-то сделать
- ты не бросаешься их сразу выполнять
- но и не забываешь
- записываешь во ВХОДЯЩИЕ
- после спокойно разбираешь все идеи, которые находились во входящих.
Почему называется ВХОДЯЩИЕ?
По аналогии с корзиной (лотком) для входящей корреспонденции: она уже пришла, но еще не разобрана.
Утром решил пару простых задач:
1. нашел горячие клавиши для быстрой заметки в Tick-Tick
(Еще проще кидать идеи во ВХОДЯЩИЕ)
2. бесило: когда открываешь терминал, например, через тот же Spotlight ( ⌘ + space ) по первым буквам it... (iTerm2) и оказываешься в корневой директории, а до той, в которой работаешь постоянно пилить и пилить через cd .
Решение:
Установил autojump
- записал нужную директорию в БД autojump командой терминале j -a директория
- сейчас перехожу по команде:
j директория
Идея работать со ВХОДЯЩИМИ повышает продуктивность:
- во время работы приходят идеи что-то сделать
- ты не бросаешься их сразу выполнять
- но и не забываешь
- записываешь во ВХОДЯЩИЕ
- после спокойно разбираешь все идеи, которые находились во входящих.
Почему называется ВХОДЯЩИЕ?
По аналогии с корзиной (лотком) для входящей корреспонденции: она уже пришла, но еще не разобрана.
Утром решил пару простых задач:
1. нашел горячие клавиши для быстрой заметки в Tick-Tick
⇧ + ⌃ + L (Еще проще кидать идеи во ВХОДЯЩИЕ)
2. бесило: когда открываешь терминал, например, через тот же Spotlight ( ⌘ + space ) по первым буквам it... (iTerm2) и оказываешься в корневой директории, а до той, в которой работаешь постоянно пилить и пилить через cd .
Решение:
Установил autojump
- записал нужную директорию в БД autojump командой терминале j -a директория
- сейчас перехожу по команде:
j директория
GitHub
GitHub - wting/autojump: A cd command that learns - easily navigate directories from the command line
A cd command that learns - easily navigate directories from the command line - wting/autojump
Как всегда подводит SE-шка
Про важность тестирования на 3-х разных размерах экранов писал ранее🔼
Верстаю онбординг учебного проекта на UIKit
Про важность тестирования на 3-х разных размерах экранов писал ранее
Верстаю онбординг учебного проекта на UIKit
Please open Telegram to view this post
VIEW IN TELEGRAM
Плагин eza для терминала
Выводит список папок и файлов в древовидной структуре.
Этот плагин имеет широкие настройки отображения списка файлов и директорий, но мне нужна была только часть с древовидной структурой.
Установка
Настройка алиесов в ~/.zshrc
В результате имеем 4 доп. Команды в терминале:
lt1 - список 1 уровня
lt2 - список 2 уровня вложенности
lt3 - список 3 уровня вложенности
lt4 - список 4 уровня вложенности
Ранее уже писал про кастомизацию терминала здесь
Выводит список папок и файлов в древовидной структуре.
Этот плагин имеет широкие настройки отображения списка файлов и директорий, но мне нужна была только часть с древовидной структурой.
Установка
brew install eza
Настройка алиесов в ~/.zshrc
plugins=(... eza)
alias lt1='eza --tree --level=1 --color=always --group-directories-first --icons'
alias lt2='eza --tree --level=2 --color=always --group-directories-first --icons'
alias lt3='eza --tree --level=3 --color=always --group-directories-first --icons'
alias lt4='eza --tree --level=4 --color=always --group-directories-first --icons'
В результате имеем 4 доп. Команды в терминале:
lt1 - список 1 уровня
lt2 - список 2 уровня вложенности
lt3 - список 3 уровня вложенности
lt4 - список 4 уровня вложенности
Ранее уже писал про кастомизацию терминала здесь
Текущий прогресс по курсам Swift
✔️ +0 16/100 - 100 дней SwiftUI
✔️ +1 18/39 - Усов книга 1
✔️ +2 7/29 - Angela Yu
🟩🟩🟩⬜️⬜️⬜️⬜️⬜️⬜️⬜️ - 100 дней
🟩🟩🟩🟩🟩🟩⬜️⬜️⬜️⬜️ - Усов
🟩🟩🟩⬜️⬜️⬜️⬜️⬜️⬜️⬜️ - Angela Yu
Проект "iOS по взрослому"
- начал таск "Верстка 1.1 Онбординг"
Отправил на первое ревью
Пришлось поразбираться с версткой под разные размеры экранов. У iPhone'ов их так много как у Андройд устройств и это радует.
В курсе Angela Yu скакун с 5 урока сразу на 16 и 18 - работа с терминалом и git (GitHub)
По Усова прошел только 1 главу enum
Подключил Аккаунт разработчика - тоже заняло определенное время, т.к. Пришлось обращаться в техподдержку.
Сейчас пытаюсь оформить Соглашение о платном конвенте, надеюсь получится и смогу публиковать приложения с подпиской.
Сейчас аккаунт позволяет публиковать только бесплатные (без платных подписок и покупок внутри) приложения.
"iOS по взрослому"
- Завершить новый таск "Верстка 1.1 Онбординг" (пройти все ревью)
Усов книга 1
- изучить 2 главы: struct, class (44 стр.)
100 дней SwiftUI
- дни 17-18 App "Чек в кафе"
- день 19 App "Конвертер"
Новый Pet-проект (пока секрет)
- подготовить картинки
- начать верстку основного экрана
Ну что ж: погнали!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Смотрел утром 100 дней SwiftUI...
и осознал, что распыляюсь между фреймворками.
Сейчас много практики получаю на учебном проекте "iOS по взрослому" - верстка UIkit кодом без сторибордов.
Курс Angela Yu - UIKit с версткой на сторибордах.
100 дней SwiftUI - логично на SwiftUI.
Врезультате, есть практика UIkit без сторибордов, но нет теории (уроков) по такому кодингу.
Надо поискать материалы, курсы по верстке кодом на UIkit и подправить свой roadmap.
и осознал, что распыляюсь между фреймворками.
Сейчас много практики получаю на учебном проекте "iOS по взрослому" - верстка UIkit кодом без сторибордов.
Курс Angela Yu - UIKit с версткой на сторибордах.
100 дней SwiftUI - логично на SwiftUI.
Врезультате, есть практика UIkit без сторибордов, но нет теории (уроков) по такому кодингу.
Надо поискать материалы, курсы по верстке кодом на UIkit и подправить свой roadmap.
Как настроить проект UIKit без сторибордов
1. Удаляем файл main.storyboard
2. В Info.plist ищем строку "Storyboard Name: Main" и удаляем всю строку
3. Настройки проекта / TARGETS / Info /
"Main storyboard file base name: Main"
Удаляем значение Main
4.В SceneDelegate.swift добавляем код в func scene(...)
Всё проект готов для верстки кодом!
1. Удаляем файл main.storyboard
2. В Info.plist ищем строку "Storyboard Name: Main" и удаляем всю строку
3. Настройки проекта / TARGETS / Info /
"Main storyboard file base name: Main"
Удаляем значение Main
4.В SceneDelegate.swift добавляем код в func scene(...)
// меняем _ на windowScene
guard let windowScene = (scene as? UIWindowScene) else { return }
// добавляем
let window = UIWindow(windowScene: windowScene)
let viewController = ViewController()
let navigationController = UINavigationController(rootViewController: viewController)
window.rootViewController = navigationController
window.makeKeyAndVisible()
self.window = window
Всё проект готов для верстки кодом!
👍1🫡1