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

История одного проекта.

Вам когда-нибудь снились верблюды? Вот и мне тоже нет. Но, когда работаешь с Camel-ом уже третий год, начинают сниться не только верблюды.
В общем, буду делиться опытом, писать о верблюдах и учить вас их готовить. Это серия статей в трёх частях: первая часть будет для тех, кому интересны истории и муки творчества; вторая — больше техническая, о паттернах интеграции, их применении и третья часть — об ошибках и отладке.
Если вам нужно объединить ваши сервисы, здесь вы узнаете, чем хорош Camel. Если вы хотите научиться использовать что-нибудь новенькое, здесь мы начнём с азов. Если вам нравятся истории и оригинальные фишки, которые есть в каждой команде, то читайте дальше.

Java приложения — значит в современном Java мире возможность встретить такое процентов на 90%, а то и больше (рассматриваем самые распространённые окружения, HotSpot based JVM версии от 1.6)
которое нельзя остановить — приложение работает, и перезапускать его по тем или иным причинам категорически нельзя
экзотика — нечто такое этакое, что не каждый день в голову взбредёт поймать (определённая последовательность вызова методов, диковинные комбинации значений параметров, ...)
доступными средствами — бесплатно, работоспособно, эффективно, легко, просто и т.д и т.п. В данной статье рассмотрен замечательный инструмент BTrace kenai.com/projects/btrace

И само собой в код Java приложения заранее ничего специально не добавлено касательно средств дебага…

Хотим поделиться с вами видео наших докладов с конференции Российские Интернет Технологии (РИТ) 2014. Вопросы к докладчикам можно писать в комментариях к посту.

«Биллинг в большом проекте».
Анатолий GremniX Панов, Badoo.




«Email-рассылки для профи- частые ошибки, что улучшать, как мониторить».
Андрей Une4ga Сас, Badoo.

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



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

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

Например, при использовании нового API все приложения, которым просто нужно хранить свои файлы в Диске, смогут получать доступ только к своей папке, лежащей в Диске пользователя в папке «Приложения». В WebDAV API сервису для этого придётся получать у пользователя разрешение на запись/чтение всего Диска, а не только конкретной папки.



В этом посте я хочу рассказывать не о структуре или об операциях, которые умеет выполнять наш API — там всё довольно очевидно — а сразу перейду к интересным вещам: что такое Hypermedia и Machine-readable and Self-describing API, и как мы все это реализовали.

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

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

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

Практически каждый разработчик, создающий информационные системы, сталкивается с необходимостью формирования различных отчетов и печатных форм. Это характерно и для большинства приложений разработанных на нашей платформе. Например, в системе, над которой я работаю в настоящее время, их 264. Для того чтобы не писать каждый раз логику формирования отчетов с нуля, мы разработали специальную библиотеку (под катом будет объяснено, почему нам не подошли существующие). Называется она YARG — Yet Another Report Generator.
YARG позволяет:

• Генерировать отчет в формате шаблона или конвертировать результат в PDF;
• Создавать шаблоны отчетов в привычных и распространенных форматах: DOC, ODT, XLS, DOCX,XLSX, HTML;
• Создавать сложные XLS и XLSX шаблоны: с вложенными областями данных, графиками, формулами и т.д.;
• Использовать в отчетах изображения и HTML-разметку;
• Хранить структуру отчетов в формате XML;
• Запускать standalone приложение для генерации отчетов, что делает возможным использование библиотеки вне Java-экосистемы (например для генерации отчетов в PHP);
• Интегрироваться с IoC-фреймворками (Spring, Guice).

Эта библиотека используется в платформе CUBA в качестве основы для движка отчетов. Мы развиваем ее с 2010 года, но совсем недавно решили сделать ее открытой, и выложили ее код на GitHub с лицензией Apache 2.0.
Данная статья призвана привлечь к ней внимание сообщества.

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

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

Использование SoftReference даёт возможность оставить поведение кеширования «на самотёк» — за пореблением памяти следит сама JVM, она же очищает старые элементы.

