Ок, я не точно выразился, но это коммент, а не статья. Строки в БД отлично помещаются. Пропустил внутреннюю очевидность, что если я делаю выборки по целой строке, то это медленнее выборки по числу. По остальному согласен. Но не считаю контроль целостности сильно важным. Проверка на дефолт всегда доступа. И проверяем входящие в любом случае, потому что вдруг на входе вместо числа true или массив прилетит. Кста, я на валидаторе перечисляю в теге свои числовые контстаны - ок работает.
В целом это холиварная тема. И много нюансов что и как. Например, я создаю структуру из http-запроса и кладу в базу - обычный CRUD. И увидел, что я просто заполняю поля структуры "1-к-1". Если здесь вставить New(), то лишняя прокладка. При удалении поля я и так узнаю. При добавлении New также пролетит мимо, как и сразу структура. При этом обычно один запрос на одну структуру. И в редких случаях когда пара запросов на создание одной структуры - все равно там случатся разные New(). То есть мне без надобности. Если структура не для записи в бд, а должна висеть в памяти и работать с мапой, то там, конечно, New() хорошо вписывается. И есть еще фабрики объектов, где можно "добавлять поля", тоже нужен конструктор, но мне не зашло
Ну вы правы в любом случае, я уже это понял. Я писал "почему", а не про "можно". Enum в базе можно хранить, и он под капотом быстрее чем строки сравнивает. Но нормализация не всегда рулит. И почему вдруг мы перескочили на узкие места БД. Я, на минуточку, писал что сравнение числовых констант в любом случае быстрее строковых констант. И на ваш вопрос "А почему, собственно, не в строках?" я сразу ответил "можно".
В чем претензия?! Го просто особенный, ему не нужен "обязательный" конструктор? И вспомним про обязательный make для мап и каналов - то есть есть, где надо. И я редко добавляю NewX(), потому что он часто лишний прокси присвоения полей. И удобно, когда объединяет несколько структур. Это "соглашение по неймингу", что "всё что начинается с New" что-то инициализирует. Добавлю даже, что мне реакт нравится, потому что там можно без классов и конструкторов ;)
Технически можно. И я делал это. Но ушел в const int. Из-за указанного "серверного мышления". В го все как-то стараются выжимать все соки из машины по CPU/памяти. 1. И быстрое сравнение строк заметно медленнее сравнения двух чисел. 2. Выборка в базе из-за строк также занимает больше памяти и процессора. Парсинг ответа из базы также занимает больше ресурсов. И клиенту это тоже отдать и там парсить. 3. Наименование числовой константы проще поменять, чем значение строки в базе. 4. Меньше соблазна в коде сравнить с человекочитаемым текстом, или использовать часть сроки, а тянешь правильную константу. Но никак не iota, так как поменяешь порядок следования - логика с базой разъедется. Просто типизированные константы.
Согласен в основном. Причем enum'ы могут появиться позже - писал выше, что когда-то и дженериков не было. То есть я не противник, но не считаю это недостатком. И я не пишу сам го, потому дискуссия бесцельная. "Почему" можно где-то спросить, но мне без надобности. И я все-таки отмечаю, что заточенность го под сервер присутствует. И эта заточенность влияет как минимум на приоритеты - swiss table и сборщик разрабы сделали, а enum'ы нет. То есть можно сказать "не срочно".
А я не совсем понимаю ваши слова. Мой тезис "без enum'ов можно" и ваш "с enum'ами хорошо" оба верны. Потом вы накинули не по теме, и это уже я не могу понять. Но мне нравится ваше "каждому своё".
"специфическое серверное мышление" же! "Получил - положил в базу" это самое постоянное действие. Go отлично заточен под тупые действия. Если посмотрите на обычный сервер, то он "широкий" - у меня больше 250 обработчиков, которые скорее горизонтальные чем вертикальные. И в такой горизонтальной логике писать просто/тупо гораздо выгоднее, чем хитро! Зато через n (нет, n мало, пусть m) лет, читается также просто. Enum'ы в этом абзаце про то, что и без них всё работает. И накину про ошибки. Когда годами пялишься в go-код, то вырабатывается выборочная слепота. Ну и для этого codestyle должен быть однообразным.
Привет, Петр! я про него тебе точно рассказывал - монолитик на go + react pwa (deloset.ru, а лендинг туда переедет с pro.deloset.ru). По теме статьи - мотив был очень сильный к написанию. К идее уже было видение "как надо" + опыт в недвижке и управлении - нельзя было не написать. И это захватывающе, но "очень тяжело продавать" для интроверта. Делаю отдельные вылазки, общаюсь, потом отдыхаю ;)
Торчу в Go уже много лет, и я в восторге от него. Тут надо понимать, что много заточено под специфическое серверное мышление. 1. Const/Var местами смешит, но это из-за аллокации в памяти - какие-то "простые" map вообще ни разу не простые. И вообще глобальные значения рекомендованы для точечного осознанного применения, так как создают неявные ошибки. 2. Enum'ов нет, но как их хранить в базе (мы же сервера программируем обычно!)? не в строках же! А в байтах отлично типизированные константы работают. Обработка - тут надо включить параноидальность - придет что угодно, в том числе ошибка. Потому программу пишешь под даже еще не известные значения. В общем, я живу без enum'сов норм, когда завезут - будем жевать. Когда-то и дженериков и итераторов не было. 3. Ошибки в Go нужны для раннего выхода - почти везде return. Если пришла не-nil err, то просто нельзя пользоваться значением, и точка! И пофиг почему. Для пакетов, которые копаются в ошибках, есть структурирование и функции. И если модуль разбирается в сортах ошибки вызываемой функции (конечно, много случаев когда ошибка равна какой-то константе типа "файл не найден"), то что-то не так с разделением логики модулей. И мне очень нравится императивное программирование в Go. Можно писать просто, и дешевые изменения логики. И видел неудачные фреймворки, которые делают магию - вот это моветон.
Сделал свой продукт, теперь учусь продавать, что чревато просадкой по техническим скиллам. Но не первый день замужем! и своё же продавать, так что держусь. Но если можете не делать своего, то не делайте!
Не очень вчитывался, но у меня вроде посложнее: - на внешний сигнал стопа закрываем прием новых запросов (у меня http-сервер), доделываем имеющиеся запросы, сервер по завершении обработки завершается и кидает ок в канал - по сигналу закрываются соединения с ресурсами, чтобы не потерять данные, - и потом выход из main (или жесткий шатдаун по истечении второго времени). И потому есть контекст на управление сервером, есть контекст запросов внутри сервера, и есть контекст на приложуху с ресурсами - данные в одну сторону. И каналы для ответов. Потому долго ковырялся.
Всё не настолько плохо, чтобы тащить новую зависимость. Мне не зашел "uber/fx". И за несколько дней разобрался в теме - задача красиво остановить сильно сложнее, чем запустить. Пучок каналов, несколько контекстов, waitgroups для внешних сервисов - и готово. Решение на пару сотен строк, разбросанных по модулям. Я за отсутствие магии в разработке, если что.
Добрых лучиков! Это кусок текста из "примерно в начале", где я набрасываю, что это не мой выбор. И там речь больше про чтение логов в chrome-for-devs. И в принципе работает - там текст же. Но ГОРАЗДО УДОБНЕЕ писать больше букв. В первую очередь, есть правило наименования переменных - чем дальше от места использования тем длиннее. И здесь по сути название очень далекой функции. Потому не надо сокращать. Про идентификаторы в путях типа "users/:id" подробно в разделе "о входящих данных". Если кроме одного идентификатора ничего не нужно - то ок. На этом REST API держится. Но если пересылать больше данных, которые уже в query/body И ДОПОЛНИТЕЛЬНО парсить путь - да зачем?! А если не пихать в путь, то сильно просто парсить входящие данные по ОДНОЙ модели с валидатором.
Вертушка - наоборот раскидывала входящие звонки на дежурных в разных офисах. А поднимать старые звонки через CRM было больнее, да. Я какое-то время назад вернулся в разрабы со своей идеей из недвижки. Долго пилил, теперь учусь продавать проект. Рекламу бросил давать еще до пандемии, но иногда делаю сделки - вот недавно меня нашла заказчица через 8 лет. С видео и аи в продажах недвиги не вижу перспектив - эффект мал, а трудоемкость высокая. А продвижение услуг - это НОВЫЕ контакты, то есть надо собрать клиентов (а не пользователей как в циан) в одном месте и свести с риелторами, которых надо фильтровать (не как в циан). Причем собрать на фоне перегретого информационного шума. Если так, то фантастика! Здесь просто общаемся, мне было приятно вспомнить что-то старое.
Стоит сначала определить, кто такой риелтор (у каждого риелтора своё определение профессии). Я склонен называть риелтора "доверенным специалистом". И сказал бы не о контент-голоде (обычно всякие страшилки) - а об отсутствии реальных контактов. Раньше с телефонной вертушки нормально клиентов набирали, и это то качество, которое не дает никакой контент (особенно сгенерированный) - клиент выбирает "своего" риелтора во многом по речи - громкость, чистота речи, понятность, и даже скорость и тембр. И приходит на личную встречу уже теплый. "Ведущие соцсети" - это имиджевая реклама, такое себе мало кто может позволить. И не всем надо - какие-то клиенты предпочитают тишину и кулуарность. З.Ы. РиЭлтор - это конкретно член Российской Гильдии Риэлторов. Грамотно писать "риелтор", но РГР зарегистрировало товарный знак "риэлтор". А называть себя таким словом может только тот, кто платит членские взносы. Риелтор - это устоявшееся название, которым любой себя может назвать.
Видео вообще в недвижке не нужно, от нейронки тем более. В первичке и так полно обмана, где соседнюю промзону или пустырь изображают на схеме взрослым лесом. Во вторичке база для ручной фильтрации (ну вы и так поняли после 100 собесов) - минимум времени на объявление по типовому шаблону. И смотреть видео будет никто. Есть общий тренд на то, что выбирают по фотографиям (витрина), а при визите уже подтверждают свое решение. Видео сработает для нестандартных объектов, которые невозможно сравнить с соседями - и уже другая оценка объекта. В целом рад, что вы опрашивали именно риелторов - обычно их почему-то игнорируют, когда что-то в недвижке хотят поменять.
Думаю, что зависит от назначения приложения. У меня сервер обслуживает сайт. И умеет всё с данными - это бизнес. А из сервисов там cron, рассылка и sse...
Entity/use_cases - это популярные слои. Походу я напутал. Use_cases решает "сложные" операции - типа "умные". И может вызывать entity и db. И entity - слой только про одну сущность. Типа здесь должно быть просто CRUD-операции, но внезапно разрастается из-за логики проксирования - нельзя в db минуя entity. И разделение на модули выше уровнем - я такое видел. И вот use_cases умеет всякие штуки, типа запрашивать данные из связанных сущностей. И один модуль запросто встретится с другим - функция из организаций вызывает список рабочих групп другого модуля. А рабочие группы вызывают полномочия участника в организации на переименование. Логично выделить такие "сложные" функции в отдельный слой, который может. И это получается супер слой, который чересчур сложен. И выше пишу - этот супер слой отлично распиливается в обработчики, но уже не тупые.
Ок, я не точно выразился, но это коммент, а не статья. Строки в БД отлично помещаются. Пропустил внутреннюю очевидность, что если я делаю выборки по целой строке, то это медленнее выборки по числу.
По остальному согласен. Но не считаю контроль целостности сильно важным. Проверка на дефолт всегда доступа. И проверяем входящие в любом случае, потому что вдруг на входе вместо числа true или массив прилетит. Кста, я на валидаторе перечисляю в теге свои числовые контстаны - ок работает.
В целом это холиварная тема. И много нюансов что и как. Например, я создаю структуру из http-запроса и кладу в базу - обычный CRUD. И увидел, что я просто заполняю поля структуры "1-к-1". Если здесь вставить New(), то лишняя прокладка. При удалении поля я и так узнаю. При добавлении New также пролетит мимо, как и сразу структура. При этом обычно один запрос на одну структуру. И в редких случаях когда пара запросов на создание одной структуры - все равно там случатся разные New(). То есть мне без надобности.
Если структура не для записи в бд, а должна висеть в памяти и работать с мапой, то там, конечно, New() хорошо вписывается.
И есть еще фабрики объектов, где можно "добавлять поля", тоже нужен конструктор, но мне не зашло
Ну вы правы в любом случае, я уже это понял. Я писал "почему", а не про "можно". Enum в базе можно хранить, и он под капотом быстрее чем строки сравнивает. Но нормализация не всегда рулит.
И почему вдруг мы перескочили на узкие места БД. Я, на минуточку, писал что сравнение числовых констант в любом случае быстрее строковых констант. И на ваш вопрос "А почему, собственно, не в строках?" я сразу ответил "можно".
В чем претензия?! Го просто особенный, ему не нужен "обязательный" конструктор? И вспомним про обязательный make для мап и каналов - то есть есть, где надо. И я редко добавляю NewX(), потому что он часто лишний прокси присвоения полей. И удобно, когда объединяет несколько структур. Это "соглашение по неймингу", что "всё что начинается с New" что-то инициализирует.
Добавлю даже, что мне реакт нравится, потому что там можно без классов и конструкторов ;)
Технически можно. И я делал это. Но ушел в const int. Из-за указанного "серверного мышления". В го все как-то стараются выжимать все соки из машины по CPU/памяти.
1. И быстрое сравнение строк заметно медленнее сравнения двух чисел.
2. Выборка в базе из-за строк также занимает больше памяти и процессора. Парсинг ответа из базы также занимает больше ресурсов. И клиенту это тоже отдать и там парсить.
3. Наименование числовой константы проще поменять, чем значение строки в базе.
4. Меньше соблазна в коде сравнить с человекочитаемым текстом, или использовать часть сроки, а тянешь правильную константу.
Но никак не iota, так как поменяешь порядок следования - логика с базой разъедется. Просто типизированные константы.
Согласен в основном. Причем enum'ы могут появиться позже - писал выше, что когда-то и дженериков не было. То есть я не противник, но не считаю это недостатком. И я не пишу сам го, потому дискуссия бесцельная. "Почему" можно где-то спросить, но мне без надобности.
И я все-таки отмечаю, что заточенность го под сервер присутствует. И эта заточенность влияет как минимум на приоритеты - swiss table и сборщик разрабы сделали, а enum'ы нет. То есть можно сказать "не срочно".
А я не совсем понимаю ваши слова. Мой тезис "без enum'ов можно" и ваш "с enum'ами хорошо" оба верны. Потом вы накинули не по теме, и это уже я не могу понять. Но мне нравится ваше "каждому своё".
go не объектный же! Тут котлеты от мух отделены. И чем NewItem() *Item не конструктор?
"специфическое серверное мышление" же! "Получил - положил в базу" это самое постоянное действие. Go отлично заточен под тупые действия. Если посмотрите на обычный сервер, то он "широкий" - у меня больше 250 обработчиков, которые скорее горизонтальные чем вертикальные. И в такой горизонтальной логике писать просто/тупо гораздо выгоднее, чем хитро! Зато через n (нет, n мало, пусть m) лет, читается также просто. Enum'ы в этом абзаце про то, что и без них всё работает.
И накину про ошибки. Когда годами пялишься в go-код, то вырабатывается выборочная слепота. Ну и для этого codestyle должен быть однообразным.
Привет, Петр! я про него тебе точно рассказывал - монолитик на go + react pwa (deloset.ru, а лендинг туда переедет с pro.deloset.ru). По теме статьи - мотив был очень сильный к написанию. К идее уже было видение "как надо" + опыт в недвижке и управлении - нельзя было не написать. И это захватывающе, но "очень тяжело продавать" для интроверта. Делаю отдельные вылазки, общаюсь, потом отдыхаю ;)
Торчу в Go уже много лет, и я в восторге от него. Тут надо понимать, что много заточено под специфическое серверное мышление.
1. Const/Var местами смешит, но это из-за аллокации в памяти - какие-то "простые" map вообще ни разу не простые. И вообще глобальные значения рекомендованы для точечного осознанного применения, так как создают неявные ошибки.
2. Enum'ов нет, но как их хранить в базе (мы же сервера программируем обычно!)? не в строках же! А в байтах отлично типизированные константы работают. Обработка - тут надо включить параноидальность - придет что угодно, в том числе ошибка. Потому программу пишешь под даже еще не известные значения. В общем, я живу без enum'сов норм, когда завезут - будем жевать. Когда-то и дженериков и итераторов не было.
3. Ошибки в Go нужны для раннего выхода - почти везде return. Если пришла не-nil err, то просто нельзя пользоваться значением, и точка! И пофиг почему. Для пакетов, которые копаются в ошибках, есть структурирование и функции. И если модуль разбирается в сортах ошибки вызываемой функции (конечно, много случаев когда ошибка равна какой-то константе типа "файл не найден"), то что-то не так с разделением логики модулей.
И мне очень нравится императивное программирование в Go. Можно писать просто, и дешевые изменения логики. И видел неудачные фреймворки, которые делают магию - вот это моветон.
Сделал свой продукт, теперь учусь продавать, что чревато просадкой по техническим скиллам. Но не первый день замужем! и своё же продавать, так что держусь. Но если можете не делать своего, то не делайте!
Не очень вчитывался, но у меня вроде посложнее:
- на внешний сигнал стопа закрываем прием новых запросов (у меня http-сервер), доделываем имеющиеся запросы, сервер по завершении обработки завершается и кидает ок в канал
- по сигналу закрываются соединения с ресурсами, чтобы не потерять данные,
- и потом выход из main (или жесткий шатдаун по истечении второго времени).
И потому есть контекст на управление сервером, есть контекст запросов внутри сервера, и есть контекст на приложуху с ресурсами - данные в одну сторону. И каналы для ответов. Потому долго ковырялся.
Всё не настолько плохо, чтобы тащить новую зависимость. Мне не зашел "uber/fx". И за несколько дней разобрался в теме - задача красиво остановить сильно сложнее, чем запустить. Пучок каналов, несколько контекстов, waitgroups для внешних сервисов - и готово. Решение на пару сотен строк, разбросанных по модулям.
Я за отсутствие магии в разработке, если что.
Добрых лучиков! Это кусок текста из "примерно в начале", где я набрасываю, что это не мой выбор. И там речь больше про чтение логов в chrome-for-devs. И в принципе работает - там текст же. Но ГОРАЗДО УДОБНЕЕ писать больше букв. В первую очередь, есть правило наименования переменных - чем дальше от места использования тем длиннее. И здесь по сути название очень далекой функции. Потому не надо сокращать.
Про идентификаторы в путях типа "users/:id" подробно в разделе "о входящих данных". Если кроме одного идентификатора ничего не нужно - то ок. На этом REST API держится. Но если пересылать больше данных, которые уже в query/body И ДОПОЛНИТЕЛЬНО парсить путь - да зачем?! А если не пихать в путь, то сильно просто парсить входящие данные по ОДНОЙ модели с валидатором.
Вертушка - наоборот раскидывала входящие звонки на дежурных в разных офисах. А поднимать старые звонки через CRM было больнее, да.
Я какое-то время назад вернулся в разрабы со своей идеей из недвижки. Долго пилил, теперь учусь продавать проект. Рекламу бросил давать еще до пандемии, но иногда делаю сделки - вот недавно меня нашла заказчица через 8 лет.
С видео и аи в продажах недвиги не вижу перспектив - эффект мал, а трудоемкость высокая. А продвижение услуг - это НОВЫЕ контакты, то есть надо собрать клиентов (а не пользователей как в циан) в одном месте и свести с риелторами, которых надо фильтровать (не как в циан). Причем собрать на фоне перегретого информационного шума. Если так, то фантастика!
Здесь просто общаемся, мне было приятно вспомнить что-то старое.
Стоит сначала определить, кто такой риелтор (у каждого риелтора своё определение профессии). Я склонен называть риелтора "доверенным специалистом". И сказал бы не о контент-голоде (обычно всякие страшилки) - а об отсутствии реальных контактов. Раньше с телефонной вертушки нормально клиентов набирали, и это то качество, которое не дает никакой контент (особенно сгенерированный) - клиент выбирает "своего" риелтора во многом по речи - громкость, чистота речи, понятность, и даже скорость и тембр. И приходит на личную встречу уже теплый.
"Ведущие соцсети" - это имиджевая реклама, такое себе мало кто может позволить. И не всем надо - какие-то клиенты предпочитают тишину и кулуарность.
З.Ы. РиЭлтор - это конкретно член Российской Гильдии Риэлторов. Грамотно писать "риелтор", но РГР зарегистрировало товарный знак "риэлтор". А называть себя таким словом может только тот, кто платит членские взносы. Риелтор - это устоявшееся название, которым любой себя может назвать.
Видео вообще в недвижке не нужно, от нейронки тем более. В первичке и так полно обмана, где соседнюю промзону или пустырь изображают на схеме взрослым лесом.
Во вторичке база для ручной фильтрации (ну вы и так поняли после 100 собесов) - минимум времени на объявление по типовому шаблону. И смотреть видео будет никто. Есть общий тренд на то, что выбирают по фотографиям (витрина), а при визите уже подтверждают свое решение. Видео сработает для нестандартных объектов, которые невозможно сравнить с соседями - и уже другая оценка объекта.
В целом рад, что вы опрашивали именно риелторов - обычно их почему-то игнорируют, когда что-то в недвижке хотят поменять.
Думаю, что зависит от назначения приложения. У меня сервер обслуживает сайт. И умеет всё с данными - это бизнес. А из сервисов там cron, рассылка и sse...
Entity/use_cases - это популярные слои. Походу я напутал. Use_cases решает "сложные" операции - типа "умные". И может вызывать entity и db. И entity - слой только про одну сущность. Типа здесь должно быть просто CRUD-операции, но внезапно разрастается из-за логики проксирования - нельзя в db минуя entity. И разделение на модули выше уровнем - я такое видел.
И вот use_cases умеет всякие штуки, типа запрашивать данные из связанных сущностей. И один модуль запросто встретится с другим - функция из организаций вызывает список рабочих групп другого модуля. А рабочие группы вызывают полномочия участника в организации на переименование.
Логично выделить такие "сложные" функции в отдельный слой, который может. И это получается супер слой, который чересчур сложен. И выше пишу - этот супер слой отлично распиливается в обработчики, но уже не тупые.