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

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

Начиная упражнения с серией микроконтроллеров msp430 сразу обратил внимание на мизерные потребления энергии в дежурных (low power mode) режимах. Всегда хотелось собрать максимально автономный радиотермометр, чтобы прибить его гвоздями к дереву напротив дома и максимально уменьшить влияние выходящего из дома тепла на точность показаний. Радиотермометр на батарейках, даже если их хватает на годы — тоже не особо гуд, лазить на дерево с целю замены батарейки не всегда здорово, особенно в плохую погоду. Решил попробовать схему питания от солнечных батарей.

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

RFID
Конечно же я начал с поиска в гугле и без особых усилий нашёл название данной — RFID (Radio Frequency IDentification) или в переводе на русский Радиочастотная Идентификация. Прочитав статью на википедии, я понял что метки (карты) делятся на 3 диапазона работы, Метки диапазона LF (125—134 кГц), Метки диапазона HF (13,56 МГц), Метки диапазона UHF (860—960 МГц). В общественном транспорте используются метки второго диапазона — HF.

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

Прочитав статью
«Простой релиз-менеджмент средствами Git»
захотелось поделиться парой своих мыслей по поводу релиз-менеджмента maven проектов.

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

В кратце: главная проблема релиз-менеджмента maven проектов — это сам maven, который, не был разработан с учетом требований CI (Continuous Integration) подхода к разработке ПО.
Парадигма SNAPSHOT версий устарела с тех пор, как CI стало стандартным подходом к разработке ПО.

Более подробно далее.

Добрый день всем хаброжителям!

Поводом к написанию статьи послужило, то что к моему большому удивлению на хабре я не нашёл статьи о реализации RESTful Web Service на Java, может, конечно, плохо искал. Да написано про RESTful web services очень много, но как то вот так, чтобы простенько с примерами кода, рабочий сервис, не так уж и легко найти и не только на хабре…

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

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

По моему первому впечатлению: действительно вещь очень удобная, а главное очень простая, ещё и если использовать JSON, а не XML, ну по крайней мере мне так показалось после опыта работы с SOAP и WSDL. Ну, да об этом я думаю и так все знают, кто хоть немного работал с веб сервисами.

Так что, кто заинтересовался реализацией, прошу под кат

Всем привет! Думаю у каждого, кто когда-либо настраивал Jenkins для работы с Git-ом возникала проблема генерации ключей на Node-ах.

В очередной раз когда мне этим пришлось заняться я оказался в нелёгкой ситуации — ssh доступа к серверу с Jenkins-ом и к его слейвам у меня не было и, соответственно, ключи я сгенерировать не мог. Но всё оказалось не так плохо.

Всё началось с того, что я в очередной раз ковырял в Eclipse Memory Analyzer дамп памяти Java-приложения и увидел такую интересную вещь:

С кодом HashMap я знаком весьма неплохо, но вложенного класса FrontCache никогда там не видел. Может, с последним обновлением JDK мне прислали обновлённый HashMap? Я заглянул в исходники, но слова «front» там не обнаружилось. Стало интересно, откуда же этот класс берётся и что он делает.

Часто, в разных местах, требуется освещение типа «лишь бы не полная тьма». Например, лестничная клетка многоквартирного дома, где иголки на полу искать не требуется, а достаточно лишь минимального света, чтобы не оступиться или иметь возможность попасть ключом в замочную скважину. Обычно, в таких случаях, вкручивается либо 20-40 ваттная «лампочка Ильича» или «экономичная» на 7-9Ватт. Лампа накаливания имеет свойство часто перегорать, а «экономички», просто, банально крадут (у меня с лестничной клетки, за 3 года, стырили штук пять, мною вкрученных — мелочь, но неприятно). Если вам нужен экономичный и защищенный от воровства (ну, скажем так, более защищенный, чем просто лампочка) источник света, то читайте дальше.

