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

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

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

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

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

Содержание:

1. Перенаправление порта позволит вам открывать локальные ссылки на мобильном устройстве
2. Активация псевдо-классов DOM-элемента
3. Повтор сетевого запроса при помощи cURL
4. Запуск сохранённых блоков кода (сниппетов) на любой веб-странице
5. Отслеживание изменений файлов через DevTools
6. Простая запись действий страницы
7. Поиск элементов DOM-дерева при помощи CSS-селекторов
8. Копирование изображения в формате Data URI
9. Переход к нужной строке при открытии файла
10. Упрощенная навигация между правками
11. Копирование ответа на сетевой запрос
12. Работа с несколькими курсорами при редактировании скриптов
13. Блочное выделение
14. Быстрый мониторинг событий в консоли
15. Доступ к выбранному DOM-узлу в консоли
16. Отслеживание незавершенных сетевых запросов при помощи фильтра is:running

Продолжение: 17-32, 33-48.

Рынок электронной коммерции и в мире и в рунете очень активно развивается, не смотря на кризисы и другие негативные явления. В мире в год средние темпы роста по данным eMarketer составляют около 18-20% в год, в России и Украине темпы роста доходят до 17-18%. Это примерно 3-4% от общего ритейла в России (в Украине чуть меньше, рынок развит меньше и сейчас глубокий кризис) и до 10-12% в США и других развитых странах. Средний уровень в мире составляет примерно 6%. Единственное исключение, в прошлом году в Украине из-за глубокого экономического кризиса рынок не вырос в долларовом эквиваленте, но для местных компаний это шанс нагнать упущенное раньше. Самое интересное, что мы все еще находимся в стадии зарождения рынка. По многим прогнозам доля электронной коммерции в общем ритейле достигнет 20% в ближайшие несколько лет. Для компаний данного сектора игнорирование этого рынка сегодня равносильно смерти завтра.



Интересен также и тот факт, что многие крупнейшие игроки электронной коммерции в США имеют оффлайн-корни, а США – это некая лакмусовая бумажка, катализатор рынка, который нам показывает, что произойдет на наших рынках в этом же сегменте через 3-5 лет. Этому уже есть подтверждение: в России ряд крупных интернет-магазинов уже давно принадлежат крупным оффлайн-сетям и поглощения продолжаются. В Украине с этим сложнее, хотя это процесс активно идет, так несколько месяцев назад компания «Фокстрот» выкупила 100% интернет-магазина Sokol.ua

Mobile commerce

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

Для тех, кто хочет погрызть гранит IT-науки, мы продолжаем публиковать список камней повкуснее и пополезнее. Предлагаем вашему вниманию следующую часть списка рекомендуемой литературы, рассчитанной для студентов 3 семестра Технопарка.

Предыдущие части: первая, вторая.

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



Иконки важны. Судя по ним, галочка внизу — это, почти наверняка, «я согласен с условиями». Телефон вверху — наверняка номер. Дальше — замок — это пароль. Оба поля активные, то есть логин и пароль у меня должны быть сразу, так?

Нет, нифига, китайский UX подразумевает, что я сначала введу телефон и нажму оранжевую кнопку (цвета иконки — и да, это кнопка!). Получу пароль и введу его во второе поле, а потом нажму зелёную кнопку. Робот сравнит телефон с паролем и пустит меня дальше. Эту форму, скорее всего, рисовал китаец.


^{А это обычная такая телефонная будка раннего космического века}

Сейчас покажу ещё несколько вещей, рождённых в стране, где квалифицированных инженеров примерно раз в двадцать больше, чем в Америке, а состояние изобретательности «советского инженера» ещё не пройдено. Я, конечно, опять продолжу свою историю и покажу интерфейсы в реальном мире — они не менее интересны с точки зрения юзабилити, нежели HCI, и не менее полезны для понимания, как можно работать с пользователем.

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

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

