Мне попалось одно исследование, которое уверяет, что использование светлой темы повышает продуктивность. Испытуемым нужно было выполнять два типа задач:
— написанные чёрным по белому;
— написанные белым по чёрному.
В итоге было обнаружено, что испытуемые легче выполняли задания, когда экраны находились в режиме положительной полярности.
Сразу претензии:
1) темные темы — это, как правило, темно-серый фон, а не черный.
2) Сколько времени длился тест? Было ли исследование на скорость выполнения задач в конце 8-часового рабочего дня?
3) Есть ли исследование того, насколько легко различаются цвета на темном фоне? Мне чисто субъективно проще различать цвета на темном фоне, чем на светлом. А для программирования это очень важно.
Пока, судя по всему, именно к программированию это исследование неприменимо. Моя версия — в темной теме ниже контрастность, и, как следствие, ниже утомляемость.
Моду, заботу о выгорании экранов и влияние внешнего света тоже можно исключать. Я в 99-м году не знал ни о моде, ни о выгорании мониторов, но исправно настраивал себе темную тему в Турбопаскале (а выше в каментах отметились еще несколько таких же, как я). Также я предпочитаю темную тему даже днем в офисе, а ночью все равно не работаю при выключенном верхнем свете (всегда включаю). А когда солнце светит так, что на экране плохо видно, то оно и в светлой теме плохо видно, имхо.
Это сработает только тогда, когда автор робота знает об этих параметрах… Я, например, не знал, так что если бы я писал бота для сканирования страниц, я бы плевал на эти параметры с высокой колокольни. Не со зла, конечно, но владельцу сайта от этого не легче. И что-то мне подсказывает, что 99% ботов пишут ламеры типа меня…
Может расскажете чем пользуются они при тестировании?
Чем-то на руби, видимо, упомянутым выше ruby-plsql-spec.
Есть еще как минимум целый пласт банковского ПО на основе Oracle.
Целый блок банковского ПО, может быть, и есть, но ИТ в банках, как правило, очень отсталое и убого организованное. Тестирование, например, часто отсутствует как класс (в смысле, как отдельный процесс). Просто конечный продукт дают какому-нибудь специально выделенному бизнес-пользователю, и тот какое-то время тыкает на кнопочки в интерфейсике.
Я работал в 4 разных банках, если что.
Решение utPLSQL было создано в 2016 году, но над ним продолжают активно работать и выпускать новые версии.
Лолшто Опечатка, наверное. Когда я искал фреймворки для тестирования PL/SQL в далеком 2013-м, utPLSQL уже существовал. Он как минимум лет на 10 старше.
А вообще похвальное начинание, я теперь знаю целых две компании, которые тестируют PL/SQL. Глядишь, и до остальных когда-нибудь дойдет.
Я тоже так могу, кстати
Я свой собственный фреймворк сделал в том же 2013-м и он у меня даже работал в продакшене, только об этом не знал никто, включая мое начальство, потому что им было тупо пофиг. Частная инициатива, так сказать. Хорошо хоть не наказали ;)
Паттерны проектирования — это просто типовые решения типовых задач, только и всего (а чтобы не путаться, вместо слова «паттерн» употребляйте более привычное русскому уху слово «шаблон»). Зло появляется, когда в них пытаются увидеть что-то большее, от этого происходят всякие бессмысленные холивары, как у вас с Kanut.
Спрашивайте сотрудников и кандидатов о результатах на текущем месте или за последние несколько лет. «Обожаю» кейсы, когда человек отработал в компании 5 лет, а на вопрос о достижениях отвечает, что за 5 лет ничего не достиг, так как «работу работал».
Это место лучше было бы поподробнее расписать, что именно вы хотели тут сказать, увидеть, как правильно, etc.
У меня был опыт работы на проекте, который внедрили за 4 года до моего прихода. Я полтора года фиксил баги, делал мелкие доработки и прочее в таком духе. Достижения чего-либо в принципе не были предусмотрены сутью проекта. Я именно что «работу работал». В чем именно ваша претензия к такой работе? Единственное, на мой взгляд, что можно предъявить человеку в такой ситуации — «почему ты пять лет тут сидишь и занимаешься этой скукотенью?», но даже в этом случае у него есть право ответить: «не твое собачье дело».
В моем случае, я просто свалил через полтора года, хотя, если бы не покупка новой квартиры и ремонт, свалил бы на полгода раньше.
Первые попытки наладить связь с координаторами программы с целью ухода из Сбертеха были безуспешными. Координатор нашей программы ответила через 2 недели что-то в духе «Я уволилась, звоните по такому-то телефону». Позвонив по данному телефону ничего нового я не узнал, скорее сообщил человеку на новом месте, что существуют студенты, наставники, курсы и прочее.
В госучреждениях/госкомпаниях это скорее правило, чем исключение. Просто запомните это на будущее, чтобы каждый раз заново не удивляться.
со слов преподавателей из МИФИ, которые до подписания нами договора уверяли, что «договор — это формальность, не понравится — уйдёте, надо пробовать».
В общем и целом — да, «договор — это просто формальность». Только учтите при этом, что разговоры с преподавателями МИФИ, организаторами/координаторами Сбертеха и т. п. — это просто слова. Когда вы кого-то о чем-то спрашиваете, первое, что вы должны себя спросить: «А что ему будет, если он мне соврет, а потом все об этом узнают?» В вашем случае ответ очевиден — ничего им не будет. Поэтому им даже мозг включать не надо, чтобы что-то вам ответить, они ляпнут первое, что придет в голову, и пойдут себе дальше, а вы останетесь разгребать.
Если вы с кем-то подписали договор, и договор касается денежных отношений, то деньги с вас силой сдерут (ну или вы с кого-то сдерете) только через суд, а суд руководствуется действующим законодательством и текстом договора. Разговоры с кем попало юридической силы не имеют.
Только система взаимодействия Сбертеха с вузом и студентами нуждается во внимании и пересмотре.
Судя по тому, что написано в вашей статье — ничего там пересматривать не надо. У студентов есть возможность поучиться на халяву и свалить в туман, а проблемой это будет только для Сбертеха. Ну так они это вполне заслужили, не хватало только решать забесплатно их проблемы.
А мысль была в том, что SQL сам мог бы компилировать циклы в запросы.
В SQL нет никаких циклов. Циклы есть в процедурных расширениях, которые у каждой СУБД свои и никак абсолютно не стандартизированы. А внутри процедуры может твориться что угодно, и, в общем случае, задача догадаться, что из происходящего внутри можно превратить в запрос, выглядит совершенно не решаемой.
Немногие это замечают, но логика, влияющая на то, какие записи окажутся в результирующей таблице в SQL, разделена на 2 части
По-моему, как раз наоборот. ВСЕ замечают, что логика разделена на две части, но не все сразу умеют правильно её готовить. Я поначалу тоже писал всё в WHERE:
select ...
from a, b, c, d, e
where a.column1 = b.column1
and b.column2 = c.column2
and c.column3 = d.column3
and d.column4 = e.column4
and a.column123 = 456
and b.column987 = 'ququ'
and ... -- и еще 100500 условий
А потом оказалось, что сложные запросы, написанные кем-то другим, а то и самим собой, но очень давно, (ВНЕЗАПНО!) нужно отлаживать и рефакторить. И вот в длинной трехстраничной портянке начинаешь разбираться — где условия соединения, где логика, где чё. Потом условия соединения сами собой кучкуются вместе, а потом уползают в секцию FROM, чтобы не мешались.
select ...
from a
join b on a.column1 = b.column1
join c on b.column2 = c.column2
join d on c.column3 = d.column3
join e on d.column4 = e.column4
where a.column123 = 456
and b.column987 = 'ququ'
and ... -- и еще 100500 условий
Потом появляется вишенка на торте. Оказывается, что записей какое-то не такое количество, поэтому нужно закомментить все, кроме одной таблицы, а потом приджойнивать остальные по одной. И оказывается, что если все условия соединения описаны во FROM, то решается эта проблема исключительно просто:
select ...
from a
-- join b on a.column1 = b.column1
-- join c on b.column2 = c.column2
-- join d on c.column3 = d.column3
-- join e on d.column4 = e.column4
where a.column123 = 456
and b.column987 = 'ququ'
and ... -- и еще 100500 условий
То есть добавить/убрать таблицу к запросу — это всего один комментарий. Сравните с тем, что будет, когда все условия идут вперемешку в WHERE.
Короче, я лично транклюкирую ту гадину, которая такую возможность у меня отнимет [сатанинский хохот за кадром]
Так а что делать если у вас написана хранимка, и ее надо для 1000 записей вызвать?
Я тоже не понял, в чем заключается проблема N+1.
1. Если у вас есть хранимка, и ее надо один раз выполнить для 1000 записей, то берете и выполняете.
2. Если у вас была хранимка, которая выполнялась для одной записи, а теперь нужно будет регулярно выполнять ее для 1000 записей, значит, у вас изменились требования и код надо дописывать/переписывать. А раз все равно надо переписывать, то переписываем хранимку так, чтобы ее можно было выполнить для любого числа записей от 1 до 1000 (в идеале — до плюс бесконечности).
Читая статью, где-то с середины начал представлять, что эту историю рассказывает хохотун от лица какого-нибудь продакт-менеджера Микрософта. Рассказ заиграл новыми красками :)))
Они не понимают, зачем нужны артикли, a про 12 времен и говорить не стоит – как может в языке быть 12 времен? Если это в языке есть, значит в этом есть логика, вот только ее никто не объясняет.
Даже просто о том, что в языке есть логика, никто не говорит.
Лично мне очень помогла научно-популярная книга Плунгяна «Почему языки такие разные». И зачем нужны артикли, и зачем 12 времен, и многое другое. Там хоть и не рассказывается о конкретных языках (просто приводятся отдельные примеры), но учить языки помогает. То есть начинаешь понимать, что для общения нужно уметь выражать некоторый набор идей, а потом понимаешь, как эти идеи в целом выражаются на изучаемом языке. Очень рекомендую.
Увы мне, боярин.
Допустим, есть пять таблиц, связанных друг с другом. В одном запросе данные нужны из 1 и 2, в другом — из 3, 4 и 5, а потом из всех вместе. И так далее. Слишком много комбинаций.
Сомневаюсь, что кто-то из минусующих вообще смотрел видео.
Я вообще хотел только мельком коменты глянуть и дальше пойти, но, увидев ваш комент, посмотрел немного видео (не всё, а только половину примерно) и теперь тоже могу минусануть от чистого сердца.
Во-первых, для видео есть youtube. Продвигайте канал, и его будут смотреть все, кому это интеесно. А на Хабре мне хочется читать.
Во-вторых, вступление про темную материю. Я немного интересовался этой темой (включая общение с профессиональными астономами на научно-популярных сайтах), и там всё сложно. Если нет под рукой профессионального физика или астронома, который подкорректирует текст, если что, лучше не писать ничего вообще. А пока складывается ощущение типа «солидная фирма возьет в аренду дырокол».
В-третьих, очень много воды. Для объяснения отвлеченного вопроса (что такое метаданные) девушка несколько минут рассказывала байку про чувака из ЮАР, к адресу которого оказались привязны 90 миллионов айпишников, а объяснять один из ключевых вопросов видео (про 80% неиспользуемых данных) не стала вообще. Просто сказала, что «есть исследования». Кто, где и как их проводил, примеры таких данных — вам знать не обязательно.
На SQL это напишет любой дурак, потому что задача — элементарная (для SQL).
А вот в чем смысл вашей функциональной модели и чем она лучше — я так и не понял. Вы придумали для нее синтаксис, но явно забыли придумать все остальное.
Я сразу скажу: я в ОРМах не разбираюсь, никогда ими не пользовался, так что знаю только то, что Мойша напел. Типа как в этой статье. А поёт Мойша гнусаво, и в ноты не попадает. И знает только три блатных аккорда.
Вот тут главное, что мне не нравится в ОРМах. Есть некоторое количество разных СУБД. С разными фичами. И тут мы такие берем ОРМ, который работает со всеми универсально, и в итоге получается, что доступны только те фичи, которые есть у всех. То есть самая крутая и навороченная СУБД за сотни нефти низводится до самой дешманской, потому что «у нас же лапки ОРМ».
В том же оракле, например, есть кеширование сиквенсов. Я сам лично сталкивался с проблемой, когда (слава богу, никаких ОРМов не бло) поднятие кэша с дефолтных 20 до 1000 прекрасно убирало все проблемы с доступом к сиквенсу. А тут получается так: сначала платим 100500 денег за СУБД, потом берем ОРМ, а потом оказывается, что чукча обманул таксиста.
И да, хибернейт по дефолту не рассчитан на параллельную модификацию базы чужими приложениями. Это необходимое условие для работы его знаменитых кешей первого и второго уровня.
Ваши слова меня огорчают. 40 лет развития многопользовательского доступа в СУБД закончились тем, что «а давайте работать с БД в однопользовательском режиме».
Я всё еще надеюсь, что это просто я что-то не понимаю, и мне кто-нибудь объяснит.
Я только за!!! ;)
1) темные темы — это, как правило, темно-серый фон, а не черный.
2) Сколько времени длился тест? Было ли исследование на скорость выполнения задач в конце 8-часового рабочего дня?
3) Есть ли исследование того, насколько легко различаются цвета на темном фоне? Мне чисто субъективно проще различать цвета на темном фоне, чем на светлом. А для программирования это очень важно.
Пока, судя по всему, именно к программированию это исследование неприменимо. Моя версия — в темной теме ниже контрастность, и, как следствие, ниже утомляемость.
Моду, заботу о выгорании экранов и влияние внешнего света тоже можно исключать. Я в 99-м году не знал ни о моде, ни о выгорании мониторов, но исправно настраивал себе темную тему в Турбопаскале (а выше в каментах отметились еще несколько таких же, как я). Также я предпочитаю темную тему даже днем в офисе, а ночью все равно не работаю при выключенном верхнем свете (всегда включаю). А когда солнце светит так, что на экране плохо видно, то оно и в светлой теме плохо видно, имхо.
То, что вам повезло, не значит, что всем остальным будет так же везти.
Целый блок банковского ПО, может быть, и есть, но ИТ в банках, как правило, очень отсталое и убого организованное. Тестирование, например, часто отсутствует как класс (в смысле, как отдельный процесс). Просто конечный продукт дают какому-нибудь специально выделенному бизнес-пользователю, и тот какое-то время тыкает на кнопочки в интерфейсике.
Я работал в 4 разных банках, если что.
ЛолштоОпечатка, наверное. Когда я искал фреймворки для тестирования PL/SQL в далеком 2013-м, utPLSQL уже существовал. Он как минимум лет на 10 старше.А вообще похвальное начинание, я теперь знаю целых две компании, которые тестируют PL/SQL. Глядишь, и до остальных когда-нибудь дойдет.
У меня был опыт работы на проекте, который внедрили за 4 года до моего прихода. Я полтора года фиксил баги, делал мелкие доработки и прочее в таком духе. Достижения чего-либо в принципе не были предусмотрены сутью проекта. Я именно что «работу работал». В чем именно ваша претензия к такой работе? Единственное, на мой взгляд, что можно предъявить человеку в такой ситуации — «почему ты пять лет тут сидишь и занимаешься этой скукотенью?», но даже в этом случае у него есть право ответить: «не твое собачье дело».
В моем случае, я просто свалил через полтора года, хотя, если бы не покупка новой квартиры и ремонт, свалил бы на полгода раньше.
В общем и целом — да, «договор — это просто формальность». Только учтите при этом, что разговоры с преподавателями МИФИ, организаторами/координаторами Сбертеха и т. п. — это просто слова. Когда вы кого-то о чем-то спрашиваете, первое, что вы должны себя спросить: «А что ему будет, если он мне соврет, а потом все об этом узнают?» В вашем случае ответ очевиден — ничего им не будет. Поэтому им даже мозг включать не надо, чтобы что-то вам ответить, они ляпнут первое, что придет в голову, и пойдут себе дальше, а вы останетесь разгребать.
Если вы с кем-то подписали договор, и договор касается денежных отношений, то деньги с вас силой сдерут (ну или вы с кого-то сдерете) только через суд, а суд руководствуется действующим законодательством и текстом договора. Разговоры с кем попало юридической силы не имеют.
Судя по тому, что написано в вашей статье — ничего там пересматривать не надо. У студентов есть возможность поучиться на халяву и свалить в туман, а проблемой это будет только для Сбертеха. Ну так они это вполне заслужили, не хватало только решать забесплатно их проблемы.
А потом оказалось, что сложные запросы, написанные кем-то другим, а то и самим собой, но очень давно, (ВНЕЗАПНО!) нужно отлаживать и рефакторить. И вот в длинной трехстраничной портянке начинаешь разбираться — где условия соединения, где логика, где чё. Потом условия соединения сами собой кучкуются вместе, а потом уползают в секцию FROM, чтобы не мешались.
Потом появляется вишенка на торте. Оказывается, что записей какое-то не такое количество, поэтому нужно закомментить все, кроме одной таблицы, а потом приджойнивать остальные по одной. И оказывается, что если все условия соединения описаны во FROM, то решается эта проблема исключительно просто:
То есть добавить/убрать таблицу к запросу — это всего один комментарий. Сравните с тем, что будет, когда все условия идут вперемешку в WHERE.
Короче, я лично транклюкирую ту гадину, которая такую возможность у меня отнимет [сатанинский хохот за кадром]
1. Если у вас есть хранимка, и ее надо один раз выполнить для 1000 записей, то берете и выполняете.
2. Если у вас была хранимка, которая выполнялась для одной записи, а теперь нужно будет регулярно выполнять ее для 1000 записей, значит, у вас изменились требования и код надо дописывать/переписывать. А раз все равно надо переписывать, то переписываем хранимку так, чтобы ее можно было выполнить для любого числа записей от 1 до 1000 (в идеале — до плюс бесконечности).
Лично мне очень помогла научно-популярная книга Плунгяна «Почему языки такие разные». И зачем нужны артикли, и зачем 12 времен, и многое другое. Там хоть и не рассказывается о конкретных языках (просто приводятся отдельные примеры), но учить языки помогает. То есть начинаешь понимать, что для общения нужно уметь выражать некоторый набор идей, а потом понимаешь, как эти идеи в целом выражаются на изучаемом языке. Очень рекомендую.
Допустим, есть пять таблиц, связанных друг с другом. В одном запросе данные нужны из 1 и 2, в другом — из 3, 4 и 5, а потом из всех вместе. И так далее. Слишком много комбинаций.
Во-первых, для видео есть youtube. Продвигайте канал, и его будут смотреть все, кому это интеесно. А на Хабре мне хочется читать.
Во-вторых, вступление про темную материю. Я немного интересовался этой темой (включая общение с профессиональными астономами на научно-популярных сайтах), и там всё сложно. Если нет под рукой профессионального физика или астронома, который подкорректирует текст, если что, лучше не писать ничего вообще. А пока складывается ощущение типа «солидная фирма возьет в аренду дырокол».
В-третьих, очень много воды. Для объяснения отвлеченного вопроса (что такое метаданные) девушка несколько минут рассказывала байку про чувака из ЮАР, к адресу которого оказались привязны 90 миллионов айпишников, а объяснять один из ключевых вопросов видео (про 80% неиспользуемых данных) не стала вообще. Просто сказала, что «есть исследования». Кто, где и как их проводил, примеры таких данных — вам знать не обязательно.
А вот в чем смысл вашей функциональной модели и чем она лучше — я так и не понял. Вы придумали для нее синтаксис, но явно забыли придумать все остальное.
Вот тут главное, что мне не нравится в ОРМах. Есть некоторое количество разных СУБД. С разными фичами. И тут мы такие берем ОРМ, который работает со всеми универсально, и в итоге получается, что доступны только те фичи, которые есть у всех. То есть самая крутая и навороченная СУБД за сотни нефти низводится до самой дешманской, потому что «у нас же
лапкиОРМ».В том же оракле, например, есть кеширование сиквенсов. Я сам лично сталкивался с проблемой, когда (слава богу, никаких ОРМов не бло) поднятие кэша с дефолтных 20 до 1000 прекрасно убирало все проблемы с доступом к сиквенсу. А тут получается так: сначала платим 100500 денег за СУБД, потом берем ОРМ, а потом оказывается, что чукча обманул таксиста.
Ваши слова меня огорчают. 40 лет развития многопользовательского доступа в СУБД закончились тем, что «а давайте работать с БД в однопользовательском режиме».
Я всё еще надеюсь, что это просто я что-то не понимаю, и мне кто-нибудь объяснит.