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

Вместо введения

Добрый день, Хабралюди.
Хотел бы поделиться со всеми моим скромным опытом выбора языка программирования для своих проектов. Сразу хочу подчеркнуть – я выбирал язык исходя из собственных нужд, и, вполне вероятно, что ваш выбор в аналогичных условиях может быть другим. Все же я искренне надеюсь, что эта статья будет полезной, так как в ней достаточно подробно и аргументировано проводится сравнение D с C++ и C#, а так же упоминаются свыше десяти различных языков, принадлежащих к различным классам и реализующих различные парадигмы. Сам D разрабатывается как высокоуровневый язык для системного и прикладного программирования.

Если вкратце, потому что мы жадные.

Мы продвинутые пользователи Matlab. Некоторые из нас хакеры Lisp. Некоторые питонисты, другие рубисты, есть ещё Perl-хакеры. Среди нас есть такие, кто использовал Mathematica раньше, чем у него начали расти волосы на лице. Есть и такие, у кого до сих пор не выросли. Мы построили больше графиков на R, чем способен любой здравомыслящий человек. C — это язык, который мы бы взяли на необитаемый остров.

Мы любим все эти языки; они прекрасны и могучи. Для той работы, которую мы делаем — научные вычисления, машинное обучение, дата-майнинг, крупномасштабная линейная алгебра, распределённые и параллельные вычисления — каждый идеально подходит в определённом аспекте, но ужасен в других. Каждый из них — это компромисс.

Мы жадные: мы хотим больше.

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

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

Какими свойствами и особенностями обладает хороший, годный грамотный, качественный протокол?

[rddt]

Я программист php, но захотел расширить горизонты, узнать что ни будь новое. Поэтому решил поучить другие языки и технологии. Выбор пал пока на perl, python и mysql.

Был взят замечательный пакет pymorphy , библиотека Флибуста (только .fb2), sedna для хранения fb2, mysql percona 5.1 для хранения статистики и маленький напильник. Была создана примитивная myisam табличка куда записывалась сколько встречалось предложение, и описание частей речи этого предложения.

Причиной разобраться в том, как же работает UTF-8 и что такое Юникод заставил тот факт, что VBScript не имеет встроенных функций работы с UTF-8. А так как ничего рабочего не нашел, то пришлось писть/дописывать самому. Опыт на мой взгляд полезный в любом случае. Для лучшего понимания начну с теории.

О Юникоде

До появления Юникода широко использовались 8-битные кодировки, главные минусы которых очевидны:

Хабравчане, позвольте вам представить мой небольшой и скромный труд по шаблонам проектирования на украинском языке. Заранее извините, если вы не из Украины.



Описание
Книга «Дизайн паттерны — просто, как двери» является бесплатной украиноязычной книгой, содержащей уникальные примеры к шаблонам проектирования. Благодаря своей нестандартной подачи материала она позволит вам легко освоить основы понимания дизайн паттернов или систематически и очень быстро повторить их перед интервью. Способ написания книги позволит провести время, отведенное на ее прочтение, без скуки, а иногда даже увлекательно.

Освежите в своей памяти подзабытые дизайн паттерны!

Скачать книгу

В нескольких словах
Книгу я написал с добрыми намерениями. Их у меня было несколько. Я хотел удостовериться, что сам понимаю все классические дизайн паттерны. Ресурсов для этого достаточно много, но я решил реализовать эти паттерны самостоятельно и придумать собственные примеры. Таким образом, начиная С 16 января 2010 я писал блог посты, которие так или иначе вызвали интерес у читателей. Чтобы этот вклад в программирование был более четким, у меня возникло желание выпустить небольшую книгу, которая стала бы коллекцией этих блог постов.

Посетите сайт книги: http://designpatterns.andriybuday.com/

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

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

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

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

• геометрический предикат «поворот»;
• противоречивость «наивной» реализации поворота;
• применение интервальной арифметики для упрощения расчета предикатов;
• длинная арифметика и несколько альтернативных способов вычислений предикатов;
• расчет погрешности вычисления поворота в числах с плавающей точкой.

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

	SomeFunction()
	{
	    ...
	    if (false)
	    {
	        ...
	    }
	    ...
	}
	

