Маленький рассказ о том, как наша команда решила организовать иконки в грядущем проекте. Чуть-чуть исторического экскурса, взгляды по сторонам (на PNG и векторные шрифты) и рассказ о том, как мы всё-таки обустроились в итоге.

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

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

• хочется вектора. Ну, ладно, вектор – это средство, а не цель. Цель – не беспокоиться ВООБЩЕ об изменении размеров, ретина дисплеях, сохранении изображения в разных форматах для разных целей.
• хочется стилизации иконок. Потому что у нас из коробки как минимум два набора тем (светлая и тёмная), а то и контрастная, для людей с нестандартным зрением, а то и оранжевенькая какая-нибудь появится ближе к Новому году… В общем – одна и та же по сути иконка должна выглядеть слегка иначе в зависимости от выбранной на странице темы.
• хочется динамической стилизации иконок. Статики – нам мало. Этого хватает для скриншотиков и рекламных буклетиков, но не для живых пользователей. А мы хотели жизни! Мы хотели ховера! Мы хотели селекшена!!! И дизаблить, дизаблить их всех!.. Извините.
• НЕ хочется, чтобы в этом участвовал JavaScript в любой его форме и проявлении. Иконки – это внешний вид, а за него ответственный HTML + CSS. Ну, ладно, класс selected я готов навесить на элементы, но это последняя граница…

Есть и факторы, облегчающие задачу. Иконки сейчас (2015, осень, начинает снежить) в моде плоские, строгие. Если лет пять назад иконки пестрели, то сейчас это ушло под влиянием МС, Эппла, Материал Дизайна…

tl;dr Внимание. Следующие несколько разделов – это расплывание мыcлею по древу, причём вширь, обзор решений (в том числе – неудачных) и котик в разных ракурсах.
Кому хочется технических подробностей того, что же вышло в итоге – пожалуйте сюда.

Java недавно стукнуло 20 лет. Казалось бы, на сегодняшний день на java написано все. Любая идея, любой проект, любой инструмент на java? — это уже есть. Тем более когда речь идет о таких банальных вещах как пул соединений к базе данных, который используют миллионы разработчиков по всему миру. Но не тут то было! Встречайте — проект HikariCP — самый быстрый на сегодняшний день пул соединений на java.

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

Этот пост — вольный и частичный перевод статьи Down the Rabbit Hole от автора HikariCP перемешанный с потоком моего сознания.

Сегодня мы продолжаем цикл статей о сборщиках мусора, поставляемых с виртуальной машиной Oracle Java HotSpot VM. Мы уже изучили немного теории и рассмотрели, каким образом с кучей расправляются два базовых сборщика — Serial GC и Parallel GC. А в этой статье речь пойдет о сборщиках CMS GC и G1 GC, первостепенной задачей которых является минимизация пауз при наведении порядка в памяти приложений, оперирующих средними и большими объемами данных, то есть по большей части в памяти серверных приложений.

Два этих сборщика объединяют общим названием «mostly concurrent collectors», то есть «по большей части конкурентные сборщики». Это связано с тем, что часть своей работы они выполняют параллельно с основными потоками приложения, то есть в какие-то моменты конкурируют с ними за ресурсы процессора. Конечно, это не проходит бесследно, и в итоге они разменивают улучшение в части пауз на ухудшение в части пропускной способности. Хотя делают это по-разному. Давайте посмотрим, как.

Как ни странно, чтобы понять рекурсию, в PostgreSQL не надо понимать рекурсию. Потому что WITH RECURSIVE, который присутствует в посгресе (и в других серьёзных базах) — это скорее вычисление чего-то итерациями до того, как будет выполнено некоторое условие.
Тем не менее это очень полезный функционал базы, который можно использовать, например, чтобы вывести все подкатегории заданной категории, если таблица задана в виде (id, parent_id, ...)

Многие боятся переходить с «мускуля» на «посгрес» из-за того, что лишь смутно понимают, что это даст. Некоторых останавливает мысль, что наверно Postgres — это слишком сложная база и требует обучения. А также, что возможно чего-то придется лишиться в связи с переходом. Попробую немного прояснить ситуацию.

Предположим, у вас есть prod и test базы данных. В какой-то момент разработчик внес изменения в тестовую базу, но забыл внести эти изменения в боевую базу. Если это часто используемая таблица, то ситуация очень быстро становится очевидной, так как в логах появятся ошибки в SQL-запросах и вам начинает звонить начальник с упреками «какого @#$%».

