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

Итак, представьте себе следующую ситуацию. Так уж случилось, что вам надо отрефакторить очень большой кусок кода, целую подсистему. Строк, эдак, на 200К. Причем рефакторинг явно выглядит очень крупным, затрагивающим базовые концепции, по которым построена ваша подсистема. Фактически надо переписать всю архитектуру, сохранив бизнес логику. Такое бывает, если, например, вы сделали один проект и у вас впереди новый, и вы хотите в нём исправить все ошибки прошлого. Допустим, по первым прикидкам, на рефакторинг надо месяца 2, не меньше. В процессе рефакторинга всё должно работать, в том числе нельзя мешать другим программистам добавлять новые фичи и чинить баги в подсистеме. Часто такой рефакторинг бывает насколько сложен, что совершенно невозможно замерджить старый код в новый, а также невозможно выкатить результат по частям. Фактически вам надо заменить двигатель самолёта на лету.

Примеры из практики, как моей, так и моих коллег:

• Переделать всю работу с базой данных с чистого JDBC на Hibernate.
• Переделать архитектуру сервиса с отсылки-приёмки сообщений на удалённый вызов процедур (RPC).
• Полностью переписать подсистему трансляции XML файлов в рантайм объекты.

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

Данный пост будет о том, как разработать свою собственную, и достаточно производительную (на моем компьютере спокойно отрисовывается и анимируется 1 000 000 частиц в реальном времени), систему частиц. Писать будем на языке C++, в качестве платформы будет использован DirectX 9.

Вторая часть доступна здесь.

Пример одного из кадров визуализации (кликабельно):

Этот пост является 2-ой и последней частью статьи о разработке системы частиц на DirectX 9. Если вы еще не читали первую часть, то рекомендую с ней ознакомиться.

В этой части статьи будет рассмотрено: работа со спрайтами, вершинные и пиксельные шейдеры, эффекты, пост-эффекты. В частности для реализации пост-эффекта — приём рендера в текстуру.

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

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

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

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

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

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

… не пиратство. Даже близко не пиратство.

Мне сложно рассуждать, используя неточные термины, такие как «большая», «сильная» или как в данном случае: «невероятно высокая». Если вы утверждаете, что проблема Android — это большая доля пиратства на основе субъективного высказывания одного разработчика или на основе общего мнения, то это не аргумент.

Навеяно постом. Попутно получилось что-то похожее на собственную реализацию лямбда-выражений :) С возможностью вычисления производной еще на этапе компиляции. Для задания функции можно использовать операторы +, -, *, /, а также ряд стандартных математических функций.

Сейчас в интернетах можно встретить много Hello World'ов на WinApi, но когда новичок спрашивает как в этот Hello World добавить пару нужных функций — закидывают тухлыми яблоками и тут же отправляют в пресловутый и могучий MSDN.

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

Здравствуйте, коллеги!
После прочтения данной статьи, я понял, что использую этот редактор не на полную мощность. Для того чтобы изучить и запомнить основные используемые команды Vim, нарисовал Wallpaper шпаргалку. Список команд не претендует на полноту, но большинство из них будут вам полезны при работе с Vim. Ее можно будет поставить на рабочий стол или просто открывать по мере необходимости.
Под катом сама картинка:

На Хабре уже упоминалась новая рубрика What if Рендела Манро (xkcd). Каждый вторник он отвечает на разные дурацкие вопросы читателей с точки зрения законов физики. Ниже перевод одного из выпусков.

Что, если внезапно стакан станет буквально наполовину пустым?
—Витторио Иаковелла

Как выяснится далее, пессимист в данном случае окажется прав. Когда говорят «стакан наполовину пуст» обычно имеют ввиду, что стакан содержит поровну воды и воздуха.

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

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

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

В принципе, любой Интеллект какого-либо Объекта или Системы определяется ПОВЕДЕНИЕМ этого Объекта или этой Системы, которое, в свою очередь, определяется в общем случае двумя технологиями: ФИЗИОЛОГИИ (Психики), как рефлекторные реакции на входное воздействие, и РАЗУМА (Сознания), как осмысленные решения на оценку обстановки.

Уровень известных «перцептронных» технологий (и иже с ними различной «нейро-кванто-семанто-статистико-математико-сетевой лабуды) это, как раз, технология Физиологии. То есть, пришёл сигнал на вход, значит, выполнил соответствующее действие. Но это просто «безмозглые автоматы» и вот они называются «слабым ИИ».
Однако, естественный Интеллект человека базируется, в основном, на второй технологии – на Разуме. А это уже «сильный ИИ». Вот в чём их принципиальная разница – в Сознании.

Приветствую.

Уж не знаю, как так вышло, но игрался я на досуге с лямбда-выражениями в С++11 (о которых, к слову, я уже писал статью, снискавшую пару лет назад на удивление достаточно неплохую популярность), и под наркотическим воздействием впечатлением от языка Haskell начал разбираться с такими понятиями, как частичное применение и каррирование в контексте языка С++. И для начала, пожалуй, неплохо бы нам определиться с этими терминами.

(оригинал — Mike Ash, взято отсюда)

Многие Cocoa разработчики имеют довольно смутное представление об Objective-C Runtime API. Они знают, что он существует где-то там (некоторые не знают даже этого!), что он важен, и Objective-C без него неработоспособен, но обычно этим все знания и ограничиваются.

Сегодня я расскажу о том, как устроен Objective-C на уровне Runtime и о том, как конекретно вы можете это использовать.

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

Хочу немного рассказать о двух подходах проектирования ПО в embedded. Два подхода эти – c использованием суперцикла или же с использованием RTOS (Real-Time Operation System, операционная система реального времени).

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

Надеюсь, будет интересно всем тем, кто хочет заглянуть в мир разработки для встраиваемых систем. Для тех, кто в embedded уже собаку съел, скорее всего, не будет ничего нового.

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

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