Несколько недель назад Microsoft презентовал свою новую разработку — проект Casablanca. Для того, чтобы понять что это, нужно вернуться еще чуть дальше в прошлое, к прошедшей конференции Going Native 2012, где помимо обсуждения нового стандарта С++11 было сказано еще немало умных мыслей. Одна из них была в лекции Херба Саттера. Он заметил, что самой большой проблемой современного С++ является не всякие там сборщики мусора или синтаксис лямбда-выражений, а бедность стандартной библиотеки. Когда начинающий программист на Java или C# спрашивает у своего старшего коллеги, как ему послать\принять HTTP-запрос, распарсить XML\JSON, заархивировать\разархивировать ZIP-файл и т.д. — он получает конкретный, однозначный и работающий всегда ответ: «используй вот этот класс из стандартной библиотеки». Когда начинающий программист на С++ задаёт тот же вопрос — он слышит «ну, стандартных средств для этого нет, нужно или самому писать или вот есть какие-то библиотеки, но тут надо выбирать, тестировать, читать лицензии...». В результате мы имеем дикий зоопарк библиотек с разным уровнем производительности, часто паршивенькой кроссплатформенностью, кучу самописных велосипедов, трудности в переходе между проектами, потому что «раньше я использовал boost, а тут в проекте всё на Qt» и т.д. Херб Саттер высказал мысль, что основное, на чём следует сосредоточиться — это расширение стандартной библиотеки.

Так вот, Microsoft Casablanca — это первый набросок того, как это расширение могло бы выглядеть, что в него могло бы входить и как оно всё вместе могло бы работать. Никто пока не говорит о стандартизации Casablanca как расширения стандартной библиотеки С++, но уже сейчас его можно скачать в виде отдельной библиотеки (что-то вроде альфа-версии) и попробовать поизучать. Кроме того, Microsoft пропагандирует Casablanca как средство создания производительных сервисов для платформы Azure.

Всем привет. Недавно меня тоже настигла переломная веха студенческой жизни — бакалаврская дипломная работа. Среди многих формальных деталей этого замечательного явления особо заметным стоит нормоконтроль. Нет, я понимаю и всячески поддерживаю, что стандарты необходимы, в том числе стандарты на оформление академического текста. Просто наши стандарты, в отличие от западных, достаточно идиотичны. Они не экономят ни чернила, ни бумагу, они не упрощают поиск литературы по номенклатуре, а усложняют чтение названия. Не говоря уже о том, что текст стандарта спроектирован и описан людьми, работающими в редакторе Microsoft Word. Опять-таки, я не имею ничего против Word, это мощнейшая система. Но технический текст в нем набирать неудобно, и по гибкости он во много раз проигрывает бессмертному творению Дональда Кнута — LaTeX.

Итак, мое написание диплома началось с того, что я потратил 4 часа на настройку преамбулы под нормы украинского стандарта оформления ДСТУ 3008-95. Насколько мне известно, он почти полностью соответствует русскому ГОСТу. Я знал, что существуют готовые решения (например, disser), но после пары проб предпочел настроить каждую деталь самостоятельно. Для тренировки. Тренировка удалась — я узнал бездну новых вещей о LaTeX, этого монстра невозможно выучить полностью :-)

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

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

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

Год назад я захотел в машину флешку с винегретом из музыки, которая была у меня в плейлисте контакта. А там, к слову, почти 1400 треков.

Итак, первое, что я сделал — октрыл список расширений оперы и набрал в поиске «vkontakte». Но вот оказия, все приложения предлагали качать по одному треку, в основном добавляя рядом с ним кнопочку «скачать». В принципе, это удобно, если надо стянуть оттуда один-два трека, но вот если их 1400…

Следующий моим шагом было открытие страницы с музыкой и внимательная медитация над ней, с целью распарсить страницу, выдрав оттуда ссылки и названия. Слегка подумав, я решил, а почему бы снова не использовать вконтактовый API? Ведь опыт использования у меня уже есть (писал десктопный плеер на Qt). Но лепить полноценное приложение, тем более на плюсах или каком-либо другом языке, мне показалось слегка не умным решением. И тут я подумал — черт возьми, есть же python, наклепаю скрипт и стяну все. Итак, выбор сделан, начинаем кодить.

Открываем Geany и пишем первые строчки… И вот тут-то моя фантазия и желание лепить комбайны из ничего опять разыгрались. Дальше под катом.

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

