Фукусима Ивановна
elisitsky
Originally posted by kamnevn at Фукусима Ивановна
На одной из фотографий железнодорожные пути в Японии после землетрясения, а на другой - трамвайные в Санкт-Петербурге после ремонта. Если бы Валентина Ивановна еще и излучала радиацию, то никакой разницы между нашими местожительствами не было бы вообще. А заголовок можно объявлять новым локальным мемом.

Апдейт: как обидели сына Валентины Ивановны.







О том, как студия Лебедева логотип сперла
elisitsky
Originally posted by ee4 at О том, как студия Лебедева логотип сперла
Есть в Подмосковье такой завод - Карболит. Построили его на заре советсткой власти, и долгое время он был единственным и крупнейшим в Союзе предприятием, выпускавшим изделия из пластмасс. Как и положено, есть у "Карболита" и свой фирменный знак, разошедшийся на многих миллионах изделий по всей стране (достаточно сказать, что все подфарники, стоп-сигналы, отражатели и прочую автомобильную тряхомудию в Совдепии делали исключительно на "Карболите"). То есть знак - архиизвестный.
А вот и ни хрена! - сказали в студии Лебедева и, получив гонорар, присвоили 100-летний знак "Карболита" Калужской области. Учитесь, молокососы, как бабло рубить!



Очень хотелось бы распространить по Интернетам! Жамкаем кнопочку ))


UPD: Спасибо [info]dogele  за то, что вытащила из базы ФИПСа лого "Карболита" в том виде, в каком оно было зарегистрировано:



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


Новая редакция протокола Web Sockets
elisitsky
На днях разработчики протокола Web Sockets преподнесли нам небольшой сюрприз под названием редакция 76. Изменения настолько глобальны, что поломана обратная совместимость с редакцией 75. Таким образом, новые клиенты не могут работать со старыми серверами и наоборот. Насколько быстро сломается то, что уже сделано в Web Socket-ном вебе? В принципе уже начало ломаться. Гугловцы обещали, что WebKit, начиная с ревизии r59903, и Chrome, начиная с версии 6.0.414.0 (ревизия r47952), будет использоваться 76 редакция протокола. А это значит, что нам сейчас надо срочно обновлять наши сервера.

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

Основные изменения связаны с безопасностью подключения. Цель: предотвратить или хотя бы максимально осложнить подделку запросов, отправленных с неверных источников. Например, чтобы нельзя было послать из браузера AJAX-запрос максимально похожий на установление веб-сокетного соединения и тем самым атаковать веб-сокет сервер.

Для этого в протокол был добавлен целый ряд заголовков, начинающихся на sec-.
Сравним старый и новый запрос на установление подключения по Web Socket:

Старый запрос:

GET /demo HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
WebSocket-Protocol: sample


Новый:

GET /demo HTTP/1.1
Host: example.com
Connection: Upgrade
Sec-WebSocket-Key2: 1_ tx7X d < nw 334J702) 7]o}` 0
Sec-WebSocket-Protocol: sample
Upgrade: WebSocket
Sec-WebSocket-Key1: 18x 6]8vM;54 *(5: { U1]8 z [ 8
Origin: http://example.com

^n:ds[4U


Заголовок Sec-WebSocket-Protocol указывает какой субпротокол вы планируете использовать. Название - ваше собственное, можно использовать, например, chat или sample или еще какое-нибудь. Данный заголовок позволяет проверить, что и сервер, и клиент поддерживают ваш протокол. Если это не так, то соединение будет сброшено. Это немного упрощает проверку поддержки конкретного протокола или его версии, экономит вам несколько строк кода.
За собственно безопасность отвечают два заголовка-близнеца Sec-WebSocket-Key1 и Sec-WebSocket-Key2. Обрабатываются они одинаково: из полученного мусора символов извлекаются цифры. Мы должны получить такой результат:
Key1: 1868545188
Key2: 1733470270

Одновременно подсчитывается количество пробелов в каждом ключе. В данном случае 12 и 10. Каждое число делится на соответственное количество пробелов. В данном случае мы получим два 32-битных числа:
Key1: 155712099
Key2: 173347027

Но и это еще не все. Дальше идет нечто совершенно безумное, похожее на тело GET-запроса. Страшно писать такие слова...
Два полученных числа представляются как big endian 32-битные целые и затем "слепляются" с образование 8 байт. Затем туда же пристыковываются 8 байт из "тела запроса". Вот эти 16 байт и образуют "секретную" подпись. Теперь задача сервера правильно ответить на такой запрос.

Опять сравним старый ответ:

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://example.com
WebSocket-Location: ws://example.com/demo
WebSocket-Protocol: sample


и новый:

HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Origin: http://example.com
Sec-WebSocket-Location: ws://example.com/
Sec-WebSocket-Protocol: chat

fQJ,fN/4F4!~K~MH


Как мы видим после заголовков ответ сервера содержит еще какие-то данные - это та самая "секретная" подпись, от которой взят md5. Полученные 128 бит записываются как есть, без конвертаций в hex-, dec- или еще куда-то.

Оригинал: Новый протокол Web Sockets

Иногда так не хочется работать...
elisitsky
При особо тяжелых приступах лени - просмотреть 3 раза, строго до еды.



Неудобные суперпредолжения
elisitsky
Сейчас знакомые подбросили супер предложение: Путевка на двоих в Тайланд на 13 дней за 25 000 рублей. Отель правда 3-ка с завтраками. Но все равно - прикинье цену - один билет туда стоит 800$. А тут по цене билетов почти две недели. Да, чуть не забыл - вылет завтра.

Жаль, что что сейчас не получается. Так что френды - если кому интересно, пишите - перекину вам предложение.

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

Чат на Erlang и Web Sockets
elisitsky
Данный чат в первую очередь задумывался как демонстрационный пример для моего доклада про веб сокеты на РИТ-2010. То есть в первую очередь он создавался чтобы протестировать веб сокеты, проверить как будет работать event-driven система, состоящая из брауера, сервера и среды передачи данных. То, что это все хорошо работает по отдельности - уже давно известно и не интересно.
Выбор Эрланга для написания сервера обусловлен двумя вещами:
- во-первых, он мне очень интересен и хотелось написать несложную программу в самообразовательных целях :)
- во-вторых, сама модель работы процессов и асинхронных коммуникаций в Эрланге как нельзя лучше подходит для реализации событийно-ориентированных вещей.
Поскольку пример демонстрационный, то дизайн сделан довольно спартанский - ровно такой, чтобы не мешал. Аналогично не делалось никакой оптимизации, защиты от хаксоров и всего прочего, что необходимо в бою.

Посмотреть можно вот тут: http://chat.websockets.ru

Как это все работает? При заходе на страницу открывается веб сокетное подключение к серверу (Если на Земле еще остались люди, которым я не прожужжал уши про эту технологию, то на том же сайте есть введение в веб сокеты ;-).

Приняв подключение, сервер добавляет процесс, отвечающий за коммуникацию с клиентом, в свой список клиентов, а потом присылает его пользователю. Для этого он посылает (в эрланговском смысле: Pid ! Msg) сообщение процессу клиента с подготовленным списком.

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

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

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

Если пользователь не авторизован, то система не принимает от него сообщения. Состояние авторизации хранится в record`е - пока это еще рано называть FSM`ом. Изначально мы находимся в состоянии, в котором отказываем пользователю в отправке сообщения - возвращаем ошибку. Это можно легко проверить если с помощью FireBug или DevTools сделать видимым слой #messagediv и отправить сообщение.

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


Код выложен на гитхабу: http://github.com/lisitsky/wisechat/blob/master/src/wisechat.erl
Я буду очень благодарен нашим гуру, если они устроят жесткую немецкую небольшую "порку".

Приключения Unicode в Erlang.
elisitsky
Первое, на что я натолкнулся, начав изучать Эрланг - это проблемы со строками, отягощенные всей юникодностью нашего алфавита. Пожалуй, будь моим родным языком английский (или латынь или любой другой с алфавитом, полностью помещающимся в первые 128 символов utf-8), часть проблем бы я просто не заметил, и даже считал, что так оно и должно быть и я все делаю правильно. К счастью, мне сразу пришлось разбираться со всеми особенностями.

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

Строкой здесь считается список int`ов, которую можно напечатать на экране. Поэтому когда вы пишете
> Str = "ABCDEF".
то на самом деле вы создаете никакую не строку, а а список чисел [65,66,67,68,69,70]. В этом легко убедиться:
> [65,66,67,68,69,70] =:= Str.
true

