Каморка

nemiga писал(а): Чтение не предотвращает. Предодвращает adherence. Если стандат (управления газовым оборудованием) запрещает использовать JMP @RX,то на это есть свои основания. (Газовики хотят автомат с конечным наблюдаемым числом состояний -- таким образом нештатные ситуации исключены в принципе).

Ну, эти случаи совсем частные не думаю, что об этом пишут в блогах, хотя могу и ошибаться

nemiga писал(а):Тестиорование и test driven development -- да, это наше все. снип... то на уровне уже хотя бы автомобильного бортового компьютвра мы не можем предложить ничего лучше, чем экстенсивное тестирование.

Ну, а я–ж про что?

nemiga писал(а):Кстати, поэтому у нас и растет зуб на bleeding edge -- новые технологии еще больше "прячут" алгоритм от пользователя, тестирование "сереет" (приходится переходить от white box testing к grаy, а то и к black box, что нас, честно говоря, сильно огорчает).

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

vinni_puh писал(а):А надо ли? Что дают bleeding edge technologies в софте юзерам?

Зависит, иногда это повышенные удобства, иногда дешевизна сервиса, а инигда это нечто, что старые технологии в принцпе неспособны предложить...

что делают марсианские роверы, и представьте сколько бы они стоили и сколько бы из разрабатывали если бы у них был 100% test coverage.

На ровере не летят ( точнее не едут ) 300 человек и даже не 1...

иногда это повышенные удобства, иногда дешевизна сервиса, а инигда это нечто, что старые технологии в принцпе неспособны предложить..

Я в программировании мало понимаю.... Давай на примере понятном чайникам... Что на фликере было б не так без новых технологий?

vinni_puh писал(а):

что делают марсианские роверы, и представьте сколько бы они стоили и сколько бы из разрабатывали если бы у них был 100% test coverage.

На ровере не летят ( точнее не едут ) 300 человек и даже не 1...

иногда это повышенные удобства, иногда дешевизна сервиса, а инигда это нечто, что старые технологии в принцпе неспособны предложить..

Я в программировании мало понимаю.... Давай на примере понятном чайникам... Что на фликере было б не так без новых технологий?

Навскидку, то что видно юзверям: in-place editing, это мы его придумали , real-time massive text/geo indexing, помоему, ни у кого такого до сих пор нету, ну еще мелочевка всякая на любителя, типа tag clustering.
А на заднем конце (backend ) у нас тоже всего нетривиального навалом, только объяснять долго...

Marmot писал(а):Посмотрите например на то, что делают марсианские роверы, и представьте сколько бы они стоили и сколько бы из разрабатывали если бы у них был 100% test coverage.

ОС для марсианского ровера делала наша фирма -- WindRiver. Test coverage у нас 100%. Отвечаю.

Alex Martychenko, PhD
Ld. Test Engineer
WindRiver
613-270-2296

.

nemiga писал(а):

Marmot писал(а):Посмотрите например на то, что делают марсианские роверы, и представьте сколько бы они стоили и сколько бы из разрабатывали если бы у них был 100% test coverage.

ОС для марсианского ровера делала наша фирма -- WindRiver. Test coverage у нас 100%. Отвечаю.

Alex Martychenko, PhD
Ld. Test Engineer
WindRiver
613-270-2296

.

Дык, а все то, что там ранится, типа алгоритмов выбора оптимального пути в песчанных дюнах ?
Хрен ты это ты это оттестируешь 100%...

nemiga писал(а): Вам не будет приятно (хотя, кто знает) узнать, что самолет с вашей женой разбился только потому, что несколько новых модулей управления закрылками были написаны с отступлением от industry стандартов. Да и в обычной жизни -- вас будет радражать, если ваша машина станет заводится только после того как вы включите/выключите радио, а стиральная машина начинает стирать лишь после того, как вы три раза хлопните дверкой, потому что софт управляющих компьютеров для них писали читатели блогов

Кстати о машинах, по каким стандартам будет тестироваться, например, программа автоматической параллельной парковки?
Или программа автоматического обгона грузовика на хайвее?

Marmot писал(а):in-place editing, это мы его придумали

Другие люди тоже это придумывали
Вот, просто поиском нашлось из задокументированных примеров:

From the June 2001 issue of MSDN Magazine. Cutting Edge: DataGrid In-place Editing "Last month (May 2001) I dug into the fundamentals of bilding ASP.NET interactive DataGrids using the <asp:DataGrid> server control."

DHTML In-Place Editing in a Wiki ..... in 1999 "double click the page title, author, or text to shift into edit mode, then click SAVE to save the value"

In-Place Editing of Web Pages: Sparrow Community-Shared Documents, also published: Proceedings of the seventh international conference on World Wide Web 7, Brisbane, Australia, Pages: 489 - 498, Year of Publication: 1998

Marmot писал(а):Дык, а все то, что там ранится, типа алгоритмов выбора оптимального пути в песчанных дюнах ?
Хрен ты это ты это оттестируешь 100%...

