А вот ссылочка по теме twitter.com/...​/1228454264915271683?s=21

Из того же треда собрали зарплаты в один документ: docs.google.com/...​XGIu7Mfy72lSVHKk/htmlview

Все зависит от приоритетов. Как говорится счастье за деньги не купишь.
Если для вас деньги основное — надо ехать туда где их много. Например в долину или Лондон. Если в Киеве вам «хватает», то и в Осло или Стокгольме тоже будет «хватать». В остальном вопрос скорее поменять ли друзей+родственников+свободу в общении на культурном уровне в Киеве — на жизнь иммигранта+спокойную жизнь, где в среднем дороги лучше, люди добрее и пенсия сытнее.

Кстати через 5-6 лет у вас и вашей семьи уже паспорт ЕС будет, если переедете сейчас =)

Ну зависит от зп в Украине — если вы 5к зарабатываете после налогов, то в скандинавии будет существенно меньше. Но на все необходимое будет хватать.
В долгосрочной перспективе — в скандинавии для детей все бесплатно, учитывая зубы и университеты. Жена со временем выучит язык и найдет работу, вложитесь в недвижимость с кредитом 1.5-2% годовых. Лет через 20 будете смотреть назад и радоваться переезду.

В Швеции всегда обсуждается per month, у контракторов per day или per hour

TDD люди не используют потому как порог вхождения высокий. Например чтобы писать тесты для апи или для базы — надо сначала разобраться как это запускать локально и на билд сервере.

Я пишу код только по TDD уже много лет, и постоянно ловлю баги. Это меня мотивирует продолжать использовать TDD. Когда я говорю TDD — я имею ввиду «red-green-refactor»

Например если мне надо сделать новый микросервис с новым эндпоинтом, например GET /customers/{id}/profile — перед тем как писать какой-либо код, я напишу тесты в которых я буду ожидать определенное поведение.
Я заранее найду ответы на вопросы (спрошу коллег):
— Что я ожидаю получить от сервера?
— Что я ожидаю получить если нет такого id?
— Что я ожидаю получить если customer с таким id заблокирован?
и так далее.
Когда я напишу тесты — они будут red, так как кода еще нет.

Следующий шаг — пишем код. Что мне нравится в TDD, что он помогает уменьшить количество кода. Если в процессе написания кода появляется вопрос «а что если я передам пустую строку в этот метод» — то есть два варианта. 1) Пишем тест который тестирует этот самый случай и думаем (спрашиваем) что мы ожидаем 2) Принимаем решение что это не важно (или никогда не произойдет) и оставляем поведение системы неопределенным. Нет теста — нет кода!

Когда все тесты зеленые — переходим к последнему шагу Refactor. Чистим код, переименовываем методы, удаляем дублирование и т.д.

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

Многие люди не осиливают TDD так как застряют в спорах что такое юнит тест, и что должен тестировать QA, а что девелопер. Я это проблему для себя и коллег решил просто — мы называем тесты тестами, если ты их можешь запустить локально. И у нас нет QA — программист отвечает за качество своего кода.

Поддержу. Есть админы из области «у нас тут сайт на вордпресе www.рога-и-копыта.com — надо задеплоить». И админ раз его задеплоил и он типа год работает. И админ целый год пьет чай, потому как www.рога-и-копыта.com — это просто три страницы которые никогда не меняются. На другом конце спектрума админ (на самом деле SRE/Network engineer) в какомнить Cloudflare где миллионы запросов в секунду, десятки датацентров и сотни новых клиентов каждый день. И все клиенты со своими требованиями... Вот уж где точно нет времени пить чай.

Аргумент из серии «электрические машины изобрели 50 лет назад — почему до сих пор мы все не ездим на электрических машинах?»

Вот нашел свой старый комент как мы фиксили OutOfMemoryException в чьем-то LINQ коде который пару лет работал и внезапно начал падать =)
dou.ua/...​et-for-beginners/#1329780

Могу вам код на Go за деньги написать. Что-то доказывать кому-то в интернете не вижу смысла

Ну например вот пишут:

DevOps culture stresses small, multidisciplinary teams, who work autonomously and take collective accountability for how actual users experience their software. For a DevOps team, there’s no place like production. Everything they do is about making customers’ live experience better.

