30+Т.е. в итоге нужно иметь такое мышление, чтобы язык программирования стал всего лишь удобным инструментом для воплощения задуманного.

Язык программирования - это ничто. Все они, на самом деле, идентичны (SQL - это не язык программирования).
А все поведенческие/мировоззренческие модели идут больше из библиотек, и знания общих принципов, принятых в том или ином сообществе.
По поводу Java и C++ ничего советовать не буду (тем более, я отчаянный критик их идей и подходов, впрочем, колокольня у меня строго своя, от задач подобранная).

А вот по поводу Oracle +/-грамотное мышление даёт:

а) вдумчивое прочтение Concepts (полезно данный кирпич прочитать даже в... довольно внятном переводе от РДТЕХ-а, если совсем с нуля, т.е. оригинал штудировать в данном случе - не обязательно). Все что не понял сразу - лучше пометить закладками (не лучше, а обязательно).

б) в обязательном порядке прочтение всех изданий некого Томаса Кайта (и никого больше)

в) и уже в качестве окончательной доводки и шлифовки п.а и п.б (т.к. концепции - это общее бла-бла-бла и терминология, а Кайт больше бъет по сути практических методов) - чтение Oracle University (эти бьют больше по площадям), причём последние - как общего назначения (тома Dxxxxx), так и мегасуперпуперспециализированного (так называемые DSI - главное, чтоб вот от них крышу не сорвало).

д) а потом можно уже и всяким разным баловаться - к примеру - почитать Льюиса по вопросам CBO, отдельно Миллсапа и Хольта (по вопросам общего Perf Tunig-а), ну и так далее, вплоть до
http://www.ixora.com.au/resources/ (кстати Oracle 8i Scaling - актуален и абсолютно на заслуженно забытый толмуд)

---

Гы, только по Oracle - теория и практика приведения себя в спортивную форму (чисто как DBD) может занять минимум пять-десять лет. Как после этого смотреть на Java и C++ (ресурсы головного мозга - имеют таки ограниченность) - без понятия (многие и не смотрят - EJB и Hibernate - вообще абсолютно безграмотная, с т.з. Oracle RDBMS, хрёнь, и в теории, и в практике, появившаяся исключительно для того, чтобы можно было строгать поделки на коленке, не вникая в п.а) - п.в)).

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

softwarerРекомендовать достаточно сложно.... как мне представляется, Вам нужны фундаментальные труды - книги с названиями типа "Алгоритмы" и "Структуры данных", методологические пособия. Конкретно.... конечно, советуя вслепую велика вероятность ошибиться, но я бы посоветовал попробовать "Искусство программирования" Кнута, с первого тома.

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

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

P.S. Кстати, бытует мнение, что лучшие программисты-разработчики получаются, как правило, отнюдь не из бывших математиков-физиков (больше из гуманитариев, к примеру - лингвистов, либо людей, психо-соматически склонных к данной професии).
И более того, с этим мнением - я даже абсолютно согласен (есть ряд практических наблюдений и выводов и на этот счет). Т.е. математическая школа (построенная, как водится, от засилья физико-технических моментов) - и бесполезна, и даже вредна (т.к. прививает несвойственный для computer science базовый аппарат мышления).

Т.е. декларативно-описательные моменты vs (что там принято у математиков, особенно в аналитических направлениях)?

Но опять же, безусловно - это смотря с какой стороны направлений IT смотреть.

krvsa 30+ , а кто ты по образованию и специальности?
----------


?

К примеру - у меня образование CAПР (CAD/CAM/CAE), специальность - инженер-системотехник(конструктор/технолог/прораммист). Работаю как программист (не совсем по изначальной специальности, больше IS в чистом виде, даже без MES (хоть есть желание)).

В бытность математику-физику-теормех... кхм.. с очень большим трудом осиливал (не моё оно, да и учили (и учат) - паршиво, т.е. учат решать задачки с известными условиями (это вторично), а не ставить/видеть решения (это первично при проектировании, особенно в условиях изначельной неопределенности/неполноты описаний)).

