Константин koropovskiy

Вот «не школы не хотят» это видимо какие то отдельные школы, потому что по своему окружению (Питер, IT) ни одна школа чего то внятного не смогла организовать.
Побольше домашки, поменьше интерактива/общения вот и вся «удаленка».
и Д.О. Фактически было Домашним Обучением вместо Дистанционного образования.
Естественно ничего кроме негатива такое «образование» вызывать не может.

ЯКласс с достаточно обширным набором предметов и тем, включая началку.

infourok с их онлайн-школой?

Отдельно упомяну, хоть и врагу не пожелаешь, питерский ад для плохих учеников, называется рцокоит, точно какое то древнее проклятье.

Дождетесь же. Сделают ценники цифровыми, и будут по 10 раз в день менять.
А потом еще и таргетирование прикрутят ) чтобы ценник был индивидуальным

заметил что логотип 1в1 Plex, только фот белый

Черной черной ночью, на черной черной трассе, стоит черный черный знак 40, сразу за которым в черном черном кусте сидят черные черные гашники с черными черными палочками и штрафуют светлых и невинных водителей за превышение скорости.
а-ха-ха-ха

Нашел в конце статьи ссылку.

а как к тиону можно приделать шумоглушитель? у него же выходные отверстия уже для комнаты предназначены?

Браво, вы учли почти все правила. Осталось только
«Запрещена точка в конце сообщения. Лучше эмодзи или скобочка»
«Используй мемы/стикеры/гифки для передачи емких мыслей (согласен/сомневаюсь/восхищен). Они создают позитивное якорение у собеседника»

что-то вендоры реселлеры все напутали. Страшно брать.
В модели за 120к пишут Core i7 — 10510U, но 6 ядер… а в 10510 их 4
тактовая при этом 1.8 (как у 10510), но максимальная 4.7 (как к 10710)

а варианта с fullHD, но 6-ядерным процессором не будет?

.

Если «за раз» — то вообще не езжу, предпочитаю переезды не более 700-800 км за сутки.
А как это связано с соблюдением ПДД?

либо я читаю не там, либо вы уж очень вольно перевели.

Based on the literature, the transmission of radar or SWS messages seems be associated with reduced average speeds for the high-risk driver subgroup described above. These speed reductions appear to last only for a short distance within a local area. The effect is only temporary; the literature suggests that it would not result in reduced average speeds of the entire traffic stream, and vehicle collisions due to the braking of those driversresponding to the radar signal have been reporte

Whether the use of radar detectors makes drivers safer is difficult to determine. The research is inconsistent. Surveys find that people report that they are safer drivers when using a radar detector and that radar users report driving more kilometres in between collisions than non-users. However, samples are non-representative and, therefore, user and non-user groups are notcomparable

Я коряво перевел как
«Наличие р.д. способствует кратковременному снижению скорости у high-risk driver (цензурного не подобрал). Не влияет на среднюю скорость потока машин. Зафиксированы случаи аварий из-за резкого снижения скорости перед радаром.

Сложно определить приводит ли использование р.д. к более безопасному вождению. Исследование говно не консистентно. Пользователи р.д. говорят, что они водят безопаснее… Но примеры не репрезентативные, группы использующие радары и не использующие не могут быть правильно сравнены»

Короче исследование показало что явной связи нет, есть даже предпосылки к обратному эффекту, то есть увеличению вероятности аварии при использовании р.д.

Не нарушайте скоростной режим и все эти радары будут вам не интересны :P

«Web scraping», чую серьезно отстал от жизни… в мое время это называлось просто парсинг.

Спасибо за анализ данных.

а зачем было читать imdb, если кинопоиск показывает его рейтинг у себя?

что ответили в чате?

Точно зашевелятся. Но в первую очередь в сторону поиска «анонима».

