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

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

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

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

«Храм должен был быть вечным. Как сама глубина. А значит, не зависеть ни от одного сервера. Создающие Храм программы свободно блуждают по сети, их фрагменты дублируются, рекомбинируются, самостоятельно организуются для работы. Чтобы Храм исчез, надо уничтожить все машины в сети.»
— «Фальшивые зеркала», 1999 год, за 2 года до появления протокола BitTorrent


Сегодня стукнуло 41 год Брэму Коэну, создателю протокола BitTorrent.

Интересные факты:

• Коэн начал программировать в 10 лет.
• Коэн признается, что неспособен работать в фиксированном графике, по часам, в компании, предъявляющей строгие требования к дресс-коду, и категорически не может выполнять бессмысленную и неинтересную работу.
• Работал в компании «Evil Geniuses for a Better Tomorrow» и Работал в «Valve».
• Для тестирования BitTorrent Брэм собрал немалую пачку порнухи, которую и раздавали туда-сюда.
• Организатор конференции CodeCon.
• Есть жена и трое детей.
• Самый большой файл на раздаче — архив сайта geocities.com размером в 641 Гб.
• За первые два года было более 20 млн. закачек клиента, сейчас от 100 до 250 млн. пользователей BitTorrent.
• В 2008 в раздачах исполняемых файлов 18% были заражены.
• В 2009 от 43% до 70% трафика в Интернет принадлежало Peer-to-peer сетям.
• В 2009 более 14.5% BitTorrent загрузок содержало zero-day вредоносные программы и поэтому BitTorrent был механизмом дистрибуции 47% zero-day зловредов.
• Технологией BitTorrent пользуются Facebook, Twitter, Internet Archive, Blizzard, World of Tanks, Eve Online, правительство Великобритании, научные исследования (BOINC), множество open source и free software проектов.

Привет, %username%! Бывает необходимо генерировать ID не подряд, причем чтобы они гарантированно не повторялись. На youtube это используется для того, чтобы вы не могли брутфорсом получить все новые и старые видосики, так же это не редкость на разных файлообменниках и вообще везде где нужно предотвратить или хотя бы затруднить возможность прямого перебора значений.


К примеру, в системе moodle, которая использовалась у нас в универе для тестирования студентов, ID ответов были инкрементными и сквозными на всю базу. Логично предположить, что правильным ответом был тот, что с наименьшим ID в пределах вопроса. В общем, проблем с тестами у нас не было. Потом они перешли на GUID, но я к тому моменту уже выпустился, хехе.

Давайте рассмотрим несколько способов генерации таких ограниченных по длине последовательностей от самых простых до криптографически стойких.

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

Если добавить строку к чему-то, то он допустит, что мы хотим получить текст, поэтому сконвертирует все в строку.

Если мы добавляем префикс "плюс" или "минус", то он допустит, что нам нужно числовое представление и сконвертирует строку в число, если сможет.

Если мы отрицаем что-то, то он сконвертирует это в булево значение.

Мы можем использовать эти особенности языка и создать немного магии со всего-лишь шестью символами: [,],(,),! и +. Если вы читаете это на десктопе, то можете открыть консоль в вашем браузере (developer tools, например) и запускать код. Просто копируйте любой код из примеров ниже в консоль, и он должен исполнится и вернуть true.

Давайте начнем с простого. Вот главные правила:

1. Префикс ! конвертирует в Boolean
2. Префикс + конвертирует в Number
3. Добавление [] конвертирует String

Вот они в действии:

![] === false
+[] === 0
[]+[] === ""

В этой статье мы поговорим об ошибках, совершаемых программистами на Bash. Во всех приведённых примерах есть какие-то изъяны. Вам удастся избежать многих из нижеописанных ошибок, если вы всегда будете использовать кавычки и никогда не будете использовать разбиение на слова (wordsplitting)! Разбиение на слова — это ущербная легаси-практика, унаследованная из оболочки Bourne. Она применяется по умолчанию, если вы не заключаете подстановки (expansions) в кавычки. В общем, подавляющее большинство подводных камней так или иначе связаны с подстановкой без кавычек, что приводит к разбиению на слова и глоббингу (globbing) получившегося результата.

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