DevOps teams apply agile practices and include operations in the team responsibility. Teams work in small batches, focus on improving the end-to-end delivery of customer value, and strive to eliminate waste and impediments along the way. There are no silos and no blame game, because the team is mutually accountable.

...

DevOps teams think in terms of competencies, not roles. While they include both developmental and operational skills and awareness, they share responsibility for running the live site. That means that developers on the team accept responsibility for the health of the running services and will rotate time on-call. The principle is, if you build it, you run it.

docs.microsoft.com/...​rn/what-is-devops-culture

Можно использовать клауд тулы типа Datadog или Loggly. Тогда разбираться надо только в их API и как мышкой покликать чтобы дашборд сделать. Если конечно хочется самому хостить опенсорс тул (на самом деле несколько одновременно) — понятное дело это на порядок сложнее и возможно прийдется нанять специально обученых людей =)

Так вас никто не заставляет использовать ORM. В микросервисах вообще 1-3 таблицы максимум в базе должно быть — зачем там орм? Я в последнее несколько лет на .net/c# использовал dapper.net и не нужно было никаких EntityFramework который майкрософт так везде пиарит

PHP будет жить пока живет wordpress и magento
Но за последние лет 5 я слышал про ровно ноль стартапов которые начинали писать какой-либо бекенд на PHP

В Швеции в стартапах часто есть только разработчики. Нет никаких девопсов. Разработчик должен сам уметь свой код запускать, тестировать, дебажить. И вообще: you built it — you run it. Когда компания становится достаточно большой (100+ инженеров) — тогда наверное есть смысл заводить SRE. Лично я не вижу в чем сложность запустить код в контейнере и снять оттуда логи/метрики. У нас даже джуны это умеют

очень рекомендую видеокурс от William Kennedy www.oreilly.com/...​rogramming/9780135261651

Предполагается что вы уже имеете опыт программирования на другом языке
Курс платный, но если нет денег — можно просто несколько раз start free trial ;)

basketItems
.Join(products, i => i.ProductId, j => j.Id, (i, j) => new {Cost = i.Price * i.Quantity})
.Where(i => i.Cost >= 100.3)
.Sum(i => i.Cost)

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

Это то самый случай когда вы пишете для компьютера, а не для людей. А должно быть наоборот

DDD не имеет никакого отношения к ООП.
Многие успешно строят системы по DDD на функциональных языках типа Скалы или Эрланга без единого класса.
Собственно мы отлично справляемся на Go и строем необанк в соответсвии с DDD

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

Я писал больше 10 лет на c#/.net и перешел на Go. Пишу всего лишь год на нем и считаю что c#/.net как и джава — технологии прошлого тысячелетия по сравнению с Go. Многие вещи за вас решены создателями (как писать тесты, как форматировать код и т.д.). Сам язык очень простой и очень хорошо подходит для современной cloud-native microservice архитектуры. Сначала мне не хватало дженерик типов, но теперь мне кажется что они просто не нужны :)

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

Крутая статья! Рад такое видеть на доу!

Спасибо за статью!
Я недавно прочитал книгу Lean Analytics и пошарил мои выводы с коллегами:

— Ideally you should have only OMTM (One Metric That Matters) that you use to understand whether you are successful or not
— Company has different stages: Empathy, Stickiness, Virality, Revenue and Scale
— OMTM is different on different stage. On early stage it’s important to get more customers, on later stages important to get revenue
— Metrics (charts) that are Up and Right are useless. For example total registered customer count over time will be always growing, but it does not tell you much about your recent change
— Rate metrics (registrations/week, payments per customer/month, etc.) are good and help you to understand if your change affects something in a positive or negative way
— Don’t measure too much — it’s hard to handle too much numbers and easy to get lost. Measure things that will be important for decision making — OMTM.
— Good startups are growing 5% per week. Bets startups are growing 20% per week
— Mobile app size should be <50Mb, otherwise registration rate drops
— If you ask credit card details in order to start trial — amount of paying customers drops significantly

В книге 6 примеров разных типов бизнесов (e-commerce, mobile game, SaaS и так далее) с конкретными примерами метрик на разных этапах жизни компании. Рекомендую всем кто интересуется аналитикой и развитием продукта!