Итак, на вопрос, можно ли наследовать класс Пингвин от класса Птица, большая часть людей ответили "да" или "нет".
На самом деле, если вам зададут такой вопрос на собеседовании, знайте: тут есть подвох.
Дело в том, что когда мы пишем программу, мы не оперируем настоящими животными, мы лишь моделируем их, т.е. строим модель для решения определенных задач, а не для всего на свете.
Пингвин и птица в разных бизнес-контекстах могут быть описаны совершенно по-разному.
Для учета количества крыльев и клювов (или кала, как подсказали в коментах) на квадратный километр территории - можно наследовать, без проблем.
Для учета перемещений животных в пространстве так не получится, потому что метод "летать" вызовет проблемы и костыли.
Более того, в одном и том же софте могут присутствовать сразу оба варианта. В различных bounded context могут быть разные модели.
Другой пример: пользователь, использующийся для проверки логина и пароля, и пользователь, для которого считают зарплату - это совершенно разные сущности, даже если у них id один и тот же. Их свойства могут храниться в разных таблицах. Наследоваться от чего-то или нет - решается в каждом конкретном случае.
На самом деле, если вам зададут такой вопрос на собеседовании, знайте: тут есть подвох.
Дело в том, что когда мы пишем программу, мы не оперируем настоящими животными, мы лишь моделируем их, т.е. строим модель для решения определенных задач, а не для всего на свете.
Пингвин и птица в разных бизнес-контекстах могут быть описаны совершенно по-разному.
Для учета количества крыльев и клювов (или кала, как подсказали в коментах) на квадратный километр территории - можно наследовать, без проблем.
Для учета перемещений животных в пространстве так не получится, потому что метод "летать" вызовет проблемы и костыли.
Более того, в одном и том же софте могут присутствовать сразу оба варианта. В различных bounded context могут быть разные модели.
Другой пример: пользователь, использующийся для проверки логина и пароля, и пользователь, для которого считают зарплату - это совершенно разные сущности, даже если у них id один и тот же. Их свойства могут храниться в разных таблицах. Наследоваться от чего-то или нет - решается в каждом конкретном случае.
👀1
Раст можно изучать и на русском языке:
Растбук https://doc.rust-lang.ru/book/
Rust by example: https://doc.rust-lang.ru/stable/rust-by-example/
Книга по асинхронному программированию: https://doc.rust-lang.ru/async-book
Лекции Кладова
https://www.youtube.com/playlist?list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e
Растбук https://doc.rust-lang.ru/book/
Rust by example: https://doc.rust-lang.ru/stable/rust-by-example/
Книга по асинхронному программированию: https://doc.rust-lang.ru/async-book
Лекции Кладова
https://www.youtube.com/playlist?list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e
Чем синьор отличается от джуна?
Помимо знания 100500 технологий и подходов, которые конечно же тоже важны, есть еще один пункт, который прям необходим, и про который почему-то редко говорят.
Это способность построить в голове модель того, что происходит в создаваемом софте. И помнить ее долго хотя бы в общих чертах.
Вам может быть насрать на выгоды бизнеса (привет, @fillpackart :) ), или вы наоборот упоролись и живете только работой. Вы можете знать или не знать детали реализации gc в jvm и вертетьна хую красно-черные деревья.
Это все неважно, если вы не можете натренировать свою серую нейросеть так, чтобы держать в голове систему в целом. То, что относится к той части софта, за которую вы отвечаете.
Вы можете сами преобразовывать бессмысленное бормотание заказчика в четкую модель или же натравить на это бизнес-аналитика или пиэма, который выдаст документацию.
Но все равно, пока в голове не "щелкнет", не уляжется понимание происходящего в целом, вы будете делать тупейшие ошибки и недоработки. Молча допиливать явную чушь из тз, потому что не поймете, что это чушь. Будете неправильно выделять сущности и абстракции в коде, потому что код - это и есть модель бизнес-процессов, записанная долбанутым компьютерным языком.
Различные подходы типа DDD помогают, но лишь отчасти, потому что без понимания системы, без заданных вовремя вопросов, точно также будут ошибочно выделены bounded contexts и сущности. Потом это придется переделывать, и в системе при этом останется дофига лишних зависимостей и странноватых названий.
Крутые шахматисты могут держать в голове десяток партий на сеансе одновременной игры.
Крутые синьорные программисты отсекут бредовую фичу еще на этапе предварительного обсуждения, задав пару правильных вопросов.
Способных держать модель в голове чаще делают тимлидами, даже если они хуже перформят в строчках кода в секунду.
Еще неплохо бы уметь объяснять происходящее другим: объясняя, лучше запоминаешь и выкристаллизовываешь суть.
Помимо знания 100500 технологий и подходов, которые конечно же тоже важны, есть еще один пункт, который прям необходим, и про который почему-то редко говорят.
Это способность построить в голове модель того, что происходит в создаваемом софте. И помнить ее долго хотя бы в общих чертах.
Вам может быть насрать на выгоды бизнеса (привет, @fillpackart :) ), или вы наоборот упоролись и живете только работой. Вы можете знать или не знать детали реализации gc в jvm и вертеть
Это все неважно, если вы не можете натренировать свою серую нейросеть так, чтобы держать в голове систему в целом. То, что относится к той части софта, за которую вы отвечаете.
Вы можете сами преобразовывать бессмысленное бормотание заказчика в четкую модель или же натравить на это бизнес-аналитика или пиэма, который выдаст документацию.
Но все равно, пока в голове не "щелкнет", не уляжется понимание происходящего в целом, вы будете делать тупейшие ошибки и недоработки. Молча допиливать явную чушь из тз, потому что не поймете, что это чушь. Будете неправильно выделять сущности и абстракции в коде, потому что код - это и есть модель бизнес-процессов, записанная долбанутым компьютерным языком.
Различные подходы типа DDD помогают, но лишь отчасти, потому что без понимания системы, без заданных вовремя вопросов, точно также будут ошибочно выделены bounded contexts и сущности. Потом это придется переделывать, и в системе при этом останется дофига лишних зависимостей и странноватых названий.
Крутые шахматисты могут держать в голове десяток партий на сеансе одновременной игры.
Крутые синьорные программисты отсекут бредовую фичу еще на этапе предварительного обсуждения, задав пару правильных вопросов.
Способных держать модель в голове чаще делают тимлидами, даже если они хуже перформят в строчках кода в секунду.
Еще неплохо бы уметь объяснять происходящее другим: объясняя, лучше запоминаешь и выкристаллизовываешь суть.
👀1
Golang Song
t.me/crossjoin
Я тут песенку сочинил про Golang. Очень простые слова, подпевай!
Ваш crossjoin
Ваш crossjoin
Audio
Cover версия нашей подписчицы NastyPasty в ответочку на https://news.1rj.ru/str/crossjoin/45
Книжка "Грокаем алгоритмы".
Смотрю оглавление:
- предисловие
- благодарности
- о книге
-- структура книги
-- как работать с книгой
-- для кого предназначена эта книга
-- Условные обозначения
-- об авторе
-- от издательства
- Глава1. Знакомство с алгоритмами
ну, думаю, задрали уже, но сейчас похоже наконец суть пойдет. А вот хуй:
-- Введение
-- Что вы узнаете об эффективности алгоритмов
-- Что вы узнаете о решении задач
сука, и только после этого началось про бинарный поиск.
Это какая-то жесть ))
Смотрю оглавление:
- предисловие
- благодарности
- о книге
-- структура книги
-- как работать с книгой
-- для кого предназначена эта книга
-- Условные обозначения
-- об авторе
-- от издательства
- Глава1. Знакомство с алгоритмами
ну, думаю, задрали уже, но сейчас похоже наконец суть пойдет. А вот хуй:
-- Введение
-- Что вы узнаете об эффективности алгоритмов
-- Что вы узнаете о решении задач
сука, и только после этого началось про бинарный поиск.
Это какая-то жесть ))
👀1
Станислав Осипов: "На собеседовании по Zoom кандидат включил рядом второй комп заранее, который все время работал в режиме голосового поиска по моим вопросам и его ответам. Комп кое-как заматчил только три из десятков вопросов. Кандидат ощущал провал затеи и очень страдал."
Хозяйке на заметку ))
Хозяйке на заметку ))
👀1
Гугл анонсировал Flutter2.
Основные новшества:
Flutter для web стал production-ready. PWA, SPA - вот это всё.
Алсо, Flutter запартнерился с Canonical и Microsoft, чтобы можно было делать десктопные приложения. Canonical даже пообещали для своих будущих приложений использовать флаттер как выбор номер 1.
Вообще, список девайсов был расширен: от складных устройств (а ля Surface Duo) до автомобилей (Toyota).
Ну а обычные андроиды и айфоны были поддержаны с самого начала. Теперь flutter можно считать полноценным кросплатформенным фреймворком
Основные новшества:
Flutter для web стал production-ready. PWA, SPA - вот это всё.
Алсо, Flutter запартнерился с Canonical и Microsoft, чтобы можно было делать десктопные приложения. Canonical даже пообещали для своих будущих приложений использовать флаттер как выбор номер 1.
Вообще, список девайсов был расширен: от складных устройств (а ля Surface Duo) до автомобилей (Toyota).
Ну а обычные андроиды и айфоны были поддержаны с самого начала. Теперь flutter можно считать полноценным кросплатформенным фреймворком
👀1
Jareny Petuh Driven Development (увидел где-то в фейсбуке)
👀1
Выше я где-то писал, что многих бесят гошные сокращения переменных. Действительно, есть такое негласное правило - чем короче, тем лучше. Однако всякие одно-двухбуквенные сокращения обычно применяют в локальном скоупе.
Т.е. ресивер или локальная переменная - это норма сократить log до l или writer до w - так как вы тут же видите, что это такое, какого типа и т.д. Однако, если вы достаете что-то из недр структуры, то названия должны быть, конечно, более говорящими.
Хотя Golang явно противопостовлялся Java с его бесконечными длинными названиями, но до маразма не нужно доходить.
Т.е. ресивер или локальная переменная - это норма сократить log до l или writer до w - так как вы тут же видите, что это такое, какого типа и т.д. Однако, если вы достаете что-то из недр структуры, то названия должны быть, конечно, более говорящими.
Хотя Golang явно противопостовлялся Java с его бесконечными длинными названиями, но до маразма не нужно доходить.
👍1👀1
Как готовиться к прохождению технического собеседования.
Так как подготовка к проведению собеса довольно трудоёмкое мероприятие, зачастую большая часть вопросов просто берется тупо из гугла. Поэтому вбиваете в гугл "%вашязык% вопросы на собеседовании" и учите по первым двум-трем ссылкам (дальше никто не пойдет, это трудоёмко). Еще имеет смысл вбить "задачи на собеседовании" и прорешать часто повторяющиеся. Чтобы покрыть любителей лайвкодинга.
Можно на двух языках, рус и англ, чтоб наверняка.
Это даст огромное преимущество на большинстве собесов, а времени займет не так много.
Ну и совет тимлидам. Спрашивать базовые вопросы все же наверно надо, но помимо этого нужно напирать на реальный опыт. "Какую интересную/сложную задачу ты решал, расскажи в деталях, что делал именно ты" - хорошая точка старта для беседы.
Например, один кандидат, который хорошо поначалу отвечал, на вопрос о сложной задаче выдал "писал запрос с джойнами", т.е. уровень оказался явно джуниорский.
Так как подготовка к проведению собеса довольно трудоёмкое мероприятие, зачастую большая часть вопросов просто берется тупо из гугла. Поэтому вбиваете в гугл "%вашязык% вопросы на собеседовании" и учите по первым двум-трем ссылкам (дальше никто не пойдет, это трудоёмко). Еще имеет смысл вбить "задачи на собеседовании" и прорешать часто повторяющиеся. Чтобы покрыть любителей лайвкодинга.
Можно на двух языках, рус и англ, чтоб наверняка.
Это даст огромное преимущество на большинстве собесов, а времени займет не так много.
Ну и совет тимлидам. Спрашивать базовые вопросы все же наверно надо, но помимо этого нужно напирать на реальный опыт. "Какую интересную/сложную задачу ты решал, расскажи в деталях, что делал именно ты" - хорошая точка старта для беседы.
Например, один кандидат, который хорошо поначалу отвечал, на вопрос о сложной задаче выдал "писал запрос с джойнами", т.е. уровень оказался явно джуниорский.
👀1
Рекурсивные CTE в Postgresql
Рекурсивные CTE нужны для работы с хитросвязанными между собой строками, например, для работы с деревьями
К примеру, у вас есть записи ( id, parent_id, name ), и вам надо построить поддерево для определенного id.
Как это всё работает.
На самоме деле, название "рекурсивные CTE" не совсем удачное, больше подошло бы "итеративное CTE".
Пример:
WITH RECURSIVE r AS (
SELECT id, parent_id, name
FROM geo
WHERE parent_id = 4
UNION
SELECT geo.id, geo.parent_id, geo.name
FROM geo
JOIN r
ON geo.parent_id = r.id
)
SELECT * FROM r;
Рекурсивный подзапрос должен состоять из двух частей, объединенных UNION
Первая часть (та что до UNION) - это так называемый anchor, он выполняется в начале, это первая итерация.
Далее в цикле выполняется вторая часть. Это очередная итерация, которая работает в связке с предыдущей (джойнится на результат предыдущей итерации).
Это всё работает до тех пор, пока очередная итерация не вернёт 0 строк результата.
Т.е. получается, что мы в первом запросе нашли все элементы где parent_id = 4, потом нашли элементы, где parent_id - это id из первого запроса, и т.д., пока не кончится.
В случае, если в таблице граф с циклическими связями, то эти итерации не кончатся никогда )
Для того, чтобы бороться с этой проблемой в postgres 14 будут сделаны дополнительные ключевые слова. Но об этом позже )
Рекурсивные CTE нужны для работы с хитросвязанными между собой строками, например, для работы с деревьями
К примеру, у вас есть записи ( id, parent_id, name ), и вам надо построить поддерево для определенного id.
Как это всё работает.
На самоме деле, название "рекурсивные CTE" не совсем удачное, больше подошло бы "итеративное CTE".
Пример:
WITH RECURSIVE r AS (
SELECT id, parent_id, name
FROM geo
WHERE parent_id = 4
UNION
SELECT geo.id, geo.parent_id, geo.name
FROM geo
JOIN r
ON geo.parent_id = r.id
)
SELECT * FROM r;
Рекурсивный подзапрос должен состоять из двух частей, объединенных UNION
Первая часть (та что до UNION) - это так называемый anchor, он выполняется в начале, это первая итерация.
Далее в цикле выполняется вторая часть. Это очередная итерация, которая работает в связке с предыдущей (джойнится на результат предыдущей итерации).
Это всё работает до тех пор, пока очередная итерация не вернёт 0 строк результата.
Т.е. получается, что мы в первом запросе нашли все элементы где parent_id = 4, потом нашли элементы, где parent_id - это id из первого запроса, и т.д., пока не кончится.
В случае, если в таблице граф с циклическими связями, то эти итерации не кончатся никогда )
Для того, чтобы бороться с этой проблемой в postgres 14 будут сделаны дополнительные ключевые слова. Но об этом позже )
Многое новое - это хорошо закомментированное старое
(из чатика SPb Reliability Meetup https://news.1rj.ru/str/spb_reliability )
(из чатика SPb Reliability Meetup https://news.1rj.ru/str/spb_reliability )
👀1
Forwarded from Технологический Болт Генона
Сегодня okmeter.io погорел вместе с дата-центром (https://habr.com/ru/news/t/546264/). Коллега пишет о DRP (https://news.1rj.ru/str/DOFH_ru/2411), а я вспомнил статью на Хабре про это
Готовим DRP — не забудьте учесть метеорит
https://habr.com/ru/company/ruvds/blog/523570/
ЗЫ Скрин не мой, скинули в личку
Готовим DRP — не забудьте учесть метеорит
https://habr.com/ru/company/ruvds/blog/523570/
ЗЫ Скрин не мой, скинули в личку
👀1
Записали выпуск "Цинкового прода" про рекурсивные CTE, выгорание, trunk-based dev и много чего еще
00:00 Приветствие
2:00 В PostgreSQL упал новый комит для рекурсивных CTE
20:17 Сгорел дата-центр OVHCloud
25:56 План сохранения онлайн бизнеса при пожаре в дата-центре
29:42 Про замедление работы Twitter Роскомнадзором
36:11 Выгорание - норма?
49:06 О мотивации к программированию
1:04:57 Налог на блогеров
1:08:10 Про Trunk Based и мертвый код
1:26:38 Как часто нужно менять работу/проекты, чтобы не впадать в стагнацию?
1:36:19 Red Hat и Google представили сервис для криптографической верификации кода
1:38:23 Любой ли команде нужен ресурсный менеджер?
https://www.youtube.com/watch?v=iQiCA7SUi2Y
00:00 Приветствие
2:00 В PostgreSQL упал новый комит для рекурсивных CTE
20:17 Сгорел дата-центр OVHCloud
25:56 План сохранения онлайн бизнеса при пожаре в дата-центре
29:42 Про замедление работы Twitter Роскомнадзором
36:11 Выгорание - норма?
49:06 О мотивации к программированию
1:04:57 Налог на блогеров
1:08:10 Про Trunk Based и мертвый код
1:26:38 Как часто нужно менять работу/проекты, чтобы не впадать в стагнацию?
1:36:19 Red Hat и Google представили сервис для криптографической верификации кода
1:38:23 Любой ли команде нужен ресурсный менеджер?
https://www.youtube.com/watch?v=iQiCA7SUi2Y
YouTube
#103 Рекурсивные CTE, выгорание, замедление твиттера
00:00 Приветствие
2:00 В PostgreSQL упал новый комит для рекурсивных CTE
20:17 Сгорел дата-центр OVHCloud
25:56 План сохранения онлайн бизнеса при пожаре в дата-центре
29:42 Про замедление работы Twitter Роскомнадзором
36:11 Выгорание - норма?
49:06 О…
2:00 В PostgreSQL упал новый комит для рекурсивных CTE
20:17 Сгорел дата-центр OVHCloud
25:56 План сохранения онлайн бизнеса при пожаре в дата-центре
29:42 Про замедление работы Twitter Роскомнадзором
36:11 Выгорание - норма?
49:06 О…
👀1
"Знание некоторых закономерностей освобождает от необходимости знать некоторые факты"
Как я уже написал, "схватывать суть" значит "отделять главное от второстепенного". Всех этому учили классе в пятом, на уроках литературы. Дают прочитать текст, а потом говорят написать по нему краткое изложение, обозначив основную суть. Когда ты маленький - это тебе кажется полной чушью, но с возрастом понимаешь важность таких упражнений. Теперь вам 25...40 и вы открываете документацию по какому-то неизвестному ранее фреймворку. Если вы - плохой разработчик, то вы бездумно копипастите примерчики и встаиваете в свой код. Но если вы ухватываете суть и понимаете зачем этот фреймворк, какую задачу он решает и как примерно это делает - то вам ни к чему держать открытой документацию. Вы уже знаете что "где-то тут должна быть вот такая вот функция" и можете предположить как она называется. В крайнем случае - вы лучше формулируете запрос в гугл. Потому что если вы не умеете видеть главное, видеть суть - то любая библиотека для вас это набор слабосвязанных функций. Половину рабочего времени вы будете проводить в гугле, хотя могли бы выдавать результат.
Коль скоро вы можете схватить суть кода и фреймворка, который вы используете - вы можете схватить суть и своего проекта. На практике это поможет осознать что, скажем, в данном конкретном случае можно обойтись одним php-файликом, а не городить конфиг вебпака на 50 экранов и поднимать кубокластер.
Вообще схватывание сути и работа именно на саму суть избавляет от кучи лишних телодвижений. Понимание сути во многом - есть правильное понимание цели чего бы вы там ни делали. А если вы хорошо представляете к чему вы идёте - у вас появляется знатно больше степеней свободы.
Как-то так.
(С) Pavel Novikov ( https://twitter.com/reinforced_sc )
Как я уже написал, "схватывать суть" значит "отделять главное от второстепенного". Всех этому учили классе в пятом, на уроках литературы. Дают прочитать текст, а потом говорят написать по нему краткое изложение, обозначив основную суть. Когда ты маленький - это тебе кажется полной чушью, но с возрастом понимаешь важность таких упражнений. Теперь вам 25...40 и вы открываете документацию по какому-то неизвестному ранее фреймворку. Если вы - плохой разработчик, то вы бездумно копипастите примерчики и встаиваете в свой код. Но если вы ухватываете суть и понимаете зачем этот фреймворк, какую задачу он решает и как примерно это делает - то вам ни к чему держать открытой документацию. Вы уже знаете что "где-то тут должна быть вот такая вот функция" и можете предположить как она называется. В крайнем случае - вы лучше формулируете запрос в гугл. Потому что если вы не умеете видеть главное, видеть суть - то любая библиотека для вас это набор слабосвязанных функций. Половину рабочего времени вы будете проводить в гугле, хотя могли бы выдавать результат.
Коль скоро вы можете схватить суть кода и фреймворка, который вы используете - вы можете схватить суть и своего проекта. На практике это поможет осознать что, скажем, в данном конкретном случае можно обойтись одним php-файликом, а не городить конфиг вебпака на 50 экранов и поднимать кубокластер.
Вообще схватывание сути и работа именно на саму суть избавляет от кучи лишних телодвижений. Понимание сути во многом - есть правильное понимание цели чего бы вы там ни делали. А если вы хорошо представляете к чему вы идёте - у вас появляется знатно больше степеней свободы.
Как-то так.
(С) Pavel Novikov ( https://twitter.com/reinforced_sc )