Кратко, чтобы не зависит от реализации конкретного класса.
Условно говоря, чтобы накачать колесо, тебе не важно от какого оно авто, т.е. нужны только те параметры которые относятся к процессу накачивания, если все колеса реализуют эти параметры и методы нужны для накачивания, на них указанно давление и у них унифицирован ниппель, нет необходимости знать какое это конкретно колесо.
Передавая в класс объект, а не интерфейс, происходит привязка к конкретной реализации, это стимулирует программиста сильнее связать данные классы, чем необходимо, что усложнит дальнейшую разработку, это усложняет тестирование, ты не можешь подпихнуть в тест другую реализацию, это делает код менее универсальным и порождает дублирование, это усиливает связность кода, усложняя его последующую модификацию.
Испытательный срок это затраты. Затраты на найм, затраты на онбординг, затраты в виде заработной платы и в конце концов время. Если вы не нанимаете специалистов на потоке вы не можете себе позволить прогнать десяток кандидатов через испытательный срок.
Там же где нанимают на потоке часто делают это через условно бесплатную стажировку, а потом растят кадры внутри.
VaneS Ri_Lax, значит и сейчас у вас лицензии нет, обновить до 10 можно было только легально приобретенные на физ.лицо копии 7, если вы смогли обойти данное ограничение, это не делает систему лицензионной.
Aloha0, быстродействие виртуальной машин зависит от ресурсов которые вы ей выделяет. Очевидно оно будет ниже если машина будет делить ресурсы с другой ОС.
А что здесь "дебажить", вы как-то установили 25% потерю в сети, вот с ней и разбирайтесь. Правда вопрос как вы эти 25 выявили, при таком проценте потери пакетов сеть фактически не работает совсем.
А где проходит та сама граница между практикой и теорией?
Вот например у вас, почему отличие UDP от TCP это теория, если эти отличия принципиально влияют на множество сетевых настроек, а не зная эти отличия невозможно корректно настроить ничего сложнее домашнего маршрутизатора.
Постановление Правительства РФ от 31 июля 2014 г. N 758
Абонент юр.лицо обязан собирать данные тех кто использует его сети.
В лучшем случае оператор связи обязан с вами расторгнуть договор, в худшем оказание услуг связи без лицензии. Так же там есть вереница штрафов за связанные нарушения, например фильтрация контента до 18 лет.
SionFE, я бы не рекомендовал подобную связку, она будет со значительным дублированием функционала за ваши деньги. Работать будет нормально.
Первое с чем определитесь, кол-во проводных хвостов и устроят ли вас ретрансляторы. Ретрансляторы имеет сложности когда у вас много безпроводных клиентов или постоянный видео wifi трафик, средняя семья вполне будет довольна ретрансляторами, особенно если подключит ТВ по проводу. У меня два ТВ, два ПК, планшет и 4 смарта, проводов нет, все конечно не летает, но видео с youtube не тормозит, узким местом остаётся 80мбит провайдер.
Вы создаете на сервере обычные папки с разбивкой по функционалу. Одна функция - одна папка. Плюс делаете папки по кол-ву отделов, в них все сотрудники советующего отдела могут делать с файлами все что угодно и сами определят внутреннее деление по функционалу.
В папку отдела помещается только то, что нужно ТОЛЬКО и исключительно одному отделу. Пользователи не могут получить доступ к файлам другого отдела, даже если очень хочется, даже если сказал директор, нужно настаивать на структуре которая более менее прозрачна для обслуживания.
Для любой общей роли в которой участвуют несколько отделов, отдельная папка.
На каждую папку вы создаете две локальные доменные группы( доменные группы бывают локальные, глобальные и универсальные ).
Одну имя папки read, другую имя папки write. Для каждой группы вы назначаете права на соответствующую папку, для одной на чтение, для другой на запись.
Дальше вы создаете глобальные доменные группы по количеству крупных бизнес ролей( например сотрудники отдела продаж, руководители отдела продаж, сотрудники колцентра, руководители среднего звена и т.д. )
Созданные глобальные доменные группы вы включаете в локальные доменные группы в соответствии с правами данных групп. Например глобальную группу сотрудники отдела продаж вы включаете в локальные группы папка отдела продаж чтение, папка отдела продаж запись, папка договора с клиентами чтение, папка договора с клиентами запись, папка реквизиты организации чтение ).
Дальше вы создаете DFS узел Отдел продаж. В этот DFS узел вы включаете traget на советующие папки.
Таким образом в данном DFS узле у вас из всех источников будут собраны все папки нужные отделу продаж.
После чего данный DFS узел у вас доступен по доменному пути( если вы его опубликуете в AD, там есть такая галочка ), например \\domainname\sale.
Доступ к данному DFS узлу вы можете настроить отдельно, но это будет влиять в основном на возможность посмотреть содержимое самого узла, т.е. увидеть список папок в этом узле, но не повлияет на возможность на доступ к сами данным, поскольку доступ к данным будет определятся NTFS разрешениями которые вы настроили на предыдущем шаге.
Вы можете конечно сделать и отдельный DSF узел на каждого пользователя, но это очень странная идея и поддерживать ее будет весьма затруднительно, честно говоря не могу представить зачем вообще такое может понадобится.
Да, если вам нужно обеспечить общий доступ к папка расположенным не на сервере, а на локальном компьютер пользователя это делает ровно этим же способом, при этом вы можете в DFS узел включать папки вообще из любых расположений, а не только расположенные на том же сервере и даже можете сделать репликацию между несколькими расположениями. Но это имеет отношение только к общему сетевому доступу. Локальный досутп проще делать по локальному, а не сетевому пути. Права по группам при этом настраиваются аналогично, только локальные группы называются по полному пути к каталогу( если только у вас такой каталог есть не на каждом ПК, если на каждом и везде права одинаковые можно использовать одно имя группы )
SionFE, не управление сетью вообще, а управление wifi. У ubiquiti оно тоже есть и пожалуй реализовано лучше. Но там нужен отдельный "контроллер"( возможно что-то поменялось и его можно поднять на роутере ), он может быть программным( на любом ПК ) или можно купить готовый( на мой взгляд предпочтительнее ).
Полюс у них есть очень качественный готовый комплект репитеров( управления вообще не нужно будет ), но с репитерами скорость будет ниже( но это значительно проще ).
AlexanderSuz, "папка" DFS находится на сервере, выглядит как папка с общим доступом при это является "виртуальной", т.е. подпапки находятся не с самой папке, а могут быть произвольным образом раскиданы по сети. Это позволяет в частности не делать жесткой связи между структурой ресурсов доступных пользователю( папки - подпапки ) и структурой фактического расположения этих файлов-папок.
Пример:
Папка отделов
..Папка Отдела продаж реальный путь d:\depfoldes\saledep
..Папка Бухгалтерии e:\depfoldes\buhdep
..Папка Юридической службы d:\legaldep
Папка договоров
..Папка договора с поставщиками d:\contracts\supplier
..Папка договора с клиентами d:\contracts\client
При этом с помощью DFS мы собираем эти папки в одну виртуальную папку
\\domain.local\sale
В которой будут две подпапки являющиеся фактически линками( для пользователя выглядят как папки )
Папка отдела( указывает на d:\depfoldes\saledep )
Договора( указывает на d:\contracts\client )
Пользователь реальный путей не видит, для него эти подпапки будут выглядеть как \\domain.local\sale\Папка отдела и \\domain.local\sale\Договора
После чего данные папки можно примонтировать пользователю в виде сетевого диска, это удобно.
Защита ПО это юридический процесс, подписывайте договор. Можете добавить код который будет обращаться к вашему серверу, так вы увидите где ПО запускалось.
Условно говоря, чтобы накачать колесо, тебе не важно от какого оно авто, т.е. нужны только те параметры которые относятся к процессу накачивания, если все колеса реализуют эти параметры и методы нужны для накачивания, на них указанно давление и у них унифицирован ниппель, нет необходимости знать какое это конкретно колесо.
Передавая в класс объект, а не интерфейс, происходит привязка к конкретной реализации, это стимулирует программиста сильнее связать данные классы, чем необходимо, что усложнит дальнейшую разработку, это усложняет тестирование, ты не можешь подпихнуть в тест другую реализацию, это делает код менее универсальным и порождает дублирование, это усиливает связность кода, усложняя его последующую модификацию.
Почитайте Мартин "Чистая архитектура"