Есть прекрасный сайт www.reformagkh.ru. На нём можно найти, управляющую компанию, закреплённую за домом, сколько денег, на что тратится и всё такое. Но кроме этого можно узнать разные интересные вещи о нашей стране в целом, например, для каждого дома на сайте указана дата его постройки, поэтому можно посмотреть, как строилась Москва с 1900 года:



Ещё более эпичная картинка получается, если посмотреть на Россию целиком:

Тема получения сертификата Let's Encrypt уже подымалась на хабре (см. тут), да и в сети можно найти много рецептов разного качества.

Читал я и ужасался: одни пишут, что то нужно nginx или apache остановить («на пару минуточек всего»), другие предлагают файлы подкладывать в папку веб-сервера (в соседней ssh-сессии), третьи — о том, как важно соблюсти правильный Content-type для файлов проверки домена…

Давайте попробуем обойтись без всего этого: чтобы не было мучительно больно ни на стадии установки, ни очередном продлении — даже если придётся обновлять сразу много доменов. Собственно, вот и вся цель моей небольшой заметки: это не пошаговый степ-бай-степ, не длинная теоретическая статья о том, как функционирует Let's Encrypt — просто описывается правильный на мой взгляд подход, который будет правилен для конфигурации любой сложности.

Вся суть в двух словах: пусть Let's Encrypt запустит веб-сервер на 9999 порту, а мы допишем конфиг nginx, чтобы он пробросил запрос на этот бекенд. Кому интересны детали — прошу под кат

Мы сделали это! Несколько сотен наших application-серверов переведены на PHP7 и прекрасно себя чувствуют. Насколько нам известно, это второй переход на PHP7 проекта такого масштаба (после Etsy). В процессе мы нашли несколько очень неприятных багов в системе кеширования байт-кода PHP7, но они исправлены. А теперь — ура! — благая весть для всего PHP-сообщества: PHP7 действительно готов к продакшену, стабилен, потребляет значительно меньше памяти и дает очень хороший прирост производительности. Ниже мы подробно расскажем, как мы перешли на PHP7, с какими трудностями столкнулись, как с ними боролись и какие результаты получили.

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

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

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

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

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

Предлагаю вашему вниманию вольный перевод статьи "Styling Broken Images" с сайта bitsofco.de.

«Битые» картинки выглядят ужасно.



Но они не всегда должны так выглядеть. Мы легко можем применить CSS к элементу (тегу) img, чтобы улучшить его внешний вид — сделать его куда более привлекательнее, чем как он выглядит по умолчанию.

Если вам наскучили дефолтные уведомления о «битых» картинках, милости прошу под кат.

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

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

Процесс бинаризации – это перевод цветного (или в градациях серого) изображения в двухцветное черно-белое. Главным параметром такого преобразования является порог t – значение, с которым сравнивается яркость каждого пикселя. По результатам сравнения, пикселю присваивается значение 0 или 1. Существуют различные методы бинаризации, которые можно условно разделить на две группы – глобальные и локальные. В первом случае величина порога остается неизменной в течение всего процесса бинаризации. Во втором изображение разбивается на области, в каждой из которых вычисляется локальный порог.

Главная цель бинаризации, это радикальное уменьшение количества информации, с которой приходится работать. Просто говоря, удачная бинаризация сильно упрощает последующую работу с изображением. С другой стороны, неудачи в процессе бинаризации могут привети к искажениям, таким, как разрывы в линиях, потеря значащих деталей, нарушение целостности объектов, появление шума и непредсказуемое искажение символов из-за неоднородностей фона. Различные методы бинаризации имеют свои слабые места: так, например, метод Оцу может приводить к утрате мелких деталей и „слипанию“ близлежащих символов, а метод Ниблэка грешит появлением ложных объектов в случае неоднородностей фона с низкой контрастностью. Отсюда следует, что каждый метод должен быть применен в своей области.

Предлагаю вам перевод статьи Gary Willoughby «Interesting ways of using Go channels».

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

Интересные способы использования Go каналов

Я написал этот пост, чтобы задокументировать доклад про Go каналы Джона Грэм-Камминга на конференции GopherCon 2014. Доклад назывался «Краткое руководство по каналам» и он доступен для просмотра на youtube.com.

На протяжении доклада нам представляют интересные способы использования Go каналов и раскрывают возможности и преимущества конкурентного программирования. Лично мне этот доклад открыл глаза на несколько новых способов структурирования программ и новых техник для синхронизации по нескольким ядрам процессора.

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

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

Функцией партиционирования таблиц в PostgreSQL, к сожалению, активно пользуются пока не многие. На мой взгляд, очень достойно о ней рассказывает в своей работе Hubert Lubaczewski (depesz.com). Предлагаю вам еще один перевод его статьи!

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

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

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

Примерами могут служить последняя цифра номера кредитной карты, девятая цифра VIN автомобилей, продаваемых в в США, или последняя цифра ISBN.

Алгоритм контрольной цифры ван Дамма — относительно новый и потому малоизвестный. Он опубликован 2004 году.

