Однажды появилась необходимость выбрать шаблонизатор для использования с Django. На одном встроенном решении останавливаться я не хотел, а провел небольшое исследование производительности и удобства использования разных продуктов.

На данный момент я выбрал Cheetah. Вот почему:

С выходом на большую арену Ruby и с появлением фреймворка Seaside, все чаще упоминается Smalltalk. Однако, среди молодого поколения (разработчики до 30 лет) бытует мнение, что это мертвый язык, разработанный на заре появления ПК и тогда же похороненный. Упоминание о Smalltalk на лекциях по ЯП, недалеко от COBOL, делает его еще более архаичным.

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

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

Для python-разработчика и vim-юзера в одном человеке, ropevim приподнесет приятный сюрприз. Наконец-то в наш любимый редактор возможна безболезненная интеграция rope — python-библиотеки, предназначенной для рефакторинга. Для тех кто не слышал о rope, кратко перечислю некоторые из возможностей: довольно умное кододополнение, возможность переименования переменных и модулей, возможность перехода на описание объекта, где бы он ни оно не находилось, автоимпорт и прочее.

Под катом список хорошей литературы.

Хороший звук — понятие относительное. Убежденные меломаны, располагающие лишними финансовыми средствами, «пролечат» любого на предмет нужной акустики, усилителя и, конечно, аудио-кабелей. Бытует мнение, что дорогущие кабели (обязательно позолоченные!) — залог отчаянно потрясающего звука, который (при прочих равных) невозможно получить при помощи обычного дешевого «шнурка». По крайней мере, недавно, на одном из «мероприятий», я наслушался таких аудиофилов, пропагандирующих немерянные траты на кабели. И, конечно, задался вопросом, надо ли это на самом деле?

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

Вход

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

Трудности

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


В одной из моих статей мы рассматривали запись звука в файл с помощью команды:

cat /dev/audio > /tmp/my.sound

Эта команда читает файл (устройство) /dev/audio с помощью команды cat и перенаправляет информацию из него в файл /tmp/my.sound (с помощью оператора >).

Здесь я хочу рассказать о настройке шлюза на Linux'e, для использования 2-х (и более) провайдеров интернета.
Для настройки мы будем использовать возможности iptables и утилиты ip из пакета, который как правило называется iproute2. А для решения поставленной задачи пакеты мы будем маршрутизировать на основе «policy routing» (т.е. маршрутизация на основе политик), а не «destination routing» (маршрутизация на основе адреса получателя).

В наше время в сети достаточно легко найти «12 правил фрилансера», или «20 советов фрилансеру», а то и «библию фриланса».
У всех разное отношение к этому явлению, разный опыт или предубеждения. Немало, кстати, негативных мнений.
Мне бы не хотелось писать очередное руководство «как заработать 10000$ в месяц». Поделюсь своим небольшим, но положительным опытом в роли «Фрилансера» и кое-какими выводами. Этот опыт сделал для меня работу на фрилансе комфортной и прибыльной.

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

Рассмотрена настройка через конфигурационный файл vimrc и приведены ссылки на статьи с описанием отдельных моментов.

Кого-то VIM оттолкнет, показавшись поначалу слишком сложным или неудобным. Однако не стоит недооценивать его гибкость и возможность настройки себя, ведь из VIM можно буквально вылепить идеальный редактор/IDE, таким, каким вы представляете его себе.

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

Я постарался писать как можно компактней, но без потери содержательной части, но статья все-равно вышла довольно объемной. Материал логически разбит на несколько разделов и совсем не обязательно читать его по порядку. Тем не менее, прочитать сведения по установке плагинов и настройке vimrc я рекомендую настоятельно.

В предыдущей части мы начали бороться за память на 256 мегабайтном слайсе «на скорую руку». Результат был, но не столь эффектный как тот которого я добился на этот раз.

