Итак, подошел к концу наш хабра-конкурс «Истории, которые меня многому научили»:

• Лучшей историей по оценке хабровчан стала история itblogger про ускорение коммуникаций
• Приз наших симпатий получила история craft_brother про правильную командность

Глядя на конкурс историй, мой коллега SlavaPankratov вспомнил две истории из своего прошлого, которые его многому научили:



Из этого видео вы узнаете:

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

P.S. В свое время мы все свои ошибки и инструменты, к которым пришли, свели в подробную интеллект карту «Формула работы с людьми», про которую SlavaPankratov как раз упоминает в видео. Скачать ее можно ниже – под катом.

«Детали — это не детали. Они создают дизайн.» — Чарльз Имз.

Успех цифровых продуктов определяется мелочами. Книга «Микровзаимодействия» Дэна Саффера научит вас проектировать эффективные функциональные элементы. А этот подробный конспект поможет лучше запомнить прочитанное или даже заменит англоязычный оригинал.

Как пользователю изменить настройку? Как включить бесшумный режим или узнать о получении нового сообщения?

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

Привет, Хабр!

Средние и крупные проекты, в которых целиком, либо значительная часть бизнес-логики реализована в хранимых процедурах СУБД, имеют ряд неудобств по управлению кодом модулей. А именно:

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

Да, есть коммерческие продукты, решающие эти проблемы полностью или частично, однако, на взгляд автора, делают это не эффективно и не элегантно. В виду этого, реализовано отображение модулей и структуры БД на файловую систему, с помощью FUSE (Filesystem in Userspace), в проекте SQLFuse. Теперь последователи Unix way смогут пройти и здесь.

Рассмотрим последовательность действий для монтирования опытной БД.

В любой компании, где существует более одного офиса, рано или поздно возникает необходимость в объединении этих самых офисов. Многие провайдеры предлагают такие услуги, но попросят за это денег, да и кто знает, что там творится на стороне провайдера? Поэтому сделаем все сами, и рассмотрим вариант объединения с помощью Mikrotik RB750, Ubuntu и OpenVPN.

Почти два года назад вышла статья «What no one told you about z-index» (и её перевод на Хабре «То, что вам никто не говорил о z-index»), авторы которой рассказывают о малоизвестной (76% проголосовавших пользователей Хабра слышат об этом впервые), но документированной возможности создания нового контекста наложения указав opacity меньше единицы.

Но несмотря на название статьи, авторы не рассказали вам ещё кое о чём.


Новый контекст наложения формируется в случаях:

• Корневой элемент () всегда содержит корневой контекст наложения. Любой элемент на странице, не участвующий в локальном контексте наложения (сформированном любым из последующих вариантов), участвует в корневом контексте наложения.
  Элемент с position отличным от static и значением z-index отличным от auto. Кроме одного исключения для position: fixed, но я это вынес в отдельный пункт.
  Элемент имеет значение opacity меньше, чем 1.
  

Не так давно состоялся релиз Scala 2.11.0. Одним из примечательных нововведений этой версии являются квазицитаты — удобный механизм для описания синтаксических деревьев Scala с помощью разбираемых во время компиляции строк; очевидно, что в первую очередь этот механизм предназначен для использования совместно с макросами.

Удивительно, но на хабре пока тему макросов в Scala рассматривают не слишком-то активно; последний пост
с серьёзным рассмотрением макросов был аж целый год назад.

В данном посте будет подробно рассмотрено написание простого макроса, предназначенного для генерации кода десериализации JSON в иерархию классов.

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

Мы назвали систему АЗ Сутра. Сутра – это на санскрите «нить», а так же ценное высказывание. Сутра – любая целостная ветвь общения, мне это нравится больше чем thread (тоже «нить», кстати). АЗ – активность и значимость.

