Этот пост является 3-й частью статьи «Создание игры «The Contender» («Соперник»)»: концепция завершения". Здесь ссылки на часть 1 (как мы сделали игру) и часть 2 (как мы запускали проект на Kickstarter).

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

Я — Джон Тисдэйл. Мы с другом создали «The Contender» («Соперник»): игра на тему президентских дебатов. 9 сентября 2015 года мы собрали 127 827,01 долларов США на Kickstarter. Казалось бы — очень большие деньги, но лишь на этой неделе, 22-го ноября 2016 года, мы, наконец, расплатились с долгами. Прошло 440 дней работы после создания продукта и кампании на Kickstarter, прежде чем мы получили 1 доллар.

Мы не ожидали, что так будет.

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

Есть ли свет в конце туннеля для провайдеров транзитного трафика?

Я был поражён на недавней встрече NANOG тем, как мало выступлений было по вопросам ISP-пространства и по проблемам, связанным с ISP-операциями, и как много — по среде дата-центров.

Если есть тема, которая является определяющей в нашем общении, то это, безусловно — среда, которая, как представляется, доминирует при проектировании дата-центров и эксплуатации сетей. И, представляется, что функция поставщика интернет-услуг (ISP-функция) и, в частности, функция поставщика транзитного трафика исчезает. Задача доставки пользователей к контенту меняется на задачу доставки контента к пользователям. Означает ли это, что транзит для интернет-пользователей теперь перестаёт действовать? Давайте посмотрим на это немного внимательнее.

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

• Вы начинаете искать новую работу
• Новая работа начинает искать вас

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

Известно, что на старых картах, на неизведанных территориях, часто помещали зловещее предупреждение: «Здесь живут драконы». Вероятно, смысл этого предупреждения состоял в том, что не стоит входить в это пространство мира, не будучи готовыми сражаться с внушающим ужас противником. Всё что угодно может случиться на этих загадочных просторах, и нередко такое «что угодно» может закончиться очень плохо.

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

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

Вот семь из устрашающих уголков мира программирования, на которых легко можно написать: «Здесь живут драконы».

Ещё не угасла надежда на слабый сигнал Wi-Fi в аэропорту, на заряд батареи, который вот-вот заставит ноутбук вырубиться — а розетку здесь найти та ещё задача — и на то, что письмо клиенту на миллион долларов вроде ушло. И в этот момент «пожалуйста, заработай» вылезает приводящее в шок сообщение: «Упс».


Ошибка. Упс… возникла серверная ошибка и ваше письмо не отправилось.

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

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

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

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

Отмеченный наградами блоггер Кевин Маркс, основатель Microformats и бывший вице-президент веб-сервисов в BT, решил изучить проблему после того, как заметил, что стал испытывать всё больше трудностей при чтении текста на экране.

1 Почему JavaScript отстой
• 1.1 Плохая конструкция
• 1.2 Система типов
• 1.3 Плохие функции
• 1.4 Отсутствующие функции
• 1.5 DOM
2 Почему Lua отстой
3 Почему PHP отстой
• 3.1 Исправлено в поддерживаемых в настоящее время версиях
4 Почему Perl 5 отстой
5 Почему Python отстой
• 5.1 Исправлено в Python 3
6 Почему Ruby отстой
7 Почему Flex/ActionScript отстой
8 Почему скриптовые языки отстой
9 Почему C отстой
10 Почему C++ отстой
11 Почему .NET отстой
12 Почему C# отстой
13 Почему VB.NET отстой
15 Почему Objective-C отстой
16 Почему Java отстой
• 16.1 Синтаксис
• 16.2 Исправлено в Java 7 (2011)
• 16.3 Модель
• 16.4 Библиотека
• 16.5 Обсуждение
17 Почему Backbase отстой
18 Почему XML отстой
19 Почему отстой XSLT/XPath
20 Почему CSS отстой
• 20.1 Исправлено в CSS3
21 Почему Scala отстой
22 Почему Haskell отстой
23 Почему Closure отстой
24 Почему Go отстой
• 24.1 Базовые средства программирования (базовый язык)
• 24.2 Взаимосовместимость
• 24.3 Стандартная библиотека
• 24.4 Набор инструментальных средств
• 24.5 Сообщество
25 Почему Rust отстой
• 25.1 Безопасность
• 25.2 Синтаксис
• 25.3 Конструкция API и система типов
• 25.4 Сообщество
• 25.5 Набор инструментальных средств

Почему JavaScript отстой

