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

И крайне редко обсуждается вопрос о необходимости этого самого фулвью.

В последнее время мировую IT-прессу буквально захлестнули патентные «новости». Чуть ли не каждый день мы читаем о компании А., запатентовавшей что-то-там, и о компании Б., подавшей в суд на компанию В. Я не знаю причин по которым в общем-то узкоспециализированная и достаточно нудная тема стала интересна широкому кругу читателей, но вижу насколько ошибочны представления очень многих людей, судя по разворачивающимся вокруг патентных новостей дискуссиям. В данной статье я хотел бы рассказать о некоторых часто встречающихся заблуждениях, причем рассказать популярным языком, не скатываясь с одной стороны в юридические дебри, а с другой — в желтизну вроде «Эппл — патентный тролль».

Самое часто встречаемое заблуждение — рассмотрение патента в качестве наступательного оружия. Вася запатентовал колесо? Значит Вася начнет днем и ночью искать всех остальных производителей колес и вставлять им палки в продукцию. Это не так. За исключением единичных адвокатских контор (настоящих патентных троллей!), IT-компании никогда не оформляют патенты для наступления/наезда на других, это попросту не вписывается в бизнес-процесс. Главных причин написания патентов всего три: паритет, давление и привлекательность для инвесторов.

Американский дизайнер представил реверсию брендов.
В своем проекте Грэхэм Смит поменял местами логотипы и дизайн конкурирующих компаний и известных брендов.

Flash-память остается доминирующим видом энергонезависимой (то есть сохраняющей информацию в отсутствии электрического тока) памяти благодаря широкому использованию в твердотельных накопителях (SSD) и привычных каждому USB флеш-накопителях. Но, несмотря на ее популярность и повсеместное использование, технология все еще остается проблемной, особенно если норма производства опускается ниже 30нм-процесса — скорость работы флеш-памяти снижается. Вдобавок к этому — ограниченное количество циклов записи-стирания и относительно низкая скорость самой записи (в миллисекундах). Из-за всех этих ограничений, исследователи уже давно ищут эффективную замену флеш-памяти для производства вышеупомянутых продуктов.

В настоящий момент существует несколько альтернативных разработок, которые вполне могли бы заменить кремниевую флеш-память, такие как PRAM (phase-change RAM), FeRAM (ferroelectric RAM), MRAM (magnetoresistive RAM) и RRAM (resistance-change RAM). Однако до сегодняшнего дня ученым различных университетов и компаний так и не удалось успешно применить текущую технологическую норму в производстве памяти по любой из этих технологий — либо механизм переключения режимов, либо сама платформа теряет эффективность и скорость на уровне «нано». Плюс к этому, ни одной из этих разработок не хватает таких важных в коммерческом производстве характеристик, как увеличение циклов записи-стирания (по-сравнению с флеш-памятью), долгосрочности хранения данных в отсутствии тока и высокой скорости переключения между режимами чтения/записи. Именно качественный и количественный рост этих показателей считается основным требованием в разработке энергонезависимой памяти следующего поколения.

А еще, не развлечения ради, исследователи планируют заменить эту технологию целиком. Совместная группа ученых из Samsung и корейского Sejong University недавно опубликовали занятную публикацию в журнале Nature Materials, описывающую новую технологию производства RRAM (resistance-change RAM это технология, позволяющая менять напряжение ячеек так, что ее состояние меняется с низкого сопротивления (высокая проводимость) на высокое сопротивление (низкая проводимость)) из оксида тантала (TaO_x), который в тестах показал огромное преимущество над существующими технологиями, побив результаты почти по всем пунктам.

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

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

Позвольте, дорогие мои хабралюди, поделиться с вами основами моего любимого тренинга, посвящённого умению слушать.

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

В данной статье мне хотелось бы предложить несколько вариантов того, как стоит создавать статьи, как их подавать и как поддерживать жизнь своей статьи.

10 сентября 2012 года завершился чемпионат по программированию Russian Code Cup 2012. Подробный рассказ о том, как все происходило, публиковался ранее, а сегодня мы разберем задачи, которые были предложены финалистам. Их было всего шесть, и каждая из них — отдельная интересная история:

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

На решение этих задач выделялось три часа. Единственным решившим пять задач из шести оказался победитель Russian Code Cup 2012 Владислав Епифанов. Чуть менее половины финалистов решили по четыре задачи. Первые три задачи сделали почти все. Задачу про колоду карт правильно решил только один Евгений Капун. Второе место на турнире заняла Наталья Бондаренко, решившая четыре задачи быстрее других и с меньшим числом попыток.

Пару месяцев назад я рассказывал о приближенных результатах в задаче о сворачивании РНК. Напомню требуется свернуть вироидный рибозим NC_003540 организма Chrysanthemum chlorotic mottle viroid, третичная структура которого неизвестна.

