Рубрика «архитектура» - 17

Доброго времени суток, уважаемые читатели Хабра. Представляю вашему вниманию цикл статей «Мамкин архитектор». В нем я постараюсь отразить личное мнение относительно построения гибких архитектур. Попутно объясню, как это пригодится менеджерам и поможет разработчикам укрепить основные понятия.

image


В этой статье речь пойдет о «творческом подъеме», «творческом спаде» и о покерном понятии «тильт». Последнее отлично отражает состояние разработчика в тех или иных состояниях предметной модели в разрезе программной архитектуры. Опус пригодится:

  1. Менеджерам, решающим вопросы от разработчиков вроде «давайте все закопаем и переделаем».
  2. Прикладным разработчикам, которым будет интересно заглянуть за броню инкапсуляции тщательно выстроенной (или хаусе) предметной модели в концептуальном ее виде.
  3. Архитекторам или дизайнерам системы будет интересен мой опыт внедрения, поддержки и удержания предметной модели в концептуальных контурах.

Читать полностью »

Matthias Noback (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомиться в оригинале). Перевод второй — по ссылке. И так как он вызвал БЕШЕННЫЙ ажиотаж(целых ДВА человека подискутировали со мной в комментах), то не перевести третью было бы преступлением.

В предыдущей статье мы обсудили разумную систему расслоения проекта, состоящую из трех слоёв:

  • Домен
  • Прикладной слой
  • Инфраструктура

Сейчас, подробно рассмотрим инфраструктурный слой.

Читать полностью »

Перевод статьи Кена Ширриффа.

Почти каждый смартфон использует процессор на основе чипа ARM1, представленного в 1985 году. Более десяти миллиардов ядер ARM было использовано в различных гаджетах, включая один из самых больших провалов Apple, карманный компьютер Newton, и один из самых оглушительных её успехов — iPhone. В этой статье мы рассмотрим ключевые части процессора ARM1: опишем общую структуру чипа, посмотрим на то, как устроены транзисторы и как они функционируют, взаимодействуя друг с другом для хранения и обработки данных, а также взглянем на визуальную симуляцию этого микропроцессора и узнаем, что происходит внутри ARM1 во время его работы.

image

Обзор микросхемы ARM1

Читать полностью »

Как в 2009 году мы начали строить облако, и где ошиблись - 1

В октябре 2009-го мы всё перепроверили. Надо было строить дата-центр на 800 стоек. На основании нашей интуиции, прогнозов по рынку и американской ситуации. Вроде как звучало логично, но было страшновато.

Тогда «облачных» вычислений в России не было, как и облачных хостингов. Собственно, и само слово-то почти не использовалось на рынке. Но мы уже видели по Америке, что там подобные инсталляции пользуются спросом. У нас были за плечами большие проекты создания HPC-кластеров для авиаконструкторов на 500 узлов, и мы верили, что облако — это такой же большой вычислительный кластер.

Наша ошибка была в том, что в 2009 году никто не думал, что облака будут использоваться для чего-то, кроме распределенных вычислений. Всем нужно процессорное время, думали мы. И начали строить архитектуру так, как строили HPC-кластеры для НИИ.

Знаете, чем принципиально такой кластер отличается от современных облачных инфраструктур? Тем, что у него очень мало обращений к дискам и всё чтение более-менее последовательное. Задача ставится одна, разбивается на куски, и каждая машина делает свой кусок. На тот момент никто не брал серьезно в расчет, что профиль нагрузки на дисковую подсистему для HPC-кластеров и облака принципиально разный: в первом случае это последовательные операции чтениязаписи, во втором — полный рандом. И это была не единственная проблема, с которой нам пришлось столкнуться.
Читать полностью »

В 2017 году Matthias Noback (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомитсья в оригинале). Переводом второй является данная статья. Перевод третьей будет доступен в скором времени.

Для меня, одним из обязательных требований, к "чистой" архитектуре, является грамотное разделение кода приложения по слоям. Сам слой не делает ничего, вся соль в том, как он используется и какие ограничения накладываются на компоненты, ему принадлежащие. Давайте немного пофилософствуем, перед тем как рассмотреть конеретные практические приемы.

Читать полностью »

Перевод ироничного поста из блога Боба Мартина в котором он рассуждает о том, насколько неудачным является использование слова interface в современных языках программирования, и какую путаницу и проблемы оно несёт разработчикам.

— Что ты думаешь об интерфейсах?

Имеешь в виду интерфейсы в Java или C#?

— Да. Классная фича этих языков?

Просто великолепная!

