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

Upd 1: изменил несколько категоричное утверждение о несходстве паттерна Декоратор и одноимённой языковой конструкции на более мягкое.

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

Дорогой Хабр!



У нас для тебя небольшой подарок. Мы тут работали-работали и вот чего сделали.
Сняли и опубликовали почти тысячу лекций по IT и математике.

UPD2 Помогите, пожалуйста, оперативно решить вопрос насчёт организации торрентов на php.

Доброго времени суток!

Введение

В своё время было необходимо сделать заметки в форме стикеров для веб-сайта. Как вы понимаете, выбора большого особо не было и мой выбор пал на всеми нам любимый CSS3. С его появлением осуществление задуманного стало возможным без какого-либо велосипедостроения. Итак, моё решение проблемы под катом. На самом деле, мопед не мой. Мне дали всего-лишь покататься.

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

Недавно взглянул на сорцы Farseer Physics Engine. Стало интересно как в этом движке реализован динамический объект. Как и ожидал, не встретил там привычных мне дифференциальных уравнений и их дискретных реализаций в виде разностных уравнений или дискретных моделей пространства состояний. Главная отмазка заявляемая причина отказа от «честной» механики во многих игровых физических движках — излишняя сложность работы с дифференциальными уравнениями и слишком большая вычислительная нагрузка.

Является преждевременная оптимизация дорогой в ад? Или подход «потом исправим» превращает программистов из «специалистов» в презираемую всеми «школоту»?

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

Не так давно мне нужно было быстро поднять маленькую виртуалку под Linux, чтобы проверить переносимость одного модуля в своем приложении, написанного на Java и вызывающего Oracle SQL Loader через java.lang.Process API.

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

Установка Oracle Enterprise Edition под Ubuntu это задача не на 5 минут. Полная и точная (по словам автора — я сам пробовал многочисленные похожие инструкции, все равно полностью без ошибок поставить ни разу не удавалось) инструкция находится здесь — www.excession.org.uk/blog/installing-oracle-on-ubuntu-karmic-64-bit.html. Сравните, насколько это геморройнее и сложнее, чем установка того же Oracle EE под Windows — там запустил OUI (Oracle Universal Installer) и следуешь его указанием. Короче, отличный пример протекающей абстракции в Linux среде (хотя, казалось бы, user-friendly дистрибутив) в духе Джоэля Спольски.

Но для Express (XE) версии есть все же человеческое решение.

Работая в команде я люблю быть в курсе активности участников. Поэтому было решено написать демона наблюдающего за поступлением новых коммитов в репозиторий git’а. Так как я работаю в Ubuntu, то уведомление было реализовано встроенным способом — библиотекой libnotify.
Язык — Python!



В статье упоминается:
1. Демон на Python;
2. Логирование на Python;
3. Хранение конфигурационных файлов программ на Python;
4. Работа с командами ОС из скриптов Python;
5. Получения списка последних изменений из git’а;
6. Стандартные всплывающие уведомления Ubuntu.

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

Начало

Так сложилось, что на текущем месте работы программисты предоставлены самим себе. То есть, конечно, кодят на благо предприятия, но совершенно бесконтрольно, вплоть до отсутствия банального тестера. ТЗ даже на «тяжелые» программы редко превышает объема в три листа А4 (один из которых — подписи всех причастных).

Звонки по поводу проблем с ПО направляются напрямую программистам. С этого всё и началось.

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

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

Большинство провальных проектов обладают одной закономерностью. Они абсолютно лишены структуры. Я называю архитектуру таких систем «пластилиновой».

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

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

Теперь давайте посмотрим, как поступит в этом случае типичный джуниор. Есть задача – её надо решить. Их так учили в университетах. Многие из них ещё находятся под влиянием маргинального лозунга «пиши код, б##дь!». Итак, он наливает себе растворимого кофе, надевает наушники с чем-нибудь пожёстче и погромче и уходит в поток на пару-тройку часов.

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

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

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

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

Здравствуйте, Хабросообщество!

На хабре есть описание множества интересных структур данных, таких как деревья отрезков, дуча и т.п. Если Вам интересны сложные структуры данных, то добро пожаловать под кат!

В этой хабрастатье на примере паттернов Наблюдатель и Компоновщик рассмотрено, как применять принципы объектно-ориентированного программирования, когда стоит использовать композицию, а когда наследование. А так же рассмотрено, какие существуют способы повторного использования кода, кроме copy-paste.

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

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

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

Не раз проскакивали сравнения сложности построения интерфейсов на Qt. В данной статье приведу пример, как можно сделать список в стиле списка модулей FireFox.



Для этого воспользуемся MVC подходом, который реализован в Qt. На выходе получим что-то вроде этого:


Весь процесс разделим на 3 части:

1. создание модели
2. создание делегата
3. создание представления

Вашему вниманию представляю свой вольный перевод, обещанный г-ном Takezo в его комменте о будущем ИИ в GameDev.

Введение

Прикольно наблюдать за внутриигровой визуализацией, особенно если ты сам ее и создал! Однако, в погоне за этим ярким впечатлением легко забыть, что не нужно визуализировать все подряд.
Ниже вы найдете видео туториал по визуализации геймплея и ИИ, записанный в секретной исследовательской лаборатории AiGameDev.

Это уже четвертая заметка, где я хочу поделиться полезными наблюдениями о паттернах ошибок и том, как можно с ними бороться. В этот раз я затрону такую тему, как обработка редких и аварийных ситуаций в программах. Рассматривая множество программ, я пришел к выводу, что код обработки ошибок в Си/Си++ программах — одно из самых ненадежных мест.
К чему приводят такие дефекты? Программа, вместо того, чтобы выдать сообщение «файл X не найден», падает и заставляет пользователя гадать, что он не так делает. Программа для работы с базой данных выводит невразумительное сообщение, вместо того, чтобы сообщить, что неверно заполнено одно из полей. Попробуем сразиться с этой разновидностью ошибок, которые досаждают нашим пользователям.