На самом деле Дуров после интервью ещё объявил о фишках на блокчейне TON внедряемых в телеграм, стикеры в виде NFT и так далее. По сути интервью часть рекламной кампании
Pascal отвратительный язык для обучения. По крайней мере был раньше. Что в школе был Pascal, что в университете на начальных курсах. Пока не начали преподавать C, вообще было не понятно, что делаем и зачем. По мне так лучше бы обучали на C# или Java. Если бы Pascal был простым и удобным, то на нём все и писали бы, но не пишут
Трудно наверное разве что джуну, для всех остальных поддержка обратной совместимости, хоть на сколько-то версий, вполне обычная практика. Я даже представить не могу, что можно писать не волнуясь об обратной совместимости
И это неплохо, так как когда прибьёт, будут эксперты, которые помогут переехать остальным, миграция с Oracle и MSSQL на PosgreSQL сейчас идёт во многих компаниях. Всё таки аргумернт "у нас везде эта бд" конечно аргумент и весомый, но не единственный. Собственно каждый новый проект - повод задуматься, актуальный ли у вас стек, посмотреть какие ещё варианты и если видите, что технологии и подходы используемые в компании устаревают, то новый проект - хороший вариант, чтобы попробовать что-то новое и в случае чего распространить опыт внутри компании
саму Redis надо готовить, так как у неё проблемы с вертикальным масштабтрованием, но для меня Garnet выглядит самым интересным, но пока он вроде не особо готов для продакшина
Понятно, что для обычного бизнес-прложения это не важно, но вот для биржи, рекламного сервиса и всего, где важна скорость и обработка большого числа запросов это важно, rust в этом случае выглядит лучше всего ещё и из-за того, что работает без сборщика мусора, что может порой задержки, не даром в net8 потратили большие усилия на работу с паматью, хотя в go она изначально была хороша. Но вот писать на rust или go после с# совсем не приятно, для меня самым интересным выглядел D, но на нём нет толковых веб фреймворков, да и работу с памятью по типу как в rust вроде так и не завезли, но как язык очень приятно
А это и не совсем REST API, это по сути надстройка над ним, например как JsonRpc. Преимущество такого подхода в том, что разделяется обработка инфраструктурных ошибок и ошибок бизнес-логики, инфраструктурные ошибки обрабатываются по статус кодам, 404, 500 и т. д. эти ошибки как правило стандартные и обработку их можно вынести в middleware, а вот ошибки валидации, ошибки выполнения бизнес операций и т. д. всегда возвращают статус код 200, но при этом имеют свой формат, свой набор статусов, который намного шире http статусов
Не согласен, разделять модели на Dto и Entity хороший подход, например частая ситуация, когда у вас у модели в базе есть поля для аудита, например created_at и created_by, так же is_deleted для soft delete. В таком случае Dto похож на Entity но часть полей в нём отстуствует и мапперы тут хорошо вписываются
Если рассмотреть покрытие кода тестами, то на левый сложнее писать, так же больше вероятность конфликтов. В книге "Совершенный код" предлагается разбивать код на методы по 7-12 строк
в свою квартиру весь свет сделал гаусс, пока всем радует и свет нравится и глаза не болят и за 3 с половиной года ни одна лампочка не перегорела, цена тоже была очень приятной
На самом деле Дуров после интервью ещё объявил о фишках на блокчейне TON внедряемых в телеграм, стикеры в виде NFT и так далее. По сути интервью часть рекламной кампании
Это для visual studio code, причём тут windows?
Pascal отвратительный язык для обучения. По крайней мере был раньше. Что в школе был Pascal, что в университете на начальных курсах. Пока не начали преподавать C, вообще было не понятно, что делаем и зачем. По мне так лучше бы обучали на C# или Java. Если бы Pascal был простым и удобным, то на нём все и писали бы, но не пишут
Трудно наверное разве что джуну, для всех остальных поддержка обратной совместимости, хоть на сколько-то версий, вполне обычная практика. Я даже представить не могу, что можно писать не волнуясь об обратной совместимости
По своему опыту в большом энтерпрайзе, сейчас либо переезжают с Oracle на PosgreSQL, либо уже переехали. Для аналитики переезжают на ClickHouse
И это неплохо, так как когда прибьёт, будут эксперты, которые помогут переехать остальным, миграция с Oracle и MSSQL на PosgreSQL сейчас идёт во многих компаниях. Всё таки аргумернт "у нас везде эта бд" конечно аргумент и весомый, но не единственный. Собственно каждый новый проект - повод задуматься, актуальный ли у вас стек, посмотреть какие ещё варианты и если видите, что технологии и подходы используемые в компании устаревают, то новый проект - хороший вариант, чтобы попробовать что-то новое и в случае чего распространить опыт внутри компании
саму Redis надо готовить, так как у неё проблемы с вертикальным масштабтрованием, но для меня Garnet выглядит самым интересным, но пока он вроде не особо готов для продакшина
Посмотрел сейчас на Чип и Дип, как раз 3000₽
прошло ещё 1,5 года, ни одна лампочка ещё не перегорела
Понятно, что для обычного бизнес-прложения это не важно, но вот для биржи, рекламного сервиса и всего, где важна скорость и обработка большого числа запросов это важно, rust в этом случае выглядит лучше всего ещё и из-за того, что работает без сборщика мусора, что может порой задержки, не даром в net8 потратили большие усилия на работу с паматью, хотя в go она изначально была хороша. Но вот писать на rust или go после с# совсем не приятно, для меня самым интересным выглядел D, но на нём нет толковых веб фреймворков, да и работу с памятью по типу как в rust вроде так и не завезли, но как язык очень приятно
А это и не совсем REST API, это по сути надстройка над ним, например как JsonRpc. Преимущество такого подхода в том, что разделяется обработка инфраструктурных ошибок и ошибок бизнес-логики, инфраструктурные ошибки обрабатываются по статус кодам, 404, 500 и т. д. эти ошибки как правило стандартные и обработку их можно вынести в middleware, а вот ошибки валидации, ошибки выполнения бизнес операций и т. д. всегда возвращают статус код 200, но при этом имеют свой формат, свой набор статусов, который намного шире http статусов
Реализовать IConvert чтобы он нормально работал с IQueryable?
Не согласен, разделять модели на Dto и Entity хороший подход, например частая ситуация, когда у вас у модели в базе есть поля для аудита, например created_at и created_by, так же is_deleted для soft delete. В таком случае Dto похож на Entity но часть полей в нём отстуствует и мапперы тут хорошо вписываются
Можно подойти с другой стороны и сделать историю основной таблицей и только добавлять в неё записи, а для данных использовать view
Сейчас ещё и WebTransport появился на замену веб-сокетам
Если рассмотреть покрытие кода тестами, то на левый сложнее писать, так же больше вероятность конфликтов. В книге "Совершенный код" предлагается разбивать код на методы по 7-12 строк
На C# я бы ещё и в отдельные классы вынес и внедрение зависимостей сделал
Игра вышла, вы не правы, она великолепна
Скорее сделают сухопутную границу до Калининграда, чем отдадут его
в свою квартиру весь свет сделал гаусс, пока всем радует и свет нравится и глаза не болят и за 3 с половиной года ни одна лампочка не перегорела, цена тоже была очень приятной