— Правда? А что такое интерфейс? Это то же самое что и класс?

Ну… Не совсем!

Читать полностью »

Я сетевой архитектор, и меня это беспокоит - 1
Порты на коммутаторе в нашем нашем дата-центре

Основа работы сетевого архитектора на *aaS-проектах — это как строить здание, которое эволюционирует. Вроде была пятиэтажка, когда построили четыре этажа, стало надо делать ещё 21, потом понадобилось пристроить домики, соединённые туннелями под землёй, а потом всё это должно стать огромным жилым комплексом с крытым двориком. И ещё там внутри жильцы, и им нельзя перекрывать канализацию, водопровод и подъезды.

Ну и да. А ещё есть текущие проблемы стандартов сетей (отставших от реальных требований на лет десять). Чаще всего это означает выдумывание хитрых велосипедов вместо того, чтобы применять очевидные, казалось бы, решения. Но велосипеды есть везде, конечно.
Читать полностью »

Мы постоянно сталкиваемся с системами, созданными другими людьми. Будь то UI приложений в смартфоне или облачные инфраструктуры современного Интернета — именно процесс взаимодействия определяет наши ощущения, впечатления, и в конечном счёте — отношение к технологии. Мы можем быть в роли инженеров, разработчиков или простых пользователей — user experience важен везде. Вокруг систем с хорошим UX образуется общество счастливых, довольных и продуктивных людей; плохой UX приводит только к боли и страданиям.

Даже если специально не отдаешь себе отчёт, то создавая новый софт, обязательно создаешь user experience. Когда код уже написан, с ним начинают взаимодействовать люди. Может быть, это разработчики из твоей команды. Может, это мобильные разработчики, пытающиеся использовать твой API, или сисадмины, на ночном держурстве пытающиеся разобраться, почему всё сломалось. Сами примеры могут быть совершенно различными по сути, но к ним применимы общие принципы. В этом хабропосте мы поговорим об идеях по поводу UX, дизайна API, психологии обучения, и других связанных областей. Рассмотрим применение хороших практик на самых разных уровнях разработки приложений. Что бы ты ни делал — писал базы данных, библиотеки, hypermedia API или мобильные приложения — рано или поздно кто-то прикоснется к твоему коду — и пусть уж он получит от этого удовольствие, верно?

Читать полностью »

Почему мы не стали делать идеально: как менялась инфраструктура серверов War Robots - 1

Первый прототип (например, игры в новой для вас нише) часто делается «на коленке» из палок и самизнаетечего. Причем палки, как правило, тоже из этого самизнаетечего. И на то есть несколько причин.

Во-первых, от неудачной идеи будет не так жалко отказаться. А во-вторых, в погоне за перфекционизмом можно забыть о потребностях конечных пользователей или никогда не закончить работу даже над альфа-версией. Но что, если в вашу «глиняную» повозку стало набираться так много людей, что перестраивать её на ходу уже не кажется такой привлекательной идеей? Примерно это с нами и случилось.

Забегу вперед и расскажу, что сейчас DAU в наших проектах около 1,5 млн. Но так было не всегда.Читать полностью »

Что нужно знать, чтобы стать системным архитектором - 1

Роли в проекте выглядят так:

  1. Аналитик слышит от бизнеса задачу в духе «нам надо работать быстрее» и идёт выяснять, что для этого нужно. Долго ковыряется и узнаёт, например, что производству нужна более простая или прозрачная схема процесса обработки заказов. Обсуждает с командой. Бизнес решает делать. Аналитик бросает в архитектора требованиями к новой системе. Аналитик узнаёт, к чему надо идти.
  2. Архитектор смотрит на требования, смотрит на систему, удивляется, смотрит ещё раз туда-сюда — и после этого ставит точное техническое задание. Архитектор видит, что нужно делать.
  3. Проектировщик — самый счастливый человек. Он берёт требования архитектора и просто лабает их до уровня детального проекта системы. Проектировщик знает, как нужно делать конкретные детали.
  4. Проект-менеджер берёт проект и смотрит, сколько нужно людей, железа, денег и других ресурсов. Делает план работ. ПМ знает, кто будет делать, и сколько это будет стоить.

Потом в обратном порядке проект принимается.

Ещё тут могут участвовать главные инженеры (в местах, где много железа или где требуются комплексные работы) и другие люди. Часто роли совмещаются — например, архитектор может быть как проектировщиком, так и брать на себя часть аналитики. ПМ может быть иногда тимлидом разработчиков. Но модель ролей примерно такая.

Дальше — имхо про то, что нужно от первых трёх ролей.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js