Шла четвёртая неделя тяжёлых боёв с Play! Framework 2.1 + Java. Победа неумолимо приближалась, но до полной капитуляции было далеко.
После обнадёживающих новостей про развитие Play! 2.1, например в LinkedIn, было решено попробовать его в одном новом проекте. Испытать его, так сказать, в деле. Что из этого получилось? Я бы сказал, что это была небольшая война между мной и Play! 2.1. Почему? Подробности под катом, а для нетерпеливых:

Краткий вывод

Для штурма надо было брать секретное оружие под кодовым названием Scala. Если встать лицом к лицу с Play! Framework 2.1 и крикнуть со всей силы: «Ты есть Scala-фреймворк!», то он испугается такой прямоты и скромно откроет свои двери в мир больших возможностей.
«Не знаете Scala?» — «Используйте Play 1.2».
«Хорошо разбираетесь в Scala?» — «Обязательно попробуйте Play 2.1. Но всё равно запаситесь терпением».

Краткое содержание первой части

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

На прошедшем в начале марте этого года мероприятии Vault, организованным Linux Foundation в Бостоне, было много разговоров о файловых системах и хранилищах. Если думаете, что там не было сказано ничего нового, то вы ошибаетесь.

Знаете ли вы, как избежать дедлоков в своей программе? Да, этому учат, про это спрашивают на собеседованиях… И тем не менее, взаимные блокировки встречаются даже в популярных проектах серьёзных компаний вроде Google. А в Java есть особый класс дедлоков, связанный с инициализацией классов, простите за каламбур. Такие ошибки легко допустить, но трудно поймать, тем более, что сама виртуальная машина вводит программиста в заблуждение.

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

Идея этого топика родилась из этого комментария.

Итак имеем: класс без конструкторов, необходимо создать экземпляр этого класса. На Java такого сделать нельзя, так что придется напрямую манипулировать байткодом. Идея состоит в том, чтобы вызвать NEW, но при этом не вызывать <init>. Но тут есть трудность, спецификация JVM говорит что так делать нельзя,

Одной строкой: вчера Google закрыл петербургский и харьковский офис разработки купленного им год назад QuickOffice, более 100 разработчиков и тестировщиков ищут работу. Мои знакомые подтверждают, что так оно и есть — без предупреждений и без выплат разорваны все контракты.

www.ewdn.com/2013/05/16/google-shuts-down-quickoffice-rd-offices-in-russia-and-ukraine
roem.ru/2013/05/17/quickoffice71810
thenextweb.com/google/2013/05/16/google-shutters-quickoffice-rd-offices-in-russia-and-ukraine-affecting-more-than-100-people
twitter.com/DenZhadanov/status/334766595555590144
watcher.com.ua/2013/05/17/kompaniya-google-zvilnyla-60-ukrayinskyh-prohramistiv
rsdn.ru/forum/job/5169768.flat
vk.com/yshubin?w=wall88613_1210%2Fall
tea-cutter.livejournal.com/292021.html

Смысл действий Google остаётся для меня загадкой. Единственное предположение — вся операция была проведена для устранения конкурента Google Docs.

Корпорация добра, говорите?

В первом своем посте на данном ресурсе хотел бы описать простейший пример создания информера, с помощью колоссально удобной утилиты Automator, идущей в комплекте с Mac Os X.

Буквально на днях, при радикальном снижении уличной температуры в Москве у меня внезапно появилась задача: визуально отслеживать температуру в серверном помещении (а точнее в стойке), с определенным интервалом, т.к. кондиционер, обслуживающий помещение, отказался работать при T < -15 ºC.

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

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

Общий момент — те программы, которые обновляют курс валют автоматически, делают это с finance.yahoo.com.

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

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

У некоторых пользователей заработал магазин песен от Apple — iTunes Store.



Всех с этим поздравляю.

Доступный контент: Музыка, Фильмы.

В данной заметке хотел бы поделиться личным опытом непосредственного сравнения Microsoft Office под Windows и Mac; постараюсь обобщить большинство вопросов и нюансов, возникающих при обдумывании как индивидуального перехода, так и перевода организаций и групп.

Свой индивидуальный опыт я считаю достаточно репрезентативным в связи с тем, что являюсь профессиональным пользователем Microsoft Office с 1996 года. Я профессионально как автор, рецензент и редактор с 1996 года ежедневно (может быть, разве что за исключением дня свадьбы) вынужден находиться в Microsoft Office буквально круглосуточно. За день через меня проходят примерно 25-30 файлов Word и 15-20 файлов Powerpoint, содержащих любые возможные функции, т.е. достаточно больших и сложных (Word, как правило, не менее 200 страниц; Powerpoint, как правило, не менее 70 слайдов). За прошедшие 14 лет я попробовал все имевшиеся версии Microsoft Office на всех имевших место версиях Windows. Надеюсь, что обратившие на себя мое внимание особенности будут репрезентативны для более «мягких» сценариев. Хотелось внести некоторую ясность, т.к. с одной стороны сама Microsoft и большинство деловых пользователей в США утверждают о полной совместимости, в то время как в рунете в большинстве случаев можно услышать противоположное.

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

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

Итак, есть 2 основных варианта открытия валютного счета для получения денег из-за границы SWIFT-переводом: счет предприятия (ЧП, ООО, ОАО — без разницы) и счет физлица (частного лица).

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

Пара слов о себе: 1.5 года работаю java-программистом в городе Лимассоле (который расположен в греческой части острова), живу там же с семьей.

Привет, Хабр!

Я не сомневаюсь, что многие из нас вчера смотрели презентацию WWDC 2014 от Apple. Были представлены новая операционная система OS X Yosemite, а так же iOS 8. Но главное, чем наверное взбудоражило Apple программистов во всем мире, так это новым языком — Swift!