Я всегда догадывался, что причина всех моих неприятностей — apache. И чем больше я пытался его настраивать, тем больше в этом убеждался. Вывод? Попробовать заменить. Одно но — переход должен быть как можно более плавным, поскольку речь, ясно дело, о продакшене.

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

Думаю вы не раз встречались с ситуацией, когда не могли найти драйвера к некоторым устройствам в ОС Windows. В диспетчере устройств эти железки гордо именуются «Неизвестное устройство». Хочу вам продемонстрировать мой метод решения подобных ситуаций и две истории успешного его применения.

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

Итак, первая история. Когда то давно я приобрел IrDA-USB адаптер для связи с телефоном Nokia и с Windows XP он работал. Прошло время, появился ноутбук с Windows Vista, и нужно было данные с телефона скопировать для сохранности. И тут выяснилось, что адаптер не работает с драйверами, которые шли на диске. На сайте производителя (Tekram) свежего драйвера под Vista не обнаружилось, но в то же время адаптер прекрасно работал под Linux, чем я и воспользовался.

Все знают, что пластиковая оболочка многих устройств с гордым логотипом производителя на деле скрывает под собой чип, который используется в сотнях подобных устройств. Linux не смотрит на логотип, Linux работает с чипами, и вывод dmesg и lspci, lsusb наглядно показывает где следует искать драйвера.

Итак, я вставил адаптер в Linux машину и посмотрел вывод lsusb:

Bus 007 Device 002: ID 9710:7780 MosChip Semiconductor MS7780 4Mbps Fast IRDA Adapter

На сайте производителя за пару минут я нашел требуемое — драйвер под Windows Vista, который заработал.

Следующий пример — сервера HP ML110G5. HP поддерживает для этой серии установку Windows Server 2003, и ничего более. В то же время сервера брались под весьма кривую систему, которая иначе как под Windows XP не запускалась. Как вы понимаете на сайте HP драйверов под Windows XP не было, а техподдержка вторично недвусмысленно выразилась, что подобная связка не поддерживается.

И снова Linux, а именно Slax, нам помог, lspci вывел наименование чипсета, драйвера под который мы успешно скачали с сайта Intel.

Вообще Linux успешно помогает работать с Windows сетями, и эти два случая демонстрируют лишь одну малую возможность применения. К примеру разворачивать новые компьютеры в сети мне привычнее при помощи partimage или dd, так как я не считаю возможным пользоваться нелицензионным ПО, а покупать Norton Ghost, когда я прекрасно обхожусь без него, это растрата средств работодателя.

Обновление: в комментариях можно найти другие решения этой частной проблемы.

Александр Радзишевский, владелец небезызвестого ресурса www.websound.ru, на днях открыл сервис AudioTag, позволяющий узнать имя исполнителя и название композиции по небольшому фрагменту композиции — достаточно загрузить лишь 15-30 секундный отрывок (или композицию целиком).

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

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

Секреты алгоритма создания слепков и источника музыкальной базы автор не раскрывает. Однако, что касается первого — они уже существуют (хоть я и не понимаю как это чудо работает, но по форме это что-то вроде MD5), а по второму вопросу, возможно, были задействованы ресурсы какого-нибудь «знакомого» онлайн-магазина — всё-таки миллион треков это очень много, да и вряд ли Алекс держит в личном архиве столько попсы :)

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

Во-первых, это приложение однопоточное. Всё делается одним процессом, работа с сокетами — неблокирующими epoll/select, никаких ожидающих ввода/вывода потоков (threads). С развитием HTTP, сначала появлением Keep-Alive, затем AJAX и набирающим популярность COMET, количество постоянных соединений с веб-сервером растёт, на нагруженных проектах измеряется тысячами и даже десятками тысяч, и если для каждого создавать свой поток (thread) со своим стеком и постоянно переключаться между ними — ресурсов сервера очень быстро не хватит.

