ermouth: (ang)
Прекрасное просто https://www.quantamagazine.org/20150519-will-computers-redefine-the-roots-of-math/

Про множества, теорию типов, гомотопии, эквивалентность и изоморфизм – и мой любимый HoTT, на идеях которого и построен jQuery.my.

Материал написан очень простым и доступным английским языком. Очень рекомендую.

После прочтения материала станет понятно, почему я хотел объяснять $.my через гомотопию – потому что манифест $.my устанавливает гомотопию между интерфейсом (то, что я назвал абстрактным связным пространством вот тут) и данными под ним. Таким образом, манифест $.my определяет тип, который суть эквивалентность между пространством данных и пространством интерфейса.
ermouth: (ang)
Для начала видео. Так выглядит процесс «узнавания» восьмёрки нейронной сетью, воспроизведённый в некотором смысле в обратном порядке:



Что именно тут значит этот «обратный порядок», я пока не разбирался, но в планчик toread записал. Видео взято из материала на Медиуме Algorithms of the Mind – рекомендуется к прочтению.

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

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

И да, в конце материала по сcылке кста прекрасный список для дальнейшего чтения.
ermouth: (ang)

Благодаря https://nplus1.ru/news/2015/05/25/nash мне попался на глаза оригинал доказательства существования точки равновесия в играх с ненулевой суммой.

Оно выглядит так (клик – PDF с работой):

Снимок экрана 2015-05-27 в 23.00.46

Соотнесение некоторых терминов типа “product space” с, например, теорией множеств можно посмотреть в моём старом посте про HoTT, там табличка есть. Это, возможно, несколько облегчит понимание.

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

Теорему Какутани о неподвижной точке можно посмотреть в Вики, она достаточно понятна. Упрощённый механистический смысл этой теоремы – если какая-то сущность выпукла, у неё есть точка равновесия, лежащий внутри этой сущности.

Нэш – в одно соображение – распространил эту теорему на набор стратегий и функций, мапящих стратегии на “размер” выигрыша в результате их применения.

В силу того, что стратегии нескольких игроков соотносятся друг с другом как “каждый с каждым”, они образуют выпуклую сущность (выпуклое множество). Значит, у этой сущности есть точка равновесия, лежащая внутри сущности.

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

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

RIP, Джон Нэш.

ermouth: (Default)

Подобрал по памяти книжки из детства, с которых у меня началось увлечение ИТ. Это период примерно с 5 по 7 класс, 1988-1991 (исключение – последняя, она 1993).

Mkiz86O1. Omkp90O1. 1315082614_knigonosha.net_31b735242b0c
0740d030d6eed655bcbb89c8e58203b10e9d073a 220df copy 1513954 Aomg89O1.
MRB1110O1. Zxsp91O1. 0232059 M486193O1.

Тут не все, только те, которые я отчётливо помню. Некоторые – большими кусками наизусть, как выяснилось. Разделены по рядам.

Ряд №1

Это у меня появился программируемый калькулятор, насколько помню, подарили мне его на НГ родители. Плюс я ходил в кружок компьютерный во Дворце пионеров, там был Агат-1, русифицрованный клон Apple ][ с дисководом.

Последнюю брошюрку в ряду, синюю, я использовал как шпаргалку по Бейсику-Агату – там в конце такой маленький справочник – и попутно запомнил всю остальную книжку. Там ряды, линейная алгебра, комплексные числа – всё прямо готовым довольно компактным кодом. Знакомство с линейной алгеброй у меня началось с этой книжки, а не с профильных учебников кста )

Ряд №2

Сборник с олимпиадными задачами у меня был немного другого, более раннего издания. На память, задачки там были преимущественно на комбинаторику, оптимизацию и поиск. Так что книжка мне немножко прикрыла пробел по этим темам, потому что в справочнике по алгоритмам на Бейсике этого не было вообще.

Из второй – коричневой – книжки я узнал про Лисп. Там про него было страниц 5 всего, но они на меня неизгладимое произвели впечатление. Любопытно, что там рядом было про Паскаль (to morfizm: не про С, я подзабыл) – и я совершенно не понял, зачем Паскаль вообще нужен в природе о_О