Предисловие

Изменение .NET метода MSIL кода во время выполнения приложения – это очень круто. Это настолько круто, что можно перехватывать вызовы функций (hooking), сделать защиту своего ПО и другие удивительные вещи. Именно поэтому мне уже давно хотелось это осуществить, но была одна проблема – MSIL код компилируется в машинный код с помощью JIT перед тем, как мы сможем что-либо с этим кодом сделать. А так как .NET CLR не документирована и изменяется от версии к версии, то мы и будем искать стабильный и надёжный путь, независимый от точного расположения адресов в памяти.

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

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

«Работать в Unity так приятно и удобно: много возможностей для самореализации» — говорили мне, но всё оказалось не так просто. В данной статье не будет петься хвалебных од Unity. Эта статья о суровых реалиях, ограничениях и сложностях, с которыми столкнулась наша маленькая команда инди-разработчиков при создании своей первой, но достаточно крупной игры Death Point.



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

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

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

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

Суть в том, что в изучаемой мной игре есть большое количество анимированных спрайтов человечков (как я изначально считал — заранее отрендеренных). Человечки разные (по-разному одетые, разных цветов и т.п.).

Давайте поговорим о физике транспортных средств

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

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

Перевод поста Стивена Вольфрама "Untangling the Tale of Ada Lovelace".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе и подготовке публикации.

---

Содержание

Ранние годы Ады
Чарльз Бэббидж
Уровень развития этой области
Возвращаемся к Аде
Возвращаясь к Бэббиджу
Статья Ады
После статьи
После смерти Ады
Что стало с Бэббиджем?
Повторное открытие
О чем на самом деле писала Ада
Вычисление чисел Бернулли
Бэббидж vs. Ада?
Секретный ингредиент Бэббиджа
В большем масштабе
А что, если...
Какими они были?
Заключение

---

Ада Лавлейс родилась 200 лет назад. Для некоторых она является знаменательной фигурой в истории вычислительной техники; для других — изрядно переоцененной личностью. В течение долгого времени я пытался разобраться, как всё было на самом деле. И вот, к её двухсотлетию, я решил разобраться в том, что называл для себя "тайной Ады".

Получилось намного сложнее, чем я ожидал. Историки расходятся во мнениях. Личности в истории сложно изучать. Технологии трудно понять. Вся история переплетается с обычаями 19-го века британского высшего общества. И есть удивительное количество ошибочных сведений и неверных трактовок.

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

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

В этой статья мне хотелось бы рассказать о том, как была ускорена отрисовка монстров при создании игры Alien Massacre. Данное решение подойдет для любых проектов, которые испольуют спрайтовую анимацию.

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

• 1 Необходимо обеспечить отрисовку большого числа анимированных объектов на сцене. Ведь мы хотим, чтобы игрок отстреливался от полчищ монстров.
• 2 Прогресс анимации должен быть различен для каждого из объектов. Ведь мы не хотим, чтобы мобы ходили строем.

Решение «из коробки»

Безусловно, первое решение было простым: все сделать с помощью уже встроенного в UnityEngine компонента Animator. Посмотрим, что из этого получается.

На первый взгляд, dynamic в C# — просто object с поддержкой машинерии компилятора. Но не совсем.

Ядром времени выполнения является DLR (Dynamic Language Runtime) — подсистема/фреймворк для поддержки динамических языков программирования. Существует реализация под собственно C#, который идет в поставке с .NET, и отдельная для Iron-языков.

Когда мы работаем с обобщениями (generics), то CLR имеет свои оптимизации на предмет специализации оных. В тот момент, когда CLR+DLR должны работать с generics вместе, поведение написанного кода может стать непредсказуемым.

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Предлагаю вашему вниманию перевод статьи Fast-Paced Multiplayer (Part I): Introduction.

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

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

