Angular Light — это самостоятельный клиентский MV(C/VM) фреймворк, который построен на идеях Angular.js и Knockout.js, и похож на упрощенный Angular.js



Вышла версия Angular Light 0.8 которая включает разные улучшения и исправления, основные изменения:

1. Поддержка Object.observe и Array.observe, что может увеличить производительность веб-приложений.
Использование Object.observe — это опциональная фича, так же её можно включать для отдельных Scope (scope деревьев). Браузеры которые не поддерживают Object.observe продолжают работать через dirty-checking, так же нужно знать некоторые нюансы.

Примечание переводчика: я заменил оригинальные обозначения сторон монеты head/tail на аверс/реверс, чтобы не вносить путаницу русскоязычными орёл/решка. На иллюстрации выше слева аверс (head), справа реверс (tail).

Спасение невозможно?

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

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

Итак, возможно вы прошли docker tutorial, докер кажется простым и полезным, но вы пока не знаете, как он может вам помочь с вашими проектами.

Обычно с деплоем возникает три проблемы:

1. Как мне доставить код на сервера?
2. Как мне запустить код на серверах?
3. Как мне обеспечить одинаковость окружения, в котором запускается и работает мой код?

Как с этим поможет Docker под катом.

Предлагаю читателям «Хабрахабра» перевод статьи «Spotting bad actors: what your logs can tell you about protecting your business» из официального блога Elasticsearch. Статья рассказывает о том, как можно использовать возможности Elasticsearch для анализа логов веб-сервера с целью обнаружения подозрительной активности на сайте.

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

Но на сколько бы изменилась ситуация, если бы мы могли заблаговременно получать развернутую информацию обо всех IP-адресах и подсетях, которые проявляют подозрительную активность и блокировать именно их? Звучит здорово, не правда ли?

Мы можем легко сделать это вместе с Elasticsearch.

Буквально недавно Крис написал про «Эффект капельного преобразования в CSS». Эффект реально крутой и сама техника реализована по-умному, но данный подход через обычные CSS фильтры имеет определенные недостатки: нельзя использовать непрозрачность, добавлять контент внутрь капель, проблемы с фоновыми цветами.

В последние дни я достаточно много экспериментировал с SVG фильтрами и заметил, что с их помощью можно решить вышеописанные проблемы в CSS реализации. Посмотрите на липкое меню, которое я сделал для демонстрации:

CodePen

Прочитав заголовок, вы, наверное, немного удивились необычности задачи, которую я перед собой поставила. Однако, как ни странно, пейджеры до сих пор иногда могут пригодиться в жизни, даже несмотря на появившееся в последние 15 лет обилие других средств коммуникации. Один из частных случаев их применения — (около)медицинское учреждение, расположенное в железо-бетонном здании, глушащем WiFi и сигнал мобильного телефона. Обслуживающий персонал, тем не менее, должен каким-то образом получать сообщения о том, куда им надо срочно переместиться в случае чего. Для решения этой проблемы руководство учреждения в нашем случае поставило себе дорогую станцию и раздало всем сотрудникам пейджерА пейджеры, которые должны были среди прочих принимать наши сигналы. Соответственно, нашей (меня и моих коллег) задачей являлась их отправка.

Уже прошли те времена, когда для отправки текста на пейджер надо было сначала пообщаться с сонной девушкой с телефонного узла. Теперь достаточно дозвониться до станции и набрать номер абонента и сообщение в тоновом режиме. Арсенал при этом сильно ограничен: можно отправлять только цифры, символы * и #, иногда буквы ABCD. Но для передачи, скажем, номера комнаты или кода ошибки должно хватить. Это довольно сильно упрощает задачу и роднит её с другими — с дозвоном в общую переговорную комнату, например.

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

На Хабрахабре есть уже немало хороших статей по хаскелю, но по большей части это всяческие введения в ФП, разъяснения каких-то теоретических штук (вроде монад, лямбда-исчисления или семейств типов) и совсем немного практических примеров. Ни в коем случае не умаляя их полезности, попробую всё-таки сместить дисбаланс, внести свою лепту в неблагодарное дело популяризации функциональщины и ещё раз показать, что язык пригоден не только для написания факториалов и неэффективных быстрых сортировок в две строчки, но и для вполне практичных вещей вроде быстрого прототипирования.

Статья постарается быть относительно real-world, но при этом не утомлять читателя объёмом или экзотическими предметными областями. «Графика и игры в обучении — это всегда sexy», как завещал великий В. С. Луговский, поэтому я набросаю простую игру, всенародно любимый «Сапёр». Разработка будет вестись «сверху вниз» — это удручающе малораспространённая, но заслуживающая пристального внимания (как и сам хаскель) методология, которая когда-то давно встретилась в отличной статье о шашках в «Практике функционального программирования», и с тех пор запала в душу.

Здравствуйте. В этой статье я расскажу про свой хобби-проект не-фон неймановского компьютера. Архитектура соответствует функциональной парадигме: программа есть дерево применений элементарных функций друг к другу. Железо — однородная статическая сеть примитивных узлов, на которую динамическое дерево программы спроецировано, и по которой программа «ползает» вычисляясь.


Примерно так работает дерево, только здесь для наглядности вычисляются арифметическое выражение, а не комбинаторное; шаг на рисунке — один такт машины.

Сейчас готов ранний прототип, существующий как в виде потактового программного симулятора, так и в виде реализации на ПЛИС.

Часть 1. Вобще-то уже все поделили до нас!
Часть 2. Истина где-то рядом

В прошлой части мы расширяли алгебру и смогли делить на ноль арифметически. В качестве бонуса, способ оказался не единственным. Однако, все эти алгебры не дали ответа на вопрос: “Что там внутри или почему нам это не показывают?”

