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

Исторически так сложилось, что видеоигры не делятся исходниками. Конечно, они ведь предназначены для игроков. Но для программистов там всегда есть, на что посмотреть. И некоторые игры всё-таки выпускали свои исходники. А я давно намеревался сделать такую подборку.

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

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

Многие игры были рассмотрены на сайте Fabien Sanglard. Если вам интересны подробности их работы, то пожалуйте к нему.

Можно заметить, что многие игры принадлежат id Software/Apogee. Совпадение? Не думаю. id славится открытостью и привычкой выпускать исходники. Старые коммерческие игры уже не имеют ценности и были бы потеряны – не лучше ли, чтобы кто-то учился чему-то полезному на их основе?

Итак, приступим (в хронологическом порядке):

Рекурсия: см. рекурсия.

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

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

— Как она сложена?
— Превосходно! Только рука немного торчит из чемодана.

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

  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    if n>1: return fib(n-1) + fib(n-2)
    return n

приходится городить всевозможные грязные хаки, начиная от:

  @memoized
  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    if n>1: return fib(n-1) + fib(n-2)
    return n

И заканчивая вообще:

  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    n0 = 0
    n1 = 1
    for k in range(n):
      n0, n1 = n1, n0+n1
    return n0

Данная статья получилась из отчета программиста после «опыта» разработки небольшого приложения на новом языке Swift.

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

Статья расчитана на новичков в Objective-C и рассказывает об одном способе выстрелить себе в ногу. Мы попытаемся создать два различных объекта NSString с одинаковым текстом, исследуем реакцию на это различных компиляторов, а также узнаем, при каких условиях NSLog(@"%@", @«123456789») выведет совсем не «123456789».

Объекты NSString и указатели

Как вы думаете, что выведет следующий код?

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

Данная статья посвящена оптимизациям компилятора Visual C++. Я собираюсь обсудить наиболее важные техники оптимизаций и решения, которые приходится применить компилятору, чтобы правильно их применить. Моя цель не в том, чтобы рассказать вам как вручную оптимизировать код, а в том, чтобы показать, почему стоит доверять компилятору оптимизировать ваш код самостоятельно.

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

Исследователи Positive Technologies обнаружили уязвимости в инфраструктуре сетей мобильной связи, которые позволяют перехватывать GPRS-трафик в открытом виде, подменять данные, блокировать доступ к Интернету, определять местоположение абонента. Под угрозой оказываются не только мобильные телефоны, но и специализированные устройства, подключенные к 2G/3G/4G-сетям с помощью модемов: банкоматы и терминалы оплаты, системы удаленного управления транспортом и промышленным оборудованием, средства телеметрии и мониторинга и т.д.

Уже довольно давно в Xсode есть возможность проверить свой код на соответствие современным особенностям Objective-C (Edit > Refactor > Convert to Modern Objective-C Syntax…). Мне всегда было интересно наблюдать за тем, что Apple продвигает в качестве хорошей практики; и даже если вы не доверяете Xcode автоматически изменять код, это простой способ проверить его на возможность внесения потенциальных улучшений.

Xcode 6 представляет несколько нововведений, а кроме того, гораздо большую гибкость, позволяя самостоятельно контролировать, какие преобразования запускать:



К сожалению, из описания преобразования не всегда очевидно, что оно делает. Некоторые полезные подробности можно прочитать в руководстве Adopting Modern Objective-C, а также посмотреть на WWDC 2014 Session 417 What’s New in LLVM. Эта статья содержит мои заметки по каждому из преобразований.

После просмотра большого количества статей и видео про роботов-пауков захотелось самому создать подобное. Было решено все сделать «с нуля», то есть создать корпус робота, спаять плату и запрограммировать.

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

Скорее всего, если вы зашли на Хабр и читаете эту статью, то хоть раз в жизни да слышали про MOOC-курсы.

Но если все же не слышали, то MOOC (по-русски принято произносить «мук») означает «Massive Open Online Course» — массовый открытый онлайн-курс. Это настоящий феномен в образовании XXI века. Газета «New York Times» назвала даже 2012 год «годом MOOC» в связи с появлением на рынке дистанционного образования 3-х «китов» — Coursera, Udacity и EdX. MOOC-ам посвящено множество статей, кто-то видит в них будущее образования, кто-то, наоборот, угрозу. Пытаются также предсказать «традиционную» и «дистанционную» составляющии обучения будущего.




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

Индексы — это первое, что необходимо хорошо понимать в работе SQL Server, но странным образом базовые вопросы не слишком часто задаются на форумах и получают не так уж много ответов.
Роб Шелдон отвечает на эти, вызывающие смущение в профессиональных кругах, вопросы об индексах в SQL Server: одни из них мы просто стесняемся задать, а прежде чем задать другие сначала подумаем дважды.

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

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

Определение события

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

