Здравствуйте, Дарней, Вы писали:
Д>Но что самое смешное — у них даже название почти в точности такое же! я даже не знаю, рыдать или смеяться Д>Написать им что ли, поинтересоваться, как дела идут?
Поинтересуйся.
Но свою разработку вряд ли стоит забрасывать. Рынок, он же большой. Так что, желаю удачи!
Здравствуйте, Igor Sukhov, Вы писали:
IS>Здравствуйте, c-smile, Вы писали:
CS>>а не написать ли нам это на Compact Framework...
IS>судя по коментариям, подобное поведение и требовалось получить.
Не понял до конца замечания ну да ладно...
Мы разговаривали с MS. (Они знают наше приложение)
Это была их рекомендация. Мы просто её проверили.
А комментарии... как тебе сказать... мы же профи
в конце концов. Да, мы это знали заранее.
Поэтому-то инициатива исходила не от нас.
Здравствуйте, c-smile, Вы писали:
IS>>Здравствуйте, c-smile, Вы писали: CS>>>а не написать ли нам это на Compact Framework... IS>>судя по коментариям, подобное поведение и требовалось получить.
CS>Не понял до конца замечания ну да ладно... CS>Мы разговаривали с MS. (Они знают наше приложение) CS>Это была их рекомендация. Мы просто её проверили.
а вы от них ждали что они вам порекомендуют решение
"от конкурентов". Нет (1).
CS>А комментарии... как тебе сказать... мы же профи CS>в конце концов. Да, мы это знали заранее. CS>Поэтому-то инициатива исходила не от нас.
Именно про это я и писал. Когда изначально (2) ставиться
задача показать что на солнце лететь ночью
нельзя, это обычно легко доказывается.
(1) + (2) приводят к предубеждению в самом начале тестирования.
Начиная с предубеждения, получить непредвзятый результат невозможно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Прекрасно, а в чем заключаются те приоритеты, которые я "навязываю" (кстати, почему именно навязываю — я им начальство, что ли ?).
Студентам? По идее препод для студентов должен быть даже больше чем начальством.
PD>Или мои приоритеты в чем-то другом заключаются ? Тогда в чем ?
Не важно в чём они заключаются, важно то, что ты их пытаешься навязывать другим.
. Казалось бы, причём тут вообще наука? Но ветка, благодаря тебе, съехала куда-то в сторону и человек, в принципе, давший вполне адекватное определение данной конкретной ситуации должен почему-то перед тобой оправдываться
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Igor Sukhov, Вы писали:
IS>Здравствуйте, c-smile, Вы писали:
IS>>>Здравствуйте, c-smile, Вы писали: CS>>>>а не написать ли нам это на Compact Framework... IS>>>судя по коментариям, подобное поведение и требовалось получить.
CS>>Не понял до конца замечания ну да ладно... CS>>Мы разговаривали с MS. (Они знают наше приложение) CS>>Это была их рекомендация. Мы просто её проверили. IS>а вы от них ждали что они вам порекомендуют решение IS>"от конкурентов". Нет (1).
Сравнивали мы с MS VC++ + SQLite.
Если это конкуренты то тогда да.
CS>>А комментарии... как тебе сказать... мы же профи CS>>в конце концов. Да, мы это знали заранее. CS>>Поэтому-то инициатива исходила не от нас. IS>Именно про это я и писал. Когда изначально (2) ставиться IS>задача показать что на солнце лететь ночью IS>нельзя, это обычно легко доказывается.
Напрасно ты сомневаешься в нашей объективности.
Не было желания быть необъективным.
Наши комментарии отражают степень нашего собственного
обалдения от результатов.
Принимая во внимание что SQLite на той же структуре базы
работает на порядки быстрее и тот факт
что на мобильной платформе программирование UI что на C++ что на
.NET одинакового порядка сложности товарищи ясное дело выбрали Пепси.
IS>(1) + (2) приводят к предубеждению в самом начале тестирования. IS>Начиная с предубеждения, получить непредвзятый результат невозможно.
Я не понял а при чем здесь предвзятось или нет.
.NET что девочка какая, а мы пацаны в поре созревания?
Изначальное и естественное желание минимизировать собственную
головную боль. Если CF дает бенефиты и позволяет хоть как-то
сократить стоимость разработки то за милую душу, почему нет?
Но воевать с таким SQL server'ом на батарейках... это дороже встанет.
Если уже и заходить на managed code то уж явно лучше использовать SuperWaba.
Она (VM/runtime) работает на Win, Palm и Symbian.
Назови хотя бы одну причину ради которой им нужен CF.
Только без этой эзотерики про потусторонние мотивы.
Здравствуйте, Дарней, Вы писали:
Д>что сложнее — выдолбить из мрамора статую высотой в два метра, или построить небоскреб высотой в энное количество сотен метров?
Да кажется мне, что и то и другое крайне не просто. И сделать это (статую или небоскреб) сможет очень и очень ограниченное количество людей, которые довели свои способности и профессиональные навыки до совершенства.
Существенная разница в том, что для изготовления статуи необходимо иметь уникальное сочетание различных знаний и умений в одном человеке, в скульпторе. В "Законах Паркинсона" это сочетание качеств называется мастерством.
При постройке небоскреба (или создании сложного объемного программного продукта) ситуация меняется. На первое место, имхо, выходит не умение делать что-то, а уменее организовать изготовление чего-либо чужими руками, умение управлять и организовывать. В тех же "Законах Паркинсона" это называется искусностью. Главный архитектор (или начальник строительства) не обязан быть хорошим архитектором, уметь расчитывать ветровую нагрузку на здание, точно знать структуру грунта и тонкости закладки фундамента. Он может иметь весьма поверхностные знания в каждой из этих областей. Но он должен прекрасно представлять себе картину происходящего в целом и должен уметь поставить на ключевые места строительство настоящих мастеров, которые прекрасно справляются со своим узким фронтом работы.
Ключевой момент в том, что даже у самого искусного руководителя возникает потребность в самых мастеровитых исполнителях. Например, когда-то я видел фрагменты документальных съемок монтирования верхушки какой-то телебашни (кажется в Канаде). Дело происходило на такой высоте, что очередную часть конструкции приходилось доставлять туда на вертолете, а принимали и укрепляли ее два строителя, пристегнутые к башне альпинистским снаряжением. Думаю, что исполнить такую работу могли только профессионалы высочайшего класса (как строители, так и пилот вертолета). Хотя для всего строительства это был всего лишь частный эпизод, один из многих моментов.
Так вот, мне кажется, что есть люди, которым нравятся (или им так кажется) масштабные задачи, вроде постройки такой башни. И они прекрасно понимают, что найдутся те, кто на сумасшедшей высоте будут монтировать верхушку. Поэтому об этом не нужно много думать, это всего лишь одна из множества задач.
А есть и те, кто знает, что все равно будут большие стройки, где все равно потребуется делать что-то частное, но очень сложное. Вроде монтирования опускаемой с вертолета очередной части башни. И никто кроме них не сможет сделать этой работы. А поэтому нужно совершенствовать и оттачивать свое мастерство, чтобы справиться с подобными задачами.
Так вот хочу заявить, что лично мне гораздо интереснее решать мелкие, но сложные задачи. Где требуется проявление личного мастерства. А вот большие и сложные, для которых нужна искусность, меня совершенно не привлекают. По разным причинам. Но, главное, ну не нравится мне делать большие разработки. Ну хоть убей! А вот маленькие, но трудоемкие и уникальные -- за милую душу, за гроши,... Да за харчи, в конце-концов! Потому, что интересно до безобразия.
Как-то так получается, что чем больше программируешь, чем больше опыта приобретаешь, тем больше приходится заниматься именно управлением, распределением работ и пр. Т.е., менять мастерство на искусность... А не хочется.
PS
Я никому не возражал. Это скорее из разряда "крик души"
Просто последние два дня курю над очередной темой, слишком большой объем в ней намечается, а сложности/уникальности особой не видно. Вот поорать и захотелось.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
отлично сказал
E>Так вот хочу заявить, что лично мне гораздо интереснее решать мелкие, но сложные задачи. Где требуется проявление личного мастерства. А вот большие и сложные, для которых нужна искусность, меня совершенно не привлекают. По разным причинам. Но, главное, ну не нравится мне делать большие разработки. Ну хоть убей! А вот маленькие, но трудоемкие и уникальные -- за милую душу, за гроши,... Да за харчи, в конце-концов! Потому, что интересно до безобразия.
Спасибо.
E>>Так вот хочу заявить, что лично мне гораздо интереснее решать мелкие, но сложные задачи. Где требуется проявление личного мастерства. А вот большие и сложные, для которых нужна искусность, меня совершенно не привлекают. По разным причинам. Но, главное, ну не нравится мне делать большие разработки. Ну хоть убей! А вот маленькие, но трудоемкие и уникальные -- за милую душу, за гроши,... Да за харчи, в конце-концов! Потому, что интересно до безобразия.
Д>А это уж — дело вкуса
Именно. Вот лично у меня такой.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, vdimas, Вы писали:
V>>С этим как раз никто не спорит. Я считаю, что не может быть человек специалистом и при этом не разбираться досконально в сути того, чем оперирует. Т.е. мне явно кажется надуманной точка зрения, что бывают "высокоуровневые" спецы, которые слабо разбираются в подробностях современной выч. техники, осей и т.д.
Д>Смотря до каких подробностей Д>В любом случае, это необходимо, но отнюдь не достаточно.
Ну... флейм так флейм, ok. Назови, плиз, "достаточный" аспект для определения "грамотности" специалиста. Мне кажется, что аспектов слишком много, и большинство из них необходимы, но, разумеется, каждый в отдельности не достаточен.
Упомянутые тобой в предыдущем посте "перекосы" и "трещины" тоже не случаются сами по себе. В современных многоуровневых приложениях слишком много аспектов. Помимо грамотной модели предметной области, которую строит разработчик ПО, ему приходится приличную часть времени тратить на разработку довольно-таки низкоуровневых, с т.з. целевой задачи, протоколов взаимодействия частей своей системы.
Например, общение клиентских машин с серверной частью никак не диктуется предметной областью, оно диктуется выбранной архитектурой системы, которая, в свою очередь, была продиктовано требуемыми техническими характеристиками и удовлетворена путем топологического расположения имеющихся в распоряжении технических ср-в. Требования транзакционности, параллельного доступа к информации (и с разными намерениями в т.ч., чтения/записи/удаления и т.д., обыгрывание различных ситуаций для выжимания максимума эффективности), все это требует "разруливания", зачастую еще на уровне разработки самой общей архитектуры, ибо именно возможности общей архитектуры продиктуют возможности самой системы. Строятся наиболее общие, похожие сценарии работы с сущностями, и от этих сценариев и пляшут.
Т.е., картинка современного проектирования получается немного смешной:
— оцениваем общие технические характеристики, и требования, выбираем общий вид архитектуры (N-tier и т.д.)
— выделяем наиболее общие сценарии работы с сущностями на этапе предварительного анализа, разбиваем их на классы (справочные данные, оперативные данные, регистры и т.д., по возможности, выделяем как можно больше общих моментов — он это уже детали имплементации)
— строим некую среду поддержки прикладных сущностей, которые , как предполагается, будут принадлежать некоторому классу, т.е. поддерживаться неким набором функциональности (которая, например, может представлять из себя комбинацию политик на различные аспекты). Такие вещи, как DAL, презентационный уровень, обмен м/у уровнями — как раз являются основой этой среды поддержки, и, по-сути, являются лишь техническими подробностями ее реализации. Тут уместно замечание, что до сих пор (!!!) многие путают DAL, например, и другие подробности с целевой прикладной функциональностью, т.е. разрабатывают эти моменты одновременно (одновременно с самой прикладной сущностью разрабатываются элементарные операции по ее персистентности), что мне представляется нелогичным (пусть по другому иногда никак, это не показатель). Подходы многих либ ORM (а у нас своя разработка этого плана ), в сочетании со встроенными ср-вами обеспечения транзакционности, параллельности доступа к персистентным хранилищам и т.д. позволяют как-то абстрагироваться от этих технических деталей.
— и вот, наконец, при детальной разработке модели прикладной области, те самые целевые прикладные сущности мы "впихиваем" в рамки имеющейся среды поддержки прикладной области. Т.е. никакая прикладная функциональность просто так не реализуется (хотя, должна была бы, по идее, не так ли?), любые прикладные требования пропускаются через призму получившихся технических возможностей, и весьма сильно дополнительно ограничиваются (т.е. роль предварительного анализа весьма велика, или же надо производить бесконечное число итераций на этапе проектирования). "Все что угодно" просто так не реализуешь. Если очередное некое требование совершенно не влазит в общую модель, то надо или подумать о расширении модели, или же ... о самой необходимости подобного требования (хе-хе, второе — весьма распространенный случай, если реализовать некую финтифлюшку сложновато, читай — дороговато, от нее просто-напросто отказываются. Кто? — сами заказчики).
Одним словом получается, что на разработку технических подробностей архитектуры обычно тратится куда как больше времени, сил и таланта конкретного архитектора, чем на модель прикладных целевых сущностей, которые вообще зачастую отдаются разработчикам более низкого ранга в иерархии (смешно, но факт). И вся эта т.н. "высокоуровневая архитектура" — суть выбранный способ оперирования низкоуровневыми вещами (а не реализация прикладной модели). Т.е. она, хочешь или не хочешь, но весьма плотно завязана на такие низкоуровневые вещи, как:
— возможности современных "доступных" компьютеров (может быть принято решение о кластеризации)
— характера поведения сети, ее технические характеристики, особенности сетевых протоколов
— возможности различных программных платформ, начиная от ОС, далее серверов WEB и БД, и заканчивая высокоуровневыми либами-средами, как для С++, так и еще более высокоуровневыми, типа Java или .Net (причем архитектор обычно очень хорошо разбирается именно в подробностях, и зачастую лучше кодера... ему же решения принимать надо! т.е. надо владеть максимумом информации)
Здравствуйте, Cyberax, Вы писали:
>> C>Уже нет Начиная с первого GeForce на чипах появился GPU — это такой >> C>быстрый векторный CPU, заточеный специально под графику. Он умеет >> C>перемножать матрицы, рассчитывать тени и т.п. >> В аппаратное перемножение матриц фиксированного объема — поверю >> (скажем, 4х4), в обсчет теней — нет.
C>А чего же так? Stencil buffer в аппаратуре не так уж сложно реализовать.
Не знаю, я бы оставил этот момент на микропрограммы. Ибо для обсчтеа теней могут применяться различные по сложности алгоритмы, где-то требуется достоверность и точность, где-то можно просто задать коэв. рассеивания и т.д.
Здравствуйте, Дарней, Вы писали:
Д>просто полный звиздец! Д>сегодня вечером опять копал интернет в поисках материалов на аналогичную тему, и нашел исследовательский проект, которым уже два года занимается Bell Labs (правда, результатов пока не видно). Детали конечно различаются, но основные идеи — просто один в один! (правда, у меня есть кое-какие идеи, до которых они не додумались ) Д>Но что самое смешное — у них даже название почти в точности такое же! я даже не знаю, рыдать или смеяться Д>Написать им что ли, поинтересоваться, как дела идут?
А можно ссылку на подробности? И что именно пытаешься сделать ты?
я не выкладывал на свой сайт детальной информации о проекте, поэтому смотреть там не на что.
да и выкладывать сейчас нечего — куча бессистемных заметок, да непригодный пока к применению генератор парсеров
надо будет собраться да написать подробное описание планов на данный момент, когда руки дойдут
Д>вот ты здесь много писал об архитектуре, DAL, N-Tier и т.п. Как ты думаешь, это относится именно к деталям низкого уровня?
Когда ты рисуешь эти части в виде "квадратиков" общей схемы — нет. Когда начинаешь разрабатывать внутренности этих самых квадратиков на конкретных платформах, то — да. Самый что ни на есть низкий уровень, требующий глубокого понимания выбранной платформы. Если же удается подобрать готовое удовлетворяющее решение (т.е. не проектировать механику этих частей самому), то опять — нет. Если эту механику все-таки придется дорабатывать — опять да. Последний случай — наиболее распространенный.
Здравствуйте, vdimas, Вы писали:
V>Когда ты рисуешь эти части в виде "квадратиков" общей схемы — нет. Когда начинаешь разрабатывать внутренности этих самых квадратиков на конкретных платформах, то — да. Самый что ни на есть низкий уровень, требующий глубокого понимания выбранной платформы. Если же удается подобрать готовое удовлетворяющее решение (т.е. не проектировать механику этих частей самому), то опять — нет. Если эту механику все-таки придется дорабатывать — опять да. Последний случай — наиболее распространенный.
я например всегда считал, что низкий уровень — это та часть, что лежит ниже уровня API операционной системы
внутренности же сервера приложений — это вполне даже высокий уровень, даже если ты залезешь в этот сервер по самый локоть
в общем, пора завязывать с "низким" и "высоким" уровнем. Очень уж эти понятия зависят от выбора точки отсчета
Здравствуйте, GlebZ, Вы писали:
GZ>Так уж это важно? Ну не клеются регуляры в классический конечный автомат с третьим подклассом грамматики Хомского. Значит это не подходит под термин теории. Зато то что на практике регуляры умеют больше. И в практике существует точно такой-же термин "регулярное выражение", который может обрабатывать скобки. Это ведь не важно. Важно что он интересуется, расширяет свой кругозор, а это более важно.
Ты не так понял. Меня ничуть не смутило, и не удивило, что он как-то по другому считал ДО этого. Меня проразил факт упорства и само трудное восприятие тех вещей, которые он должен был воспринимать как повторение пройденного (я прекрасно знаю кафедру, с которой описываемый чел вышел). Я упомянул про лоботомию именно в этом смысле — невозможность переосмыслить собственные знания. На собеседовании молодых преттендентов практически бесполезно проверять накопленный багаж, интересней посмотреть на способность рассуждать, обобщать, отделять значимое от второстепенного (пусть даже он где-то будет совсем не прав,интересна сама способность к рассуждениям и принятиям решений).
Для меня лично тот факт, что вчерашний студент изучил эти перловые регулярные выражения — ни плюс и не минус, а абсолютно ничего... Не показатель в общем, ибо это знания прикладного характера. И у него еще нет их некоей критической массы, чтобы можно было хоть как-то пытаться их проверять.
Почему именно так? Вот пример на те же регулярные выражения (надуманный... только что)
Пусть у нас есть задача создать некий динамический лексер. Т.е. в некоем виде в "одно место" поступают правила для текущего разбора (пусть в удобно закодированной форме), а в "другое место" — входные цепочки для того самого разбора. Предположим, я предложу решить подобную задачу преттенденту и попрошу обосновать решение. Независимо от того, как он решит задачу, без обоснования решения и сравнения различных путей решения, его собственное будет стоить 0 целых 0 десятых.
В данном случае очевидны 2 решения (на основе имеющихся технологий):
— динамически строить "перловые" регулярные выражения
— динамически строить конечный автомат самому (или с помощью некоей известной либы)
В зависимости от различных входных условий может оказаться следующее:
— построить автомат самому сложнее/не сложнее/легче, чем построить регулярные выражения
— требования к эффективности высокие/не высокие/отсутствуют
— набор входных правил меняется "очень часто"/"не часто"/"редко".
И какой смысл будет рассматривать его конкретное решение,если человек недостаточно хорошо представляет, сколько он за свое (неважно какое) решение платит и где именно.
Я и сам закончил не многим более 10 лет назад и еще прекрасно помню уровень многих своих друзей-одногрупнников на момент выпуска. Пытаюсь найти сейчас примерно такого же уровня — пусто... Блин, краткий обзор современного "продвинутого" выпускника: немного джавы, HTML, немного С++, какие-то обрывочные знания MFC/ATL/COM/Дельфи и... глубочайшие провалы в основах (на фиг тогда сдались те обрывки знаний?). Такое ощущение, что безграничная доступность машинного времени (копм у всех) банально отвлекает студентов от учебы. Написание программ мартышкиным способом (методом тупого тыка и перебора подходящих вариантов) — не лучшее времяпрепровождение. ИМХО, наоборот — весьма отупляющее занятие.
-----------------
Если тебе интересно для сравнения. Любое зачитывание "в лоб" закодированных правил лексического разбора — это суть построение NFA. Собственно, сама задача построения лексера — это привести NFA к DFA (причем для реального использования даже не обязательно потом минимизировать, ибо это никак не отражается на эффективности). Скажу только, что сразу после института я бы закодировал подобную задачку весьма быстро, а так потратил примерно пол-часа. Вот код процедуры перевода:
void DoConvert() {
_dfa = new DFA();
NFA.State nfaState;
Enqueue(_nfa.startState);
while (_convertQueue.Count!=0) {
nfaState = Dequeue();
if (nfaState._convertedState == null) {
nfaState._convertedState = new ConvertedState();
nfaState._convertedState.Combine(nfaState);
}
ConvertedState convertedState = nfaState._convertedState;
foreach (NFA.Transition nfaTransition in nfaState.transitions.Values) {
ConvertedState nextState = null;
// find marked stateforeach (NFA.State nfaTransitionState in nfaTransition.nextStates) {
if (nfaTransitionState._convertedState != null) {
nextState = nfaTransitionState._convertedState;
break;
}
}
if (nextState == null)
nextState = new ConvertedState();
foreach (NFA.State nfaTransitionState in nfaTransition.nextStates) {
if(nfaTransitionState._convertedState == null) {
nextState.Combine(nfaTransitionState);
Enqueue(nfaTransitionState);
} else if(nfaTransitionState._convertedState !=nextState)
// TODO: try to merge converted states if output is equalthrow new ApplicationException("Conflict of output during NFA->DFA conversion:" +
"\nConverted Output: " + nfaTransitionState._convertedState.tag.ToString() +
"\nSupposed Output: " + nextState.tag.ToString());
}
convertedState.transitions.Add(nfaTransition.input, nextState);
}
}
startState = _nfa.startState._convertedState;
CopyToDFAStates(_dfa, _dfa.startState, startState);
}
Есть еще алгоритмы построения сразу DFA из входного описания, тогда общий код будет еще короче и не нужен промежуточный NFA. Правда, эти алгоритмы не подходят для построения лексера из описания языком расширенных регулярных выражений (не перловых).
Не думаю, что построитель перловых регулярных выражений был бы проще, скорее — ровно наоборот. (Опять же, от преттендентов не требуется готовый код, требуется умение рассуждать, сравнивать, пытаться обнаруживать значимое)
Здравствуйте, Дарней, Вы писали:
Д>я не выкладывал на свой сайт детальной информации о проекте, поэтому смотреть там не на что. Д>да и выкладывать сейчас нечего — куча бессистемных заметок, да непригодный пока к применению генератор парсеров Д>надо будет собраться да написать подробное описание планов на данный момент, когда руки дойдут
если на дотнете — пиши в приват, с лексерами помогу
в общем, есть потребность в разработке своих DSL, но нужен инструмент, которым легко ворочать
* thriving in a production environment *
Но ветка, благодаря тебе, съехала куда-то в сторону и человек, в принципе, давший вполне адекватное определение данной конкретной ситуации должен почему-то перед тобой оправдываться 
Если нам не помогут, то мы тоже никого не пощадим.
(правда, результатов пока не видно). Детали конечно различаются, но основные идеи — просто один в один! (правда, у меня есть кое-какие идеи, до которых они не додумались 
