Category: литература

me

Сказочка на ночь

А давайте я вам расскажу сказу-быль об одном интернет-провайдере?

Жил-был, значится, один интернет-провайдер, и был у него биллинг, а данные биллинга жили в базе, в Постгресе. Но сказка не о Постгресе, об этом как-нибудь потом.

И вот в этой самой базе хранились все клиентские пароли. Так как разработчики были не полными идиотами, пароли они хэшировали. И на момент написания биллинга хэш-функция считалась надежной. Вот беда - было это 10 лет назад. А вторая беда - так, не беда - бедулька, я бы даже сказал; в общем, так - бедулечка, и была она в том, что пароль генерировался предсказуемым образом: одна цифра и только строчные буквы от a до z; длина 12 октетов. При этом в пароле никогда не встречалось две и более гласных или согласных подряд. От чего количество переборов исчислялось не квинтиллионами (10^18), как могло бы быть, а всего лишь сотней-другой миллиардов.

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

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

В этой сказке-были есть мораль:
1) Не используйте MD5 НИГДЕ. Ни с солью, ни без.
2) Не используйте алгоритмов, не допускающих конфигурируемого усложнения хэша.
3) Прежде чем писать генератор пароля, прикиньте количество возможных вариантов. Потому что [a-z0-9] длиной 12 байт === 36^12 == 4.73e+18. А пароль с чередующимися гласными и согласными и одной цифрой == 5^5 * 21 ^ 6 * 10 = 1.27e+11.
4) Прежде чем писать код, осильте, наконец, https://ru.wikipedia.org/wiki/PBKDF2
me

HTTP/2

В нашей записной книжечке Универсальных Решений прибыло; встречайте: очередная серебряная пуля, HTTP/2. Скоро во всех опенсорс-браузерах!

Небольшой FAQ:

Q: - Кто выиграет от этого набора мегамегафичей, призванных экономить время загрузки?
A: - Хостеры, облачные хостеры и "консультанты по хайлоаду" всех местей и расцветок.

Q: - Почему?
A: - Потому, что никто другой не получит профита после того как модули, ответственные за приоретизацию начнут писать на PHP/Python/Ruby/Node.js и прочем трешаке.

Q: - Когда это начнется?
A: - Очевидно, когда очередной стартапоориентированный задрот с Хабры переведет и творчески дополнит непонятные места в статье "HTTP/2 [подставить любой модный ЯП] Howto"

Q: - Хорошо ли это?
A: - Я считаю - отлично. В условиях кризиса всегда приятно срубить бабла с проекта, где окопалось слишком много энтузиастов. Причем, метод срубания бабла будет очень прост: ввыпилить ырубить новомодный идиотизм и вынести статику обратно на отдельный хост, где ей самое место.
me

Сказка на ночь

Быль или небыль, верить или нет - решайте сами, а расскажу я вам историю.

В далеких лихих 1990-х жили-были себе одни юристы. Они много и долго работали и заработали чуть-чуть денег. И захотели они диверсифицировать свой бизнес и организовать холдинг. Сказано - сделано: открыли они свой банк. Прошло немного времени и решили веселые юристы зайти в реальный сектор экономики, и построили свой молочный завод. И жили они мирно и радостно, и были года тучные и хорошие - когда весь бизнес давал много-много денег, столько, что оставались лишние. Ну а раз есть лишние деньги, значит надо их потратить. И посмотрели уже не мальчики, но тронутые сединой мужи по сторонам и увидели Интернет. А присмотревшись внимательнее, поняли, что зело несовершенен он, многого не хвататет, а то, что есть - сделано неправильно. И решили сделать всем хорошо.

И вот тут-то все заверте...присказке конец и начинается сказочка. Время действия - примерно 5 лет назад, 2009 год.

В интернете, по общему мнению было много хороших сервисов: Фейсбук, ВКонтакте, Мэйлру, Википедия,МВамба, Баду, Хэдхантер... да разве всех их упомнишь. Но не были эти сервисы собраны под одним крылом и не было в них должной синергии. Вообще говоря, фатальным недостатком всех этих сервисов было то, что они почему-то принадлежали разным владельцам, а не холдигу.

Мужи долго думали, морщили лбы и наконец придумали: надо взять и написать собственную социальную сеть! Проект большой, а потому сели разрабатывать его концепцию. Думали обстоятельно, почти три года, просчитывая каждую мелочь. Зато проект соцсети вышел чудо как хорош; все там было: и знакомства для души (клон Badoo), и знакомства для тела (клон Wamba), и рекрутинговый сайт (клон HH), и миниигры как на Mail.ru, и своя Википедия, и даже блоги с комментариями, фоточками и видео. А объединяла все эти сервисы своя соцсеть с мощным API. Ну, или должна была в скором будущем объединить.

