Здравствуйте.
После посещения одной конференции у меня появилась идея, воплощение которой я и представляю.
Данный пост предоставляет пример работы с библиотеками grab и rdflib, а также готовый класс для выполнения SPARQL запросов к содержимому web-страниц.

Использовать данный инструмент предполагается для превращения информации с сайтов, которые не предоставляют её в структурированном виде (rdf-тройки, xml, json), в понятный «машинам» вид.

Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».

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

Совсем недавно, перейдя на новый проект, я решил для разнообразия также перейти с Eclipse на Idea. С идеей у меня уже был опыт еще с 6-й версии, она мне нравилась, но проблем у нее было достаточно много. Тогда я отказался от нее в виду периодических глюков при долгой работе. Увидев, что уже на дворе 11-я версия я обрадовался и решил опять попытать счастья, так как по интерфейсу идея для меня гораздо приятней…

Около месяца назад заметил, что при активной разработке, когда выделенные под кучу 768мб памяти заполнены под 80%, любое действие, вроде движения мышкой, переключения фокуса, просто прокрутка колесом мышки или непосредственно скроллом в окне вызывает большое потребление памяти и оставшиеся 20% памяти съедаются за несколько секунд работы. После чего, естественно, про комфортную работу можно забыть и приходится перегружать среду в виду постоянного срабатывания сборщика. Сегодня эта ситуация меня окончательно достала и я решил узнать — в чем же собственно проблема?

Интуитивно я понимал, что вероятней всего каждое движение мышки и любое действие вроде прокрутки генерирует определенные события, которые потом обрабатываются, но ТАК МНОГО этих событий я не ожидал. Для затравки — 2 скриншота потребления памяти при движении мыши в окне редактора и скроллинге внутри открытого класса на 1000 строк:

Движение:
Скроллинг:

Обычная прокрутка в окне редактирования кода в пике съедает почти 100мб памяти за несколько секунд… Любое движение мыши генерирует объектов на десятки мегабайт… Единственный позитивный момент во всем этом, что все эти объекты потом собираются.

Доброе утро, дорогие хабралюди!

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

В четверг вечером я вернулся из очередной поездки по интеловским местам Израиля. Времени с этого момента прошло всего ничего, но уже раз пять успел услышать вопрос – а какая взаимосвязь между Intel и Израилем? Причем один раз он прозвучал из уст главы представительства в России и СНГ одной из крупнейших IT-компаний… Что же, раз такое дело, есть смысл сначала провести небольшой ликбез, а потом рассказать об увиденном в Тель-Авиве и Кирьят-Гате.

Паттерн Singleton появился, пожалуй, как только появились статичные объекты. В Smalltalk-80 так был сделан ChangeSet, а чуть в самых разных библиотеках стали появляться сессии, статусы и тому подобные объекты, которых объединяло одно — они должны были быть одни-единственные на всю программу.

В 1994 году вышла известная книга «Паттерны проектирования», представив публике, среди 22-х прочих, и нашего героя, которого теперь назвали Singleton. Была там и его реализация на C++, вот такая:

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

Поначалу я набирался опыта на DEC PDP-8, но самый кайф начался, когда появилась CP/M. CP/M изначально была «операционной системой для бизнеса», но ещё это была система, которую можно было позволить себе иметь дома, — серьёзная вещь для молодого подающего надежды гика.

От переводчика: The Codeless Code — сборник побасенок о философии программирования. Побасенки в сборнике разные — некоторые весьма кровожадные, некоторые достаточно хардкорные с технической точки зрения (родной язык автора — Java), но встречаются очень емкие. Представляю вам перевод семи наиболее полюбившихся мне историй, остальные 30+ (новые добавляются каждую неделю) можно найти на сайте.

Пустяк

Три дня и три ночи мастер не появлялся из своей кельи. На четвертый день монахи отправили послушника проведать его.

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

Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»

После выпуска 2000 иконок FatCow прошло более года. Пошел четвертый год рисования. Страницу посетило 560,096 (288,511+235,221+36,364) посетителей. Чтобы дойти до 3500 иконок, работы хватит до февраля 2013 года. Если добавить размер 64x64, то до середины 2015-го года. Пока вложено $76778 и 2000 часов работы. Тут выложили 3000 иконок, за неделю до выпуска на официальном сайте, ибо владельцы коровы (Bluehost) заняты покупкой крокодила (HostGator).



Чтобы понять, какой набор иконок самый уникальный в мире, пришлось рассортировать 7422 иконок. Результат не подвел…

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

1. Я прав, а ты нет

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

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

На прошедшей конференции Appication Developer Days, Роман Елизаров (elizarov) рассказал, как профилировать, т.е. исследовать производительность любых Java-приложений, без использования специализированных инструментов, будь они хоть вендорские, хоть open-source.Оказывается, можно использовать малоизвестные, встроенные в JVM возможности (threaddumps, java agents, bytecode manipulation), и быстро и эффективно реализовать профилирование, которое можно запускать постоянно даже на боевой системе.Вот видео доклада (тут оно косолапо эмбедится, но оно 1280x720, все отлично читаемо):

Но я предлагаю также, взглянуть на 70K текста иллюстрированной статьи-стенограммы под катом, составленной мной по видео и слайдам.

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

Пламенный привет, дорогие хабравчане!

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

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

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

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

Java vs. C#… Что может быть лучше вечного спора? Нет, данная статья не посвящена очередному бенчмарку, и даже не является holy war, не стоит даже вопрос: «кто круче».

Для каждой задачи существует свой инструмент. Сравнивать C# и Ruby, например, не имеет смысла, т.к. их целевое предназначение совершенно разное, да и природа также. Однако именно C# и Java являются наиболее близкими по своей философии.

Очень часто коллеги, пишущие на Java, даже не подозревают о многих (!!!) вещах, которые предоставляет (или, наоборот не предоставляет) C#.

Если Вам интересно посмотреть на C# и Java без субъективизма, а также узнать внутреннее устройство той или иной возможности, тогда вперед.

В Java существует возможность использования программного кода, реализованного на других языках программирования, так называемый JNI. Можно написать динамически линкуемую библиотеку, затем загрузить ее в Java-коде и использовать функции оттуда, объявив их как native методы загрузившего ее класса. JNI создавался в первую очередь для того, чтобы выполнять машинно-зависимые действия (а также, возможно, улучшить производительность критических по скорости частей приложения) на C/C++, но никто не мешает нам написать библиотеку и на ассемблере.

Химики любят говорить, что химия занимается исследованием грязных веществ чистыми методами, физика — чистых веществ грязными методами, а физическая химия, дескать, исследует грязные вещества грязными методами. В областях, традиционно относящихся к искусственному интеллекту или смежных с ними (распознавание образов, решение NP-трудных задач, обработка текста и т.д.), большинство задач являются грязными. Т.е. плохо поддающимися формальному описанию и не имеющими четких критериев правильности решения. Не знаю, как выкручиваются химики, а программистам редко удается порешать такие задачи, не запачкавшись. Программирование грязных задач тоже грязно, и здесь грязное — не значит плохое. Эта статья не о том, как сохранить чистоту и стерильность. Эта статья о том, как, вооружившись ломом мужеством и терпением, погрузиться в глубинные литосферные слои и выжить.

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