Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

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

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

Ну, от слов к делу

Столько слов придумали, все и не запомнишь — Канбан, Скрам, ЭксПи…
Есть ощущение что создается наука из ничего так-же как бухгалтерия в нашем государстве.
А ведь смысл и идея не нова, лежит в основе мироздания, матушки природы и любого производства.

Вот мои простые тезисы по этому поводу:
1. Делай только то что надо сейчас
2. Делай только то что принесет максимальный эффект
3. Если задача сложная разбивай на простые
4. Используй самый простой подход решающий задачу
5. Работай одновременно только над одной задачей
6. Переключайся только когда задача полностью готова
7. Делай работу над ошибками

В идеале готова — в нужном качестве у заказчика и он ей доволен.

Спасибо за внимание!

PS: Если статья понравилась, поднимите карму.
Потому как те кому не понравилась понимаете что сделали…

Вряд ли найдётся Java разработчик, который не знает что такое Spring Framework. Одними из базовых технологий данного фреймворка являются IoC контейнер и поддержка AOP. Эти технологии позволяют успешно разбивать архитектуру приложения на обособленные слои, как на уровне классов, так и на уровне компоновки объектов во время выполнения. Казалось бы, что приложение отлично структурировано на элементы/слои, но по своей сути оно остаётся монолитным. Монолитным во время выполнения (runtime)! Только в рамках данного фреймворка не существует универсальных решений этой проблемы. Чуть меньшее количество Java разработчиков слышало об OSGi. Это спецификация модульных систем для Java платформы. Использование конкретной реализации данной спецификации в качестве основы приложения позволяет сделать его модульным, как во время выполнения, так и на физическом уровне (уровне файлов). О синергии этих технологий и пойдёт речь в этой статье.

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

Директриса долго отпинывалась, да и я со своим характером не сахар. Но тем не менее в сентябре мне вручили журнал 7а класса по предмету «Вводный курс информатики и программирования».

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

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

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

В этой статье мы хотим поделиться нашим впечатлением и опытом о разработке двух интерактивных книг для детей: «История о Мисс Моппет» и «Сказка о Котёнке Томе».

Начнём с того, что отметим: самое важное в книге – это текст. Именно поэтому для книг очень важным является перевод, а применительно к приложениям на App Store: для книг-приложений, очень важна качественная локализация.

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

Мы решили делать интерактивные книги на русском языке с озвучкой текста.

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

Случалось ли Вам играть в игру вроде StarCraft или Supreme Commander и получать сообщение об ошибке вроде “Обнаружена рассинхронизация”, за которым следует закрытие игры? Хотите узнать отчего так происходит? Это наследие архитектуры игрового движка, часто используемой стратегиями в реальном времени.¹

Мой опыт в этой области происходит из работы с движком Supreme Commander в студии Gas Powered Games. В период бета тестирования в Starcraft и Warcraft 3 тоже были проблемы с синхронизацией, так что можно сказать что в целом они работают так же. Для простоты я буду говорить именно о движке Supreme Commander. Нахождение сходства с другими играми оставлю как упражнение для читателя :)

[Статья Armin Ronacher о принципах вычисления коллизий в сетевых шутерах. Носит скорее обзорный и исследовательский, нежели технический характер. Здесь и далее в квадратных скобках примечание переводчика]

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

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

Почитав интервью создателей знаменитого бестселлера “Cut the Rope”, в котором утверждается, что на создание веревки ими было потрачено больше всего времени, я не поверил, что написать «алгоритм движения тяжелой нити» действительно так сложно, и для этого надо чуть ли не самим писать физический движок. Погуглив, готового ответа я не нашел, и решил попробовать сделать самостоятельно нечто подобное на cocos2D + Box2D.
За основу были взяты правила:

1. Цепь делать лучше с помощью прямоугольных тел, соединенных Revolute Joint’ами;
2. Чем тяжелее объекты составляющие цепь – тем она стабильнее;
3. Количество итераций при шаге – чем больше, тем лучше (мне хватило 3-х);
4. Очень помогает, если каждый кусочек цепи, помимо Revolute Joint’а соединить Distance Joint’ом.

С момента запуска nesbox.com прошло уже более полутора лет, все это время меня не покидала идея сделать игру для двоих через интернет. Если интересно, как мы пришли к рабочему варианту, добро пожаловать под кат.

