...

нафига ...

...

Задумка конечно хорошая, но что такое Microsoft Office OneNote 2010 не знаю. Поэтому использовать не буду.
Если что-то хотите систематизировать, может лучше веб-страничку нарисовать, сделать удобную сортировку, поиск? С возможностью обновления участниками форума? Могу даже у себя захостить. 24/7 гарантированно. Можно и с админами переговорить, может они разрешат к форуму прикрутить? Хотя врядли они на это пойдут. Массив и тот чинить никто не хочет.

Спасибо! Я понял, что подобная фигня никому не интересна, поэтому принято решение более не напрягаться и не выкладывать её в инете.
Тему можно снести.

Не, ну так уж радикально - зря Вы. Зачем по двум человекам судите по остальным. Вероятно кто-то уже скачал и сказал про себя "спасибо".
Я же всего-навсего предложил несколько другую схему ведения дневника. В его наполнении могут участвовать все, а контролировать процесс - ответственные за это дело. Например - Вы.
Верните пост и ссылку на место. И не судите строго. Мое мнение - это не мнение всех остальных. Извините, если обидел.

З.Ы. Если интересно - могу технически реализовать свою задумку - более расширенную версию девчарта с блекджеком и ш красивыми описаниями, картинками-примерами и комментами, поиском. Поможете?

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



Хм. А какого рода помощь Вам требуется?

Чушь. Нужно!

Можно вместе систематизировать и создать упорядоченный справочник. Была сперва мысль написать движок справочника и наполнить его информацией. Но сама по себе информация не очень интересна. Интересно ее обновление, возможность ее добавления и корректировки силами сообщества. При трезвом взгляде, на эту роль хорошо подходит движок wiki или тот же форум. Где отдельная тема - описание какой либо пленки в каком нибудь проявителе или как то так. Можно конечно и изобрести велосипед, написав с нуля - не против.

Вот помощь нужна собственно в развитии идеи, помощь в классификации существующего, помощь в развитии творения, модерировании и т.п.

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

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

Простите, что не ответил сразу.
Разумеется, это делать НАДО!!!

И лично я это всемерно приветствую.

В свое время (в "Текущем дневнике проявок...", в начале этот процесс отслежен) за основу был взят:
http://www.digitaltruth.com/devchart.php?F...&mdc=Search
- он был русифицирован, к нему были добавлены практические результаты нескольких людей а потом введена "встроенная" температурная коррекция (по 7% времени на каждый 1С - простейший вариант). Далее это было "прикручено" к Форуму и сделана заполняемая форма введения новых результатов. Вводимые результаты просматривались модератором и активизировались. Долгое время все работало замечательно, а вот потом полезли спаммеры (боты) . До нескольких СОТЕН постов в эту форму ежедневно! Внесение новыз результатов совершенно "захлебнулось". А потом и модуль массива "подломали" - пришлось дезактивировать...

Восстановитьть что-либо подобное ОЧЕНЬ бы хотелось, но КАК все это будет в свете вышеприведенных проблем? Тут надо думать...

И еще, Павел с Ольгой сейчас физически переезжают в Москву, и судя по всему именно по этому не могут сейчас особенно отвечать в Форуме; а так я думаю, немало конструктивного уже сказали бы.

есть предложение набросать в черновом виде что именно должно быть в таком продвинутом варианте проявочного лога и как он должен выглядеть. пишем все самые разумные и безумные предложения
сделать это в виде веб-приложения не проблема. да и захостить есть где. но нужно иметь спецификации чтобы делать и не переделывать потом по 20ть раз.
идея с коррекцией по температуре хорошая. мне видится так же связка лога с рецептурой. и возможность внесения новых рецептов.
как один из вариантов - это офлайновая оболочка (помимо веба) которая позволяет хранить и анализировать какие-то приватные результаты проявок/рецептур с возможностью их публикации. такой вариант я тоже продумывал - в принципе реализуемо

Ребята! Можно я сразу всем отвечу?

Моя имха, так сказать

1. Для того, чтобы реализовывать подобный проект, нужно много свободного времени. У кого его много?

2. У проекта должен быть только ОДИН идеолог (руководитель проекта). Когда у проекта несколько голов, ни к чему хорошему это не приводит. Поэтому для начала нужно выбрать человека, который будет держать бразды правления и собирать все мысли воедино. Главные требования - огромное желание реализовать подобный проект, знание и понимание предметной области и наличие свободного времени. Все остальные могут только генерировать идеи и выполнять чётко поставленные задачи руководителя проекта.


ЗЫ: а против спам-ботов нужно защиту ставить, например, циферки для ввода их вручную.
ЗЗЫ: сейчас посмотрел специально - даже в форме регистрации на форуме защитный код отключен. Зачем? Вот боты и лезут.

То, что было выложено, не является тем, что Вы хотели бы видеть
Это всего лишь собранные в электронной записной книжке (Microsoft OneNote 2010, ставится вместе с офисом) и систематизированные по пленкам рецепты из дневника обработки пленок.

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

Прямо так сказать, что свободного времени много - значит соврать. Пару часов после работы, чуть больше в выходные могу выделить. Естественно всё не очень быстро получится. Это надо понимать.

Сперва совместно нужно выработать общую концепцию. Определить, что хотим получить на выходе. В open-source разработках принимают участие люди со всех точек планеты, но координатор должен быть один. В крайнем случае очень сплоченный коллектив, где все друг другу доверяют и понимают друг друга.

Да, конечно. Множество методов борьбы. Самый простой - капча или апрув админа.

А я вот теперь все свободное время, которого и так мизер, стараюсь выделить на проявку пленок и печать фотокарточек



Хорошо! Скажите мне, пожалуйста, как Вы представляете себе совместную выработку общей концепции?




Вот об этом я и говорю. Только использую для этого термин "руководитель проекта".

1. Выбрать руководителя проекта.
2. Выслушать мнение остальных по поводу функционала, дизайна, новых фич и т.п.
3. На основе сформировавшейся по п.2 картины построить для себя техзадание, утвердить его.
4. Определиться с разработчиком(ами) и приступить к реализации.
5. В процессе разработки предоставлять возможность тестирования всем желающим.

Как-то так наверное.

3.1 вынести техзадание на публичное обсуждение.
3.2 внести последние корректировки по результатам п. 3.1

Хм! Странно! Процесс мы с Вами понимаем одинаково.
Получается, что говорим об одном и том же, но в разных местах расставляем акценты, поэтому не можем друг друга понять

С пунктами 3.x согласен.
Можно ли теперь, пока не выполнен пункт 1, начать обсуждение пункта 2?

Попробую выразить мысль, как я хочу видеть дневник:
1. Каждая запись в дневнике описывает какую-то одну обработку конкретной пленки в конкретном проявителе с конкретными режимами агитации.
2. Запись имеет следующие поля:
а) Вид пленки (фотоматериала) напр. FOMAPAN 100
б) Вид проявителя, напр. Rodinal
в) Разбавление проявителя, напр. 1+100
г) Другие изменения в рецептуру, напр. добавление бензотриазола 0.1
д) Температура проявления, напр. 20C
е) Условия агитации
ж) Сканы негативов
з) Сканы позитивов (отпечатков)
и) Описание процесса, личное мнение о результате и т.п.
к) Комментарии

3. При такой структуре хранения записей в БД можно просто получить дополнительные необходимые фичи:
А) Представление дневника в наглядной табличной форме
Б) Сортировка по а) пленке, б) проявителю
В) Наглядное сравнение двух и более проявок между собой

Вот. Сейчас подумаю, еще допишу. Чего-то хотелось еще....

Можно. Вот только пока нет человека, который будет всё это консолидировать и отделять зерна от плевел, всё это будет лежать мёртвым грузом или будет использовано сторонним разработчиком для реализации своего проекта. Да, согласен, я параноик



Только рекомендую не хранить данные в одной таблице, а всё-таки создать нормальную реляционную модель хранения данных. Я готов её спроектировать. Осталось только определиться с СУБД.
Отображение же данных пользователю в одно-табличном представлении возможно.

Также, на мой взгляд, будет полезной функция, которая позволит пользователям добавлять уже к существующим рецептам свой результат повторения этого рецепта со своими примерами сканов. Надеюсь, что понятно объяснил )))

Да, конечно дополнения разумные. Как-то я упустил их.
Что касается, СУБД, то разницы большой не вижу, если не отклоняться от стандартов. MySQL везде есть, думаю его и стоит использовать. Это облегчит перенос между площадками.
И конечно же реляционные возможности СУБД надо использовать. Фирмы-производители, виды пленок, проявителей и иже с ним напрашиваются само-собой в справочники.
Набросайте структуру табличек, если есть время - обсудим ее. (Мне сейчас немного некогда - срочная работа, я лучше как DBA поучаствую в обсуждении и корректировке структуры). Уверен, все сделаете правильно.

Что если ввести понятия как Основной результат и Повторение результата. Тогда Повторение результатов - это что-то вроже комментариев к Основному результату. Можно им отдельный статус дать. А вообще, комменты там не уместны видимо. Для этого форум есть. Добавление Повторения результата с примерами - пожалуйста. Если рецепт модифицирован, то это отдельный Основной результат.
Так? Не запутались?

а я бы каменты разрешил. если кто-то повторил и получил другой результат - почему бы это не опубликовать?
режим агитации можно записывать в сокращенном виде. тем более не так уж много разным вариаций с агитацией как может показаться.
в структуре не отображен момент с двухрастворными проявителями. нюанс заключается в том, что рецептура второго раствора может варьироваться при неизменном первом. опять же вылазит время во втором растворе. и режим агитации в нем.
при заливке сканов (а особенно 100% кропов) надо учитывать разрешение при сканировании. крайне неудобно сопоставлять кропы отсканеные с разным разрешением

еще один момент - просрочка. неплохо бы где-то делать отметку что пленка просрочена на столько-то лет с возможностью делать выборку "только просрочка"
PS это по свежим следам так сказать - сегодня проявлял широкую свему64 просрочка 93го года без бромистого. и без бензотриазола. вообще без каких-то антивуалентов. на выходе идеальные негативы - вуали просто нет. зерно в норме. фантастика блин

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

Еще мысли есть, но вот силенок сейчас имеется ровно на то, чтобы сказать об этом...
Завтра постараюсь довести.

Над структурой я уже работаю.
Руководителя нет, поэтому в команде разброд и шатание

Предлагаю на всеобщее голосование кандидатуру 3aBxo3, если он конечно согласен. Если согласен, то один голос (мой) уже есть. Думаю, хорошая кандидатура на должность руководителя.

Ваша помощь и участие, Aleksiy, очень требуется. Заранее спасибо!

У меня из требуемых качеств руководителя присутствует только одно - огромное желание реализовать проект. У меня крайне мало свободного времени и почти полное отсутствие знаний предметной области.

Я вот как раз Вашу кандидатуру хотел предложить. Активности Вам не занимать, знаний тоже. Площадка для реализации проекта Ваша. Рискну предположить, что у Вас серьезные навыки DBA и девелопера. С желанием реализовать проект, похоже, тоже всё в полном порядке

ЗЫ: это не алаверды! Это серьёзное предложение

Алексей! С днем рождения Вас! Здоровья и долгих лет жизни!


Если верить форумному напоминателю, то мы с Вами одногодки

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

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

Картинка удалена.

Ага, ну почти как я и представлял себе. На досуге осмыслю структуру и внесу еще предложения. Пока же есть пару непонятных моментов:
1. Годность пленки. Зачем это делать через справочник? Фактически годность пленки можно выразить целым числом INTEGER в годах просрочки. 0-в пределах срока годности, 1-1 год просрочки и т.д. Или что-то иное задумывалось, потому как в таблице "Итерация" есть "Срок годности пленки"?
2. "Тип скана" - скан негатива или отпечатка. Так понимаю?
3. Так же против справочника "Разбавление". Разбавления нестандартны, помимо ходовых 1+2, 1+3 разбавляют более оригинально, 1+50,1+60 - в общем простор для творчества. Предлагаю просто типизировать запись о разбавлении и не вводить справочник.

Ни в коем случае не критика, выяснение рабочих моментов - чего недопонял.

В остальном, структура очень адекватна. Можно взять за основу.

Upd. Да, и в таблице "Пользователь", пароли хранить не стоит. Хэш пароля - да.

Словарь "Годность пленки" сделан для легкого разделения пленок на просроченные и нет. В нем всего два значения: "Свежая" и "Просроченная". Человек ведь может и не знать срока годности пленки, но быть уверенным в том, что она реально просрочена. В этом случае он проставляет, что пленка просрочена и не ставит срок годности. Если же известен срок годности, то он ставится для того, чтобы тот, кто будет читать рецепт, сам мог вычислить срок просрочки. Кстати, для этого надо фиксировать дату рецепта или дату добавления рецепта в базу.



