Осторожно, трафик! Но можно хотя бы посмотреть картинки )

   Идея создать дома свой «рабочий кабинет» у меня зрела давно – как-то сам дошел до осознания его необходимости, хотя немалый вклад в начинания сделал этот давний пост на Хабре. У меня было своё рабочее место – большой удобный стол, где помещалось практически всё и даже больше… но, по сути, он был проходным двором – все время кто-то ходил, был рядом, отвлекал… такое очень часто мешает сосредоточиться и начать работать. Иногда, бывает, сидишь весь вечер за компом и понимаешь, что абсолютно ничего не сделал, хотя родным заявил «так, мне надо поработать».

(Первые части: 1 2 3 4 5 6). Как и обещал вчера, продолжаем обсуждать XDG и движемся к следующим темам. Возможно, мы двигаемся слишком быстро, и действительно имело бы смысл публиковать одну статью раз в два-три дня, чтобы оставалось время всё обсудить. Но, наверно, пока «бензин есть», я буду продолжать писать. А потом можно будет вернуться и обговорить ранее освещённые вопросы. Мне кажется, что в компьютерной лингвистике разные темы настолько тесно связаны друг с другом, что разговор об одной из них без связи с другими малопродуктивен. А мы ещё не обо всём беседовали, так что лучше охватить взглядом как можно больше аспектов компьютерного анализа текста, а потом уже рассуждать о конкретике в рамках общей картины происходящего.

В преддверии Нового года решил начать небольшой цикл статей, посвящённых наиболее интересующему меня лично направлению в обработке текстов на естественном языке. (То есть NLP в заголовке означает natural language processing — ваш К.О.) Синтаксический анализ, семантика, машинный перевод, поиск смысла слова в контексте — в общем, вся радость компьютерного лингвиста :)

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

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

Некоторое время назад здесь находился замечательный пост-перевод о 50 инди-играх, в которые действительно стоит сыграть. В настоящий момент он устарел, но ему на замену пришёл целый цикл постов об инди-играх — «Великолепная подборка инди-игр»:

• Часть первая
• Часть вторая
• Часть третья
• Часть четвёртая

Хочу признаться: уже несколько лет я болею вирусом «МДС». Я не могу слушать никакого другого аудиоконтента, кроме этой передачи.

Кто знает и любит игры серии Samorost, тому я мысленно жму руку. Чудесные по атмосфере Flash-игрушки, потрясающие по задумке и реализации. Если кто еще не слышал об этих Flash-квестах, настоятельно рекомендую поиграть как в первый Samorost, так и в его продолжение — Samorost 2.

Не так давно я задался вопросом, а не выйдет ли вскорости третья часть этой чудесной серии. Оказалось, что пока нет — авторы игры, студия Amanita Design, сейчас работают над полноценной, как они сами выразились, приключенческой игрой Machinarium, выход которой намечен на первую половину 2009 года. Судя по скриншотам, эта игрушка должна стать отличным образцом рисованных квестов, которые из-за массовой «3D-зации» чуть было не канули в Лету (чту память по двухмерным «Петьке и Василие Ивановиче», спасающим Галактику, и рисованным братьям Пилотам).

Впрочем, двухсерийный «Саморост» и будущий «Машинариум» —

Floor Planner beta — очень занятный сервис для планировки помещений. Вы можете учитывать в планировке всё что угодно, начиная от стен и пола, заканчивая диваном и сервизом тарелок.

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

Итак, что же представляет из себя Screen?

Хотел я написать взывающий к разуму ИТ-шника пост о вреде долгосидения перед компьютером и важности зарядки для глаз, но не буду. Просто вот так:

Не будешь делать зарядку — потеряешь зрение через несколько лет!

Ниже написано то, что надо делать. Зарядка отнимает 5-7 минут ежедневной жизни, но зато существенно понижает вероятность нужды в очках.

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

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

Далее в посте:

1. С какой стати писать компиляторы?
2. Общий план
3. Анализ текста
4. Практический пример
5. Как это работает?

Мне довольно часто, даже постоянно приходится обращаться к разным базам данных MySQL. Испробовав немало разных GUI клиентов я понял, что они все меня не удовлетворяют. То проблемы с кодировкой, то отсутствует автодополнение кода, то не работает история запросов. В общем пришел я к использованию консольного клиента mysql. И вроде все хорошо, но была пара проблем.
Во-первых заходя в очередную закладку с открытым соединением mysql я тупо смотрел в строку приглашения и старался понять на каком я сервере нахожусь и к какой базе данных подключен. Во-вторых при выводе большого количества полей или при выводе поля с длиной превышающей ширину терминала получалась каша из черточек, букв и палочек :). На днях я покопался в документации и с кое-чем разобрался.

