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

Find — аналог SELECT в MySQL. Используется для выборки документов из MongoDB. Возвращает массив документов в виде коллекции, если документов нет — пустую коллекцию. Пример:

> db.users.find();

Вернёт всех пользователей из коллекции.

> db.users.find( { age: 27 } );

Вернёт всех пользователей, у которых возраст равен 27.

Я стал замечать, что в последнее время build-системам стали уделять всё больше внимания, и, под влиянием этого, их в одночасье стало настолько много, что, честно говоря, уже всех и не упомнить. Последнее время у меня на слуху четыре системы: Grunt, Gulp, Brunch и Gear. Про все что-то где-то было написано, но ни разу не ставился вопрос о том, какие преимущества или недостатки они имеют друг перед другом? И именно поэтому я решил провести сравнительный анализ самых популярных build-систем(по версии google).

Но сперва надо определиться с критериями, по которым мы будем оценивать эти системы:

• Начало работы.
• Производительность. Никто не хочет ждать по минуте после изменения одного coffee-файла.
• Документация. Чем нагляднее и проще — тем лучше.
• Плагины. Ведь мы не хотим столкнуться с проблемой, когда мы начали использовать билд-систему, а в ней нет адаптера, скажем, для jasmine?

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

На Хабре не раз поднимался вопрос автодополнения адресов в форме (раз, два, три).

Но вот и перед мной появилась задача реализовать такое автодополнение для небольшого интернет магазина. Критерии были такие:

• Автодополнение адресов только Москвы
• Автодополнение адреса одной строкой
• Решение должно быть бесплатно (лимит запросов не менее 1000 в сутки)
• Возможность подключить без дополнительных JS библиотек. (Я использую AngularJS Bootstrap-UI, в котором есть директива Typeahead, реализующая автодополнение формы)
• Стопроцентный uptime не обязателен

Но какой источник данных выбрать? Я выбрал целых четыре, и решил их сравнить: в одном углу ринга заморские Google Geocode и Google Autococomplete, а в другом отечественные КЛАДР в облаке и DaData подсказки.

DISCLAIMER: Автор никак не причастен к разработчикам ни одного из представленных сервисов.

История

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

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

И наконец, в один прекрасный день вы решили: “Сделаем это!”. И вот вы уже пытаетесь разобраться как реализовать бизнес-логику своего приложения, ту киллер-фичу, которая будет двигать продукт вперед. У вас есть идея как это сделать, и вы знаете, что способны на это. И вот вы говорите: “Готово! Работает!” У вас есть успешный прототип! Осталось только упаковать его в веб приложение.

“Окей, сделаем сайт,” говорите вы.

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

Перед вами десятки и десятки архитектурных решений, которые необходимо принять. И вы не хотите ошибиться: требуются технологии, которые позволят вести быструю разработку, поддерживают постоянные итерации, максимальную эффективность, скорость, устойчивость и многое другое. Вы хотите быть бережливым (lean) и гибким (agile). Вы хотите использовать технологии, которые помогут вам быть успешным как в краткосрочной, так и в долгосрочной перспективе. А выбрать их далеко не всегда так просто.

“Я перегружен”, говорите вы и чувствуете себя перегруженным. Энергия уже не та, что была в начале. Вы пытаетесь собраться с мыслями, но работы слишком много. Прототип медленно блекнет и умирает.

В прошлые выходные раздался звонок мобильного телефона. Номер незнакомый. Снимаю трубку.
На противоположном конце линии девушка сообщает, что она представляет компанию Яндекс, и что мне высылали электронное письмо с информацией о новом сервисе: теперь можно принимать на сайте платежи не только Яндекс.Деньгами, но и банковскими картами VISA/MasterCard с помощью формы от Яндекса. Я ответил, что письмо не получал (может попало в спам?), но информация интересная, и я обязательно подробнее ознакомлюсь с новыми возможностями сервиса.

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

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

Например, сейчас у нас в работе есть SharePoint-портал, который используется для дистанционного расчетно-финансового обслуживания контрагентов компании-заказчика. У каждого контрагента имеется несколько пользователей — от 1 до 10. Мы хотели понять, как они обращаются с тем или иным функционалом. Чтобы обрисовать для себя их поведение, мы задействовали средства Google Analytics.

Доклад на девятой конференции «Свободное программное обеспечение в высшей школе», 25–26 января 2014. Исходный код заметок и примеров к ним доступен на https://github.com/mbykov/articles.

• первое знакомство с component — unix way в веб-программировании
• пример создания компоненты
• юнит-тестирование — консоль
• юнит-тестирование — express
• юнит-тестирование — браузер
• make vs. gulp vs. grunt, & watch
• Z's dead, baby
• компоненты и couchapps

Все, кто работает с node.js, знают TJ Головайчука, автора веб-сервера express, библиотеки для тестирования mocha, и прочая, и прочая. Но, наверное, самый блестящий его проект на сегодня — это Component — http://github.com/component. На русском пока немного литературы о Компонентах, попробую восполнить этот пробел. TJ опубликовал первое сообщение о Компонентах в своем блоге 19 декабря 2012 г. Сейчас, после взрывного роста, количество компонент уже зашкаливает за тысячу, и растет каждый день.

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



Мы в Яндекс.Почте, сложном и массовом проекте, накопили заметный опыт в поиске и устранении таких утечек, и хотим им поделиться.

О чем топик?

В этой статье я расскажу о реализациях разного функционала (преимущественно, на веб-сервисах) для обеспечения безопасности пользователей на примере «гигантов» современной IT индустрии. Данный материал будет полезен разработчикам, архитекторам, тим-лидам и менеджерам при постановке задач схожего функционала. Реализации в статье разработаны командами профессионалов, проверены временем и сотнями миллионами пользователей (а также большим количеством хакеров), хоть и никаких гарантий, что именно данный вариант реализации — абсолютно правильный и 100% безопасный, конечно же нет. Информация основана на личном анализе этих ресурсов.

На нашем проекте мы используем Backbone.js в качестве основного JS-фреймворка. Почему выбор пал на него, я возможно ещё расскажу в одном из следующих постов, в этот раз речь о другом. Как известно, из коробки Backbone предлагает весьма скромные возможности, компенсируя это максимальной гибкостью. Поскольку Backbone существует достаточно давно и успел обзавестись серьёзным сообществом разработчиков, для решения многих типовых задач Backbone-приложений сегодня существуют плагины либо целые надстроенные над Backbone фреймворки (многим известен например Backbone.Marionette, очень многообещающе выглядит недавно вышедший Base — кстати советую приглядеться).
Тем не менее, есть одна достаточно распространённая задача, адекватное решения которой мне до сих пор не попадалось: речь идёт о создании типовых автономных элементов UI. Скажем, у вас в проекте используется элемент выбора даты, для его создания вы используете найденный вами на бескрайних просторах гитхаба плагин jQuery. С этим последним всё хорошо кроме того, что вам нужно вручную дёргать его каждый раз, когда на вашей странице появляется соответствующий input, а потом возможно ещё и подчищать созданную им разметку во избежание дальнейших конфликтов. В итоге вам приходится писать много повторяющегося кода. Вот здесь вам и пригодится Backbone.Component.

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

Привет, Хабр.

В этой статье пойдет речь о том, из чего состоит Marionette.js, и о возможности не писать свой велосипед.

Статья рассчитана в первую очередь на работавших с Backbone.js и/или Marionette.js.
Для вновь знакомящихся будет полезна первая, обзорная, часть и ссылки в конце статьи.

Привет, Хабр! В ходе обсуждения одной статьи про «идеальную» домашнюю сеть, возник спор, что лучше, аппаратный NAS или мини-компьютер с Linux дистрибутивом. Автор предлагал использовать аппаратный NAS, т. к. якобы он проще в администрировании, не требует знаний Linux, да и вообще NAS тихий. Но при этом, для просмотра на DLNA-телевизоре видео, который он не поддерживает, предлагал включать ноутбук с транскодирующим DLNA. Меня это, мягко говоря, удивило, т. к. в идеальной сети такого быть не должно. Поэтому хочу представить своё видение одного из ключевых компонентов домашней сети — централизованного хранилища данных, и основано оно будет на мини-ПК с ОС Ubuntu Server.

Наткнулся вчера на этот инструмент и не смог пройти мимо, провел ночь за написанием тестов, а теперь хочу поделиться находкой. QUnit — это библиотека от разработчиков jQuery, позволяющая писать unit-тесты для кода на javascript. Удобна в использовании, ничего лишнего, осваивается за 20 минут, выгода от применения — колоссальная.

Самым нетерпеливым сразу ссылки:
Официальная документация на сайте jquery: docs.jquery.com/QUnit
Реальные примеры тестов (для модулей jquery): view.jquery.com/trunk/jquery/test/unit
Руководство для начинающих (англ): www.swift-lizard.com/2009/11/24/test-driven-development-with-jquery-qunit
Система распределенного тестирования (гениально и просто): testswarm.com

Под катом информация о преимуществах юнит-тестирования применительно к js и разбор возможностей библиотеки на примерах.

В developer подписках Apple есть возможность разрабатывать приложения для внутрикорпоративного использования. При этом приложения не проходят проверку со стороны Apple и не обязаны «светится» в AppStore. Всё выше сказанное относится и к Ad Hoc приложениям, они принципиально ничем не отличаются, разве что временем жизни после создания.

Для распространения приложения хотелось решить задачи:

1. пользователь самостоятельно мог установить приложение на свое устройство
2. только авторизированный пользователь мог устанавливать приложение
3. простая публикация приложения на сервере

Продолжая свои рискованные и бесчеловечные эксперименты в области веб-проектирования, сегодня я предлагаю вашему вниманию дальнейшее развитие Markdown webdocs и его интеграцию с сервисом GitHub.
Что получилось: достаточно простая, несколько вики-подобная (в подходе к редактированию), с форматированием текста markdown + html + компоненты, с встроенным редактором (и не только текста страницы, но и структуры сайта), без дополнительных сервисов/серверов/базы данных, основанная на Git(Hub) и файлах, фактически CMS система ориентированная на создание документации, простых сайтов или веб-приложений, с возможностью распределенной работы с общим репозиторием (читаемые диффы, автоматические коммиты, возможны пул-реквесты).

^{Вот так люди видят вашу страницу}

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

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

По моим примерным подсчётам (усреднение с ряда позиций), конверсии для нас выглядят так:

• Только название и картинка — около 1,5%.
• С описанием от производителя — чуть более 2%.
• С описанием человека, который держал это в руках и знает правила — около 6%.

Ниже — рассказ про то, как мы доводили время на сайте от 3 минут сначала до 6:40, а потом до 20:48. Да-да, двадцати минут сорока восьми секунд для среднего посетителя. Честного среднего, с учётом отказов и по полной выборке.

Вместо предисловия

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

Чуть больше года назад встала проблема выбора NoSQL решения для проекта. Был ряд определенных требований.

1. Возможность расширения (триггеры, хранимые процедуры);
2. Полнотекстовый поиск;
3. Наличие провайдера для .NET;
4. Поддержка POCO;
5. Возможность развернуть на Windows платформе;
6. Желательно поддержка lucene.net;
7. Желательно поддержка транзакций;
8. Желательно поддержка асинхронных запросов;
9. Желательно map reduce;
10. Желательно наличие документации и сообщества разработчиков.

После долгих поисков и сравнений выбор пал на RavenDb. Меня немного удивило, что данному продукту посвящено не так много публикаций. После года общения с данным NoSQL решением решил поделиться впечатлениями. Переписывать документацию не вижу смысла, все очень хорошо описано на сайте проекта и в официальных группах. А также блоге разработчика Ayende blog.