• Golang + Make

• Std http server

• Gorm + Postgres

• Docker Compose

• TEMPL + HTMX + Alpine.js

Но упор делать на Golang (пока что).

И начал я стирать пыль в голове по программированию, смотреть всяко-разные видео с youtube, решал задачи на codewars и узнавал как устроены проекты у нейросеток и по мелочи. Сразу отмечу что с концепцией того как программировать (функции, структуры, циклы, потоки и т.д.) я помнил, однако с концепцией ООП был знаком только поверхностно, поэтому пересматривал все как для полных нулей.

Решил я закрепить пройденный материал каким-нибудь pet-проектом, и тут столкнулся с проблемой. Возможно это не только у меня так, но проблема заключается в проектировании самого приложения. То есть придумал тему (сервис сокращения ссылок на WebSocket), схематично представил ее, но по мере создания этого проекта появляются "нюансы": то не учел что нужно добавить таблицы в БД, то поля таблиц БД добавить/удалить/заменить; то функционал изначально делал одним, а затем думаешь мол нахер оно вообще здесь нужно было и начинаешь переделывать. В качестве помощника, советчика и авторитета служит нейронки.

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

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

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

Пилю своё приложение, которое поможет ленивым стать лучшей версией себя

- throwmaybe : "I don't know, depends"
- throwish : "Most of the time quiet"
- nopexcept : "Trying not to throw"
- ¯\\_(ツ)_/¯ : "Even the compiler is unsure"
- maysometimethrowanexceptionifsomesortofconditionsarerealised : "All is in the exception name"
- throweventuallymaybe : "One day, maybe…"
- throwifyouinsist : "You asked for it"
- throwbutonlyonTuesdays : "Seasonal behavior"
- throwunlessyou’relucky : "It depends on internal state"
- throwunlessnoexcept : "I exist in a paradox"
- throwmaybe¯\\_(ツ)_/¯ : "I am Schrödinger’s function"

Looking forward to your thoughts — or at least your raised eyebrows.

Перевод(гуглтранслейт):
Спецификации исключений в C++ в настоящее время стольже же точны, как удар кувалды. Это предложение предлагает более эмоциональный подход к квалификаторам исключений — ведь иногда вашей функции просто нужно выплеснуть эмоции.

Мотивация

В современном C++ спецификации исключений недостаточно детализированы.

Бинарный выбор между noexcept и потенциально генерирующими исключения функциями не отражает всю тонкость поведения исключений.

Описание предложения

Это предложение вводит набор выразительных квалификаторов, отражающих эмоциональную и вероятностную природу обработки исключений:

- throwmaybe : «Не знаю, зависит от обстоятельств»
- throwish : «Большую часть времени тихо»
- nopexcept : «Стараюсь не выдавать исключения»
- ¯\\_(ツ)_/¯ : «Даже компилятор не уверен»
- maysometimethrowanexceptionifsomesortofconditionsarerealised : «Всё дело в имени исключения»
- throweventuallymaybe : «Однажды, может быть…»
- throwifyouinsist : «Вы сами напросились»
- throwbutonlyonTuesdays : «Сезонный режим»
- throwunlessyou’relucky : «Зависит от внутреннего состояния»
- throwunlessnoexcept : «Я существую в парадоксе»
- throwmaybe¯\\_(ツ)_/¯: «Я — функция Шрёдингера».

С нетерпением жду ваших мыслей — или хотя бы поднятых бровей.