Этот пост был написан спустя год после запуска Google+, и пролежал в черновиках с тех пор ещё два года. Периодически я вспоминал про него, вздрагивая: а вдруг G+ взлетел и пост будет уже не актуален? Но время шло, Google+ всё никак не взлетал, и три года после запуска его соцсети, жизнь кипит в Фейсбуке, Твиттере и Вконтакте. Жизнь кипит и на Ютубе, где без G+ теперь ни лайк не поставишь, ни коммент не оставишь. И только в самом G+ жизни нет. А выводы поста не просто остаются актуальными, а подтверждены практикой. Поэтому просто выкладываю написанный два года текст как есть.

Конечно, понятие неуспеха относительно. В Google+ есть большое количество пользователей, бренды считают обязательным в свой «соцпакет» к представительствам в Фейсбуке и Вконтакте добавлять и G+. И тем не менее Google+ — это провал.

Робот-пылесос — у многих из нас эти бытовые устройства ассоциируются с брендом iRobot. Но сегодня количество марок, которые можно найти на рынке насчитывает не один десяток. Да, iRobot остается одним из самых узнаваемых, но не менее активно в лидеры пробиваются и аппараты от Samsung, и устройства от LG, и еще целый ряд менее именитых азиатов. Цена на робопылесосы стартует от 8-9 тысяч, а затем улетает в космос — можно найти модели и за 30, и за 40 тысяч. Самые ходовые, естественно, это бюджетные пылесосы стоимостью около 10 тысяч рублей. Плюс-минус.

Привет всем! На хабре я уже более 5 лет и успел заметить множество стартапов которые были анонсированы здесь и успели дорасти до серьезных коммерческих проектов.
Мне всегда хотелось повторить их путь и следствием этого стал запуск Raindrop.io и публикации анонса.



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

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

Актуально это и на работе. Для хранения и обмена полезными ссылками на разные Github проекты, статьи, сервисы раньше мы использовали Skype, но сейчас стали использовать для этих целей Yammer. Оба этих способа имеют свои недостатки. Основной недостаток Skype для обмена ссылками — это сложность поиска по истории. Проблема Yammer — он не индексирует текст статьи, а только сниппет. Ни один из них не имеет возможности автоматической категоризации.

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

• добавление статьи одной кнопкой из браузера
• автоматическая категоризация
• русская и английская морфология
• просмотр текста статьи
• операторы поискового запроса

Может ли поисковый сервер Elasticsearch использоваться в качестве NoSQL базы данных? Положительный ответ позволит рассмотреть его различные свойства, в том числе и те, от реализации которых он отказался, чтобы стать одним из самых гибких, производительных и масштабируемых поисковых движков. Но для ответа на этот вопрос стоит сначала определиться с самим термином NoSQL, так как в зависимости от контекста он может трактоваться по-разному.

Что же все-таки такое NoSQL?

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

Дело в том, что речь идет совсем не об SQL. Поясним. Язык запросов Hive явно был вдохновлен SQL. Это же можно сказать и о языке Esper, хоть он работает и не с потоками, а с отношениями. Интересна история PostgreSQL — изначально он назывался Postgres, в качестве языка запросов использовал Quel и являлся ORDBMS, а сегодня PostgreSQL обладает многими функциями, которые позволяют ему быть документноориентированным хранилищем.

В данном случае речь идет не о ACID — в определении NoSQL о транзакциях ничего не говорится. Hyperdex — это база NoSQL, которая стремится обеспечивать ACID-транзакции. MySQL, несомненно, является базой SQL и в своей истории имеет сомнительные интерпретации на тему, что же на самом деле означает ACID.

В своем прошлом посте, с анонсом Google Chrome расширения для Likeastore, я упомянул тот факт, что в качестве поискового индекса мы начали использовать ElasticSeach. Именно ElasticSeach дал достаточно хорошую производительность и качество поиска, после которого было принято решение, выпустить расширение к хрому.

В этом посте, я расскажу о том, что использование связки MongoDB + ElasticSeach, есть крайне эффективное NoSQL решение, и о том, как перейти на ElasticSearch, если у вас уже есть MongoDB.

