• Грандиозная битва в EVE Online, кто потерял 300000$ и что же всё-таки там произошло

    • Перевод
    Несколько дней назад в интернете появилась новость о самой масштабной битве в игре EVE Online, в которой было уничтожено кораблей на 300000 долларов. Многим оказалось интересно, как в какой-то битве в онлайн игре можно потерять столько денег. Но, большинство текстов про эту эпических масштабов битву написано языком, в котором не играющему в EVE Online человеку понятны лишь предлоги и матерные слова. Пару дней назад я наткнулся на очень интересную статью, где всё произошедшее описано очень простым и понятным языком.

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


    Читать дальше
  • Пессимальные Алгоритмы и Анализ Вычислительной Усложнённости

    • Перевод
    «Усложнённость (Simplexity) — процесс, которым природа достигает простых результатов сложными путями.» — Bruce Schiff



    1. Введение


    Представьте себе следующую задачу: у нас есть таблица из n целочисленных ключей A1, A2, …, An, и целочисленное значение X. Нам нужно найти индекс числа X в этой таблице, но при этом мы особо никуда не торопимся. На самом деле, мы бы хотели делать это как можно дольше.

    Для этой задачи мы могли бы остановиться на самом тривиальном алгоритме, а именно, перебирать все An по порядку и сравнивать их с X. Но, может так случиться, что X = A1, и алгоритм остановится на самом первом шаге. Таким образом, мы видим, что наивный алгоритм в наилучшем случае имеет временную сложность O(1). Возникает вопрос — можем ли мы улучшить (то есть, ухудшить) этот результат?

    Разумеется, мы можем сильно замедлить этот алгоритм, добавив в него пустых циклов перед первой проверкой равенства X и A1. Но, к сожалению, этот способ нам не годится, потому что любой дурак заметит, что алгоритм просто-напросто впустую тратит время. Таким образом, нам нужно найти такой алгоритм, который бы всё-таки продвигался к цели, не смотря на отсутствие энтузиазма, или вовсе желания до неё в конечном итоге дойти.
    Заинтригованы? Добро пожаловать под кат.
  • Что можно узнать о кандидате по тестовому заданию

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

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

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

      На экране есть сетка M на N из цветных квадратиков. Нужно реализовать на этой сетке следующий эффект — по клику слева направо со скоростью V пробегает волна, меняя цвет квадратиков на другой (единый для всей волны). Эффект должен работать при любых значениях M, N, V. Волна начинается всегда у левой стенки. Одновременно может идти несколько волн разного цвета.
      Анимационный пример: http://dl.dropbox.com/u/3601116/wave.swf (покликать по флэшке).


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

      А у меня получилась следующая статистика:

      1. В итоге, задание взяли чуть больше 20 человек.
      2. Пара человек ничего не сделали.
      3. Половина из оставшихся (по моим критериям) с ним не справились.
      4. Кандидаты четко разделились на весьма интересные группы.

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

        Представьте на минутку обычного программиста. Допустим, его зовут Вася и ему нужно сделать анимированную менюшку на сайт/десктоп приложение/мобильный апп. Знаете, которые выезжают сверху вниз, как меню у окна Windows или меню с яблочком у OS X. Вот такое.

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

        var opened = false;

        Вроде, работает. Но, если быстро кликать по кнопке, меню начинает моргать, открываясь и закрываясь не успев доанимироваться в конечное состояние. Вася добавляет флаг animating. Теперь код у нас такой:

        var opened = false;
        var animating = false;
        
        function onClick(event) {
          if (animating) return;
          if (opened) close();
          else open();
        }
        

        Через какое-то время Васе говорят, что меню может быть полностью выключено и неактивно. Не вопрос! Мы-то с вами тут программисты опытные, все понимаем, что… нужно добавить ЕЩЕ ОДИН ФЛАГ! И, всего-то через пару дней разработки, код меню уже пестрит двустрочными IF-ами типа вот такого:

        if (enabled && opened && !animating && !selected && finishedTransition && !endOfTheWorld && ...) { ... }

        Вася начинает задаваться вопросами: как вообще может быть, что animating == true и enabled == false; почему у него время от времени все глючит; как тут вообще поймешь в каком состоянии находится меню. Ага! Состояния... О них дальше и пойдет речь.

        Знакомьтесь, это Вася.


        Читать дальше →
      • Как вырастить программу из прототипа

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


          А что, если я скажу, что не все проекты одинаковые, и некоторые из них не то что можно, а даже нужно тщательно выращивать из прототипа? Об этом я рассказывал на конференции Unite'12, а сейчас расскажу вам.
          Читать дальше →
        • RPG для разработчиков. Два года спустя

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

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

            Топик тогда собрал 100500 комментов (в основном «супер! хочу!»), а особо заразительные собрались в команды и стали воплощать идею в жизнь. Так что же было сделано за эти два года?


            Читать дальше →
          • Achievements в Visual Studio

              Год назад пробегал топик, мол, а что если сделать в Visual Studio ачивки как в MMO? И вот, народ сделал. Пока что ачивок маловато, но тренд интересный.

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

              Приятно, что кто-то пытается воплотить эти идеи в жизнь.

              Странно, но на хабре эта новость как-то прошла незамеченной и поиск ничего не дал.
            • Coder vs. Developer vs. Engineer — а какой Job Title у тебя, %username%?

                Computer Scientist, Software Engineer и Coder заходят в бар.
                — О, а вот и программисты! — окликает их бармен...


                Я знаю людей, которые программируют уже не один десяток лет, но обижаются, когда их называют "программистами". А по запросу Coder vs Developer vs Software Engineer в гугле находится 113 000 000 ссылок: 1 2 3 4 5 6 7 8 9 … 113 000 000. Что интересно, можно найти совершенно противоположные мнения об одном и том же. С чем-то я согласен, а с чем-то в корне нет.

                Последние же несколько лет так вообще постоянно подливают масло в огонь, появляются какие-то совсем странные программисты, которые называют себя Creative Technologist, Creative Coder и Interactive Developer.

                Давайте же попробуем разобраться.
                Читать дальше →
              • Как я проходил собеседование в компанию Zynga

                  На Хабре опять стали появляться статьи о том, как проходить собеседования на должность программиста. Материал из них полезен соискателям так же, как учебники полезны студентам во время сессии. Вызубрите том по Мат. Анализу и, если попадете на тот экзамен, получите пятерку.

                  Гораздо интереснее читать реальные истории людей, которые описывают свой опыт собеседований в ту или иную известную компанию. Что спрашивали, что не спрашивали, какая была атмосфера, сколько проходило интервью? Такие данные много полезнее, чем «а зазубри еще это, авось спросят».

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

                  Ну, и картиночка на затравку.


                  Читать дальше →
                • Scala + Processing – интересный способ выучить новый язык

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

                    Но что можно сделать такого интересного на Scala? На самом деле, выбор не слишком большой. Я как-то придумал небольшую тулзу, неспешно написал ее, и «забил». А через несколько месяцев, к своему стыду, гуглил синтаксис «for loop»…

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

                    Я переписал на Scala и выложил на GitHub парочку примеров. На скрине как раз один из них — MSA Fluids. Заинтересовавшихся прошу под кат.

                    Читать дальше →