Слышали ли вы когда-нибудь в свой адрес упреки в неконструктивности? Может быть, сами кого-то упрекали? Как вы понимаете, что вот это конкретное обсуждение не конструктивно, а вот это конструктивно?

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

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

• Поймете причины поведения своих коллег, руководства и заказчиков в некоторых ситуациях
• Занесете в свой арсенал несколько простых приемов, которые помогут вам легче договариваться по работе
• Сможете абсолютно точно объяснить любому коллеге, что он неконструктивен (и в чем именно), если он действительно неконструктивен

Здесь не будет полюбившихся нам матриц 2 на 2, но пару схем мы разберем.

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

От переводчика: Это первая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Как клиентская, так и серверная часть Persona написаны на JavaScript. В ходе работы команда проекта создала несколько инструментов на все случаи жизни — от локализации до отладки, управления зависимостями и многого другого. В этой серии статей разработчики Mozilla делятся с сообществом своим опытом и этими инструментами, которые пригодятся любому, кто пишет высоконагруженный сервис на Node.js.

Первая статья цикла посвящена распространённой проблеме Node.js — утечкам памяти, особенностям утечек в высоконагруженных проектах и библиотеке node-memwatch, которая помогает найти и устранить такие утечки в Node.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Зачем заморачиваться?

Вы можете спросить, зачем вообще отслеживать утечки памяти? Неужели нет более важных дел? Почему бы просто не перезапускать процесс время от времени, или просто добавить памяти на сервер? Есть три причины, по которым устранять утечки всё-таки важно:

1. Возможно, вы не сильно переживаете об утечках памяти, но этого нельзя сказать о V8 (движок JavaScript на котором работает Node). Чем больше памяти занято, тем активнее работает сборщик мусора, замедляя ваше приложение. Так что в Node утечки напрямую вредят производительности.
2. Утечки могут привести к другим проблемам. Протекающий код может блокировать ограниченные ресурсы. У вас могут закончиться файловые дескрипторы или вы вдруг не сможете открыть ещё одно соединение с БД. Такие проблемы могут возникнуть задолго до того, как кончится память, но обрушат ваше приложение ничуть не хуже.
3. Рано или поздно ваше приложение упадёт. И это наверняка случится во время наплыва посетителей. Вас все засмеют и будут писать про вас гадости на Hacker News.

