Этот "тонкий равномерный бульон" остается неизменным бесконечно долго, при том что вероятность нарушения баланса в любой условной точке бесконечно близка к нулю.
Насколько я помню, сингулярность - является конечной точкой в времени, судя по современному научпопу, в черных дырах это так. При этом, непонятно, что такое "вероятность" в условиях отсутствия времени - возможно, что в таких условиях происходит всё, что в принципе может произойти. В т.ч., может появиться вселенная, в которой появится такое явление как время. Причем, время, не связанное со временем породившей ее вселенной - между ними не будет отношений "до" или "после".
Фундаментальность времени - все еще спорный вопрос, насколько я понимаю. Возможно, что до появления вселенной не было ни пространства, ни времени. Так что вопрос "что было ДО большого взрыва" в этом контексте может вообще не иметь смысла - не было времени, значит, не было момента "до".
Если на прием (особенно, первичный) врачу выделяют 15 минут, пациенту лучше поискать другое место. Да и нормальному врачу тоже.
Если врач не запишет результат осмотра, диагноз, план обследования, план лечения, рекомендации, это будет примерно то же самое, как если программист сочинит в голове кусок кода, расскажет его кому-то вслух, но не станет записывать. Времяпровождение очень занимательное, но с практической точки зрения бесполезное. Немногие пациенты способны со слуха запомнить все формулировки, рекомендации и назначения. И внутренние коммуникации - с точки зрения безопасности пациента, медикаментозное назначение врач должен передавать среднему медперсоналу письменно/в электронном виде. Устно можно только продублировать.
И да, врача тоже не надо отвлекать, пока он работает с пациентом.
Привет. Переводил пару проектов с oracle на postgresql. Сначала попробовал ora2pg, но в итоге оказалось проще написать свой мигратор (меньше 150 строк кода), который подключался к двум базам, затягивал пачками N строк из таблиц oracle и вставлял в postgres. Через промежуточную базу, т.к. в изменилась не только СУБД, но и структура данных, поэтому сначала конвертация из oracle в промежуточную postgres, затем из из промежуточной в целевую уже с учетом изменения структуры данных. Всех нюансов, почему ora2pg не зашел, сейчас уже не вспомню.
Что касается миграции pl/sql кода, то обратите внимание на такой момент - код типа select ... into ... в оракле при отсутствии данных выдает исключение no_data_found, а в postgresql не выдает. Лечится через "select ... into strict ...".
Отсутствие пакетов в postgres довольно неудобно. Пришлось использовать просто процедуры и функции и соглашение по наименованию вида "package_name__function_name". Есть еще вариант использовать в качестве "пакета" отдельную схему данных, тогда синтаксис будет прежним - "package_name.function_name", но остановились на первом варианте.
Зависимые представления. Если view2 берет данные из view1, нельзя просто так взять и через create or replace view добавить поле во view1, надо дропнуть view1 и зависимые объекты, затем заново создать их в правильном порядке. Это усложняет логику наката изменений в БД.
В конце прошлого века в каком-то радиожурнале был, помнится, проект - наушники из двух динамических микрофонов. Микрофоны с их тонкими мембранами звучали лучше некоторых заводских наушников
Я когда-то паял примитивный "ритм-генератор" - генератор 16-тактовых последовательностей звуков ударных инструментов - бочки, среднего барабана, "длинной" и "короткой" тарелки. Тогда пришлось придумать, как формировать для них звук, имея примитивную элементную базу - транзисторы. Так вот, тарелки получились лучше всего - сначала генерился шум, это делается одним транзистором, затем частотный фильтр, который из белого шума делал звук, как будто долго произносится буква "с" (даже лучше сказать, буква "сь") и потом генератор огибающей (т.е., задавался уровень, громкость этой самой "сь"). Огибающая по сигналу старта начиналась с максимума и затем опускалась до нуля. У короткой тарелки - быстро опускалось, у длинной - помедленнее. Бочка - то же самое, только вместо шума была низкочастотная синусоида. Средний барабан - уже не помню точно, это где-то 1991 или 1992й год был, кажется синусоида повыше бочки плюс шум пониже тарелки, типа "ш".
ps. Бочка получилось довольно поганая, а тарелки - вполне себе
Октава - это частотный интервал, когда частота отличается в 2 раза.
Полутон - частотный интервал в 1/12 от октавы. Например, есть какая-то первая нота, без разницы какая. На пол-тона выше - это частота, которая выше первой ноты в корень 12й степени из двух. Пройдем 12 полутонов и получим увеличение частоты ровно в 2 раза.
Это действительно было простым языком, просто, когда сфера незнакомая, всё кажется совершенно странным и нелогичным. Музыка - практически математика, но терминология и обозначения такие несистемные, т.к. и сама музыка и ее терминология формировалась сильно отдельно от математики.
Далее. Между нотой "ля" и нотой "си" - 2 полутона. Если увеличить "ля" на пол-тона - мы попадем на ноту, которую можно назвать "ля-диез". Если же уменьшить си на "пол-тона", то попадем на ту же самую ноту, которую в этот раз можно назвать "си-бемоль". Мы ее так назовем просто потому, что опускались от более высокой ноты в этот раз. Как именно считать - зависит от тональности.
Тональность - это когда в мелодии, из набора в 12 полутонов выделяют 7, необязательно начиная с "до". У музыканта в голове при названии тональности сразу складывается схема, по каким нотам будет играться мелодия, это у них типа короткой записи массива. Самый простой пример - тональность "до-мажор" - это все белые клавиши, 7 штук в каждой октаве.
Позвольте поделиться своим опытом обучения слепой печати: Зачем: Сначала мне понадобилось перепечатывать много текста по-русски с бумаги. Я понял, что глядя на клавиши я просто не успеваю смотреть то в источник, то на клавиатуру, то на экран для контроля ввода. И посчитав, понял, что не успеваю по срокам - был определенный объем, который нужно было перепечатать к сроку.
До этого пробовал несколько программ для обучения (это была середина 1990-х), прогресс был крайне медленный. Тогда решил обучаться непосредственно в процессе перепечатывания. Но поскольку глаза чисто автоматически подсматривали на клавиатуру и пальцы, то скрутил из проволоки каркас над клавиатурой, который накрыл листом бумаги. Поскольку расположение клавиш еще плохо помнил, то вывел на экран on-screen keyboard. Оказалось, что это не то же самое, что смотреть на саму клавиатуру, очень быстро начал вырабатываться навык. Где-то через час-два скорость ввода сравнялась с той, которая была, когда смотрел на клавиатуру. К сроку успел в результате.
OCR не мог тогда применить по ряду причин, если у кого-то такой вопрос возникнет.
Слепая печать по-русски и слепая печать латиницей - не одно и то же. Когда пытался писать текст программы вслепую, пальцы сами жали в русские буквы по звучанию, то есть, вместо "print" пытался набрать "ghbyn". Поэтому, опять накрыл клавиатуру и несколько дней писал программы, вводя текст уже латиницей. Эта часть обучения заняла больше времени, сейчас уже точно не помню сколько. Думаю, что навык печати по-русски сбивал. После того, как натренировался, по ощущению в голове как бы 2 разные области - 1) я печатаю по-русски и 2) я печатаю латиницей, происходит переключение.
По ощущению от всего этого, никакие обучающие приложения со своими заданиями и близко по мотивации не сравнятся с реально стоящими задачами. Быстрее всего научиться плавать оказалось бросившись в воду.
В Oracle, например, есть пакеты, которые позволяют упорядочить код, плюс много готовых пакетов для работы с tcp, почтой и т.п. Таким образом, значительную часть логики можно держать в базе без головной боли. А в Postgres "из коробки" такой возможности нет (если вы, опять же, не подключите pl/sql), поэтому, держать много кода в pg/sql лично мне неудобно. И есть смысл унести код в backend, вместе с процедурой отправки сообщений
Делали аналогичную задачу в другой СУБД для отправки писем и СМС. В транзакции письмо укладывалось в очередь сообщений и всё. Далее по расписанию процедура занималась отправкой. Преимущества:
Так еще можно проверять доп.условия, например, всё, что сгенерировалось ночью - отлежится до утра, чтобы не будить клиентов. А сотрудникам сообщения могут сразу отправляться.
Письмо клиенту может отлежаться, например, 5 минут. В этот период исходные данные могут измениться (например, визит отменится или перенесется на другое время) и можно успеть удалить или изменить сообщения
Здравствуйте! Добавление виртуального графа создает аналог прямой связи между узлами одного и того же столбца. В оригинальном графе они связаны лишь через крайний узел и узлы соседнего столбца. Разве не так?
Нас Мегафон трясет, чтобы зарегистрировали на Госуслугах на конкретного сотрудника симкарту, которая виртуально привязана с сервису отправки СМС клиентам. По факту эта симка лежит в тумбочке, а доступ к сервису идет по логину. Но грозятся отключить услугу, если не зарегистрируем. Где логика?
Из моего опыта - оптимальные способы планирования и контроля сроков по задачам сильно зависят от того, является ли заказчик внутренним (т.е., разработчики - это подразделение в той же организации, что и заказчики) или внешним (сторонняя организация, для которой разрабытывается софт, который потом не будет значительно и постоянно меняться). В первом случае burn-down-chart как мне кажется, почти никогда и не должен опускаться до нуля, если брать весь массив задач целиком. Поэтому, мы немного доработали подход:
1) определили milestone - крайний срок, когда нужно запустить проект.
2) поделили задачи по приоритету - "до запуска", "после запуска" и "когда-нибудь потом". И burn-down-chart строили только по задачам "до запуска".
3) использовали модифицированный burn-down-chart, где каждый столбец состоял из двух частей стеком друг над другом - нижней, сколько осталось задач сделать и верхней, сколько задач уже сделано. Таким образом, "срединная" линия между частями была классическим burn-down, а верхняя - отражала общее количество. Эффект от этого - чисто психологический, не так грустно смотреть на график и показать почему мы не укладываемся в планы - потому что вон сколько задач сделали, а вон еще сколько накидали.
4) по мере необходимости пересматривали приоритеты, чтобы уложиться в срок к запуску.
5) после запуска доводили до подразделений-заказчиков длительности исполнения по запланированным задачам и максимальное суммарное время на двухнедельный спринт. И подразделения-заказчики между собой решали, какие задачи можно выкинуть, чтобы уложиться в лимит. Этот лимит был заложен меньше суммы рабочего времени всех разработчиков, таким образом, оставили время на тех.долг и экстренные исправления по критическим ошибкам, пробравшимся мимо тестировщиков. Самое сложное тут было убедить заказчика, что лимит должен быть меньше суммы рабочего времени разработчиков - что это вовсе не от лени.
Многие (если не все) базы данных умеют хранить дату без таймзоны. Вот в таком виде и надо ее хранить. Тогда дата рождения не поплывет у клиентов в разных часовых поясах. А вот момент, когда поздравлять пациента - надо вычислять с учетом таймзоны поздравляемого - наступила эта дата там, или нет. И еще надо позаботиться о том, чтобы кроме СУБД еще какой-нибудь слой (backend или frontend) не произвел преобразование даты вида "дд.мм.гггг 00:00:00" в таймзону клиента.
Кстати, недавно столкнулся с паспортом (настоящим), где дата рождения была указана как "00.00.1946" (именно так, с нулями), которую в поле типа Дата и подобные внести никак нельзя. Я так понимаю, в МВД для даты рождения используется просто строка. И в данном случае, видимо, точная дата рождения была утеряна.
Насколько я помню, сингулярность - является конечной точкой в времени, судя по современному научпопу, в черных дырах это так. При этом, непонятно, что такое "вероятность" в условиях отсутствия времени - возможно, что в таких условиях происходит всё, что в принципе может произойти. В т.ч., может появиться вселенная, в которой появится такое явление как время. Причем, время, не связанное со временем породившей ее вселенной - между ними не будет отношений "до" или "после".
Фундаментальность времени - все еще спорный вопрос, насколько я понимаю. Возможно, что до появления вселенной не было ни пространства, ни времени. Так что вопрос "что было ДО большого взрыва" в этом контексте может вообще не иметь смысла - не было времени, значит, не было момента "до".
Если на прием (особенно, первичный) врачу выделяют 15 минут, пациенту лучше поискать другое место. Да и нормальному врачу тоже.
Если врач не запишет результат осмотра, диагноз, план обследования, план лечения, рекомендации, это будет примерно то же самое, как если программист сочинит в голове кусок кода, расскажет его кому-то вслух, но не станет записывать. Времяпровождение очень занимательное, но с практической точки зрения бесполезное. Немногие пациенты способны со слуха запомнить все формулировки, рекомендации и назначения. И внутренние коммуникации - с точки зрения безопасности пациента, медикаментозное назначение врач должен передавать среднему медперсоналу письменно/в электронном виде. Устно можно только продублировать.
И да, врача тоже не надо отвлекать, пока он работает с пациентом.
Привет. Переводил пару проектов с oracle на postgresql. Сначала попробовал ora2pg, но в итоге оказалось проще написать свой мигратор (меньше 150 строк кода), который подключался к двум базам, затягивал пачками N строк из таблиц oracle и вставлял в postgres. Через промежуточную базу, т.к. в изменилась не только СУБД, но и структура данных, поэтому сначала конвертация из oracle в промежуточную postgres, затем из из промежуточной в целевую уже с учетом изменения структуры данных. Всех нюансов, почему ora2pg не зашел, сейчас уже не вспомню.
Что касается миграции pl/sql кода, то обратите внимание на такой момент - код типа select ... into ... в оракле при отсутствии данных выдает исключение no_data_found, а в postgresql не выдает. Лечится через "select ... into strict ...".
Отсутствие пакетов в postgres довольно неудобно. Пришлось использовать просто процедуры и функции и соглашение по наименованию вида "package_name__function_name". Есть еще вариант использовать в качестве "пакета" отдельную схему данных, тогда синтаксис будет прежним - "package_name.function_name", но остановились на первом варианте.
Зависимые представления. Если view2 берет данные из view1, нельзя просто так взять и через create or replace view добавить поле во view1, надо дропнуть view1 и зависимые объекты, затем заново создать их в правильном порядке. Это усложняет логику наката изменений в БД.
В конце прошлого века в каком-то радиожурнале был, помнится, проект - наушники из двух динамических микрофонов. Микрофоны с их тонкими мембранами звучали лучше некоторых заводских наушников
тут написано "приятный звук". Пока не разобрался досконально в предмете - рано критиковать, а вот хвалить можно :)
Про диаграмму ударных.
Я когда-то паял примитивный "ритм-генератор" - генератор 16-тактовых последовательностей звуков ударных инструментов - бочки, среднего барабана, "длинной" и "короткой" тарелки. Тогда пришлось придумать, как формировать для них звук, имея примитивную элементную базу - транзисторы. Так вот, тарелки получились лучше всего - сначала генерился шум, это делается одним транзистором, затем частотный фильтр, который из белого шума делал звук, как будто долго произносится буква "с" (даже лучше сказать, буква "сь") и потом генератор огибающей (т.е., задавался уровень, громкость этой самой "сь"). Огибающая по сигналу старта начиналась с максимума и затем опускалась до нуля. У короткой тарелки - быстро опускалось, у длинной - помедленнее. Бочка - то же самое, только вместо шума была низкочастотная синусоида. Средний барабан - уже не помню точно, это где-то 1991 или 1992й год был, кажется синусоида повыше бочки плюс шум пониже тарелки, типа "ш".
ps. Бочка получилось довольно поганая, а тарелки - вполне себе
Октава - это частотный интервал, когда частота отличается в 2 раза.
Полутон - частотный интервал в 1/12 от октавы. Например, есть какая-то первая нота, без разницы какая. На пол-тона выше - это частота, которая выше первой ноты в корень 12й степени из двух. Пройдем 12 полутонов и получим увеличение частоты ровно в 2 раза.
Это действительно было простым языком, просто, когда сфера незнакомая, всё кажется совершенно странным и нелогичным. Музыка - практически математика, но терминология и обозначения такие несистемные, т.к. и сама музыка и ее терминология формировалась сильно отдельно от математики.
Далее. Между нотой "ля" и нотой "си" - 2 полутона. Если увеличить "ля" на пол-тона - мы попадем на ноту, которую можно назвать "ля-диез". Если же уменьшить си на "пол-тона", то попадем на ту же самую ноту, которую в этот раз можно назвать "си-бемоль". Мы ее так назовем просто потому, что опускались от более высокой ноты в этот раз. Как именно считать - зависит от тональности.
Тональность - это когда в мелодии, из набора в 12 полутонов выделяют 7, необязательно начиная с "до". У музыканта в голове при названии тональности сразу складывается схема, по каким нотам будет играться мелодия, это у них типа короткой записи массива. Самый простой пример - тональность "до-мажор" - это все белые клавиши, 7 штук в каждой октаве.
Позвольте поделиться своим опытом обучения слепой печати:
Зачем: Сначала мне понадобилось перепечатывать много текста по-русски с бумаги. Я понял, что глядя на клавиши я просто не успеваю смотреть то в источник, то на клавиатуру, то на экран для контроля ввода. И посчитав, понял, что не успеваю по срокам - был определенный объем, который нужно было перепечатать к сроку.
До этого пробовал несколько программ для обучения (это была середина 1990-х), прогресс был крайне медленный. Тогда решил обучаться непосредственно в процессе перепечатывания. Но поскольку глаза чисто автоматически подсматривали на клавиатуру и пальцы, то скрутил из проволоки каркас над клавиатурой, который накрыл листом бумаги. Поскольку расположение клавиш еще плохо помнил, то вывел на экран on-screen keyboard. Оказалось, что это не то же самое, что смотреть на саму клавиатуру, очень быстро начал вырабатываться навык. Где-то через час-два скорость ввода сравнялась с той, которая была, когда смотрел на клавиатуру. К сроку успел в результате.
OCR не мог тогда применить по ряду причин, если у кого-то такой вопрос возникнет.
Слепая печать по-русски и слепая печать латиницей - не одно и то же. Когда пытался писать текст программы вслепую, пальцы сами жали в русские буквы по звучанию, то есть, вместо "print" пытался набрать "ghbyn". Поэтому, опять накрыл клавиатуру и несколько дней писал программы, вводя текст уже латиницей. Эта часть обучения заняла больше времени, сейчас уже точно не помню сколько. Думаю, что навык печати по-русски сбивал. После того, как натренировался, по ощущению в голове как бы 2 разные области - 1) я печатаю по-русски и 2) я печатаю латиницей, происходит переключение.
По ощущению от всего этого, никакие обучающие приложения со своими заданиями и близко по мотивации не сравнятся с реально стоящими задачами. Быстрее всего научиться плавать оказалось бросившись в воду.
И еще...
В Oracle, например, есть пакеты, которые позволяют упорядочить код, плюс много готовых пакетов для работы с tcp, почтой и т.п. Таким образом, значительную часть логики можно держать в базе без головной боли. А в Postgres "из коробки" такой возможности нет (если вы, опять же, не подключите pl/sql), поэтому, держать много кода в pg/sql лично мне неудобно. И есть смысл унести код в backend, вместе с процедурой отправки сообщений
Делали аналогичную задачу в другой СУБД для отправки писем и СМС. В транзакции письмо укладывалось в очередь сообщений и всё. Далее по расписанию процедура занималась отправкой. Преимущества:
Так еще можно проверять доп.условия, например, всё, что сгенерировалось ночью - отлежится до утра, чтобы не будить клиентов. А сотрудникам сообщения могут сразу отправляться.
Письмо клиенту может отлежаться, например, 5 минут. В этот период исходные данные могут измениться (например, визит отменится или перенесется на другое время) и можно успеть удалить или изменить сообщения
Здравствуйте! Добавление виртуального графа создает аналог прямой связи между узлами одного и того же столбца. В оригинальном графе они связаны лишь через крайний узел и узлы соседнего столбца. Разве не так?
Добрый день! Подскажите, а что дает хранение файлов в отдельном домене?
Нас Мегафон трясет, чтобы зарегистрировали на Госуслугах на конкретного сотрудника симкарту, которая виртуально привязана с сервису отправки СМС клиентам. По факту эта симка лежит в тумбочке, а доступ к сервису идет по логину. Но грозятся отключить услугу, если не зарегистрируем. Где логика?
Да, точно, моя ошибка
Но есть мадридская система регистрации товарных знаков: https://www.wipo.int/madrid/ru/
Может, из-за того, что отсутствует характерная кристаллическая решетка?
Абсолютно согласен, жаль, не могу плюс поставить
Из моего опыта - оптимальные способы планирования и контроля сроков по задачам сильно зависят от того, является ли заказчик внутренним (т.е., разработчики - это подразделение в той же организации, что и заказчики) или внешним (сторонняя организация, для которой разрабытывается софт, который потом не будет значительно и постоянно меняться). В первом случае burn-down-chart как мне кажется, почти никогда и не должен опускаться до нуля, если брать весь массив задач целиком. Поэтому, мы немного доработали подход:
1) определили milestone - крайний срок, когда нужно запустить проект.
2) поделили задачи по приоритету - "до запуска", "после запуска" и "когда-нибудь потом". И burn-down-chart строили только по задачам "до запуска".
3) использовали модифицированный burn-down-chart, где каждый столбец состоял из двух частей стеком друг над другом - нижней, сколько осталось задач сделать и верхней, сколько задач уже сделано. Таким образом, "срединная" линия между частями была классическим burn-down, а верхняя - отражала общее количество. Эффект от этого - чисто психологический, не так грустно смотреть на график и показать почему мы не укладываемся в планы - потому что вон сколько задач сделали, а вон еще сколько накидали.
4) по мере необходимости пересматривали приоритеты, чтобы уложиться в срок к запуску.
5) после запуска доводили до подразделений-заказчиков длительности исполнения по запланированным задачам и максимальное суммарное время на двухнедельный спринт. И подразделения-заказчики между собой решали, какие задачи можно выкинуть, чтобы уложиться в лимит. Этот лимит был заложен меньше суммы рабочего времени всех разработчиков, таким образом, оставили время на тех.долг и экстренные исправления по критическим ошибкам, пробравшимся мимо тестировщиков. Самое сложное тут было убедить заказчика, что лимит должен быть меньше суммы рабочего времени разработчиков - что это вовсе не от лени.
Многие (если не все) базы данных умеют хранить дату без таймзоны. Вот в таком виде и надо ее хранить. Тогда дата рождения не поплывет у клиентов в разных часовых поясах. А вот момент, когда поздравлять пациента - надо вычислять с учетом таймзоны поздравляемого - наступила эта дата там, или нет. И еще надо позаботиться о том, чтобы кроме СУБД еще какой-нибудь слой (backend или frontend) не произвел преобразование даты вида "дд.мм.гггг 00:00:00" в таймзону клиента.
Кстати, недавно столкнулся с паспортом (настоящим), где дата рождения была указана как "00.00.1946" (именно так, с нулями), которую в поле типа Дата и подобные внести никак нельзя. Я так понимаю, в МВД для даты рождения используется просто строка. И в данном случае, видимо, точная дата рождения была утеряна.