Это первая часть статьи, посвященной такому языковому механизму Java 5+ как аннотации. Она имеет вводный характер и рассчитана на Junior разработчиков или тех, кто только приступает к изучению языка.

Я занимаюсь онлайн обучением Java и опубликую часть учебных материалов в рамках переработки курса Java Core.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

Мой метод обучения состоит в том, что я

1. строю усложняющуюся последовательность примеров
2. объясняю возможные варианты применения
3. объясняю логику двигавшую авторами (по мере возможности)
4. даю большое количество тестов (50-100) всесторонне проверяющее понимание и демонстрирующих различные комбинации
5. даю лабораторные для самостоятельной работы

Данная статье следует пунктам #1 (последовательность примеров) и #2(варианты применения).

Псевдоэлементы :before и :after позволяют добавлять содержимое (стили) до и после элемента, к которому были применены.

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

     Доброго времени суток, уважаемые читатели. В этом посте я хотел бы описать несколько примеров развертки mongoDB, отличия между ними, принципы их работы. Однако больше всего хотелось бы поделиться с вами практическом опытом шардирования mongoDB. Если бы этот пост имел план, он бы выглядел скорее всего так:

1. Вступление. Кратко о масштабировании
2. Некоторые примеры развертки mongoDB и их описание
3. Шардинг mongoDB

    Пункты 1 и 2 — теоретические, а номер 3 претендует на практическое руководство по поднятию кластера mongoDB и больше всего подойдет тем, кто столкнулся с этим в первый раз.

Это третья часть переведённых заметок «Good User Interface». Первые 16 частей уже ранее перевели наши коллеги из ADV на Хабре, а вторые 11 перевели мы.

Идея 28


Используйте варианты по-умолчанию, не заставляя людей выбирать

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

Читая ежедневную порцию постов из своей подборки Google Reader наткнулся на пост про ORM для MongoDB с манящим названием «Morphia». Ниже вы найдете компоновку материалов из его документации, претендующую на звание «очень краткий обзор».

