Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

» прикладное программирование и не только оно...

Автор: delover
Дата сообщения: 05.08.2011 18:42
akaGM

Цитата:
и каких компараторов?

А сейчас увидел компараторы, круто, я бы добавил ещё один который купил толи 30 евро толи долларов не помню. Мне надо однако сначала попробовать те что в списке.


Цитата:
в colorer настраиваются _все_ цвета...

Ну хотябы попробую красный цвет поменять, однако осальная подсветка всё равно страдает. Как правило красный начинается с "нетривиального" джавакода.


Цитата:
дефолтом стоит размер файла в 5000 строк

я бы для xml весом в 170Мб вообще бы не раскрашивал, так лучше было бы. В общем в фаре я подотстал.

ComradG
100% соглашусь. Самый лучший плагин IMHO который я видел для фара написал я сам. ))) Охотно делюсь (с) -
F2 | Проводник | explorer /e, "!\\", /select, "!.!"
Нажимая F2 F2 из фара можно сразу же делать драгдроп файла или папки, да короче всё что угодно.
Автор: akaGM
Дата сообщения: 06.08.2011 02:50
Qraizer
я не ошибаюсь, "верификаторы кода" -- твоя вотчина?
тогда глянь, плиз, в "инструментарий"...
Автор: ComradG
Дата сообщения: 06.08.2011 15:03
akaGM
относительно верификаторов. раньше FxCop распространялся отдельно, теперь его M$ ныкает в громоздкие никому не нужные пакеты. вопрос: может кто зальет на файлообменник какой и поместит на него ссылку в шапке?

delover

Цитата:
100% соглашусь.
правда с третьей версией Фара как-то не все гладко, и написанные ранее плагины пашут (да и то не все) через врапер.
Автор: akaGM
Дата сообщения: 06.08.2011 15:43
ComradG
а чё ты ко мне-то? я вообще не знаю что это такое...
Автор: Qraizer
Дата сообщения: 07.08.2011 00:50
ComradG, это не твоё мнение. Твоё мнение было бы аргументированным. Это было даже не мнение, так, соседка нашеплата. Ладно, слив в пользу Colorer-а.
Кстати, те плагины, что искаропки, мне большей частью не нравятся. Заменял на альтернативные. Колорер не исключение.
akaGM, да, моя. Я видел ту тему. У нас свои специализированные инструменты. А не специализированные - кому как, в частности и из того списка. У меня же уже озвученный FAR & K°.

Цитата:
Охотно делюсь
Плагин "Контекстное меню проводника" у меня забинден на App.
К компараторам добавлю Beyond Compare. Предоставлен нам заказчиком. ИМХО очень удобен, особенно регеспами для своих правил сравнения. Но примерно половина из нас предпочитает Araxis Merge. Говорят, не хуже. Не знаю, не пробовал.
Автор: delover
Дата сообщения: 07.08.2011 00:55
Qraizer

Цитата:
К компараторам добавлю Beyond Compare

Про него я и писал, купил себе - недорогой ещё версию 2. Потом писал автору - сколька доплатить надо, чтобы 3 был?, он ответил - нисколька и выслал лицензию. ) Было очень приятно получить хороший тулз.
Автор: akaGM
Дата сообщения: 07.08.2011 01:16
Qraizer
ну так а что это такое?
проверка чего? проверка на что? проверка зачем?
типа проверка доказательства правильности/непротиворечивости программы, того что она решает поставленную задачу?
и что, это всё так строго формализовано уже, что даже тулзы имеются?

Цитата:
У меня же уже озвученный FAR & K°.

слушай, тогда очень больной вопрос...
я совсем недавно пересел на 1920х1080 разрешение, и все мои любимые и самолично рисованые фонты (8х16 и 9х16) оказались ни к чёрту. фонтовых ресурсов прошерстил уйму (вот самый большой специальный, это не развал, кликай спокойно)
-- бесполезно, самому сейчас уже рисовать лень...
может подскажешь что, на чём сам сидишь/глядишь?
сюда
http://forum.ru-board.com/topic.cgi?forum=4&topic=3391#1
можно не посылать, там до сих пор пара постов без ответа
?
Автор: ComradG
Дата сообщения: 07.08.2011 01:19
Qraizer

Цитата:
Твоё мнение было бы аргументированным.
оно итак более, чем аргументировано, а для толстолобиков повторю, что доказывать можно все, что угодно.

