Что представляет из себя шина данных (3 видео)

Шина данных это одна из самых важных шин, из-за необходимости которой собственно и формируется вся остальная система. Численность имеющихся у нее разрядов указывает на скорость и производительность обмена данными, кроме этого определяет наибольшее число выполняемых команд. Шина данных это устройство, которое передает данные всегда в двух направлениях.

Для работы компьютера предполагается наличие в его составе комплекса определенных систем, и отсутствие хотя бы одной из них приведет к полной неработоспособности ПК. Ниже перечислены основные системы:

Центральный процессор
Графический адаптер
Система оперативной памяти (ОЗУ)

Но все-таки эти модули, даже в комплексе не будут выполнять тех функций, которые от них требуются. Для того, чтобы все компоненты функционировали как положено, среди них создается взаимосвязь, с помощью которой будет выполняться необходимые вычислительные и другие операции. Средства связи такого рода создают именно компьютерные системные шины. Следовательно, можно утверждать, что данный компонент является крайне необходимым элементом в компьютерном блоке.

Содержание

Компьютерная шина
Основное деление компьютерных шин
Одна из самых значимых устройств связи
Производительность компьютера
Системные шины в современных компьютерах
Шина данных
Связанные понятия
Упоминания в литературе
Связанные понятия (продолжение)
События, шины и интеграция данных в непростом мире микросервисов
Что мы сделали?
Что это значит?
Как это работает?
Что мы придумали?
💥 Видео

Компьютерная шина

Компьютерная шина – это электронная магистраль предназначенная для передачи информации между функциональными модулями компьютера. Такими как: центральный процессор, графический адаптер, винчестер, ОЗУ и остальными устройствами. Данная система включает в себя некоторое количество других шин, в частности: шины адреса, шина данных, кстати их может быть несколько, и шина управления.

Основное деление компьютерных шин

Отличие шин друг от друга базируется на нескольких моментах. Главным признаком считается Первенствующим показателем является место расположения. Исходя из этого шины бывают следующих типов:

Шины для создания магистральной связи между компонентами установленными внутри компьютерного блока, а именно: центральный процессор, оперативное запоминающее устройство, системная плата. В современных компьютерах она обозначается как — локальная шина.
Шины служащие для подсоединения к системной плате периферийных гаджетов, таких, как: адаптеры, карты памяти, называются — внешними шинами.

По-большому счету, компьютерной шиной можно охарактеризовать практически всякое устройство, служащее для создания связи между двумя и более компонентами. Даже оборудование для подключения компьютера к сети Интернет в определенной степени считается системной шиной.

Одна из самых значимых устройств связи

Все действия выполняемые нами с помощью компьютера, будь то работа с документами или прослушивание музыкальных треков, компьютерные игры — все это возможно только благодаря процессору. Равным образом и процессор не может выполнять свои функции, не имея при этом магистральной связи с остальными значимыми компонентами осуществляющими полноценную работу компьютера. То есть, именно с помощью системной шины процессора организуется в одно целое комплекс устройств.

Производительность компьютера

Все основные компьютерные шины в зависимости от предназначения, делятся на несколько категорий:

Адресные шины
Шины управления
Шины данных

У процессора может быть задействовано несколько системных трактов связи, при этом, как показала практика, наличие определенного количества шин увеличивает эффективность работы компьютера. Пропускная способность компьютерной шины в большей части определяет производительность ПК. Принцип ее действия заключается в определение скорости трансляции данных, передающихся с локальных устройств на другие вычислительные модули и обратно.

Системные шины в современных компьютерах

Стандартная локальная шина, разработанная ассоциацией VESA, получила компетентное признание в мире компьютерных технологий. Официальное ее название VL-Bus и она же является одной из самых популярных шин локального назначения со дня ее представления. Используя шину VL-Bus можно осуществлять 32-разрядную передачу информации между графическим адаптером и процессором либо винчестером.

Однако, такая магистраль связи не способна поддерживать корректную работу микропроцессора. Вследствие этого она встраивается в систему вместе с 16-разрядной шиной ISA, и таким образом выполняет функции дополнительного расширения.

Компьютерная шина, оперативка, центральный процессор и мосты

Видео:Как работает LIN шина автомобиля. K-Line L-Line шины данных. Лин шина автомобиля. Lin-bus networkСкачать

Шина данных

