Гоняют по алгоритмам и структурам данных по той причине, что в таких компаниях инженеры сталкиваются с проблемами, которые не решаются через stackoverflow.com. Это понимание приходит в тот момент, когда видишь, что за последний год многократно приходилось использовать эти знания. В отличие от 15 предыдущих.
А вот системный дизайн очень субъективный. За 30-40 минут нужно не только нарисовать квадратики в ужасном редакторе, но и формализовать максимально нечёткие требования, придумать какую-то бизнес или UI/ux концепцию, а потом ещё и углубиться в ненужные детали. И по пути все время думать, кто же этот человек, который сразу хочет дизайн на млрд запросов. А ещё понимать абсурдность ситуации, что все происходящее практически никак не ложится на архитектурные стандарты.
Хотя это не имеет никакого значения в данном контексте, тк в любом случае модерирую не я, а кто-то. Но и тем не менее, толпа/боты поддаются панике и хайпу, ей что-то кажется, она бежит жаловаться, а фб любит деньги и следует запросам толпы. В итоге и получается, что фб может скрывать мнения под натиском толпы.
И мне интересно, можно ли создать сеть, которая by design будет свободна от такого изъяна, но и в то же время не будет помойкой
Я не считаю, что по факту мы живём в таком мире. Поэтому для меня вполне закономерным является вопрос, как уберечься от расправы толпы и форсирования единого мнения.
Один из примеров: модераторы могут поддерживать некие фильтры (как можно больше градаций), но только пользователь может выбирать какие фильтры он может применять для своей "ленты". Например, в политике я хочу читать все, а в новостях только проверяемые факты без мнения и тд.
Только я являюсь модератором контента, который потребляю и никакой модератор не может запретить мне читать, что я хочу.
Этого нет в фб и твиттере, к примеру. Там есть власть толпы и формирование политики партии/компании.
Одним из примеров, который интересно было рассмотреть, и который не лежит в технической плоскости - система жалоб.
По разным причинам несколько человек могут по-разному рассматривать ту или иную информацию. Одни видеть в ней истину, другие - ложь. Для одних это нарушение прав, для других - ок.
Таким образом модератору будут поступать жалобы на контент, который допустим для одной подгруппы и недопустим для другой (здесь речь не идёт о контенте, который можно однозначно оценить как запрещённый).
В итоге получается, что модератор может единолично закрыть доступ к контенту, который допустим.
На более глобальном уровне это выглядит так же, как и с фб - человеческий фактор влияет на доступность информации, которую я как пользователь получаю
Мне кажется, что следующий виток развития соц взаимодействия лежит не столько в технических характеристиках и фичах, сколько в области философии, т.е. концептуально ином подходе.
Самый простой пример - свобода слова. Кто и что может выкладывать в публичную плоскость, кто и как может контролировать (и может ли) контент и других участников. А если только участники могут управлять своим контентом без модерации, что делать с детским порно и прочим незаконным контентом?
И много подобных вопросов из области философии, этики и прочих слов.
ТС, чем отличается эта сеть от других? Если она станет глобальной, можно ли будет отключать неугодных?
Но вообще я ни в коем случае не пропагандирую никакой из подходов. Это инструменты. И нужно знать их как сильные так и слабые стороны, чтобы выбрать правильный. Вполне описанные проблемы могут быть несущественными на фоне преимуществ, или вовсе неактуальными для конкретного проекта.
п.с. По поводу ручками создавать.
Пришлось бы, но не приходится, потому что существуют инструменты.
вы правильно начали писать про графы зависимостей. но вот я не увидел продолжения.
да, зависимости — это граф (DAG), как вы и написали
да, число нод увеличивается с глубиной (в большинстве проектов)
а вот чего я не увидел:
Марк Симан в своих статьях(1) сам же и пишет, что идеальный SOLID это набор функций, т.к. буквы S и I приводят нас в идеальном мире к "миллиону" интерфейсов одного метода, т.е. "миллиону" функций. естественно, с увеличением количества связей между ними посредством абстракций (или функций).
поэтому на вашем графе должно быть вот совсем больше стрелочек. т.е. при количестве абстракций N, число связей между ними будет M, где M > N (вполне может и 2N). При этом, если вы говорите о чистоте функций и прочих радостях, наверное, вам морально сложно будет вызывать глобальные функции отовсюду в пользу функций высшего порядка.
как следствие следствией:
DI требует описать только N абстракций, и бибилиотека сама создаст все необходимые связи в момент разрешения зависимости. в вашем примере необходимо все зависимости прописывать руками, что практически всегда будет сложнее, ведь M > N (и в этот момент откройте какой-то проект, над которым работает 30-50+ человек хотя бы год и посмотрите, насколько или во сколько именно M > N с учетом всех логгеров, конфигов и т.д.). далее это приводит к усложнению поддержки и расширению кодовой базы.
статья выглядит слишком агитационной. в ней не описаны плюсы, а микросервисная архитектура выставлена такой себе панацеей. одна из проблем в том, что на кого-то агитация подействует и микросервис родится там, где ему не место, или как минимум не в процессе эволюции системы.
хотелось бы услышать и про минусы. сказать, что требуется DevOps/Agile team, или остановится на юнит и интеграционных тестах — это как упустить половину.
Интересно было бы услышать, как у вас обеспечивается качество и своевременность поставок сервиса. Как происходит разработка, какие виды тестов выполняются? хотя бы как вы обеспечиваете тестирование (и какое) нового функционала? Делаете ли вы это до того, как он попал в общую ветку и т.д. И как результат насколько предсказуема разработка?
В Киеве яндекс карты у убера. При чем по заявлению водителей они лучше гугловских. И все правки очень оперативно вносятся.
Но оно сырое очень. А что значит "будет"? Я по северной Европе поездил и отличий вообще не заметил. Опции те же. Израиль — то же самое
вас ведь никто не заставляет пользоваться сервисом, или в убере выбирать машины классом повыше.
а вот как вы в убере вызываете микроавтобус, чтобы уехать 5+? Что делаете, когда «машин поблизости нет»? Или когда 30-50% адресов некорректно распознается. или когда водитель везет неоптимальным маршрутом и ловит все пробки (а потом пиши-строчи, чтобы проанализировали и вернули деньги). а уклон все эти проблемы решил «из-коробки».
в убере забит адрес «Дом» — центр города. После 3-5 обращений не осилили пофиксить баг, из-за которого не сохраняется номер дома, а машина приезжать хз куда.
но для каждой задачи подходит свой инструмент. если нужно быстро и сейчас любой ценой (и если рядом есть машина) — здесь убер выигрывает. если ездишь по крупным город по разным странам — выигрывает, т.к. пользуешься той же картой и тем же приложением (и можно карты на страны назначать). и быдлить водитель вряд ли будет, т.к. кошельком реально отвечает.
свои плюсы и минусы в общем.
Гоняют по алгоритмам и структурам данных по той причине, что в таких компаниях инженеры сталкиваются с проблемами, которые не решаются через stackoverflow.com. Это понимание приходит в тот момент, когда видишь, что за последний год многократно приходилось использовать эти знания. В отличие от 15 предыдущих.
А вот системный дизайн очень субъективный. За 30-40 минут нужно не только нарисовать квадратики в ужасном редакторе, но и формализовать максимально нечёткие требования, придумать какую-то бизнес или UI/ux концепцию, а потом ещё и углубиться в ненужные детали. И по пути все время думать, кто же этот человек, который сразу хочет дизайн на млрд запросов. А ещё понимать абсурдность ситуации, что все происходящее практически никак не ложится на архитектурные стандарты.
Хотя это не имеет никакого значения в данном контексте, тк в любом случае модерирую не я, а кто-то. Но и тем не менее, толпа/боты поддаются панике и хайпу, ей что-то кажется, она бежит жаловаться, а фб любит деньги и следует запросам толпы. В итоге и получается, что фб может скрывать мнения под натиском толпы.
И мне интересно, можно ли создать сеть, которая by design будет свободна от такого изъяна, но и в то же время не будет помойкой
Я не считаю, что по факту мы живём в таком мире. Поэтому для меня вполне закономерным является вопрос, как уберечься от расправы толпы и форсирования единого мнения.
Один из примеров: модераторы могут поддерживать некие фильтры (как можно больше градаций), но только пользователь может выбирать какие фильтры он может применять для своей "ленты". Например, в политике я хочу читать все, а в новостях только проверяемые факты без мнения и тд.
Только я являюсь модератором контента, который потребляю и никакой модератор не может запретить мне читать, что я хочу.
Этого нет в фб и твиттере, к примеру. Там есть власть толпы и формирование политики партии/компании.
Одним из примеров, который интересно было рассмотреть, и который не лежит в технической плоскости - система жалоб.
По разным причинам несколько человек могут по-разному рассматривать ту или иную информацию. Одни видеть в ней истину, другие - ложь. Для одних это нарушение прав, для других - ок.
Таким образом модератору будут поступать жалобы на контент, который допустим для одной подгруппы и недопустим для другой (здесь речь не идёт о контенте, который можно однозначно оценить как запрещённый).
В итоге получается, что модератор может единолично закрыть доступ к контенту, который допустим.
На более глобальном уровне это выглядит так же, как и с фб - человеческий фактор влияет на доступность информации, которую я как пользователь получаю
Мне кажется, что следующий виток развития соц взаимодействия лежит не столько в технических характеристиках и фичах, сколько в области философии, т.е. концептуально ином подходе.
Самый простой пример - свобода слова. Кто и что может выкладывать в публичную плоскость, кто и как может контролировать (и может ли) контент и других участников. А если только участники могут управлять своим контентом без модерации, что делать с детским порно и прочим незаконным контентом?
И много подобных вопросов из области философии, этики и прочих слов.
ТС, чем отличается эта сеть от других? Если она станет глобальной, можно ли будет отключать неугодных?
И
Но вообще я ни в коем случае не пропагандирую никакой из подходов. Это инструменты. И нужно знать их как сильные так и слабые стороны, чтобы выбрать правильный. Вполне описанные проблемы могут быть несущественными на фоне преимуществ, или вовсе неактуальными для конкретного проекта.
п.с. По поводу ручками создавать.
Пришлось бы, но не приходится, потому что существуют инструменты.
вы правильно начали писать про графы зависимостей. но вот я не увидел продолжения.
а вот чего я не увидел:
Марк Симан в своих статьях(1) сам же и пишет, что идеальный SOLID это набор функций, т.к. буквы S и I приводят нас в идеальном мире к "миллиону" интерфейсов одного метода, т.е. "миллиону" функций. естественно, с увеличением количества связей между ними посредством абстракций (или функций).
поэтому на вашем графе должно быть вот совсем больше стрелочек. т.е. при количестве абстракций N, число связей между ними будет M, где M > N (вполне может и 2N). При этом, если вы говорите о чистоте функций и прочих радостях, наверное, вам морально сложно будет вызывать глобальные функции отовсюду в пользу функций высшего порядка.
как следствие следствией:
DI требует описать только N абстракций, и бибилиотека сама создаст все необходимые связи в момент разрешения зависимости. в вашем примере необходимо все зависимости прописывать руками, что практически всегда будет сложнее, ведь M > N (и в этот момент откройте какой-то проект, над которым работает 30-50+ человек хотя бы год и посмотрите, насколько или во сколько именно M > N с учетом всех логгеров, конфигов и т.д.). далее это приводит к усложнению поддержки и расширению кодовой базы.
*1: https://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
Подскажите, какие паттерны вы используете для коммуникации между слоями в коде и внедрения зависимостей?
хотелось бы услышать и про минусы. сказать, что требуется DevOps/Agile team, или остановится на юнит и интеграционных тестах — это как упустить половину.
Интересно было бы услышать, как у вас обеспечивается качество и своевременность поставок сервиса. Как происходит разработка, какие виды тестов выполняются? хотя бы как вы обеспечиваете тестирование (и какое) нового функционала? Делаете ли вы это до того, как он попал в общую ветку и т.д. И как результат насколько предсказуема разработка?
А если к REST добавить swagger?
В Киеве яндекс карты у убера. При чем по заявлению водителей они лучше гугловских. И все правки очень оперативно вносятся.
Но оно сырое очень. А что значит "будет"? Я по северной Европе поездил и отличий вообще не заметил. Опции те же. Израиль — то же самое
а вот как вы в убере вызываете микроавтобус, чтобы уехать 5+? Что делаете, когда «машин поблизости нет»? Или когда 30-50% адресов некорректно распознается. или когда водитель везет неоптимальным маршрутом и ловит все пробки (а потом пиши-строчи, чтобы проанализировали и вернули деньги). а уклон все эти проблемы решил «из-коробки».
в убере забит адрес «Дом» — центр города. После 3-5 обращений не осилили пофиксить баг, из-за которого не сохраняется номер дома, а машина приезжать хз куда.
но для каждой задачи подходит свой инструмент. если нужно быстро и сейчас любой ценой (и если рядом есть машина) — здесь убер выигрывает. если ездишь по крупным город по разным странам — выигрывает, т.к. пользуешься той же картой и тем же приложением (и можно карты на страны назначать). и быдлить водитель вряд ли будет, т.к. кошельком реально отвечает.
свои плюсы и минусы в общем.