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

в 15:07, , рубрики: CIAC, Cisco, Cisco Nexus, Cloupia, FEX, flexpod, hyper-v, microsoft, MultiStore, NetApp, nexus 2000, nexus 5000, oracle, Oracle RAC, rhel, sap, Secure Multi-Tenancy, UCS, vdi, VMware, vSphere, xendesktop, архитектура, Блог компании NetApp, облачные технологии, СХД, цод, метки: , , , , , , , , , , , , , , , , , , , , , , , , ,

В продолжение статьи Что такое FlexPod? Если в вкратце, то FlexPod — набор конфигураций серверного и сетевого оборудования и программного обеспечения для ЦОД, предлагаемый компаниями Cisco и NetApp, сформированный на основе серверов Cisco UCS, коммутаторов Cisco Nexus, систем хранения данных NetApp FAS. 24 января 2013 компании NetApp и Cisco объявили о расширении сотрудничества.

Таким образом осуществляя более глубокую интеграцию продуктов обеих компаний и новые конфигурации решения FlexPod используя некоторые новые разработки обеих компаний.

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

в 19:08, , рубрики: архитектура, переводы, принципы разработки, Программирование, разработка, разработка по
От переводчика

На днях в сети появился минисайт minifesto.org со здравой, на мой взгляд, тезисной выжимкой опыта подхода к стартапам (да и к разработке в целом). Манифестность текста смягчается от начала к концу, но это не делает его хуже.

Снова прошу прощения за отсутствие перевода словосочетания “computer science”.
Минифест (манифест разработчиков минималистов)

Кратко

  • Боритесь за закон Парето, следите за тем, чтобы 20% вашего труда давало вам 80% результата;
  • Расставляйте приоритеты, ведь минимализм нужен для того, чтобы делать то, что нужно, а не распыляться по мелочам;
  • Лучшее — враг хорошего: сначала просто сделайте, потом сделайте правильно, потом сделайте лучше;
  • Убивайте в зародыше, не бойтесь начать всё сначала. Чем быстрее ошибётесь, тем быстрее научитесь;
  • Повышайте свою ценность. Постоянно думайте о том, чем можно помочь команде, — и развивайтесь в этом направлении;
  • Сперва основы. Мыслите последовательно, ориентируясь на лучшие практики мира Computer Science;
  • Посмотрите с разных сторон. Простое получается тяжелее, чем сложное, поэтому включайте воображение;
  • Синтаксис — основа взаимодействия. Мы пишем код для людей, а не для машин;
  • Не запутывайте. Старайтесь проектировать слоями, по мере возможности не зависящими друг от друга;
  • Вычищайте оставленное-на-всякий-случай. Минимализм борется с отвлекающим от основного.

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

в 12:54, , рубрики: mvc, архитектура, Веб-разработка, ооп, переводы, Проектирование и рефакторинг, фреймворк, метки: , , ,

(статья очень старая, по поднятые в ней вопросы актуальны по сей день и регулярно поднимаются в различных обсуждениях)

Многие из вас наверняка заметили, что я пишу книгу о Zend Framework. Недавно я закончил черновики двух глав: «Архитектура приложений на Zend Framework» и «Понимая Zend Framework». В первой главе объясняется архитектурный шаблон Model-View-Controller (MVC) и причины, по которым он стал стандартом де-факто для веб-приложений. Во второй исследуется связь MVC с компонентами Zend Framework, их структурой и взаимодействием.

Завершив обе главы я осознал, что большую часть времени описывал модель и ее фактическое отсутствие в Zend Framework. На самом деле ни один веб-фреймворк не предлагает нам полноценную модель (по причинам, которые я объясню чуть позже). И ни в одном из них не дается внятного объяснения этому обстоятельству. Вместо этого они последовательно связывают понятие модели с родственным, но не идентичным понятием доступа к данным, что изрядно всех запутывает.

Эта сторона фреймворков никогда не привлекала особого внимания. И все же именно она лежит в основе целого класса проблем в тех приложениях, которые пытаются использовать MVC по образу и подобию фреймворков для веб-приложений. Более того, попытки донести идею модели до других разработчиков нередко напоминают битье головой о стену. Я не хочу сказать, что все разработчики тупые или не понимают саму идею, просто никто из них (вне зависимости от того, работают они с PHP или нет) не связывает модели с той областью, которая наделяет их смыслом — принципами объектно-ориентированного программирования.
Читать полностью »

в 1:54, , рубрики: архитектура, будущее, будущее здесь, дома, здания, строительство, экология

«Безбашенные» небоскребы будущего

От зданий, которые качают воду в гималайских ледниках, до круглых башен, которые могут позволить путешествовать их жильцам не выходя из дома. Как архитекторы представляют себе здания будущего?Читать полностью »

в 10:58, , рубрики: Алгоритмы, архитектура, Блог компании «Apps4All», гауди, Программирование, реверс-инжиниринг, управление проектами

Строительство Саграда Фамилия началось в 1882 году, а позже в этом году строительство возглавил знаменитый архитектор Антонио Гауди́, который заложил основы ставшей теперь знаменитой на весь мир церкви Барселоны. Гауди посвятил Саграда Фамилия многие годы и спустя 130 лет храм считается одним их самых потрясающих и уникальных строений на Земле. Хотя за прошедшее время строительство так и не было завершено.

ПО помогло закончить план Гауди, начатый 130 лет назадЧитать полностью »

в 7:21, , рубрики: Google, архитектура, офис, Офисы IT-компаний, метки: , ,

Проект нового кампуса Google

Компания Google славится своими офисами. Наверное, любой программист мечтает работать на территории Googleplex.
Но ни один из офисов компании не был построен с нуля. Она лишь брала существующую недвижимость и перестраивала под свои нужды.
Гугл не так давно уже предпринимал попытку построить собственный офис. В 2011 году был нанят немецкий архитектор Christophe Ingenhoven, который должен был спроектировать комплекс суперсовременных зданий неподалёку от существующего Googleplex. Но год спустя компания решила отказаться от этого проекта и осуществить свои планы в другой части Mountain View — ближе к заливу Сан-Франциско. Для этого было решено найти нового архитектора.
В распоряжение ресурса Vanity Fair попал рендер нового проекта, подготовленный архитектурным бюро NBBJ.
Читать полностью »

в 21:30, , рубрики: php, security, архитектура, безопасность, информационная безопасность, метки: , , ,

Я рад продолжить рассказывать свои взгляды к подходам создания безопасных веб-ресурсов и веб-приложений и перейти от первой части, которая содержит в себе некоторые общеполезные security-инструкции, ко второй — разработке самого приложения.
Читать полностью »

в 15:01, , рубрики: Анализ и проектирование систем, архитектура, дизайн, команда, проектирование, Проектирование и рефакторинг, разработка, шаблоны проектирования, метки: , , , , ,

Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.

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

в 4:16, , рубрики: архитектура, ооп, паттерны проектирования, Совершенный код, управление проектами, метки: , , ,

Любому приличному программисту известно, что грамотно написанная система должна иметь хорошую архитектуру, обеспечивающую чёткую структуру, удачное сочетание и взаимодействие объектов, чётко распределённые между объектами роли и разделение на слои.

Каждый приличный руководитель проекта знает, что для успешного, сданного в срок проекта хорошего качества (который, к тому же, не слишком вылез из бюджета) необходим отлаженный процесс, обеспечивающий прозрачное взаимодействие между членами команды, чёткое распределение ролей и обязанностей, полномочий и ответственности. Т.е. грамотная архитектура команды.

В этой статье я (очевидно, не слишком серьёзно) попробую спроецировать основные принципы ООП на проектное управление и посмотреть, что из этого получится.

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

в 18:17, , рубрики: bdd, coffeescript, DDD, dsl, KISS, YAGNI, архитектура, ооп, Программирование, Проектирование и рефакторинг, метки: , , , , , , ,

Поскольку идея данного поста родилась у меня независимо от эпопеи с хлебопекарней, хочу вставить и свои пять копеек.

Итак, суть проблемы — поставить программный код в соответствие с бизнес-требованиями. Существуют замечательные методологии и техники, например, Behavior Driven Development (BDD), которые позволяют в декларативном стиле описать требуемое поведение системы (тесты).

Возникает вопрос — зачем описывать как должен работать код, если можно и сам код написать в этих терминах. Почему user story не может быть самой программой.

не код должен генерироваться из модели — модель должна быть кодом

Чтобы не томить читателей сразу перейду от слов к делу. Представим себе язык для программирования вот такого робота:
image

Warning! Данный пример служит только для иллюстрации идеи и не предназначен для приготовления пищи в реальной жизни. Автор не несет ответственности за вред здоровью нанесенный в результате употребления пищи, приготовленной с помощью данного примера.

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

1...1020...464748...49
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js