Простые вещи и в Swift/Kotlin делаются просто. Например тут можно было бы остановиться на статическом номере и вручную его менять когда нужно. Но хотелось именно автоматизировать процесс, чтобы забыть о этих номерах версий. Именно тогда и вылезли описанные в статье подводные камни.
Да всё нормально. Я сначала хотел на средний уровень разработчиков поставить этот пост. Но в редакции Хабра мне порекомендовали поставить для начинающих. В принципе, если бы когда я начинал разработку попал на эту статью - она бы мне помогла начать.
Надеюсь статья получилась не слишком сложной для начинающих.
Я сейчас параллельно учусь в школе 21 (от Сбера) и как раз один из текущих проектов, это проект CI/CD, где бонусным заданием как раз надо создать CI/CD бота. Так что у меня скоро появится такой бот и прикручу его к своим проектам.
Мы сборки под Firebase не делали. У нас у всех проектов свой бекенд и публикуем сразу в AppStore/GooglePlay. Тестировщики тестируют на своих девайсах или эмуляторах.
Если вы делаете сборки с разных веток, то это не значит, что одна версия более свежая. Это значит что у вас 2 совершенно разные версии. Соответственно для тестирования нужны совершенно разные номера версий. Как вариант, после номер версии ещё выводить хеш-код коммита, его не сложно добавить. Но лично мне так не нравится, выглядит "не красиво" - хотя в сторах видел много приложений, у которых в номере версии указывается хеш-код коммита.
Про Kotlin + Compose + kts и SwiftUI, планировал следующую статью в зависимости от того, как эта зайдёт. Спасибо за совет про toml-файл - когда буду готовить следующую статью, то посмотрю на этот файл.
Наоборот - версию выставлять через гит практично. Но для этого должна быть корректно выстроена работа с гит. Мы выкладывали в TestFlight/тестовый Google Play версии только с ветки "rc" - наверно напишу отдельную статью про git, GitHub, GitLab - у начинающих часто с ними проблемы... Это позволит версиям быть последовательно, а не хаотично, и всегда у сборки будет новый номер.
Да, можно поставить, но лично для меня это не принципиально. Скорость сборки проектов актуальна для больших проектов, когда важна каждая миллисекунда. Для пет-проектов и небольших проектов, считаю не тем, на что нужно обращать внимание.
Про тесты согласен. Пет-проекты обычно пишутся без тестов. И это также более актуально для больших проектов. С fastline к сожалению не довелось работать.
Благодарю за комментарии и подробные предложения по редактуре. Как буду немного посвободней - внесу предложенные изменения в статью.
Статья писалась для начинающих, для тех, кто ни разу не пробовал React и хотел бы разобраться с ним. Да, за основу я взял официальную документацию, но там многие моменты не были расписаны или наоборот было много воды. Хотелось сжать информацию, чтобы с основами можно было ознакомиться за 10 минут, а не за день (сколько мне потребовалось на изучение документации).
То что статья кажется слабой для мидлов и синьоров - возможно. Но она писалась не для них, а для трейни и джунов, которым интересно попробовать React и решить хотят они дальше его изучать или нет.
И спасибо за ссылку - почитал, там действительно всё подробно описано.
Так у каждого свои кружочки. В статье я показал мои кружочки. В моих нет embedded. Кстати сегодня выступал с этой темой на мероприятии от МТС и понял, что мне снова надо рисовать кружочки, и выбирать на чём сконцентрироваться)))
3 года назад ходил в вашу компанию на собеседование (правда по Android). Тогда я был джуном, а ваша компания искала только мидлов/синьоров и мне отказали. Прошло 3 года, теперь я мидл/синьор/тимлид и сам ищу себе стажёров, также как и вы))) Успехов со стажёрами, коллега :)
Бэкенд — это, наверное, одна из немногих сфер, где сейчас популярно несколько языков. Тут придётся определиться более точно со сферой.
Большинство сайтов во всём мире написаны на php, так что если хочется писать бэкенд для сайтов за границей, то php — это лучший выбор.
Я сразу написал, что - популярно несколько языков, и далее - большинство сайтов написано на php. Конечно многое сейчас написано на python и JS, но по количеству сайтов - лидирует php. Да, наверно они скоро догонят и обгонят его, но пока так.
Что касается выбора - я описывал свою историю. По большому счёту все 9 направлений - это разные миры. И в каждом из этих миров я немного разбирался, т.к. люблю развиваться и постоянно искать и изучать что-то новое. У вас видимо другая жизненная стратегия - заниматься тем, чем вы занимаетесь. Это тоже нормальная стратегия - потому у вас видимо не было подобных сложностей в выборе.
Про 15 лет... Когда работал в 1С или руководителем в Сбере меня всё устраивало. И мне нужно было за полгода-год решить куда двигаться дальше. Так что я не 15 лет выбирал, а полгода-год.
Я бы не сказал, что там нет бизнес-логики. Просто она не такая, как в АБС.
Во фронтах бизнес-логика больше связана с UX и управлением бизнес-процессом.
В АБС бизнес-логика больше про управление данными и процессинг.
Нормальный процедурный язык где есть типы данных с фиксированной точкой (для которых реализована вся арифметика, в т.ч. такие вещи как "присвоение с округлением" если переменная с большим количеством разрядов присваивается переменной с меньшим), удобно со строками работать, много функций работы с датой-временем и поддержкой самых разных форматов дат и времени... Плюс он дает достаточно быстрый и эффективный код на выходе. Плюс имеет как встроенные функции работы с таблицами, так и возможность вставлять SQL операторы непосредственно в код...
Это описание мне напомнило 1С))) Ну может кроме большого количества разрядов и "быстрый и эффективный код на выходе"))) "Вьетнамские флешбеки"))) Благо из 1С ушёл в более техническую разработку.
Больше года думал, чем я хочу заниматься и не мог на чём-то конкретном остановиться. Так что обращение к психологу и ментору лично мне помогло быстро определиться.
Ментору я заплатил за помощь в решении моего вопроса. Он мне помог. Я тогда не знал про икигай. И только потом, когда узнал о нём - то вспомнил, что ментор мне задавал похожие вопросы. Кстати, ментор недавно запустил IT-бизнес в банковском секторе с которого получает несколько миллионов в месяц. Это я к тому, что он не представитель инфоцыган, а реальный бизнесмен.
мотивации "хочу в мобилки" и "хочу в ии" слишком широкие и абстрактные
Чтобы прийти к чему-то конкретному нужно сначала определиться в этих широких и абстрактных понятиях.
"игрофикация" вообще относится к менеджменту или коучингу а не к программированию.
Я привёл мои сферы интересов для примера и да, некоторые из них не из IT. В частности "игрофикация" скорее ближе к маркетингу (или к менеджменту, если используется для улучшения внутренних процессов компании)
Знаком с Lean Startup. В нём не совсем так. Скорее: Можно зарабатывать на том, что является "болью" клиента. И это западный подход, через "боль".
"Икигай" это восточный подход, чтобы его понять - нужно другое мышление, "не западное". В восточном подходе можно начать получать доход как благодарность за счастье, а не как избавление от "боли". Ближе всего из известному к этому подходу "донейшн" - когда не указана цена, и человек сам решает сколько заплатить.
А если "мир" не готов за это платить, то значит ему не сильно нужно. А если вы думаете, что миру что-то нужно, но не попытались это продать, значит это гипотеза, которую вы не проверили (и которая скорее всего не работает).
Тут всё сложнее. За некоторые вещи "мир" не может платить столько сколько нужно, чтобы окупиться. Тут не нулевая цена. Тут вопрос соответствия цены спроса и предложения. Часто бывает, что цена спроса ниже, чем цена предложения. И это не значит, что люди не готовы платить. Просто они не могут или не готовы платить больше.
Так что при оценке "готов ли мир платить" нужно оценивать не да/нет, а например в конкретных цифрах: сколько готов платить и сколько заказчиков готовы столько платить.
Математические расчёты и на MathLab делают - сам когда-то решал дифференциально-интегральные уравнения для строителей - по расчёту мостов (смещения и скручивания под нагрузкой)
Всё-таки считаю это более узкие области. Да, там тоже нужны специалисты. Даже на таких экзотических языках как Haskell - но их в разы меньше, чем тех же Java-программистов. Достаточно открыть hh.ru и посмотреть, кто требуется.
Я описываю свой опыт. Работал во фронтальных системах и там 90% разработчиков были на Java. Так же знаю, что для банкоматов ПО писалось на С/C++, но их явно было меньше, чем нас. Потому и сделал такой вывод.
Повторюсь, что говорил именно про большинство. В ядре разработчиков больше чем в фронтальных системах? Если так то признаю, что был не прав указывая язык.
Простые вещи и в Swift/Kotlin делаются просто. Например тут можно было бы остановиться на статическом номере и вручную его менять когда нужно. Но хотелось именно автоматизировать процесс, чтобы забыть о этих номерах версий. Именно тогда и вылезли описанные в статье подводные камни.
Да всё нормально. Я сначала хотел на средний уровень разработчиков поставить этот пост. Но в редакции Хабра мне порекомендовали поставить для начинающих. В принципе, если бы когда я начинал разработку попал на эту статью - она бы мне помогла начать.
Надеюсь статья получилась не слишком сложной для начинающих.
Благодарю, изучу этот проект позже https://github.com/android/nowinandroid
Я сейчас параллельно учусь в школе 21 (от Сбера) и как раз один из текущих проектов, это проект CI/CD, где бонусным заданием как раз надо создать CI/CD бота. Так что у меня скоро появится такой бот и прикручу его к своим проектам.
Да, потому что у вас видимо не маленький проект. А я пишу как раз для начинаюших, у кого ещё нет CI/CD и прочего)
Круто. Тоже планировал бота написать, но пока руки до этого не дошли.
Мы сборки под Firebase не делали. У нас у всех проектов свой бекенд и публикуем сразу в AppStore/GooglePlay. Тестировщики тестируют на своих девайсах или эмуляторах.
Для фиче-веток можно отдельные теги вводить ;)
Если вы делаете сборки с разных веток, то это не значит, что одна версия более свежая. Это значит что у вас 2 совершенно разные версии. Соответственно для тестирования нужны совершенно разные номера версий. Как вариант, после номер версии ещё выводить хеш-код коммита, его не сложно добавить. Но лично мне так не нравится, выглядит "не красиво" - хотя в сторах видел много приложений, у которых в номере версии указывается хеш-код коммита.
Про Kotlin + Compose + kts и SwiftUI, планировал следующую статью в зависимости от того, как эта зайдёт. Спасибо за совет про toml-файл - когда буду готовить следующую статью, то посмотрю на этот файл.
Наоборот - версию выставлять через гит практично. Но для этого должна быть корректно выстроена работа с гит. Мы выкладывали в TestFlight/тестовый Google Play версии только с ветки "rc" - наверно напишу отдельную статью про git, GitHub, GitLab - у начинающих часто с ними проблемы... Это позволит версиям быть последовательно, а не хаотично, и всегда у сборки будет новый номер.
Да, можно поставить, но лично для меня это не принципиально. Скорость сборки проектов актуальна для больших проектов, когда важна каждая миллисекунда. Для пет-проектов и небольших проектов, считаю не тем, на что нужно обращать внимание.
Про тесты согласен. Пет-проекты обычно пишутся без тестов. И это также более актуально для больших проектов. С fastline к сожалению не довелось работать.
Благодарю за комментарии и подробные предложения по редактуре. Как буду немного посвободней - внесу предложенные изменения в статью.
Статья писалась для начинающих, для тех, кто ни разу не пробовал React и хотел бы разобраться с ним. Да, за основу я взял официальную документацию, но там многие моменты не были расписаны или наоборот было много воды. Хотелось сжать информацию, чтобы с основами можно было ознакомиться за 10 минут, а не за день (сколько мне потребовалось на изучение документации).
То что статья кажется слабой для мидлов и синьоров - возможно. Но она писалась не для них, а для трейни и джунов, которым интересно попробовать React и решить хотят они дальше его изучать или нет.
И спасибо за ссылку - почитал, там действительно всё подробно описано.
Так у каждого свои кружочки. В статье я показал мои кружочки. В моих нет embedded.
Кстати сегодня выступал с этой темой на мероприятии от МТС и понял, что мне снова надо рисовать кружочки, и выбирать на чём сконцентрироваться)))
3 года назад ходил в вашу компанию на собеседование (правда по Android). Тогда я был джуном, а ваша компания искала только мидлов/синьоров и мне отказали. Прошло 3 года, теперь я мидл/синьор/тимлид и сам ищу себе стажёров, также как и вы))) Успехов со стажёрами, коллега :)
Видимо вы не внимательно читали, цитата:
Я сразу написал, что - популярно несколько языков, и далее - большинство сайтов написано на php. Конечно многое сейчас написано на python и JS, но по количеству сайтов - лидирует php. Да, наверно они скоро догонят и обгонят его, но пока так.
Что касается выбора - я описывал свою историю. По большому счёту все 9 направлений - это разные миры. И в каждом из этих миров я немного разбирался, т.к. люблю развиваться и постоянно искать и изучать что-то новое. У вас видимо другая жизненная стратегия - заниматься тем, чем вы занимаетесь. Это тоже нормальная стратегия - потому у вас видимо не было подобных сложностей в выборе.
Про 15 лет... Когда работал в 1С или руководителем в Сбере меня всё устраивало. И мне нужно было за полгода-год решить куда двигаться дальше. Так что я не 15 лет выбирал, а полгода-год.
Я бы не сказал, что там нет бизнес-логики. Просто она не такая, как в АБС.
Во фронтах бизнес-логика больше связана с UX и управлением бизнес-процессом.
В АБС бизнес-логика больше про управление данными и процессинг.
Это описание мне напомнило 1С))) Ну может кроме большого количества разрядов и "быстрый и эффективный код на выходе"))) "Вьетнамские флешбеки"))) Благо из 1С ушёл в более техническую разработку.
Больше года думал, чем я хочу заниматься и не мог на чём-то конкретном остановиться.
Так что обращение к психологу и ментору лично мне помогло быстро определиться.
Ментору я заплатил за помощь в решении моего вопроса. Он мне помог. Я тогда не знал про икигай. И только потом, когда узнал о нём - то вспомнил, что ментор мне задавал похожие вопросы. Кстати, ментор недавно запустил IT-бизнес в банковском секторе с которого получает несколько миллионов в месяц. Это я к тому, что он не представитель инфоцыган, а реальный бизнесмен.
Чтобы прийти к чему-то конкретному нужно сначала определиться в этих широких и абстрактных понятиях.
Я привёл мои сферы интересов для примера и да, некоторые из них не из IT. В частности "игрофикация" скорее ближе к маркетингу (или к менеджменту, если используется для улучшения внутренних процессов компании)
Знаком с Lean Startup. В нём не совсем так. Скорее: Можно зарабатывать на том, что является "болью" клиента. И это западный подход, через "боль".
"Икигай" это восточный подход, чтобы его понять - нужно другое мышление, "не западное". В восточном подходе можно начать получать доход как благодарность за счастье, а не как избавление от "боли". Ближе всего из известному к этому подходу "донейшн" - когда не указана цена, и человек сам решает сколько заплатить.
Тут всё сложнее. За некоторые вещи "мир" не может платить столько сколько нужно, чтобы окупиться. Тут не нулевая цена. Тут вопрос соответствия цены спроса и предложения. Часто бывает, что цена спроса ниже, чем цена предложения. И это не значит, что люди не готовы платить. Просто они не могут или не готовы платить больше.
Так что при оценке "готов ли мир платить" нужно оценивать не да/нет, а например в конкретных цифрах: сколько готов платить и сколько заказчиков готовы столько платить.
Математические расчёты и на MathLab делают - сам когда-то решал дифференциально-интегральные уравнения для строителей - по расчёту мостов (смещения и скручивания под нагрузкой)
Всё-таки считаю это более узкие области. Да, там тоже нужны специалисты. Даже на таких экзотических языках как Haskell - но их в разы меньше, чем тех же Java-программистов. Достаточно открыть hh.ru и посмотреть, кто требуется.
То, что там много разного полностью согласен.
Я описываю свой опыт. Работал во фронтальных системах и там 90% разработчиков были на Java. Так же знаю, что для банкоматов ПО писалось на С/C++, но их явно было меньше, чем нас. Потому и сделал такой вывод.
Повторюсь, что говорил именно про большинство. В ядре разработчиков больше чем в фронтальных системах? Если так то признаю, что был не прав указывая язык.
Я в банке во фронтальных системах работал - там как раз было очень много Java. Что там в АБС я не видел. Может там C/C++ или ещё что-то.