Программирование *

Межпроцессное взаимодействие (Inter-process communication (IPC)) — это набор методов для обмена данными между потоками процессов. Процессы могут быть запущены как на одном и том же компьютере, так и на разных, соединенных сетью. IPC бывают нескольких типов: «сигнал», «сокет», «семафор», «файл», «сообщение»…

В данной статье я хочу рассмотреть всего 3 типа IPC:

1. именованный канал
2. разделенная память
3. семафор

Отступление: данная статья является учебной и расчитана на людей, только еще вступающих на путь системного программирования. Ее главный замысел — познакомиться с различными способами взаимодействия между процессами на POSIX-совместимой ОС.

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

Wireshark — одна из незаменимых утилит для «прослушки» сети, при работе с сетевыми протоколами. В состав программы уже входит некое количество диссекторов¹, которое помогают детально рассмотреть пакеты базовых протоколов. Но при работе над проприетарным протоколом компании Nortel я столкнулся с отсутсвием подходящего диссектора. А нужен он был как воздух. Выход был очевиден — написать свой. Что я и сделал.
Таким образом, имея небольшой опыт написания плагина «анатома» под Wireshark, я решил поделиться знаниями и опытом с сообществом. Ну и для себя записать, на случай, если в будущем понадобится.

Диссекция — лат. dissectio, от dissecare, рассекать

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

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

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

Но вопрос остаётся тем же: как с годами программисты справляются с атакой всё новых технологий?

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

В статье описан способ группировки типов в языке C++, реализованный через шаблонный класс IGroup. Приём группировки типов даёт возможность указать несколько типов для объекта. Например, можно указать два интерфейса объекта.

Вообще этот приём мог быть языковой конструкцией, но таковой конструкции ни в одном ЯП не встречал (в комментариях мне уже разъяснили что почём и про Generics и про Boost и даже про STL, спасибо за обсуждение). Потому было интересно попытаться реализовать его на C++.

Я хочу рассказать о не совсем очевидной пользе префиксов в названиях имён и типов. Я считаю что у любых разработок у которых наличествует внешнее апи, должны быть префиксы, причём не с потолка взятые а тщательно выбранные.
Всё дело в удобстве поиска информации. Я уже почти год знаком с box2d, чуть больше с SDL и около двух месяцев как начал писать под ios (cocoa). И при работе с этими библиотеками я ощутил необыкновенную легкость и удобность. И совсем недавно, когда опять плотно занялся actionScript понял, чем те библиотеки отличаются от стандартного рантайма Adobe: префиксами. И дело не в коде, не в наличии пакетов или неймспейсов. Дело в гуглении. Это же просто шикарно, набрать в гугле SDL_MOUSEBUTTONDOWN, или NSArray или b2Shape и сразу получить то, что вы ищите. Это огромный плюс, возможность мгновенно находить то что вам нужно, очень важная часть хорошего апи. Чтобы найти документацию или сторонние обсуждения к Array от Adobe надо приписывать всякие штуки, типа as3 или Adobe, некоторые статьи теряются и не находятся таким образом. По запросу «array sort» гуглится и msdn и java и flash и php.

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

Данный текст опубликован под лицензией CC-BY.

Идея Java vs .Net vs Mono

Сама идея создания подобного теста появилась из-за, постоянно не дававшего мне покоя, противопоставления .Net и Java, и я решил максимально объективно оценить реальную производительность данных платформ, затем в поле зрения попала интересная opensource разработка Mono (свободная реализация .Net), и было решено включить и её, а заодно прогнать тесты под Linux. Соответственно были разработаны две аналогичных программы тестирования на языках C# и Java. Далее будут приведены фрагменты исходников на C#, полный исходный код можно получить из репозитария Google Code:
http://code.google.com/p/dotnet-java-benchmark/source/checkout
Целью данного теста является сравнение производительности различных виртуальных машин, выполняющих по сути один и тот же код на одном и том же компьютере. В соревновании принимали участие следующие платформы:

• Microsoft .Net 4.0 (Windows 7)
• Oracle Java SE Version 6 Update 24 (Windows 7)
• Oracle Java SE Version 6 Update 24 (Linux 2.6.35.27 Ubuntu 10.10)
• Novell Mono 2.11 (Linux 2.6.35.27 Ubuntu 10.10)

За последнюю неделю появилось несколько топиков с названием «10 однострочников на <MY_LANGUAGE>, которые произведут впечатление на ваших друзей», которые содержат однострочное решение нескольких простых задач, демонстрирующее достоинства и «крутость» любимого языка программирования автора. Я решил перевести их и для сравнения собрать в одном топике. Вся волна началась (вроде как) со Scala.
Итак, поехали!

Добрый день, хабрахабр!

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

В данной статье речь пойдет о библиотеке libgcrypt.

Постановка проблемы

Имеется база данных, содержащая список российских и украинских имён-фамилий в английской транскрипции, как она записана в туристических паспортах. Поскольку некоторое время назад правила транскрибирования для оных паспортов в России поменялись (толи с английских на французские, толи наоборот), имеется вполне реальная и даже официальная возможность того, что какое либо ФИО может быть записано иначе. Кроме того, данные порой могут браться из морского паспорта, что делает ситуацию ещё запутанней.
А теперь представьте, что вам нужно быстро найти в этой базе человека по фамилии, ну например, Щеглов… (смайл)

Варианты решения

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

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

 

 

Появился сервис лет 10 назад назывался «Computer Language Shootout». Сейчас он называется The Computer Language Benchmarks Game. Сервис давал хоть какую-то возможность бегло оценить производительность реализаций языков программирования. Тема, конечно, пикантна. Время идёт, интерес к теме не падает. Есть одно «но». Cервис и раньше-то был весьма специфичен, но теперь дело совсем худо.

 

Каждый программист когда-то давно, в начале своего Пути писал что-то типа вот этого:

double div( double a, double b )
{
	return a / b;
}

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

За душу программиста сражаются три могущественных духа-покровителя: Художник, Трудяга и Прагматик.

Если вы слышите внутри себя голос: «Ты не можешь рисовать», рисуйте во что бы то ни стало, пока голос не стихнет.
— Винсент ван Гог

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

Уже не первый раз сталкиваюсь с негибким отношением к поднятию исключений. Именно к поднятию, потому что к перехвату у большинства мнение совпадает: перехватывай только тогда, когда на самом деле можешь обработать. Поднятие же воспринимается, как нечто исключительное, из ряда вон. Когда видят throw, начинают рассказывать кучу историй о том как...

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

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