Но и это тоже еще не фатально, во многих языках строка часто мимикрирует под массив, что позволяет удобно работать с ней как с массивом. И здесь вы так же получаете похожие возможности, например, так можно взять 3-ий символ строки:
> Char = lists:nth(3, Str).
67
Я думаю вас уже не удивило появление здесь именно 67, а не "С"? Потому что раз нет строк, то и символы тоже не нужны. Символ - это просто его код в таблице.
Если хотите увидеть как он выглядит на экране, напечатайте его как символ:
> io:format("~c~n", [Char]).
C
ok

Вторая важная мысль. Как еще можно представить строку текста? Конечно, как последовательность байт. Что, кстати говоря, выглядит даже логичнее. В любом случае, когда вы эту строку будете куда-то отправлять или записывать в файл, запишется именно последовательность байт.
Для бинарных данных есть специальный объект - binary.
Здесь все просто - последовательность байт она и в Африке последовательность байт:
> SB = <<"ABCDEF">>.
<<"ABCDEF">>

Можно убедиться, что это последовательность тех же самых байт, что и в списке:
> <<"ABCDEF">> =:= <<65,66,67,68,69,70>>.
true


С латиницей разобрались, казалось бы что нового может дать unicode?
Но вот тут-то и начинается веселье. Беда в том, что в список символов записывается не его представление в utf-8, а его номер в таблице unicode - тот самый code point.
Именно поэтому строка "АБВГД" так сильно отличается от своего латинского аналога:
> "АБВГД".
[1040,1041,1042,1043,1044]

А вот двоичное представление этой строки в utf-8 совсем другое:
> RB = unicode:characters_to_binary("АБВГД").
<<208,144,208,145,208,146,208,147,208,148>>

И если мы этот бинарь побайтово напечатаем, то получим не тоже самое, что в случае первого списка:
> io:fwrite("~w~n", [erlang:binary_to_list(RB)]).
[208,144,208,145,208,146,208,147,208,148]
ok


Что с этим делать?
Выбрать правильный формат и применять по месту. При необходимости одно можно конвертировать в другое. Для этого вам поможет ряд полезных функций:

1) RB = unicode:characters_to_binary("АБВГД"). % из списка юникодных символов делает бинарь в utf-8
<<208,144,208,145,208,146,208,147,208,148>>

2) unicode:characters_to_list( <<208,144,208,145,208,146,208,147,208,148>> ). % из бинаря в utf-8 делает список
[1040,1041,1042,1043,1044]
Вы же еще помните, что так выглядит строка "АБВГД"?

3) unicode:characters_to_list("АБВГД"). % причем вы можете "скормить" и список, только смысла в этом немного
[1040,1041,1042,1043,1044]

Доклад про Веб Сокеты (Web Sockets) на РИТ-2010
elisitsky
Мой доклад про Веб Сокеты на РИТ-2010. Рассмотрено что это такое и почему вам надо обратить внимание на них, если вы хотите делать интерактивное веб-приложение.