Добрый всем вечер.

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

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

Меня время от времени озадачивают вопросами в связи с мимолётной заметкой, которую я сделал в 2010, по поводу того, что я больше не программирую ради заработка. Это правда. Я не работал в качестве full-time программиста с 2003-го. Короткая версия этих вопросов — «Почему?». Более длинная версия — «Слушай, ты ведёшь супер-технический блог о программировании и, похоже, ты знаешь все эти штучки, но неужели ты не хочешь работать программистом?».

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

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

Заинтересовавшихся прошу под кат.

Доброго времени суток. Это статья — перевод заинтересовавшего меня поста в блоге аспиранта Университета штата Нью-Йорк в Стоуни-Брук. Статья в доступной форме описывает основные концепции функционального программирования, их преимущества и недостатки. Думаю она будет полезна широкому кругу читателей, которые сомневаются, нужно ли им углубляться в мир функционального программирования или нет. Пожелания, предложения и замечания по переводу и терминологии принимаются по личной почте.

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

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

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

Задача

Первичные требования были такими:
В сложном стилизованном документе doc или docx вывести нужную информацию в помеченных местах.

В дальнейшем они были уточнены и расширены:

• В сложном стилизованном документе docx вывести данные в помеченных местах.
• Разметка вывода данных должна быть похожа на скриптлеты: ${}, <%%>, <%=%>.
• Данными для вывода могут быть объект. Нужна возможность обращения к полям.
• Для вывода использовать один из скриптовых языков: Groovy, JavaScript.
• Нужно иметь возможность выводить списки объектов в таблицы, в каждой ячейке отображая поля.

Имеющиеся решения

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

Jasper reports

В качестве шаблона использует файл xml-разметки *.jrxml. Файл разметки документа + данные (как из БД, так и Map параметров) отдаются процессору, который формирует любой из следующих форматов: PDF, XML, HTML, CSV, XLS, RTF, TXT.
Не устроило:

• Это не WYSIWYG, даже при наличии iReport — визуального средства формирования jrxml-файлов.
• Надо хорошо изучить JasperReports API, чтобы создать и стилизовать сложный шаблон.
• Не выводит в нужном формате. Можно и PDF, но хотелось бы иметь возможность потом поредактировать выходной документ.

Видеоматериалы

В одной из своих статей Бьёрн Страуструп (папа С++) признался, что он не признает видео материалы в качестве источника для самообразования. И с ним сложно не согласиться, когда речь касается изучения с нуля языка программирования или технологии. Я правда сомневаюсь, что можно одолеть такого монстра, как С++ или стать гуру WPF лежа на диване и просматривая обучающее видео типа «Узнай все за 24 часа». Но если вы ставите себе цель познакомиться с некоторой технологией или новой возможностью языка программирования, или просто послушать философско-компьютерные размышления умного товарища, то в этом случае веб-касты, записи конференций или другой вид видеоматериалов может быть очень кстати.

Открою не Америку, но шкатулку Пандоры: в Java-коде много бойлерплейта. Типовые геттеры, сеттеры и конструкторы, методы ленивой инициализации, методы toString, hashCode, equals, обработчики исключений, которые никогда не выбрасываются, закрывалки потоков, блоки синхронизации. Проблема заключается даже не в том, чтобы написать всё это — современные среды разработки справляются с такими задачами нажатием нескольких клавиш. Сложность в поддержании бойлерплейта в актуальном состоянии по мере внесения модификаций в код. А в некоторых случаях (многопоточность, реализация методов hashCode и equals) и сам шаблонный код написать без ошибок — далеко не простая задача. Одним из решений проблемы является генерация кода, и в этой статье я расскажу про проект Lombok — библиотеку, которая не только может избавить вас от бойлерплейта, но и сделать это максимально прозрачно, с минимальной конфигурацией и, что немаловажно, с поддержкой на уровне среды разработки.

Доброго времени суток!
Давно искал инструмент, чтобы быстро можно было узнать принадлежность того или иного телефонного номера к тому или иному оператору связи и/или региону.

Всегда использовал для этих задач МТТ, чего, в принципе всегда хватало.
Но хотелось чего-то ещё более простого и быстрого.

Если Вас также как и меня интересовало что-то подобное, прошу под кат.

