Много статей и сайтов сравнивают шрифты для программирования — всё это отличные ресурсы. Так зачем я опять поднимаю эту тему? Потому что сам всегда терялся в десятках шрифтов и не мог понять, какой лучше. Так что я опробовал много шрифтов и выбрал следующие для вас. Они довольно популярны и их легко получить. И самое главное, все эти шрифты бесплатны!

Я ранжировал шрифты по следующим показателям:

• Насколько различимы схожие символы, такие как 0O, 1lI.
• Легко ли читается шрифт (ширина строк, ширина/высота символов).
• И мои личные предпочтения!

Все скриншоты сделаны в VSCode на одном фрагменте кода. Если не обозначено иное, то везде установлен размер "editor.fontSize": 14.

«Определение ада: «Тот человек, которым вы стали, в свой последний день на земле встретится с человеком, которым вы могли бы стать».
— Автор неизвестен

На днях широкое внимание привлекло состоявшееся в начале года на митапе NYC Lisp выступление Джеральда Джей Сассмана, — одного из авторов великого и могучего SICP, а также крестного отца Scheme. Всему виной — ответ на вопрос, почему в MIT прекратили преподавать ставший легендарным курс 6.001, построенный на основе книги Сассмана и Абельсона «Структура и интерпретация компьютерных программ» (вопрос задан на 59 минуте).



Сассман назвал две причины; впрочем, сразу замечу, что в первой из них нет ничего особенного. К 1997 году Абельсон и Сассман уже устали рассказывать практически одно и то же с 80-ых, поэтому решили оставить преподавание и предложили главе кафедры самостоятельно решить, как поступить с самим курсом. Здесь удивляться действительно нечему — что угодно может осточертерть, если заниматься им достаточно долго.

Впрочем, вторая причина гораздо серьезнее. По мнению Сассмана, они с Абельсоном осознали, что учебный план SICP больше не в силах подготовить инженеров к тому, что представляет собой «инжиниринг» сегодня. В 80-ых и 90-ых инженеры строили сложные системы, комбинируя простые и хорошо изученные «части». Целью SICP было предоставить язык абстракций для рассуждений о таких системах.

В этом посте я дам метаинформацию об авторском праве и свободных лицензиях. Т. е. то, что должен знать каждый, кто пишет свободное ПО. Я не буду останавливаться на конкретных примерах таких лицензий, это вы сможете найти где-нибудь ещё в интернете. Также, я немного поговорю о GPL. Сразу скажу, что я не юрист, и мог где-то ошибиться. Весь этот пост применим почти ко всем развитым странам, в том числе к России и Америке (правда, к сожалению, авторизированного перевода GPL на русский язык нет, а потому она недействительна в России). Везде, где я говорю про GPL, я имею в виду GPL третьей версии, хотя почти вся эта информация применима и к GPL 2, и, скорее всего, будет применима к последующим версиям. (Ещё раз скажу: я плохо разбираюсь в теме, см. UPD от 2016-11-10 в конце статьи.)

Авторское право

Любой продукт интеллектуального труда автоматически становится объектом авторского права. Всевозможные «Copyright», «All right reserved», «©» и т. д. не обязательны. Регистрация авторского права не нужна, однако, она может пригодиться, чтобы потом доказать, что вы действительно являетесь владельцем авторских прав, например, в суде. Т. е. если вы, например, написали программу, выложили её в интернет, не подписались, не написали «Copyright» и т. д., то вы всё равно являетесь владельцем авторских прав на неё. Но вот далеко не факт, что у вас получится, в случае чего, это доказать.

Что значит авторское право? Кто-то может подумать, что это право брать денежные отчисления за использование произведения. Да, это так, но авторское право включает в себя не только это. Авторское право — это право устанавливать любые ограничения и условия (т. е., собственно, лицензию) на использование произведения, в том числе право требовать отчисления. Например, какой-нибудь программист может потребовать, чтобы его программу использовали только стоя на одной ноге. И он будет прав. И любой, кто не подчинится этому условию, будет нарушать закон.

1. Введение

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



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

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

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

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

Присылает нам заказчик (Газпром) свою версию договора.
Понимаем — нашу они не подпишут,
вносим реквизиты и отправляем обратно.
Пропадают на две недели… возвращают протокол разногласий к договору.

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

23 ноября 2011 года id Software поддержала собственную традицию и опубликовала исходный код своего предыдущего движка.

На сей раз настало время idTech4, который использовался в Prey, в Quake 4 и, разумеется, в Doom 3. Всего за несколько часов было создано больше 400 форков репозитория на GitHub, люди начали исследовать внутренние механизмы игры или портировать её на другие платформы. Я тоже решил поучаствовать и создал Intel-версию для Mac OS X, которую Джон Кармак любезно прорекламировал.

С точки зрения чистоты и комментариев это самый лучший релиз кода id Software со времени кодовой базы Doom iPhone (которая была выпущена позже, а потому откомментирована лучше). Крайне рекомендую каждому изучить этот движок, собрать его и поэкспериментировать.

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