Книжка Трейстера просто разложила в голове, что такое PC. Больше помню её по обложке, а не по конкретному содержанию.

Роджерс попал ко мне совсем ненадолго, может, на неделю – и не помню, ни откуда взялся, ни куда делся. Помню что впечатление он на меня произвёл ошеломляющее в том смысле, что если хорошо подумать, огромное количество задач реализуются целочисленной арифметикой без деления.

Ещё оттуда я узнал про алгоритм Брезенхэма, трассировку лучей, сплайны и тп штуки.

Ряд №3

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

Первая книжка интересна тем, что там никакая не сопливая теория, а вполне себе систематический разбор 4- и 8-битных советских микроконтроллеров. Это в 1990 примерно году то. С архитектурой, системой команд, а по 1816ВЕ48 (Гарвардская архитектура, замечу) – даже с ассемблером. Совершенно неоценимая книжка для понимания как что работает – микроконтроллеры, особенно 4-битные, очень интересно устроены.

Чёрная книжка – изумительного качества издание. Там в конце был мануаль и справочник по ассемблеру для Z-80, причём так организованный, что было видно, какие биты в байтах команд что задействуют и сколько что тактов занимает. После чтения Роджерса и книжки про микроконтроллеры я отвращение к ассемблеру пересилил и довольно долгое время писал вообще только на нём для Спектрума. Эта чёрная книжка была неоценимым подспорьем.

Роспись по битам организации системы команд дала кста возможность писать самомодифицирующиеся программы (рерайт на ассемблере, да). Снова я начал это делать только спустя 25 лет.

Толковый словарь – толстая книжка страниц на 600. Там, как сейчас выяснилось, примерно 4000 статей с термином и коротким описанием.

Книжка эта по тем временам качества исключительного – вдумчиво читая её статья за статьёй можно было составить прекрасную понятийную картинку. Скажем, понятия “лямбда-исчисление” или “L-system” я узнал именно оттуда, лет в 14, и понял, что это такое – что немаловажно.

i486 – это уже попозже, класс 9-й. Хороший двухтомник (4 книги – но два тома, 2-4 книги – во втором томе, вот так). Стоил довольно дорого для школьника, так что я его купил только из изумления и любопытства. Полистал в книжном – и просто пришёл в восторг от инженерной сложности. Купил только поэтому, и потом зачитал её до дыр буквально.

Она у меня кста была типичной “туалетной” (хе-хе, кто понимает) литературой, пардон. То-есть любимая крышесносящая книжка, которую можно читать с любого места когда угодно. Справочно – во взрослой жизни у меня на этой роли был сначала Улисс, а потом Сайгё ) Так что смею утверждать, что техническая литература тоже может быть предельно умиротворяющей ггг

----

В общем, в ножки кланяюсь авторам этих книг. Все реально сыграли в моей жизни огромную роль – и ни с одним я не знаком.

ermouth: (Default)

Новое модное веяние, во многом – просто красивое название для концепции distributed render, которая у меня оформилась в середине 2012. Дополнительно к distributed render это ещё и быстрая синхронизация локальных данных клиента и сервера, максимальная согласованность того, что в UI и того, что в главной БД.

Ну и главная фишка – более-менее единый код для клиента и для сервера.

Я с этими штуками за 3 последних года вдоволь наэкспериментировался вдоль и поперёк – просто не называл это isomorphic javascript. В этой связи у меня оформилось несколько стойких соображений.

Изоморфность, когерентность и диффы

Изоморфные веб-приложения – это, конечно, такая серебряная пуля. В идеале – отображение удалённой БД на UI, работающее в обе стороны в реальном времени.

Самая главная беда у нас по пути – канал связи. Мы заранее не знаем какой он у нас будет – и это главное соображение, почему серебряной пули не случится. Когда приложение исполняется локально, скорость отображения изменений UI на подлежащий документ известна и она очень высока.

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

Простой пример. У нас есть чатик, который дописывает узлы в какой-то док по мере появления реплик. Пусть он их передаёт diff-ами, например.

Мы начинаем передавать в чатик 10 картинок по 10 мегабайт каждая. Добавляем их в UI – и хотим написать реплику со ссылкой на одну из картинок.

