Всем привет! Меня зовут Дмитрий Павлов, в компании Align Technology мы с коллегами занимаемся разработкой Web API для взаимодействия внутренних систем и интеграции нашей компании со сторонними вендорами. Об идеях создания API для веба, а точнее RESTful API я хотел бы рассказать в этой статье.

В последние годы тема Web API стала очень популярна, многие компании занимаются созданием подобных интерфейсов, как открытых, так и для внутреннего пользования. В описании Web API практически всегда можно встретить акроним REST, но что же это обозначает этот термин и правильно ли его используют?

Ниже будет приведен список инструментов мониторинга. Есть как минимум 80 способов, с помощью которых ваша машинка будет под контролем.



1. первый инструмент — top

Консольная команда top- удобный системный монитор, простой в использовании, с помощью которой выводится список работающих в системе процессов, информации о этих процессах. Данная команда в реальном времени сортирует их по нагрузке на процессор, инструмент предустановлен во многих системах UNIX.

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

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

Многие менеджеры сталкиваются с одной очень занимательной проблемой в IT-сфере. И имя этой проблеме — оценка эффективности работника. Еще пол столетия назад такая задача не вызывала приступов мигрени и паники у руководителей или экономистов, потому что все было просто. Работник закрутил 50 гаек — плохо, закрутил 150 гаек — великолепно! Но пришла революция информационных технологий, и оценка эффективности стала краеугольным камнем.



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

Для написания этой заметки  было затрачено:

• 68338 километров на поездки.
• 72 человеко-часа на почтовую переписку.
• 423 человеко-часа на эксперименты с коллективом в 30 человек.
• 88 часов на подготовку докладов и выступления на конференциях.
• 17 чашек кофе на беседу с мудрыми людьми на афтепати.
• Порядка 25 часов на набор этого текста и правку багов в нем :).
• До смерти замученный копирайтер, который был вынужден разбирать мои черновики, аудиозаписи и вообще ему спасибо.

Много денег и времени. Пожалуй, самым затратным (по нервам, времени и деньгам) был эксперимент над собственной командой, о котором мне безумно неловко вспоминать. Но об этом — ниже.

Рано или поздно, наверное, у каждого директора возникает желание платить по справедливости. За выполенную работу. И очень многие сейчас пытаются внедрять KPI (ключевые показатели эффективности). Работает так: вы, как владелец бизнеса, назначаете конкретные цели для сотрудников. Они достигают или не достигают поставленных целей в процессе работы. Тем, кто достиг — выдается плюшка (денежная премия).

Смысл такого подхода: платить по справедливости. На сколько наработал — столько и получил. Это честно, это логично, это — прекрасно!

Ну, логично же, что:

• Продажникам  нужно назначать процент с оборота. Волки должны быть голодными. (Да, есть альтернативное мнение, что применить такой подход — значит «обложить себя дополнительным налогом». Но как по мне — тут все справедливо :-)).
• Офисному планктону — ставить оклад. Стабильность для них — ооочень важное условие существования.

А вот с творческими единицами (дизайнерами, программистами) — все значительно сложнее.

Мы недавно провели опрос руководителей ведущих диджитал-агентств и веб-студий страны на тему «а как вы используете KPI по отношению к труду творческих единиц», в результате получили вот такую картинку:



Некоторые компании (15%) применяют KPI для оценки эффективности труда программистов и дизайнеров.

Давно идут споры о том, что такое работа программиста — ремесло, навык или искусство. При этом постоянно встаёт вопрос оценки результата. О том, как разные разработчики и руководители в Яндексе подходят к вопросу оценки работы программиста, мы поговорим в этом посте.



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

Пример очень неудачного опыта, пояснение в разделе “о технике безопасности”

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

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

CPU: 1 x 2GHz
HDD: 10Gb
RAM: 512Mb
OS: Debian 8 x64

Схема работы системы выглядит следующим образом:

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

Всем привет!
Процесс обработки ошибок в Yii был для меня не совсем прозрачным с первых дней использования этого фреймворка. Даже несмотря на наличие в документации специального раздела Error Handling. В каких случаях какие view используются, как влияет ajax или debug-режим, зачем нужен errorAction, в чем отличия при обработке исключений?
В итоге после копания в документации и исходном коде фреймворка я нарисовал наглядную схему обработки ошибок, которая лично для меня оказалась весьма полезной и наверняка пригодится кому-то еще.
Под катом собственно схема и некоторые комментарии к ней.

1. Верстка, аутсорсинг и технические задания

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

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

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



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

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