Именно так.



Особых возражений нет.



Таблица "Пользователь" пока в набросочном варианте. Я не имел ввиду, что в ней будет храниться пароль в открытом виде


ЗЫ: приятно побеседовать с человеком, который разбирается в построении реляционных моделей данных

Кстати, забыл добавить к сущности "Итерация" поле "Полученная чувствительность". Уже сделано.

Вопрос такой: если избавляемся от словаря "Разбавление", то может поле "Разбавление" добавить к сущности "Итерация", а не к сущности "Рецепт"?

Ага, идея понятна. Мысль вычислять срок просрочки хорошая. Только основываться надо не на дате добавления рецепта в БД. Можно ведь по памяти довавить рецепт, или из тетрадки, воспроизведенный когда-то там уже не вчера. Но это решаемо. Не будем зацикливаться.

Да, более 10 лет в обнимку с ораклом на продакшене. Да Вы, батенька, тоже не промах. Приятно.

Логично. Один и тот же рецепт в разных разбавлениях дает разную картинку. Переносим в Итерацию - я "за".

Двухрастворные проявители можно учесть двумя записями Рецепта в Итерации. Для однорастворных - второй Идентификатор рецепта - NULL.
Трехрастворные и т.п. - слайды и цветная проявка - не стоит этой возни со структурой, я думаю.

И еще один момент. Хотелось бы устаканить терминологию.

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

Нет. На мой взгляд стоит сделать промежуточную между проявителем и итерацией таблицу, в которую вынести поля "Разбавление", "Время", "Температура" и "Агитация". Для однорастворного проявителя в этой таблице будет одна запись для каждой итерации, для двухрастворного - две и так далее.

Вобщем, пока как-то так... только кольцевая связь мне не нравится... мозги на сегодня больше не варят. Завтра буду еще думать.

Картинка удалена.

С терминологией согласен. Постараюсь придерживаться.
Насчет промежуточной можно подумать. Если выносим Идентификатор пленки в Итерацию, то все встает на свои места.

стоило отофлайнится немного а тут такое движение
народ! я конечно понимаю что нормализация и реляционные отношения спасут мир. но мы же не луноход проектируем? зачем такой сложный структура для такой простой задача?
ну вот смотрите:

1) чувствительность не надо выносить в отдельную табличку. ряд чувствительностей стандартный. в вебинтерфейсе выбор из списка

2) то же самое относится к разрешению скана. нефиг сканировать с разрешением 2741дпи народ этого не поймет

3) тип скана я бы вообще заменил на integer со значениями 0/1. ну и может быть 2 (правда не знаю что оно может означать)

4) сроки годности. я бы все же упростил и оставил одно integer поле - просрочка в годах. если оно 0 (по умолчанию) то материал не просроченный. дело в том что иногда приходится работать с материалом срок годности которого известен крайне неопределенно. но то что он просрочен скажем лет на надцать сказать можно с большой долей уверенности

5) таблицу "рецепт" я бы выбросил. "идентификатор пленки" добавить к "итерации". выбрать все итерации по цепочке проявитель-агитация-итерация не сложно - один запрос.

6) таблицы проявитель/раствор я бы объединил. всегда можно завести две записи - например Diafine A, Diafine B. я частенько использую в качестве второго раствора универсальные составы. т.е. первый раствор меняется а второй скажем такой же как и Diafine B.
в случае чб-слайд процесса либо кросспроцесса (обработки С41й пленки по чб) весь процесс многостадийный и там может участвовать несколько проявителей и других ванн (отбелка, осветление, чернение, фиксаж и тп). понятное дело что все эти ванны к проявителю имеют весьма далекое отношение, обычно являются универсальными и взаимозаменяемыми
в свете этого и расширения спектра процессов я бы объединил таблицы "проявитель" и "раствор". с полями: наименование, состав (текст) и тип раствора (проявитель, допроявляющий (для двухрастворников), стоп, отбелка, осветление, чернящий, фиксаж, вспомогательный и тп). при этом такие операции как замачивание, промывка и засветка тоже вписываются в эту схему! т.е. можно полностью расписать весь процесс (если он сложный скажем - у меня KodakVision2 по чб 8 ванн однако)
пункт спорный и обсуждаемый - так что надо думать

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

