Всем здрасьте.
Твиттером давно пользуется добрая половина Хабра. Я, ископаемое, сегодня узнаю, что количество букв в каждом сообщении жёстко лимитировано. В голове тут же рождается короткий хелп, которым спешу поделиться. За банальность просто проходите мимо )

К чему все это

Итак, снова о вечном, об организации почтового сервера в организации средних размеров. Казалось бы, что в этом сложного, берешь любой линукс дистибутив, ставишь любой проверенный временем пакет почтовых программ (MTA, MDA, антивирус, антиспам) и забываешь про него. Но вместо сладкой жизни сразу получаешь потоки спама как на входе, так и на выходе (если здоровье вашей внутренней сети оставляет желать лучшего). А вместе с тем жалобы пользователей на спам, на неотправляющуюся почту и пр. У системных администраторов-новичков здесь могут опустится руки. Но, есть простой и достаточно элегантный выход из сложившейся ситуации — позвать на помощь Большого Брата, то есть Google и спрятаться за его широкими плечами. В предлагаемом решении службы Google используются как резервное хранилище почты, спамфильтр и антивирус, с чем они прекрасно и справляются, что вам может подтвердить любой пользователь gmail.

Plone — CMS с открытым исходным кодом, написанным на Python. Базируется на Zope.

На Plone легко создать как небольшой сайт-визитку, так и целый портал, например, новостной. Редактирование информации происходит прямо на сайте (без помощи всяких панелей). А на Plone 3.x вообще все можно редактировать на лету с помощью внедренной AJAX-технологии.

В России существует несколько компаний, предлагающих уже готовый Plone-сайт или доступ к ZMI (интерфейсу управления Zope), с помощью которого в три клика создается новый сайт на Plone.

Итак, пойдем по алфавиту:

www.2x.ru (2x Hosting)

От 200 рублей в месяц. 150 мегабайтов места. Plone 2.5.1

www.bitwave.ru (BitWave)

От 300 рублей в месяц. 500 мегабайтов места. Plone 2.5.5.

www.komtet.ru (Комтет)

От 240 рублей в месяц. 250 мегабайтов места. Plone 2.5.5, 3.1

www.prosvet-dv.ru (PROSVET DeVelopment)

От 150 рублей в месяц. 300 мегабайтов места. Plone 2.5.5, 3.1

www.summatech.ru (Сумма технологий)

От 240 рублей в месяц. 400 мегабайтов места.

Для сравнения выбраны самые простые и дешевые тарифы. На этих тарифах дается только один Plone сайт. Управление осуществляется только из интерфейса Plone и из ZMI. Нет доступа к консоли, то есть нельзя устанавливать свои продукты и работать с файловой системой. В принципе, для простого сайта на Plone этого и не требуется.

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

Многие пользователи Linux рано или поздно сталкиваются с bash-скриптами. До недавнего времени я не знал как можно использовать графический интерфейс в скриптах. Оказывается очень просто.

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

Мы будем использовать библиотеку zenity (ещё есть kdialog ). У меня она была уже установлена. Набираем в консоли zenity --help или man zenity.

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

Доброго времени суток. Этот топик рассчитан на тех, кто имеет представление об ограниченных машинах Больцмана (restricted Boltzmann machine, RBM) и их использовании для предобучения нейронных сетей. В нем мы рассмотрим особенности применения ограниченных машин Больцмана для работы с изображениями, взятыми из реального мира, поймем, почему стандартные типы нейронов плохо подходят для этой задачи и как их улучшить, а также немного пораспознаем выражения эмоций на человеческих лицах в качестве эксперимента. Те, кто представления o RBM не имеет, могут его получить, в частности, отсюда:

Реализация Restricted Boltzmann machine на c#,
Предобучение нейронной сети с использованием ограниченной машины Больцмана

Я давно хотел написать какую-нибудь сетевую игру на bash, причём желательно, чтобы управление было удобное, с клавиатуры, обычными курсорным клавишами. Вообще, тема интерактивного взаимодействия в bash глубже, чем «введите число, нажмите „Enter“» не раскопана. Мне пришлось всё изобретать и исследовать самостоятельно. Я очень старался найти что-то похожее по уровню интерактивности, но не нашёл.

