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

Дышите.

Найди друга.

Написать.

Нарисовать.

Дышите: двигайтесь медленно, чтобы двигаться быстрее.

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

Лучшим девизом могло бы быть Двигайся медленно, чтобы двигаться быстро. Когда Facebook захотел выйти на новые страны, вместо того, чтобы создавать местные команды для каждой новой территории, он сделал нечто гораздо более изобретательное: он попросил своих пользователей переводить слова на другие языки, которые они знали. Бум. Facebook мгновенно набрал масштабы. Но это решение было не первым и не самым очевидным, и, вероятно, потребовалось больше времени, чтобы найти его. Требуется терпение, чтобы увидеть результаты сбора всех лучших переводов от своих пользователей для ~ 7000 языков мира, а не увидеть немедленные результаты перевода на популярные языки в зависимости от территорий, на которых Facebook наиболее популярен.

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

# Ruby Final Project - A Command Line Interface Program
* Make your application interactive (take user input and display some output)
* Use good object oriented principles
## Your task
Your task is to build out hangman.  Users guess letters, and depending on the word, each letter is filled in.  Think about how to model the program such that we could hold onto a user history, and see the number of games a user has won or lost.  Build this out in pure ruby.  You can use the require_all gem, and the pry gem.  Do not use any sql.
## Setup
You'll need to build this project from scratch, but your project should have a good, clean directory structure and looks similar to other gems. Following the directory structure common in other gems will make it easier for other developers to pick up your code and know where to find things. You're directory/file structure should look something like this:
```bash
├── README.md
├── LICENSE
├── .rspec
├── bin
│   └── run
├── app
│   └── models
├── tools
│   └── console.rb
```
### `bin/run`
The bin folder will hold your runner file which starts the program and should require only your environment file. You should be able to start your program by running `bin/run` in the command line. Remeber to put `#!/usr/bin/env ruby` at the top of your runner so that the command line knows to run it as a ruby file.
### `config/environment.rb`
The config folder should have your environment file, which should require all the other files that are needed to run your project, and load Bundler to require all of the dependencies listed in your Gemfile
### `README.md`
The README should be well written and clear. Anyone reading your readme should know exactly what your app/gem does, how to get it running on their computer, and how to contribute to it.
## Timeframe
We should wrap this project up on Tuesday morning.

Вы уже переезжаете?

Писать

Что ж, вместо того, чтобы начать яростно рисовать отношения и строить наши модели и классы — обычный первый шаг в объектно-ориентированном программировании, — Марселла предложила нечто гораздо более мудрое: Должны ли мы сначала написать наш ReadMe? — спросила она. Я задумался на минуту. "ДА."

Примечание для менее знакомых: файлы readme обычно представляют собой надоедливый файл .txt, который поставляется с большинством ваших внешних загрузок. БОЛЬШИНСТВО людей не читают свои ридми, но обычно неплохо начать с них, если это новая программа. Забавная мысль: может быть, программисты пишут ридми для себя, а не для пользователей…

Вот наш ридми.

To start the game, open your terminal and type in bin/run.
The hangperson game has a database built into the app with words and phrases. There are five categories, each of them containing words and phrases.
To begin the game, the application will ask the user for his or her name. Then, the user will be prompted to select one of five categories. The application then chooses a random word or phrase from that category. The application will display underscores for each letter in the word or phrase. The application will then prompt the user to guess a letter.
After each user letter or solve input, the user will see three things on the display: the hangperson, the incorrect guesses, and the puzzle. If the user guesses a letter which is not contained in the puzzle, the guessed letter will be stored under incorrect guesses. The user will also get one strike for each incorrect letter guessed, including if the user guesses the same incorrect letter multiple times. Each strike will add one part to the hangperson body. If the user enters a letter that is contained in the puzzle, the application will update the puzzle to reflect the placement of the correct letter. The hangperson and the incorrect guesses will also be displayed, but will not change after correct guesses.
Rules of the game:
The user has six strikes before the game ends, resulting in a loss for the user. If the user successfully guesses the word or phrase, or successfully “solves”, then the game ends, resulting in a win for the user.
If at any any point the user wants to "solve," he or she can type in the entire word or phrase at one time. If the guess is correct, the game ends, resulting in a win for the user. If the guess is incorrect, the game ends, resulting in a loss for the user.

Наш ридми выглядел не так, как вначале. Тем не менее, написав его вместе, мы сделали несколько удивительных вещей:

  • Согласовано наше видение игры
  • Тщательно определенные термины, такие как "выигрыш", "проигрыш", "решение"
  • Визуализировал игру
  • У нас была точка отсчета, когда мы кодировали, чтобы убедиться, что мы на правильном пути; мы постоянно модифицировали файл сведений, чтобы отразить любое новое мышление

Найди друга: парное программирование

Парное программирование может быть трудным. Как лучше всего работать вместе в группе над выпуском кода? Flatiron учит нас, что должно быть разделение обязанностей. Один человек должен быть водителем; другой, лидер. Водитель печатает код, а лидер разрабатывает стратегию / обсуждает, каким должен быть код. Эти двое постоянно меняются ролями, обычно через 25–30 минут.

Но прежде чем вы это сделаете, что бы вы хотели сделать по-другому?

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

Первое, что мы сделали, это поговорили о том, как нам нравится работать вместе.

  • Над чем вы хотите работать?
  • В чем вы чувствуете себя менее комфортно?
  • Что вы хотите сделать в первую очередь?
  • Что вы об этом думаете?
  • Как вы себя чувствуете?
  • Расскажите о своей семье. Расскажите мне о вас.

Этот шаг был самым важным.

Рисовать

Визуализация имеет решающее значение в объектно-ориентированном программировании. Рисуйте с отдачей. Стереть. Фотографировать. Перерисовать.

Повторить все это

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

Но что мы действительно узнали, так это то, что наша первая версия виселицы не следовала лучшим принципам объектно-ориентированного создания классов, когда каждый класс имел единственную ответственность. Читать ее было нелегко, и она не следовала принципу НЕ ПОВТОРЯЙТЕСЬ СЕБЯ.

Нам пришлось вернуться и сломать наш код, чтобы сделать его лучше. И мы делали это снова, и снова, и снова.

В заключении…

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

Потому что это возможность исправить некоторые из наших худших привычек.

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

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

Какую привычку/процесс вы хотите исправить? И какие еще аспекты своей жизни вы можете использовать, чтобы это исправить?

PSA: Если вы хотите поиграть в нашу первую версию палача, вы можете проверить наш гитхаб здесь. Это не идеально, но работает. Если вы впервые занимаетесь строительством во Флэтайроне, сделайте себе одолжение и сначала постройте его самостоятельно :)