Давным-давно в одной далёкой-далёкой... проекте, понадобилось мне сделать обработку http-запросов на Netty. К сожалению, стандартных удобных механизмов для маппинга http-запросов в Netty не нашлось (да и этот фреймвёрк совсем не для того), поэтому, было решено реализовать собственный механизм.
Рубрика «Анализ и проектирование систем» - 48
Маппинг запросов на Netty
2019-01-12 в 19:02, admin, рубрики: java, mapping requests, netty, open source, rest, Анализ и проектирование систем, высокая производительность, ПрограммированиеКурс MIT «Безопасность компьютерных систем». Лекция 23: «Экономика безопасности», часть 2
2019-01-12 в 12:33, admin, рубрики: Анализ и проектирование систем, Безопасность компьютерных систем, бесопасность, Блог компании ua-hosting.company, информационная безопасность, ПрограммированиеМассачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год
Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.
Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3
Лекция 15: «Медицинское программное обеспечение» Часть 1 / Часть 2 / Часть 3
Лекция 16: «Атаки через побочный канал» Часть 1 / Часть 2 / Часть 3
Лекция 17: «Аутентификация пользователя» Часть 1 / Часть 2 / Часть 3
Лекция 18: «Частный просмотр интернета» Часть 1 / Часть 2 / Часть 3
Лекция 19: «Анонимные сети» Часть 1 / Часть 2 / Часть 3
Лекция 20: «Безопасность мобильных телефонов» Часть 1 / Часть 2 / Часть 3
Лекция 21: «Отслеживание данных» Часть 1 / Часть 2 / Часть 3Читать полностью »
Курс MIT «Безопасность компьютерных систем». Лекция 23: «Экономика безопасности», часть 1
2019-01-11 в 17:00, admin, рубрики: Анализ и проектирование систем, Безопасность компьютерных систем, бесопасность, Блог компании ua-hosting.company, информационная безопасность, ПрограммированиеМассачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год
Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.
Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3
Лекция 15: «Медицинское программное обеспечение» Часть 1 / Часть 2 / Часть 3
Лекция 16: «Атаки через побочный канал» Часть 1 / Часть 2 / Часть 3
Лекция 17: «Аутентификация пользователя» Часть 1 / Часть 2 / Часть 3
Лекция 18: «Частный просмотр интернета» Часть 1 / Часть 2 / Часть 3
Лекция 19: «Анонимные сети» Часть 1 / Часть 2 / Часть 3
Лекция 20: «Безопасность мобильных телефонов» Часть 1 / Часть 2 / Часть 3
Лекция 21: «Отслеживание данных» Часть 1 / Часть 2 / Часть 3Читать полностью »
«Надежность и безотказность как в Google» — и не только: перевод статьи «Расчёт надёжности сервиса»
2019-01-11 в 5:13, admin, рубрики: devops, Google, slo, sre, Анализ и проектирование систем, Блог компании ITSumma, системное администрирование
Главная задача коммерческих (да и некоммерческих тоже) сервисов — быть всегда доступными для пользователя. Хотя сбои случаются у всех, вопрос в том, что делает IT-команда для их минимизации. Мы перевели статью Бена Трейнора, Майка Далина, Вивек Рау и Бетси Бейер «Расчёт надёжности сервиса», в которой рассказывается, в том числе, на примере Google, почему 100% — неверный ориентир для показателя надежности, что такое «правило четырёх девяток» и как на практике математически прогнозировать допустимость крупных и мелких отключений сервиса иили его критических компонентов — ожидаемое количество простоя, время обнаружения сбоя и время восстановления сервиса.
Воронка изменений
2019-01-08 в 16:55, admin, рубрики: Анализ и проектирование систем, Карьера в IT-индустрии, управление изменениями, Управление продуктом, управление проектамиЧего воду в ступе толочь, вступления писать, сразу к делу.
Первый слой – кто хочет?
Многие из нас хотят что-то изменить в своем отделе, или компании, или даже в отрасли — профессиональной, например. Я это знаю, потому что давно наблюдаю и общаюсь — как в нашем кругу, так и в других, не связанных с программистами и вообще ИТ.
Но до реальных изменений дело доходит крайне – крайне редко. Это, наверное, даже не единицы процентов, а доли одного процента. Почему так?
Если собрать всех – например, программистов – и спросить: кто хочет что-то изменить в отделе, компании или отрасли? – то руки поднимут больше половины. Почему до конца, до реальных изменений, полезных и заметных, доходят эти несчастные доли? Где, и почему теряются остальные?
Этот процесс чем-то напоминает воронку, как в продажах. Помните же воронку продаж? Она показывает, сколько обращений переходят в деньги. Выглядит примерно так:
Ой, не то. Вот так:
Попробуем разобраться — кто, где отвалился и почему.
Итак, первый, самый широкий слой воронки – те, кто поднял руку.Читать полностью »
Как поделить архитектуру и реализацию и не поругаться
2019-01-08 в 10:59, admin, рубрики: Анализ и проектирование систем, архитектура, дизайн кода, Программирование, проектирование, Проектирование и рефакторинг, управление разработкойСоздание новой системы — многоэтапный процесс: проработка концепции и дизайна, проектирование архитектуры, реализация, тестирование, релиз. Проектирование архитектуры и реализация — это те этапы, которыми в первую очередь занимаются разработчики.
Большинство разработчиков любят заниматься архитектурой, продумывать как система или её часть будет устроена с чистого листа. Если тот, кто продумал архитектуру системы, и будет её реализовывать, никаких проблем с мотивацией нет: программист получит удовлетворение от воплощения в жизнь задуманных им идей. Но если архитектуру продумал один, а реализацией будет заниматься другой, то у последнего может возникнуть естественное возмущение: все продумали за меня, а мне только делать по написанному?
О том, как избежать таких ситуаций, почему реализация может быть не менее интересной, чем проработка архитектуры, а иногда и более, речь пойдет в этой статье.
Патологическая анатомия на производстве
2019-01-07 в 17:11, admin, рубрики: Анализ и проектирование систем, Карьера в IT-индустрии, управление качеством, управление персоналом, Управление продуктомПродолжаем тему управления качеством, начало здесь.
Что такое качество – допустим, разобрались, это степень соответствия требованиям потребителя. Вы, возможно, не согласны, по крайней мере с моей категоричностью, но вроде явных ляпов в этом определении нет.
Определение — понятно, но для управления качеством этого недостаточно. Это какая-то базовая, фундаментальная ценность, цель системы, а не руководство к действию. Что делать-то надо?
На что направить свои усилия, чтобы повысить качество? И качество чего надо повысить? Все слышали, что есть качество продукта, а есть – качество процесса. В чем разница? Что важнее?
А может, усилия надо направить на требования потребителя? Оставить качество на месте, а потребителя убедить, что его требования не обоснованы, и ему совсем другое нужно – не то, что он просит. Например, убедить покупателя, что колбаса из курицы – лучше, чем колбаса из мяса. Несложно ведь? Курица – диетическая, жира меньше, легче усваивается, да и стоит дешевле. Если убедить в этом покупателей, то они изменят свои требования, и качество продукта резко возрастет.
Это что такое получится? Управление качеством? В конечном итоге – да, но путь немного странный. Мы не качеством управлять будем, а требованиями. Есть вроде такая область знаний – управление требованиями? В ИТ, в частности. Хотя, если посмотреть телевизор, там только и занимаются, что управлением требованиями – кажется, это «пропагандой» называется.
Попробую рассказать то, что я успел узнать за свою жизнь про «нормальное» управление качеством.Читать полностью »
Не лечите меня, доктор
2019-01-06 в 15:59, admin, рубрики: Анализ и проектирование систем, Карьера в IT-индустрии, управление качеством, Управление продуктомКогда собирали доклады на голосование для участия в одной специализированной конференции, я хотел рассказать такую тему – как подсидеть директора по качеству. Это был бы конъюнктурный доклад про карьерный рост для программиста или ИТ-директора.
С одной стороны, рост в сторону директора по качеству кажется странным – это вроде совсем другая область. Но, как мы все уже знаем, из программиста может вырасти дофига чего интересного. Это не только я говорю – такая мысль звучит все чаще. Например, на той же конференции другого года был доклад на эту тему — как на западе ИТ-директора уходят в операционный менеджмент, не связанный с ИТ.
Тема управления качеством лично мне кажется невероятно, просто ужасно интересной и безумно полезной. Не потому, что управление качеством – как новый сезон Шерлока или тряхнувшего стариной Джека Бауэра. Просто управление качеством в нашей стране – это пример исключительно наглого, циничного, элементарного, тупейшего, и оттого удивительно эффективного шарлатанства.
Я не знаю ни одной другой отрасли знаний, в которой трудилось бы такое же количество людей, ничего не понимающих в своей профессии. Это не шутка, не гипербола. Я наблюдаю за этими ребятами больше 15 лет — еще с тех пор, когда сертификат ISO еще был престижной редкостью. Я работал с директорами по качеству и специалистами, консультантами и аудиторами, преподавателями ВУЗов и президентами ассоциаций, студентами и аспирантами. Сколько из них, по-вашему, знают и понимают, что такое управление качеством и как его осуществлять? А, вы же знаете, я выше написал – ноль. Ладно, пусть будет 1 % — наверняка где-то, случайно, или волею небес, есть люди, которые что-то понимают. Ну и вы, если внимательно и без предубеждения отнесетесь к управлению качеством, тоже будете понимать. Так, может, и до 2% дотянем.Читать полностью »
Кровососы. Классификация программиста
2019-01-05 в 9:39, admin, рубрики: Анализ и проектирование систем, Карьера в IT-индустрии, менеджеры, управление персоналом, управление проектамиКто такие руководители, и зачем они нужны? Какая от них в жизни польза? Чем они вообще занимаются? А чем они должны заниматься?
С одной стороны, традиционно руководитель понимается как тот, кто управляет – строит планы, дает указания, контролирует сроки, орет громче всех, принимает решения и несет за них ответственность.
С другой стороны, есть мнение, что руководитель должен заниматься только развитием вверенного подразделения, не принимая участия в оперативном управлении.
С третьей стороны, есть самоуправление и бирюзовые организации, которые на практике доказали, что такая сущность, как руководитель, не нужна вовсе – это просто набор обязанностей, ролей и контрольных точек, которые легко размазываются между разными людьми.
Так кто же он такой, этот руководитель, и зачем он нужен? Руководитель нужен компании или компания нужна руководителю, как источник дохода? Может, он просто оправдывает свое существование, ведь результат того стоит – доходы руководителей зачастую несопоставимо выше, чем доходы обычных сотрудников.
Я использую специальную модель для оценки руководителей, с которой вам и предлагаю ознакомиться.Читать полностью »
Сергей и научный метод
2019-01-04 в 14:35, admin, рубрики: Анализ и проектирование систем, сергей, Читальный залВсе совпадения случайны.
Кто не спрятался, я не виноват.
— Проходи, что стоишь как не родной?
Сергей огляделся — в квартире своего учителя-профессора он еще не бывал. Обыкновенная московская, в старом доме — видимо, еще с тех времен, когда их выдавали… или не выдавали, черт его знает, он-то эти времена уже не застал. Бардак конечно, но рабочий — повсюду книги и распечатки каких-то статей. Похоже, профессор продолжает вести активную научную работу, несмотря на свой возраст…
Читать полностью »