Цитата:
это не твоё мнение.
это тебе соседка нашептала? ты за себя отвечай. ну нравится тебе колорер, ну и пирожок тебе в руки, а свою религию навязывай в своей епархии и не высаживай других.

akaGM

Цитата:
а чё ты ко мне-то? я вообще не знаю что это такое...
ты ж про верификаторы говорил... вот. это своего рода верификатор кола для NET-кодеров.
Автор: akaGM
Дата сообщения: 07.08.2011 01:31
ComradG

Цитата:
ты ж про верификаторы говорил... вот. это своего рода верификатор кола для NET-кодеров.
могу только повторить:
Цитата:
а чё ты ко мне-то? я вообще не знаю что это такое...
зачем подо мной-то подвесил? и не говорил, а спрашивал...
Автор: data man
Дата сообщения: 07.08.2011 06:41
akaGM

Цитата:
может подскажешь что, на чём сам сидишь/глядишь?

На оф. форуме FAR есть тема
На последних страницах есть несколько достойных внимания шрифтов.
Автор: akaGM
Дата сообщения: 07.08.2011 13:05
data man
ок, смотрю...
Автор: delover
Дата сообщения: 10.08.2011 09:31
В нашем городе обнаружена новая категория Трамвайных Билетов!!! 619352. Используя математическую операцию - циклический сдвиг такой билет становится счастливым 193526. Так как у счастливых билетов съехал центр, категория билетов названа "Весёлые".
Автор: akaGM
Дата сообщения: 10.08.2011 10:59
delover
не, лучше
- "циклические"
- "регулярные"
во!
- "месячные"
Автор: Qraizer
Дата сообщения: 11.08.2011 04:55
akaGM

Цитата:
ну так а что это такое?
проверка чего? проверка на что? проверка зачем?
Ну, проверок много. Начиная с ревью кода, которое мы не делаем, и его отладки, которую тоже не делаем. Мы делаем верификацию кода. Упрощённо говоря, это тестирование. Но это довольно грубая аналогия. После нас ещё выполняется валидация и собственно сертификация.

Цитата:
типа проверка доказательства правильности/непротиворечивости программы, того что она решает поставленную задачу?
Есть требования на код, определяющее его поведение. Не вдаваясь в детали - описание алгоритмической части. Но опять же это черезчур приближённо. Наша задача - проверить, что поведение кода точно соответствует поведению, следуемому из требований на него.

Цитата:
и что, это всё так строго формализовано уже, что даже тулзы имеются?
Формализовано тестирование. Примерно так же, как формализована игра в шахматы Шахматным Кодексом. Однако на одних только правилах игры нормально не поиграешь. Да, есть определённые правила, как тестировать. Этому учат. Впрочем, учебников по тестированию и в гугле хватает. Но тест тесту большая рознь, примерно так же различны разные шахматные этюды и задачи.
Формализована процедура верификации. Стандартами предприятия, основанными на отраслевых стандартах. Тестирование - часть процедуры верификации, а та - часть процедуры сертификации.
Тулзы в этих действиях помогают. Есть инструментаторы и сборщики покрытия кода. Есть наборы макросов для MSOffice-ных и Acrobatных приложений для облегчения соблюдения формальностей на различных стадиях процедур верификации и сертификации. Есть SVN с хранением состояний пакетов, чандж-доков, лоадов, бэйз-лайнов, связей между всем этим и родом этих связей. Есть трак для ведения журналов несоответствий и решений по ним. Есть спец. инструментарий, предоставляемый конкретными заказчиками для конкретных проектов, например, J-Tag отладчики или мониторы ARINC реального времени.
В общем много всего, и это всё весьма узкоспециализировано.

Со шрифтами я не заморачивался. Стоит обычный 8х12. FAR у меня на весь экран почти никогда не распахнут. Обычно надо иметь у себя открытыми несколько документов требований, пару бланков ревью, калькулятор, Оперу для интернета, Оултук для корпоративной почты, VPN до заказчика, удалённые столы до его бенчей, Acrobat для стандартов, и ещё там по мелочи. FAR в окошке в количестве четырёх экземпляров не редкость. Размер окон 100x50. Удобно.
Автор: akaGM
Дата сообщения: 11.08.2011 09:54
Qraizer
да, спасибо за ответ...
понятно, что ничего непонятно :)
понятно, что при желании всё можно отыскать в сети...
и прав ли я, думая о том, что всё-таки определяющим является сам код, ну или предметная область где он будет крутиться?
слабо представляется, как это будет выглядеть для "hello world" или для:

Код: void main() {
float R;
printf("программа расчёта периметра круга по радиусу\n");
scanf("задайте радиус = %f", &R);
printf("периметр круга = %7.4f\n", 2.*M_PI*R);
}
Автор: Qraizer
Дата сообщения: 11.08.2011 15:25
akaGM, код как таковой мы не смотрим. Мы пишем юнит-тесты, и входными данными являются требования на код. Только если есть расхождение между реальным поведением кода и поведением по требованиям, при ошибках сборки, а также при исполнении ручных степов, т.е. которые невозможно выполнить в автоматическом режиме, мы можем посмотреть код. Обычно результатом является ишук (issue), отправляемое заказчику.
Тестировать по коду нет никакого смысла. Получается, что тестируется не поведение кода, а качество работы компилятора. Это нафиг никому не нужно.

Добавлено:

Цитата:
маловато будет, а разрешение какое?
От 1024х768 до 1920х1080. Знакоместа 8х16 при окошках 100х50 вполне хватает.
Автор: akaGM
Дата сообщения: 11.08.2011 16:36
Qraizer
ясно...
так что, заведомо известно чтО должен делать этот код раз известно
Цитата:
расхождение между реальным поведением кода и поведением по требованиям

а вот если я дополню свою программу вычисления периметра вот такими четырьмя условиями:
1) при R=0 периметр = 0
2) при R=1.0 периметр = 2Pi
3) при R=2.0 периметр = 4Pi
4) при R < 0 периметр не определён

можно такое ТЗ отправлять на валидацию/верификацию,
которую оно заведомо не пройдёт при < 0 :) ?
а если дать аналитическую формулу?


Цитата:
От 1024х768 до 1920х1080. Знакоместа 8х16 при окошках 100х50 вполне хватает.

ты ж писал 8х12?
и потом 8х12 в 100х50 при 1024х768 это не одно и тоже, что 8х12 в 100х50 при 1920х1080
и физический размер зерна здесь ни при чём...
-----
100х50, посмотрел, у меня тоже приблиз. столько же знакомест...
Автор: Qraizer
Дата сообщения: 12.08.2011 00:54

Цитата:
так что, заведомо известно чтО должен делать этот код раз известно
Цитата:расхождение между реальным поведением кода и поведением по требованиям
Нет. Наличие расхождения ничего не говорит о том, что правильно. Это решаем не мы, а авторы архитектуры системы.
Формально. Заказчик оговаривает ТЗ с системными интеграторами, и те после его утверждения выпускают системные требования. Они отличаются от ТЗ всякоразными деталями, неинтересными заказчику, но существенными с точки зрения различных факторов. Например, конечной стоимостью системы. Они обычно описывают только лишь обязательные возможности и характеристики проектируемой системы и должны быть понятны потенциальному потребителю изделия (не обязательно только заказчику), чтобы он мог, просто их почитав, понять, подходит/не подходит.
Затем эти требования отдаются на растерзание инженерному составу, и тот выпускает требования верхнего уровня, которые описывают архитектуру системы в терминах узлов, компонентов, их взаимодействия итп. Т.е. это уже скелет будущей системы, где каждый компонент и узел и их взаимодействие описываются не менее детально, чем системные требования описывают изделие в целом. Эти требования обязаны полно и недвусмысленно описывать теперь уже не просто характеристки, а поведение системы при любых обстоятельствах в рамках условий эксплуатации. Они должны быть понятны любому человеку, владеющему языком изложения, например, английским, и предметной областью применения системы, например, инженеру по радиоэлектронным коммуникациям, если речь идёт о радиоточке в кабине пилота.
Далее эти требования направляются персоналу следующего уровня, и те выполняют детальную проработку архитекутуры, фактически делая из скелета готовое изделие. Так получаются требования нижнего уровня, детально описывающие все нюансы дизайна системы. Логика, описываемая в них, не обязаны быть понятной кому бы то ни было, т.к. тут это не требуется. Требуется - по-прежнему полное и непротиворечивое описание поведения, но язык предметной области не обязан быть понятен кому-либо, кроме специалистов-технологов. Вот им наконец-то требования попадают на реализацию.
Применительно к программным продуктам. Условно, конечно. ТЗ заказчика: "тут окошко, я там мышкой тыц, оно возьми и вот как-нибудь вот так вот сделайся". Системный уровень требований: "должно быть окно, кликабельное, с такой-то реакцией на этот клик; окно должно вмещаться в десктоп с разрешением не менее такого-то; два и более окна недопустимы, попытки создания новых их экземпляров при уже имеющемся долны передавать фокус в имеющееся" итд. Верхний уровень: "У окна должен быть стандартный заголовок и стандартное системное меню. В системном меню должны быть два дополнительных пункта ... Стандартный пункт "Развернуть" должен быть запрещён ... Меню окна должно содержать ... Клиентская область ... Пункт меню такой-то должен ... " итд итп. Нижний уровень требований: "Должна быть вызвана RegisterClass() с параметрами ... Должна быть вызвана CreateWindow() с параметрами ... если возвращаемое значение ... иначе ... ... если uMsg равен WM_LBUTTONUP ... если параметр wParam ... ... ..." итдитпидрetc. Специалист-технолог - это программист, а то и просто кодер. И он пишет код по требованиям дизайна на него.
Несоответствие в поведении - это проблема. Но как правильно, знает в лучшем случае специалист в предметной области. А зачастую и только интегратор. Так что принимать решение о правильности не может даже программист. Он не обязан понимать, что он программирует. Хотя если понимает, то это безусловно хорошо, ибо он может взять на себя некую часть работы по ревью и верификации ещё на стадии создания кода, а то и ишуки закрывать в кратчайшие сроки.

