Добрый день! Меня зовут Антон Щастный.

Это моя очередная статья, посвящённая разработке веб приложений на Java. Хочу предложить вам сделать небольшую систему учёта клиентов, написанную с использованием фреймворка Spring и библиотеки Hibernate.

Что будет в приложении:

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

Что будем использовать:

• веб фреймворк Spring MVC,
• фреймворк Spring Security,
• ORM библиотеку Hibernate,
• MySQL в качестве СУБД.

Инфраструктура:

• редактор SpringSource Tool Suite,
• сборщик проектов Maven,
• система логгирования Log4j,
• постоянное подключение к интернету.

В моей предыдущей статье о Spring MVC был упущен ряд моментов по использованию аннотаций в Java-коде и применению Maven для сборки проекта. В данной статье я попытался исправить упущение.

Цель статьи – показать начинающим веб разработчикам совместное использование различных технологий платформы Java.

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

Что же такое MVP и чем он так хорошо? Ответ на этот вопрос ниже, а начнем с того, что многие из нас сталкиваются с такой дилеммой: «Есть отличная идея, но надо много времени и средств для реализации». Возможно, пару дней эта идея не покидает ваш разум, но потом вы понимаете своё бессилие, и на этом все заканчивается. А все могло быть по-другому…

Долгое время использовал в своих проектах, различные готовые JavaScript-календари для ввода дат, в частности Dynarch jsCalendar, и они полностью устраивали. Но в ходе разработки одного проекта, связанного с автострахованием, возникла необходимость довольно частого ввода дат из прошлого (дни рождения, дата выдачи паспорта и водительских прав, пенсионного и т.п.). Оказалось, что использовать календари в таких случаях не так уж и удобно, так как приходится отматывать несколько десятков лет назад и для этого приходится делать много действий мышкой.

Сегодня деление на американский и британский варианты английского языка во многом можно считать условным. Американизмы могут активно использоваться в речи британцев и впоследствии укорениться в британской речи, так что иногда при редактировании очередной статьи в словаре ABBYY Lingvo приходится отказываться от пометы «амер.» (американский вариант английского языка) или ограничиваться компромиссным «преим. амер.» (используется преимущественно в американском варианте английского языка). Например, не так давно пользователь на форуме Lingvo упрекнул нас в том, что мы до сих пор считаем слово awesome (в его известном значении) американизмом, хотя это давно не так. Возразить нечего, пользователь прав. Региональные границы стираются, модные американские словечки становятся атрибутом речи британской молодежи и т.д.

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

То, что британцы именуют reception, американцы назовут front desk (стойка администрации — в гостинице, например).

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

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

Выглядело это примерно так:



html

<div class="large_button"><br>  <span class="buttons submit_v2-button clickable"><br>    <i class="left left2"></i><br>    <i class="body"><br>      <b>В архив</b><br>      <i class="end"><br>        <i></i><br>      </i><br>    </i><br>  </span><br></div>

Видно, что запутаться в таком коде проще простого, тем паче, что вариантов кнопок на проекте накопилось не менее 30. Попытка создать такую кнопку на серверной стороне вызывала негодование у коллег «пехапистов».

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

Если вы запускаете новый сайт и заканчиваете его оформление, то есть смысл посмотреть коллекцию Subtle Patterns: отлично оформленную коллекцию фоновых текстур (паттернов) под лицензией Creative Commons Attribution 3.0 Unported. Их можно использовать без ограничений.

Сайт привлекает удобным предварительным просмотром: каждую текстуру можно мгновенно применить на всей странице в качестве фона. Сейчас там 93 работы, коллекция еженедельно пополняется отличными новинками.

Все текстуры на сайте Subtle Patterns являются повторяющимися, то есть склеиваются в бесшовную заливку.

О чем эта статья?

Эта статья о том:

1. Что такое релиз?
2. Как нумеруются релизы?
3. Зачем при релизе нужен бранч?
4. Почему релиз это больше, чем просто jar (war, ear, zip, etc)?
5. Что такое maven-release-plugin?
6. Делаем бранч c помощью release:branch.
7. Подготовка к релизу с помощью release:prepare.
8. Выпускаем релиз с помощью release:perform.

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