Всем прикольно пообсуждать «всё новое хреновое», и последние пару лет мы увлечённо обсуждали и пробовали NoSQL/NewSQL на сервере и Angular/Knockout/Ember на клиенте. Но эти тренды, похоже, уже на излёте. Отличный момент, чтобы присесть и поразмыслить, что же дальше. Как сказал M. Andreessen, «software is eating the world». В то же время, mobile/web apps едят обычные приложения. Поэтому особенно интересно прикинуть, а куда же всё катится в мире мобильных и веб-приложений? Ведь они, получается, едят вообще всех. Я считаю, что следующей Большой Темой будет синхронизация данных, и вот почему.

Весной этого года я узнал о возможности базы данных HP Vertica создавать запросы с матчингом паттернов событий. Так называемый Events Pattern Matching хорошо ложился под задачу анализировать поведение пользователей в продуктах ivi.ru. Мы решили попробовать разобраться с воронками оплаты, с поиском проблемных мест на устройствах, глубже погрузиться в анализ трафика. Нашей команде очень нравится, как реализована аналитика у Mixpanel и Localytics (она как раз основана на событиях и их свойствах), поэтому многие идеи были позаимствованы у них.

Привет! Меня зовут Алексей Озерицкий. В Яндексе я работаю в разработке технологий и инфраструктуры. Не только тем нашим сервисам, которыми пользуются миллионы людей, важно уметь работать с действительно большими объемами данных без сбоев. Один из наших ключевых внутренних инструментов — Я.Статистика, информация в котором предназначена только для сотрудников Яндекса и более того — является коммерческой тайной. Статистика занимается сбором, хранением и обработкой информации (в первую очередь логов) от сервисов Яндекса. Результатом нашей работы с ней являются статистические расчеты для дальнейшей аналитики и принятия продуктовых решений.

Один из ключевых компонентов Статистики – Logbroker, распределенное многодатацентровое решение по сбору и поставке данных. Ключевые особенности системы – возможность переживать отключение дата-центра, поддержка семантики exactly once на доставку сообщений и поддержка потоков реального времени (секунды задержки от возникновения события на источнике до получения на приемнике).

В ядре системы лежит Apache Kafka. Logbroker с помощью API изолирует пользователя от сырых потоков Apache Kafka, реализует процессы восстановления после сбоев (в том числе семантику exactly once) и сервисные процессы (междатацентровая репликация, раздача данных на кластеры расчета: YT, YaMR...).

JavaScript, наверное, самый известный мультипарадигменный язык, в котором очень много неочевидных особенностей. Но тем не менее любим ли мы его или ругаем, факт остается фактом — это основной язык, на котором работает современный web.

В ушедшем году, вышел стандарт ECMAScript 2015 (неформально ES6), который сильно изменил, то к чему мы привыкли. Появилась масса новых возможностей, которые по сути представляют собой современное надмножество языка, пытающегося решить существующие проблемы. Class, let, const, стрелочные функции… разработчик, который ранее не видел код, написанный на ES6, не сразу догадается, что перед ним, по сути, старый добрый JS.

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

Я пользуюсь макбуком уже примерно 1 год, я использую его ежедневно и очень много. До этого я сидел на Ubuntu и Windows. И когда я покупал MacBook то я ожидал, что продуманность ОС и удобство пользования будут выше всяких похвал. Как никак это ведь Apple, да и завышенная цена формирует у меня завышенные ожидания по поводу качества. Но увы на практике все оказалось не настолько идеальным как я считал. Многие недочеты происходят из фундаментального подхода Apple, в котором они дизайн ставят выше удобства и очень часто получается так, что то, что они делают красивым с эстетической точки зрения не удобно использовать на практике. Вообще я сторонник того, что бы красивый дизайн не портил функциональность. Есть еще и другой класс недостатков, которые просто есть и не понятно по каким причинам Apple решила реализовать этот функционал именно так, а не иначе. Но обо все по порядку.

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

Данная статья статья как раз из разряда таких исследований. Проводя работы по анализу защищенности мы приводим обычно очень схожие (общие для всех) советы, которым мало следует, некоторые best practices, которые или просто повышают общий уровень защищенности системы (например — применение CSP), или действительно позволяют предотвратить атаку.

Введение

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

Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик. Я расскажу, как сделать так, чтобы ваш сайт открывался быстро. Очень быстро.

Каждый веб-разработчик, выбравший Mac, после первичной настройки системы ищет рабочий инструментарий. И если c IDE и редакторами всё понятно, то что-либо подобное по удобству win-довым OpenServer или Denwer за бесплатно найти трудно. Есть отличное решение MAMP PRO, но оно стоит две тысячи деревянных. Да и работа через Apache некоторых может смутить.

Занимаясь решением этого вопроса, набрёл на интереснейший материал, который рассказывает о том, как при помощи консольного пакет-менеджера Homebrew настроить рабочее пространство буквально за 5-10 минут. Публикую его перевод, потому что кому-нибудь подобная инструкция по настройке веб-окружения на Mac обязательно пригодится.