Как-то обошло Хабр стороной появление видеокурса по Redux, созданного Даниилом Абрамовым, автором библиотеки. В первых роликах рассказывается о принципах Redux, а затем поэтапно разбирается разработка веб-приложения на нем.

Вот он: egghead.io/series/getting-started-with-redux

Под катом — перевод введения с сайта курса, egghead.io.

Нечеткий поиск строк является весьма дорогостоящей в смысле вычислительных ресурсов задачей, особенно если вам необходима высокая точность получаемых результатов. В статье описан алгоритм нечеткого поиска в словаре, который обеспечивает высокую скорость поиска при сохранении 100% точности и сравнительно низком потреблении памяти. Именно автомат Левенштейна позволил разработчикам Lucene повысить скорость нечеткого поиска на два порядка

Чтобы Яндекс показал Ваш сайт в числе первых, нужно чтобы он максимально полно отвечал на запрос пользователя. И это будет уже половина успеха. Оставшаяся половина это удобство, техническая составляющая сайта и его простота. Ниже я привел чек-лист из 68 пунктов, который был разработан специально для системы управления задачами PTYSH, совместно с компанией DFAKTOR. А теперь я делюсь им с Вами. Кропотливое выполнение каждого пункта из данного чек-листа позволит вывести практически любой сайт на самый верх поисковой выдачи. Но придется как следует поработать. Начнем с самого малого.

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

Эта публикация предполагает, что у вас есть некоторый опыт работы с Python и Redis и, в меньшей степени — с Lua, но и тем, у кого такого опыта нет, тоже будет интересно.

Зачем ограничивать число запросов?

Например, Twitter ограничивает количество запросов к своему API, а Reddit и StackOverflow используют ограничения на количество сообщений и комментариев.

Если вы знаете, почему после выполнения `hset mySey foo bar` мы потратим не менее 296 байт оперативной памяти, почему инженеры instagram не используют строковые ключи, зачем всегда стоит менять hash-max-ziplist-entries/hash-max-ziplist-val и почему тип данных, лежащий в основе hash это и часть list, sorted set, set — не читайте. Для остальных я попробую об этом рассказать. Понимание устройства и работы хеш таблиц в Redis критически важно при написания систем, где важна экономия памяти.

О чём эта статья — какие расходы несёт Redis на хранения самого ключа, что такое ziplist и dict, когда и для чего они используются, сколько занимают в памяти. Когда hash хранится в ziplist, когда в dicth и что нам это даёт. Какие советы из модных статей об оптимизации Redis не стоит воспринимать всерьёз и почему.

^{© Антон Кокарев}

Выхода Fallout 4 осталось ждать недолго. Множество фанатов по всему миру уже до дыр засмотрели тизеры игры, на форумах обсуждаются детали увиденного, и с новой силой разгорелся спор между адептами олдскульных «правильных» Fallout’ов 1/2 и теми, кому пришлись по душе скитания по пустоши в третьей части игры. Но оба лагеря геймеров, как и множество людей, никогда не игравших ни в какой Fallout, объединяет тяга к прекрасному — к постапокалипсису, к миру, лежащему в руинах. Вероятно, у психологов найдется в загашниках пара теорий, объясняющих, почему широким народным массам так интересна тема разрушенного мира, в котором выживают остатки человечества. Но не будем заниматься самодеятельным психоанализом, а лучше в преддверии выхода нового Fallout'a почитаем книги и посмотрим фильмы, в которых действие разворачивается во времена постапокалипсиса.

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

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

На другой стороне шкалы методы больших данных, когда все данные о вас начиная от сборки браузера, типа девайса (точнее, его цены) и разрешения экрана, плюс все данные профиля и оценка ваших действий на сайте ведут к оптимальному результату. Самый простой способ использования таких данных – за первые 20-30 секунд нахождения на сайте строить ваш профиль и сравнивать с профилями таких же людей. И предлагать вам в итоге не самые дешёвые квартиры и отели, например, а начинать с тех цен, которые для вас будут приемлемыми. Вы наверняка знаете эту сортировку, которую почему-то подают в прессе под соусом «самой удобной для клиента».

По моим ощущениям, самая удобная для нашего покупателя – это такая, которая понятна и поддаётся контролю.

Привет, Хабр! Мы продолжаем делиться технологической кухней Retail Rocket. В сегодняшней статье мы разберем вопрос выбора БД для хранения больших и часто обновляемых данных.

На самом начальном этапе разработки платформы перед нами возникли следующие задачи:

• Хранить у себя товарные базы магазинов (т.е. сведения о каждом товаре всех подключенных в нашу платформу магазинов с полным обновлением 25 млн. товарных позиций каждые 3 часа).
• Хранить рекомендации для каждого товара (около 100 млн. товаров содержит от 20 и более рекомендуемых товаров для каждого ключа).
• Обеспечение стабильно быстрой выдачи таких данных по запросу.