Еще раз. Мы делаем OS (VxWorks). Которая rock solid, не виснет, не blue screen, вообще ничего.

За ОС мы (я, в том числе) подписываемся и отвечаем.

За аппликухи -- вопрос к тем, кто и как их писал. Наше дело -- дать качественный API (что мы и делаем, он 100% тестирован во всех режимах, в том числе мною лично).

.

Весенняя писал(а):

Marmot писал(а):in-place editing, это мы его придумали

Другие люди тоже это придумывали
Вот, просто поиском нашлось из задокументированных примеров:

From the June 2001 issue of MSDN Magazine. Cutting Edge: DataGrid In-place Editing "Last month (May 2001) I dug into the fundamentals of bilding ASP.NET interactive DataGrids using the <asp:DataGrid> server control."

DHTML In-Place Editing in a Wiki ..... in 1999 "double click the page title, author, or text to shift into edit mode, then click SAVE to save the value"

In-Place Editing of Web Pages: Sparrow Community-Shared Documents, also published: Proceedings of the seventh international conference on World Wide Web 7, Brisbane, Australia, Pages: 489 - 498, Year of Publication: 1998

Ок, когда мы это делали мы всего этого не видели
Ну значит не мы придумали, кто-то еще, смысла это не меняет, в 2005 году это не было широко распространенной практикой, т.е. на тот момент это была сама что ни на есть bleeding edge technology.
A кто был первым напонимает вопрос о том, кто открыл Америку , Колумб или Эрик Рыжий

nemiga писал(а):

Marmot писал(а):Дык, а все то, что там ранится, типа алгоритмов выбора оптимального пути в песчанных дюнах ?
Хрен ты это ты это оттестируешь 100%...

Еще раз. Мы делаем OS (VxWorks). Которая rock solid, не виснет, не blue screen, вообще ничего.

За ОС мы (я, в том числе) подписываемся и отвечаем.

За аппликухи -- вопрос к тем, кто и как их писал. Наше дело -- дать качественный API (что мы и делаем, он 100% тестирован во всех режимах, в том числе мною лично).

Ага, как раз OS оттестировать еще можно, там все специфицировано на уровне API и всяких там гарантий. Тоже самое касается, BTW, JVM, все четко прописано. Так что создание rock solid JVM это вопрос ближайшего времени. Только вот кому эти OS и JVM нужны без аппликух?
А с ростом сложности аппликух, существующие стандартные методики тестированию можно будет отправить на свалку. Примеры я уже привел выше...

Marmot писал(а):Кстати о машинах, по каким стандартам будет тестироваться, например, программа автоматической параллельной парковки?
Или программа автоматического обгона грузовика на хайвее?

Я понимаю, что можно сначала кодировать, а потом подгонять стандарты под что получилось. Я знаю, что так часто делается. Но мне такой подход не нравится.

Я -- из другой эпохи, когда устройство должно было работать не в принципе, а в корпусе.

Хотя, в общем-то все понимают, что сегодняшние методы тестирования не поспевают за развитием технологий. IMHO, новые решения следует искать не со стороны тестирования, а со стороны программирования, даже алгоритма. Постулат примерно такой: если программировать без ошибок, то и тестирование не понадобится.

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

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

Т.е., тенденция развития будет в сторону стандартизации и off-the shelf solutions.

.

nemiga писал(а): Я понимаю, что можно сначала кодировать, а потом подгонять стандарты под что получилось. Я знаю, что так часто делается. Но мне такой подход не нравится.

А никуда от этого не деться, есть тьма примеров мертворожденных стадартов, когда технология идет совсем другим путем.

nemiga писал(а):Хотя, в общем-то все понимают, что сегодняшние методы тестирования не поспевают за развитием технологий. IMHO, новые решения следует искать не со стороны тестирования, а со стороны программирования, даже алгоритма. Постулат примерно такой: если программировать без ошибок, то и тестирование не понадобится.

Гы! Сейчас все больше разрабатывется алгоритмов с нечеткой логикой, когда в практически одной и той же ситуации может быть правильным принятие нескольких различных решений. Более того, механизм принятия решения во многих случаях невозможно повторить используя "человеческую" логику.
И выявить ошибку в таком алгоритме намного труднее.


ИМХО, конечным этапом развия IT будет создание полноценного AI
А пока мы только пытаемся воспроизвести отдельные компненнты естественного интеллекта с присущей ему нечеткой логикой.
Я, например, работаю над алгоритмами нечеткой кластеризации пытаясь категоризировать паттерны поведения наших пользователей
Такой алгоритм должен быть мечтой все спецслужб
И, кстати, я уверен что, алгоритмы парковки и обгона будут того же типа, нечеткое принятие решения на основе анализа паттерна ситуации.

Marmot писал(а): ИМХО, конечным этапом развия IT будет создание полноценного AI

Я извиняюсь, не удержалась

Marmot писал(а):ИМХО, конечным этапом развия IT будет создание полноценного AI

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


.