Перевод блог поста и доклада Russ Cox с GopherCon 2017, с обращением ко всему Go сообществу помочь в обсуждении и планировании Go 2. Видео доклада будет добавлено сразу после опубликования.

25 сентября 2007 года, после того как Роб Пайк, Роберт Грисмайер и Кен Томпсон несколько дней обсуждали идею создания нового языка, Роб предложил имя "Go".

В следующем году, Ян Лэнс Тейлор и я присоединились к команде и мы впятером создали два компилятора и стандартную библиотеку, которые были публично открыты 10 ноября 2009.

С таким громким заголовком я думал сначала написать статью. Нет, на самом деле, вполне возможно, что у вас всё хорошо и эта статья — не про вас. Но очень часто, когда люди приходят из других языков, можно видеть, как они пытаются «притянуть за уши» паттерны из того языка, к которому они привыкли, и они в Go зачастую работают плохо.



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

Задача планировщика в Go — распределять запущенные горутины между потоками ОС, которые могут исполняться одним или большим количеством процессоров. В многопоточных вычислениях, возникли две парадигмы в планировании: делиться задачами (work sharing) и красть задачи (work stealing).

• Work-sharing: Когда процессор генерирует новые потоки, он пытается мигрировать их на другие процессоры, в надежде, что они попадут к простаивающему или недостаточно нагруженному процессору.
• Work-stealing: Недостаточно нагруженный процессор активно ищет потоки других процессоров и "крадет" некоторые из них.

Миграция потоков происходит реже при work stealing подходе, чем при work sharing. Когда все процессоры заняты, потоки не мигрируют. Как только появляется простаивающий процессор, рассматривается вариант миграции.

В Go начиная с версии 1.1 планировщик реализован по схеме work stealing и был написан Дмитрием Вьюковым. Эта статья подробно объясняет устройство work stealing планировщиков и как он устроен в Go.

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

После интересной обратной разработки игрового движка Comprehend (см. Recomprehend) я подбирал новый проект для реверс-инжиниринга игры под DOS. За долгие годы разные люди реверсировали множество старых популярных игр и опубликовали для них спецификации и инструменты. Например, на сайте shikadi.net есть куча информации об играх, в которые я играл в детстве.

Я обнаружил, что для реверс-инжиниринга игры The Lost Vikings компании Blizzard (тогда она называлась Silicon and Synapse), похоже, не предпринималось никаких серьёзных попыток. Игра была выпущена в 1993 году, на закате эры DOS, и очень нравилась мне в юности. The Lost Vikings — это головоломка-платформер, в которой игрок управляет тремя викингами, каждый из которых имеет собственные умения. Викингам нужно объединить свои силы для решения загадок и прохождения уровней с различной тематикой: космический корабль, доисторический мир, Древний Египет. На изображении ниже показан первый уровень игры (источник: Strategy Wiki):



Казалось, что эту игру разобрать будет довольно просто. Уровни основаны на тайловых картах и содержат простые загадки: кнопки, включающие и отключающие объекты, передвижные ящики и поднимающий предметы кран. И на самом деле, бóльшая часть проекта по обратной разработке была достаточно прямолинейной. У игры есть один пакетный файл данных, содержащий сжатые блоки файлов. Блоки кодируют различные ресурсы игры, такие как спрайты, карты, звуки и т.д. Я написал несколько утилит, которые можно использовать для просмотра ресурсов игры: The Lost Vikings Tools.

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

Введение в интро

Демосцена — это о создании классных штук, которые работают в реальном времени (как бы «крутятся в вашем компьютере»). Их называют демки. Некоторые из них по-настоящему маленькие, скажем, 64k или меньше — такие называются интро. Название происходит от рекламирования или представления взломанных программ (crack intro). Итак, интро — это просто маленькая демка.

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

Бинарник под Windows: guberniya_final.zip (61.8 kB) (немного ломается на картах AMD)

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

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

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

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

В этой статье я хочу немного поговорить об авторском праве и свободных лицензиях на ПО. Текст является результатом самостоятельного выбора лицензий и их применения к своим проектам.

Статья будет полезна тем, кто хочет:

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

Часть 1: введение

17 апреля 2012 года Джордан Мекнер опубликовал исходный код Prince of Persia.

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

Очевидно слабая для программирования игр среда Apple II на самом деле была фундаментом несравнимых ни с чем инноваций и творчества: самомодифицирующийся код, внутренний загрузчик, умный формат гибких дисков и смещение таблиц поиска. В каждом своём модуле Prince Of Persia хранит сокровища инженерной мысли.

Чтение исходников позволило мне не только узнать больше о процессе разработки игр в 80-х, но и снова вызвало чувство признательности за те вещи, которые сегодня считаются естественными.

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

В этой статье я расскажу, как использовать описанные в прошлой статье инструменты для исследования игры Felix The Cat для NES. Моя первоначальная цель была, как обычно, разобрать формат уровней игры и добавить её в свой универсальный редактор уровней CadEditor, однако в ходе изучения игры обнаружилось, что описание уровней сжато (это редкость для NES-игр!), поэтому я также разобрал формат компрессии данных, и написал компрессор, позволяющий сжимать отредактированные уровни так же, как это делали разработчики игры.