Как я создал приложение, демонстрирующее первое и последнее предложения великих романов

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

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

«Самое важное предложение в любой статье - первое.

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

- О хорошем письме, Уильям Зинссер

Один из способов понять, как строить хорошие предложения, - это напечатать прозу писателей, которыми вы восхищаетесь, при чтении ее вслух. Хантер С. Томпсон переписывал романы целиком, набивая на пишущей машинке Великий Гэтсби и Прощай, оружие, чтобы Фицджеральд и Хемингуэй взяли его в руки.

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

Но я могу прочитать только определенное количество книг и записать только определенное количество предложений за те несколько часов, которые у меня есть каждый день между заработком долларов и получением Z. Детей вырастить, коврики пропылесосить, Очень странные дела - выпить - ну, знаете, жизнь.

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

Так уж вышло, что моя последняя навязчивая идея - научиться программировать на JavaScript. Итак, с моими ограниченными знаниями я начал создавать это место сам, используя фреймворки JavaScript MongoDB, Express, Angular 2 и Node.js, известные под общим названием стек MEAN. Я назвал это (очень простое) веб-приложение Первое и последнее.

«Некоторые ценят изобразительное искусство; другие ценят прекрасные вина. Я ценю прекрасные предложения ».

- Как написать предложение и как его прочитать, Стэнли Фиш

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

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

Читать все

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

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

- О писательстве, Стивен Кинг

Возможно, вы хотите завести блог или написать Средний пост для Free Code Camp. Может быть, вы хотите произвести впечатление на своего начальника, написав более качественные отчеты.

В моем городе - Оттаве, Онтарио - около 150 000 человек работают на федеральное правительство Канады. Еще тысячи работают в городе. Я считаю, что наиболее часто публикуются правительственные документы: служебные записки, информационные бюллетени, постановления, пресс-релизы, политики, общественные рекомендации, руководящие принципы и т. Д.

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

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

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

Да, эти книги часто изобилуют штампами. Но они никогда не сбивают с толку. Такие авторы, как Джеймс Паттерсон, Линвуд Барклай и Харлан Кобен, знают толк в упрощении предложений. Я многому научился, изучая их сочинение - я не книжный сноб - и вы найдете некоторые из их предложений в «Первом» и «Последнем».

«Если это похоже на письмо, я его переписываю».

- 10 правил письма, Элмор Леонард

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

С другой стороны, не рекомендуется заниматься Улиссом после пятой Багама-мамы.

Недостаточно информации

Моя основная техническая цель при создании First и Last была проста: получить данные из браузера, вставить их в базу данных, а затем вернуть в браузер для отображения. Вот и все. Я хотел узнать, как информация перемещается между интерфейсом (Angular) и сервером (Node и MongoDB).

Другими словами, я хотел создать приложение, которое выполняло бы четыре основные операции с базой данных - создание, чтение, обновление и удаление (CRUD). Я не фанат аббревиатур, но должен признать, мне нравятся CRUD и MEAN. Эти ласковые слова в адрес угрюмого пессимиста.

Шаг 1. Получите данные пользователя

Шаг 2. Сохраните в MongoDB

Шаг 3. Извлечь из базы данных и отобразить в браузере

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

Чтобы отобразить мои сохраненные предложения в браузере, мне сначала нужно было извлечь их из базы данных. Когда я спросил MongoDB о трех случайных записях, он вернул массив с тремя объектами. В Angular я назначил полученные данные локальному массиву, называемому «предложениями», который я объявил содержащим объекты.

