Прочитал интересную и полезную статью (1) — и захотел поделиться собственным опытом. В нашей фирме за 12 лет работы с одной (своей, Oracle-ориентированной) программой у сотен клиентов накоплен богатейший материал на тему апгрейда структуры БД.

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

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

Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (1, 2, 3 и др.), так и в Интернете (преимущественно, англоязычном).

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

Есть сервис passwordcard который позволяет генерировать и распечатывать такие вот карточки паролей.



Суть заключается в том, чтобы запоминать только картинки и длину, например вертикаль «О» запоминаем только вертикаль, получается JQ3xqZkE

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

UPD: Для особо умных ребят уточню, что комбинаций здесь гораздо больше и facepalm писать не следует, потому как пароль можно как по диагонали брать, по змейке, зиг-загом, в обратном порядке, через один и так далее

UPD2: судя по всему сервер упал под хабраддосом (:

А что ты перенес в облака из своего обихода?

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

1)Емайл: Я полностью отказался от купленного the bat и перешел на гуглопочту, настроил на всех почтах перенаправления на основную и дал разрешение основной почте слать письма от всех моих ящиков. Сразу обращу внимание на безопасность и возможность привязки гуглопочты к номеру сотового телефона, что позволит при потере контроля или взломе вернуть себе доступ к ящику.

Доброго времени суток, уважаемые хабровчане!
Я хочу рассказать вам об относительно новом и интересном, на мой взгляд, механизме атаки на отказ в обслуживании — Slow HTTP POST.
Поиск показал отсутствие на хабре информации по теме, что несколько удивило меня, и я решил восполнить это досадное упущение. Тема не нова, но, как показали мои небольшие исследования, более чем актуальна. Забегая вперед, скажу, что полученные мной результаты позволяют говорить о существовании широко доступной технологии, позволяющей с одного компьютера с небольшим каналом «укладывать» небольшие и средние сайты, а при использовании нескольких машин с повсеместно распространенным сейчас скоростным доступом в Интернет причинить немало проблем и более серьезным проектам. Всех заинтересовавшихся покорнейше прошу пожаловать под хабракат.

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

Для исправления опечаток в словах понадобится:
Расстояние Левенштейна (или расстояние Дамерау-Левенштейна — разница будет незначительной) — levenshtein()
Metaphone — metaphone()
Алгоритм Оливера — similar_text()
База русских слов (с падежами, учетом времен и т.д.).

Введение

Алгоритмы нечеткого поиска (также известного как поиск по сходству или fuzzy string search) являются основой систем проверки орфографии и полноценных поисковых систем вроде Google или Yandex. Например, такие алгоритмы используются для функций наподобие «Возможно вы имели в виду …» в тех же поисковых системах.

В этой обзорной статье я рассмотрю следующие понятия, методы и алгоритмы:

• Расстояние Левенштейна
• Расстояние Дамерау-Левенштейна
• Алгоритм Bitap с модификациями от Wu и Manber
• Алгоритм расширения выборки
• Метод N-грамм
• Хеширование по сигнатуре
• BK-деревья

А также проведу сравнительное тестирование качества и производительности алгоритмов.

Привет. Я хочу показать вам небольшой фокус. Для начала вам потребуется скачать архив с двумя файлами. Оба имеют одинаковый размер и одну и ту же md5 сумму. Проверьте никакого обмана нет. Md5 хеш обоих равен ecea96a6fea9a1744adcc9802ab7590d. Теперь запустите программу good.exe и вы увидите на экране следующее.
Попробуйте запустить программу evil.exe.
Что-то пошло не так? Хотите попробовать сами?

Прочитал недавно заметку «15 Вопросов на собеседовании в Google, из-за которых вы можете почувствовать себя глупым» в интернете и самый же первый ответ на самый первый вопрос мне не понравился. Человек я дотошный, поэтому решил математически вычислить количество тех самых шариков для гольфа.



Там читатель берет объем автобуса, делит на объем шарика и получает количество шаров. Вычитает, правда, какое-то количество, учитывая, что там есть «сиденья и прочая ерунда, занимающая свободное место, а также сферическая форма мяча означает, что будет достаточно много свободного места между ними». Правильно ли он учел?

Давайте разберемся.

Двоичная куча (binary heap) – просто реализуемая структура данных, позволяющая быстро (за логарифмическое время) добавлять элементы и извлекать элемент с максимальным приоритетом (например, максимальный по значению).

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

Введение

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

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

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

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

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

Добрый день,

