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

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

Очередные «попугаи»?! О, нет. Три реальных теста, три разных направления, различные устройства и интересные факты.

Данная статья в некотором роды выжимка того, что Вы могли бы узнать просмотрев разные видео ролики господина Шипилева, Елизарова, Смирнова. Собственно мы даже собрали для Вас плейлист если Вы захотите пойти «the hard way». В статье я лишь попробую Вам передать некоторые основные мысли/идеи, которые при желании Вы сможете намного более глубоко изучить в первоисточниках.

Итак, давайте теперь перейдем к собственно сабжу. Еще лет пять назад можно было не сильно «парясь» выдавать на-гора однопоточные программы, которые с трудом запускались на топовом железе и знать, что через год-два этот кусочек “программки” (простите за аллегорию) начнет работать нормально. Сегодня подобный «бесплатный обед» закончился.


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

Часто так бывает, что есть хорошая библиотека, а чего-то в ней не хватает, каких-нибудь перламутровых пуговиц. Так и мне с Activiti, довольно популярным движком бизнес-процесcов с поддержкой BPMN 2.0, ценным своей Java-нативностью. Не вдаваясь в подробности внутреннего устройства этого продукта с открытым исходным кодом, достаточно очевидно, что в своей работе он использует разнообразные данные: метаданные определений бизнес-процессов, данные экземпляров и исторические данные. Для их хранения Activiti использует СУБД, позволяя выбрать из DB2, H2, Oracle, MySQL, MS SQL и PostgreSQL. Этот движок весьма неплох, и используется не только для маленьких поделок. Возможно, вопрос о поддержке кэширования обращений к БД в этом продукте возник не только у меня. Как минимум единожды он задавался разработчикам, которые на него ответили в том смысле, что метаданные кэшируются, а для остальных данных большого смысла в этом нет и это не просто. В принципе, про отсутствие большого смысла согласиться можно — данные конкретного экземпляра или его исторические данные с небольшой вероятностью могут повторно понадобиться. Но сценарий, когда такое всё-таки случится, тоже возможен. Например, если у нас кластер серверов Activiti с общей базой. В общем, человек с пытливым умом вполне может захотеть иметь приличный кэш в Activiti. Например, использовать в этом качестве Apache Ignite.

Под катом пример решения этой проблемы, код выложен на GitHub.

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

В Dolphin 5.0 можно было хотя бы загрузить любую игру с GameCube. Кроме одной. Сложный способ использования блока управления памятью в PowerPC Star Wars: The Clone Wars до недавнего времени не позволял играть в неё через Dolphin. Но в версии Dolphin 5.0-540 эта проблема наконец решена: эмулятор научился загружать все игры GameCube из официальной библиотеки консоли.

День 00

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

День 01

В голове у меня вертелось несколько идей и самой простой из них, казалась игра-кликер, с набиванием чего-либо и покупкой разного за набитое что-либо. Идея есть, нужен движок. В оперативные сроки был найден замечательный своей простотой движок Clickteam Fusion 2.5 Developer, с которым я уже виделся на youtube и который позволял сразу же собрать игру для Android. Что ж, идея есть, движок есть. Прикинув палец к носу решил начинать.

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



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

Поэтому, во-первых, мы сейчас перезапустили сайт JUG.ru, чтобы исправить это. А во-вторых, раз русскоязычные регулярно обновляемые ресурсы в дефиците, вспомнили, какие есть англоязычные, и делимся результатами с Хабром. Разумеется, в текст вошло далеко не всё возможное, и будем только рады дополнениям в комментариях.

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

Добрый день!

В этой статье я рассмотрю unit/integration тестирование в GWT с использованием UI компонентов GWT и GXT и MVP (с Passive View) архитектуры для разделения логики и внешнего вида приложения.
GWT и GXT здесь выделены не случайно — Google разработал несколько framework'ов, которые облегчают поддержку паттерна MVP (точнее, более общее — разделение логики и представления) в GWT. Это Activity and Place для разделения логики приложения на модули, GWT Editor для автоматического мапинга POJO объектов на widget, UiBinding для декларативного описания интерфейса.
Всё это поддерживается ещё и UI framework'ом GXT. Т.ч. по сути не будет большой разницы в использовании UI компонентов GWT или GXT.

В результате получим легко тестируемое приложение без поднятия тяжёлого framework'а GWT.

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

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

Всех заинтересовавшихся прошу под кат.

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

На Хабре уже была публикация, посвященная нагрузочному тестированию АС, взаимодействующих по JMS при помощи JMeter. В ней описано применение JMeter как источника нагрузки, внешней системы, инициирующей бизнес-процесс в нашей (тестируемой) системе. Но что делать, если процесс инициируется внутри нашей системы, она отправляет запросы во внешнюю систему и ожидает ответа (то есть нам необходима заглушка внешней системы)?

Найти ответ на этот вопрос нам пришлось во время одного из проектов по нагрузочному тестированию.

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



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

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.

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



Статья не претендует на глубину и/или академичность. Это попытка систематизировать опыт и обратить внимание разработчиков на не очень очевидные аспекты.

От переводчика. Вот уже три года как я занимаюсь развитием интернет-сервиса безвозмездного дарения Дару-дар. И всё это время я пытаюсь понять, в чём суть нашего «бизнеса», нормально ли, что основой мотивации нашей деятельности является настойчивое желание воплотить нашу миссию, а не создать успешное коммерческое предприятие? Все вокруг говорят о бизнес-стартапах, раундах инвестирования, бизнес-стратегиях. А когда кому-то рассказываешь о том, как интернет может изменять общество, его традиции и культуру, не прибегая при этом к насилию, это ни у кого не находит отклика, тебя всё равно обязательно спрашивают «а где деньги?». В какой-то момент времени я узнал о том, что существует такое явление как «социальное предпринимательство». Этот мой перевод — одна из попыток разобраться, что это такое, как с этим жить и работать.

---

Автор публикации: Грегори Диз (J. Gregory Dees), директор Центра развития социального предпринимательства Дюкского Университета (США). Оригинальный текст написан 31 октября 1998, отредактирован 30 мая 2001

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

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

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

И вот совсем недавно появились явные признаки краха пирамиды (пока одной) – крупный известный купонный сервис просит признать себя банкротом.

Автор текста — Билл Марис, президент и управляющий партнер в Google Ventures

Я слышал, люди переживают, не оказались ли мы в случае со стартапами в пузыре. Он такой же плохой, как пузырь доткомов в 2000-м? Может ли он быть еще хуже старого? Я подумал, что нам стоит посмотреть на все доступные данные и понять, можем ли мы извлечь их них что-то большее, чем просто личное мнение. Так что я попросил наших специалистов в Google Ventures вникнуть в вопрос и узнать, что сообщают нам строгие данные. А этом тексте поделюсь с вами обнаруженным.

Пожалуй, каждое эссе Пола Грэма смело можно причислять к must read для it-шника. Особенно для стартапера или владельца собственного бизнеса. Мы в Alconost перевели новую заметку этого известного предпринимателя, инвестора, программиста и писателя.

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

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

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


Переведено в Alconost