Динамическое программирование является довольно важным подходом в решении многих сложных задач, основанным на разбиении задачи на подзадачи и решении этих подзадач единожды, даже если они являются частью нескольких других подзадач. Перед людьми, которые только начинают овладевать функциональным программированием часто возникает вопрос: «как избежать повторного решения подзадач, если не использовать переменные для сохранения результатов?». В этом вопросе одна особенность функционального программирования — отсутствие переменных — мешает кешировать результаты решения подзадач, но другая особенность поможет — ленивые вычисления.

Недавно у нас были небольшие обучающие курсы для повышения нашей компетенции в сетевой части нашей инфраструктуры. Основную идею этих курсов, покрывающую OSPF/BGP/MPLS я тут повторять не буду ибо:

• Пока ещё явно недостаточно компетентен.
• Есть много более объективные ресурсы рассказывающие об этих темах.

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

Ссылки на вики зачастую более примечательны секциями «External links» и «References» нежели самим содержанием

Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).

Судя по всему, неделя исключений на хабре успешно наступила :). Накопив достаточную «подушку» кармы чтобы не бояться уйти в минус, я, пожалуй, тоже выскажу свое мнение по данному вопросу. Сразу оговорюсь, что мнение сугубо личное, основанное на небольшом практическом опыте коммерческой разработки: C++, Objective-C, C#, Java, Python, Ruby.

Совсем недавно издательство No Starch Press подготовило и выпустило печатное издание замечательного учебника Learn You a Haskell for Great Good! (онлайн-версия), написанного Miran Lipovača.

Я хочу представить вам самый актуальный перевод главы 11 Аппликативные функторы, оригиналом для которого послужило именно издание от No Starch Press, адаптированное для печати.

Вчера я опубликовал перевод топика «Прокрастинация разрушила мою жизнь» одного из североамериканских хлопцев с Hacker News. Сегодня вы можете ознакомиться с интересными ответами HN-юзеров.

юзер Isamu

Психолог Пирс Стил в своей книге «Уравнение прокрастинации» считает, что проблема заключается не в перфекционизме, а в импульсивном управлении.
Хотя у вас нет проблем с тем, чтобы начать работу, прокрастинация начинается позже. Вот мой конспект книги:

Знакомо ли вам такое состояние, когда вы настолько увлечены идеей, что полностью погружаетесь в процесс ее реализации, забывая о времени и окружающем мире? А завершив, испытываете радость и даже счастье? Значит, у вас есть опыт потоковых состояний – особых ресурсных состояний сознания, когда все внимание сфокусировано на цели, и в результате замечательные идеи рождаются сами собой, и время концентрируется, вмещая гораздо больше, чем в обычном состоянии.
Тема эффективности потоковых состояний для работы и творчества уже несколько раз поднималась на Хабре, и в этой статье мы хотим обсудить практическую часть – что необходимо для того, чтобы вызывать это состояние «на заказ»?

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

Некоторым везет. Вы точно знаете такого. У него на столе широкоформатный монитор, которым можно заменить экран в кинотеатре. Компьютер, приютившийся под дорогим дубовым столом, мощнее WOPR из старого фильма «Военные игры». И, конечно же, не забываем, что всё это в отдельном кабинете, в котором даже можно закрыть дверь на ключ (само собой, по исключительно важным поводам). И если вам людишкам из-за офисных перегородок этого мало, то вспомните, что этот чувак отвечает за самые крутые проекты и использует самые сексуальные и новейшие технологий. Он из тех, кем все прочие смертные тоскливыми ночами мечтают быть, вместо того чтобы спать. Но какого же ему так везет?

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

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

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

В этом топике пойдет речь о задаче Прима-Краскала (“жадный алгоритм”) и ее решении на языке «Пролог».

Начали!

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

Классификация

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

Сэм Арон (Sam Aaron), один из разработчиков Overtone, выложил впечатляющее видео, как он синтезирует мелодии в редакторе Emacs, используя различные приёмы — триггеры инструментов, назначение будущих событий и проектирование сэмплов — на языке Clojure. Музыка звучит сразу после написания строчки кода (live coding).

Т.к. с недавних пор сервис документации по html5 diveintohtml5.org Марка Пилгрима лежит — я решил поднять свой с преферансом и дамами на платформе гугла. Все доки оказались доступны на гитхабе и там лишь статические файлы, потому никаких проблем не возникло. Единственно из-за ограничений гугле на максимальный размер файла 10МБ не влезли два видео, но влезла их копия в формате webm.
Наслаждаемся.
UPD: заменил видео на более мелкие тех же форматов, и поправил пару недочетов с API геолокации гугла.

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

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

Заранее предупреждаю и извиняюсь, но оно того стоит: букаф многа.

Введение

В средней школе я был «круглым» двоечником, которого переводили в следующий класс только под значительным влиянием моего отца, в то время проректора ФПИ, довольно влиятельного (в личном общении) и властного человека.

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

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

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

        Доброго времени суток!
        Как известно, одной из важных задач, решаемых обработкой изображений (помимо сброса пары кг и укрывания дефектов кожи на аватарках), является поиск и распознавание нужных нам объектов на сцене. Но этот процесс весьма сложный и ресурсоемкий, что делает его неприменимым в системах реального времени. Сегодня мы и поговорим, нельзя ли каким-то образом решить эту проблему и ускорить процесс поиска нужного объекта на сцене, с минимальными потерями в точности (а может, и без них вовсе). И вообще, причем тут папоротники?
PS
Традиционно много картинок.

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

Пост в первую очередь предназначен для тех, кто не знаком с Pivotal Tracker, или тех кто считает его сложным и непонятным.