Статьи

Локации: Ретроспектива

Приложение Loccasions теперь поддерживает большинство основных функций, которые я хотел создать. В первом посте из серии, в которой упоминаются Locassions ( здесь ), я изложил следующие пользовательские истории:

  • Как незарегистрированный пользователь, я хочу видеть домашнюю / целевую страницу
  • Как администратор, я хочу иметь возможность приглашать пользователей в Loccasions
  • Как приглашенный пользователь, я хочу иметь возможность создать учетную запись
  • Как зарегистрированный пользователь, я хочу иметь возможность создавать события
  • Как зарегистрированный пользователь, я хочу иметь возможность создавать случаи
  • Как зарегистрированный пользователь, я хочу видеть случаи на карте
Мы сделали их все, кроме второго рассказа о приглашении пользователей. Поскольку первый раунд пользовательских историй завершен, я думаю, что пришло время ретроспективы. Кроме того, это будет последний пост в серии Loccasions на некоторое время (если не навсегда), так как я стремлюсь освободиться от оков этой серии и перейти к другим темам в Ruby.

Что такое ретроспектива?

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

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

Я бы солгал, если бы сказал, что сделал больше, чем просто случайно выбрал несколько из быстрого поиска в Google, но просматривая каждый из них, я увидел общие компоненты:
  • Чашка Как мы Делали? Но не слишком, это испортит блюдо.
  • Чашка Что пошло не так?
  • Немного того, что было правильно?
  • Шутник планирования нашей следующей итерации.
Вот и все. Если вы добавите слишком много какого-либо из этих ингредиентов, вполне вероятно, что ваша ретроспектива получится сгоревшей, сырой или в какой-либо другой несъедобной форме. Ни при каких обстоятельствах нельзя использовать любой из следующих ингредиентов:
  • порицание
  • гнев
  • Гипербола («Так как X пошел хорошо, мы должны использовать его для всего!»)
В конце концов, ретроспектива о том, чтобы стать лучше, а не о назначении вины. Мы поправляемся, учась на наших ошибках и планируя («Планы бесполезны, но планирование — это все.» — Дуайт Д. Эйзенхауэр) немного лучше. Кроме того, если ваша ретроспектива длится более 4 часов, я бы серьезно усомнился в ценности чего-либо за пределами этого времени. Помните, что один раз, когда вы не улучшаете приложение, это когда вы все сидите на встрече, переоценивая / сражаясь / и т.д.

Что пошло не так?

Я решил сделать серию Loccasions открытой для разработки «настоящего» Rails-приложения, в отличие от многих надуманных примеров, которые мы видим в Интернете. После моей первой «итерации» я не думаю, что выполнил эту цель. Во-первых, это редкое приложение, которое является детищем и работой одного разработчика. Кроме того, я принял много решений относительно технологий, драгоценных камней и тому подобного, основываясь на шатком обосновании. Если вы помните, я выбрал MongoDB, в основном, потому что я хотел играть с ним. Если бы это было «настоящее» приложение, я бы никогда не принял подобное решение.

Во многих случаях я стал немного небрежным с кодом и примерами. Это привело к тому, что некоторым статьям стало очень трудно следовать, и мне пришлось столкнуться с ужасным приложением типа «Ну, он работает на моем ноутбуке». Только благодаря усилиям некоторых Alert Readers (особенно Николаса Генри… этот парень — машина) эта проблема была несколько смягчена.

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

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

Что правильно?

С учетом негатива, я думаю, что с Loccasions многое пошло хорошо. Во-первых, и самое главное, я многому научился и хорошо провел время, написав сериал. Как разработчики, когда мы наслаждаемся своим ремеслом и заботимся о проблеме, которую решаем, жизнь прекрасна. Кроме того, я думаю, что выбор Backbone для клиентского кода был идеальным выбором. Чем больше я использую Backbone, тем больше он мне нравится. Это просто достаточно фреймворка и достаточно далеко, что дает отличный опыт кодирования.

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

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

На сервере выбрать Devise было легко и оказалось отличным выбором. Довольно часто драгоценные камни с популярностью Devise могут превратиться в кучки неиспользуемого кода Sasquatchian, но Devise не считает меня таким.

Форман, это почти императив сейчас, на мой взгляд. Особенно, если вы внедряетесь в Heroku, Форман просто облегчает жизнь.

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

Как стать лучше?

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

Другая группа людей, чье участие могло бы значительно улучшить Loccasions, — пользователи. Привлечение людей к фактическому использованию приложения и обратной связи будет определять направление приложения и его ретроспективу. За многие годы разработки пользовательских приложений я наблюдал, как наша индустрия / сообщество эволюционировало от обращения с пользователями, как необходимого зла, до надлежащего помещения их на место водителя. Я помню, как читал пост в блоге (автора которого я не могу найти… извините!), В котором говорилось (перефразируя) «Вы всегда можете сказать, когда разработчик разработал ваше приложение». Это, безусловно, верно для Loccasions, в нем можно использовать Designer. Нажмите.

Какой план?

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

  • развертывание
  • UX / Дизайн
Это широкие термины, очевидно. Развернув немного, для развертывания я бы отправил приложение в Heroku. Как часть этого, я думаю, что просмотр какого-либо сервера Continuous Integration также поможет сгладить сценарии развертывания и разработки. Исследование серверов CI также включено в список немедленного планирования.
Для задач UX / Design, я думаю, что в планах будет привлечение пары пользователей и добросовестного веб-дизайнера. Если бы я мог заставить некоторых пользователей запускать приложение, давать обратную связь и заставлять дизайнера еще раз дать приложение, Loccasions был бы экспоненциально лучше.
Конечно, есть определенные задачи, которые идут с каждым из этих пунктов планирования более высокого уровня, но мы остановимся здесь. Loccasions было очень весело писать и писать. Возможно, это не оригинальная работа Rails, но она охватывала множество тем и отвечала на множество вопросов. Спасибо за чтение серии, для тех из вас, кто застрял с ней. Может быть, я подберу его снова через несколько месяцев.