Второй ключевой момент — что один SELECT… WHERE pk in (k1, k2, ..., kN) выполняется быстрее, чем несколько SELECT… WHERE pk=… Выполняя работу с базой данных большими пачками можно уменьшить не только число запросов в секунду, но и общую нагрузку.

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

К примеру аренда четырехядерного AMD Opteron 2344 HE (1.7 GHz), 4Gb RAM, 2x250GB HDD обойдется в $100, что сравнимо с арендой порта и места в стойке под сервер у нас в стране.

Очень нравится мне возможность ограничивать набор вводимых символов в полях ввода с помощью регулярного выражения.

Эта функциональность существует в Ext.JS, но этот каркас несколько тяжеловесен для большинства сайтов. Поэтому я нарисовал плагин для jQuery, выполняющий тот же функционал.

Перевод отличной статейки. Думаю, будет полезна как новичкам, которые только приступили к использованию jQuery, так и тем, кто уже какое-то время с ним работает. А кого-то, возможно, заставит глянуть эту чудесную библиотечку. Многие советы имеют отношение не только к jQuery, но и к JavaScript в целом. Лично для меня была весьма и весьма познавательной, посему и захотелось донести это «до масс». Перевод не дословный, но передающий смысл и максимально адаптированный к русскому языку.

Далее все написано от имени автора оригинальной статьи.

Введение

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

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

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

Содержание

1. Загружайте фреймворк с Google Code
2. Используйте «шпаргалку» (cheat sheet)
3. Соединяйте все ваши скрипты и уменьшайте размер файла
4. Используйте возможности Firebug для ведения логов
5. Минимизируйте операции выборки в пользу кэширования
6. Сводите манипуляции с DOM-деревом к минимуму
7. Оборачивайте все в единый элемент, когда речь идет о любой вставке в DOM
8. Используйте «id» вместо классов, где это возможно
9. Задайте контекст своим селекторам
10. Используйте последовательности вызовов методов с умом
11. Научитесь правильно использовать анимацию
12. Научитесь назначать и делегировать события
13. Используйте классы для сохранения состояния
14. Еще лучше — используйте встроенный в jQuery метод data() для сохранения состояния
15. Пишите собственные селекторы
16. Подготавливайте HTML и модифицируйте его, когда страница загружена
17. Используйте «отложенную загрузку» (lazy loading) для определенного контента для выигрыша в общей скорости и преимуществ для SEO
18. Используйте служебные функции jQuery
19. Используйте «noconflict» для переименования глобального объекта «jquery», когда используете его с другими фреймворками
20. Как узнать что картинки загружены?
21. Всегда используйте последнюю версию
22. Как проверить, что элемент существует?
23. Добавляйте класс «JS» в элемент «html»
24. Возвращайте «false» для отмены поведения по-умолчанию
25. Короткая запись для события готовности документа

Хочу поделиться простым, но эффективным алгоритмом определения нечетких копий документов. Есть много статей об использовании для этой цели алгоритма шинглов. Ходят слухи, что большие поисковые системы используют очень похожий алгоритм у себя. Однако, все признают, что шинглы плохо подходят для коротких (3-5 предложений) документов. А в моей задаче надо было работать именно с такими документами. В качестве решения предлагают закольцовывать текст, чтобы как бы сделать из него длинный, но мне кажется, что это не очень правильное решение, точность распознавания дублей все равно будет низкая.

Итак, описание алгоритма, который я использовал:

Какое-то время назад потребовалось перенести проекты с выделенного сервера на VPS. Для этих целей был выбран slicehost. В общем и целом контора нравится и готов её рекомендовать всем.

Случилась лишь одна проблема: начали приходить уведомления о слишком сильном использовании диска (чтение/запись). Долгое время проблема не находила решения из-за отсутствия времени, но это вылилось в непонятные отказы, сопровождавшиеся статистикой в >200% CPU usage. После долгих извращений, была найдена проблема, а затем и её решение.