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

Итак, задача:
Хочется, чтобы каптчу вводить не приходилось. Хоть если играешь сам, хоть если играет за тебя бот, если ты спишь.
Дополнительное условие: 40 часов времени (ибо паника на корабле).
Желательное условие: установочный файл под Windows.
Ещё одно желательное условие: результат должен занимать не более мегабайта.

Как-то раз в одной неглупой статье один неглупый хабраюзер рассказал одну неглупую идею. Суть её была в том, что в его компании настроена система, контролирующая написанный программистами код в момент попытки добавления его в репозиторий и отклоняющая код, не проходящий по некоторым критериям. Мне идея понравилась. Я (и еще 3 человека) попросили автора развить мысль и написать статью об этом, но она так и не появилась. И я решил разобраться сам.

 

Вступление

В статье будет рассказано о том, как в кратчайшие сроки познакомиться с основами скриптинга в GIMP на языке Scheme и приступить непосредственно к решению простых практических задач. Данный материал предназначен лишь для тех, кто собирается автоматизировать рутинную обработку здесь и сейчас, не сильно вдаваясь в тонкости и не жертвуя драгоценным временем. Также, статью не рекомендуется использовать в качестве пособия по Scheme отдельно от Script-fu. Связано это с упрощённым стилем программирования в данном материале и отсутствием освещения других немаловажных фактов, которые нас сейчас волнуют гораздо меньше, чем скорость освоения.

Содержание:

1. Что нам понадобится?
2. Коротко о синтаксисе
3. Переменные
4. Функции
5. Списки
6. Регистрация скрипта в GIMP
7. Написание кода
8. Заключение

Предисловие

Всем доброго времени суток. Начиная с 2003 года, и по сегодняшний день, я профессионально занимаюсь разработкой прикладного программного обеспечения в среде Delphi 7 — Delphi 2010. И надо сказать, что эта работа позволяет мне достаточно неплохо зарабатывать на хлеб и пользоваться уважением своих коллег в нескольких организациях, с которыми я работаю.
Но многие наверняка знают о трудностях компании Borland, и как следствие провальной судьбе нескольких, вышедших подряд, версиях Delphi. Все Delphi, начиная с версии 8 (~2003 год) по 2007-ю, были не просто непопулярны. Их IDE были крайне нестабильны. Фатальные сбои среды разработки, требующие перезапуска, становились неотъемлемой частью процесса программирования. Сам язык менялся настолько незначительно, что большинство разработчиков на вопрос: “Что изменилось в новой версии?” могли только невнятно пробубнить: “Ну,… кажется, были добавлены новые компоненты…”. И только в 2009 году отделившаяся от Borland компания CodeGear смогла вывести на рынок относительно стабильную RAD Studio 2009, включающую новую версию Delphi. Подведя итоги, получаем 6 с лишним лет застоя, на фоне бурно развивающихся информационных технологий.
Поэтому и по сей день, значительный процент профессиональных разработчиков Delphi работает в 7-й версии. Могу только посочувствовать их упорству и посоветовать (если они и далее желают работать с Delphi) как можно скорее осваивать Delphi 2010. В сравнении с Delphi 7, 2010-я версия — это качественный скачек вперед. Я не стану подробно останавливаться на сравнении, поскольку это расходиться с темой статьи, но совсем промолчать не могу. Таких людей нужно чаще мотивировать, поскольку привыкание может быть существенной помехой на пути профессионального развития. Перейдя на версию 2010, вы получите стабильно работающую IDE, значительно превосходящую по комфорту работы среду Delphi 7. Из языковых возможностей вы приобретете поддержку юникода, возможность работы с обобщенными типами и анонимные методы, которые также могут плодотворно сказаться на качестве кода и скорости работы.

Доброе время суток хабражители и хабражительницы. Сегодня хотел бы поделиться с вами своими попытками в программировании физических процессов. А конкретнее – попытке углубиться до молекулярных масштабов. Тема для разговора под хабракатом – молекулярная динамика.

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

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

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

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

На фоне нынешних рассуждений о том, «справится ли мой телефон/калькулятор/часы с проигрыванием HD-видео» отошел на задний план интересный исторический факт: немногим более 10 лет назад проблемой была даже не скорость декодирования видео (теплый ламповый MPEG декодировался тогда отдельными аппаратными декодерами; остальные перебивались возможностями имеющегося ЦП), а скорость его вывода на экран. Многоэкранная среда убивает на корню идею переноса блока памяти с декодированным изображением в видеопамять, ведь окна могут перекрывать друг друга самым причудливым образом.

Проблему решили аппаратно. Приложение, которое должно выводить видео на экран, выводило теперь лишь фон определенного цвета (как правило, очень темный пурпурный), а «впечатыванием» видео занималась видеокарта. При составлении изображения она заменяла пикселы фона на соответствующие пикселы декодированного кадра. Приложение же теперь имело в своем распоряжении область памяти, в которую можно было очень быстро копировать кадры из видео. Технологию назвали hardware overlay и очень быстро внедрили ее во все потребительские и профессиональные видеокарты.

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

Введение

Статья посвящена работе с MVVM и WPF. В ней описывается процесс разработки twitter client. Процесс разработки разбит на шаги. В конце каждого шага читатель параллельно пишущий приложение должен иметь работающее приложение. Каждый последующий шаг добавляет какую-то функциональность к написанному на предыдущем шаге. Используется thirdparty библиотека TweetSharp. Ссылку на исходный код, а так же оригинал статьи, написанный мной на английском, можно найти тут.
Статья рассчитана на новичков в WPF разработке. Но предполагается, что читатель имеет некоторый начальный опыт работы с WPF, в частности освоил data binding.
Я не буду писать зачем нужно использовать MVVM – считаю, что об этом хорошо написано в статье “Приложения WPF с шаблоном проектирования модель-представление-модель представления” от Джоша Смита. Если вы не хотите читать эту статью – просто поверьте мне – неверное спроектированное GUI в случае с WPF превращается в большую головную боль.