1. Morphia очень просто использовать. Это легкий и быстрый фреймворк
2. Поддерживает как аннотированные POJO объекты, так и DAO подход
3. Вся конфигурация задается аннотациями, XML файлы не используются
4. Поддерживается интерфейс расширений (в настоящий момент во фреймворк встроены валидация (jsr330) и поддержка SLF4J для протоколирования
5. Отлично работает с Google Guice, Spring и другими DI фреймворками
6. Содержит большое количество точек расширения
7. Поддерживает GWT

С 13 марта 2014 года более чем 150 клиентов получили доступ к сервису Witget. За 2 недели использования сервиса витжеты были показаны суммарно 80 000 посетителей сайтов, где был установлен скрипт Witget.

О сервисе
Сервис Witget помогает владельцам интернет-ресурсов повысить конверсию на сайте, разместив на нем специальные инструменты – витжеты. Они представляют собой всплывающие окна, кнопки социальных сетей, топперы, флоры и др. Удобство Witget в том, что можно тонко настроить показ витжетов для определенных когорт посетителей сайта. Более того, для размещения витжетов на своем сайте не нужно владеть навыками дизайна или программирования, так как необходимые инструменты уже созданы в сервисе. Клиент может выбрать из сотен готовых шаблонов, произведя необходимые настройки в личном кабинете у нас на сайте.

Результаты
Первыми доступ к сервису получили те, кто с декабря 2013 года оставлял предзаявку на тестирование Witget. Большинство из них – маркетологи (46%) и владельцы небольших интернет-магазинов (53%) с посещаемостью в среднем до 1000 человек в сутки (цифра получена в ходе анкетирования).

История

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

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

И наконец, в один прекрасный день вы решили: “Сделаем это!”. И вот вы уже пытаетесь разобраться как реализовать бизнес-логику своего приложения, ту киллер-фичу, которая будет двигать продукт вперед. У вас есть идея как это сделать, и вы знаете, что способны на это. И вот вы говорите: “Готово! Работает!” У вас есть успешный прототип! Осталось только упаковать его в веб приложение.

“Окей, сделаем сайт,” говорите вы.

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

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

“Я перегружен”, говорите вы и чувствуете себя перегруженным. Энергия уже не та, что была в начале. Вы пытаетесь собраться с мыслями, но работы слишком много. Прототип медленно блекнет и умирает.

Это первая из двух статей, рассказывающая о тестировании с помощью gremlins.js и grunt-gremlins. Первая статья — перевод официальной документации gremlins.js. Вторая — опыт внедрения gremlins.js в реальный проект при помощи grunt-gremlins.

Gremlins.js это monkey testing библиотека написанная на JavaScript, для Node.js и браузеров. С ее помощью проверяется надежность веб-приложений под полчищем гремлинов.

Kate: What are they, Billy?
Billy Peltzer: They're gremlins, Kate, just like Mr. Futterman said.

С чего всё начиналось

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

Немного погодя, оказалось, что все компоненты стоят вместе как готовый принтер и настрой сильно упал (Ох уж эти московские перекупщики), но на помощь пришел Китай со своими сверхдешевыми электроникой и электромеханическими компонентами. В порыве радости был заказан комплект электроники RAMPS 1.4 (Как самый простой в использовании по отзывам), 5 шаговых двигателей типа nema 17 (момент удержания должен быть не меньше 1.5кг/см, но я взял аж 4кг/см), 2 метра приводного ремня размера t2.5 с двумя алюминиевыми шкивами по 20 зубьев, а так же нагревательную платформу (mk2a самая распространенная), так же нужно не забыть взять 12 линейных подшипников lm8uu. На всё я потратил чуть больше 13 тысяч рублей, что, согласитесь, несколько меньше, чем, даже, комплекты для самостоятельной сборки в магазинах.

Спустя 2 месяца ожидания

За эти месяцы я успел познакомиться на форуме с несколькими интересными людьми, один из которых любезно распечатал на своем Replicator2 детали для моего принтера (Я выбрал конструкцию Prusa Mendel i2 из-за её дешевизны и простоты сборки). Кстати говоря, точность изготовления деталей мало на что влияет и, в принципе, можно их делать хоть из ложек, я лично сделал часть деталей для рамы из толстой фанеры. Большой проблемой было найти направляющие валы, которые стоят от 600 рублей за метр (Каленые и прочные, т.е. избыточная прочность), но решение было найдено на рынке: обычные прутки из нержавейки диаметром 8мм отлично подошли (Нужно всего 3 метра, как и что резать, написано на Вики), так же 6 метров шпилек м8 и 6 подшипников 608 (Как в роликах и скейтбордах). В качестве блока питания можно использовать что угодно от 400Вт 12-19В. Забрав с почты последнюю посылку (Не буду говорить про нашу почту, все и так всё знают. Битые и мятые коробки, ожидание, потерянные извещения), я понял, что предстоит много работы.

Вот и состоялся релиз Java 8. Кто-то по-настоящему ждал её и тестировал предрелизную версию, считая недели до марта, для кого-то смена цифры в версии JDK была лишь поводом пару раз поиграть с обновленным языком в домашней IDE без отрыва от работы (ввод языка в production всегда занимает некоторое время), кто-то просто не нуждается в новых фичах, им и возможностей «семерки» хватает с лихвой. Тем не менее, восьмую Java ждать стоило — и не просто ждать, но и внимательно присмотреться к некоторым ее нововведениям, ведь в этой версии их действительно немало, и если ознакомиться с ними поближе, то не исключено, что хорошо знакомый язык предстанет перед вами в совершенно новом свете, порадовав возможностью писать еще более красивый и лаконичный код. И если уж говорить про новые возможности Java 8, было бы странно не начать с лямбда-выражений.

Java еще не умерла — и люди начинают это понимать.

Добро пожаловать в ведение по Java 8. Этот материал шаг за шагом познакомит вас со всеми новыми фичами языка. Вы научитесь использовать методы интерфейсов по умолчанию (default interface methods), лямбда-выражения (lambda expressions), ссылки на методы (method references) и повторяемые аннотации (repeatable annotations). Все это будет сопровождаться короткими и простыми примерами кода. В конце статьи вы познакомитесь с наиболее свежими изменениями в API, касающихся потоков, функциональных интерфейсов, расширений для ассоциативных массивов, а также с изменениями в API работы с датами.

Возможно, вам уже попадался на глаза этот приём. Это поле ввода, которое выглядит так, как будто в нем есть текстовая подсказка (placeholder), но при начале набора текста она не исчезает, а отодвигается в сторону. Мне нравится эта идея. Брэд Фрост написал очень хорошую статью об этом приёме, подробно рассмотрев все «за» и «против».

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

Вот так выглядит форма на nest.com:

Я стал замечать, что в последнее время build-системам стали уделять всё больше внимания, и, под влиянием этого, их в одночасье стало настолько много, что, честно говоря, уже всех и не упомнить. Последнее время у меня на слуху четыре системы: Grunt, Gulp, Brunch и Gear. Про все что-то где-то было написано, но ни разу не ставился вопрос о том, какие преимущества или недостатки они имеют друг перед другом? И именно поэтому я решил провести сравнительный анализ самых популярных build-систем(по версии google).

Но сперва надо определиться с критериями, по которым мы будем оценивать эти системы:

• Начало работы.
• Производительность. Никто не хочет ждать по минуте после изменения одного coffee-файла.
• Документация. Чем нагляднее и проще — тем лучше.
• Плагины. Ведь мы не хотим столкнуться с проблемой, когда мы начали использовать билд-систему, а в ней нет адаптера, скажем, для jasmine?

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

INTRO

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

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

Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.

Данным постом мы открываем рубрику «Переводы» в нашем блоге. Почему мы решили открыть такую рубрику? Дело в том, что сотни специалистов, работающих в Mail.Ru Group, для решения стоящих перед ними задач ежедневно прочитывают множество интересных статей и постов на форумах. Некоторые из них кажутся нам интересными, и мы считаем своим долгом перевести их на русский и поделиться этими ценными знаниями с Хабражителями.

Пользуясь случаем, хотим сообщить новость: сегодня состоялось открытие Технопарка — нашего образовательного проекта, о котором мы уже не раз писали на Хабре (например, тут, тут и тут). Теперь у технопарковцев есть свое собственное помещение. Изначально Технопарк задуман как место, где талантливые студенты МГТУ им. Баумана могут получить дополнительное образование в сфере веб-разработки, дизайна и программирования, а также окунуться в работу над реальными проектами высокой сложности. В общем, у Технопарка сегодня знаменательный день, и поэтому первый выпуск в рубрике «Переводы» мы решили посвятить образовательным ресурсам для веб-разработчиков и веб-дизайнеров. Ведь пока такие Технопарки не распространились по всей стране, разработчикам зачастую приходится заниматься исключительно самообразованием.

Первая часть про прототипы.



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

Здравствуй, дорогой хабрадруг! Сегодня существуют более тысячи способов создать кнопку; чтобы понять их сущность, вам нужно лишь потратить немного времени, просмотрев работы на сайте dribbble.com. Большинство из этих примеров очень похожи друг на друга, однако время от времени попадаются и такие кнопки, на создание которых потратили чуть больше внимания, времени и сил.



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

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

Доброго времени суток, хабражители!

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

Это и натолкнуло меня на данное исследование — есть ли способ оптимизировать процесс логирования?

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

Осторожно, под катом трафик.