xPoint

заниматься коддингом - это по сути "глагольный оборот" для выражения действия с коддингом. Опять-же в англ. языке это будет обозначаться как coding и будет обозначать кодирование (доказательства см. выше) Если вам Ожегов не авторитет в толковании слов, то как доказать вам значение слова? Именно для этого и создают толковые словари. А если ваша логика не правильная? Если вам кажется, но на самом деле это не так? А если мы оба ошибаемся и эти слова обозначают совсем другое. Что тогда делать? Может спросить у людей, кто что думает по этому поводу? Или устроить голосование по этому поводу?

Если придраться, то выходит вот что: по словарю Ожегова по гугловскому переводчику засекречивание карт или документов - засекречивание, можно сказать шифрование документов кодирование, т.е. шифрование кодировка, кодовая система шифрование Т.е. в обоих случаях и кодирование и coding обозначают шифрование. Из этого можно сделать простой вывод, что слова кодирование и coding(и кодинг тоже) являются фактически одинаковыми словами, только на разных языках.

Одно (кодирование) - русский термин, второе (кодинг) - англоязычный (т.е. происходит от англ. coding). Хотя обозначают одно и то же http://translate.google.com/translate_t?hl=ru#en|ru|coding

Вспомнил старый анекдот на эту тему:

этих стандартов кодирования может быть сотни. Главное придерживаться одного стандарта везде, чтобы код был понятным без лишних комментариев.

зависит от того что ты хочешь защитить. В некоторых случаях может хватить и этого. А в некоторых может не хватить. Если есть конкретные критерии безопасности, то нужно руководствоваться ими. Если их нет, то стоит самостоятельно их выяснить, смоделировав ситуации взлома.

Почему бы тебе не найти уже готовый скрипт обратной связи

Не за что. В следующий раз будь повнимательнее :-)

синтаксис вроде верный, должно работать по идее. у меня такой запрос сработал: SELECT * FROM articles WHERE CONCAT( name, latin_name ) LIKE '%zip%' LIMIT 0 , 30 Вернул 2 результата. може пробел мешает?

так что-ли? SELECT * FROM table WHERE CONCAT(name,family) LIKE '%text%'

Попробуй менять не все сразу а по частям: сначала [size=3] на <font size="3px">, а потом [/size] на </font>

Зато будем иметь очень много проблем на форумах, отвечая на такие вот вопросы "веб-мастеров".

функция is_dir() проверяет существует ли директория, а функция mkdir() создает папку

Можно использовать метод __get для обеспечения read only. По-другому мне кажется невозможно защитить свойство.

Как ты думаешь, что это может значить ? Не зря ведь разработчики поместили это замечание в справочнике, думаю стоит прислушаться к их словам.

а ты читал весь пост? Я не советовал ему ставить генту, я написал, что там много статей, которые можно с успехом применить на других дистрибутивах.

советую посмотреть вики gentoo. Там в основном все про gentoo, но достаточно много статей, которые можно с успехом применить и на других дистрибутивах. Также советую http://www.opennet.ru/. Там также есть форум. А в остальном - гугль тебе в помощь. Без него никуда.

Вобщем, взяв идею rash я проверил работу автоинкремента на tinyint в MySQL версии 5.0.67. Оказалось работает не совсем так как я предполагал. Вот таблица: CREATE TABLE IF NOT EXISTS `testtable` ( `id` tinyint(2) NOT NULL auto_increment, `title` varchar(25) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; вот код пхп: <?php $con = mysql_connect("localhost",'root',''); mysql_select_db('test'); //делаем вставку for($i=0;$i<127;$i++){ $res = mysql_query("INSERT INTO testtable VALUES(NULL,'test_$i')"); } //удаляем for($i=0;$i<25;$i++){ mysql_query("DELETE FROM testtable WHERE id='$i'"); } //снова пробуем вставить for($i=0;$i<256;$i++){ $res = mysql_query("INSERT INTO testtable VALUES(NULL,'test_$i')"); if(!$res)break; } echo $i."\n";//на какой позиции остановились echo mysql_error($con)."\n";//какую ошибку вывел ?> код вывел: Т.е. поначалу все шло так как я и предполагал. Дойдя до верхней границы, автоинкремент увеличил число на 1 и попытался сделать запись. TINYINT увидел, что число больше верхней границы и уменьшил его до максимально возможного и попытался сделать запись. Все бы прошло нормально, если бы поле ид не было PRIMARY KEY. Первичный ключ должен быть уникальным и не должен повторяться. Именно из-за PRIMARY KEY вылезла ошибка и вставка прекратилась. И удаление никоим образом не повлияло на вставку.

невозможно. потому что загружаемый на сервер файл будет доступен в пхп только после того как весь загрузится и будет сохранен в tmp-папку. После данные о загруженном файле будут доступны в массиве $_FILES

Конечно выходит из строя, поскольку больше не сможет генерировать уникальных ключей. А насчет добавления записей, то скорее всего будет перезаписывать последнюю запись, по правилам работы с INT и генерировать предупреждение

из оф. мана

это не правится, потому что auto_increment так и работает

а в этот раз на миранду это подействовало. Коннект был нестабильный и работало все очень слабо. а у меня линукс, так что мне есть смысл его юзать

второй источник у тебя это http://habrahabr.ru/blogs/im/49778/ Вот еще по теме http://habrahabr.ru/blogs/im/49877/ К тому же по всей видимости AOL прекратила отключение альтернативных клиентов, поскольку у меня сейчас и миранда и pidgin пашут нормально с украинского IP (вчера с греческого pidgin хорошо шёл)