Перевёл после прочтения комментариев к статье «О ненависти к C++». В цитатах можно найти ответы на большинство возникших там вопросов.

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

49. Lisp — это не язык, а строительный материал.
— Alan Kay

48. Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены.
— Edward V Berard

Навигатор:
Работа с OpenCV. Часть 1. Установка и Hello World

В этой серии статей будет расcмотрена работа с библиотекой компьютерного зрения OpenCV. Для работы из под Java будет использоваться интерфейс JavaCV.

Автор: Виктор Ерухимов, исполнительный директор Itseez, председатель рабочей группы OpenVX

The Khronos Group 18 ноября 2013 года представила предварительную спецификацию стандарта OpenVX 1.0 для компьютерного зрения. Поскольку Itseez был одним из инициаторов этой деятельности и активно участвовал в создании спецификации, мы решили рассказать про этот стандарт аудитории Хабрахабра.

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

Введение

Здравствуй, уважаемый хабраюзер.Я хотел бы тебе представить материал о практическом создании компилятора, который будет транслировать код, написанный на языке Cool, в код виртуальной машины CIL (Common Intermediate Language) под платформу .NET.Данный материал я решил разбить на две части из-за лени все сразу это описывать

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

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

В последние годы тема юнит-тестов, регрессивного тестирования, continuous integration, TDD, BDD, etc становится все популярней и все больше разработчиков начинают активно применять данные техники в своих проектах. При этом отдельным вопросом встает проблема автоматического тестирования пользовательского интерфейса в десктопных приложениях. В этой статье я постараюсь рассмотреть уже существующие решения, а так же привести вариант своего велосипеда написания тестов для UI на .net.

Введение

Работая тут над одним проектом, потребовалось мне, что бы функциональность проекта расширялась на лету и сторонними разработчиками, причём возможностей к расширению было как можно больше, с возможностью правки кода на лету. Соответственно плагины для этого не очень годились из-за необходимости их постоянной перекомпиляции после любой правки. Выход: скрипты. До этого со скриптами я работал достаточно давно и это была Lua на C++. Вариант хороший, если бы не несколько минусов:

• Отсутствие нормальной реализации или прослойки под .NET/Mono — во всех что я видел были какие-то недоработки (может и плохо искал — как минимум пропустил Lua в TaoFramework)
• По всей видимости, нужно было писать кучу биндингов что бы среда исполнения .NET/Mono могла нормально взаимодействовать со средой Lua и обратно.

Тогда-то я и задался вопросом — а может быть в .NET/Mono уже есть что-нибудь для реализации скриптов? И ответ был да. Пространство имён "System.CodeDom.Compiler" было как раз то, что мне надо — возможность реализовать скрипты которые максимально соединялись со средой .NET/Mono.

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

Статья затронет весь цикл разработки приложения. Вместе мы напишем простенькую игру “Крестики-Нолики” с одним экраном (в ОС Android это называется Activity).

Отсутствие опыта разработки на языке Java не должно стать препятствием в освоении Android. Так, в примерах не будут использоваться специфичные для Java конструкции (или они будет минимизированы на столько, на сколько это возможно). Если Вы пишете, например, на PHP и знакомы с основополагающими принципами в разработке ПО, эта статья будет вам наиболее полезна. В свою очередь так как, я не являюсь экспертом по разработке на Java, можно предположить, что исходный код не претендует на лейбл “лучшие практики разработки на Java”.

Это пятая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»
• «Исправляем ошибки»

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

Часть 5. Процесс слияния

Обеспечение слаженной работы нескольких людей над одним и тем же кодом — это важная функция системы контроля версий.

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

Это третья часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»

Одно из преимуществ использования Mercurial — возможность работать командой над одним кодом. Mercurial позволяет каждому работать независимо и помогает объединять сделанные изменения.

Часть 3. Привыкаем работать в команде

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

Это четвертая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»

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

Часть 4. Исправляем ошибки

Mercurial позволяет свободно экспериментировать. Представьте, что во время работы вы что-то не то сделали в редакторе, и случилось нечто ужасное:

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

Основы

Комментарии

Комментарии в OCaml обозначаются символами (* и *), примерно так:
(* Это однострочный комментарий *)

(* Это комментарий
   на несколько
   строк.
*)

Другими словами, комментарии в OCaml очень похожи на комментарии в Си (/* ... */).

В настоящий момент нет однострочных комментариев (как #... в Перле или // ... в C99/C++/Java). Когда-то обсуждалась возможность использовать ## ..., и я весьма рекомендую окамловским товарищам в будущем добавить эту возможность (однако, хорошие редакторы открывают возможность использования однострочных комментариев даже сейчас).

Комментарии в OCaml вложенные, это позволяет очень просто комментировать куски кода с комментариями:
(* This code is broken ...

(* Primality test. *)
let is_prime n =
(* note to self: ask about this on the mailing lists *) XXX;;

*)


Вызов функций

Допустим, вы написали функцию, назовём её repeated, которая берёт исходную строку s, число n и возвращает новую строку, состоящую из n раз повторённой строки s.

В большинстве С-подобных языков вызов функции будет выглядеть так:
repeated ("hello", 3) /* this is C code */

Это означает «вызвать функцию repeated с двумя аргументами, первый аргумент — строка hello, второй аргумент — число 3».

Подобно остальным функциональным языкам программирования, в OCaml, запись вызовов функций и использование скобок существенно отличается, что приводит к множеству ошибок. Вот пример того же самого вызова, записанного на OCaml: repeated "hello" 3 (* this is OCaml code *).

Обратите внимание — нет скобок, нет запятых между аргументами.

[прим. пер.: продолжение перевода, первая статья тут]

Структура программ на OCaml

Теперь мы потратим немного времени на высокоуровневый анализ некоторых настоящих программ на OCaml'е. Я хотел бы показать вам локальные и глобальные определения, разницу в использовании ;; и ;, модули, вложенные функции, ссылки. Из-за этого мы столкнёмся с множеством концепций OCaml'а, которые пока что не имеют смысла для начинающего изучать OCaml, так как мы не встречали их ранее. Не фокусируйтесь на них, сконцентрируйтесь вместо этого на общем представлении о формате программ и особенностях языка, на которые я буду указывать.

Локальные «переменные» (на самом деле локальные выражения)

Возьмём нашу функцию average на Си и добавим в неё локальные переменные (сравните её с примером в прошлой главе).

double average (double a, double b)
{
  double sum = a + b;
  return sum / 2;
}

Теперь посмотрим на это для OCaml:

let average a b =
  let sum = a +. b in
  sum /. 2.0;;

Стандартное выражение let name = expression in используется для определения локального именованного выражения и name может быть использовано в дальнейшем вместо expression вплоть до ;;, который означает окончание локального блока кода. Обратите внимание, мы даже не использовали отступ после объявления in. Просто воспринимайте let ... in так, как будто это один оператор.

Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть «Переобучение для пользователей Subversion».

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

Часть 2. Основы Mercurial

Mercurial — это система контроля версий. Разработчики используют ее для администрирования исходного кода. У нее два основных назначения:

1. Она хранит все предыдущие версии каждого файла
2. Она может объединить разные версии вашего кода, то есть сотрудники могут независимо работать над кодом и затем объединять свои изменения