С технической стороны здесь ключевым аргументом служит баланс между надежностью решения (Reliability) и его стоимостью (TCO). Причина простая: у типичного железа uptime не может вечным - оно ломается, необходимы окна для сервисного обслуживания.
С гарантиями по availably > 99.9 вы неизбежно приходите либо к надёжным как космические корабли мейнфреймам, либо к распределенной архитектуре - в зависимости от допусков по отзывчивости.
Это не то, что вам нужно для типичного стартапа. Но в некоторых специфичных доменах (из области медицины, обработки платежей и т.п.) все уже зарегулировано и у вас нет выбора с самого начала.
Everything Should Be Made as Simple as Possible, But Not Simpler
Делайте всё как можно проще, но не слишком упрощайте.
Я согласен, что польза от микросервисов переоценена и в эту повестку было вложено много облачного маркетинга. Но если у вас паранойя это ещё не значит, что нужно их бояться.
Monolith-first может быть хорошей тактикой в определенных ситуациях. Например, если вы делаете с нуля и пока не вполне понимаете, что именно вам нужно. Или собираете PoC. Но если ключевые критерии уже известны, то нужно проектировать подходящее решение.
Вообще эти ребята из Linux придумали Git. Вариант с почтой позволяет работать децентрализованно и в основном в оффлайне. Вы не зависите ни от какого центрального ресурса. Достаточно утром скачать последние сообщения и потом можете разгребать в удобном темпе - хоть в самолёте, хоть на конференции, хоть под пальмой. При этом, вся история всех переписок за все время всегда у вас - точно так же как и склонированный код. Почта не ограничивает в формате переписки, позволяя с одинаковым успехом использовать как для патчей, так и для дискуссий или решения каких-то вопросов.
Основной формат изменений - здесь патч сеты. Поскольку такие наборы патчей не ограничены рамками пул реквестов, мейнтейнеры могут легко их комбинировать из разных стримов, апрувать и вливать частями как им покажется удобнее.
GitHub неплох для небольших и средних проектов. Дальше получается месиво из десятков тысяч issue и многих сотен пул реквестов. Большая часть из этого скорее вопросы. Приходится изобретать искусственные церемонии, автоматику, которые периодически устраивают чистку и автоматически все это закрывают. В почте этого по просту не нужно.
Поскольку пул реквесты основаны на ветках, то влить лишь часть изменений вы не можете (не пыпадая из формата, который предлагает либо все целиком принять, либо отправить ещё ждать). В итоге образуются фича бранчи, мержить которые то ещё удовольствие. Если нужно изменить комит в середине, получаете целую научную проблему rebase vs merge.
Оценка безопасности цепочки поставок (Supply Chain Security) — важный аспект в обеспечении безопасности ПО.
SCA получает доступ ко всему исходному коду проектов компании. Это чувствительная информация, как вы описали. Поэтому возникает вопрос: а кто оценивает оценщика и его продукты, и какие новые риски появляются с его стороны?
Спасибо, вы абсолютно правы. Писал с телефона, отвлекаясь и получилось крайне неряшливо. Я когда прочитал, то заметил ещё ошибки, начиная с compliment/complement.
Вообще мысль была в том, что "дополнение" это довольно фундаментальное понятие, которое можно встретить и в теории множеств, и в логике, и в алгебре. Но у меня в голове картинка стала складываться лишь когда начал изучать математику на английском. На русском ассоциации, как в случае с "дополнительным кодом", ведут куда-то ни туда.
offtopic // Екатерина Яшникова это талантище. Познакомился с её творчеством несколько лет тому назад. Редкое сочетание поэзии, музыки и манеры в одном исполнителе.
Переводчику можно поставить памятник за корректное использование в статье классической русскоязычной терминологии. Но кто ее такой выдумал нужно казнить.
На мой взгляд, здесь тот случай когда русскоязычное научное сообщество с переводами перемудрило, усложнив понимание.
В английском достаточно знать слово compliment и иметь немного воображения.
One's complement (обратный код)
Two's complement (дополнительный код).
Complement ("дополнение", оно же в частных случаях "отрицание" или "инвертирование"). Грубо говоря если у вас есть часть предмета, то compliment это остальная часть, которой нужно дополнить вашу, чтобы получить целое. Например, есть множество допустимых значений {0, 1}. У вас есть {0}, соответственно не хватает {1} - это и есть дополнение.
В случае обратного кода (one's complement), отрицательное значение дополняет положительное до всех единиц. Технически мы просто инвертируем (sic это тоже дополнение) биты:
Представление симметрично. Но +0 и -0 имеют разные значения, а прибавляя (-0) мы получаем переполнение.
Дополнительный код (two's complement) - термин похож на кальку с английского, где потерялось упоминание двойки. Здесь two (2) это основание системы счисления. Если у нас двоичная система счисления и есть N разрядов, то представление отрицательного значения должно дополнять представление положительного до 2^N. Например, для трёх бит 2^3 это (8) 1000. Следовательно:
Как видно в таком представлении нет проблемы с нулем. Правда, отрицательных на одно больше, чем положительных, а верхний предел не укладывается в заданное число бит.
easy-medium, которые в спокойной обстановке программист способен решить за 5-7 минут, но с учетом стресса и доски на собесе даётся 20-30 минут.
Я проваливал на собеседованиях даже простые задачи. Здесь как в вузе. Если тема находится прямо сейчас в голове, то задача решается на рефлексах. Но через год уже нужно напрягать голову, что вспомнить. Через 20 лет это не немного грустный челенж. При этом вечером, когда есть возможность войти в поток и спокойно подумать, все решается действительно легко и без подсказок из гугла.
Алгоритмические проблемы хорошо отлавливают регрессии и перформанс тесты уже на самых ранних стадиях. У меня не было на практике такого, чтобы прод лег именно из-за алгоритмов.
Обычно перформанс деградирует медленно, по мере увеличения кодовой базы, наростания слоев абстракций и каких-то костылей. У вас просто нет какой-то понятной точки, которую можно переписать с O(n^2) на O(n log n). Для того, чтобы с этим бороться нужно в первую очередь хорошо знать код своего проекта. При оптимизации вы оперируете не функциями, а компонентами или даже микро-сервисами.
На моей практике к фатальным инцидентам в продакшен чаще приводят ошибки в конфигурации - когда ошиблись буквально в одном символе или перепутали параметр под конкретный энв. Причем на патч для конфига в пару строчек смотели в общей сложности человек 30, начиная с аналитика в момент поставки задачи, разработки, тестирования, релиз менеджеров и заканчивая опсом, который это накатывал. Но ошибку обнаруживает лишь эксплуатация.
Иногда пролетают ошибки интеграции, когда источник данных не держит по перформансу или есть проблемы с доступностью. Но это решается на уровне архитектуры, а не алгоритмов.
Почему бы не сделать пайплайн на домашку? Если не проходит линтер или селениум тест на валидность страницы, то даже не тратить время
Пайплайны это не софт, который можно купить и за 5 минут установить. Это разработка, для которой нужны специалисты с профильным опытом, время и ресурсы - иначе инвестиции в автоматизацию ни когда не окупятся. Понятно почему они есть у техногигантов типа Яндекса и их нет у многих других.
я понимал, что такая рекламная установка существует, но не ожидал, что кто-то всерьёз в это верит.
На старте у людей просто нет необходимых знаний, чтобы понять реальные затраты и оценить свои возможности. Особенно, когда помимо взаимодействия с рекламой в реальном опыте ни чего нет.
Кстати, вот это типичный синдром поколения айфонов. Где папки и файлы как таковые отсутствуют. Зато это поколение умеет ловко называть файлы и искать их, организуя работу
Прямое манипулирование объектами - без использования промежуточных концепций типа файлов и папок - это один из ключевых элементов в идеологии всех интерфейсов Apple уже лет 30. Правда в последние годы они все же прогнулись под привычки "виндузятников", так что современное поколение айфонов уже испорчено файлами.
Всё описанное автором совершенно рядовые и базовые ситуации для любого педагога, ничего страшного и атипичного в них нет, драмы тоже никакой
Не знаю за что вам наставили минусов, но это правда. Преподаватель для ученика это не помощник, это препятствие на пути к диплому. Что-то типа спортивного снаряда - штанги, груши или там - коня. Его задача создать ученику challenge, а задача ученика попытаться его преодолеть. Именно опыт преодолевания потом кристаллизуется в знания.
Понятно, что процесс эмоциональный и в ход могут идти совершенно разные приемы. Причем с обоих сторон. В наше время доходило до рукоприкладства.
На самом деле, побыть в роли преподавателя это классный опыт. Понятно, что без шишек не обойтись (см. первый абзац). Зато потом потом начинаешь лучше понимать своих учителей, видеть и ценить истинный профессионализм.
Или в данном случае такой подход оправдан и даёт свои плоды? Если да, то почему это работает?
Есть бизнес, который зарабатывает на первой продаже, а есть кто зарабатывает на повторных. Репутация это затраты и она нужна вторым. А первые во многих случаях могут прожить без нее. Подумайте, сколько человек покупают курсы повторно, и все станет ясно.
Например, если на странице разработчика присутствует баннер, то следует обратить более пристальное внимание на сам пакет.
Я считаю, что добавлять закладки в софт это неприемлемо. Но ставить в один ряд ребят просто за то, что они обозначили свою позицию, это слишком неоднозначно для статьи на публичном ресурсе. Больше похоже на пропаганду. В плане конкретно безопасности такой совет вообще ни о чем - подавляющая масса всякого malware идёт безо всяких банеров.
Но это собеседование, которое больше направленно на алгоритмы, чем не проработку ТЗ. Там прямо в условиях задачи очень технически прописаны условия, что есть такие-то файлы, структура такая-то, надо решить такую-то задачу, и только её.
Автор про это написал, что его в первую очередь интересует как раз диалог, а не код:
The conversation is much more important to me than the actual lines of code my candidate writes on the whiteboard. What tradeoffs exist? How do you balance between them?
...
Great candidates must ask clarifying questions before jumping into coding. I’m hoping to see some intuition from my candidates as I’ve actually expressed the problem in an ambiguous way. Did I mean 2 unique pages per day or overall?
Я тут не спорю с тем, плох ваш подход или хорош. Бывают ситуации, когда именно так и надо поступать. Но в данном случае это ваше допущение, а их нужно всегда проверять.
Зато в олимпиадах, со стороны организаторов, все наоборот. Вы все организуете, придумываете интересные задачи, ищете участников по разным уголкам света, устраиваете мероприятие, и ещё делаете массу разных вещей. А все призы достаются кому-то другому. =)
Если серьезно, я согласен, что вопрос комплексный и его можно рассматривать с разных сторон. Моя позиция здесь - свою работу нужно делать максимально качественно. А если не устраивают компенсации, то менять работодателя.
Развивая идею, чтобы определить асимптотику лучше не гадать, а делать эксперименты и собирать метрики в отчёты с красивыми графиками - как это принято у data science вообще или нагрузочных тестировщиков в частности.
Понятия алгоритма и алгоритмической сложности это абстракции. Для анализа работы реальных комплексных приложений такой подход не сильно практичен. За каждым интерфейсом может скрываться что угодно: от гениальных оптимизаций до досадных ляпов - причем с флуктуациями от версии к версии.
С технической стороны здесь ключевым аргументом служит баланс между надежностью решения (Reliability) и его стоимостью (TCO). Причина простая: у типичного железа uptime не может вечным - оно ломается, необходимы окна для сервисного обслуживания.
С гарантиями по availably > 99.9 вы неизбежно приходите либо к надёжным как космические корабли мейнфреймам, либо к распределенной архитектуре - в зависимости от допусков по отзывчивости.
Это не то, что вам нужно для типичного стартапа. Но в некоторых специфичных доменах (из области медицины, обработки платежей и т.п.) все уже зарегулировано и у вас нет выбора с самого начала.
Я согласен, что польза от микросервисов переоценена и в эту повестку было вложено много облачного маркетинга. Но если у вас паранойя это ещё не значит, что нужно их бояться.
Monolith-first может быть хорошей тактикой в определенных ситуациях. Например, если вы делаете с нуля и пока не вполне понимаете, что именно вам нужно. Или собираете PoC. Но если ключевые критерии уже известны, то нужно проектировать подходящее решение.
Вообще эти ребята из Linux придумали Git. Вариант с почтой позволяет работать децентрализованно и в основном в оффлайне. Вы не зависите ни от какого центрального ресурса. Достаточно утром скачать последние сообщения и потом можете разгребать в удобном темпе - хоть в самолёте, хоть на конференции, хоть под пальмой. При этом, вся история всех переписок за все время всегда у вас - точно так же как и склонированный код. Почта не ограничивает в формате переписки, позволяя с одинаковым успехом использовать как для патчей, так и для дискуссий или решения каких-то вопросов.
Основной формат изменений - здесь патч сеты. Поскольку такие наборы патчей не ограничены рамками пул реквестов, мейнтейнеры могут легко их комбинировать из разных стримов, апрувать и вливать частями как им покажется удобнее.
GitHub неплох для небольших и средних проектов. Дальше получается месиво из десятков тысяч issue и многих сотен пул реквестов. Большая часть из этого скорее вопросы. Приходится изобретать искусственные церемонии, автоматику, которые периодически устраивают чистку и автоматически все это закрывают. В почте этого по просту не нужно.
Поскольку пул реквесты основаны на ветках, то влить лишь часть изменений вы не можете (не пыпадая из формата, который предлагает либо все целиком принять, либо отправить ещё ждать). В итоге образуются фича бранчи, мержить которые то ещё удовольствие. Если нужно изменить комит в середине, получаете целую научную проблему rebase vs merge.
Интерфейс, в первую очередь отвечает на насущные вопросы пользователя. Предпочтения это вкусовщина, когда вопрос уже отвечен.
Если вопрос "в какое время?" - выводим абсолютное.
Если вопрос: "сколько времени прошло? / через сколько это будет?" - выводим относительное.
Понять какие у юзера вопросы это вообще продуктовая тема.
Если вопросы могут меняться от сценарию к сценарию в одних и тех же экранах - вызываем пояснительную бригаду UI/UX. Им за это деньги платят.
SCA получает доступ ко всему исходному коду проектов компании. Это чувствительная информация, как вы описали. Поэтому возникает вопрос: а кто оценивает оценщика и его продукты, и какие новые риски появляются с его стороны?
Хотел найти у вас на сайте SLA, но в итоге попал на страницу с сертификатами, сроки которых давно закончились https://rt-solar.ru/about_company/information/licenses/. Можете прокомментировать?
Спасибо, вы абсолютно правы. Писал с телефона, отвлекаясь и получилось крайне неряшливо. Я когда прочитал, то заметил ещё ошибки, начиная с compliment/complement.
Вообще мысль была в том, что "дополнение" это довольно фундаментальное понятие, которое можно встретить и в теории множеств, и в логике, и в алгебре. Но у меня в голове картинка стала складываться лишь когда начал изучать математику на английском. На русском ассоциации, как в случае с "дополнительным кодом", ведут куда-то ни туда.
offtopic // Екатерина Яшникова это талантище. Познакомился с её творчеством несколько лет тому назад. Редкое сочетание поэзии, музыки и манеры в одном исполнителе.
Ждём рождественскую распродажу устройств с банковскими тайнами на Авито? А если серьезно, интересно как они потом поступают с изъятым.
Переводчику можно поставить памятник за корректное использование в статье классической русскоязычной терминологии. Но кто ее такой выдумал нужно казнить.
На мой взгляд, здесь тот случай когда русскоязычное научное сообщество с переводами перемудрило, усложнив понимание.
В английском достаточно знать слово compliment и иметь немного воображения.
Complement ("дополнение", оно же в частных случаях "отрицание" или "инвертирование"). Грубо говоря если у вас есть часть предмета, то compliment это остальная часть, которой нужно дополнить вашу, чтобы получить целое. Например, есть множество допустимых значений {0, 1}. У вас есть {0}, соответственно не хватает {1} - это и есть дополнение.
В случае обратного кода (one's complement), отрицательное значение дополняет положительное до всех единиц. Технически мы просто инвертируем (sic это тоже дополнение) биты:
То есть: 000 + 111 = 001 + 110 = 010 + 101 = 011 + 100 == 111
Представление симметрично. Но +0 и -0 имеют разные значения, а прибавляя (-0) мы получаем переполнение.
Дополнительный код (two's complement) - термин похож на кальку с английского, где потерялось упоминание двойки. Здесь two (2) это основание системы счисления. Если у нас двоичная система счисления и есть N разрядов, то представление отрицательного значения должно дополнять представление положительного до 2^N. Например, для трёх бит 2^3 это (8) 1000. Следовательно:
Для проверки: 001 + 111 = 010 + 110 = 011 + 101 == 1000.
Как видно в таком представлении нет проблемы с нулем. Правда, отрицательных на одно больше, чем положительных, а верхний предел не укладывается в заданное число бит.
Я проваливал на собеседованиях даже простые задачи. Здесь как в вузе. Если тема находится прямо сейчас в голове, то задача решается на рефлексах. Но через год уже нужно напрягать голову, что вспомнить. Через 20 лет это не немного грустный челенж. При этом вечером, когда есть возможность войти в поток и спокойно подумать, все решается действительно легко и без подсказок из гугла.
Алгоритмические проблемы хорошо отлавливают регрессии и перформанс тесты уже на самых ранних стадиях. У меня не было на практике такого, чтобы прод лег именно из-за алгоритмов.
Обычно перформанс деградирует медленно, по мере увеличения кодовой базы, наростания слоев абстракций и каких-то костылей. У вас просто нет какой-то понятной точки, которую можно переписать с O(n^2) на O(n log n). Для того, чтобы с этим бороться нужно в первую очередь хорошо знать код своего проекта. При оптимизации вы оперируете не функциями, а компонентами или даже микро-сервисами.
На моей практике к фатальным инцидентам в продакшен чаще приводят ошибки в конфигурации - когда ошиблись буквально в одном символе или перепутали параметр под конкретный энв. Причем на патч для конфига в пару строчек смотели в общей сложности человек 30, начиная с аналитика в момент поставки задачи, разработки, тестирования, релиз менеджеров и заканчивая опсом, который это накатывал. Но ошибку обнаруживает лишь эксплуатация.
Иногда пролетают ошибки интеграции, когда источник данных не держит по перформансу или есть проблемы с доступностью. Но это решается на уровне архитектуры, а не алгоритмов.
Пайплайны это не софт, который можно купить и за 5 минут установить. Это разработка, для которой нужны специалисты с профильным опытом, время и ресурсы - иначе инвестиции в автоматизацию ни когда не окупятся. Понятно почему они есть у техногигантов типа Яндекса и их нет у многих других.
На старте у людей просто нет необходимых знаний, чтобы понять реальные затраты и оценить свои возможности. Особенно, когда помимо взаимодействия с рекламой в реальном опыте ни чего нет.
Прямое манипулирование объектами - без использования промежуточных концепций типа файлов и папок - это один из ключевых элементов в идеологии всех интерфейсов Apple уже лет 30. Правда в последние годы они все же прогнулись под привычки "виндузятников", так что современное поколение айфонов уже испорчено файлами.
Не знаю за что вам наставили минусов, но это правда. Преподаватель для ученика это не помощник, это препятствие на пути к диплому. Что-то типа спортивного снаряда - штанги, груши или там - коня. Его задача создать ученику challenge, а задача ученика попытаться его преодолеть. Именно опыт преодолевания потом кристаллизуется в знания.
Понятно, что процесс эмоциональный и в ход могут идти совершенно разные приемы. Причем с обоих сторон. В наше время доходило до рукоприкладства.
На самом деле, побыть в роли преподавателя это классный опыт. Понятно, что без шишек не обойтись (см. первый абзац). Зато потом потом начинаешь лучше понимать своих учителей, видеть и ценить истинный профессионализм.
Есть бизнес, который зарабатывает на первой продаже, а есть кто зарабатывает на повторных. Репутация это затраты и она нужна вторым. А первые во многих случаях могут прожить без нее. Подумайте, сколько человек покупают курсы повторно, и все станет ясно.
Я считаю, что добавлять закладки в софт это неприемлемо. Но ставить в один ряд ребят просто за то, что они обозначили свою позицию, это слишком неоднозначно для статьи на публичном ресурсе. Больше похоже на пропаганду. В плане конкретно безопасности такой совет вообще ни о чем - подавляющая масса всякого malware идёт безо всяких банеров.
Автор про это написал, что его в первую очередь интересует как раз диалог, а не код:
Я тут не спорю с тем, плох ваш подход или хорош. Бывают ситуации, когда именно так и надо поступать. Но в данном случае это ваше допущение, а их нужно всегда проверять.
Зато в олимпиадах, со стороны организаторов, все наоборот. Вы все организуете, придумываете интересные задачи, ищете участников по разным уголкам света, устраиваете мероприятие, и ещё делаете массу разных вещей. А все призы достаются кому-то другому. =)
Если серьезно, я согласен, что вопрос комплексный и его можно рассматривать с разных сторон. Моя позиция здесь - свою работу нужно делать максимально качественно. А если не устраивают компенсации, то менять работодателя.
Развивая идею, чтобы определить асимптотику лучше не гадать, а делать эксперименты и собирать метрики в отчёты с красивыми графиками - как это принято у data science вообще или нагрузочных тестировщиков в частности.
Понятия алгоритма и алгоритмической сложности это абстракции. Для анализа работы реальных комплексных приложений такой подход не сильно практичен. За каждым интерфейсом может скрываться что угодно: от гениальных оптимизаций до досадных ляпов - причем с флуктуациями от версии к версии.