Серия «Веб-разработка»

Часть 3. Внезапная. А зачем мы всё это делаем?

Продолжение поста Какую задачу будет решать веб-приложение?

Если кому-то что-то непонятно, спрашивайте. И наоборот, если видите, что я несу бред - поправляйте.

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

Если более детально, то я увидел некую проблему (затруднённость обмена частными посланиями на пикабу), придумал, как её решить посредством ПО и решил это сделать. Также был вопрос, а почему я собираюсь это делать именно так? В данном случае - потому что, опять же, я так решил. В случае коммерческой разработки любое такое решение нужно будет обосновывать, потому что оно будет стоить от очень больших до гигантских или даже невероятных сумм. Потому что абсолютно любое решение имеет как плюсы, так и минусы. Всё как в любой другой инженерной и прочей системе, и как вообще всегда в жизни.

А, может, можно сделать как-то иначе, лучше? Конечно, можно. Всё всегда можно сделать иначе, особенно в разработке ПО. Но, каждое решение см. абзац выше. Поэтому я пока собираюсь делать по написанному во втором посте алгоритму, поскольку пока никто не предложил, как можно в нём что-то улучшить, существенно что-то не ухудшив. Зато, как было замечено, этот алгоритм является частным случаем другого алгоритма, на базе которого работает 99% обмена данными в нынешних компьютерных системах. Такой вот ещё один внезапный учебный плюс нарисовался :)

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

Показать полностью

Какую задачу будет решать веб-приложение?

Продолжение поста Пишем и запускаем веб-приложение

Раз есть интерес, начнём!

Если кому-то что-то непонятно, спрашивайте. И наоборот, если видите, что я несу бред - поправляйте.

На пикабу нельзя, ну или я не знаю, как, послать друг другу сообщение так, чтобы его не увидели все. Как это можно было бы сделать? Например, так: один пользователь сообщает другому, в комментах, обычным образом, код, на который нужно отправить сообщение (этап 1). Второй переходит по адресу с этим кодом и оставляет там сообщение (этап 2). А также запоминает второй код, который потом тоже сообщает в комментах первому. Первый снова идёт на этот сервис и, по полученному от второго коду, читает сообщение (этап 3). Что-то типа установки tcp сессии, если кому интересно :)

Зачем нужны эти коды? Первый код будет гарантировать второму пользователю, что сообщение точно будет адресовано первому. А второй код будет позволять первому пользователю выбрать сообщение именно второго. Почему? Потому что, сообщив на этапе 1 общедоступный код, первый пользователь может получить сообщения от кого угодно, ведь сервис предполагается общедоступным. Сервис будет генерировать уникальный второй код при каждом сохранении каждого сообщения, соответственно, получив через комменты второй код, первый пользователь будет точно знать, какое сообщение направлено конкретным юзером пикабу. Тут, конечно, не обязательно пикабу, главное, что можно обменяться общедоступным способом двумя кодами и, посредством их, получить частное сообщение, никому, кроме адресата, уже недоступное.

А откуда будет браться первый код? Его тоже будет генерировать сервис, при регистрации. Т.е., для получения таких сообщений получателю нужно будет зарегистрироваться на этом сервисе. Регистрация будет позволять получателю видеть отправленные только ему сообщения. Отправителю регистрироваться не нужно. Для защиты от спамов и ддосов желательно будет после получения нужного сообщения делать первый код недействительным и, для возможности получения нового сообщения, нужно будет сгенерировать новый код 1 (временный URL).

Итак, что должен будет делать этот веб-сервис:

  1. Регистрировать пользователей-получателей сообщений.

  2. Генерировать им некий код, лучше всего - уникальный временный URL, по которому будет доступно поле ввода сообщения (код 1).

  3. Сохранять полученные сообщения для последующего показа их получателю.

  4. Для отправителя генерировать код сохранённого сообщения (код 2).

  5. Показывать получателю конкретное сообщение по коду 2.

  6. Удалять все эти коды и сообщения по некоторым правилам.

Показать полностью

Пишем и запускаем веб-приложение

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

  1. Что такое веб-приложение.

  2. Его создание. Писать буду на Perl + Dancer2.

  3. Создание БД и взаимодействие с ней. PostgreSQL.

  4. Запуск приложения и БД в docker посредством docker-compose.

  5. Запуск приложения на реальном хостинге и организация доступа к нему посредством настройки DNS-записей.

  6. Для желающих - хранение кода приложения в git.

Собственно, если кому-либо это интересно, черканите в комментариях.

Отличная работа, все прочитано!