Вот и последний обещанный видеодоклад с HighLoad:

Петр Зайцев — Диагностика и исправление проблем производительности MySQL

Часть 1 (30:56): video.mail.ru/corp/miftahetdinova/5/6.html

Часть 2 (28:35): video.mail.ru/corp/miftahetdinova/5/7.html

Часть 3 (28:33): video.mail.ru/corp/miftahetdinova/5/8.html

Часть 4 (28:29): video.mail.ru/corp/miftahetdinova/5/9.html

Часть 5 (28:13): video.mail.ru/corp/miftahetdinova/5/10.html

Часть 6 (28:10): video.mail.ru/corp/miftahetdinova/5/11.html

Часть 7 (28:13): video.mail.ru/corp/miftahetdinova/5/12.html

Часть 8 (22:50): video.mail.ru/corp/miftahetdinova/5/13.html

Часть 9 (16:01): video.mail.ru/corp/miftahetdinova/5/14.html

Часть 10 (15:02): video.mail.ru/corp/miftahetdinova/5/15.html

Также мы постараемся до конца года выложить доклады с HighLoad++ в Power Point.

Хорошего вам дня!

UPD. Уважаемые хабраюзеры! Мы хотим еще раз извиниться за невысокое качество видео, которое, тем не менее, решили выложить, т.к. знали, что темы HighLoad-a для вас крайне важны и интересны и наряду с негативным фидбеком получили очень много позитива, благодарностей и просьб продолжать выкладку докладов.

Завтра, 29 декабря, как мы уже обещали, на «Хабре» также будут выложены презентации всех докладов в PPT. В хорошем качестве ;)

Спасибо за терпение и фидбек!

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

Предположим, что у нас есть 100 млн. долларов, которые нужно вложить в несколько возможных инвестиций. Каждое из этих вложений имеет различную стоимость и различный ожидаемый доход. Мы должны решить, как потратить деньги, чтобы получить максимальную прибыль.
Задачи такого типа называются задачами формирования портфеля. У нас есть несколько позиций (инвестиций), которые должны поместиться в портфель фиксированного размера (100 млн. долларов). Каждая позиция имеет свою прибыльность. Необходимо найти набор позиций, которые помещаются в портфель и дают максимальную прибыль.
Многие из вас скажут, что никакие эвристики тут не нужны, и что вполне можно обойтись полным перебором. Другие заявят, что и полный перебор не нужен, ведь существует метод ветвей и границ. Но как быть, если количество возможных инвестиций 65? Полное дерево решений содержит более 7*10^19 узлов. Предположим, что метод ветвей и границ перебирает десятую часть процента этих узлов, а компьютер проверяет миллион узлов в секунду. В этих условиях для решения задачи потребовалось бы более 2 млн. лет. Именно для таких сложных задач и используются эвристики. Если вам интересно, милости прошу под кат.

Для реализации понадобится уверенные знания работы TCP/IP и желание понять. В результате мы получим возможность сканировать удаленную машину на открытые порты от чужого адреса по следующией схеме (картинка из мануала по nmap):

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

Оглавление (на данный момент)

Часть 1. Описание, операции, применения.
Часть 2. Ценная информация в дереве и множественные операции с ней.
Часть 3. Декартово дерево по неявному ключу.
To be continued...

Декартово дерево (cartesian tree, treap) — красивая и легко реализующаяся структура данных, которая с минимальными усилиями позволит вам производить многие скоростные операции над массивами ваших данных. Что характерно, на Хабрахабре единственное его упоминание я нашел в обзорном посте многоуважаемого winger, но тогда продолжение тому циклу так и не последовало. Обидно, кстати.

Я постараюсь покрыть все, что мне известно по теме — несмотря на то, что известно мне сравнительно не так уж много, материала вполне хватит поста на два, а то и на три. Все алгоритмы иллюстрируются исходниками на C# (а так как я любитель функционального программирования, то где-нибудь в послесловии речь зайдет и о F# — но это читать не обязательно :). Итак, приступим.

Введение

В качестве введения рекомендую прочесть пост про двоичные деревья поиска того же winger, поскольку без понимания того, что такое дерево, дерево поиска, а так же без знания оценок сложности алгоритма многое из материала данной статьи останется для вас китайской грамотой. Обидно, правда?

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

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

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

Продолжение перевода первой части руководства. Начало тут.

В данном отрывке рассмотрены команды работы с файловой системой и файлами, такие как ls, mkdir, touch, mv, cp, затронуто использование echo и cat. Рассказано про иноды файловой системы.