Меня зовут Андрей Кармацкий, и я руковожу работой над дизайном Яндекс.Карт. Весной я ездил в Новосибирск на конференцию Codefest 2013, на которой рассказывал о том, как мы разрабатываем дизайн Яндекс.Карт. Это была хорошая возможность структурировать накопленные знания в небольшую историю, которой хочется поделиться и с вами.

Почему я люблю карты?

Карты завораживают меня своей красотой, за которой скрывается большой смысл, — информация, кропотливо собранная и структурированная.

Например, Carta Marina братьев Магнусов. Может показаться, что это просто красивая иллюстрация. На самом деле, это уникальный исторический документ, который содержит множество сведений и исторических фактов о Северной Европе XVI века. На сегодняшний день сохранилось только две копии этой карты.



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

Одним из главных недостатков традиционного .NET API в .dwg совместимых САПР является невозможность создания пользовательских примитивов (Custom Entities) на .NET. Пользовательские примитивы создаются на С++, для их использования в .NET необходимо создать управляемые обёртки на C++/CLI.

Технология MultiCAD .NET позволяет создавать пользовательские примитивы, не выходя за рамки управляемого кода. Помимо отсутствия промежуточных объектов на C++, в MultiCAD .NET максимально используются стандартные для .NET механизмы, как следствие нет необходимости во многих привычных для САПР программистов операциях: не нужно вручную описывать сериализацию, свойства в инспектор можно вывести без создания COM объекта и т.п.

В качестве демонстрации MultiCAD .NET мы рассмотрим пример приложения CustomObjects, содержащийся в комплекте поставки SDK. Этот пример создает пользовательский примитив, который представляет собой прямоугольную рамку с находящимся внутри текстом:



Чертежи, содержащие наш тестовый примитив, могут быть открыты в любой .dwg совместимой САПР. Для изменения примитива необходимо загрузить сборку, содержащую код примитива, причём во все поддерживаемые САПР платформы загружается одна и та же сборка без перекомпиляции. Технология является родной для nanoCAD, для загрузки модуля в AutoCAD требуется модуль расширения (Object Enabler). Как это работает смотрите под катом.

Шесть месяцев назад ребром встал вопрос о тексте для моего дипломного перевода. Результатом помощи коллективного разума стало решение переводить главу Scalable Web Architecture and Distributed Systems за авторством Kate Matsudaira. Нужно отметить, что это мой первый перевод такого объема и сложности. Текст, был мною относительно успешно переведен, хотя по качеству перевода я поставил бы себе 6-7 из 10. Дабы мои усилия не пропали втуне, публикую результат своих трудов.

По просьбам читателей Хабра, теперь полная версия в виде топика.

Масштабируемая веб-архитектура и распределенные системы

Кейт Матсудейра

Перевод: jedi-to-be.
Коррекция: Anastasiaf15, sunshine_lass, Amaliya, fireball, Goudron.

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

Огромная и очень богатая компания, собравшая под своим крылом множество профессионалов, лучших спецов по юзабилити. Компания, занимающаяся сбором статистик, собирающая фокус-группы, проводящая маркетинговые исследования. Всякий раз возникает один и тот же наболевший вопрос: где результат, который устроит пользователя? Сейчас Фейсбук — воплощенный в реальность бардак.

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

Но моя статья не о том. Я хочу представить вашему вниманию свой труд, на который меня изначально натолкнул пользователь Klimentij, написавший статью «Юзабилити Facebook». Долгое время хотел им заняться и вот, наконец, появилось свободное время.

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

Зачем это надо? Я хочу показать свой Фейсбук с простым и понятным интерфейсом, который будет дружелюбным по отношению к пользователю, повысить юзабилити и сделать его более трендовым. Хочу заметить, что это лишь мое видение проблемы, многие элементы могут нуждаться в переосмыслении, так что не судите строго.

Весь УИ представлен на английском. Во-первых, ближе к оригиналу; во-вторых, в текущей версии его русификация некорректна.

По роду занятий я часто общаюсь с различными русскими и западными командами. Очень частый вопрос — есть ли какая-нибудь специфика в работе наших и как это влияет на разработку?

Есть очень неплохая книжка о специфике работы русских вообще. Она называется «Русская модель управления». Ее написал А.П.Прохоров (другой, не олигарх). Не буду ее пересказывать. Основная идея в том, что русские по своей природе могут работать только в двух модах. В нестабильном состоянии они могут свернуть горы. В это время мотивация очень высокая. В стабильном расслабленном состоянии — когда никто не пинает — русские вроде как работают плохо и не сильно утруждаются.

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

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

Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.

Итак, предыдущая часть была посвящена настройке сервиса SQL Reporting в Windows Azure. Мы рассмотрели два варианта настройки сервисов публикации отчетов: как сервис (SQL Reporting) и с использованием виртуальной машины SQL Server (SSRS). Теперь давайте разберем способ настройки сервисов SQL Reporting и SQL Server для поддержки сценариев multi-tenant, когда один сервис отчетов может использоваться для разных источников данных.

Публикация проекта

1. Откройте проект отчетов в “SQL Server Business Intelligent Development Studio”;
2. В контекстном меню проекта выберите пункт “Properties”;
3. Мы будет разделять отчеты одного заказчика от другого, используя разные корневые каталоги. Для этого в значения полей с префиксом “Target…Folder” укажите корневой каталог с именем заказчика;
   
   
4. Опубликуйте проект отчетов для разных заказчиков в SQL Reporting service и/или виртуальную машину SQL Server.

Здравствуйте дорогие хабражители.

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

Так вот, я собственно и есть тот самый «парень в оранжевом», и хочу опровергнуть предыдущую информацию — я не выбрасываю сервера, фотки постановочные и вообще все фотошоп и провокация. Я складываю их в кладовку, а они там собирают пыль. Люди о них запинаются и расстраиваются. После предыдущего поста мы получили массу писем с просьбами не выбрасывать сервера в мусорный контейнер, а отдать их для опытов или в хорошие руки, утряся все проблемы с бухгалтерией мы решили поступить именно так.

Некий dypsilon выложил на GitHub огромную коллекцию ссылок на ресурсы по веб-разработке, за что ему огромное спасибо.

Список состоит из ссылок на библиотеки, руководства и статьи.

Frontend: github.com/dypsilon/frontend-dev-bookmarks
Backend: gist.github.com/dypsilon/5819528 (много node.js)

Ссылок много, но все — строго по делу и упорядочены по группам (пример для фронтенда):

1. Архитектура
2. Фреймворки
3. Cross Browser
4. Cross Device
5. Паттерны и сниппеты
6. Манипуляция с DOM
7. … и многое другое

matmuchrapna советует еще frontdesk Вячеслава Олиянчука.
Настоятельно рекомендуется добавить в закладки, а лучше — почитать.

Здравствуйте.

Понадобилось мне использовать для анализа данных OLAP кубы. Эту технологию я активно изучал и использовал в 2001-2002 годах и даже сертифицировался по ней. Но потом долгое время не прикасался к ней. И вот совсем недавно попробовал воспользоваться 2012 SQL Server’ом, но не тут то было: многое и того что появилось в новом сервере оказалось мне совершенно не знакомым.

Потратив некоторое время на знакомство, решил поделиться навыками с сообществом: записал обучающий видеоролик о том, как создается куб и измерения.

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

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

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

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

Когда-то я говорил, что к собеседованию должен готовиться не только соискатель, но и интервьювер. Теперь я сам провожу собеседования, но после десятого интервью все соискатели выглядят как китайцы – одинаково.

Когда-то я говорил, что опаздывать на встречи могут только пид$расы. Теперь я сам часто опаздываю на встречи, но в то же время не сплю с мужиками.

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

Изображение защиты

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

1. ограничение/запрет постинга прямых ссылок на оригиналы изображений
2. вы параноик и пытаетесь ограничить распростронение копий изображений

UPDATE
Универсальной защиты конечно же не существует. Статья о том, как не подставлять напрямую данные из GET в SQL-запросы. Только в контексте защиты изображений.

Концепция

Я работаю с ASP.NET достаточно давно. При разработке многих проектов я часто сталкивался с тем, что однотипные операции по управлению данными занимают слишком много времени. Естественно для сайтов существуют CMS системы, а для более сложных систем различные генераторы шаблонных страниц, которые создают заготовки для форм редактирования и просмотра информации. Но мне хотелось получить более универсальный инструмент, который в тоже время не накладывал бы ограничений на процесс построения архитектуры приложения.

Недавно я получил от своего знакомого вопрос примерно следующего содержания:

Добрый день Михаил! Сейчас занимаюсь одной исследовательской работой. Учитывая ваш профессиональный опыт, хотел бы вас попросить ответить на вопрос:

Вы выпустили продукт, который делали целый год, потратив на разработку все инвестиции. Из 1 000 первых пользователей 995 удалили его или перестали им пользоваться на следующий же день. Опишите ваши действия.
Заранее благодарю!!!

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

Вообще, у меня сложилось мнение, что об успехе продукта можно сказать примерно через полгода. Маркетинговые кампании, ПР и просто сарафанное радио — вещи довольно долговременные, а информация должна иметь время, чтобы распространиться. Впрочем, если ваш продукт стал успешен с первого дня, это заметно сразу, но такие продукты — тема совершенно другой статьи из разряда Success Story. Мы же поговорим о том, что делать, если на взлёте отказали оба двигателя.

Что посеешь, то и пожнешь
Из желудя вырастет дуб,
Из семени репейника — только репейник
Профессиональное образование —
это семена, которые мы сеем...

Поиск высококлассных специалистов — один из самых сложных вопросов в бизнесе, связанном с разработкой ПО. Несмотря на все сложности мировой и отечественной экономики, квалифицированных кадров не хватает катастрофически. Количество проектов, требующих высокой квалификации, растет значительно быстрее, чем “зреют” специалисты (разработчик — 2-3 года, ведущий разработчик — плюс 2 года, архитектор решения — плюс 3–5 лет ...).

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

Структурные исключения — один из ключевых механизмов обработки ошибочных (в том числе и собственно исключительных) ситуаций. Ниже перечислены некоторые рекомендации по программированию, повышающие общее качество кода при работе с исключениями на C# и шире — платформе .NET.

Собственный класс. Выбрасывайте исключения на основе собственного класса, унаследованного от Exception, а не напрямую — на основе Exception, потому что это дает возможность определить свой собственный обработчик и отделить отслеживание и обработку исключений, выбрасываемых вашим кодом и кодом фреймворка .NET.

Отдельные поля. Создавайте отдельные поля в собственном классе для передачи существенной информации, вместо сериализации и десериализации данных в поле Message. Несмотря на то, что идея упаковки в Message сложных данных в виде строки типа JSON выглядит соблазнительно, это редко является удачной идеей, поскольку добавляет дополнительный расход ресурсов на кодирование, локализацию, декодирование.

Мы продолжаем публиковать стенограммы выступлений с нашего декабрьского Design Camp. Сегодня на очереди статья Алексея Кулакова из JetStyle. Видео-версия выступления доступна на techdays.ru, презентацию можно скачать там же.

Как и ранее, это авторская статья и не отображает позицию компании Microsoft.

Статья написана по мотивам доклада для дизайнеров (в основном).

У меня есть объекты ненависти в нашем дизайн-процессе. Я хочу поделиться ими с вами, возможно, это что-нибудь изменит.

Надеюсь, объяснять, что дизайн — это не «красивые картинки» уже никому не надо. Мы все понимаем, что на самом деле занимаемся выстраиванием эффективной коммуникации визуальными средствами.



Все, о чем пойдет речь, исходит из того, что мы (дизайнеры) решаем задачи живых людей, что сами дизайнеры — живые люди. Сознательные, наделенные волей, ответственностью, выполняющие определенную функцию. Функция эта заключается в обмене содержанием с помощью экрана. Собственно, это и называется интерфейсом =)

Интерфейс — это «оболочка», которая позволяет взаимодействовать с каким-то содержанием. Оболочка состоит из навигации, кнопочек, формочек, разной красоты и т.д. А есть то, что в этом интерфейсе «лежит», то, что пользователь из взаимодействия с ним извлекает — содержание. Интерфейс для того и нужен, чтобы его передать. Даже тогда, когда речь идет не о «контентных сайтах», а об инструментах, пользователь извлекает что-то из интерфейса, и что это надо очень хорошо понимать.

Проект, ведущийся по заказу Минпромторга коллективом разработчиков под руководством МГТУ «СТАНКИН», вышел на финишную прямую.

27 марта 2013 года было объявлено о сдаче очередного этапа НИОКР по созданию отечественного лицензируемого программного ядра трехмерного моделирования. В рамках этого этапа впервые была получена полнофункциональная версия программного продукта.

Геометрическое ядро трёхмерного моделирования — это программная компонента, предназначенная для использования в качестве базового инструментального средства при разработке программных систем, связанных с точным компьютерным моделированием физических трёхмерных объектов. Конечными продуктами, которые могут быть разработаны на основе такого решения, являются системы автоматизированного проектирования (CAD), подготовки производства (CAM), инженерного анализа (CAE) и многих других приложений инженерного программного обеспечения. Во всех таких системах требуется точный и высокопроизводительный инструмент для работы с моделью — формирования данных, хранения, восстановления, средства анализа, специализированные расчёты и многое другое.

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

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

Как я докатился до этого

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

По личным причинам после окончания ВУЗа остался в том же городе, тут же в России на пару-тройку лет (хотя настроение «поравалительное»). Изначально аспирантура не планировалась, но за пару месяцев до диплома я понял, что этого времени достаточно для чего-то более существенного, чем 3 года просто работы системным администратором. Решил пустить усилия в русло науки.

Группа исследователей из IBM, используя информацию о перемещениях 500 тыс. пользователей мобильной связи, разработали модель для улучшения маршрутов общественного транспорта.

Модель успешно опробовали в городе Абиджан (население 3,8 млн человек, столица Кот-д’Ивуара). На иллюстрации показаны действующие маршруты автобусов (малиновым) и улучшения, предлагаемые алгоритмом (синим). Он предложил 65 возможных улучшений, в том числе три новых маршрута, с общей экономией времени 10% в пассажиро-минутах для всех пассажиров, учитывая время поездки и время ожидания.

Новый алгоритм полезен не только для оптимизации, но и для прокладки новых маршрутов в только что построенных микрорайонах. Здесь он чётко показывает, какими путями, в какое время и в каком объёме передвигается людская масса. Можно составить оптимальные маршруты и расписание транспорта. Важен сам факт появления нового инструмента, который могут использовать городские власти для оптимизации инфраструктуры мегаполиса.