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

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

Прошлым летом совершенно неожиданно для себя я приобрел смартфон Nexus One. Своей покупкой был страшно доволен и подолгу ковырялся в его софтовой начинке, восхищаясь продуманностью системы. Поскольку я уже давно являюсь разработчиком игр, захотелось смастерить что-то свое и для этого устройства. После достаточно плотного изучения платформы, чтения специальной литературы, появились и первые ласточки в виде различных украшательств экрана. Надо заметить, что несмотря на то, что я с java никогда серьезно не работал, язык показался легко осваиваемым и интуитивно понятным. Очень сильно помогла и документация от Гугла. Все это в совокупности вселяло надежды на успешную разработку первого серьезного проекта, дизайн которого уже начал складываться с первых шагов изучения Android. Энтузиазма добавил и тот факт, что после пробного выкладывания приложения с живыми обоями на маркет за первые сутки его скачало почти тысяча пользователей. В голове завертелись мысли о коммерческих проектах и «легкой наживе».

Это была лирично-оптимистичная преамбула, а теперь перейдем к реальной действительности.

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

Зачем это нужно? В первую очередь, для гарантированного улучшения качества вашего ПО и улучшении настроения тестировщиков.

В чем идея? Чаще всего тестирование мобильных приложений осуществляется людьми: тестировщик берет приложение, iPhone 3, iPhone 4, iPad, если ему не повезло, то еще берет пару андроидов и GalaxyTab, и тестирует ваше приложение, 80% тестирования составляют примерно такие сценарии:
— запустить приложение, убедиться, что оно не падает;
— перейти на вкладку места, убедиться, что все пункты на месте;
— зайти в один из пунктов, убедиться, что описание на месте;
…

Такие тесты проводятся после каждого релиза и занимают очень много времени.

В свое время в вебе на помощь пришел Selenium, который позволил через специальный плагин к браузеру записывать действия тестировщика (все помнят макросы в MS Word?) и затем проигрывать их автоматически с проверкой результата. Можно запускать тесты даже на разных браузерах! Мы использовали это решение в своей компании, и оно, действительно, работает. Усилия на разработку тестов окупились.

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

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

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

Ну и начну с, пожалуй, самого известного, а потому и самого используемого фреймворка для тестирования — JUnit. Используется он в двух вариантах JUnit 3 и JUnit 4. Рассмотрю обе версии, так как в старых проектах до сих пор используется 3-я, которая поддерживает Java 1.4.

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

Забегая вперед, вот что получилось:

По результатам этого вопроса.

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

Добрый день, Хабражитель!

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

Итак, в данном посте я постарался изложить самые важные и значимые на мой взгляд моменты по работе со Swing и графикой — как создавать компоненты, как стилизовать интерфейс, чего делать не стоит и многое другое…

Если вы словили OutOfMemoryError, то это вовсе не значит, что ваше приложение создает много объектов, которые не могут почиститься сборщиком мусора и заполняют всю память, выделенную вами с помощью параметра -Xmx. Я, как минимум, могу придумать два других случая, когда вы можете увидеть эту ошибку. Дело в том, что память java процесса не ограничивается областью -Xmx, где ваше приложение программно создает объекты.

Здраствуй, Хабражитель!

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

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

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

В последнее время я работаю с клиентами над вопросами настроек JVM. Смахивает ситуация на то, что далеко не все из разработчиков и администраторов знают о том, как работает garbage collection и о том, как JVM использует память. Поэтому я решил дать вводную в эту тему с наглядным примером. Пост не претендует на то, чтобы покрыть весь объем знаний о garbage collection или настройке JVM (он огромен), ну и, в конце концов, об этом много чего хорошего написано уже в Сети.

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

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

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

Недавно я сдавал экзамен Oracle Certified Professional Java Programmer (бывший Sun Certified), и за время подготовки прорешал огромное количество различных задачек. Отдельные задачки по джаве иногда появляются на хабре и вызывают немалый интерес, поэтому я решил поделиться накопленным и сделать небольшую подборку.