Я, как и многие программисты, после знаменитого выступления Линуса Торвальдса о Git на Google Talks заинтересовался распределенными системами управления версиями, а в особенно Git.

Я довольно таки свободно читаю на английском, но мне приятнее читать на русском языке, при условии нормального перевода.
Существует замечательная книга «Git Magic» Бена Лина (Ben Lynn).
Благодаря труду многих людей вышел первый черновой вариант этой книги. Всех желающих улучшить перевод — приглашаю под кат.

Думаю, что многие Java-разработчики знают или хотя бы слышали о методе String.intern(). Но далеко не каждый использует его в своих приложениях или представляет в каких случаях он полезен и полезен ли вообще. Так было и со мной до тех пор пока я не столкнулся с этим методом в одном из проектов. В тот момент я захотел узнать смысл и особенности его использования и набрел на одну весьма интересную статью ведущего разработчика Yahoo! по имени Ethan Nicholas, переводом которой теперь хочу поделиться с той частью Хабра-сообщества, которая не безразлична к языку Java.

Тем, кто знает об этом методе лишь понаслышке, добро пожаловать под кат.

Я почему вредный был?
Потому что у меня велосипеда не было!
Мультфильм «Трое из Простоквашино»

Когда десять раз делаешь одно и то же, на одиннадцатый раз ты волей-неволей начинаешь задумываться о том, как бы процесс оптимизировать. Так и с версткой: после десятка сверстанных страниц хочется слегка упростить свою задачу. Тут на помощь, конечно же, приходят разнообразные фреймворки (чего только стоит oocss или наикрутейший CSS-фреймворк от Яндекса или целая куча других не менее интересных фреймворков). Пригодятся и системы сборки (Ant стоит на службе у студии Артемия Лебедева, да и я потихоньку постигаю его Дао). Не стоит забывать и различные хаки и шаблоны лейаутов, коих в интернете бесчисленное множество.

Однако как быть с сайтом, для которого надо сверстать пару-тройку типичных страниц? Нет смысла тащить с собой кучу лишнего CSS-кода. Кроме того, многим верстальщикам гораздо проще написать качественный код с нуля, чем перегружать кучу заранее объявленных бесполезных классов. Что делать?

Чтобы решить эту высосанную из пальца нетривиальную задачу я написал простейший шаблон для верстки, который сильно облегчил мне работу над проектами. Шаблон примитивен и прост (потому так и зовется), на звание фреймворка ни в коем случае не претендует (минус в карму тому, кто обзовет его фреймворком! ;) ). Он несет в себе заранее объявленные CSS-классы для работы с меню, списками, формами, ресеты основных тегов (вроде сброса отступов у форм и правильных отступов у <p>) и еще кое-какие полезные для меня вкусности.

Заметка не новая, но я уверен, что и сейчас не все знают всё нижеперечисленное (Здесь и далее курсив переводчика).

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

Замер скорости в контроллерах — это очень просто. Используйте метод benchmark в любой модели.

Каждый, кто разрабатывал приложение на RoR знает, что в консоли (./script/console) не слишком удобно просматривать ActiveRecord объекты, они имеют мягко говоря не читабельный вид

Например в моем последнем проекте есть модель Schema

Пишу чтобы не забыть, а в дальнейшем использовать, надеюсь кому-нибудь тоже будет полезно. Озадачился заменить скайповские попапы на стандартные убунтовские нотификации, уж больно глаз режут. Есть задача, есть желание её решить. Как оказалось решение достаточно несложное. И так, решение.

Хочу представить свой перевод статьи «Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews».

Я ненавижу тебя: твой код – хлам!
Взаимоотношения участников ревизий кода

Джонатан Лэндж (Jonathan Lange), 15.09.2008

Обзор

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

Мы кратко рассмотрим, почему следует проводить ревизии кода, и сделаем упор на вопросе, как складываются при этом взаимоотношения участников процесса, в особенности в проектах с открытым исходным кодом. Действительно, отчасти open source привлекает (а порой наоборот отпугивает!) людей именно потому, что ваш код будут просматривать эксперты со всего земного шара. Мы также рассмотрим влияние, оказываемое некоторыми существующими технологиями на культуру ревизий кода, рассмотрим, чего можно достичь с их помощью, и как проводятся ревизии в других сферах деятельности. Мы также обозначим некоторые «подводные камни» ревизий, которые легко не заметить.