Я бы сказал, что "жёлтый/белый". Белые встречаются и используются довольно часто, и порой более предпочтительны, ибо обычно у них допустим меньший радиус изгиба.
Бывают случаи, когда подключают MM оптику с SM-модулями.
Неудачная, даже непонятная, фраза. Видимо, имеется в виду "подключают SM-модули MM-патчкордами".
Ошибка №2. Неправильная длина волны
На иллюстрации в области для "1490nm Single-mode" изображён явно одноглазик.
Ошибка №3. Два одинаковых WDM модуля
На иллюстрации - двуглазики. Тогда как вы ещё в статье часть 3 указывали, что WDM работают на разных длинах волн по одному волокну.
К слову, я лично не видел двуглазиков с разными длинами волн..
Особенно обидно, когда на патч-корде стоит защелка и нужно пальцы сломать, чтобы её расщелкнуть.
Вы имеете в виду дуплексные кабели, где пара разъёмов удерживается вместе дополнительной защёлкой? Это да, вынимая разъёмы из защёлки, порой можно даже повредить кабель. Особенно если это SC-дуплекс - там защёлки дубовые, правда, они состоят из двух деталей и рассчитаны на то, что будут сниматься инструментом, а не голыми пальцами, и действительно, тонкая отвёртка или канцелярский резак сильно облегчают её снятие.
Или вы имеете в виду фиксатор разъёма, который удлиняют и делают в форме горбика/треугольника, облегчая вроде бы подключения-отключения, в случае, когда этот фиксатор ломается посередине и "задняя" половинка падает под переднюю, превращаясь в защёлку и затрудняя изъятие разъёма? С таким тоже пару раз сталкивался - ох, и матерился, вынимая.. помогает только аккуратная обрезка этой заклинивающей половинки канцелярским резаком или тонкими кусачками.
Коллеги, какие самые странные проблемы с SFP встречались у вас?
У меня самой странной была проблема, когда один SFP+ модуль (из 8 совершенно одинаковых) прекрасно работал в первом слоте двухпортовой серверной карты, но напрочь отказался работать во втором. Вот даже идей никаких, почему такое может быть, посему и разбираться не стал.
Такая архитектура позволяет передавать данные из технологического сегмента сети и сохранить физический и логический разрыв между цехом и офисом.
Ну если логический разрыв на этой схеме я ещё худо-бедно могу себе представить (точнее, представить могу, в виде двойной безадресной однонаправленной трансляции, но вот видеть - не вижу), то что вы разумеете под физическим разрывом, я вообще не понимаю.
Увы, но у меня как-то нет желания впрягаться в этот воз (а тут нужно или по-серьёзному впрягаться, или вообще не лезть, чтобы не получилось чего непотребного). К тому же структурные претензии заведомо разведут книгу и курс. Нам бы что попроще - контакт, куда можно заслать список того, что считаешь требующим рихтовки, а дальше пусть автор думает, прислушаться или проигнорировать..
Книга произвела весьма приятное впечатление. Язык простой и понятный. Хотя терминологические и даже структурные претензии (по счастью, в подавляющем большинстве своём - минорного характера) имеются.
Курс не смотрел - там требуется регистрация, а я не любитель лишних регистраций.
Из-за этого плоский формат требует постоянной ручной доработки.
Позволю себе не согласиться. Все три описанные проблемы - это явно проблемы на присылающей стороне. Причём если последние две - результат неправильно выбранного формата ячеек, то откуда взялась первая и что она есть, я вообще не понимаю, её просто не должно существовать. И вместо того, чтобы надавать менеджеру по шее за некачественную работу, вы предлагаете по-тихому исправить все допущенные им косяки, и пусть его халтурит дальше.
Чтобы добиться такой же стабильности внутри хранимой процедуры на SQL, придется писать обработчик ошибок
Это ещё зачем?
просто автоматически заменит проблемные места на NaN и спокойно зальет таблицу дальше
А вот это уже плохо. Получается, что скрипт по-тихому, никому не сообщая, сохраняет на сервере заведомо некорректные данные. ИМХО единственное правильное поведение в случае любой погрешности - это пропуск импорта проблемной записи с занесением её исходных данных в соотв. лог. Совсем хорошо - копирование "сырых" данных в специально предназначенную для этого таблицу. А если данные имеют внутренние ссылки, то процесс вообще должен быть остановлен до устранения выявленных проблем в исходных данных.
Ручные манипуляции с CSV ломают структуру данных на первом же текстовом поле, где внутри ячейки окажутся обычные запятые или кавычки.
Ну это заведомо неверное утверждение. Будь так - CSV не был бы стандартным средством переноса информации. Все текстовые поля (а при необходимости - вообще все поля) оборачиваются в кавычки, а кавычки внутри значения удваиваются либо экранируются - и никаких проблем ни с запятыми, ни с кавычками.
Заставлять Linux-сервер бд тратить процессорное время на парсинг внутри хранимых процедур - значит положить СУБД при росте нагрузок.
Описанная вами процедура - одноразовая. Это не однотипные запросы, которые летят от кучи клиентов большим и непредсказуемым потоком. Посему опасности "положить сервер" просто нет. Вот если бы импортировался, не приведи господи, XML, тогда да - процедура парсинга и импорта в MySQL тяжёлая и крайне по памяти прожорливая (кто импортировал ФИАС - знает).
И учтите ещё один момент. Сервер БД специально приспособлен и оптимизирован для пакетной обработки данных, его собственно для этого и создавали. А уж по производительности и имеющимся ресурсам он вообще кроет клиента как бык овцу. К тому же передача одного CSV и передача набора записей - это несколько различающиеся нагрузки на сетевую подсистему.
PS. К слову - а как ваш скрипт поведёт себя, если передаваемые данные содержат минорные форматные погрешности?
Моё личное мнение - много лишнего. Уже ж гарантированно есть два достаточно мощных инструмента - MySQL и Excel, которых более чем достаточно для решения задачи, так какой великий смысл наворачивать ещё кучу инструментов (pandas, sqlalchemy и openpyxl)? Особенно если их (а то ещё и python до кучи) в системе изначально не имеется. Хотя надо-то всего лишь в Excel (вручную либо VBA-процедурой) пересохранить файл в CSV, или загрузить данные из того же формата, а с конвертацией в обе стороны (и созданием таблицы при необходимости) прекрасно справится достаточно несложная хранимая процедура на MySQL.
Пожалуйста, отформатируйте нормально тексты запросов - сейчас они совершенно нечитаемы.
Для авто поиска уязвимых финансовых полей
По-моему, попытка отбирать поля по подстроке в имени поля - весьма неудачное решение. Да и причина объявления "неудачным" типа данных INT также совершенно непонятна.
И да, "автопоиск" - это одно слово, а не два.
Поиск изолированных таблиц
А вот зависшие "острова" таблиц такая метода не найдёт. Зато найдёт и подсветит таблицы-справочники, хранилище строк для работы мультиязычного интерфейса и прочие самостоятельные и независимые источники данных.
В процессе тестирования часто создаются временные таблицы (temp_users, debug_table). Их накатывают на базу, а после успешного деплоя забывают удалить.
Вре́менные таблицы автоматически удаляются после закрытия соединения, в котором они были созданы.
Но даже если вы говорите о статических таблицах, созданных для технических целей и не нужных на этапе эксплуатации, то всё равно весьма странно, почему бы почистить их от записей озаботились, а удалить - нет. Тут скорее следовало бы ожидать "или всё, или ничего".
По-моему, автор сделала абсолютно всё, чтобы показывать и объяснять что угодно, но только не утверждение, сформулированное в самом начале. Нет, я понимаю, если бы исходное утверждение было бы сложно или вообще невозможно воплотить на практике, но что может быть проще воды, текущей в изогнутой стеклянной трубке? Да, возникли бы определённые сложности с измерением давления, но они вполне решаемы. Но вместо (условно) несжимаемой жидкости (воды) почему-то используется то электроток, то очень хорошо сжимаемый воздух, а когда дело дошло-таки до воды, то трубку взяли ну очень малопрозрачную..
Честное слово: я многократно пробовал пройти этот квест с помощью нескольких принадлежащих мне телефонных номеров и разных браузеров, результат во всех случаях был одинаковый: регистрация на «Рамблере» не работает.
Странно, что у вас за проблема с неудавшейся авторизацией через СберID. Я без проблем прошёл процесс авторизации. Правда, попробовав создать новый ящик, в самом конце упёрся в плашку, которая вполне открыто и честно сообщает:
Не, ну рассказ в стиле "автомобиль съехал с горки не быстрее велосипеда, а потом мы завелись...". Как по мне - вообще ни о чём, чисто ради плюсадина в публикации.
Весьма оптимистично. Я в жизни с таким сталкивался ровно дважды - и оба раза не то что получать информацию с устройств сети, и уж тем более заниматься их конфигурированием, но даже подключиться к ним не удавалось. Шторм отличается не только избыточным количеством дублирующихся пакетов, но и катастрофическим процентом потерь, при котором интерфейс управления устройством - несбыточная мечта. И приходится начинать именно с разрыва физики.
Я бы сказал, что "жёлтый/белый". Белые встречаются и используются довольно часто, и порой более предпочтительны, ибо обычно у них допустим меньший радиус изгиба.
Неудачная, даже непонятная, фраза. Видимо, имеется в виду "подключают SM-модули MM-патчкордами".
На иллюстрации в области для "1490nm Single-mode" изображён явно одноглазик.
На иллюстрации - двуглазики. Тогда как вы ещё в статье часть 3 указывали, что WDM работают на разных длинах волн по одному волокну.
К слову, я лично не видел двуглазиков с разными длинами волн..
Вы имеете в виду дуплексные кабели, где пара разъёмов удерживается вместе дополнительной защёлкой? Это да, вынимая разъёмы из защёлки, порой можно даже повредить кабель. Особенно если это SC-дуплекс - там защёлки дубовые, правда, они состоят из двух деталей и рассчитаны на то, что будут сниматься инструментом, а не голыми пальцами, и действительно, тонкая отвёртка или канцелярский резак сильно облегчают её снятие.
Или вы имеете в виду фиксатор разъёма, который удлиняют и делают в форме горбика/треугольника, облегчая вроде бы подключения-отключения, в случае, когда этот фиксатор ломается посередине и "задняя" половинка падает под переднюю, превращаясь в защёлку и затрудняя изъятие разъёма? С таким тоже пару раз сталкивался - ох, и матерился, вынимая.. помогает только аккуратная обрезка этой заклинивающей половинки канцелярским резаком или тонкими кусачками.
У меня самой странной была проблема, когда один SFP+ модуль (из 8 совершенно одинаковых) прекрасно работал в первом слоте двухпортовой серверной карты, но напрочь отказался работать во втором. Вот даже идей никаких, почему такое может быть, посему и разбираться не стал.
Ну если логический разрыв на этой схеме я ещё худо-бедно могу себе представить (точнее, представить могу, в виде двойной безадресной однонаправленной трансляции, но вот видеть - не вижу), то что вы разумеете под физическим разрывом, я вообще не понимаю.
Увы, но у меня как-то нет желания впрягаться в этот воз (а тут нужно или по-серьёзному впрягаться, или вообще не лезть, чтобы не получилось чего непотребного). К тому же структурные претензии заведомо разведут книгу и курс. Нам бы что попроще - контакт, куда можно заслать список того, что считаешь требующим рихтовки, а дальше пусть автор думает, прислушаться или проигнорировать..
Угу, прощайте, кастомные настройки, пользовательские переменные, вре́менные таблицы, и всё прочее со scope=connection.
Книга произвела весьма приятное впечатление. Язык простой и понятный. Хотя терминологические и даже структурные претензии (по счастью, в подавляющем большинстве своём - минорного характера) имеются.
Курс не смотрел - там требуется регистрация, а я не любитель лишних регистраций.
И не понял, что делает в списке тегов SQLite.
Ну вообще-то объёма, а не массы. Сохранение ещё и массы - всего лишь следствие несжимаемости, т.е. постоянства плотности.
Позволю себе не согласиться. Все три описанные проблемы - это явно проблемы на присылающей стороне. Причём если последние две - результат неправильно выбранного формата ячеек, то откуда взялась первая и что она есть, я вообще не понимаю, её просто не должно существовать. И вместо того, чтобы надавать менеджеру по шее за некачественную работу, вы предлагаете по-тихому исправить все допущенные им косяки, и пусть его халтурит дальше.
Это ещё зачем?
А вот это уже плохо. Получается, что скрипт по-тихому, никому не сообщая, сохраняет на сервере заведомо некорректные данные. ИМХО единственное правильное поведение в случае любой погрешности - это пропуск импорта проблемной записи с занесением её исходных данных в соотв. лог. Совсем хорошо - копирование "сырых" данных в специально предназначенную для этого таблицу. А если данные имеют внутренние ссылки, то процесс вообще должен быть остановлен до устранения выявленных проблем в исходных данных.
Ну это заведомо неверное утверждение. Будь так - CSV не был бы стандартным средством переноса информации. Все текстовые поля (а при необходимости - вообще все поля) оборачиваются в кавычки, а кавычки внутри значения удваиваются либо экранируются - и никаких проблем ни с запятыми, ни с кавычками.
Описанная вами процедура - одноразовая. Это не однотипные запросы, которые летят от кучи клиентов большим и непредсказуемым потоком. Посему опасности "положить сервер" просто нет. Вот если бы импортировался, не приведи господи, XML, тогда да - процедура парсинга и импорта в MySQL тяжёлая и крайне по памяти прожорливая (кто импортировал ФИАС - знает).
И учтите ещё один момент. Сервер БД специально приспособлен и оптимизирован для пакетной обработки данных, его собственно для этого и создавали. А уж по производительности и имеющимся ресурсам он вообще кроет клиента как бык овцу. К тому же передача одного CSV и передача набора записей - это несколько различающиеся нагрузки на сетевую подсистему.
PS. К слову - а как ваш скрипт поведёт себя, если передаваемые данные содержат минорные форматные погрешности?
Моё личное мнение - много лишнего. Уже ж гарантированно есть два достаточно мощных инструмента - MySQL и Excel, которых более чем достаточно для решения задачи, так какой великий смысл наворачивать ещё кучу инструментов (pandas, sqlalchemy и openpyxl)? Особенно если их (а то ещё и python до кучи) в системе изначально не имеется. Хотя надо-то всего лишь в Excel (вручную либо VBA-процедурой) пересохранить файл в CSV, или загрузить данные из того же формата, а с конвертацией в обе стороны (и созданием таблицы при необходимости) прекрасно справится достаточно несложная хранимая процедура на MySQL.
Точечный впрыск красителя позволит пронаблюдать динамику движения жидкости. И траекторию, и скорость.
Какое это имеет отношение к статье?
Как и почему - я знаю. Но если у автора было желание рассказать и показать наглядно, то эта затея, имхо, с треском провалена.
Пожалуйста, отформатируйте нормально тексты запросов - сейчас они совершенно нечитаемы.
По-моему, попытка отбирать поля по подстроке в имени поля - весьма неудачное решение. Да и причина объявления "неудачным" типа данных INT также совершенно непонятна.
И да, "автопоиск" - это одно слово, а не два.
А вот зависшие "острова" таблиц такая метода не найдёт. Зато найдёт и подсветит таблицы-справочники, хранилище строк для работы мультиязычного интерфейса и прочие самостоятельные и независимые источники данных.
Вре́менные таблицы автоматически удаляются после закрытия соединения, в котором они были созданы.
Но даже если вы говорите о статических таблицах, созданных для технических целей и не нужных на этапе эксплуатации, то всё равно весьма странно, почему бы почистить их от записей озаботились, а удалить - нет. Тут скорее следовало бы ожидать "или всё, или ничего".
По-моему, автор сделала абсолютно всё, чтобы показывать и объяснять что угодно, но только не утверждение, сформулированное в самом начале. Нет, я понимаю, если бы исходное утверждение было бы сложно или вообще невозможно воплотить на практике, но что может быть проще воды, текущей в изогнутой стеклянной трубке? Да, возникли бы определённые сложности с измерением давления, но они вполне решаемы. Но вместо (условно) несжимаемой жидкости (воды) почему-то используется то электроток, то очень хорошо сжимаемый воздух, а когда дело дошло-таки до воды, то трубку взяли ну очень малопрозрачную..
Не шутка ни разу. Сейчас красиво материться без подсказок мало кто умеет..
Странно, что у вас за проблема с неудавшейся авторизацией через СберID. Я без проблем прошёл процесс авторизации. Правда, попробовав создать новый ящик, в самом конце упёрся в плашку, которая вполне открыто и честно сообщает:
Дипфэйк умершего родственника? ну да, это можно считать жизнью, наверное..
Пропущен пункт в голосовании, с формулировкой типа "SO для людей трансформируется в SO для агентов".
Уже сейчас SO гораздо менее интересен. Действительно качественных вопросов кот наплакал.
Не, ну рассказ в стиле "автомобиль съехал с горки не быстрее велосипеда, а потом мы завелись...". Как по мне - вообще ни о чём, чисто ради плюсадина в публикации.
Когда - не скажу. Но вот только с чего ты думаешь, что если оно закончится, то именно так, как ты хочешь?
Весьма оптимистично. Я в жизни с таким сталкивался ровно дважды - и оба раза не то что получать информацию с устройств сети, и уж тем более заниматься их конфигурированием, но даже подключиться к ним не удавалось. Шторм отличается не только избыточным количеством дублирующихся пакетов, но и катастрофическим процентом потерь, при котором интерфейс управления устройством - несбыточная мечта. И приходится начинать именно с разрыва физики.
А это отдельно.
Интересно, совпадает ли список излишне (до OFFSET) заблокированных записей в случаях:
и
Или во втором случае избытка не будет?