Сомневаюсь. Если это апп на электроне, со своим встроенным браузером, то да. Здесь же все пускается в том же хроме, только без навигации. Установил хабр как приложение, запустил, и не вижу отдельного процесса.
Вроде как уже давно можно было сделать шорткат в системе на сайт, чтобы он открывался в отдельном окне без URL и табов. Не совсем понятно чем установка приложения отличается от шортката.
Не обязательно. Когда фронт модульный и пилится одновременно несколькими командами, возникает проблема с зависимостями, когда разные команды используют либы разных версий, которые по нескольку раз включаются в финальный бандл. Поэтому некоторые переходят на монорепозиторий, где менеджить зависимости легче.
Больше. Все инкрустированные сервисы типа социальных кнопок, рекламы, аналитики тащат с собой свои SDK-бандлы, каждый из которых запросто может превосходить сам код страницы. Благо грузятся они все асинхронно. Автор должен был это учесть.
Каким объективным методом аффтар меряет "Skill" на приведенном графике? К тому же "Сеньорити" подвержено инфляции. Сеньоры сейчас не то же самое, что 10 день назад. Поэтому набирая джунов, вы дай бог возьмете кого-то с недельными курсами.
Не кажется ли вам, что роль различных методик и практик менеджмента сильно преувеличена? Если у вас в команде только ленивые задницы, которые ждут, когда им скажут какие кнопки им давить, то хоть расперпендикуляртесь, вы не заставите их делать что-либо удобоваримое.
В общем случае техдолг -- задачи, которые не приносят непосредственный value бизнесу, но от решения которых зависит скорость выкатывания новых фич. Способом борьбы может быть также мелкий рефакторинг непосредственно при решении основной бизнес задачи. В некоторых случаях техдолг превосходит по объему полную реимплементацию проекта. Однако основной проблемой здесь будет объяснить бизнесу необходимость данного действия. Обычно такое происходит только после полной смены команды.
gRPC - это всё-таки клиент-серверный протокол, нежели полностью распределённый, как например RMI или CORBA. Основное их отличие в том, что endpoint также является объектом, который можно сериализовать и передавать по сети, таким образом осуществляя двустороннюю связь. Одним из кейсов является remote invoke with callback, где помимо структур передается локальный объект, которому удаленный сервис передаст результат. Все же современные протоколы работают лишь в одну сторону.
Дэвид Теннант -- бесспорно лучший доктор! Но эпизоды с Меттью Смитом более захватывающие, к тому же с очаровательной Карен Гиллан. С Питером Капальди через все серии стала протаскиваться "повесточка", которой авторы стали все больше уделять внимание в ущерб сценарию. И с Джоди Фостер авторы сделали "повесточку" главной целью сериала, полностью забив на сценарий.
Я понимаю, если это бизнес -- там как бы изначально цель продать побольше воздуха. Но в IT люди как-то должны критически относиться к навязываемому буллшиту! Я уверен, все эти диаграммы и термины были придуманы людьми, которые не написали ни строчки кода, начиная с университета, и по большей части по причине безделия. Скорей всего человек просто, наконец, разобрался в том, что заимплементили девелоперы, и решил об этом поведать миру, придумывая заумные термины вроде "лямбля" и "каппа" архитектуры, которые можно натянуть на что угодно как сову на глобус.
С другой стороны, польза от "архитектуры" все же есть: все эти диаграммы и модные слова помогают перед клиентом оправдывать ценник проекта. Ибо как в фильме: "гренка не может стоить 8 долларов, а 'крутон' -- может".
Лев Николаевич Толстой был известным полиглотом. Он владел 13 языками. В возрасте 80 лет он стал учить китайский. Но язык ему не дался. "То ли китайский язык слишком сложный, то ли я для него слишком стар" -- разочарованно промолвил Лев Толстой. (где хаскель?)
Может я ошибаюсь ввиду своей ограниченности, но у меня стойкое впечатление, что сначала появляется задача, потом ее решение, и затем реализация. И уже потом умные люди придумывают ей название, классифицируют и пишут о ней в своих блогах, статьях, рассказывают на конференциях, засовывают в учебники, продают ее бизнесу как новую "серебряную пулю", а те в свою очередь добавляют ее в список требований для очередной вакансии...
Это в любом случае означает, что команда считает эти детали значимыми, но не имеет информации, позволяющей оценить степень соответствия каждого из вариантов желаемому продактом.
Как я уже сказал выше, если команда, ждет, что ей объяснят на какие кнопки давить, то это незрелая команда, не способная принимать решения. Значимые детали -- это те, которые определяют архитектуру решения, и которые потом будет сложно поменять. Их и нужно обговаривать в первую очередь с продактом. А куда сдвинуть кнопку или какую надпись поставить на компонент -- это незначительные детали, которые лучше обсуждать уже имея на руках что-то рабочее, и которые прокатывают как есть в 90% случаев.
Технические же детали вообще не нужно обсуждать с продактом, потому как вероятны два варианта:
либо он отложит проблему в долгий ящих и скажет "подумаю потом на досуге"
либо, что еще хуже, примет некомпетентное решение за тебя, которое сулит многими проблемами в дальнейшем
При всем уважении, многие руководители убеждены, что причиной провала проекта является именно неверно выбранная или неправильно используемая методология. И что перейдя на X, их проект попрет как по вазелину. Хотя реальная ситуация может быть как в старом анекдоте: "У моей бабушки был бордель. И вот когда доходы падали, она меняла девочек, а не двигала кровати."
Если почти на все, то у вас явно есть проблемы с делегированием, которые, скорее всего, вытекают из проблем с постановкой задач своей команде.
Там миллион причин: от низкой мотивации в команде до того, что сам менеджер просто ленивая задница.
Задача должна быть четко и конкретно сформулирована.
Насколько конкретно? Если PM должен объяснять девелоперу какие клавиши он должен нажать, то нафиг такой девелопер -- его уже сейчас дешевле заменит ИИ. И при всем желании вы не сможете сформулировать четко и конкретно любую задачу, учтя все стопицот нюансов и кейсов, либо вы уже будете не в силах сфокусироваться ни на чем другом. Вместо этого PM должен донести идею, что он хочет видеть, и дать команде возможность для самостоятельного маневра и выбора решений. И если команда вас постоянно "пингует" спрашивая деталей по любому поводу, это говорит о ее общей незрелости и необходимости внедрения тимлида.
Также стоит отметить, что SMART – это не волшебная таблетка
Очень важная ремарка: мы впарили вам очередной X, но никаких гарантий не даем и никакой ответственности не несем.
Помню дрючил ASM, чтобы инжектнуть в классы код, проверяющий наличие лицензии для нашего продукта. Причем, вместо вызова сторонней функции инлайнился сам код прямо в методы, рандомно выбранные при сборке. Кроме того, пришлось придумать некое подобие полиморфности при генерации, чтобы код не был вычищен простым поиском по шаблону. Интересно, но на мой взгляд слишком трудозатратно: cамым тяжелым была генерация лямбд.
Поэтому лучшим на мой взгляд способом для генерации кода в рантайме будет компиляция из исходного кода с использованием javax.tools.JavaCompiler в связке с каким-нибудь JavaPoet или шаблонизатором. Чаще нужно просто модифицировать уже существующий код, тогда ByteBuddy тут нет равных.
Меня вообще забавляет свойство современных разработчиков, не разобравшись как следует с решением и не вникая в теорию, одним махом переехать на другую платформу или внести в проект ещё одну тяжёлую зависимость. У меня один разраб топил за редис как средство оптимизации хреново написанных запросов. В итоге был послан и нагружен дополнительно теорией и переписыванием тех самых запросов.
Не берусь говорить о конкретной реализации движка, но теоретически хеш индексы дают константный доступ для одной записи, соответственно время растет линейно. Для дедуплицирования нет необходимости использовать btree.
Извините, если, написав много тестов, следуя хрестоматийным TDD-шным истинам, в вас не закралось зерно сомнения по поводу правильности данного подхода, то вы пока еще ничего не поняли.
Тесты — это документация
Буллщит. Покажите мне хоть один проект, где бы документация была опубликована ввиде тестов. Есть конечно BDD, но это когда тесты готовят по опубликованной спеке, а не наоборот. Простая и понятная сигнатура метода -- сама себе документация. Для неочевидных вещей здесь же описывается спека на человечьем языке. А ваши стопицот тестов никто никогда не прочтет в жизни.
Но если вам легко написать на код тест, скорее всего, он легко читается и у него простая логика.
TDD и злоупотребление unit-ами ведет к излишней фрагметнированности кода, когда логика становится "размазанной" по большому числу абстракций и фунциональных компонентов, созданных искусственно в угоду тестируемости. В итоге каждый фрагмент действительно становится проще тестировать отдельно, но вся композиционная логика бизнес кейса остается за пределами какого-то либо теста, что зачастую провоцирует "нежданчики" на проде. И понять что реально делает фрагментированный код на порядок сложнее, нежели если вся логика была бы описана линейно.
Другая вещь, которую вы не упомянули -- это мокирование. Оно как правило занимает 90% времени написания теста и его отладки. А самое смешное, что в подавляющем большинстве случаев поведение мокированного кода -- это поведение сферического коня в вакууме, которое слабо соотносится с реальными кейсами. Особенно все, что касается стейта и базы данных. Поэтому народ сейчас все более склонен поднимать в контейнере реальную базу с тестовым набором данных, чтобы тестировать все как есть. А юниты все чаще заменяются "сценарными" тестами, которые тестируют именно бизнес спецификацию, а не внутренний дизайн.
у компонента есть шаблон, взаимодействие с которым нужно тоже протестировать, и хуки жизненного цикла, которые накладывают дополнительные ограничения в тестах.
Совершенно верно, и это проблема Angular и других фреймворков, которые местами противоречат вашему тезису о тестируемости кода, вынужная вас строго следовать исключительно предусмотренным паттернам.
Давайте немного улучшим наш код. Перенесем логику в сервис
Это по-вашему улучшение? Вы нагрузили сервис доступа к данным инородной логикой обработки и визуализации ошибки, закамуфлировав ее ввиде "пустого" результата для компонента.
Тесты — это инвестиции в светлое будущее
Тесты -- это мусор в проекте, необходимый лишь для повышения качества service delivery, и требуют значительных затрат на написание и поддержку. Чем больше глупых тестов в проекте с многократным покрытием одних и тех же фрагментов, тем сложнее становится выкатывание новых фич. Поэтому держать нужно лишь необходимый минимум.
Тесты -- это тоже код, поэтому они также могут содержать баги. Кто же тестирует тесты? Основной код? Круговая порука получается.
Однозначно. Продюсер льет в topic строго последовательно, используя одно соединение. Ack подтверждения служат для гарантии доставки при выходе из строя основной partition, а не для упорядочения. Все остальное фантазии автора.
Сомневаюсь. Если это апп на электроне, со своим встроенным браузером, то да. Здесь же все пускается в том же хроме, только без навигации. Установил хабр как приложение, запустил, и не вижу отдельного процесса.
Вроде как уже давно можно было сделать шорткат в системе на сайт, чтобы он открывался в отдельном окне без URL и табов. Не совсем понятно чем установка приложения отличается от шортката.
Не обязательно. Когда фронт модульный и пилится одновременно несколькими командами, возникает проблема с зависимостями, когда разные команды используют либы разных версий, которые по нескольку раз включаются в финальный бандл. Поэтому некоторые переходят на монорепозиторий, где менеджить зависимости легче.
Больше. Все инкрустированные сервисы типа социальных кнопок, рекламы, аналитики тащат с собой свои SDK-бандлы, каждый из которых запросто может превосходить сам код страницы. Благо грузятся они все асинхронно. Автор должен был это учесть.
Каким объективным методом аффтар меряет "Skill" на приведенном графике? К тому же "Сеньорити" подвержено инфляции. Сеньоры сейчас не то же самое, что 10 день назад. Поэтому набирая джунов, вы дай бог возьмете кого-то с недельными курсами.
Не кажется ли вам, что роль различных методик и практик менеджмента сильно преувеличена? Если у вас в команде только ленивые задницы, которые ждут, когда им скажут какие кнопки им давить, то хоть расперпендикуляртесь, вы не заставите их делать что-либо удобоваримое.
В общем случае техдолг -- задачи, которые не приносят непосредственный value бизнесу, но от решения которых зависит скорость выкатывания новых фич. Способом борьбы может быть также мелкий рефакторинг непосредственно при решении основной бизнес задачи. В некоторых случаях техдолг превосходит по объему полную реимплементацию проекта. Однако основной проблемой здесь будет объяснить бизнесу необходимость данного действия. Обычно такое происходит только после полной смены команды.
gRPC - это всё-таки клиент-серверный протокол, нежели полностью распределённый, как например RMI или CORBA. Основное их отличие в том, что endpoint также является объектом, который можно сериализовать и передавать по сети, таким образом осуществляя двустороннюю связь. Одним из кейсов является remote invoke with callback, где помимо структур передается локальный объект, которому удаленный сервис передаст результат. Все же современные протоколы работают лишь в одну сторону.
Я так понимаю, это перефразированный закон Гудхарта: https://ru.wikipedia.org/wiki/Закон_Гудхарта
Дэвид Теннант -- бесспорно лучший доктор! Но эпизоды с Меттью Смитом более захватывающие, к тому же с очаровательной Карен Гиллан. С Питером Капальди через все серии стала протаскиваться "повесточка", которой авторы стали все больше уделять внимание в ущерб сценарию. И с Джоди Фостер авторы сделали "повесточку" главной целью сериала, полностью забив на сценарий.
Я понимаю, если это бизнес -- там как бы изначально цель продать побольше воздуха. Но в IT люди как-то должны критически относиться к навязываемому буллшиту! Я уверен, все эти диаграммы и термины были придуманы людьми, которые не написали ни строчки кода, начиная с университета, и по большей части по причине безделия. Скорей всего человек просто, наконец, разобрался в том, что заимплементили девелоперы, и решил об этом поведать миру, придумывая заумные термины вроде "лямбля" и "каппа" архитектуры, которые можно натянуть на что угодно как сову на глобус.
С другой стороны, польза от "архитектуры" все же есть: все эти диаграммы и модные слова помогают перед клиентом оправдывать ценник проекта. Ибо как в фильме: "гренка не может стоить 8 долларов, а 'крутон' -- может".
Лев Николаевич Толстой был известным полиглотом. Он владел 13 языками. В возрасте 80 лет он стал учить китайский. Но язык ему не дался. "То ли китайский язык слишком сложный, то ли я для него слишком стар" -- разочарованно промолвил Лев Толстой. (где хаскель?)
P.S. Знать и владеть -- разные вещи.
Может я ошибаюсь ввиду своей ограниченности, но у меня стойкое впечатление, что сначала появляется задача, потом ее решение, и затем реализация. И уже потом умные люди придумывают ей название, классифицируют и пишут о ней в своих блогах, статьях, рассказывают на конференциях, засовывают в учебники, продают ее бизнесу как новую "серебряную пулю", а те в свою очередь добавляют ее в список требований для очередной вакансии...
Как я уже сказал выше, если команда, ждет, что ей объяснят на какие кнопки давить, то это незрелая команда, не способная принимать решения. Значимые детали -- это те, которые определяют архитектуру решения, и которые потом будет сложно поменять. Их и нужно обговаривать в первую очередь с продактом. А куда сдвинуть кнопку или какую надпись поставить на компонент -- это незначительные детали, которые лучше обсуждать уже имея на руках что-то рабочее, и которые прокатывают как есть в 90% случаев.
Технические же детали вообще не нужно обсуждать с продактом, потому как вероятны два варианта:
либо он отложит проблему в долгий ящих и скажет "подумаю потом на досуге"
либо, что еще хуже, примет некомпетентное решение за тебя, которое сулит многими проблемами в дальнейшем
При всем уважении, многие руководители убеждены, что причиной провала проекта является именно неверно выбранная или неправильно используемая методология. И что перейдя на X, их проект попрет как по вазелину. Хотя реальная ситуация может быть как в старом анекдоте: "У моей бабушки был бордель. И вот когда доходы падали, она меняла девочек, а не двигала кровати."
Там миллион причин: от низкой мотивации в команде до того, что сам менеджер просто ленивая задница.
Насколько конкретно? Если PM должен объяснять девелоперу какие клавиши он должен нажать, то нафиг такой девелопер -- его уже сейчас дешевле заменит ИИ. И при всем желании вы не сможете сформулировать четко и конкретно любую задачу, учтя все стопицот нюансов и кейсов, либо вы уже будете не в силах сфокусироваться ни на чем другом. Вместо этого PM должен донести идею, что он хочет видеть, и дать команде возможность для самостоятельного маневра и выбора решений. И если команда вас постоянно "пингует" спрашивая деталей по любому поводу, это говорит о ее общей незрелости и необходимости внедрения тимлида.
Очень важная ремарка: мы впарили вам очередной X, но никаких гарантий не даем и никакой ответственности не несем.
Помню дрючил ASM, чтобы инжектнуть в классы код, проверяющий наличие лицензии для нашего продукта. Причем, вместо вызова сторонней функции инлайнился сам код прямо в методы, рандомно выбранные при сборке. Кроме того, пришлось придумать некое подобие полиморфности при генерации, чтобы код не был вычищен простым поиском по шаблону. Интересно, но на мой взгляд слишком трудозатратно: cамым тяжелым была генерация лямбд.
Поэтому лучшим на мой взгляд способом для генерации кода в рантайме будет компиляция из исходного кода с использованием
javax.tools.JavaCompilerв связке с каким-нибудь JavaPoet или шаблонизатором. Чаще нужно просто модифицировать уже существующий код, тогда ByteBuddy тут нет равных.Меня вообще забавляет свойство современных разработчиков, не разобравшись как следует с решением и не вникая в теорию, одним махом переехать на другую платформу или внести в проект ещё одну тяжёлую зависимость. У меня один разраб топил за редис как средство оптимизации хреново написанных запросов. В итоге был послан и нагружен дополнительно теорией и переписыванием тех самых запросов.
Не берусь говорить о конкретной реализации движка, но теоретически хеш индексы дают константный доступ для одной записи, соответственно время растет линейно. Для дедуплицирования нет необходимости использовать btree.
Извините, если, написав много тестов, следуя хрестоматийным TDD-шным истинам, в вас не закралось зерно сомнения по поводу правильности данного подхода, то вы пока еще ничего не поняли.
Буллщит. Покажите мне хоть один проект, где бы документация была опубликована ввиде тестов. Есть конечно BDD, но это когда тесты готовят по опубликованной спеке, а не наоборот. Простая и понятная сигнатура метода -- сама себе документация. Для неочевидных вещей здесь же описывается спека на человечьем языке. А ваши стопицот тестов никто никогда не прочтет в жизни.
TDD и злоупотребление unit-ами ведет к излишней фрагметнированности кода, когда логика становится "размазанной" по большому числу абстракций и фунциональных компонентов, созданных искусственно в угоду тестируемости. В итоге каждый фрагмент действительно становится проще тестировать отдельно, но вся композиционная логика бизнес кейса остается за пределами какого-то либо теста, что зачастую провоцирует "нежданчики" на проде. И понять что реально делает фрагментированный код на порядок сложнее, нежели если вся логика была бы описана линейно.
Другая вещь, которую вы не упомянули -- это мокирование. Оно как правило занимает 90% времени написания теста и его отладки. А самое смешное, что в подавляющем большинстве случаев поведение мокированного кода -- это поведение сферического коня в вакууме, которое слабо соотносится с реальными кейсами. Особенно все, что касается стейта и базы данных. Поэтому народ сейчас все более склонен поднимать в контейнере реальную базу с тестовым набором данных, чтобы тестировать все как есть. А юниты все чаще заменяются "сценарными" тестами, которые тестируют именно бизнес спецификацию, а не внутренний дизайн.
Совершенно верно, и это проблема Angular и других фреймворков, которые местами противоречат вашему тезису о тестируемости кода, вынужная вас строго следовать исключительно предусмотренным паттернам.
Это по-вашему улучшение? Вы нагрузили сервис доступа к данным инородной логикой обработки и визуализации ошибки, закамуфлировав ее ввиде "пустого" результата для компонента.
Тесты -- это мусор в проекте, необходимый лишь для повышения качества service delivery, и требуют значительных затрат на написание и поддержку. Чем больше глупых тестов в проекте с многократным покрытием одних и тех же фрагментов, тем сложнее становится выкатывание новых фич. Поэтому держать нужно лишь необходимый минимум.
Тесты -- это тоже код, поэтому они также могут содержать баги. Кто же тестирует тесты? Основной код? Круговая порука получается.
Однозначно. Продюсер льет в topic строго последовательно, используя одно соединение. Ack подтверждения служат для гарантии доставки при выходе из строя основной partition, а не для упорядочения. Все остальное фантазии автора.