C. G. Bell, W. D. Strecker, “Computer What Have We Learned from the PDP-11,” The 3rd Annual Symposium on Computer Architecture Conference Proceedings, pp. l-14, 1976.
Эта статья, которую я выбрал сегодня, является ретроспективой компьютерного дизайна. Это одна из ряда статей Гордона Белла с различными соавторами, описывающей разработку, рост, и внезапную замену культовой линейки продуктов компании, миникомпьютеров PDP-11.
Читать полностью »
Автор: Денис Цыплаков, Solution Architect, DataArt
В DataArt я работаю по двум направлениям. В первом помогаю людям чинить системы, сломанные тем или иным образом и по самым разным причинам. Во втором помогаю проектировать новые системы так, чтобы они в будущем сломаны не были или, если говорить реалистичнее, чтобы сломать их было сложнее.
Если вы не делаете что-то принципиально новое, например, первый в мире интернет-поисковик или искусственный интеллект для управления запуском ядерных ракет, создать дизайн хорошей системы довольно просто. Достаточно учесть все требования, посмотреть на дизайн похожих систем и сделать примерно так же, не совершив при этом грубых ошибок. Звучит как чрезмерное упрощение вопроса, но давайте вспомним, что на дворе 2019 год, и «типовые рецепты» дизайна систем есть практически для всего. Бизнес может подкидывать сложные технические задачи — скажем, обработать миллион разнородных PDF-файлов и вынуть из них таблицы с данными о расходах — но вот архитектура систем редко отличается большой оригинальностью. Главное тут — не ошибиться с определением того, какую именно систему мы строим, и не промахнуться с выбором технологий.
В последнем пунктом регулярно возникают типичные ошибки, о некоторых из них я расскажу в статье.Читать полностью »
Колодой, если верить писателям, раньше называлась «команда», которую набирал себе вор. У каждого человека в команде была своя «масть» — специализация и назначение. Вот что пишет об этом Борис Акунин в книге «Любовник смерти»:
«Пацаны рассказывали, что у настоящих деловых, кто по законам живет, шайка „колодой“ называется, и в каждой колоде свой кумплект. Кумплект — это восемь фартовых, каждый при своем положении. Главный — »король"; при нем маруха, по-деловому «дама»; потом «валет» — вроде как главный помощник; ну и прочие бойцы, от десятки до шестерки. А больше восьми человек в шайке не держат, так уж исстари заведено."
Меньше восьми людей брать смысла нет, будут пробелы в «компетенциях». Больше — нельзя, будет дублирование и потеря управляемости.
Как ни странно, тот же Джефф Сазерленд, один из авторов скрама, называл похожие цифры — от 5 до 9 человек. Хотя и не уточнял специализацию.
Ну да ладно. А мы продолжаем тему построения команд по ролям, на основе тестов Белбина.Читать полностью »
This year, a theatre production series called Tale of the Century was launched in Estonia. Throughout the year, 22 local theatres presented their interpretations of the past hundred years of Estonian history to the audiences. In the draw, the Russian Theatre was assigned the topic of the future of Estonia.
Итак, мы уже определились с областью применения, методологией и архитектурой. Перейдем от теории к практике, к написанию кода. Хотелось бы начать с шаблонов проектирования, которые описывают бизнес логику — Service и Interactor. Но прежде чем приступить к ним, изучим структурные паттерны — ValueObject и Entity. Разрабатывать мы будем на языке ruby. В дальнейших статьях разберем все паттерны, необходимые для разработки с использованием Вариативной архитектуры. Все наработки, являющиеся приложениями к данному циклу статей, соберем в отдельный фреймворк.
И мы уже подобрали подходящее название — LunaPark.
Текущие наработки выложенны на Github.
Разобрав все шаблоны, соберем один полноценный микросервис.
There are a lot of posts about what a typical coding interview at Google looks like. But, while not as widely described and discussed, there is also quite often a system design interview. For an SRE position it’s NALSD: non-abstract large system design. The key difference between SWE and SRE interviews consists in these two letters: NA.
So, what is the difference? How to be prepared for this interview? Let’s be non-abstract, and use an example. To be more non-abstract, let’s take something from the material world, such that you won’t be asked the exact same thing at the real interview (at least, not at the Google interview) :)
So, let’s design a public library system. For the paper books, like you have seen everywhere around. The whole text below was written all at once within around one hour, to roughly show you the areas that you should be able to cover / touch during the interview. Please excuse some disorder, that’s how I think (therefore I am).
Читать полностью »
Ускользает понимание своего или чужого кода?
Не можете вникнуть в алгоритм?
Проводите кучу время в отладке, но найти место неверной инициализации не получается, а хочется получать удовольствие от кодирования?
Вспомните о приведенных ниже правилах и примените их!
В статье не рассматриваются базовые правила именования переменных и функций, синтаксические отступы и масштабная тема рефакторинга. Рассматриваются 5 простых правил по упрощению кода и снижению нагрузки на мозг в процессе разработки.
Рассмотрим процесс восприятия данных, чтобы соотнести описанные правила с процессом восприятия и определить критерии простого кода.
Упрощенный процесс восприятия состоит из следующих этапов:
Я описывал ранее типичное кодинг-интервью. Помимо кодинга почти всегда есть вопрос на проектирование систем. (Large) System Design. В случае собеседований на SRE, это еще более интересный (как по мне) зверь — NALSD. Non-abstract large system design. Главное отличие между SWE и SRE именно в этих буковках “NA”.
В чем же отличие, и как подготовиться к нему? Давайте разберём на примере. В качестве примера возьмём что-то весьма материальное, что-то такое, что точно никто никогда не спросит на реальном собеседовании (в гугл) :)
Например — давайте спроектируем библиотеку. Для бумажных книг, обычную такую. Весь текст ниже был написан в один присест за примерно час, чтобы примерно показать что можно успеть, и что важно успеть. Так что уж простите за сумбурность, но я так мыслю (а значит, так существую).
Читать полностью »
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Читать полностью »
Ключевой проблемой любой организации являются изменения.
Где-то изменений слишком много, или наоборот — слишком мало, а может — нет идей, или есть, но их никто не реализует, или воплощение начинается, но никогда не заканчивается, а зачастую вообще, планируются одни изменения, а получаются другие, во многих же местах просто не замечается сама потребность в изменениях.
Если все эти проблемы объединить под одним словом, то словом этим будет «изменения». Именно с ними и проблемы. Тут вроде ничего доказывать не надо, все на поверхности лежит, но на всякий случай пару тезисов приведу.
Если у вас проблемы с продажами, вам нужны изменения. Очевидно? Вроде да. Или продукты продаете не те, что нужны рынку, или их слишком мало, или слишком много, или сроки срываете, или качество — недопустимо низкое, или продавцы хамят клиентам – неважно, это причины. Чтобы эти причины перестали оказывать влияние на систему продаж, нужны изменения.
Если у вас проблемы со снабжением, то вам нужны изменения. Очевидно? Вроде да. Или поставщиков других надо найти, или заказы формировать почаще, или, возможно, пореже, или партии уменьшить, или логистику улучшить, или перестать наемным транспортом пользоваться, или начать наемным транспортом пользоваться. Не так важно, что именно надо изменить, но что-то изменить — надо.
Если у вас проблемы с автоматизацией, то вам нужны изменения. Очевидно? Вроде да. Или платформу сменить, или программный продукт другой взять, или программистов нанять, или программистов разогнать, или порядочного аутсорсера найти (ха-ха), или перестать пользоваться колхозным интегратором и нанять федерального, или послать федералов и найти в своей деревне увлеченного фаната, или пересмотреть управление ИТ-отделом, или изменить мотивацию программистов. Не важно, что именно, но что-то надо менять.Читать полностью »