Вчера вышла [весьма достойная статья про Web Components, и я понял, что не могу не поделиться тем опытом, что я накопил за последние восемь месяцев. Я не буду рассказывать о том, как работать с Веб Компонентами, я расскажу, почему. Поэтому тем, кто не знает об этом стеке технологий, стоит прочитать статью по ссылке выше.
Дело в том, что в июне вышла первая стабильная версия моей библиотеки CornerJS. Начавшись как автономная реализация директив из AngularJS, она постепенно превратилась в более простой — как в использовании, так и в реализации — аналог (неточный, да, я знаю) Пользовательских Элементов из спецификации Веба Компонентов.

Я прошел через большое количество узких мест, а сейчас эта библиотека используется в нескольких больших и не очень проектах в реальных условиях.

Это замечательная, на мой взгляд, в реализации библиотека — я действительно считал ее основным инструментом в разработке, и в последнем проекте (видеопортале) она оказалась важнее jQuery: от него я мог бы отказаться, а от нее нет.

Но я, как человек, внедривший ее в нашу команду, и отказываюсь от нее — мы переходим на Mozilla X-tags для IE9+ сайтов и Polymer для IE10+ сайтов. К счастью, на моей памяти у нас был всего один или два проекта IE8+.

И в этом посте я расскажу, почему веб-компоненты — это не просто будущее веба. А единственное будущее веба.

Функциональность LINQ запросов в C# переписана на PHP. Изначально библиотека задумывалась как тренинг, так как подобные библиотеки уже существуют, но потом было решено её опубликовать для всех. Скопировать LINQ на PHP один в один невозможно, поскольку возможности языков C# и PHP очень разные. Отличительной возможностью предлагаемого решения является ориентация на итераторы, ленивые лямбда выражения и сигнатура LINQ методов, идентичная C# на сколько это возможно. Все стандартные LINQ методы, естественно, реализованы. Описание возможностей проекта с объяснением причин, почему именно такое решение было выбрано, под катом.

«Только со смертью догмы начинается наука.»
// Галилео Галилей

«Я начал завидовать рабам. Они всё знают заранее. У них твёрдые убеждения.»
// х/ф Марка Захарова «Убить дракона» по мотивам пьесы Евгения Шварца

Уже пару лет и дня не проходит, чтобы я не услышал (или не прочитал) от людей, начинающих новые проекты, фразу типа «Возьмем серверный движок для REST API и MVC, и погнали». Сначала я думал, что у этих слов есть один источник, может книжку какую завезли во все магазины или где-то в топе поисковиков лежит статья, зомбирующая разработчиков. Если же выяснять у них, что они понимают под REST и MVC, то можно повредиться умом. Ну с MVC уже все ясно, об этом я уже давно писал, ничего не изменилось, только усугубилось, стоит набрать в Google Images «mvc» и мы увидим страшное, стрелочки в любые стороны. Ну а про REST отвечают следующее: ну как же, нам нужно из браузерного GUI и мобильного приложения вызывать серверные методы, например: setUserCity(userId, cityId) или calculateMatrix(data) или startVideoConverter(options, source, destination) а потом мы столкнемся с большой нагрузкой и архитектура REST все решит. Дальше я задаю вопросы, от которых глаза округляются уже у тех, кто недавно еще горел праведной верой, рвался в бой и точно знал, что к чему в этом мире. Теперь можно перейти к рассмотрению терминологической катастрофы, в эпицентре которой мы с вами пребываем.

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

Когнитивное восприятия себя и окружающих людей мешает нам дать объективную оценку происходящему. Мир вокруг нас воспринимается через призму собственных убеждений и потакания своим инстинктам.
Задумаетесь, как вы принимаете решения? На чем они основаны: на логике, эмоциях или психологических установках?

Например, Маша, считает, что вечно опаздывающий на работу Вова — страшно неорганизованный человек, который не умеет управлять своим временем.
При этом Вова опаздывает на работу, потому что вынужден с утра умыть, накормить, одеть маленькую дочку и отвести ее в садик. Сама Маша приходит почти вовремя только на работу, во всех иных случаях она всегда опаздывает. Маша винит в своих опозданиях пробки на дорогах, не сработавший будильник, родственников, которые ее отвлекали.
95% бизнесменов терпят крах в первые 1-2,5 года, считая, что знают своего потребителя и могут заставить его купить свой товар. Мысль: «Я знаю, как думает мой покупатель», — главная ошибка начинающего бизнесмена.
На самом деле сам покупатель не знает, как он думает.
Именно поэтому большие компании содержат несколько маркетологов для реализации своей продукции.

Интернет-маркетологи, познавшие особенности когнитивного восприятия, выработали несколько механизмов, способных «включить» скрытые механизмы поведения.

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

В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго плана:

• На роль тестировщика готовы брать кого угодно, кто умеет достаточно уверенно нажимать на кнопочки
• Тестировщики редко участвуют в судьбе проекта, принимают решения по требованиям и срокам
• Тестировщиков стараются подключать как можно позже, когда надо «покликать» и «поикать ошибки»
• За исключением небольшого числа продуктовых компаний, большинство работодателей предлагают тестировщикам зарплату в 1,5-2 раза ниже, чем разработчикам.

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

Искушенного пользователя сегодня вряд ли можно удивить необычным формфактором — мы уже привыкли к тому, что у каждого крупного производителя есть свой “трансформер”. А некоторые из крупных брендов даже успели зарекомендовать себя как “вечные экспериментаторы”. Например, тот же ASUS.

Есть и чуть менее смелые (или чуть более осторожные — как угодно) компании, которые иногда удивляют. В конце прошлого года это удалось сделать Lenovo, представив Yoga Tablet, планшет с откидным упором.

Как-то полтора года назад я сидел в кафе на Арбате и думал о своем будущем. На тот момент работал программистом на полставки и учился в одном техническом ВУЗе. Все было стабильно, но хотелось чего-то большего – и я решил посмотреть, сколько зарабатывают хорошие программисты на фрилансе. Опыт «фрилансерства» у меня к тому моменту уже был, но впечатление осталось не самое лучшее — деньги маленькие, заказчики не всегда адекватные, один раз даже меня «кинули» с оплатой.

Я зашел на сайт всем известной российской фриланс-биржи и увидел, что за год моего отсутствия там ничего не изменилось: платят — мало, просят — много и так далее. Так у меня родилась идея посмотреть, что происходит на западе. Я нашел на Хабре статьи про иностранные биржи Odesk и Elance, почитал, подумал, как все сложно, и благополучно забыл про эту затею.

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

Спустя какое время стало ясно, что основная идея Prototype вошла в противоречие с миром. Создатели браузеров ответили на возрождение Javascript добавлением новых API, многие из которых конфликтовали с реализацией Prototype.

— Sam Stephenson, создатель Prototype.js, You Are Not Your Code

Создатели браузеров поступают гармонично. Решение о новых API принимают с учётом текущих трендов в opensource сообществах. Так prototype.js способствовал появлению Array.prototype.forEach(), map() и т.д., jquery вдохновил разработчиков на HTMLElement.prototype.querySelector() и querySelectorAll().

Код на стороне клиента становится сложнее и объёмнее. Появляются многочисленные фреймворки, которые помогают держать этот хаос под контролем. Backbone, ember, angular и другие создали, чтобы помочь писать чистый, модульный код. Фреймворки уровня приложения — это тренд. Его дух присутствует в JS среде уже какое-то время. Не удивительно, что создатели браузеров решили обратить на него внимание.

За последние шесть лет, пока я строил команду по проектированию интерфейсов, начав с самостоятельной деятельности и закончив командой из 11 человек, я видел, насколько сильно дизайнерские исследования могут повлиять на развитие продукта. Раньше у нас было мало времени на опрос клиентов и тестирование удобства. В основном мы действовали спонтанно: слушали, что говорит техподдержка и переделывали всё на ходу.



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

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

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

А началось все с личного кризиса.

При работе с информацией часто возникают задачи парсинга веб-страниц. Одной из проблем в этом деле является определение похожих страниц. Хороший пример такого алгоритма — «Алгоритм шинглов для веб-документов».

Часть проекта по парсингу реализована на Node.JS, поэтому и алгоритм нужно было реализовать на нем. Реализаций на javascript или npm-пакетов я не нашел — пришлось писать свою.

От переводчика: Sam Altman, успешный предприниматель из Калифорнии, делится своими наблюдениями по поводу того, что общего у самых успешных компаний. Сам Sam Altman, основавший компанию Loopt, которой удалось привлечь $30 миллионов венчурного капитала, входит в число партнеров Y Combinator. BusinessWeek назвал его одним из «Лучших технологических предпринимателей».

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

* Они одержимы качеством продукта/опыта. Почти слишком одержимы, они тратят много времени на детали, которые на первый взгляд не очень важны. Учредители этих компаний реагируют так, будто они чувствуют физическую боль, когда что-то идет не так с продуктом или пользователю оказывают плохую поддержку. Хотя они верят в ранний запуск и циклы, эти люди не собираются размениваться на плохой продукт. (Это не повод откладывать запуск. Вы, наверное, и так с ним медлите).

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

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

Настоящие размышления о программировании посвящаются главе 33 “Личность” и тем, кто решил связать свою жизнь с разработкой программного обеспечения.

Многие JavaScript-фреймворки предлагают свое представление о том, как должен выглядеть код. Более того, речь идет не просто о стиле, речь идет о способе написания сценариев. Это обусловлено практически абсолютной демократичностью JavaScript, да-да, именно таким является мультипарадигменный язык с С-подобным синтаксисом, прототипным наследованием, динамической типизацией и реализацией разнящейся от браузера к браузеру. Поэтому, когда речь идет о test-driven JavaScript я понимаю, что речь идет не просто об особом стиле программирования, но об особых технических принципах для особого фреймворка позволяющего тестировать JS приложения.

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

Внимание: длиннопост.

Некоторое время назад я начал рассказывать на Хабре про Elliptics — наше отказоустойчивое распределенное key-value хранилище (к слову, свободное и распространяемое под GPL-лицензией). Тогда я в общем описал устройство Elliptics: про архитектуру и основные принципы работы, за счет чего достигается надежность системы, как систему можно расширять, и как она ведет себя при сбоях.

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



Сегодня — про сетевую и программную архитектуру Elliptics и некоторые из его особенностей. Также я подробно расскажу про кэш и нашу низкоуровневую библиотеку для локального хранения данных — Eblob.

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

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

Семен занимал одну из самых важных должностей в этом проекте и мог влиять на многие аспекты бизнеса. Вопрос, с которым он обратился к аудитории звучал примерно так: «Друзья, у нас довольно успешный интернет-магазин игрушек, но мне не нравится его дизайн. Например вот эта штука, или эта. Я бы хотел выслушать ваше мнение, что нам можно изменить или улучшить?»

Аудитория не заставила себя долго ждать и тут же начала извергать самые разные идеи, предлагать развитие функционала или отказ от чего-то.

Вот проблема только в том, что никому не было интересно, а что же происходит с данным магазином сейчас, какая у него конверсия? На этот вопрос Семен ответил несколько расплывчато. Он думал или вернее догадывался о конверсии в 2% во что мне верилось с трудом.

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

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