kant

Знал, что кто-нибудь да будет высказывать глупые(сорри) догадки роде того что я инвестор и ищу тут проект для инвестирования, или что у меня есть "мега идея на миллион" и я таким образом ищу себе прораммистов что-бы ее реализовать.. =) Специально что-бы избавиться от таких вопросов я и написал свой ЗЫЖ в стартовом топике.
Все проще на самом деле: У меня, как и у вас, есть идеи. У меня, как и у вас, есть немного денег. У меня, как и у вас, есть определенные знания(не достаточные, сразу хочу сазать. Потому что многие тут считают, что они уже все знают про стартапы [laugh]). А если человек здесь отписался, значит, мы смотрим в одном направлении(.com, а не .kz). Раз так, то почему не встретиться? Поговорим. Возможно, найдем общий язык и понимание и сделаем что-нибудь вместе.. Сейчас все твердят о КазНете и людей, кому КазНет побоку, но которые хотят сделать свой проект Оочень мало.

Цель визита: Найти человека. правильного.

Лучший из всех возможных вариантов ответа Потому и спрашивал, люди ведь разные есть.
Я примерно понял ваши. Думаю нам будет о чем поговорить. По крайней мере попробовать стоит.
Я инженер, смею надеяться очень хороший. Но это есть и мой минус как вы понимаете. Раз уж вы интересуетесь стартапами, то скорее всего хорошо знаете и свои слабые стороны.
Есть опыт работы в проектах на мировом рынке, не в казнете, в том числе и стартапов, опять таки не кахахских. Риски связанные со стартапами знаю Требования которые будут предъявляться к продукту тоже. Будет чем поделиться.

Свой email отправил в ЛС.

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

А какова будет цель визита?
У вас есть идея, и вы хотите ее реализовать, или вы хотите инвестировать в уже работающий проект?

Использует ли кто в своей работе Dependency Injection фрэймворки, что есть например в Spring и в Гугл - Google Guice

Конкретно с этими не работал, но работал с аналогами для С# (Unity, ObjectBuilder).
Если вы оцениваете фреймворки на возможность использования в проекте, то вот мое мнение:
При использовании желательно сперва много времени посвятить на проектирование, и корректное разбиение системы на компоненты.
Также очень поможет построение прототипа, чтобы понять где будут подводные камни. А они будут, в частности процесс отладки несколько отличается от стандартного.
Это поможет получить пользу от использования Dependency Injection.
Применение будет оправданно если вы разрабатываете какую-то enterprise-level систему, или сложного GUI приложения, которое будет поддерживать интеграцию с другими приложениями или модульность.
При использовании у вас скорее всего будет чрезмерное использование ресурсов при старте приложения и не очень быстрый старт.
Также будьте готовы к большим конфигурационным файлам, которые имеют тенденцию увеличиваться по мере роста системы.
Я ни в коем случае вас не отговариваю от использования, просто хочу предупредить что есть определенные подводные камни, не указанные в рекламных проспектах. В целом библиотека очень полезна, но не для любого проекта.

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

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

Форма 2. Добавляющая запчасти в список требуемых или желаемых запчастей.
Все тот же список запчастей.
На этой форме клиент хочет видеть список в тех же голубых тонах, что и верхний список формы один.
Для каждой строки таблицы, отображается следующая информация
Кнопка добавляющая добавить.
Наименование детали
Текстовое поле для внесения количества добавляемых деталей.
Стоимость одной единицы.

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

Существующий список на данный момент обладает тремя параметрами, контролирующими его тображение
1. Цвет
2. Команда/меню выполняемая над элементом списка
3. Необходимость отображать кол-во как текстовое поле.

Вот как я вижу реализацию модульности системе:

Создать функцию которая будет отображать список на основе переданных в нее параметров. Этот вариант неэффективен, потому что количество параметров, по мере роста проекта, может быстро вырасти до 10. Даже при 6 параметрах, становится неудобно пользоваться такой функцией, параметры добавляются без всякого логического порядка, а пере упорядочивание параметров, дело неблагодарное и может легко привести к ошибкам. Разумеется можно вместо нашей будущую функцию с 10 параметрами сделать одну функцию которая занимается отображением списка, и несколько функций, которые устанавливают параметры отображения. Так как у нас проект форм на 50, то нам придется для функций поддерживать конвенцию по наименованиям, чтобы вновь приходящий молодняк, легко разбирался в проекте.
При поддержке общей системы наименования функций, у нас будет пара тройка функций следующего вида

list_repairparts_draw();
list_repairparts_setstyle();
list repairparts_setoption();

Для тех кто не любит очень длинные имена, языки заботливо предоставляют возможность использования пространства имен

namespace repairparts
{
list_draw();
list_setstyle();
list setoption();
}

Согласитесь, что оба варианта очень напоминают определение примерно следующего класса.

class list_repairparts
{
  draw()
  setstyle()
  setoptions()
}

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

Если вы спросите в чем разница, если и в том и в том случае работать не будет рассмотрим следуюший пример:
Есть три списка отображаемых на экране последовательно.
Допусти есть параметры, которые приводят к том что список не отображается. При модульном подходе, вы можете оказаться в ситуации, когда после ввода некорректных параметров, процедура не будет отображать ни один из дальнейших списков, даже если они будут передавать правильные параметры.
В случае с модульным подходом мы можем потерять на форме 1, 2 или 3 списка, в зависимости от того в какой из списков по порядку, вы введете неправильные параметры. В случае если у объекта будет наблюдаться тоже поведение, то вы увидите два корректно отработавших списка вне зависимости от того какой список вызывается с неправильными параметрами. Это помогает локализовать ошибку быстрее и спасти свою шкуру, в случае если третий по счету список почему-то оказался очень важен для клиента.
При наличии подобного бага, ООП подход увеличивает показатели устойчивости системы к ошибкам.

----------------------------------------------------------------------------------------------------------------

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

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

для того чтоб абстрагироваться нужно ООП?
Сделайте модуль, наполните его процедурами, и абстрагируйтесь на здоровье.
Без всяких наследований и инкапсуляций.

Рисование графиков достаточно нетривиальная задача. ООП тут как нельзя кстати. Рядовой график состоит из следующих частей. Оси(Axis), Область данных, Легенда. Оси бывают разные, с линейной и нелинейной шкалой, состоящие из данных одного столбца или нескольких, сами столбцы тоже бывают вычисляемыми. Область рисования - bar, dots, lines и так далее. Каким образом мне формировать HTML или изображение для такого рода графиков без ООП? И будет ли лучше не применять ООП.

и зачем там ООП?
Создаете массивы, или ассоциативные массивы, заполняете их данными и прорисовываете графики...

Есть несколько вопросов
1. Не могли бы вы описать подход, который по вашему мнению стоит использовать в веб?
2. На каком языке программирования вы пишете в веб?
3. Что в вашем понимании, является модулем, применимо к языку программирования на котором вы пишете?
4. Можно подробнее описать каким образом вы будуте обрабатывать различные варианты комбинаций осей и типов графиков. Хотя-бы следующее разделение осей на типы вертикальная/горизонтальная, линейная/логарифмическая, один столбец из набора данных/несколько. И соответственно три типа графиков: bar, pie, и cross-tab. Сама предметная область как это делать, волнует не сильно, но хотелось бы увидеть решение, которое будет эффективно справляться с геометрическим ростом вариантов, которые надо учитывать.