Так или иначе, практически каждый из нас использовал в своей жизни технику интеллект–карт или Mind Mapping. Это всего лишь простая радиальная схема, но с правильным подходом ее можно превратить в мощный инструмент аналитики и синтеза информации, который всегда под рукой и достаточно прост в использовании. И что самое интересное, освоение техники настолько естественно для нашего мозга, что занимает всего лишь несколько минут…

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

IL Stub Diagnostic Tool

IL заглушки (stubs) динамически генерируются во время работы приложения на лету и управляют маршаллингом и вызовом целевого метода. IL Stub Diagnostic tool была создана чтобы улучшить качество отладки приложений. Это real-time монитор, который показывает детали каждой IL заглушки, создаваемой в исследуемом процессе. Для каждой заглушки утилита показывает ее IL код и сигнатуры Managed/Unmanaged методов

На сайте Oracle стала доступна для скачивания предварительная версия JavaFX Scene Builder:



Редактор предназначен для мышкоредактирования формочек под JavaFX. Рассмотрим что в нём есть:

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

Мигрируйте с Maven 2 на Maven 3

Вы еще используете maven2? Странно. Одна только миграция на 3-ю версию может значительно ускорить процесс сборки. В моем проекте переход на Maven 3 дал прирост в скорости сборки на 10%. Вероятней всего за счет каких-то фиксов и оптимизаций, что были сделаны в новой версии (так как заявляют разработчики количество кода было существенно уменьшено и сильно отрефакторено). Миграция займет у Вас несколько минут и в большинстве случаев будет безболезненной. Хотя есть шанс, что некоторые конфигурационные файлы все же придется подправить.

Используем ядра и дополнительные потоки

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

mvn -T 4 clean intall
mvn -T 2C clean install

В первом случае мы явно указываем, что хотим запустить процесс сборки на 4 потока. Во втором случае мы указываем, что на каждое ядро должно быть выделено по 2 потока для процесса сборки. Это одна из новых фич нового мавена — Parallel Builds. Эта фича анализирует граф зависимостей Вашего проекта
и распихивает модули по разным потокам, сборка которых может быть выполнена параллельно.
Для моего текущего проекта скорость сборки со вторым параметром (-T 2C) ускорилась на 20%. Правда тут есть один минус. Количество ресурсов, что будет потребляться для билда может значительно вырасти. В моем случае это +30% к потребляемой памяти.
Хочу сразу обратить внимание — если связанность модулей в Вашем проекте очень низкая — то
скорость сборки этой опцией можно увеличить на порядок.
Это, кстати, повод задуматься об Вашей архитектуре проекта. Ведь если билд занимает довольно много времени, то небольшой рефакторинг поможет уменьшить эту цифру. Хотя, конечно, это все очень индивидуально.
Вообще разработчики заявляют, что прирост в скорости сборки может быть 20-50%.

«Chicago Boss — бескомпромиссный веб-фреймворк, любимый дизайнерами, инженерами и этим парнем с пейджером.» — © chicagoboss.org

«Erlang — язык для создания отказоустойчивых распределенных приложений. Это — один из немногих функциональных языков, который давно и успешно применяется на практике. Например — в телекомах (Ericsson AXD-301 switch), банковских системах, системах автоматизации, высоконагруженных веб-приложениях (Facebook Chat). При этом Erlang — продукт с открытым исходным кодом и распространяется бесплатно.» — говорит нам сайт русскоязычного сообщества Erlang.

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

По заверению обоих разработка веб-приложений на базе этого фреймворка ничуть не медленнее разработки на тех же рельсах (Ruby on Rails). А в чем-то даже быстрее. Я с функциональным программированием до этого особо знаком не был, но под давлением товарища решил попробовать. Хочу сказать, что опыт был весьма удачным и у меня получилось создать мой первый веб-сайт быстрее, чем год назад с тем же Ruby on Rails.

В настоящее время трудно представить себе приложение на MVC3Framework без использования Dependency injection. Это статья рассчитана на тех кто знает, что такое DI, но никогда не использовал Autofac для этого.
Так же отмечу что более подробно об Autofac вы сможете прочитать тут

Для начала мы должны скачать и включить библиотеки Autofac в проект. Для этого я использую NuGet. Введите в консоли:
PM> Install-Package Autofac Устанавливаем сам Autofac
PM> Install-Package Autofac.Mvc3 И дополнения к Mvc3

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