Когда проект связан ровно с одним типом хранилища, OpenDAL будет не нужной прослойкой (при условии, что гарантируется отсутствие необходимости смены хранилища). А вот когда типов хранилищ сразу несколько, то он встанет в полный рост, т.к. общий функционал будет реализован ровно один раз, а функционал специфичный для хранилища одного типа и необходимый в проекте все равно нужно будет как-то имплементировать для остальных типов хранилищ. По сути аналог ODBC/JDBC для баз данных.
Мне кажется, главная претензия автора не в том, что все должны перекатываться на чистый Си, писать вручную вызывать системные вызовы, и аллоцировать память. А в том, что сейчас ситуация выглядит примерно как "Ехал фреймворк через фреймворк, видит фреймворк в фреймворке фреймворк"
Мне было бы любопытно познакомиться с человеком, который на чистом Си и стандартной библиотеке способен написать современное готовое к продакшену комерческое веб решение и способный убедить в необходимости этого менеджмент :) Понятно, что у автора речь шла именно об отказе от фреймворков, а не от высокоуровневых языков (хотя технически Си тоже к ним относится).
Могу ошибаться (Не силён в веб-технологиях, прошу поправить, если не прав), но тем не менее, сейчас мы имеем ситуацию, когда условный Nest транслирует код в код на NodeJS, который обращается к движку V8, который преобразовывает всё это в байткод. А ещё, в проекте скорее всего задействовано штук примерно 50 разных зависимостей, который тянут за собой ещё 150 зависимостей. А ещё, наш фронтенд, который и без того тяжёлый, скорее всего ждёт выполнения каких-то API запросов, которые выполняются на сервере, на котором примерно такая же ситуация. И получается гигантских размеров многослойный пирог, который распутывать замучаешься.
Тут, мне кажется, идет смешение понятий фреймворк и библиотека. Фреймворков в силу определения не может быть много, они задают форму всего приложения и зачастую строятся по принципу "фреймворк вызывает код программиста". С библиотеками все наоборот, они ни как не ограничивают код, который их вызывает. В JS мире тонны зависимостей вызваны как раз библиотеками, которые там на любой чих, а так же скромностью стандартной библиотеки.
Rest of message
Да, в IT нужно постоянно учиться. Нет, постоянная актуализация знаний не отменяет необходимости знать, как устроена база под капотом (напротив, чтобы понять, почему фреймворк работает так, как он работает, нужно знать, какие возможности языка это позволили разработчикам фреймворка). Этот же принцип работает и для библиотек. По этой же причине, если планируется в дальнейшем как-то расширять приложение, его код нужно держать в актуальном состоянии. Это позволит при необходимости легко найти специалиста, который его модифицирует.
А касательно специализации... На мой взгляд, принципиальной разницы между современными языками комерческой разработки нет. У всех одна база из 20 века, и с тех пор в IT не то чтобы много что поменялось. Как говорится, ассемблер лишь синтаксический сахар над машинным кодом :)
Если код написан на фремворке, то как бы плохо он не был написан, он остается скован ограничениями и требованиями фреймворка. А значит, точки входа известны, основные механизмы известны, останется только с бизнес слоем разобраться. В случае мало-мальски крупного самопального решения только "бог в помощь". Доки нет, комментов нет, "мейнтейнер" 2 недели на проекте (если этот велосипед хоть как-то "поддерживается"). Лучше один раз потратить много времени на изучение стандартного решения, а затем регулярно следить за его обновлениями, чем каждый раз разбираться в коде вот таких "всё своё, домашнее" кулибиных.
За рубежом достаточно много компаний с русскоязычными командами, в которых язык не требуется. Из известных авиасейлс, джетбрейнс, производные яндекса. Попробуйте рассматривать их. Это может значительно ускорить отъезд. На бытовом уровне вашего А2 будет достаточно для функционирования, а в англоязычной среде обучение пойдет сильно быстрее
Разрешите поинтересоваться, какие преимущества вам дает электромобиль по сравнению с машиной на ДВС? (Вопрос без сарказма, иронии и какого-либо скрытого подтекста). И еще, если можно, примерные климатические условия (хотя бы длительность периодов с температурой ниже 0)
У них там с этим цирк. Когда первый раз проходил медкомиссию на категорию годности, первый раз поликлиника сама отправляла документы. А уже в следующий и последующие разы, все возил сам.
Если на примере Новосибирска (хотя в остальных городах, я думаю, примерно то же самое), то: 1. Ходит гораздо реже, т.е. надо подстраивать свое расписание, это не всегда возможно. Автобус\маршрутка же ходят каждые условные 15 минут 2. Более удаленные остановки и редкие остановки. Зачем ехать до электрички, а потом от нее до цели, если можно просто сразу ехать к цели? Еще и время сэкономить. 3. (Опционально) Чуть более сложная процедура оплаты, кассы не на каждой станции, а прилож вроде как не позволяет купить билет вот прям сразу, только за какое-то время до электрички. Есть схемы, где электричка оптимальна, вроде объехать утренние/вечерние пробки. Ну или для меня она была удобна в вопросе добраться до ЖД вокзала. Или безальтернативна, когда нужно перевезти что-то более менее крупное, вроде того же велосипеда, а автобусы в том направлении или не ходят, или требуется цать пересадок. Но на этом ее полномочия всё.
Почему не продавать два варианта? С зарядным и без. Как сейчас продают процессора с куллером и без него. Пропорции вариантов можно сбалансировать хотя бы текущим соотношением продаж телефонов и зарядных устройств, для первичной оценки пойдет
Есть, просто пока сложно запихать нейронку, способную к автогенерированию контента и реакции на действия пользователя, в среднестатистический ПК :) Вообще, игра, которая играет с игроком аля ГладОС только не понарошку, мне кажется достойным продолжением серии
Ламерский вопрос, но как IP клиента до NAT поможет идентифицировать его трафик после?
Таблицы соответствия есть только на самом NAT, нет?
Если источник свежих сигнатур и обновлений один, то вот вообще не вариант.
Да, так и задумано. Это набор хаков для разработки с опциональной возможностью деплоиться в Azure и генерировать манифесты для k8s
Когда проект связан ровно с одним типом хранилища, OpenDAL будет не нужной прослойкой (при условии, что гарантируется отсутствие необходимости смены хранилища). А вот когда типов хранилищ сразу несколько, то он встанет в полный рост, т.к. общий функционал будет реализован ровно один раз, а функционал специфичный для хранилища одного типа и необходимый в проекте все равно нужно будет как-то имплементировать для остальных типов хранилищ.
По сути аналог ODBC/JDBC для баз данных.
Их несколько: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/out
В случае параметров, как раз про указатели
Мне было бы любопытно познакомиться с человеком, который на чистом Си и стандартной библиотеке способен написать современное готовое к продакшену комерческое веб решение и способный убедить в необходимости этого менеджмент :)
Понятно, что у автора речь шла именно об отказе от фреймворков, а не от высокоуровневых языков (хотя технически Си тоже к ним относится).
Тут, мне кажется, идет смешение понятий фреймворк и библиотека. Фреймворков в силу определения не может быть много, они задают форму всего приложения и зачастую строятся по принципу "фреймворк вызывает код программиста". С библиотеками все наоборот, они ни как не ограничивают код, который их вызывает. В JS мире тонны зависимостей вызваны как раз библиотеками, которые там на любой чих, а так же скромностью стандартной библиотеки.
Да, в IT нужно постоянно учиться. Нет, постоянная актуализация знаний не отменяет необходимости знать, как устроена база под капотом (напротив, чтобы понять, почему фреймворк работает так, как он работает, нужно знать, какие возможности языка это позволили разработчикам фреймворка). Этот же принцип работает и для библиотек. По этой же причине, если планируется в дальнейшем как-то расширять приложение, его код нужно держать в актуальном состоянии. Это позволит при необходимости легко найти специалиста, который его модифицирует.
А касательно специализации... На мой взгляд, принципиальной разницы между современными языками комерческой разработки нет. У всех одна база из 20 века, и с тех пор в IT не то чтобы много что поменялось. Как говорится, ассемблер лишь синтаксический сахар над машинным кодом :)
Если код написан на фремворке, то как бы плохо он не был написан, он остается скован ограничениями и требованиями фреймворка. А значит, точки входа известны, основные механизмы известны, останется только с бизнес слоем разобраться.
В случае мало-мальски крупного самопального решения только "бог в помощь". Доки нет, комментов нет, "мейнтейнер" 2 недели на проекте (если этот велосипед хоть как-то "поддерживается").
Лучше один раз потратить много времени на изучение стандартного решения, а затем регулярно следить за его обновлениями, чем каждый раз разбираться в коде вот таких "всё своё, домашнее" кулибиных.
За рубежом достаточно много компаний с русскоязычными командами, в которых язык не требуется. Из известных авиасейлс, джетбрейнс, производные яндекса. Попробуйте рассматривать их. Это может значительно ускорить отъезд.
На бытовом уровне вашего А2 будет достаточно для функционирования, а в англоязычной среде обучение пойдет сильно быстрее
И HTTP/3 с QUIC :)
Спасибо большое за статью!
Разрешите поинтересоваться, какие преимущества вам дает электромобиль по сравнению с машиной на ДВС? (Вопрос без сарказма, иронии и какого-либо скрытого подтекста). И еще, если можно, примерные климатические условия (хотя бы длительность периодов с температурой ниже 0)
Не обязательно. Ученые последнее время узнают о содержании гостайны в их работах после публикации работ. Со всеми вытекающими.
Вроде бы на двое суток отложили, если я правильно понял
Это больше не так работает. Мне грели голову три призыва. Друг уже на 5 или 6 идет...
Возможно на это и расчет, если раньше можно было отсидеться и без армии, и без детей, то теперь или демографию правь, или в армию иди
/sarcasm
У них там с этим цирк. Когда первый раз проходил медкомиссию на категорию годности, первый раз поликлиника сама отправляла документы. А уже в следующий и последующие разы, все возил сам.
Если на примере Новосибирска (хотя в остальных городах, я думаю, примерно то же самое), то:
1. Ходит гораздо реже, т.е. надо подстраивать свое расписание, это не всегда возможно. Автобус\маршрутка же ходят каждые условные 15 минут
2. Более удаленные остановки и редкие остановки. Зачем ехать до электрички, а потом от нее до цели, если можно просто сразу ехать к цели? Еще и время сэкономить.
3. (Опционально) Чуть более сложная процедура оплаты, кассы не на каждой станции, а прилож вроде как не позволяет купить билет вот прям сразу, только за какое-то время до электрички.
Есть схемы, где электричка оптимальна, вроде объехать утренние/вечерние пробки. Ну или для меня она была удобна в вопросе добраться до ЖД вокзала. Или безальтернативна, когда нужно перевезти что-то более менее крупное, вроде того же велосипеда, а автобусы в том направлении или не ходят, или требуется цать пересадок. Но на этом ее полномочия всё.
Полагаю, что о падении ряда крупных банков Штатов и Европы.
Почему не продавать два варианта? С зарядным и без. Как сейчас продают процессора с куллером и без него. Пропорции вариантов можно сбалансировать хотя бы текущим соотношением продаж телефонов и зарядных устройств, для первичной оценки пойдет
Справедливости ради, такое уже существует. Тур по тарифу VPN :)
Есть, просто пока сложно запихать нейронку, способную к автогенерированию контента и реакции на действия пользователя, в среднестатистический ПК :) Вообще, игра, которая играет с игроком аля ГладОС только не понарошку, мне кажется достойным продолжением серии