По пунктам 1,2,3 - поддерживаю полностью.
4 - аналогично. Об этом говорил и то же предлагал ранее.
Остальное - надо на свежую голову. Завтра.

ну это нормальный процесс обсуждения. даже после того как структуру более менее устаканим надо будет на нее еще раз посмотреть под кривым углом с точки зрения удобства использования

Итак, давайте по-порядку!



Я, конечно, не совсем понял Ваше предложение, но рискну предположить, что варианта два:

а) Вы предлагаете вообще убрать значение "номинальная чувствительность пленки" из модели. В этом случае у пользователя не будет возможности выбрать все пленки одинаковой чувствительности для выбора нужной пленки под конкретную задачу.
б) Вы предлагаете убрать таблицу "Чувствительность", оставив при этом в таблице "Пленка" поле "Чувствительность" и реализовав непосредственно в коде программы выпадающий список возможных значений этого поля. Согласен, ряд чувствительностей стандартный. Но что мы будем делать, если завтра вдруг фирма Ilford выпустит пленку с нестандартной чувствительностью? Правильно! Нам придется обращаться к программисту, чтоб он изменил код программы. Это плохая практика, и я ВСЕГДА стараюсь избегать подобных решений. Вобщем, моё мнение - словарь "Чувствительность" необходимо оставить и реализовать в интерфейсе какой-либо редактор словарей или же просто дать пользователю самому добавить новое значение в словарь с последующей модерацией.




Ответ абсолютно идентичен пункту 1. Я бы даже сказал, что он более категоричен, ибо разрешения сканирования не стандартны.



В словаре "Тип скана" всего два значения: негатив и бумага (позитив). Вполне возможно, что негатив стоит разбить на два, типа негативный негатив и позитивный негатив . Как этот словарь реализовать, цифрами или словами, это не принципиально. Просто если цифрами, то программисту придется слова прописывать в коде, привязывая их к цифрам.
Так что по этому вопросу у меня нет принципиальной позиции. Пусть прораммист делает так, как ему удобнее.




Вот Вы сами как раз описали ситуацию, в которое одно поле типа integer мало чем поможет. Вы НЕ ЗНАЕТЕ, на сколько лет просрочена пленка, но точно уверены, что она просрочена. Какую цифру Вы проставите в этом поле? В описанной же мной модели в таблице "Годность пленки" всего два значения: свежая и просроченная, и Вы просто ставите у пленки признак, что она просрочена, а поле "Срок годности" оставляете пустым, ну или можете указать в нем приблизительный год истечения срока годности. Так что здесь я тоже категорически не согласен. Хотя тут не спорю, таблицу "Годность пленки" можно убрать и в таблицу "Итерация" просто добавить атрибут "Годность пленки", имеющий всего два значения.



Тут буду думать ещё. Ответ для меня пока не очевиден.



И как пользователь сможет выбирать все записи, относящиеся к проявителю Diafine? А так в таблице "Проявитель" будет запись "Diafine", а в таблице "Раствор" будет две записи "Diafine A" и "Diafine B", относящиеся к одной записи "Diafine".
Кстати, если, допустим, в таблице "Проявитель" добавить вторую запись типа "Diafine модифицированный (автор Relayer)" и к ней привязать имеющийся уже в таблице "Раствор" Diafine B, то у нас получится отношение между этими двумя таблицами "многие ко многим", соответственно, придется добавлять промежуточную таблицу для развязки этой ситуации.



Структура, кстати, предельно простая... примитивная, я бы сказал. А нормализация значительно упростит задачу программисту.

Всё выше мной написанное - это моя, как говорится, "бизатвецтвинная имха"
В конечном итоге всё будет решать программист

Вот. Немного подумал и получается что.
1. Чувствительность все таки надо связывать с Фирмой производителем. Есть стандартный ряд чувствительностей, но есть и стандартные пленки. Fomapan 100,200,400 но нет Fomapan 160. Так что это разумно.

2. Тип пленки нельзя привязывать к итерации. Он должен быть привязан к пленке.

3. Связка Рецепт-Проявитель-Раствор мне что-то не нравится. Может Проявитель и Раствор объединить, а между Рецептом и Проявителем сделать связующую таблицу один ко многим. Возможность описывать многорастворные проявители.

И на перспективу. Надо придумать доменное имя для проекта. Идеи есть? Что-то с воображением совсем туго. Или третий уровень у d-76.ru выпросить?