export class DisplayallComponent implements OnInit {  
  sentences: [Object]; 
  

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

const SentenceSchema = mongoose.Schema({  
  likes: {  
    type: Number, default: 0 
  }, 
  likedBy: {  
    type: [String] 
  }

Опять без проблем. Наконец, я добавил комментарии. Каждый объект комментария будет содержать имя пользователя и тело комментария. Я добавил массив объектов в свою схему данных, объявив его так же, как я сделал для своего массива «предложений» в Angular.

const SentenceSchema = mongoose.Schema({  
  likes: {  
    type: Number, default: 0 
  }, 
  likedBy: {  
    type: [String] 
  },
  comments: {
    type: [Object]
  } 

Однако когда я попробовал комментировать, это не сработало. Не было явных ошибок в интерфейсе, не кричал красный текст в консоли Chrome DevTools. Однако когда я заглянул в базу данных, комментариев, которые я отправил в браузере, нигде не было.

После небольшого количества попыток-попробуй-то и тихих ночных проклятий я понял, в чем проблема. Как оказалось, MongoDB хотел, чтобы я был более конкретным, чем Angular. Мне пришлось указать ему типы данных каждого элемента в объекте комментария в моем массиве «комментариев». Недостаточно просто заявить, что массив содержит объекты.

comments: [{
       username: String,
       body: String
 }],

Казалось бы, у программистов есть по крайней мере одна общая черта с автором книги Пятьдесят оттенков серого. Иногда стоит быть более точным.

Держи это коротко (иш)

Я люблю хорошие длинные предложения, правда. Гаррисон Кейллор, прославившийся Домашний компаньон в прериях, пишет красивые, забавные, бессвязные предложения, которые заканчиваются только тогда, когда заканчиваются чернила. Писательница Э. Доктороу начинает Билли Батгейт предложением из 131 слова и заканчивается громкостью из 277 слов. В легенде научно-популярной литературы Гей Талезе Жизнь писателя есть предложение, состоящее из ЧЕТЫРЕ СОТНИ ДЕВЯТНАДЦАТЬ слов.

Но не заблуждайтесь - эти писатели выпендриваются. Они хорошо разбираются в своем деле и хотят, чтобы вы это знали. И меня это устраивает. Потому что в руках великого писателя любое предложение, даже на одно длиннее, чем рецепт Шакила О’Нила в Burger King, будет под контролем.

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

Одним словом, блерг.

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

Слишком много информации

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

У журналистов толстая кожа. Нам это нужно. Например, ранее на этой неделе я получил следующее письмо - от одного парня, который снимает роскошные апартаменты в Будапеште - о статье о прерывистом голодании, которую я написал в 2013 году.

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

if(this.authService.loggedIn()) {
  const isInArray = sentence.likedBy.includes(this.username); 
  if(!isInArray) {
    sentence.likedBy.push(this.username); 
    this.authService.incrementLikes(sentence).subscribe(data => {
      this.sentences[index] = data;

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

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

К сожалению, в моей модели данных в бэкенде это было.

module.exports.incrementLikes = function(sentence, callback) {
  const query = {_id:sentence._id};
  sentence.likes++;
  const likesPlus = sentence.likes;
  const likesUserArray = sentence.likedBy;
  const newLikeUser = likesUserArray[likesUserArray.length - 1];
  Sentences.findOneAndUpdate(query, 
    {likes: likesPlus, $push:{likedBy: newLikeUser}}, 
    {new: true}, callback
  );
}

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

Если этого не было достаточно, я скопировал весь массив «LikeBy» из объекта предложения, переданного функции, а затем сделал ДРУГОЙ локальную переменную для хранения последнего имени пользователя в этом массиве, прежде чем, наконец, вставить это имя пользователя в массив «любилBy» базы данных.

Это сработало, но все же. Нелепый.

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

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

onLikeClick(sentence, index) {
  if(this.authService.loggedIn()) {
    const isInArray = sentence.likedBy.includes(this.username); 
    if(!isInArray) {
      const updateLikes = {
        likeID: sentence._id,
        likeUsername: this.username
      }
      this.authService.incrementLikes(updateLikes).subscribe(data =>
          this.sentences[index] = data;

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

module.exports.incrementLikes = function(updateLikes, callback) {
  const query = {_id:updateLikes.likeID};
  const newLikeUser = updateLikes.likeUsername;
  Sentences.findOneAndUpdate(query, 
    {$inc: {likes: 1}, $push: {likedBy: newLikeUser}}, 
    {new: true}, callback
  );
}

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

Нет смысла передавать ненужную информацию.

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

Будь проще

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

«О, как чудесно», - стонет он своим крохотным мозговым ртом. «Это будет чертовски весело».

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

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

«Бедный Фолкнер. Неужели он действительно думает, что громкие слова вызывают большие эмоции? Он думает, что я не знаю десятидолларовых слов. Я их хорошо знаю. Но есть старые, простые и лучшие слова, и я их использую ».

- Эрнест Хемингуэй

В некоторых формах письма всегда будет неприглядный беспорядок - это неизбежно. Статьи по программированию и технологиям будут иметь аббревиатуры. У делового письма будут модные словечки. Резюме медицинских исследований может содержать скорректированные коэффициенты частоты 0,86, 96% ДИ 0,4–0,56.

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

Хорошо писать - это сложно. Но страдать должен писатель. Не читатель.