Пусть почтальоен читает задом наперед - это же удобно!
elisitsky
 В очередной заметке "Ководства" http://www.artlebedev.ru/kovodstvo/sections/163/ Тема предлагает всем перейти на западную систему указания адреса на конверте.
Честно говоря, я ее никогда не понимал. 
Вот скажите, как должен почтальон читать адрес? Первой строкой он видит фамилию и имя адресата - условного Васю Пупкина. Что ему с того? Ведь врядли это будет его знакомый, значит наверняка, надо посмотреть строчкой дальше - адрес и улицу. Хорошо, там написано 3-я Строителей, дом 25. Уже можно нести конверт? А в какой собственно город надо нести? В Москву или Санкт-Петербург? А может сразу в Уфу - так тоже такой адрес есть. Вот в том-то и проблема, что не будучи уверенным, что все более крупные элементы адреса (страна, область, город и т.д.) правильны, нельзя использовать более мелкие. А это значит, что все равно адрес придется перечесть полностью, но только задом наперед. Очень удобно?

Я понимаю, откуда взялась система писать адрес задом наперед: она идет из тех времен, когда почтальон обслуживал свою деревню или небольшой район города и почти всех своих клиентов знал в лицо. Вот тогда действительно проще, прочитав имя на конверте, понять куда надо нести, адрес здесь лишь уточнение. Ну и само собой, на случай если почтальон сменится.

Размышления про времена в английском языке
elisitsky
Мне попалась замечательная заметка Ильи Бирмана про то, что на самом деле в английском всего 3 времени.
Видно, что человек прочувствовал смысл и логику языка. Даже стало удивительно, почему эту логику не рассказывают в школе. Может так было бы проще понять? 

Дальнейшие рассуждения меня привели к мысли, что времен в человеческом сознании действительно три ("раньше", "сейчас" и "потом"). Но отсутствие в языке таких форм как совершенный вид глагола как раз и требует дополнительных конструкций, которые строятся с помощью глаголов. Эти конструкции уже устоялись и восприимаются умом как нужная форма глагола, а в речи - как особый вид времени.
Сравните "I have written the letter" и "I have the letter written". Если идти от трехвременной модели, то правильной должна быть вторая фраза. Дословно "Я имею письмо написанное". Однако в языке устоялась первая фраза. Почему? Просто она больше понравилась англичанам, так шел исторический процесс. Да мало ли почему, но они выбрали такой вариант.

Давайте его проанализируем. Артикль the выполняет роль указателя не объект и стоит перед словосочетанием. Структура обеих фраз такова: "подлежащее-сказуемое-the-дополнение". Вторая фраза четко ложится в эту модель: "Я-имею-the-письмо-написанное". А вот в с первой проблема: "Я-имею-написанное-the-письмо". У нас получается, что артикль разрывает объект. Это тоже самое, как поставить дорожный знак не перед перекрестком, а прямо посреди него, так что придется тормозить и объезжать.
И чтобы его филологически понять этот феномен нам приходится вводить в размышлениях новый тип глагола. "Я-(имею-написанное)-the-письмо". Вот теперь, если рассматривать написанное в скобках ("иметь-написанное") как некий сложно-составной вид глагола, все встает на свои места. Этот вид так же может иметь прошедшее время: фраза "Я-(имел-написанным)-the-письмо" описывает ту же самую ситуацию, но бывшую когда-то давно. Или будущее: "I will have written the letter before he comes"  &mdash; "Я-буду-(иметь-написанным)-the-письмо-до-того-как-он-придет" &mdash; "Я напишу письмо до того как он придет".
Весь вопрос в том как назвать такую форму глагола. В русском это разывается совершенный вид глагола, в английском - perfect. Кстати говоря, один из переводов слова "perfect" &mdash; "совершенный". Можно было бы назвать так же. Но они решили считать это особым временем глагола. Это их право.

?

Log in

No account? Create an account