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

И первый лайфхак – кликабельная картинка до ката, которая ведёт сразу внутрь публикации:

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

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

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

Для тех, кто не хочет тратить время, сразу расскажу про полученные выводы. БД PostgreSQL размещенная на btrfs c опцией compress=lzo, сокращает объем бд в двое (в сравнении с любыми ФС без сжатия) и при использовании многопоточного, последовательного чтения, значительно сокращает нагрузку на дисковую подсистему.

Здравствуйте. Хочу поделиться с хабровчанами своим опытом развертывания кластера Postgres-xl в виде мини-инструкции для «чайников». Статей и мануалов на тему развертывания кластера postgres-xl не то чтобы много, но достаточно. И в них всех есть пару существенных недостатков на взгляд такого человека как я, который никогда прежде не занимался кластеризацией и тем более никогда прежде не работал в линукс-подобных осях. Все статьи подобного рода написаны для людей уже более-менее знакомых с линуксом и развертыванием postgresql/postgres-xl на таком окружении.

Поэтому и возникло желание поделится с остальными своими наработками. Далее я пошагово опишу весь процесс развертывания, от скачивания исходников postgres-xl и их компиляции, до конфигурирования кластера.

Так как много статей «для опытных» уже написано, и на хабре тоже, я опущу описание самого Postgres-xl, его компонентов и их типов (ролей).

Привет Хабр! Последние 1.5 года я работал над своим проектом, которому был необходим надежный облачный хостинг. До этого момента я больше 10 лет занимался веб-программированием и когда я решил построить свой хостинг у меня были относительно поверхностные знания в этой области, я и сейчас не являюсь системным администратором. Все что я буду рассказывать может выполнить обычный программист в течение 5 минут, просто запустив набор сценариев для Ansible, которые я подготовил специально для вас и выложил на GitHub.

Без малого два года назад мы начали использовать в разработке нашего флагманского проекта СУБД ЛИНТЕР новую модель ветвления и управления подмодулями git-а. Десятки тысяч коммитов, сделанные за это время группой разработчиков, позволяют с определенной долей уверенности считать нововведения успешными. Эта статья — краткий обзор принципов организации хранилища исходных кодов в большом проекте на базе альтернативной реализации модулей git, сложившейся стратегии ветвления и инструментария linflow.

Amazon S3 удобно использовать для хранения файлов любых форматов. Кроме удобного API получаем практически безразмерное хранилище. Отличная доступность и невысокая стоимость делают S3 мегапривлекательной для молодых и небольших проектов.

Однако со временем файлов становится все больше. А платить придется не только за новые данные, но за всю историю. Кроме этого, Amazon дерет деньги за GET и POST запросы, а также за трафик.

Несмотря на низкую стоимость на старте, с ростом это решение будет обходиться все дороже.

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

Я постоянно веду переговоры с собственниками бизнесов и могу сказать однозначно — понимание, зачем внедрять ERP-системы, пришло далеко не ко всем.

Когда ты задаешь такой вопрос, то можно услышать много разных вариантов ответов.
Например:

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

И реже (но все чаще и чаще) звучат такие ответы как:

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

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

Да, теперь стало гораздо страшнее нажимать кнопку «Submit», ведь если вы чего-то недоглядели — в отличии от веб-приложений не получится посидеть ночь, обложившись банками ред-булла и пиццами и все исправить — ревью на мобильных платформах занимает время, а если говорить про iOS — аж целую неделю. Неделя — более чем достаточный срок для того, чтобы лояльный ранее пользователь перестал открывать ваше приложение.

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



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

И снова в эфире наша постоянная рубрика «Лекции Технопарка». На этот раз предлагаем вам ознакомиться с материалами курса «Проектирование высоконагруженных систем». Цель курса — получение студентами навыков проектирования высокоэффективных программных систем.

