🚀 Спонсорство на YouTube восстановлено!
Наконец-то получилось создать новый AdSense аккаунт, пройти все верификации и прилинковать его к YouTube каналу dmdev.
Как подтверждение - вижу, что вновь пошли новые ребята присоединяться к спонсорской программе YouTube.
Так что всем большое спасибо, кто помог информацией и ссылками на то, как быстро восстановить доступ к видео!
И всем вновь приятного просмотра :)
Наконец-то получилось создать новый AdSense аккаунт, пройти все верификации и прилинковать его к YouTube каналу dmdev.
Как подтверждение - вижу, что вновь пошли новые ребята присоединяться к спонсорской программе YouTube.
Так что всем большое спасибо, кто помог информацией и ссылками на то, как быстро восстановить доступ к видео!
И всем вновь приятного просмотра :)
🔥55🎉12👍6⚡3❤2
This media is not supported in your browser
VIEW IN TELEGRAM
Копипаст - это хорошо!
Копируя очередной блок кода откуда-то для своего сервиса, помни - что это абсолютно естественно (в рамках разумного конечно). Потому что это заложенно в нас генетически!
👉Как отличный пример:
на видео мой сын, которому 1 год и 4 месяца пытается скопировать довольно сложное для него упражнение для раскатки мышц роллом. И его явно никто не просил и не учил этому, потому что у детей его возраста уши нужны для красоты. Так что все происходит естественно.
Поэтому в который раз убеждаюсь, что абсолютно любой человек - это универсальная копировальная машина 😎
Копируя очередной блок кода откуда-то для своего сервиса, помни - что это абсолютно естественно (в рамках разумного конечно). Потому что это заложенно в нас генетически!
👉Как отличный пример:
на видео мой сын, которому 1 год и 4 месяца пытается скопировать довольно сложное для него упражнение для раскатки мышц роллом. И его явно никто не просил и не учил этому, потому что у детей его возраста уши нужны для красоты. Так что все происходит естественно.
Поэтому в который раз убеждаюсь, что абсолютно любой человек - это универсальная копировальная машина 😎
🔥60😍18👍15❤5😁5💯3🥰2
Почему исторически пришли к использованию нескольких баз данных на одном проекте?
Лет 10 назад (а может уже и больше) я написал довольно сложный SQL запрос, который ежедневно вытягивал информацию заказчику об израсходованных пользователями ресурсах. Сам запрос отрабатывал просто замечательно, пока данных не перевалило за 50M. Последующий тюнинг запроса и создание индексов хоть и улучшили ситуацию, но лишь отложили неминуемую проблему.
И уже тогда я задавался вопросом - неужели нельзя как-то иначе структурировать данные в СУБД, чтобы можно было и правильно хранить, соблюдая первые нормальные формы, и читать их также эффективно.
Как оказалось - нельзя 🙂
Поэтому решение, к которому мы тогда пришли и которое сейчас уже повсеместно встречается везде (и которое кажется абсолютно логичным, но не тогда казалось нам!) - это использование нескольких СУБД. Но как и любое другое решение, оно имеет свои плюсы и минус - и это надо помнить.
Например:
- одна для обработки live данных пользователей
- вторая для быстрого поиска по этим live данным
- третья для аналитики и отчетов
Обычно, для каждого варианта используются разные СУБД, которые выполняют свои функции лучше всего. Например, для первого кейса PostgreSQL, для второго Elasticsearch, для третьего BigQuery.
PS. Фото - это я решил покормить лемуров на Кипре. Но их было также много, как и баз данных сейчас у меня в Google 😅
Лет 10 назад (а может уже и больше) я написал довольно сложный SQL запрос, который ежедневно вытягивал информацию заказчику об израсходованных пользователями ресурсах. Сам запрос отрабатывал просто замечательно, пока данных не перевалило за 50M. Последующий тюнинг запроса и создание индексов хоть и улучшили ситуацию, но лишь отложили неминуемую проблему.
И уже тогда я задавался вопросом - неужели нельзя как-то иначе структурировать данные в СУБД, чтобы можно было и правильно хранить, соблюдая первые нормальные формы, и читать их также эффективно.
Как оказалось - нельзя 🙂
Это все равно, что решить две диаметрально противоположные проблемы на чтение и запись данных - одним и тем же способом.
Поэтому решение, к которому мы тогда пришли и которое сейчас уже повсеместно встречается везде (и которое кажется абсолютно логичным, но не тогда казалось нам!) - это использование нескольких СУБД. Но как и любое другое решение, оно имеет свои плюсы и минус - и это надо помнить.
Например:
- одна для обработки live данных пользователей
- вторая для быстрого поиска по этим live данным
- третья для аналитики и отчетов
Обычно, для каждого варианта используются разные СУБД, которые выполняют свои функции лучше всего. Например, для первого кейса PostgreSQL, для второго Elasticsearch, для третьего BigQuery.
Но нужно помнить, что это вполне нормально и даже более правильно начинать с одной СУБД и только со временем добавлять другие, если в этом есть или предвидется необходимость в скором времени - YAGNI!
PS. Фото - это я решил покормить лемуров на Кипре. Но их было также много, как и баз данных сейчас у меня в Google 😅
🔥44👍18❤4❤🔥4😁4
Какое количество строк в таблицах реляционных СУБД можно считать оптимальным?
Anonymous Quiz
6%
До 10к
12%
До 100к
34%
До 1М
31%
До 10М
17%
До 100М
🤔18👍5🤯3😭3
Какое оптимальное количество строк в таблицах реляционных СУБД?
На своем опыте использования разных СУБД и пообщавшись с более профильными ребятами DBE (Database Engineer) - я пришел к выводу, на сколько хорошо или плохо работают реляционные СУБД в зависимости от объема данных в таблицах:
1️⃣ От 0 до 10M - такое количество строк, пожалуй, является идеальным. Все SQL запросы по любым колонкам работают очень быстро, и даже full scan выполняется за доли секунды.
2️⃣ От 10М до 50М - это довольно увесистые таблицы, уже нужно задумываться о создании индексов и как написать хорошо SQL запросы. Нужно избегать full scan, если это возможно. Старые SQL запросы скорее всего придется пересмотреть и оптимизировать, потому что появляются проблемы с производительностью приложений.
3️⃣ От 50М до 100М - пора доставать задачи из бэклога о редизайне схемы базы данных, рассматривать партиционирование/шардирование (на уровне СУБД, если она это поддерживает, либо на уровне приложения). Или даже использование/переезд на другую СУБД, потому что релиз практически любой фичи сопряжен с какими-то проблемами. А старый функицонал все чаще выстреливает в ногу там, где даже не ожидал. Даже простейшее добавление/удаление колонки, создание нового индекса может привести к full outage.
4️⃣ От 100М до 1ММ - это как тонущий корабль, ибо поздно задумываться о чем-то - проблемы уже есть здесь и сейчас. А использовать какое-либо решение из пункта 3 сопряжено с большими проблемами или даже не является возможным.
Уже не помню из какой книги, но я достал для себя интересную мысль, которую применяю при написании алгоритмов или тех же SQL запросов:
Другими словами говоря, я ставлю себя на место машины/компьютера.
Например:
1️⃣ Переносить дрова по одной штуке сложнее, чем взять тележку (= использование батчей)
2️⃣ Если попросить друга, то выкопать картошку в огороде будет почти в 2 раза быстрее (= использование несколько ядер/потоков)
3️⃣ Поднимать вес гантель становится все сложнее с увеличением веса (= увеличению кол-ва строк в таблицах)
4️⃣ Искать номер телефона в справочнике гораздо быстрее, если он отсортирован по алфавиту (= использование сортировок и двоичного поиска)
PS. На фото - это я себе сделал подарок на НГ, чтобы выполнять силовые не выходя из дома 😁
На своем опыте использования разных СУБД и пообщавшись с более профильными ребятами DBE (Database Engineer) - я пришел к выводу, на сколько хорошо или плохо работают реляционные СУБД в зависимости от объема данных в таблицах:
1️⃣ От 0 до 10M - такое количество строк, пожалуй, является идеальным. Все SQL запросы по любым колонкам работают очень быстро, и даже full scan выполняется за доли секунды.
2️⃣ От 10М до 50М - это довольно увесистые таблицы, уже нужно задумываться о создании индексов и как написать хорошо SQL запросы. Нужно избегать full scan, если это возможно. Старые SQL запросы скорее всего придется пересмотреть и оптимизировать, потому что появляются проблемы с производительностью приложений.
3️⃣ От 50М до 100М - пора доставать задачи из бэклога о редизайне схемы базы данных, рассматривать партиционирование/шардирование (на уровне СУБД, если она это поддерживает, либо на уровне приложения). Или даже использование/переезд на другую СУБД, потому что релиз практически любой фичи сопряжен с какими-то проблемами. А старый функицонал все чаще выстреливает в ногу там, где даже не ожидал. Даже простейшее добавление/удаление колонки, создание нового индекса может привести к full outage.
4️⃣ От 100М до 1ММ - это как тонущий корабль, ибо поздно задумываться о чем-то - проблемы уже есть здесь и сейчас. А использовать какое-либо решение из пункта 3 сопряжено с большими проблемами или даже не является возможным.
Также нужно помнить не только о количестве, но и об объеме информации (количестве байт), которое занимает в среднем одна строка в таблице. Ибо если решить хранить там бинарники (картинки, файлы) или большие строки, то описанные выше проблемы как будто сдигаются и могут начаться гораздо раньше!
Уже не помню из какой книги, но я достал для себя интересную мысль, которую применяю при написании алгоритмов или тех же SQL запросов:
Eсли что-то сложно или дольше делать тебе, то и машине это будет сложнее/дольше.
Другими словами говоря, я ставлю себя на место машины/компьютера.
Например:
1️⃣ Переносить дрова по одной штуке сложнее, чем взять тележку (= использование батчей)
2️⃣ Если попросить друга, то выкопать картошку в огороде будет почти в 2 раза быстрее (= использование несколько ядер/потоков)
3️⃣ Поднимать вес гантель становится все сложнее с увеличением веса (= увеличению кол-ва строк в таблицах)
4️⃣ Искать номер телефона в справочнике гораздо быстрее, если он отсортирован по алфавиту (= использование сортировок и двоичного поиска)
PS. На фото - это я себе сделал подарок на НГ, чтобы выполнять силовые не выходя из дома 😁
👍46🔥15❤7❤🔥3
С Наступающим Новым 2025 Годом!
Каждый раз в конце декабря я подвожу итоги для себя лично, чего я досиг и какая работа была проделана мной. Все-таки, очень часто со временем забываются и даже обесцениваются свои же труды, хотя когда-то это же самое казалось стоящим!
1️⃣ Купил машину. Это было очень важное приобретение по сравнению со всеми остальными моими покупками машин, потому что в этот раз я ее приобрел больше для сына и семьи, нежели сугубо для себя одного. Но почему-то в этот раз у меня даже не было радости или какого-то восторга от приобритения. Было чувство, как будто я просто в магазин сходил. Не нравится, когда со временем тебя перестают радовать даже такие вещи.
2️⃣ Месяц жили с семьей на Кипре. Пожалуй, это было лучшее время для меня в этом году, когда все вместе, не нужно пропадать днями на работе, а погода позволяет выходить на пробежки в шортах и майке в декабре месяце. Здесь я получил очень много нового для себя опыта, начиная от левостороннего движения и заканчивая первым в жизни землетрясением. Именно такой опыт увеличивает плостность твоей жизни, от чего кажется, что она становится еще длиннее и насыщеннее!
3️⃣ Взял 3 разряд в беге и триатлоне. Спорт - это не только про преодоление себя, дисциплину и прочее, хотя это одно из важнейших его качеств. Благодаря бегу я начал много читать книг (только ~7 за этот год) и интересоваться физиологией человека, как устроены наши тела, как происходит энергопотребление и другие очень важные процессы внутри нас (даже курс по долголетию прошел!). Тем самым я стал еще больше и усиленнее следить за тем, что я кушаю, пью, сплю, какие физ упражнения делаю, работаю и т.д. С возрастом здоровье только набирает ценность и становится все важнее и важнее для тебя.
4️⃣ Погасил ипотеку за квартиру. Покупка очередной квартиры, как и покупка очередной машины - больше не приносит того же восторга и удовольствия. Но отсутствие всяких кредитов явно делает мою жизнь спокойнее и менее стрессовой. А это дорогого стоит в наше время! Так что как и раньше - буду всеми силами в будущем отказываться от взятия всяких кредитов/ипотек и т.д.
5️⃣ Провел 4 группы менторства DMdev. В отличие от своей основной работы в Google, здесь я получаю настоящую благодарность от людей за то, что помог им реализовать их планы и цели в жизни. Это очень сильно помогает мне в получении душевного спокойствия. Поэтому буду стараться проводить их и дальше, пока это возможно!
6️⃣ Закончил курс по Docker. Это был единственный курс в этом году, хотя планировал изначально два. Законченные дела - это то, что помогает быть более дисциплинированным, ведь начинать что-то делать гораздо проще, чем продолжать и заканчивать. Для этого приходится брать силу воли и идти дальше, когда совсем уж и не хочется.
Теперь, написав все на бумаге, мне становится приятнее осознавать (или даже "осязать"), что не зря прошел этот год и можно заслуженно позволить себе отдохнуть на Новый Год, чтобы потом сразу же поставить перед собой новые цели. Ведь без целей твой фокус внимания будет метаться из стороны в сторону, и все силы (как и твое время) будут уходить вникуда.
❄️ ❄️ ❄️ ❄️ ❄️ ❄️
Поэтому всем желаю похвалить себя за пройденный путь и проделанный труд в 2024 году, загадать и идти к своим самым амбициозным желаниям в 2025 году, не спешить жить и замедляться, проводить больше времени с семьей и близкими, и просто человеческого счастья! Ваш Денис 🥳
Каждый раз в конце декабря я подвожу итоги для себя лично, чего я досиг и какая работа была проделана мной. Все-таки, очень часто со временем забываются и даже обесцениваются свои же труды, хотя когда-то это же самое казалось стоящим!
1️⃣ Купил машину. Это было очень важное приобретение по сравнению со всеми остальными моими покупками машин, потому что в этот раз я ее приобрел больше для сына и семьи, нежели сугубо для себя одного. Но почему-то в этот раз у меня даже не было радости или какого-то восторга от приобритения. Было чувство, как будто я просто в магазин сходил. Не нравится, когда со временем тебя перестают радовать даже такие вещи.
2️⃣ Месяц жили с семьей на Кипре. Пожалуй, это было лучшее время для меня в этом году, когда все вместе, не нужно пропадать днями на работе, а погода позволяет выходить на пробежки в шортах и майке в декабре месяце. Здесь я получил очень много нового для себя опыта, начиная от левостороннего движения и заканчивая первым в жизни землетрясением. Именно такой опыт увеличивает плостность твоей жизни, от чего кажется, что она становится еще длиннее и насыщеннее!
3️⃣ Взял 3 разряд в беге и триатлоне. Спорт - это не только про преодоление себя, дисциплину и прочее, хотя это одно из важнейших его качеств. Благодаря бегу я начал много читать книг (только ~7 за этот год) и интересоваться физиологией человека, как устроены наши тела, как происходит энергопотребление и другие очень важные процессы внутри нас (даже курс по долголетию прошел!). Тем самым я стал еще больше и усиленнее следить за тем, что я кушаю, пью, сплю, какие физ упражнения делаю, работаю и т.д. С возрастом здоровье только набирает ценность и становится все важнее и важнее для тебя.
4️⃣ Погасил ипотеку за квартиру. Покупка очередной квартиры, как и покупка очередной машины - больше не приносит того же восторга и удовольствия. Но отсутствие всяких кредитов явно делает мою жизнь спокойнее и менее стрессовой. А это дорогого стоит в наше время! Так что как и раньше - буду всеми силами в будущем отказываться от взятия всяких кредитов/ипотек и т.д.
5️⃣ Провел 4 группы менторства DMdev. В отличие от своей основной работы в Google, здесь я получаю настоящую благодарность от людей за то, что помог им реализовать их планы и цели в жизни. Это очень сильно помогает мне в получении душевного спокойствия. Поэтому буду стараться проводить их и дальше, пока это возможно!
6️⃣ Закончил курс по Docker. Это был единственный курс в этом году, хотя планировал изначально два. Законченные дела - это то, что помогает быть более дисциплинированным, ведь начинать что-то делать гораздо проще, чем продолжать и заканчивать. Для этого приходится брать силу воли и идти дальше, когда совсем уж и не хочется.
Теперь, написав все на бумаге, мне становится приятнее осознавать (или даже "осязать"), что не зря прошел этот год и можно заслуженно позволить себе отдохнуть на Новый Год, чтобы потом сразу же поставить перед собой новые цели. Ведь без целей твой фокус внимания будет метаться из стороны в сторону, и все силы (как и твое время) будут уходить вникуда.
Поэтому всем желаю похвалить себя за пройденный путь и проделанный труд в 2024 году, загадать и идти к своим самым амбициозным желаниям в 2025 году, не спешить жить и замедляться, проводить больше времени с семьей и близкими, и просто человеческого счастья! Ваш Денис 🥳
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥110❤33👍19🎉8🤩2🏆1🍾1
У меня новый год начался на работе с задач по аналитике. С ней мне не приходилось работать с тех пор, как я устроился в Google.
И что я понял... Что прогресс не стоит на месте даже здесь. Если раньше я использовал BigQuery для построения запросов и Looker для визуализации аналитических данных, то сейчас я вообще никак не ограничен в способах получения данных.
Я могу использовать в одном запросе данные из BigQuery, Spanner, да даже csv файл могу заджойнить! О такой гибкости я мог только мечтать.
Поэтому смело инвестируй свое время в SQL. Это, пожалуй, такой же ключевой навык для backend разработчика, как и знание Bash. Причем оба инструмента старше меня. Как говорится, великое актуально всегда :)
И что я понял... Что прогресс не стоит на месте даже здесь. Если раньше я использовал BigQuery для построения запросов и Looker для визуализации аналитических данных, то сейчас я вообще никак не ограничен в способах получения данных.
Я могу использовать в одном запросе данные из BigQuery, Spanner, да даже csv файл могу заджойнить! О такой гибкости я мог только мечтать.
Но самое главное, что для всего этого мне достаточно хорошо знать SQL, потому что этот язык с небольшими диалектами/изменениями используется везде! А он, на минуточку, был создан в далеком 1974 году, т.е. уже 50 лет назад.
Поэтому смело инвестируй свое время в SQL. Это, пожалуй, такой же ключевой навык для backend разработчика, как и знание Bash. Причем оба инструмента старше меня. Как говорится, великое актуально всегда :)
❤🔥26👍23🔥11❤2
This media is not supported in your browser
VIEW IN TELEGRAM
Top Alerts
Я уже не раз в своих постах затрагивал тему логов и метрик, чтобы донести на сколько важны они в системе. И возвращаясь к метрикам: какой топ самых распространенных алертов, которые должны быть настроены у каждого?
1️⃣ Availability - доступность сервиса. Или иначе: как много 5xx ошибок возвращается клиентам по сравнению с другими статусами.
2️⃣ Latency - как много времени сервису трубется для обработки одного запроса. Если оно становится больше, то это может свидетельствовать о каких-то внутренних неполадках (например, downstream сервис или база данных подтормаживают, SQL запросы не оптимизированы, и т.д.). Также это каскадно может привести к проблемам у upstream сервисов.
3️⃣ Traffic absence - отсутствие траффика вообще, когда ни одного запроса не достигает твоего сервиса на протяжении часа, двух, суток и т.д. Это свидетельствует о проблемах на уровень выше, в инфрастуктуре или на стороне клиента. Часто про этот алерт забывают, но он невероятно важен как и два предыдущих!
В любом случае, алерты - это конечно хорошо, но очень уж не нравится просыпаться среди ночи, когда они звонят тебе на телефон 🥲
Я уже не раз в своих постах затрагивал тему логов и метрик, чтобы донести на сколько важны они в системе. И возвращаясь к метрикам: какой топ самых распространенных алертов, которые должны быть настроены у каждого?
1️⃣ Availability - доступность сервиса. Или иначе: как много 5xx ошибок возвращается клиентам по сравнению с другими статусами.
2️⃣ Latency - как много времени сервису трубется для обработки одного запроса. Если оно становится больше, то это может свидетельствовать о каких-то внутренних неполадках (например, downstream сервис или база данных подтормаживают, SQL запросы не оптимизированы, и т.д.). Также это каскадно может привести к проблемам у upstream сервисов.
3️⃣ Traffic absence - отсутствие траффика вообще, когда ни одного запроса не достигает твоего сервиса на протяжении часа, двух, суток и т.д. Это свидетельствует о проблемах на уровень выше, в инфрастуктуре или на стороне клиента. Часто про этот алерт забывают, но он невероятно важен как и два предыдущих!
В любом случае, алерты - это конечно хорошо, но очень уж не нравится просыпаться среди ночи, когда они звонят тебе на телефон 🥲
👍34🔥9❤🔥2❤1
Фото для привлечения внимания 😁
Осталось 3 места на менторство DMdev 1 ступени
Записывайся, будем прокачивать мозги, а не тело💻
Да начнется трансформация!
👇
клик-клик
Осталось 3 места на менторство DMdev 1 ступени
Записывайся, будем прокачивать мозги, а не тело
Да начнется трансформация!
👇
клик-клик
Please open Telegram to view this post
VIEW IN TELEGRAM
😁67🔥15👍5⚡1👏1🤔1🌚1
Учитель - это не тот, кто скажет тебе нечто, о чем другие до него не могли сказать. Учитель станет твоим другом, потому что скажет так, что ты наконец-то услышишь
Что-то в этом есть. Сам помню, как бывает слушаешь ту же самую сложную тему, которую плохо понимаешь, но от другого человека - и мир как будто начинает играть новыми красками, и до тебя наконец-то доходит.
Также очень сильно влияет то, КАК до тебя доносят информацию, используя уже известные тебе знания, термины, понятия и т.д. По-другому говоря, объясняют "неизвестное" через "известное".
Если же говорить про Java, то очень важно постепенно изучать ее по моему Roadmap, не пропуская какие-то темы. Даже если тебе, как ученику, кажется, что это не нужно и можно пропустить парочку курсов!
PS. Календарь настоящий, у меня дома на кухонном столе стоит 🙂
Что-то в этом есть. Сам помню, как бывает слушаешь ту же самую сложную тему, которую плохо понимаешь, но от другого человека - и мир как будто начинает играть новыми красками, и до тебя наконец-то доходит.
Также очень сильно влияет то, КАК до тебя доносят информацию, используя уже известные тебе знания, термины, понятия и т.д. По-другому говоря, объясняют "неизвестное" через "известное".
Если же говорить про Java, то очень важно постепенно изучать ее по моему Roadmap, не пропуская какие-то темы. Даже если тебе, как ученику, кажется, что это не нужно и можно пропустить парочку курсов!
PS. Календарь настоящий, у меня дома на кухонном столе стоит 🙂
👍43🔥14❤4🤔3
На Java сейчас в основном проекты на поддержке, а новые в сфере применения Java пишутся на Go или JS. Так ли это?
Начну с того, что когда я учился в университете БГУИР в далеком 2009 году, я всегда думал, что все вокруг меня пишут на C/C++. А значит и мне надо учить этот язык, чтобы устроиться на работу.
Потом я работал в компании Godel Technologies, где большинство проектов были написаны на C#, причем количество проектов этих только увеличивалось со временем, а проектов по Java уменьшалось здесь. И закрадывалась мысль, что вот-вот и C# поборет Java и нужно свичнуться на него побыстрее.
К чему это я?
Если хочется более объективной оценки, то лучше смотреть на вакансии в интересующем тебя регионе или на мировые рейтинги языков программирования, например, TIOBE или GitHub.
Лично я предпочитаю TIOBE, потому что он основан на анализе поисковых запросов по языку программирования, активности сообщества разработчиков, количестве вакансий и проектов. Он обновляется ежемесячно.
GitHub же не совсем объективен по моему мнению, потому что большинство компаний (тем более таких больших как MAANG) не держат там свой код. И, наоборот, студенты и фрилансеры активно его используют.
Также нужно обращать внимание на доменную область применения языка. Например, Python находится на первом месте в рейтингах потому, что сейчас нейронные сети и AI на хайпе. Но это не значит, что прикладные программы, enterprise, мобильные приложения и веб пишутся на нем с той же популярностью - это совсем не так. Эти области заняты другими языками.
Python - это обычно про data science и machine learning (и то он переписывается на C++, если нужно установить приложение на пользовательские устройства).
Что же касается изначального вопроса про Go - то, работая в компании Google, которая создала его, могу сказать, что он занял здесь лишь свою небольшую нишу. Так что до сих пор при выборе языка программирования для backend разработки новых сервисов - здесь предпочтительным является Java/Kotlin.
Теперь, напоследок, хочу добавить следующее:
Начну с того, что когда я учился в университете БГУИР в далеком 2009 году, я всегда думал, что все вокруг меня пишут на C/C++. А значит и мне надо учить этот язык, чтобы устроиться на работу.
Потом я работал в компании Godel Technologies, где большинство проектов были написаны на C#, причем количество проектов этих только увеличивалось со временем, а проектов по Java уменьшалось здесь. И закрадывалась мысль, что вот-вот и C# поборет Java и нужно свичнуться на него побыстрее.
К чему это я?
А к тому, что нужно шире смотреть на вещи, а не на обстановку и людей вокруг тебя, потому что таким образом сильно сужается точка зрения. Но самое главное, что зачастую она не объективна и даже не верна (и это относится не только к программированию, а вообще ко всему).
Если хочется более объективной оценки, то лучше смотреть на вакансии в интересующем тебя регионе или на мировые рейтинги языков программирования, например, TIOBE или GitHub.
Лично я предпочитаю TIOBE, потому что он основан на анализе поисковых запросов по языку программирования, активности сообщества разработчиков, количестве вакансий и проектов. Он обновляется ежемесячно.
GitHub же не совсем объективен по моему мнению, потому что большинство компаний (тем более таких больших как MAANG) не держат там свой код. И, наоборот, студенты и фрилансеры активно его используют.
Также нужно обращать внимание на доменную область применения языка. Например, Python находится на первом месте в рейтингах потому, что сейчас нейронные сети и AI на хайпе. Но это не значит, что прикладные программы, enterprise, мобильные приложения и веб пишутся на нем с той же популярностью - это совсем не так. Эти области заняты другими языками.
Python - это обычно про data science и machine learning (и то он переписывается на C++, если нужно установить приложение на пользовательские устройства).
Что же касается изначального вопроса про Go - то, работая в компании Google, которая создала его, могу сказать, что он занял здесь лишь свою небольшую нишу. Так что до сих пор при выборе языка программирования для backend разработки новых сервисов - здесь предпочтительным является Java/Kotlin.
Теперь, напоследок, хочу добавить следующее:
Один язык не является фундаментально лучше или хуже другого. Выбор языка зачастую основывается на опыте инженеров, кто будет писать приложение, проблемной области, которую нужно решить, и уже построенной экосистемы внутри компании.
👍72🔥14❤🔥5
Ровно неделя до старта менторства DMdev!
Еще осталось:
- 2 места на 1 ступень (записаться)
- освободилось 1 место ко мне на 2 ступень! (записаться)
Если все еще сомневаешься идти или нет, то просто напиши по любым вопросам @karina_matveyenka
PS. Примеры финальных проектов, которые у вас будут по окончании менторства, можно посмотреть на YouTube:
- 1 ступень
- 2 ступень
Еще осталось:
- 2 места на 1 ступень (записаться)
- освободилось 1 место ко мне на 2 ступень! (записаться)
Если все еще сомневаешься идти или нет, то просто напиши по любым вопросам @karina_matveyenka
PS. Примеры финальных проектов, которые у вас будут по окончании менторства, можно посмотреть на YouTube:
- 1 ступень
- 2 ступень
🔥11👍7❤🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Самый младший студент на первой ступени менторства😁
Юбилейный 15ый старт двух ступеней состоялся 🎉
Впереди 3,5 месяца насыщенной и продуктивной работы!
Цель поставили, план наметили - осталось только действовать.
Спасибо каждому за доверие, let’s go 🚀
P.S. Для тех, кто любит прыгнуть в последний вагон -> еще два человека могут присоединиться
(писать @karina_matveyenka)
Юбилейный 15ый старт двух ступеней состоялся 🎉
Впереди 3,5 месяца насыщенной и продуктивной работы!
Цель поставили, план наметили - осталось только действовать.
Спасибо каждому за доверие, let’s go 🚀
P.S. Для тех, кто любит прыгнуть в последний вагон -> еще два человека могут присоединиться
(писать @karina_matveyenka)
🎉38🔥20😁9❤🔥4❤3⚡1👍1
Хочу завести новую рубрику: ответы на ваши анонимные вопросы 💻
Часто вопросы задаются в коментариях к постам, под разными видео.
Они теряются и порой остаются неотвеченными.
Теперь для ваших вопросов есть отдельное место, буду отвечать по возможности тут в телеграм канале или инстаграм https://www.instagram.com/denis.dmdev
P.S. Я не буду видеть, кто задал вопрос, они будут полностью анонимны.
Задать вопрос:
👇
https://forms.gle/FLHEHQ7GcSNjmtku5
Часто вопросы задаются в коментариях к постам, под разными видео.
Они теряются и порой остаются неотвеченными.
Теперь для ваших вопросов есть отдельное место, буду отвечать по возможности тут в телеграм канале или инстаграм https://www.instagram.com/denis.dmdev
P.S. Я не буду видеть, кто задал вопрос, они будут полностью анонимны.
Задать вопрос:
👇
https://forms.gle/FLHEHQ7GcSNjmtku5
Please open Telegram to view this post
VIEW IN TELEGRAM
Google Docs
Твой вопрос к DMdev
Здесь можно задать любой анонимный вопрос
Ответ можно будет увидеть в telegram канале https://t.me/dmdev_talks или instagram https://www.instagram.com/denis.dmdev
Ответ можно будет увидеть в telegram канале https://t.me/dmdev_talks или instagram https://www.instagram.com/denis.dmdev
👍41❤🔥6🤔2❤1
Отвечаю на #ВашВопрос
👇
В каком layer-е нужно маппить DTO? В сервисе или контроллере?
Обычно все происходит на уровне сервисов, где есть доступ к сущностям и еще открыта транзакция. Это позволяет предоставить в dto все необходимые данные, что часто требует выполнения новых запросов в СУБД.
На уровне контроллеров уже не должно быть транзакции, а значит:
- либо не получится так гибко сконструировать dto
- либо упадет какое-нибудь исключение (знаменитое LazyInitializationException)
- либо придется вызывать другие методы сервисов.
Также в большинстве случаев достаточно лишь одной dto на чтение одной сущности, чтобы в последующем передать ее клиенту по http или другому протоколу. Если же необходимы разные представления, то просто mapper/converter можно передать в качестве дополнительно параметра в метод сервиса, например:
А для тех, кто любит открывать транзакции выше уровня сервисов и ничего не видит плохого оставлять property spring.jpa.open-in-view: true - есть неплохая статья для прочтения.
👇
В каком layer-е нужно маппить DTO? В сервисе или контроллере?
Обычно все происходит на уровне сервисов, где есть доступ к сущностям и еще открыта транзакция. Это позволяет предоставить в dto все необходимые данные, что часто требует выполнения новых запросов в СУБД.
На уровне контроллеров уже не должно быть транзакции, а значит:
- либо не получится так гибко сконструировать dto
- либо упадет какое-нибудь исключение (знаменитое LazyInitializationException)
- либо придется вызывать другие методы сервисов.
Также в большинстве случаев достаточно лишь одной dto на чтение одной сущности, чтобы в последующем передать ее клиенту по http или другому протоколу. Если же необходимы разные представления, то просто mapper/converter можно передать в качестве дополнительно параметра в метод сервиса, например:
// Это использование дефолтного маппера
public Optional<UserReadDto> findById(Long id) {
return userRepository.findById(id)
.map(userReadMapper::map);
}
// Это использование динамического маппера, переданного с контроллера
public Optional<T> findById(Long id, Mapper<User, T> mapper) {
return userRepository.findById(id)
.map(mapper::map);
}
А для тех, кто любит открывать транзакции выше уровня сервисов и ничего не видит плохого оставлять property spring.jpa.open-in-view: true - есть неплохая статья для прочтения.
👍48❤🔥7🔥6❤2
Когда ты только начинаешь заниматься программированием, то что бы ты ни делал - это будет улучшать твои навыки. Даже смежные темы, например, решение примеров по алгебре или геометрии за 8 класс - улучшат твое мышление в программировании. Поэтому, конечно же, такой быстрый прогресс очень сильно может замотивировать: сравнительно мало усилий прилагается для сравнительно большого результата.
Но с течением времени таких зон для улучшений становится все меньше и меньше. И, наоборот, сил и времени приходится тратить все больше и больше, чтобы спрогрессировать хотя бы на чуть-чуть. Более того, ты не всегда даже понимаешь, что может помочь тебе в этом (или просто уже не хочешь). Это ведет к тому, что на каком-то этапе, у всех по разному, человек может остановиться и не развиваться дальше. У кого-то это на уровне Junior, у кого-то Middle, у кого-то Senior.
Следующий интересный факт: навыки притупляются без использования. А значит для поддержания какого-то определенного уровня нужно постоянно выполнять какой-то минимум работ. Например, если у тебя когда-то алгоритмы отлетали назубок, то через пару лет без практики тебе придется неплохо так попотеть, чтобы просто повернуть односвязный список. И, наоборот, решая по 1-2 задачке в неделю будет достаточно, чтобы на протяжении долго времени держать этот навык в тонусе.
Но есть и хорошая новость: достигнув какого-то уровня, например, Lead, очень легко и с гораздо меньшими затраченными усилиями потребуется, чтобы вновь оказаться там после долгого перерыва.
Но с течением времени таких зон для улучшений становится все меньше и меньше. И, наоборот, сил и времени приходится тратить все больше и больше, чтобы спрогрессировать хотя бы на чуть-чуть. Более того, ты не всегда даже понимаешь, что может помочь тебе в этом (или просто уже не хочешь). Это ведет к тому, что на каком-то этапе, у всех по разному, человек может остановиться и не развиваться дальше. У кого-то это на уровне Junior, у кого-то Middle, у кого-то Senior.
Следующий интересный факт: навыки притупляются без использования. А значит для поддержания какого-то определенного уровня нужно постоянно выполнять какой-то минимум работ. Например, если у тебя когда-то алгоритмы отлетали назубок, то через пару лет без практики тебе придется неплохо так попотеть, чтобы просто повернуть односвязный список. И, наоборот, решая по 1-2 задачке в неделю будет достаточно, чтобы на протяжении долго времени держать этот навык в тонусе.
Но есть и хорошая новость: достигнув какого-то уровня, например, Lead, очень легко и с гораздо меньшими затраченными усилиями потребуется, чтобы вновь оказаться там после долгого перерыва.
🔥34👍14❤4❤🔥4💯3
☝️Лазейка, как купить пакет из всех моих курсов со скидкой 67% и получить в подарок участие в первом закрытом вебинаре «Микросервисы» 🎁
Сейчас:14.999 rub на полгода
18 марта: 4.999 rub на год
ПРАЗДНИЧНАЯ РАСПРОДАЖА
Сейчас:
18 марта: 4.999 rub на год
ПРАЗДНИЧНАЯ РАСПРОДАЖА
🔥67👍13❤3🤩3💩2🏆2