• Структуры данных
• Алгоритмы и «концепции»
• Язык программирования

интервьюер: Приветствую, хотите кофе или что-нибудь еще? Нужен перерыв?

я: Нет, кажется я уже выпил достаточно кофе!

интервьюер: Отлично, отлично. Как вы относитесь к написанию кода на доске?

я: Я только так код и пишу!

интервьюер: ...

я: Это была шутка.

интервьюер: OK, итак, вам знакома задача "fizz buzz"?

я: ...

интервьюер: Это было да или нет?

я: Это что-то вроде "Не могу поверить, что вы меня об этом спрашиваете."

интервьюер: OK, значит, нужно напечатать числа от 1 до 100, только если число делится нацело на 3, напечатать слово "fizz", если на 5 — "buzz", а если делится на 15, то — "fizzbuzz".

я: Я знаю эту задачу.

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

я: ...

интервьюер: Вот маркер и губка.

я: [задумался на пару минут]

интервьюер: Вам нужна помощь, чтобы начать?

я: Нет, нет, все в порядке. Итак, начнем с пары стандартных импортов:

import numpy as np
import tensorflow as tf

интервьюер: Эм, вы же правильно поняли проблему в fizzbuzz, верно?

я: Так точно. Давайте обсудим модели. Я думаю тут подойдет простой многослойный перцептрон с одним скрытым слоем.

Уже через две с половиной недели в Питере пройдет большая .NET-конференция DotNext.

Предыдущая конференция DotNext прошла в декабре в Москве. В этом посте я, по уже сложившейся традиции, расскажу о ее лучших докладах (по мнению участников).

Конференцию посетило около 450 человек, и еще около 100-150 смотрели ее онлайн. Свои отзывы нам оставили более 400 человек — это около 70% участников. Такой процент позволяет нам говорить о том, что наша выборка релевантна, а рейтинг — довольно объективен.

10 место

Александр ControlFlow Шведов, JetBrains — Дизайн и эволюция C# на примере свойств
Средняя оценка: 4.41



Эдакий экскурс в историю построения языка, позволяющий взглянуть на один из элементов современного C# глазами ее разработчиков. В докладе речь идет не только о том, какие свойства сейчас, но и о том, как они эволюционировали от версии к версии.

В этой серии из двух статей о производительности и памяти описываются базовые принципы и приводятся советы для разработчиков по повышению производительности программного обеспечения. Эти статьи затрагивают, в частности, работу памяти и компоновку. В первой части было рассказано об использовании регистров и о применении алгоритмов блокирования для повышения многократного использования данных. В этой части статьи сначала описывается компоновка данных для обычного распараллеливания — программирования для общей памяти с потоками, а затем распределенные вычисления по сетям MPI. В статье описываются понятия, связанные с распараллеливанием: векторизация (инструкции SIMD) и работа с общей памятью (многопоточная архитектура), а также вычисления с распределенной памятью. И наконец, в этой статье сравниваются компоновки данных «массив структур» (AOS) и «структура массивов» (SOA).

… Молвит он: «Коль жив я буду, чудный остров навещу, у Гвидона погощу».

В царстве Салтана не без изьяна. Принят закон — не лезть за кордон, да тут князь Гвидон.
Опять прислал поклон, да приглашение на угощение,- надо принимать политическое решение.

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

Было однако одна проблема,- нужен был маршрут или схема. Поскольку никто (кроме Врангеля барона) не знал, как добраться до острова Гвидона. Корабельщики дали карту,- пришлось сесть за парту. Над картой склонился Салтан, — где тут остров Буян? Задача была как будто знакома — проложить путь к острову Гвидона. Но как найти дорогу, когда путей слишком много?

До ночи решал Салтан задачку, в итоге свалился в спячку. Снились ему матрицы и точки, да на болоте кочки. На кочку прыгнул Нео с острова Борнео.
— Если хочешь добраться ко сроку — плыви по максимальному потоку.
— Чего? — Салтан почти проснулся. Но Нео уже в зайца обернулся.