Продолжаем цикл статей о технологиях, использующихся в работе хранилища данных (Data Warehouse, DWH) нашего банка. В этой статье я постараюсь кратко и немного поверхностно рассказать о Greenplum — СУБД, основанной на postgreSQL, и являющейся ядром нашего DWH. В статье не будут приводиться логи установки, конфиги и прочее — и без этого заметка получилась достаточно объёмной. Вместо этого я расскажу про общую архитектуру СУБД, способы хранения и заливки данных, бекапы, а также перечислю несколько проблем, с которыми мы столкнулись в ходе эксплуатации.



Немного о наших инсталляциях:

• проект живёт у нас чуть больше двух лет;
• 4 контура от 10 до 26 машин;
• размер БД около 30 Тб;
• в БД около 10000 таблиц;
• до 700 queries per second.

За тем, как оно работает, прошу под кат!

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

Пара примеров:

• «Удобный хостинг»: Предустановка панели управления и дозаказ лицензий на лету
• Как работает API нашего IaaS-провайдера
• Как мы разработали свой DNS-менеджер

Сегодня мы поговорим о том, как ускорить загрузку страниц, и взглянем на советы эксперта по Ruby Нейта Беркопеца (Nate Berkopec).

Ночная зала. Тысячи таинственных ликов в темноте, подсвеченных голубоватым свечением мониторов. Оглушительный треск миллиона клавиш. Подобные выстрелам автомата удары по клавишам «Enter». Зловещее стрекотание сотен тысяч мышек… Так, наверняка, играло воображение каждого разработчика высоконагруженной системы. И если его вовремя не остановить, то может выйти целый триллер или фильм ужасов. Но в данной статье мы будем гораздо ближе к земле. Мы кратко рассмотрим известные подходы к решению задачи поисковых подсказок, как мы научились делать их полнотекстовыми, а также расскажем о парочке уловок, на которые мы пошли, чтобы придать им скорости, но при этом не научить жадности к ресурсам. В конце статьи вас ждёт бонус — небольшой рабочий пример.

БЭМ набирает популярность и становится актуальнее — например, недавно Google выпустил новую библиотеку блоков под названием Material Design Lite, реализованную по БЭМ-методологии. Команда БЭМ тоже не сидела без дела — мы выпустили новую версию библиотеки bem-components, на базе которой построены сайты и проекты не только Яндекса, но и других разработчиков.

Эти события натолкнули нас на мысль ещё раз вспомнить и рассказать вам, как сформировались принципы разработки библиотек в БЭМ-методологии. Надеемся, что многим это будет интересно и полезно. Итак, поехали.



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

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

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

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

Square, PayPal, iZettle — известные во всем мире компании, которые предлагают решения по приему банковских карт. Ни один из брендов не представлен в России. Зато у нас есть десять собственных. Мною проведено независимое исследование сервисов мобильного эквайринга в России, позволяющих принимать платежи по банковским картам Visa и MasterCard: iPay, Sum Up, Pay Me, 2Can, SimplePay, LifePay, Термит, ibox, Paybyway и RBK Card.

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

Задача: как получить деньги от другого человека здесь и сейчас?

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

На Июль 2013 г. найдено 6 сервисов по переводу средств с карты на карту по технологиям Visa Money Transfer® и MasterCard MoneySend®:

• MasterCard Mobile
• Qiwi
• Альфа- Банк
• RuRu
• PayOnline
• Русский Стандарт

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

В этой теме хотелось бы познакомить читателей с относительно новым подходом к контролю доступа под названием Attribute-based access control. Знакомство будет происходить на примере сравнения с популярным нынче Role-based access control.

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Спустя нескольких часов поиска и тестирования порядка 15 программ для расшаривания скриншотов и файлов в Windows, я кажется нашёл на мой взгляд самое функциональное, удобное, и плюс ко всему ещё и freeware & open-source решение. Подумал, что почувствую себя большим эгоистом, если не поделюсь им с кем-то ещё. Итак, встречайте!

ShareXMod — приложение позволяющее прозрачным и удобным способом расшаривать файлы и скриншоты (+редактирование/аннотации) с использованием более 20 различных сторонних сервисов. Не пугайтесь большого окошка на картинке, вся функциональность приложения реализуется в фоновом режиме, в свёрнутом в трей состоянии.

С Дмитрием Коробицыным мы посвятили 159й вебинар UX Russia влиянию дизайна (в широком смысле) на продажи интернет-магазина.



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

Продолжительность около часа! Видео для самых фанатов этой темы и этих спикеров :)