Добрый день.
События, публикации, решения по темам: разработка и тестирование программного обеспечения, инструменты автоматизации и модульные тесты, системное администрирование.
Разработка приложений
• The Daily WTF: элегантный выход из цикла.
• Основы программной инженерии по SWEBOK: перевод, замечания, комментарии.
• Священные войны: что такое хорошо и что такое плохо в применении try/catch?
• Искусственный интеллект в поисковике Google: как учитываются синонимы при выдаче результатов поискового запроса?
• Mark Needham: стратегический дизайн при моделировании, разработке и поддержке приложения.
• Программирование средств промышленной автоматики: последовательность этапов на живом примере.
• Безопасность в Web: что угрожает и как защититься?
• Соприкосновение двух миров: прокси-сервер Nginx, запущенный на Linux, служит улучшению производительности приложений в среде ASP.NET.
• SQL для новичков: типы отношений (relationships) в базах данных.
• Куда податься начинающему разработчику? Davy Brion дает советы по выбору профессионального пути.
• Значение паттернов в разработке программного обеспечения и их влияние на качество выпускаемого приложения.
• Gojko Adzic: фундаментальные принципы развертывания облака и подходы к дизайну облачного приложения.
• Windows Azure: разработка web-сервисов и организация хранилища.
• Производительность web-сайтов: что нужно знать и что можно предпринять?
• Уроки масштабирования: 11 простых правил для стартапов, растущих на дрожжах.
• Теория цвета для дизайнеров. Часть 1: значения цветов.
• Steve Krug: новая книга о usability. Материалы, выложенные в открытый доступ.
Тестирование программного обеспечения
• Joel Spolsky: роскошная статья о Тестировщике. В чем его значимость, кто может им стать?
• James Bach: логирование как неотъемлемый элемент исследовательского тестирования. Michael Bolton согласен с предыдущим оратором и рассказывает об инструментах, которые будут полезны в случае невозможности логирования.
• James Bach: аудиоподкасты на тему организации тестирования приложений.
• James Whittaker: подходы к тестированию, демонстрируемые претендентами на работу в Google.
• Adam Goucher призывает тестировщиков упростить себе жизнь и отказаться от использования https в тестовых сценариях.
• Мухи отдельно, котлеты отдельно, или как поступить тестировщику, если инженеру неинтересны “маркетинговые” последствия бага, а маркетологу – “инженерные”.
• Mark Russinovich в своем репертуаре: как инструменты Sysinternals способны помочь в исследовании загадочного поведения системы.
• I.M.Testy: за лесом не видно деревьев, или размышления о тестировании API.
• I.M.Testy о тестировании граничных условий: что пройдет мимо тестировщика, проверяющего систему через графический интерфейс?
• Тестирование графического интерфейса: трезвый взгляд без розовых очков.
• Логин: краткая методика тестированию входа в систему.
• В первом выпуске журнала Agile Record: гибкие методики в разработке и тестировании ПО, Selenium в автоматизированных сценариях, будущее тестирования.
• Raymond Chen: как поменять отладчик, подключенный к исследуемому процессу?
Инструменты автоматизатора и модульные тесты
• FitNesse + Ranorex: управление прогоном автоматизированных тестовых сценариев.
• Девять критериев оценки инструментов для автоматизированного тестирования.
• MSDN Magazine: тестирование web-приложений с помощью JavaScript.
• SIKULI – еще одна визуальная среда для создания скриптов, эмулирующих действия пользователя в графическом интерфейсе. P.S. Adam Goucher добавил пару ласковых слов.
• Четыре инструмента для тестирования Flex-приложений.
• JMeter: как отлаживать нагрузочные тесты?
• Обзор: 50 доступных инструментов для тестирования производительности.
• Visual Studio 2010: ветвления и циклы при создании web-тестов.
• MSDN Magazine: автоматизация тестирования web-приложений с помощью JavaScript.
• Тестирование производительности web-сервисов с помощью soapUI.
• Success story: перечень инструментов, хорошо зарекомендовавших себя при мониторинге и тестировании производительности web-сайтов.
• Gojko Adzic: организация модульных тестов в среде .Net c помощью Cucumber (1, 2, 3).
Системное администрирование
• Секреты работы в Linux доступны широкой публике.
• Магия Unix: 15 советов по работе с top и 7 примеров работы с awk.
• Системное администрирование и программирование в Unix: памятка на все случаи жизни.
• Unix: запуск задач по расписанию с помощью cronjob.
Разное
• Marc Andreessen, легенда Силиконовой Долины, делится советами по персональной продуктивности.
• Joel Spolsky об избытке действующих лиц при принятии решений: девяти женщинам будет непросто договориться о судьбе одного ребенка.
• Сто законов Мерфи, применимых к программному обеспечению.
• Microsoft: жизнь большой корпорации глазами рядового сотрудника.
Вышло в эпизодах:
Б1. Релиз? У них что, все работает? Куда мы смотрели?
Б2. Все на совещании. Нам нужно решить, что делать дальше. Пообщаться, отчитаться, спрогнозировать.
Б1. Если мы будем только совещаться, то тестировщики будут не нужны.
Б2. Гениально! Это надо обсудить!
Б1. Слыхал прогноз? Конец продукту грядет. В 2012 году.
Б2. Строим Ноев ковчег?
Б1. Лучше ковер-самолет. Сейчас вся живность – в облаках.
Р1. Вот что я думаю: нам не надо искать и исправлять баги. Если клиенту что-то не понравится, он сообщит. И мы это исправим.
Р2. Хорошая идея. Мы будем делать только то, что нужно пользователю. Никаких лишних движений.
Р1. Может быть, нам методику запатентовать? Как назовем?
Р2. User Driven Development? Extreme Agile?
Всего наилучшего. Оставайтесь с нами.
01.02.2010
Капитан Аляска |
С миру по нитке |
Комментарии
Добрый день.
Субъективное мнение о будущем облачных технологий по опыту работы с Eucalyptus, VMware vSphere и Microsoft Windows Azure.
Краткое вступление
В настоящий момент сервисы, предоставляемые по запросу (on demand), можно условно разбить на три группы:
1. Infrastructure-as-a-Service (IaaS)
Провайдер выделяет виртуальные машины с уникальными IP-адресами, хранилище данных и дополнительные сервисы (например, балансировщик нагрузки), облегчающие развертывание информационных систем. Самый яркий пример: Amazon EC2. В распоряжение пользователя предоставляются виртуальные машины с предустановленным программным обеспечением и требуемыми ресурсами, а также сервисы для работы с данными (SimpleDB, MapReduce, RDS), с помощью которых можно построить свою инфраструктуру. Подобную функциональность предлагает Eucalyptus, но при этом облако реализуется на вычислительных мощностях его владельца.
Еще один пример: решения VMware. Компоненты vSphere/vCenter позволяют динамически управлять нагрузкой на хосты и обеспечивать бесперебойную работу виртуальных машин (перенос и рестарт виртуальных машин на другом хосте в случае сбоя и даже создание “теневых” копий виртуальных машин, чтобы избежать простоев). Партнеры VMware предлагают технопарки, которые можно арендовать под свои нужды.
2. Platform-as-a-Service (PaaS)
Провайдер выделяет место для размещения пользовательских приложений + свой API. Типичный пример: Windows Azure, облачная OS от Microsoft. Разработчик получает интерфейсы и библиотеки Azure, на основе которых создает свою систему и размещает ее в датацентре Microsoft.
3. Software-as-a-Service (SaaS)
Провайдер предоставляет свое приложение. К примеру, Google Docs или Twitter. Пользователь приходит “на все готовое”, у сторонних разработчиков есть возможность создавать плагины.
Сильные и слабые стороны облачных вычислений
Главное достоинство облачных технологий: отличные возможности для масштабирования. Система растет, набирает популярность? Нужно больше “виртуальных сил”? Больше места для данных? Все просто. Новые ресурсы (workers в Azure, instances в EC2 и Eucalyptus, дисковое пространство) выделяются по запросу либо автоматически по достижении порога допустимой нагрузки или заполнения выделенного хранилища.
Другие достоинства облаков соседствуют с неочевидными тонкими звеньями. Вот несколько примеров:
1. У пользователя отпадает необходимость заботиться о размещении/сохранности приложений и данных. Можно забыть про резервное копирование? В какой-то степени, да. Провайдер заботится о регулярном архивировании и восстановлении в случае аварий. Но насколько надежна защита персональной информации? Можем ли мы быть уверены, что к нашим данным не будет несанкционированного доступа со стороны персонала провайдера и особо ретивых хакеров? Любое программное обеспечение подвержено взлому (снаружи или изнутри), в любом программном продукте есть баги (и в локальных приложениях, и в облачных сервисах). Но, в отличие от локальных систем, удаленные облачные сервисы не находятся в круге нашего влияния: мы получим только тот уровень безопасности, который может предоставить провайдер. И еще один нюанс: если в случае взлома банковского аккаунта хороший банк компенсирует потери, то в случае уничтожения или раскрытия секретных данных возможности для компенсации не столь очевидны.
2. Доступ к системе из любой точки, в которой есть Интернет. Да, так оно и есть. Но бывает, что Интернет есть, а сервисы провайдера недоступны. Скажем, ведутся регламентные работы, идет миграция приложений из одного датацентра в другой или же аккаунт пользователя просто заблокирован (”за дело” или по ошибке – это другая история).
3. Снижение расходов на инфраструктуру. Безусловно. К примеру, в случае EC2 и Azure пользователю не нужно держать технопарк на своей территории и заботиться о его обслуживании и обновлении. Но другая сторона медали – плата за ресурсы облака (количество instances/workers, трафик, объем хранилища, время работы - у каждого провайдера своя кухня).
4. API. Это здорово. Не надо изобретать велосипед. Но тем не менее, Azure – это не конструктор Lego. Это платформа, на которой надо отлаживать свои приложения. Удаленная отладка – дело непростое. В настоящий момент возможности “горячей” отладки в облаке ограничены, поэтому приходится воспроизводить баг на локальной девелоперской фабрике. На первый взгляд, это кажется достаточно удобным, но частенько возникают баги, которые на ура повторяются в “живом” облаке, но не воспроизводятся в локальной среде. И еще один нюанс – зависимость от API. Провайдер меняет SDK – будь любезен вносить изменения в свою систему, даже если ее текущее состояние тебя (и твоих клиентов) полностью устраивает.
Что можно ожидать в ближайшем будущем
Пользователей облачных систем можно условно поделить на две больших группы: корпоративные и простые.
Корпоративные пользователи с радостью ухватятся за Windows Azure: “Какие слабые места? Это технология от Microsoft, это прорыв!”. Такие пользователи давно сидят на игле Microsoft и не будут с нее слезать. Есть IT-бюджет, который нужно распилить, и Azure видится модным, перспективным вариантом вне зависимости от качества предоставляемых услуг. Такая позиция будет устраивать очень многих: и Microsoft, и фирмы-разработчики ПО, и корпорации-клиенты, и страховые компании (как же без них - новые риски). Безусловно, часть PaaS-пирога отъест Google App Engine, но старая кобыла Microsoft с борозды не сойдет. Что касается IAAS, то будущее просматривается в настоящем: решения Amazon надежны и эффективны – только плати.
У простых пользователей нет большого бюджета, и деньги они не выложат просто так. Им нужна технология, но не хочется зависеть от провайдера. Поэтому все более популярным будет развертывание облачных систем на своих площадках. Хороший пример – Eucalyptus. Открытый код, слегка сыроват, но можно заточить под свои нужды. Более того, Eucalyptus получил большую поддержку со стороны Ubuntu. Последняя версия Ubuntu Server позволяет развернуть Enterprise Cloud на базе Eucalyptus. И вот еще две интересных возможности Eucalyptus: 1) связка Eucalyptus + VMware: в качестве гипервизора использовать не KVM или Xen, а VMware ESX, тем самым объединив в одной системе “эластичность” выделения ресурсов в Eucalyptus и богатые возможности мониторинга/автоматизации/графического интерфейса, которые есть в ESX; 2) интеграция с Amazon EC2: при нехватке внутренних ресурсов можно временно арендовать виртуальные машины на Amazon, нарастив мощность своей “домашней” системы – благо Eucalyptus многое вобрал из EC2, включая клиентские инструменты для управления облаком. Дальше – больше: если облако находится в круге влияния его хозяина, то следующим шагом будет “домашний” API, домашний framework (либо самописный, либо созданный на основе существующих) и, в конечном итоге, информационная система, которая вбирает в себя возможности IaaS/PaaS/SaaS и при этом находится под полным контролем ее владельца.
Интересные времена настают. Оставайтесь с нами.
17.01.2010
Капитан Аляска |
Приложения |
Комментарии (2)
