Наш опыт в работе с Mobility Express показал, что решение уровня не выше мелкого офиса.
Для обеспечения работы компаний и зданий класса А — для точек доступа нужены либо кластеры физических контроллеров, либо в худьшем случае ИБП тк говорить о каких-то сцераниях работы Mobility Express в Failover не приходится — всё просто падает и более не поднимется. А специалисты официальных представителей по обе стороны океана отвечают одно и то же: ждите, там на верху думают.
А еще в уважаемой компании любят дописывать Outdoor к оборудованию с ограничениями по температурам только выше нуля и влажности не выше 80% :)
PS: но наши сети всё-таки на Mobility Express;( Мы стараемся быть оптимистами. И ждем дня когда это всё накроется медным тазом и все точки доступа придется заново настраивать.
Прочла.
Решение хорошее, но где же сравнение с прямыми конкурентами? Cisco Aironet? В особенности Mobility Express?
Хотелось бы посмотреть на реализации механизма failover?
А что если это корпоративная сеть и выдача DHCP поручена Windows?
Где упоминания про Hotspot 2.0 или 802.11u?
А вообще TP-LINK решения хорошие, но за 15 лет я так и не поняла, сегмент их применения.
P.S. Хотя и Cisco Aironet не идеален. Дорого. И не всё заявленное работает.
Я не сказала, что технологии нет.
Имелось ввиду, что вводить в эксплуатацию — опасно.
Более того, отпечаток пальцев не удобен. Те же проблемы что и с телефоном зимой — перчатки приходится снимать.
К тому же есть ряд профессий, как бармены, их кожа постоянно поддаётся воздействию разных кислот (попробуйте за 8 часов сделать 100 махито), итд. Но это вы и без меня знаете :)
Мдя. Приблизительно в это же время, в прошлом году я решила и себе СВО собрать.
В целом получилось очень весело и очень дорого, но оно того стоило.
Я отношусь к тому типу людей, когда удовольствие от процесса стоит больше чем сам процесс.
Начиная сборку своей первой СВО, заводские системы отбросила по причине их ущербности с эстетической точки зрения, да и какое удовольствие прикручивать всё точно так же.
В итоге, я потратила на новый PC порядке 6к баксов, но обзавелась лобзиком, всякими наждачными бумагами, феном (не тем что, у меня в ванной), научилась работать с акрилом (да, почему-то мне захотелось иметь акриловые трубки), научилась размещать заказы на крупных заводах для производства 1 деталюхи (крепление помп) под обещания оооочень крупных партий. Залила пол квартиры красителем (подумала, что я умная и от протечек я всё сделала правильно).
В итоге на сборку ушло почти 4 месяца, большую часть времени училась работать с акрилом (чуток перегрела, и уже трубка хреново выглядит).
Но даже тот факт, что мой 5960Х оказалался весьма фиговым экземпляром, способным работать только на 4.4HGz удовольствие от процесса я получила огромное количество. Лего — отдыхает.
Моё мнение такое:
Если есть свободное время и деньги — СВО ваш выбор, в ином случае «воздух» самое оно.
P.S. Хотела поделится своими, как говорят коллеги, двумя центами.
Проделаю ли я ещё раз неч-то подобное? Однозначно да. Жду когда Интел 10 ядерный процессов выпустит.
1. constructor injection — это читаемость кода. Сразу видно, что необходимо для работы конкретного класса.
к примеру:
public class MyController: Controller
{
ctor(IReader reader, IWriter writer);
}
и любому читающему понятно, что тут R/W операции, не вчитываясь в остальные строчки кода.
Использование injection method — это штуковина, нужна для экзотических вещей, когда в время построения нужно преодолеть рекурсивную зависимость объектов один от другого. Ну и ещё для парочки специфических сценариев.
Если у класса есть опциональные зависимости, то такие зависимости лучше подсовывать через property injection.
Вообщем, правило должно быть такое: то, без чего работа класса не возможна — в конструктор, всё остальное property injection.
А что касается баг-репортов, то у них есть замечательный раздел «раньше работало», и если репортить в него, то в 90% случаев _живой_ человек отвечает, задаёт вопросы. итд. Часто сама пользуюсь. Иногда помогает.
Ага, а потом утром придя на работу, а служба поддержки пользователей встречает тебя с вилами:
— Нам всё утро звонили пользователи и просили объяснить им «Что именно пошло не так, и что им с этим делать?»
Я каждый день работаю с разработчиками, и всё больше и больше убеждаюсь, что вопросы диагностики и работы с исключениями разработчиками спускаются на тормозах. Почему? Это вопрос философский, чем практический.
При работе с исключениями, я бы выделила две особенности:
а. Исключения для разработчика
б. Исключения для пользователя
Во-первых, сообщения для разработчика нужно снабжать необходимой _полезной_ информацией. Что бы те получив исключение UserNotFoundException долго не мучились пытаясь хоть как-то понять, какой именно пользователь не был найден. И всегда помнить, что исключение может произойти тогда, когда ваше приложение развёрнуто в 100500 серверах по такому же количеству ДЦ и подключится отладчиком, или включить подробную (verbose) детализацию логов у вас может не получится.
Ко второй категории, исключений я бы отнесла те, что имеют все больше шансов быть отображёнными пользователю. (Это ведь исключения. Никто не может дать 100% гарантии.) Такие исключения, нужно не только чётко типизировать, но ещё и давать им идентификационные номера, классы, описание, и всё, что будет вам полезно услышать от пользователя, в момент его обращения к вам с проблемой.
N.B. А многие любят писать такое:
try
{
}
catch(Exception ex)
{
log.Write(...., ex);
}
По этому мы на собеседования выносим вопросы:
а. А как себя поведёт этот код, если случилось StackOverflowException? SEHException? OutOfMemoryException?
P.S. Спасибо разработчикам C# 6.0 за фильтрацию исключений
Раньше писать про то, как складывать пути на дисках.
Для .NET на все собеседования выносили вопросы ответом на которые должны были стать варианции по применению System.IO.Path.Combine(...)
Теперь, имеем полноценного приемника System.Uri
class Program
{
static void Main(string[] args)
{
var domain = new Uri("https://internet-banking.com", UriKind.Absolute);
var path = ".subdomain.tw";
var uri = new Uri(domain, path);
Console.WriteLine(uri);
}
}
И на выходе будет то, что нужно:
https://internet-banking.com/.subdomain.tw
P.S. Но Uri не самый простой инструмент, там есть свои особенности.
Я говорю о изнасиловании трупа, пусть даже и в университете открытого посещения — это некрофилия, в каком бы виде она не была.
Не имеющая ни чего общего с коммерцией, если исключить особые договорённости после проиграша в карты.
Если серьёзно, то всё что мы видим и пользуемся всё служит для зарабатывания денег, нравится нам это или нет.
ReactOS — денег заработать в том виде, что есть сейчас не сможет, уж ни как.
Представим себе картину, на которой маленькая компания решила экономить на ИТ инфраструктуре, и осознала, что им нужен для работы Windows. Денег они не заработали, а банк где у них открыт счёт предоставляет клиент-банкинг только под Windows. (Менять банк в этом случае — это фанатизм, и ReactOS не имеет к этому отношение). И вот тут они решают выбрать ReactOS (халява), запускают клиент-банк — работает. Победа уже близко. Но наступает момент, когда клиент присылает запрос в excel'е или word'е. Решение — ставим OpenOffice (или как его там). И всё вроде открытое, свободное, и оно… хряк… и файл не открывается.
Что делают в этом случае? Правильно — идут в гугл (мы ведь экономим на IT оф. тех. поддержка нам не доступна). А там по ключевым словам — полная хрень! (может быть даже этот ответ там попадётся). И весь бизнес встал. Всё умерло.
В бизнесе главное деньги и время (гарантии дают только в морге).
Купив билет за 2000 баксов в бизнес-классе, люди зачастую пытаются выспаться над Атлантикой, чтобы по прилёту продолжать работать. (Ситуацию когда просто это круто — я не рассматриваю, т.к. в бизнес-планах авиакомпаний я не встречала пунктов "… мы сделаем… так… и… так… и люди у которых много денег как косяки рыб повалят..."). И говоря о сборке боинга, я не имела ввиду, что это невозможно, а хотела намекнуть на то, что затраты времени будут не соизмеримы в этой вселенной с 50 баксами за лицензию.
Т.е. вся задумка в том, что бы не платить за windows 50-60 баксов?
Какой в этом смысл?
99.9% комерческого софта имеет поддержку Windows, и при любой необходимости обратиться в службу поддержки вам сразу же скажут: Мы поддерживаем Windows, и на «клонах» мы не тестировали — помочь не можем.
При попытках собрать какое-то более менее комерческое решение на базе ReactOS, все сразу же столкнуться с «Это не реализовано — можете реализовать самостоятельно».
Вспоминаем времена, когда был Wine на linux'е и много-много шаманства когда пытались хоть что-то запустить.
У кого-то получалось, но большенство с прибором клали на это всё. И наступила эра виртуализации, когда ставят Virtual Box, VmWare, Hyper-V и запускают всё что необходимо.
Вся ситуация выглядит так: Я не хочу платить авиакомпании за билет — дорого, я с друзьями в гараже соберу свой Боинг 777 и буду летать куда хочу.
А как ваш чуда продукт справляется с чтением/декодированием VIN?
Для обеспечения работы компаний и зданий класса А — для точек доступа нужены либо кластеры физических контроллеров, либо в худьшем случае ИБП тк говорить о каких-то сцераниях работы Mobility Express в Failover не приходится — всё просто падает и более не поднимется. А специалисты официальных представителей по обе стороны океана отвечают одно и то же: ждите, там на верху думают.
А еще в уважаемой компании любят дописывать Outdoor к оборудованию с ограничениями по температурам только выше нуля и влажности не выше 80% :)
PS: но наши сети всё-таки на Mobility Express;( Мы стараемся быть оптимистами. И ждем дня когда это всё накроется медным тазом и все точки доступа придется заново настраивать.
Вы изобрели Enterprise Service Bus только в рамках одного процесса.
А так же на практике, не без изъянов, реализовали паттерн Producer-Consumer.
Посмотрите в сторону TPL (DataFlow Blocks)
Я всем своим коллегам говорю — вы прикладные программисты, и всё что вы изобрели сегодня, до вас уже изобрели.
Решение хорошее, но где же сравнение с прямыми конкурентами? Cisco Aironet? В особенности Mobility Express?
Хотелось бы посмотреть на реализации механизма failover?
А что если это корпоративная сеть и выдача DHCP поручена Windows?
Где упоминания про Hotspot 2.0 или 802.11u?
А вообще TP-LINK решения хорошие, но за 15 лет я так и не поняла, сегмент их применения.
P.S. Хотя и Cisco Aironet не идеален. Дорого. И не всё заявленное работает.
Имелось ввиду, что вводить в эксплуатацию — опасно.
Более того, отпечаток пальцев не удобен. Те же проблемы что и с телефоном зимой — перчатки приходится снимать.
К тому же есть ряд профессий, как бармены, их кожа постоянно поддаётся воздействию разных кислот (попробуйте за 8 часов сделать 100 махито), итд. Но это вы и без меня знаете :)
(отпечатки пальцев до сих пор не вводят, т.к. есть риск отделения последних от владельца)
Я для себя сделала вывод: хочу организовывать собеседования, а не проходить их.
У меня своя компания.
(Но проводить первичный скрининг, читать резюме, и не опаздывать на интервью — лучше бы я научилась их не заваливать, шутка)
Возможно следующий апгрейд будет на фрионе.
В целом получилось очень весело и очень дорого, но оно того стоило.
Я отношусь к тому типу людей, когда удовольствие от процесса стоит больше чем сам процесс.
Начиная сборку своей первой СВО, заводские системы отбросила по причине их ущербности с эстетической точки зрения, да и какое удовольствие прикручивать всё точно так же.
В итоге, я потратила на новый PC порядке 6к баксов, но обзавелась лобзиком, всякими наждачными бумагами, феном (не тем что, у меня в ванной), научилась работать с акрилом (да, почему-то мне захотелось иметь акриловые трубки), научилась размещать заказы на крупных заводах для производства 1 деталюхи (крепление помп) под обещания оооочень крупных партий. Залила пол квартиры красителем (подумала, что я умная и от протечек я всё сделала правильно).
В итоге на сборку ушло почти 4 месяца, большую часть времени училась работать с акрилом (чуток перегрела, и уже трубка хреново выглядит).
Но даже тот факт, что мой 5960Х оказалался весьма фиговым экземпляром, способным работать только на 4.4HGz удовольствие от процесса я получила огромное количество. Лего — отдыхает.
Моё мнение такое:
Если есть свободное время и деньги — СВО ваш выбор, в ином случае «воздух» самое оно.
P.S. Хотела поделится своими, как говорят коллеги, двумя центами.
Проделаю ли я ещё раз неч-то подобное? Однозначно да. Жду когда Интел 10 ядерный процессов выпустит.
В парочке больших проектов, мы уже пару раз меняли ORM — максимум неделя, и 1-2 дня отлов багов. Это не страшно.
DI — мы ещё не меняли, не видем в этом смысла Unity хоть и тежеловат по сравнению с конкурентами, но его гибкость пока недостежимая высота для других.
1. constructor injection — это читаемость кода. Сразу видно, что необходимо для работы конкретного класса.
к примеру:
public class MyController: Controller
{
ctor(IReader reader, IWriter writer);
}
и любому читающему понятно, что тут R/W операции, не вчитываясь в остальные строчки кода.
Использование injection method — это штуковина, нужна для экзотических вещей, когда в время построения нужно преодолеть рекурсивную зависимость объектов один от другого. Ну и ещё для парочки специфических сценариев.
Если у класса есть опциональные зависимости, то такие зависимости лучше подсовывать через property injection.
Вообщем, правило должно быть такое: то, без чего работа класса не возможна — в конструктор, всё остальное property injection.
Подумала, что попала на сайт по продаже виагры и чёрного СЕО.
А какая версия Windows используется в подобных исследованиях?
Что-то мне подсказывает что это билды из серии Fast/Slow Ring.
Я уже два года родителей не могу от этого отучить)
кОшмар начинается, если они письмо удалили в котором было ya.ru
— Нам всё утро звонили пользователи и просили объяснить им «Что именно пошло не так, и что им с этим делать?»
Я каждый день работаю с разработчиками, и всё больше и больше убеждаюсь, что вопросы диагностики и работы с исключениями разработчиками спускаются на тормозах. Почему? Это вопрос философский, чем практический.
При работе с исключениями, я бы выделила две особенности:
а. Исключения для разработчика
б. Исключения для пользователя
Во-первых, сообщения для разработчика нужно снабжать необходимой _полезной_ информацией. Что бы те получив исключение UserNotFoundException долго не мучились пытаясь хоть как-то понять, какой именно пользователь не был найден. И всегда помнить, что исключение может произойти тогда, когда ваше приложение развёрнуто в 100500 серверах по такому же количеству ДЦ и подключится отладчиком, или включить подробную (verbose) детализацию логов у вас может не получится.
Ко второй категории, исключений я бы отнесла те, что имеют все больше шансов быть отображёнными пользователю. (Это ведь исключения. Никто не может дать 100% гарантии.) Такие исключения, нужно не только чётко типизировать, но ещё и давать им идентификационные номера, классы, описание, и всё, что будет вам полезно услышать от пользователя, в момент его обращения к вам с проблемой.
N.B. А многие любят писать такое:
try
{
}
catch(Exception ex)
{
log.Write(...., ex);
}
По этому мы на собеседования выносим вопросы:
а. А как себя поведёт этот код, если случилось StackOverflowException? SEHException? OutOfMemoryException?
P.S. Спасибо разработчикам C# 6.0 за фильтрацию исключений
Exception Filters
Для .NET на все собеседования выносили вопросы ответом на которые должны были стать варианции по применению System.IO.Path.Combine(...)
Теперь, имеем полноценного приемника System.Uri
class Program { static void Main(string[] args) { var domain = new Uri("https://internet-banking.com", UriKind.Absolute); var path = ".subdomain.tw"; var uri = new Uri(domain, path); Console.WriteLine(uri); } }И на выходе будет то, что нужно:
P.S. Но Uri не самый простой инструмент, там есть свои особенности.
Я говорю о изнасиловании трупа, пусть даже и в университете открытого посещения — это некрофилия, в каком бы виде она не была.
Не имеющая ни чего общего с коммерцией, если исключить особые договорённости после проиграша в карты.
Если серьёзно, то всё что мы видим и пользуемся всё служит для зарабатывания денег, нравится нам это или нет.
ReactOS — денег заработать в том виде, что есть сейчас не сможет, уж ни как.
Представим себе картину, на которой маленькая компания решила экономить на ИТ инфраструктуре, и осознала, что им нужен для работы Windows. Денег они не заработали, а банк где у них открыт счёт предоставляет клиент-банкинг только под Windows. (Менять банк в этом случае — это фанатизм, и ReactOS не имеет к этому отношение). И вот тут они решают выбрать ReactOS (халява), запускают клиент-банк — работает. Победа уже близко. Но наступает момент, когда клиент присылает запрос в excel'е или word'е. Решение — ставим OpenOffice (или как его там). И всё вроде открытое, свободное, и оно… хряк… и файл не открывается.
Что делают в этом случае? Правильно — идут в гугл (мы ведь экономим на IT оф. тех. поддержка нам не доступна). А там по ключевым словам — полная хрень! (может быть даже этот ответ там попадётся). И весь бизнес встал. Всё умерло.
В бизнесе главное деньги и время (гарантии дают только в морге).
Купив билет за 2000 баксов в бизнес-классе, люди зачастую пытаются выспаться над Атлантикой, чтобы по прилёту продолжать работать. (Ситуацию когда просто это круто — я не рассматриваю, т.к. в бизнес-планах авиакомпаний я не встречала пунктов "… мы сделаем… так… и… так… и люди у которых много денег как косяки рыб повалят..."). И говоря о сборке боинга, я не имела ввиду, что это невозможно, а хотела намекнуть на то, что затраты времени будут не соизмеримы в этой вселенной с 50 баксами за лицензию.
Какой в этом смысл?
99.9% комерческого софта имеет поддержку Windows, и при любой необходимости обратиться в службу поддержки вам сразу же скажут: Мы поддерживаем Windows, и на «клонах» мы не тестировали — помочь не можем.
При попытках собрать какое-то более менее комерческое решение на базе ReactOS, все сразу же столкнуться с «Это не реализовано — можете реализовать самостоятельно».
Вспоминаем времена, когда был Wine на linux'е и много-много шаманства когда пытались хоть что-то запустить.
У кого-то получалось, но большенство с прибором клали на это всё. И наступила эра виртуализации, когда ставят Virtual Box, VmWare, Hyper-V и запускают всё что необходимо.
Вся ситуация выглядит так: Я не хочу платить авиакомпании за билет — дорого, я с друзьями в гараже соберу свой Боинг 777 и буду летать куда хочу.