Зато с удовольствием ходил (будучи уже программистом практиком и даже со стажем) на инженерную графику, теорию машин и механизмов, детали машин и даже сопромат (в части МКЭ). т.е. туда, где были принципы системности и именно - декларативно-описательные модели, как основа.

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

Программированию (как водится) в ВУЗ-е никто серьёзно не учил, не учит, да и не будет учить (нет у нас школы в постсовке, хоть тресни).

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

Он (Кнут) не даёт системное мышление. IMHО - вообще.

Кстати, насчёт системного мышления я бы таки посоветовал OOD Буча (ранние издания, не зашоренные рекламой "рациональной розы"), и... очень даже незаслуженно забытых стариканов Шлеера и Меллора (я в бытность утерял их книжку по OOA, хоть перечитал раз пять, не меньше).

Имхо, это (ООА и ООД) куда полезнее, чем старина Кнут (хоть его тоже никто не отменял, но он - излагает только "алгебру"). Опять же, в качестве альтернативы - уметь видеть задачи в целом vs уметь решать частные задачки известными методами (соответственно).

P.S. Есть, правда, масса изданий на этот счёт (системный подход) в смежных направлениях (вообще не IT), куда более серьёзных (особенно у архитекторов/строителей). Но советовать не стану (последнее утверждение довольно спорно, да и под рукой у меня их нет, хотя, в период студенчества я читал их в библиотеке - просто взахлеб, как развёрнутое практическое дополнение к принципам ООД и ООА, которые, по сути, ничего то нового в общую инженерию и не внесли).

30+ Недавно, читая учебник по дискретной математике.

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

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

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

30+Но, вообще, хотелось бы знать, к примеру, как составить алгоритм в том или ином случае.

В общем случае это всего три конструкции (Законы алгоритмизации):

а) последовательное выполнение
б) логическое ветвление
в) возврат (цикл)

Вот и весь общий случай, все остальное - уже следствия (вариации). Ну и плюс - память - линейный массив и любые вычисления можно сделать сложением и операцией изменения знака (т.е. все IT построенно на машине фон Неймана).

30+Вот, я как раз о том, что "все" программирование построено на каком-то математическо-логическом аппарате, который нужно изучить...

Вот еще ссылочга: http://russian.joelonsoftware.com/index.html
Как раз по теме мышления программистов (Лорд Палмерстон в программировании, Закон Дырявых Абстракций - обязательны к прочтению, IMHO).

Кстати, новые переводы вот здесь: http://local.joelonsoftware.com/mediawiki/index.php/Russian

Спольски - один из немногих блогов, которые полезно читать (многое спорно, но пишет он по сути, в отличии от).

30+В идеале, мне это видится следующим образом. Заказчик (начальник и т.п.) описывает мне софтину простым человеческим языком.

Не-а. Простым человеческим языком - можно только на заборе неприличное слово написать.

Если заказчик невменяем, и не может оформить нормальное ТЗ (не говоря уже о Техпроекте) - то
нужно нанимать аналитиков и проектировщиков, которые сделают диагностику заказчику, напишут
много всякого разного (схем, формул, графиков, табличек-формочек), на что Заказчик посмотрит-
и скажет: "О крута (хоть я ничего не понял". Ну а программисты тоже, должны всю эту хрень
переварить, сказать свое громкое фи, и сделать так, как считают нужным.

И это есть правильно и хорошо.

30+ Типа, нужно чтобы софтина делала то-то и то-то и выглядело это (внешне) так-то. Я составляю алгоритм и реализую его,


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

- Нафиг мне Ваши алгоритмы, покажите мне Ваши структуры данных (таблицы).

И тут он - абсолютно прав. Алгоритм - это ничто, его любой недоученный студент слабает. А вот
правильно спроектировать схемы данных - это нужно уметь-с.

30+ причем делаю это не только на Java (потому что я знаю, скажем, только Java), а на том языке, который больше всего подходит для решения данной задачи (в пределах разумного, естественно).

Еще раз, для тех кто на бронепоезде (без обид) - язык это ничто. Все определяют библиотеки, фреймворки.
Язык это основа. Это лишь средство. То, что ты обладаешь русским языком - не даст тебе возможность написать новую Войну и мир (хоть в мире Java и .NET бытует иное мнение, в известной притче о тысяче кодирующих обезьян).