Здравствуйте, хабражители. Думаю, многие из вас слышали о программируемых калькуляторах (а некоторые даже использовали их). Как ни странно, здесь я не нашел ни одной статьи, рассказывающей о такой интересной вещи, и поэтому решил восполнить этот пробел и рассказать об основах программирования на калькуляторах.

Некоторое время назад я нашел у себя в кладовке старый «Электроника МК-61», принадлежавший моему папе. Естественно, я не мог упустить такой шанс освоить не совсем «стандартное» программирование на калькуляторе. (В случае, если у вас нет программируемого калькулятора, вы можете скачать эмулятор здесь)

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

В настоящий момент книга готовится к выходу в одном из питерских издательств.
Скачать отрывок в PDF (2,4 Мб, 21 стр) (содержание, предисловие и первая вводная глава)

Знаете, копаюсь тут по всяким языковым сайтам в связи с работой, и очень часто наталкиваюсь на такое изречение: инженеры (программисты) стоят дорого, серверы — нет. Ну, контекст у этого изречения классический: мол, код на нашем языке L.1 тормознее в X раз, чем код на L.2, но зато программировать удобнее (что зачастую, кстати, сомнительно, из-за сложных взаимоотношений внутри громадных систем типов, созданных за несколько сотен или даже тысяч мифических человеко-лет).

Так вот. IMHO, дурацкое изречение.

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

Связные списки

В OCaml, так же как в Perl, есть встроенная на уровне языка поддержка списков. Все элементы списка должны быть одного типа. Для определения типа используется выражение:

[1; 2; 3]

Обратите внимание: точка с запятой, а не запятая.

[] означает пустой список.

У списка есть голова (первый элемент) и хвост (остальные элементы, кроме головы). Голова — элемент. Хвост — список. В вышеприведённом примере голова — целое число 1, а хвост — список [2; 3].

Альтернативной формой записи является использование оператора конструирования (cons) в форме head :: tail. Нижеприведённые строки полностью эквивалентны друг другу.

[1; 2; 3]
1 :: [2; 3]
1 :: 2 :: [3]
1 :: 2 :: 3 :: []

Зачем мы упомянули оператор конструирования? Он полезен когда мы начинаем сопоставление с образцом для списков, мы обсудим это чуть позже.

Тип данных для связного списка

Тип данных для связного списка целых будет int list; общий тип для связного списка объектов типа foo будет foo list.

Всем привет! Появившаяся недавно на Хабре статья, посвященная языку APL, на мой взгляд, не столько описала, сколько усложнила этот довольно простой и логичный язык. Я решил попытаться доказать что APL — это просто! Для этого я покажу вам, как написать на APL небольшое GUI приложение с использованием интерпретатора компании Dyalog, так как собственно сам язык APL состоит из пары десятков примитивов (те самые «закорючки») и всё. Параллельно постараюсь объяснить значение используемых примитивов и особенности разработки в Dyalog APL (много картинок!).
Итак, «Угадай Число» на APL!

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

Структура программ на 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 так, как будто это один оператор.

«В скором будущем стоимость аппаратной части компьютеров, необходимой для запуска и работы программы будет ничтожно мала по сравнению со стоимостью труда программиста, поэтому имеет смысл развивать языки программирования, которые, хоть и более требовательны к ресурсам компьютера, зато позволяют минимизировать количество кода», — примерно так рассуждал доктор Джим Браун, возглавлявший группу APL девелоперов IBM в середине 80х. Что ж, его прогнозы оправдались лишь отчасти. Сейчас APL применяется, и вполне успешно для программирования финансовых и научных расчетов, входит в состав .NET платформы и в TIOBE Index на ноябрь 2010 занимает 33 место (рейтинг 0,366%).

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

Основы

Комментарии

Комментарии в 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 *).

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

В предыдущих заметках (часть I, часть II) об async/await в C# 5 я написал, что подобный подход реализован в таких языках, как Haskell, F# и Nemerle, но, в отличие от C#, эти языки поддерживают концепцию более высокого уровня, которая позволяет реализовать асинхронные вычисления в стиле async/await в виде библиотеки, а не на уровне языка. Забавно, что в Nemerle сама эта концепция реализована в виде библиотеки. Имя этой концепции — монада. Помимо асинхронных вычислений монады позволяют реализовать другие вкусности, такие как list comprehension, continuation, превращение грязных функций в чистый блок, через который неявно протаскивается состояние, и множество других.

Некоторые монады реализуют такие «хотелки» C# программистов, как yield коллекции или yield foreach и yield из лямбда выражения.

Цель этой заметки — введение в асинхронное программирование и computation expressions в Nemerle, но она так же может быть полезна тем, кто изучает F#, так так реализация асинхронного программирования в Nemerle была сделана с оглядкой на него в F#. С другой стороны, кому-нибудь может быть интересно, как некоторые задачи, которые являются проблемой в других языках (После всех асинхронных вызовов), решаются с помощью computation expressions в пару строк.

Оптимизация сборки — одна из основных прелестей Gentoo, однако все описанное применимо к любому случаю компиляции ПО из исходных кодов. Все параметры сборки в Gentoo задаются в файле make.conf.
По сути нас интересует лишь переменная CFLAGS. CXXFLAGS должна быть равна CXXFLAGS="${CFLAGS}", а в MAKEOPTS лишь указывается число параллельно запускаемых процессов компиляции (обычно задают общее число ядер процессоров + 1).