Если мы требуем ссылочной когерентности – реплика не сможет быть отправлена в БД до того, как туда попадут картинки. Это, конечно, так себе чатик будет.

То-есть требование ссылочной когерентности отвалилось на простейшем юз-кейсе. Ну или нам надо сделать такую БД в которой два произвольных апдейта всегда коммутируют – что-то не видать таких, ога.

Итого: изоморфность – наверное, когерентность – видимо нет.

Декомпозиция задачи

В самом деле, ссылочная когерентность UI и remote-отображения в подавляющем большинстве случае не необходима. Если не выдвигать её как требование, задача распадается на четыре части.

Мы, в идеале, хотим иметь такую среду исполнения, приложения которой:

  1. можно использовать на клиенте как UI для модификации подлежащего документа,
  2. можно использовать на сервере как валидатор,
  3. можно использовать на сервере как параметризуемый шаблон, генерящий HTML,
  4. не должны заботиться, где вообще находится документ и его реплики.

Ну и мы подразумеваем, что у нас приложение – это одинаковая сущность и для клиента, и для сервера.

Условие №1, клиентский UI – чисто здравый смысл. Приложения – они для людей.

Условие №2, валидатор из приложения – самое главное. Валидация приложением – это когда мы можем взять документ, взять код приложения и не выполняя его в части UI определить, мог ли документ быть получен нормальной работой этого аппа в соответствующем окружении.

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

С точки зрения математики каждый валидный документ приложения образует неподвижную точку для функции, которая “вычисляет” приложение над документом.

С точки зрения пользователя это эквивалент операций Открыть >> Сохранить, после которого документ не должен измениться, и по пути не должно возникнуть никаких ошибок. Вот только всё это надо иметь возможность делать без UI.

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

Условие №3. Приложение как параметризуемый шаблон. Это считается главной серебряной пулей, чуть не самой желанной фичей. Дескать чтобы вот передать на сервер URL – а он тебе HTML-снапшот приложения в нужном состоянии.

Или не передавать – а попросить с сервера данные и отрендерить приложение на клиенте, но чтобы то же самое получилось.

Это серебряной пулей считается напрасно, хотя усилия по реализации предприняты в целом колоссальные. Это примерно так же переоценено, как responsive layouts. Да, иногда нужно, и даже удобно – но если всё так делать, то это очень ограничивает.

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

То-есть не надо смешивать две задачи:

  1. Максимально эффективно скормить гуглу вашу базы.
  2. Иметь на сервере функцию, которая может вам прислать HTML-снапшот вашего приложения в любом его состоянии.

Первая задача стОит, чтобы её решать, вторая – ну её нафиг.

Условие №4. Среда исполнения должна сама выбирать стратегию распространения изменений по уровням кэша (локальная БД >> удалённая БД или несколько удалённых БД, пиринговая доставка другим юзерам, дайджесты на емэйлы и тп).

Ну или как минимум давать максимально удобно конфигурировать параметры стратегии.

Для приложения все эти детали должны быть скрыты, у него одна операция – сэйв, и один ивент – внешний апдейт документа.

Я такую конструкцию в части API к БД смог довольно быстро собрать – но в целом оно довольно неудобно. С одной напрягает бардак с promise. С другой – с памятью.

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

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

Это, вообще говоря, требования противоречивые (ситуация кста касается и пункта №2 про валидатор).

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

Потому что эти 5 мегов придётся загружать в каждую серверную сессию при валидации данных этого приложения, пришедших удалённо. Можно какие угодно предпринимать усилия по дедупликации, и всё равно найдётся такая задача, где стратегия дедупликации поломается и сервер начнёт жрать память и размножать данные по сессиям.

Итого

Изоморфные в полный рост приложения – это довольно нишевый продукт, потому что сейчас делать и владеть ими дорого, поддерживать сложно и все имеющиеся решения очень громоздки.

Что-то простое из них можно собрать просто и коротко, а вот сложное – получается непременно хромота с какой-нибудь стороны.

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

Вообще, думаю, тут не обойдётся без появления нового языка (или следующей итерации JS) – и он будет ближе к Erlang по компоновке кода и соглашениям, чем к JS.