---

Кстати, а про паттерны GoF тебе еще никто не рассказывал?

maytonПаттерны - вещь хорошая, когда необходим плотный диалог рабочих групп, работающих над одним проектом. Если вы работаете один и у вас хороший, технический склад ума, то акцентировать особое внимание на этих буржуазных стандартах не стоит. Многие из паттернов вы применяете не задумываясь. Pool и Singleton я начал использовать даже не зная их названия. Декоратор мы все используем каждый день и повсеместно.

Поддерживаю. Во всяком случае - совсем не стоит делать из них кумира, тем более, ряд GoF паттернов (к примеру - Immutable, Memento, Flyweight) вообще надерганы яверами, извиняюсь, что волосы из носа (в нормальных языках такого безобразия просто нет).

Да и особой там америки нет, в паттернах этих. Впрочем, опять же, только яверы страдают такой хренью, как строгое следование этим лекалам, включая явное участие в именах классов (...Controller, ....Proxy, ...Facade, ...Factory, ...Singleton).

Что (последнее лекалирование) - и вовсе признак дурного вкуса и прочего моветона (зачем банальности эти расписывать?)

--

Хоть ничего эти GoF не открыли. Просто описали то, что было известно десятки лет назад до них.
Но провели классификацю - ну и ладно, спасибо и на этом (лишь бы сильно мозги на заформатировались у кого).

Но в любом случае - для прочтения полезно (я вот так все и не осилил - надоело мусолить банальности).

ve301а я бы по другому сказал - нафиг мне ваши структуры данных - покажите форму и юзеров
форма определяет структуру данных


Не-а... ответ не верный.

Форма определяет лишь форму, но не содержание. Делать содержание только от формы - довольно глупо (вот у меня содержание одно, а форм представления несколько - см. сущность Документы).

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

ve301
И вот подходим к любопытному аспекту - а где содержание? и что за чудо документы нужны?

Еще раз. Очень просто.

Есть документы. Финансовые, к примеру. Платежки, накладные, ордера, счета-фактуры и прочая всякая разная.

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

Итого:

правильный способ: создать мегасущность, которая содержит все описательные поля всех возможных
документов в рамках данной задачи (их там, кстати, не много, полей этих)

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

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

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

Подумай.

ve301
<бред поскипан, тындекс ужоснах тоже>

30+Реально делаю... Вышеописанным способом написано уже 9 отчетных программ. Пользователям нравится. Но хотелось бы уйти от чистой отчетности...

Опять откровение. Для того, чтобы делать отчётные формы - программирование не нужно.

Вообще. Я в упор не помню ни одного отчета, который я не смор бы построить с помощью банального SQL и вменяемого репортера (бенд ориентированного - Crystall Reports, Fast Reports, ну и так далее).

Не стой стороны копаете, уважаемый (и вообще - репортинг это не программирование... вообще).

30+Вот, поэтому и нужно соответствующие навыки (то о чем я писал в начале), чтоб не всю жизнь отчетами заниматься...

Если бы это были отчеты сами по себе, согласен, обошлись бы SQL и jReports, но это (отчеты) часть системы. Т.е. нужен соответствующий GUI, где частенько приходится и компоненты лабать (не только по форме их раскидывать) и данные, получаемые из этих компонентов до помещения их в запрос соответствующим образом обработать...


У..... как все запущено то.
Вообще то есть такой режим: Запрос/просмотр данных/правка.

А отчет (любой), по сути не должен требовать никаких дополнительных контролов, а работать от текущего контекста (просмотра).

Что запросили, то и получили (хоть как). Генератору отчетов просто передаётся текущий контекст, и не важно, какие фильтры туда наложены (это не отчетово дело - источником данных рулить).

Впрочем, озвученный изначально подход (к отчету тулим толпу контролов для фильтрации) вполне себе характеризует яверов (впрочем, не только). Они любители все делать дважды, трижды, четырежды (fine grained part of), размазывая задачу на сотни строк кода и человеко-месяцы там, где... ничего, по большому счету, кодировать не нужно.