Нет, не здоровенного. А просто удобного будильника для Андроида. После долгих поисков на Маркете я так и не смог найти будильник, который мне было бы приятно использовать. Поэтому в этой статье я буду проектировать будильник таким, каким бы я сам хотел его видеть.

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

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

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

И в-третьих, в нём нет никаких математических примеров для отключения звонка. Так что для любителей математики он не подойдёт.

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

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

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

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

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

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

Ура! То, о чем так давно боялись спросить большевики, случилось! В след за облачными вычислениями сегодня мы открываем эпоху туманных (fog) вычислений!

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

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

Для тех, кто не знаком с эпопеей переписываний с нуля данной утилиты, небольшое видео того, как это работает:

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

Жил да был один проект. И был у него интерфейс для выбора неких сущностей, живущих в древовидной структуре.

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

Просто саджест делать было скучно, поэтому я сделал вот такую штуковину, которая немного напоминает по внешнему виду маковский Файндер в мультиколоночном режиме. Отсюда и название — b-finder.

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

Сегодня мы будем воссоздавать прогресс-бар из программы установки Adobe Flash Player средствами CSS3, используя градиенты и тени.



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

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

Тех, кому этого ресурса достаточно, данная статья вряд-ли заинтересует.

Установка и настройка инструментов для разработки хорошо описана в Android Development Tutorial, поэтому это я могу пропустить.

Где тестировать свое приложение

Сначала нужно определиться, на что устанавливать и где тестировать свой проект. Можно ставить на эмулятор, как это описано в выше указанной статье. Как многие замечают, работает он очень медленно. К тому же, частое заблуждение – перед запуском приложения новички закрывают каждый раз эмулятор и снова его запускают. Этого делать не надо.
Другой способ — можно установить на VirtualBox Android-x86.
Но настоящий девайс рано или поздно понадобится – хотя бы по той причине, что писать приложения, где задействована камера или видео, или очень неудобно, или просто невозможно. Поэтому, если есть возможность приобрести устройство с Android – лучше использовать его. Я ставлю на свой HTC Wildfire, не смотря на то, что в нем появляется ненужный хлам, но я экономлю свое время (и нервы).

Какую литературу использовать

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

Суть её очень проста: если хранить перечисления как сущности (@Entity), то с ними получается крайне неудобно работать, база данных нагружается лишними запросами даже несмотря на кэширование, а сами запросы к БД усложняются лишними JOIN'ами. Если же перечисление определять как enum, то с ними становится удобно работать, но возникает проблема синхронизации с базой данных и отслеживания ошибок таковой синхронизации.

Особенно актуально это в том случае, когда поле, содержащее перечисление, аннотировано как @Enumerated(EnumType.ORDINAL) — всё мгновенно ломается при смене порядка объявления значений. Если же мы храним значения в строковом виде — как @Enumerated(EnumType.STRING) — возникает проблема скорости доступа, так как индексы по строковым полям менее эффективны и занимают больше места. Более того, вне зависимости от способа хранения значения поля при отсутствии в базе данных таблицы со списком допустимых значений мы никак не защищены от некорректных или устаревших данных и, как следствие, проблем.

Однако сама идея хранения в базе данных заманчива простотой построения запросов вручную, очень ценной при отладке ПО или решении сложных ситуаций. Когда можно написать не просто SELECT id, title FROM product WHERE status = 5, а, скажем, SELECT id, title FROM product JOIN status ON status.id = product.status_id WHERE status.code = 'NEW' — это очень ценно. В том числе и тем, что мы всегда можем быть уверены в том, что status_id содержит корректное значение, если поставим FOREIGN KEY.

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

Предисловие

Считается, что unit-тесты не должны использовать реальных объектов (т.е. подключений к базам данных, сетевых сокетов и подобного рода ресурсов). На этой почве развилось очень много холиваров — надо тестировать код, работающий с базами данных, или это плохой тон. Если тестировать, то можно ли это называть Unit-тестирование или это функциональное тестирование (или интеграционное, т.к. мы тестируем совместную работу двух программных сред/модулей). Споры и баталии не утихают. Я же попрошу читателей не отвлекаться на священные войны, а принять этот материал как пищу для размышления. Давайте не будем забывать, что описанное мною лишь инструмент, его применимость определяется задачей.

Выбор инструментов

Пожалуй самое сложное в Unit-тестировании — это проверка кода, работающего с подключениями к базам данных (по большому счету, проверка кода, работающего с внешними объектами). Да, можно использовать mock'и взамен подключений, но если у вас более одной операции с JDBC-провайдером, то вы с большей вероятностью сделаете ошибку в mock-объекте, чем отловите ее в коде при помощи последнего. Что же остается? Использовать реальные базы данных тоже нехорошо, ведь сервер БД в репозиторий не положишь… А если я скажу, что очень даже положишь, и он уже там находится? Решение нашей проблемы — HSQLDB.

HSQLDB — это реляционная база данных полностью написанная на Java. При этом, что очень примечательно, сервер базы данных может подниматься как отдельным инстансом, так и создаваться внутри Java-приложения. Небольшой размер и возможность полностью хранить всю базу данных в памяти (по умолчанию) делают HSQLDB идеальным сервером БД для Unit-тестирования. С учетом того, что с точки зрения JDBC и ORM реализация СУБД не имеет значения (если вы придерживаетесь стандарта SQL и не злоупотребляете расширениями движков СУБД), то мы с легкостью сможем подменить подключение к PostgreSQL или Oracle на соединение с HSQLDB при Unit-тестировании.

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

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