И вот оно свершилось — рибозим свернулся ! (В нем образованы все имеющиеся водородные связи)

Смотрим его конечное состояние, а под катом еще его траекторию сворачивания, а также подводим итоги.

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

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

Ниже показан результат обработки реального размытого изображения (не с синтетическим размытием). Исходное изображение было получено камерой Canon 500D с объективом EF 85mm/1.8. Фокусировка была выставлена вручную, чтобы получить размытие. Как видно, текст совершенно не читается, лишь угадывается диалоговое окно Windows 7.



И вот результат обработки:



Практически весь текст читается достаточно хорошо, хотя и появились некоторые характерные искажения.

Под катом подробное описание проблем деконволюции, способов их решения, а также множество примеров и сравнений. Осторожно, много картинок!

После написания этого поста, меня заинтересовали параметры поиска которые можно использовать, для удобной работы.
Задавшись этим вопросом, в рунете я более менее полной информации не нашел.
Но! Оказывается Google уже давно и для всех, все показал.

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

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

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

В последнее время на Хабре часто начали появляться статьи о ASP.NET MVC. Однако в этой статье я бы хотел сделать несколько заметок по поводу построения приложений на вышеприведенном фреймворке: минимальный набор NuGet-packages (без которых грех начинать работу), логирование, подводные камни при использовании стандартных membership-, profile- провайдеров. И, напоследок, почему Web API из MVC 4 — то, что так долго мы все ждали.

Большинство программистов, которых нелегкая судьба свела с платформной.Net знают о существовании значимых типов (value types) и ссылочных типов (reference types). И довольно многие из них прекрасно знают, что помимо названия, эти типы имеют и другие различия, такие как расположение объектов оных типов в памяти, а также в семантике.

Что касается первого различия (о котором стоит упомянуть как минимум ради полноты изложения), то оно заключается в том, что экземпляры ссылочных типов всегда располагаются в управляемой куче, в то время как экземпляры значимых типов по умолчанию располагаются в стеке, но могут мигрировать в управляемую кучу вследствие упаковки, будучи членами ссылочных типов, а также при использовании их в хитрых экзотических конструкциях языка C#, типа замыканий (*).

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

Предисловие

Я уже долгое время ничего не исследую, так сказать ушел на покой. Но тут мне на глаза попалась очередная поделка немало известного в определенных кругах PE_Kill'a. Т.к. мне довелось решать его предыдущую поделку в рамках CRACKL@B Contest 2010, которая в свою очередь была довольно интересна, я решил взглянуть на его новое «детище».

Что вас ждет под катом: подделка CRC32, брут ключа для RC4, факторизация для RSA, а также использование коллизии для MD4 и генерация двух разных сообщений с одинаковыми хешеми. Всё это и многое другое под катом.

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-сентябрь 2011. В связи с повышенной конференционной активностью этой осенью вышла пауза с публикациями, но дальше такого наплыва мероприятий не будет.

Вступление

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

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

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

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

Большинство компиляторов на текущий момент являются чёрными ящиками — они превращают исходный код в объектные файлы или сборки. Цель “Roslyn Project” от компании Microsoft — открыть компиляторы Visual Basic и C#, дав разработчикам возможность пользоваться API, предоставляющим SyntaxTree, Emit API, Symbol API, Binding & Flow Analysis API. Над API надстраивается множество полезных сервисов:


Roslyn можно использовать для генерации кода, анализа и оптимизации, а так же поддержки сценариев и интерактивного использования VB и C#. На днях вышел Microsoft “Roslyn” October 2011 CTP, который уже можно скачать и попробовать на деле. Под катом подборка ссылочек по теме.

На Хабре уже были статьи об OpenCL, CUDA и GPGPU со сравнениями производительности, базовыми понятиями и примерами, поэтому рассказывать об основах и принципах работы я тут не буду, даже код не покажу. Но я хочу описать в чем заключаются реальные трудности при использовании GPU (про ограничения и их последствия), почему нельзя сравнивать производительность CPU и GPU, а также про то насколько “универсален” OpenCL на самом деле.

Эта статья посвящена основам программирования на OpenCl. OpenCl -это язык программирования на GPU/CPU, по своей структуре близкий к стандарту c99. Его развитием занимается Khronos Group, где на их сайте доступна полная документация. Во избежание полемики на тему «ну это же всё тривиально, достаточно покопаться в инете» сразу оговорюсь: в рунете информация на эту тематику практически полностью отсутствует, а в западном инете доступна весьма в разрозненном состоянии на десятке сайтов. Здесь будет приведена некоторая компиляция базовых принципов, максимально упрощающая начинающему программисту жизнь, а так же позволяющая с самого первого проекта максимально задействовать вычислительные мощности видеокарты. Людям написавшим 2-3 серьёзных программы на OpenCl это будет уже неинтересно. Статья в некотором смысле является продолжением моей прошлой статьи.