У нас уже под 40 :(

Хрен его знает, кто что делает

У нас уже под 40 :(

без структурного деления?

С

Это только на бекенде под 40

думаю Денис про структурное деление

Я не считаю фронтэнд и клиентских

на одного руководителя с каким-то проектом не нужно более 5 работников

Я ж не спорю, чем меньше - тем лучше. Имхо

эти 5 работников могут быть тоже менеджерами каждый со своими 5-ю

Когда было 12, было круто

Как выросли - ужас

кстати, тут наткнулся https://forum.dlang.org/post/txszkgnbelpwpjxvayau@forum.dlang.org к теме про gamedev, C++, Unity и C#

думаю Денис про структурное деление

Да, про "рабочую группу"

Я щас осваиваю C# по работе, очень крутой язычелло

Просто космолет по возможностям и инафраструктуре )

Просто космолет по возможностям и инафраструктуре )

даже если с Java сравнивать?

тяжело на нём тебе будет после Ди

даже если с Java сравнивать?

Не знаю на java я не писал

Норот, никто не задумал писать api для телеграм-ботов? Оно не сложное но там есть нюансы. Есть такие люди?

Но в VS есть встроенный дебаг подробнейший, уже настроены юнит тесты и все остальное

Норот, никто не задумал писать api для телеграм-ботов? Оно не сложное но там есть нюансы. Есть такие люди?

Я задумывал

Есть только delegram

Я даже начал писать )

Но чёт забросил

Есть только delegram

неглядя предположу что устарел - 2015 год в нём

да

Ну и как всегда развилка - писать ли на вайбе или на нативных сокетах

У меня просто штуки 4 идеи для ботов, там ничего сложного, и хостить их даже можно на домашнем компе, телеграм бот не требует белого ИП. Но так лень начинать писать.... )

Если постоянно опрашивать - то можно курлом отделаться

Ну и как всегда развилка - писать ли на вайбе или на нативных сокетах

На вайбе, конечно. Нативные сокеты слишком низкоуровневые и к ним есть другие вопросы.

А ну вообще у меня уже есть бот готовый

Если постоянно опрашивать - то можно курлом отделаться

Надо поддержать все способы подключения в 1 пакете

Как раз месяц назад писал

выделить API из него не получится?

Там есть но оно почти такое же как в delegram, если не меньше. Мне нужно было только прием и отправка текста

Да короче, нет проблем, я могу начать контрибутить. Мне самому нужно, если нужно кому то кроме меня то это уже достаточные причины

Оформим в отдельный пакет

А JSON parser какой?

сначала делал на vibe, потом взял asdf

Оформим в отдельный пакет

Давай, я готов поддержать потому что сразу заюзаю это в реальном проекте

Структуры с optional юзаешь ?

asdf вообще пушка кстати

А JSON parser какой?

там сообщения небольшие поэтому даже значения не имеет, думаю.

Ты посмотри на Message структуру там )

asdf вообще пушка кстати

Да мне нравится, а вот вайбовский json не смог НЕ работать с несуществующими полями, падает при парсинге

Смотрел с год назад, вроде не очень страшно быо

Давай, я готов поддержать потому что сразу заюзаю это в реальном проекте

Займусь в пятницу вечером

> Да мне нравится, а вот вайбовский json не смог НЕ работать с несуществующими полями, падает при парсинге дык и не надо парсить в жёсткие структуры

иногда, конечно, надо)

но думаю даже в ботовом апи пакете можно будет без этого обойтись

Ой, вру. Не optional, a Nullable

> Да мне нравится, а вот вайбовский json не смог НЕ работать с несуществующими полями, падает при парсинге дык и не надо парсить в жёсткие структуры

Почему? Там очень неудобно парсить в бесформенные JSON куски и потом с ними работать непонятно как.

А может это и не нужно

Типа помечаешь в структуре поле как Nullable!int test

А так - описал структуры с полями, вложенные и т.д. - херак, и у тебя json распарсился в объектную модель сразу в 1 строчку.

И если в JSON не было - оно isNull

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

И если в JSON не было - оно isNull

Да юзал что-то такое

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

Не понял

смотри. к тебе прилетел Json

ну да Update например

нужно ли тебе его складывать в структуру какую-то многоуровневую?

или одноуровневую плоскую?

Лучше в многоуровневую. Нужно, так удобнее

возникает вопрос: а зачем? если тебе поля эти надо 1 раз заюзать то до них можно руками дотянуться указав путь где они там лежат внутри этого json

> так удобнее никакой разницы если ты юзаешь их 1 раз - так и так опишешь путь же.

ERROR: S client not available

json он же дерево неизвестной формы, зачем натягивать сову на этот глобус?

Вместо JSON["message"]["text"] можно писать update.message.text - нагляднее

это не принципиально

json он же дерево неизвестной формы, зачем натягивать сову на этот глобус?

Конкретно в апи телеграма оно очень даже известной формы, там апи жестко задано

Но иногда появляются доп. поля

а иногда исчезают. и если у тебя все поля не используются зачем привязываться к тем которые приходят-уходят?

> а иногда исчезают. Вот это не знаю, может и нет

ну версию изменят у АПИ да и всё, и поле уберут какой-то

это же жизнь

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

Оне не будут ломать апи, очень много библиотек от них зависит

обязательно будут.

все всегда обещают ничего не ломать

Кстати я уже на багу в asdf напоролся, там нельзя распарсить именовыннае enum

все всегда обещают ничего не ломать

Слушай ну свое первое апи для телеграма я написал в 2016 году или даже раньше ) Там у них четкая политика. Однако даже если предположить такое, то что с того? Думаю можно легко сделать workaround для тех кто хочет работать с сырой json структурой а не с жестко заданными

Типа requestRaw() и получаешь сырые данные, парсишь их как хочешь

Типа requestRaw() и получаешь сырые данные, парсишь их как хочешь

думаю ди позволит сделать так что в зависимости от того какой результат хочешь шаблон его создаст

Да, будет и так и так )

хочет raw будет raw, хочешь asdf - будет он

я за vibe потомучто надёжность важнее скорости

Только там весь vibed придется тянуть а не только vibe-core

Т.к. нужны https запросы

http отдельно, его json отдельно

особо выбора-то сейчас и нет, кроме vibe все остальные серверы и клиенты совсем поделки

https умеет curl, прямо вот сейчас прикручиваю - такая гадость!

Все равно он deprecated

вот вот

не, скорее как сокеты - заброшен

https умеет curl, прямо вот сейчас прикручиваю - такая гадость!

dlang-requests ?

https может?

да

а что в качестве библиотеки криптографии применено?