Всем привет!
Я уже рассказывал про 5 возможных моделей ветвления в git https://t.me/javaKotlinDevOps/95
Нашел еще одну, причем уверен некоторым читателям этого блога она покажется знакомым)
Встречайте stacked pull requests.
Вот краткое описание https://www.michaelagreiler.com/stacked-pull-requests
А вот еще более краткое от меня:
1) работаем через Pull Requests (PR), они же Merge Requests
2) PR выстраиваем в лесенку
3) вливаем в обратном порядке
4) при изменениях в родительском PR, например, по результату код-ревью, проталкиваем изменения во все дочерние PR
Основное назначение данной схемы:
1) упор на ревью небольших кусочков кода, разделение фичи на мелкие commit-ы, удобные для ревью
2) разного рода миграции, когда на промежуточных стадиях код не компилируется и тесты не проходят, а все вместе - неудобоваримо для код ревью
Данная модель может работать поверх любого их описанных выше flow, за исключение trunk based. trunk based, напомню, вообще убирает Pull Requests, а процесс ревью осуществляется либо при парном программировании, либо пост-фактум.
Альтернативой является один PR с предположим 10 commits. Но преимущество данной схемы в том, что создавая вместо этого 10 PR автор скорее задумается о том, чтобы каждый из них представлял атомарное изменение, удобное для ревью.
#git #vcs #branching
Я уже рассказывал про 5 возможных моделей ветвления в git https://t.me/javaKotlinDevOps/95
Нашел еще одну, причем уверен некоторым читателям этого блога она покажется знакомым)
Встречайте stacked pull requests.
Вот краткое описание https://www.michaelagreiler.com/stacked-pull-requests
А вот еще более краткое от меня:
1) работаем через Pull Requests (PR), они же Merge Requests
2) PR выстраиваем в лесенку
3) вливаем в обратном порядке
4) при изменениях в родительском PR, например, по результату код-ревью, проталкиваем изменения во все дочерние PR
Основное назначение данной схемы:
1) упор на ревью небольших кусочков кода, разделение фичи на мелкие commit-ы, удобные для ревью
2) разного рода миграции, когда на промежуточных стадиях код не компилируется и тесты не проходят, а все вместе - неудобоваримо для код ревью
Данная модель может работать поверх любого их описанных выше flow, за исключение trunk based. trunk based, напомню, вообще убирает Pull Requests, а процесс ревью осуществляется либо при парном программировании, либо пост-фактум.
Альтернативой является один PR с предположим 10 commits. Но преимущество данной схемы в том, что создавая вместо этого 10 PR автор скорее задумается о том, чтобы каждый из них представлял атомарное изменение, удобное для ревью.
#git #vcs #branching
Telegram
(java || kotlin) && devOps
Всем привет!
Давно хотел написать про основные модели ветвления при работе c исходным кодом.
Итак поехали!
1) великий и ужасный gitflow.
Картинка: https://habrastorage.org/r/w1560/webt/ah/aw/yf/ahawyfcuk_rids2mljkuocattzg.jpeg
Описание: https://github.…
Давно хотел написать про основные модели ветвления при работе c исходным кодом.
Итак поехали!
1) великий и ужасный gitflow.
Картинка: https://habrastorage.org/r/w1560/webt/ah/aw/yf/ahawyfcuk_rids2mljkuocattzg.jpeg
Описание: https://github.…
Всем привет!
Минутка истории. И разных подходов к работе с opensource.
1-я история. Жила была компания Microsoft, и в какой-то момент она "запустила" свою инфраструктуру разработки. Были выделены ресурсы для исправление этой ситуации. Один из примеров такой деятельность - перенос исходников в git, создание своего форка git, проверка его на GitHub и вливание форка в основную ветку git. Вот тут немного подробнее про доработку git под требования Microsoft - большой объем репозитория - https://habr.com/ru/articles/795635/
2-я история. Жила была компания Facebook, тогда еще не иноагент) Компания была молодая, но тоже уже столкнулась с проблемой хранения и организации код-ревью на большом объеме кода. Разработчики компании готовы innersource-ить, чтобы решить проблему. Постучались в git, получили отказ с формулировкой - это частный случай, для основной массы пользователей не нужно, делайте маленькие репозитории. Постучались в Mercurial - там ее pull request согласились принять. Перешли на Mercurial https://habr.com/ru/articles/798881 Но предположу, что часть разработчиков на этом не успокоилась и в результате появился Sapling https://sapling-scm.com/docs/introduction/differences-hg
Это новая Version Control System, которая может работать как со своим форматом repo, так и с git. При этом делает упор на частичное клонирование репо и работу с коммитами: быстрый откат, сохранение истории изменений при слиянии коммитов и даже https://sapling-scm.com/docs/commands/absorb
Тут наверное нужна мораль...)
На первый взгляд подход git более последователен - выбрали лидера рынка, допилили, вернули в основную ветку, помогли opensource сообществу. Но с другой стороны git хоть и является стандартом, но не идеален. И Sapling решает ряд его проблем. Кто-то должен протаптывать новые тропы, пусть и ценой чуть большего беспорядка в своей инфраструктуре разработки
#git #vcs
Минутка истории. И разных подходов к работе с opensource.
1-я история. Жила была компания Microsoft, и в какой-то момент она "запустила" свою инфраструктуру разработки. Были выделены ресурсы для исправление этой ситуации. Один из примеров такой деятельность - перенос исходников в git, создание своего форка git, проверка его на GitHub и вливание форка в основную ветку git. Вот тут немного подробнее про доработку git под требования Microsoft - большой объем репозитория - https://habr.com/ru/articles/795635/
2-я история. Жила была компания Facebook, тогда еще не иноагент) Компания была молодая, но тоже уже столкнулась с проблемой хранения и организации код-ревью на большом объеме кода. Разработчики компании готовы innersource-ить, чтобы решить проблему. Постучались в git, получили отказ с формулировкой - это частный случай, для основной массы пользователей не нужно, делайте маленькие репозитории. Постучались в Mercurial - там ее pull request согласились принять. Перешли на Mercurial https://habr.com/ru/articles/798881 Но предположу, что часть разработчиков на этом не успокоилась и в результате появился Sapling https://sapling-scm.com/docs/introduction/differences-hg
Это новая Version Control System, которая может работать как со своим форматом repo, так и с git. При этом делает упор на частичное клонирование репо и работу с коммитами: быстрый откат, сохранение истории изменений при слиянии коммитов и даже https://sapling-scm.com/docs/commands/absorb
Тут наверное нужна мораль...)
На первый взгляд подход git более последователен - выбрали лидера рынка, допилили, вернули в основную ветку, помогли opensource сообществу. Но с другой стороны git хоть и является стандартом, но не идеален. И Sapling решает ряд его проблем. Кто-то должен протаптывать новые тропы, пусть и ценой чуть большего беспорядка в своей инфраструктуре разработки
#git #vcs
Хабр
Итак, вы думаете, что знаете Git? Часть третья: реально большие репозитории
Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является...
Всем привет!
Уже писал от проблеме внедрения новых технологий в enterprise компаниях https://t.me/javaKotlinDevOps/250
Два дополнения.
1) предлагаемое решение можно назвать технологическим стеком, но есть более распространенное «импортное» название - техрадар.
2) вот пример реальной компании, которая серьезно занялась этой проблемой https://habr.com/ru/companies/sbermarket/articles/645661/
Особенно хочу подчеркнуть принцип построения снизу-вверх, или поощряющая vs принуждающая система.
И идею, что техрадар может быть ориентиром для карьерного роста, он же план развития.
#arch #technology #techradar
Уже писал от проблеме внедрения новых технологий в enterprise компаниях https://t.me/javaKotlinDevOps/250
Два дополнения.
1) предлагаемое решение можно назвать технологическим стеком, но есть более распространенное «импортное» название - техрадар.
2) вот пример реальной компании, которая серьезно занялась этой проблемой https://habr.com/ru/companies/sbermarket/articles/645661/
Особенно хочу подчеркнуть принцип построения снизу-вверх, или поощряющая vs принуждающая система.
И идею, что техрадар может быть ориентиром для карьерного роста, он же план развития.
#arch #technology #techradar
Telegram
(java || kotlin) && devOps
Всем привет!
Есть такая проблема в больших компаниях, а-ка "кровавый enterprise" - сложность внедрения новых технологий.
Я про СУБД, в частности noSQL, брокеры сообщений, стриминговые платформы, системы мониторинга, DevOps pipeline, облачные решения и т.д.…
Есть такая проблема в больших компаниях, а-ка "кровавый enterprise" - сложность внедрения новых технологий.
Я про СУБД, в частности noSQL, брокеры сообщений, стриминговые платформы, системы мониторинга, DevOps pipeline, облачные решения и т.д.…
Всем привет!
Когда говорят о том, как необходимо учитывать требования информационной безопасности (ИБ) при разработке ПО часто забывают об одной проблеме.
Мир ИБ и мир разработки часто практически не пересекаются. Специалистов по ИБ нет в командах, разработчики и "безопасники" говорят на разном языке. Поверхность атаки, вектор атаки, SAST, DAST, OSS - для команды это что-то далекое, внешнее. Это плохо, но это факт. А встречаются эти два мира часто перед моментом выхода нового релиза на ПРОМ. Что тоже плохо.
Что же тут можно сделать?
1) базу про ИБ разработка должна знать, немного писал об этом тут https://t.me/javaKotlinDevOps/27
2) представители ИБ должны приходить в команды, в виде митапов, личных встреч, раннего ревью архитектуры, т.к. в любом случае именно они знают наиболее важные болевые точки
3) а так как мы живем в мире победившего Agile - требования ИБ тоже можно внедрять по Agile. Начиная с простых - технических, связанных с конкретными интеграциями и данными. Т.к. именно техническую стороны разработчики знают и могут контролировать. Подключая владельца продукта и специалиста ИБ, т.к. именно они должны знать, где потенциально могут быть наибольшие потери в финансовом и репутационном плане.
И по этому поводу есть хорошая статья, где процесс расписан по шагам https://habr.com/ru/companies/vk/articles/504062/
#security
Когда говорят о том, как необходимо учитывать требования информационной безопасности (ИБ) при разработке ПО часто забывают об одной проблеме.
Мир ИБ и мир разработки часто практически не пересекаются. Специалистов по ИБ нет в командах, разработчики и "безопасники" говорят на разном языке. Поверхность атаки, вектор атаки, SAST, DAST, OSS - для команды это что-то далекое, внешнее. Это плохо, но это факт. А встречаются эти два мира часто перед моментом выхода нового релиза на ПРОМ. Что тоже плохо.
Что же тут можно сделать?
1) базу про ИБ разработка должна знать, немного писал об этом тут https://t.me/javaKotlinDevOps/27
2) представители ИБ должны приходить в команды, в виде митапов, личных встреч, раннего ревью архитектуры, т.к. в любом случае именно они знают наиболее важные болевые точки
3) а так как мы живем в мире победившего Agile - требования ИБ тоже можно внедрять по Agile. Начиная с простых - технических, связанных с конкретными интеграциями и данными. Т.к. именно техническую стороны разработчики знают и могут контролировать. Подключая владельца продукта и специалиста ИБ, т.к. именно они должны знать, где потенциально могут быть наибольшие потери в финансовом и репутационном плане.
И по этому поводу есть хорошая статья, где процесс расписан по шагам https://habr.com/ru/companies/vk/articles/504062/
#security
Telegram
(java || kotlin) && devOps
Всем привет!
В предыдущем посте я упомянул про защиту от DOS аттак в коде. Раскрою тему.
Для начала стоит различать DDOS и DOS - (Distribted) Denial of Service.
Первый - это когда злоумышленник долбит миллионами запросов в секунду. Такое не выдержит ни один…
В предыдущем посте я упомянул про защиту от DOS аттак в коде. Раскрою тему.
Для начала стоит различать DDOS и DOS - (Distribted) Denial of Service.
Первый - это когда злоумышленник долбит миллионами запросов в секунду. Такое не выдержит ни один…
Всем привет!
Продолжим серию с тэгом #interview_question
Вот код:
@Service
public class MyService {
public void syncMethod() {
System.out.println("Synchronous method executed.");
asyncMethod();
}
@Async
public void asyncMethod() {
System.out.println("Async method executed.");
}
}
Что с ним не так?
Подсказка: @Async выполняет код в отдельном потоке.
Еще подсказка: магия Spring работает через proxy объекты. Из-за proxy объектов, к слову, магия ломается на финальных классах, в частности в Kotlin, без специальных настроек.
И последняя подсказка: вызов метода того же класса в Java работает через неявное указание this, и этот вызов идет через пул констант класса
https://ru.stackoverflow.com/questions/846457/Пул-констант-в-java
В общем код проблема в том, что asyncMethod будет вызван синхронно, как обычный метод того же класса, proxy код будет проигнорирован. Аналогичная проблема будет и с @Transactional. Проблема называется self execution.
Решений два:
1) простое и поэтому правильное - вызывать метод asyncMethod() из другого класса
2) сделать self injection - внедрить класс сам в себя. Выглядит странно, может сбить с толку, но наверняка может пригодится в отдельных случаях.
P.S. Еще один оффтопик. Код для поста я попросил сгененировать GigaChat и ChatGPT. Первый не справился, второй - справился, но с третьей попытки. И к тому же его пришлось почистить. Указание на название проблемы - self execution - не помогло, у обоих моделей без уточняющих подсказок выдается пример с рекурсивным вызовом асинхронного метода. В общем быстрее написать самому)
#interview_question #spring #java
Продолжим серию с тэгом #interview_question
Вот код:
@Service
public class MyService {
public void syncMethod() {
System.out.println("Synchronous method executed.");
asyncMethod();
}
@Async
public void asyncMethod() {
System.out.println("Async method executed.");
}
}
Что с ним не так?
Подсказка: @Async выполняет код в отдельном потоке.
Еще подсказка: магия Spring работает через proxy объекты. Из-за proxy объектов, к слову, магия ломается на финальных классах, в частности в Kotlin, без специальных настроек.
И последняя подсказка: вызов метода того же класса в Java работает через неявное указание this, и этот вызов идет через пул констант класса
https://ru.stackoverflow.com/questions/846457/Пул-констант-в-java
В общем код проблема в том, что asyncMethod будет вызван синхронно, как обычный метод того же класса, proxy код будет проигнорирован. Аналогичная проблема будет и с @Transactional. Проблема называется self execution.
Решений два:
1) простое и поэтому правильное - вызывать метод asyncMethod() из другого класса
2) сделать self injection - внедрить класс сам в себя. Выглядит странно, может сбить с толку, но наверняка может пригодится в отдельных случаях.
P.S. Еще один оффтопик. Код для поста я попросил сгененировать GigaChat и ChatGPT. Первый не справился, второй - справился, но с третьей попытки. И к тому же его пришлось почистить. Указание на название проблемы - self execution - не помогло, у обоих моделей без уточняющих подсказок выдается пример с рекурсивным вызовом асинхронного метода. В общем быстрее написать самому)
#interview_question #spring #java
Stack Overflow на русском
Пул констант в Java
Не раз слышал о так называемом пуле констант в языке программирования Java. Знаю о пуле объектов типа String, пуле для типов Byte, Short, Character, Integer, Long и даже Boolean.
Также знаю, что мы...
Также знаю, что мы...
И снова здравствуйте)
Вчера произошло знаменательное событие для этого блога - первые 100 подписчиков. Просить голоса не буду, не представляю, что с ними делать. Ну не сторисы же записывать?)))
Сделаю по-другому - пишите в личку или в комменты вопросы\проблемы, которые было бы интересно обсудить. По первым трем, по которым мне есть что сказать, сделаю посты.
#blog
Вчера произошло знаменательное событие для этого блога - первые 100 подписчиков. Просить голоса не буду, не представляю, что с ними делать. Ну не сторисы же записывать?)))
Сделаю по-другому - пишите в личку или в комменты вопросы\проблемы, которые было бы интересно обсудить. По первым трем, по которым мне есть что сказать, сделаю посты.
#blog
Всем привет!
В продолжение вчерашней темы про магию аннотаций Spring - статья про то, чем различаются @Async и @Scheduled под капотом
https://habr.com/ru/articles/771112/
И почему их может иметь смысл использовать вместе.
И та, и другая аннотация приводит к выполнению кода в отдельном потоке. Вопрос только в том, сколько таких потоков?
@Async по умолчанию создает новый поток.
А все @Scheduled - работают в одном потоке.
Как правильно? Правильно управлять потоками явно, через явное указание пула потоков в обоих случаях.
P.S. Вообще управлять явно, не полагаясь на значения по умолчанию, часто является правильной стратегией. Потоки, таймауты, квоты, кодировки, таймзоны, версии библиотек и образов ...
#spring #spring_magic #multithreading
В продолжение вчерашней темы про магию аннотаций Spring - статья про то, чем различаются @Async и @Scheduled под капотом
https://habr.com/ru/articles/771112/
И почему их может иметь смысл использовать вместе.
И та, и другая аннотация приводит к выполнению кода в отдельном потоке. Вопрос только в том, сколько таких потоков?
@Async по умолчанию создает новый поток.
А все @Scheduled - работают в одном потоке.
Как правильно? Правильно управлять потоками явно, через явное указание пула потоков в обоих случаях.
P.S. Вообще управлять явно, не полагаясь на значения по умолчанию, часто является правильной стратегией. Потоки, таймауты, квоты, кодировки, таймзоны, версии библиотек и образов ...
#spring #spring_magic #multithreading
Хабр
@Scheduled + @Async (в Spring Boot)
Недавно отвечал на вопрос почему аннотации @Scheduled и @Async иногда используют вместе, данный вопрос попался человеку на собеседовании. Многие начинающие разработчики на java не до конца понимают в...
Всем привет!
Недавно вышла 22-я Java. Обычная, не LTS версия.
Вот неплохой обзор нововведений https://habr.com/ru/articles/801467/
Что могу отметить: из 12 JEP - больших фичей Java по сути - по которым велась работа в релизе, 7 появились в предыдущих версиях. Т.е фиксят и рефакторят.
Что же появилось интересного из новых фичей?
Launch Multi-File Source-Code Programs (JEP 458) - возможность быстрого запуска из командной строки без сборки в jar для кода, разбросанного по нескольким файлам. Запускать код из одного файла можно было и ранее.
Вместе с появившимся в 21 Java Implicitly Declared Classes and Instance Main Methods (Second Preview) (JEP 463) - запуск кода из простого метода main без параметров и без класса - видна тенденция упростить вкатывание новичков в Java, сделать его похожим на тот же Python.
Stream Gatherers (Preview) (JEP 461) - если раньше для стримов можно было писать свои коллекторы, то сейчас можно будет и gatherer - промежуточные операции. Кажется интересная тема, открывает возможности для большого расширения возможностей стримов. Странно, что ждали 14 версий)
Class-File API (Preview) (JEP 457) - если раньше для работы с байт-кодом использовались сторонние библиотеки, одна из которых - ASM - была первой среди равных, т.к. поставлялась с JDK, то сейчас сделали ее аналог уже в составе JDK. Цель - чтобы изменения в API Java и в API для работы с байт-кодом были синхронизированы. Тоже в общем-то вполне логичная фича.
Ну и еще одна мелкая фича, появление как я подозреваю которой приведет к тому, что появятся новые головоломные задачки на собесах. Statements before super(...) (Preview) (JEP 447) - как следует из названия в конструкторах можно писать код перед вызовом super(), но не любой, а только не нарушающий порядок инициализации класса. Это вам не Spring, никаких проксей) Т.е. код в прологе не должен ссылаться на конструируемый объект, включая поля из суперкласса и на экземпляры внутреннего класса.
P.S. Да, все еще идут споры по String Templates, про которые я писал ранее https://t.me/javaKotlinDevOps/246 Делать их расширяемыми или как у всех) В 22-й Java пока оставили как было
#java #java_new_version #interview_question
Недавно вышла 22-я Java. Обычная, не LTS версия.
Вот неплохой обзор нововведений https://habr.com/ru/articles/801467/
Что могу отметить: из 12 JEP - больших фичей Java по сути - по которым велась работа в релизе, 7 появились в предыдущих версиях. Т.е фиксят и рефакторят.
Что же появилось интересного из новых фичей?
Launch Multi-File Source-Code Programs (JEP 458) - возможность быстрого запуска из командной строки без сборки в jar для кода, разбросанного по нескольким файлам. Запускать код из одного файла можно было и ранее.
Вместе с появившимся в 21 Java Implicitly Declared Classes and Instance Main Methods (Second Preview) (JEP 463) - запуск кода из простого метода main без параметров и без класса - видна тенденция упростить вкатывание новичков в Java, сделать его похожим на тот же Python.
Stream Gatherers (Preview) (JEP 461) - если раньше для стримов можно было писать свои коллекторы, то сейчас можно будет и gatherer - промежуточные операции. Кажется интересная тема, открывает возможности для большого расширения возможностей стримов. Странно, что ждали 14 версий)
Class-File API (Preview) (JEP 457) - если раньше для работы с байт-кодом использовались сторонние библиотеки, одна из которых - ASM - была первой среди равных, т.к. поставлялась с JDK, то сейчас сделали ее аналог уже в составе JDK. Цель - чтобы изменения в API Java и в API для работы с байт-кодом были синхронизированы. Тоже в общем-то вполне логичная фича.
Ну и еще одна мелкая фича, появление как я подозреваю которой приведет к тому, что появятся новые головоломные задачки на собесах. Statements before super(...) (Preview) (JEP 447) - как следует из названия в конструкторах можно писать код перед вызовом super(), но не любой, а только не нарушающий порядок инициализации класса. Это вам не Spring, никаких проксей) Т.е. код в прологе не должен ссылаться на конструируемый объект, включая поля из суперкласса и на экземпляры внутреннего класса.
P.S. Да, все еще идут споры по String Templates, про которые я писал ранее https://t.me/javaKotlinDevOps/246 Делать их расширяемыми или как у всех) В 22-й Java пока оставили как было
#java #java_new_version #interview_question
Хабр
Вышла Java 22
Вышла общедоступная версия Java 22 . В этот релиз попало около 2300 закрытых задач и 12 JEP'ов . Release Notes можно посмотреть здесь . Полный список изменений API – здесь . Java 22 не является...
Всем привет!
Небольшая ремарка по использованию ChatGPT и аналогов.
На мой взгляд самая большая проблема с ними возникает не тогда, когда они генерируют ерунду - это сразу видно.
Ну например, отсутствующие классы или методы. Такой код или сразу отбрасывается, или благодаря подсказкам IDE дописывается.
Плохо, когда генерируемый код похож на правильный. Даже очень похож. Тогда ты принимаешь рекомендацию, мысленно помечаешь задачу как выполненную и пытаешься идти дальше. А приложение падает в неожиданном месте. Пример из моей практики - сгенерированная командная строка. Выглядит как настоящая, отличается одним отсутствующим пробелом. Такие же проблемы возможны с RegExp.
Да, часто проблема решается тестами. Но есть тривиальный код, который с одной стороны не хочется писать самому, т.к. он тривиальный, а с другой стороны он часто покрывается не модульными, а интеграционными тестами. А condition coverage у интеграционных тестов по понятным причинам хуже, чем у модульных.
Можно ли решить эту проблему - не уверен. Суть работы LLM в том, что они дают не точный ответ, а выведенный из данных модели под конкретный контекст. Поэтому добавление второй модели, которая будет проверять ответы первой, кажется не поможет. Добавлять валидаторы ответа - потребуется очень много валидаторов...
#llm
Небольшая ремарка по использованию ChatGPT и аналогов.
На мой взгляд самая большая проблема с ними возникает не тогда, когда они генерируют ерунду - это сразу видно.
Ну например, отсутствующие классы или методы. Такой код или сразу отбрасывается, или благодаря подсказкам IDE дописывается.
Плохо, когда генерируемый код похож на правильный. Даже очень похож. Тогда ты принимаешь рекомендацию, мысленно помечаешь задачу как выполненную и пытаешься идти дальше. А приложение падает в неожиданном месте. Пример из моей практики - сгенерированная командная строка. Выглядит как настоящая, отличается одним отсутствующим пробелом. Такие же проблемы возможны с RegExp.
Да, часто проблема решается тестами. Но есть тривиальный код, который с одной стороны не хочется писать самому, т.к. он тривиальный, а с другой стороны он часто покрывается не модульными, а интеграционными тестами. А condition coverage у интеграционных тестов по понятным причинам хуже, чем у модульных.
Можно ли решить эту проблему - не уверен. Суть работы LLM в том, что они дают не точный ответ, а выведенный из данных модели под конкретный контекст. Поэтому добавление второй модели, которая будет проверять ответы первой, кажется не поможет. Добавлять валидаторы ответа - потребуется очень много валидаторов...
#llm
Всем привет!
Я уже не раз говорил и повторю еще раз - мир Java хорош своей огромной базой opensource библиотек на все случаи жизни.
Даже для работы с LLM (ChatGPT) уже библиотеки появляются https://t.me/javaKotlinDevOps/241
И для прочего Machine Learning тоже https://t.me/javaKotlinDevOps/142
А еще на Java можно писать Telegram боты https://www.baeldung.com/spring-boot-telegram-bot
#java #libraries
Я уже не раз говорил и повторю еще раз - мир Java хорош своей огромной базой opensource библиотек на все случаи жизни.
Даже для работы с LLM (ChatGPT) уже библиотеки появляются https://t.me/javaKotlinDevOps/241
И для прочего Machine Learning тоже https://t.me/javaKotlinDevOps/142
А еще на Java можно писать Telegram боты https://www.baeldung.com/spring-boot-telegram-bot
#java #libraries
Telegram
(java || kotlin) && devOps
Всем привет в новом году!
Предположу - многие знают о том, что для Data Science, ML, DL, AI в основном используют Python. Я уже подымал эту тему тут https://t.me/javaKotlinDevOps/142
Хотел бы подчеркнуть важность экосистемы - в Python было создано так много…
Предположу - многие знают о том, что для Data Science, ML, DL, AI в основном используют Python. Я уже подымал эту тему тут https://t.me/javaKotlinDevOps/142
Хотел бы подчеркнуть важность экосистемы - в Python было создано так много…
Всем привет!
Насколько сложнее разрабатывать монолит? В каком коде больше ошибок - микросервисном или монолитном? Частная проблема в ИТ - не количественных оценок, вместо этого есть экспертное мнение. Но не все так плохо, какие-то данные все же есть. Причём в классике, Макконнел Совершенный код.
Вот график типичной плотности ошибок в проекте в зависимости от числа строк кода. Синий — максимальное, красный — среднее, зелёный — наименьшее количество.
http://www.viva64.com/external-pictures/habr103/image2.png
Детали тут https://habr.com/ru/companies/pvs-studio/articles/150539
#monolith #statistics
Насколько сложнее разрабатывать монолит? В каком коде больше ошибок - микросервисном или монолитном? Частная проблема в ИТ - не количественных оценок, вместо этого есть экспертное мнение. Но не все так плохо, какие-то данные все же есть. Причём в классике, Макконнел Совершенный код.
Вот график типичной плотности ошибок в проекте в зависимости от числа строк кода. Синий — максимальное, красный — среднее, зелёный — наименьшее количество.
http://www.viva64.com/external-pictures/habr103/image2.png
Детали тут https://habr.com/ru/companies/pvs-studio/articles/150539
#monolith #statistics
Хабр
Ощущения, которые подтвердились числами
Долгое время меня беспокоили статьи в интернете, в которых делалась попытка на основе проверки небольших проектов, судить о пользе использования статических анализаторов кода. Во многих из прочитанных...
Всем привет!
Нашел интересный антипаттерн, о котором ранее не задумывался. Coding By Exception - кодирование через исключения, не знаю как лучше перевести.
Суть в том, что под каждую ошибку заводится отдельное исключение. Почему это плохо?
1) В случае проверяемых исключений понятно - сигнатуры методов не "загрязняются", появляется искушение написать throws Exception.
2) Но ничуть не лучше ситуация в случае непроверяемых исключений. Для обработки исключений все равно приходится писать код. Чем больше исключений - чем больше количество такого кода. А если обработка единообразная для группы исключений возникает вопрос - а точно ли их надо разделять? Исключения хоть и должны быть свои, кастомные, но они должны охватывать какие-то типовые ошибки, а не каждую конкретную ошибку.
3) Если при любой ошибке бросать исключение - это может сказаться на производительности
4) Если при любой ошибке бросать исключение - это по сути goto программирование - переход в произвольное место кода. А goto - это "матерый" антипаттерн)))
#antipatterns
Нашел интересный антипаттерн, о котором ранее не задумывался. Coding By Exception - кодирование через исключения, не знаю как лучше перевести.
Суть в том, что под каждую ошибку заводится отдельное исключение. Почему это плохо?
1) В случае проверяемых исключений понятно - сигнатуры методов не "загрязняются", появляется искушение написать throws Exception.
2) Но ничуть не лучше ситуация в случае непроверяемых исключений. Для обработки исключений все равно приходится писать код. Чем больше исключений - чем больше количество такого кода. А если обработка единообразная для группы исключений возникает вопрос - а точно ли их надо разделять? Исключения хоть и должны быть свои, кастомные, но они должны охватывать какие-то типовые ошибки, а не каждую конкретную ошибку.
3) Если при любой ошибке бросать исключение - это может сказаться на производительности
4) Если при любой ошибке бросать исключение - это по сути goto программирование - переход в произвольное место кода. А goto - это "матерый" антипаттерн)))
#antipatterns
Всем привет!
Недавно вышла новая версия IDEA - 2024.1. В новой версии появилось много "вкусного", вот что я бы отметил:
1) если раньше аналог Copylot (Gigacode) был доступен только по отдельной подписке, и при этом сильно уступал Copylot, то сейчас в Ultimate появился "бесплатный" AutoCompletion. Проверил: в моем случае, предлагает компилируемый код, но требующий правок) Вообще вижу тенденцию, что часть изначально платных LLM инструментов становятся бесплатными - ChatGPT4, IDEA AI. В случае Microsoft - они просто делятся машинным временем для популяризации инструмента, в случае IDEA - работает локальная модель, которой как контекст подается код открытого проекта.
2) IntelliJ в курсе проблемы долгой инициализации проекта... ремарка - еще бы они не были в курсе, такое сложно не заметить) ... и сделала доступной ряд фич IDE во время инициализации. Плюс сейчас происходит быстрый парсинг maven pom, и на основе полученной информации становится доступной навигация по проекту пока идет индексация.
3) ряд улучшений по работе с логами:
- AutoCompletion кода для инициализации логгера, если в классе ее еще нет
- как альтернатива возможна автогенерация этого кода
- парсинг логов на предмет наличия там классов проекта.
Что я бы отдельно отметил на примере этой и предыдущей фичи - комплексный подход. Берем все (заведенные тикеты), что можем улучшить по теме - и улучшаем)
4) новая консоль. Главные фичи - снова AutoCompletion и разбиение единого полотна текста на команды, что облегчает их копирование. В будущем обещают улучшение AutoCompletion и даже подсказки по ошибкам. Видимо с использованием LLM. Жаль, пока работает только на bash и PowerShell, но думаю тоже доделают.
5) sticky режим при прокрутке больших файлов. Т.е. всегда видны декларация класса и текущего метода каким бы большим не был метод. Число видимых строк настраивается. Напомнило мне "хлебные крошки" на сайтах. Большие классы и методы конечно же зло, но это зло существует)
6) куча улучшение по работе с Pull request - можно ревьювить их в IDEA, в т.ч. смотреть diff, писать комментарии, смотреть статус prCheck и даже ставить лайки) К сожалению только GitHub и GitLab.
7) для самого частого рефакторинга - переименование - сделали inline режим: не надо вызывать команду по шорткату или меню - просто переименовываешь сущность, а IDEA сама предложит переименовать ее по всему проекту
8) появилась поддержка OpenRewrite - фреймворка для написания рефакторингов, если встроенные не устраивают. https://t.me/javaKotlinDevOps/116 Правильный подход, я считаю
9) и наконец на первый взгляд незаметная фича - альфа тестирование нового компилятора Kotlin K2. Казалось бы - ну и ладно, заменили компилятор, при чем тут IDE. А штука в том, что ребята специально переписали свой компилятор, чтобы его удобнее было использовать для фич IDEA - сделать то, что раньше не получалось и ускорить работу IDE. Т.е во-первых, интересен тот факт, что для подсветки синтаксиса, AutoCompletion и т.д используется компилятор, а во-вторых - удобно быть и разработчиком IDE, и разработчиком языка) Более этого, это было одной из причин разработки этого языка - https://t.me/javaKotlinDevOps/38
Вот пожалуй и все, что запомнилось.
#idea #kotlin
Недавно вышла новая версия IDEA - 2024.1. В новой версии появилось много "вкусного", вот что я бы отметил:
1) если раньше аналог Copylot (Gigacode) был доступен только по отдельной подписке, и при этом сильно уступал Copylot, то сейчас в Ultimate появился "бесплатный" AutoCompletion. Проверил: в моем случае, предлагает компилируемый код, но требующий правок) Вообще вижу тенденцию, что часть изначально платных LLM инструментов становятся бесплатными - ChatGPT4, IDEA AI. В случае Microsoft - они просто делятся машинным временем для популяризации инструмента, в случае IDEA - работает локальная модель, которой как контекст подается код открытого проекта.
2) IntelliJ в курсе проблемы долгой инициализации проекта... ремарка - еще бы они не были в курсе, такое сложно не заметить) ... и сделала доступной ряд фич IDE во время инициализации. Плюс сейчас происходит быстрый парсинг maven pom, и на основе полученной информации становится доступной навигация по проекту пока идет индексация.
3) ряд улучшений по работе с логами:
- AutoCompletion кода для инициализации логгера, если в классе ее еще нет
- как альтернатива возможна автогенерация этого кода
- парсинг логов на предмет наличия там классов проекта.
Что я бы отдельно отметил на примере этой и предыдущей фичи - комплексный подход. Берем все (заведенные тикеты), что можем улучшить по теме - и улучшаем)
4) новая консоль. Главные фичи - снова AutoCompletion и разбиение единого полотна текста на команды, что облегчает их копирование. В будущем обещают улучшение AutoCompletion и даже подсказки по ошибкам. Видимо с использованием LLM. Жаль, пока работает только на bash и PowerShell, но думаю тоже доделают.
5) sticky режим при прокрутке больших файлов. Т.е. всегда видны декларация класса и текущего метода каким бы большим не был метод. Число видимых строк настраивается. Напомнило мне "хлебные крошки" на сайтах. Большие классы и методы конечно же зло, но это зло существует)
6) куча улучшение по работе с Pull request - можно ревьювить их в IDEA, в т.ч. смотреть diff, писать комментарии, смотреть статус prCheck и даже ставить лайки) К сожалению только GitHub и GitLab.
7) для самого частого рефакторинга - переименование - сделали inline режим: не надо вызывать команду по шорткату или меню - просто переименовываешь сущность, а IDEA сама предложит переименовать ее по всему проекту
8) появилась поддержка OpenRewrite - фреймворка для написания рефакторингов, если встроенные не устраивают. https://t.me/javaKotlinDevOps/116 Правильный подход, я считаю
9) и наконец на первый взгляд незаметная фича - альфа тестирование нового компилятора Kotlin K2. Казалось бы - ну и ладно, заменили компилятор, при чем тут IDE. А штука в том, что ребята специально переписали свой компилятор, чтобы его удобнее было использовать для фич IDEA - сделать то, что раньше не получалось и ускорить работу IDE. Т.е во-первых, интересен тот факт, что для подсветки синтаксиса, AutoCompletion и т.д используется компилятор, а во-вторых - удобно быть и разработчиком IDE, и разработчиком языка) Более этого, это было одной из причин разработки этого языка - https://t.me/javaKotlinDevOps/38
Вот пожалуй и все, что запомнилось.
#idea #kotlin
Telegram
(java || kotlin) && devOps
Всем привет!
Иногда проект нужно мигрировать - перейти на новую версию платформы, фреймворк, новый формат конфигов. Для преобразований XML есть XSLT. Для JSON - целый зоопарк тулов - https://stackoverflow.com/questions/1618038/xslt-equivalent-for-json
А…
Иногда проект нужно мигрировать - перейти на новую версию платформы, фреймворк, новый формат конфигов. Для преобразований XML есть XSLT. Для JSON - целый зоопарк тулов - https://stackoverflow.com/questions/1618038/xslt-equivalent-for-json
А…
Всем привет!
Увидел интересное мнение по системам low code. Я о BPM движках, Pega и тому подобных системах, которые предлагают разработку путем создания квадратиков из библиотеки готовых компонент и соединения их стрелочками. Мнение полностью совпадает с моим опытом.
Так вот - 80% задачи такая система вам решит. Возможно) Но на оставшиеся 20% вы потратите кучу времени, причем времени разработчиков. А то, что получится в итоге, будет содержать ряд компромиссов, и поэтому будет хуже, чем разработанное с нуля решение)
#low_code
Увидел интересное мнение по системам low code. Я о BPM движках, Pega и тому подобных системах, которые предлагают разработку путем создания квадратиков из библиотеки готовых компонент и соединения их стрелочками. Мнение полностью совпадает с моим опытом.
Так вот - 80% задачи такая система вам решит. Возможно) Но на оставшиеся 20% вы потратите кучу времени, причем времени разработчиков. А то, что получится в итоге, будет содержать ряд компромиссов, и поэтому будет хуже, чем разработанное с нуля решение)
#low_code
Всем привет!
Что ж, появилась первая книжка про ChatGPT для разработчиков на русском.
https://www.piter.com/collection/all/product/razrabotka-prilozheniy-na-baze-gpt-4-i-chatgpt
С почином!
Книжка небольшая, 180 страниц, про основы LLM и работу с API ChatGPT.
Я купил, буду изучать.
P.S. Python конечно же)
P.P.S. На Хабре издательство Питер выкладывает статью про каждую книгу с промокодом. https://habr.com/ru/companies/piter/articles/807039/
#llm #chatgpt
Что ж, появилась первая книжка про ChatGPT для разработчиков на русском.
https://www.piter.com/collection/all/product/razrabotka-prilozheniy-na-baze-gpt-4-i-chatgpt
С почином!
Книжка небольшая, 180 страниц, про основы LLM и работу с API ChatGPT.
Я купил, буду изучать.
P.S. Python конечно же)
P.P.S. На Хабре издательство Питер выкладывает статью про каждую книгу с промокодом. https://habr.com/ru/companies/piter/articles/807039/
#llm #chatgpt
www.piter.com
Разработка приложений на базе GPT-4 и ChatGPT
Разработка приложений с помощью GPT-4 и ChatGPT.
Всем привет!
Небольшой пост из серии "хозяйке на заметку")
Можно ли слить в git 2 проекта, не имеющих общей истории?
Первый вопрос, который тут возникает - а зачем???
Но похоже иногда такая потребность есть, потому что у git merge есть опция --allow-unrelated-histories.
Можно предположить, что такая опция может понадобится если проект начал разрабатываться 2 людьми, при этом забыли сделать общий первый commit. Или были жесткие rewrite-ы)
#git #tricks
Небольшой пост из серии "хозяйке на заметку")
Можно ли слить в git 2 проекта, не имеющих общей истории?
Первый вопрос, который тут возникает - а зачем???
Но похоже иногда такая потребность есть, потому что у git merge есть опция --allow-unrelated-histories.
Можно предположить, что такая опция может понадобится если проект начал разрабатываться 2 людьми, при этом забыли сделать общий первый commit. Или были жесткие rewrite-ы)
#git #tricks
Всем привет!
Я уже поднимал тему интеграции микросервисов через Java API - https://t.me/javaKotlinDevOps/208
Напомню, основная проблема там, что Java API - это по сути DTO-шки, пусть даже и выделенные в отдельную библиотеку. Поэтому легко начать считать частью своего кода, после чего забыть про их своевременное обновление и поймать ошибку уже на поздних этапах интеграции.
Что же тут можно сделать?
1) monorepo. Подходит в случае, если микросервисы разрабатываются одной командой или в организации принята практика монорепозитория. Да, конечно же нужно хорошее покрытие интеграционными тестами, запускаемое на prcheck. Если оно есть, то изменения подтянутся на очередном pull-е. И в любом случае изменения, ломающие обратную совместимость, требуют отдельной процедуры вливания. Но правила работы с такими изменениями должны быть прописаны в monorepo. Впрочем это справедливо для всех вариантов синхронизации.
2) "партнерство". Взял в кавычки, т.к. требуется расшифровка. Назовем так паттерн, когда все команды, использующие Java API тесно взаимодействуют, ответственно подходят к версионированию API и своевременно оповещают друг друга об изменениях. Если надо - синхронизируют релизные циклы, хотя это крайний случай. Синхронизация релизов в общем случае - антипаттерн, но бывают исключения
3) подключение внешних зависимостей с version range для минорных версий. В Maven это выглядит вот так
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-utils</artifactId>
<version>[1.0, 2.0)</version>
</dependency>
Тут разрешается брать все версии между 1.0 <= x < 2.0
Просто убирать версию не стоит, т.к. изменение major - это как правило поломка обратной совместимости.
Детали тут https://maven.apache.org/pom.html#dependency-version-requirement-specification
Gradle поддерживает похожий синтаксис
implementation('org.slf4j:slf4j-api') {
version {
strictly '[1.0, 2.0['
}
Детали https://docs.gradle.org/current/userguide/single_versions.html
Данный вариант хорошо подходит для случая, когда ваша команда - это потребитель сервиса, изменения вносятся на другой стороне.
Подводный камень - безопасники не любят wildcard версии зависимостей. Но кажется, что тут их можно уломать, т.к.
а) зависимость внутренняя
б) у нас не чистый wildcard, а version range.
4) git submodule - возможность в родительский репозиторий подключать подмодули, подтягиваемые из других репозиториев. Все библиотеки с Java API подключаются как подмодули. Детали тут https://git-scm.com/book/ru/v2/Инструменты-Git-Подмодули
Позволяет вносить изменение в общее API всем командам, работающим с ним.
Но у данного способа есть ряд подводных камней.
Все обычные команды:
git clone
git pull
git push
git checkout
некорректно работают с подмодулями. Точнее их игнорируют.
При этом для каждой такой команды есть или "волшебный" ключик командной строки, подключающий поддержку подмодулей, или отдельная команда для подмодулей.
Плюс у git есть возможность задавать алиасы - т.е. на эти команды можно повестить алиасы, и вызвать, например, не git push, а git push_with_submodule. Или лучше git pushs. А для действий, требующих указания ключей, можно через git config включить эти ключи в режиме по умолчанию на вашей рабочей станции. Если все это настроить и не забывать применять алиасы - все будет работать как часы. Главное не забывать)))
Я уже поднимал тему интеграции микросервисов через Java API - https://t.me/javaKotlinDevOps/208
Напомню, основная проблема там, что Java API - это по сути DTO-шки, пусть даже и выделенные в отдельную библиотеку. Поэтому легко начать считать частью своего кода, после чего забыть про их своевременное обновление и поймать ошибку уже на поздних этапах интеграции.
Что же тут можно сделать?
1) monorepo. Подходит в случае, если микросервисы разрабатываются одной командой или в организации принята практика монорепозитория. Да, конечно же нужно хорошее покрытие интеграционными тестами, запускаемое на prcheck. Если оно есть, то изменения подтянутся на очередном pull-е. И в любом случае изменения, ломающие обратную совместимость, требуют отдельной процедуры вливания. Но правила работы с такими изменениями должны быть прописаны в monorepo. Впрочем это справедливо для всех вариантов синхронизации.
2) "партнерство". Взял в кавычки, т.к. требуется расшифровка. Назовем так паттерн, когда все команды, использующие Java API тесно взаимодействуют, ответственно подходят к версионированию API и своевременно оповещают друг друга об изменениях. Если надо - синхронизируют релизные циклы, хотя это крайний случай. Синхронизация релизов в общем случае - антипаттерн, но бывают исключения
3) подключение внешних зависимостей с version range для минорных версий. В Maven это выглядит вот так
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-utils</artifactId>
<version>[1.0, 2.0)</version>
</dependency>
Тут разрешается брать все версии между 1.0 <= x < 2.0
Просто убирать версию не стоит, т.к. изменение major - это как правило поломка обратной совместимости.
Детали тут https://maven.apache.org/pom.html#dependency-version-requirement-specification
Gradle поддерживает похожий синтаксис
implementation('org.slf4j:slf4j-api') {
version {
strictly '[1.0, 2.0['
}
Детали https://docs.gradle.org/current/userguide/single_versions.html
Данный вариант хорошо подходит для случая, когда ваша команда - это потребитель сервиса, изменения вносятся на другой стороне.
Подводный камень - безопасники не любят wildcard версии зависимостей. Но кажется, что тут их можно уломать, т.к.
а) зависимость внутренняя
б) у нас не чистый wildcard, а version range.
4) git submodule - возможность в родительский репозиторий подключать подмодули, подтягиваемые из других репозиториев. Все библиотеки с Java API подключаются как подмодули. Детали тут https://git-scm.com/book/ru/v2/Инструменты-Git-Подмодули
Позволяет вносить изменение в общее API всем командам, работающим с ним.
Но у данного способа есть ряд подводных камней.
Все обычные команды:
git clone
git pull
git push
git checkout
некорректно работают с подмодулями. Точнее их игнорируют.
При этом для каждой такой команды есть или "волшебный" ключик командной строки, подключающий поддержку подмодулей, или отдельная команда для подмодулей.
Плюс у git есть возможность задавать алиасы - т.е. на эти команды можно повестить алиасы, и вызвать, например, не git push, а git push_with_submodule. Или лучше git pushs. А для действий, требующих указания ключей, можно через git config включить эти ключи в режиме по умолчанию на вашей рабочей станции. Если все это настроить и не забывать применять алиасы - все будет работать как часы. Главное не забывать)))
Примерный набор команд:
git config submodule.recurse true # добавляет ключ --recurse-submodules ко всем командам кроме clone. В частности checkout и pull
git config diff.submodule log # отображать также изменения в подмодулях при выполнении diff в корне
git config alias.clones 'clone --recurse-submodules' # подтягивать подмодули при клонировании
git config alias.diffs '!'"git diff && git submodule foreach 'git diff'" # показать изменения по всем подмодулям
git config alias.pushs 'push --recurse-submodules=on-demand' # запушить изменения вначале в подмодулях, потом в основной проект
git config alias.updates 'submodule update --remote --merge' # подтянуть изменения подмодулей из удаленных репозиториев и влить их в локальную копию. После этого можно самому вносить изменения в подмодуль
В любом случае предлагаю прочитать статью по ссылке выше.
#git #api #integraion
git config submodule.recurse true # добавляет ключ --recurse-submodules ко всем командам кроме clone. В частности checkout и pull
git config diff.submodule log # отображать также изменения в подмодулях при выполнении diff в корне
git config alias.clones 'clone --recurse-submodules' # подтягивать подмодули при клонировании
git config alias.diffs '!'"git diff && git submodule foreach 'git diff'" # показать изменения по всем подмодулям
git config alias.pushs 'push --recurse-submodules=on-demand' # запушить изменения вначале в подмодулях, потом в основной проект
git config alias.updates 'submodule update --remote --merge' # подтянуть изменения подмодулей из удаленных репозиториев и влить их в локальную копию. После этого можно самому вносить изменения в подмодуль
В любом случае предлагаю прочитать статью по ссылке выше.
#git #api #integraion
Telegram
(java || kotlin) && devOps
Всем привет!
Прочитал статью о том, как можно обойтись без OpenAPI при взаимодействии по REST API https://habr.com/ru/companies/magnit/articles/763952
Для тех кому лень читать - там предлагается использовать Java DTO. В целом подход интересный и рабочий.…
Прочитал статью о том, как можно обойтись без OpenAPI при взаимодействии по REST API https://habr.com/ru/companies/magnit/articles/763952
Для тех кому лень читать - там предлагается использовать Java DTO. В целом подход интересный и рабочий.…
Всем привет!
Интересная статья с опросом разработчиков https://habr.com/ru/articles/797045/
Что хотелось бы сказать по итогу прочтения.
Тему зарплат я обсуждать не готов, это слишком сложно)
То, что именно джуны склонны приукрашивать свое резюме - ожидаемо.
Процент девушек в ИТ - ну да, ну да, все грустно.
Тот, факт, что в ИТ проходят без профильного высшего образования (или образование было профильным, но преподавали не то) - тоже понятен. Зато с техническим, что тоже понятно.
Интересно то, что таких людей становится больше. Я честно говоря, думал наоборот. Вроде ИТ кафедр больше, чем лет 10-15-20 назад ...
Видимо работает тренд "Войти в ИТ".
Что еще интересно - в более 50% случаев люди, пришедшие после курсов, без опыта, сумели влиться в команду.
Ну и самое интересное - оценка полезности курсов.
Яндекс Практикум - ок.
Хекслет и Karpov.Courses - не слышал, надо бы глянуть.
По крайней мере теперь понятно, куда направлять тех, кто хочет войти в ИТ)
#learning #it
Интересная статья с опросом разработчиков https://habr.com/ru/articles/797045/
Что хотелось бы сказать по итогу прочтения.
Тему зарплат я обсуждать не готов, это слишком сложно)
То, что именно джуны склонны приукрашивать свое резюме - ожидаемо.
Процент девушек в ИТ - ну да, ну да, все грустно.
Тот, факт, что в ИТ проходят без профильного высшего образования (или образование было профильным, но преподавали не то) - тоже понятен. Зато с техническим, что тоже понятно.
Интересно то, что таких людей становится больше. Я честно говоря, думал наоборот. Вроде ИТ кафедр больше, чем лет 10-15-20 назад ...
Видимо работает тренд "Войти в ИТ".
Что еще интересно - в более 50% случаев люди, пришедшие после курсов, без опыта, сумели влиться в команду.
Ну и самое интересное - оценка полезности курсов.
Яндекс Практикум - ок.
Хекслет и Karpov.Courses - не слышал, надо бы глянуть.
По крайней мере теперь понятно, куда направлять тех, кто хочет войти в ИТ)
#learning #it
Хабр
Опросил больше 1000 айтишников: вранье в резюме и котируемость курсов по «вкатыванию в IT»
Получилось отследить довольно интересные тренды: как размер стажа в индустрии коррелирует с отношением к выдумыванию опыта в резюме, как в IT-среде на самом деле относятся к выпускникам школ в стиле...
Всем привет!
Периодически на работе приходится сталкиваться с задачей подключения той или иной платформенной компоненты. Платформа у нас большая, компонент много.
С подключением обычно два вида сложностей:
1) изучить кукбук, подключить правильные зависимости и сделать правильные настройки) Зависимости - это очевидно для разработки, а вот настройки - далеко не всегда.
2) административка: завести заявку на подключение - в JIRA, Confluence или даже по почте. Вот это совсем не интуитивно, а ошибки, связанные с отсутствием заявки сложно отлаживать. Оправдывают такой процесс обычно так:
а) что новый потребитель - это дополнительная нагрузка, ее нужно запланировать.
б) требованиями безопасности.
в) просто считается, что это нормально
А хуже, если заявки придется делать на каждый используемый стенд.
Что в итоге? Мыши колются, но едят кактус)
А хочется найти решение, как бы это должно работать в "идеальном мире"... Например, вот так.
Настройки:
а) максимум настроек должны иметь приемлемые значения по умолчанию
б) там, где это невозможно - нужен генератор приложения из каркаса, который сгенерирует шаблон и файл fixme.md с инструкцией как заполнять. Там, где настройки лежат вне приложения - или положить в приложение, или тоже генератор.
Заявки: в идеале должен быть портал, на котором можно заказать железо и там же указать используемые компоненты платформы и требования к ним: прогнозное число RPS и\или размер хранилища для планирования нагрузки, данные сертификатов для интеграции и прочую информацию, требуемую поставщиком. Возникает вопрос - как быть с тем, что железо нужно для разных стендов - например, сохранять заказ для первого стенда и потом клонировать его для других стендов. Данные заказа попадают в команду платформенной компоненты, а далее они уже сами решают как их обрабатывать - или подключают автоматизацию, или по старинке - руками. Итого получаем систему, которая хранит архитектуру модуля и информацию по полученной инфраструктуре. Причем актуальную информацию, т.к. от нее зависят доступы. Информацию лучше загружать в виде текстовых файлов, все же Infrastructure as Code рулит)
Повторюсь - это концепт, при реализации возможны неочевидные на первый взгляд проблемы, т.к. подключаемые компоненты платформы имеют разную архитектуру и требования.
А основная цель предлагаемых изменений - автоматизировать ручной неочевидный труд, и т.об. снизить число ошибок и время на отладку.
#it #infrastructure #arch #platform
Периодически на работе приходится сталкиваться с задачей подключения той или иной платформенной компоненты. Платформа у нас большая, компонент много.
С подключением обычно два вида сложностей:
1) изучить кукбук, подключить правильные зависимости и сделать правильные настройки) Зависимости - это очевидно для разработки, а вот настройки - далеко не всегда.
2) административка: завести заявку на подключение - в JIRA, Confluence или даже по почте. Вот это совсем не интуитивно, а ошибки, связанные с отсутствием заявки сложно отлаживать. Оправдывают такой процесс обычно так:
а) что новый потребитель - это дополнительная нагрузка, ее нужно запланировать.
б) требованиями безопасности.
в) просто считается, что это нормально
А хуже, если заявки придется делать на каждый используемый стенд.
Что в итоге? Мыши колются, но едят кактус)
А хочется найти решение, как бы это должно работать в "идеальном мире"... Например, вот так.
Настройки:
а) максимум настроек должны иметь приемлемые значения по умолчанию
б) там, где это невозможно - нужен генератор приложения из каркаса, который сгенерирует шаблон и файл fixme.md с инструкцией как заполнять. Там, где настройки лежат вне приложения - или положить в приложение, или тоже генератор.
Заявки: в идеале должен быть портал, на котором можно заказать железо и там же указать используемые компоненты платформы и требования к ним: прогнозное число RPS и\или размер хранилища для планирования нагрузки, данные сертификатов для интеграции и прочую информацию, требуемую поставщиком. Возникает вопрос - как быть с тем, что железо нужно для разных стендов - например, сохранять заказ для первого стенда и потом клонировать его для других стендов. Данные заказа попадают в команду платформенной компоненты, а далее они уже сами решают как их обрабатывать - или подключают автоматизацию, или по старинке - руками. Итого получаем систему, которая хранит архитектуру модуля и информацию по полученной инфраструктуре. Причем актуальную информацию, т.к. от нее зависят доступы. Информацию лучше загружать в виде текстовых файлов, все же Infrastructure as Code рулит)
Повторюсь - это концепт, при реализации возможны неочевидные на первый взгляд проблемы, т.к. подключаемые компоненты платформы имеют разную архитектуру и требования.
А основная цель предлагаемых изменений - автоматизировать ручной неочевидный труд, и т.об. снизить число ошибок и время на отладку.
#it #infrastructure #arch #platform