Шина данных — часть системной шины, предназначенная для передачи данных между компонентами компьютера.

В компьютерной технике принято различать выводы устройств по назначению: одни для передачи информации (например, в виде сигналов низкого или высокого уровня), другие для сообщения всем устройствам (шина адреса) — кому эти данные предназначены.

На материнской плате шина может также состоять из множества параллельно идущих через всех потребителей данных проводников (например, в архитектуре IBM PC).

Связанные понятия

Упоминания в литературе

Связанные понятия (продолжение)

Компьютерная ши́на (англ. computer bus) в архитектуре компьютера — подсистема, служащая для передачи данных между функциональными блоками компьютера. В устройстве шины можно различить механический, электрический (физический) и логический (управляющий) уровни.

В информатике бу́фер (англ. buffer), мн. ч. бу́феры — это область памяти, используемая для временного хранения данных при вводе или выводе. Обмен данными (ввод и вывод) может происходить как с внешними устройствами, так и с процессами в пределах компьютера. Буферы могут быть реализованы в аппаратном или программном обеспечении, но подавляющее большинство буферов реализуется в программном обеспечении. Буферы используются, когда существует разница между скоростью получения данных и скоростью их обработки.

Латентность (в т.ч. англ. CAS Latency, CL; жарг. тайминг) — временна́я задержка сигнала при работе динамической оперативной памяти со страничной организацией, в частности, SDRAM. Эти временны́е задержки также называют таймингами и для краткости записывают в виде трех чисел, по порядку: CAS Latency, RAS to CAS Delay и RAS Precharge Time. От них в значительной степени зависит пропускная способность участка «процессор-память» и задержки чтения данных из памяти и, как следствие, быстродействие системы.

Mультипле́ксор — устройство, имеющее несколько сигнальных входов, один или более управляющих входов и один выход. Мультиплексор позволяет передавать сигнал с одного из входов на выход; при этом выбор желаемого входа осуществляется подачей соответствующей комбинации управляющих сигналов.

В телекоммуникации и информатике под последовательной передачей данных понимают процесс передачи данных по одному биту за один промежуток времени, последовательно один за одним по одному коммуникационному каналу или компьютерной шине, в отличие от параллельной передачи данных, при которой несколько бит пересылаются одновременно по линии связи из нескольких параллельных каналов. Последовательная передача всегда используется при связи на дальние расстояния и в большинстве компьютерных сетей, так как.

Программи́руемая логи́ческая интегра́льная схе́ма (ПЛИС, англ. programmable logic device, PLD) — электронный компонент (интегральная микросхема), используемый для создания конфигурируемых цифровых электронных схем. В отличие от обычных цифровых микросхем, логика работы ПЛИС не определяется при изготовлении, а задаётся посредством программирования (проектирования). Для программирования используются программатор и IDE (отладочная среда), позволяющие задать желаемую структуру цифрового устройства в.

Читайте также: Уравнение состояния воздуха в шине

