Привет. Меня зовут Роман, и я не изобретатель велосипедов. Мне нравится фреймворк Angular и экосистема вокруг него, и я разрабатываю с его помощью свои веб-приложения. С моей точки зрения, основное преимущество Angular в долгосрочной перспективе базируется на разделении кода между HTML и TypeScript, что подробно было описано одним из его разработчиков why-angular-renders-components-with.html Это преимущество имеет и обратную сторону: необходимость компиляции в принципе и сложность динамической компиляции компонентов в runtime. А так хочется использовать уже знакомый синтаксис шаблонов Angular, чтобы дать пользователю своих приложений возможность настраивать шаблоны писем, генерировать отчеты и таблицы для печати или задавать формат экспорта xml файлов! Чтобы узнать, как это сделать — добро пожаловать под кат!

Нынче в интернетах только и говорят об облаках, как они бесконечны и прекрасны… о серверах, которые они там видели… А ты? Вот и я решил поделиться с читателями своим опытом разработки онлайн сервиса проектирования помещений и интерьеров в 3D. Здесь я постараюсь рассказать об архитектуре проекта в целом и о деталях реализации.

В популярной платформе для быстрого создания веб-приложений скоро появится официальная поддержка SQL. Ранее разработчики неоднократно отказывались это делать, мотивируя тем, что SQL не вписывается в философию проекта. Однако, настойчивость сообщества сделала своё дело и уже сейчас вы можете попробовать предварительную реализацию поддержки SQL в Meteor. Все подробности — под катом!

В этой статье я предлагаю краткий обзор библиотек геометрического моделирования с точки зрения разработчика специализированной CAD системы и делюсь опытом интеграции ядра C3D.

Если рынок «больших» программ проектирования давно поделен между несколькими крупными игроками вроде AutoCAD, SolidWorks, NX, Creo Elements и CATIA и т.п., то рынок специализированных программ проектирования всего и вся – окон и лестниц, корпусной и мягкой мебели, трубопроводов и корпусов весьма широк и динамичен. Причин для этого, на мой взгляд, две: во-первых, это высокая стоимость покупки крупной САПР и сотрудника, умеющего в ней эффективно работать. А, во-вторых, отсутствие адаптации для проектирования конкретных изделий в крупной САПР приводит к тому, что скорость проектирования специализированных изделий в них низкая.

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

Всем доброго времени суток! В этой статье я хочу рассказать про трудности, с которыми столкнулся при отображении и обновлении древовидной структуры с помощью QTreeView и QAbstractItemModel. Так же предложу велосипед, который я создал, чтобы обойти эти трудности.