...Skype — это дьявольски хитрая программа, написанная бесспорно талантливыми людьми..._{Крис Касперски}

Доброго времени суток!

Skype сейчас я встречаю чаще на компьютерах чем другие IM клиенты, мне он практически заменил icq, вся рабочая переписка ведется в skype, но речь пойдет не о том, что лучше или популярней. Часто бывает так, что участвуешь сразу в нескольких чатах где количество участников превышает 10, что собственно и приводит к тому, что на рабочем столе и в трее постоянно обновляется количество новых сообщений, а также уведомления в виде всплывающих сообщений, а теперь представьте что у вас 3 окна чата с друзьями, 1 с вашим боссом, другой с девушкой — все это в сумме начинает запутывать, отвлекать и порой раздражать. Хотелось бы расставить приоритеты…

Раньше я чаще всего настраивал «политику» уведомлений только через глобальные настройки программы
Случилось так, что я узнал, что в каждом окне чата skype возможно использование команд, например /alertsoff отключит уведомления для конкретного окна чата, соответственно /alertson включит их обратно.
Поискав немного я наткнулся на некое how-to, оказывается у skype чата довольно много текстовых команд, подобие IRC команд. Далее я постарался попробовать все возможные из них на двух имеющихся у меня платформах, как оказалось не все и не везде работает… Прошу под кат.

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

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

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

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

Мы будем под кэшированием понимать сохранение результатов вычислений в ответ на некоторые запросы. То есть, повторный результат запроса не всегда вычисляется заново, но иногда берется из таблицы, называемой кэшем. Сложно переоценить роль кеширования в современных системах. При этом часто возникает проблема, связанная с недостатком памяти. Действительно, что делать, если запросов много, а памяти хватает лишь для хранения ограниченного числа результатов? В этом случае, как правило, кеш стрится следующим образом. Фиксируется размер кэша, пусть будет N, и сохраняются результаты только для N самых «популярных» запросов.

То есть сохраняются результаты вычислений, которые скорее всего запросят заново.
Как определять эти «популярные» запросы? Наиболее известным способом является LRU, о котором я и расскажу в этой статье.

Благодаря голливудским блокбастерам, мы знаем, что у людей с расстроенной психикой бывает множество заболеваний, например, они могут воображать себя кем-то другим и вести себя соответственно. Классический пример такого фильма, это «Бойцовский клуб» от Финчера, фильм снят крупными стежками, в книге Паланика, эта история рассказана полнее и лучше. Для тех, кто не знаком с фильмом или книгой, рекомендую наверстать упущенное, но здесь изложу краткий синопсис.
Главный герой устал от обыденности и однажды он встречает человека, который показывает ему выход из привычной жизни, это бойцовский клуб или бои с другими яппи, которые также утомлены окружающей действительностью. Бои дают вкус к жизни, открывают новые возможности, дают новый мир. В конце фильма герой осознает, что все это время он был двумя людьми одновременно, он узнает это по косвенным признакам и на этом картина и заканчивается. А наше повествование с этого и начинается.

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

Данная мини-заметка в первую очередь является ответом на вопрос. Так как мой аккаунт read-only, то вот такой вот способ ответа. «А жизнь-то налаживается!» ©

Первый вывод после прочтения вопроса и ответов — не делайте так, как предложил defuz. Он не понимает суть проблемы, и если вы сделаете как им предложено — скорее всего, вы потеряете данные.
Второй: alekciy тоже не совсем прав, но тут шансов на потерю данных гораздо меньше. Почти никаких.
Ну и третий: блин, ну когда же люди поймут, что владеть используемым инструментом это реально необходимо? Читайте документацию!

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

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



Я не стал использовать замученную Лену, а нашел свою фотку Венеции. Правое изображение честно получено из левого, причем без использования ухищрений типа 48-битного формата (в этом случае будет 100% восстановление исходного изображения) – слева самый обычный PNG, размытый искусственно. Результат впечатляет… но на практике не все так просто. Под катом подробный обзор теории и практические результаты.
Осторожно, много картинок в формате PNG!

Как-то раз возникла необходимость написать транслитерацию на Python — из кириллицы в латиницу. Из слова «ситх» получается «sith», а из «шелест» выходит «shelest».

Казалось бы, чего тут вообще писать — задача едва сложнее print "Hello world". И это отчасти так — но не совсем.

Дело в том, что некоторые буквы в русском языке при транслитерации преобразуются не в одну, а сразу несколько латинских букв: это Ж, Ц, Ч, Ш, Щ, Ю и Я. По сути, если бы правилами транслитерации предполагалось преобразовывать их в одну латинскую букву, то транслитерация русского в английский действительно была бы не намного сложнее той самой простейшей программы.

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

К примеру, фраза «ШАПКА и Юля» преобразуется в «SHAPKA и YUlya», либо в «ShAPKA и Yulya» — в зависимости от того, что задано в таблице транслитерации для «Ш» и «Ю» (иногда задаётся «SH» и «YU», а иногда «Sh» и «Yu»).

То есть регистр следующей буквы в стандартных функциях транслитерации не учитывается, и все буквы в верхнем регистре заменяются по общим правилам. Поэтому в ходе транслитерации для слов «ЧАША» и «Щи» легко получается что-то вроде «ChAShA» или «SCHi», когда реально мы скорее хотели получить «CHASHA» и «Schi».

Тем не менее, все найденные реализации транслитерации из кириллицы в латиницу на Python, как выяснилось, эту особенность не учитывали. Это и многочисленные решения, приведённые на форумах, и библиотека pytils, реализующая транслитерацию в одном из своих модулей.

Значит, напишем свою функцию транслитерации, с блэкджеком и^W^W^W^H^H. :)

Цель этой статьи — заставить всех, особенно программистов на Си, сказать «я не знаю Си».
Хочется показать, что тёмные углы в Си значительно ближе, чем кажется и даже тривиальные строки кода несут в себе undefined behavior.

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

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

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

Что тут можно сказать? Невольно вспоминается старый пошлый анекдот: ну ужас. Ну просто ужас, но ведь не ужас-ужас-ужас.

Введение

В 1965 г. в журнале «Information and Control» была опубликована работа Л.Заде под названием «Fuzzy sets». Это название переведено на русский язык как нечеткие множества. Побудительным мотивом стала необходимость описания таких явлений и понятий, которые имеют многозначным и неточный характер. Известные до этого математические методы, использовавшие классическую теорию множеств и двузначную логику, не позволяли решать проблемы этого типа.

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

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

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

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

Введение

Как-то несколько лет назад, на одном из форумов, я нашел такую замечательную фразу — «Каждый уважающий себя программист в жизни должен написать свой чат-клиент». Тогда мои знания не позволяли сделать это. Я просто улыбнулся и прошел мимо этой фразы. Но вот совсем недавно я столкнулся именно с данной проблемой — нужно было написать свой чат. Ну а так как последнее время мой интерес был направлен на изучение и разработку Qt-приложений, на чем будет сделан он, решилось само собой.

Эта статья посвящена программированию GUI на базе фреймворка Qt от Nokia. Мы рассмотрим способы разработки интерфейсов для нативного отображения на платформах Windows, Linux и Mac OS X.

Презентацию^[1] вёл Йенс Бач-Вииг (Jens Bache-Wiig) — разработчик Qt (с 2005 года), занимающийся интерфейсами (look and feel).

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

Итак, приступим. Каждое графическое окружение имеет свой свод правил (User Interface Guidelines, UIG) по созданию интерфейсов, предназначенных для этих окружений. Из основных можно отметить такие руководства как Windows User Experience Interaction Guideline, Apple Human Interface Guideline, KDE User Interface Guideline и GNOME HID. Каждое из этих руководств «определяет положение кнопочек и рюшечек» конкретного окружения. Фреймворк Qt, в свою очередь, осуществляет поддержку всех этих руководств, предоставляя разработчику возможность создавать программы с использованием виджетов, «подстраивающихся» под окружение.

В сети можно найти много описаний сборки mingw и GNU утилит под ним. Я тоже решил написать свой вариант, так как во-первых он на русском. Во-вторых используются последние стабильные исходники (по состоянию на 27.01.2011). В третьих добавлена оптимизация циклов (graphite loop optimizations). В четвертых я описываю причины выбора тех или иных опций конфигурации исходников. В пятых, чтобы не забыть.

О чём эта статья

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

В этой статье я напишу как устроен алгоритм шифрования AES (которого иногда называют Rijndael) и напишу его на JavaScript. Почему на JavaScript? Чтобы запустить программу на этом языке, нужен только браузер в котором вы читаете эту статью. Чтобы запустить программу, скажем, на C, нужен компилятор и найдётся совсем мало желающих, готовых потратить время на компиляцию кода из какой то статьи. В конце есть ссылка по которой можно скачать архив с html страницей и несколькими js файлами — это пример реализации AES на JavaScript.

Введение

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

Основные операции в деревьях выполняются за время пропорциональное его высоте. Сбалансированные деревья минимизируют свою высоту (к примеру, высота бинарного сбалансированного дерева с n узлами равна log n). Большинство знакомо с такими сбалансированными деревьями, как «красно-черное дерево», «AVL-дерево», «Декартово дерево», поэтому не будем углубляться.

В чем же проблема этих стандартных деревьев поиска? Рассмотрим огромную базу данных, представленную в виде одного из упомянутых деревьев. Очевидно, что мы не можем хранить всё это дерево в оперативной памяти => в ней храним лишь часть информации, остальное же хранится на стороннем носителе (допустим, на жестком диске, скорость доступа к которому гораздо медленнее). Такие деревья как красно-черное или Декартово будут требовать от нас log n обращений к стороннему носителю. При больших n это очень много. Как раз эту проблему и призваны решить B-деревья!

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

Сообщество жизненно важно любому проекту Open Source. Активное и живое сообщество явлется сердцем проекта. Однако, писать код под свободной лицензией не достаточно для привлечения пользователей и разработчиков к построению сообщества. В этой статье рассматривается то, что позволяет выстроить успешное сообщество OpenSource.