Цитата:
а вот если я дополню свою программу вычисления периметра вот такими четырьмя условиями:
Такие требования бессмысленны. Учитывая тип данных "плавающая точка" и подавно. Поведение кода определено только для трёх точных значений с плавающей точкой и не определено для остальных значений. Формула расчёта тестируется 2-мя степами. Плюс два степа на тестирование граничных значений.
Что касается ввода/вывода, то оно, будучи выполняемо отдельными функциями, в требованиях обычно так и оформляется, мол, вызвать такую-то функцию с такими-то параметрами. Каждая из них должна иметь свои требования, и у каждой из них будет свой тест, так что тут нет необходимости их тестировать, достаточно проверить факт вызова и корректность параметров. Учитывая, что в этом фрагменте кода все параметры константны, для тестирования этого фрагмента требований требуется не более 1-го степа. Он вполне может быть совмещён с одним из предыдущих степов, тестирующих формулу.

Цитата:
ты ж писал 8х12?
Ну да, очепятался. Конечно, размер окна будет разный при разных разрешениях. Ну и что?
Автор: akaGM
Дата сообщения: 12.08.2011 01:09
Qraizer
как-то это сложно... особенно если пытаться объять это всё сразу
кстати, есть такие в вашем процессе, кот. должны быть компетентны на всех стадиях, ступенях (на жизненном цикле создания, так сказать)? как они называются?
какие-то положения из области ЭС (экспертных систем) у вас задействованы?


Цитата:
Ну да, очепятался. Конечно, размер окна будет разный при разных разрешениях. Ну и что?
да мелко! а так ничего...
Автор: Qraizer
Дата сообщения: 12.08.2011 14:01

Цитата:
как-то это сложно...
Зато надёжно. Дело ещё в том, что по отраслевым стандартам сертифицируется не конечное изделие, а процесс его производства. Это формализует процесс до такой степени, что наличие незамеченных недочётов в конечном изделии может быть на порядки ниже, чем если по традиционной схеме.

Цитата:
кстати, есть такие в вашем процессе, кот. должны быть компетентны на всех стадиях
Не знаю. Это у заказчиков интересоваться надо. Наверно есть. Но сам посуди, будет ли менеджер высшего звена заниматься кодингом? Более того, для надёжности и пущей нейтрализации человеческого фактора каждая стадия обязана быть выполнена разными людьми. Например, тот, кто выпускает требования, не должен писать код по ним. Хотя допустимо привлекать многопрофильного специалиста к разного рода деятельности, если она относятся к разным проектам.
Автор: akaGM
Дата сообщения: 12.08.2011 14:16

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

Цитата:
Более того, для надёжности и пущей нейтрализации человеческого фактора каждая стадия обязана быть выполнена разными людьми.
я как раз и спрашиваю о том кто/что объединяет этих разных людей...
и вообще "узкий специалист подобен флюсу"
Автор: delover
Дата сообщения: 12.08.2011 16:25
Qraizer

Цитата:
Размер окон 100x50. Удобно.

Посмотрел и понял, что моё предложение достойно внимания. Как-то давно, подглядел, понравилось, попросил показать... - 120x50. Попробуйте. 120x50 у меня пережило XP и Vista. Сейчас семёрка с тем же размером FAR.