«Cluster» означает, что кеш самостоятельно отслеживает события инвалидации (устаревания, обновления) значений и следит за тем, чтобы на других серверах в кластере устаревшие элементы выкидывались из кеша. Есть и другие определения кластерного кеша. Например, основной режим работы JBoss Cache может даже «вытягивать» элементы с других узлов кластера, если их нет на текущей машине. Но для нашей системы, где скорость получения элемента с другой машины ненамного меньше скорости генерации элемента, достаточно инвалидации.

Read-Write означает, что мы не используем блокировку элементов кеша и вообще не думаем (почти) о том, что в нашей системе есть какие-то независимые транзакции. Для CMS это нормально, но, разумеется, для какого-нибудь enterprise application это было бы недопустимо.

О чем речь?

Кто занимался веб-разработкой на Java, наверняка сталкивался с такой проблемой как java.lang.OutOfMemoryError: PermGen space. Возникает она, как правило, после перезапуска веб-приложения внутри сервера без перезапуска самого сервера. Перезапуск веб-приложения без перезапуска сервера может понадобиться в процессе разработки, чтобы не ждать лишнее время запуска самого сервера. Если у вас задеплоено несколько веб-приложений, перезапуск всего сервера может быть гораздо дольше перезапуска одного веб-приложения. Или же весь сервер просто нельзя перезапускать, так как другие веб-приложения используются. Первое решение, которое приходит на ум – увеличить максимальный объем PermGen памяти, доступный JVM (сделать это можно опцией -XX:MaxPermSize), но это лишь отсрочит падение, после нескольких перезапусков вы снова получите OutOfMemoryError. Хорошо было бы иметь возможность сколько угодно раз перезапускать и передеплоивать веб-приложение на работающем сервере. О том, как побороть PermGen, и пойдет дальнейший разговор.

Простите, но накипело.
Много шишек уже набито на тему безопасности сайтов. Молодые специалисты, окончившие ВУЗы, хоть и умеют программировать, но в вопросе безопасности сайта наступают на одни и те же грабли.

Этот конспект-памятка о том, как добиться относительно высокой безопасности приложений в вебе, а также предостеречь новичков от банальных ошибок. Список составлялся без учета языка программирования, поэтому подходит для всех. А теперь позвольте, я немного побуду КО.


Итак, каким должен быть безопасный сайт?

Психология — интересная и иногда полезная наука. Многочисленные исследования показывают, что задержка в отображении веб-страницы дольше 300 мс заставляет пользователя отвлечься от веб-ресурса и задуматься: «что за хрень?». Поэтому УСКОРИВ веб-проект до психологически невоспринимаемых значений, можно ПРОСТО удерживать пользователей дольше. И именно поэтому бизнес готов тратиться на скорость: $80М — чтобы уменьшить latenсy всего на 1 мс.



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

Какое-то время назад Mail.Ru Group приняла решение о выходе на международный рынок. Чтобы обезопасить себя и свои наработки, мы решили запустить процесс патентования. Мониторинг интернет-среды в России показал, что у нас эта тема пребывает в состоянии, близком к зачаточному, и придется изобретать велосипед.

Не без пары фальстартов, но велосипед мы изобрели, и он поехал: мы подали первые заявки на патентование изобретений наших сотрудников в США. Нам в этом активно помогает Павел Погодин, который раньше занимался патентованием в Sun Microsystems и в Oracle. Не так давно Павел приезжал в наш офис и рассказывал о том, какие технологии патентуемы, как лучше всего подходить к вопросам патентования, как оформлять описание изобретений и что нужно сделать, чтобы патент прошел.

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

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

Метод 1. Фотографии пользователей с товаром

Кошка «из коробки» не умеет слезать с дерева. Подъём в хардкоде рефлексов, а спуска там нет. Он не жизненно необходим. И она не умеет спускаться — разумеется, пока не увидит, как другая кошка делает это. Стоит один раз понять принцип на примере, и она сможет повторить это сама. Зеркалирование поведения – одна из самых глубоких моделей обучения, поэтому просто грех ей не воспользоваться.

Совет – например, покажите ваш товар в естественной обстановке с теми людьми, которые им пользуются. Вот как это делаем мы:



За 5 лет работы у нас образовался достаточно большой архив фотографий настолок с играми. Мы их и использовали. Вы можете сделать практически то же самое. Да! Есть нюанс. Если ваши покупатели – дети, то никогда не ставьте фотографии с более младшими «пользователями»: гораздо лучше — постарше. Всё просто. Ребёнок хочет быть похожим на старших и совершенно не хочет – на «малышей».

Современный капитализм обусловил одни простой житейский «закон» — богатые становятся богаче, бедные — еще беднее. Так как больше денег -> больше возможностей заработать -> больше денег. Нам, работникам IT, немного повезло. Благодаря спросу на наш труд, который нам, чего уж скрывать, нравится, мы застряли где-то посередине — средств хватает на удовлетворение большего числа основных потребностей и еще остается небольшой излишек.

И вот тут многих начинает волновать вопрос — «что с ним делать?». Многие сделав вывод что «хранить нельзя» в решении вопроса идут дальше и задаются следующим вопросом: «во что инвестировать?». Возникает еще один попутный вопрос: «как обеспечить себе старость?».

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

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

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

Доводилось ли вам когда-либо исследовать шаг за шагом выполние некого Java кода, который не удосужились снабдить средствами логирования или прочими механизмами наблюдения?
Усложним задачу тем, что не будем перекомпилировать исследуемый код, да и вообще перезапускать существующий процесс (тот случай, когда непонятное поведение было да и при перестарте сплыло). Java машина, конечно же, запущена с самыми обыкновенными опциями (без параметров для аттача дебагера или ещё каких наворотов).
А так хочется понять, что же происходит.

Именно этим мы и займёмся.

Scope определяет жизненный цикл объекта. Например, java-бин (далее просто бин) определённый в RequestScope создается при получении http запроса и освобождается при завершении данного запроса. В JEE и в Spring есть возможность создавать свой собственный scope. Т.е. мы можем создавать объекты со своим собственным жизненным циклом — они будут создаваться по какому либо нашему событию и также уничтожаться. В JEE за это отвечает спецификация CDI (Context and Dependency Injection) и на самом деле там уже есть один подобный встроенный scope. Это ConversationScope. У нас есть API и аннотации для начала и окончания conversation. Если мы их не используем, то по-умолчанию ConversationScope ведет себя как RequestScope. Для отслеживания conversation каждого отдельного клиента используется специальный conversationId, который обычно добавляется как параметр http запроса. Но такой подход не работает для веб-сервисов. А в Spring вообще нет ничего подобного. Но в моей практике заказчик попросил сделать веб-сервис, который бы использовал одно и то же физическое соединение к внешней системе для нескольких последовательных вызовов. Также надо было хранить некоторое количество дополнительных данных. Т.е. надо было сохранять некое состояние (объект с соединением и данными) на определённый промежуток времени, такой аналог conversation scope для веб-сервиса. Можно, конечно, сохранить этот объект в Мар, где ключом будет наш аналог conversationId, а Мар положить в ServleContext и доставать это всё из методов веб-сервиса. Но это неудобно. Гораздо удобнее, когда сам сервер будет инжектить нам наш объект по заданному conversationId. Поэтому, сделаем свой scope, который будет работать с SOAP веб-сервисом. Сам по себе веб-сервис не может принадлежать какому-либо scope, но наш бин, который мы будем инжектить в веб-сервис, будет принадлежать нашему scope.

В этой статье я расскажу о создании самодокументируемого web сервиса (jax-ws), который использует элементы XSD Restrictions.

Эта тема была поднята в ходе нескольких (3+) собеседований который я прошёл за последние полтора месяца — в разных вариациях но примерно об одном. Казалось бы, известные вещи — но собрав все ответы и объяснения какие я давал (и кое-что что нашёл позже в гугле), решил сохранить их не у себя в гугл-драйве, а написать краткий обзор.

Речь шла о небольших и типовых приложениях Enterprise / Web на Java, каких пишется множество (ну такие, на 10-100 тысяч клиентов, миллион посещений и т.п.). Пусть это будет обобщённый диалог в виде вопросов и ответов.

 

В: Допустим, у вас есть приложение (самое обычное — JSP, Spring, Hibernate например) развернутое на томкате (Apache Tomcat) и вы однажды замечаете что сервер с томкатом загружен на 80% в среднем. Что делать?