Зачем? Как это делать написано уже 100 раз до меня, просто возьмите архитектуру любого http сервера, например, nginx. STL + pthreads + OpenSSL + libev + Intel TBB + libfmt + rapidjson - основа.
Для бинарного протокола используем ULEB-кодирование и свой формат описания пакетов.
Парсер HTTP свой, для API-сервера не нужна полная поддержка протокола.
SSL проксирование через CloudFlare или через nginx, он же может и корректность протокола проверять.
У нас на этом написано несколько бэкэндов онлайн-игр, API-сервера для аналитики, различные сервисы.
Базовая часть, эквивалентная тому, что описана в статье пишется за день, остальное все время уже уходит на бизнес-логику.
БД ClickHouse + MySQL, адаптер самописный.
Я так же написал свое расширение для ClickHouse для PHP (оно открытое), которое работает с ним по нативному протоколу и тоже базовая часть заняла около суток, остальное время уже реализация дополнительного функционала.
Как люди извращаются, чтобы решить проблемы, которые сами же и выбрали. Хотите я ускорю ваши C++ вызовы в 1000 раз? Просто. Используйте. C++.
И не надо мне писать про преимущества Go, современный C++ такой же безопасный и на нем так же быстро решаются продуктовые задачи как и на Go, при том что он часто быстрее и гораздо более универсальный и мощный.
Странно, на такое 2 недели… На C++ давно уже пишем гораздо более сложные вещи за день примерно. Без проблем с производительностью, WS/бинарный протокол/rest. Без явного выделения памяти, RAII и так далее. Поддерживать может любой программист, кто понимает C-подобный синтаксис, даже полный даун.
Фактически - всё, нет, ВСЁ, что вы описали - как раз признак ТУПОСТИ. Вы описали костыли для инвалидов (умственных). Умный человек как раз всё это сделает сам, чекпоинты, дедлайны, бизнес-ценность, даже задачу сделает не так, как ее поставили, а так, как это на самом деле нужно бизнесу.
Так работают нормальные программисты. Им не нужны лиды, ТЗ… Достаточно описать идею и дальше вы получите работающий бизнес-продукт.
Это все сложно и непонятно. У меня было всё гораздо проще - я программирую с 9 лет (мне 39) и я всегда считал, что программирую лучше всех (и за годы жизни не встречал лично людей, которые программируют лучше). И я знал почти всё всегда лучше других и всегда спорил до победного отстаивая свою точку зрения даже если меня о ней никто не спрашивал. Я создавал целые теории и философию чтобы доказать, что я прав. И да, были моменты, где мне доказывали, что я не прав и я на них учился. Это лучшее обучение, что есть в мире. А еще я читал очень много книг по программированию, управлению людьми, проектами, рефакторинг, математика, гейм-дизайн, маркетинг, аналитика и так далее. И читал я потому что мне было интересно.
Прошел 2 полноценных MBA (1 на 2 года зарубежный и второй на 1 год, наш), германский курс по PMBook и еще кучу мелких и тоже просто потому что было интересно, мне было плевать на развитие как таковое всегда.
Для меня любая новая тема и тем более та, в которой я еще не разбираюсь - вызов и соревнование, где я должен за очень мало времени стать лучшим, показать всем как надо учиться и потом делать.
Среднее выполнение задач у меня в 3-5 раз меньше, чем даже у Сеньоров. А если говорить про бизнес, то у окружающих вообще мрак.
Так что не мучайте себя, забейте, вы все всё-равно выше головы не прыгнете, у вас не хватит мозгов. Или докажите, что я не прав. :)
Кстати, заметил, что нормальные книги по программированию пишут только зарубежные авторы… А я их очень много прочитал.
По бизнес-направлениям тоже зарубежные авторы на голову выше наших, наши как-будто боятся рассказать самое ценное, что есть, и поэтому книги выходят сухими и бесполезными.
Вы странный. Писать отдельную статью про «обучение». Сам процесс «обучение» выделяют в обособленную сущность только глупые люди. Для меня, например, его отдельно не существует, я просто делаю и это получается. Никаких правил и особенных подходов, просто всё легко. Не сразу получается идеально, но очень быстро становится таковым, но без вот этого всего, что вы написали :)
Я бы сказал, что «обучение» неизбежно, как третий закон Ньютона и скорость этого процесса напрямую и экспоненциально зависит от интеллекта субъекта.
А не проще сразу писать быстрые запросы, а тех, кто не умеет - увольнять? У меня случаи были оптимизации (руками), которые и в 10 000 раз ускоряли запрос (написанный не мной)… Ваш движок не ускорит запросы, написанные мной… Более того, для оптимизации «запросов» я применяю еще методы кэширования данных (те же MATERIALIZED VIEW и временные таблицы), изменение структуры таблиц и формата записи данных, изменения алгоритмов, которые используют эти запросы. Ваш движок такое умеет?
Я считаю, такие оптимизаторы вредными. Они позволяют тем, кто работает с БД быть тупыми…
Линус тут жестко тупанул. Замените Rust на «детскую порнографию» и со азу станет понятно, что всё, что он написал - чушь полнейшая. Я понимаю тех разработчиков, которые говорят, что не хотят иметь никакого отношения к Rust (детской порнографии) и что Rust (детской порнографии) не место в ядре никак и никогда и что у них есть право голоса по поводу любых запретов Rust (детской порнографии)…
Логика стала понятнее? Вот для меня Rust еще хуже, чем детская порнография…
price с клиента в коммерции надо передавать ОБЯЗАТЕЛЬНО, а потом уже проверять на сервере соответствие и возвращать «Цена изменилась», если она изменилась, иначе пользователь откроет форму со старой ценой, будет думать, что покупает за старую цену, и пока он смотрит цена может поменяться и там дальше куча проблем, начиная от заказа с другой ценой, заканчивая списанием другой суммы…
Облако всё-равно это тупо. Облако выходит в 5-10 раз дороже собственных серверов… 14 лет уже этим занимаюсь и ни разу не было такого случая, чтобы облако было чем-то лучше или эффективнее…
Аргумент так себе. У фашизма корни растут ещё с более древних времён, но фашизм от этого хорошим не станет :) Но если сократить все аргументы против Go (по сравнению с C++) до одной фразы, то получится "У Go нет ни одного преимущества по сравнению с C++, зато полно недостатков".
Лучше всего если бы вы могли вытащить колонки из телевизора и поставить на их место новые, то же и с модулем с ОС, пульт бы был один и работал с таким же заменяемым контроллером пульта.
И если бы замена занимала минуту даже дауном, а настройка выполнялась бы автоматически. Пульт при этом должен «подстраиваться» под набор устройств в телевизоре как Мистик из XMan.
В идеале и экран тоже так же нужно менять.
Нужно лишь договориться об интерфейсе подключения (Type C?) и протоколе…
Это тоже монолит, только с правильной архитектурой. Но большинство разработчиков делают либо обычный телевизор, либо то, что вы описали… Только у них еще хуже всё, чтобы подсоединить колонки надо самому паять переходник, каждый динамик настраивается отдельно по сложной инструкции, иначе не заработает или звук будет отставать где-то, где-то тише, где-то громче :) Приставка требовала бы ручного патчинга KDE под FreeBSD, работала бы от питания 4.37V ни больше ни меньше, но только если колонки играют тише 50% громкости, если больше - уже 5V. Пульты бы не работали, если бы лежали ближе 1м друг к другу и некоторые функции меняли бы что-то еще в других системах (типа сделал громче и стала яркость меньше, увеличил яркость и язык в ОС поменялся на японский)
Пипец у вас позиция человека, который все что угодно сделает чтобы его взяли на работу. Это желание одобрения и признания изучается в психологии :) Я бы ответил «не хочу». Не нравится мой ответ - идите на… Вам я нужен гораздо больше чем вы мне :)
Зачем? Как это делать написано уже 100 раз до меня, просто возьмите архитектуру любого http сервера, например, nginx. STL + pthreads + OpenSSL + libev + Intel TBB + libfmt + rapidjson - основа.
Для бинарного протокола используем ULEB-кодирование и свой формат описания пакетов.
Парсер HTTP свой, для API-сервера не нужна полная поддержка протокола.
SSL проксирование через CloudFlare или через nginx, он же может и корректность протокола проверять.
У нас на этом написано несколько бэкэндов онлайн-игр, API-сервера для аналитики, различные сервисы.
Базовая часть, эквивалентная тому, что описана в статье пишется за день, остальное все время уже уходит на бизнес-логику.
БД ClickHouse + MySQL, адаптер самописный.
Я так же написал свое расширение для ClickHouse для PHP (оно открытое), которое работает с ним по нативному протоколу и тоже базовая часть заняла около суток, остальное время уже реализация дополнительного функционала.
У вас что-то не так просто с эффективностью…
Как люди извращаются, чтобы решить проблемы, которые сами же и выбрали. Хотите я ускорю ваши C++ вызовы в 1000 раз? Просто. Используйте. C++.
И не надо мне писать про преимущества Go, современный C++ такой же безопасный и на нем так же быстро решаются продуктовые задачи как и на Go, при том что он часто быстрее и гораздо более универсальный и мощный.
Странно, на такое 2 недели… На C++ давно уже пишем гораздо более сложные вещи за день примерно. Без проблем с производительностью, WS/бинарный протокол/rest. Без явного выделения памяти, RAII и так далее. Поддерживать может любой программист, кто понимает C-подобный синтаксис, даже полный даун.
Фактически - всё, нет, ВСЁ, что вы описали - как раз признак ТУПОСТИ. Вы описали костыли для инвалидов (умственных). Умный человек как раз всё это сделает сам, чекпоинты, дедлайны, бизнес-ценность, даже задачу сделает не так, как ее поставили, а так, как это на самом деле нужно бизнесу.
Так работают нормальные программисты. Им не нужны лиды, ТЗ… Достаточно описать идею и дальше вы получите работающий бизнес-продукт.
Вот они, олимпиадники… Код корректный, но ужасный, отвратительный.
Столько таких повидал за время работы, для меня «Призер олимпиады» - красный флаг.
Только детям мозги ломаете :( На 1000 олимпиадников находится только 1, которому это пошло на пользу.
Это все сложно и непонятно. У меня было всё гораздо проще - я программирую с 9 лет (мне 39) и я всегда считал, что программирую лучше всех (и за годы жизни не встречал лично людей, которые программируют лучше). И я знал почти всё всегда лучше других и всегда спорил до победного отстаивая свою точку зрения даже если меня о ней никто не спрашивал. Я создавал целые теории и философию чтобы доказать, что я прав. И да, были моменты, где мне доказывали, что я не прав и я на них учился. Это лучшее обучение, что есть в мире. А еще я читал очень много книг по программированию, управлению людьми, проектами, рефакторинг, математика, гейм-дизайн, маркетинг, аналитика и так далее. И читал я потому что мне было интересно.
Прошел 2 полноценных MBA (1 на 2 года зарубежный и второй на 1 год, наш), германский курс по PMBook и еще кучу мелких и тоже просто потому что было интересно, мне было плевать на развитие как таковое всегда.
Для меня любая новая тема и тем более та, в которой я еще не разбираюсь - вызов и соревнование, где я должен за очень мало времени стать лучшим, показать всем как надо учиться и потом делать.
Среднее выполнение задач у меня в 3-5 раз меньше, чем даже у Сеньоров. А если говорить про бизнес, то у окружающих вообще мрак.
Так что не мучайте себя, забейте, вы все всё-равно выше головы не прыгнете, у вас не хватит мозгов. Или докажите, что я не прав. :)
Кстати, заметил, что нормальные книги по программированию пишут только зарубежные авторы… А я их очень много прочитал.
По бизнес-направлениям тоже зарубежные авторы на голову выше наших, наши как-будто боятся рассказать самое ценное, что есть, и поэтому книги выходят сухими и бесполезными.
Вы странный. Писать отдельную статью про «обучение». Сам процесс «обучение» выделяют в обособленную сущность только глупые люди. Для меня, например, его отдельно не существует, я просто делаю и это получается. Никаких правил и особенных подходов, просто всё легко. Не сразу получается идеально, но очень быстро становится таковым, но без вот этого всего, что вы написали :)
Я бы сказал, что «обучение» неизбежно, как третий закон Ньютона и скорость этого процесса напрямую и экспоненциально зависит от интеллекта субъекта.
А не проще сразу писать быстрые запросы, а тех, кто не умеет - увольнять? У меня случаи были оптимизации (руками), которые и в 10 000 раз ускоряли запрос (написанный не мной)… Ваш движок не ускорит запросы, написанные мной… Более того, для оптимизации «запросов» я применяю еще методы кэширования данных (те же MATERIALIZED VIEW и временные таблицы), изменение структуры таблиц и формата записи данных, изменения алгоритмов, которые используют эти запросы. Ваш движок такое умеет?
Я считаю, такие оптимизаторы вредными. Они позволяют тем, кто работает с БД быть тупыми…
И вы не показали еще запросы с JOIN-ами, в ClickHouse их надо писать по особому, чтобы было быстро
У меня 30 лет опыта разработки и из них 20 коммерческого, если я накручу 2-3 года, то никто не заметит :)
Линус тут жестко тупанул. Замените Rust на «детскую порнографию» и со азу станет понятно, что всё, что он написал - чушь полнейшая. Я понимаю тех разработчиков, которые говорят, что не хотят иметь никакого отношения к Rust (детской порнографии) и что Rust (детской порнографии) не место в ядре никак и никогда и что у них есть право голоса по поводу любых запретов Rust (детской порнографии)…
Логика стала понятнее? Вот для меня Rust еще хуже, чем детская порнография…
Очередные советы, которые делают только хуже :)
price с клиента в коммерции надо передавать ОБЯЗАТЕЛЬНО, а потом уже проверять на сервере соответствие и возвращать «Цена изменилась», если она изменилась, иначе пользователь откроет форму со старой ценой, будет думать, что покупает за старую цену, и пока он смотрит цена может поменяться и там дальше куча проблем, начиная от заказа с другой ценой, заканчивая списанием другой суммы…
Облако всё-равно это тупо. Облако выходит в 5-10 раз дороже собственных серверов… 14 лет уже этим занимаюсь и ни разу не было такого случая, чтобы облако было чем-то лучше или эффективнее…
Это вопросы для джуна все :) Я всё это еще в школе уже знал, хотя было 0 лет опыта коммерческого программирования…
Аргумент так себе. У фашизма корни растут ещё с более древних времён, но фашизм от этого хорошим не станет :)
Но если сократить все аргументы против Go (по сравнению с C++) до одной фразы, то получится "У Go нет ни одного преимущества по сравнению с C++, зато полно недостатков".
Если у вас код на C++ работает так же быстро как и на Go, то вы просто не умеете писать на C++ :)
Go - от слова Govno, на мой взгляд. А опыт у меня большой на всех популярных языках программирования.
P.S.: Не знаю на чем вы там собирали библиотеку, но 2 минуты на сборку проекта такого масштаба - очень и очень много.
Ищи проблему в себе. У меня в 18 лет было уже 9 лет опыта программирования и 2 года из них коммерческого…
Я бы в рекомендации еще добавил - не используйте Python :)
Черное, белое… Серое!
Лучше всего если бы вы могли вытащить колонки из телевизора и поставить на их место новые, то же и с модулем с ОС, пульт бы был один и работал с таким же заменяемым контроллером пульта.
И если бы замена занимала минуту даже дауном, а настройка выполнялась бы автоматически. Пульт при этом должен «подстраиваться» под набор устройств в телевизоре как Мистик из XMan.
В идеале и экран тоже так же нужно менять.
Нужно лишь договориться об интерфейсе подключения (Type C?) и протоколе…
Это тоже монолит, только с правильной архитектурой. Но большинство разработчиков делают либо обычный телевизор, либо то, что вы описали… Только у них еще хуже всё, чтобы подсоединить колонки надо самому паять переходник, каждый динамик настраивается отдельно по сложной инструкции, иначе не заработает или звук будет отставать где-то, где-то тише, где-то громче :) Приставка требовала бы ручного патчинга KDE под FreeBSD, работала бы от питания 4.37V ни больше ни меньше, но только если колонки играют тише 50% громкости, если больше - уже 5V. Пульты бы не работали, если бы лежали ближе 1м друг к другу и некоторые функции меняли бы что-то еще в других системах (типа сделал громче и стала яркость меньше, увеличил яркость и язык в ОС поменялся на японский)
Пипец у вас позиция человека, который все что угодно сделает чтобы его взяли на работу. Это желание одобрения и признания изучается в психологии :) Я бы ответил «не хочу». Не нравится мой ответ - идите на… Вам я нужен гораздо больше чем вы мне :)