Зачем может быть нужен блок if (false)?

Предположим, что:

1. Это не ошибка и не забывчивость.
2. if и false — это именно оператор условия и логическая ложь, а не какие-то хитрости с макросами\строками и т.д.

Пару вариантов ответа под катом. Желающие высказать свои идеи приглашаются мимо отгадки сразу в комментарии.

Я нашел еще один (очень простой) график, отражающий рейтинг языков программирования. Всё элементарно: по горизонтали — количество проектов на Github, по вертикали — количество вопросов на Stackoverflow.



Я позволил себе провести на этом графике две красные диагональные линии, чтобы показать как наглядно отделены друг от друга мейнстрим (C++, C#, Java, PHP, Javascript и т.д.), группа «альтернативного мировозрения» (Scala, Haskell, Erlang, Prolog, Lisp) и откровенный трэш (всё, что ниже). По-моему, проще некуда. Никаких там годовых колебаний в полтора процента, высчитанных по непонятным формулам.
Взято тут.

UPD: сорри за мини-троллинг со словом «трэш» — зато он породил весьма интересную дискуссию в комментариях. Всем высказавшимся — спасибо.

В этом коде могут быть ошибки; я только доказал, что он правилен, а не проверял его.
Дональд Кнут

Сегодня я наткнулся на пост, в котором утверждалось, что использовать функцию C++ STL make_heap нельзя, потому что почти никто не умеет использовать ее правильно. Сначала я возмутился смехотворностью этой идеи — любой человек, имеющий хотя бы начальное представление об алгоритмах, должен знать, как правильно использовать make_heap. Но потом я задумался о том, сколько программистов не знают, что такое куча, более того, им это даже не нужно… А потом я понял, что все эти люди в равной степени зовутся программистами.

Когда я был маленьким, мне давали множество плохих советов о правильных техниках программирования. За прошедшие годы я осознал, что большинство советов не были плохими сами по себе, но давались в отрыве от контекста. Расцвет стартапов, наблюдающийся в настоящее время, заставил многих хакеров осознать, что «эффективность не имеет значения» — совет, таящий в себе множество ловушек и нюансов контекста, особенно когда речь идет о сложных архитектурах, которые могут взаимодействовать неожиданным образом. Эффект испорченного телефона, возникающий из-за недостатка контекста в таких высказываниях, сам по себе представляет проблему, но на самом деле он — лишь симптом проблемы более глубокой.

Термин «программист» покрывает колоссальный спектр способностей и умений. По вертикальной оси, программист может едва уметь писать на vbscript — или разрабатывать компиляторы для Intel или научный софт для авиакомпаний. По горизонтальной оси, он может быть экспертом в базах данных, улучшать производительность GPU, писать библиотеки параллельных вычислений, физические движки или драйвера для принтеров, заниматься обработкой изображений, генерацией 3D моделей или исследованиями в области искусственного интеллекта, использовать coffeescript, HTML5 и AJAX для разработки веб-приложений или nginx и PHP для разработки LAMP-стека, на котором веб-приложения работают… И это все — программисты.

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

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

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

Мы все знаем, что в мире создано несколько тысяч языков программирования. Один только список программ Hello, world с сайта Wikibooks включает в себя 230 категорий (полный список на сегодня состоит из 402 элементов). При этом известный рейтинг TIOBE подтверждает очевидное соображение: основная масса этих языков скорее мертва, чем жива. Уже на долю первого десятка языков приходится 76,77% всех учтённых TIOBE проектов. Второй десяток увеличивает эту долю до 85,61%. Стало быть, на оставшиеся 30 языков (TIOBE учитывает лишь первые 50 языков при расчёте процентов) приходится менее 15% упоминаний.

Понятно, что рейтинги заключают в себе некоторую долю лукавства, поскольку даже непопулярный по общим цифрам язык может быть крайне важен для какой-либо узкой сферы. Возьмём любимый здесь многими Erlang или Haskell (39-е и 41-е места рейтинга) или ещё более очевидные Simulink и LabVIEW, вообще не попавшие в Top 50, но незаменимые в своих областях. С другой стороны, очевидно, что языки действительно приходят и уходят, и популярность, скажем, Паскаля обречена на снижение, поскольку на смену идут более прогрессивные языки, метящие в ту же нишу. (Не будем упоминать здесь Delphi, в котором от Паскаля остался разве что базовый синтаксис. У традиционного паскалиста листинг на Delphi может вызывать такой же ступор, какой у меня вызвала первая увиденная мною программа на Visual Basic 6, с этими Private и Public, Option Strict и Dim As, напрочь отсутствовавшими в родном Бейсике ZX Spectrum.)

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

Думаю, многим разработчикам на управляемом коде всегда интересовало: сколько же байт занимает экземпляр объекта? А каков лимит размера одного объекта в CLR? Существуют ли различия в выделении памяти между 32-битными и 64-битными системами? Если данные вопросы для Вас не пустой звук, тогда прошу под кат.

В листе рассылки Git развернулась дискуссия о том, как язык программирования высокого уровня снижает производительность приложения, в связи с обсуждением JGit. Дискуссия особенно интересна, потому что в ней принимали участие программисты, эксперты высочайшего уровня как в C, так и в Java. Один из них — Шон Пирс (Shawn O. Pearce), известный Java-программист из компании Google, активный коммитер в Eclipse, соавтор Git и автор Java-имплементации Git под названием JGit. В своём сообщении он назвал реальные ограничения, с которыми сталкивается высококвалифицированный разработчик, пытаясь написать эффективный Java-код, сравнимый по производительности с максимально оптимизированным кодом C. Хотя письмо датируется апрелем 2009 года, но некоторые аргументы Шона до сих пор не потеряли актуальность.

List: git
Subject: Re: Why Git is so fast (was: Re: Eric Sink's blog — notes on git,
From: «Shawn O. Pearce» <spearce () spearce! org>

Как было сказано ранее, мы сделали много маленьких оптимизаций в коде Git на C, чтобы добиться реально высокой производительности. 5% здесь, 10% там, и внезапно ты уже на 60% быстрее, чем был раньше. Нико [Питре], Линус [Торвальдс] и Джунио [Хамано] — все они потратили определённое время в последние три-четыре года для оптимизации отдельных фрагментов Git, исключительно для того, чтобы он работал максимально быстро.

Не для кого не секрет, что «Mail.ru Агент» стал довольно популярным IM проектом. Здесь вам и поддержка ICQ, XMPP, голосовых звонков и даже отправка SMS, только вот компания Mail.ru совсем забыла о разработчиках.
Официальная документация протокола обмена данными Mail.ru Агент описывает версию протокола 1.7 реализованную в 2008 году. На данный момент сервер использует протокол версии 1.24.

1. Прошу прощения, что долго не писал.
2. Готов PS2 SDK.

Я хотел не упускать CD(DVD)-ROM Library, поэтому ссылки и гайд по установке PS2 SDK вы найдете в конце второй части этой статьи.
Тема достаточно сложная. Также буду благодарен, если кто-нибудь перельет на другой не платный хостинг PS2 SDK.
PS2 SDK доступен тут. Narod.ru.
Магнет (ссылка нормально не вставляется благодаря хабра-парсеру): magnet:?xt=urn:btih:F6114E45C5E392E6D213F2547C466FADB5DA5A13&dn=sce.zip&tr=udp%3a//tracker.openbittorrent.com%3a80/announce
Еще одна ссылка. Спасибо Konstantinus и ahmpro

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

Я использую 2 оригинальных джойстика Dual Shock 2, однако, у меня есть два не оригинальных джойстика (используются для подключения к компу через спец. Устройство или через мультитап для игры вчетвером), о которых я буду упоминать отдельно.