Поскольку тонкости управления с клавиатурой съели очень много моего времени, я не стал заморачиваться с тонкостями совместимости, поэтому игра тестировалась только под Mac OS X, есть ненулевая вероятность, что она заработает и под Linux и уж точно её можно допилить там до рабочего состояния.

Для работы игра требует наличия nc (aka Netcat) и терминала с поддержкой 256 цветов (под Mac OS рекомендую iTerm2). При наличие интереса к игре, допилю до терминала на 16 цветов и /dev/tcp. Кстати начал выкладывать все свои шел-поделки на ГитХаб.



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

Играть просто — в каждый момент времени активна только одна доска (на скриншоте — правая, у неё буквы и цифры вокруг доски ярче), на активной доске курсор двигается курсорными клавишами — ←, →, ↑ и ↓, взять фигуру и поставить её на доску — по клавише пробела или Enter. Как только вы поставили фигуру на доску, ход переходит к сопернику. «Съесть» фигуру соперника проще простого — достаточно поставить свою фигуру на чужую. В игре есть защита — нельзя «съесть» свою фигуру.

Ничего помимо этого в игре нет — не производится правильность контроля ходов, нет проверки на завершение игры, можно даже ходить фигурами соперника. Было очень сложно придумать как обрабатывать нажатия в shell, так что остальное сделать я просто не успел, не поместилось в формат «игрушка за вечер».

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

Привет, хабралюди! Кто из вас не мечтал создать свою игру? А возможно ли написать браузерную стратегию, не имея при этом опыта и денег? Возможно, если очень этого хотеть.

Под катом моя история создания бесплатной пошаговой стратегии.

Всем добрый день!

На Хабре уже поднималась тема организации работы с внешними пакетами с использованием подмодулей или деревьев в Git. Это показалось хорошим решением, но на деле вылилось в неудобства и запутанность. Тогда я решил перенести всё на python-пакеты. Чем и поделюсь сейчас на примере Django приложения.

С тех пор как я настолько обленился что стал заваривать чай прямо в кружке, я начал пользоваться апплетом teatime. Уже после третьего дня там завелась настройка «Пельмени». Разумеется, не лучшее решение, если учесть особенности техпроцесса варки этого замечательного блюда.
Так как писать апплет мне тоже было лень, я решил набросать крошечный скриптик для напоминаний.

Итак, постановка задачи

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

Реализация

При попытке отредактировать этот старый пост слетело всё форматирование. Может быть я его когда-нибудь исправлю.

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

Основные преимущества:

• Делая push из удалённой копии мы автоматически обновляем live-копию сайта
• Правки файлов на сервере не будут разрушать историю коммитов
• Простота, не нужны особые правила выполнения коммитов
• Можно применить к уже запущенному сайту, без повторного деплоя или перемещения файлов

Стандартная статья о нечеткой логике обычно грешит двумя вещами:

1. В 99% случаев статья касается исключительно применения нечеткой логики в контексте нечетких множеств, а точнее нечеткого вывода, а еще точнее алгоритма Мамдани. Складывается впечатление, что только этим способом нечеткая логика может быть применена, однако это не так.
2. Почти всегда статья написана на математическом языке. Замечательно, но программисты пользуются другим языком с другими обозначениями. Поэтому оказывается, что статья просто непонятна тем, кому, казалось бы, должна быть полезна.

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

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

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

Я уже некоторое время ковыряю TDD и задача постоянного контроля качества для меня становится всё актуальней. Особенно при пополнении команды новыми разработчиками.

Сначала я запускал тесты руками: save, switch, $ nosetests. Потом к тестам добавились проверялки качества кода и пришлось всё засунуть в скрипт:
pyflakes *.py
pep8 *.py
pylint *.py
nosetests

