Более трех лет назад я написал пост о выборе платежной системы для приема платежей на своем прошлом проекте. С тех пор прошло довольно много времени и многое в способах приема платежей изменилось. Теперь я расскажу как делал прием платежей на сайте poiskvps.ru.

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

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

В первой части мы остановились на следующей спецификации: Трансдьюсер — это функция принимающая функцию step, и возвращающая новую функцию step.

step⁰ → step¹

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

result⁰, item → result¹

Чтобы получить новый текущий результат в функции step¹, нужно вызвать функцию step⁰, передав в нее старый текущий результат и новое значение, которое мы хотим добавить. Если мы не хотим добавлять значение, то просто возвращем старый результат. Если хотим добавить одно значение, то вызываем step⁰, и то что он вернет возвращаем как новый результат. Если хотим добавить несколько значений, то вызываем step⁰ несколько раз по цепочке, это проще показать на примере реализации трансдьюсера flatten:

function flatten() {
  return function(step) {
    return function(result, item) {
      for (var i = 0; i < item.length; i++) {
        result = step(result, item[i]);
      }
      return result;
    }
  }
}

var flattenT = flatten();

_.reduce([[1, 2], [], [3]], flattenT(append), []); // => [1, 2, 3]

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

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

Итак, сейчас мы можем:

1. Изменять элементы (прим. map)
2. Пропускать элементы (прим. filter)
3. Выдавать для одного элемента несколько новых (прим. flatten)

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

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

Браузер Google Chrome поставляется с превосходными инструментами для разработчика, они же есть в Яндекс.Браузере, новой Опере, и в других браузерах, основанных на базе Chromium.

Среди них есть потрясающие инструменты для работы с памятью, ознакомиться с которыми можно в статье пользователя Panya — «Как находить и устранять утечки памяти на примере Яндекс.Почты».

Javascript хранит объект в памяти до тех пор, пока на него есть хоть одна ссылка. Как только вы удаляете все ссылки на объект, он уничтожается сборщиком мусора.

Таким образом, чтобы удалить объект, нужно удалить все ссылки на него.

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

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



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


Автоматическое распознавание уже начинает справляться с русским языком, за исключением некоторых особо сложных случаев

Сразу отмечу — да, эти решения могут сочетаться с определением конкретного человека по «голосовому отпечатку пальца», но это немного другая история и подробно останавливаться на этом здесь я не буду.

Обычно мы рассказываем про то, как делаем внешние продукты или их отдельные фичи — сам 2ГИС, его графику и типографику или Этажи. При этом тема внутренних продуктов ещё ни разу не поднималась. Исправляем эту досадную оплошность на примере «Fiji» — продукта для отрисовки интерактивной карты.

В последнее время появилось достаточно много мониторов с высоким разрешением, 150 dbi и выше, особенно в ноутбуках. И при этом всё выглядит жутко маленьким.
Причина этого — система думает что у Вашего монитора разрешение 96..100 dpi.
Решать это только увеличением размера шрифта неправильно, т.к. размеры всех остальных элеменов интерфейса остаются маленькими. Надо чтобы графическая оболочка сама это делала.

Мне с решением этой проблемы пришлось весьма долго рыться в интернете, собирая мелкие заметки, т.к. не оказалось места где бы это можно было увидеть всё вместе.

Ниже будет идти список где что поправить, все параметры привожу для своего монитора — 13,3" при 2560x1600, это даёт 226 dpi. Более высокое разрешение сейчас я видел только в ноутбуке Fujistu U904 — 262 dpi.

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



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

Наверное, каждый, кто использовал JavaScript, когда-либо сталкивался (или столкнётся в будущем) с асинхронными вызовами. Может быть, это будет обращение к базе на стороне сервера. Может быть — работа с таймером для создания анимации на сайте.

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

timeout(1000);
console.log('Hello, world!');

Можно ли реализовать нечто подобное? Разумеется, можно.
В данной статье мы рассмотрим один опасный, но действенный способ.

Mail.Ru — огромный портал, существующий более 15-ти лет. За это время мы прошли путь от небольшого веб-проекта до самого посещаемого сайта рунета. В состав портала входит огромное количество сервисов, у каждого из которых своя судьба, и над каждым из которых работает отдельная команда. Разработчикам пришлось как следует потрудиться, чтобы на всех проектах — и новых, и старых, и тех, которые присоединились к порталу по мере его развития, — использовалась единая система авторизации. А через много лет перед нами встала фактически обратная задача: разделить пользовательские сессии. О том, зачем мы это делали, какие трудности нас ожидали и как мы их обошли, я расскажу в этом посте.

Каждому разработчику в определенной степени следует овладеть навыками работы в терминале. Физически находиться у компьютера не всегда возможно, поэтому приходится подключаться удаленно. И действительно, GUI-программы вполне могут с этим с правиться, но зачастую они работают медленнее, чем получение доступа через тот же терминал (в конце концов, это лишь обмен текстом).

Привет хабр. Сегодня я хочу рассказать о необычном явлении, которое я наблюдал в результате эксперимента. Скажу сразу ничего общего с ИТ и объяснений с научной точки зрения не будет.
А будет «качер», ёмкость с водой, испорченные лампочки и любопытство познать новое! Кому стало интересно – прошу, заходите, будет весело.

Эксперимент с мемристорами в HP

Корпорация HP рассчитывает произвести настоящую революцию на рынке информационных технологий. Проект под названием The Machine — это попытка разработать новую компьютерную архитектуру, с новой операционной системой и новым типом ОЗУ на мемристорах, которые лишены ограничений современной DRAM и флэш-памяти и предполагают сверхвысокие скорости передачи данных.

