Это она, и она гуглится сходу прямо. Еще можно купить англоязычный оригинал Баха (я ниже привел ISBN). К слову, Кетов читал в том числе по Робачевскому.
Это проблема, но, тем не менее, я не встречал за свою карьеру книг, подходящих близко к потенциалу Арсмтронга (это при том, что в RU.LINUX ее всегда по-доброму чморили как "Секреты Армстронга младшего от Армстронга старшего").
Книга - настоящая инструкция, как стать из начинающего уверенным power-user. В частности, там есть и отсылка к vimtutor. И даже что-то про богопротивный емакс.
Немет, с другой стороны, - это сборник анекдотов из жизни BAFH, не дающая ни академических знаний (справедливости ради, за академическими знаниями по теме надо идти к Робачевскому либо к англоязычному оригиналу Баха), ни каких-то вменяемых ступенек роста. Пиар да и только.
Можно пойти чуть дальше и предположить, что инженеры знают если не про intent-based config/configuration-as-a-code, то хотя бы 1) умеют в скриптование рутинных задач и 2) понимают, что иметь единую (и не сильно распределенную) точку отказа/притяжения трафика - это куда больший риск, чем удобство.
Справведливости ради, Ekahau* стоит непомерно, чтобы покупать его себе в отдел, а для найма подрядчика с подобным софтом-оборудованием требуется психология чуть сложнее, чем "мы сами с усами".
У меня на памяти был клиент, который заплатил за моделирование с одним ТЗ, а в реальности стенки оказались в других местах (отчасти из других материалов), но точки доступа повесили все равно там, где они были отмечены на картинках. На вопрос, почему не был проведен повторный анализ, ответил "да, мы все понимаем, но вот как-то так". Грустить по таким точно не стоит.
* дешевые аналоги Ekahau настолько же не интересны, как и дешевые аналоги промышленных анализаторов-генераторов трафика: экономии не получается, когда нужны функционал и качество.
Я концептуально не согласен в том, что ранжирование субъективно. Есть best practices, и ZTN - одна из них. Вы, как я понимаю, в консалтинге работаете, если у вас клиент спросит, с чего начать, не будете же рассказывать про субъективность ранжирования рекомендаций.
ZTN в общем - это отсутствие понятия trusted зон, выражающееся в необходимости писать максимально гранулярные правила (в то же время, не доводя это до идиотизма). Про ZTNA я ничего не писал и не слышал.
Не хотите palo alto попробовать? 15 лет работать с фортинетом - это большое увлечение, снимаю шляпу.
>> Эта безопасность через неясность действительно работает
Вы упоминаете неработающее решение первым, а парадигму ZeroTrust одиннадцатой. Хотя в вашей же статье от 2018 года вы поставили пункт "Rules with ANY/ALL in services are almost always a bad idea" существенно выше. Что изменилось за 5 лет?
Неработающим это решение является потому, что вероятность взлома никак не зависит от неизвестности порта - это не подбор хеша длиной 256 бит, это околомгновенное прочесывание 64к портов. Если у вас не установлено стандартного пароля на стандартной учетке, ломай-не хочу.
Можно пример ситуации, когда на 1099 "куда" меньшие налоги, чем на w2? Я поигрался с https://www.viewthenumbers.com/w2-vs-1099 и практически не вижу разницы на диапазоне 100-300к/год. Начальные условия - одинаковый gross.
Если имеется в виду, что контрактор за ту же работу может получать другую почасовую ставку (получать больше gross), то это уже не относится к налогам.
Мы, возможно, по-разному понимаем что такое нормализованная-денормализованная.
Нормализованная - это когда 3НФ и вот это все. Когда в таблице минимум информации, который используется для ВСЕХ записей, а все остальное, что может быть опционально (предпочитаемый напиток из примера выше), выносится в дополнительные таблицы с foreign key (на юзера из примера выше).
Денормализованная - это когда у вас, как у автора поста, 150 полей и вы добавляете 151-ое, потому что ну альтер тейбл же проще, чем таблицы, связи, джойны.
Повторяю, я _не_ топлю за добавление полей. Я против добавления полей просто потому, что так кому-то проще. И не стал бы его делать (кроме случая, когда изначально кривой дизайн с пропущенными ключевыми ОБЯЗАТЕЛЬНЫМИ ВЕЗДЕ полями, но это уже другая история).
Дропнуть-добавить в нормализованной базе? Путем удаления-добавления таблицы с зависимостью по foreign key. Бизнес-логика при добавлении таблиц не страдает совсем, при удалении - сначала надо убрать зависимости из бизнес-логики. Где там будет даунтайм - не вполне понятно, если выдержать паузу на распространение изменения/устаревание кешей. Если добавление происходит с каким-то ненулевым объемом данных, то есть вероятность какой-то деградации на время добавления - тут, опять же, поможет DBA - как в качественно-количественной оценке рисков, так и в собственно работе.
Дропнуть-добавить в денормализованной - это вы не у того человека спрашиваете, я за такие решения/дизайны не агитирую :)
Это вопрос про дизайн и про размер базы (число юзеров). Если юзеров 100 и будет 1000 ближе к тепловой смерти вселенной, то нормализация не нужна. Хотя я не понимаю такой аллергии по отношению к нормальным таблицам. Пример кстати говорящий - если у юзера 150 полей, то, по вашей же логике, это проектировал синьор.
А вот если в соседней таблице лежит полная история использования какого-то частоиспользуемого ресурса этими пользователями, и число строк в той таблице измеряется, например, сотнями миллионов, то придется задуматься и о размере индекса, и о минимизации длины самой записи.
Повторюсь, если у вас в базе 10 связанных таблиц, и как программисту вам приходится делать селект с 33 иннер-аутер-лефт-райт джойнами, обмазываясь констрейнтами и развивая себе абстрактное мышление до визуального представления 11-мерного пространства, синьор в данном случае - это вы. Миддл бы посоветовался с DBA и сделал встроенную функцию. Причем запрос для нее и профайлинг вполне сделает DBA на радостях, что хоть кто-то решил сделать решение не через зад. И да, под каждый запрос - функция. Нужно новое представление в программе - новая функция в базе. Это просто.
Это она, и она гуглится сходу прямо. Еще можно купить англоязычный оригинал Баха (я ниже привел ISBN).
К слову, Кетов читал в том числе по Робачевскому.
Робачевский 978-5-94157-538-1 - сходу гуглится в интернете (или оригинал Баха ISBN-13 978-0132017992).
Это проблема, но, тем не менее, я не встречал за свою карьеру книг, подходящих близко к потенциалу Арсмтронга (это при том, что в RU.LINUX ее всегда по-доброму чморили как "Секреты Армстронга младшего от Армстронга старшего").
Книга - настоящая инструкция, как стать из начинающего уверенным power-user. В частности, там есть и отсылка к vimtutor. И даже что-то про богопротивный емакс.
Немет, с другой стороны, - это сборник анекдотов из жизни BAFH, не дающая ни академических знаний (справедливости ради, за академическими знаниями по теме надо идти к Робачевскому либо к англоязычному оригиналу Баха), ни каких-то вменяемых ступенек роста. Пиар да и только.
Не надо читать Немет, читайте Армстронга:
https://festima.ru/docs/368019289/allrussia/dzheims-armstrong-sekrety-unix-2-e-izdanie
> 1. Хлопок растёт там, где тепло.
> 2. В Англии холодно.
Ответ узбека, что он не знает, - единственно правильный.
Подсказка: даны ли в условиях задачи отношение хлопка к холоду либо эксклюзивность роста в тепле?
Можно пойти чуть дальше и предположить, что инженеры знают если не про intent-based config/configuration-as-a-code, то хотя бы 1) умеют в скриптование рутинных задач и 2) понимают, что иметь единую (и не сильно распределенную) точку отказа/притяжения трафика - это куда больший риск, чем удобство.
Справведливости ради, Ekahau* стоит непомерно, чтобы покупать его себе в отдел, а для найма подрядчика с подобным софтом-оборудованием требуется психология чуть сложнее, чем "мы сами с усами".
У меня на памяти был клиент, который заплатил за моделирование с одним ТЗ, а в реальности стенки оказались в других местах (отчасти из других материалов), но точки доступа повесили все равно там, где они были отмечены на картинках. На вопрос, почему не был проведен повторный анализ, ответил "да, мы все понимаем, но вот как-то так". Грустить по таким точно не стоит.
* дешевые аналоги Ekahau настолько же не интересны, как и дешевые аналоги промышленных анализаторов-генераторов трафика: экономии не получается, когда нужны функционал и качество.
Не могли бы вы перечислить плюсы централизованной коммутации вайфай траффика и минусы локальной коммутации его же?
Хочу обратить внимание читателя, что ни Mist (J), ни Mojo (A) траффик через центральную точку не гоняют.
Почему бы в 2023 году не использовать решения, не гоняющие трафик через контроллер(ы)?
Так не делает разве что та часть стрелков, которая не знает, зачем держать глаза открытыми.
То, что большинству этому надо учиться, бесспорно.
Re:Статья 2018 года: https://www.linkedin.com/pulse/tips-best-practices-caring-your-fortigate-firewalls-yuri-slobodyanyuk/?trackingId=BSOUTSA%2BS7%2BN3Wb5jw40gw%3D%3D
Я концептуально не согласен в том, что ранжирование субъективно. Есть best practices, и ZTN - одна из них. Вы, как я понимаю, в консалтинге работаете, если у вас клиент спросит, с чего начать, не будете же рассказывать про субъективность ранжирования рекомендаций.
ZTN в общем - это отсутствие понятия trusted зон, выражающееся в необходимости писать максимально гранулярные правила (в то же время, не доводя это до идиотизма). Про ZTNA я ничего не писал и не слышал.
Не хотите palo alto попробовать? 15 лет работать с фортинетом - это большое увлечение, снимаю шляпу.
Для ухода от налогов. В случае, когда руководят и работают идейно-порядочные люди, конечно, это не так, но идейно-порядочные люди - большая редкость.
Если хотите аналогию, то это примерно как профсоюзы: декларируется защита работника, но есть нюанс.
>> Эта безопасность через неясность действительно работает
Вы упоминаете неработающее решение первым, а парадигму ZeroTrust одиннадцатой.
Хотя в вашей же статье от 2018 года вы поставили пункт "Rules with ANY/ALL in services are almost always a bad idea" существенно выше. Что изменилось за 5 лет?
Неработающим это решение является потому, что вероятность взлома никак не зависит от неизвестности порта - это не подбор хеша длиной 256 бит, это околомгновенное прочесывание 64к портов. Если у вас не установлено стандартного пароля на стандартной учетке, ломай-не хочу.
Спасибо за ликбез, надо будет как-нибудь сходить в эту часть жизни и попробовать.
Можно пример ситуации, когда на 1099 "куда" меньшие налоги, чем на w2? Я поигрался с https://www.viewthenumbers.com/w2-vs-1099 и практически не вижу разницы на диапазоне 100-300к/год. Начальные условия - одинаковый gross.
Если имеется в виду, что контрактор за ту же работу может получать другую почасовую ставку (получать больше gross), то это уже не относится к налогам.
Стоило бы сначала вычленить главное слово: "говноконтракт", а не второсперенное "по щелчку".
Контракторы практически не имеют бенефитов, зато имеют срочный контракт. FTE имеют запись в контракте "до 65 лет".
Американский employment at will никто не отменял, но оно работает в обе стороны. Ничего плохого в этом явлении нет.
Не было в моем исходном сообщении про "добавить поле" :)
Мы, возможно, по-разному понимаем что такое нормализованная-денормализованная.
Нормализованная - это когда 3НФ и вот это все. Когда в таблице минимум информации, который используется для ВСЕХ записей, а все остальное, что может быть опционально (предпочитаемый напиток из примера выше), выносится в дополнительные таблицы с foreign key (на юзера из примера выше).
Денормализованная - это когда у вас, как у автора поста, 150 полей и вы добавляете 151-ое, потому что ну альтер тейбл же проще, чем таблицы, связи, джойны.
Повторяю, я _не_ топлю за добавление полей. Я против добавления полей просто потому, что так кому-то проще. И не стал бы его делать (кроме случая, когда изначально кривой дизайн с пропущенными ключевыми ОБЯЗАТЕЛЬНЫМИ ВЕЗДЕ полями, но это уже другая история).
Надеюсь, теперь мы на одной волне.
Дропнуть-добавить в нормализованной базе? Путем удаления-добавления таблицы с зависимостью по foreign key. Бизнес-логика при добавлении таблиц не страдает совсем, при удалении - сначала надо убрать зависимости из бизнес-логики. Где там будет даунтайм - не вполне понятно, если выдержать паузу на распространение изменения/устаревание кешей. Если добавление происходит с каким-то ненулевым объемом данных, то есть вероятность какой-то деградации на время добавления - тут, опять же, поможет DBA - как в качественно-количественной оценке рисков, так и в собственно работе.
Дропнуть-добавить в денормализованной - это вы не у того человека спрашиваете, я за такие решения/дизайны не агитирую :)
Это вопрос про дизайн и про размер базы (число юзеров). Если юзеров 100 и будет 1000 ближе к тепловой смерти вселенной, то нормализация не нужна. Хотя я не понимаю такой аллергии по отношению к нормальным таблицам. Пример кстати говорящий - если у юзера 150 полей, то, по вашей же логике, это проектировал синьор.
А вот если в соседней таблице лежит полная история использования какого-то частоиспользуемого ресурса этими пользователями, и число строк в той таблице измеряется, например, сотнями миллионов, то придется задуматься и о размере индекса, и о минимизации длины самой записи.
Повторюсь, если у вас в базе 10 связанных таблиц, и как программисту вам приходится делать селект с 33 иннер-аутер-лефт-райт джойнами, обмазываясь констрейнтами и развивая себе абстрактное мышление до визуального представления 11-мерного пространства, синьор в данном случае - это вы. Миддл бы посоветовался с DBA и сделал встроенную функцию. Причем запрос для нее и профайлинг вполне сделает DBA на радостях, что хоть кто-то решил сделать решение не через зад. И да, под каждый запрос - функция. Нужно новое представление в программе - новая функция в базе. Это просто.
p.s. я не DBA и никогда им не был.