В последнее время в научных публикациях всё чаще упоминается алгоритм достижения консенсуса в распределенных системах под названием Paxos. Среди таких публикаций ряд работ сотрудников Google (Chubby, Megastore, Spanner) ранее уже частично освещенных на хабре, архитектуры систем WANdisco, Ceph и пр. В то же время, сам алгоритм Paxos считается сложным для понимания, хоть и основывается он на элементарных принципах.

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

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

Это наблюдение берет начало в далеком 1895 году, когда французский социолог Габриэль Тард (Gabriel Tarde) впервые описал процесс социальных изменений посредством подражательного по своей природе механизма «группового мышления» и S-образного паттерна [1]. В 1983 году Эверетт Роджерс (Everett Rogers) разработал более совершенную четырехступенчатую модель инновационного процесса принятия решения, состоящую из: (1) знаний, (2) убеждения, (3) решения и реализации и (4) подтверждения.

Эти два протокола долго жили в разных нишах применения, но наступило время, когда они стали конкурировать друг с другом. Мы однозначно видим, что Ethernet набирает скорость в прямом смысле слова и начинает лезть туда, где FC всегда считался единственным игроком на поле. Появились альтернативы FC, работающие на Ethernet, как в блочном доступе: IP-SAN, FCoE так и других типах, это файловый (SMB, NFS), RDMA и объектный.
Эта статья не призвана к сравнению протоколов, а скорее как краткое хронологическое описание эволюции сетей ЦОД.


* по некоторым событиям нет точных дат. Корректировки и дополнения по датам прошу присылать с удостоверяющими их ссылками. Таймлайн.

Я — веб-разработчик с непрофильным образованием и ~10-летним стажем. Я делал для веба все, что только могло прийти в голову моим заказчикам и, иногда, начальству. Я люблю эту работу. Но все же есть несколько вещей, которые я делаю совсем не улыбаясь. Одна из них — это file uploader. From the very beginning — когда еще никому не приходило в голову делать его аяксовым — и до настоящего времени — когда он ресайзит картинки, загружает файлы в несколько потоков и многое-многое другое — он остается для меня одной из самых нелюбимых задач. Вроде как у меня получилось с этим справиться. Если интересно — добро пожаловать под кат.
Вас ждут немножко Coffeescript-а, совсем чуть-чуть жалоб на jQuery, краткое описание $.Deferred, один к месту и не к месту нечаянно примененный паттерн и отсылка к одной забавной и интересной книге.

С написания предыдущей статьи про генерацию Excel документов по шаблону прошло много времени и задача несколько изменилась. Новая задача была поставлена следующим образом: из готового документа excel или word сделать шаблон через веб-интерфейс. В процессе формирования подставлять в шаблон нужные значения, убирать и/или «клонировать» куски шаблона. После формирования, документ должен быть доступен пользователю для визуального редактирования в браузере. Готовый документ должен сохраниться на сервере, быть доступным для скачивания пользователем как в своём расширении (*.doc/*.xls), так и в pdf. При этом верстка скачиваемого файла должна быть идентична шаблону, который был загружен в самом начале (без всяких искажений полей и областей печати).
Что же, задача есть — будем решать!

Каждый программист — проектировщик API. Хорошие программы состоят из модулей, а протокол взаимодействия модулей — это тоже API. Хорошие модули используются повторно.

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.

API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.

API должен описывать сам себя. Изучение кода на таком API не вызывает желания читать комментарии. Вообще, комментарии редко нужны.

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.

В Facebook мне попался очень интересный пост «Баллада о продающих письмах» на странице Антона Гладкова. Не могу не поделиться этим с Хабром, так как материал считаю чрезвычайно полезным. Но для этого пришлось произвести рерайт, поскольку оригинал насыщен запрещенными здесь словами. Надеюсь безобидный овощ под холодец сможет хотя бы частично передать эмоции автора, не нарушая правил.



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

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