Над амбициозным проектом работает 75% персонала HP Labs, пишет BusinessWeek.

Начиная с версии 1.5, в Firefox появился механизм кеширования, сохраняющий состояние страницы в памяти. Кеширование действует на одну сессию браузера. Перемещаясь по посещенным страницам с использованием кнопок «Назад/Вперёд», нет необходимости загружать страницу с сервера целиком. При этом вся страница, включая js-скрипты, как бы «консервируются» в том состоянии, в котором они были, когда пользователь их покидал. Данный механизм позволяет производить навигацию по посещенным страницам крайне быстро. Состояние кеша остается неизменным, пока действует сессия браузера (пока пользователь не закроет закладку, или браузер).

Не «баг», а «фича»

Помимо прочего, непонимание данного механизма браузеров вызывает настоящую головную боль у разработчиков. Рассмотрим пример.
Есть форма, данные которой мы хотим отправить на сервер. Мы хотим как-то визуализировать этот процесс и запускаем спиннер при отправке формы. Браузер переходит на следующую страницу. Если мы вернемся назад, используя кнопку браузера «Назад» (или через window.history.back()), то скорее всего увидим, что спиннер так и вращается, хотя на самом деле уже ничего не происходит.

Разработчик может посчитать, что данное поведение ни что иное как баг браузера или какая-то его особенность, и в поисках быстрого решения бездумно вставить лишний обработчик на событие unload (первый пункт в списке, приведенном дальше). Тем самым разработчик отказывается от BFCache вообще, тем самым лишая своих пользователей возможности практически мгновенного перемещения по посещенным страницам.

Психология — интересная и иногда полезная наука. Многочисленные исследования показывают, что задержка в отображении веб-страницы дольше 300 мс заставляет пользователя отвлечься от веб-ресурса и задуматься: «что за хрень?». Поэтому УСКОРИВ веб-проект до психологически невоспринимаемых значений, можно ПРОСТО удерживать пользователей дольше. И именно поэтому бизнес готов тратиться на скорость: $80М — чтобы уменьшить latenсy всего на 1 мс.



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

Как известно, 29-я версия браузера Firefox получила новый интерфейс под названием Australis для своей оболочки (табы, строка поиска, кнопки навигации и закладок; устранение Addon Bar и замена его на попап под кнопкой «инструментов» (три горизонтальные чёрточки, общепринятый знак для многих веб-интерфейсов)). Рассмотрим, что мы потеряли на сегодня из рычагов управления интерфейсом, которые до сих пор существовали в виде нескольких расширений браузера.

Конечно, для разработчиков расширений интерфейсов это не было неожиданным — за две версии нововведения объявляются и появляются в альфа-версиях, затем отрабатываются в бета-. Это — приерно 3 месяца на возможность подготовиться заранее (но большинство расширений поддерживают энтузиасты, которые не всегда могут выделить на это свободное время). Предусмотрена возможность частичного отката интерфейса к прежним версиям с помощью установки официального расширения Classic Theme Restorer.

Если посмотреть, на что больше всего жалуются пользователи новой версии:

Давным-давно, когда разрабатывалась файловая система Unix, в ней появились «псевдо-файлы» . и .., чтобы упростить перемещение между каталогами. Кажется, .. был добавлен в Версии 2, когда файловая система стала иерархической (в первой версии она была устроена совсем по-другому). Но эти «псевдо-файлы» засоряли вывод ls, и то ли Кен, то ли Деннис добавил в код ls простую проверку:

if (name[0] == '.') continue;

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

if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;

— но какая разница, главное что всё работало.

У этого было два далеко идущих последствия.

Представляю вам свой open-source проект — JPHP. Это альтернативная реализация PHP для JavaVM с поддержкой JIT. Я начал проект в одиночку в октябре 2013 года и за 4 месяца реализовал компилятор php в байткод JVM. Язык поддерживается на уровне PHP 5.3, частично поддерживаются возможности PHP 5.4 и 5.5. По своей идеологии проект напоминает JRuby и Jython.

Я подготовил небольшую презентацию, которая расскажет о проекте и не отнимет у вас много времени:

Возможно, вам уже попадался на глаза этот приём. Это поле ввода, которое выглядит так, как будто в нем есть текстовая подсказка (placeholder), но при начале набора текста она не исчезает, а отодвигается в сторону. Мне нравится эта идея. Брэд Фрост написал очень хорошую статью об этом приёме, подробно рассмотрев все «за» и «против».

Большинство примеров использования этой техники полагаются на JavaScript. В один прекрасный день я зашёл на nest.com, увидел там этот приём и задумался: а нельзя ли реализовать то же самое без JavaScript? И вот что из этого вышло.

Вот так выглядит форма на nest.com:

Привет Хабр!

Изначально хотел назвать статью «HTML по ГОСТ`у», но потом выяснилось что у большинства программистов не было предмета «Метрология и стандартизация» и о «стандартизации», «сертификации», «унификации» не все слышали.

В i-Free я много занимаюсь разработкой веб-приложений. А поскольку их много, они разные и работают в разных условиях, то само собой приходится задумываться о стандартизации. Есть такой проект «Пуленепробиваемый HTML5» (http://html5boilerplate.com/), в котором разработчики решили создать идеальный шаблон странички. Он мне очень нравился, и все свои проекты я начинал именно с него. Но, исправляя баг за багом, делая все новые и новые приложения, я пришел к выводу, что многого в нем не хватает. В этой статье я хотел бы рассказать о том, что обычно пропускают при написание страничек и веб-приложений и показать, чем и зачем я прокачал свой шаблон пустой странички.