Продолжаем обзор различия между бесплатным nanoCAD 3.7 и платным nanoCAD 4.0. После того, как мы рассмотрели новшества, которые появились в платформе nanoCAD, рассмотрим оптимизированный функционал — тут тоже есть что-то относящееся только к 4-ой версии.
Тот кто только начал нас читать, рекомендуем начать со статей "Двойная звезда nanoCAD: бесплатный 3.7 и платный 4.0" и "nanoCAD 3.7 vs 4.0 – что появилось нового? (часть №1)".
Читать полностью »
Вольный перевод статьи о том, почему важно делать эскизы, прежде чем приступать к прототипированию. Мне, как менеджеру проектов и, по совместительству, проектировщику интерфейсов — статья показалась очень полезной. Крайне рекомендуется к прочтению всем участникам проектных команд.
Этим летом в нашей компании произошло два события: выпуск новой версии nanoCAD 4.0 и обновление бесплатной версии nanoCAD 3.5 до версии 3.7 (о причинах такого шага мы рассуждали в предыдущей статье «Двойная звезда nanoCAD: бесплатный 3.7 и платный 4.0»). И, конечно, от пользователей начали поступать вопросы: чем отличаются? а что лучше использовать? Для ответа на эти вопросы, конечно, надо забраться в техническое описание новых функций каждого продукта и сравнить. А затем решить для себя, что вам для работы подходит больше.
Мы решили вам немного помочь — описывая каждую новую/оптимизированную функцию, мы поставим рядом с ней специальный значок — в какую версию программы она включена… А уже вы выбирайте решение под себя :-)
Начнем с новых функций, которых раньше не было в nanoCAD…
Читать полностью »
В первой и второй частях статьи мы рассмотрели четыре первых шага на пути проектирования приложения:
В третьей части мы поговорим о том, как предполагаемая функциональность приложения должна пробрасываться через интерфейс приложения: где ее следует завязывать на системные решения, где использовать специальные элементы управления, а где ее нужно интегрировать в контент.
Читать полностью »
Данная статья является продолжением моих статей (Часть 1, Часть 2, Часть 3) о применении ГОСТов 34й серии. Сегодня мы поговорим о таком важном и, не побоюсь этого слова, ключевом моменте в создании автоматизированной системы как Техническое задание.
Только еще раз хочу напомнить, что ГОСТ – это не готовый рецепт. Это всего лишь шаблон. Необходимую информацию вы занесете в него сами. И сами решите, что надо заносить и какие пункты использовать. Вам никто не мешает сделать ТЗ вообще на полстраницы. Только учтите, что ТЗ вы пишете не для ГОСТ и не для дяди. Вы его пишете для себя. Потому что именно вы будете по нему работать.
Читать полностью »
Лето 2012… Проект nanoCAD, разрабатываемый нашей компанией претерпел существенные изменения: из бесплатного nanoCAD выделилась платная версия. Можно сказать, что мы прошли первую ступень Star(T)Up’а – nanoCAD крепнет и развивается. Далее путешествие по бескрайним просторам САПР-космоса будут осуществлять две (одинаково важные для нас) версии nanoCAD.
О причинах разделения, различиях и наших планах на будущее – в статье ниже.
Читать полностью »
В предыдущей части мы рассмотрели три первых шага на пути проектирования приложения:
Как вы могли заметить, первые три шага действительно можно смело применять к любым проектам,
я думаю, они от этого только выиграют. В этой части мы рассмотрим четвертый шаг — планирование навигации в приложении, и на этот раз нам никак не обойтись без понимания специфики Windows 8.
Одна из сложностей, с которой, по моему опыту, сталкиваются практически все разработчики и дизайнеры, работая над приложениями для Windows 8 и Windows Phone, начинается прямо с порога – с проектирования того, как пользователь будет взаимодействовать с приложением (UX и UI).
Часто разработчик (автор приложения) приходит с некоторой готовой идей и старается напрямую перенести в Windows 8 привычную десктопную, мобильную или веб-функциональность. Обычно эта прямолинейная попытка «портирования» оборачивается стремлением сохранить все, что есть в оригинальном решении, включая схожие шаблоны решения интерфейсных задач и знакомые приемы разработки и написания кода.
Читать полностью »
Данная статья является третьей частью и продолжает рассмотрение ГОСТов 34й серии (часть 1, часть 2)
Теперь пришло время поговорить о шестой стадии разработки АС, а именно о стадии «Рабочая документация». Что же это за стадия такая? Как я заметил ранее во второй части, эта стадия настолько близка к стадии «Технический проект», что даже ГОСТ 34.601-90 при всей своей строгости допускает объединение этих стадий в одну «Техно-рабочий проект». В чем же между ними разница? Разница достаточно очевидная (как и родство): если на стадии «Технический проект» мы готовили комплект документов именно на проект АС как таковой, то на стадии «Рабочая документация» мы готовим комплект документов необходимых непосредственно для внедрения АС на конкретной площадке.
Читать полностью »
После появления статей типа "Я не знаю ООП" — возникает желание внести ясность, «сорвать покровы» и «докопаться до истины».
Обычно выделяют (читай: на собеседовании требуют назвать) четыре «принципа объектно-ориентированного программирования»: абстракцию, инкапсуляцию, наследование и полиморфизм.
На мой взгляд (не говоря о том, что абстракция и полиморфизм могут быть запросто отнесены к подразделам наследования), принцип тут один, в общем, тот же самый, что при проектировании баз данных: представление всего в виде объекта — некоторой штуковины со свойствами. Набор обычно бывает фиксированным, и тогда говорят о классе объектов, а даже если понятия класса и нет, то наличие свойств с определёнными названиями подразумевается логикой программы, т.е. нечто типа класса в виде некоего минимального набора свойств всё равно присутствует. В общем, воззрения восходят к давнему С-шному/паскалевскому типу данных struct/record. Потом к этому добавили немного «функциональности» (в смысле функционального программирования): значением свойства может быть функция, причём такая, которая имеет доступ к самой структуре/записи, значением одного из свойств которой она является. Сей феномен, в лучших традициях немецкого латиноязычного нейминга (когда опция называется «вариантом», а степень числа — «потенцией»), назвали «методом». Желание повторно использовать код, в сочетании с представлением каждого предмета как некоего подобия паскалевской «записи», привело к появлению концепции «наследования».Читать полностью »
