Перевод статьи "(How to Write a (Lisp) Interpreter (in Python))" Питера Норвига. В данной статье Питер довольно кратко, но емко описывает принцип работы интерпретаторов и показывает как можно написать совсем крошечный (всего 90 строк на Python) интерпретатор подмножества языка Scheme. Перевод публикуется с разрешения автора.

Питер Норвиг (англ. Peter Norvig) — американский ученый в области вычислительной техники. В данный момент работает директором по исследованиям (ранее — директор по качеству поиска) в корпорации Google. Ранее являлся главой Подразделения вычислительной техники в исследовательском центре Амес NASA, где он руководил штатом из двухсот ученых, занимающихся разработками NASA в областях анатомии и робототехники, автоматизированной разработке ПО и анализа данных, нейроинженерии, разработки коллективных систем, и принятия решений, основанном на симуляции.

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

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

Как составить список ключевых фраз?

Вполне понятно, что основным инструментом будут системы подбора ключевых фраз поисковых систем:
wordstat.yandex.ru
adwords.google.com/select/KeywordToolExternal
adstat.rambler.ru

Однако, не стоит бездумно вводить в них все, что придет в голову.

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

Если этого будет недостаточно, то вот несколько вариантов перебора:

1. Разные части речи (компьютер — компьютерный)
2. Синонимы (советую использовать словари синонимов)
4. Варианты написания фраз – аббревиатуры, «бытовые» (компьютер — комп), транслитерации (toyota — тойота)
5. Ассоциации в системах подбора (выводятся те фразы, которые были запрошены пользователями для уточнения своих запросов)
6. Более общие слова и фразы. Тут нужно быть осторожнее, так как использование таких ключевиков размывает аудиторию сайта, а значит, ухудшает ее качество. По поводу отсечения «левых» фраз читайте нашу заметку «Как засоряют ТОП».

Я уже около 20 лет программирую на Lisp и прочитал множество сообщений Usenet и статей в блогах, написанных Lisp — разработчиками. Я часто задавал себе вопрос — А существует ли типичный Lisp — разработчик, как существуют типичные представители наций или других групп людей?

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

Итак, что же это значит, когда кто-либо говорит, что foo выглядит как pythonic? Что значит, когда кто-либо смотрит в наш код и говорит, что он unpythonic? Давайте попробуем разобраться.

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

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

Понятие Pythonicity плотно связано с минималистической концепцией Python’a и уходом от принципа «существует много способов сделать это». Нечитабельный код, или непонятные идиомы – все это unpythonic.

При переходе от одного языка к другому, некоторые вещи должны быть «разучены». Что мы знаем из других языков программирования, что не будет к месту в Python’e?

Метод console.log() — отличный способ вывести отладочную информацию, не мешая пользователю. Но знаете ли Вы, что объект console имеет еще уйму других не менее полезных методов? Очень редко разработчики используют этот функционал, ограничиваясь неблокирующим alert'ом. Что-ж, давайте исправим это положение.

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Наверное каждый разработчик подходил к моменту выбора между двумя решениями одной задачи и естесвенно решающим фактором выбора является наиболее быстрый способ (по времени процесса). Так и я в ходе разработки поиска для своей CMS задался вопросом: что лучше, делать поиск по базе используя полнотекстовой индекс или с помощью оператора сравнения LIKE, имея небольшое количество информации.

Для того, чтобы ответить на свой вопрос я провел небольшой опыт: создал таблицу с четырмя полями (два из которых использовались для поиска и были проиндексированы FULLTEXT'ом) содержащую 5 000 строк. Поля по которым производился поиск содержали по 255 символов, случайно выбранных из одного большого текста. Поиск производился так же по случайным словам не короче 4-х символов.

Примерно два года назад я арендовал у одного немецкого хостера не очень мощный сервер на базе Centos 5.2. На нём живут несколько вебпроектов, приносящих некоторую прибыль, и поэтому, я стараюсь присматривать за ним по мере возможности.
На Centos есть стандартный анализатор логов Logwatch, который запускается ежедневно по крону, анализирует содержимое /var/log, делает сводный отчет и присылает его по электропочте. В один прекрасный день я обнаружил в этом отчете запись:

--------------------- yum Begin ------------------------ 
 
 Packages Installed:
    lzo2 - 2.02-3.el5.rf.i386
    dnstracer - 1.8-1.2.el5.rf.i386
    openvpn - 2.0.9-1.el5.rf.i386

---------------------- yum End -------------------------

В тот момент меня она очень смутила, так как в предыдущий день на сервер я не логинился и тем более ничего не устанавливал. Первое, что пришло в голову — сервер был скомпроментирован. Себя я считал уверенным пользователем Linux, однако я растерялся. Благо в тот момент в icq был мой бывший коллега, лучший системный администратор, которого я знаю, и просто очень хороший человек.
Он помог быстро проверить систему. В результате у меня сформировалось краткое HowTo о том, как быстро проверить свой сервер на предмет взлома. Уверен, что многим Храброчитателям оно будет полезно. Предполагается, что пользователь знаком с консолью Linux/Unix.

Вышла в свет новая версия русскоязычной базы данных стран и городов. Основные изменения:
— для перевода названий городов использован API Карт Google (идея chernikov)
— для поиска по странам СНГ подключена база geobaza.ru (идея derketzer)
Результат этой работы доступен для свободного скачивания.

Введение

Эта вводная статья предназначена для желающих попробовать применить Common Lisp в задачах веб-программирования. Я не буду останавливаться на преимуществах этого языка, за меня это сделал ababo в своем вводном посте Разработка web-приложений на языке Common Lisp (часть первая)

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

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

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

Для тех, кто любит проматывать скучные процедуры установки — в конце статьи размещена небольшая вкусность, которая, возможно, расширит ваш взгляд на веб-программирование, если до этого момента вы не имели дела с лиспом. Ищите по ключевым словам SLIME и SWANK :)