Но иногда изменения затрагивают редко используемые таблицы, либо изменения на первый взгляд не совсем очевидны (например, кто-то изменил длину поля VARCHAR и у вас стали обрезаться строки, или кто-то добавил индекс, из-за которого запросы на тестовой базе выполняются на порядок быстрее).

Еще вариант — вы провели обновление ПО и у вас все перестало работать. Куча непонятных ошибок на пустом месте, приложение лежит, пользователи не довольны.

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

Что это и зачем оно надо: Как известно, главное преимущество Java мира в том в нем существует огромное количество open-source проектов на на все случаи жизни, однако найти нужный на github'e не так просто, так как описание проекта часто мало информативно, зачастую сложно даже понять этот проект для Android'a или нет. В этой статье я автоматически и полуавтоматически собрал Java проекты, убрал старые и проекты только для Android'a, выбрал 350 набравших больше всего звезд, разделил по категориям и перевел описания.

Если вы хотите убедиться что базы данных пишут не только на C, найти проекты для работы с большими данными или нейронными сетями, пишите свой язык программирования для JVM и хотите посмотреть как это уже сделано или же просто хотите узнать какие новые возможности можно найти в Java мире open-source то это статья вам, думаю, может пригодится.


Другие статьи серии: часть 1. JPA и Hibernate в вопросах и ответах

Update: Внимание, актуальная версия со много большим количеством ссылок, находиться теперь в моем github'e проекте useful-java-links, по этой ссылке.

Привет, Мегамозг, сегодня у нас необычный видео-пост. Мы ранее уже писали про запуск нашего бесплатного образовательного спецпроекта UMI для студий и агентств, а также выкладывали два текстовых эпизода (про разработку КП на создание сайта и важные KPI), которые получили хорошие оценки от хабра-сообщества.

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

1. Презентация агентства потенциальному заказчику. Игровой эпизод с Сергеем Прокофьевым, Creative People.

Все хорошее когда-нибудь заканчивается. Сегодня последний день нашего корпоративного блога на Хабре. Решили переехать на свой отдельный блог (осторожно, там может всплыть окно — ненавязчивое, но тем не менее!).

Честно говоря, не знаем, принято ли писать прощальные посты в корпоративных блогах Хабра, но решили написать. Просто хотим сказать СПАСИБО Хабру и всем, кто его читает. Отдельное спасибо поклонникам блога — у нас сложилось прямо небольшое сообщество. 2,300 человек — это сила!

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

Немного статистики, чтобы подвести черту под этим большим куском нашей жизни (метрики выбраны из интереса):

• Опубликовано статей: 81
• Общее количество просмотров: 2,598,237
• Рейтинг статей: 76 позитивных, 5 негативных, 1 была пристрелена )
• Суммарный рейтинг статей: 2,134
• Средний рейтинг статей: +26
• Максимальный рейтинг статьи: +177

Метрики никогда не были самоцелью, но сейчас смотришь — вроде и неплохо мы с вами поработали, а? Под катом:

• 12 самых популярных статей блога Стратоплана, суммарно набравшие более 1,000,000 просмотров
• Причины ухода и где нас можно найти

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

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

Добро пожаловать в серию «ES6 в деталях»! В этой еженедельной серии статей мы будем изучать ECMAScript 6 — новую готовящуюся к выходу спецификацию языка JavaScript. ES6 имеет множество новых возможностей, которые делают JS мощнее и выразительнее, и каждую неделю мы будем рассматривать эти возможности. Но прежде чем мы приступим, неплохо бы поговорить о том, чем является ES6 и что от него ожидать.

Добрый день.

Я занимаюсь IT-преподаванием. Читал Java Core (материалы тут).
Сейчас написал и продаю курс «Scala for Java Developers»

В этом посте решил открыть видео двух курсов (проходивших в режиме вебинаров) по многопоточности под JVM (это 16 + 16 двухчасовых лекций).

Больше о материалах (программа, полезные ссылки) можно прочитать в постах-объявлениях о вебинарах (Программа курса «Multicore programming in Java» (25 марта 2014), Программа и материалы курса «Multicore programming in Java» (31 июля)).

