Заблокировали, восстановили сообщения из бэкапа, это понятно. Но в следующий раз пойдут в ход пароли «qwerty» или ещё что-нибудь. Кроме того чисто по-человечески неприятно, что пару месяцев на форуме была грязь, а администраторы не замечали.
Брат подтверждение оплаты за учёбу потерял так. Родители оплатили и выслали почтой квитанцию (первым классом, между прочим). Ходил на почту, ругался, но так и не получил. Как-то вроде договорился с деканатом, но в некоторых местах, говорят, за отсутствие квитанции могут отчислить.
Как-то решал ради интереса пример экзамена по математике прошлых лет, слитый откуда-то с интернета. Как ни странно, показалось, что часть «B» местами проще, чем «A». В «А» хотя выбор вариантов ответа ограничен, обычно дают варианты заковыристые, с подвохом, которые реально могут получиться при невнимательном решении. А в «B», например, просят решить уравнение и вписать ответ в клеточки. Ты сразу знаешь, что, во-первых, корень ровно один, а не два и не ноль (хотя из вида уравнения это неочевидно), во-вторых, в результате не может получиться, например, корень из двух, потому что в клеточки его не впишешь, а правила округления не указаны. Это существенно упрощает и ламеризует задание.
В ответе в результате вычислений точность может снизиться. Если, скажем, делить на число, определённое с высокой погрешностью, то погрешность результата вообще может взмыть до небес. Надо просто считать погрешность параллельно с основными вычислениями, тогда станет понятно, до какой точности имеет смысл записывать результат. Конечно, на ЕГЭ это вряд ли требуется :-)
Насчёт того, есть посылка или нету, я как-то напоролся. Ждал диски с музыкой из заграницы, приходил на почту, спрашивал, есть ли посылка из такой-то страны по такому-то адресу. Посмотрев в компьютере, в журналах, мне стабильно говорили, что нет. Потом я узнал, что надо спрашивать ещё «а заказная бандероль есть?», «а ценная?». У них эти вещи могут быть в разных списках, в разных журналах, на разных компьютерах, и, конечно, они не посмотрят сами везде, если не попросить специально.
А извещение тогда мне не приносили, как я выяснил, по удивительной причине: «у почтальона нет ключа от домофона и поэтому, когда он не может попасть в подъезд, от втыкает извещения в щель подъездной двери». Нормально, да? В подъезде 50 квартир. Разумеется, первый входящий соберёт все эти выпавшие из щели извещения и раскидает по нужным ящикам. И никто их не затопчет, и дети их не растащат. Я так опешил, что даже ругаться не стал, просто отдал им свой ключ :-)
Разные случаи бывают. Например, человек скачал и расшарил без разбора 100 гигов, большинство взрослой, а там где-то попалось не то, может, он сам и не смотрел. За такое сажать, кажется, перебор. В общем, без подробностей дела трудно судить.
У нас в городе наркоту купить несложно. Если поймают одного несчастного невезучего наркодилера, который не заплатил кому надо откаты, вы его тоже будете защищать? :-)
Надо же с чего-то начинать. Алсо показательные процессы эффективны.
Бывают проблемы, которые не так легко фиксаются с помощью bind.
Во-первых, если давно написанный кривой интерфейс подразумевает передачу строки с SQL-запросом в качестве параметра или возвращаемого значения. Типа такого (Java):
interface SQLDatabaseDriver {
public String getNamesQuery();
public String getValueByNameQuery(String value);
};
class SomeSpecificDatabaseDriver implements SQLDatabaseDriver {
public String getNamesQuery() { return "SELECT name FROM tbl";}
public String getValueByNameQuery(String name) {
return "SELECT value FROM tbl WHERE name='"+name+"'";
}
};
Пусть такой интерфейс использует некий класс, который наполняет коллекцию данными из произвольной SQL-базы. Интерфейс мог быть реализован 20 раз для разных сторонних баз и вдобавок опубликован с целью, чтобы сторонние разработчики писали плагины (и они их написали!). А тут вдруг задумались об SQL-инъекциях. Что делать? Оборвать руки проектировщику интерфейса, правильно. Только проблему это не решит.
Второй проблемный случай, когда мы генерируем запрос с непостоянным количеством подставляемых полей. Нам это требовалось при массовой вставке данных в базу. Делать prepare(«INSERT blahblah VALUES(?,?,?)») и потом тысячу раз execute(var1, var2, var3) существенно медленнее, чем загнать всё в один длинный INSERT. Особенно разница ощутима, когда база по сети и далеко. Мы сделали классик на перле, который инкапсулировал множественную вставку в базу, используя функцию $dbh->quote(), которая умеет экранировать спецсимволы в запросах и делает это правильно для любой СУБД, для который установлен перловый драйвер. Когда набиралась максимально допустимая длина запроса, проталкивали в сокет и начинали формировать новый запрос. Прекрасно работало и с MySQL, и с Oracle, с UTF-8 тоже. К сожалению, я не нашёл аналога $dbh->quote() в Java (плохо искал?). Ручная реализация экранирования кажется ненадёжной, так как некоторые СУБД требуют удвоение кавычки, а некоторые — добавление слэша перед ней.
На нормальных сайтах нормальная реклама. Я рекламу не блокирую, так как знаю, что некоторые сайты без показов рекламы просто закроются. Иногда под настроение на особо годных сайтах даже специально кликаю на баннеры, мне нетрудно, а людям приятно :-) Конечно, порой достаёт всякая мишура, которая висит поверх странички, загораживает пол-экрана и ещё и глючит при попытке её закрыть. Или когда на onclick открывается окошко с кучей полуголых девиц. Увы не всегда удаётся просто не посещать такие сайты. Такое фильтровать стоит, а тихие баннеры по углам пусть себе висят.
А извещение тогда мне не приносили, как я выяснил, по удивительной причине: «у почтальона нет ключа от домофона и поэтому, когда он не может попасть в подъезд, от втыкает извещения в щель подъездной двери». Нормально, да? В подъезде 50 квартир. Разумеется, первый входящий соберёт все эти выпавшие из щели извещения и раскидает по нужным ящикам. И никто их не затопчет, и дети их не растащат. Я так опешил, что даже ругаться не стал, просто отдал им свой ключ :-)
info.russianpost.ru/servlet/post_item?action=search&barCode=%s
Ввожу идентификатор непосредственно в URL вместо %s. Этот адрес года четыре работает без изменений с тех пор как я узнал про него. Рекомендую :-)
Надо же с чего-то начинать. Алсо показательные процессы эффективны.
Во-первых, если давно написанный кривой интерфейс подразумевает передачу строки с SQL-запросом в качестве параметра или возвращаемого значения. Типа такого (Java):
Пусть такой интерфейс использует некий класс, который наполняет коллекцию данными из произвольной SQL-базы. Интерфейс мог быть реализован 20 раз для разных сторонних баз и вдобавок опубликован с целью, чтобы сторонние разработчики писали плагины (и они их написали!). А тут вдруг задумались об SQL-инъекциях. Что делать? Оборвать руки проектировщику интерфейса, правильно. Только проблему это не решит.
Второй проблемный случай, когда мы генерируем запрос с непостоянным количеством подставляемых полей. Нам это требовалось при массовой вставке данных в базу. Делать prepare(«INSERT blahblah VALUES(?,?,?)») и потом тысячу раз execute(var1, var2, var3) существенно медленнее, чем загнать всё в один длинный INSERT. Особенно разница ощутима, когда база по сети и далеко. Мы сделали классик на перле, который инкапсулировал множественную вставку в базу, используя функцию $dbh->quote(), которая умеет экранировать спецсимволы в запросах и делает это правильно для любой СУБД, для который установлен перловый драйвер. Когда набиралась максимально допустимая длина запроса, проталкивали в сокет и начинали формировать новый запрос. Прекрасно работало и с MySQL, и с Oracle, с UTF-8 тоже. К сожалению, я не нашёл аналога $dbh->quote() в Java (плохо искал?). Ручная реализация экранирования кажется ненадёжной, так как некоторые СУБД требуют удвоение кавычки, а некоторые — добавление слэша перед ней.
Вообще такие истории каждый день происходят :-)