Я думаю все любители DIY имеющие аккумуляторный инструмент знают, что аккумуляторы штука недолговечная.
А купить замену бывает не так просто. И дело зачастую не в цене (хотя и цена аккумуляторы для профессионального инструмента может быть совсем не детской), а в том, что нереально найти нужную модель.
Я сам столкнулся с этой проблемой после двух лет эксплуатации профессионального шуруповерта с 18V аккумуляторами на 1,5А*ч.
Несмотря на то, что я предусмотрительно докупил 2 дополнительных батареи в комплект к двум шедшим в комплекте в последнее время все 4 стали работать неприлично мало и вопрос встал ребром. Дело осложнялось тем, что итальянский производитель, увы, разорился пару лет назад. Торговая марка была продана китайцам, а сама линейка профессионального инструмента снята с производства. Так что простое решение «выкинуть и купить новые» не проходило.
Осторожно — много фото.

ContentProvider — класс Android для обмена данными между приложениями. Именно так и написано в явадоках: A content provider is only required if you need to share data between multiple applications. Но кто же читает документацию, пока всё работает? Очевидно, только тот, кто набил достаточно шишек, наступая на всевозможные грабли.

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

Введение

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

Несмотря на то, что спецификацию HTML5 планируется полностью утвердить и добиться максимально широкой функциональной совместимости лишь в 2014 году, уже сейчас начинают выкристаллизовываться идеи о том как должна выглядеть данная спецификация следующего поколения — HTML.next, как его в рабочем порядке называют в W3C-консорциуме.

Новые элементы семантики

<dеcompress>

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

Пример использования:

<decompress href="http://thisisanexample.com/mobile/familyreunion.zip">
<a href="familyreunion.zip/html/activities.html">Activities from our family reunion</a>
<img src="familyreunion.zip/img/familyreunion1.jpg">

Знаете сколько в памяти занимает строка? Каких только я не слышал ответов на этот вопрос, начиная от «не знаю» до «2 байта * количество символов в строке». А сколько тогда занимает пустая строка? А знаете сколько занимает объект класса Integer? А сколько будет занимать Ваш собственный объект класса с тремя Integer полями? Забавно, но ни один мой знакомый Java программист не смог ответить на эти вопросы… Да, большинству из нас это вообще не нужно и никто в реальных java проектах не будет об этом думать. Но это, ведь, как не знать объем двигателя машины на которой Вы ездите. Вы можете быть прекрасным водителем и даже не подозревать о том, что значат цифры 2.4 или 1.6 на вашей машине. Но я уверен, что найдется мало людей, которые не знакомы со значением этих цифр. Так почему же java программисты так мало знают об этой части своего инструмента?

Integer vs int

Все мы знаем, что в java — everything is an object. Кроме, пожалуй, примитивов и ссылок на сами объекты. Давайте рассмотрим две типичных ситуации:

//первый случай
int a = 300;
//второй случай
Integer b = 301;

В этих простых строках разница просто огромна, как для JVM так и для ООП. В первом случае, все что у нас есть — это 4-х байтная переменная, которая содержит значение из стека. Во втором случае у нас есть ссылочная переменная и сам объект, на который эта переменная ссылается. Следовательно, если в первом случае мы определено знаем, что занимаемый размер равен:

sizeOf(int)

то во втором:

sizeOf(reference) + sizeOf(Integer)

Забегая вперед скажу — во втором случае количество потребляемой памяти приблизительно в 5 раз больше и зависит от JVM. А теперь давайте разберемся, почему разница настолько огромна.

Из чего же состоит объект?

Прежде чем определять объем потребляемой памяти, следует разобраться, что же JVM хранит для каждого объекта:

• Заголовок объекта;
• Память для примитивных типов;
• Память для ссылочных типов;
• Смещение/выравнивание — по сути, это несколько неиспользуемых байт, что размещаются после данных самого объекта. Это сделано для того, чтобы адрес в памяти всегда был кратным машинному слову, для ускорения чтения из памяти + уменьшения количества бит для указателя на объект + предположительно для уменьшения фрагментации памяти. Стоит также отметить, что в java размер любого объекта кратен 8 байтам!

Ларс Вогель — евангелист Eclipse.
Под катом Вы обнаружите перевод его статьи, которая описывает процесс создания Android-приложений с помощью Eclipse. Используется Eclipse 3.6, Java 1.6 и Android 2.3 (Gingerbread).
Часть 2

В этой статье я закончу свой рассказ о разработке моей первой игры под Android. Для тех, кто не видел/не прочел — часть первая.

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

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

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