Slider Background

2014

День здоровья 2014

Не все умеют качественно отдыхать, но нам нет равных в этом деле, мы вновь всем дружным коллективом выехали на день здоровья.

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

Развлекались мы очень активно и весело, стреляли из лука, метали ножи и топоры, лазили по веревочной переправе, стреляли из пневматической винтовки, играли в волейбол.
Вдоволь накатались по Волге на ватрушках и лыжах. Мы получили заряд бодрости и прекрасного настроения в полной мере отдохнули и набрались сил для новых свершений.


Подробнее

IT-Олимпиада 2014

2-3 августа 2014 года прошла олимпиада среди ИТ-фирм Самары. В общем медальном зачеты мы стали четвертыми из 30 фирм.
Саша Рыжов выиграл золото в стрельбе. Ирина Захарова выиграла две серебряные медали в беге на 5000 метров и прыжках, и это после того, как в составе нашей команде заняла третье место в вело эстафете.
Вот полный список участников вело эстафеты: Стас Баничус, Владимир Букин, Ирина Захарова, Алексей Солдатов, Алия Яхина.
Ольга Лисицина завоевала бронзовую медаль в настольном теннисе.
А наша команда по волейболу, состоявшая из парней и девушек, взяла бронзу в мужском турнире. Вот имена наших спортсменов: Стас Баничус (еще одна медаль!), Ирина Захарова (вновь она!), Ольга Лисицина (вторая медаль!), Кирилл Резников, Женя Станкевич, Паша Трешников.
В шаге от пьедестала остановилась наша сборная по стритболу и Миша Черясов в прыжках в длину. Футболисты победили всех в группе, но проиграли в четвертьфинале будущим серебряным медалистам. Антон Ершов стал пятым в шахматах.
Всего от нас участвовало 32 человека, включая наших друзей из СМС, спасибо всем за борьбу и волю к победе!

Подробнее

Конференция DevCon 2014

Проходило данное мероприятие 28-29 мая, и, так как мне и Денису Тагаеву посчастливилось туда попасть, пишу краткий отчет для всех интересующихся.

Вначале для тех, кто не знает, что такое DevCon. Конференцию ежегодно проводит Microsoft для привлечения разработчиков к работе на их платформе. Удовольствие это не бесплатное и не дешевое, но в принципе того стоит, проводится в загородном формате.
На конференции такого масштаба я был впервые. И там было круто! Даже пасмурная погода и иногда небольшой дождь не испортили впечатление. В общем, всем рекомендую, да и сам бы не отказался съездить еще раз.

Место

Называется оно природный курорт «Яхонты» и расположено в деревне «Жилино», что в Московской области около города Ногинск. Два часа езды на автобусе от станции метро «Партизанская». Масштаб курорта впечатлил: много больших домов отельного типа для размещения большого количества человек. На конференции было более 900 участников и их разместили всего в 2 домах. Место клевое: красивое озеро, ресторан, большая концертная площадка, дом для конференций с одним огромным залом и несколькими залами среднего размера, у озера пляж (но погода не позволяла), детская площадка. Территория оформлена в традиционном русском стиле, в дереве. Сервис как и на любом курорте: гостиничный номер, ресепшн, горничные, шведский стол, официанты  и т.д. Позабавили служащие, ездящие по территории на трехколесном велосипеде с подносом яблок на голове.

 

Организация

У нас был очень плотный график, так как конференция шла всего полтора дня, и было заявлено много докладов. Сразу же по приезду нам дали кучу заданий: нужно было зарегистрироваться, получить ключ от номера, рюкзак, отметить командировочные, успеть позавтракать, заполнить анкету, изучить правила фотоконкурса и что-то еще. Нам пришлось поторопиться, чтобы успеть к открытию в 11 часов. Спасибо организаторам, нас разместили с Денисом вместе, как мы и просили. Между домами в палатке был организован «Гостевой дом», где всех зарегистрировали, там же можно было попробовать Xbox One и Oculus Rift - 3D устройство, которое одевается, как шлем, на голову и выводит 3D модель. На докладе показывали пример модели, написанной на чистом JavaScript, двигаться внутри такой модели можно было с помощью устройства или из браузера, который синхронизировался с устройством. Также в гостевом доме был 3D принтер, и неожиданно KIA Quaris, бортовой комп которой, взаимодействовал с бекэндом, находящимся в облаке. В перерывах между докладами там шла онлайн-трансляция. Слева от гостевого дома находился дом для конференций, а справа по длинной дорожке ресторан. В ресторане шведский стол.Между докладами был перерыв в 20 минут, за который можно было выпить кофе и перекусить. В первый день было 6 докладов, во второй – 7, полтора часа было отведено на обед, ужин и завтрак. Доклады были в том числе и на английском, для них под залог ценного документа выдавали наушники с синхронным переводом. После каждого доклада можно было задавать вопросы или лично пообщаться с докладчиком, но в этом случае рискуешь опоздать на следующий. В гостевом доме и доме для конференций был бесплатный вай-вай, в столовой не было, а в гостинице был от «Яхонтов» за деньги, что немного огорчило.

Про доклады

Началось все с пленарного доклада на 2 часа, где веселый американец итальянского происхождения при помощи коллег из известной корпорации рассказывал про светлое будущее Microsoft, и как их ПО скоро окажется на любом устройстве (напоминает исконную стратегию Java, что очень забавно). Далее с перерывом на обед и ужин шли доклады продолжительностью по часу. А вот вечером наш ждал приятный сюрприз: пивная вечеринка и выступление группы УмаТурман. Почему-то я никак не ожидал, что на пивной вечеринке будет клинское пиво с сухариками хрустим. А вот концерт очень понравился, спели все хиты, была домашняя атмосфера, желающие, как следует, отрывались, а в конце ребята даже спели на бис песню из «Ночного дозора». После выступления неожиданно был пионерский костер с песнями под гитару. А для тех, кто не любит романтическую атмосферу, проходила «Ночь кодирования» и «Машинное обучение на F# за полтора часа».
Утром, едва проснувшись, уже в 7:30 отправились на завтрак. И в 9 часов опять понеслись доклады, к счастью, хотя бы первые 2 доклада шли по полчаса. Потом еще 5 докладов с перерывом на обед, закрытие конференции с вручением призов и посадка на автобус.
Про закрытие: вначале показали фотоотчет и нарезку смешных видео со звукорядом из эпизодов конференции, а потом было вручение призов за фотоконкурс и «Ночь кодирования» и в завершение общее фото. В фотоконкурсе было много номинаций и победители получили разные модели телефона Nokia. А вот победителю «Ночи кодирования» подарили планшет, за программу для Windows Phone, которая измеряет скорость раскручивания рукой телефона.
Большинство докладов, конечно, было про облако (Windows Azure) и кроссплатформенную разработку..

Открытие конференции. Пленарный доклад - Джоржио Сардо, Александр Ложечкин, Михаил Черномордиков, Microsoft

Начал доклад Михаил Черномордиков, он с энтузиазмом рассказывал про DevCon, говорил о его массовости, хорошей организации, курорте "Яхонты" и т.д.
Далее слово взял улыбающийся итальянец небольшого росточка, который в течение почти двух часов, периодически приглашая коллег показать какие-то детали, рассказывал, как клёво писать на платформах Microsoft, как майкрософт делает жизнь людей лучше, как клево развивается их облако (Windows Azure), как майкрософт развивает кроссплатформенность и много чего еще клевого, что есть у майкрософт. Выступление, как и принято, у американцев проходило в жанре Standup, то бишь с шутками и раздеванием до майки со сборной России по футболу. Основной посыл этой конференции сводился к тому, что Microsoft вкладывается и в устройства (кроссплатформенность), и в сервисы (в облаке), и в разработчиков (клевые инструменты, в основном, конечно, это Visual Studio, куда они пытаются запихнуть всё). Доклад очень понравился, удивительно, как у него получалось плавно переходить от одного к другому и рассказать вообще про все технологии Microsoft меньше, чем за 2 часа. Правда не обошлось без накладок, студия повисла раза 3 у разных людей, это нормально :)
Интересные тезисы:
  • Единая среда разработки для всех устройств.
  • Обновление для Windows Phone и Windows.
Нативная разработка игр (с++): для XBox One, Windows 8.1 и Windows Phone. Unity – для всех платформ:
  • c#/Xaml, с++/dx, js/html/css.
  • Бесплатный компилятор .net – Roslyn.
  • Xib/ios, axml/android, xaml/native ui.
  • Xamarin c#.
  • Универсальные приложения на c# для WinRT, Win Phone, Android (Xamarin).
Упаковка веб-приложений в магазин Windows (сайт zoopla):
  • Упаковка сайта в пакет. Создание среды для андроид (cordova).
  • Улучшение кроссплатформенности.
Облако (Azure):
  • Автоматический выбор элемента страницы в браузере и редактирование в браузере (Browser Link).
  • WebJobs – фоновые приложения сайта, взаимодействуют с сайтом через атрибуты.
  • Добавление элементов данных для своего портала в windows azure.
Мобильные сервисы:
  • AD онлайн.
  • Мобильные приложения с бекендом в облаке.
  • Удаленная база данных в azure. Синхронизация с локальной.
Облако (Azure) продолжение:
  • Автодокументация портала на azure.
  • Проверка API, безопасность трафика, статистика нагрузки и активности пользователей.
  • Поддержка многих платформ в azure.
Будущее:
  • Тенденция расширения кроссплатформенности на Xbox.
Далее слово взял Александр Ложечкин, и уже по внешнему виду и манере разговора стало понятно, что слово взял менеджер. Первое, что он сказал: до этого была теория, а теперь перейдем к практике. В основном говорил про регион Восточной Европы, который он и представляет в Microsoft. Сказал что здесь больше всего технических спецов и наиболее востребованные кадры, и что Microsoft будет вкладываться в этот регион. Ну и приводил кучу менеджерских цифр по статистике нашего региона по развитию разработки. В конце доклада неожиданно сказал, что в последнем скайпе появилась возможность синхронного перевода, и посоветовал всем попробовать.

Новейшие сервисы Windows Azure, которые помогут сделать ваши приложения быстрее, надежнее и безопаснее. Владимир Юнев, Microsoft

По моему мнению, это был самый интересный доклад, самый лучший докладчик и самый обширный и динамичный доклад.
  • 11 дата центров по все миру.
Web sites:
  • Публикация через портал или расширение для студии.
  • Фоновые задачи: WebJobs.
  • Удаленная отладка через портал.
  • Поддержка Java.
  • Полноценный бэкап сайта, возможность пинговать сайт через скрипты или портал.
  • Поддержка ssl (одного бесплатно), управление трафиком (менеджер), переключает на разные дата центры в зависимости от месторасположения и от нагрузки.
  • API Management через прокси портала azure: безопасность, трансформации в разные форматы, много функций портала из коробки (500$ в месяц).
  • Redis (база в памяти, кеш для любых данных): доступен как сервис, есть библиотеки для всех платформ, с репликацией (есть пакет nuget).
  • Kudu – панель администрирования сайта (Open Source), удаленный PowerShell, можно снимать дамп памяти, можно доставить расширения (phpmyadmin, azure local resource explorer), управление WebJobes.
Мобильная разработка (мобильные сервисы):
  • Единый бекэнд для всех платформ (много разных sdk), можно писать и на .net (rest сервис asp .net) (раньше только через nodejs)
  • Разграничение доступа через удаленный AD.
  • Доступ к разным БД.
  • Синхронизация данных (если нет доступа используется независимая бд, оффлайн БД SQLite, разрешение конфликтов).
  • Переход на пуш уведомления вместо смс (пуш намного дешевле), меньше спама.
Корпоративная разработка:
  • RemoteApp размещение старых приложений в azure, потом может заработать на любом устройстве (не только с windows) (используя AD), пока бесплатное !!!
  • Azure Files - SMB 2.1 в облаке !!!, хранит 3 копии – до 100 ТБ.
  • Azure AD – единая точка ко всем ресурсам, интеграция собственного AD с AD в облаке, ко многим сервисам в интернете.
  • Мультифакторная аутентификация (смс, коды безопасности), Управление правами, Самообслуживание для пользователей (например сброс пароля).
  • AD – бесплатно.
Инфраструктура:
  • Виртуальные машины (простое добавление агентов, виртуальных машин), антивирусы.
  • 8-16 ядер, 56-112 ГБ РАМ, быстрая шина обмена данных между виртуальными машинами, более быстрые процессоры.
  • Резервирование адресов (белых, прямых), внутренняя балансировка ресурсов (внутри инфраструктуры) (раньше только внешняя).
  • Подключение нескольких локальных сетей к единой виртуальной, vpn между дата центрами
  • 14$ минимальная цена за инфраструктуру.
  • SQL Database: сохранение до 30 бэкапов (платно), георепликация (из другого региона).
  • 20 мб – бесплатно!
Инструментарий:
  • Все через студию, нужно поставить azure sdk, удаленная отладка, подключение к приложению любого бекэнда, доступ к коду бекэнду, тестирование пуш нотификаций.
  • Visual Studio Online: хорошая поддержка веб.
  • Цель – получать деньги за услугу, за использование облака.

Создание мобильных приложений для веб-разработчиков. Джефф Буртофт, Microsoft

  • Веб-приложения в магазине – идея не прижилась и мало приложений.
  • Firefox OS Emulator позволяет запускать веб-приложения как на устройстве.
  • Можно закрепить веб-приложение в устройстве.
  • Можно представить обычное приложение, размещенное на веб-сервере.
  • Поиск браузерных приложений зависит от поисковика. Магазины приложений позволяют быстрее найти приложение.
  • Трансформацию веб приложения в мобильное делает компонент WebView (но приложение расположено на веб-сервере).
  • Это приложение будет иметь свой кэш и куки.
  • Можно написать код для закрепления на начальном экране.
  • Есть готовые шаблоны js (находящиеся на специальных серверах, но могут храниться и в кеше, то есть можно работать оффлайн) для: кнопки назад, меню, сортировка, вторичное закрепление, то есть все функции, как и у приложения из магазина.
  • Есть манифест веб-приложения (json), содержит метаданные для магазина. Например, ориентация экрана, можно описывать конкретные функции для конкретных платформ.
  • Цель – написать приложение раз, а работало чтобы везде.
  • Код внутри WebView не имеет доступа к WinAPI.
  • Ajax также будет работать, потому что все кэшируется (http запросы и все остальное), то есть все будет работать как будто онлайн.

Управление качеством в промышленной разработке программных продуктов. Владимир Гусаров, Dell

Ожидал большего от доклада, но в результате доклад оказался о том, что и так есть в большинстве фирм, в том числе у нас. Докладчик периодически ссылался на TFS, и говорил, что там есть все, и если вы его поставите, то будет вам счастье (то есть качество).
  • Application LifeCycle Management (ALM) – это все кроме, непосредственной разработки продукта.
  • Что такое качество: совокупность многих свойств (красота, удобство, надежность, выполнение своих функций).
  • Этапы ALM: сбор требований, разработка и документирование, тестирование, фидбек от заказчика, доработка, выпуск, техподдержка.
Сбор требований:
  • Прототипирование, макетирование дизайна, критерии готовности
Разработка и документирование:
  • Модульное тестирование, организация кода (система контроля версий), автоматическая сборка (кода, документации, запуска тестов, покрытие. Собираться должно все !!!), инспекция (статистический анализ кода).
Тестирование:
  • Тест-планы (кейсы), фиксация прохождение тестов (ручных и автоматических), автоматическое тестирование, нагрузочное тестирование
Обратная связь:
  •  Демо результатов спринта, клиент сбора обратной связи (есть в TFS, Feedback Client) (простота использования, запись видео и голоса, создание мгновенных снимков), подключение на разных этапах. Обратная связь - чем раньше, тем лучше (пусть даже небольшой функционал).
Выпуск:
  • Release Management (TFS) – автоматизация управления выпуском, полное управление стеком стадий продукта.
  • Утверждение выпуска (автоматическое через Release Management).
  • Тренинги: техподдержки, отдела продаж.
  • Продукты умирают, потому их не продают !!! (с)
Тех. поддержка:
  • Удовлетворенность потребителя (тесная связь с разработкой), метрики инцидентов (кейсов), стоимость инцидента (кейсов), обзор продукта службой поддержки.
Lab Management:
  • Тоже входит в TFS :) – создание тестовых окружений.
Метрики качества:
Разработка, подготовка к выпуску:
  • Тенденции дефектов
  • Тенденции сборки
  • Изменения исходного кода
  • Реактивация дефектов
Эскалация техподдержки:
  • Время до решения
  • Время в разработке
  • Время реакции
Качество – это когда в компанию возвращается клиент, а не товар.(с)

Введение в UnityEngine. Владимир Колесников, Microsoft

Решил немного разнообразить и сходить на доклад про написание графических приложений, в основном игр, на .net, с использованием хорошего движка.
Доклад был интересный, но докладчик не очень понравился, все как-то он старался обговаривать кратко сложные моменты и уходил от хитрых вопросов, ссылаясь на недостаток времени.
  • Многоплатформенный графический движок.
  • Фреймворк для работы с аудио, сетью, вводом/выводом.
  • Компиляторы и среда выполнения (плагины), базирующиеся на .net (mono).
  • C#, javascript, boo.
  • Визуальный редактор (плагины).
  • Asset Store (магазин скриптов, текстур, расширений).
Почему Unity3D ?
  • Многоплатформенность: оптимизация быстродействия, возможность использования специального API (плагины под конкретную платформу, c#, c++)
  • Зрелость и популярность: 53% игровых разработок
  • Подтвержденные возможности разработки высококачественных игр
  • Расширение через плагины
  • Набор готовых текстур для создания простых игр (земля, небо, «человечек»).
  • Переход в MonoDevelop для написание обработчиков.
  • Перевод из c# на с++, затем в js, в итоге все работает в webgl.

Intel Parallel Studio XE. Новая. Производительность. Твоя. Игорь Воробцов, Станислав Павлов, Intel

Доклад оказался не совсем о том, что я ожидал. Но инструмент этот в целом интересный.
Intel Parallel Studio XE - это набор инструментов от Intel для написания приложений, максимально использующих параллельность. К сожалению, писать можно только на c, c++ (или неожиданно! на фортране), но говорят, что инструменты могут быть встроены в visual studio.
  • Высокопроизводительные вычисления.
  • Гонка частот процессоров подошла к концу, сейчас идет гонка за количество ядер – это вызов программисту, софт должен масштабироваться на все ядра.
  • Как максимально использовать железо – новый компилятор, добиться базовой версии, распараллелить, добиться стабильной параллельной версии, найти узкие места сдерживающие производительность, оптимизировать микроархитектуру.
  • Для этого помогает пакет Intel Parallel Studio XE, состоящий из 4 частей: средство проектирования параллельных приложений, компилятор и библиотеки, поиск ошибок, профилирование производительности (интеграция в студию)

Создание XAML-приложения для Windows Phone, планшетов и настрольных компьютеров с помощью проектов универсальных приложений. Ларри Либерман, Microsoft

Доклад понравился, докладчик не совсем: очень сильно торопился, старался преподнести много материала, но иногда наоборот повторялся.
  • Один solution с общей частью и отдельными проектами под платформы.
  • В общей части может почти все что угодно, включая визуальные компоненты, есть отдельные шаблоны в студии.
  • Для добавления новой платформы, есть пункт в контекстном меню проекта. Далее нужно переместить часть кода в общую часть.
  • В общем коде нюансы платформ реализуется через директивы условной компиляции.
  • Выбор платформы реализуется через выбор стартового приложения нужный платформы в солюшене. Можно реализовать переход по кнопке назад для windows phone.
  • Поддержка IntelliSense в условной компиляции, переключение запуска приложений.
  • Портабельные библиотеки менее удобные, можно использовать только скомпилированные библиотеки в проекте для конкретной платформы.
  • Студия упрощает разработку универсальных приложений.
  • Можно переключаться между нужными разрешениями экрана в дизайнере студии.
  • Отдельные свойства в дизайнере для определенной платформы (например, цвет акцента).
  • Есть нюансы, которые отличаются, например, открытие файлов или работа с устройствами, их надо знать.

Колоночные индексы в SQL Server 2014. Дмитрий Пилюгин, TNS Gallup Adfact

Доклад клевый и сложный, докладчик понравился. Народу пришло много, а я задержался на 5 минут, пришлось сидеть на полу и писать в блокнотике.
Сразу скажу, штука эта для запросов, поднимающих много колонок или выполняющих агрегацию из кучи исходных строк. В противном случае может быть даже вредна. Появилась в MS SQL 2012, но по-человечески ее допили в 2014, о чем собственно и шла речь в докладе.
  • Это такой же индекс, может некластеризованный с указанием столбцов, а может быть кластеризованный, тогда он будет один на таблицу, столбцы указывать не надо.
  • Каждая колонка такого индекса располагается на отдельной странице в файле данных.
  • Суть алгоритма работы такого индекса – разбиение таблицы на группу строк, далее столбцов, и затем сжатие и сохранение в формате LOB в специальном месте.
  • Основные преимущества: поднимаются только нужные столбцы, хорошо сжимаются, исключение сегментов, пакетный режим обработки (строки обрабатываются пачками, не по одной).
  • Колоночный индекс – необновляемый, совместим с обычным, в 2014 – есть обновляемый, но не совместимый с другими (можно создать только кластеризованный один на таблицу).
  • Можно собирать статистику по колоночному индексу.
  • Сканирование оптимальное по производительности (с использованием словаря).
  • Динамическое определение степени параллелизма (DUP) (для нескольких row group).
  • Механизм закладок для колоночных индексов (используется при изменении колоночного индекса) использует номер row group и номер внутри группы.
  • При использовании кластерного колоночного индекса, нужно удалить все другие индексы, а также есть ряд других ограничений.
  • При добавлении записей в кластерный колоночный индекс данные не сразу преобразуются в колоночный формат (сжатая закрытая row group).

Централизованное управление облачным приложением с помощью Azure Resource Manager. Хакан Эскиси, Microsoft

Думал, что доклад про дополнительный инструмент для разработчиков под Windows Azure, а оказалось что это скорее инструмент для администраторов таких приложений. Инструмент этот оказался для меня каким-то совсем мутным, я понял доклад где-то на 40%. Ресурсная группа: имеющие один жизненный цикл.
  • Унифицированный интерфейс доступа ко всем ресурсам (API): Azure PowerShell, REST API. Размещение ресурсов в разных регионах.
  • Файлы шаблонов ресурсов в json.
  • В файле конфигурации можно настраивать зависимости между ресурсами.
  • Много рассказал про развитие REST API (OData) и json (Scheme).
  • Azure Resource Manager состоит из 3 частей: контейнер жизненного цикла, декларативная модель развертывания и конфигурации (json), соответствующий уровень управления.
  • Жизненнный цикл: разворачивание, обновление, удаление, статус.
Итого, Azure Resource Manager – это:
  • Декларативность в текстовом виде
  • Повторное использование
  • Унифицированное API
  • Работает везде

Практика кросс-платформенной разработки на C# и XAML с ипользованием Appercode. Дмитрий Адонин, Digital Sparta

Доклад очень понравился, докладчик был молодой, но рассказывал четко и грамотно, хорошо построил доклад. Технически один из самых интересных докладов. Наша разработка – можно гордиться!
  • Xamarin – 60% общего кода.
  • Базируется на моно (написана разработчиком моно), предоставляет обертки над системными вызовами.
  • Общий код из коробки: ввод, вывод, сеть, потоки, SQLite, поддержка Portable Class Library.
  • Xamarin+MVVM – до 70% общего кода.
  • Позволяет переиспользовать вьюмодель, вью пишутся под каждую платформу.
  • MVVM Cross (есть в nuget), MVVM Light (частично) – фреймворки для MVVM.
  • В андроид во вью (axml) нужно добавить только специальный биндинг (умеет mvvm cross).
  • В ios тоже, но в code behind.
  • Процент общего кода для ios – минимальный (около 50%).
  • Xamarin 3.0: поддержка верстки для iosв студии.
  • Xamarin.Forms – кроссплатформенный ui: базируется на идеях ui android, ios. Поддерживает xaml (много похоже на обычный xaml).
  • Genymotion – быстрый эмулятор, быстрее нативного, для некоммерческой разработки – бесплатный.
  • Большая часть простых контролов может быть переиспользована.
  • ApperCode (расширение для студии) – 146% общего кода J.
  • ApeerCode: ui framework, xaml, bindings, стили, ui модель как в Silverlight. Мелкие фишки: android – скролл по 2 направлениям, ios – работа с клавиатурой. Контролы предстоставляют обертки, можно подсунуть любой uielement. Апперкод не взаимодействует с mvvm фреймворками, имеет свои биндинги.
  • Нужна лицензия xamarin, ApperCode – бесплатный и будет бесплатный, получили грант от майкрософт. Готовы к сотрудничеству, нужны примеры проектов.

Практический опыт создания расширений Microsoft Visual Studio. Николай Леонов, Microsoft

Доклад понравился, все четко разложено по этапам, каждый этап сделан отдельной заливкой в гите.
  • Расширение должно не зависеть от бизнес-логики.
  • Возможности расширения: интеграция в студию, подписка на события студии, работы со свойствами узла обозревателя решений, создание страницы параметров, интеграция с панелью вывода и окном Списка ошибок, запуск инструментов.
  • Что нужно для разработки расширения: поставить сдк студии, выбрать тип проекта для создания расширения, задать тип проекта – пакет.
  • После запуска проекта расширения запускается экспресс версия студии.
  • Можно связывать команды через атрибуты пакета. Можно зарегистрировать свою команду в нужном месте меню, можно привязать хоткей. Можно создать динамическую команду (через обработку события студии), можно команду привязать к нескольким местам.
  • Для динамических команд нужно задать событие загрузки пакета расширения (через атрибут). Можно создать динамическую группу команд.
  • Можно создать кастомную панель свойств (нужно наследоваться от стандартного класса, нужно переписать контекст данных нужного класса).
  • Подписка на события студии (объект DTE), нужно хранить ссылку на класс события студии.
  • Для создания страницы настроек (в свойствах студии будет новая строка) нужно наследоваться от стандартного класса и задать нужные атрибуты, используются публичные свойства с заданным чтением и записью, нужно на них навешивать атрибуты.
  • Можно выводить сообщение в отдельную группу в аутпут и в ошибки студии.
  • Интеграция с Powershell (создание своего хоста Powershell): передача параметров в скрипт, перехват вывода, обработки в скрипте переменных студии.

Заключение

График очень плотный, но нужно попытаться успеть все. Я вот не успел/забыл: поставить оценку докладам (Денис сделал – молодец, получил еще приз), получить сертификат (жалею, хотел получить), участвовать в фотоконкурсе (я не хотел фотографировать на телефон, а фотоаппарат брать не стал, о чем жалею), погулять по всей территории (немного, конечно, успел, но хотел бы подольше).
Народу была тьма (более 900 человек), куда не сунься - везде люди/небольшие очереди, особенно в ресторане.
Но в целом все, конечно, очень понравилось: доклады интересные, концерт клевый, организация хорошая, еда вкусная, разнообразная. Всем рекомендую!
Вот вкратце (или уже нет) отчет о конференции, если кто хочет более подробно что-то узнать, обращайтесь, с удовольствием отвечу.
Подробнее

Самые распространенные ошибки аналитиков ИТ

Давно уже порывалась поделиться опытом написать.

Я периодически оглядываюсь в прошлое, анализирую свои поступки и их следствия, и делаю выводы типа «вот это привело к радости и счастью, а вот это - к печали и лучше не повторять».

Набивая очередную шишку, я решила, что пора писать талмуд под названием «Туда не ходи, а то снег в башка попадет», потому что «туда» ходят абсолютно все аналитики, а некоторые – раз по пять-шесть, «чтобы уж точно быть уверенными».

Большая часть описанного – это пережито мной на собственном опыте или наблюдалось мной со стороны на опыте коллег. Кроме того, я попросила руководителей проектов и наших аналитиков поделиться своим опытом и своими наблюдениями. И я расскажу вам, что из этого вышло.

Всем известно, что у каждой крайности есть своя полярность, которую не трудно представить, опираясь на описание противоположной. Думаю, это вы сможете представить сами.

Мы, СМСки, достаточно самокритичны, поэтому делимся своим опытом с желающими поучиться =)

Друзья, если у вас есть что добавить - пишите в комментарии.

1              Вера на слово


Она же – отсутствие критического мышления.
Это когда тебе кто-то что-то рассказывает, говорит, что что-то устроено вот так, или будет устроено вот так, а ты киваешь головой, кушаешь все это, и так и записываешь. А потом оказывается, что всё не так, или не всё, а кое-что, но это кое-что сильно влияет на остальное.
Так бывает когда, например, сначала концепция была одна, а потом она изменилась, а твой рассказчик не в курсе, или просто забыл об этом. Ну, или кто-то что-то понял по-своему и тебе пересказал так, как сам понял. Это подводные камни, пираньи, которые ждут аналитиков в тихом водоеме.
Короче, всё нужно ставить под сомнение и проверять.

2              Копипаст


Копипаст, или же «Взятие чьего-то (какого-то) документа за основу для создания своего» - совершенно чудесная вещь. Делается с целью экономии времени и ресурсов. Аккаунт тебе говорит: «У нас уже есть хорошее ТЗ, его надо только чуток подправить». Ну, или ты берешь какое-то абстрактное ТЗ листов на стопятьдесят (главное, что про него известно - оно написано по ГОСТ) и думаешь: «Я быстренько выкину ненужное и добавлю свое». Ага, как же. Быстренько. В процессе вычитки глаз замыливается, и - вот оно, удивление заказчика: «Мы – российская компания, а у вас в ТЗ какой-то Казахстан упоминается!». Ну, это в лучшем случае. В худшем – тебя выгонят из кабинета с позором (перед этим кинув тебе в лицо упомянутое ранее ТЗ).
Ну, или аналитик копирует какие-то части интерфейсов, или логики работы из других приложений (наших или чужих, не важно) без особого понимания, почему это подойдет, и без какой-то готовности отстаивать что это решение как лучшее.
Вообще, копипаст дело неблагодарное – тем, что включает веру на слово и блокирует ваше Шестое Чувство.

3              Игнорирование интуиции


Это, вообще, песня.
Например, пишешь ты спецификацию и тебя терзают смутные сомнения, что…:
  • не для всех очевидно поведение функции, сценарий по которой ПМ решил не документировать во имя экономии времени (такое часто бывает, например, когда спецификация нужна вчера, но по плану работа над ней должна начаться через неделю);
  • всё в документе кажется взаимосвязано и последовательно, но всё-таки где-то тут собака порылась и надо бы порыться и тебе, правда, сроки поджимают;
  • как-то всё не совсем удобно и красиво;
  • вот это решение не делать фильтрацию и сортировку, про которые заказчик сейчас забыл упомянуть, не «по фэн-шуй» и не «юзабилити»;
  • надо бы заложить реализацию той пары отчетных форм, которые есть в регламенте заказчика, и о которых заказчик не упомянул в своем интервью;
  • надо, надо поднять этот вопрос на уровне команды / задать его заказчику / включить описание в спецификацию / конкретизировать требование в документе;
  • заказчика не устроит альтернатива, которую навязывают разработчики/архитекторы;
  • вот эту большую и сложную задачку надо бы сделать сейчас, а не откладывать на финал проекта…

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

Какие могут быть последствия?

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

Похуже – если заказчик поднимает тот самый вопрос и таки- требует сделать по-человечески удобно / добавить фильтрацию и сортировку / добавить отчетные формы, про которые он, и правда, забыл, - и это будет стоить вам нервов, а команде, в зависимости от обстоятельств, может стоить лишней трудоемкости.

А самое ужасное – когда этот, нераскрытый, вопрос приводит к переделке некоего функционала. Ну, или к дополнительному функционалу, от которого можно было вовремя спастись ограничением требований.

4              Игнор официальных документов (договора, ТТ, ТП, ТЗ и т.д.)


А вот это уже самая великая самоподстава.
Например, ПМ и аккаунт в один голос говорят «Мы с заказчиками договорились, что это не делаем!».
В этот момент аналитик должен вспомнить фразу «Что написано пером, того не вырубить топором!». Потому что, действительно, не вырубить и делать всё равно придется. Со слезами. Заказчики – они же хозяева своего слова. Сегодня дали, завтра забрали. Даже если сейчас тебе (ПМ и аккаунт) не поверят, то потом (когда наступит это «придется»), можно будет злорадно произнести «Я же говорила!». Ну, и делать, конечно.

5              Очевидное


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

6              Молчание

Иногда молчание - это не золото, а зло.

Этой ошибкой страдают излишне амбициозные или же не уверенные в себе люди.

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

Аналитик может уйти в себя и думать над задачей долго-долго, гуглить, рыться в книжках и т.п., вместо того, чтобы посоветоваться с коллегами и быстро получить желаемое – чаще всего в ближайшем окружении находится человек, владеющий информацией или способный подсказать, у кого еще спросить, где что почитать.

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

7              Спешка


Наверное, у каждого аналитика бывает острое желание быстро-быстро сделать работу. Прям вот рррраз! - и готово. Скоро-скоро выдать крутой результат, и получить звание героя аналитического труда (хотя бы на некоторое время).
На практике замечено, что впоследствии проект ждут разнообразные приключения. Например, не продумал аналитик взаимосвязи. И вооооот к нему потянулись с вопросами сначала разработчики, потом тестировщики, потом преемники-аналитики... Скучно не будет.
А уж если не продумать влияние функций друг на друга, и перед сдачей обнаружить их взаимоисключение (такое бывает на больших проектах)…
Попробуйте сами представить сколько работы прибавится всем-всем-всем.

8              Устные договоренности


Порой случаются неожиданности.
Переговоры были трудные, все в мыле, много спорили, доходило до криков… но вы получили то, что хотели. Другая сторона согласилась на ваши условия.
И вот вы радостно, с оптимизмом глядя в будущее, бросаетесь реализовывать требования. Проходит неделя, месяц.. Приходит срок демонстрации функционала.
А заказчик внезапно… не помнит о ваших договоренностях. Снова – здорово. Снова переговоры, вы аргументируете, что вы же договорились!.. Что заказчик согласился на ваши условия!.. И вы же в добрых партнерских отношениях… Как же так?..
«А была бы бумага…»
Сюда же относятся недокументированные соглашения внутри команды. Сегодня вы с разработчиками договорились делать функцию так, а завтра обнаружили, что сделана она несколько иначе (совсем иначе), а разработчики говорят, что вы так и договорились. Чем докажете свою правоту, господа аналитики?
Аналитик всегда должен помнить фразу «Что написано пером, того не вырубить топором!». Очень важно сразу после очной встречи или телефонного разговора зафиксировать принятые решения в письме и отправить другой стороне с просьбой подтвердить правильность записанного.
Так сказать, доверяй, но подтверждай.

9              Единственный источник информации


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

10              Потеря причинно-следственных связей


Самая катастрофическая ошибка аналитика.
«Куда ты ведешь нас? Не видно ни зги!»
Отсутствие способности выстраивать ПСС наравне с буйной фантазией приводит к дырам в функционале и серьезным травматическим последствиям – как для психики разработчиков, так и для проекта в целом.
«Откуда взялось это требование?», «Зачем нам реализовывать эту функцию вот таким образом, а не таким?», «Как это повлияет на соседний функционал?», «А что будет, если пользователь нажмет на кнопку [Сохранить] не заполняя это поле?»..
Одним словом, аналитик должен точно представлять картинку в целом, а не одну функцию, и знать, откуда-куда-зачем-и-когда. А самое главное - ясно излагать это в документах и спецификациях.

11              Мелочи


Мелочи – это такая штука, которая достает медленно и с гарантией.

Аналитик протоптал дорожку к руководителю проекта (или старшему аналитику, или другому коллеге) с маленькими вопросами: «А как будет тут? А как сделать лучше, я не знаю? А что вот в этом случае? А где посмотреть?» То и дело, то есть, частенько, и не имея своего варианта ответа. Вроде мелочь, а отвлекает и раздражает. Создается впечатление, что своим мозгом аналитик не пользуется, а использует мозги коллег.

Ну, или начинает писать документ, не продумав сначала его структуру и последовательность изложения, не придерживается единого стиля… Потом тут надо поправить, там… И в итоге получается сумбур и отсутствие единой картины.

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

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

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

Часто случается отсутствие примеров в документах. Например, описана методика расчета, но нет примера с конкретными данными, и, как следствие, от взгляда аналитика ускользают какие-то нюансы, например, округление, размерность и т.п.

Бывает, что аналитик может описать сто частных случаев вместо описания одного-двух основных принципов, объединяющих эти сто случаев.

Еще бывает, что аналитик стремится приукрасить текст или рисунок, привнести частичку себя. Потом приходится идущему следом за ним всё это удалять. Ну, и неприятно, если заказчик тыкает пальцем в подобные «красоты».

«Мелочи не играют решающей роли. Они решают всё!» (с)

13              Не уверенная позиция


Она же - неготовность отстаивать свое мнение.
Разработчик спрашивает «А может вот так лучше?», а аналитик сразу соглашается: «Ладно, давай так».
Тут возникает вопрос: а зачем аналитик описывал свой вариант? Ведь было же там что-то ценное? Если не было, то напрашивается вывод, что аналитик – тюфяк, у которого нет собственного мнения, и сомнения в том, что он действительно проанализировал требования.
Всё это, конечно же, приводит к потере драгоценного времени.

13              Перегорание


Отдельно хочу сказать про неумение некоторых аналитиков вовремя остановиться. Они полностью вкладываются в работу, буквально уходят в неё с головой, «жгут», забывая пообедать, попить воды и даже сходить в туалет (да-да).
Такие вещи чреваты накоплением усталости, нервными срывами, снижением иммунитета и, как следствие, снижением качества и производительности работы.
Моя позиция в этом вопросе проста: всему свое время. Время работать и время отдыхать. И ответственность каждого человека - самостоятельно отслеживать свои физические и психологические ощущения и регулировать свою деятельность.

Аналитика – это искусство балансировать


В чем призвание аналитика, его главная задача?

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

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

Ничего лишнего и всё, что необходимо.

П.С.: на семинар пришли некоторые из наших коллег-разработчиков, и, как водится, начались холивары: "Вы плохо пишете" - "Вы спецификации не читаете!"

Похоже, в ближайшее время мы создадим семинар "Ошибки разработчиков глазами аналитиков" =)



Подробнее