Теоретически да, практически пока нет. В приложении для маруси есть возможность создавать сценарии для своей колонки - например маруся может что-то сказать. Если расковырять приложение, то можно всё это делать через home assistant. Но пока нет.
Если взглянуть на статью чуть пристальнее, то окажется, что чуть более, чем все примеры притянуты за уши. Понимаю, что нет смысла ввязываться в спор на тему "в интернете кто-то не прав" и становиться призёром специальных олимпийских игр, получив первое место по минусам, но не могу пройти мимо. Такое впечатление, что автор зачем-то подменяет понятия. Но зачем? Чтоб убедить 20 доверчивых читателей, что стандарты - зло? HTML, CSS, ECMA Script, C++, SQL и вот это вот всё - зло, надо от этого всего отказаться, чтобы что? Не надо публиковать стандарты и тогда всем станет сразу хорошо? Да, кто-то что-то делает раньше других и получает от этого конкурентные преимущества.
Мне казалось, что такое понятие, как стандарт, станадртизация всего, в том числе различных форматов обмена - это в первую очередь одна из мер борьбы с монополиями и во вторую облегчение жизни простых пользователей. Шаг, который защищает нас всех от того, что одна компания завладеет контролем над чем-то. Да, стандарт может быть не бесплатным, за его использованием, за использование логотипа может взиматься плата (hdmi, display port, usb, тысячи их). Но стандарт, который нигде не описан, это, простите, не стандарт, а собственность коммерческой компании. Не могу ничего сказать про стандарт ISO на микроскопы. Мне всегда казалось, что принятие стандарта - это процесс коллективный и открытый. "представители этой компании были ведущими составителями" - ведущими, но не единственными - кто-то имел знания, но просто не сумел их использовать. Может ларчик просто открывался - компания была ведущей и поэтому в основном её продукцию и покупали и стандарт особо роли не играл - но тут сказать ничего не могу - просто мои домыслы, которые появились, полсе того, как я взглянул на другие пункты.
PDF - википедия говорит, что стандарт основан на PostScript (открытый стандарт, появился в 1982 году), опубликован 15 июня 1993. Я так понимаю он изначально был открытым и бесплатным (но это не точно), продавалось только ПО. А c с 1 июля 2008 года является открытым стандартом ISO 32000. Ну то есть одно дело вася пупкин выложил стандарт на своей домашней страничке. А другое дело отправил его в ISO и там его приняли, зафиксировали, проверили, присвоили номер. Ну и если мне не изменяет мой склероз, было несколько бесплатных читалок PDF и до 2008 года. Вроде даже с открытым исходным кодом. И вообще "В 1985 году продажи компьютеров Macintosh начали падать, и Apple нужен был «killer app» — нечто, что мог бы только её компьютер. Стив Джобс инвестировал 2,5 млн $ в Adobe, которая создала PostScript-контроллер для принтера Apple LaserWriter, и в Aldus, создавшую программу PageMaker, использовавшую все возможности Macintosh и LaserWriter. Появившаяся тогда возможность допечатной подготовки на компьютере спасла Apple и превратила Adobe и Aldus в крупные компании." - что плохого в том, что Стив Джобс сделал что-то хорошее?
Java вроде была стандартом почти с самого начала. Помню реализацию от IBM, реализацию от Semantec - одну из первых реализаций с JIT (вот бесдоказательная фраза со stack overflow - Borland had the first one followed shortly by Symantec. Sun licensed the Symantec one. Symantec demoed theirs in March of 1996. Хотя не припоминаю JIT от Borland). Реализация от azul вроде до сих пор живёт и продаётся. И вроде насколько я помню, товарищи из Sun очень серьёзно относились к стандартизации и открытости - существовал TCK, прохождение которого позволяло продукту носить имя Java (товарный знак, принадлежал Sun). Насколько я помню существовали также совместимые реализации их серверного процессора на архитектуре sparc. Кстати в том числе от нашей небезызвестной МЦСТ. Не понимаю кто кого и как тут обманывал стандартами, и на чём наживался.
Chrome, cookie, android - смешались в кучу кони, люди. Вроде движок хрома и не стандарт, а open source. И почти все браузеры на него перешли - ну просто потому что хорош. И веб дизайнеры говорят им за это огромное спасибо, что наконец то в браузерах появилась нормальная поддержка стандартов. И я думаю, что если Google Chrome вдруг при запрещённых third-party cookies начнёт отправлять статистику в Google и использовать её для показа контекстной рекламы, то их так нагнут, что они надолго забудут что такое реклама и куда её надо показывать. Они могут писать что-то мелким шрифтом, но я думаю соблюдение лицензионного соглашения - это святое. И что-то идея создания андроида для победы хрома - это чё-то больше похоже на влажные фантазии.
Ну и микрософт как раз является ярким примером компании, которая делала всё, чтобы предотвратить возникновение стандартов. Любым способом. Уж и суд постановил - либо вы опубликуете ваши форматы, либо мы вас. И всё равно - опубликовали якобы "стандарт", в котором использовались проприетарные блобы. Хотя "де факто стандарт обмена сообщениями doc" - тоже в какой-то степени стандарт.
Может автор немного попутал стандарты и open source и статью понять как проклятые капиталисты пишут программы, которые захватывают рынок - пусть отдают их бесплатно, а ещё лучше сразу опенсорсят.
Спасибо, очень годная статья. Вот каждый раз делаю cat /proc/meminfo (редко), или в метрики смотрю, и каждый раз приходится вспоминать, а что все эти слова значат. Особенно WSS. Напрашивается в начале статьи кратенько (свёрнуто) список этих самых типов памяти и расшифровочку. Да, и про библиотечки я б тоже послушал - грузятся ли они в память, а в какую. Чтоб добавил одну только эту статью в закладки, и каждый раз, когда надо, пошёл, посмотрел и всё сразу стало ясно. Да даже не в закладки, а прям с графаны ссылочку сюда тыц.
К сожалению время идёт и наблюдается перетекание качества в количество. Количество растёт, а вот качество.
Как известно, микросервисная архитектура позволяет разбивать приложения на более мелкие и управляемые блоки.
Ребят, ну вы серьёзно? Вы же вроде как курсы IT, должны же знать - вся история программирования есть разные способы разбиения приложения на более мелкие и управляемые блоки. Функции, подпрограммы, библиотеки, объекты, модули, программы, тысячи их. И нет, микросервисная архитектура не предлагает новых способов разбиенич приложения на более мелкие и управляемые блоки - просто использует существующие . Ну разве что затрудняет переиспользование. Вроде же большая, уважаемая контора, с высоким рейтингом на хабре, вроде как обучающая людей, ну как же такое писать то можно. Ну в конце то концов, несмотря на всю мою лютую, дикую ненависть к микросервисам, ну ведь у них тоже есть своя область применение, полезные свойства. Возможность быстрее делать апдейт маленького сервиса большого приложения (обычно не особо нужно, ну если, конечно у вас не монстр, стартующий два часа. И не работает на практике потому что в апдейт чаще выкатывают кучу микросервисов). Самое главное - независимость сервисов - делай свои сервисы так, чтоб они продолжали работать даже когда родительский микросервис недоступен - позволяет не растерять всех пользователей, когда что-то накрылось - типа что-то накрылось, но что-то ещё продолжает работать. Возможность гибко масштабироваться (обычно не нужно - load balancer-а обычно более чем достаточно). Решить проблему с нехваткой физических ресурсов (CPU, Memory). Но интернет-магазин, если это не озон-амазон в качестве примера - ну ё-маё. Всё равно, что использовать NoSQL просто для фана - ну и что, что одна нода, зато есть возможность масштабироваться, когда-нибудь. Ну зайдите с другой стороны. "Когда вам придётся работать с заказчиком, который ничего не понимает в IT, то слова микросервис и k8s будут его сильно возбуждать - даже в баню везти не придётся. И сразу станет понятно почему под проект надо так много железна - кластер же, отказоустойчивость, микросервисы. И сразу станет не так важно, что мы просим за проект в 10 раз больше, чем нужно - на железо придётся потратиться ещё в 10 раз больше, так что всё обосновано, всё норм." Вот уже прошли сезоны хайпа на orb, sql, xml, rest, docker - всё прошло и заняло своё место. А "микросервисы - это наша серебряная пуля" продолжает жить. "У нас всё очень современно. Java17, spring boot, микросервисы, k8s, scram, agile". "А почему к вас микросервисы? Да хз, консультант сказал - пилите микросервисы, монолит уже не модно".
Разница между микросервисами и osgi - это как разница между sql и java package-ем. Это же абсолютно разные вещи.
Микросервис - новомодное слово. Как правило под ним понимают отдельное, достаточно независимое, распределённое приложение, выполняющую какую либо функцию и поддерживаемое одной командой. Т.е. микросервис как правило общается с другими микросервисами по сети, имеет свою базу и должен уметь работать даже если сервис, от которого он зависит, упал. Поскольку за один микросервис отвечает не более одной команды, то у него волей - неволей приходится выстраивать чёткие границы.
Ну про плюсы и минусы микросервисов писать нет смысла. Как говорится если вы не можете рассказать о минусах микросервисов, значит вы не знаете, что это такое.
Вот эти границы между микросервисами, без которых микросервис не микросервис, и есть модульность. И автор сообщает, что модульность можно получить и другими, более простыми и дешёвыми путями. А использовать микросервисы только ради модульности по меньшей мере глупо. И перечисляет несколько вариантов обеспечения модульности java приложений. Osgi - это в первую очередь способ обеспечения модульности (и независимости). А заодно и ioc и di - аналог спринга, но обязывает разделять публичную и приватную части. То, что некоторые фреймворки предоставляют удалённый доступ для разных частей - ну почему бы и нет. Никто же не запускает eclipse распределённо на кластере osgi. Приложение из сотни osgi бандлов в одной jvm - это эклипс. Приложение из тысячи спринговых бинов в одной jvm - это монолит. Несколько микросервисов в одной jvm - это оксюморон. Монолит - плохо, микросервис - хорошо - это часто неправда.
OpenClose принцип можно интерпретировать как открыто для использования, но реализация должна быть скрыта. Если говорить про ООП, то класс предоставляет к использованию открытые методы (и все они предназначены для использования извне) и скрывает детали реализации - всё остальное скрыто. Открыть то, что нужно и скрыть всё остальное, чтоб не дать запутаться в дебрях реализации.
На более высоком уровне - это разделение компонентов на API и реализацию. Всё, что доступно для использования вынесено в API. При этом компонент с API имеет минимум зависимостей (норма - если вообще не имеет, или имеет зависимости только от других, более высокоуровневых API). И при использовании код зависит только от API и при этом скрываются все зависимости от реализации.
Ну такое. Пока не встречал компаний, которые заставляли развиваться. Скорее наоборот - нам все это нужно вчера и как можно быстрее. Не надо разбираться - сделай как-нибудь быстро, чтоб только работало. Берут лучших из тех, кого могут взять (а кто бы поступил иначе), стараются выжать из них всё, что можно, а потом без зазрения совести выбрасывают. Ну не выбрасывают - просто стандартное повышение зарплаты в компании обычно такое, что для повышения зарплаты проще всего уволиться и заново устроиться - чем дольше работаешь, тем меньше получаешь. И вот ты в поте лица трудишься, стараешься что-то сделать и внезапно выясняешь, что а) - ты отстал от жизни, б) - ты производишь говнокод, в) - твой говнокод уже дремучее легаси и единственное, что с ним можно сделать - выкинуть и переписать заново.
Ну и да - ИТ такая область, что ты либо развиваешься, либо ты уже умер. Кому нужны технологии 20 летней давности?
Во-первых надо соблюдать некий баланс между личной жизнью и работой, иначе выгоришь. Во-вторых на работе надо соблюдать баланс между работой и развитием. В третьих надо полсылать в жопу менеджеров с их "мы хотим это вчера". И самое главное надо душить подушкой людей, повторяющих мантру "думай как менеджер" "думай как бизнес" "бизнес приносит деньги" "без бизнеса не будет этой работы". Будет. Если все будут думать как бизнес, то все подадутся в бизнесмены, а программировать некому будет. Бизнесмен должен думать, как бизнесмен, а программист должен думать как программист.
Хосспади, когда же, наконец, исчезнет эта вера в священный грааль микросервисов. И hr перестанут с апломбом заявлять, что у них на проекте не абы какой монолит, а сам спринг бут, микросервисы, кубернетес и скрам. Потому если ты не знаешь, как работает аннотация transactional, то это не к нам.
Когдаж уйдет эта вера туда, куда безвозвратно скрылась безудежная увлеченность corba, xml, soap и j2ee.
Ну зачем вам микросервисы - сделайте сначала просто декомпозицию системы на компоненты с правильными зависимостями. Выделите АПИ. Примените уже, наконец, не к столу будет сказано, этот ваш s, o, i и d из solid, про который вы все спрашиваете, на уровне компонентов. И тестируйте свои компоненты отдельно друг от друга. Напишите автотесты, тестируйте и релизьте свой продукт как душе угодно - хоть каждый день, хоть вместе, хоть по отдельности. Хоть на каждый комит.
Latency и throughput в микросервисах не станут лучше. Скорее наоборот. Как минимум лишние сетевые вызовы сделают latency выше.
Да, микросервисы могут улучшить дизайн системы потому что скорее всего вам придется делить код и уменьшать связность системы. Но это можно сделать и без микросервисов.
Ну есть же объективная причина использовать микросервисы - ресурсы же - память, storage. Или, например, время старта приложения (кому-то в облаках это еще интересно?). Или необходимость хранить в памяти большие датасеты, специфичные для разных задач. На худой конец независимая база.
С таким же успехом можно спрашивать достаточно ли у нас грамотные разрабы, чтоб задизайнить сразу все нормально и вовремя отрефачить и раздербанить на отдельные компоненты, когда возникнет необходимость. Или все-таки микросервисы - положим каждую какашку в отдельный горшочек. Если что сподручнее будет выбросить.
Но если, конечно, начальство решает выделять время на рефакторинг системы или нет, и оно знает, что микросервисы - это модно, стильно и молодежно, и это единственный способ начальство убедить - это таки сделать микросервисы, ну тогда да. Штош. Лучше так, чем никак.
Или, например, аргумент 15 летней давности. А почему ibm web sphere - это долго, дорого и больно, почему не просто tomcat. Потому что ibm web sphere стоит икс. А железо под него стоит еще икс. А там еще ibm db2 икс. И на этом фоне сумма икс, которую мы просим за проект выглядит вполне реалистично. А представь, что мы делаем проект на бесплатном томкате, используем бесплатную базу. У заказчика возникает вопрос а почему не бесплатно. Учись, студент.
Но вообще с плохим начальством нет смысла бодаться и пытаться что-то объяснить, показать и доказать. Гораздо проще найти вменяемое. А оно либо само развалится. Либо вы в том месте и не нужны.
Автор рассматривает определенный срез производства и анализирует в чем с ним проблема. То есть на реальных технических примерах поясняет, что без грамотно выстроенных технологий качественной продукции не получить. Например в советское время технологиям внимание не уделялось, они были выстроены плохо, поэтому и качество продукции было низкое.
Рынок вам сам по себе технологии не выстроит. Кадры не обучит. Тех процесс не наладит. Рынок скажет - за не качественный будильник дам рубль сегодня, а за качественный три, и вчера. А автор вам ответил на вопрос - почему будильники получаются некачественными и как сделать качественный, чтоб его за три взяли.
Часто "в кулуарах" условные "люди старой закалки" часто ругают современную систему образования за ЕГЭ (часто не имея особого представления как он вообще устроен) и лего за то, что они не развивают креативность мышления, а просто учат работать по инструкции. Немного поразмышляв на эту тему я пришел к выводу, озвученному в данной статье - для производства качественной продукции умение читать, писать и следовать инструкциям так же жизненно необходимо, как и разработка. И это одна из ключевых проблем кадров в частности и производства в общем советского периода. Одна из причин того, что в советское время качественно делали только "для космоса", "для авиации" и "для оборонки". Не знаю как соотносятся процент вложений в разработку и производство нового вида, но без грамотных инструкций качественной продукции не создашь. А что мы имели в советское время - инструкции, которыми могли пользоваться не более 5% населения, часто с ручной правкой печатного текста по которым собрать изделие просто невозможно. Даешь такой ребенку конструктор с этой инструкцией, он это все видит, плачет, и у него психологическая травма на всю оставшуюся жизнь :(. И всю жизнь этот советский ребенок готов "вносить рационализаторские предложения", но не готов читать и следовать инструкциям.
PS: Автору респект - очень интересная тема и годная статья.
Под android package имеется ввиду не что иное, как android package - не знаю, как сказать по-другому. Под SHA имеется ввиду "Отпечаток сертификата для Android", как это называют в VK или "SHA-1 certificate fingerprint", как это называют в google или хэш-ключи Android, как это называют в facebook. SHA1 хэш ключа, которым вы подписываете свое приложение перед тем, как отправлять его в store.
Если вы захотите добавить "вход через VK" в свое android приложение, то для этого вам надо будет зайти на сайт vk для разработчиков, добавить там свое приложение и указать "Название пакета для Android", "Main activity для Android", "Отпечаток сертификата для Android". Вам предоставят ID приложения, "Защищённый ключ", "Сервисный ключ доступа". И это справедливо для любого типа нативного приложения (Windows, iOS) и для всех OIDC провайдеров (facebook, yandex, twitter, github и пр.) - то есть все провайдеры просят предоставить эту информацию. Ну и мне непонятно, как сервером используется информация "Название пакета для Android", "Main activity для Android", "Отпечаток сертификата для Android" в OIDC протоколе. Я постарался внимательно прочитать все RFC по OIDC, задал вопросы на Хабр Q&A, Stack overflow и никто не ответил, так что до сих пор непонятно.
Это не совсем комментарий. Скорее вопрос по теме OIDC Auth для мобильных клиентов. Пытаюсь выяснить для чего сервера OIDC просят android package + SHA при создании авторизации для приложения android. Ну и аналогично для iOS, Windows. В спеке не нашел, в гугле не нагуглил. На вопрос никто не ответил. Even on stack overflow. Я хотел начать смотреть код OSS OIDC сервера, но вы то уже, наверное, все посмотрели и можете легко сказать зачем же это все нужно и как это работает.
В моей конфигурации dnsmasq полагается на DoH (dnscrypt-proxy) для разрешения обычных имен и на tor для разрешения имен, внесенных в специальный список. В этой схеме DoH особо не нужен - можно было вполне положиться на DNS, который поставляет провайдер. Всё-таки задача - не предоставление абсолютной анонимности, а предоставление клиентам локальной сети прозрачного доступа к ресурсам из специального списка.
Технология подключения - GPON. Основываясь на своем опыте скажу, что да - самый правильный вариант - перевести роутер МГТС в режим бриджа и забыть. Правда говорят с этим могут возникнуть проблемы. Можно использовать и SFP, но его надо купить, настроить и это надо иметь соответствующий маршрутизатор. Я сам не проверял, но на 4pda говорят, что можно купить модем Huawei HG8310M за примерно 1400 рублей - там вход GPON, выход LAN и он работает в режиме бриджа. Да, в принципе, на авито можно купить тот же sercomm rv6699 или что-то похожее за 1000 рублей и перепрошить.
Ну во-первых если в свою уютненькую веточку, то почему нет?
Во-вторых, а почему нет. Я по ошибке вмержил бранч из 19 комитов вида «ай, забыл запятую и пробел». Ну простите, кому это интересно. Предупредил всех, зарибейзил, запушил. Все смеются все довольны.
Насколько я понимаю git reset --soft '@{u}' сработает только если не делать merge upstream ветки. Ну то есть делаешь ветку, делаешь в нее 100500 комитов, никаких merge. Потом склеил и отдал.
Пожалуй что не соглашусь с правилом 1 фича — 1 выстрелчеловек. В идеальном мире — да, возможно.
Допустим мы решили на сайте сделать новую кнопочку. У нас есть верстальщик и программист. Дизайнер нам все нарисовал, верстальщик сверстал, программист сделал, а оно не работает. Например верстальщик что-то не учел и в общей верстке это не работает. Или пришел продукт, посмотрел, не понравилось, решили переделать. Надо править. Это норма.
Или разработчик бэкенд, разработчик фронтенд. Да, набросали АПИ, но что это за работа в которой не требуется изменений.
Или 10 лет назад вообще все комитили в мастер и никого это не смущало.
Теоретически да, практически пока нет. В приложении для маруси есть возможность создавать сценарии для своей колонки - например маруся может что-то сказать. Если расковырять приложение, то можно всё это делать через home assistant. Но пока нет.
Если взглянуть на статью чуть пристальнее, то окажется, что чуть более, чем все примеры притянуты за уши. Понимаю, что нет смысла ввязываться в спор на тему "в интернете кто-то не прав" и становиться призёром специальных олимпийских игр, получив первое место по минусам, но не могу пройти мимо. Такое впечатление, что автор зачем-то подменяет понятия. Но зачем? Чтоб убедить 20 доверчивых читателей, что стандарты - зло? HTML, CSS, ECMA Script, C++, SQL и вот это вот всё - зло, надо от этого всего отказаться, чтобы что? Не надо публиковать стандарты и тогда всем станет сразу хорошо? Да, кто-то что-то делает раньше других и получает от этого конкурентные преимущества.
Мне казалось, что такое понятие, как стандарт, станадртизация всего, в том числе различных форматов обмена - это в первую очередь одна из мер борьбы с монополиями и во вторую облегчение жизни простых пользователей. Шаг, который защищает нас всех от того, что одна компания завладеет контролем над чем-то. Да, стандарт может быть не бесплатным, за его использованием, за использование логотипа может взиматься плата (hdmi, display port, usb, тысячи их). Но стандарт, который нигде не описан, это, простите, не стандарт, а собственность коммерческой компании.
Не могу ничего сказать про стандарт ISO на микроскопы. Мне всегда казалось, что принятие стандарта - это процесс коллективный и открытый. "представители этой компании были ведущими составителями" - ведущими, но не единственными - кто-то имел знания, но просто не сумел их использовать. Может ларчик просто открывался - компания была ведущей и поэтому в основном её продукцию и покупали и стандарт особо роли не играл - но тут сказать ничего не могу - просто мои домыслы, которые появились, полсе того, как я взглянул на другие пункты.
PDF - википедия говорит, что стандарт основан на PostScript (открытый стандарт, появился в 1982 году), опубликован 15 июня 1993. Я так понимаю он изначально был открытым и бесплатным (но это не точно), продавалось только ПО. А c с 1 июля 2008 года является открытым стандартом ISO 32000. Ну то есть одно дело вася пупкин выложил стандарт на своей домашней страничке. А другое дело отправил его в ISO и там его приняли, зафиксировали, проверили, присвоили номер. Ну и если мне не изменяет мой склероз, было несколько бесплатных читалок PDF и до 2008 года. Вроде даже с открытым исходным кодом. И вообще "В 1985 году продажи компьютеров Macintosh начали падать, и Apple нужен был «killer app» — нечто, что мог бы только её компьютер. Стив Джобс инвестировал 2,5 млн $ в Adobe, которая создала PostScript-контроллер для принтера Apple LaserWriter, и в Aldus, создавшую программу PageMaker, использовавшую все возможности Macintosh и LaserWriter. Появившаяся тогда возможность допечатной подготовки на компьютере спасла Apple и превратила Adobe и Aldus в крупные компании." - что плохого в том, что Стив Джобс сделал что-то хорошее?
Java вроде была стандартом почти с самого начала. Помню реализацию от IBM, реализацию от Semantec - одну из первых реализаций с JIT (вот бесдоказательная фраза со stack overflow - Borland had the first one followed shortly by Symantec. Sun licensed the Symantec one. Symantec demoed theirs in March of 1996. Хотя не припоминаю JIT от Borland). Реализация от azul вроде до сих пор живёт и продаётся. И вроде насколько я помню, товарищи из Sun очень серьёзно относились к стандартизации и открытости - существовал TCK, прохождение которого позволяло продукту носить имя Java (товарный знак, принадлежал Sun). Насколько я помню существовали также совместимые реализации их серверного процессора на архитектуре sparc. Кстати в том числе от нашей небезызвестной МЦСТ. Не понимаю кто кого и как тут обманывал стандартами, и на чём наживался.
Chrome, cookie, android - смешались в кучу кони, люди. Вроде движок хрома и не стандарт, а open source. И почти все браузеры на него перешли - ну просто потому что хорош. И веб дизайнеры говорят им за это огромное спасибо, что наконец то в браузерах появилась нормальная поддержка стандартов. И я думаю, что если Google Chrome вдруг при запрещённых third-party cookies начнёт отправлять статистику в Google и использовать её для показа контекстной рекламы, то их так нагнут, что они надолго забудут что такое реклама и куда её надо показывать. Они могут писать что-то мелким шрифтом, но я думаю соблюдение лицензионного соглашения - это святое. И что-то идея создания андроида для победы хрома - это чё-то больше похоже на влажные фантазии.
Ну и микрософт как раз является ярким примером компании, которая делала всё, чтобы предотвратить возникновение стандартов. Любым способом. Уж и суд постановил - либо вы опубликуете ваши форматы, либо мы вас. И всё равно - опубликовали якобы "стандарт", в котором использовались проприетарные блобы. Хотя "де факто стандарт обмена сообщениями doc" - тоже в какой-то степени стандарт.
Может автор немного попутал стандарты и open source и статью понять как проклятые капиталисты пишут программы, которые захватывают рынок - пусть отдают их бесплатно, а ещё лучше сразу опенсорсят.
Спасибо, очень годная статья. Вот каждый раз делаю cat /proc/meminfo (редко), или в метрики смотрю, и каждый раз приходится вспоминать, а что все эти слова значат. Особенно WSS.
Напрашивается в начале статьи кратенько (свёрнуто) список этих самых типов памяти и расшифровочку. Да, и про библиотечки я б тоже послушал - грузятся ли они в память, а в какую. Чтоб добавил одну только эту статью в закладки, и каждый раз, когда надо, пошёл, посмотрел и всё сразу стало ясно. Да даже не в закладки, а прям с графаны ссылочку сюда тыц.
К сожалению время идёт и наблюдается перетекание качества в количество. Количество растёт, а вот качество.
Ребят, ну вы серьёзно? Вы же вроде как курсы IT, должны же знать - вся история программирования есть разные способы разбиения приложения на более мелкие и управляемые блоки. Функции, подпрограммы, библиотеки, объекты, модули, программы, тысячи их. И нет, микросервисная архитектура не предлагает новых способов разбиенич приложения на более мелкие и управляемые блоки - просто использует существующие . Ну разве что затрудняет переиспользование.
Вроде же большая, уважаемая контора, с высоким рейтингом на хабре, вроде как обучающая людей, ну как же такое писать то можно.
Ну в конце то концов, несмотря на всю мою лютую, дикую ненависть к микросервисам, ну ведь у них тоже есть своя область применение, полезные свойства. Возможность быстрее делать апдейт маленького сервиса большого приложения (обычно не особо нужно, ну если, конечно у вас не монстр, стартующий два часа. И не работает на практике потому что в апдейт чаще выкатывают кучу микросервисов). Самое главное - независимость сервисов - делай свои сервисы так, чтоб они продолжали работать даже когда родительский микросервис недоступен - позволяет не растерять всех пользователей, когда что-то накрылось - типа что-то накрылось, но что-то ещё продолжает работать. Возможность гибко масштабироваться (обычно не нужно - load balancer-а обычно более чем достаточно). Решить проблему с нехваткой физических ресурсов (CPU, Memory). Но интернет-магазин, если это не озон-амазон в качестве примера - ну ё-маё. Всё равно, что использовать NoSQL просто для фана - ну и что, что одна нода, зато есть возможность масштабироваться, когда-нибудь.
Ну зайдите с другой стороны. "Когда вам придётся работать с заказчиком, который ничего не понимает в IT, то слова микросервис и k8s будут его сильно возбуждать - даже в баню везти не придётся. И сразу станет понятно почему под проект надо так много железна - кластер же, отказоустойчивость, микросервисы. И сразу станет не так важно, что мы просим за проект в 10 раз больше, чем нужно - на железо придётся потратиться ещё в 10 раз больше, так что всё обосновано, всё норм."
Вот уже прошли сезоны хайпа на orb, sql, xml, rest, docker - всё прошло и заняло своё место. А "микросервисы - это наша серебряная пуля" продолжает жить. "У нас всё очень современно. Java17, spring boot, микросервисы, k8s, scram, agile". "А почему к вас микросервисы? Да хз, консультант сказал - пилите микросервисы, монолит уже не модно".
Разница между микросервисами и osgi - это как разница между sql и java package-ем. Это же абсолютно разные вещи.
Микросервис - новомодное слово. Как правило под ним понимают отдельное, достаточно независимое, распределённое приложение, выполняющую какую либо функцию и поддерживаемое одной командой. Т.е. микросервис как правило общается с другими микросервисами по сети, имеет свою базу и должен уметь работать даже если сервис, от которого он зависит, упал. Поскольку за один микросервис отвечает не более одной команды, то у него волей - неволей приходится выстраивать чёткие границы.
Ну про плюсы и минусы микросервисов писать нет смысла. Как говорится если вы не можете рассказать о минусах микросервисов, значит вы не знаете, что это такое.
Вот эти границы между микросервисами, без которых микросервис не микросервис, и есть модульность. И автор сообщает, что модульность можно получить и другими, более простыми и дешёвыми путями. А использовать микросервисы только ради модульности по меньшей мере глупо. И перечисляет несколько вариантов обеспечения модульности java приложений. Osgi - это в первую очередь способ обеспечения модульности (и независимости). А заодно и ioc и di - аналог спринга, но обязывает разделять публичную и приватную части. То, что некоторые фреймворки предоставляют удалённый доступ для разных частей - ну почему бы и нет. Никто же не запускает eclipse распределённо на кластере osgi. Приложение из сотни osgi бандлов в одной jvm - это эклипс. Приложение из тысячи спринговых бинов в одной jvm - это монолит. Несколько микросервисов в одной jvm - это оксюморон. Монолит - плохо, микросервис - хорошо - это часто неправда.
OpenClose принцип можно интерпретировать как открыто для использования, но реализация должна быть скрыта. Если говорить про ООП, то класс предоставляет к использованию открытые методы (и все они предназначены для использования извне) и скрывает детали реализации - всё остальное скрыто. Открыть то, что нужно и скрыть всё остальное, чтоб не дать запутаться в дебрях реализации.
На более высоком уровне - это разделение компонентов на API и реализацию. Всё, что доступно для использования вынесено в API. При этом компонент с API имеет минимум зависимостей (норма - если вообще не имеет, или имеет зависимости только от других, более высокоуровневых API). И при использовании код зависит только от API и при этом скрываются все зависимости от реализации.
Ну такое. Пока не встречал компаний, которые заставляли развиваться. Скорее наоборот - нам все это нужно вчера и как можно быстрее. Не надо разбираться - сделай как-нибудь быстро, чтоб только работало. Берут лучших из тех, кого могут взять (а кто бы поступил иначе), стараются выжать из них всё, что можно, а потом без зазрения совести выбрасывают. Ну не выбрасывают - просто стандартное повышение зарплаты в компании обычно такое, что для повышения зарплаты проще всего уволиться и заново устроиться - чем дольше работаешь, тем меньше получаешь. И вот ты в поте лица трудишься, стараешься что-то сделать и внезапно выясняешь, что а) - ты отстал от жизни, б) - ты производишь говнокод, в) - твой говнокод уже дремучее легаси и единственное, что с ним можно сделать - выкинуть и переписать заново.
Ну и да - ИТ такая область, что ты либо развиваешься, либо ты уже умер. Кому нужны технологии 20 летней давности?
Во-первых надо соблюдать некий баланс между личной жизнью и работой, иначе выгоришь. Во-вторых на работе надо соблюдать баланс между работой и развитием. В третьих надо полсылать в жопу менеджеров с их "мы хотим это вчера". И самое главное надо душить подушкой людей, повторяющих мантру "думай как менеджер" "думай как бизнес" "бизнес приносит деньги" "без бизнеса не будет этой работы". Будет. Если все будут думать как бизнес, то все подадутся в бизнесмены, а программировать некому будет. Бизнесмен должен думать, как бизнесмен, а программист должен думать как программист.
Хосспади, когда же, наконец, исчезнет эта вера в священный грааль микросервисов. И hr перестанут с апломбом заявлять, что у них на проекте не абы какой монолит, а сам спринг бут, микросервисы, кубернетес и скрам. Потому если ты не знаешь, как работает аннотация transactional, то это не к нам.
Когдаж уйдет эта вера туда, куда безвозвратно скрылась безудежная увлеченность corba, xml, soap и j2ee.
Ну зачем вам микросервисы - сделайте сначала просто декомпозицию системы на компоненты с правильными зависимостями. Выделите АПИ. Примените уже, наконец, не к столу будет сказано, этот ваш s, o, i и d из solid, про который вы все спрашиваете, на уровне компонентов. И тестируйте свои компоненты отдельно друг от друга. Напишите автотесты, тестируйте и релизьте свой продукт как душе угодно - хоть каждый день, хоть вместе, хоть по отдельности. Хоть на каждый комит.
Latency и throughput в микросервисах не станут лучше. Скорее наоборот. Как минимум лишние сетевые вызовы сделают latency выше.
Да, микросервисы могут улучшить дизайн системы потому что скорее всего вам придется делить код и уменьшать связность системы. Но это можно сделать и без микросервисов.
Ну есть же объективная причина использовать микросервисы - ресурсы же - память, storage. Или, например, время старта приложения (кому-то в облаках это еще интересно?). Или необходимость хранить в памяти большие датасеты, специфичные для разных задач. На худой конец независимая база.
С таким же успехом можно спрашивать достаточно ли у нас грамотные разрабы, чтоб задизайнить сразу все нормально и вовремя отрефачить и раздербанить на отдельные компоненты, когда возникнет необходимость. Или все-таки микросервисы - положим каждую какашку в отдельный горшочек. Если что сподручнее будет выбросить.
Но если, конечно, начальство решает выделять время на рефакторинг системы или нет, и оно знает, что микросервисы - это модно, стильно и молодежно, и это единственный способ начальство убедить - это таки сделать микросервисы, ну тогда да. Штош. Лучше так, чем никак.
Или, например, аргумент 15 летней давности. А почему ibm web sphere - это долго, дорого и больно, почему не просто tomcat. Потому что ibm web sphere стоит икс. А железо под него стоит еще икс. А там еще ibm db2 икс. И на этом фоне сумма икс, которую мы просим за проект выглядит вполне реалистично. А представь, что мы делаем проект на бесплатном томкате, используем бесплатную базу. У заказчика возникает вопрос а почему не бесплатно. Учись, студент.
Но вообще с плохим начальством нет смысла бодаться и пытаться что-то объяснить, показать и доказать. Гораздо проще найти вменяемое. А оно либо само развалится. Либо вы в том месте и не нужны.
У меня все. Минусуйте.
Автор рассматривает определенный срез производства и анализирует в чем с ним проблема. То есть на реальных технических примерах поясняет, что без грамотно выстроенных технологий качественной продукции не получить. Например в советское время технологиям внимание не уделялось, они были выстроены плохо, поэтому и качество продукции было низкое.
Рынок вам сам по себе технологии не выстроит. Кадры не обучит. Тех процесс не наладит. Рынок скажет - за не качественный будильник дам рубль сегодня, а за качественный три, и вчера.
А автор вам ответил на вопрос - почему будильники получаются некачественными и как сделать качественный, чтоб его за три взяли.
Часто "в кулуарах" условные "люди старой закалки" часто ругают современную систему образования за ЕГЭ (часто не имея особого представления как он вообще устроен) и лего за то, что они не развивают креативность мышления, а просто учат работать по инструкции. Немного поразмышляв на эту тему я пришел к выводу, озвученному в данной статье - для производства качественной продукции умение читать, писать и следовать инструкциям так же жизненно необходимо, как и разработка. И это одна из ключевых проблем кадров в частности и производства в общем советского периода. Одна из причин того, что в советское время качественно делали только "для космоса", "для авиации" и "для оборонки". Не знаю как соотносятся процент вложений в разработку и производство нового вида, но без грамотных инструкций качественной продукции не создашь. А что мы имели в советское время - инструкции, которыми могли пользоваться не более 5% населения, часто с ручной правкой печатного текста по которым собрать изделие просто невозможно. Даешь такой ребенку конструктор с этой инструкцией, он это все видит, плачет, и у него психологическая травма на всю оставшуюся жизнь :(. И всю жизнь этот советский ребенок готов "вносить рационализаторские предложения", но не готов читать и следовать инструкциям.
PS: Автору респект - очень интересная тема и годная статья.
Под android package имеется ввиду не что иное, как android package - не знаю, как сказать по-другому. Под SHA имеется ввиду "Отпечаток сертификата для Android", как это называют в VK или "SHA-1 certificate fingerprint", как это называют в google или хэш-ключи Android, как это называют в facebook. SHA1 хэш ключа, которым вы подписываете свое приложение перед тем, как отправлять его в store.
Если вы захотите добавить "вход через VK" в свое android приложение, то для этого вам надо будет зайти на сайт vk для разработчиков, добавить там свое приложение и указать "Название пакета для Android", "Main activity для Android", "Отпечаток сертификата для Android". Вам предоставят ID приложения, "Защищённый ключ", "Сервисный ключ доступа". И это справедливо для любого типа нативного приложения (Windows, iOS) и для всех OIDC провайдеров (facebook, yandex, twitter, github и пр.) - то есть все провайдеры просят предоставить эту информацию. Ну и мне непонятно, как сервером используется информация "Название пакета для Android", "Main activity для Android", "Отпечаток сертификата для Android" в OIDC протоколе. Я постарался внимательно прочитать все RFC по OIDC, задал вопросы на Хабр Q&A, Stack overflow и никто не ответил, так что до сих пор непонятно.
В RFC 8252 (OAuth 2.0 for Native Apps) я вижу только предпочтительный flow для native apps и необходимость использовать PKCE.
RFC 7636 (PKCE - Proof Key for Code Exchange by OAuth Public Clients) добавляет верификацию вместо секретного ключа в OIDC flow - для того, чтобы перехват первоначального ответа не позволил злоумышленнику получить доступ.
Как используется android package и sha-1 certificate fingerprint непонятно. Исходные данные похожи на те, что используют в verified android app links.
Похоже самым простым способом ответить на этот вопрос будет взять исходники OSS OIDC Authorization Server и посмотреть.
Это не совсем комментарий. Скорее вопрос по теме OIDC Auth для мобильных клиентов.
Пытаюсь выяснить для чего сервера OIDC просят android package + SHA при создании авторизации для приложения android. Ну и аналогично для iOS, Windows. В спеке не нашел, в гугле не нагуглил. На вопрос никто не ответил. Even on stack overflow. Я хотел начать смотреть код OSS OIDC сервера, но вы то уже, наверное, все посмотрели и можете легко сказать зачем же это все нужно и как это работает.
В моей конфигурации dnsmasq полагается на DoH (dnscrypt-proxy) для разрешения обычных имен и на tor для разрешения имен, внесенных в специальный список. В этой схеме DoH особо не нужен - можно было вполне положиться на DNS, который поставляет провайдер. Всё-таки задача - не предоставление абсолютной анонимности, а предоставление клиентам локальной сети прозрачного доступа к ресурсам из специального списка.
Технология подключения - GPON. Основываясь на своем опыте скажу, что да - самый правильный вариант - перевести роутер МГТС в режим бриджа и забыть. Правда говорят с этим могут возникнуть проблемы. Можно использовать и SFP, но его надо купить, настроить и это надо иметь соответствующий маршрутизатор. Я сам не проверял, но на 4pda говорят, что можно купить модем Huawei HG8310M за примерно 1400 рублей - там вход GPON, выход LAN и он работает в режиме бриджа. Да, в принципе, на авито можно купить тот же sercomm rv6699 или что-то похожее за 1000 рублей и перепрошить.
Во-вторых, а почему нет. Я по ошибке вмержил бранч из 19 комитов вида «ай, забыл запятую и пробел». Ну простите, кому это интересно. Предупредил всех, зарибейзил, запушил. Все смеются все довольны.
выстрелчеловек. В идеальном мире — да, возможно.Допустим мы решили на сайте сделать новую кнопочку. У нас есть верстальщик и программист. Дизайнер нам все нарисовал, верстальщик сверстал, программист сделал, а оно не работает. Например верстальщик что-то не учел и в общей верстке это не работает. Или пришел продукт, посмотрел, не понравилось, решили переделать. Надо править. Это норма.
Или разработчик бэкенд, разработчик фронтенд. Да, набросали АПИ, но что это за работа в которой не требуется изменений.
Или 10 лет назад вообще все комитили в мастер и никого это не смущало.