Считаю, что если к собеседованию нужно готовиться - а тем более, готовиться несколько месяцев - процесс найма не может считаться хорошим. Сейчас полно специально обученных людей и курсов, которые учат проходить собеседования, а не дают хотя бы минимальные академическое знания. Человек, который учился проходить собеседования будет уметь проходить собеседования. А дальше - как повезет.
Проведу аналогию со обучением студентов. Экзамен, который должен рассматриваться как срез знаний, проверка того, что человек выучил, давно дискредитировал себя. Что важнее - проверить, какие знания получил человек за год в учёбы или как хорошо он зазубрил билеты и научился на них отвечать? Очевидно, система образования должна делать упор на первое. Собственно, гуглы и их подражатели превратили собеседование в экзамен к которому можно/нужно подготовиться. Отражает ли он реальную пригодность кандидатов? Как повезет.
Человек, который умеет быстро разобраться в сложной ситуации может не иметь никакого отношения к академическим знаниям в точных науках - буквально месяц назад собеседовал бывшего следователя, который переквалифицировался в разработчика - невероятно острый ум и чёткая логика при отсутствии богатого прикладного опыта.
Статья выглядит не как развенчивание мифов, а как оправдание. Тезис о том, что нанимают ровно тех, кого надо - лукавство. Но понять вас могу - я бы тоже так сказал. Иначе придётся признать систему найма неэффективной, а труды высоких умов с тысячами лет человеко-часов напрасными.
Да, можно. Это сложно и неудобно, но можно так сделать. А всё потому, что при использовании оператора pivot со списком итоговые данные, по сути, должны быть развёрнуты из двухмерного представления в n-мерное. Как это должно выглядеть в таблице - честно, ума не приложу. Похоже, не один я - Oracle, к примеру, прибегает к помощи XML.
Не говоря уже о том, что писать и через join, и через запятую - это вообще что-то страшное. Да еще и с такими именами-алиасами, которые даже для примеров лучше никогда не использовать.
Порог вхождения != знание языка в целом. Легкие запросы научиться писать легко, языковых конструкций и ключевых слов не много, синтаксис тривиальный. Сложности начинаются много позже.
с преподавателем курсов по DBA/SQL PostgreSQL
Вашего преподавателя зовут Том Кайт Майкл Стоунбрейкер? Отдает каким-то бахвальством, честное слово.
Под низким порогом вхождения имелась ввиду простота синтаксиса языка структурированных запросов, а вовсе не реализацию драйверов под конкретные СУБД в бородатых годах :)
Забавляет, когда спрашивают, с какой версией Java работал. Блин, это ж не Angular и не Perl :)
Или вымораживают вопросы типа "а сколько лет работали с микросервисами" от людей, которые не знают, что это. Я чего, считал? Это ж не фреймворк какой даже...
вряд ли современный SQL сервер вообще уступает Ораклу
Насколько я в курсе, MS SQL никогда не ругали за плохой оптимизатор, как раз наоборот, хвалили, как и Oracle.
Удивляться люди начинают, когда тащат "ораклячие" запросы например на PostgreSQL - на малых данных подвоха не заметно, зато на проде все внезапно встаёт колом. Хотя на Oracle работало. Такое видел, хотя Pg активно развивается, может, уже и такого не бывает.
сделать запрос SELECT TOP 10
В Oracle, если не изменяет память, версии так с 12-ой (которая 2013 года), добавили limit и offset, так что можно обойтись без извращений с rownum. 9-ка это что-то совсем уж старое.
SQL имеет весьма низкий порог вхождения и подкупает простотой, отсюда такие "перлы". А какой-нибудь Oracle за счёт мощного оптимизатора ещё и "прощает" подобное. До поры до времени.
Сам ни раз писал видел запросы, от которых волосы на спине начинают шевелиться.
Увидел просто десять пунктов - подзаголовков в статье.
Модульное и интеграционное тестирование — это два наиболее важных вида тестирования...
И далее про интеграционное тестирование особо ничего не сказано, настолько оно, по всей видимости, важно.
Зато есть целых несколько абзацев про автогенераторы тестов, кои приспособить к проекту целая отдельная наука.
После прочтения осталось странное ощущение - с одной стороны ничего нового не узнал, с другой - материал выглядит сумбурно, неструктурированно, так что и старые знания не освежил.
в качестве примера попробуйте набросать на CompletableFuture код который выполняет асинхронный ввод-вывод, ждёт результатов не съедая время потока (т.е. неблокирующе) и написать продолжение обработки после получения результатов.
Если ваша ремарка апеллирует к сложности такого кода — не согласен. Если к сложности понимания как его писать, используя CompletableFuture — да, есть такое, с библиотекой надо разбираться.
С другой стороны — асинхронность это всегда сложно, уже исходя из своей сути. Я бы подчеркнул, что в экосистеме есть вменяемый, но не самый простой для понимания инструмент, который, к тому же худо-бедно развивается (Future -> CompletableFuture).
Некоторые базы поддерживают настоящую реактивность, но скажем Постгрес — нет
Таки Pg умеет в реактивщину. Вероятно, вы имели ввиду, что у данной СУБД нет асинхронного API.
— Теперь расскажите мне, что же должно быть на аналогичной табличке от пришельцев, чтоб мы всей планетой решили, что нам объявили войну и проигнорировали весь контекст послания?
— Что-то не то про Аллаха.
Легковесные потоки? Null-безопасность? Функции-расширения? Свойства (в Java есть только псевдо-свойства)? Перегрузка операторов? Про лаконичность и функциональный уклон уже писали.
Вообще, мне кажется, это дело привычки и необходимости. Java вполне справляется со своими задача вот уже много лет и даже начала усиленно развиваться в последнее время.
Kotlin, несмотря на все свои плюсы, еще молод. Переходить на него "просто потому что" немного странно. Начать новый проект — почему бы и нет?
Сам не так давно начал работать с Groovy (параллельно с Java) — несмотря на то, что есть очевидные плюсы, многое из того, что использую в Java, не хватает. Что-то непривычно и не нравится (динамическая типизация, замыкания вместо уже привычных лямбд, статическая компиляция по желанию).
Был у меня как-то такой вопрос на собеседовании. И интервьюер как раз хотел услышать именно такой ответ, как вы и дали.
Пришлось ему объяснять, что
select count(g.id)
from group g
left join students s on s.group_id = g.id
where s.id is null
как правило (но не всегда!), проигрывает в производительности
select count(g.id)
from group g
where not exists (select null
from students s
where s.group_id = g.id)
Добавлю к этому очень немаловажный факт, что в разных СУБД и версиях этих СУБД (!), с разным количеством данных в таблицах и разными индексами на таблицах, могут быть разные планы и производительность этих двух запросов.
Вообще, тема anti-semi join довольно холиварная. Но я бы такой запрос, который вы привели как правильный, вежливо попросил бы переделать (откуда и для чего ограничение на подзапросы, если, конечно, речь не о какой-нибудь старенькой Firebird) — он предпочтительнее, чаще производительнее, так как нет тяжелого «left join» и, в конце-то концов, зачем вам тащить «студентов» наверх, если вы их используете только как условие для отбора данных?
Для тех, кому интересно — есть до неприличия простой способ создания REST API — через Spring Data REST. Плюс сервис можно укомплектовать каким-нибудь The HAL Browser — сразу и тестирование из коробки.
Oracle — sysdate, в PostgreSQL — now(), в MySQL — now(), curdate(), MsSQL — getdate.
А вот ANSI SQL знает вот такое CURRENT_TIMESTAMP. По идее, должна работать везде (проверил на Oracle и PostgreSQL ).
Считаю, что если к собеседованию нужно готовиться - а тем более, готовиться несколько месяцев - процесс найма не может считаться хорошим. Сейчас полно специально обученных людей и курсов, которые учат проходить собеседования, а не дают хотя бы минимальные академическое знания. Человек, который учился проходить собеседования будет уметь проходить собеседования. А дальше - как повезет.
Проведу аналогию со обучением студентов. Экзамен, который должен рассматриваться как срез знаний, проверка того, что человек выучил, давно дискредитировал себя. Что важнее - проверить, какие знания получил человек за год в учёбы или как хорошо он зазубрил билеты и научился на них отвечать? Очевидно, система образования должна делать упор на первое. Собственно, гуглы и их подражатели превратили собеседование в экзамен к которому можно/нужно подготовиться. Отражает ли он реальную пригодность кандидатов? Как повезет.
Человек, который умеет быстро разобраться в сложной ситуации может не иметь никакого отношения к академическим знаниям в точных науках - буквально месяц назад собеседовал бывшего следователя, который переквалифицировался в разработчика - невероятно острый ум и чёткая логика при отсутствии богатого прикладного опыта.
Статья выглядит не как развенчивание мифов, а как оправдание. Тезис о том, что нанимают ровно тех, кого надо - лукавство. Но понять вас могу - я бы тоже так сказал. Иначе придётся признать систему найма неэффективной, а труды высоких умов с тысячами лет человеко-часов напрасными.
Опять квизы под вопросы замаскировали. Ну, такое. На любителя.
Да, можно. Это сложно и неудобно, но можно так сделать. А всё потому, что при использовании оператора pivot со списком итоговые данные, по сути, должны быть развёрнуты из двухмерного представления в n-мерное. Как это должно выглядеть в таблице - честно, ума не приложу. Похоже, не один я - Oracle, к примеру, прибегает к помощи XML.
Не говоря уже о том, что писать и через join, и через запятую - это вообще что-то страшное. Да еще и с такими именами-алиасами, которые даже для примеров лучше никогда не использовать.
Порог вхождения != знание языка в целом. Легкие запросы научиться писать легко, языковых конструкций и ключевых слов не много, синтаксис тривиальный. Сложности начинаются много позже.
Вашего преподавателя зовут
Том КайтМайкл Стоунбрейкер? Отдает каким-то бахвальством, честное слово.Под низким порогом вхождения имелась ввиду простота синтаксиса языка структурированных запросов, а вовсе не реализацию драйверов под конкретные СУБД в бородатых годах :)
Забавляет, когда спрашивают, с какой версией Java работал. Блин, это ж не Angular и не Perl :)
Или вымораживают вопросы типа "а сколько лет работали с микросервисами" от людей, которые не знают, что это. Я чего, считал? Это ж не фреймворк какой даже...
Насколько я в курсе, MS SQL никогда не ругали за плохой оптимизатор, как раз наоборот, хвалили, как и Oracle.
Удивляться люди начинают, когда тащат "ораклячие" запросы например на PostgreSQL - на малых данных подвоха не заметно, зато на проде все внезапно встаёт колом. Хотя на Oracle работало. Такое видел, хотя Pg активно развивается, может, уже и такого не бывает.
В Oracle, если не изменяет память, версии так с 12-ой (которая 2013 года), добавили limit и offset, так что можно обойтись без извращений с rownum. 9-ка это что-то совсем уж старое.
SQL имеет весьма низкий порог вхождения и подкупает простотой, отсюда такие "перлы". А какой-нибудь Oracle за счёт мощного оптимизатора ещё и "прощает" подобное. До поры до времени.
Сам ни раз
писалвидел запросы, от которых волосы на спине начинают шевелиться.Десять лучших практик...
Увидел просто десять пунктов - подзаголовков в статье.
Модульное и интеграционное тестирование — это два наиболее важных вида тестирования...
И далее про интеграционное тестирование особо ничего не сказано, настолько оно, по всей видимости, важно.
Зато есть целых несколько абзацев про автогенераторы тестов, кои приспособить к проекту целая отдельная наука.
После прочтения осталось странное ощущение - с одной стороны ничего нового не узнал, с другой - материал выглядит сумбурно, неструктурированно, так что и старые знания не освежил.
Все это вполне пишется. Примеры.
Если ваша ремарка апеллирует к сложности такого кода — не согласен. Если к сложности понимания как его писать, используя CompletableFuture — да, есть такое, с библиотекой надо разбираться.
С другой стороны — асинхронность это всегда сложно, уже исходя из своей сути. Я бы подчеркнул, что в экосистеме есть вменяемый, но не самый простой для понимания инструмент, который, к тому же худо-бедно развивается (Future -> CompletableFuture).
Таки Pg умеет в реактивщину. Вероятно, вы имели ввиду, что у данной СУБД нет асинхронного API.
— Теперь расскажите мне, что же должно быть на аналогичной табличке от пришельцев, чтоб мы всей планетой решили, что нам объявили войну и проигнорировали весь контекст послания?
— Что-то не то про Аллаха.
Легковесные потоки? Null-безопасность? Функции-расширения? Свойства (в Java есть только псевдо-свойства)? Перегрузка операторов? Про лаконичность и функциональный уклон уже писали.
Вообще, мне кажется, это дело привычки и необходимости. Java вполне справляется со своими задача вот уже много лет и даже начала усиленно развиваться в последнее время.
Kotlin, несмотря на все свои плюсы, еще молод. Переходить на него "просто потому что" немного странно. Начать новый проект — почему бы и нет?
Сам не так давно начал работать с Groovy (параллельно с Java) — несмотря на то, что есть очевидные плюсы, многое из того, что использую в Java, не хватает. Что-то непривычно и не нравится (динамическая типизация, замыкания вместо уже привычных лямбд, статическая компиляция по желанию).
Пришлось ему объяснять, что
как правило (но не всегда!), проигрывает в производительности
Добавлю к этому очень немаловажный факт, что в разных СУБД и версиях этих СУБД (!), с разным количеством данных в таблицах и разными индексами на таблицах, могут быть разные планы и производительность этих двух запросов.
Вообще, тема anti-semi join довольно холиварная. Но я бы такой запрос, который вы привели как правильный, вежливо попросил бы переделать (откуда и для чего ограничение на подзапросы, если, конечно, речь не о какой-нибудь старенькой Firebird) — он предпочтительнее, чаще производительнее, так как нет тяжелого «left join» и, в конце-то концов, зачем вам тащить «студентов» наверх, если вы их используете только как условие для отбора данных?
Отличная статья. Спасибо за понятное изложение. Вопрос не по теме — зачем ToString, Data ведь уже включает его?
Вроде как нет. На практике ни разу не встречал, если честно.
А вот ANSI SQL знает вот такое CURRENT_TIMESTAMP. По идее, должна работать везде (проверил на Oracle и PostgreSQL ).