Вступление

Здравствуйте, уважаемые читатели! Для многих джанго-разработчиков не секрет, что с версии 1.3+ вместо используемых ранее generic views нам необходимо начинать использовать class based views. А с 1.4+ версии generic views вообще могут стать deprecated. Информация про class based views (далее CBV) в интернете довольно скупа (а в рунете и подавно). Нет, конечно есть превосходные статьи, в том числе тут на хабре. Одна из статей была опубликована буквально на днях. Но я отношусь к той категории людей, что привыкли все изучать на практике и данный топик написан для таких же людей.
В качестве практического задания мной был выбран классический вариант — создание блога. Для того, чтобы использовать возможности CBV по максимуму мы немного усложним задачу. Пусть это будет не просто блог, а блог, с возможностью публиковать приватные статьи, недоступные неавторизованным пользователям.
Дальнейшие рассуждения подразумевают, что читатель ознакомлен с фреймворком Django и имеет навыки в создании проектов.

Доброго времени суток, уважаемые читатели! Не так давно мной была опубликована первая часть статьи на данную тему. Я хочу еще раз поблагодарить всех пользователей, высказавших конструктивную критику, благодаря которой примеры в статье удалось привести к почти идеальному виду. В то же время я понял, что данный формат подачи материала является неэффективным: мы рассмотрели всего пару методов, реализованных в Class Based View (далее по тексту CBV). Во второй части я решил переработать подачу и далее постараюсь описать максимально возможное количество методов, представленных в API. Постараюсь, также, охватить те методы, которые были упущены в первой части. Очень надеюсь на конструктивную поддержку читателей и надеюсь, что и в дальнейшем у нас получится продуктивный диалог, в результате которого статья станет еще более информативной.

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

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

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

Итак, правила были объявлены и неделя прошла в работе.

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

Цель статьи рассказать о своем поиске «идеального» редактора для python кода, о том почему выбрал emacs и кратко о том как я его (emacs) настроил для работы с python.

Небольшая предистория: Разработкой на python я занимаюсь уже более двух лет и все это время пытался подобрать оптимальный редактор. Что я только не использовал за это время — mcedit, nano, gedit, netbeans, eclipse, а также некоторые другие платные варианты (демо версии). Но всегда чего то нехватало, где то автокомплита, где то подсветки, где то банально неудобно. Какой то период (около 10 месяцев) использовал Eclipse, но его прожорливость в ресурсах, зависания доводили до белого каления. Когда ошибки eclipse мне окончательно надоели, я начал поиски такого редактора который стал бы отличным помошником в работе.
Вооружившись google начал искать «идеальный» редактор.

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

Вопрос: Почему поиск в python dict на больших объемах данных быстрее чем итерация по индексированному массиву?

Ответ: В dict хранятся хэши от ключей. Каждый раз, когда мы ищем в dict значение по ключу, мы сначала вычисляем его хэш, а потом (внезапно), выполняем бинарный поиск. Таким образом, сложность составляет O(lg(N))!

На самом деле никакого бинарного поиска тут нет. И сложность алгоритма не O(lg(N)), а Amort. O(1) — так как в основе dict питона лежит структура под названием Hash Table.

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

В последнее время все больше «ходят» разговоры про новомодные алгоритмы, такие как нейронные сети и генетический алгоритм. Сегодня я расскажу про генетические алгоритмы, но давайте на этот раз постараемся обойтись без заумных определений и сложных терминах.
Как сказал один из великих ученных: «Если вы не можете объяснить свою теорию своей жене, ваша теория ничего не стоит!» Так давайте попытаемся во всем разобраться по порядку.

Регулярные выражения (РВ) это, по существу, крошечный язык программирования, встроенный в Python и доступный при помощи модуля re. Используя его, вы указывается правила для множества возможных строк, которые вы хотите проверить; это множество может содержать английские фразы, или адреса электронной почты, или TeX команды, или все что угодно. С помощью РВ вы можете задавать вопросы, такие как «Соответствует ли эта строка шаблону?», или «Совпадает ли шаблон где-нибудь с этой строкой?». Вы можете также использовать регулярные выражения, чтобы изменить строку или разбить ее на части различными способами.