Набрали полсотни программистов и начали проектировать и писать. Так как проект революционный, то и технологии были выбраны подстать: Erlang, Node.js, NoSQL. На клиентской же стороне должно было работать вебприложение. Не совсем понятно, какое, но - должно. По плану разработка до запуска должна была вестись 4 (четыре) года, два из которых уже прошли. Уже сейчас готовы основные элементы соцсети и некоторых сервисов, так что году этак в 2016 будет запущен новый конкурент ВКонтакте и Фейсбука. Люди настроены оптимистично, работа идет, нужны новые разработчики.

А тут и до игр дело дошло, и меня начали хантить. По ссылке - рассказ о новой игрушке.

Вот и сказочке конец. Выводы каждый сделает сам. Если захочет.
me

Один в поле не воин

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

О чем эта притча? О том, что малый труд есть часть большого целого. Эта мысль настолько проста для всеобщего понимания, что практически все забывают про обратную сторону медали, а именно: результаты любого труда всегда персонализированы. Ты строишь собор, и по трудам твоим тебя запомнят как гениального каменотеса, строителя или художника.

Мы все плывем в одной лодке и цель одна. Но каждый делает свое дело. Эту меру ответственности не отнять, на других не сбросить и между чужими людьми не поделить.

Дикси спроектировал интерфейс. Саша и Иван нарисовали дизайн. Я придумал архитектуру серверной части. Вместе с Эдиком и Оскаром мы написали большую часть серверного кода. В этом нам неоценимо помог Костя. Саша и Антон сделали весь клиент-сайд. Дарья и Даня оттестировали. Дима, Андрей и Артем засетапили сервера. Максим поднял систему монитоинга. Ирина запустила проект. Новая почта не состоялась бы без всех вообще и каждого в отдельности. Кто здесь главнее и ценнее, я не знаю. Да и не особо хочу знать.

P.S. Кто на проекте найдет dopefish (да-да, ту самую) - тот молодец.
me

CTPP 2.5.0

Готов пререлиз новой минорной версии CTPP: 2.5.0.
Первая версия ветки 2.5, готовая к использованию в production будет 2.5.1.

Появились итераторы; конструкция: TMPL_foreach array as iterator. Имя итератора может содержать символы [a-zA-Z_][a-zA-Z0-9_]+.

<TMPL_foreach pages as page>
    <TMPL_foreach page.users as user>
        <TMPL_foreach user.friends as friend>
            Page:   <TMPL_var page.id> <TMPL_var page.url>
            User:   <TMPL_var user.id> <TMPL_var user.name>
            Friend: <TMPL_var friend.id> <TMPL_var name> <TMPL_var friend.name>
        </TMPL_foreach>
    </TMPL_foreach>
</TMPL_foreach>


Для чего все это надо?
Для того, чтобы во вложенных циклах можно было обращаться к переменным внешнего цикла.
Разумеется, сохранен и старый метод работы с циклами посредством операторов <TMPL_loop foo> и </TMPL_loop>

Если имя итератора не указано, переменная ищется сначала внутри последнего итератора, а затем - в глобальной области данных; по тому же образу и подобию, что и в TMPL_loop. То есть, в приведенном примере <TMPL_var name> <TMPL_var friend.name> выдадут один и тот же результат.

Допустимо произвольное количество уровней вложенности циклов друг в друга; также можно комбинировать TMPL_loop и TMPL_foreach.

ВНИМАНИЕ! Байткод шаблонов, сгенерированных версиями 2.4.X будет исполняться и в 2.5.X, но обратное неверно: в 2.5.0 введена новая инструкция виртуальной машины (REPLACE), которой ранее не было. Если что - вас предупреждали ;).

В следующих патчах предполагается реализовать оператор <TMPL_break условие> что позволит прерывать текущий цикл по заданному условию.

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

Количество строк кода проекта превысило 29000. Видимо, к версии 2.6 придется дробить проект на собственно виртуальную машину, компиляторы диалектов шаблонов и библиотеку стандартных функций.

TODO: сделать фильтр HTML тегов (привет, СУП!) и сделать по такому же образу и подобию фильтр BB-code. В отдаленной перспективе - реализовать систему мультиязычной трансляции с мультиформами (СУП, привет во второй раз!).

Начиная с сегодня основная ветка разработки - 2.5
http://svn.havoc.ru/svn/ctpp2/branches/ctpp2-2.5/

Изменения в ветке 2.4 в дальнейшем будут производиться в режиме исправления ошибок (что маловероятно) и обратного портирования функций стадартной библиотеки.
me

UTF8 uppercase/lowercase преобразование

Довольно часто бывают такие ситуации когда строку или символ в utf-8 над привести к верхнему или нижнему регистру.
Линковать свой проект для этого с ICU или Glib либо неудобно, либо нет смысла.

Проблему в какой-то мере решает Chacu (CHArset Conversion Utility) - маленькая и легкая библиотека С, реализующая uppercase/lowercase для строк и символов utf-8.

Collapse )