За что отвечает команда git merge? Загрязняет ветку мерж комитами ...
Как-то слишком категорично. Если вы сторонник ребейза, подскажите как правильно вести разработку, когда в команде разработчики пилят отдельные фичи (порой пересекающиеся), а релиз собирается под конец месяца из набора готовых фичей, причем релиз вполне может и пересобираться по желанию заказчика?
Не понимаю подобных подборок – здесь большая часть ссылок ведет на чисто ознакомительные статьи о том, что такое безопасность, ее задачи и цели, или на статьи с какими-то очень базовыми техниками этичного хакинга, а остальная часть ссылок, потенциально полезная, ведет на платные (!) курсы, бесплатные там только нарезка программы курсов.
По сути вы правы. Свое пожелание я неверно возвел в форму долженствования.
есть шанс на полезные и конструктивные дискуссии
Хотелось бы в это верить, но как показывает опыт (не только мой) это почти нереально. Стоит выразить сомнение или замечания – и карма идет в минуса. Это касается любых точек зрения.
Считаю, что хабр и ит-сообщество в целом должно быть вне политики, пропаганды и вбросов, и должно оперировать фактами и логикой.
оппонент прокачал наглость, силу и возможность говорить мне в лицо, что 2+2=87%
Видимо тут отсылка к итогам выборов и вы выражаете явное сомнение в достоверности результатов. Вполне может быть, что на вашем избирательном участке или даже всех зарубежных 288 участках за ВВП проголосовали 0%. На итоговую цифру это может вообще никак не повлиять, потому что выборка не репрезентативная. Распределение поддержки кандидатов сильно зависит от территории, возрастной группы, образования, рода деятельности, много от чего. Потому, чтобы выражать "сомнения", подкрепленные фактами, нужно собрать и проанализировать данные с достаточного количества избирательных участков по всей стране, а иначе это пустословие.
Безусловно все зависит от задач, но проекты на OSGI (в частности Apache Karaf) – это для неповоротливых монолитов, которые не перезапускаются месяцами, когда для деплоя мы подключаемся к консоли по ssh и выгружаем / загружаем модули вручную, когда перенос данных со стенда на стенд – это испытания и боль, когда отладка – это бессонные ночи. В современном мире с ci/cd, с kubernetes и микросервисами использовать Karaf – это боль. Говорю по собственному опыту. Но как упомянул все зависит от проекта, интересно узнать, что вас сподвигло на использование этого подхода?
Думаю, намного эффективней было бы построить опреснители и качать воду в пустыню, создавая искусственные оазисы, создавая огромные площади под выращивание тех же персиков и манго. Это более экологично чем бездыханная стекляшка, плюс новая статья в экспорте страны. Конечно, нам тут легко рассуждать на диване, но высотка в полкилометра и длиной 100км выглядит немного бредово.
Вот вы говорите, что ранее западные фирмы платили в Мск 10к$ и было хорошо, а сейчас такой уровень ЗП не найти. Ну да, возможно. Но с какой стати факт того, что кто-то платит 10к$, должно влиять на предложения от других компаний? Если есть желание получать высокую ЗП - ищите заказчика и релоцируйтесь к нему, не вижу проблемы.
Вот вы в комментариях говорите, что есть дефицит квалифицированных "малооплачиваемых" кадров. А я по своему опыту скажу, что с засильем всяких онлайн школ и курсов есть просто дефицит квалифицированных кадров. Куча людей после таких курсов льется на рынок и просят обещанные им инфоцыганами 2к$. Конечно, в этой толпе есть неограненные бриллианты, но их единицы, в большинстве случаев это просто болванчики.
С одной стороны – красиво оформленные анимации и примеры кода для формирования распределений у себя на коленке. С другой стороны – а в чем физический смысл этих распределений? Хотя бы пару примеров из жизни, подходы как увидеть такое распределение в прикладной задаче? Для кого в итоге эта статья написана? Для того, кто в теме и кто знает тервер, эта статья будет ни о чем. А для того, кто не знает тервер, от этих красивых анимаций и сухого кода понятней не станет, и придется искать информацию в интернете.
Это не просто сравнение ради сравнения, это просто бред какой-то.Типа возьмем рандомные фреймворки, запустим на машинках в каком-то облаке и посмотрим, что из этого выйдет. Сказать, что тут много нюансов - ничего не сказать: – throughput / latency сильно зависят от конкурентности запросов, – приложения на jit яп сильно зависят от прогрева, выделенных ресурсов, настроек сборки мусора, – все приложения зависят от архитектуры, те же java/c# jit компиляторы не так чтобы оптимизированы под arm-ы, их десятками лет полировали под x86, – все зависят от настроек системы, настроек сети, и в целом от расположения машин в сети датацентра.
В подобных статьях, напичканных сотней узкоспециализированных аббревиатур, просто обязан был глоссарий. Soc - System on Chip? IoC - Inversion of control? Что это, для кого вообще это статья?
А при больших нагрузках ему придётся думать над каждым запросом. Придётся по 10 раз их переписывать, чтобы попадать под влияние того или иного индекса.
Как разработчик (потребитель) вы пишете то, что вам нужно, какие выбрать данные и по каким условиям. А то насколько эффективна будет эта выборка - это вопрос к тем, кто ответственен к проектирование бд (aka dba), ну и к работе бд в целом (оптимизатор, кеши, диски).
Но если вы совмещаете в себе обе роли - потребителя данных и проектировщика - тогда да, нужно хорошо разбираться в сути вопроса.
К слову о filtered, cpu на самом деле не такой затратный как чтение блоков данных с диска или contention с буферным кешем. Потому все "зависит от".
Безусловно все зависит от принятого в команде flow, но обычно любые изменения в коде делаются в отдельных ветках, чтобы пройти кодревью и аппрув от команды. Ситуация, когда мы одновременно работаем в 2 ветках, скорее редкость, чем правило. Но даже в такой ситуации нет сложности сделать коммит изменений, переключиться в новую ветку и вести там работу. В принципе worktree аналогичен тому, чтобы самому сделать чекаут проекта в 2 разных каталога и работать "параллельно".
Почему микросервисы помогут вам ускорить поставку бизнес-ценности.
Слишком громкое заявление. Микросервисы – это не серебряная пуля, и в общем случае под каждую задачу нужен свой подход, своя архитектура.
создать десятки копий вашего приложения ... что даст прирост производительности на количество запущенных копий
Слишком громкое и неверное заявление. Ваш МС не изолирован ведь от других частей системы (а иначе это не часть системы) и при масштабировании одной части системы вы будете упираться в производительность другой части (закон Амдала). Например, упретесь в производительность БД и придется думать как оптимизировать работу с ней: разделение чтения и записи, попытка ввода слоя кеша, проблема с инвалидацией кеша и т.д. т.п. Решение одной проблемы будет плодить другие и так далее по кругу.
Дешёвое масштабирование и эффективный расход ресурсов
Тоже слишком громкое заявление. Да, если вы арендуете ресурсы в облаке, то вам проще управлять ресурсами и мыслить абстракциями request cpu / ram у pod'ов. Но дешево и эффективно ли это? – вопрос открытый, потому что все скрыто от вас, а цена за оверхед k8s просто включена в стоимость ресурсов. Если компания большая и имеет свой ДЦ, то ей дешевле управлять ресурсами через менеджеры ВМ.
Ко всему прочему не все так радужно с облаками, stateful set в k8s это просто костыль и постоянная боль с отваливающимися volume'ами. Т.е. опять же, решение одних проблем (простота доставки) порождает другие проблемы (ненадежность сетевых хранилищ).
К чему это я все? Кроме очевидных преимуществ МСА стоит подсвечивать и их недостатки, которые нужно учитывать. Плюс не хватает примеров, как стоит и как не стоит дробить системы, чтобы вместо МСА не получить распределенный монолит.
CSV это просто последовательность символов, которые разделены запятой или любым другим одиночным символом
Позвольте не согласиться. Как уже отметили другие, в формате CSV есть особые правила для обработки многострочных значений и значений, содержащих спецсимволы (в том числе и сам разделитель), такие значения оборачиваются в кавычки. Наивные парсеры не учитывают такие спец. значения.
Потом, любой URL это, в сущности, та же самая пресловутая CSV строчка
Опять же, не все так просто https://en.wikipedia.org/wiki/Uniform_Resource_Identifier и в общем случае идентификатор ресурса зависит от схемы, имеет в себе компоненты (scheme, userinfo, host, port, path, query, fragment), и разделителями компонент являются разные группы символов.
К чему это я? Если есть возможность использовать готовую отлаженную библиотеку, то лучше использовать ее, нежели изобретать еще один велосипед на квадратных колесах.
Без обид, но ТС стоило более серьезно подойти к делу. Листинги кода не соответствуют заявленному языку. На первом листинге какой-то математический формализм, на остальных язык ассемблера.
Как-то слишком категорично. Если вы сторонник ребейза, подскажите как правильно вести разработку, когда в команде разработчики пилят отдельные фичи (порой пересекающиеся), а релиз собирается под конец месяца из набора готовых фичей, причем релиз вполне может и пересобираться по желанию заказчика?
Не сойдется, в видео даже упоминания нет о cp/m и сделке ibm с ms.
Не понимаю подобных подборок – здесь большая часть ссылок ведет на чисто ознакомительные статьи о том, что такое безопасность, ее задачи и цели, или на статьи с какими-то очень базовыми техниками этичного хакинга, а остальная часть ссылок, потенциально полезная, ведет на платные (!) курсы, бесплатные там только нарезка программы курсов.
По сути вы правы. Свое пожелание я неверно возвел в форму долженствования.
Хотелось бы в это верить, но как показывает опыт (не только мой) это почти нереально. Стоит выразить сомнение или замечания – и карма идет в минуса. Это касается любых точек зрения.
Стоит дать дельный комментарий – и держите минус в карму.
Считаю, что хабр и ит-сообщество в целом должно быть вне политики, пропаганды и вбросов, и должно оперировать фактами и логикой.
Видимо тут отсылка к итогам выборов и вы выражаете явное сомнение в достоверности результатов. Вполне может быть, что на вашем избирательном участке или даже всех зарубежных 288 участках за ВВП проголосовали 0%. На итоговую цифру это может вообще никак не повлиять, потому что выборка не репрезентативная. Распределение поддержки кандидатов сильно зависит от территории, возрастной группы, образования, рода деятельности, много от чего. Потому, чтобы выражать "сомнения", подкрепленные фактами, нужно собрать и проанализировать данные с достаточного количества избирательных участков по всей стране, а иначе это пустословие.
Безусловно все зависит от задач, но проекты на OSGI (в частности Apache Karaf) – это для неповоротливых монолитов, которые не перезапускаются месяцами, когда для деплоя мы подключаемся к консоли по ssh и выгружаем / загружаем модули вручную, когда перенос данных со стенда на стенд – это испытания и боль, когда отладка – это бессонные ночи. В современном мире с ci/cd, с kubernetes и микросервисами использовать Karaf – это боль. Говорю по собственному опыту. Но как упомянул все зависит от проекта, интересно узнать, что вас сподвигло на использование этого подхода?
Думаю, намного эффективней было бы построить опреснители и качать воду в пустыню, создавая искусственные оазисы, создавая огромные площади под выращивание тех же персиков и манго. Это более экологично чем бездыханная стекляшка, плюс новая статья в экспорте страны. Конечно, нам тут легко рассуждать на диване, но высотка в полкилометра и длиной 100км выглядит немного бредово.
Извиняюсь за желчность в комментарии, наболело.
Вот вы говорите, что ранее западные фирмы платили в Мск 10к$ и было хорошо, а сейчас такой уровень ЗП не найти. Ну да, возможно. Но с какой стати факт того, что кто-то платит 10к$, должно влиять на предложения от других компаний? Если есть желание получать высокую ЗП - ищите заказчика и релоцируйтесь к нему, не вижу проблемы.
Вот вы в комментариях говорите, что есть дефицит квалифицированных "малооплачиваемых" кадров. А я по своему опыту скажу, что с засильем всяких онлайн школ и курсов есть просто дефицит квалифицированных кадров. Куча людей после таких курсов льется на рынок и просят обещанные им инфоцыганами 2к$. Конечно, в этой толпе есть неограненные бриллианты, но их единицы, в большинстве случаев это просто болванчики.
С одной стороны – красиво оформленные анимации и примеры кода для формирования распределений у себя на коленке. С другой стороны – а в чем физический смысл этих распределений? Хотя бы пару примеров из жизни, подходы как увидеть такое распределение в прикладной задаче? Для кого в итоге эта статья написана? Для того, кто в теме и кто знает тервер, эта статья будет ни о чем. А для того, кто не знает тервер, от этих красивых анимаций и сухого кода понятней не станет, и придется искать информацию в интернете.
Это не просто сравнение ради сравнения, это просто бред какой-то.Типа возьмем рандомные фреймворки, запустим на машинках в каком-то облаке и посмотрим, что из этого выйдет. Сказать, что тут много нюансов - ничего не сказать:
– throughput / latency сильно зависят от конкурентности запросов,
– приложения на jit яп сильно зависят от прогрева, выделенных ресурсов, настроек сборки мусора,
– все приложения зависят от архитектуры, те же java/c# jit компиляторы не так чтобы оптимизированы под arm-ы, их десятками лет полировали под x86,
– все зависят от настроек системы, настроек сети, и в целом от расположения машин в сети датацентра.
Как уже упоминали ранее, в более профессиональных бенчмарках результаты подобных plaintext тестов лежат рядом в пределах погрешности +-5% https://www.techempower.com/benchmarks/#hw=ph&test=plaintext§ion=data-r22
В подобных статьях, напичканных сотней узкоспециализированных аббревиатур, просто обязан был глоссарий. Soc - System on Chip? IoC - Inversion of control? Что это, для кого вообще это статья?
Как разработчик (потребитель) вы пишете то, что вам нужно, какие выбрать данные и по каким условиям. А то насколько эффективна будет эта выборка - это вопрос к тем, кто ответственен к проектирование бд (aka dba), ну и к работе бд в целом (оптимизатор, кеши, диски).
Но если вы совмещаете в себе обе роли - потребителя данных и проектировщика - тогда да, нужно хорошо разбираться в сути вопроса.
К слову о filtered, cpu на самом деле не такой затратный как чтение блоков данных с диска или contention с буферным кешем. Потому все "зависит от".
Безусловно все зависит от принятого в команде flow, но обычно любые изменения в коде делаются в отдельных ветках, чтобы пройти кодревью и аппрув от команды. Ситуация, когда мы одновременно работаем в 2 ветках, скорее редкость, чем правило. Но даже в такой ситуации нет сложности сделать коммит изменений, переключиться в новую ветку и вести там работу. В принципе worktree аналогичен тому, чтобы самому сделать чекаут проекта в 2 разных каталога и работать "параллельно".
Слишком громкое заявление. Микросервисы – это не серебряная пуля, и в общем случае под каждую задачу нужен свой подход, своя архитектура.
Слишком громкое и неверное заявление. Ваш МС не изолирован ведь от других частей системы (а иначе это не часть системы) и при масштабировании одной части системы вы будете упираться в производительность другой части (закон Амдала). Например, упретесь в производительность БД и придется думать как оптимизировать работу с ней: разделение чтения и записи, попытка ввода слоя кеша, проблема с инвалидацией кеша и т.д. т.п. Решение одной проблемы будет плодить другие и так далее по кругу.
Тоже слишком громкое заявление. Да, если вы арендуете ресурсы в облаке, то вам проще управлять ресурсами и мыслить абстракциями request cpu / ram у pod'ов. Но дешево и эффективно ли это? – вопрос открытый, потому что все скрыто от вас, а цена за оверхед k8s просто включена в стоимость ресурсов. Если компания большая и имеет свой ДЦ, то ей дешевле управлять ресурсами через менеджеры ВМ.
Ко всему прочему не все так радужно с облаками, stateful set в k8s это просто костыль и постоянная боль с отваливающимися volume'ами. Т.е. опять же, решение одних проблем (простота доставки) порождает другие проблемы (ненадежность сетевых хранилищ).
К чему это я все? Кроме очевидных преимуществ МСА стоит подсвечивать и их недостатки, которые нужно учитывать. Плюс не хватает примеров, как стоит и как не стоит дробить системы, чтобы вместо МСА не получить распределенный монолит.
Почти в 100% случаев SOAP используется поверх HTTP(s), или что вы имели в виду под http api?
прошу ссылки на литературу, где можно почитать об этом.. не встречал упоминания об иных типах-объединениях.
Позвольте не согласиться. Как уже отметили другие, в формате CSV есть особые правила для обработки многострочных значений и значений, содержащих спецсимволы (в том числе и сам разделитель), такие значения оборачиваются в кавычки. Наивные парсеры не учитывают такие спец. значения.
Опять же, не все так просто https://en.wikipedia.org/wiki/Uniform_Resource_Identifier и в общем случае идентификатор ресурса зависит от схемы, имеет в себе компоненты (scheme, userinfo, host, port, path, query, fragment), и разделителями компонент являются разные группы символов.
К чему это я? Если есть возможность использовать готовую отлаженную библиотеку, то лучше использовать ее, нежели изобретать еще один велосипед на квадратных колесах.
У некоторых авторов тип-сумма / тип-объединение – это одно и тоже. https://en.wikipedia.org/wiki/Tagged_union
Без обид, но ТС стоило более серьезно подойти к делу. Листинги кода не соответствуют заявленному языку. На первом листинге какой-то математический формализм, на остальных язык ассемблера.
Простой поиск в гугле дает нам ссылку на "спецификацию" языка: https://warwick.ac.uk/fac/sci/dcs/people/abhir_bhalerao/mark1_autocode_interpreter/mark1-report.pdf
А еще ссылки на примеры кода с интерпретатором: https://www.dcs.warwick.ac.uk/~abhir/mark1/