1. Экстент — это любая 4-Д область из 4-Д пространства-времени. Дело в том, что наше пространство четырехмерно. Просто одно из измерений мы переживаем специфическим образом – как нечто, что разворачивается перед нами в одном направлении. Но для моделирования такая особенность нашего восприятия не имеет значения.
2. Считается, что экстент, который мы считаем событием, с точки зрения рассказчика имеет нулевую временную ширину. То есть с точки зрения рассказчика событие – это мгновение. Однако, всегда существует точка зрения, в которой шириной события уже нельзя пренебречь и нам понадобится рассмотреть временную ширину этого экстента.
3. Событие имеет физический смысл – это факты и ничего, кроме фактов. Мы рассматриваем такое событие как набор фактов без их трактовок. Например, в примере с маяком есть событие смотритель сидит на дровне и отдыхает. Такое событие мы будем называть физическое событие.
4. Кроме физического события существует множество трактовок этого физического события разными субъектами. Например, при описании маяка одно и то же физическое событие «Смотритель отдыхает» может быть описано как: «Розжиг закончен» и «Тушение начато». Такое событие мы будем называть функциональное событие.

В итоге мы имеем такую иерархию объектов:

Или сказ о том, как разработка JSON валидатора превратилась в очередной JSON binding

Пока нормальные разработчики пишут приложения я изобретаю велосипеды.

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

Рекомендую заранее статью про то, как работать в потоке, и статью про спонтанное планирование (для тех, кто ненавидит тайм-менеджмент).

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

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

Настала пора поведать общественности о нашем приложении timera. C сегодняшнего дня его можно скачать в appstore.
Об архитектуре timera расскажет heximal (Павел), наш ios разработчик, у него сейчас read only, поэтому его пост публикую я.

— > В этом посте я напишу о моем скромном участии в интересном и перспективном проекте с весьма оригинальным названием Timera (от слов time и era). По удачному стечению обстоятельств я пребывал в активной фазе поисков новых горизонтов развития в тот самый момент, когда руководство стартапа искало кандидата на вакансию iOS-разработчика. Суть проекта довольно проста – ее визуальное представление и описание архитектуры можно видеть на главной иллюстрации к посту, под катом.

У любого желающего писать программы для продукции фирмы Apple в жизни наступает такой момент, когда ему приходиться изучить новый язык программирования — Objective-C. Когда-то этот счастливый момент постиг и меня. А чтобы лучше запомнить основные особенности этого языка, решил законспектировать свои мысли во время осмысления его документации, которыми и делюсь с вами.

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

Введение

До определенного момента своей жизни я ни о какой самоорганизации не задумывался. Все небольшое количество студенческих (аспирантских, junior-developer'ских) дел помещалось в голове, в нужный момент вспоминалось, а что не вспоминалось — тому не повезло. Женитьба, ремонт в квартире, рождение первенца, смена трех мест работы — все это удавалось худо-бедно удерживать в памяти. Но, как говорится, чем дальше в магазин, тем выше ставка по  кредиту. В какой-то момент у меня появилось ощущение, что я  постоянно занимаюсь «тушением пожаров» на работе, дома, в аспирантуре: провалил срок по рабочей задаче, не вспомнил о поездке к врачу с ребенком, дотянул до последнего с заказом билетов-отелей на летний отдых… О каких-нибудь хобби и получении удовольствия от жизни речи и вовсе не шло.

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

Доброго времени суток уважаемые хаброжители, меня зовут Юра, и сегодня я поведаю вам о проблемах высокотехнологичного отпрыска удалённой работы — фриланса, а именно о разработке мобильных, десктопных и вэб-приложений, вёрстке и дизайне. Работаю я в этой сфере достаточно недавно, буквально с 2008го, и опыта хорошего и плохого у меня накопилось достаточно много. Цель данной публикации — показать разницу между простыми сотрудниками и фрилансерами, а также — показать основные организационные проблемы, которые возникают при разработке и проектировании программного обеспечения. Я надеюсь, что этот пост поможет прояснить некоторые производственные моменты, которые могли бы быть не совсем очевидны для разработчиков и их руководства.

Суждения в данной статье субъективны — сплошная концентрированная «отсебятинка».
Они основаны на моём личном опыте и опыте людей с которыми я общаюсь.

Признак плохого дизайна №1:
Наличие объекта-«бога» с именем, содержащим «Manager», «Processor» или «API»

Ведущий iOS-разработчик Redmadrobot Егор BepTep Тафланиди — о том, как добиться стройного архитектурного дизайна мобильного приложения, используя классические шаблоны проектирования и логическое разделение исходного кода на модули.

Эксцентричных миллиардеров сложно чем-то удивить, поэтому, получая расплывчатые задания, их помощники всегда должны мыслить масштабно. Люди, работающие на Росса Перо поступили именно так, когда в 2006 году их босс объявил, что хочет декорировать свой офис в Плано, штат Техас [пригород Далласа, – здесь и далее прим. перев.] «реликвиями» из мира вычислительной техники. Зная, что нескольких жалких Apple I и Altair 880 будет недостаточно, чтобы удовлетворить запросы бывшего кандидата в президенты, его сотрудники решили нацелиться на более крупную рыбу и найти большой блок от ENIAC (Electronic Numerical Integrator And Computer, Электронный Числовой Интегратор и Вычислитель).