L>Хм. Реклама рекламой, но работать с технологией рано или поздно надо начинать.
Зачем надо? кому надо? в чем смысл слова "надо"? с целями деятельности определиться надо.
MSS>>Опять изучаем грабли путем наступания на них? L>К сожалению, я не знаю другого эффективного пути обучения.
А я знаю. Книжки, документация, примерчики. Этих трех вещей хватает, чтобы просто сесть и пойти вперед в разработке. Без прототипов и черновиков.
L>Этого конечно никто не отменял. Но по-настоящему технологию узнаешь только потрогав её руками. Документация-примеры — это всегда только начало, процентов 30 пути.
90. Документация-примеры-общение на профильных форумах = 90%.
Остальные 10 доберешь в процессе реальной работы. Может и лид подсказать. Я без старших товарищей справлялся.
L>In the perferct world
В реальной практике всех моих 15 лет профессиональной деятельности. Никто — повторяю, никто — не писал черновики на выброс, чтобы освоиться с технологией.
Здравствуйте, Maxim S. Shatskih, Вы писали:
AP>>По моему, в "Программисте-прагматике" для предотвращения подобной ситуации авторы советуют прототип писать не на вашем основном рабочем языке. Если пишете на C#, то сделайте прототип, для обкатки решения, на VB или Delphi.
MSS>Авторы жгут не по-детски. Иначе и не скажешь.
MSS>То есть — помимо "боевого" языка, всей командой выучить еще и "учебный"? а ведь любой язык, даже учебный — имеет свои заморочки и подводные камни.
На самом деле я совершенно исказил цитату, или всё-таки это была другая книга
Вот что пишут в Pragmatic programmer
Since a prototype should gloss over details, and focus in on specific aspects of the system being considered, you may
want to implement prototypes using a very high-level language—higher than the rest of the project (maybe a language
such as Perl, Python, or Tcl). A high-level scripting language lets you defer many details (including specifying data
types) and still produce a functional (albeit incomplete or slow) piece of code.[6] If you need to prototype user
interfaces, investigate tools such as Tcl/Tk, Visual Basic, Powerbuilder, or Delphi.
Автору топика рекомендую поискать эту книгу (Pragmatic Programmer) — позиция авторов по поводу прототипирования аргументирована и адекватна.
Раздел Prototypes and Post-it Notes
How Not to Use Prototypes
Before you embark on any code-based prototyping, make sure that everyone understands that you are writing
disposable code. Prototypes can be deceptively attractive to people who don't know that they are just prototypes.
You must make it very clear that this code is disposable, incomplete, and unable to be completed.
It's easy to become misled by the apparent completeness of a demonstrated prototype, and project sponsors or
management may insist on deploying the prototype (or its progeny) if you don't set the right expectations. Remind
them that you can build a great prototype of a new car out of balsa wood and duct tape, but you wouldn't try to drive
it in rush-hour traffic!
If you feel there is a strong possibility in your environment or culture that the purpose of prototype code may be
misinterpreted, you may be better off with the tracer bullet approach. You'll end up with a solid framework on which
to base future development.
When used properly, a prototype can save you huge amounts of time, money, pain, and suffering by identifying and
correcting potential problem spots early in the development cycle—the time when fixing mistakes is both cheap and
easy.
L>>Хм. Реклама рекламой, но работать с технологией рано или поздно надо начинать. MSS>Зачем надо? кому надо? в чем смысл слова "надо"? с целями деятельности определиться надо.
Ну, это несложно. Цель деятельности программерской конторы — разработка ПО за деньги. Зачастую новые проекты требуют использования новых (не обязательно новых в плане возраста) технологий, с которыми никто в команде (в конторе) ещё не работал.
L>>К сожалению, я не знаю другого эффективного пути обучения. MSS>А я знаю. Книжки, документация, примерчики. Этих трех вещей хватает, чтобы просто сесть и пойти вперед в разработке. Без прототипов и черновиков. MSS>90. Документация-примеры-общение на профильных форумах = 90%.
Э... Не все технологии одинаково хорошо документированны. Есть такие по которым и книжек днём с огнём не сыщешь, и примеры покрывают 10% юзкейсов, и документация оставляет желать лучшего. Предлагаешь отказаться от проекта пока технология не вызреет настолько что появятся все составляющие успеха? Предполагаю что иногда так и делают, но не все и не всегда.
L>>In the perferct world MSS>В реальной практике всех моих 15 лет профессиональной деятельности. Никто — повторяю, никто — не писал черновики на выброс, чтобы освоиться с технологией.
Ну а я в реальной практике за 12 лет профессиональной деятельности раза 2 или 3 сталкивался лично, и ещё несколько раз слышал про подобное от коллег. Бывают, бывают ситуации когда это оправдано. Пойми, мил человек — я не к тому что ты что-то неправильно делал или что-то неправильно понимаешь. Просто индустрия IT нынче разрослась ну шибко широко, и то что в одном её краю кажется идиотизмом и расходом средств впустую — в другом вполне себе оправданная практика.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Целью ее разработки было — получить полноценно многозадачную и почти полноценно 32битную ОС _с меньшими требованиями к памяти, чем НТ_.
+ требования почти полной совместимости с Win16 и DOS. NT этого там и не смогла обеспечить. Как раз 16-битный код в 95-ых для этого и использовался. По тем же причинам там были дыры в защите памяти.
MSS>Когда требования к памяти у НТ перестали быть напряжными — линейка Win9x стала умирать. WinMe был просто провальный продукт.
И когда потребность в 16-битных приложения стала отпадать (выпустили их 32-битные аналоги).
Вот сейчас скажем Вынь64 есть и отлично работает. На столах в большинстве своем 64-разрядные машины. Но большинство людей используют 32-битные ОС только в связи с тем, что основная масса софта 32-битная.
MSS>И исторически сначала сделали НТ, а уже потом — Win32 над старым VMM и 16битными GDI и USER, что и есть Win95. Т.е. поток идей шел из НТ в 95, а не наоборот.
На самом деле не совсем так. NT разрабатывалась (в самом начале) как замена OS/2 2.х и изначально ее API был развитем API Презентэшон менеджера из полуоси. Но в это время у МС выгорел проект с Windows 3.х. Она набрала нехилую популярность и было решено переоринтировать НТ на API Windows 3.х. Так как оно было 16-битным было решено создать 32-битное API максимально совместимое с 16-битным, для облегчения миграци программ написанных под Вынь 3.х.
Так был разработан Win32 API. Причем сразу этот API подразумевал разный уровень поддержки. Скачала свет увидел Win32S — это обертка для 16-битного API. Он ставился на Вынь 3.1 и позволял запускать 32-битные приложения из под нее. Но все вызовы в Вынь32Эс конвертировались в 16-битные, а многоие и вовсе не были реализованы (били только заглушки ничего не делающие). В НТ Win32 API был реализоан полноценно. В 95-ых он был реализован, но с некоторыми ограничениями и позже чем в НТ или Вынь32Эс.
Так что таки, да, Вынь 95 была после НТ, но таки, Win32 API был специально разработан как замена 16-битному и не только для НТ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, iZEN, Вы писали:
ZEN>Интерфейс пользователя WinNT4 (win32.sys и comctl.dll) оттачивался на Win95 и только после этого в 1996 году была выпущена WinNT4 с интерфейсом "как у Win95".
Сам то понял что сказал?
ZEN>OLE/OLE32 и ActiveX первоначально обкатывались в Win3x/Win95 и только потом переносились в NT-линейку.
OLE — это вообще прошлый век существоваший только в 16-битном мире (как набор сообщений Виндовс).
OLE32 никогда не было в природе. Было OLE 2. Так вот OLE 2 — это набор СOM-интерфейсов независимый от платформы. А COM как раз и разрабатывался для него. И специальной поддержки COM в ОС не требуется. Вот DCOM-это другое дело. Причем в Win16 его вообще не было. А в 95-ых он ставился отдельно. И только в НТ он поставлялся и поставяется в составе ОС.
ZEN>Впоследствии даже система драйверов перекочевала из Win98 в Win2000.
Каких еще драйверов? Причем тут драйверы?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
L>Э... Не все технологии одинаково хорошо документированны. Есть такие по которым и книжек днём с огнём не сыщешь, и примеры покрывают 10% юзкейсов, и документация оставляет желать лучшего. Предлагаешь отказаться от проекта пока технология не вызреет настолько что появятся все составляющие успеха? Предполагаю что иногда так и делают, но не все и не всегда.
Бывает. Согласен. Но как из этого следует написание _черновика_ на весь проект? ну, написали исследовательский код. Ну, он заработал. И что — теперь его в помойку, и заново переписывать?
Надо сразу чисто писать, даже исследовательский код, если есть шансы, что он заработает.
Предложение писать прототип UI на Пауэрбилдере — это достаточное ИМХО основание не покупать книгу.
Видите ли, у ПауэрБилдера (оставим в покое вопрос качества этого тула) свой достаточно развитый набор готовых UI элементов, в этом вопросе он примерно соответствует Access. И желаю счастья потом отписывать на Си++ точно такие же.
MSS>Бывает. Согласен. Но как из этого следует написание _черновика_ на весь проект? ну, написали исследовательский код. Ну, он заработал. И что — теперь его в помойку, и заново переписывать?
Как правило — да, лучше в помойку. Прототип же не обязательно по размеру кода сопоставим с оригиналом Это ж только концепция, функционала в нём — дай Бог если 25% от всего проекта, о производительности и масштабируемости вообще обычно не думают, так что кода там процентов 10% от основного проекта.
Кстати, как пример — я бы привёл примеры кода из MSDN (не все, но подавляющее большинство). Как правило, они кусками копипейстятся в прототип, но из продакшн кода я их стараюсь всеми силами выковыривать, оставляя ту же логику работы но переписывая всё втрое короче и понятнее.
MSS>Надо сразу чисто писать, даже исследовательский код, если есть шансы, что он заработает.
Э... Опять же — я согласен что НЕПЛОХО БЫ было уметь так писать. Но зачастую, не обладая чётким пониманием технологии написать сразу чисто просто не под силу даже очень опытному разработчику.
Давайте я лучше приведу конкретный пример: был проект, нужно было захватывать видео со встроенной камеры в мобильном девайсе на базе WinMobile. С мобильными девайсами был небольшой опыт работы, с DirectShow (а он там как и всё остальное на Win Mobile — слегка специфичный) — не было вообще. В результате — написали прототип (с жутким качеством кода, поскольку код на 75% состоял из кусков накопипейстеных из китайских форумов и прочих весьма сомнительных мест). А потом, когда примерно поняли что и как нужно делать — переписали всё заново. Зато прототип смогли быстро показать заказчику, который увидел какого качества видео можно ожидать .
MSS>Видите ли, у ПауэрБилдера (оставим в покое вопрос качества этого тула) свой достаточно развитый набор готовых UI элементов, в этом вопросе он примерно соответствует Access. И желаю счастья потом отписывать на Си++ точно такие же.
А не обязательно точно так же. Нужно просто похоже. Никто не требует от прототипа 100% соответствия релизной версии.
Хотя честно говоря сама идея писАть прототип на другом языке мне не кажется слишком удачной. Overkill, IMHO.
L>Давайте я лучше приведу конкретный пример: был проект, нужно было захватывать видео со встроенной камеры в мобильном девайсе на базе WinMobile. С мобильными девайсами был небольшой опыт работы, с DirectShow (а он там как и всё остальное на Win Mobile — слегка специфичный) — не было вообще. В результате — написали прототип (с жутким качеством кода, поскольку код на 75% состоял из кусков накопипейстеных из китайских форумов и прочих весьма сомнительных мест).
Вам повезло, что это вообще заработало даже как демка. Не повезло бы, возникли бы какие баги неприятные — все равно пришлось бы для их исправления изучать DirectShow, в т.ч. специфичный для CE.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, iZEN, Вы писали:
ZEN>>Интерфейс пользователя WinNT4 (win32.sys и comctl.dll) оттачивался на Win95 и только после этого в 1996 году была выпущена WinNT4 с интерфейсом "как у Win95".
VD>Сам то понял что сказал?
Угу. Explorer оттачивался в Win9x, а только потом переносился в NTx.
iZEN>>OLE/OLE32 и ActiveX первоначально обкатывались в Win3x/Win95 и только потом переносились в NT-линейку.
VD>OLE — это вообще прошлый век существоваший только в 16-битном мире (как набор сообщений Виндовс). VD>OLE32 никогда не было в природе. Было OLE 2. Так вот OLE 2 — это набор СOM-интерфейсов независимый от платформы. А COM как раз и разрабатывался для него. И специальной поддержки COM в ОС не требуется. Вот DCOM-это другое дело. Причем в Win16 его вообще не было. А в 95-ых он ставился отдельно. И только в НТ он поставлялся и поставяется в составе ОС.
OLE, оно же OLE16, оно же VB OCX. Модули для программирования приложений в VisualBasic, писались на MS VisualC++ начиная с Windows3.1.
OLE2, оно же OLE32, позднее переименовано в ActiveX и COM (Component Object Model). Под эту модель затачивался реестр 32-битных версий Windows.
Windows 95 вышла в августе 1995 года. Windows NT4 вышла в июле 1996 года. Прототипирование и обкатка технологий прослеживается как нигде, особенно в прикладных вещах.
iZEN>>Впоследствии даже система драйверов перекочевала из Win98 в Win2000.
VD>Каких еще драйверов? Причем тут драйверы?
Windows Driver Model — *.WDM
Впервые появилась в Windows 98 (июнь, 1998), прошла в Windows ME (сентябрь, 2000), заменила систему управления драйверами в NT-линейке с выходом Windows 2000 (февраль, 2000).
(Ты ж вроде на Windows и должен помнить историю. )
ZEN>Впервые появилась в Windows 98 (июнь, 1998), прошла в Windows ME (сентябрь, 2000), заменила систему управления драйверами в NT-линейке с выходом Windows 2000 (февраль, 2000).
Не заменила, а расширила. WDM — это НТ4 модель драйверов с добавленными PnP & Power.
Здравствуйте, Maxim S. Shatskih, Вы писали: MSS>90. Документация-примеры-общение на профильных форумах = 90%.
Ну это если брать технологии 90х годов, то да. Уже и профильные форумы под завязку набиты; и документация есть, и статьи/примеры и т.п.
А с чем-то более-менее новым... Вот сейчас, к примеру, развивается WPF и Silverlight. Я бы лично не рискнул сразу рисовать ТЗ на Silverlight и бросаться реализовывать финальную версию. Потому что на данном этапе я затрудняюсь не только стоимость, но и вообще реализуемость какого-либо проекта оценить.
Много лет назад была у меня задача: разработать свой Mail-клиент. Под винду. Я, будучи наслышан о MAPI, почитал поподробнее документацию, убедился что таки да — всё ровно для меня, все тонкости взаимодействия с POP3/SMTP уже реализованы, осталось только UI написать. Оценил задачу, начал колбасить.
И только тогда, когда приложение было на 90% готово, оказалось, что в очередной версии микрософт молча убрала программную отправку почты. Т.е. метод есть, возвращает S_OK, но ничего не происходит. Пришлось за выходные полностью переписать всё что касалось отправки и получения почты. Только запуск интерактивного аутлука выполняет собственно отправку.
Вот тебе и 10%.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Много лет назад была у меня задача: разработать свой Mail-клиент. Под винду. Я, будучи наслышан о MAPI, почитал поподробнее документацию, убедился что таки да — всё ровно для меня, все тонкости взаимодействия с POP3/SMTP уже реализованы, осталось только UI написать. Оценил задачу, начал колбасить. S>И только тогда, когда приложение было на 90% готово, оказалось, что в очередной версии микрософт молча убрала программную отправку почты. Т.е. метод есть, возвращает S_OK, но ничего не происходит. Пришлось за выходные полностью переписать всё что касалось отправки и получения почты. Только запуск интерактивного аутлука выполняет собственно отправку. S>Вот тебе и 10%.
POP3/SMTP, вообще-то, примитивные и простые протоколы обмена информацией, основанные служебных "командах" в формате ASCII.
Здравствуйте, iZEN, Вы писали:
ZEN>POP3/SMTP, вообще-то, примитивные и простые протоколы обмена информацией, основанные служебных "командах" в формате ASCII.
И какое отношение это имеет к теме разговора?
А насчет POP3/SMTP я в курсе. Так, в качестве упражнения на дом: сколько RFC необходимо изучить, чтобы принять (или отправить) русскоязычное письмо с аттачментом?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
MSS>Вам повезло, что это вообще заработало даже как демка. Не повезло бы, возникли бы какие баги неприятные — все равно пришлось бы для их исправления изучать DirectShow, в т.ч. специфичный для CE.
Дело в том что "изучать DirectShow специфичный для CE" возможности нет. Нет документации. Вся что есть от МС — по PC-шному DirectShow. Понять что работает а что не работает (и главное — как сделать чтобы работало) в CE-шном можно только методом "втыка и вытыка".
ZEN>>POP3/SMTP, вообще-то, примитивные и простые протоколы обмена информацией, основанные служебных "командах" в формате ASCII. S>И какое отношение это имеет к теме разговора? S>А насчет POP3/SMTP я в курсе. Так, в качестве упражнения на дом: сколько RFC необходимо изучить, чтобы принять (или отправить) русскоязычное письмо с аттачментом?
Ориентировочно 2 десятка (это если не реализовывать самому SSL-enabled протоколы). Но дело даже не в RFC, а в том чтобы сделать парсинг Mime контента письма так же, как это делает Outlook. А там ньюансов — на человекогод (hint — далеко не все письма удовлетворяют RFC, но показывать их всё равно нужно).
Да, кстати — году эдак в 2004-м MS открыла интерфейсы для парсина mime-content <--> MAPI object. Правда, ЕМНИП, только для Outlook 2003 и старше.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Еще раз повторю: написание больших черновиков, чтобы поощущать технологию и посмотреть, что получится — сочли бы бредом все мои бывшие и нынешние работодатели.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>P.S. Я занимался программированием в нескольких командах, каждая из которых сделала по достаточно сложному продукту. Так вот, Я НИ РАЗУ не видел, чтобы при написании кода хотя бы в одной из этих команд — а они сильно разные — использовался бы подход с "черновиком". Это для меня вообще новое слово в программировании
Feasibility study — стандартная вещь. Выбрать одну из нескольких подходящих технологий, проверить практическое быстродействие, оценить поддержку со стороны IDE и т.д. Другое дело, что масштаб умеренный, без дублирования.
)
