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

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

[rddt]

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



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

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

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

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

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

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

Я нашел еще один (очень простой) график, отражающий рейтинг языков программирования. Всё элементарно: по горизонтали — количество проектов на 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-стека, на котором веб-приложения работают… И это все — программисты.

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

В листе рассылки 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, исключительно для того, чтобы он работал максимально быстро.

Rust — новый экспериментальный язык программирования, разрабатываемый Mozilla. Язык компилируемый и мультипарадигмальный, позиционируется как альтернатива С/С++, что уже само по себе интересно, так как даже претендентов на конкуренцию не так уж и много. Можно вспомнить D Вальтера Брайта или Go от Google.
В Rust поддерживаются функицональное, параллельное, процедурное и объектно-ориентированное программирование, т.е. почти весь спектр реально используемых в прикладном программировании парадигм.

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

Каждый справляет новый год по разному.
Кто-то помнит его, а кто-то нет.
Я стоял на балконе и курил, наблюдая салют. Вобщем-то, я ждал когда запишется диск.
Диск было не жалко ради такого эксперимента – он того стоил.
Это было мое первое приложение под PlayStation 2. Правда, все, что оно умело – это выводить клавиатуру и, с помощью джойстика, печатать, но это был уже прогресс!
Итак, запуск! Работает!

Сама суть

Так я начинаю цикл статей по программированию для PlayStation 2
Сначала будет длинная теория.
Потом практика. Поскольку я не профессионал С++ (или С — кому как нравится, но я буду рассказывать на С++), то прошу строго не судить о коде.
Также, по PlayStation 2 SDK желательно использовать Red Hat 6 или выше, однако, я пишу все это под Windows 7. Хоть все и работает криво, но работает – и ладно.
К началу практических экспериментов советую иметь чипованную PlayStation 2 и сетевой кабель. Для моих экспериментов выбрана PlayStation 2 Slim 90006 формата NTSC чипованная и сетевой кабель синего цвета =) (Я не использовал для дебага режим iLink, поскольку драйвера в комплекте идут только под Linux, да и жесткий диск нужен).

Введение

В этом посте мы рассмотрим производительность горутин (goroutine). Горутины — это нечто в роде очень дешевых и легковесных потоков. Больше всего, наверное, они похожи на процессы в Erlang.

Согласно документации мы можем использовать сотни тысяч горутин в наших программах. И цель статьи — проверить и конкретизировать это.

В субботу на прошлой неделе «дело было вечером, делать было нечего», и мы с хабраюзером sourcerer разговаривали не понятно о чём. И почему-то речь зашла речь о задаче обратной к задаче построения графика функции по её выражению. То есть, например, у нас есть выражение y(x) = (cos^0,5x ⋅ cos 200x + |x|^0,5 − 0,7)(4 − x²)^0,01. График такой функции чем-то напоминает сердечко. Но нам был интересен обратный вопрос, как, имея, например, изображение сердечка, получить выражение для функции, графиком которой будет это самое сердечко.

Какие-нибудь ряды Фурье вспоминать не хотелось, а хотелось чего-то простого и красивого. Мы начали вспоминать известные нам результаты, связанные с этим вопросом. В результате получилась программка, которая по изображению генерирует ломаную линию, чем-то напоминающую исходное изображение. На примере котёнка по имени Гав это выглядит примерно так (смотреть лучше издалека):



Если интересно как такое сделать, а также узнать про формулу конопли, формулу, график которой является этой же формулой, то добро пожаловать под хабракат. (Будет много картинок.)

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

Начало

Так сложилось, что на текущем месте работы программисты предоставлены самим себе. То есть, конечно, кодят на благо предприятия, но совершенно бесконтрольно, вплоть до отсутствия банального тестера. ТЗ даже на «тяжелые» программы редко превышает объема в три листа А4 (один из которых — подписи всех причастных).

Звонки по поводу проблем с ПО направляются напрямую программистам. С этого всё и началось.

Бывают баги а бывают и БАГи. И если баги обычно фиксятся и забываются, то БАГи остаются с нами навсегда. Хочу поделиться с Вами тремя такими БАЖищами.

Первый такой казус произошел в 2005 году, когда я работал на фирме FriendScout24. У нас была тулза для мониторинга, в которой была хтмлная табличка и в каждой строчке по серверу. Если сервер отвечал нормально — он отрисовывался зеленным, если нет то красным. Обычно всё было спокойно зелененьким. И тут, в один прекрасный августовский день, сервера начали падать лесенкой. Пам-Пам-Пам — 4 сервера за 3 минуты. Через 5 минут всё снова позеленело, как будто ничего и не было.

Доброго всем времени суток!
Возникло желание (и даже возможность!) рассказать сообществу о замечательном языке программирования D. Как ни печально, в сети по нему все еще минимум информации, а на хабре и того меньше.
Все скорее всего о нем даже знают, но мало кто пытался писать на нем проекты, а все из за того, что он, видите ли, «не выстрелил», что у него нет будущего. Основная задумка, с которой я пишу эту статью — развеять некоторые заблуждения по поводу этого, несомненно, замечательного языка программирования, ну и заодно, конечно, просто отдать в широкие массы еще немного информации о нем.

Коллеги, поздравляю нас с выходом очередной версии этого очень хорошего кроссплатформенного фреймворка. В первую очередь Qt — это набор примитивов и готовых модулей для разработки GUI кроссплатформенных приложений на C++, но за годы развития область применения Qt значительно расширилась. Код для создания «резиновых», легко локализуемых интерфейсов давно доступен не только из C++, но и из многих других языков — python, ruby, php. Технология QML, о которой в последний месяц мы много прочитали благодаря конкурсу от Nokia, позволяет создавать полноэкранные интерфейсы, основанные не на виджетах, а на графических примитивах, их взаимодействии и анимации. Встроенные средства для использования Javascript в качестве скриптового языка приложений, тесная интеграция с WebKit, собственная кроссплатформенная IDE — о Qt можно рассказывать довольно долго. Но я этого делать не буду — только кратко расскажу про то, что нового.

Здравствуй, уважаемый Хабр! Я являюсь участником разработки автоматизированных систем управления высокой надежности, которые применяются на электростанциях, космодромах, сложных производствах и т.п. Однажды передо мной встала задача придумать метод проверки работоспособности программ в условиях загруженности всяких железяк, а именно:

1. Загруженность процессора
2. Загруженность сети отправкой/приемом
3. Нехватка оперативной памяти
4. Загруженность жесткого диска запросами чтения/записи

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

Рекомендации геймдизайнеру от программиста (архитектора).

Вступление

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

Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.

Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.

Я намеренно оставил за кадром другие документы: концепцию, экономическое обоснование и ТЗ для других исполнителей. Это позволило сфокусироваться на одной теме и осветить ее и только ее достаточно подробно.

«от нефиг делать / just for lulz» посвящается…



Змейка. Игра старая (как утверждает Wikipedia: середины или даже конца 1970х годов), но от того не менее интересная, по крайней мере в качестве примера несложного но интересного алгоритма для иллюстрации возможностей графического программирования на LabVIEW 2009.