Уверен, каждый из читателей, знает что такое шаблон проектирования “Singleton”, но не каждый знает как его программировать эффективно и правильно. Данная статья является попыткой агрегирования существующих знаний по этому вопросу.

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

Riak это NoSQL решение, честная DHT (key/value storage) с дополнительными возможностями для разруливания конфликтов.

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

client a: def o-value = DHT.get("some-key");
client a: def a-value = changeValue(o-value);
client b: def o-value = DHT.get("some-key");
client a: DHT.put("some-key", a-value);
client b: def b-value = changeValue(o-value);
client b: DHT.put("some-key", b-value);

Получилось, что клиент b переписал данные клиента a и никто об этом не знает (ни a, ни b, ни тот, кто прочтет данные по этому ключу позже).

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

Например, MongoDB использует compare-and-swap стратегию: с каждым документом (значением) храниться его версия, при обновлении указывается версия «предка» измененного документа, если в базе в момент обновления храниться предок, то обновление проходит, если нет, то нет: обновляющая сторона получает сообщение, и пытается провести обновление снова — аналог STM. Такой подход хорошо работает с шардами, но плохо с репликацией.

Riak решает проблему конкурентного доступа подобно системам контроля версий, он, как бы, сохраняет конфликтные версии в разных бранчах, предоставляя программе при следующей выборке провести merge. Такой подход позволяет разрешать конфликты, связанные не только с конкурентным доступом, но и с времянной изолированостью части кластера (partition tolerance: кластер машин может распаться на две части, обе части будут работать и смогут без проблем объединиться в будущем).

Riak накладыват больше условий на разработку, но обеспечивает масштабируемость и надежность данных при работе с большим объемом информации. Статья опишет, как «обойти» ограничения Riak при разработке типичных web приложений.

Введение

Кажется, монады в программировании стали загадкой века. И для этого есть две причины:

• недостаточное знание теории категорий;
• многие авторы стараюстся не упоминать категории вообще.

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

Мы начнём с простого введения в категории и функторы, затем дадим определение монады, приведём простые примеры монад в категориях и в конце приведём монадическую терминологию используемую в языках программирования.

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

Содержание

1. Категория
2. Функтор
3. Естественное преобразование
4. Монада
5. Монады исключения и состояния
6. Монады в программировании
7. Ссылки

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

А поговорим мы о системе сборки.

За последнюю неделю появилось несколько топиков с названием «10 однострочников на <MY_LANGUAGE>, которые произведут впечатление на ваших друзей», которые содержат однострочное решение нескольких простых задач, демонстрирующее достоинства и «крутость» любимого языка программирования автора. Я решил перевести их и для сравнения собрать в одном топике. Вся волна началась (вроде как) со Scala.
Итак, поехали!

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

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

Большинство тех, кто перешел с операционных систем Windows или Mac OS на Ubuntu, сталкиваются с тем, что их любимые игры не работают на Ubuntu. И дело в том, что игровые студии мало обращают внимания на платформу Linux по причине того, что ОС Windows имеет большее распространение, а также существует мнение, что дистрибутивы на базе Linux мало распространены и нестабильны. Именно для этого создавалась Ubuntu, в которой реализован дружественный интерфейс для пользователя и достаточная стабильность.
Данный топик основан на старой записи в блоге LinuxGames07 и содержит обзор десяти лучших игр для Ubuntu, а также способ установки, скриншот и видео об игре и её описание.

1.Tremulous

Многопользовательская игра, смесь жанров 3D-action (FPS) и стратегии реального времени (RTS). Игра работает на базе игрового движка Quake III и изначально создавалась как модификация (мод) к игре Quake III.


Установка:
sudo apt-get install tremulous

Что такое CouchDB для вас? Вероятно любой, кто хоть немного интересуется популярной нынче темой NoSQL, прекрасно знает общие детали: это такая симпатичная игрушка с map/reduce-запросами, которые пишутся на JavaScript, с которой можно работать, гоняя JSON по HTTP-протоколу, а также не исключено, что слышали, что она fault-tolerant, тобишь не ломается вообще. Дальше этого обычно дело не идёт, в результате CouchDB отправляется в delicious в общую кучу со всякими MongoDB, Cassandra, Hadoop и т.п.

Примерно такого мнения придерживался и я вплоть до недавнего времени, пока не возникла острая необходимость переосмыслить архитектуру текущего проекта (упёршегося лбом в свою реляционную БД) и пересесть на документную базу данных, которая бы умела map/reduce. После того, как более пристально взгялнул на CouchDB, я понял, что он уникален в своём классе, его не следует ставить в один ряд с упомянутыми продуктами. Идеи, которые заложены в CouchDB настолько концептуальны, что способны в корне перевернуть представление о разработке веб-приложений.

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

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

Предыстория такова. Слил я как-то все песни Владимира Высоцкого, всего 32 альбома, но кодировка в них была cp1251. Так как я давно для себя решил, что вся информация у меня будет храниться только в Юникоде, cp1251 в такой большой коллекции меня это не устраивало.

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

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

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

Но через какое-то время это стало тоже неудобно. Мы захотели иметь возможность переходить от одной СУБД к другой без кардинальных изменений исходного кода.

Мы разработали DAL — абстракцию, где низкоуровневый API для доступа к каждой базе данных разносился по драйверам, которые подключались по мере необходимости. А сам пользователь общался исключительно с высокоуровневыми объектами, получающие запросы и возвращающие результат. Но спустя некоторое время и эта схема перестала давать нам нужную гибкость.

P.S. Пользуясь случаем предлагаю заглянуть в мой личный и полностью некоммерческий блог, посвященный технологиям, психологии, философии и личному опыту: http://v673.com.