Скрипт запускать каждый раз ужасно лениво, поэтому небольшая оболочка на inotifywait стала запускать тесты и проверки после каждого сохранения:
while true; do
inotifywait -e modify project/*.py -qq; clear
./do_tests
done

Тут я стал более-менее доволен происходящим и даже на некоторое время расслабился. Но ведь программист кроме того, что ленив ещё и горд, поэтому результаты хочется кому-нибудь показать. Чтобы вести историю происходящего (которая очень помогает когда заходит начальник начальника и спрашивает: «ну-с, чем вы занимались последний месяц?») уже есть система контроля версий. Но она показывает только, что сделано и не даёт обзора успешности каждой ревизии. Получается что код лежит, но непонятно в каком он состоянии и что где ещё надо сделать.

Кроме того довольно тяжело следить за коллегами, которые тоже могут что-то сделать и забыть прогнать тесты, в результате в репозитории лежит битый код, не прошедший code review и при очередном pull может внезапно начаться clusterfuck.

И тут очень вовремя kmmbvnr@lj выпустил скринкаст, в котором он демонстрировал интеграцию тестирования для django-проектов с сабжем Jenkins (бывш. Hudson). Посмотрел я на все эти красоты, графики и отчёты и тоже захотел чтобы всё само пело и играло. Но у него django-jenkins, как и следует из названия, встраивается в джангу и генерит отчёты используя хитрую систему. Мой проект до джанги не дорос и скорее всего не дорастёт — это достаточно тривиальное WSGI-приложение, которое правда стремительно разрастается. Пришлось поднимать всё с нуля.

Воскресенье я на это убил, но в целом всё довольно прямолинейно и теперь у меня есть симпатичные отчёты:



Что внутри?

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

Сдача результатов работы является одним из самых драматических этапов проекта. Человеко-месяцы, потраченные на разработку, отладку, тестирование и внедрение вашего решения, не должны быть потрачены зря. Если сдача работ поручена вам, то ваша роль в команде весьма значительна, а доверие руководства велико, даже если начальники вам этого никогда не говорили. Облажаться на сдаче работ иногда означает конец вашей блистательной карьеры. Так что лучше этого не делать.

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

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

На Хабре много статей о завершённых проектах (стартапах), советов как стать успешным и как доделать игру. Мне, к сожалению, довелось поучаствовать и в нескольких незавершённых проектах.

Так вот, советы как завалить проект:

1) Если вам в проекте нужна графика, каждый человек в команде должен попробовать себя в роли художника. Если задание отдано одному художнику, всем обязательно нужно принимать участие в обсуждении результата, давать советы и вообще всячески помогать. Художнику при этом нужно постоянно перерисовывать и править, дабы угодить всем сразу. Вообще, демократия – лучший метод для решения всех задач в проекте.

2) Концепт не нужен, зачем тратить время? Главное, начать как можно быстрей писать код, а идеи и концепт обязательно придут в пути. Кто быстрей начнёт программировать, сможет забронировать самые интересные задания.

3) Очень важно менять существенные вещи примерно в середине проекта, а лучше несколько раз. Ведь нужно было срочно программировать, и выбрали не ту технологию, не тот способ, 3D графику вместо 2D.

В .bashrc можно описывать функции.

К чему это я? Если вам не хватает alias, не обязательно писать однострочный скрипт.

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

Введение

Имплементация Cocos2d на Objective-C используется для разработки игр для iPhone весьма широко. По данным официального сайта число игр на этом движке уже превышает 1800. Не раз упоминался он и на Хабре. Другие порты (cocos2d-x на C++ и cocos2d-android на Java) также известны и набирают популярность. Однако прародитель этих движков, оригинальный Cocos2d оказался незаслуженно обойден вниманием. Попробую восполнить этот пробел.

Хочу поделиться опытом настройки сервера для django-проектов. Так вышло, что мне часто приходится настраивать с нуля VPS-сервера для запуска на них django-сайтов. Как-то мне в голову пришла идея записать пошагово процесс настройки. Оказалось, что “по бумажке” выполнять эти рутинные операции гораздо проще и быстрее — все нюансы записаны, трудно что-то упустить. Дальше больше — я превратил инструкцию в самостоятельный shell-скрипт — запустил и сервер готов. Я думаю, некоторым python-разработчикам, особенно начинающим, будет полезно ознакомиться с содержимым скрипта. С некоторыми доработками вы, возможно, захотите использовать его в своей практике.