До сих пор мы говорили о типах только в отношении классов и интерфейсов. В течение многих лет мы только их (и массивы) и могли использовать. Однако же, PHP 7 добавляет возможность использовать и скалярные величины тоже, такие как int, string и float.

Но постойте. В PHP большинство примитивов являются взаимозаменяемыми. Мы можем передать "123" в функцию, которая хочет int, и довериться PHP, который все сделает «правильно». Так для чего же тогда нужны скалярные типы?

Инженер фотосервиса Imgur Джейкоб Гринлиф (Jacob Greenleaf) опубликовал в блоге на Medium материал, в котором изложил несколько советов по созданию высокодоступного кода для отказоустойчивых систем. Мы решили взглянуть на экспертное мнение.

Примечания tsafin:

Перед публикацией своего цикла статей по MapReduce в Caché, мне показалось важным озвучить данную прошлогоднюю точку зрения из статьи Адама Дрейка «Command-line tools can be 235x faster than your Hadoop cluster». К сожалению оригинальная статья Тома Хайдена, на которую он ссылается стала уже недоступна на сайте Тома, но её, по-прежнему, можно найти в архивах. Для полноты картины предлагаю ознакомиться и с ней тоже.

Введение

Посещая в очередной раз свои любимые сайты, я нашел крутую статью Тома Хайдена об использовании Amazon Elastic Map Reduce (EMR) и mrjob для вычисления статистики отношения выигрыш/проигрыш в наборе данных со статистикой по шахматным матчам, которую он скачал с сайта millionbase archive, и c которой он начал играться используя EMR. Так как объем данных был всего 1.75GB, описывающий 2 миллиона шахматных партий, то я скептически отнесся к использованию Hadoop для данной задачи, хотя были и понятны его намерения просто поиграться и изучить плотнее, на реальном примере, утилиту mrjob и инфраструктуру EMR.

Случайно увидел вот такую подсказку на Озоне:



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

У нас самих не лучший в мире поиск, но он продаёт. Давайте покажу, что мы сделали.

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

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

И вообще вели себя вызывающе с точки зрения ИТ.

При этом объём кода, нужные мощности и сложность реализации процессов росли. Дело в том, что такая деавтоматизация требует очень нехилых вложений в ИТ. Сейчас объясню на примерах, в чём дело и зачем мы так странно делаем.

После того, как у меня появился новый монитор на рабочем месте, я начал новую итерацию улучшения своего «безмышечного» (mouse-less, прим. пер.) опыта. Вы же знаете, что это значит, не так ли? Это значит, что каждый раз, когда вы беретесь за мышку, убирая руку с клавиатуры, вы тратите немного времени и энергии. Если вам нужно набирать много текста (а я много пишу кода), это становится существенным.

Так же существует следующий уровень «безмышечного» опыта, когда вы стараетесь избежать труднодоступных клавиш, например Delete, Backspace, Escape или даже Enter.

Если вы держите руки в стандартной позиции для 10-пальцевой слепой печати, более удобно нажать Ctrl-m вместо того, чтобы тянуться мизинцем к энтеру.

Немного теории

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

Суть проблемы

Если ваш IP адрес попал в черный список – адресаты не будут получать ваши электронные письма.

Попадание IP в публичные спам-базы грозит наступлением корпоративного почтового коллапса. Это неприятно, даже если e-mail адресов на домене всего 5 и всех пользователей можно временно «пересадить» на «обычную» почту на Яндексе или Mail.ru. Но, когда к внутреннему почтовому серверу «приколочены» более 50 ящиков, интегрированных с CRM-системой, проблема приобретает катастрофический характер.

Решение