Курс рассчитан на слушателей, которые начинают изучать многопоточность с нуля (после крепкого курса Java Core, Middle Developer из чистого web-а или перешедшим из скриптовых/интерпретируемых языков программирования). Он не будет подходить тем, кто перешел из «суровых» С/С++ или ищет «академической высоты».

Детально рассматриваются темы Hardware, New Java memory Model, java.util.concurrent (atomics, blocking queues, thread pool, locks, synchronizers), message passing alternative, software transactional memory alternative, Java 7 Fork/Join, Java 8 Parallel Streams (+Lambdas, +Stream API), CSP/JCSP alternative

Небольшое резюме: статья про успешное внедрение Zabbix с автоматизацией большинства процессов, не претендует на tutorial, но если нужны будут подробности, то могу предоставить.

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

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

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

Многие разговоры про бэкапы начинаются с присказки что люди делятся на две категории… так вот я отношусь к тем людям которые делают бэкапы. Правильно настроенное резервное копирование и проверка резервных копий укрепляет сон. А наличие заранее написаных и проигранных инструкций по восстановлению вообще укрепляет пищеварение и иммунитет. Так вот, за время работы с PostgreSQL мне довелось часто настраивать резервное копирование, при этом условия и требования были самые разные. Однако при этом набор инструментов за редким исключением оставался неизменным. В этой статье поделюсь своим опытом в деле, как можно брать резервные копии PostgreSQL.

По правилам современного фронтенда отдавать пользователю надо минимум файлов с минимальным весом. Но во время разработки писать все в один файл, ещё и в сжатом виде, очень неудобно, поэтому для решения этой задачи используют разные сборки в виде готовых yeoman.io, generator-yeogurt и т.п. Или собирают сами с использование Grunt, Gulp и т.п. Но речь не об этом, речь об отладке javascript-а в этих сборках.

Возможно, в маленьких проектах в этом нет необходимости, но в крупных без этого никуда, особенно если вы используете MVC фреймворк и/или кучу самописного кода.

На Хабре уже есть хорошая статья на тему отладки js с помощью map файла в хроме — «Введение в Javascript Source Maps». Но если вы работает в среде разработки, особенно если эта среда от JetBrains, то лезть в хром как-то неправильно (хотя, конечно, это очень холиварная тема). Поэтому я решил написать эту статью.

Итак, приступим.

Добрый день!
При unit-тестировании часто сталкиваешься с необходимостью заполнять сложные объекты, чтобы возвращать их со стороны заглушек или наоборот — давать их на вход методам и тестам. Некоторые разработчики игнорируют get-set конвенции Java, а даже если геттеры и сеттеры есть, то заполнение объекта достаточно сложной структуры порой требует больше кода, чем сам тест. Это анти-паттерн Excessive Setup, и хочется научиться с ним бороться. В этой статье я расскажу, как с помощью библиотеки PODAM заполнять объекты быстро и красиво, продолжая идеи разумной рандомизации как входных данных для тестов, так и данных, возвращаемых заглушками — покажу на примерах, пороюсь в исходниках.
Итак, чтобы долго не думать, но и не заниматься миром животных, сгенерим страну.

Устройство для снимка экрана на первых компьютерах (Command-Shift-3)

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

Ведь кажется, что скриншот — это “секунда работы, Alt+PrintScreen и Ctrl+V!”. Некоторые клиенты удивляются, когда слышат, что скриншот в мануале может стоить и $2 и даже $5.

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

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

Начнём со «Справочника по инженерной психологии» Вудсона и Коновера.

«Справочник по инженерной психологии» — Вудсон, Коновер

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

Всем привет, и ещё раз всех с прошедшими праздниками. Трудовые будни набирают обороты и вместе с ними растёт информационный голод мучающий нас. Мир разработки переднего конца не дремлет и готовит нам много сюрпризов в наступившем году, и уж поверьте мне, скучно не будет ни кому. Одна из новых особенностей которые нам готовят разработчики браузеров совместно с группами разработчиков пишущих спецификации — JavaScript Promises(далее в переводе — Обещания, прошу сильно не бить) — полюбившийся многим шаблон написания асинхронного кода обзаводится нативной поддержкой. Что же такое обещания и с чем их едят можно прочесть в нижеследующем переводе(слегка вольном) замечательной статьи Джейка Арчибальда.