Вчера пол дня потратил на подробное изучение LESS и его отличие от используемых нами SASS/SCSS.

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

Рекомендация первая: забудьте про блочную верстку. Весь лэйаут должен быть на таблицах. При этом, без крайней необходимости — их тоже лучше не использовать. Также следует выкинуть из головы представления о семантике, сокращенных css-правилах, валидации, плавающих блоках — и прочее. Самый распространенный в РФ почтовый сервис на данный момент (mail.ru) вообще не понимает стили (css). Любые тэги/атрибуты style заменяются на xstyle и не работают. Вообще все.

Так что, фактически, при вёрстке html для почтовой рассылки надо мысленно переместиться в 90-ые годы прошлого века и смело использовать все распространенные приёмы того времени.

Для тех, кто с ними не знаком (как я был) — напомню:

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

Второй камень — «Якоря»

Если рассылка большого объема на несколько страниц, появляется необходимость навигации внутри рассылки. Как известно, для такой навигации на html-странице используются «якоря».

Вступление

Встречалась ли вам ситуация, когда необходимо реализовать хранение древовидной структуры в реляционной БД?



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

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

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

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

При реализации одного из проектов на Yii framework у меня возникла задача сделать регистрацию и авторизацию пользователей через сторонние сервисы (Google, Facebook, Twitter, etc).

У данной задачи есть два пути решения:

• Использовать сервис авторизации, например Loginza;
• Реализовывать функции авторизации самостоятельно для каждого сервиса.

UPDATE: Актуальная версия и инструкция по настройке доступны на github.com. Инструкция в данной статье подходит для EAuth версии <= 1.1.3.

Уверен, каждый из читателей, знает что такое шаблон проектирования “Singleton”, но не каждый знает как его программировать эффективно и правильно. Данная статья является попыткой агрегирования существующих знаний по этому вопросу.

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

Всем привет!

В этой статье я расскажу, как с помощью Google Analytics отслеживать лайки на вашем сайте и покажу, как это делать с кнопкой “Мне нравится” из Вконтакте.

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

Вступление окончено, переходим к советам!

Каждый сайт должен иметь favicon. Если вы до сих пор не сделали значок для вашего сайта — сделайте, теперь это еще проще!
Faviconist — новый favicon генератор от Michael Mahemoff.

Вам больше не нужен Photoshop для создания простого значка. Как Mahemoff пишет в своем блоге: Faviconist для 95% людей, которых устроит микро-дизайн их иконки, остальным все равно придется прибегнуть к Photoshop.

Вы — ProductOwner и отвечаете за группу веб-проектов. Когда сайты висят, недоступны или Клиентам выводится отладочная информация типа «Exception in object COrderController constructor… » — вам начинают звонить на мобильный, писать в твиттер и т.п.:

• топ-менеджер (или генеральный)
• коллеги, некоторые злорадствуя
• наши уважаемые Клиенты

Еще веселее, когда вас дергают… вечером за ужином, в иное время во время исполнения супружеских обязанностей, в отпуске :-)
Разберем популярные кейсы, ключевые принципы обеспечения доступности веб-проектов и попытаемся выстроить чеклист «Безмятежного отпуска».

В прошлой части мы рассматривали авторизацию через вконтакте, сегодня остановимся на mail.ru и использовании аватарок из обоих социальных сетей.
Для начала как всегда нам необходимо зарегистрировать в социальной сети свое приложение (у майла четкое разделение между приложениями и сайтами, но я по привычке буду говорить «приложение»). Кстати в процессе регистрации вы увидите от трех до пяти js ошибок, когда-нибудь mail.ru их исправит. После регистрации вам доступны ID приложения, приватный ключ (ничего приватного, используется для js-api вызовов, виден всем) и секретный ключ (используется для сервер-сервер взаимодействия, не говорите никому и не забывайте в комментариях).