Представьте, через неделю вам уезжать в Веллингтон, где основным языком является английский, а вы его знаете на уровне «Ландн из э кэпитал». Идея выучить новый язык кажется абсурдной, куда уж тут за 7 дней освоить все эти знания. Но вспомните закон Парето, который обещает 80% результатов за 20% усилий. Лексика любого естественного языка очень хорошо вписывается в данный принцип. Вопрос — сколько слов нужно знать, чтобы общаться на повседневные темы?

«Максимум сотню, – говорит Фабио Капелло, бывший тренер сборной Англии по футболу. – Когда говоришь о тактике, не требуется большой словарный запас». Капелло, конечно, преувеличивает, и тем не менее он проработал в Англии три с половиной года, зная язык на поверхностном уровне. И это, по его мнению, не помешало ему тренировать команду.

Так может быть стоит ограничиться сотней слов?

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

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

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

Это не профессиональное исследование, но надо понимать, что за каждой анкетой стоит карьера и судьба конкретного человека. Черт побери, звучит пафосно, но это так. Что любопытно, анкеты нам присылали люди из самых разных компаний (и даже не только ИТ отрасли), самого разного возраста (от 24 лет до 51 года), из 6 стран, — вероятно, это говорит, об универсальности замеченных проблем.

Итак, что удалось заметить.

Я провожу собеседования на тестировщиков. У меня иногда болит голова.

Долго собирался написать статью… И вот, наконец, выполнил свое намерение. Вопросы, поднимаемые в статье, обсуждались уже не раз и не два, но усердные поиски компиляции ответов на эти вопросы так и не увенчались успехом. Но, как подсказывает мой опыт, такая компиляция очень нужна. Прежде всего она требуется юниорам, ибо в сети по запросу «тестирование» на них (соискателей) обрушивается огромный объем информационного мусора, который плохо структурирован и часто противоречит сам себе.

Frontend с каждым днём становится сложнее. Задачи — объёмнее, пользовательский интерфейс — насыщеннее, HTML, CSS и Javascript — огромнее, а сон фронтендера — короче и беспокойнее. Необходимо грамотно структурировать код, выполнять множество рутинных задач (компиляция css- и js-препроцессоров, сборка спрайтов, подготовка и оптимизация изображений, минификация файлов и др). Если вы работаете в команде — это автоматически увеличивает сложность разработки. Чтобы решить эти проблемы, я создал TARS — сборщик html-вёрстки, основанный на gulpjs.

Приветствую, Хабр!

В этой статье я постараюсь разжевать, что делать с дампами в Java, как понять причину или приблизиться к причине возникновения OOM, посмотреть на инструменты для анализа дампов, инструмент (один, да) для мониторинга хипа, и вообще вникнуть в это дело для общего развития. Исследуются такие инструменты, как JVisualVM (рассмотрю некоторые плагины к нему и OQL Console), Eclipse Memory Analyzing Tool.
Очень много понаписал, но надеюсь, что всё только по делу :)

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

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


Дома в центре Москвы разного цвета в зависимости от площади здания.
Данные: © Участники OpenStreetMap

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

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

Привет ребят, давайте для начала проверим вашу память. Итак:

«На море на океане есть остров, на том острове дуб стоит, под дубом сундук зарыт, в сундуке — заяц, в зайце — утка, в утке — яйцо» в яйце игла — смерть Кощея!

А теперь, внимание, вопрос — как это формализовать?
Как приатачить к яйцу иголку и какова временная сложность детача смертии моей. Как перенести сказку в быль, как это выглядит на B-деревьях и почему на самом деле нет разницы между 2D и 1D.
А было все так: давным давно, в неком царстве, некотором государстве, на одном сервисе с шейрингом геолокации очень захотелось Иванушке Дурачку на уровне ЧПУ разделить Москву(/RU/MOW/) и Область(/RU/MOS/). И вообще навести порядок, чтобы все лежало по полочкам красиво и по алфавиту. Но не получалось ему сокровища свои посчитать, и аккуратно разложить. А Василису, хоть и дурак, к сбережениям не пускал.
Но решение было найдено.
Совсем недалеко над каким-то златом успешно чах Чахлик, еще и смерть он свою прятал по науке.
И если задача определения региональной (точнее полигональной) принадлежности некой иголки к некому сундуку выходит за рамки данной статьи, то нам ничто не мешает погрузиться в глубины зайца и посмотреть как он устроен на табличном уровне.
PS: и не спрашивайте почему зайца.