Итак, ниже представлен десяток наиболее, на мой взгляд, интересных задач по Java SE из более чем 1000, проработанных мной. Сложность варьируется от средней до ооооооочень сложной. Решение большинства задач практически не требует знания API, достаточно логики и фундаментальных основ Java.

К слову, сложность экзамена Oracle Certified Professional Java Programmer гораздо ниже чем сложность данного теста, поэтому все, кто правильно ответит хотя бы на половину этих вопросов, может смело сдавать этот экзамен без всякой подготовки.

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

ВНИМАНИЕ: во второй половине статьи — ответы и подробные пояснения по соответствующим нюансам JAVA.

Уже давно являюсь пользователем продукции Apple. Старенький макбук полностью справляется с теми задачами, что на него возлагаются. В основном конечно развлекательные. Но в последнее время стало не хватать места на 40 гиговом жестком диске. И вот наконец у меня зачесались руки настроить свой домашний сервер, как хранилище. Некоторое время работал по ftp, но это было не удобно. Было принято решение настроить наконец Appletalk, не зря же он есть и заодно приручить к нему TimeMachine:-)

Предисловие

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

Создание QML файлов — невероятно веселая задача, но довольно часто проблематично разбить замечательные Photoshop шаблоны, которые прислал вам дизайнер, в полностью готовый интерфейс Qt Quick. Было бы замечательно, если бы мы смогли автоматизировать этот процесс? Я тоже так подумал, и написал пару полезных скриптов. Первый — скрипт для Photoshop. Просто положите его совместно с другими скриптам, и у Вас появится новый пункт в меню «Export QML», с помощью которого можно перебросить сцену в один QML-файл с элементами Text или Image из каждого слоя. Скрипт также можно использовать и для векторной графики, поскольку в Adobe Illustrator есть удобная опция экспорта в Photoshop.

Я сделал небольшое демонстрационное видео, чтобы лучшее продемонстрировать, как это работает на практике:

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

В этом выпуске серии «5 вещей …», я представлю некоторые из тонких аспектов многопоточного программирования, в том числе synchronized-методы, volatile переменные и атомарные классы. Речь пойдет в особенности о том, как некоторые из этих конструкций взаимодействуют с JVM и Java-компилятором, и как различные взаимодействия могут повлиять на производительность приложений.

Хочу признаться сразу, что я вас отчасти обманул, ибо драйвер, если верить википедии — это компьютерная программа, с помощью которой другая программа (обычно операционная система) получает доступ к аппаратному обеспечению некоторого устройства. А сегодня мы создадим некую заготовку для драйвера, т.к. на самом деле ни с каким железом мы работать не будем. Эту полезную функциональность вы сможете добавить сами, если пожелаете.

То, что мы сегодня создадим, корректнее будет назвать LKM (Linux Kernel Module или загрузочный модуль ядра). Стоит сказать, что драйвер – это одна из разновидностей LKM.

Писать модуль мы будем под ядра линейки 2.6. LKM для 2.6 отличается от 2.4. Я не буду останавливаться на различиях, ибо это не входит в рамки поста.

Мы создадим символьное устройство /dev/test, которое будет обрабатываться нашим модулем. Хочу сразу оговориться, что размещать символьное устройство не обязательно в каталоге /dev, просто это является частью «древнего магического ритуала».

Неожиданно тихо прошел релиз новой версии virtualbox, в котором впервые появилась возможность запускать в виртуальной машине MacOS X. Официально. С оригинального диска. Не хакинтош.

Аргумент -9 (или KILL) для команды kill следует использовать в POSIX-совместимых системах только в случае крайней необходимости. Почему? Сигнал KILL не может быть обработан процессом. Это означает, что после завершения процесса с помощью kill -9, дочерние процессы останутся в памяти и станут «осиротевшими» (orphaned), файловая система окажется засорена временными файлами, сегменты совместно используемой памяти — активными, сокеты — зависшими, а функция atexit(3) вообще не будет выполнена. В результате есть риск столкнуться с неожиданными и сложными для отладки проблемами.

Чем не устраивает ArtMoney

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