За последнее время я несколько раз успел поучаствовать в дискуссиях о том, чем Angular лучше или хуже Knockout и других JS-фреймворков. И очень часто я сталкивался с тем, что есть некоторое непонимание сути различий в подходах, заложенных в эти продукты. Иногда дело доходило даже до того, что в качестве преимущества Knockout приводились валидные по умолчанию префиксы «data-», что ну просто совсем смешно (не говоря уж о том, что их можно использовать и в Angular).

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

1. Модульная организация кода, тестируемость и жестокая война с любыми глобальными данными.
2. Пропаганда декларативного подхода через создание собственных HTML-директив.
3. Механизм проверки изменения данных в дата-биндинге без использования коллбэков.

И третий пункт мне здесь видится наиболее сложным для понимания. Поговорим именно о нем.

О библиотеке knockout.js на хабре написано не так много, но кое что есть (и конечно же есть официальный туториал и другие материалы на оф. сайте и хороший ресурс на англ. языке knockmeout.net, статьи которого смогу перевести, если будет спрос). Данная статья возможно перерастёт в цикл статей по javascript и нокауту, если нло не похитит меня.

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

Начал изучать NodeJS. Нигде не нашел актуальный стек мейнстримных библиотек (технологий) применяемых в node. Поэтому решил сам составить список.

После некоторого, опыта решил написать небольшую статью-шпаргалку о загрузке файлов с использованием возможностей HTML5, а именно File API.

Читайте далее:

1. Поддержка браузерами.
2. Загрузка через Form Data.
3. Загрузка через File Reader.

Краткое содержание:

Возьмем немного функций высшего порядка, добавим частичное применение функций, приправим fold с map-ом и получим Javascript DSL для работы с DOM.

Человеческим языком:
Простое и понятное введение в функциональное программирование на чистом и понятном Javascript.

В отличие от «Через тернии к Haskell» все разжевано (возможно даже слишком) и разложено по полочкам.

Прочтение статьи развоплотит миф о неприменимости ФП в реальной жизни. Вы сможете смотреть на решение одной и той же задачи с разных точек зрения. Прямо как на картинке.

Здравствуйте, я разработчик игр на Flash. Последнее время все больше стало появляться постов про флешокапец, и MustHave JavaScript (дальше JS). Вроде как за JS будущие, и за открытым вебом.
Я долго не рассматривал JS всерьез как платформу для разработки игр. Ведь это интерпретированный язык, и скорость JS оставляет желать лучшего. Но совсем недавно был портирован на JS мой любимый фреймворк для анимации TweenLite. Вместе с этим автор создал тестовый пример показывающий производительность актуальных JS фреймворков: здесь.

Мне стало очень интересно, так как TweenLite JS выдавал неплохие FPS. И тут я решил написать такой же пример для сравнения Flash и JS фреймворков.
Дальше мне стало интересно сравнить FPS этих примеров в разных браузерах, и на разных ОС.
Сам тест — это анимация передвижения, и изменения размеров картинок, при чем можно изменять их количество. Тестовый пример для Flash лежит здесь, исходники примера здесь.

В данном руководстве описана разработка, компиляция и развертывание приложений Node.js в Windows Azure с помощью интегрированной среды разработки (IDE) Cloud9.

О чем пойдет речь в данном руководстве:

• Как создать проект в Cloud9 IDE.
• Как развернуть проект в Windows Azure.
• Как обновить развернутое приложение в Windows Azure.
• Как перемещать проекты между тестовыми и рабочими развертываниями.

Cloud9 IDE –– это кросс-платформенная среда разработки с веб-интерфейсом. Одна из функций Cloud9 для проектов на базе Node.js позволяет выполнять прямое развертывание приложений в Windows Azure. Кроме того, среда Cloud9 интегрирована с репозиториями GitHub и BitBucket, что облегчает обмен проектами с другими разработчиками.

С помощью Cloud9 можно разрабатывать и развертывать приложения в Windows Azure из большинства современных браузеров и операционных систем, причем установка дополнительных инструментов или SDK на локальном компьютере не требуется. Ниже описана работа в браузере Google Chrome на компьютере Mac.

Предисловие

Одним из камней преткновения при разработке на node.js является более сложная, по сравнению с другими современными языками, отладка. Из-за асинхронной структуры кода в большом приложении найти утечку памяти или место интенсивного использования процессора становится затруднительно без специализированных утилит. В разное время для node.js уже создавались инструменты профилирования, но большинство из них либо просто не достаточно удобные, либо перестали поддерживаться разработчиками.

Поиски

Долгое время я обходился консервативными методами отладки в виде периодического вывода объёма используемой памяти и времени выполнения критических участков кода в консоль, но настал момент, когда необходимость наличия качественного инструмента встала очень остро.

Первым делом я решил посмотреть не оправился ли node-inspector, который после перехода на node.js 0.6.x перестал поддерживать профилирование CPU и Heap. Оказалось, что в новой версии node-inspector неработающий профайлинг окончательно исключён и теперь это просто debugger. Немного покопавшись в коде старой версии, мне всё же удалось завести профилирование CPU и Heap на node 0.8.x, однако это решение не было идеальным. Чтобы вывести его из состояния «поделки» необходимо было бы заменить устаревший интерфейс WebKit-консоли на современный, переписав приличное количество кода и исправить некоторые проблемы производительности. В целом, решение на основе консоли WebKit мне кажется очень не гибким, поэтому я бросил эту затею и продолжил поиски.

Вот оно

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

Американская компания Bocoup, как и многие другие веб-разработчики, постоянно использует в работе известный «пуленепробиваемый» шаблон для создания HTML5-сайтов HTML5 Boilerplate. Однако, сотрудники Bocoup решили не только пользоваться, но внести свой вклад в общее дело и выкатили для всеобщего пользования не менее концептуальную вещь — Backbone Boilerplate, набор лучших средств и приёмов для создания приложений Backbone.js.

Прямо из коробки мы получаем:

• Backbone, Underscore и jQuery, всё это на базе HTML5 Boilerplate.
• Инструмент Windows/Mac/Linux для прекомпиляции шаблонов, связывания и минификации всех библиотек, кода приложения и CSS.
• Лёгкий веб-сервер node.js.
• Многочисленные сниппеты кода для Backbone, облегчающие жизнь.

В Backbone Boilerplate логичная и элегантная файловая система (отдельно код, вспомогательные файлы, тесты, билды) и есть возможность создавать собственные классы Models/Collections/Views/Routers внутри модулей.

Разработчики говорят, что проект появился в результате их долгих попыток работать с другими шаблонами: оказалось, что в одних нет процесса сборки, другие налагают излишние ограничения. Новый Backbone Boilerplate призван исправить ситуацию и вполне может стать каноническим, каким стал тот же HTML5 Boilerplate.

Однажды вечером, сразу после того, как я закончил разбираться с наследованием в JS, мне пришла в голову идея, что пора бы заняться чем-нибудь посложнее — например паттернами. На столе внезапно оказалась книжка Gof, а на экране ноутбука появился труд с названием «JavaScript patterns».

В общем, спустя пару вечеров, у меня появились описания и реализации на JavaScriptе самых основных паттернов — Decorator, Observer, Factory, Mediator, Memoization (не совсем паттерн, а скорее техника, но мне кажется что она прекрасно в этот ряд вписывается) и Singleton.

Прочитав статью jtaby.com/2012/04/23/modern-web-development-part-1.html я узнал несколько полезных вещей, напишу-ка я их здесь дабы не забыть.

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

Скорость сайта состоит из 2 частей: как быстро загружается страница и как быстро работает код в ней. Многие сервисы, такие как минификаторы или CDN, помогают ускорить загрузку, но скорость работы кода зависит только от вас.

Небольшие изменения в коде могут давать огромные изменения в производительности. Всего несколько строк могут означать разницу между быстрым сайтом и диалогом “Unresponsive Script”.

Это перевод и форма повествования от первого лица сохранена. Автор — Бен Бойтер, бакалавр информационных технологий в Университете Чарльза Стерта (CSU).


Большинство людей не в курсе, но моей диссертацией была программа для чтения текста с изображения. Я думал, что, если смогу получить высокий уровень распознавания, то это можно будет использовать для улучшения результатов поиска. Мой отличный советник доктор Гао Джунбин предложил мне написать диссертацию на эту тему. Наконец-то я нашел время написать эту статью и здесь я постараюсь рассказать о всем том, что узнал. Если бы только было что-то подобное, когда я только начинал…

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

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

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

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

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

TryGit — интерактивный обучающий курс по Github в стиле Codecademy. Курс состоит из 25 мини-уроков, которые знакомят пользователя с базовыми понятиями и основными командами git, при этом ученик своими руками вводит команды в консоль, смотрит результат и читает сопровождающие надписи с объяснением происходящего.



Вот таким в будущем должно стать обучение в школах!

Конечно, 15-минутное введение не заменит полноценного учебника. Для обучения можно рекомендовать бесплатную книгу Pro Git и видеокурс Getting Git.

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

Во многих случаях когда запросы содержат условия равенства как например {“name”: “Charlie”}, принцип который выше очень полезен. Но что о нем можно сказать со следующим примером:

Запрос:
db.drivers.find({"country": {"$in": ["A", "G"]}).sort({"carsOwned": 1})
Индекс:
{"country": 1, "carsOwned": 1}

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