На прошлой неделе BBC рассказала, что для новой версии главной страницы использовала методологию БЭМ, созданную в Яндексе. По такому случаю мы решили поднять материалы мастер-класса «Разрабатываем сайт с нуля на полном стеке БЭМ-технологий» и рассказать вам, как начать использовать полный стек БЭМ-технологий в своих проектах.

БЭМ упрощает разработку сайтов, которые нужно быстро создавать и долго поддерживать. Эту технологию используют во фронтенде почти всех сервисов Яндекса, и она уже успела обрасти множеством библиотек и инструментов, которыми мы хотим с вами поделиться.



В статье мы расскажем, в чём преимущество вёрстки независимыми блоками и что такое уровни переопределения, познакомимся с готовыми библиотеками блоков и инструментами для автоматизации сборки. Покажем, как разные инструменты — например, autoprefixer, css-препроцессор Stylus или модульная система YModules — упрощают жизнь разработчика и создают по-настоящему удобную платформу, если встроить их в процесс разработки по БЭМ.

На живом примере мы объясним, в чём польза декларативного подхода, когда одни и те же идеи можно использовать как для CSS, так и для JavaScript. Отдельно остановимся на декларативных шаблонах BEMHTML и BEMTREE, которые позволяют преобразовывать данные в БЭМ-дерево, описанное в формате BEMJSON и, затем в HTML. Рассмотрим в деталях, как написать серверную часть приложения по БЭМ-методологии.

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

Две недели назад закончилась Школа Автоматизации Процессов Разработки (ШАПР) в санкт-петербургском Яндексе.
Забегая вперёд, скажу, что преподавателям удалось главное: за неполных три месяца они «испортили» наше восприятие процесса разработки, как и обещали в начале Школы. Ручное тестирование и сборка начали жутко раздражать, вызывая мысли вроде «а ведь сейчас, вместо выполнения рутинных операций, я бы мог писать красивый код ...».

Подробнее о том, как им это удалось, можно прочитать здесь и ещё немного здесь.

В практической части обучения мы реализовали web-блог, на базе перечисленных по ссылке выше технологий.
Меня, как android-разработчика, заинтересовала возможность применения этих технологий и инструментов для организации Continuous Integration для Android.
Вдохновлённый докладом Алексея Коровянского на MBLTDev, и, особенно, результатами Google Test Automation Conference 2014 касательно тестирования Android-приложений, я реализовал упрощенный аналог нашего учебного проекта под другую платформу, перенеся туда всё что смог и успел. На этом предисловие заканчивается и начинается собственно описание автоматизации.

Когда меня развернули на 180 градусов в аэропорту перед полётом в Грецию, я начал звонить в сервисы по билетам и отелю. AWAD, фактически, положил на меня как на клиента – «посмотрите на сайте», «войдите в личный кабинет» и так далее. С другой стороны, Букинг внимательно выслушал, в прямом эфире набрал отель и чётко перенёс моё бронирование, пока я шёл к аэроэкспрессу. Хотя в правилах отеля если что не так – постоялец идёт на хрен. Так я оценил разницу в сервисе.

Но я не про это. Дело в том, что Букинг предложил мне контракт на проверку адекватности перевода их сайта на русский. Сразу покажу, с чего началось:



А вот чем продолжилось:



А теперь расскажу и покажу, что и как с текстами интерфейсов.