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

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

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

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

Повертели в руках плотники чертежи, что Oracle Flashback зовутся, да засомневались. Неужто рычажок UNDO_RETENTION, по-умолчанию в 3 минуты установленный, можно без последствий до года докрутить, ничего не потерять и не утонуть в гигабайтах лишних данных. Решили свой механизмус собрать.

Сказки кончились, дальше суровая реализация механизмуса.

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

Грамматика — проблема не только Хабрахабр, но и всего интернета. Да чего там! Даже во времена ФИДО проблема была актуальна. Так родилась легенда про Черного поинта. Это старая история. Надеюсь, её впомнит еще кто-нибудь кроме меня.

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

С 1-го января 2009 года президентом Microsoft Россия станет Николай Прянишников. В Microsoft он переходит из компании Вымпелком (он же Билайн), где Николай занимал должность исполнительного вице-президента по развитию международного бизнеса.

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

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

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

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

Директор, откидываясь на спинку кресла и растягиваясь в хитрой улыбке, замечает: «Только один правду сказал! Как тут догадаться кто из них кто?»

Web наступает. Все больше и больше обычных настольных приложений переезжает в Internet. Уже никого не удивить онлайновым текстовым или графическим редактором. А уж различные многопользовательские комплексы, базы данных, системы отчетности — тут раздолье для веб-технологий. Например, еще несколько лет назад было бы вполне нормально сделать систему регистрации и учета клиентов скажем стоматологической поликлиники или библиотеки в Delphi, добавить базу данных и сетевую часть. Но сейчас такое решение окажется неразумным: гораздо проще, удобнее, а значит и эффективнее использовать все то, что предоставляет нам Web, даже если приложением будут пользоваться только внутри локальной сети. Кроме того, такое решение кроссплатформенное, что актуально в связи с наметившейся тенденцией перехода к свободным ОС. Все что нужно на клиентских компьютерах — наличие браузера, никаких установок, настроек и прочего.

Но у решения все делать в web есть недостаток (даже не один, но я сейчас не буду перечислять все): неудобство при печати отчетов, бланков документов и прочих печатных страниц. Это связано с тем, что веб-страницы рассчитываются прежде всего для отображения на экране монитора и не подтачиваются для печати, что нередко ведет к расползанию печатной страницы. К счастью это все временные трудности и их можно обойти. Можно, например, генерировать отчеты в pdf или doc. Но я считаю это не слишком удобным: пользователю надо устанавливать программы, работающие с этими форматами, каждый раз выкачивать с сервера сгенерированный файл, печатать из сторонней программы, а не браузера. Поэтому стоит приложить усилия к созданию страниц, правильно выводящихся на печать прямо из браузера.