Носил Пебблы года 3. был полностью доволен.
Постепенно уменьшалась батарейка, начал сыпаться экран — хотел купить новые и был жутко разочарован что их купили и закрыли :(
Сейчас ближайшие по функционалу AmazFit Bip… но нет той 1000 приложений и «ламповости» кнопок :(

Спасибо. после вашей подсказки увидел, что на первой квитанции 2 номера бронирования, на второй 3 номера бронирования.

Я не смог найти отличия между «одна квитанция» и «разные квитанции»
Неудивительно, что люди путаются.

PS да и на сайте только «пересадка» в терминах… как обычный человек должен понять покупает он стыковочный рейс или нет?

Но подождите. В HIVE вообще не SQL. В SQL для интервала есть BETWEEN. для битовой маски сходу не придумаю, не сталкивался по работе с подобными JOIN, обычно это уже были обычные фильтры.

на кросс да, будет пусто.

Как часто вам в работе нужно декартово произведение?
По моему опыту:
INNER и LEFT джойны нужны почти всегда.
RIGHT JOIN нужен редко.
FULL OUTER нужен редко.
CROSS не нужен почти никогда, даже NATURAL JOIN нужен чаще чем CROSS.

Нет. Вы получите все записи. Проверено на Pg10 и Ora11. В MySQL5.7 «FULL» еще нет =-)

Здесь явно подписан левый прямоугольник и правый. Inner join объединяет одинаковые элементы в обоих прямоугольниках.
Отличия от кругов скорее косметические.
Отсылка к диаграмме Венна имеет смыл только для тех кто помнит диаграммы Венна. Помнящих не так много как может показаться :D

Ни круги, ни прямоугольники не показывают наглядно почему будет 4 записи при наличии 2х единичек с каждой стороны и 6 записей при 2 к 3. Впрочем никакие картинки это нормально не показывают. При не уникальных записях мы получаем мультипликативный эффект. Чтобы его понять надо с другой стороны подходить к JOIN и построению запросов. Уж точно не пытаться это объяснять через cross join, использующийся примерно в 1 запросе из 10000.

По моему опыту проще заходит объяснение через вложенные циклы.
Но повторюсь, это уже гораздо дальше простого понимания когда надо ставить INNER, когда LEFT OUTER, а когда FULL OUTER, а именно на это нацелены картинки.

На картинке с кругами тоже ничего не говорится про пересечение. там только круги и заливка/штриховка.

Статья как раз о том, что при условии не уникальных "*" вы получите больше строк ответа, чем ожидается на основании этой картинки.

Я буду перечитывать текст перед отправкой. Я буду перечитывать текст перед отправкой. Я буду перечитывать текст перед отправкой. :(
Хотел дописать «Это точно не из из числа»

Вообще вся статья исходит из изначально неверной предпосылки что «таблица — это вообще не множество.» Но дальше сводится к верному что JOIN это не INTERSECT.

Но зачем разработчикам знать нюансы терминологии теории множеств на собеседовании по SQL на стандартном базовом вопросе про SQL?!
Не знает отличий между INNER и LEFT — не писал в SQL запросы сложнее «дай список по таблице с фильтром» — надо учить или прощаться.
Знает разницу между INNER и LEFT — ок, даже кружочками (привет универ, или гугл, или 100500 других источников знаний по SQL). Хотите уточнить пределы знаний — задаете дальнейшие вопросы. Про не уникальность, про сравнение NULL, да про что угодно вплоть до оконных функций, и вставки в несколько таблиц одним INSERT запросом

задаете advanced вопросы? это точно из

Простите, если совсем не в тему напишу.

Понятно, что даже одна полоса сблизит районы

Почему это подается аксиомой? Что является признаком близости?

Получается также, что с точки зрения расстояний добавление к двухполосной дороге по одной полосе с каждой стороны эквивалентно добавлению трех полос с одной. Евклидова близость в обоих случаях увеличится в два раза. Занятно.

Мне из этого видится вывод, что Евклидовая близость никак не ответит на вопросы «как изменится пропускная способность между районами», «несет ли новое ребро экономическую выгоду»

спасибо за статью.

Видимо пообсуждать Японский РКН и призвать выходить на митинги защиты интернета в Японии.

Собственно для задачи гарантированного избавления от совместных правок это и придумано.
Как мне показалось в докладе обсуждается именно проблема совместных правок.

Впрочем топик про Pg. И, судя по всему, в нем нельзя на уровне базы гарантировать неизменяемость данных другими транзакциями на необходимое время.

В Oracle есть select for update

неужели в Pg нет ничего столь же удобного?

На своих проектах я стараюсь добиться того, чтобы накат, в том числе и bugfix-ов и hotfix-ов, был не болью, а быстрым и понятным процессом.

с подобным стремлением нельзя не согласиться.

Можно любую ситуацию доводить до абсурда. Менять код БД на несколько порядков проще чем менять код JavaEE какой-нибудь. Об этом и говорится в статье.

Мой изначальный коммент был про то, что возможны ситуации, когда изменение кода в БД на проде даст быстрый желаемый результат без тяжелых последствий.
Это не значит что надо переходить на Production Driven Development.
Это значит, что при рассмотрении конкретной ситуации, надо учитывать подобную возможность.
Если система доставки спроектирована как рассказывает VladimirVerstov
выше, то подобная возможность не будет использоваться.
Если система доставки нового кода от 4х недель и больше, то нельзя догматично отбрасывать возможность спасти больше данных заказчика прямым вмешательством (и конечно работать в сторону уменьшения времени доставки).

А что мешает начать читать внимательно?

Бизнес не требовал раньше подобное разграничение доступов. Почему же его надо было заранее делать? Теперь ограничение потребовалось. Вся суть примера в изменившихся требованиях и вариантах их реализации.

А идея добавить на скорую руку какой-то триггер, который что-то будет делать (причем, разумеется, только на проде) настолько плохая, что мне кажется, комментировать ее бессмысленно.

Идея оставить заказчика наедине с его проблемами до ближайшего релиза не предоставляя обходных решений еще хуже.
Дело не в плохости «добавить на скорую руку какой-то триггер». Если триггер взвели и одновременно с этим в системе контроля версий он тоже появился и в реализуемом постоянном решении это учтено, то получаем win-win. Бизнес доволен оперативностью и спокойно ждет оплаченную доработку. Разработка довольна, что не надо делать все аврально.

То есть вы за вариант «запускать процесс обычного нового ЧТТ/ТЗ по аварийной схеме с максимально быстрой выкаткой»? просто потому что Бизнес захотел быстро?

Вариант с отсутствием доступа вообще весь тред делает бессмысленным, поэтому предлагаю его не рассматривать.
Пусть без прямого доступа, но передать временную «миграцию» отдельно от общего решения всегда можно. Отличаться от прямого доступа это будет только в части того кто будет запускать скрипт.

Вот вам пример из жизни

Бизнесу надо запретить почти всем пользователям выполнять операцию, которая раньше была вполне себе легитимной. Например сделать это новой настройкой уровня доступа. Естественно рассылаются новые должностные инструкции пользователям, согласовывается новое ТЗ/ЧТТ на изменение функционала поддерживаемой системы.
И конечно ждать его величество Бизнес очень не любит.

Что лучше?
Воткнуть триггер сегодня чтобы пользователи гарантированно перестали делать чего они не должны, и затем выкатить новый релиз по стандартной схеме?
или уповать на новые инструкции в ожидании релиза?
или запускать процесс обычного нового ЧТТ/ТЗ по аварийной схеме с максимально быстрой выкаткой?

Вот поэтому я никогда и не показываю рабочие скрипты. Они обычно написаны наспех и годятся только для внутреннего пользования.

В скрипте «Информация о таблицах»
* таблица «d» джойнится только имени таблицы, когда надо джойнить по 2м полям.
* запрос раз в 10 тяжелее чем можно было бы за счет джойнов с запросами с предварительной группировкой.

Скрипт «Скрипт «Атрибутный состав таблиц»» не смог дождаться завершения при копипасте с сайте. Выключил через 2 минуты. Притом, что ожидаемый вывод 2 строки:
SCHEMA_NAME_1 TABLE_NAME_1
SCHEMA_NAME_1 TABLE_NAME_2

Поведение вызвано тем же GROUP BY.

PS. добавлю облегченный скрипт «Информация о таблицах».

WITH filter(owner, table_name)
     AS (SELECT 'SCHEMA_NAME_1'
               ,t.*
           FROM TABLE(sys.odcivarchar2list('TABLE_NAME_1', 'TABLE_NAME_2')) t
         UNION ALL
         SELECT owner
               ,table_name
           FROM all_tables
          WHERE owner = 'SCHEMA_NAME_2')
SELECT   a.owner AS schema_name
        ,a.table_name
        ,e.comments
        ,b.num_rows as height
        ,(SELECT   COUNT(1) AS width
              FROM all_tab_columns x
             WHERE x.owner = a.owner
               AND x.table_name = a.table_name
          GROUP BY owner, table_name)
            width
        ,(SELECT   LISTAGG(column_name || ' (' || data_type || ')', ', ') WITHIN GROUP (ORDER BY column_id)
                      AS datetime_columns
              FROM all_tab_columns x
             WHERE (data_type = 'DATE'
                 OR data_type LIKE 'TIMESTAMP%'
                 OR data_type LIKE 'INTERVAL%'
                 OR LOWER(column_name) LIKE '%period%'
                 OR LOWER(column_name) LIKE '%date%'
                 OR LOWER(column_name) LIKE '%time%')
               AND x.owner = a.owner
               AND x.table_name = a.table_name
          GROUP BY owner, table_name)
            datetime_columns
        ,b.avg_row_len
        ,(SELECT   LISTAGG(column_name, ', ') WITHIN GROUP (ORDER BY column_position) AS part_key
              FROM all_part_key_columns x
             WHERE object_type = 'TABLE'
               AND x.owner = a.owner
               AND x.name = a.table_name
          GROUP BY owner, name)
            part_key
        ,(SELECT   LISTAGG(column_name, ', ') WITHIN GROUP (ORDER BY column_position) AS subpart_key
              FROM all_subpart_key_columns x
             WHERE object_type = 'TABLE'
               AND x.owner = a.owner
               AND x.name = a.table_name
          GROUP BY owner, name)
            subpart_key
    FROM filter a
         LEFT JOIN all_tab_statistics b
            ON a.table_name = b.table_name
           AND a.owner = b.owner
           AND b.object_type = 'TABLE'
         LEFT JOIN all_tab_comments e
            ON a.table_name = e.table_name
           AND a.owner = e.owner
           AND table_type = 'TABLE'
ORDER BY a.owner, a.table_name

Они хотя бы полностью совместимы.
А после передаваемых по наследству улучшений начнется веселуха как с железом сейчас.