Тимлиду часто надо мерджить. Мерджить — это 3 колонки кода на одном экране.
Ритина, это, конечно, хорошо. Но большой монитор для разработчика — мастхэв
Всё это конечно хорошо, но пока в России в городах, вместо положеных 60, народ ездит 80 дороги в России будут опасны.
По-хорошему должно быть строгое соблюдение скоростного режима, а не +20 км/ч.
Те если стоит знак на 30, то ехать надо 30, а не 50.
По хорошему, надо делать дефолтную скорость в городах 50, без возможности превышать.
С читалками есть одна проблема: на них плохо читать пиратские сканы учебников, тут планшет вне конкуренции. А издательства не хотят выпускать учебники в электронном виде, ведь они зарабатывают на бумаге.
По факту ребята делают деньги на детском сколиозе.
Хабр — не место для дискуссий. Здесь согласные в лучшем случае поставят "плюс" комментарию, но несогласные "минусуют" в карму. Потому если не хоте слитую карму, как у меня, то нужно включать самоцензуру на максимум.
Те у вас не получится отстаивать непопулярную точку зрения, даже чтобы просто узнать какие контраргументы к ней применяются. Жанр: сделать наборс и посмотреть, как люди предлагают лучшее решение тут будет стоить вам слитой кармы. Лучше обсуждать спорные вопросы чатиках в телеге или твиторе, есть ещё экзотический вариант разделы /pr на имиджбордах, но это на любителя.
Но есть хорошая вещь для тех, кто пишет узкоспециализированные статьи: такие статьи очень хорошо индексируются гуглом и вас будут читать долгие годы, а хайпостатьи уже перестанут читать через неделю-две.
1. Не аутсорсите критичные для бизнеса вещи. Аутсорсерам всё равно на ваш бизнес, они получают плату за часы. То, что для аутсорсера важен бренд или имя — большое заблуждение. Единственное, что может заставить работать аутсореров лучше — это хорошая неустойка.
2. Толк от аутсорсера можно получить только тогда, когда вы знаете что и как нужно сделать. В противном случае согласование «что» займёт вечность, а «как» будет скорее всего криво. Заводите аналитиков, менеджеров и архитекторов на своей стороне. Развивайте процессы и технологии на своей стороне. Аутсорсерам оставьте исполнение и следование вашим процессам. Менеджеры в аутсорсинговой конторе зальют вам в уши про их мега-процессы, SEI CMM и прочее. Лучший процесс тот, который интегрирован с вами. Лучше работают специалисты интегрированные в ваши команды.
3. Если уже работаете с аутсорсерами, то старайтесь работать напрямую с разработчиками, а не с менеджерами на стороне аутсорсинговой компании. Менеджер скорее всего будет продавать вам джунов по цене синьёров, и одного синьёра будет продавать на несколько проектов одновременно и мутить с отчётами. Плюс, если у вас будет личный контакт с исполнителем, то ему будет проще вас понять и вы реально будете контролировать процесс.
4. Постоянно делайте аудит. За аутсорсерами надо постоянно следить. Если аутсорсите инфраструктуру, то аудит безопасности нельзя доверять сами аутсорсерам. Ищите компетентных специалистов, способных сделать аудит ваших решений. Аутсорсер не будет платить штрафы за нарушение GDPR и прочих регуляций, их будете платить вы. Если у вас нет времени/денег на аудит, то скорее всего вы потратите ещё больше времени и денег.
5. Аутсорсинг может быть очень эффективным инструментом, особенно если вы лично знаете тех, кто на вас работает. Но помните, что аутсорсинг сгубил Боинг, и ответственность за всё несёт Боинг, а не те аутсорсеры, которые говнокодили авионику.
Как вы бэкапили ваши терабайты Mongo-данных?
Например, Elastic легко умеет заливать терабайтные снапшоты в S3 из коробки, причем делает это очень быстро.
Я бы хотел знать другое:
1. В Mongo нет нормальных бэкапов, вам предложат либо тормозной mongodump/mongorestore либо делать снапшоты дисков. Уже после этого пункта вам вряд ли захочется работать с mongo.
2. В Mongo очень томозные курсоры. Если вы хотите пробежать по всей коллекции размеров в несколько сот гигабайт, то это будет очень долго. Так что в связке Mongo + Elastic переидексировать ваши гигабайты будет долгой задачей.
3. У Mongo нет нормального бесплатного GUI, самое лучшее — это NoSQLBooster, но он стоит денег.
4. У Mongo много ограничений, на размер документа, на блокировки и т.д. в cosmos лимиты ещё меньше.
5. Mongo очень тяжело администрировать. В отличии от, например, Elasticsearch. Знакомые devops'ы при словах «конфигурировать mongo» как-то быстро сливались.
6. Если вы думаете, что сейчас закините монгу в кубер и будет у вас сверхбыстрое хранилище документов на 10TB, то вы очень ошибаетесь.
7. Mongo и Cosmos — это разные системы. Не стоит разрабатывать под Mongo в надежде, что оно потом легко заведётся на Cosmos.
Обычно путь миграци на mongo проекта выглядит так:
1. Решили перейти с Oracle/MS SQL/MySQL на mongo
2. MVP выглядит отлично всё работает.
3. Залили реальные данные, начали разворачивать кластер и погрустнели.
4. Захотелось построить репорт.
5. Внезапно кто-то из вспомнил про блокировки и ACID. Которые, в Mongo 4, конечно, есть, только вся ваша транзакция должна помещаться в один монго-документ размером в 16MB.
6…
7. Перешли на PostgreSQL.
Моё ИМХО, что позиционирование mongo, как no-sql системы общего назначения крайне неправильно.
Да, когда вы пишете MVP, то всё быстро.
Да, там много фичей, но очень много подводных камней при работе с большими базами.
И надо очень хорошо понимать, что у вас за данные, как проект будет развиваться и сможете ли вы найти достаточно компетентных devops'ов под Mongo.
Иначе берите PostgreSQL и используйте json-поля. Если очень хочется no-sql, то присмотритесь к Elastic (в 2020ом он уже вполне себе no-sql база, а не временный индекс: снапшотить, админить и использовать его удобнее, чем Mongo).
Либо сразу затачивайтесь на конкретное облако: cosmos или aws documentdb. Я не использовал MongoDB Atlas, но говорят, проблемы администрирования он лечит.
Да никто не пользуется бюджетной российской медициной.
Меня волнует решение моих проблем, в России за 2000 я могу попасть к специалисту в платной клинике, за ещё 2000 я делаю анализы в хеликсе. 2000 рублей — это 23 евро. Если мне не понравится, что сказал специалист, то я пойду в другую клинику, чтобы узнать мнение другого врача.
В германии семейный врач с хреновым английским будет мне мозг выносить, потом ждать N недель специалиста, который не включит мозг.
В том-то смысл быть IT-щником, что ты можешь получать нормальные услуги для себя и своих детей. По части сервиса за деньги для людей, зарабатывающих 3000 баксов в месяц, Россия пока вне конкуренции.
Я в Питере живу, машина по городу вообще не нужны, ведь есть метро и такси за 100-200 рублей (~3 евро). «Железный гроб» я купил за 3 своих зарплаты и езжу на нём за город и по Карелии.
А ещё я могу просто набрать номер клиники «21 век» и попасть к врачу если не в этот день, то на следующий за 1000-1500 рублей (~18 евро). А из Германии вроде как надо в Чехию лететь, чтобы полечиться нормально. У ребёнка что-то заболело, я просто имею годовую подписку на детского врача, который приезжает сам ко мне домой и стоит это ~200 евро в год.
А ещё в Питере за 500 евро я просто прихожу и вселяюсь в хату, которая мне нравится (на самом деле есть своя, но когда не было, то снимал за примерно 400 евро по тому курсу).
А ещё в Питере есть центры развития детей, где я просто плачу 300 евро и получаю отличных воспитателей на русском языке + логопеда, они ещё английский учат. Я вот совершенно не верю, что я могу обеспечить такой же уровень дошкольного образования в Германии (где центр скорее всего если и будет то дорого и далеко).
А ещё в Питере я не экономлю ни свет, ни воду ни газ. Ребёнок плавает в ванне почти каждый день.
Понятно, что в России куча проблем и надо валить, но выше я описал тот уровень комфорта, к которому я привык. И я не понимаю, что такого в Германии, что вы от всего этого счастья отказываетесь. Есть же и приличные страны, вроде Чехии, где хотя бы с медициной получше (собственно, знакомые поуехалы из Германии летают в Чехию и Россию на лечение). Ну или нидерланды, где можно не учить местный язык и прекрасно обходиться английским.
Мысль про фасады — очень правильная.
Репозиторий — это вообще зло, потому что реюзается. Когда GetUser внутри начинает возвращать все поля юзера, ещё и огромное дерево за ним. Ведь GetUser кому-то ещё пригодился.
Репозиторий прячет DbContext, который содержит в себе список Tracked-сущностей и очень хорошо, когда можно этим управлять. Кстати, именно потому в EF Core 5 добавили DbContextFactory, чтобы народ не прокдидывал один DbContext по всем сервисам в скопе.
Чтобы писать просто, надо меньше реюзать:
«а давайте сущность прямо из view прокидывать в ORM» — звучит красиво, но на практике лучше сдалать кучу классов для каждого View и DTO для каждого запроса, а потом мэппить одно на другое auto-mapper'ом.
Кодегеренация — это очень круто, именно она позволяет сделать мэппинг максимально быстрым.
Зачем им деньги?
Они за идею работать идут. За деньгами надо в коммерцию идти — носки продавать на рынке. А тут Родина дала им возможность строить ракеты — это же высшее счастье.
статья, конечно, практически бесполезная. Но тема важная. было бы интересно почитать более глубоко про то, как проходить Soft-skills интеврью и как правильно «пролечивать» российские, европейские и американские компании. Какие типы вопросов бывают и как на них правильно отвечать.
Ритина, это, конечно, хорошо. Но большой монитор для разработчика — мастхэв
По-хорошему должно быть строгое соблюдение скоростного режима, а не +20 км/ч.
Те если стоит знак на 30, то ехать надо 30, а не 50.
По хорошему, надо делать дефолтную скорость в городах 50, без возможности превышать.
По факту ребята делают деньги на детском сколиозе.
Хабр — не место для дискуссий. Здесь согласные в лучшем случае поставят "плюс" комментарию, но несогласные "минусуют" в карму. Потому если не хоте слитую карму, как у меня, то нужно включать самоцензуру на максимум.
Те у вас не получится отстаивать непопулярную точку зрения, даже чтобы просто узнать какие контраргументы к ней применяются. Жанр: сделать наборс и посмотреть, как люди предлагают лучшее решение тут будет стоить вам слитой кармы. Лучше обсуждать спорные вопросы чатиках в телеге или твиторе, есть ещё экзотический вариант разделы /pr на имиджбордах, но это на любителя.
Но есть хорошая вещь для тех, кто пишет узкоспециализированные статьи: такие статьи очень хорошо индексируются гуглом и вас будут читать долгие годы, а хайпостатьи уже перестанут читать через неделю-две.
2. Толк от аутсорсера можно получить только тогда, когда вы знаете что и как нужно сделать. В противном случае согласование «что» займёт вечность, а «как» будет скорее всего криво. Заводите аналитиков, менеджеров и архитекторов на своей стороне. Развивайте процессы и технологии на своей стороне. Аутсорсерам оставьте исполнение и следование вашим процессам. Менеджеры в аутсорсинговой конторе зальют вам в уши про их мега-процессы, SEI CMM и прочее. Лучший процесс тот, который интегрирован с вами. Лучше работают специалисты интегрированные в ваши команды.
3. Если уже работаете с аутсорсерами, то старайтесь работать напрямую с разработчиками, а не с менеджерами на стороне аутсорсинговой компании. Менеджер скорее всего будет продавать вам джунов по цене синьёров, и одного синьёра будет продавать на несколько проектов одновременно и мутить с отчётами. Плюс, если у вас будет личный контакт с исполнителем, то ему будет проще вас понять и вы реально будете контролировать процесс.
4. Постоянно делайте аудит. За аутсорсерами надо постоянно следить. Если аутсорсите инфраструктуру, то аудит безопасности нельзя доверять сами аутсорсерам. Ищите компетентных специалистов, способных сделать аудит ваших решений. Аутсорсер не будет платить штрафы за нарушение GDPR и прочих регуляций, их будете платить вы. Если у вас нет времени/денег на аудит, то скорее всего вы потратите ещё больше времени и денег.
5. Аутсорсинг может быть очень эффективным инструментом, особенно если вы лично знаете тех, кто на вас работает. Но помните, что аутсорсинг сгубил Боинг, и ответственность за всё несёт Боинг, а не те аутсорсеры, которые говнокодили авионику.
Например, Elastic легко умеет заливать терабайтные снапшоты в S3 из коробки, причем делает это очень быстро.
1. В Mongo нет нормальных бэкапов, вам предложат либо тормозной mongodump/mongorestore либо делать снапшоты дисков. Уже после этого пункта вам вряд ли захочется работать с mongo.
2. В Mongo очень томозные курсоры. Если вы хотите пробежать по всей коллекции размеров в несколько сот гигабайт, то это будет очень долго. Так что в связке Mongo + Elastic переидексировать ваши гигабайты будет долгой задачей.
3. У Mongo нет нормального бесплатного GUI, самое лучшее — это NoSQLBooster, но он стоит денег.
4. У Mongo много ограничений, на размер документа, на блокировки и т.д. в cosmos лимиты ещё меньше.
5. Mongo очень тяжело администрировать. В отличии от, например, Elasticsearch. Знакомые devops'ы при словах «конфигурировать mongo» как-то быстро сливались.
6. Если вы думаете, что сейчас закините монгу в кубер и будет у вас сверхбыстрое хранилище документов на 10TB, то вы очень ошибаетесь.
7. Mongo и Cosmos — это разные системы. Не стоит разрабатывать под Mongo в надежде, что оно потом легко заведётся на Cosmos.
Обычно путь миграци на mongo проекта выглядит так:
1. Решили перейти с Oracle/MS SQL/MySQL на mongo
2. MVP выглядит отлично всё работает.
3. Залили реальные данные, начали разворачивать кластер и погрустнели.
4. Захотелось построить репорт.
5. Внезапно кто-то из вспомнил про блокировки и ACID. Которые, в Mongo 4, конечно, есть, только вся ваша транзакция должна помещаться в один монго-документ размером в 16MB.
6…
7. Перешли на PostgreSQL.
Моё ИМХО, что позиционирование mongo, как no-sql системы общего назначения крайне неправильно.
Да, когда вы пишете MVP, то всё быстро.
Да, там много фичей, но очень много подводных камней при работе с большими базами.
И надо очень хорошо понимать, что у вас за данные, как проект будет развиваться и сможете ли вы найти достаточно компетентных devops'ов под Mongo.
Иначе берите PostgreSQL и используйте json-поля. Если очень хочется no-sql, то присмотритесь к Elastic (в 2020ом он уже вполне себе no-sql база, а не временный индекс: снапшотить, админить и использовать его удобнее, чем Mongo).
Либо сразу затачивайтесь на конкретное облако: cosmos или aws documentdb. Я не использовал MongoDB Atlas, но говорят, проблемы администрирования он лечит.
Меня волнует решение моих проблем, в России за 2000 я могу попасть к специалисту в платной клинике, за ещё 2000 я делаю анализы в хеликсе. 2000 рублей — это 23 евро. Если мне не понравится, что сказал специалист, то я пойду в другую клинику, чтобы узнать мнение другого врача.
В германии семейный врач с хреновым английским будет мне мозг выносить, потом ждать N недель специалиста, который не включит мозг.
В том-то смысл быть IT-щником, что ты можешь получать нормальные услуги для себя и своих детей. По части сервиса за деньги для людей, зарабатывающих 3000 баксов в месяц, Россия пока вне конкуренции.
www.youtube.com/watch?v=kV6RF684e-I
А ещё я могу просто набрать номер клиники «21 век» и попасть к врачу если не в этот день, то на следующий за 1000-1500 рублей (~18 евро). А из Германии вроде как надо в Чехию лететь, чтобы полечиться нормально. У ребёнка что-то заболело, я просто имею годовую подписку на детского врача, который приезжает сам ко мне домой и стоит это ~200 евро в год.
А ещё в Питере за 500 евро я просто прихожу и вселяюсь в хату, которая мне нравится (на самом деле есть своя, но когда не было, то снимал за примерно 400 евро по тому курсу).
А ещё в Питере есть центры развития детей, где я просто плачу 300 евро и получаю отличных воспитателей на русском языке + логопеда, они ещё английский учат. Я вот совершенно не верю, что я могу обеспечить такой же уровень дошкольного образования в Германии (где центр скорее всего если и будет то дорого и далеко).
А ещё в Питере я не экономлю ни свет, ни воду ни газ. Ребёнок плавает в ванне почти каждый день.
Понятно, что в России куча проблем и надо валить, но выше я описал тот уровень комфорта, к которому я привык. И я не понимаю, что такого в Германии, что вы от всего этого счастья отказываетесь. Есть же и приличные страны, вроде Чехии, где хотя бы с медициной получше (собственно, знакомые поуехалы из Германии летают в Чехию и Россию на лечение). Ну или нидерланды, где можно не учить местный язык и прекрасно обходиться английским.
Мысль про фасады — очень правильная.
Репозиторий — это вообще зло, потому что реюзается. Когда GetUser внутри начинает возвращать все поля юзера, ещё и огромное дерево за ним. Ведь GetUser кому-то ещё пригодился.
Репозиторий прячет DbContext, который содержит в себе список Tracked-сущностей и очень хорошо, когда можно этим управлять. Кстати, именно потому в EF Core 5 добавили DbContextFactory, чтобы народ не прокдидывал один DbContext по всем сервисам в скопе.
Чтобы писать просто, надо меньше реюзать:
«а давайте сущность прямо из view прокидывать в ORM» — звучит красиво, но на практике лучше сдалать кучу классов для каждого View и DTO для каждого запроса, а потом мэппить одно на другое auto-mapper'ом.
Кодегеренация — это очень круто, именно она позволяет сделать мэппинг максимально быстрым.
github.com/reinforced/Reinforced.Tecture
Они за идею работать идут. За деньгами надо в коммерцию идти — носки продавать на рынке. А тут Родина дала им возможность строить ракеты — это же высшее счастье.