Сегодня вышел самый долгожданный компонент PHPixie 3 — Auth для авторизации пользователей. Авторизация это наиболее критическая часть любого приложения, сделать ее правильно трудно, а ошибки могут скомпрометировать множество пользователей, особенно если речь идет об оупенсорсе. Использование устарелых hash-функций, криптографически небезопасных генераторов случайных чисел, неправильная работа с кукисами встречаются слишком часто. Я уже когда-то писал о старой уязвимости в Laravel, которую кстати полностью так не исправили. Поэтому в PHPixie Auth я очень внимательно отнёсся к аутентификации, особенно к долгим сессиям и кукисам.

Кстати в конце статьи у меня для вас есть очень радостная новость (спойлер: PHPixie теперь член PHP-FIG)

Какую бы вы назначили цену за проживание незнакомцев в вашем доме? Или сколько вы сами заплатили бы за то, чтобы пожить у кого–то? Вы заплатили бы больше или меньше, будь это спланированный отпуск или спонтанная поездка?
Не так просто ответить на все эти вопросы. В своё время мы столкнулись с тем, что заставляя арендодателей и пользователей отвечать на них, мы тем самым уменьшали активную базу данных жилья. Собирая фокус–группы мы наблюдали за тем, как люди вносят своё жильё в список доступных для аренды мест на нашем портале. И большинство застревали, когда нужно было назначить стоимость. Многие начинали смотреть, какие цены установлены на жильё поблизости, открывая в браузере кучу вкладок и пытаясь сравнивать своё предложение с аналогичными. Кто–то уже приходил, имея определённую цель, может быть, чтобы немного заработать на оплату ипотеки или оплату отпуска. Такие люди устанавливали цену исходя из своих заранее обдуманных целей, без учёта реальной ситуации на рынке. А некоторые, к сожалению, просто сдавались и не указывали стоимость аренды их жилья.

Мы пришли к выводу, что нужно предложить арендодателям удобный автоматизированный сервис, помогающий принять решение при назначении стоимости аренды. Разработка началась в 2012 году, и мы до сих пор его периодически дорабатываем. Этим летом мы внедрили динамическое ценообразование: ориентировочные цены пересчитываются ежедневно, исходя из текущей рыночной ситуации. Мы настроили алгоритм так, чтобы он учитывал наличие необычных, даже удивительных свойств выставляемого жилья. Также мы внедрили, уникальный, как мы считаем, механизм машинного обучения, позволяющий системе не только обучаться на своём опыте, но и, при необходимости, использовать небольшую толику «человеческой» интуиции.

Появилась задача обезопасить админскую часть на сайте. Причём это надо было сделать без внесения изменений в код самого сайта. Лучшее, что смог я найти — oauth2_proxy и nginx-google-oauth, но они требовали обработку коллбэков. Эти решения мне не понравились и я их отверг.

Пришлось обратиться к одному из модулей nginx и комплектующим для велосипеда.

Недавно мы опубликовали перевод статьи, в которой приводились аргументы в пользу изучения языков семейства С. Этот пост вызвал немало споров, в том числе была высказана точка зрения, что языки семейства С сходят со сцены; их востребованность хоть и велика, но снижается. Возможно, это и так. Но всё же язык С по-прежнему остаётся одним из наиболее распространённых.

Примечание переводчика: Мы в «Латере» занимаемся созданием биллинга для операторов связи. Мы будем писать об особенностях системы и деталях ее разработки в нашем блоге на Хабре (например, об обеспечении отказоустойчивости), но почерпнуть что-то интересное можно и из опыта других компаний. Сегодня мы представляем вашему вниманию адаптированный перевод заметки главного инженера LinkedIn Джоша Клемма о процессе масштабирования инфраструктуры социальной сети.



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

Сегодня в LinkedIn насчитывается более 350 миллионов пользователей по всему миру. Мы проверяем десятки тысяч веб-страниц каждую секунду, каждый день. На мобильные устройства сейчас приходится более 50% нашего трафика по всему миру. Пользователи запрашивают данные из наших бэкенд-систем, которые, в свою очередь, обрабатывают по несколько миллионов запросов в секунду. Как же мы этого добились?

Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.

В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.