Emacs. Большая и сложная программа. Ему как ничему другому подходит это определение. Эмакс был создан очень давно в лаборатории искуственного интллекта MIT, он несет в себе гены очень своеобразной культуры лисп-хакеров былых времен. С тех пор он не раз переписывался, улучшался, дополнялся и обрастал тысячами расширений в течение десятков лет. Эмакс, если и был когда-то мощным текстовым редактором, сейчас стал некоей универсальной программой, в нём можно делать абсолютно всё что угодно, если это хотя бы немного затрагивает собой задачу отображения или редактирования текста, и даже больше. Людям знающим универсальность играет на руку, ведь одной программой можно делать тысячу разных дел, при этом не прилагая усилий для переучивания к разным интерфейсам. Людей, впервые запустивших эмакс подобная универсальность и непривычный интерфейс поначалу пугает. Научиться пользоваться эмаксом, понять его идею и проникнуться ею задача непростая, трудоемкая и долгая (как говорится, пологая кривая обучаемости).

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

Чем старше я становлюсь, тем менее важной становится запятая. Пусть читатель сам решает, где ему ставить паузы. — Elizabeth Clarkson Zwart

Примерно так я комментировал свой код двадцать лет назад (внимание, чуток драмы):

/*
 * Когда мы дойдем сюда, наша структура уже будет готова. 
 * К тому же, мы создали достаточно большой буфер, в который 
 * можно засунуть все входные данные, плюс есть немного места
 * про запас. Я не уверен, понадобится ли оно, но хуже не будет. 
 * Теперь нам надо обновить счетчик, предполагая, что клиент 
 * уже прочитал значение, но еще не использовал его. Сначала 
 * я хотел переложить обязанность инкремента на плечи вызывающего
 * кода. С другой стороны, это означает, что инкремент нужно делать всем, 
 * поэтому я решил, что будет лучше перенести его сюда. Но мы можем 
 * пересмотреть это решение позже, если вдруг кому-то из внешних функций 
 * захочется делать инкремент самому.
*/
counter++; // инкрементировать счетчик для потребляемого значения

/*
 * Теперь нужно просмотреть весь буфер с данными. Для этой 
 * операции нам понадобится еще один индекс, иначе перед 
 * выходом из функции мы потеряем начальное значение. 
 * Я хотел назвать эту переменную ‘ref’, потому что в некотором
 * смысле мы будем обращаться с ней как со ссылкой на данные. 
 * В конце концов я пришел к выводу, что самым лучшим  
 * названием для нее будет ‘pos’. Если что, я не против обсудить
 * это решение.
*/
char* pos = buffer; // начинаем наш обход данных

/*
Теперь, мы...
*/

Ну что, узнаете? А должны! Если быть предельно невежливым, весь код выше написал нуб. (Между прочим, если вы не знаете, кто такой нуб, значит вы — нуб).

Лет пять-шесть назад, когда я ещё программировал преимущественно на PHP, я начал использовать библиотеку curl для парсинга сайтов. Мне нужен был инструмент, который позволял эмулировать сессию пользователя на сайте, отсылать заголовки обычного браузера, давать удобный способ отсылки POST-запросов. Сначала я пытался использовать напрямую curl-расширение, но его интерфейс оказался очень неудобным и я написал обёртку с более простым интерфейсом. Время шло, я пересел на python и столкнулся с таким же дубовым API curl-расширения. Пришлось переписать обёртку на python.

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

Введение

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

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

Итак задача:
Организовать удобное администрирование многодоменного web сервера.
Модель системы: linux -> nginx -> apache -> php -> mysql.

Раньше у меня для каждого домена были отдельные конфиги для nginx и apache,
и для добавления нового хоста требовалось добавить как минимум 2 конфига.

Работа была организована удобно. По сути, были 2 скрипта. 1 для добаления хоста к nginx, другой для apache. (ещё есть скрипт добавления хоста в bind но это другая история).

Но и это было не удобно в условия добавления удаления хостов… иногда забыл nginx прописать, иногда в апаче чтото не то…
Решено было следующим образом:

Вместо эпиграфа.

Поймал дед золотую рыбку. Она ему говорит:
— Чего тебе, дед?
— Хочу чтоб мой аппарат был длиной до колен.
Взяла рыбка и укоротила деду ноги.
Мораль: ставьте корректно техническое задание.

Добрый день великий и могучий Хабр.
Некоторое время назад было несколько постов о технических заданиях (Как поставить задачу для простого (шаблонного) сайта, Почему мы никогда не составляем ТЗ. А что взамен?, Правила технического задания), которые хотелось бы продолжить и рассказать про мой подход к написанию ТЗ на шаблонные сайты.

В заметке ТЗ для web-разработчика автор пишет:

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

Никак не комментируя заметку в целом, хотелось бы сделать несколько замечаний по поводу разных способов представления информации в ТЗ и не только в нём.

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

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

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

Одним из способов разрешения такого конфликта является написание задания на проект – технического задания, которое предполагает полное и точно изложение требований внутрифирменного заказчика и является своеобразной инструкцией для IT -специалиста.