Статья о крайностях, в которые нередко попадают разработчики или менеджеры, отсекая от себя смежную облать знаний за туман войны. Всё же понять визави — это первый шаг к принятию)
Если не ошибаюсь, Сбер запустил в пилотном режиме оплату билета пластиковой картой. На метро Ленинский проспект я терминал видел и даже оплачивал там билет.
Есть ещё немаловажный момент — Excel очень распространен в корпоративной среде за счёт вхождения в пакет MS Office. Зачастую, это единственный инструмент, который есть в распоряжении практически у всех. И вот начинается цирк с конями: кто-то за счет макросов и\или Access-а начинает превращать Excel в монстра, кто-то распарсивает огромные файлы опять же в Excel-формат и с ними уже работает и тд. Другими словами, Excel, при всех своих недостатках, часто единственное решение проблем.
Лично я вижу решение этих проблем бизнеса в своем маленьком отделе разработки, который взаимодействует напрямую с бизнесом и пилит их реализую бизнес-процесса. Почему этот вариант? Бизнес иногда настолько многогранен, что натягивать на ERP/СRM или еще какую систему выходит дороже и дольше, чем проще посчитать в экселях.
Тут ответ можно в целый пост развернуть. Если кратко — «да, вы правы». Нужно решить задачу. Это есть краеугольный камень жизнедеятельности разработчика или айтишника в целом. Ведь кормит меня не технология, а решенные с её помощью задачи. Столяра не кормит молоток, его кормит проданный стул, художника не кормит кисть — его кормит проданная картина. Надеюсь аналогия и мысль понятны в сумбурности моего изложения.
Видимо до мысли «задачеориентированного» программирования вы не додумались пока? Вступление в холивар и разбор вашего крайне спорного утверждение по косточкам — есть тлен и не ведет к уменьшению энтропии.
Статья про веб от программиста на сях, и без всякой ненависти в сторону PHP… Удивительные вещи происходят!
На мой субъективный взгляд, пользоваться трейсом (print_r, var_dump) в PHP выходило более продуктивней что ли. Всегда под рукой все переменные окружения, локальные и глобальные массивы, вывод вёрстки. Или я таки не умею правильно готовить дебаггер…
Отладка клиентсайда, лучший выбор — божественный Firebug под Firefox, под него же есть и отладочные модули серверного кода — FirePHP.
И да, я понимаю, что руки до фреймворков у вас вряд ли дойдут, но они скрывают в себе огромную уйму полезного, в том числе и коннекторы к социалочкам.
Существуют владельцы активов или процессов. Задача ИБ оценить актив и предоставить владельцу актива, сопутствующие этому активу риски. Объяснить ему на пальцах, что будет при этом, этом и этом.
В теории, теория и практика — это одно и то же. Но на практике это совершенно разные вещи. Раздутые из мухи в дирижабль риски, которые представляются на оценку топ-менеджменту, да еще оформленные казённым языком, провоцируют у оного лютое чувство паранойи. («Давайте запретим пользователям запускать все (!) экзешники на компьютере. Все экзешники, всем пользователям. Ведь это несет риск запуска на компьютере вируса, а вирус может увести ВСЮ КЛИЕНТСКУЮ СИСТЕМУ». Утрирую немного, но как на это должен реагировать топ-менджмент?
Я долгое время думал над тем, как можно сдвинуть эту систему хотя бы в уровень адекватного. Общая мысль проста — не нужно грести всех под одну гребенку, и уборщицу и системного архитектора. Без корреляции скажем так роли, или access rules, для разных сотрудников ИБ на предприятии является тем, чем она есть. Плюс ко всему имеет место быть и обычная лень, когда безопаснику лень разбираться во всех хитрослетениях системы, чтобы адекватно составить правила доступа. А если этих систем еще и в несколько раз больше, чем безопасников — то система просто ступорится и всё, аллес.
Верно. Это не романтизированный образ «анти-хакера», который отбивается от атак АсидБёрнов и КрэшОверрайдов. Это больше склочный, бюрократический образ обиженного недооценённого сотрудника, который делает сизифов труд и никто его, по большому счёту, в рассчёт особо не берет. Всем нужно делать своё дело, работу работать, а не блюсти бесконечные нормы безопасности, и из-за эффекта недооценнёности они рожают тысячи нормативных актов и норм, чтобы хоть количеством добиться «услышимости».
Хороший вопрос. Если проект не подпадает под явные зоны ответственности ИБ, то его вроде как и вносить в список угроз не нужно. Соответственно, ответственность за угрозу (которой вроде как и нет, данные-то несекурные), переходит к преемнику бравшего ответственность, как и всё другое «наследство».
Поясню на примере. Есть идея реализовать %фичанейм%, которая повысит %оченьважныйKPIнейм%. При этом данные, которыми предполагается вертеть не представляют никакой угрозы безопасности, ни какое-нибудь там 152-ФЗ или, прости господи, PCI DSS. Однако к этой реализации применяются те же самые меры, как и для всего остального — гибкости то нет, нормативы один, гребенка одна. И вот в этом случае, дабы безопасность не упарывалась на согласованиях, руководитель кастует заклинание «Принимаю риски». И всё. Безопасники имеют виноватого на случай ЕСЛИ что-то произойдет, бизнес имеет свою фичу и никто из этих двух не имеет геморрой.
По пунктам 1 и 2, ИБ в этом случае тоже не несет ответственности, но виноватого ищет и найдет. И анархию можно контролировать, контролируя опорные точки и сверхважные инфраструктурные цели, к которым вряд ли относятся десктопы менеджеров.
Бывали казусы, когда согласование с ИБ занимало время, превосходящее в несколько раз время на проектирование, разработку и внедрение проекта. Делают проект на хостинге\локальном компе\наручных часах, а после обкатки и тестирования уже выводят в поле полки для борьбы с IT и ИБ.
Лично я вижу решение этих проблем бизнеса в своем маленьком отделе разработки, который взаимодействует напрямую с бизнесом и пилит их реализую бизнес-процесса. Почему этот вариант? Бизнес иногда настолько многогранен, что натягивать на ERP/СRM или еще какую систему выходит дороже и дольше, чем проще посчитать в экселях.
На мой субъективный взгляд, пользоваться трейсом (print_r, var_dump) в PHP выходило более продуктивней что ли. Всегда под рукой все переменные окружения, локальные и глобальные массивы, вывод вёрстки. Или я таки не умею правильно готовить дебаггер…
Отладка клиентсайда, лучший выбор — божественный Firebug под Firefox, под него же есть и отладочные модули серверного кода — FirePHP.
И да, я понимаю, что руки до фреймворков у вас вряд ли дойдут, но они скрывают в себе огромную уйму полезного, в том числе и коннекторы к социалочкам.
В теории, теория и практика — это одно и то же. Но на практике это совершенно разные вещи. Раздутые из мухи в дирижабль риски, которые представляются на оценку топ-менеджменту, да еще оформленные казённым языком, провоцируют у оного лютое чувство паранойи. («Давайте запретим пользователям запускать все (!) экзешники на компьютере. Все экзешники, всем пользователям. Ведь это несет риск запуска на компьютере вируса, а вирус может увести ВСЮ КЛИЕНТСКУЮ СИСТЕМУ». Утрирую немного, но как на это должен реагировать топ-менджмент?
обиженногонедооценённого сотрудника, который делает сизифов труд и никто его, по большому счёту, в рассчёт особо не берет. Всем нужно делать своё дело, работу работать, а не блюсти бесконечные нормы безопасности, и из-за эффекта недооценнёности они рожают тысячи нормативных актов и норм, чтобы хоть количеством добиться «услышимости».По пунктам 1 и 2, ИБ в этом случае тоже не несет ответственности, но виноватого ищет и найдет. И анархию можно контролировать, контролируя опорные точки и сверхважные инфраструктурные цели, к которым вряд ли относятся десктопы менеджеров.