Убийство монстров и создание программного обеспечения
Я начал программировать компьютеры, когда мне было восемь лет. Мама перевезла нас обратно в Джексонвилл, штат Флорида, где мы временно жили с моими тетей и дядей, пока она искала работу. И тетя, и дядя (которые были очень любезны нас поселить) были военными, поэтому они смогли купить персональный компьютер. Они принесли этого лоха домой, и я сразу начал играть в игры. Мне приходилось загружать игры на компьютер через большие дискеты... пятидюймовые квадраты, которые вставлялись в дисковод. Мой дядя и я играли в гольф, где нужно было нажать пробел, чтобы мяч покатился — символ @, который скользил по «зеленому», который представлял собой ряд символов #. Нажатие пробела во второй раз остановит мяч. Надеюсь, вы достаточно точно рассчитали время, чтобы мяч остановился над «отверстием» — пустым местом в ряду символов #. С этих пятидюймовых дискет началось мое изучение программирования на протяжении всей жизни.
Мне было всего восемь лет, но я очень быстро понял, как работают файлы README. Они пришли с компьютерными играми и помогли с подключением к BBS (системы досок объявлений, веб-серверы старой школы!). Я начал читать все больше и больше о том, как программировать на BASIC, потому что хотел сделать свою собственную игру.. По крайней мере, так все началось. Вскоре после изучения BASIC я понял, что компьютеру требуется очень много времени, чтобы завершить загрузку операционной системы, а затем мне придется выйти из ОС, чтобы программировать на BASIC. Чтобы сократить долгое время ожидания (пару минут), я «замыкал» процесс загрузки во время его загрузки. Тут я понял, чего хочу - создать загрузчик. Загрузчик был простой задачей, которую необходимо было выполнить, и это неизбежно привело бы меня к большему количеству проблем с программированием, как только я мог бы программировать быстрее, не дожидаясь часа в день.
Мне было десять, когда я начал играть в текстовые ролевые игры. Вспомните Dungeons and Dragons, но на BBS она называлась MajorMUD. Я загорелся желанием убить больше монстров и собрать больше золота и опыта, чтобы я мог стать сильнее как игрок и иметь хорошее игровое оборудование, чтобы атаковать других игроков. Это было известно в PvP (игрок против игрока), где вы могли атаковать других игроков в игре, пока вы играли. Игра в эту игру на локальной BBS означает, что вы звонили по местному номеру телефона, чтобы подключиться к серверу, который, вероятно, находился очень близко к тому месту, где вы физически жили. Именно здесь мой опыт программирования действительно оформился.
Моя первая бизнес-задача
Чтобы получить опыт и золото в MajorMUD, мне нужно было безостановочно печатать за клавиатурой. Если бы это была текстовая игра, в которой приходилось повторять одни и те же команды снова и снова, почему бы не написать программу, которая делает это за меня? Я бросился спрашивать других игроков, слышали ли они о способе сделать это — наверняка слышали. Они сказали: «Вы должны писать сценарии на PERL». Хм? Что такое PERL? Это был язык программирования/скриптов. Но мне было десять, поэтому в конце концов я просто понял, что это позволит мне написать приложение, которое будет делать что-то за меня на компьютере.
Я помню, как взломал сценарий, который уже был кем-то создан. Сценарий поставляется с некоторыми базовыми функциями, такими как возможность подключения к серверу самостоятельно. Даже если телефонная линия выйдет из строя, он будет повторно набирать тот же номер, пока не подключится. Сценарий также будет следовать по пути текстового файла. Текстовый файл имел направление для каждой строки, в котором скрипт будет двигаться, строка за строкой. Если бы вы хотели идти на восток, слово «восток» было бы на отдельной строке. Сценарий спускался по моему списку и перемещался из комнаты в комнату. Если бы в комнате были какие-нибудь монстры, он бы немедленно атаковал их. Это было полезно, но через несколько недель я обнаружил, что люди в игре называли себя близко к именам монстров, из-за чего мой скрипт немедленно начинал атаковать этого игрока! Это было плохо. Когда мне было десять лет, этот сценарий в MajorMUD был моей первой реальной проблемой программирования.
Обучение через применение
Многие люди спрашивают меня: «Как вы начали?» или «Как я могу заинтересовать своих детей программированием?» Ответ таков: найдите очень, очень маленькую и целенаправленную проблему, которую можно исправить с помощью программного обеспечения, и выясните, как код может решить эту проблему. Когда мне было десять, MajorMUD представил проблему, которую я понял, что могу решить. Как программист, случаи становятся немного сложнее, но процесс тот же — если вы не знаете решения, вы ищете его. Если нечему учиться, создадим.
Моя первая проблема преподала мне ценный урок, который я вспоминаю каждый раз, когда мы разбираем проект. Мне пришлось научиться сосредотачиваться на одной проблеме, стоящей на моем пути к X, чтобы решить настоящую конечную проблему. Мне не нужно было продолжать добавлять функции просто для того, чтобы добавить их — это одна из самых распространенных проблем, с которыми мы сталкиваемся, когда наши клиенты пытаются оценить свой проект. Единственное, что мне нужно было сделать, это написать достаточно кода приложения, чтобы решить мою проблему. Вы бы не стали находить пушистые вещи просто для того, чтобы что-то добавить, потому что, если бы вы это сделали, это раздуло бы код и испортило бы смысл программного обеспечения. В свои десять лет я просто хотел играть в игру — я не хотел кодировать весь день. Мы придерживаемся той же идеи для наших клиентов: создайте платформу, созданную для решения проблем, с которыми сталкиваются люди. Решите только эту проблему. Затем, если есть дополнительное время, мы тратим его на улучшение этого решения. В этом нет абсолютно ничего плохого.
MajorMUD был всего лишь одной простой проблемой, которую можно решить с помощью программного обеспечения, но реальное применение к корпоративному программному обеспечению не сильно отличается. Вот как я помогаю людям научиться программировать: найдите проблему и каким-то образом посмотрите, как вы можете автоматизировать или исправить ее с помощью программирования. Иногда научиться программировать не означает записаться в школу кодирования. Это означает решение проблемы путем программирования системы так, чтобы она что-то делала для вас, с помощью любой технологии или «языка», подходящих для решения.
Практическое применение
Допустим, вы хотите новый iPhone. Единственный способ узнать, находится ли телефон в магазине Apple Store рядом с вами, — это зайти на сайт apple.com, ввести свой почтовый индекс и нажать «Отправить», чтобы найти ближайший магазин. Затем он сообщает вам, есть ли там в настоящее время телефоны. Так почему бы не доверить эту работу компьютеру? Самый быстрый способ — начать поиск плагина Google Chrome и посмотреть, есть ли расширение или плагин, чтобы записывать нажатия клавиш и действия в Интернете. Я записывала, как захожу на сайт Apple, ввожу свой почтовый индекс в текстовое поле и нажимаю «Отправить». Вероятно, у плагина также был бы способ предупредить меня об определенном тексте на веб-странице, независимо от того, доступен ли на экране новый iPhone. Поиск существующего решения в контексте инструментов, которые вы используете в настоящее время, может помочь вам понять, что должно произойти, чтобы получить необходимую информацию.
В детстве компьютерные игры в то время были очень большой частью моей жизни. Моя проблема была такой же, как и у всех остальных на этом рынке: играть в игру, пока я не сижу перед компьютером. Эта проблема на самом деле ничем не отличается от попыток просмотреть веб-сайты в поисках самого дешевого рейса во Францию. Моя задача MajorMUD и проблема с поиском авиабилетов — это просто ряд задач, которые нужно выполнять определенным образом, в результате чего мы сталкиваемся с определенными проблемами по пути. Программирование — это автоматизация этих задач с использованием как можно меньшего количества кода и обеспечение того, чтобы большинство проблем, возникающих на пути, могли быть устранены программным обеспечением. Нет такого понятия, как сложное программное обеспечение или раздутое программное обеспечение. Единственное, что есть, это программное обеспечение, которое пытается решить слишком много проблем одновременно. В конце концов, поиск и устранение проблем при создании программного обеспечения — это просто прославленная версия убийства монстров.