Swift является новым инновационным языком программирования для Cocoa and Cocoa Touch с еще более кратким и выразительным синтаксисом, с помощью которого приложения пишутся молниеносно. Это делает написание кода интерактивнее и веселее, и работает бок о бок с Objective-C. По словам Федериги, некоторые функции Swift работают быстрее, чем в других объектно-ориентированных языках: например, сортировка сложных объектов происходит в 3,9 раза быстрее, чем в Python, и почти в полтора раза быстрее, чем в Objective-C.

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

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

Ошибка #1 — Идея

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

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

Несколько лет делал заказные игрульки под iOS. В условиях, когда некогда точить, а нужно пилить, идешь в гугл и спрашиваешь. Гуглокодинг. Вот и свела судьба меня с Cocos2D for iPhone и теплым ламповым www.raywenderlich.com

Мне Objective-C понравился, как и сам cocos2D. Мягкий как пластилин. После приличных лет писанины на C++ все как-то упростилось. Увы, только iOS. Безусловно, появились всякие Apportable, однако я не хотел почему-то смотреть в ту сторону. К тому же чувствовалась усталость от одной и той же платформы и хотелось своего проекта, при том, чтобы игралось на каждой микроволновке. Unity вроде хорош, но закрыт, а для меня очень важно знать, как оно работает изнутри: оценить потенциальные боттлнеки, что-то оптимизировать (приходилось часто за практику), да даже просто баги пофиксить. Плюс, хотелось начать что-то делать прям сейчас. А поскольку с моделью айфоновского кокоса я был очень хорошо знаком, было принято решение взглянуть на cocos2D-X. Тот, что на C++.

Для чего Java-программисты прибегают к native методам? Иногда, чтобы воспользоваться сторонней DLL библиотекой. В других случаях, чтобы ускорить критичный алгоритм за счет оптимизированного кода на C или ассемблере. Например, для обработки потокового медиа, для сжатия, шифрования и т.п.

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

1. создание stack frame;
2. перекладывание аргументов в соответствии с ABI;
3. оборачивание ссылок в JNI хендлы (jobject);
4. передачу дополнительных аргументов JNIEnv* и jclass;
5. захват и освобождение монитора, если метод synchronized;
6. «ленивую» линковку нативной функции;
7. трассировку входа и выхода из метода;
8. перевод потока из состояния in_Java в in_native и обратно;
9. проверку необходимости safepoint;
10. обработку возможных исключений.

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

Да, и сегодня я расскажу о недокументированных возможностях HotSpot JVM для ускоренного вызова простых JNI методов. Хотя эта оптимизация появилась еще с первых версий Java 7, что удивительно, о ней еще никто нигде не писал.

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

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

Сегодня мы расскажем, как нам удалось построить свою платформу для сервиса видео на Одноклассниках на Java за 3 месяца.

Начнем с того, что представляет собой видеосервис на Одноклассниках. Он доступен как на вебе, так и в версиях для мобильных устройств. Одним из отличий Одноклассников от других соцсетей является наличие видеовитрины, где в разделах «ТОП недели», «Новинки» и каналах собраны видео. Для этих разделов видео отбирается автоматически по хитрому алгоритму на основании числа просмотров, классов и скорости роста популярности видео. И конечно, на витрине представлены каналы с контентом от партнеров:— сериалы, ТВ шоу, мультфильмы и кино.

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

Видеосервисом на Одноклассниках пользуется свыше 10 миллионов уникальных пользователей в день, которые смотрят свыше 70 миллионов видеороликов и загружает 50 тысяч видео в день.

Видеобаза Одноклассников насчитывает свыше 28 миллионов роликов. Исходящий трафик по вечерам достигает 80 гигабит в секунду. Ежедневно загружаемые 5 терабайт нового видео в день преобразуются в наш внутренний формат и на выходе получается 2 терабайта. Получившиеся файлы хранятся в трех копиях, что, в итоге, суммарно составляет 6 терабайт нового видео в день. Входящий трафик по загрузке достигает 2 гигабит в пиковые часы.

Уже много лет работая со спрингом, я заметил забавную закономерность: в каждой новой версии добавляется новый способ конфигурирования контекста. Давайте вспомним, как это было:

• В первом спринге конфигурацию можно было писать исключительно на xml-e. (ClassPathXmlApplicationContext(“context.xml”))
• Во втором (точнее с 2.5) появилось возможность создавать контекст через аннотации. (AnnotationConfigApplicationContext(“package.name”))
• Третий спринг добавил конфигурацию на джаве. (AnnotationConfigApplicationContext(JavaConfig.class))
• Четвёртый тоже сохранил традицию и уже с декабря 2013 года можно конфигурировать при помощи груви скриптов (GenericGroovyApplicationContext(“context.groovy”))

Консультируя и проводя тренинги в различных компаниях, я видел самое разное отношение к этим способам конфигурирования. Крупные компании, зачастую живущие по принципу «работает – не трогай», до сих пор лелеют старые xml -конфигурации, продолжая их множить и кормить новыми бинами. «Зато у нас все централизовано!» — кричат их архитекторы, добавляя 100500-тысячную строчку в xml-Бога.
Компании поменьше, пытающееся угнаться за новшеством технологий, беспощадно сжигают старые XML-ы, переписывая всё что могут, на аннотации, а что не могут на Java-конфиг. И уже потирают руки, пытаясь придумать, а куда бы им теперь приткнуть конфигурацию на грувях.



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

А где же находится правда? Неужели как всегда посередине?
Давайте попробуем разобраться…

Для начала давайте сравним стратегии декларации бинов.

Начнём с классического XML-a: