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

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

Перевод статьи Марка Миллера: Why is Great UI so hard to achieve?

Сегодня утром, когда я заправлял свою машину бензином, мне в глаза неожиданно бросилось еще одно доказательство того, что большинство интерфейсов пользователя не удовлетворяют трём основным показателям хорошего интерфейса: ясности (clarity), эффективности (efficiency) и открытости (discoverability).

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

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

На первый взгляд кажется, что ничем другим кроме отката и повтора Undo/Redo не занимается и заниматься не может. Но это не совсем так.



При реализации XtraRichEdit настал момент, когда нам надо было сделать свойство, которое отвечает на вопрос, изменён документ или нет. Как именно его делать, на первый взгляд было вполне очевидно. Надо было завести переменную isModified и выставлять ей значение true, когда документ изменялся. В тот момент, когда пользователь сохранял документ, надо было присвоить ей значение false. Разумеется, изначальное значение переменной также было false, что означало, что документ не изменён.

Всё было просто и понятно и мы принялись за дело.

Создано множество компонентов для .NET, реализующих функциональность календаря и планировщика (органайзера). Их задача — предоставить пользователю возможности, сходные с теми, которые он получает при использовании конечных приложений Outlook Calendar, Apple iCal, Windows Calendar, интернет-календарей Google Calendar и им подобных. Важное место среди этих возможностей занимает печать. Функционал печати у компонентов должен быть не хуже, чем у специализированных приложений, но при этом предоставлять большую гибкость в настройках.

В данной статье мы хотим сделать краткий обзор DXCore и рассказать, чем может быть полезна эта .NET библиотека.

DXCore — это абсолютно бесплатный продукт, который мы развиваем и поддерживаем начиная с 2004 года. В двух словах, DXCore облегчает разработку расширений для Visual Studio.

Мы стараемся проектировать API этой библиотеки так, чтобы максимально упростить процесс создания плагинов — чтобы разработчики могли сосредоточится на функциональности и по возможности избежать основных сложностей интеграции с Visual Studio.

Живя и работая в современном мире IT, мы все — рано или поздно, так или иначе — обращаемся в службу технической поддержки. Как это выглядит для нас, пользователей, все более-менее представляют. Но вот что находится на обратной стороне Луны? Немногие из нас знают, как обычно устроена служба поддержки в той или иной организации… Мало представляли себе и мы, как правильно организовать работу суппорта, когда более 10-ти лет назад перед нами встала такая задача. За это время мы прошли долгий путь, набили себе немало шишек, и теперь хотим поделиться с вами нашим опытом в этой сфере.

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

Итак, как работают «Чип и Дейл» в компании DevExpress:

В этой статье мы продолжим рассказывать о том, как мы делали Undo/Redo в текстовом редакторе XtraRichEdit.

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

Нам же оставалось добавить возможность форматирования участков текста (шрифт, его размер и т.п.) и все остальные «мелочи» типа параграфов со всеми их свойствами, стилей и т.п. А ещё концепт не умел делать Undo/Redo.

Такая простая и привычная функция в любом текстовом и графическом редакторе. Казалось бы, какие могут быть сложности с её реализацией? Впервые столкнувшись с разработкой Undo/Redo для текстового редактора XtraRichEdit, мы задумались, а какой же подход нам избрать?

Приветствуем Вас от имени компании DevExpress.

В этом посте мы расскажем про то, чем занимается наша компания, и про тех, кто работает в её тульском офисе.

 

Многие их тех, кто использует .NET, Delphi и другие средства разработки, рано или поздно сталкивались с выбором: разработать что-то недостающее самому, или приобрести готовое? И со спокойной душой отправлялись писать свои собственные компоненты, неприятно поразившись стоимостью существующих. А так ли велика их цена на самом деле? Вот небольшая история, которая заставила меня взглянуть на стоимость компонентов другими глазами.