Да. Закончится Интернет. А какой смысл в технологиях, когда нельзя сделать запрос на сервер? Мы вернёмся в каменный век, когда (к примеру!) табель в отдел кадров носили на дискете (спасибо, ещё, что в Excel). Недавно ещё такое было.
Это означает, что все против всех будут атаки делать. ИТ может закончится гораздо раньше, чем электричество. ИИ просто не успеет взлететь. Хотя, данный меморандум подталкивает ситуацию к сюжету фильма "Терминатор".
Во-первых, можно поменять алгоритм. Если, например, речь идёт о сортировке элементов некоторого массива, то на разных данных более быстрыми будут разные алгоритмы. Различие в данных относится и к их размеру (тут в дело вступают константы оценок сложности), и к их содержанию (бывают, так сказать, частично упорядоченные массивы). В случае, если речь идёт, например, о построении матричного профиля временного ряда (это такая функция, которая сопоставляет каждому фрагменту временного ряда расстояние до заданного образца из другого временного ряда: Вы проводите скользящее окно фиксированной ширины/длины вдоль временного ряда и получаете новый временной ряд, который и называется матричным профилем), то его непосредственное вычисление часто оказывается невозможным (слишком много сравнений!), зато имеются техники, позволяющие существенным образом сократить количество сравнений (и вычислять матричный профиль за секунды и минуты против часов и дней).
Во-вторых, можно "прошерстить" сам алгоритм, и проверить правильно его реализации. Можно попытаться переписать его, возможно, выбрав другие структуры данных (с учётом времени доступа и времени обновления структуры). Ещё бывает очень дорогим вызов процедур/функций. Плюс оптимизация компилятора. И не забудем про кеширование в оперативной памяти. А многопоточность? Вот, бывает так, что процесс хочет записать что-то в память, а память ещё не готова принять данные?
В-третьих, (а, точнее, во-первых!), надо всё тщательно измерить. Любое оценочное суждение должно быть подкреплено числом. Запускать надо на разных конфигурациях/машинах. Надо точно знать, точно ли, что это колесо доедет до Москвы, а до Казани не до едет.
Мы провели аудит черновиков и выявили типичные причины ошибок...
А можно немного позанудствовать? Почему нельзя написать "Мы проверили черновики..."? Могут ли быть ещё какие-то нетипичные причины ошибки? И точно ли то, что Вы искали именно причины ошибок.
, возникающих на этапе создания текстов.
А если просто завершить предложение "... причины ошибок в [наших] текстах"?
Это позволило нам точнее настраивать внутренние стандарты и обучающие материалы для авторов, ...
Оказывается, стандарты можно настраивать, но ещё настраивать можно и обучающие материалы! Почему бы не использовать глагол "корректировать"? Например: "Это позволило нам скорректировать внутренние стандарты и обучающие материалы для авторов". К тому же, само слово "настраивать" (точнее, его форма) предполагает некое протяжённое во времени действие, как будь-то Вы, теперь, постоянно всё настраиваете, а смысл заключается, как раз, в том, чтобы провести анализ и по результатам этого анализа предпринять некое однократное действие.
... чтобы повышать качество текстов до того, как они попадут на ревью.
Как резкий поворот мысли! А, ведь, можно было поставить точку, ведь, и так понятно, ради чего корректируются стандарты и руководства.
Написание текстов — трудная работа. Но, порою, достаточно немного отодвинуться от собственного текста, прочитать на свежую голову, чтобы увидеть все ошибки и огрехи. А ещё можно распечатать. Не пожалеть бумаги и тон(н)ера. С бумаги это всё как-то виднее. ;-)
Тут можно не согласиться. Тире обычно появляется там, где пропускается слово. Здесь пропущено слово "есть" ("Аз есмь...") или, как ещё раньше говорили "суть". Почему-то это простое правило (про пропуск слова) забывают.
Самый страшный вопрос. Вот так сядешь, задашься у... немедленно куда-то "улетаешь". Невозможно понять/принять отсутствие. А как это, когда ничего нет? Запретный вопрос. Очень страшный.
Если можно было бы эти медали "перелить" в отечественные операционные системы, облака, офисные пакеты, матлабы, фотошопы, иллюстраторы и прочие акробаты...
Извините, но я — совсем тёмный. Не понимаю, как могут приходить кому-то какие-то письма. Допустим, на noreply.us установлен почтовый сервер, то, верно ли я понимаю ситуацию, что этот сервер может принять входящее письмо по адресу "[что-то-там]@noreply.us"?
Вы, скорее всего, встречались с кардинально противоположными мнениями: "Django умер, да здравствует FastAPI", "Сейчас на FastAPI уже не пишут, встречай LiteStar", "Вообще на FastAPI особо ничего не пишем, только на Django".
Вместо простых оценочных суждений, было бы здорово прочитать глубокий сравнительный анализ различных технологий и понять, где чего-то не хватает, а где хватает чего-то с избытком (если, конечно, есть такое). Если что-то уже успешно используется, то зачем предлагается что-то новое? Если предлагается что-то новое, то, значит, все победные реляции старого — пустая бравада? Что же мешает иметь какой-то один фреймворк для решения определённого круга задач, и не выдумывать постоянно что-то новое? И можно ли, наконец, изучить какие-то общие принципы (основы-полагающие), и не завязываться на конкретные фреймворки, и, соответственно, не спрашивать в вакансиях знание конкретных фреймворков, а спрашивать знания в области решения самих задач (но не их реализаций)?
Хоть бы кто-нибудь вышел и сказал, что мы нашли (при помощи) определённые закономерности построения ПО, и теперь ПО можно делать автоматически (уже без ИИ). Но, почему-то, всё происходит ровно наоборот. Где же высокий уровень экспертизы?
Троянская война на техническом ресурсе звучит как эпическое противостояние компьютерных вирусов и средств защиты от них.
Пэрри, кстати, успел доказать практически возможность устного запоминания и передачи такого объема данных (перед тем, как в 1935 году случайно застрелился, распаковывая чемодан). Для этого исследователь отправился в Югославию и стал изучать живую устную эпическую традицию сербских сказителей. В ходе одной из таких записей была зафиксирована поэма, по объему значительно превосходившая «Одиссею».
После смерти Пэрри его ассистент Альберт Лорд продолжил эту работу и в 1960 году опубликовал книгу The Singer of Tales. Ее главный вывод стал одним из фундаментальных для современного изучения Гомера: устный эпос нельзя адекватно понимать по модели письменной литературы. Устный эпос может существовать не как один неизменный объект, а как множество реализаций одной структуры (то есть, если бы записанной оказалась другая версия «Одиссеи», а не та, что дошла до нас, отличалась бы она в целом не сильно).
Это-то, как раз, и есть самый спорный вопрос! Помнится, ещё некий Анатолий Тимофеевич Фоменко, тот, который из "Новой хронологии", усомнился в долгой передаче из уст в уста. Тут, ведь, ещё вопрос языка: должен сохранятся язык, а за тысячу лет любой язык изменится сильно. Труднее всего представить отсутствие различных вариантов, ведь, если бы всё передавалось из уст в уста, то обязательно возникали бы варианты. Или придётся предположить, что изустная передача, наоборот (то есть — против письменной передачи, когда переписчик легко правит оригинал), способствует некому закреплению варианта. Изустное сказание оказывается, таким образом, неким священнодействием, когда искажение — это нарушение исходного кода (легаси?))). В этом во всём есть значительная доля фантастики. Трудно исключить. Именно поэтому, на сегодняшний день, более правдоподобной выглядит гипотеза "Новой хронологии", согласно которой вся "Иллиада" и "Одиссея" — это позднее высоколитературное описание реальной Троянской войны, которое никогда не передавалось из уст в уста. При этом, реальная Троя — это современный Стамбул. И, если бы Шлиман действительно взял томик Гомера и прошёлся бы даже и по современному Стамбулу, то он нашёл бы гораздо большее соответствие описанным в греческом эпосе событиям, чем тот городишко, который он откопал на совсем другом берегу.
P.S. Совершенно не хочу порождать новый разговор вокруг Новой Хронологии. Упомянул для полноты картины. Не более.
Интересно, может ли помочь ситуации наличие транзитного счёта, относящегося к самому банку, на который перечисляются деньги до совершения всех проверок, и специального дежурного ответственного (!) сотрудника, который должен подключаться к каждой спорной сделке?
Безопасность человека должна иметь более высокий приоритет, чем выполнение его распоряжений, а уже затем система должна следовать командам пользователя, пояснил Инглис.
[Точнее, не компилируемого, а скомпилированного (уже!) файла.]
Другими словами, нужна точка запуска. Строго говоря, операционная система должна иметь некий специальный раздел, где размещаются программы. Мы обычно исходим из того, что исполняемый файл может располагаться где угодно в файловой системе компьютера, куда мы его кинули, и это настоящий произвол! Но вопрос ещё и в том, зачем нам знать, где сидит фазан наш исполняемый файл. Мы хотим иметь доступ к различным компонентам/модулям нашего приложения? К данным? Но, разве, данные не должны храниться отдельно от самих программ?
Расположение библиотечного кода
Почему всё время говорится о компиляции? Компилятор и так знает, что и где расположено.
Импортированные сущности
Нужно что-то вроде Git/Docker. ;-)
...
В общем, не очень понятно, к чему всё это? Если бы речь была о том, что нужно запущенной программе, тогда да. Тогда нужно было бы передавать в саму программу ещё и третий объект, который и содержит всю информацию. А ещё можно было бы (и это уже высший пилотаж!) передавать информацию программе о том, что она "запускается" на этапе разработки, что это ещё не запуск целевого кода, а, так сказать, "запуск" исходного кода, когда можно тестирование вводить (к примеру), и какие-то операции с кодом делать в среде разработки.
Да. Закончится Интернет. А какой смысл в технологиях, когда нельзя сделать запрос на сервер? Мы вернёмся в каменный век, когда (к примеру!) табель в отдел кадров носили на дискете (спасибо, ещё, что в Excel). Недавно ещё такое было.
Это означает, что все против всех будут атаки делать. ИТ может закончится гораздо раньше, чем электричество. ИИ просто не успеет взлететь. Хотя, данный меморандум подталкивает ситуацию к сюжету фильма "Терминатор".
[ Ну, я даже и не джун... ;-( ]
Во-первых, можно поменять алгоритм. Если, например, речь идёт о сортировке элементов некоторого массива, то на разных данных более быстрыми будут разные алгоритмы. Различие в данных относится и к их размеру (тут в дело вступают константы оценок сложности), и к их содержанию (бывают, так сказать, частично упорядоченные массивы). В случае, если речь идёт, например, о построении матричного профиля временного ряда (это такая функция, которая сопоставляет каждому фрагменту временного ряда расстояние до заданного образца из другого временного ряда: Вы проводите скользящее окно фиксированной ширины/длины вдоль временного ряда и получаете новый временной ряд, который и называется матричным профилем), то его непосредственное вычисление часто оказывается невозможным (слишком много сравнений!), зато имеются техники, позволяющие существенным образом сократить количество сравнений (и вычислять матричный профиль за секунды и минуты против часов и дней).
Во-вторых, можно "прошерстить" сам алгоритм, и проверить правильно его реализации. Можно попытаться переписать его, возможно, выбрав другие структуры данных (с учётом времени доступа и времени обновления структуры). Ещё бывает очень дорогим вызов процедур/функций. Плюс оптимизация компилятора. И не забудем про кеширование в оперативной памяти. А многопоточность? Вот, бывает так, что процесс хочет записать что-то в память, а память ещё не готова принять данные?
В-третьих, (а, точнее, во-первых!), надо всё тщательно измерить. Любое оценочное суждение должно быть подкреплено числом. Запускать надо на разных конфигурациях/машинах. Надо точно знать, точно ли, что это колесо доедет до Москвы, а до Казани не до едет.
А можно немного позанудствовать? Почему нельзя написать "Мы проверили черновики..."? Могут ли быть ещё какие-то нетипичные причины ошибки? И точно ли то, что Вы искали именно причины ошибок.
А если просто завершить предложение "... причины ошибок в [наших] текстах"?
Оказывается, стандарты можно настраивать, но ещё настраивать можно и обучающие материалы! Почему бы не использовать глагол "корректировать"? Например: "Это позволило нам скорректировать внутренние стандарты и обучающие материалы для авторов". К тому же, само слово "настраивать" (точнее, его форма) предполагает некое протяжённое во времени действие, как будь-то Вы, теперь, постоянно всё настраиваете, а смысл заключается, как раз, в том, чтобы провести анализ и по результатам этого анализа предпринять некое однократное действие.
Как резкий поворот мысли! А, ведь, можно было поставить точку, ведь, и так понятно, ради чего корректируются стандарты и руководства.
Написание текстов — трудная работа. Но, порою, достаточно немного отодвинуться от собственного текста, прочитать на свежую голову, чтобы увидеть все ошибки и огрехи. А ещё можно распечатать. Не пожалеть бумаги и тон(н)ера. С бумаги это всё как-то виднее. ;-)
Как правильно:
Тут можно не согласиться. Тире обычно появляется там, где пропускается слово. Здесь пропущено слово "есть" ("Аз есмь...") или, как ещё раньше говорили "суть". Почему-то это простое правило (про пропуск слова) забывают.
В естественном и убывающем порядке важности:
Выбрал не тот алгоритм/структуру данных; дефекты реализации.
Незнакомая мне особенность языка.
Неправильная/неэффективная технологическая платформа/технология/язык программирования.
Возможно, упустил что-то ещё.
Самый страшный вопрос. Вот так сядешь, задашься у... немедленно куда-то "улетаешь". Невозможно понять/принять отсутствие. А как это, когда ничего нет? Запретный вопрос. Очень страшный.
Понятное дело, что всякая ОС реализуется снизу. Но проектировать её надо сверху. Нужно что-то предложить пользователю, некую модель приложений.
Если можно было бы эти медали "перелить" в отечественные операционные системы, облака, офисные пакеты, матлабы, фотошопы, иллюстраторы и прочие акробаты...
Извините, но я — совсем тёмный. Не понимаю, как могут приходить кому-то какие-то письма. Допустим, на noreply.us установлен почтовый сервер, то, верно ли я понимаю ситуацию, что этот сервер может принять входящее письмо по адресу "[что-то-там]@noreply.us"?
"Мысль изреченная есть ложь." (с)
И только разговор проникновенный
Связать способен Будущее с Прошлым
И осветить всю жизнь Истиной Любви.
Вместо простых оценочных суждений, было бы здорово прочитать глубокий сравнительный анализ различных технологий и понять, где чего-то не хватает, а где хватает чего-то с избытком (если, конечно, есть такое). Если что-то уже успешно используется, то зачем предлагается что-то новое? Если предлагается что-то новое, то, значит, все победные реляции старого — пустая бравада? Что же мешает иметь какой-то один фреймворк для решения определённого круга задач, и не выдумывать постоянно что-то новое? И можно ли, наконец, изучить какие-то общие принципы (основы-полагающие), и не завязываться на конкретные фреймворки, и, соответственно, не спрашивать в вакансиях знание конкретных фреймворков, а спрашивать знания в области решения самих задач (но не их реализаций)?
Хоть бы кто-нибудь вышел и сказал, что мы нашли (при помощи) определённые закономерности построения ПО, и теперь ПО можно делать автоматически (уже без ИИ). Но, почему-то, всё происходит ровно наоборот. Где же высокий уровень экспертизы?
Троянская война на техническом ресурсе звучит как эпическое противостояние компьютерных вирусов и средств защиты от них.
Это-то, как раз, и есть самый спорный вопрос! Помнится, ещё некий Анатолий Тимофеевич Фоменко, тот, который из "Новой хронологии", усомнился в долгой передаче из уст в уста. Тут, ведь, ещё вопрос языка: должен сохранятся язык, а за тысячу лет любой язык изменится сильно. Труднее всего представить отсутствие различных вариантов, ведь, если бы всё передавалось из уст в уста, то обязательно возникали бы варианты. Или придётся предположить, что изустная передача, наоборот (то есть — против письменной передачи, когда переписчик легко правит оригинал), способствует некому закреплению варианта. Изустное сказание оказывается, таким образом, неким священнодействием, когда искажение — это нарушение исходного кода (легаси?))). В этом во всём есть значительная доля фантастики. Трудно исключить. Именно поэтому, на сегодняшний день, более правдоподобной выглядит гипотеза "Новой хронологии", согласно которой вся "Иллиада" и "Одиссея" — это позднее высоколитературное описание реальной Троянской войны, которое никогда не передавалось из уст в уста. При этом, реальная Троя — это современный Стамбул. И, если бы Шлиман действительно взял томик Гомера и прошёлся бы даже и по современному Стамбулу, то он нашёл бы гораздо большее соответствие описанным в греческом эпосе событиям, чем тот городишко, который он откопал на совсем другом берегу.
P.S. Совершенно не хочу порождать новый разговор вокруг Новой Хронологии. Упомянул для полноты картины. Не более.
Интересно, может ли помочь ситуации наличие транзитного счёта, относящегося к самому банку, на который перечисляются деньги до совершения всех проверок, и специального дежурного ответственного (!) сотрудника, который должен подключаться к каждой спорной сделке?
Да-да. Для Вашей же безопасности! Вот-вот. :-)
Огромное спасибо за возможность целиком прочитать целую главу! Стала понятна логика. Что-то даже заинтересовало читать дальше.
А, вообще, Вам не нужны редакторы? Этому можно научиться (если нет опыта)? А Авторы нужны?
Очень интересно!
[Точнее, не компилируемого, а скомпилированного (уже!) файла.]
Другими словами, нужна точка запуска. Строго говоря, операционная система должна иметь некий специальный раздел, где размещаются программы. Мы обычно исходим из того, что исполняемый файл может располагаться где угодно в файловой системе компьютера, куда мы его кинули, и это настоящий произвол! Но вопрос ещё и в том, зачем нам знать, где сидит
фазаннаш исполняемый файл. Мы хотим иметь доступ к различным компонентам/модулям нашего приложения? К данным? Но, разве, данные не должны храниться отдельно от самих программ?Почему всё время говорится о компиляции? Компилятор и так знает, что и где расположено.
Нужно что-то вроде Git/Docker. ;-)
В общем, не очень понятно, к чему всё это? Если бы речь была о том, что нужно запущенной программе, тогда да. Тогда нужно было бы передавать в саму программу ещё и третий объект, который и содержит всю информацию. А ещё можно было бы (и это уже высший пилотаж!) передавать информацию программе о том, что она "запускается" на этапе разработки, что это ещё не запуск целевого кода, а, так сказать, "запуск" исходного кода, когда можно тестирование вводить (к примеру), и какие-то операции с кодом делать в среде разработки.
Блин! Вот дали бы старым программистам нынешние гигабайты, их бы программы не только летали бы, но и на лету много чего ещё всякого полезного делали!!
Если есть Duck-тест, то почему бы не быть Doom-тесту?! ;-)