Многоканальный режим (англ. Multi-channel architecture) — режим работы оперативной памяти (RAM) и её взаимодействия с материнской платой, процессором и другими компонентами компьютера, при котором может быть увеличена скорость передачи данных между ними за счёт использования сразу нескольких каналов для доступа к объединённому банку памяти (это можно проиллюстрировать на примере ёмкостей, через горлышко одной из которых жидкость будет выливаться дольше, чем из двух других с такими же общим суммарным.

Ввод-вывод через порты (англ. I/O ports) — схемотехническое решение, организующее взаимодействие процессора и устройств ввода-вывода. Противоположность вводу-выводу через память.

Видео:СПРОСИ ЭКСПЕРТА: Выпуск 1. Чем отличается шина данных от ETL?Скачать

События, шины и интеграция данных в непростом мире микросервисов

Валентин Гогичашвили объясняет микросервисы. Перед вами расшифровка доклада с Highload++.

Добрый день, я Валентин Гогичашвили. Все слайды я сделал латиницей, надеюсь не будет проблем. Я из Zalando.

Что такое Zalando? Наверное, вы знаете Lamoda, Zalando был папой Lamoda своё время. Чтобы понять, что такое Zalando, нужно представить Lamoda и увеличить в несколько раз.

Zalando – это магазин шмоток, мы начали продавать обувь, очень хорошую между прочим. Начали расширяться всё больше и больше. Снаружи сайт выглядит очень просто. За 6 лет что я работаю в Zalando и за 8 лет существования — эта компания была одной из самых быстрорастущих в Европе в какое-то время. Шесть лет назад, когда я пришел в Zalando, она росла где-то 100%.

Когда я начинал 6 лет назад, это был маленький стартап, я пришёл довольно поздно, там уже было 40 человек. Мы начинали в Берлине, за эти 6 лет мы расширили Zalando Technology на много городов, включая Хельсинки и Дублин. В Дублине сидят data-science’ы, в Хельсинки сидят mobile developer’ы.

Zalando Technology растёт. На данный момент мы нанимаем в районе 50 человек в месяц, это страшное дело. Почему? Потому что мы хотим построить самую крутую fashion-платформу в мире. Очень амбициозно, посмотрим, что получится.

Хочу немножко вернуться в историю и показать вам старый мир, в котором вы, скорее всего, в какой-то момент вашей карьеры определенно были.

Zalando начинался как маленький сервис у которого было 3 уровня: web applicaton, backend и база данных. Мы использовали Magento. К тому моменту, когда меня позвали в Zalando, мы были самыми большими пользователями Magento в мире. У нас были огромные головные боли с MySQL.

Мы начали проект REBOOT. Я и пришел на этот проект 6 лет назад.

Что мы сделали?

Мы переписали все на Java, потому что мы знали Java. Мы поставили везде PostgreSQL, потому что я знал PostgreSQL. Ну и Python – это дело техники. Практически любой нормальный человек меня поддержит, что Python для tooling’a — это единственное правильное решение (люди из мира Perl, не убивайте меня). Python это хорошая шутка для написания tooling.

У нас начала развиваться такая схема:

У нас была система macro services. Java Backend, PostgreSQL storage c PostgreSQL шардингом. Я два года назад на этой же конференции рассказывал о том, как мы делаем PostgreSQL-шардинги, как мы управляем схемами, как мы выкатываем версии без downtime, было очень интересно.

Как я сказал, Java мы все знали. SOAP использовался для объединения macro-сервисов друг с другом. PostgreSQL давал нам возможность иметь очень чистые данные. У нас была схема, чистые данные, транзакции и хранимые процедуры, котором мы научили всех java-developer’ов или тех, кто еще остались из PHP-мира, которых мы научили Java и хранимым процедурам.

Один хинт: если вы находитесь в режиме меньше 15 миллионов пользователей в месяц, то вы можете использовать систему Java SProc Wrapper для автоматического шардирования PostgreSQL из Java. Очень интересная штука, которая PostgreSQL в RSP-систему, по существу.

Всё было хорошо, мы написали и переписали всё. Мы сперва купили систему управления нашими складами, а потом всё переписали. Потому что мы должны были двигаться намного быстрее чем те люди, у которых мы купили систему могли это сделать.

Всё прекрасно работало пока не началась проблема с кадрами. Наш прекрасный мир начал рушиться на глазах. Система стандартизации, ее уровень, который мы ввели на уровне Java, SOAP начал крошиться. Люди начали жаловаться и уходить или просто не приходить.

Мы им говорили: вы должны писать на Java, если вы уйдете, что мы будем делать? Если вы напишите что-то на Haskell или на Clojure и уйдете что мы будем делать? А они нам отвечали fuck you.

Мы решили подойти к делу серьезно. Мы решили перестроить не только архитектуру, но и всю организацию. Мы начали процесс перестройки организации, которая не видела немецкая индустрия, в которой мы сказали, что мы разрушаем полностью всё, что у нас было. Это была организация в которой было в районе 900 человек, мы разрушаем иерархическую структуру в том виде в которой она была. Мы объявляем Radical Agility.

Видео:03. Основы устройства компьютера. Память и шина. [Универсальный программист]Скачать

Что это значит?

Мы объявляем, что у нас есть команды, которые автономны, которые двигаются вперед осмысленно. Конечно же мы хотим, чтобы люди, которые занимались делом, они делали это дело с мастерством.

Они могут выбрать своё собственное технологический стэк. Если команда решила, что они будет писать на Haskell или Clojure, то пусть так и будет. Но за это надо платить. Команды должны поддерживать сервисы, которые они написали сами, просыпаться ночью сами. Включая выбор персистент стэка. Мы вам научили PostgreSQL, если вы хотите выбрать MongoDB, а нет стоп, MongoDB у нас заблокирован. У нас есть радар технологий в котором мы проводим помесячные опросы и технологии, которые считаем опасными, ставим на красный сектор. Это означает, что команда могут выбирать эти технологии, но они пенять полностью на себя, если что-то пойдет не так.

Мы сказали, что команды будут изолированы своими AWS-аккаунтами. До этого мы были в своих собственных дата центрах, выбрав AWS, мы пошли на сделку с дьяволом. Мы сказали, мы знаем, что это будет стоить дороже, но мы будем двигаться быстрее. У нас не будет ситуаций как до этого, в собственных дата центрах: для того, чтобы заказать один жесткий диск, требовалось 6 недель. Это было невыносимо и невозможно. Мы не могли двигаться вперед.

Очень многие люди считают, что автономия — это анархия. Автономия — это не анархия. С автономией приходит очень много ответственности, особенно для Zalando, которая publicly traded company. Мы на бирже и как в любую publicly traded company к нам приходят аудиторы и они проверяют, как работают наши системы. Мы должны были создать какую-то структуру, которая позволит нашим developer’ам работать с AWS, но всё же оставаться способными отвечать на вопросы аудиторов уровня: «Почему у вас это IP-адрес в публичном доступе без идентификаций?»

Читайте также: Шины continental кросс контакт

Получилась вот такая система:

Мы хотели сделать её максимально простой, она действительно простая. Но все ругаются, когда видят её.

Если вы уходите в AWS, напоминание вам, с этой быстротой и с открытостью, и если вы выбираете идею с микросервисами или публичными сервисами, то за это может быть придётся платить. В том числе если вы хотите сделать систему, которая безопасна, которая отвечает на вопросы, которые могут задавать наши аудиторы.

Конечно же мы сказали, что для того чтобы поддерживать разнородный стэк технологий мы поднимаем уровень стандартизации с Java и PostgreSQL на более высокий уровень. Мы поднимаем уровень стандартизации на уровень REST APIs.

Что это значит? Я отмечал это на предыдущем докладе о том, что нам нужна система описания API. Описание системы того как микросервисы общаются друг с другом. Нам нужен порядок. На каком-то уровне нам нужно стандартизироваться. Мы объявили о том, что у нас будет система API first. И что каждый сервис перед тем как его начнут писать, команда должна прийти в API гильдию и уговорить их принять API в состав утвержденных API. Мы написали REST API guidelines, очень интересные. На них даже ссылались в некоторых ресурсах. API first библиотеки, которые позволяют использовать Swagger (OpenAPI) в качестве руторов для сервера. Например, connection — это рутор для flask’a в Python, а play-swagger — это рутор для play-системы в Scala. Для Clojure есть такой же рутор, это очень удобно. Вы пишите сперва Swagger файл, описываете то, чего вы хотите добиться от своего микросервиса, а потом просто указываете, какие функции в вашей системе должны исполнять те или иные операции в API.

Но проблема с микросервисами. Я хочу несколько раз повторить эту фразу. Микросервисы — это ответ на организационные проблемы, это не технический ответ. Я не буду советовать микросервисы никому, кто маленький. Я не буду советовать микросервисы тем, у кого нет проблем с разношерстной технологической базой, кому не нужно писать один сервис на Scala, другой сервис на Python или Haskell. Количество проблем с микросервисами довольно высокое. Этот барьер. Для того, чтобы его преодолеть, нужно довольно много боли испытать перед этим, как сделали это мы.

Одна из самых больших проблем с миркосервисами: микросервисы по своей дефиниции закрывают доступ к системе персистирования данных. Базы спрятаны внутри микросервиса.

Таким образом классический extract transform load process не работает.

Давайте сделаем один шаг назад и вспомним, как работаем в классическом мире. Что у нас есть? У нас есть классический мир, у нас есть developer’ы, junior developer’ы, senior developer’ы, DBA и Business Intelligence.

Как это работает?

В простом случае у нас бизнес логика, база, ETL процесс достаёт прямо из базы наши данные и засовывает в Date Warehouse (DWH).

В большем масштабе у нас есть много сервисов, много баз и один процесс, который пишется, скорее всего, ручками. Вытаскиваются данные из этих баз и кладутся в специальную базу для бизнес-аналитиков. Она очень хорошо структурирована, бизнес аналитики понимают, что они делают.

Конечно это всё — не без проблем. Это всё очень трудно автоматизировать. В мире микросервисов у нас всё не так.

Когда мы объявили о микросервисах, когда мы объявили о Radical Agility, когда мы объявили об этих всех прекрасных нововведениях для developer’ов, бизнес-аналитики были очень недовольны.

Как собирать данные из огромного количества микросервисах?

Речь идет не о десятках, а о сотнях или даже тысячах. Потом приходит Валентин на коне и говорит: мы всё будет писать в поток, в queue. Потом архитекторы говорят: почему queue? Кто-то будет использовать Kafka, кто-то будет использовать Rabbit, как мы будет это всё интегрировать? Наши security-officer’ы сказали: никогда в жизни, мы не позволим. Наши бизнес-аналитики сказали: если там не будет схемы, мы повесимся и не сможем понять, что течёт, это же будет просто сточная канава, а не система транспорта данных.

Мы сели и начали совещаться и решать, что же делать. Наши основные цели: простота использования нашей системы, хотим, чтобы у нас не было single point of failure, не было такого монстра, который если он упадёт, то всё упадёт. Должна быть безопасная система, и эта система должна удовлетворять потребностям бизнес-аналитики, система должна удовлетворять наших data-science’ов. Она должна в хорошем случае дать возможность другим сервисам использовать эти данные, которые текут через шину.

Из Event Bus мы сможем вытаскивать Business Intelligence или в какие-то Data heavy services. DDDM это любимое понятие в последнее время. Это data driven decisions making system. Любой менеджер будет в восторге от такого слова. Machine learning and DDDM.

Что мы придумали?

Nakadi. Вы наверно поняли, что у меня фамилия довольно грузинская. Nakadi по-грузински значит поток. Например, горный поток.

Мы начали делать такой поток. Основные принципы, которые мы туда вложили, немножко повторюсь.

Мы сказали, что у нас будет стандартный HTTP API. По возможности — restful. Мы сделаем централизованную или по возможности не очень централизованную event type registry. Мы введём разные классы event types. Например, на данный момент у нас поддерживается два класса. Это data capture и business events. То есть если у нас меняются сущности, то мы можем event capture записывать с всей необходимой метаинформацией. Если у нас просто информация о том, что в бизнес-процессе что-то произошло, то это обычно намного более простой случай, и мы можем писать более простой event. Но всё равно бизнес-аналитики требуют, чтобы у нас была организована структура, которую можно будет автоматически парсить.

Имея огромный опыт работы с PostgreSQL и со схемами, мы знаем, что без поддержки версионирования схем ничего не будет работать. То есть если мы скатимся до уровня, где программисты должны будут описывать order created, затем order created 1,2,3, мы будем, по существу, делать систему похожую на Microsoft Windows, и это будет очень трудно, особенно для того чтобы понимать, как развиваться сущность, как версионируется сущность. Очень важно, чтобы этот интерфейс позволял стримить данные, чтобы можно было реагировать как можно быстрее на приход сообщений и оповещать всех желающих о приходе сообщения.

Читайте также: Свалка шин в тюмени

Мы не хотели изобретать велосипед. Наша цель — сделать максимально минимальную систему, которая будет использовать существующие системы. Поэтому на данный момент мы взяли Kafk’у, как underline систему и PostgreSQL для хранения метаданных и схемы.

Nakadi Cluster — это то, что у нас есть. Существует в виде open source проекта. В данный момент он валидирует схему, которую регистрировали до этого. Он умеет записывать дополнительную информацию в метаполя для event’a. Например, время прихода или если клиент не создал уникальные id для event’a, то и уникальные id туда можно запихнуть.

Также мы посчитали, что нужно взять на себя управление offset’ами. Те, кто знает, как работает Kafka. Кто-нибудь знает? Хорошо, но не большинство. Kafka – классическая pub/sub-система, в которой продюсер записывает данные последовательно, а клиент не хранит, как в классических message-системах.

Для клиента не создаются отельные копии message, единственное, что нужно клиенту, — это offset. То есть сдвиг в этом бесконечном потоке. Можете представить, что Kafka — это такой бесконечный поток данных, в котором пронумерована каждая сточка. Если ваш клиент хочет забрать данные, он говорит: читай с позиции X. Kafka даст ему эти данные из позиции X. Таким образом гарантируется упорядоченность данных, таким образом гарантируется что на сервере не надо хранить очень много информации, как обычно делается в классических message-системах, которые позволяют комитить часть прочитанных event’ов. В данной ситуации у нас есть проблема в том нельзя закомитить кусок прочитанного блока. Сейчас пошёл offtext, про Kafk’y не хотел говорить, извините.

High level interface делает чтение из kafk’и очень простым для клиентов. Клиенты не должны обмениваться информацией, кто из какого раздела читает, какие offset’ы они хранят. Просто приходит клиент и получает то, что нужно из системы. Мы решили по пути минимального сопротивления. Zookeeper уже есть для Kafk’и, какой бы ужасный Zookeeper не был, он у нас уже есть, нас уже нужно его manage’ить и мы используем его для хранения offset’ов и дополнительной информации. PostgreSQL — для метаданных и хранения схем.

Сейчас я хочу рассказать в каком направлении мы движемся.

Мы движемся очень быстро. Поэтому, когда я вернусь в Берлин, какие-то части будут уже сделаны.

На данный момент у нас есть Nakadi Cluster, у нас есть Nakadi UI, который мы начали писать на Elm, чтобы заинтересовать других людей. Elm крутой, люблю его.

Следующим шагом мы хотим иметь возможность управлять несколькими кластерами. Мы уже видели косяки, когда приходит новый продюсер и начинает писать 10 тысяч event’ов в секунду, не предупредив ни о чем.

Наш кластер не успевает масштабироваться. Мы хотим, чтобы у нас были разные кластеры по разным типам данных. Стандартизацию интерфейса мы делали специально так, чтобы не было никакой завязки на Kafk’y.

Мы можем переключиться с Kafk’и на Redis. А с Redis’a на Kinesis. По существу, идея такая, что в зависимости от необходимости сервиса и свойств event’ов, которые они пишут, если кому-то не интересен ordering, упорядоченность, то можно использовать систему, которая не поддерживает ordering и более эффективна, чем Kafka. На данный момент у нас есть возможность абстрагировать это, используя наш интерфейс.

Nakadi Scheme Manager нужно вытаскивать из кластера, потому что он должен быть зашерен. Следующий шаг — такая идея, чтобы у нас схемы детектировались. То есть поднимается микросервис, публицирует свой swagger-файл, публицирует список event’ов в том же формате, что и swagger. Автоматически crawker забирает это всё и избавляет developer’ов от необходимости дополнительно перед deployment’ом inject’ить схему в message bus.

Ну и конечно, topology manager, чтобы можно было каким-то образом рутить продюсером и консюмеров на разные кластеры. Тут рассказывали, что Kafka работает как слон. Нет, не как слон, а как паровоз. В нашей ситуации этот паровоз всё время ломается. Не знаю, кто производил этот паровоз, но для того, чтобы управлять Kafk’ой в AWS, оказалось, что это не так просто.

Мы написали систему Bubuku, очень хорошее название, очень русское.

У меня был большой слайд, на котором было указано что делает Bubuku, но он получился очень большим. Всё можно посмотреть по ссылке.

В прицепе Bubuku имеет цели делать то, что не делают другие с Kafk’ой. Основные идеи что это автоматически reportition, автоматический scaling и возможность пережить попадания молнией, crazy monkeys которые убивают инстансы.

Кстати, у нас систему тестирует Chaos Monkey, и очень даже неплохо всё это работает. Всем рекомендую, если вы пишите микросервисы, всегда думайте, как эта система переживает Chaos Monkey. Это — Netflix-система, которая рандомно убивает ноды или отключает сеть, портит вам систему

Какую бы вы систему ни построили, если вы её не тестируете, то она не будет работать, если что-то поломается.

Заключая свой поверхностный рассказ, хочу сказать: то, о чем я рассказывал, сейчас мы разрабатываем в open source. Почему open source? Мы даже написали, почему Zalando делает open source.

Когда люди пишут в open source, они пишут не для компании, а для себя отчасти. Поэтому мы видим, что качество продуктов лучше, мы видим, что изолируемость продуктов от инфраструктуры лучше. Никто не записывает внутрь zalando.de и не правят ключи, не комитят в Git.

У нас есть принципы о том, как open source’ить. Есть ли у вас вопросы в компании должны ли мы open source’ить или нет? Есть принцип open source first. Перед тем как начать проект, мы думаем, стоит ли его open source’ить. Для того что понять и ответить на этот вопрос, нужно ответить на вопросы: