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



Более 300 рецензированных исследований показали, что ВР (виртуальная реальность) является эффективным инструментом при лечении таких психических расстройств, как тревожность, депрессия, травма и зависимость. Поэтому не удивительно, что появляется множество компаний, которые разрабатывают терапевтический контент, задействующий технологию погружения. Это многообещающее поле для деятельности: от помощи в снятии напряжения у пассажиров во время длительных перелетов до виртуальных ИИ-психотерапевтов.

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

TL;DR: базовая логика redux помещается в 7 строк JS кода.

О redux вкратце (вольный перевод заголовка на гитхабе):

Redux — библиотека управления состоянием для приложений, написанных на JavaScript.

Она помогает писать приложения, которые ведут себя стабильно/предсказуемо, работают на разных окружениях (клиент/сервер/нативный код) и легко тестируемы.

Я склонировал репозиторий redux, открыл в редакторе папку с исходниками (игнорируя docs, examples и прочее) и взялся за ножницы клавишу Delete:

• Удалил все комментарии из кода
  Каждый метод библиотеки задокументирован с помощью JSDoc весьма подробно
  
• Убрал валидацию и логирование ошибок
  В каждом методе жёстко контролируются входные параметры с выведением очень приятных глазу подробных комментариев в консоль
  
• Убрал методы bindActionCreators, subscribe, replaceReducer и observable.
  
  … потому что мог. Ну или потому что поленился писать для них примеры. Но без корнер-кейсов они ещё менее интересны, чем то, что ждёт вас впереди.
  

А теперь давайте разберём то, что осталось

Update: По совету хабрачеловека maxshopen, топик перенесен в свежесозданный блог «Финансы для всех». Решение это обосновывается тем, что сейчас (особенно — сейчас) нельзя жить в изоляции от мира, и хотим мы этого или нет — но информационными технологиями и чистым Computer Science мир не ограничивается, и параллельный вроде бы мир финансов влияет на нас, зачастую — непосредственно. Помимо этого, IT и финансы — это вообще совершенно отдельная, довольно интересная тема, и рассказать тут есть про что. Поэтому вот вам пробный камень :-)

(топик ориентирован на тех, кому интересны финансы, но не на профессиональных финансистов — все же обзор больше любительский, и даже знание финансовой терминологии не требуется)

Итак… с чего же начинается финансовый анализ? В самом простом случае — с оценки цен на акции компании сейчас, вчера, неделю, месяц или год назад. Но компании — как и люди — не живут в изолированой среде, они существуют на рынке, общаются с другими компаниями, и все эти факторы влияют друг на друга. Поэтому одним из самых полезных инструментов быстрой оценки состояния дел компании может стать сравнительный график котировок акций. Он отражает как менялась стоимость акций одной компании относительно стоимости акций другой компании со временем. Дополнительным удобством такого графика является то, что на него можно добавить рыночные индексы (о них чуть ниже).

Многие компании представляют свои версии бесплатных финасовых сервисов, и даже рекламируют, что отображают данные в реальном времени. Верить этому, конечно же, не стоит: будь оно так, Reuters и Bloomberg — крупнейшие поставщики финансовой информации — давно бы уже разорились. Однако продукты двух последних компаний — это очень дорогие программные, а в случае Bloomberg — еще и программно-аппаратные комплексы, которые стоят ну прямо-таки диких для простых смертных денег. Для прочих (простых смертных) существуют два продукта от вечно конкурирующих братьев по интернет-оружию — а именно Yahoo! и Google Finance.

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

Многие из нас наверняка думали о сборке двудинового кар ПК, c тачскрином, GPS и 3G интернет соединением для серфинга или подкачки нужных карт. Чтоб теперь у нас есть возможность купить готовый кар ПК. Что самое интересное в качестве операционной системы на нем установлена убунту 10.10. Подробности под катом

По результатам этого вопроса.

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

«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

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

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


Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:

• Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.
  
  
• Клиент — отвечает за взаимодействие с пользователем ^[1].
  
  

Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте четко разделены.

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

1. Бизнес-логика не смешивается с пользовательским интерфейсом.
2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
3. Клиентский компьютер не требователен к ресурсам;
4. И т.д.

Но, относятся ли web-приложения к клиент-серверной архитектуре?

Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

Но! За реализацию интерфейса отвечает не клиент, а тоже сервер. На сервере происходит обработка клиентской формы. Сервер генерирует HTML-код пользовательского интерфейса.

Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…