"как проще попасть в топ 10 яндекса" - нейросетью ищем подходящие документы, нейросетью ранжируем. Блобов с весами (скорее всего) в репозитории нет
"как обойти модерацию объявления" - ну может есть какой-то стоп-лист слов. Но все равно скорее всего есть какой-то скоринг, либо нейросетью, либо живыми людьми.
"как получить больше заказов в такси" - такси и так говорит как получить больше заказов. Такси берет с заказов комиссию, больше зарабатывают водители - больше получает такси. "Как обмануть такси и получать бабки ничего не делая" - это еще может быть, но это еще найти надо. Те, кто пишет этот код, - тоже же об этом думают, а вы видите код впервые. Я бы не стал утверждать про "немалые шансы".
"как получить минимальную цену поездки на такси" - ну видите вы алгоритм "если вокруг тебя много желающих уехать, а желающих везти - мало, то поставить коэффициент повыше". И что? Коэффициент динамический, распределения заявок/водителей в момент заказа у вас нет. "Надо пойти туда, где поменьше народу хочет уехать" - это и без утечек очевидно.
Автоматы достаточно сложные и зависят от динамических данных; знания как они работают обычно недостаточно чтобы его обойти. Конечно, белый ящик проще взламывать, чем черный, но это не "шансы немалые".
Ну только порядковые числа широкоизвестных европейских языков не соответствуют программистским (на самом деле математическим) индексам. Потому что когда языки появлялись - математика была, скажем так, очень слабо развита. И ошибочно (но исторически раньше) стали говорить "элемент номер 3" про тот после которого станет 3, а не тот перед которым было 3.
Продам комплект "приставка + скрепка (ручной работы)". Приставка за $1000, скрепка за $200, но покупаете комплект - так и быть скину, за $1150. Что? Скрепка в нагрузку? Не понимаю о чем вы.
КВт в час - это как метры в секунду, КВт/ч, это довольно странная единица. Единица измерения энергии - киловатт-час, КВт*ч. Киловатт-часы в час - это и есть киловатты, они же джоули в секунду. Неаккуратная конвертация из джоулей-в-месяц в киловатты (киловатт-часы в час) может приводить к ошибкам в 3600 раз - я не проверял вашу арифметику, но возможно именно это здесь и произошло.
Схема рассчитана на определённый уровень информационной безопасности потому, что люди, которые ее разрабатывали, обладают недостаточно высокой квалификацией. Более квалифицированные специалисты могут сделать защиту от больших дураков.
Я не особо филолог, но двоеточие - "более сильный" разделитель, чем запятая. "В отличие от" относится к откату, а не к "постепенно". Возможно, лучше было написать "постепенно и неотвратимо" - в отличие от бекенда, который можно откатить. Получается, что кусочек "в отличие от" вы выдергиваете из контекста отката.
в отличие от обновлений бэкенда, в этом случае откатить приложение до более низкой версии не получится
Бекенд можно оперативно закатить обратно, если что-то пошло не так. Но да, конечно, бекенд раскатывается не мгновенно (если у вас не один сервер), это нужно учитывать.
GET /order/<id>/feedback-screen и PUT /order/<id>/feedback
Подразумевая, что если я что-то сохранил через PUT, через GET я получу примерно то же самое. Очевидно, что feedback и feedback-screen - разные ресурсы.
Циферблатом можно пользоваться как компасом строго потому, что за сутки стрелка делает два оборота, а солнце - один. И известно что в полдень солнце на юге. Если момент отсчета не менять (начало суток - в момент когда солнце ниже всего за горизонтом), и стрелка делает один оборот за сутки - то можно легко адаптировать алгоритм.
[...] когда большинство людей считает по порядку, то они не начинают с нуля. они начинают с единицы.
И это скорее непрофессиональное когнитивное искажение. В том смысле, что если бы они начинали с нуля - связанная со счетом математика была бы проще. Но считать предметы люди научились сильно раньше, чем придумали ноль...
А ноль - это точка. Это не год, это всего лишь момент времени между первым годом до н.э. и первым годом после оной.
И это тоже скорее ошибка, нежели гениальная задумка. Потому что при работе с датами вокруг нуля надо помнить про отсутствие нулевого года. В астрономическом календаре, например, нулевой год есть. Потому что так реально удобнее.
Впрочем, я топлю исключительно за идею "считать по порядку с нуля, а года нумеровать не натуральными числами в два направления, а целыми (с центральным нулевым годом)", идея придумать новые секунды мне не близка - они получатся такими же искусственными как и текущие, шило на мыло .
- я могу пойти к питонщикам и сказать, что их_такой_синаксисис полное говно
Можете, и кто-то даже с вами согласится - _поле для защищенных и __поле для приватных, ну что это за дичь!
- могу пойти к сишникам/джавистам и сказать, что их синтаксис и типизация слишком сложна
Ну не совсем, шаблоны в крестах правда сложные, но в джаве типизация простая - к ней основная претензия что она слишком простая и недостаточно мощная, многословно получается.
- пойти в любой ООП и сказать, что прототипное наследование - отстой
Прототипное наследование - атрибут JS, в других ОО языках оно не используется.
Проекция используется в картографии, в том числе и в масштабных топокартах.
На небольших участках (пара сотен километров) в средних широтах - искажения не слишком заметны, участок поверхности слабо отличим от плоскости. Соответственно, на таких картах можно один раз посчитать (1км поверхности = 1см карты) и пользоваться во всех направлениях.
Если же сделать карту всей земли - то 1см в районе полюса и на экваторе будут различаться очень сильно. Соответственно, прежде чем отвечать "есть ли тут 20км расстояния" нужно ответить "какова длина одного километра поверхности в сантиметрах карты на нужной широте"
Это не лучше велосипеда автора - масштабировать в зависимости от широты надо также, индексы не работают.
На экваторе 20 км - это одна дельта градусов долготы, в средних широтах - другая, в полярных районах - третья. Нужно масштабировать в зависимости от широты.
Можете предложить способ "посчитать длину хорды" проще? :) Посчитать расстояние в градусах по теореме пифагора - некорректно, потому что масштабы по осям разные (грубо говоря, получится не окружность радиусом 20 км, а эллипс с, кажется, большей полуосью в 20 км).
широта и долгота становятся X и Y осями просто на плоскости
Нет, не становятся просто. Их нужно отмасштабировать - один градус долготы на экваторе, в средних широтах и за полярным кругом имеют совсем разную длину (в то время как градус широты можно считать неизменных). Собственно, автор правильно и масштабирует. Другой вопрос, конечно, зачем делать это руками, когда в мейнстримовых СУБД есть специальные инструменты для работы с геоданными (в т.ч. специальные индексы).
"как проще попасть в топ 10 яндекса" - нейросетью ищем подходящие документы, нейросетью ранжируем. Блобов с весами (скорее всего) в репозитории нет
"как обойти модерацию объявления" - ну может есть какой-то стоп-лист слов. Но все равно скорее всего есть какой-то скоринг, либо нейросетью, либо живыми людьми.
"как получить больше заказов в такси" - такси и так говорит как получить больше заказов. Такси берет с заказов комиссию, больше зарабатывают водители - больше получает такси. "Как обмануть такси и получать бабки ничего не делая" - это еще может быть, но это еще найти надо. Те, кто пишет этот код, - тоже же об этом думают, а вы видите код впервые. Я бы не стал утверждать про "немалые шансы".
"как получить минимальную цену поездки на такси" - ну видите вы алгоритм "если вокруг тебя много желающих уехать, а желающих везти - мало, то поставить коэффициент повыше". И что? Коэффициент динамический, распределения заявок/водителей в момент заказа у вас нет. "Надо пойти туда, где поменьше народу хочет уехать" - это и без утечек очевидно.
Автоматы достаточно сложные и зависят от динамических данных; знания как они работают обычно недостаточно чтобы его обойти. Конечно, белый ящик проще взламывать, чем черный, но это не "шансы немалые".
Это только по расстоянию 0,15625%. А еще по массе воды очень немного по сравнению со всей массой.
Ну только порядковые числа широкоизвестных европейских языков не соответствуют программистским (на самом деле математическим) индексам. Потому что когда языки появлялись - математика была, скажем так, очень слабо развита. И ошибочно (но исторически раньше) стали говорить "элемент номер 3" про тот после которого станет 3, а не тот перед которым было 3.
Продам комплект "приставка + скрепка (ручной работы)". Приставка за $1000, скрепка за $200, но покупаете комплект - так и быть скину, за $1150. Что? Скрепка в нагрузку? Не понимаю о чем вы.
КВт в час - это как метры в секунду, КВт/ч, это довольно странная единица. Единица измерения энергии - киловатт-час, КВт*ч. Киловатт-часы в час - это и есть киловатты, они же джоули в секунду. Неаккуратная конвертация из джоулей-в-месяц в киловатты (киловатт-часы в час) может приводить к ошибкам в 3600 раз - я не проверял вашу арифметику, но возможно именно это здесь и произошло.
Надо смотреть вблизи - там почти наверняка видно следы инструментов.
К плавильне какие претензии, такими еще в Древнем Египте пользовались.. :)
Схема рассчитана на определённый уровень информационной безопасности потому, что люди, которые ее разрабатывали, обладают недостаточно высокой квалификацией. Более квалифицированные специалисты могут сделать защиту от больших дураков.
В IT)
Я не особо филолог, но двоеточие - "более сильный" разделитель, чем запятая. "В отличие от" относится к откату, а не к "постепенно". Возможно, лучше было написать "постепенно и неотвратимо" - в отличие от бекенда, который можно откатить. Получается, что кусочек "в отличие от" вы выдергиваете из контекста отката.
Выдергиваете из контекста.
Бекенд можно оперативно закатить обратно, если что-то пошло не так. Но да, конечно, бекенд раскатывается не мгновенно (если у вас не один сервер), это нужно учитывать.
GET /order/<id>/feedback-screen и PUT /order/<id>/feedback
Подразумевая, что если я что-то сохранил через PUT, через GET я получу примерно то же самое. Очевидно, что feedback и feedback-screen - разные ресурсы.
Я не специалист, но могу предположить что всасываются только те звенья, которые прошли через пресс протеаз.
Наверно и пептиды могут попадаться, но в недостаточном для ощутимого влияния количестве.
Циферблатом можно пользоваться как компасом строго потому, что за сутки стрелка делает два оборота, а солнце - один. И известно что в полдень солнце на юге. Если момент отсчета не менять (начало суток - в момент когда солнце ниже всего за горизонтом), и стрелка делает один оборот за сутки - то можно легко адаптировать алгоритм.
И это скорее непрофессиональное когнитивное искажение. В том смысле, что если бы они начинали с нуля - связанная со счетом математика была бы проще. Но считать предметы люди научились сильно раньше, чем придумали ноль...
И это тоже скорее ошибка, нежели гениальная задумка. Потому что при работе с датами вокруг нуля надо помнить про отсутствие нулевого года. В астрономическом календаре, например, нулевой год есть. Потому что так реально удобнее.
Впрочем, я топлю исключительно за идею "считать по порядку с нуля, а года нумеровать не натуральными числами в два направления, а целыми (с центральным нулевым годом)", идея придумать новые секунды мне не близка - они получатся такими же искусственными как и текущие, шило на мыло
.
Можете, и кто-то даже с вами согласится - _поле для защищенных и __поле для приватных, ну что это за дичь!
Ну не совсем, шаблоны в крестах правда сложные, но в джаве типизация простая - к ней основная претензия что она слишком простая и недостаточно мощная, многословно получается.
Прототипное наследование - атрибут JS, в других ОО языках оно не используется.
Но в целом вы конечно правы, это глупо.
А вы проверьте численно.
На небольших участках (пара сотен километров) в средних широтах - искажения не слишком заметны, участок поверхности слабо отличим от плоскости. Соответственно, на таких картах можно один раз посчитать (1км поверхности = 1см карты) и пользоваться во всех направлениях.
Если же сделать карту всей земли - то 1см в районе полюса и на экваторе будут различаться очень сильно. Соответственно, прежде чем отвечать "есть ли тут 20км расстояния" нужно ответить "какова длина одного километра поверхности в сантиметрах карты на нужной широте"
Это не лучше велосипеда автора - масштабировать в зависимости от широты надо также, индексы не работают.
Нет, не знаете :)
На экваторе 20 км - это одна дельта градусов долготы, в средних широтах - другая, в полярных районах - третья. Нужно масштабировать в зависимости от широты.
Можете предложить способ "посчитать длину хорды" проще? :)
Посчитать расстояние в градусах по теореме пифагора - некорректно, потому что масштабы по осям разные (грубо говоря, получится не окружность радиусом 20 км, а эллипс с, кажется, большей полуосью в 20 км).
Нет, не становятся просто. Их нужно отмасштабировать - один градус долготы на экваторе, в средних широтах и за полярным кругом имеют совсем разную длину (в то время как градус широты можно считать неизменных). Собственно, автор правильно и масштабирует. Другой вопрос, конечно, зачем делать это руками, когда в мейнстримовых СУБД есть специальные инструменты для работы с геоданными (в т.ч. специальные индексы).