Решил все-таки написать статью про SQLite, в которой хочу обобщить свой 3-х летний опыт использования этой БД под Windows. Вижу, что тема популярная, но информации мало.

Часть 2
Часть 3

Небольшая вводная.

Эта статья не для начинающих программистов.
Она не является учебником по SQL.
Она не агитирует использовать SQLite.
Она не агитирует не использовать SQLite.
Статья написана в виде вопросов от гипотетического новичка в SQLite и ответов на них (поскольку информации очень много и так хоть немного проще ее структурировать).

Часть 1
Часть 3

В этой части будут затронуты непростые вопросы использования SQLite через работу с его программным интерфейсом (API).

О третьих героях, понятное дело, все знают. Недели времени, потерянного за hotseat-ом, вызубренные характеристики юнитов, тактика застройки, развития. Еженедельные посиделки с друзьями за героями c кофе и рогаликами. Здорово, в общем было. А вот на днях захотелось повторить и сыграть по сети. Уже ж разъехались все, hotseat не прокатит. Скачали дистрибутив клинка Армагеддона, настроили hamachi, да не заладилось что-то. Пинг большой почему-то, не завелось ничего. Ну, занятые все, разбираться некогда, да и неохота. Не пошла игра.

А герои то установлены, желание играть есть. Решил кампанию пройти (к своему стыду, так ни разу не хватило терпения пройти ее в прошлом). Запустил, выбрал кампанию возрождения Эратии, нажал на эпизод «Жертвы войны». И я не знаю, интуиция, наверное, появляется какая-то за то время, пока программированием занимаешься. В общем, показали мне герои такую картинку:

И, как часто у меня случается, игра закончилась, а началась более интересное и захватывающее занятие.

Дизайнер-шрифтовик Иван Гладких, более известный как Джованни Лемонад (Jovanny Lemonad), вчера (1 августа 2012 года) объявил о выходе нового шрифта «Ораниенбаум», являющегося акцидентною антиквою необыкновенно красивых начертаний, что особенно проявляется в криволинейных элементах букв (в лапках, хвостиках и др.):

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

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

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

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

Что должно получиться

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

Демонстрация

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

Но мы меня простим и сделаем вид, что это цикл статей ;).

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

Попробуем ответить на каждый из этих вопросов по отдельности.

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

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

Что было плохо?

• Было недостаточно проверок на соответствие чека и данных в SKTransaction.
• Было недостаточно проверок ответа сервера.

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

Для того, чтобы сделать этот процесс проще и удобнее, я написал небольшое рельсовое приложение, которое умеет эти иконки сортировать и фильтровать.

Выпуск нового подкаста на RPOD:
taop.rpod.ru/278611.html

Cсылочки для JRebel:
http://www.jrebel.com
http://habrahabr.ru/blogs/java/135922/
http://habrahabr.ru/blogs/java/135633/

Java Performance:
http://www.amazon.com/Java-Performance-Charlie-Hunt/dp/0137142528

Блог:
http://anton-arhipov.livejournal.com
http://arhipov.blogspot.com

Kotlin o_O:
http://kotlin-demo.jetbrains.com/

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

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

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

Думаю, не мне одному чрезвычайно надоели ресурсы, требующие регистрации по каждому поводу и без. С обязательной капчей, которая правильно введется только с пятого раза, с подтверждением по е-мейлу, которое обязательно свалится в спам и то — только через сутки. Придумывать каждый раз новую пару логин-пароль — забудется, вводить одно и то же на всех сайтах — небезопасно. Местами прокатывают пары вида «qwerty:qwerty» или «login:password», но, увы, далеко не везде. Надоело. Не счесть, сколько раз я, увидев надпись «только зарегистрированный пользователь может ****», просто кривился и закрывал вкладку, чтобы больше ни разу на этот сайт не заходить. Неужели администраторы ресурсов сами этого не понимают?

• Зачем?
  
  • Для оффлайнового просмотра на читалках.
• Моя читалка не поддерживает FB2!
  
  • Универсальный конвертор
• Хочу!
  
  1. Обзаводимся Python 2.7+. Тестировалось на Python 2.7.3.
  2. Ставим библиотеку BeautifulSoup 4. Вкратце варианты:
     
     • apt-get install python-beautifulsoup4
     • easy_install beautifulsoup4
     • pip install beautifulsoup4
     • Исходники и python setup.py install
  3. Качаем код из репозитория (прямая ссылка на последнюю версию).
  4. Открываем файл habrafav.py и в строке username = ... прописываем свой логин.
  5. python habrafav.py (или просто habrafav.py под Windows)
  6. Ждём. У меня с кэшированными данными экспорт ~150 статей занимает около 6 минут и 600 Мб оперативной памяти.
  7. Забираем habrahabr_favorites.fb2. Мой занимает примерно 62 Мб.

Здравствуй «ХабраСообщество»!
Выкладываю небольшой обзор и результаты тестирования основных алгоритмов сжатия с Java.
Кому интересно прошу под кат, кому нет — просьба не минусовать и сказать, что тема не достойна хабра – уберу в черновики.

Введение и подготовка

Привет хаброжители. Данный пост является «рерайтом» моего поста для песочницы. На этот раз я постараюсь охватить больше тем, чем тогда.

Почему Java?

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

IDE

Начнем с выбора IDE. Я являюсь фанатом Eclipse и посоветую вам его.
Если же почему-то вам он не понравился, вы можете использовать NetBeans, Intellij IDEA или командную строку и ваш любимый редактор.

JDK

И скачаем JDK последней версии: JDK 7u4

Скорее всего проблем с установкой IDE у вас не возникнет, а если у вас 64-битная система, все же посоветую устанавливать 32-битный Eclipse, так как иногда бывают ошибки и Eclipse у вас просто не запустится.

Под катом мы приступим к созданию игры.

Представьте себе, что вы уже написали немалую часть кода приложения, и тут выясняется, что вам необходимо добавить логирование на вызов большого числа методов, или необходимо на некоторые схожие методы добавить дополнительную валидацию входных данных.
Вы можете просто переписать нужные участки кода, а можете воспользоваться появившемся в EJB 3.0 механизмом интерсепторов (interceptors).

Если интересны подробности и небольшой пример реализации прошу под кат.

http://pyxeledit.com/



Когда я полгода или чуть больше назад решил ради разнообразия попробовать Flixel и сделать свой платформер, то меня сначало удивило, а потом начало злить отсутствие нормального редактора тайлов. С платформером и флешем я уже наигрался, но наткнувшись на бету не могу не поделиться с хабрасообществом.
Пара роликов c использованием под катом.

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

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

Некоторые методологии просто предлагают принять это за данность и как-то приноровиться (например, планировать только ближайший этап), другие пытаются навести армейскую строгость, проводя Deadline и вводя «реакцию на отклонения».

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

Приведу на ваш суд три возможных ситуации.

Ситуация первая. Швейцарский нож или «а еще кружок по фото, а еще нам петь охота»

http://mapeditor.org/



Tiled Map Editor — редактор пиксельарт тайтлсетов написанный на C++ (существует и Java версия программы). Данную программу можно использовать для разработки игр любого 2D-жанра. Редактор имеет большой набор готовых тайлсетов, что значительно увеличивает скорость разработки игры. Пара роликов c использованием под катом