Пока древние вязали узелки, такой вопрос возникнуть не мог. Сейчас, куда не глянь, “бла-бла, для а≠0”. Значит ответ затаился где-то между узелками и настоящим. В математике все строго и последовательно, а значит и ответ не мог потеряться.

Напоминаю, есть мужик Дэвид Сирлин, который известен чемпионством по Street Fighter и в GameDev. Он написал книгу про то, как побеждать и готовиться к турнирам. Первая вступительная часть тут. Ниже — выжимка части II и мои комментарии.

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

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

Давным-давно мы с друзьями играли в Starcraft по диалапному модему. Я часто проигрывал, пока не прочитал на одной из BBS фразу, которая всё поменяла. Принцип очень простой: в стратегиях реального времени выигрывает тот, кто постоянно атакует. Нужно было научиться мыслить категориями постоянного создания угроз.

К чему я это. Есть такой мужик — Дэвид Сирлин. Киберспортсмен, чемпион по Street Fighter, гейм-дизайнер, настольщик, киберспортивный тренер. У него есть целая теория на тему того, как тренироваться и играть так, чтобы выигрывать. Универсальная, применима ко всем играм. Ниже — основные тезисы первой части и мои комментарии. Прочитать про основные вещи из книги будет интересно и с точки зрения GameDev (в особенности — балансировки), и просто по жизни.

В посте речь пойдет о написании утилиты для нагрузочного тестирования HTTP сервисов на Node.js, а также описание самого инструмента и области его использования.

Я еще чуток добавил прыти —  
Все не так уж сумрачно вблизи:
В мире шахмат пешка может выйти —  
Если тренируется — в ферзи!

          Владимир Высоцкий "Честь шахматной короны" 

Правила, особенно такие сложные, как рокировка или "взятие на проходе", не появляются на пустом месте. Никто не придумывает их просто так, чтобы позлить разработчика (во всяком случае, я надеюсь на это). В таких «устоявшихся» играх как Шахматы или Шашки, каждое из правил выстрадано десятилетиями. Тысячами игр, в десятках стран, по всему миру. Это бесценный материал для анализа. Неудачные решения отмирают, успешные — расцветают в сотнях различных вариантов (среди которых также есть как удачные, так и не очень). Сегодня, мы поговорим о двух особенно удачных находках... 

Читая М. Липовача «Изучай Haskell во имя добра!», я поначалу не понимал, чем частичное применение отличается от каррирования. Потратил некоторое время на разбор данного вопроса и набросал себе «шпаргалку» по обозначенной теме.

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

Введение
1. Базовые элементы
2. Группировка
3. Движение
4. Частицы
5. Анимация — 1
6. Анимация — 2
7. Простой ландшафт
8. Статические коллизии
9. Динамические коллизии
10. Импорт моделей
11. Встраивание физических движков
12. Тени, туман
Продолжение — многопользовательский шутер

В статье речь пойдет о технологии WebSocket. Точнее не о самой технологии, а о том, как ее можно использовать. Я давно слежу за ней. Еще когда в 2011 году один мой коллега прислал мне ссылку на стандарт, пробежав глазами, я как-то расстроился. Выглядело настолько круто, и я думал, что в момент, когда это появится в популярных браузерах, я уже буду планировать, на что потратить свою пенсию. Но все оказалось не так, и как гласит caniuse.com WebSocket не поддерживается только в Opera Mini (надо бы провести голосование, как давно кто-либо видел Opera Mini).

Кто трогал WebSocketы руками, тот наверняка знает, что работать с API тяжело. В Javascript API достаточно низкоуровневый (принять сообщение — отправить сообщение), и придется разрабатывать алгоритм, как этими сообщениями обмениваться. Поэтому и была предпринята попытка упростить работу с вебсокетами.

Так и появился WSRPC. Для нетерпеливых вот простое демо.

Передохнём от верстки всяких пользовательских интерфейсов и просто порисуем на CSS. Рисовать будем такую вот сцену:



Смотреть на jsfiddle.

В статье я попробую описать пошаговое создание этой сцены.

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

Предыдущая публикация: Правильные многогранники. Часть 1. Трёхмерие

Вступление

Вижу, что на Хабре люди серьёзные собрались. Статью про трёхмерие на счёт «раз» разобрали. Однако пространствами постоянной кривизны никого не удивишь в наше время. Тем не менее всегда находятся желающие заглянуть выше, в четырёхмерие. Ну что ж, именно с такими любознательными коллегами мы продолжаем разговор и переходим на следующий уровень по размерности.

Моя задача не просто рассказать про разбиения пространств постоянной кривизны любой размерности на правильные многогранники, а сделать это так, чтобы материал поняли даже вчерашние школьники, окончившие 11 классов. Я люблю статьи на Хабре именно за их доходчивость, понятность, простоту, не смотря на сложность материала, и в таком же качестве стараюсь подавать сведения в публикациях. В ВУЗах и в отечественных публикациях предлагаемый материал возможно рассматривается, но, как мне кажется, не в таком виде. Думаю, что информация будет полезна и для студентов. В иностранной литературе данный материал есть, соответственно не на русском языке, в сильно сжатом виде и с использованием высшей математики. Тут я всё «разжёвываю» для школьников, без высшей математики, фактически на одной геометрической интуиции. Мы увидим в следующей статье, как будет сделан переход от 4D к 5D с помощью геометрии, наглядно, без высшей алгебры. Это будет самый сложный шаг, но кто его поймёт, тот поймёт и все остальные размерности от 6 и выше. Не уверен, что мне удалось всё основательно «разжевать», поэтому, если будут дополнительные вопросы — задавайте, это поможет мне улучшить статью.

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

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