Сегодня наткнулся на неожиданность при загрузке программы в iTunes Connect для публикации в AppStore. Моя программа использует шифрование для защиты информации от неавторизированного распространения. Распространение приложений с шифрованием ограничено законодательством США и контролируется Департаментом Промышленности и Безопасности Министерства торговли США — Department of Commerce (DOC) Bureau of Industry and Security (BIS). Для тех, кому интересно — что было, и что стало…

Началось с того, что некоторые сообщения, приходящие из списка рассылки по subscribe.ru (да-да, я знаю, что давно пора перейти на RSS), показывались через интерфейс гуглопочты обрезанными. При том, если смотреть через IMAP или POP3 или исходник сообщения с того же гугл интерфейса — то все ок — письмо целое.

В ФАКе написано, что когда письмо обрезано, то внизу письма можно нажать на кнопку «Посмотреть сообщение полностью», но такой опции нет почему-то, по крайней мере у меня. А у вас?

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

Узнал, что в веб-интерфейсе гуглопочты применяются вот такие ограничения:
102kb plaintext'а
51 страниц
102369 символов
(upd.: 56769 символов — проверил)
30 цепочек писем.

Странные лимиты. Я их полностью не проверял, но попробуйте сами себе написать длинное письмо. Тупо обрезает и даже не извиняется. :)

Я верю, что у кого-то из хабрасообщества возникали подобные вопросы, может, кто-то объяснит?
Или таки я что-то недопонял? Ведь это как-то даже не похоже на Гугл.

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

Первое. Эту концепцию обычно называют «заставить политиков сделать что-то под влиянием общественного резонанса». Определение это не верно. Потому что «заставить» любого человека сделать что угодно — это когда пистолет к виску подносишь. Очевидно, что слово, даже повторенное всеми жителями планеты, в пистолет не превращается, и любой политик может его игнорировать. Поэтому правильнее было бы сказать «убедить» или «спровоцировать» действия властей методом общественного резонанса.

Что это значит? Это значит, что если власть отреагировала на шум в интернете положительно, значит, сама власть считает нужным реагировать на такие случаи, и ей не хватало только сообщений о них — что и дал интернет. Второй причиной может быть то, что власть знала о проблемах, но предпочитала оттягивать момент их решения, потому что «люди и так не жалуются». А вот начали шумно жаловаться — пришлось пойти решать.

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

Идея в том, чтобы ограничить понижение кармы каждого пользователя в сутки определённым значением. Здесь уже есть несколько вариантов.

• Для кармы больше 5 за день можно потерять не больше 80% кармы. Это обусловлено тем, что ограничение минусования не должно внести «вседозволенности» в ряды людей с очень большой кармой. Например, чтобы избежать ситуации «продвинутого тролля», который качается, а потом троллит по полной.
• Для кармы меньше 5 за день можно потерять не больше 10 пунктов кармы. Насколько я понимаю, нет ранжирования при отрицательной карме, соответственно и 10 пунктов достаточно, чтобы моментально остудить заслуживающего это человека.

В NTFS заложена поддержка длины пути больше, чем поддерживает Windows. В Windows длина пути ограничена константой MAX_PATH, равной 260 символам. Почему именно такое число, а не, скажем, 255?

Начались у меня странные глюки в ICQ — при добавлении контакта один случайный удалялся.
решил глянуть что за трабла — скачал Qip Contact Manager и внимательно просмотрел всю инфу.

Итого:
* 67 активных контактов
* 189 «левых»

Если посчитать — 256 штук. Видимо такое ограничение на количество контактов.
Интересно почему разработчики поставили ограничение на размер 1 byte?
И почему удаленные контакты хранится на сервере, а не удаляются?

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

Создавая очередной сервис, я исхожу из следующих соображений:
1. Логин не должен быть слишком короткий (у меня сейчас от 3 символов включительно, для более крупных систем, типа GMail, используется от 6).
2. Логин не должен быть слишком длинный, иначе в каком-нибудь интерфейсе он начнёт что-нибудь неправильно распирать. Я использую логины до 20 символов, но интересно выслушать ваши мнения по этому поводу.
3. Логин может использоваться в адресной строке, при интеграции с SMS и проч. Поэтому оставляем только латинские символы, цифры, подчёркивание, дефис и точку.
3а. Если логин может быть использован как имя поддомена, то эти условия сокращаются до символов латинского алфавита, цифр и дефиса (дефис не может быть первым и последним, он не может повторяться).
4. Иногда очень удобно использовать двойную навигацию: по логину и ID. Например, у нас на одном сервисе используется адрес domain.com/users/<login> для пользователей с логином и domain.com/users/<id> для тех, у кого нет логина (т. н. виртуальные профили, которые зарегистрированы администрацией или другими пользователями). Это приводит к тому, что логин не может состоять только из цифр, чтобы не путать его с идентификатором.
5. Слова-исключения: www, mail, ns1, ns2, ns3, ns4, admin, god, moderator, editor. Первые 6 являются исключениями для совместимости с поддоменами. А какие слова-исключения используете вы?

И основной вопрос к читателям: какие ограничения стоят у вас, и что я забыл?

Что и как и как много хранит MySQL?

Данный материал создан специально для программистов, которые быстро смогут определиться какой тип данных лучше выбрать для хранения значений в БД MySQL.

Для затравки, интересная цитата из мануала по MySQL:
«Максимальный размер записи в MyISAM составляет 65534 байтов. Каждый BLOB или TEXT-столбец засчитывается здесь как 5-9 байтов.» — как это трактовать однозначно не понятно. НО ясно что много-примного столбцов в таблицу на засунешь. «Извращенистые программисты» — будьте аккуратны (66000 столбцов вы точно создать не сможете).

UPD: Если найдете ошибку, или я что-то где-то утаил — отпишитесь в комментах, с удовольствием добавлю.

UPD1 В первую очередь (и самый лучший вариант для новичков) прочитать ОФИЦИАЛЬНЫЙ МАНУАЛ dev.mysql.com/doc/refman/5.0/en/data-types.html (спасибо Psyh за прямую ссылку), а здесь вырезка для META обработчиков данных (как в лице программистов так и в лице машинной обработки).

UPD2 В принципе, все что написано ниже, можно прочитать по адресу www.mysql.ru/docs/man/Column_types.html (за ссылку «русского перевода», спасибо artuska).

UPD3 Еще одну неплохую ссылку предоставил 4all: newcontinent.ru/h/mysqlc/ (материал на русском)

UPD4 Цитата из комментов от egorF:
# 14«Как главный редактор русскоязычного перевода доки на MySQL, я рекомендую в него не заглядывать — он уже сказочно морально устарел.»