Было время, когда я ничего не знал про VCS, ни что это такое, ни тем более зачем это мне. И верхом своих достижений считал папочку с архивами версий. К моменту осознания необходимости системы контроля версий я уже набил шишек и прочувствовал необходимость такого инструмента. Но борландовский аналог CVS меня не впечатлил. У каждого файла свой номер версии. Как мне получить срез определенного релиза я так и не разобрался. А в это время SVN победоносно шла сквозь умы разработчиков. Черт, это было то, чего мне так не хватало. Прочитав доку и начав работать я просто влюбился в нее. Да, были трудности и определенные неудобства, но куда без них.
Так я и работал бы в SVN, но ничего не стоит на месте. В интернете уже потекли тонкие ручейки новостей про Git. Я не кидаюсь за каждой новой технологией, и прошло уже достаточно много времени, пока мне не прожужжали этим Git’ом все мозги. Мне стало любопытно, я вначале присматривался, примерялся, а потом плюнул и начал новый проект на Git. Мучался с ребятами 2 недели, накачал литературы, написал шпаргалку… ничего, привыкли, … а потом меня поперло.

Теперь меня регулярно просят рассказать про Git и что в нем такого. Уже надоело, поэтому этот пост для тех, кто еще сомневается.

Node.js обычно вызывал у людей, которым я о нём рассказывал, две различные реакции. В основном они воспринимали его «как есть», однако многие были сбиты с толку.

Если вы относитесь ко второй группе, я попробую объяснить, что же такое Node.js:

• Это инструмент командной строки. Вы скачиваете архив, компилируете и устанавливаете его.
• Это позволит вам выполнять программы на JavaScript, набрав 'node my_app.js' в терминале.
• JavaScript выполняется движком V8 (тем самым, благодаря которому так быстро работает Google Chrome).
• Node.js предоставляет API для доступа к сети и файловой системе из JavaScript.

Вступление

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

Пару недель назад все начали писать о предстоящей майкрософтовской конференции PDC (Professional Developers Conference). В частности, Дуг Рейли написал пост «Кто управляет вашей карьерой?». Многие прочитали и сослались на пост, а некоторые (например, Сэм Джентайл или Роберт Херлбат) даже развили идею в ответных постах.

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

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

Любовь к HTML5 продолжает вдохновлять Поля Айриша. Во-первых, он подарил нам Modernizr, а сейчас он объединился с Divya Manian для создания шаблона HTML5, который использует передовые техники, чтобы Вы могли начать использовать его в своей практике.

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

Если вы полагаете, что масштабируемость Вашего нового, web приложения — это основное на чем Вам надо сосредоточиться,… подумайте дважды. Можно с уверенностью утверждать, что в обозримом будущем массового нашествия пользователей не ожидается. Вместо этого этого следует готовиться к медленному увеличению количества посетителей, с возможным пиком увеличения их числа (прим. переводчика: хабраэффект например). Но сосредотачиваться на архитектуре и масштабируемости Вашего приложения до миллионов пользователей — не очень хорошая идея. Миллионы это много. Скорее следует приготовиться к борьбе за первую тысячу пользователей. Возможно даже меньше, если Ваш сервис платный.

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

После чтения дискуссии на Hacker News, я снова серьезно задумался о языках программирования. Имеет ли какое-то значение, знаешь ты только один или несколько? Могу ли я знать 5 языков одинаково хорошо? Или хотя бы настолько хорошо, чтобы утверждать, что я их «знаю».

1. Верстка, аутсорсинг и технические задания

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

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