Добавлено:
Мне по поводу верификаторов вспомнилась одна "придча". ) Её удобно применять когда разгарается спор об особенностях, и знании компиляторов.
Компиляторы похожи на самолёт, или аэроплан. Один пилот хвастается другому:
- Я летал на сверхзвуковых, я знаю 8 моделей аэропланов, 12 вертолётов, дельтаплан и воздушный шар.
Другой пилот с поникшей головой:
- Ну мне нечем похвастаться, я знаю только один самолёт. Разве, что могу похвастаться тем, что облетел на нём весь мир.
В случае с верификаторами приоткрывается новый смысл притчи.
Автор: data man
Дата сообщения: 12.08.2011 16:52
akaGM

Цитата:
Всего записей: 3333


Автор: akaGM
Дата сообщения: 12.08.2011 17:09
data man
спас
приглашаю тебя на на мой праздник 3333*2 :)

Хотя более весомый юбилей будет... э-э-э | Зарегистр. 06-12-2002 | в декабре след. года...
Автор: Qraizer
Дата сообщения: 13.08.2011 04:37
akaGM, разные уровни абстракции - разные уровни специализации. Человек, который пишет требования дизайна, безусловно сможет их и закодить, если он к тому же и ещё и программист. Но вот написать требования верхнего уровня уже может не хватить широты охвата предметной области. Так же и наоборот, менеджер, выпускающий системные требования, скорее всего неспособен будет представить себе дизайн продукта в деталях. Обычно ж как: чем глубже смотришь, тем больше деталей видишь, но и тем меньше угол поля зрения.

Цитата:
я как раз и спрашиваю о том кто/что объединяет этих разных людей...
В общем-то ничего. Они могут даже работать в разных конторах. И даже разных государствах. Мы вот, к примеру, выполняем верификацию по договору подряда. Заказчик в другом городе. Были и есть проекты, где заказчик мерикосовый, там же интеграторы, плюс подрядчики из Чехии и Польше. А исполнители - индусы и китайцы. Мы как раз территориально посередине .
Автор: akaGM
Дата сообщения: 13.08.2011 09:58
Qraizer
это-то как раз понятно, ещё в школе учили, "мировое разделение труда" называется...
расскажи немного об интеграторах?

Цитата:
Мы как раз территориально посередине

да, на китайско-польской границе...
Автор: Qraizer
Дата сообщения: 14.08.2011 02:01
А что я тебе о них могу рассказать? Я из в глаза не видел. Судя по роду занятий, это менеджеры, которые хорошо знают конъюктуру рынка, и при этом они достаточно хорошие психологи, чтобы вести переговоры. При этом они также хорошо знают возможности своей компании, объём и контент наработанного материала итп. Скорее всего у них достаточно помощников и консультантов в областях, не так тесно связанных с основным видом деятельности, но в ряде случаев важных для выполнения их обязанностей, не исключено, что важных в зависимости от конктерного заказа. В общем, это авангард успешной компании.
Впрочем, не исключено, что системные интеграторы и менеджеры - это всё-таки разные люди, и первые как раз и являются теми самыми помощниками и консультантами вторых. Скажем так, информацией об своей управленческой структуре заказчик с нами не делится.
Автор: akaGM
Дата сообщения: 14.08.2011 02:19
Qraizer
ну да, наверное, раньше таких называли "толкачи"...

Цитата:
системные интеграторы

во-во, о них...
они блок-схемы со стрелочками рисуют? :)
а кто тогда системные архитекторы?
а вообще, блин, сейчас торговец в ларьке -- "менеджер по продажам"...
Автор: delover
Дата сообщения: 17.08.2011 09:28
Qraizer

Цитата:
К компараторам добавлю Beyond Compare. Предоставлен нам заказчиком. ИМХО очень удобен...

Добавил, если что - подправьте - "инструментарий"
Автор: delover
Дата сообщения: 26.08.2011 20:36
Хочу поздравить программистов, которые пользуются интернетом
и неломанным Windows. Кто не успел заметить -
Россия попрощалась с двумя часовыми поясами
http://ria.ru/society/20100328/216782180.html
Москва ,например , +4, Екатеринбург +6. Для меня это было немного шокирующим событием.
24-го числа контроль версий писал ещё +5, а сегодня 26 пишет +6...
Такие события происходят один или менее раз в жизни. )

Добавлено:
а так же
http://support.microsoft.com/gp/cp_dst#tab0

Страницы: 12345678910111213141516171819202122232425262728293031

Предыдущая тема: Borland Developer Studio 2006 и Oracle пакеты


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.