ermouth: (Default)

Интерпретатор Лиспа на яваскрипте, объемом в 1Кб. Он не совсем Лисп на входе кушает – там некоторое очень близкое подобие Лиспа (AST в нативном JS формате), но всё равно нереально круто.

https://github.com/kanaka/miniMAL/blob/gh-pages/stepB_web.js – исходник. После упаковки чем-то типа jscrush оно превращается вот в такое:

Снимок экрана 2015-03-02 в 0.16.35

У меня получилось через jscompress+jscrush ужать полный исходник (с макросами и обработкой ошибок) до 1.5Кб с первой же попытки, так что думаю эту реализацию можно сделать ещё короче.

Яваскрипт великий язык, да.

ermouth: (ang)
Только что обнаружил совершенно феноменальный для себя факт: оказывается, лимонная кислота и аскорбиновая – это совсем неродственные соединения.

Я знаю об их существовании лет с 7 (мама – химик-органик), но я решительно не помню, с чего мне померещилось, и очень стойко, что это почти одно и то же. Химические формулы у них довольно близки – C6H8O7 и C6H8O6 – а вот структурно, оказывается, они совсем не похожи.

Как все эти 30 лет мне не попадалась структурная формула лимонной кислоты – просто не могу совершенно понять. С учётом того, что я представляю себе свойства цитратов – солей лимонной кислоты – это всё просто детектив какой-то.

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

Если поискать общее между всеми такими «открытиями», получается, что они из тех областей знания, что изучались полностью самостоятельно. Интересно – похоже, иногда при самообразовании языковые паттерны играют с сознанием странные шутки. То-есть, мозг по названию даёт какое-то своё толкование незнакомого явления – и устойчиво фиксирует этот смысл. «Сама придумала, сама поверила», да.


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

И ещё про лимонную кислоту, страшное. Сейчас её не из лимонов делают, а промышленно из чёрной плесени о_О.
ermouth: (ang)

Мне сегодня на Stackoverflow попался изумительной красоты вопрос про javascript. Я, как обычно, невнимательно его прочитал и ответил немного не в кассу, ну, меня быстро поправили.

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

Задача: нужно сконструировать такую функцию add, которая делает вот так

add(1) >> 1
add(1)(2) >> 3
add(2)(3)(4) >> 9

Цепочка вызовов может быть любой длины, в скобках только числа.

Сначала может показаться, что задачка нерешаема. Потом – что нам нужно локально расширить объект Number какой-то конструкцией, которая позволит вызывать Number как функцию. Это можно сделать – но получается очень громоздко. В самом деле надо идти с другой стороны – делать такую функцию, которая при попытке её с чем нибудь сложить кастится в число.

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

Сделать функцию, которая при попытке её с чем-нибудь сложить “прикидывается” числом совсем просто.

Дело в том, что любая функция в js – объект. У неё есть метод toString, который и управляет кастингом. Собственно, он и вызывается неявно, когда вычисляемое выражение требует привдения к примитивному типу. Если toString наследуется от прототипа – он вернёт исходный текст функции. Но мы можем его подменить – и он станет возвращать число.

Хак целиком выглядит вот так:


var add = (function() {
    var factory = function(value) {
        var fn = function(num) { return factory(value + num) };
        fn.toString = function() {return value};
        return fn;
    };
    return factory(0);
})();

Офигенно, по-моему, с эстетической точки зрения. На каждом вызове функции возвращается новая функция, которая скрыто каррирована значением предыдущего шага и которая прикидывается числом, если её закастить в примитивный тип.

Такой очень хитрый итератор.

Использовать в жизни я бы такое, правда, не посоветовал – оно mind-blowing, медленное и хрупкое. Как и всё, что красивое и бесполезное )

ermouth: (ang)
Придумал фразу, которую можно смело давать на экзаменах по русскому, если хочется «завалить».

О боже, 8 бит на чашку чаю – и я в раю.

Кто не читает мой тви – попробуйте определить какие слова тут в каком падеже. Ответ под катом.
ExpandПосмотреть ответ... )
Такие дела )
ermouth: (ang)