В связи со сменой Hostkey основного ЦОД со Стордаты на Мегафон и переноса основной площадки вирутуализации и перехода на Server 2012 для Windows нам пришлось делать новый высокопроизводительный файлер для выдачи iSCSI/NFS/SMB таргетов на кластеры и нашим клиентам для организации частных облаков/кластеров. Мы выбрали и внедрили NexentaStor и вот что из этого вышло и как мы это делали

(Сокращённый перевод статьи Пьера-Хьюза Шарбонне)

Как уже сообщалось ранее на Java One, в Java 8 версии HotSpot планируется отказаться от PermGen пространства в пользу новой его вариации — Metaspace. Ранний доступ к JDK 8 даёт возможность наблюдать Metaspace в действии, чем и воспользовался автор оригинальной статьи чтоб узнать, какие преимущества даёт MetaSpace в сравнении с PermGen, и убедится во всём непосредственно.

Подробнорсти под катом.

Если вы часто используете maven, то наверняка сталкивались с ситуацией когда какого-нибудь нужного артефакта не оказывается в maven central. Конечно всегда можно установить недостающий джарник в ваш локальный репозиторий ~/.m2, но это отрицательно сказывается на переносимости билда, ведь на машине коллеги, у которого данный jar не установлен, билд уже не соберется.

Так же есть возможность использовать в качестве зависимости локальный файл не из репозитория, но для этого в проекте его опять же необходимо где-то хранить, а пушить либы в source control не очень хорошо.

Но существет еще один вариант. Вы можите использовать один из своих репозиториев на Google Code или GitHub в качестве хранилища maven артефактов. Рассмотрим как это можно сделать

Думаю, почти каждый сталкивался с таким мнением: писать тесты сложно, все примеры написания тестов даны для простейших случаев, а в реальной жизни они не работают. У меня же за последние годы сложилось впечатление, что писать тесты — это очень просто, даже тривиально^*. Автор упомянутого выше комментария далее говорит, что неплохо было бы сделать пример сложного приложения и показать, как его тестировать. Попробую именно этим и заняться.

^*)Писать сами тесты — действительно элементарно. Создать инфраструктуру, позволяющую легко писать тесты — чуть сложнее.

В качестве введения

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

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

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

Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему Git серьёзно поломан, и почему всем следует вместо этого пользоваться Mercurial, до тех пор, пока разработчки Git его не починят. Ну ладно, я был не настолько груб, но близок к этому.

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

Ниже я нарисовал упрощёный граф истории репозитория Git с тремя созданными ветками: «master», «release» и «topic». До того, как энтузиасты Git начнут ругаться, что я исхитрился показать нереально плохой случай запутанности истории, позвольте мне заверить вас, что это на самом деле ещё упрощённый пример. У меня есть доступ к реальному репозиторию Git, где создано шесть рабочих веток релизов, около сорока рабочих тематических веток и несколько сотен ранее существовавших веток, которые уже удалены с центрального сервера.

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

Я отвечу на вопросы: Что тестируем? Кто этим занимается? Зачем это все происходит? Что у нас есть?
А затем расскажу как все работает: опишу круги тестирования — с первого по девятый.

Что?

Наш продукт — корпоративное web-приложение Service Desk, написано на java.

Кто?

Я — лид группы автоматизированного тестирования; программисты код которых тестируем; ручные тестировщики, рутину которых мы искореняем; менеджеры верящие, что если тесты прошли, то все не так уж и плохо.

Зачем?

Цель моей группы — уберечь продукт от регрессионной спирали смерти.
Задача группы — необнаружение дефектов максимумом интересных способов с минимальным количеством ручного труда.

Что у нас уже есть?

900 коротких и не очень сценариев использования приложения закодированых в тесты.
CI Jenkins на шести серверах, три СУБД, два семейства ОС и три браузера под которые пишем продукт.

Как это работает?

Это пятая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»
• «Исправляем ошибки»

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

Часть 5. Процесс слияния

Обеспечение слаженной работы нескольких людей над одним и тем же кодом — это важная функция системы контроля версий.

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

Это четвертая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»

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

Часть 4. Исправляем ошибки

Mercurial позволяет свободно экспериментировать. Представьте, что во время работы вы что-то не то сделали в редакторе, и случилось нечто ужасное: