Ну вот да, я пробовал "везде json", но оказалось, что в C++ офигеть как неудобно работать с json. Пробовал и ORM-стайл, но и там свои сложности. Интересно даже, отличается ли Rust в этом плане чем-то.
А подскажите, пожалуйста, как в этой архитектуре сейчас принято работать с базами данных?
С чем я лично столкнулся: у базы данных свои типы (string, int'ы разные, дата-время и так далее), у нативного языка - свои, у js - свои. В итоге постепенно пришёл к тому, чтобы подружить js и базу данных напрямую, оставив одну конвертацию типов вместо двух, и всю бизнес-логику перенёс в js. Но такое странное ощущение осталось, потому что js и веб вроде бы должны выполнять чисто интерфейсные функции, а бизнес-логику хотелось бы держать отдельно от интерфейса (даже если она будет написана на том же языке). Но и дублирования хотелось бы как-то избежать (модель данных в js / модель данных в нативном языке / структура данных в DB). Как это нормальные люди делают?
Logitech Lift - только ради колёсика скролла. Сама мышь не очень удобная.
Лично мне из "вертикальных" китайская мышь Delux M618mini более удобна, но колёсико там унылое. Вот если бы китайцы научились делать такое же крутое колесо, как у Logitech, это было бы круто. А с одним logitech выбор очень уж маленький и компромиссный.
Основное неудобство в том, что когда температура или острая боль, то тебе не до вникания в механизм работы страховой. Ты просто идёшь в поликлинику, надеясь, что тебе хотя бы облегчат состояние, а система начинает палки в колёса ставить: по дмс идите в другую регистратуру на другой этаж, этот врач не принимает по дмс, или принимает но не сегодня, звоните и согласовывайте в страховой сами, и так далее, куча гемора. Очень грустно с этим всем бодаться, когда хочется лечь и помереть. Система пока всё ещё не для людей, а для заработка денег. (Впрочем, этого никто и не скрывает.)
В современных банковских приложениях ввод кода из смс, присланного банком, считается цифровой подписью. А вы нам голову морочите вашей заумью. Не мешайте деградировать.
Пост напомнил бородатый анекдот про "формулу бороды".
Берем слово "борода". Токенизатор разбивает его на "бор" + "ода". Для них есть внутренние эмбеддинги: "бор" - это лес, а "ода" - это стих. Получается - "лес стих". То есть "безветрие", без v три e. Итого, формула бороды: "3e - v", где e - экспонента, а v - параметр бороды.
Примерно так работают рассуждающие нейросети в моём понимании.
Почему нельзя сразу делать нормальный API без хардкода типа что у пользователя не больше двух глаз? Строят архитектуру на необоснованных предположениях, и сами потом страдают. /s
uint16_t* data = (uint16_t*)str;Ох, это опасно! Лучше не делайте так.
Рискуете упасть на arm из-за выравнивания.
Ну вот да, я пробовал "везде json", но оказалось, что в C++ офигеть как неудобно работать с json. Пробовал и ORM-стайл, но и там свои сложности.
Интересно даже, отличается ли Rust в этом плане чем-то.
А подскажите, пожалуйста, как в этой архитектуре сейчас принято работать с базами данных?
С чем я лично столкнулся: у базы данных свои типы (string, int'ы разные, дата-время и так далее), у нативного языка - свои, у js - свои. В итоге постепенно пришёл к тому, чтобы подружить js и базу данных напрямую, оставив одну конвертацию типов вместо двух, и всю бизнес-логику перенёс в js. Но такое странное ощущение осталось, потому что js и веб вроде бы должны выполнять чисто интерфейсные функции, а бизнес-логику хотелось бы держать отдельно от интерфейса (даже если она будет написана на том же языке). Но и дублирования хотелось бы как-то избежать (модель данных в js / модель данных в нативном языке / структура данных в DB). Как это нормальные люди делают?
Logitech Lift - только ради колёсика скролла. Сама мышь не очень удобная.
Лично мне из "вертикальных" китайская мышь Delux M618mini более удобна, но колёсико там унылое.
Вот если бы китайцы научились делать такое же крутое колесо, как у Logitech, это было бы круто. А с одним logitech выбор очень уж маленький и компромиссный.
Но не может, потому что есть более полезные задачи с точки зрения начальства.
Основное неудобство в том, что когда температура или острая боль, то тебе не до вникания в механизм работы страховой. Ты просто идёшь в поликлинику, надеясь, что тебе хотя бы облегчат состояние, а система начинает палки в колёса ставить: по дмс идите в другую регистратуру на другой этаж, этот врач не принимает по дмс, или принимает но не сегодня, звоните и согласовывайте в страховой сами, и так далее, куча гемора. Очень грустно с этим всем бодаться, когда хочется лечь и помереть. Система пока всё ещё не для людей, а для заработка денег. (Впрочем, этого никто и не скрывает.)
Спасибо за статью. На самом деле очень интересно.
В современных банковских приложениях ввод кода из смс, присланного банком, считается цифровой подписью. А вы нам голову морочите вашей заумью. Не мешайте деградировать.
Ждём Zen 6 и тогда будет интересно посравнивать. А пока в статье ничего нового.
Звучит хорошо. Но не работает в рыночной экономике.
Пост напомнил бородатый анекдот про "формулу бороды".
Берем слово "борода". Токенизатор разбивает его на "бор" + "ода". Для них есть внутренние эмбеддинги: "бор" - это лес, а "ода" - это стих. Получается - "лес стих". То есть "безветрие", без v три e. Итого, формула бороды: "3e - v", где e - экспонента, а v - параметр бороды.
Примерно так работают рассуждающие нейросети в моём понимании.
Раздел "5. Продвинутые темы" отсутствует.
Спасибо за пост. Благодаря вам удалось выбрать правильное место и время для наблюдения, было круто.
Скоро люди станут совсем не нужны...
Если компания будет использовать Koda, coda.io и так далее, то предложение "посмотри в коде" будет особенно эпичным.
Теперь ведь нейросети за вас код пишут?
А где gigaam и t-one?
Этак можно использовать любую тулзу для бекапов (например, backintime), просто отформатировать fs под сжатие, чтобы лучше влезало.
М... ротоскопинг
Почему нельзя сразу делать нормальный API без хардкода типа что у пользователя не больше двух глаз? Строят архитектуру на необоснованных предположениях, и сами потом страдают. /s