Без формул там страшных, простым языком с картинками, которые можно палкой на песке нарисовать. Я просто тут на днях объяснял коллегам, как работает, по скайпу, без картинок – и объяснил буквально на пальцах за 20 минут.

Если по-простому – это алгоритм, который позволяет по серии отсчётов (картинок, например), определить сдвиг, поворот, зум и вообще любое другое изменение, и очень быстро.
ermouth: (ang)
Ура-ура. Полторы недели тестировал всячески и оптимизировал, в тч под IE8, будь он неладен.

Доступно на гитхабе, через bower install jquerymy или на jquerymy.com.

Новые фичи манифеста – require и files. Массив require позволяет при старте формы проверять и догружать если надо какие-то данные или библиотеки/плагины. Объект files – включать в манифесты binary data инлайном, да так, что эти дата при старте формы получают сессионный URL.

Оптимизирован сценарий связанных списков master-detail, обновляющих друг друга.

Ещё чуть-чуть – и код перевалит за 100Кб. Начал 2 года назад с 10Кб.

Общее количество манифестов jquerymy, появившихся за это время – более 200. Основное применение – коммерческие онлайн-приложения бэкэндов.
ermouth: (ang)
Расчехлю журнальчег похвастаться.

Выкатил jQuery.my 0.9.9. Обновил сайт jquerymy.com, теперь есть русская версия и офигительные демки с возможостью редактирования их исходного кода и запуска прямо на странице, в песочнице.


Контент написан в расширяемый редакторе наподобие того, что в Medium.

Вот демка этого редактора http://jquerymy.com/ru/meditor.html, всё интерактивное. То-есть это как OLE-объекты в Ворде примерно работaет. Есчо демка пишет в локалСторидж, так что а) перезагрузка страницы не убьёт правки, если вы редактируете, б) лучше не аттачить картинки больше мегабайта-двух.
ermouth: (Default)

Не могу не перепостить.

Возле дома просветлённого горного даоса приземлилась серебристая летающая тарелка. Шлюз медленно открылся. Яркий белый свет залил лужайку у дома. Из света показалась неестественно тощая и высокая фигура.

Рауати Ксентари, достойный сын расы Ксентари, вошел в дом даоса и прямо с порога спросил:

— Что ты отдашь мне взамен на все тайны строения Вселенной?

Мудрец сидел профилем к своему гостю и созерцал стоящее перед ним жестяное ведро. Не поворачиваясь к пришельцу он спокойно произнёс:

— Вот это ведро с говном.

Инопланетянин крепко задумался.

— Но почему? – наконец спросил он. Мудрец медленно повернулся к гостю и строго посмотрел в его огромные тёмные глаза.

— Потому что в доме горного даоса, – изрёк он с нажимом, – не место ведру с говном!

В тот же вечер Рауати Ксентари стал его учеником.”

Это на простой понятный язык перекладывается так: “Никому не нужны ваши тайные знания. Уберите ведро с говном”.

Изумительно контрастная притча.

Lars Bak

Nov. 11th, 2013 03:23 pm
ermouth: (Default)

Прекрасное из обсуждения производительности js и Java:

But if you really want to compare the two, here's an interesting datapoint for you: HotSpot, which is one of the more popular, and also more performant JVM implementations out there, was created by a team of guys which included, among other people, a guy named Lars Bak. But actually, HotSpot didn't appear out of thin air, it was based on the sourcecode of the Anamorphic Smalltalk VM, which was created by a team of guys which included, among other people, a guy named Lars Bak.

V8, which is one of the more popular, and also more performant JavaScript implementations out there, was created by a team of guys which included, among other people, a guy named Lars Bak. But actually, V8 didn't appear out of thin air, it was based on the sourcecode of the Anamorphic Smalltalk VM, which was created by a team of guys which included, among other people, a guy named Lars Bak.”

Такие дела. Интересно, что визуально код на смолтоке у меня легко в голове распознаётся, но я ни строчки на нём не написал о_О

ermouth: (Default)

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

Плюсами – что мне более-менее понятно как сделать, минусами – обычно есть серьёзное препятствие нетехнологического характера (законы, правила вендоров и тп). Знак вопроса – не совсем ясно, как это технологически. Плюс-минус обычно значит, что решение есть, но фрагментарное либо ненадёжное.