Алгоритм обнаруживает все ошибки в одной цифре и все одиночные перестановки соседних цифр. Он заметно проще, чем сравнимый по возможностям алгоритм Верхуффа, и не требует использования специальных символов (таких как X в 10-значном ISBN).

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

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

Некоторые могут возразить, что следование гайдам может убить творчество, и в итоге все приложения будут выглядеть одинаково. С точки зрения UX, я тут вижу другую проблему. Может казаться, что применение лучших шаблонов, которые используют Google / Facebook / Instagram / [вставить любимое приложение], всегда является отличным решением. Что они ставят себе такие же задачи, что и вы. Вот несколько шаблонов, которые считаются (или считались) лучшими, но в то же время не такие уж они и хорошие, какими кажутся на первый взгляд.

Недавно попалась на глаза занимательная статья с аналогичным названием о языке Haskell. Автор предлагал читателю проследить за мыслью программиста, решающего типичную ООП задачу но в Хаскеле. Помимо очевидной пользы расширения представлений читателей о том, что ООП — это отнюдь не «классы» и «наследование», подобные статьи полезны для понимания того, как правильно пользоваться языком. Предлагаю читателю решить ту же самую задачу, но на языке Go, в котором ООП тоже реализован непривычно.

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

Лет так 6 назад, когда слоник был только в 8.0, а я плотно сидел на MySql, часто слышал призывы сменить DB. Я помню как это было болезненно начать. Но после того, как решился, ни разу не жалел и на мускул уже вряд ли вернусь. Уж очень много тут плюсов, но пост не об этом.

Пришла задача: написать магазин, большой в перспективе. А-ля Фотос, Хотлайн. Ну и стандартная задача для таких площадок — это фильтр.

Вступление

Предупреждаю сразу: технического в статье очень мало. Это практически пошаговая инструкция для не очень сведующих в техническом плане пользователей. Для людей сведущих (и тех, кому лень читать много текста), приведу две ссылки: Telegram Bots API + IFTTT Maker Channel.

Теперь подробнее. Думаю, все слышали про мессенджер Telegram. Вероятно, многие даже знают про нехитрый API для создания ботов в этом мессенджере. Кроме того, не так давно в T появилась возможность создавать так называемые «каналы» (channels), упрощающие мгновенную рассылку сообщений практически любому количеству подписавшихся на канал лиц. Наконец, самая свежая новость: ботов стало можно добавлять в качестве администраторов в каналы, то есть такие рассылки стало можно делать автоматизированно.

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

• три канала (@RedditTop, @r_pics, @gone_wild — осторожно, последний с «взрослым» контентом), которые ежечасно импортируют топовые посты с Реддита (и двух его сабреддитов);
• ещё канал, делающий то же с постами с 9GAG;
• и, наконец, завел хитрого бота @JamesBot, который анонимно пересылает все сообщения, написанные ему, в общий канал (@secret_ru, @secret_en, @secret_es, @secret_ar или @secret_fa — в зависимости от языка). Получился анонимный чат средней степени трэшовости.

Уже после создания всех этих ботов и каналов мне пришло в голову, что простейший автоимпорт постов откуда-то «снаружи» можно наладить вообще без всякого кода и хостинга — буквально минут за 5. На помощь нам придет прекрасный сервис IFTTT — If This Then That, имеющий множество интеграций с социальными сетями и прочими сервисами. Правда, к сожалению, прямой интеграции с Телеграмом у него (пока?) нет — зато есть т.н. IFTTT Maker Channel, позволяющий делать простые HTTP(S)-запросы при срабатывании триггера. К сожалению, мы не сможем принимать сообщения, отправленные боту (входящие запросы IFTTT Maker принимать может, но, увы, только в строго определенном формате) — интерактива не выйдет. Зато сможем по срабатывании любого события (например, новый твит или пост в FB):

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

Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

— Многие из нас используют промисы без действительного их понимания.

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

Здравствуйте, дорогие читатели!

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

Много Java, JavaScript, схем, рассуждений и очень много текста

Предлагаю читателям «Хабрахабра» перевод статьи «The land of undocumented react.js: The Context».

Если мы взглянем на React компонент то мы можем увидеть некоторые свойства.

State

Да, каждый React компонент имеет state. Это что-то внутри компонента. Только сам компонент может читать и писать в свой собственный state и как видно из названия — state используется для хранения состояния компонента (Привет, Кэп). Не интересно, давайте дальше.

Props

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

Context

Встречайте context, причину, по которой я написал этот пост. Context — это недокументированная особенность React и похожа на props, но разница в том, что props передается исключительно от родительского компонента к дочернему и они не распространяются вниз по иерархии, в то время как context просто может быть запрошен в дочернем элементе.

Удобство работы с любым API во многом зависит от того, как написана и оформлена его документация. Cейчас мы ведём работу по стандартизации и унификации описания всех наших API, и вопросы документирования для нас особенно актуальны.
После долгих поисков мы решили оформлять документацию в формате RAML. Так называется специализированный язык для описания REST API. О его возможностях и преимуществах мы расскажем в этой статье.