Учтите, что некоторые положения относятся не к самому JavaScript, а к программным интерфейсам веб-приложений (https://developer.mozilla.org/en/docs/Web/API).

Плохая конструкция

• Каждый скрипт исполняется в едином глобальном пространстве имён, доступ в которое возможен в браузерах с оконным объектом.
• Camel-регистр никуда не годится:

XMLHttpRequest
HTMLHRElement

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

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

«Диагноз — не конец, а начало дела».
Мартин Х. Фишер.

Недавно я проходил телефонное собеседование с кадровиком из Google. Поскольку я соответствовал критериям на такое (добровольное) собеседование, но не смог пройти тест, в этом посте перечислены вопросы и предполагаемые ответы на них. Этот пост может оказаться полезным тем, кому в один прекрасный день позвонят из Гугла.

Для ясности: я начал заниматься программированием 37 лет назад (мне тогда было 11 лет) и постоянно занимаюсь этим. Кроме того, 24 года назад (мне было 24) я был назначен директором по исследованиям и развитию; с тех пор среди многих других работ мною были проведены НИОКР по наиболее ответственным частям проектов TWD — все они поставляются, как коммерческие продукты:

• Глобальная WAN-сеть (распределённая C/VHDL L2 VPN, базирующаяся на кастомном kernel-bypass IP-стэке и нашем собственном методе постквантового шифрования)
• G-WAN (200-килобайтный сервер прикладных программ с 17 заложенными языками программирования C/C++, C#, Objective-C, Java, Go, PHP и т.д.)
• Remote-Anything (запатентованное решение управления сетью предприятия, 280 млн. лицензий, используемых в 138 странах)

Представитель Гугла подчеркнул, что требуется как опыт управления, так и современного программирования (редкое сочетание). Но наличие более 20 лет опыта в первом и почти 40 лет во втором оказалось недостаточным — я не смог дать «правильные ответы». Означает ли это, что Гугл слишком высоко поднимает планку или что у его кадровиков самих не хватает знаний, которые они, как предполагается, должны оценивать?

Давайте посмотрим!

Здесь встречают по манерам…

В 17-ом веке во Франции манеры приобрели политическое значение. Король Людовик XIV и его предшественники, собирая вместе аристократию Франции под одной крышей с сувереном в его дворце в Версале, основали своего рода школу манер.

Во дворце придворные жили под деспотическим надзором короля. Если вы вызывали недовольство Людовика, то он просто высказывал пожелание «не видеть вас» на следующий день. И желание короля «не видеть вас» было равносильно полному забвению вас в Версале.

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

Маргарет Виссер

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

Эстер Шиндлер — автор свободно распространяемого выпуска «Руководство по выживанию для сотрудников, работающих удалённо».


Кубиклы

С позиции пользователя, iOS — выдающаяся платформа. Возможно, несколько монотонная и жёсткая, но привлекательная и надёжная (в основном).

С позиции разработчика дела обстоят совсем иначе. Работать с iOS (а на самом деле, вообще, с Apple) — всё равно, что пытаться разговаривать с параноидальным роботом, действующим как известный советский пограничник из романа Кафки.

В начале этого сентября в Windows, как часть 53-го обновления, появился новый модифицированный дизайн основного пользовательского интерфейса Chrome, т.н. «Chrome MD» (Material design). Он стал последней ступенью трёхступенчатого ввода в действие нового дизайна, который был начат в релизе 51 с Chrome OS и Linux и был продолжен в релизе 52 с macOS. Windows стала высшей точкой этого процесса, и, поскольку Chrome не закончится никогда, то мне кажется, что сейчас самое время оглянуться и поразмышлять над этим процессом, который занял почти 2 года и который дал некоторые знания и опыт, полезные, возможно, и для вас.

Занимаясь поиском сотрудников или поиском удалённой работы, мы часто озабочены только самим, конкретным, рабочим местом и не обращаем внимания на коллектив, связанный с ним. Такое смещение внимания может не только привести к решениям, основанным на недостоверной информации, но также и нивелировать потенциальные достоинства удалённой работы.

Как тролли захватили ваш любимый сайт вопросов и ответов по программированию

Сайт Stack Overflow был создан в 2008 году Джеффом Этвудом и Джоэлем Спольским как более открытая альтернатива возникшим ранее аналогичным сайтам, таким как, например, Experts-Exchange. Название для сайта было выбрано голосованием в апреле 2008 года читателями популярного блога по программированию Coding Horror, который вёл Этвуд.

Многие годы сайт Stack Overflow был одним из самых популярных ресурсов для программистов, пытающихся решить какую-то проблему. Поскольку вопросы, размещавшиеся на Stack Overflow, часто оказывались среди первых, которые выдавал Google в каком-либо поиске, относившемся к программированию, то пользователи массово приходили на сайт и начинали задавать свои собственные вопросы.

На июль 2015 года у Stack Overflow было более 4 млн. зарегистрированных пользователей и почти 10 млн. вопросов (без учёта удалённых пользователей и вопросов). Однако в исследовании 2013 года было выявлено, что 77% пользователей задают только один вопрос, 65% отвечают только на один вопрос и лишь 8% пользователей дают ответы на более чем 5 вопросов. В настоящей статье я хотел бы рассмотреть возможные причины такого чрезвычайно низкого процента.

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

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

Хорошая разработка пользовательского интерфейса решает обе эти проблемы проектирования:

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

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

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

Жизнь прекрасна. А затем происходит нечто.

(Поскольку люди спрашивали: Sublime Text 3 с «Spacegray Light» («платиново-серый светлый») из Materialize и гарнитура Ubuntu Mono Bold)

Как и большинство других студентов, обучавшихся по программе компьютерных наук в Калифорнийском университете в Сан-Диего, я в течение нескольких лет шёл через различные курсы просто «накатом». Я никогда не был ни хорошим, ни плохим по успеваемости, и мой средний балл был «не очень». Я любил курсы программирования с их чрезвычайно сложными заданиями; математический анализ же был мне не по душе.

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

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

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

Ниже показаны 44 наиболее популярных проекта, появившихся на Product Hunt за лето 2016 года, каждый из которых набрал более 1 000 голосов. Надеемся, вы найдёте в этом списке много того, что поможет вам подготовиться к творческому, продуктивному и волнующему вас сезону «погружения в работу». Получайте удовольствие.