Основные фичи

Контроль доступа:
+ Круги – как группы пользователей, похоже на гугл
+ Круги как структура безопасности децентрализованы, принадлежность сущности к кругу и текущий администратор определяются по технологии, похожей на валидацию биткоина
В круги попадают не только пользователи, но и устройства хранения (компутеры, мобилы и тп)
± Также в круги попадают шлюзы в соцсети и на внешние хранилища
+ Мандатный доступ на основе атрибутов кругов и все из этого следствия

Хранение:
+ Оригинальный контент реплицируется только туда, куда позволяет контроль доступа круга (скриншоты и взлом конечно исключить нельзя)
+ Репликация где можно двусторонняя
± Риалтаймовая репликация типа как в гугл-доках
+ Конфликты сохраняются как форки с возможностью слияния
?Каждое устройство хранения – торрент-узел
?  Каждое устройство хранения – веб-сервер
+ Хранилища предоставляют какой-то REST API как для выборки данных…
± …так и для рендера этих данных в меру своих вычислительных возможностей (генерация интерфейса вокруг данных)

Получение данных:
+ Торрент-подобный способ для статического контента. Каждый кусочек контента должен иметь что-то типа MagnetURI и распространяться технологией типа торрентов с шифрованием. Ну то-есть у нас ведь контент сразу в нескольких местах одинаковый может храниться.
+ Веб-доступ для “динамического” контента, причём список узлов с возможностями обновляется с торрент-клиента – это позволяет избежать централизации контроля доступа

По интерфейсу много соображений, в другой раз.

ermouth: (Default)

Нашёл подборку научных работ Сахарова, отца советской водородной бомбы. Прямая ссылка на pdf http://ufn.ru/ufn91/ufn91_5/Russian/r915b.pdf

По концентрации смысла на один байт это очень ёмкое чтиво. Искал я собсно одну работу – она там со страницы 95, где там вписано “Посвящаю Люсе” )

Название звучит удручающе сразу – “Космологические переходы с изменением сигнатуры метрики”. Если попроще – он там рассматривает занятную теорию такого мира, в котором координат времени больше одной.

Дальше жестокий малопонятный гон есличо.

ExpandRead more... )
ermouth: (Default)

Прочитал по наводке Ктототама вот это http://bit.ly/XK0aY9 (кста если вы посмотрите на урл материала, вы поймёте почему те, кто за ЧПУ в урлах – жывотные).

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

Kot, это скорее всего преувеличение и вот почему.

Я сам в школе писал на ассемблере для спектрума 48К и иногда получались самомодифицирующиеся программы, и даже с чертами "криптографии". Я в бложеке писал както про кубик Рубика и, вроде, про реализацию Жизни Конвея.

Причина, по которым появлялся такой код, предельно тривиальна.

Самомодифицирующийся код мне нужен был для быстрых побитных операций на Z80, которые бы принимали индекс бита в слове как параметр – рерайтинг позволял получить скорость, к которой обычными методами невозможно было даже приблизиться. Никак вообще.

А "криптография" – скорее всего просто сложная упаковка данных в памяти, я это делал в кубике рубика, потому что по-другому преварительно просчитанные роадмапы было просто никак не сохранить. Не помещались )

"Виртуальная машина" – просто диспетчер мультиметода, созданного во время выполнения ну и тд. (UPD В школе я каэш не знал, что это так называется)

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

Сейчас так не пишут.

В общем, не так страшен чёрт, как его малютка )

ermouth: (Default)

Мы раньше полетели в космос и вообще были в состоянии конкурировать в области сложной управляемой техники с 50 по70-е года прошлого столетия во много благодаря одному человеку, сибирскому конструктору радиоламп Авдееву.

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

А летать надо было. Как же полетели?

ExpandRead more... )
ermouth: (Default)

В 1961-1962 году СССР провёл серию высотных ядерных взрывов К-1…К-5. Один из них, К-3, рванули на высоте 300 км примерно над Джезказганом, это Казахстан.

Интересен этот взрыв тем, что была предпринята попытка оценить высотный ядерный взрыв как электромагнитное оружие. Для этого телефонная линия под взрывом длиной в 600 примерно километров по прямой была обвешена приборами и всякими предохранителями. Ещё линию порезали на куски по несколько десятков километров.

Так вот, ядерный взрыв в космосе расплавил все эти 600 км линии токами до 3500 ампер, сжег все предохранители, вызвал несколько пожаров на защитных станциях и попутно вывел из строя Карагандинскую электростанцию.

Дальше гон и паранойя )

ExpandRead more... )
ermouth: (ang)

Волшебный яваскрипт. Просто вставьте это в консоль браузера, ну кто знает где она )


(eval((function(){var Y,$,_="\"ПC@H56!LnУ F59y97E395ц K3ш`@ CуE@ C7з3бC^yKXjscrush @ 8K5`^ 5гXqC@F59@FыF K`yE@C@``@цы @ H867HE@ H E3K б5з 383б3гXбуб97.LnJscrush – 8уq5C3бфу8E763C @ 8уq5C3FqC5883C E3K7 7H63C86H7 Aivo Paas. Н5E363CыF K3q@`@H79@5F 5гX`5гEXз7867H@6ь q7E3H^ @ qC386X86C3E@.LnО9 383б599Xх3C3шXC7б36756 97 E3K5 @ K`@99ых json-F788@H7х q3H63Cяющ@х8yK799ых, жFё6 EC7693, E7E zip – 9X3ч59ь F5K`5993. 10EБ H F@9у6у qC@F5C93. ИF599Xэ636 65E86 8ж76 qC@F5C9X97 20%.LnЖ^ 83H85F E3C36E@5 K799ы5, E3C3ч5 83659 б7й6, 95 @F556 8Fы8`7 – overhead 36 8`3H7C5й @ C78E3K@C3Hщ@E7 8ъ5K756 эфф5E6. ПC@ э63F K799ы5 з7qC386XF3гу6 8K5`^8y95ч@675FыF@, F3ж9X@8q3`ьз3H^ K`yэ63г3.LnР78E3K@Cу568yэ6XH8ё 3ч59ь бы86C3, 83q3867H@FX8XHC5F595F qC386XC7зб3C7 @8х3K93гXE3K7.LnС3б86H5993, H36 E3K:LnLn\"+\"function (s0){4var i,B,m,S,c,M,N,e,Z,t,o,x,j,R,Y,s=s0;4B=sG/2,m='';4T;;m=c+m){4 Tc=0,i=122;!c&&--i;!~WQ[i])&&(c=Q[i]));4#if(!c)break;4# To={},M=N=e=Z=t=0;++t<=B;)4##Ti=0;++i<sG-t;)4## if(!o[x=s.substr(j=i,t)])4###if(~(j=Wx,j+t)))4### TZ=t,o[x]=1;~j;o[x]++)Dj=Wx,j+t);DB=Z;DTi in o){D j=encodeURI(i).replace(/%../g,'i')G;D if(j=(R=o[i])*j-R-j-1) if(j>M||j==M&&R>N)M=j,N=R,e=i;D}Dif(!e)break;Ds=sVe).join(c)+c+e4}4c=sV'L\"')G<sVL\"'L\")G?(B='L\"', /L\"/g):(B=L\"'L\", /'/g);4return '(eval((function(){var Y,$,_='+B+s.replace(c,'LLLL'+B)+B+';TY=0;$='+B+m+B+'[Y++];)with(_V$))_=join(pop());return _})()));';Ln }\"# 3о4Ln#5е6т7а8с9н@иCрD4####EкFмG.lengthHвKдL\\Tfor(V.split(Ws.indexOf(X3 ^76ь`лqпyя ";for(Y=0;$="yq`^XWVTLKHGFEDC@9876543#"[Y++];)with(_.split($))_=join(pop());return _})()));

Profile

ermouth: (Default)
ermouth

November 2021

S M T W T F S
 123456
78910111213
14151617181920
21 222324252627
282930    

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

Expand All Cut TagsCollapse All Cut Tags
Page generated Jul. 30th, 2025 02:45 am
Powered by Dreamwidth Studios