| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Религиозные войны > Почему так не любят Delphi? |
| Автор: yura13 20.1.2012, 13:31 |
| Реально, ведь под уиндовс больше не на чем писать. Джава и сишарп требуют установки своих виртуальных машин, да ещё и актуальной версии. С++ язык для извращенцев. Что же использовать? Укажите на адекватное средство программирования под уиндовс а потом хайте делфи. Ведь действительно, программы ведь не на чём писать. |
| Автор: Данкинг 20.1.2012, 13:48 |
| Не знаю, наверное, завидуют простоте, с которой можно писать на Дельфи, причём писать что угодно. |
| Автор: DarkProg 20.1.2012, 14:21 | ||
Я не пробовал писать пока службы, так что не решусь сказать сложно это или нет. Хотя в ближайшее время попробую написать. Основная направленость Делфы это написание пользовательских приложений, или как бы это точнее сказать - всё для пользователей. Более того на сегодняшний день XE2 позволяет собирать приложения для Mac, но тоже пока ещё не опробовал, хотя мак есть у начальника и он согласен был добровольно его дать под опыты с приложениями  У нас просто была заинтересованность тогда А если почитать роадмапы от ембаркадеро, то там же можно увидеть поддержку линукса со следующей версии(люди которые ковыряли исходники писали, что там уже даже зачатки есть под это), что несказанно греет мою душу. Единстввенное для чего не годится делфа, так это программирования микроконтроллеров... к сожалению... А ругают и с пеной у рта доказывают, что делфи туфта те кто ничего не понимает в программировании. Я могу задать встречный вопрос и задаю всем в последнее время, что лучше Китайский или Английский? |
| Автор: LSD 20.1.2012, 14:28 | ||
У тебя там опечатка  |
| Автор: Artemon 20.1.2012, 15:10 |
| Мне кажется такая неприязнь формируется со школьной скамьи. Кому-то преподают Pascal, кому-то C++ Мне вот например преподавали C++ И у меня априори негативное отношение к Delphi, как говорится не читал, но осуждаю. |
| Автор: Snowy 20.1.2012, 15:16 |
 рис 1. yura13 |
| Автор: Данкинг 20.1.2012, 15:17 | ||||
Ну да, если какие-нибудь драйверы писать, то Дельфи тоже не подойдёт, думается.
Зависит от цели программиста. Добавлено через 1 минуту и 16 секунд Взять работу с ole-объектами. Ну-ка, как на C++ сиё будет выглядеть? Или на джаве? |
| Автор: LSD 20.1.2012, 15:56 | ||
Результат программирования на дельфи, не зависит от программиста |
| Автор: newbee 20.1.2012, 16:07 |
| Делфи не любят за быдлокодеров, которые там раньше копошились, обсосано уже сто раз было. Сейчас по этой же причине не любят петухон. |
| Автор: AndreyIQ 20.1.2012, 16:14 | ||||
Как-то писал протокол копирования файлов с/на флешку, ввиде службы, легко и просто.
Не Delphi конечно, но все же, под PIC'и, есть MickroPascal |
| Автор: Данкинг 20.1.2012, 17:12 | ||
Результат программирования - это программа, которая написана за счёт меньшего числа операторов, чем на том же C++. Добавлено через 3 минуты и 2 секунды Пример - работа с Excel. Какое это извращение на Билдере и как всё просто и понятно на Дельфи. |
| Автор: 502 20.1.2012, 17:26 |
| Ocaml ^_^ |
| Автор: LSD 20.1.2012, 17:44 | ||
Только у быдлокодеров скорость разработки ограничена скоростью печати  |
| Автор: Данкинг 20.1.2012, 17:52 | ||
А при чём здесь быдлокодеры? Речь о ЯП, а не быдлокоде/кодерах. |
| Автор: LSD 20.1.2012, 17:59 | ||
Потому что скорость разработки и количество операторов очень слабо связаны. К.О. |
| Автор: Данкинг 20.1.2012, 18:24 |
| "Опытный программист на С++ легко решит любые, несуществующие в Паскале проблемы" ? |
| Автор: 502 20.1.2012, 18:25 | ||
в паскале есть метапрограммирование? |
| Автор: Данкинг 20.1.2012, 18:30 | ||
Я даже не знаю, что это такое. Вывод: для каких-то узкоспециализированных задач С++, возможно, подходит больше. Но для повседневной работы Дельфи куда удобнее. |
| Автор: 502 20.1.2012, 18:34 | ||
чем? |
| Автор: rodnover 20.1.2012, 21:18 |
| С базами и формочками работать. 3 года прописал в связке Delphi+Firebird. Дико удобно, но как решишь чего архитектурно извратиться или улучшить - начинаются костыли. На C++ этого нет. Там, правда, другие костыли... И, кстати, всё больше убеждаюсь в том, что мышкотыкательное делание формочек менее удобно и практично. |
| Автор: Данкинг 20.1.2012, 21:36 | ||||||
Простотой.
И с базами тоже, кстати.
Т.е. динамически создавать формы на джаве, задавая все параметры, удобнее? |
| Автор: DarkProg 21.1.2012, 11:51 | ||
Интересно и что тратить процессорное время на то чтобы своять форму, вместо того чтобы вязть сделать один шаблончик формы, кнуть его в репозиторий и потом в зависимости от задач для конкретного програмного продукта подправлять в ту или иную сторону? Я на типовые формы благодаря такому методу трачу не более 5 минут. Сложные же формы, которых ещё не было в программе делаются с нуля минут ну за 20-30, особенно если там какая-нить хитрая заморочка, а потом уже коддинг. Вопрос к тем кому не нравится делфи, нука назовите мне компоненты для других языков? Для делфи существуют горы готовых компонентов у меня стоит TMS+SUI+DevExpress - этого с избытком хватает для решения любых задач. В редких случаях когда негде хранить свойства приходится делать наследника, но это делов на 5 минут |
| Автор: newbee 22.1.2012, 01:12 | ||||
Добавлено через 1 минуту и 46 секунд
|
| Автор: 502 22.1.2012, 14:21 | ||
ну хоть что-то есть  |
| Автор: k0rvin 22.1.2012, 17:17 | ||||||
А разве в C++ оно есть? Добавлено через 1 минуту и 41 секунду
Вообще зачастую да, однако в любой современной IDE для джавы есть и визуальный дизайнер формы. |
| Автор: 502 22.1.2012, 17:21 | ||
ну может не такое кошерное как в lisp или nemerle |
| Автор: yura13 24.1.2012, 11:35 |
На Делфи можно построить систему любой сложности с минимумом затрат  |
| Автор: LSD 24.1.2012, 11:45 | ||||
Как построишь что-то сложнее чем:
позови |
| Автор: yura13 24.1.2012, 11:56 | ||||||||
Многие уже совсем забыли, что в разработки главное не методологии, паттерны и бес практики, а решение стоящей задачи. И делфи тут прекрасно справляется, если надо то формочками, если не надо то и более сложными подходами. Главное что разработчики насколько погрузли во все свои методологии, что забывают о решении задачи. И не смотря на все ваши методологии код писать однако придётся, и есть ли смысл его усложнять всякими
|
| Автор: Akella 24.1.2012, 12:19 | ||||
Чем-чем? Чем С++! Добавлено через 1 минуту и 47 секунд Говорили, что на дельфи много-много не заработаешь, но тем не мене, http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=911488&msg=11942052 вакансия дельфи программиста 600-1800 уёв. Я думаю, это неплохая зарплата |
| Автор: 502 24.1.2012, 12:23 | ||||
не убедил 
вопрос в том, сколько этих вакансий |
| Автор: k0rvin 24.1.2012, 13:16 | ||
Здесь же, на винграде, в Руби-разделе было несколько вакансий на RoR от 80 круб. При том, что писать на Руби значительно проще и удобней, чем на Делфи =) |
| Автор: Akella 24.1.2012, 17:44 | ||
А что в сях нету try/finally  ?Добавлено через 7 минут и 21 секунду При чём здесь руби, что же вы сравниваете руби и дельфи? Добавлено через 8 минут и 43 секунды
это называется широкий |
| Автор: k0rvin 24.1.2012, 18:13 | ||
В сях как бы вообще нет исключений. А в сях++ юзают http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5_%D1%80%D0%B5%D1%81%D1%83%D1%80%D1%81%D0%B0_%D0%B5%D1%81%D1%82%D1%8C_%D0%B8%D0%BD%D0%B8%D1%86%D0%B8%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F, поэтому там finally не нужен. |
| Автор: LSD 24.1.2012, 18:31 |
| Любят языки в которых есть (чем больше пунктов тем лучше): - есть куча синтаксического сахара, чтоб аж попа слипалась - есть куча библиотек, фреймворков и желательно чтоб бесплатно - есть несколько IDE на выбор - вообще выбор очень важен, пусть 99% используют одну IDE и пару библиотек, выбор важен, нет выбора - язык проприетарный отстой - сложны для освоения, это тешит ЧСВ тех кто их освоил - просты для освоения, но при этом не слишком популярны чтобы не было толпы школьников Так что Дельфи выпадает практически по всем пунктам. |
| Автор: Akella 24.1.2012, 23:39 | ||
ну по этому точно не выпадает  |
| Автор: LSD 25.1.2012, 14:58 | ||
Расскажи ка про библиотеки для написания веб приложений И кстати, к этому вашему VCL эмбакадабра прикрутила MVC, или как г0внокодили так и г0внокодите? |
| Автор: yura13 25.1.2012, 20:19 | ||||
Да нет, не в этом дело. За java стоит oracle, за .net microsoft, за python google. Embarcadero этим троим не конкурент, поэтому его никто особо не пиарит. Вот отсюда и ростут ноги, и ниодному с выше упомянутых Delphi не уступает. C с/c++ другая история, тут и оптимизация и низкоуровневый и куча уже существующих либ.
В нашей компании как раз таки веб на Delphi + MVC(почти) стоит. Да, у нас свой MVC фреймворк для Delphi свой вебсервер. Производительность в результате имеем, по оценке независимых экспертов, больше чем в 10(!) раз превышающую аналогичные решения на java и .net. По разработки для веб на Delphi могу сказать следующее, что разрабатывать сложно только для разработчиков одиночек или для небольших компаний. большая же компания вполне может содержать команду, в нашем случае всего 5 человек, которые будут работать над веб сервером и веб фреймворком. Профит от этого колоссальный. Буквально 3 года назад руководство хотело мигрировать на одну из следующих технологий: java, python, ruby. Мы пригласили архитекторов, работающих с этими технологиями для консультации. Все из них согласились, что лучше нашего фреймворка, для НАШЕЙ компании ничего нет! ВСЕ архитекторы с этим согласились, хотя всё начиналось примерно так: "Delphi для веб??? MVC на Delphi??? Ребята, вы что? Это всё не правильно!". Много говорили о динго, рор и прочих вещах. Но после того, как они начали понимать КАК это всё работало, они соглашались, что всё очень грамотно продумано и лучше для нашей компании ничего быть не может. Так что инвестиции в создание платформы для веб на Delphi сторицей окупаются. Более того, Embarcadero продолжает развивать свой продукт, и вскоре мы покинем мир уиндовс!  Да здравстует линукс, привет яблоки |
| Автор: yura13 25.1.2012, 22:45 |
| Я почему эту тему создал. Просто хочется чтобы как можно больше разработчиков умело смотреть на мир чистыми глазами, а не замурзанными ораклом или майкрософтом. Отбросьте предрассудки и пишите чистый код, на чистых, а не прокладочных ЯП! |
| Автор: 502 26.1.2012, 10:27 | ||
это про Dart? |
| Автор: yura13 26.1.2012, 12:24 | ||||
Как же достали эти новички  виртуальные машины java и .net имеются ввиду. Имеется ввиду, что писать нужно код родной для ОС. Ни JS ни Dart в эту категорию не попадут, так как это ЯП бля браузера, а следовательно нативными для ОС никак не могут быть. Добавлено через 2 минуты и 1 секунду 502, ты бы лучше книжку какую нибудь почитал чем на форумах бред постить |
| Автор: 502 26.1.2012, 12:27 | ||
ахахахахаха LOL про node.js не слышал, а Dart позиционируется как для браузера так и для сервера |
| Автор: yura13 26.1.2012, 12:33 | ||
Покажи мне где я Dart позиционировал для сервера??? И в мыслях такого не было! И вообще, здесь тема о Делфи, если что |
| Автор: 502 26.1.2012, 12:36 | ||||||
вот тут а про js ты вообще бред пишешь
и чо? обсуждаем delphi в вакууме? |
| Автор: yura13 26.1.2012, 12:36 | ||||
| А сервер на JS это изврат ещё тот. Если в браузере деваться некуда, то для сервера технологий хватает. Добавлено через 2 минуты и 9 секунд
здесь???
здесь написано что-то о Dart на сервере? мне кажется ты меня троллишь |
| Автор: 502 26.1.2012, 12:39 | ||||||
говори себе это почаще
и чо?
сервер на delphi это изврат, да а js няшка |
| Автор: newbee 26.1.2012, 12:48 | ||||||
Подумай на досуге, чем обычно десктопная программа занимается 99% своего времени выполнения. И да, 502 ты дал правильный совет, но тебе тоже не помешало бы заполнить чем-нибудь пустоту в голове. Добавлено через 1 минуту и 51 секунду Для сервера Dart позиционирует гугл, есличо. |
| Автор: LSD 26.1.2012, 13:57 | ||||||||||
А за Ruby и JS кто стоит? ZOG?
Это конечно толстый тролилнг но я отвечу. Даже если оставить в стороне явное привирание про 10 кратное преимущество в скорости, тут куча других проблем. Теоретически за счет узкой специализации, самописный лисапед может превосходить готовые решения. На практике же как всегда есть куча но (речь идет о живых и развивающихся проектах, а не о заброшенных): - готовые библиотеки постоянно внедряют поддержку новые фич - готовые библиотеки тестируются гораздо большем числом пользователей, и значит более стабильны - производительность готовые библиотеки получает больше внимания разработчиков, чем свой лисапед - готовые библиотеки поддерживаются средами разработки, тулами - готовые библиотеки имеют комюнити и документацию, как минимум для них известны подводные камни и ограничения Самое главное: готовые библиотеки известны и поддерживаемы. Если у вас завтра уволятся все разработчики вашего велосипеда, то с вероятностью 90% его будет проще переписать, чем поддерживать. А вот если бы вы использовали стандартный веб сервер, то можно было бы легко найти человека который бы обладал соответствующим опытом. Ваш велосипед он нужен не из-за каких-то там мифических преимуществ Дельфи, а "от бедности" Дельфи на веб фреймворки.
Жители Москвы, стесненные жилищным кризисом, бросятся в ваш великолепный город. Столица автоматически переходит в Васюки. Сюда переезжает правительство. Васюки переименовываются в Нью-Москву, а Москва - в Старые Васюки. … Нью-Москва становится элегантнейшим центром Европы, а скоро и всего мира. Добавлено через 2 минуты и 41 секунду И кстати я до сих пор не услышал ничего
Я так понимаю они отсутствуют как класс? И что там с распределенными кешами и нереляционными базами, есть чо?
|
| Автор: 502 26.1.2012, 18:44 | ||
а при чем тут delphi? такой фреймворк что нельзя написать на другие ЯП? LOOOOOOOOOOOOOOOOOOOOOOOOL |
| Автор: yura13 26.1.2012, 19:08 | ||||||||||||||||||||||
Что греха таить, нет хороших решений. Есть решения от третьих лиц, но в своё время нам они не подошли.
Ну по популярности Ruby до Java ой как далеко. А JS в список популярных вообще случайно попал, теперь всем миром не могут его от туда убрать
Извини, но у нас наши сервера в суме отдают несколько десятков гигабайт REST/XML данных за секунду. И в основном это XML меньше 1 кб. Каждый сервер обрабатывает несколько тысяч запросов в секунду. И + ещё бд дёргает. Благо 4 вида кеша обращения к бд сильно гасят. А теперь скажите, что тут делать хвалёной яве? Да она сразу ложится, даже и не дёргается, проверяли. Вот почему создание своей веб платформы на Delphi сторицей окупается.
Над платформой для веб работает не кто попало, а люди, которые уже имели опыт в подобных вещах и знают что делают. Проблемы однако есть, но всё решается. А если они вдруг все уйдут, то найдутся новые. Всё отлично документируется, поэтому проект продолжат. Да и не будут все вместе увольняться. В крайнем случае заставят две недели отработать и передать кому-то проект.
Есть решения универсальные а есть специальные, мы себе можем позволить специальное и имеем с этого профит.
Для десктопа уж лучше MVP. Его мы для десктопа не используем, а используем г0внокодинг. Есть несколько заготовленных шаблонных проектов. С помощью нашей маленькой IDE создаются нужные прокси-классы, и другие специфичные вещи. Дале мы размещаем компоненты и пишем логику. Порой, такой проект бывает готов за 3(!) дня. То есть, от постановки требования, до возможности использовать проходит меньше недели. вот вам и Делфи Далее, если подобный функционал нужен будут постоянно мы переносим его в веб. Не знаю, может для кого-то это и г0внокод, но мы имеем реальный результат.
Пользователи Iphone 4 это оценят
А мужики то думали что ява до сих пор интерпретируется
Нас мало волнует почему ява тупит. А тупит в основном потому что опирается на JVM, что и есть прокладка. Нас интересует производительность, а её в яве, ну скажем, не так много. |
| Автор: 502 26.1.2012, 22:01 | ||||
причем тут вообще iphone, и да js там есть, а delphi нет
java компилируется в байткод какие у нас сеньоры пошли, они знают о программировани намного меньше джуниоров, мдя |
| Автор: LSD 27.1.2012, 15:02 | ||||||||||||
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html, при том что у них не было Борланда.
Бедные мужики из твитеру, ораклу, сану, ибеэму и т.д., как они там со своей явой мучаются. Тут же такой классый сервер на дельфях простаивает. Сходите к ним, предложите свой сервер, потом вместе поржем
Я бы это сформулировал так: г0внокодинг это дельфи вей
У вас еще и IDE своя?  У вас там чо, рекрутинг проходит по параметру сколько своих лисапедов написал?
Уже не один проект на совести этих профессионалов.
Ты рассуждаешь про вещи в которых не разбираешься. |
| Автор: yura13 27.1.2012, 16:09 | ||||||||||||||
Учись различать сарказм
У нас тут не Москва, наша компания находится в одной из самых высокотехнологичных стран мира, и у нас так не принято.
Каждый Delphi разработчик нашей компании имеет Embarcadero RAD Studio 2010 редакции Architect. По сути Architect каждому не нужна, но мы хотим поддержать этот проект. А то что своя IDE есть, то тут нечему удивляться. Есть вещи, специфичные для нашей компании, и через приблуды к Embarcadero RAD Studio всё не так хорошо решается.
Не совсем. Я ещё в студенческие годы два проекта на яве педалил.
Иногда я думаю что лучше бы у нас тоже не было Борланда По крайней мере последние годы его существования он Делфи делал скорее вред.
Дельфи вей - это решения производственных задач за 3 дня, которые в яве решаются 3 месяца.
Я же говорил, наше решение не универсальное - а специальное. |
| Автор: Pawl 27.1.2012, 19:30 |
| Что ж вы так все на Delphi в целом и на Юру13 в частности накинулись? Ну, нравится человеку Дельфа, ну пишет он на ней, так и слава Богу - при любимом деле ведь, за которое еще и деньги, небось, платят! Тем более, походу, у буржуинов. Не каждому дано такое счастье! А что до Delphi, все-же развивают его, на что-то надеются. Вон, каждый год по новой версии выпускают. Видимо, окупается, иначе давно бы обанкротились. Т. е. пишут люди, да еще и за лицуху денежки платят! Вон, Кристиан Гислер для своего тотала только Delphi и использует, и нечего такой файл-менеджерчик получился, мне нравится. Короче, тут как в природе: не приспособился - вымер, а пока не вымер - имеешь право на существование. Delphi же сейчас не только существует, но и развивается, т. е. совершенствуется. А что из этого получится - время покажет! |
| Автор: kin 27.1.2012, 19:50 |
| Привет! Вы, конечно, извините, что вмешиваюсь в ваш, высокоинтеллектуальный спор, от которого несомненно зависит будущее этого мира, но ощущение того, что вы, yura13, то ли рекламируете вашу фирму, то ли ее продукцию, с увеличением количества страниц этого поста становиться все сильнее и сильнее... В общем, как в анекдоте"...ты тоже из далека начал..." P.S. Усы, лапы..., главное - хвост!... |
| Автор: Данкинг 29.1.2012, 12:47 |
| http://forum.vingrad.ru/index.php?showtopic=346127&view=findpost&p=2453920 один из примеров, когда в Билдере (даже не "чистый" С !!!) появляются ошибки, которых в Дельфи в принципе быть не может. |
| Автор: Akella 30.1.2012, 01:37 | ||||||||
Ну вот список. Есть реально живые и развивающиеся , в том числе и халявныеIndy, intraweb, TMS Intraweb, spring, Responsive Software Framework, Raudus, uniGUI, DelphiOnRails, ExtPascal, WebHub, xxm, RTC, G Framework, iwelite, ExpressWeb. Добавлено через 6 минут и 22 секунды
И без MVC хорошо.
Ну да, а как по другому. Не надо сравнивать какие-то там циклы и куски кода. Нужно сравнивать производительность приложения в целом. И программы на дельфи весьма шустренькие У каждого языка есть своя ниша, так сказать. Добавлено через 13 минут и 4 секунды
угу http://www.msbtree.ru/ |
| Автор: Stolzen 30.1.2012, 12:56 | ||
DephiOnRails? Да вы знаете толк в извращениях Какую-нибудь базу за пару дней наваять - Delphi для этого отлично подходит. Что-то большее... На любителя. |
| Автор: Данкинг 30.1.2012, 13:47 | ||
Базу на Дельфи наваять? |
| Автор: Stolzen 30.1.2012, 13:50 |
| Накидать по формочке элементов, да связать их с СУБД. За пару дней можно управиться, если сложной логики не нужно. |
| Автор: LSD 30.1.2012, 14:00 | ||||||||||||||
Ну все, мы все попадали со стульев, от крутизны вашей компании
Какой опотный разаботчик
Я говорю, что если эти ваши "специалисты", которые работают "в одной из самых высокотехнологичных стран мира" заявляют:
То это говорит исключительно за радиус кривизны рук этих "специалистов".
Первый же пример в точку:
Нужно веб приложение? Вот тебе сокеты, сиди пиши
Я и говорю: дельфи вей Дельфи провоцирует разработчиков разводить ### в коде. Щелкнул мышкой на кнопку и получил свой Button111OnClick, и прям там и накодил логику. А когда потом надо будет разделить бизнес логику и слой презентации, хрен это у тебя получится. |
| Автор: Akella 30.1.2012, 14:29 | ||||
Ну во первых дельфи не направлен на написание веб-приложение, тем не менее позволяет. Вот, например, на TMS IntraWeb можно писать: http://www.tmssoftware.com/site/products.asp?t=iw http://www.tmssoftware.com/site/tmsiwpro.asp TMS IntraWeb Charts TMS IntraWeb Component Pack Pro Script Edition TMS IntraWeb Component Pack Pro TMS IntraWeb Component Studio TMS IntraWeb HTML5 Controls Pack TMS IntraWeb Planner TMS IntraWeb Query Builder TMS IntraWeb Security System TMS IntraWeb iPhone controls pack Добавлено через 1 минуту и 1 секунду
Кого он провоцирует, это их проблемы. Добавлено через 7 минут и 2 секунды Мне интересно, какая будет будет производительно у программ с использованием FireMonkey. |
| Автор: LSD 30.1.2012, 14:44 | ||||
А вот "гуру" считает что еще как направлен.
Вот именно из-за таких "проблемных", дельфи и не любят. На одного Ghisler десяток таких г0внокодеров. Добавлено через 35 секунд И кстати, а чем борланд писали свой интербейз? |
| Автор: Akella 30.1.2012, 15:45 | ||||
Без понятия. Я не вникал в тонкости MVC. Тут что-то нашёл: http://pyatochkin.blogspot.com/2010/10/delphi-mvc-pattern.html и даже с примером. Добавлено через 5 минут и 45 секунд
и что с того |
| Автор: Stolzen 30.1.2012, 16:21 | ||
На делфи, наверное. Они же и делфи писали на делфи. Добавлено через 1 минуту и 13 секунд А хотя он древний очень. Наверное тогда на крестах. |
| Автор: tzirechnoy 30.1.2012, 18:49 | ||
Он настолько древний, что по тем временам этот препроцэссор для С никому не был интересен. |
| Автор: yura13 30.1.2012, 23:57 | ||||||||||||||
Вы ошиблись
На Делфи можно писать логику любой сложности, это вам не яваскрипт.
Я не говорю что опытный. Но хотя я на яве и не пишу, но регулярно сталкиваюсь. Можно подумать у вас есть приличный опыт разработки на Делфи?
Если в явы нет производительности - значит разработчики криворукие. Железная логика
Некоторые люди, наивно полагают что с MVC нельзя г0внокодить. Наверное вы не видели как люди пишут вьюхи, генерирующие для себя контроллеры. В любом случае MVC от г0внокодинга не спасает. Да и простор для г0внокодинга за пределами MVC хватает. И ещё, есть люди, которые наивно полагают, что используя MVC они будут меньше кода писать . Потом они становятся более опытны, и уже начинают наивно полагать что их приложения будет проще поддерживать и развивать . Потом, они становятся ещё опытнее и думают что их приложения будет проще тестировать, если они на MVC. И когда они окончательно растеряли свои иллюзии, они начинают понимать, что MVC их проблем не решит А вот полностью логику приложения писать в обработчиках - это уже надо руки отрывать. Пишутся классы, содержащие логику, а в обработчиках они создаются и вызывают какие-то свои методы, это нормально
За "гуру" спасибо, польщён. Вот только не припомню где писал что направлен. Я писал что большая компания может себе позволить и будет иметь с этого профит. Однако, для команды < 30 человек, скорее всего, найдутся более удобные технологии.
Что тогда про пхп говорить? |
| Автор: 502 31.1.2012, 10:09 | ||
и чо? если пхп плохой ЯП то дэлфай автоматически становится хорошим, как был УГ так и остается |
| Автор: LSD 31.1.2012, 13:40 | ||||||||||||||
Его даже не борланд начал разрабатывать.
Опыт небольшой, но я и не говори про ограничения дельфи как ЯП. Я говорил про ущербность велосипедов.
Если разработчик говорит, что с помощью ХХХ задачу не реализовать он на 100% в этом уверен, а при этом существуют примеры реализации задачи с помощью ХХХ. То из этого следует вывод, или разработчик по глупости делает такие заявления, или сознательно обманывает заказчика. Какой вариант был в вашем случае - тебе виднее.
Некоторые люди наивно полагают, что читать что пишет оппонент излишне, достаточно приписать ему свои фантазии.
А! Так вот на кого дельфи равняется, на похапе Это многое объясняет |
| Автор: LSD 31.1.2012, 17:10 |
| http://habrahabr.ru/blogs/compilers/137336/ Я прям даже не знаю как на это реагировать |
| Автор: 502 31.1.2012, 17:26 | ||
бросай java`u |
| Автор: LSD 31.1.2012, 18:07 | ||
И куда бежать дельфи или JS? |
| Автор: 502 31.1.2012, 18:11 | ||||
ну так все, js уже нинужен
|
| Автор: kemiisto 31.1.2012, 18:36 | ||
Тут не исправить уже ничего. Господь, жги! |
| Автор: newbee 31.1.2012, 19:22 | ||
|
| Автор: LSD 1.2.2012, 12:29 | ||||||
Сразу вспоминается байка про цикл в программе управления космическим кораблем. Когда по ошибке вместо:
написал:
и аппарат не вышел на орбиту (это не про фобос-грусть если чо ). |
| Автор: yura13 1.2.2012, 13:44 | ||||||||
Вопрос был не о возможности сделать, а о производительности.
Ты не использование MVC приравниваешь в г0внокодингу, я тебе и говорю, что MVC не панацея, и его применение с г0внокодера разработчика не сделает.
Это и был сарказм. Это был саркастическая реакция на твой саркастический комплимент
Можешь так как на GWT. Люди давно пишут трансляторы в JS с разных ЯП, так как на JS писать ни один здравый разработчик не хочет. |
| Автор: Zloxa 1.2.2012, 15:43 | ||||
Потребовалось жавой мне с FTP выбрать файлы по маске и вдуть их. Гуглил, гуглил - http://www.nsftools.com/tips/JavaFtp.htm 
:facepalm |
| Автор: LSD 1.2.2012, 18:09 | ||||||||
А я за производительность и писал Нагрузка на тот же твиттер будет поболее чем на ваши серваки.
Я приравниваю не использование общепринятых шаблонов проектирования в базовой библиотеке языка, как дурной пример для новичков => провоцирование г0внокодинга.
Так и на дельфи нормальный разработчик писать не хочет
Чо-то ты фигню какую-то нагуглил. http://java-source.net/open-source/network-clients Что у тебя за запрос то был, что выдал такую фигню? |
| Автор: Zloxa 1.2.2012, 19:09 | ||||
Выставка велосипедов? Добавлено через 5 минут и 26 секунд
Нифига не фигня. Там четвертым пунктом предлагают Apache Commons Net™ library. |
| Автор: yura13 2.2.2012, 13:11 | ||||||||||
Ну у твиттера своя голова на плечах, у нас своя. Кроме того, можно предположить кучу причин, по которых твитер использует яву. И первая из них та, что если он был бы написан на делфи, такие как ты им бы принципиально не пользовались бы. А всё потому, что евангелисты из ораклу не зря свой хлеб едят. Промылили всем мозг уже этой явой, пока на яве не напишешь сообщества не поддержат. А нагрузку твиттеры вполне себе могут решить количеством серверов. Мы же не понимаем, зачем покупать лишнее железо и нанимать людей, которые будут всё это обслуживать.
Делфи имеет весьма солидный возраст, и модификация базовой библиотеки языка (VCL) это очень ответственная задача. Может в новых версиях с FireMonkey уже есть поддержка. Хотя можно начать с того, что Делфи всё же не ориентирован на веб, а на десктопе MVC/MVP как собаке 5 лапа.
Ну если нормальный - это тот, кому ораклы с майкрософтом мозг промыли, тогда да
Во-во. Только и занимаются тем что друг у друга передирают. Я уже умолчу как майкрософт делфи передрал с свой .нет
Я вот скачал по этой ссылке ФТП клиент на яве, jftp. Запустил его и задумался, начнут ли когда-то на яве делать нормальный, человеческий гуй???!!! |
| Автор: Stolzen 2.2.2012, 13:20 | ||
Да ладно |
| Автор: 502 2.2.2012, 13:21 | ||||
что за чушь, мне все ровно на чем написан skype`ом же пользуюсь
ЯП vs платформа |
| Автор: LSD 2.2.2012, 15:09 | ||||||||||||||
Публичные библиотеки не могут быть велосипедами
О котором ты скромно умолчал (наверное чтобы фейспалм получился убедительней). Хотя одно то, что они рекомендуют писать свой велосипед при наличии хороших готовых решений, уже многое говорит про этих ребят.
Отсыпь
Я же говорю:
Ты хоть википедию открой, когда твиттер появился, на чем он вначале был написан, на чем сейчас. Когда в конце концов оракл купил сан.
Сервер стоит как месячная зарплата хорошего разработчика (или дельфисты рабатают за еду? ). Проще, дешевле и перспективнее иметь хорошо масштабируемое приложение, чем заниматься микро оптимизацией, пытаясь получить 5% ускорение.
И это говорит человек у которого сервера под виндой работают  |
| Автор: Zloxa 2.2.2012, 16:52 | ||||||||
У меня батхерт случился до того, как я дошел до четвертого пункта. Четвертый пункт я вообще случайно обнаружил, когда уже излился и собирался закрыть страницу. Но ход мысли, мне кажется, вполне правильным. Сначала убедиться что типовое решение платформы не подходит, следом оценить трудозатраты по самостоятельной реализации необходимого функционала, следом поискать решение от вендора платформы, лишь затем искать решение сторонних производителей.
НЕ совсем понял. Если я предоставлю публичный доступ к своему велосипеду, он, что, в феррари превратится чтоле? 
Для меня тоже крайняя необходимость применения паттерна MVC для десктопа - сомнительна. Куда убедительнее было бы если бы вместо "да ладно" был бы срыв покровов или же феерическая расстановка точек какая-никакая. Для многих моих знакомых преход с делфи на свинг(он же реализует МВЦ, так ведь?) добавил много рутины, не предоставив при том очевидного профита.
В жавьей среде тоже не мало г0внокодеров. Отличие жавьего г0внокода от делфевого заключается, мне думается, лишь во впечатлениях, полученных в резльтате его производства. Делфевый г0внокод производится легко и не принужденно. А жавий средством неимоверных усилий и потуг, катарсис в результате - да, получается улетный. |
| Автор: lukas 2.2.2012, 17:51 |
| Ну кстати говоря Java не так уж плох (как язык), попробовал я недавно один веб-фреймворк по типу Django + Grails, называется Play! (http://www.playframework.org/), очень даже мощно и нет никаких сервелетов, компонентов и прочего нагромождения Java. |
| Автор: Stolzen 3.2.2012, 09:04 | ||
Если вы не видите суслика, это еще не значит, что его нет. |
| Автор: LSD 3.2.2012, 15:10 | ||||||||
Категорически не согласен: 1. Встроенное решение платформы. 2. Сторонняя библиотека. 3. Свой велосипед.
Я тебе в http://forum.vingrad.ru/forum/topic-165364.html отвечу
Их везде полно. Вопрос в том, что делается для того чтобы их было поменьше.
Традиционный вопрос: сколько у тебя аккопыта разработки на Java? |
| Автор: Zloxa 3.2.2012, 15:42 | ||
Нисколько. Любые попытки приобрести этот опыт ввергают меня в полное, кромешное уныние.  |
| Автор: lukas 3.2.2012, 16:27 | ||
У меня такая же ситуация, но с языком С++. Я изучал многие языки, какие-то поверхностно, какие-то более подробно, но только с++ оставил после себя один негатив. |
| Автор: yura13 3.2.2012, 18:50 | ||||||||||
Опытному разработчику с Делфи соскочить трудно, ему нужно видеть явный профит от перехода. В моём случае его не видно. Может, если бы я был одиноким фрилансером, и делал проекты для веб, то может бы и увидел. Но даже для веб в делфи есть решения, коллега выше приводил. Другое дело что заказов не будет, но причину я пояснил, евангелисты свой хлеб едят не зря.
В жавистов бытует мнение что гуй должен быть построен с кода, вот они и цепляются за всякие MVC/MVP. Хотя весь мир давно понял, что декоративный лучше. Если нужно приложение, в которого 100500 экранов + свистелки, перделки, дрочилки, плевалки, профит от MVP скорее всего будет. Если же вам всего лишь иногда скрыть некоторые контролы, MVP напрасная трата времени.
Я поверил тебе на слово, что он был написан на яве. То что он переехал с руби на яву и его производительность выросла, меня не удивляет. Но на Делфи можно добиться ещё большего.
Если бы 5%. У нас другие проценты Не знаю сколько там у вас сервера стоят с колько получает разработчик, но у нас сервер(железо + софт) строит в разы меньше чем месячная зп джуниора. А вот хороший админ стоит дороже чем средний разработчик. В общем вопрос не идёт про один сервер а о сотнях а может и тысячах.
Это скоро закончится. Вопрос в том, что пока другой возможности нет. |
| Автор: Stolzen 3.2.2012, 18:55 | ||
А тестируете вы как? Ручками тыкаете? И свинг не реализует MVC (ну за исключением некоторых компонентов), на нем можно делать точно такие же волшебные кнопки, как и на делфях. |
| Автор: LSD 6.2.2012, 16:07 | ||||||||
Нечто подобное я чувствую, когда приходится писать на PL/SQL
Вопрос в том, сколько придется положить сил, чтобы добиться этого "большего". В твитере решили что не оправдано много. Кстати, есть хоть один публично доступный сайт который бы работал на дельфи?
Например датацентр эпл http://www.washingtonpost.com/business/economy/cloud-centers-bring-high-tech-flash-but-not-many-jobs-to-beaten-down-towns/2011/11/08/gIQAccTQtN_story.html включая весь обслуживающий персонал и посменную работу. Так что или у вас админы такие, или администрирование виндовых серверов требует экстра затрат.
В смысле закончится? Дельфи умрет окончательно? |
| Автор: Zloxa 6.2.2012, 19:58 | ||||||
Ты не поверишь, но я тоже. Определенно я Формсам предпочту свинги. Потому что если жава это просто не удобна и рутинна, то Формсы это просто наиживейшее воплощение пи#деца.
Пример вот под руку подвернулся. Тривиальненькая задачка - В аппликушке продернуть процедурки из PL/SQL пакетика. Соответственно, его(пакетик) не плохо было бы врапнуть. Проникнувшись презрением старших товарищей к всяким велосипедам, стал гуглить, искать готовые решения. Нашел. JPublisher. Врапнул. Результат врапа процедуры, которая принимает в качестве параметра абонента, в результат отдает номер посылки и курсор с данными:
Так то я понимаю, что в жаве нет out параметров - дело житейское, наверное ведь из благих побуждений так было делано, но, простите, к чему, в результате это провоцирует?  И вот что теперь делать? Смириться? Переписать давно работающую серверную часть? Писать собственный враппер лапами? Писать врапер над врапером? Как тут не впасть в уныние? |
| Автор: lukas 6.2.2012, 20:56 | ||
Да я тоже не могу представить себе - как совместить MVC и GUI. Может есть удачные попытки?
Представляешь, в JavaScript их тоже нет. Решается относительно через то, что в Java и так объекты передаются по ссылке, если передаешь примитивный тип, то оборачивай его в объект. Например int -> new Integer(<value>) |
| Автор: LSD 7.2.2012, 14:11 | ||
В данном случае хорошее решение, это создать комплексный объект с результатами выполнения процедуры и возвращать его. Менее красивое но идеологически более близкое к out параметрам это AtomicReference. Вообще сама концепция out параметров это нечто очень странное, вроде это параметр функции, но на деле это ее результат. В PL/SQL это скорее костыли, чтобы не пугать DBA созданием объектов. |
| Автор: Zloxa 7.2.2012, 16:03 | ||||
Увы, сие есть суть "написать собственный велосипед" vs "воспользоватсья сторонней разарботкой". ((( Но это правда - да, для другой темы, на которую ты тут ссылался. JPublisher вроде как предлагает http://docs.oracle.com/cd/E11882_01/java.112/e10587/genclint.htm#JJPUB24140 возвращения out параметров, я еще не до конца с этим разобрался, но каждый из них, правда, уже оставил ощущение того самого, к чему, по твоему мнению, провоцирует делфи. Однако ж самое печальное в том, что курсор, возвращенный этим врапером, после выхода из процедуры, оказывается закрыт, и применение оставшихся двух методик, вероятно, приведет к тому же самому Увы, по подобному сценарию развивается почти все мое знакомство с жавой. 1) О! - есть офигенная фича, аккурат под задачу, вдохновенно пытаемся применить 2) Бля, идея хороша, но реализация ограничена. Только для сферических коней в вакууме, в реалии - нонюзефул! 3) Боремся с разочарованием, сожалеем о потраченном времени 4) Уныло велосипедируем, мимоходом г0внокодя.
Аут параметры реализованы не только в PL/SQL. И да, я с тобой согласен, что, возможно, их использование - не верх эстетики. Но погуглив я обнаружил, что в жаве существуют вполне устоявшиеся методики обхода этого ограничения платформы. Т.е. ограничение призванное упорядочить код провоцирует пораждение г0внокода. К чему я это все пишу? Прежде всего к тому, что то, чем ты объяснял не любовь к делфи, в не малой степени присуще и жаве. Возможно даже в большей степени - попытаюсь объяснить почему. 1) Г0внокод в большинстве случаев образуется в результате не понимания концептуальных основ. В современной жаве переплетаются множество концепций, и все они, с моей точки зрения, далеко не просты для понимания. 2) Г0внокод в ряде случаев возникает на стыке технологий. В самой жаве используется множество технологий, и не все друг с другом согласуются. Там где плохо стыкуется, образуется множество кастылей и заплаток 3) Зачастую г0внокод появляется в виду наличия ограничений платформы. Да, многие ее ограничения призваны уберечь разраба от производства г0внокода, но порой, эти ограничения обходить приходится. |
| Автор: LSD 7.2.2012, 19:14 | ||||||
"Велосипед vs сторонняя либа" это когда речь идет о неком универсальном решении, а не врапер над конкретной процедурой в твоей конкретной базе. Или ты пытаешься реализовать свой JPublisher с блекджеком и шлюхами?
Ребята попытались сделать универсальный код, так чтобы юзеру не пришлось самому ничего писать, но получилось хреново. http://static.springsource.org/spring/docs/current/spring-framework-reference/html/jdbc.html#jdbc-simple-jdbc-call-1 хорошая реализация от Спринга. Они не стали пытаться автоматически генерировать объект и автоматически заполнять его данными. Просто предоставили удобный способ сделать такой враппер.
1) Согласен. 2) Согласен частично. Если две популярные технологии плохо стыкуются между собой, то довольно скоро появляются библиотеки/тулы для решения этой проблемы. 3) В подавляющем большинстве случаев это говорит, или несоответствии целей и средств, или издержках legacy кода. Не могу припомнить таких проблем во вновь проектируемых системах. |
| Автор: Zloxa 7.2.2012, 19:36 | ||||
Т.е. врапать ручками десятки объектов и пакетов это не велосипедировать? Или врапать десятки объектов и пакетов универсальным решением, но пяток-другой перехирачивать кастомом это не г0внокодинг?
Спасибо большое, поковыряю. |
| Автор: Zloxa 8.2.2012, 10:51 | ||
Но это же совсем не то Да, это несколько более няшно нежели создавать коллабл стайтмент и биндить параметры по индексу, но суть все равно - та же. Все равно что позднее связывание, если этот термин тут применим. При изменении спецификации вызываемой процедуры мы получим ошибку во время исполнения, а не во время билда проекта. Это же никуда не годная практика |
| Автор: Stolzen 8.2.2012, 11:22 | ||
Используйте тогда ОРО (ORM) |
| Автор: AndreyIQ 8.2.2012, 11:26 |
 по моему содержание темы не соответствует названию |
| Автор: AndreyIQ 8.2.2012, 12:15 | ||
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html |
| Автор: 502 8.2.2012, 14:05 | ||
ага, программировать нам скоро на Logo |
| Автор: lukas 9.2.2012, 18:51 | ||
А С++ падает... |
| Автор: LSD 10.2.2012, 12:06 | ||||||
Выполнять руками большой объем работы который может быть автоматизирован это конечно г0внокодинг. Но тут надо понимать разницу между: простыми DTO генерируемыми JPublisher-ом и няшными самописными Business Objects, в которых все сделано по уму, инкапсуляция, целостность, бизнес логика и т.д. Перекладывать руками из процедуры в plain DTO смысла не много. А вот создавать Business Objects с которыми потом приложение может полноценно работать, это совсем другое.
С моей точки зрения - нет. Все инструменты имеют свои ограничения и иногда приходится изделие тщательно обработывать напильником Главное сделать так, чтобы не приходилось делать это после каждого билда
Удали из таблицы колонку получишь ошибку во время выполнения селекта. Ну научились же с этим как-то жить. Тут то же самое. |
| Автор: Zloxa 10.2.2012, 14:16 | ||||
В этом, пожалуй, заключается одно из основных преимуществ реализации логики работы с данными на стороне СУБД. Изменил спецификацию таблицы, все связанные объекты ревалидирутся, ошибки всплывают сразу и без юнит тестов. Привыкнумши к этому однажды, необходимость отвыкать обратно при переходе на другую платформу, сложно воспринимать иначе как откровенный дауншифт.
Я так полагаю подобный автоматически генерируемый код должен бы регенерироваться билд сценарием. Согласись, это было бы очень здорово. При изменении схемы данных, при изменении спецификации серверных процедур, ошибки вылазили бы еще на этапе сборки. Допиливание напильником полностью нивелирует данный профит. Тут допустимо только наращивание костылей сверху. В моем случае так, увы, не получится - полученный врапер не работоспособен в принципе. Он закрывает стайтмент внутри функции, что влечет за собой и закрытие возваращаемого курсора. Сейчас хочу попробовать врапнуть PL/SQL пакет другим PL/SQL пакетом который будет иметь спецификацию, которую JPublisher сможет врапнуть корректно. Пока - не получается. К слову, справедливости ради, надо отметить, что врапперы от http://www.allroundautomations.com/doapkg.html, таки тоже местами приходилось допиливать напильником. Помню, давно-давно, когда я еще писал на делфи, а не в песочницу, и о винграде вообще слыхом не слыхивал, в каком-то форуме, где обсуждались проблемы работы этого визарда, затесался какой-то жава девелолопер и с очень обидным пафосом и опломобм изрек бла-бла вроде "не стоит сравнивать велосипеды с иномарками, на велосипед, как ни крути, кондиционер не приспособишь". Сейчас, имея более близкое знакомство с технологиями Жавы нежели тогда, я бы уже не затаил бы обиды, а преисполнился бы иронией к автору этой сентеции. |
| Автор: Zloxa 10.2.2012, 14:54 | ||||
Гугл http://www.google.ru/search?aq=f&sourceid=chrome&ie=UTF-8&q=%D0%9E%D0%A0%D0%9E#q=OPO+ORM&hl=ru&prmd=imvns&ei=JQM1T9idAoyO4gTQ3dz1AQ&start=10&sa=N&bav=on.2,or.r_gc.r_pw.r_cp.,cf.osb&fp=3f4df5ca4036165c&biw=1280&bih=909. Не окажите ли услугу дать прямой линк?
Я не смог придумать как нарисовать линию тренда так, чтобы последний скачек можно было действительно назвать ростом.   В то же время жава имеет куда более очевидный тренд  В отличии от C#  здесь с-ка рост очевиден. Не могу не похвалить себя. Когда еще в 2002м году я пролистал первую книжку по C#, я пришел к заключению, мол все мы там будем. ( |
| Автор: Stolzen 10.2.2012, 16:24 | ||||
Да, конечно - http://en.wikipedia.org/wiki/Object-relational_mapping В джаве самый популярный это Hibernate, в дотнете есть NHibernate и какой-то майкросовтовский фреймворк со словом Entity в начале. Java да, тоже умрет когда-нибудь - что поделаешь. Однако ближайшие лет 10 джавистам беспокоиться не о чем. Вон, делфи - сколько лет уже пребывает в агонии, однако программисты до сих пор умудряются программировать на нем Добавлено через 54 секунды
А буквы в ОРО русские, кстати. Объектно-реляционное отображение это расшифровывается. |
| Автор: LSD 10.2.2012, 17:16 | ||||||||
Посмотри на проблему шире. Ты смотришь на свой маленький кусочек: СУБД+около СУБД-шная логика. У любой более менее сложной системы есть внешние системы, которые так же могут поменять API и твое приложение перестанет работать, или наоборот они перестанут работать. Конечно если все делать в СУБД, то таких проблем можно избежать (да и то не всегда, не забываем про динамический SQL). Но такое решение выглядит, мягко говоря странным, не говоря уж про его реализуемость.
Особенно когда у тебя несколько баз для разработки и на каждую патчи по своему графику накатываются
Ну тогда у С++ еще более печальная тенденция  Ты просто неправильно расцениваешь эти графики.
Это скорее индикатор модности языка, чем реальное положение на рынке. Добавлено через 4 минуты и 23 секунды http://habrahabr.ru/blogs/statistics/137926/ один рейтинг. |
| Автор: Stolzen 10.2.2012, 18:15 | ||
Хороший рейтинг, да. |
| Автор: Zloxa 10.2.2012, 18:23 | ||||||
Я не понял мысли которую ты пытался сейчас донести. Следует сознательно отказаться от идеи организовать жесткую связь на уровне исходного кода между модулями в гетерогенной системе в пользу динамической связи, потому что шит вездесущ и всяко может хаппенс?
Я подумал было, что это имя собственное ))
Будучи труЪ датабазником, когда я слышу это слово, я просто обязан уронить на пол кирпич |
| Автор: LSD 10.2.2012, 19:26 | ||
Не следует из гетерогенной системы, делать гомогенную только потому, что очень здорово когда при изменении схемы данных ошибки вылазят еще на этапе сборки. |
| Автор: Zloxa 11.2.2012, 13:45 | ||
А какие для этого еще нужны аргументы? Может и жесткую типизацию - нуеганафиг? В пользу динамической типизации? Фигли, юнит тестами все вытестим. |
| Автор: LSD 13.2.2012, 10:31 | ||
Спокуха, без фанатизма Разделение системы на несколько независимых, слабосвязанных компонент имеет свои преимущества и недостатки. На мой взгляд преимуществ выноса логики из СУБД гораздо больше, чем преимуществ от того, что схема данных валидируется на этапе компиляции. |
| Автор: Zloxa 13.2.2012, 10:54 | ||
Я высосал из пальца лишь http://forum.vingrad.ru/index.php?showtopic=229816&view=findpost&p=2245674. И все три - не про оракл. Для каждого из трех кейсов, в динамическом связывании преимуществ не вижу. |
| Автор: LSD 13.2.2012, 11:22 | ||
Динамической связывание, это следствие распределенности, а не самоцель. |
| Автор: Zloxa 13.2.2012, 11:41 | ||
провокация к г0внокодину детектед |
| Автор: LSD 13.2.2012, 11:56 | ||
У вас детектор сломался |
| Автор: Zloxa 13.2.2012, 12:09 | ||||
Это просто вы уж принюхались, не замечаете |
| Автор: LSD 13.2.2012, 12:52 | ||
Зато я замечаю как кое-кто предлагает пихать весь код в базу. Полностью игнорируя тот факт, что СУБД вообщем-то не особо рассчитана. |
| Автор: Zloxa 13.2.2012, 14:29 | ||
Окстись. Отнюдь ведь не весь. Только ту часть логики, которая оперирует непосредственно данными. Не смотря на то,что на PL/SQL способен получить http реквест и отдать http респонз, я не заблуждась в том, что размещение логики визуализации на стороне СУБД действительна уместна в общем, не исключительном случае. Не понятно почему вы так держитесь за свои заблуждения, что логика работы с данными обязана быть вынесена за пределы базы данных. Ведь лопатить данные жавой получается на столько же коряво, как и формировать хттпреспонз из PL/SQL. Добавлено через 3 минуты и 12 секунд Вот многие мои знакомые делфисты, кстати, чураются реализовывать логику работы с данными средствами делфи. И кто, спрашивается, после этого овнокодер? |
| Автор: LSD 13.2.2012, 14:59 | ||||||
Что значит оперирует непосредственно данными? Я думал что 90% кода как раз занимаются тем что оперируют данными, а оставшийся код обслуживает эти 90%.
Я считаю, что логика по возможности должна быть в одном месте. Если у вас логика настолько простая, что она спокойно реализуется на PL/SQL, пусть будет в базе. Но только чтобы вся, а не размазывалась тонким слоем по базе, среднему уровню и клиенту. Добавлено через 1 минуту и 15 секунд
И кстати, я тоже чураюсь реализовывать логику работы с данными средствами дельфи Добавлено через 9 минут и 45 секунд Вспомнил историю из жизни: есть у нас некая система которая хранит и обрабатывает некие данные. Мы ей шлем запрос сделай мне то-то и то-то, система проверяет входные данные и делает что велено. Все проверки сделаны тригерами. А тут клиентам захотелось странного, чтобы проверять пользовательский ввод до того как он нажал Submit, и показывать сообщение об ошибке. Будь эта логика не в СУБД мы бы это легко реализовали, а так жди пока они все вытащат этот код из тригеров. |
| Автор: Zloxa 13.2.2012, 16:24 | ||||
Да, у нас логика на столько простая, что спокойно реализуется на PL/SQL. И вынос на выделенный сервер приложений ее многократ усложнит. И тогда та же логика станет действительно сложной. Сложной станет как в разработке, так и при эксплуатации. Возьму простой пример(логику которого проще объяснить). Модуль расчета скорости реализации товара. Исходные данные - преагрегированные данные об остатке товара на размещении(по магазину) на начало месяца, преаггрегированная движуха по товару на размещении в течении дня, список товаров на размещении, по которым должны быть посчитаны скорости. Расчет для товара на размещении выполняется одним запросом. Запрос сложный. Разматывает остаток по товару на год назад, исключает из результата т.н. аномальные периоды, когда товар не продавался в течении достаточного для группы оборачиваемости товара промежутка времени(например товар был украден, а по системе числился), из оставшегося, выбирает непрерывный, наиболее близкий к текущей дате, трехнедельный диапазон дат, когда товар имелся в наличии более N дней, при этом дни, когда товар ушел в ноль или вышел из нуля, считаются как полудни и, в конце концов, считает среднее за день количество штук, проданных в этом трехнедельном диапазоне. Реализовать такой алгоритм иттеративными средствами, мне думается, многократ сложнее нежели декларативными, в 150 строк врядли уместишь. В один обход курсора все не посчитаешь, пришлось бы либо возвраты обеспечивать, либо рекурсию привлекать. Все остальное в этом модуле - обвяз. Принять по AQ XML со списком товар+размещение, по которым должен произвестись расчет, посчитать для каждого товара скорость, упаковать в XML результат+сопутствующую статистику, отдать результат тем же AQ.
Менее пятисот строк. Глянул, из них не менее ста - коментарии и закоментированные фрагменты кода, так что - все четыреста. Действительно все достаточно просто. Но, боюсь, реализация того же самого функционала средствами жавы оказалась бы куда менее проста и лаконична. А елси бы для доступа к данным использовался ОРМ, боюсь это было бы еще и неадекватно ресурсоемко. |
| Автор: LSD 13.2.2012, 16:27 | ||
Надеюсь дельфисты поняли |
| Автор: k0rvin 13.2.2012, 16:29 | ||
Потому что делфи банально неудобен для этого и слишком негибок, чтобы это можно было удобно реализовать его же средствами. Вот на рельсах, например, логика удобно пишется. |
| Автор: LSD 13.2.2012, 16:40 | ||
И что? Из Java нельзя выполнить этот запрос? Или я где-то утверждал, что нельзя использовать SQL там где это нужно/удобно? |
| Автор: Zloxa 13.2.2012, 16:48 | ||||
Я тебе как-то уже приводил историю из жизни, когда реализуя логику на стороне приложения, две разные команды ее реализовали несколько по разному и мы, в результате, получили сохраненные в одной структуре документы, которые оказались по разному отражены в регистрах остатков. Что же касается кода в триггерах, то радуйтесь что у вас он есть. Радуйтесь, что как бы вы не накосячили со своим контроллем ввода, логику стороннего приложения(не отключая, конечно триггеров), вы не закривите. У нас вон, есть на жаве писаный Oracle RPM(Retail Price Management). И бизнес нас просит подлить туда правила ценообразования для 20 магазинов о 150тыщ наименований товаров в каждом. А мы не можем. Исходный код закрыт, логика не описана, если хибер сочтет что целостность данных нарушена, RPM просто перестает работать. Понять чего ему не хватает можно только трассировкой, которая очень усложняется тем, что используется пулл коннектов. Бизнесу придется ручками эти данные херачить. Добавлено @ 16:52
Можно. Но из PL/SQL выполнять этот запрос - удобнее. Мне кажется правильным было бы - завернуть этот запрос в пакетик и дернуть его из жавы. Но это уже размазывание логики. Нет? Но и опять же, в чем профит тут тогда от использования жавы? Где пресловутая абстракция от БД? |
| Автор: LSD 13.2.2012, 18:22 | ||||||||||
Если кратко, то твой рассказ звучит так: у нас есть древнее глючное ПО, которое мы костылим с помощью ХХХ. А потому ХХХ это очень хорошая штука, и все новые проекты тоже должны его использовать.
Чем?
Абстракция будет если использовать простой select без специфичных фишек оракла. |
| Автор: Zloxa 13.2.2012, 19:12 | ||||||||
Фиксацией связи с объектами схемы. Синтаксическим анализом на этапе компиляции, а не исполнения. Возможностью влиять на план запроса без пересборки приложения. Ну и скажи, в общем - какая разница, будет ли запрос сохранен в строке, в ресурсе проекта или же в схеме данных, скажем вьюхой или хранимкой. Суть то остается той же. Логика реализуется средствами внешней системы, сиречь размазана.
Все равно не будет. Один и тот же стейтмент, дающий один и тот же результат в режиме монопольного доступа к данным, в конкурентном режиме на версионниках и блокировочниках будет выполняться по разному и может дать даже разные результаты. Если мы подобный запрос пустим на блокировочнике вроде MS SQL в режиме изоляции read commited, на время исполнения он блокирует регистры остатков. Прочие приложения, двигающие по остаткам - встанут колом. Да и сам запрос может встать на блокировке. Могут случиться взаимные блокировки. Результат будет получен согласованным на момент окончания работы стейтмета. А оракл никого не заблокирует, и сам на блокировке не встанет. Результат будет согласованным на момент начала работы стейтмента. Для версионников и блокировочников таки нужен несколько разный подход при решении однотипных задач. Если мы хотим абстрагироваться от платформы БД, нам придется свести свое взаимодействие с ней до очень примитивного уровня и серьезно так навелосипедировать.
Не, скорее так - у нас есть дорогое глючное ПО, реализованное средствами XXX, которое требует невероятно дорогих компетенцией при поддержке на эксплуатации. И потому не надо делать мифа из того, что XXX это само по себе хорошая штука, его использование не уберегает от гуано на выходе. Ни использование модных технологий и шаблонов проектирования не могут являться препятствием для г0внотечи. Они призваны лишь перебить запах и отвлечь внимание, ввести в заблуждение переведя овнокодинг в категорию искусства.
Я тоже так считаю. И лучше чем база - место сложно придумать. И пофиг будет ли писать в базу дерзкий студент жавапис, матерый ли, но мудаковатый делфист, харизматичный ли индус-формсист, или же дешевый суппортер, с базовыми навыками sql, получивший заявку "удалить накладную" на сервисдеск, от своевременного исполнения которой зависит его KPI. Никто из них не должен иметь возможность закривить данные, нарушить логику приложения, а суппортер таки должен получить бонусную часть своей и без того крохотной зарплаты, начисляемой по KPI. |
| Автор: LSD 14.2.2012, 15:51 | ||||||||
Никуда эти проблемы не деваются. Раньше у тебя в строке лежал текст запроса, а теперь текст вызова процедуры. Понадобится еще один параметр в where добавить, переписываем процедуру, и все сигнатура изменилась будет ошибка во времени исполнения.
1. Ты слишком преувеличиваешь проблему взаимных блокировок. Я вот за все время ни разу не сталкивался с подобными проблемами. 2. Абстрагирование это не поменять настройки конекта, и опа мы уже работаем с MS SQL вместо Оракла. Это возможность портировать приложение с Оракла на MS SQL с минимальными усилиями. А если вам хочется полной независимости от СУБД, то тут конечно придется свести взаимодействие к примитивным селектам.
Даже и не знаю, где ты такое увидел. Есть хорошие общепринятые практики при разработке ПО, они не гарантируют что у тебя получится хороший продукт, но значительно этому способствуют. А их неиспользование наоборот. Аналогия со здоровым образом жизни, не гарантирует что ты не будешь болеть, но сильно уменьшает вероятность многих болезней.
Ты слишком базоориентирован Ты исходишь из того, что все крутится вокруг базы и все должны на нее молиться. А жизнь, то она разнообразнее У нас есть система персистит данные в memory mapped file, и потом отдельный процесс неспешно разгребает это все и сохраняет в базу. В работе системы база не участвует, она нужна для архива. Есть другая система которая представляет из себя большой Oracle Coherence кластер, в который сохраняются данные и в нем же происходит агрегации и другие вычисления, база тут тоже задействована исключительно для архивных функций. |
| Автор: Zloxa 14.2.2012, 17:35 | ||||||||||
Таки вероятность того, что изменится спецификация интерфейсной процедуры меньше, чем вероятность, что изменятся объекты схемы, с этой интерфейсной процедурой связанные. На то она и интерфейсная. И тем полезнее было бы иметь возможность генерировать врапперы для таких процедур. Иной раз, глядишь, разраб пересмотрит модификацию схемы данных, если увидит, что он не сможет в этом случае поддержать взаимодействие с уже написанным клиентом. Если мы интегрируемая с внешней системой средствами XML, мы ведь имеем ту же самую картинку. Если на той стороне изменится спецификация обмена, нам будет предоставлен измененный XSD, по которому завсегда мы можем регенернуть врапер и все места, где нам следует что-то предпринять тут же разметятся в коде красными выделениями. Почему желать подобного от связки с БД, ты находишь странным?
Я в данный момент в первую очередь думал о блокировке по чтению. В блокировочниках это бич. Нельзя снимать тяжелые аналитические отчеты с оперативно изменяемых данных. Только в режиме грязных чтений, рискуя получить не согласованный результат. Важно каковы требования к чистоте данных. Может статься, решение использования блокировочника против версионника, пожет потребовать и радикальной смены архитектуры. О том что запрос может рубануться по дедлоку упомянул потому лишь, что между делом об этом подумалось. Впрочем, оракл тоже может рубануть запрос по snapshot too old.
Я вот сталкиваюсь постоянно. Ко мне интерактивно поступают данные об операциях из ~трехсот розничных магазинов, все это молотится параллельно, если пренебрежительно относиться к стратегии блокирования, дедлоки не избежны. Да и бэкоффис у нас работает, как правило, в длинной транзакции, тоже приходится об этом постоянно думать.
Рассогласованную базу вернуть в согласованное состояние многократ сложнее нежели исправить ошибку в коде, приводящую к ее рассоглаованию. Порой - вообще не возможно, если отсутствует не искаженный источник. Потерянные или же искаженные алгоритмы восстановить оказывается куда проще. Понятно что ценность данных форумного движка, или даже витрины интернет магазина - не велика, требования к качеству таких данных смехотворны. А вот ценность данных, на основе которых формируется финансовая отчетность, на основании которых принимаются управленческие решения - крайне велика. Я помню времена, когда мы пускали новую учетную систему. Данные оказались искажены и была утеряна связь между обобщенными кодами товара, на которых делается заказ поставщикам и индивидуальных кодов, на которых ведется учет в магазинах. В результате к нам на склады в очередь выстраивались фуры с товаром, склады были переполнены, нанимали таджиков на разгрузку, при этом магазинные полки были пустые. Это были безумные денежные потери. И если бы проблема была вызвана не верно работающиим алгоритмом, можно было бы дернуть данные в эксель или матлаб, посчитать чо как надо, и принять верное управленческое решение вручную, мимо системы. А если данные дерьмо - на чем принимать решение? Это уже потеря бизнеса. Как тут не замолиться вокруг базы?
Я не отрицаю, что существуют случаи, когда решение на жаве оказывается предпочтительнее связки Delphi + PL/SQL. Но я работаю в этой связке и смотрю с этой колокольни. Мое признание вовсе не означает что в результате замены этой связки на жаву, даже при условии следованиям паттерннам и бестпрактикам, будет получен сколь нибудь ощутимый профит. На данном этапе своего личностного развития, я скорее ожидаю обратного. Причем по той самой причине, которую ты озвучил, как причину нелюбви к делфи. Жава, вероятно от избыточной гибкости, для придания общей конструкции определенной прочности, требует следования паттернам и практикам, вынуждая тем самым отказ от использования смежных технологий, способных решать задачи более эффективно, провоцируя тем самым велосипедирование и овнокодинг. |
| Автор: LSD 15.2.2012, 18:53 | ||||||||||||
А вьюхи вам кто не велит использовать?
Как бы предполагается, что разработчик модифицирует БД не потому, что его левая нога захотела, а потому что перед ним появилась некая задача реализация которой требует подобную модификацию. И он обсуждает предполагаемые изменения со всеми кто использует эту базу.
С тем же JSON-ом такой лафы (в виде XSD) нет. Однако многие веб сервисы его используют, и ничего как-то живут. Да XSD не панацея, если тебя не информировали вовремя что XSD изменился, и надо использовать новую версию. А еще есть проблема старых клиентов. Я вообще не представляю как вы у себя можете позволить делать breaking change при наличии 300 филиалов.
Сам Оракл рекомендует разносить по разным базам OLTP и аналитику. Так что достаточно просто их разнести. На OLTP быстрые запросы и много DML, на аналитике длинные запросы и минимум DML-я.
1. При этом ты как-то игнорируешь тот факт, что ошибка приводящая к рассогласованию может с таким же успехом быть и в коде ХП/триггеров. 2. Не надо путать бизнес логику и sanity checks для поддержания целостности. Sanity checks должны в обязательном порядке присутствовать в базе. А логику от туда лучше вынести.
Я про твою конкретную систему вообще не говорил. Я про нее ничего не знаю. |
| Автор: AlekXL 15.2.2012, 23:50 |
| http://www.itwriting.com/blog/5423-cross-platform-windows-and-mac-lifts-delphi-sales-by-54.html только я лично FM не люблю. Не проще ли было сделать порт VCL? Пока под FM не появятся VirtualTreeView,THTML и др либы подобной сложности, не стоит даже и смотреть в ее сторону, имхо. Сила Д. в сверхпродуктивных, feature-rich и быстрых контролах (что даже на доднете трудно повторить), а не в раскрашенных кнопках. Но сам факт "поддержки" Mac OSX немного сбивает спесь с евангелистов и ###кодеров, от кривизны рук подавшихся в веб-разработку А лазарь под вин уже не внушает отвращения, между прочим... |
| Автор: Zloxa 16.2.2012, 02:01 | ||||||||||||||||
В чем, скажи, принципиальная разница - дергать интерфейсную вьюху, созданную специально для приложения или же процедуру? С вьюхами мороки больше. Основная проблема - применение критериев отбора. Оракл не поддерживает параметризированных вьюх, а некоторые предикаты лучше прописать глубоко-глубоко в подзапросе. http://docs.oracle.com/cd/E11882_01/server.112/e16638/optimops.htm#PFGRF94586 вещь конечно опупенная, но не идеальная, спасает далеко не всегда. Опять же, от того, какие предикаты будут применены и как - может меняться и план запроса. В некоторых случаях, в зависимости от значения параметров, запрос не плохо было бы переформулировать. А если его еще и хинтовать придется... согласись эти вещи далеки от компетенций жава программиста, их лучше оставить на стороне базы данных.
Вообще это как раз таки офигенный тезис в пользу организации интеграции средствами интерфейсных объектов схемы. По связанным объектам, ты сразу видишь кто и как использует объекты, которые ты желаешь изменить и можешь проанализировать, а закривишь ли ты кого. В результате такого анализа можно очень резко сократить список участников процесса и лист согласования дизайна.
На "как-то" будем ориентироваться? Ну так и на формсах  люди тоже как-то пишут.
Я согласен. Но я ведь рассматривал не эту ситуацию, я рассматривал ситуацию, когда меня информировли, и что мне очень много времени сэкономит, если я по измененной спецификации регенерну обертку к этому XML, и тут же в коде получу список мест, где надо подправить код.
Узнал новое слово У нас интеграция с филиалами не на прямую - через файлобмен. Филиал, в высокой степени автономен. Регламент допускает какое-то время задержки в обмене. Возможно я тебя ввел в заблуждение, используя слово "интерактивно". Не понмю, что я под ним подразумевал. Вероятно я имел в виду "интенсивно". Но вообще я не помню что мы делали, когда у нас менялась спецификация интерфейсов. Ровно как и не помню, когда в последний раз такое случалось. Как то выкручивались.
Так то оно так.. но иногда бывает когда OLTP чуть больше чем OLTP, но далеко не DWH и выносить аналитику в одельную базу, организовывать ETL процессы как то не адекватно накладно.
Нисколь. Я не рассматривал причин, я лишь объяснял свою базоцентричность. Что же касается причин, основная причина рассогласования данных - таки обход логики. Пройти мимо логики, реализованной в базе - тяжелее всего. А задействовать ее, в свою очередь - проще всего.
Еще одно новое слово Расчет остатков (запасов) это бизнес логика? В некоторой степени это системная логика - как бы преаггрегация данных бизнес-транзакций. Но на основе этих данных принимаются бизнес-значимые решения. То же самое, скажем, рейтинг прайслистов поставщиков. Тоже своего рода преаггегация. Прайслист - да, как бы бизнесс-объект. А вот рейтинг, уже как бы системный. Мне не нравится слово бизнес-логика. Я не совсем его понимаю. Блин вот серьезно, претит мне идея считать такие вещи как остатки за пределами базы. Очень претит. |
| Автор: lukas 16.2.2012, 11:52 |
| Люди о чем вы спорите? |
| Автор: Zloxa 16.2.2012, 12:21 | ||
О религиозных воззрениях же, епрст  |
| Автор: LSD 16.2.2012, 15:48 | ||||||||||||
Какие вопросы тебя волнуют в 3 часа ночи Я не вижу большой разницы что использовать для сокрытия структуры базы: процедуры или вьюхи.
Для этих целей у нас есть DBA/DBD мы приходим к ним с запросами которые медленно работают и спрашиваем "какого х... валера?".
По связным объектам ты видишь только связи внутри БД. Из этих связей совершенно неясен публичный API базы. Ну и самое главное изменение даже не публичных API может иметь side эффект на публичных.
Просто посмотрим как там решаются эти проблемы
А как ты предполагаешь "пройти мимо логики" реализованной в среднем уровне? Как будто клиентам кто-то дает логин/пароль в базу и позволяет внешние соединения с базой.
Да. И sanity checks это тоже часть бизнес логики. Но ее дублирование мы допускаем, ради высших целей |
| Автор: lukas 17.2.2012, 13:37 |
| Так, я выбираю MongoDB, их девиз "никакой логики в базе данных", база данных должна лишь хранить информацию и умело ее искать и доставать. Вся логика должна быть в коде. |
| Автор: 502 17.2.2012, 14:00 | ||
а что в mongo уже нельзя писать функции? o_O |
| Автор: Zloxa 17.2.2012, 14:09 | ||
В некоторых случаях, это само по себе уже львиная часть логики |
| Автор: LSD 5.3.2012, 18:18 |
| Чой-то дискуссия подзатихла, надо подкинуть аргументов на вентилятор Стало интересно а какие CI сервера для дельфей есть. Кроме Automated Build Studio, ничего не нашел. С тулами для сборки ситуация еще более кислая, не нашел ни одной. |
| Автор: Stolzen 6.3.2012, 15:32 |
| http://dou.ua/lenta/articles/chtoby-razrabotchiki-ne-begali-ili-delphi-navsegda/ |
| Автор: LSD 7.3.2012, 10:50 | ||||
Каменты доставляют:
|
| Автор: Akella 14.3.2012, 14:42 | ||
адрес не помню, но недавно на нём был, как только вспомню, скину сюда Добавлено через 3 минуты и 23 секунды На дельфи лучше писать веб-приложение, а не веб-сайт. Добавлено через 6 минут и 36 секунд Вот этот сайт http://www.delphifaq.ru/ |
| Автор: LSD 14.3.2012, 15:27 | ||||
Слог то какой:
Добавлено через 5 минут и 41 секунду У-у-у-у как все запущено, ребята даже 404 нормально не отрабатывают. http://www.delphifaq.ru/abc/ - ошибка нормально обрабатывается http://www.delphifaq.ru/abc - так нет. |
| Автор: Akella 15.3.2012, 10:32 |
| и чё? |
| Автор: Zloxa 15.3.2012, 11:08 |
| Akella, ну согласись, ведь это несколько абсурдно - писать собственный веб сервер, чтобы замутить сайт. LSD, ну согласись, ведь это несколько абусрдно - говорить что молоток плох тем, что гвозди доставать удобнее пассатижами. Что же касатеся CI, я канешна понимаю, что это все ниэпически круто. Но в реалии мне не доводилось участвовать в проектах, где это было край необходимо. В моих реалиях я херачу серверную часть, реализую прикладную логику на датабазе, выставляю апи, другой человек на делфях рисует гуевую морду. Раньше еще был человечек, который на жаве рисовал вебовую морду. Но по юзабилити веб приложение всегда уступало гуевому, и в конце концов, им никто не пользовался, а трудозатраты на веб приложение существенно превышали трудозатраты на гуевую морду, поэтому от этой практики мы в конце концов отказались. |
| Автор: Akella 15.3.2012, 11:17 | ||
Ну да, согласен. Но дельфи позволяет писать как StandAlone апликации, так и примочку для апача/ISS, разве нет? |
| Автор: LSD 15.3.2012, 11:33 | ||||||
Вебсервер - любительская поделка которая максимум тянет на proof of concept.
Не понял к чему относится твой комментарий.
А мне вот наоборот, доводилось участвовать в проектах в которых вначале не было CI, а потом мы его внедрили. И могу сказать, что польза от него была ощутимая. И? |
| Автор: Akella 15.3.2012, 11:44 | ||
Вот-вот. Я админю, так сказать, большую фирму. У нас есть своя программа с базой. Когда-то я для них писал это всё на дельфи с огнептичкой. А 2,5 года назад учредитель захотел переехать в веб. Выбирал я между дотнетом и пхп. В итоге пришел к пхп из-за сравнительной дешевизны. Хотелось кроссбраузерности и кроссплатформенности. Но не тут-то было! Оказалось, что даже кроссбраузерность не всегда легко дается. Так и порешили, и перешли полностью в веб: пхп + мускуль. И всё это было из-за того, что канал связи в центральном офисе и на филиалах был не ахти какой. Да, с функциональностью и дизайном проиграли. Ужасно проиграли. Может потому что разработчики оказались не очень компетентные, может потому что инструменты программирования были хуже. Не знаю. Но теперь я жалею и думаю, что можно было избежать этого, оставить приложение как есть и продолжать его использолвать и дописывать. Просто базу перенести на хостинг с firebird. Пользователям новое веб-приложение оказалось сильно непривычное, неудобное, они потеряли много удобства в своей работе, сильно плевались и фукали на новую программу. Мало того, мы нормально можем использовать только Firefox, т.к. код (JavaScript) нормально работает только в Firefox, а потом уже, если есть время, то может быть допиливают для остальных браузеров, хотя сильно этим не занимаются. Как всегда нет времни и особого желания. И я вот свою программу тоже хочу перекинуть в веб. Вернее только базу в веб, жаль что хостингов с firebird можно по пальцам пересчитать. Так что можно сейчас смело писать веб-приложения на дельфи, а лучше на firemonkey, т.к. firemonkey предоставляет кроссплатформенность. Но, почему-то много примеров для 3D программирования и графики, и очень мало для LiveBindings и баз данных. Нет документации, особенно на русском :( Я прошу не путать веб-приложения и веб-сайты. |
| Автор: Zloxa 15.3.2012, 11:58 | ||||||
Фиг его знает, товарищ майор. :unnw Если говорить об ISS, там сам бох велел ASP зюзать. Преимуществ у делфи тут не вижу. Если говорить об апаче, апач кроссплатформенен, здесь бы жава была бы очень уместа. Я вообще скептически отношусь к современной разработке под веб. Не смотря на высокую востребованность и безусловную перспективность, пророка в этом отечестве пока не объявилось. Все нынесуществующие платформы обрекают разработчика акцентироваться более на презентативном аспекте нежели на прикладном. Очень уж сильно много рутины при визуализации. Уверен, когда-нибудь, кто-нибудь и сможет предложить что-нибудь вразумительное, что покроет ту фору, которая сейчас есть у гуя перед вебом. И это что-нибудь, мне кажется, будет радикально отличаться от того, что мы видим сейчас. А потому мне все нынешние технологии, платформы, фреймворки представляются не иначе как недоделки какие-то.
К тому, что не высокая привлекательность инструментария для использования в веб разработке, в целом не характеризует инструментарий.
Ваш же проект был на жаве - так? И без этих кастылей вам было плохо - так? А нам без этих кастылей прекрасно живется. Мы даже слова такие из википедии вычитываем, на столько нас не парят те проблемы, которые вы имеете на своей платформе. |
| Автор: LSD 15.3.2012, 13:01 | ||||||
Так весь вопрос в том, для чего хорошо подходит дельфи кроме "клепания формочек к базам"? ТС распинался про то какой у них крутой вебсервер получился, но с пруфами как-то не срослось.
Повторяю еще раз: это элемент культуры разработки. Вот у вас счастливых дельфистов, сколько разработчиков и сколько тестировщиков? Что будет в случае 10 минутного простоя системы?
Это потому, что тебе не приходилось обновлять клиента для сотни тысяч внешних клиентов. |
| Автор: Zloxa 15.3.2012, 15:17 | ||||
Так то хром как то умудряется обновляться легко и не принужденно, не заметно для пользователя. Вопрос, я так понимаю, лишь кривизны рук. Я не говорю что веб бесперспективняк. Я лишь говорю, что птенец еще не вылупился и еще даже не понятно что там вобще проклевывается. Рано еще это чудо называть курицей. И использовать его там, где нужны лишь формочки к базам (80% задач корпоративного сектора), получается весьма убого. Но жить с этим, как-то уже можно и сейчас. И живут как-то. Но не уверен, что к этому "как-то" надо осознанно стремиться. Скорее это издержки, которые обуславливают профит совсем в других вещах. И далеко не везде этот профит может быть получен. И далеко не везде эти издержки учитываются при принятии решения, решение нередко принимается под влиянием веяний времени. Мне кажется случай, описанный Акеллой достаточно характерен. Хотели поинновационнее, а в результате всем поплохело.
Для того чтобы 10минутный простой не приводил к пи#де и потере бизнеса, мы строим системы с высокой степенью автономности узлов. Возможно да, решения получаются несколько дороже и в разработке и в обслуживании. Но наши магазины будут продавать, даже если наш датацентр взорвется. Сотен тыщ клиентов у нас нет. У нас есть триста магазинов в Москве и области. В каждом магазине ведется учет делфевой самопиской. Одна инсталляция на магазин, около десятка рабочих мест. Где-то больше - где-то меньше. Поддержкой трехсот инсталляций этой софтины занимаются 2,5 человека. Они отвечают в том числе и за расстановку версий. Расстановка производится вручную. Но не сказал бы я, что расстановка это основное их занятие. Как процесс организован в других наших подразделениях, в других регионах, на других учетных системах - не уверен, но кажется дела обстоят схожим образом. Разработка этой самописки ведется на стороне, но, думаю, не ошибусь, если скажу что разработчиков 1,5-2 человека. Тестированием занимаются и они на своей стороне своими двумя человеками и мы на своей - своими двумя с половиной. Выбор правильного инструментария качественно снижает количество задействованного ресурса (Тут троллю, конечно. У нас сейчас на жаве новую нескучную POS пишут. Не знаю сколько у них разарботчиков. Я общаюсь только с одним. Но подручные у него помоему есть, так что можно считать что те же 1,5 - 2 человека)В течении достаточно длительного времени у нас муссировалась тема "облегченной" POS. POS которая не ведет учет, регистриует лишь факты продаж, а приходно/расходные операции оформляются через веб. От идеи пришлось в конце концов отказаться. Мы достаточно жестко ограничены законодательством в ценообразовании, нам нужен строгий партионный учет, который вписать в эту концепцию нам не удалось. Возможно в банкинге дела обстоят как-то сильно иначе и требования централизации там более насущны. Не знаю. Помню подглядывал в монитор теточки в юниаструме. Пяток лет назад она забивала мои анкетные данные через делфевую формочку на удаленном рабочем столе(кажись цитриксом). Пару же лет назад, уже через вебморду. В обоих случаях пришлось подождать - были какие-то затыки с коннектом. Но юниаструм фиг с ним, там клиентская проходимость низкая. Теточки по большей части чаи гоняют. А вот в сбере бы за это "немножко подождать" сотрудниц офиса линчевала бы очередь негодующих клиентов. В Сбере в каждом отделении стоит автономная система - не знаешь? Или они через веб формы работают? Мне кажется - у них филиалы весьма автономны. |
| Автор: LSD 15.3.2012, 17:45 | ||||
Ну во первых надо заметить что хром для гугла это приложение №1 (как минимум на десктопах). Так что труда туда вбухивается ого-го сколько. А вот та же Пикасса например не обновляется с такой же легкостью как это делает хром, как думаешь почему? Во вторых идея хранить код в профиле пользователя явно противоречит тому для чего эта папка создавалась.
А кто говорил, что веб интерфейс это серебрянная пуля? Достаточно очевидно, что плохие каналы связи, это первый признак того, что веб гуй тут не подходит. Что касается обработки больших объемов данных, у нас в соседнем проекте ребята делали систему для аналитики на Flex+Java Server. И ничего система нормально работала, на тормоза никто не жаловался. Справедливости ради надо отметить, что она использовалась только в интранете, так что сетевые задержки были минимальны. Вообще говоря: пользователь больше пары тысяч строк глазами все равно не просмотрит, если данных больше значит нужна фильтрация, группировка или еще как реорганизовывать отображение. На остальное отвечу позже. |
| Автор: Zloxa 15.3.2012, 19:51 | ||
Так то я не столько о каналах связи говорил, сколько о сложностях реализации презентативного слоя. И тут не только верстка. Тут еще кастыльность связи между набором данных и его визуальным отражением. Нечеткое определение сессии, невозможность использования длинных транзакций... Дофига там проблем, не присущих классическим, толстым, клиентам. И, если уж на то пошло, не плохо бы вспомнить, что изначально вся эта веб байда гордо именовалась "тонкий клиент" и предназначалась для использования как раз таки на малостабильных каналах связи Сейчас иной толстый клиент куда тоньший канал требует ;)) |
| Автор: serger 20.3.2012, 18:30 | ||
| Delphi мне понравился... Я балдел от него... Пока не пришлось переставлять софт на машине. Потом каждый раз при необходимости установки и настройки делфей, меня от них тошнило всё больше и больше... Ну и ещё, было дело, уже когда я сильно их не любил, надо было разобраться с delphi кодом. Очень понравилось выяснять, какие свойства в каком компоненте описаны, как установлены и откуда в коде берётся определённое поведение (а это ок-ся компонент в форму закинут и там установлены определённые свойства). Кстати, с net щас похожие проблемы (недавно надо было разобраться с кодом). Да и много где начинают похожее городить.. Ладно хоть описание форм теперь в xml - для контроля версий лучше. А сам язык нормальный - есть конечно загибоны (var... interface), но они терпимы... зы
Веб сложен, потому что каждому охота вы*** со своим дизайном... Были тут умники - приходили пытались научить, как сэкономить на вёрстке... ;) Ну а формочки в вебе уже давно неплохо так клепаются, в том же grails. |
| Автор: LSD 21.3.2012, 12:51 | ||||||
Это не заслуга Дельфи и не ваша. Просто таков ваш бизнес, что отдельные элементы могут достаточно долго работать в автономном режиме. А есть бизнес где это не возможно. Я не представляю как организовать тот же трейдинг без централизации, так чтобы каждый трейдер торговал сам по себе.
Веб гуй может быть очень отзывчивым особенно если использовать RIA. Могут ли отделения банка работать в автономном режиме, я не очень в курсе. Банковский день надо закрывать централизованно, так что связь должна быть, но вот допустимо ли ее пропадание в середине для - не знаю.
Есть куча библиотек которые облегчают эту задачу. Тот же грид на ExtJS реализуется достаточно просто, и при этом он весьма отзывчив. Посмотри их http://www.sencha.com/products/extjs/examples/. При использовании Flex можно вообще использовать мышкокликательное программирование так любимое Дельфистами. Хотя по мере набора опыта, все Flex программисты которых я знаю, перешли на написание гуя руками. Думаю это все от недостатка опыта в разработке веб приложений. |
| Автор: Zloxa 21.3.2012, 13:34 | ||||
Его я в том числе и имел в виду, когда говорил о недовылупленности. Да - тема офигенна. Но фора традиционного гуя пока еще далеко не покрыта. Делфевые, доднетные гриды и умеет больше и допиливаются проще.
У RIA, если я правильно понял о чем речь, - я вижу основное преимущество не столько в отзывчивости, сколько в возможности иметь собственную сессию c сервером приложений, принцип работы которой отличается от HTTP сессии и ближе к классической клиент-серверной сессии. Это позволяет реализовать пессимистическую стратегию блокирования, которую не возможно реализовать в класическим веб приложении, и которая очень востребована в корпоративном секторе. Например накладную куда проще заблокировать на время ее модификации пользователем, нежели свести воедино результат параллельной работы над ней двух разных пользователей. Если же попытаться заблокировать ресурс в http сессии, возникает непонятка, когда его освобождать, пользователь может закрыть окно редактирования, не завершая сессии и сервер приложения не будет оповещен об этом факте. Да, существуют разнородые кастыли, которые применить для получения желаемого, но даже до статуса органических протезов им весьма далеко. Я так понимаю Oracle Forms можно отнести к этим самым RIA. Его концепция, в этом отношении, мне очень нравится. Принцип построения вебового приложения не отличается от классического клиент-сервера. Но во всем же остальном, увы, это буквально чудовище. Flex - не ковырял, но в виду его иметь, наверное стоит. Ораклиный металинк на флексе врой как переписан. Но кто его знает, не ждет ли этот флекс участь жава апплетов, которые казались столь же перспективными еще так недавно. Не будет ли для флекса HTML5 тем же самым, чем стал для апплетов флэш? |
| Автор: LSD 21.3.2012, 15:31 | ||||
То что нативные гриды да и вообще весь гуй превосходит веб, по возможностям реализации всякого нестандартного это бесспорно. Но я и не припомню чтобы кто-то с этим спорил. Вопрос в том насколько эти все навороты нужны.
Есть веб сокеты. Правда они появились недавно, потому не очень распространены пока. Добавлено через 1 минуту и 8 секунд Ах да, главная претензия к Дельфям, они наш null обозвали nil! И вы еще спрашиваете за что их не любят?! |
| Автор: Zloxa 21.3.2012, 16:43 | ||||
Вам с вашим null и обращаться то достойно не дозволено
 |
| Автор: LSD 21.3.2012, 16:46 | ||
А что не так? |
| Автор: Zloxa 21.3.2012, 16:53 | ||||
Трехзначная логика - где? Ваш null - значение, характеризующее неопределенное значение. Т.е. значение определено, но оно не определено - подвоха не чуствуешь? Принюхался? Вот оно - достойное поведение:
|
| Автор: LSD 21.3.2012, 17:27 | ||||||||
Где-где -- в су-бэ-де
Это ваш null - значение характеризующее, а наш это значение указателя не указывающего ни на какой объект и все. Никакой другой смысловой нагрузки он не несет.
У тебя опечатка Что будет в результате?
|
| Автор: Zloxa 21.3.2012, 18:58 | ||||
Том Кайт за это извинялся, исправиться не обещал, но покаянную голову не рубят. К тому же, приняв это как данность, привыкнув к этому, действительно начинаешь понимать, на сколько бесполезно, маразматично и порочно понятие "пустая строка".
А ваш это недонаш null  |
| Автор: LSD 22.3.2012, 10:20 | ||
Я так понимаю, следующая стадия это считать, что 0 в числах маразматичен и порочнен, достаточно null  А еще varchar2 в два раза лучше чем varchar |
| Автор: Lazin 22.3.2012, 11:07 |
| "не любят" - неправильное выражение, скорее не берут в расчет при выборе платформы для разработки приложений, даже под "уиндоус" |
| Автор: Zloxa 23.3.2012, 11:09 | ||||||
LSD, вот реально, на практике сколько раз тебе доводилось выполнять операцию со строками подобную той, что ты продемонстрировал? Я вот не припомню. На том, что length от пустой строки возвращает null я не припомню, чтобы спотыкался даже в начале своего знакомства с оркалом. Обычно длина строки нужна для того чтобы определить больше ли она нуля или же меньше ли ее некое значение. От того, что пустая строка эквивалентна null дискомфорт испытал лишь единожды, в самом начале своего знакомства c ораклом, пытался что-то заовнокодить, опираясь на различие пустой строки и null, досадовал что не получается. Зато очень хорошо помню что при написании клиентов для других систем приходилось вешать чеки length(str)> 0 вместо обычных not null, т.к. при сохранении формы в базе не заполненные edit box'ы сохранялись как ''. Тоже и при разборе XML "<a/>" текст для этого элемента не определен, но экстракт по "/a/text()" вернет пустую строку, сохраняем в базе - обманываем not null констрейнты.
Варчар круче. Но он пока сферический и в вакууме.
http://docs.oracle.com/cd/E11882_01/server.112/e26088/sql_elements001.htm#SQLRF50978 |
| Автор: LSD 26.3.2012, 10:29 | ||||
А часто ли тебе в базе приходится парсить тексты, регулярки и т.п.?
В этом весь Оракл. Куча древнего гoвна мамонта, оставшегося с 1979 года. Но за который они крепко держаться, и всех пытаются убедить, что это фича а не баг. Вместо того чтобы придти и сказать, с версия 12 будет обратно несовместима и мы вычистим оттуда весь шлак. Кому влом переписывать сидите на 11. |
| Автор: Zloxa 26.3.2012, 12:07 | ||||
Вообще достаточно часто. Задача "вдувать по расписанию в базу CSV/XML c ftp" уже набила жуткую оскомину. Но я не понял к чему этот вопрос.
Вообще есть мнение, что varchar это не депрекейт вовсе, а резерв фо фьючер юз. А varchar2 называется так чтобы не путали с ансишным вачрчаром, т.к. его поведение, в части сравнения с null отличается от описанного в стандартах. Если ты архаичным гуано называешь именно тип varchar2... К той же категории можно отнести и все строки фискированной длинны, которые в новых проектах никем не используются, но поддерживаются практически всеми движками баз данных. А за счет того, что эти типы данных были опрометчиво стандартизированы, их поддержку придется обеспечивать и в новых, не скучных СУБД, буде такие появятся. Зачем допиливать ансишное поведение ораклиным строкам - вопрос весьма не однозначный. Я, например, не могу на него сходу ответить. Шаблоны это рвет только тем кто не привык к этому. Тем же кто привык, это практически не доставляет неудобства, зато профит - очевиден. Я, лично, не уверен что прейду на varchar, если оракл его реализует, и его отличие от varchar2 будет лишь в части синонимичности пустоты и неопределенности. Мне такой varchar будет определенно менее удобен. Если ты архаичным гуано зазываешь прочие плюшки от оракла... вроде версионной изоляции транзакций, реализованной в пику имеющихся тогда(да и сейчас) стандартам, не в полной мере их поддерживающих... То, на сколько мне известно, этот тип изоляции уже вройкак пытаются стандартизировать как обособленный, майкрософт его уже с 2005й версии и к себе допилил в какой -то степени. Уж больно офигительно это получилось в конце то концов. |
| Автор: Akella 26.3.2012, 13:43 |
| http://www.teobit.ru/ и здесь есть несколько сайтов: http://www.teobit.ru/#Portfolio сайты написан на http://morfik.com/stories_delphi |
| Автор: LSD 26.3.2012, 14:38 | ||||||
Ты их парсишь руками (substring/regex)? Просто когда шаблон совпадает с пустой строкой, получить null вместо этой самой строки довольно неприятно.
Я называю древним гoвном мамонта, несовместимости со стандартом и явные косяки: - пустые строки - null и уникальные индексы - varchar2
Ты называешь преимуществами те фишки которыми пользуешься сам в своем проекте (как длинные транзакции), а те что не используемые относишь к "никому не используемым" Я вот длинные транзакции использовал всего один раз, да и они бы прекрасно сработали и на любой другой базе. А строки фиксированной длинны использовать приходилось чаще, как правило это некий идентификатор фиксированного формата. |
| Автор: Zloxa 26.3.2012, 15:36 | ||||||||||||||
CSV - да. Для разбора XML есть нативные инструменты.
Тут я опять не уверен, что понимаю что ты имеешь в виду. Но если бы я наталкивался на эту неприятность, я, наверное, запомнил бы, и, вероятно, понял бы о чем ты )) Однако, соглашусь, это неприятно когда ты к чему-то не имеешь привычки, но имеешь привычку к чему-то другому, пытаешься делать как делаешь всегда, а получаешь кукиш. Точно так же мне на жаве писать неприятно. Это как нибудь хараткерезует саму жаву?
Это офигенно же! Часто доводится этой фичей пользоваться. Без нее, прям даже не представляю - как без рук. Но да, от кастыля тут что-то действительно есть. Составные индексы реализуют несколько иную логику работы с null - неединнобразие некое, определенно, наблюдается. Но я определенно не хотел бы, чтобы это неединообразие устранилось включением null в индексы.
Я не вижу особых преимуществ хранения идентификаторов фиксированного формата в строках фиксированной длинны. Быть может даст экономию каких то спичек на перфомансе. Сам храню такие в варчар2.
Этот пункт повторяет первый. Наверно для большей весомости повторен
Я пяток лет назад тоже не мог этим похвастать. Хоть и имел уже достаточно длительный стаж датабейз девелопмента. Просто мое погружение в эту специфику было не настолько полным и конкурентые процессы в моих тогдашних базах носили скорее исключительный нежели перманентный характер. Многие подходы применяемые мною тогда(и, в общем, работающие, успешно решающие те задачи, которые передо мною стояли), сейчас я бы не смог себе позволить применять, даже если бы у меня была уверенность что под тот коврик, куда все заметено, никто не никогда не заглянет. Добавлено через 10 минут и 57 секунд
Зато вот, кстати, вспомнилось. Сейчас имею неприятности на интеграции с PG. PG сохраняет пустые строки в not null поля. Эти пустые строки, не будучи не определенными, упаковываются в пустые элементы xml, размеченные в DTD как обязательные и, соответственно успешно валидируется. Блин, неужели это противоречит "человеческой" логике, что если, скажем, поле "номер документа" или "ГТД" размечены в как обязательные для заполенния, то пустой строки там быть не должно. |
| Автор: RockClimber 26.3.2012, 18:36 |
| Топик не читал. Выскажу свою версию по сабжу. Во-первых, Delphi не так уж сильно не любят. Многим просто параллельно. Большинство нелюбящих его тупо не видели никогда, и ругают по принципу "все побежали, и я побежал". Остальные, видимо, никак не могут смириться с тем, что хоронят его уже второй десяток лет, а он, с**ко, никак не умирает А сейчас, говорят, у Embarcadero продажи растут на 50% в год, так что новая анти-delphi волна не загорами, запасайтесь попкорном.  |
| Автор: ivanfain 26.3.2012, 20:54 | ||||
Я наоборот замечал что ругают как раз те, кто с него ушли. А тем кто не видели его, тем он по-барабану.
А по мне так он давно мёртв. То, что его продают, ещё ничего не доказывает. |
| Автор: Akella 28.3.2012, 23:14 |
| Уже говорили, что судя по отзывам, все ЯП мертвы, кроме питона, и тот на таблэтках |
| Автор: Stolzen 29.3.2012, 08:33 | ||
А как же шарп и дядя Билли? |
| Автор: LSD 29.3.2012, 11:04 | ||||||||||||
Ну например вычислить сколько пробелов надо для padding-а:
и вместо ожидаемого col_width получаем null. Очень мило
Обратно, нет никаких причин отказываться от них.
Наверно для того чтобы напомнить, что даже в такой простой вещи как типы данных Оракл умудрился выпендриться и сделать полностью несовместимую вещь. Простейщий create table не перенесешь на другую СУБД, без ручной правки.
Тип DATE тоже не соответствует стандарту, но что-то они не спешат вводить DATE2
Ты явно не понимаешь проблему, но пытаешься переложить ее на PG. У тебя проблема с валидацией входных данных, поля "номер документа" или "ГТД" не могут быть не только пустыми строками, но и строками состоящими только из пробелов, не может там быть и иероглифов и т.д. Оракл выполнял за тебя одну простейшую проверку и ты почему-то решил, что это круто и этого достаточно. |
| Автор: Akella 29.3.2012, 12:28 |
| http://www.spring4d.org/ |
| Автор: Zloxa 29.3.2012, 12:42 | ||||||||
А как бы ты падил на другой, более православной, субэдэ? Где исходная строка может принимать как не определенное значение, так и значение пустой строки? Если у тебя поле nullable, тебе всяко пришлось бы на это закладываться. Если нет, то - нет.
Да, я действительно не понимаю принципиального различия между пустой строкой и не определенным значением. Я действительно не могу придумать что может характеризовать пустая строка иначе как неопределенность.
Это ключевое слово. Ты не приывк работать с неопределенностью, не имеешь ее в виду, но пытаешься использовать устоявшиеся практики работы с другим инструментом. Это выглядит почти http://forum.vingrad.ru/index.php?showtopic=345645&view=findpost&p=2472112. Только вот в данном конкретном случае, у меня не создается впечатления что ты прикалываешься. Возможно ты делаешь это черезмерно уж тонко, а я, как баран, веду с тобой беседу на полном серьезе.
Да, было бы классно. Меня задолбало всякий раз придумывать имя для атрибута даты сущности, не пересекающееся с зарезервированными словами. Зачастую приходится его префиксовать именем сущности. Масло же масленное выходит... ASN.ASN_DATE . DATE2, определенно, решило бы эту проблему |
| Автор: LSD 29.3.2012, 15:25 | ||||||||
Это может быть не только поле, но и результат substr или trim.
Почему 0 может характеризовать что-то отличное от неопределенности, а пустая строка - нет? Плюс абзац был посвящен вовсе не пустым строкам, но ты почему-то полностью проигнорировал все что написано дальше.
Ожидаемый это не только привычки, но и поведение других типов. Почему для чисел 0 и null это разные вещи? Почему в CLOB или RAW пустая строка и null это разные вещи?
Что ты тут со своим Дельфи, не видишь у нас тут уже ораклосрач |
| Автор: Zloxa 29.3.2012, 17:04 | ||||||||||
И substr и trimm могут быть применены к nullable значению. Потому на то, что в результате будет is null все равно, как правило, приходится закладываться. На счет результата тримма от заведомо определенного значения, что правильнее вернуть null или '', действительно не столь уж и очевидно. Но с сабстром.... Он вернет null лишь в том случае, если ты у него запросишь то, неведомо что. Неопределеность, в этом случае, мне кажется, куда ближе соответствует естественной логике нежели пустая строка.
Весьма же нелепый тезис. Если мы будем основывать свои ожидания на поведенческих особенностях других типов, дождемся что в результате "100"+"500" в результате станем ожидать"600".
У меня нет практики работы с системой, где null эквивалентно 0. Я не могу оценить эту идею. У меня есть практика работы с системой, где null эквивалентно ''. И мне действительно не понятно что вызывает такой сильный анальный зуд. Неудобства эта особенность особого не доставляет. Профит, хоть и не бессомненный, от этого, какой, да есть. Причины с этим что-то срочно делать, для меня далеко не очевидны. Оснований назвать это прям уж таки порочной практикой у меня - нет. На этом и строятся мои сомнения в действительной полезности такого понятия, как пустая строка. Твои же попытки раскрыть ее несомненную пользу, пока, я оцениваю как тщетные.
Я тебе начал было отвечать на тот абзац, но получилось уныло и не интересно.
Я вообще не понимаю о чем тут сраться. Я не нахожу что продукты оракла являются верхом эстетики. Скорее наоборот. Я согласен с тем, что у оракла весьма дурной вкус. |
| Автор: RockClimber 29.3.2012, 23:11 | ||
Вот это я и называю "вторая волна". Я не видел новых Delphi холиваров года три наверно, только догорающие старые, а тут последние полгода они что-то растут как грибы после дождя... А еще я хотел спросить, что же может доказать "жизнь", если наличие вакансий и продажи средств разработки не доказывают. Но побоялся оскорбить чужие религиозные чувства. |
| Автор: RockClimber 29.3.2012, 23:41 |
| Вот, кстати, к вопросу о том, "за что не любят делфи": http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=898212&msg=11665115 Очень показательна критика некоторых товарищей, которые искренне считают, что их любимые крутейшие фичи появились именно в дотнете, а не в delphi десятью годами ранее |
| Автор: Akella 30.3.2012, 11:37 |
| RockClimber, у LSD и Zloxa уже сраз пошёл в другую тему, как мне показалось , просто междуусобица |
| Автор: LSD 30.3.2012, 12:18 | ||||||
substr и trimm от неопределенного значения должны вернуть неопределенной значение или выкинуть эксепшн (смотря что поддерживается языком). substr и trimm при корректных параметрах должны вернуть конкретное значение. Т.е. если запросили substr(5, 0) то и вернутся должна пустая строка или должно быть отдельно оговорено в контракте substr() что length должен быть строго больше нуля иначе будет эксепшн.
1. На самом деле твой пример содержит ошибку (или это сознательное мухлевание? ). Операция сложения к строкам не применима, к строкам применима операция конкатенации и даже если они обе обозначаются одним символом, это не значит что это одна и та же операция 2. По твоей логике мы не должны ожидать что результат сложения целых и дробных чисел будет одинаков, типы данных то разные. 3. Есть тип CLOB, который от VARCHAR2 отличается только реализацией, почему там другое поведение?
А какие еще СУБД/ЯП реализуют подобную логику? Как думаешь почему? |
| Автор: lukas 30.3.2012, 12:50 |
| Вам не надоело строчить столько текста друг другу? |
| Автор: Zloxa 30.3.2012, 13:37 | ||||||||||||||||
А какие ЯП(кроме SQL) реализуют трехзначную логику? Стоит ли лишь на этом основании срать кирпичами на SQL, требовать сделать как у всех нормальных языков, чтоб LSD удобно было?
Почему именно пустая строка? Это же абсурд! Должно вернуться не определенное значение. Это же логично!
Если в документации оговорено что "If substring_length is less than 1, then Oracle returns null.", то, как бе все по контракту и получается что все пучком
Кому должны, LSD? И почему должны? Потому что так сделано в яве? Потому что так сделано у майкрософта? Потому что тебе так привычно?
Сложение может и будет одинаково. Но вот деление, по твоей логике, должно бы работать тоже одинаково?
:facepalm Кстати, для меня такое поведение - действительно неожиданность. Я привык в результате деления целых получать дробное.
Клоб, чар и варчар это совершенно разные типы, имеют различное предназначение, различную механику и нет ничего странного в том, что они имеют разную специфику. Почему ты не находишь странным ожидать от чара поведения подобного варачару, но не находишь странным ожидать того же от клоба? |
| Автор: Zloxa 30.3.2012, 14:21 |
| Нуи, в общем, так.... Мне не нравится что наша дискусия перешла в русло очевидных для меня вещей. Я бы был более склонен обсудить вещи для меня не столь очевидные. В частности - разница null и "". Я, привыкнув к ораклу, действительно ее перестал улавливать. И чтобы ее уловить(или же убедиться что ее нет), мне таки требуется стороннее мнение. - Я не нахожу принципиальной разницы в том, используем ли мы четыре буквы или два символа для обозначения суть одного и того же. - Я не нахожу неудобным то, что взятие функции length от null возвращает null. Там, где нужно получить 0 вместо null, ничего не мешает использовать nvl - Меня очень радует, что конкатенация с null в результате дает не null а эквивалент конкатенации с пустой строкой. В системах, где null не эквивалентен пустой строке, это, временами, несколько усложняет жизнь, а профит от этого для меня не очевиден. Конкатенацию строк мне доводится пользовать много чаще расчета длины строки. - Меня очень радует, что после отображения строки в элементе управления, по команде пользователя "сохранить", мне не надо думать о том, как ее сохранять: как null, каким это значение было до того, как было помещено в элемент управления, или же как пустую строку, которая хранится в элементе управления. Я действительно не способен смоделировать ситуации, когда различение null и пустой строки - принципиально. По этой причине я нахожу лишним одно из двух. Либо строки не должны быть nullable, либо строки, в принципе не должны быть пустыми. Варианты, в принципе, равнозначны, у каждого есть плюсы, у каждого есть минусы. Ненулобельная строка всегда будет считаться count'ом и сохраняться в индексе, что очень досадно. В то же время для nullaбельной строки length может вернуть null, что тоже досадно, но имхо - не на столько же. |
| Автор: Akella 30.3.2012, 14:36 | ||
У них просто работы нет , нужно же чем-то заняться |
| Автор: kemiisto 30.3.2012, 14:37 |
| 10 страниц оффтопа про nil и пустую строку. МОГЁТЕ! |
| Автор: LSD 30.3.2012, 14:42 | ||||||||
Не передергивай, там еще и СУБД упоминались. В каких СУБД кроме Оракла пустая строка эквивалентна null? И какое отношения эквивалентность '' и null имеет к трехзначной логике?
Опиши контракт полностью и нелогичность станет очевидна
Наверно я тебя удивлю, но деление бывает двух видов: целочисленное и дробное. Для разных типов может использоваться разное деление как в Java/C++ или одно и то же как в Deplhi. Но поведение деления одинаково для byte/short/int/long и для float/double.
И в чем же принципиальная разница между CLOB и VARCHAR2? (ограничения на максимальную длинну, методы по работе с типом и т.д., это не принципиальные ограничения, это детали реализации) |
| Автор: Zloxa 30.3.2012, 15:40 | ||||||||
Никакое. Вопрос был задан для того, чтобы показать абсурдность аппеляций к аналогам, которые ты так настойчиво приводишь. Зачем ораклу делать как делают все? Да, оракл выпендрился. Но он выпендрился не только тут. Очень много его выпендрежа в конце концов оказалось стандартизовано. Многое из его выпендрежа оказалось не принято обществом. Да, фича, о которой мы говорим - спорная. Ну давай обсудим, чего нас эта фича лишает, что нам эта фича дает. Зачем нам опираться на стереотипы и шаблоны? Может быть там, у них, к кому ты аппелируешь, все не правильно? Зачем сводить все к тому, что сотни мух не могут ошибаться?
Я не понял о чем ты говоришь.
Наверное я тебя удивлю, но строки бывают разных типов.. для разных типов может.... бла бла бла....
В чем принципиальная разница null и ''? |
| Автор: LSD 30.3.2012, 16:50 | ||||||||||
Тут более уместна другая аналогия: "Вся рота идет не в ногу, один прапорщик в ногу".
Если добавить сюда замечание насчет того что If length of the substring is zero, than null would be returned это будет выглядеть как явное исключение из общего правила. Ради чего нарушать единообразие?
Расскажи поподробней про разные типы строк.
Расскажу, но после того как ты ответишь на вопрос. |
| Автор: Zloxa 30.3.2012, 17:42 | ||||||
Ради чего его соблюдать?
Клоб - не строка. Сравнивать варчар с клобом, имхо, все равно что сравнивать строку со стримом или с чем то вроде. Может не самая лучшая аналогия, но в целом - как то так. Clob, объявленный как переменная, переменной по факту не явлется. Он является локатором, посредством которого ты можешь получить доступ к этим неким текстовым данным. То же самое и в таблице. Ты бы стал задаваться вопросом в чем разница между строкой и чарактерстримом? Просто ли бы тебе было сформулировать эту разницу, если бы ответ на этот идиотский вопрос с тебя настойчиво требовали?
Как смог - рассказал. Жду. |
| Автор: LSD 30.3.2012, 19:12 | ||||||
Каждый exceptional case потенциальный источник ошибок.
В общем случае стрим отличается от строки тем что: - стрим имеет неизвестную длинну (в частном случае мы можем узнать ожидаемое количество данных) - стрим поступает из некого внешнего источника данных и поступление может неожиданно прерваться Стрим это некая абстракция с помощью которой можно получить доступ к данным, но это не единственно возможная абстракция. Например файл можно прочесть и как стрим, можно с помощью RandomAccessFile читать произвольные байты, можно замапить как memory mapped files - 3 разных абстракции для одно и того же файла, но файл то один Я не вижу у CLOB как типа данных никаких особенных качеств по сравнению с VARCHAR2. Есть только особенности реализации, связанные с ограничением по памяти, производительности и т.п., но по сути та же строка.
Если я не знаю ответ на некий вопрос (каким бы дурацким он не казался), это повод задуматься действительно я понимаю эту разницу. Или я просто привык и перестал задаваться "дурацкими вопросами", но сути не понимаю. |
| Автор: Zloxa 30.3.2012, 20:52 | ||
|
| Автор: RockClimber 31.3.2012, 20:14 |
| LSD, Zloxa! У ну пошли вон со своим эскуэлем из делфисрача!  |
| Автор: ivanfain 2.4.2012, 04:14 | ||
Где ты такое откапываешь? Ты им сам пользовался? Если нет, то пожалуйста, не рекомендуй дабы не позорится. |
| Автор: RockClimber 2.4.2012, 22:34 |
| Как умирает Delphi: наблюдаем в деталях. Вот http://www.tdelphiblog.com/2012/04/samoe-interesnoe-v-delphi-blogah-za.html список только самых интересных статей (по мнению составителя) из Delphi-блогов за 2011-й год. Чтоб я всю жизнь так умирал |
| Автор: Lazin 3.4.2012, 22:21 | ||
Добрая половина статей написана Реймондом Ченом совсем не о delphi, все остальное - неинтересные статьи про delphi  Добавлено через 6 минут и 51 секунду Итак, внимание! Заходим вот сюда: http://stackoverflow.com/tags Видим самый популярный тег - c#, почти 300k вопросов. Вбиваем в поле ввода "delphi" и видим, что самый популярный тег не дотягивает до 15к вопросов, delphi теги, все вместе, едва дотягивают до 17k. И где здесь популярность? Для сравнения, тег haskell - 6k. Тег perl - 18k. C++ - 120k. Это говорит о том, что delphi в мире используют примерно так же часто как перл. |
| Автор: RockClimber 6.4.2012, 20:24 | ||
Так он умер или просто непопулярный? Или это одно и то же? А за что его не любить? За то, что уже умер, или за то, что никак не умрет? Объясните, а то я уже запутался.  |
| Автор: k0rvin 11.4.2012, 13:23 | ||
Возможно одна из причин то, что в Эмбаркадеро упоротые люди работают?
http://www.delphinotes.ru/2012/03/blog-post.html |
| Автор: Alexeis 11.4.2012, 14:51 | ||
Можно не любить за то что не популярный. Потому что код написанный на непопулярном языке сложнее сопровождать и развивать. На самом деле ответ на вопрос ТС был дан еще 10 страниц назад. Собственно он состоит в том, что легкость освоения привело к засилию его быдлокодерами, которых собственно и не любят. Отсюда параллель язык для быдлокодеров. |
| Автор: RockClimber 13.4.2012, 19:01 | ||||
|
| Автор: Akella 16.4.2012, 16:26 | ||
Почему именно так определяешь популярность? |
| Автор: Akella 16.4.2012, 19:32 | ||||
Тебя кто-то заставляет или в чем проблема? |
| Автор: Akella 12.5.2012, 14:56 | ||
Можно в коде создать кнопку, написать процедуру и присвоить её событию на нажатие кнопки, или я не понял чего-то? Вот тебе нужно написать некий код, процедуру, например, создания и показа окна. Чтобы пользователь нажал кнопку на панели или выбрал меню, или использовал клавиши быстрого доступа? Как ты будешь делать? Ну так, кратенько. В дельфи есть такая компонента, как ActionList, там можно создать action(ы) с некоторыми свойствами/событиями. Затем присвоить созданный action кнопке(ам), меню, "горячим" клавишам. Всё. Добавлено @ 14:58 Я не пытаюсь типа спорить, если так это можно назвать, мне просто интересно. |
| Автор: LSD 12.5.2012, 15:03 | ||
Не можно, а нужно. Но кто же будет так делать, когда есть способ проще. Когда Борланд сваяла свой JBuilder который и в Яве позволял делать то же самое Щелкнул мышкой на кнопку и получил свой Button111OnClick, то и на Яве появилось достаточно количество проектов в таком же стиле. Но потом JBuilder умер |
| Автор: Akella 12.5.2012, 16:33 |
| Ну так как же всё-таки правильно, по твоему? |
| Автор: LSD 12.5.2012, 17:18 |
| Правильно разделять представление и бизнес логику. |
| Автор: Akella 12.5.2012, 17:35 |
| нет, ну конкретнее, как быть в той ситуации? |
| Автор: k0rvin 17.5.2012, 11:14 | ||||||||||
Мне, например, нравится, как это сделано у Apple: 1.
http://www.youtube.com/watch?v=_KAtEK7j06Y 2.
http://www.youtube.com/watch?v=MIo5EF2zDBY |
| Автор: LSD 17.5.2012, 12:18 | ||
Что ты подразумеваешь под "конкретнее", ты хочешь код что ли? |
| Автор: Akella 17.5.2012, 12:48 | ||||
Ты хочешь сказать, что всё нужно делать в коде? И не заниматься "компонентомкидательством" на форму? |
| Автор: LSD 17.5.2012, 13:56 | ||
Если ты делаешь действительно сложный гуй - то да. Вообще по хорошему действие и его вызов из гуя должны быть настраиваемыми. Т.е. мы можем повесить хоткей на некое действие, можем добавить кнопку на тулбар, или создать свое главное или контекстное меню, куда добавить это действие. Плюс плагины тоже должны создавать свои действия и так же прозрачно их встраивать в приложение. |
| Автор: Zloxa 17.5.2012, 14:21 | ||
Акелла правильно кивнул на TAction. Он именно этим и занимается. Ввели, емнип в еще 5й делфе. Ты создаешь действие, потом рефаешь его из менюхи, туллбара, кнопы, попапа. Ты можешь управлять иконами, видимостью, доступностью, описанием экшна как из кода реализующего некую логику, так и декларативно, описав обработчик события обновления статуса экшна. Визуальные контроллы, для которых назначен экшн будут обновляться в соответствии с его настройками. Всамделе - бомба вещь. |
| Автор: ivanfain 20.5.2012, 16:06 | ||
Не правда. Сложный гуй проще сделать в дизайнере, потому как у тебя нервов не хватит каждый раз запускать проект, дабы передвинуть контрол на пиксель в лево, потомы что он почему-то совсем не смотрится. Уже давно люди поняли, что гуй десктопных приложений нужно делать в дизайнере, только явистам это пока не всем дошло. Ну так вы посмотрите и на программы, написанные на яве. В обработчике Button1OnClick можно создать класс, который вызовет один единственный метод, вот и всё. Ну и конечно там можно писать всё, что касается гуя. Если вы не согласны, что сложный гуй можно сделать в дизайнере, то скажите, много ли вы знаете насколько динамичных гуев, который сложно сделать размещением компонентов на форму? Вокруг меня: хром, ворд, тоталкомандер, скайп и тд. не помню программы, где гуй каждую секунды с ног на голову переворачивается. А вот, что касается размещения на форме Не визуальных компонетов, и не имеющих отношения к гую - это, простите, быдлокод. |
| Автор: serger 21.5.2012, 07:35 |
| ivanfain, бред. Полностью не согласен. |
| Автор: Zloxa 21.5.2012, 09:11 | ||
Тут согласен. Процесс ручного фомрирования километровых XML конфигов - дает куда большее удовлетворение и яркий экстаз, если это наконец заработает. |
| Автор: LSD 21.5.2012, 14:20 | ||
И в результате получаем гуй состоящий из нагромождения контролов и который может работать в одном разрешении экрана. |
| Автор: Zloxa 21.5.2012, 14:35 | ||
Наверное ты не о разрешении а об коэффиценте увеличения(не знаю как по русски, scalling), которое устанавливается в настройках винды. Тут конечно да, жава срала на эти настройки гуеоса, и при их любых настройках выглядит одинаково. В делфе у формы есть свойство, определяющее подобное поведение. Действительно жаль что оно всегда по умолчанию отключено. |
| Автор: LSD 21.5.2012, 16:08 | ||
Нет именно про разрешение. Если компоненты выравниваются попиксельно, то ни о каком изменении размеров окна и речи не идет. |
| Автор: Zloxa 21.5.2012, 16:41 | ||
Есть крюки (емнип, называются anchos), которые можно определить для визуального компонента и сразу же проверить, в дизайнере, как это будет работать при растягивании/сжатии формы. Появилась плюшка не сразу. Кажись в седьмой делфе, возможно в пятой. Раньше резиновые формы приходилось делать панелями. Чуть менее удобно, но куда удобнее, нежели лапами кодить. |
| Автор: ivanfain 21.5.2012, 17:50 | ||||||
Для конфигурирования xml обычно делают визуальные дизайнеры, а вот конфигурировать его в презентационном слое приложения... ну вы понимаете... не самое лучшее место.
Всё решается, разрешение экрана уже давно не является страшной проблемой при визуальном проектировании приложения. Тем более, никто не запрещает и с кода какие-то элементы подвинуть. Другое дело полностью на mvc приложение делать. В общим у кого нету опыта с обоими юзезкейсами, тому не понять. |
| Автор: k0rvin 22.5.2012, 11:42 | ||
А еще есть Layout'ы всякие. |
| Автор: Zloxa 22.5.2012, 14:57 | ||
Это наверное позже седьмой версии появилось? То я и не ковырял вовсе. Это уже не труЪ делфи |
| Автор: k0rvin 22.5.2012, 19:29 | ||
В данном случае я не столько о делфи, сколько в общем. И чем layout'ы не Ъ-делфи? |
| Автор: LSD 23.5.2012, 11:33 | ||||||
Проверил -IDEA масштабирует все контролы и шрифты в соответствии с установленным DPI.
Все прогрессивное человечество давно использует для этого layout manager-ы. И только дельфисты что то там из кода двигают
У меня есть опыт и того и другого, и я пришел к выводу, что при наличии опыта написание гуя руками дает лучший результат чем дизайнером. Плюс опыт моих коллег, минимум две знакомые командами разработчиков отказались от дизайнеров в пользу ручного написания. Правда надо заметить, что во всех случаях использовались нормальные языки с layout manager-ами, а не с "попиксельным позиционированием". |
| Автор: ivanfain 24.5.2012, 20:01 | ||||
Ну я то не дельфист. А скажите пожалуйста, в каких единицах измерения вы ставите отступы между элементами управления?
А кто говорил что нужно попиксельно позиционировать? Я не знаком с layout manager-ами, но что-то мне подсказывает что используемые мной средства будут хуже. Тем не менее, в конечном итоге приходишь к выводу, что в дизайнере делать лучше. Подумайте сами, ведь изначально гуевые приложения начали создавать с кода, потом пришли к дизайнеру форм. Однако всем хочется пробовать что-то новое, вот и используют мвс, и первое время даже начинают видеть в этом профит. Но вот есть куча моментов когда это не удобно, перечислю которые первые приходят в голову: 1. Как я уже говорил, пока не запустишь приложения, не будешь знать как оно выглядит, и хотя ты будешь знать что элемент А находится за элементом В, всё равно это всё не сможешь оценить, если не увидишь всю картину. 2. приложения созданные в дизайнере проще модифицировать. так уж получается, что требование к ПО постоянно меняются, а как ни странно, приложение на мвс сложнее модифицировать при изменении структуры, так что разделение логики и представления в мвс это понты для приезжих. 3. иногда не хочется весь этот огород городить с мвс, а хочется по больше сосредоточится на основной задачи приложения, дизайнер форм делает всё гораздо быстрее, кроме того, не приходится писать однообразный код реализации мвс. |
| Автор: Zloxa 25.5.2012, 09:17 | ||||
Судя по тем заблуждениям, что ты высказывал раньше(относительно экшн, относительно нагромождения контролов, не способного работать с разными разрешениями), опыта у тебя в одном, определенно меньше нежели в другом. Выводы, при таком раскладе, делать не совсем корректно.
Здесь отчасти согласен. В этом утверждении, определенно что-то есть. При проектировании структуры БД мне определенно проще использовать ddl, нежели графические дизайнеры схемы данных. Припоминаю, что некогда функционал для ПЛИС мне было проще реализовывать средствами vhdl, нежели используя графический редактор логики, предоставляемый производителем ПЛИС. Но в обоих случаях, достоинство декларативного языка обуславливается вполне определенными недостатками графических средств. В обоих случаях я начинал с графических дизайнеров, и, лишь не удовлетворившись ими, начинал изучать семантику декларативного языка. От ворда, к примеру, я не ушел ни к какому языку разметки текста. От делфийского дизайнера форм, я не ушел к динамической компоновке форм. Это говорит о том, что эти средства в достаточной степени покрывают мои потребности. То, что вам проще херачить формы лапами, говорит лишь о том, что прочие средства предоставляемые вам платформой еще более убоги. |
| Автор: LSD 25.5.2012, 16:27 | ||||||||
Использовал дефолтные (99% процентов случаев)
Ты про TAction? Так я про него ничего и не говорил, я говорил про то как себя по умолчанию ведет визуальный редактор Дельфей. Если бы он спрашивал имя для нового TAction, а потом создавал отдельный класс для него и регистрировал как обработчик события, тогда бы я бы согласился, что редактор гуя делает максимум того, на что он способен. Но насколько я знаю, он этого не делает. |
| Автор: Zloxa 25.5.2012, 16:48 | ||
И зачем это нужно там, где это не нужно? |
| Автор: LSD 28.5.2012, 18:48 | ||
Затем чтобы приучать начинающих быдельфи програмистов к хорошему стилю |
| Автор: Akella 30.5.2012, 20:34 | ||||||||||
Разработчики DevExpress пошли дальше и создали бомбу по мощнее в лице dxBarManager А TActionList + TcxImageList + TdxBarManager весьма сильно разгружают программиста по времени. Добавлено через 4 минуты и 48 секунд
зависит от компонентов для дельфи много компонентов, позволяющих строить "резиновый дизайн" Добавлено через 10 минут и 16 секунд
1. Можно из кода, а можно и не из кода. 2. Ты сам подумай, если не ты в своём приложении двигаешь НЕ из кода, то кто-то другой до тебя в любом случае двигает из кода |
| Автор: LSD 31.5.2012, 10:26 | ||||
Пропущено ключевое слово сторонних
Layout manager уже написаны и хорошо протестированы сотнями программистов. В отличие от самописного управления расположением компоненов. |
| Автор: Zloxa 31.5.2012, 10:41 | ||||
От проекта вроде как не отказались, но приоритет этой новой нескучной POS на жаве, сильно задвинули. В параллель пустили новую не скучную POS на 1С. Разработка в обоих случаях - java и 1С ведется двумя человеками. Кастом - дичайший. 1С используется скорее как платформа, нежели решение. Выводы пока делать рано, но кое-что уже можно попытатсья сравнить. Период от начала разработки - выход на интеграционные тесты на жаве занял более полугода. 1С - менее месяца. За две недели интеграционного тестирования с POS на 1С мы продвинулись по процессам на два шага дальше, чем за два месяца интеграционного тестирования с POS на Java. 1Cники ни разу пока не упомянули словосочетание "хорошая практика", в дискуссии на подобные темы не пускались. Вместо этого: "надо? Сделаем!". Технические вопросы, вроде того, как изменить формат XML сообщений обмена, чтобы он был воспринят "гибкими" фреймворками, 1Сниками вообще не поднимались, вдули как им дали, не привередничая. Вобще с 1Сниками обсуждалось больше прикладные вопросы, чем технические. До обсуждения прикладных вопросов с Java программистами, мы вроде как и не дошли вовсе. Добавлено @ 10:43
Я со сторонними, о которых бает Акелла, мало знаком. Нативные, вполне позволяют делать резиновые формы. Стороннние, возможно, делают это лучше. А возможно, протсо наследуют функционал нативных. |
| Автор: RockClimber 6.6.2012, 19:17 | ||
Буквально несколькими сообщениями ранее делфистов ругали за то, что они этого не делают |
| Автор: LSD 7.6.2012, 12:22 | ||
Где? |
| Автор: Akella 15.6.2012, 13:02 |
| http://code.google.com/p/fpos/wiki/FPOSWiki Many people judge that Pascal can't be used to write an OS, this project will prove that they are WRONG. |
| Автор: LSD 15.6.2012, 14:05 | ||
In fact many people judge that Pascal can't be used to write an OS suitable for everyday usage |
| Автор: k0rvin 15.6.2012, 14:23 | ||
"So what?" ОС и на Хаскелле есть, и на Лиспах разных их несколько, толку-то? |
| Автор: LSD 21.6.2012, 13:19 |
| Есть такие хорошие программы PL/SQL Developer и TOAD. Для Оракла пожалуй лучшие средства разработки. Но у них есть фатальный недостаток: они написаны на Дельфи. Из-за этого на 64 битной винде, они не могут использовать 64 битного клиента и приходится специально для них ставить 32-х битный клиент. Бедному Christian Ghisler приходится извращаться с отдельным исполняемым файлом, чтобы получить поддержку 64 битных систем. |
| Автор: Zloxa 21.6.2012, 16:03 |
| Однако ж, надо заметить, для оракла предостаточно и средств разработки, написанных и на жаве. Хоть они и могут крутиться и на линуксе и на виндовсе и на 32, и на 64.... Но юзабилити их заставляет ставить 32х разрядный клиент и пользовать PL/SQL Developer и TOAD Вот не ясно - что мешает жаваписам написать описюнительную среду разработки для оракла? Сайд эффект, кстати, от производителя PL/SQL Developer'а - DOA прекраснейшая библиотека доступа к ораклу. Тоды - не знаю, ODAC - не ихний ли? Тоже хвалят. Жабьи либы для оракли - угнетают :( |
| Автор: Akella 21.6.2012, 16:20 | ||
Что мешает написать на яве очень удобную и быструю среду разработки?  |
| Автор: LSD 21.6.2012, 16:28 | ||||||||
Не надо передергивать. На Java можно писать прекрасные IDE, IDEA тому пример. А то что бесплатные IDE уступают коммерческим лидерам рынка, так это вполне естественная ситуация в мире ПО. Так же хотелось бы заметить, что в плане наворотов и PL/SQL Developer-у и TOAD-у до той же IDEA или NetBeans очень далеко.
Вот только не понятно, что мешало заюзать в PL/SQL Developer DOA и не связываться вообще с оракловым клиентом. Что же это сапожник без сапог.
Чем? Добавлено через 31 секунду
Ничего не мешает, более того такие IDE есть. |
| Автор: LSD 21.6.2012, 18:03 | ||
А вот и причина по которой Оракл не может написать приличную IDE под свою базу: http://www.gazeta.ru/business/news/2012/06/21/n_2400053.shtml |
| Автор: Zloxa 21.6.2012, 18:21 | ||||||
Спору нет. Делфийская IDE тоже на Object Pascal написана. И до ней тоже Плскл девелоперам и тодам расти и расти. Но ведь и комерческих IDE на жаве для оракла на слуху особо нет. Те что на слуху- те оба делфевые (что, правослово, всамделе удивляет). Почему комерсанты брезгуют жавой, но не брезгуют делфи?
DOA, емнип, через OCI работает. Здесь direct, скорее всего означает возможность работать с наборами данных в том числе и мимо всяких там делфийских датасетов, когда нужно. Но могу ошибаться. Давно писал клиентов на делфи.
В первую очередь - вопросиками. Ораклиный jdbc клиент вроде умеет работать с именованными параметрами, но на своей небогатой практике его использования натыкался уже не раз на ансуппортед фичи, когда приходилось переделывать на вопросики, чтоб заработало. Во вторую, отсутствием возможности работы со всякими ораклеспицифик плюшками. Точно на вскидку не помню, кажись коллекцию биндом - хер передашь. С объектными типами тоже, кажется, отгребал. В третью, всякая около вкуснота, вроде тех же врапперов, DOAвские врапперы можно юзать, пусть и рехтовать напильником иногда приходится приходится. От враперов Jpublisher'а пришлось отказаться в силу категорической не пригодности. Для очреедей, алертов, пайпов, и прочей фиготы DOA предоставляет удобные обертки. В жаве вроде только для очередей, вроде как JMS, вроде как написано что замечательно стыкуется. Только вот фиг я разобрался откуда этот jms качнуть, как к проекту подключить. Времени на разборки потратил куда больше чем раньше тратил на реализацию, и безрезультатно. Пришлось по дедовски - препаред стайтмент для PL/SQL блока, бинды вопросиками и уже в PL/SQL создавать объекты, ставить в очередь - не тоска ли? Правда, DOA - тоже коммерческий продукт. Мож есть пусть и коммерческий, но удобный на жаве? |
| Автор: LSD 22.6.2012, 12:05 | ||||||||||
Для Оракла существует пяток IDE, и еще десяток универсальных клиентов. Считать такую выборку репрезентативной не серьезно.
Да, я DOA с ODAC перепутал.
Кто о чем... 
Поконкретнее, в чем проблема? В самом JDBC конечно нет никаких классов и методов для работы с специфичными оракловыми фишками, но в самом оракловом драйвере все есть и объекты и коллекции. Как по твоему SQL Developer работает?
Я не понимаю твою страсть к враперам, так что не буду комментировать. Что же касается того, что ты не смог разобраться с JMS, как-то странно обвинять драйвер |
| Автор: Zloxa 28.6.2012, 08:41 | ||||||
Походу - ждет. Оракл прислал письмо:
Добавлено @ 08:44
Тебе просто не приходится работать с логикой, реализованной на стороне БД. Допустим есть пакет, из него торчат писят процедур/функций. Большая их часть используется приложением. Како тут без враппера? Уныло. Весьма уныло. Что же касается целесообразности выноса логики на сервер, приведу пример:  Здесь реализация функции проведения фискального (один из нескольких типов документа) документа по регистру исторического остатка(один из нескольких регистров). Всего четыре мержика. В совокупности тянут чуть более чем на тыщщу строк. Врядли мержики о пятиста строк, будучи сохраненыыми в строку ли, в ресурс жавы, будут выглядить органично. Я не думаю, что отказавшись от объединения всего необходимого функционала в одном SQL операторе мы в чем либо выиграем. Врядли выиграли бы в простоте реализации, наверняка потеряли бы в производительности. Можешь мне назвать хоть одну разумную(ессно с моей точки зрения) причину, почему этот функционал должен реализовываться вне базы данных? |
| Автор: Zloxa 28.6.2012, 09:06 | ||
Я не драйвер обвиняю, а сожалею об отсутствии простых и удобных средств доступа к функционалу БД. |
| Автор: LSD 28.6.2012, 11:41 | ||||||
Писят процедур/функций не появляются за один день. Они пишутся по мере развития системы, и по мере их появления к ним дописывается враперы.
Иногда это целесообразно, а иногда нет. И что?
Я работал и с нативным API AQ и через JMX, и с другими JMX провайдерами. Нет там ничего сложного, средний программист на Java разберется за пару дней. |
| Автор: Zloxa 28.6.2012, 12:18 | ||||||||
Они и писались по мере развития системы. И потребность написания жабьего клиента - тоже возникла в процессе эволюционного развития. Впрочем ты дал ответ. Жававэй - врапать лапами, биндить вопросиками. От чего же тогда не тоска?
Среднему программисту на делфи не потребуется пары дней, чтобы разобраться с DOA API для AQ. И даже интернеты не нужны. На жаве я ниже среднего программист. Сделал пару, тройку наскоков, не понял даже с чем разбираться. Когда сроки прижали, бахнул через pl/sql в препаред стайтменте. Делов там было всего - создать достаточно не сложный объект, да поставить его в очередь. Времени это у меня заняло меньше, чем я потратил на попытки разобраться, но не красиво. Ввергает в уныние ( Хуже было бы если бы у меня объект инкапсулировал бы еще и коллекцию. Хрен бы я бахнул это через PL/SQL. Сорвал бы сроки.
Это как? Через dbms_aq?
Спасибо, запомню ключевое слово для будущего гугления. Я прально понимаю, что это имплементация JMS, который, по сути лишь интерфейс, сиречь сферический и в вакууме? |
| Автор: Zloxa 28.6.2012, 12:38 | ||
Желаю расширить свой кругозор. Просто в моей практике случаев, когда вынос фунционала из базы не целесообразен существенно превышает количество случаев, когда он целесообразен. Потому я мыслю однобоко. Потому я и пытаюсь это обсуждать. В твоей же практике, я так понимаю, другой перевес. При этом ты оставляешь ощущение весьма компетентного человека, вполне способного отрефлексить более одной точки зрения. Потому я и пытаюсь это обсуждать именно с тобой. |
| Автор: LSD 29.6.2012, 15:19 | ||||||||||
Не верю (при условии конечно, что этот самый программист впервые сталкивается с message-oriented middleware). Просто почитать, понять концепцию топиков и очередей, понять как это создается в Оракле, уже день, другой займет.
У AQ есть Java API не являющееся реализацией JMS.
Забудь, это опечатка, там должно быть JMS Я тебе другое подкинул MOM (message-oriented middleware)
JMS это просто API который имплементится вендором.
С моей точки зрения, у вас типичная ERP (исходя из того что я от тебя слышал). Как и все ERP она ориентированна на данные. Данные вы храните в СУБД и обрабатывать их встроенными средствами СУБД (хранимки) и удобней и быстрей. И вся архитектура вашей системы выстроена под эту концепцию. И тут внезапно у вас появляется необходимость "прикрутить" туда Java и вот тут мое понимание уже заканчивается. Для чего вам Java модуль какова его функция в вашей системе? |
| Автор: Zloxa 29.6.2012, 15:33 | ||||||||||
Я предполагаю, что человек, желающий поставить сообщение в очредь, уже знает, что он хочет сделать. Ему для этого нужен только инструмент. И не знаком ему именно инструмент.
Забыл, спасибо.
Запомнил, спасибо.
Всякие обменные процессы c внешними контрагентами/системами. Формировать/разбирать всякие xls, xml, csv, зиповать их, выкладывать на ftp, слать емайлы, принимать - не совсем удобно в pl/sql. Хотя есть некоторые процессы, того же характера, когда трафик не ожидается большим, проще бахнуть то же на pl/sql и засунуть в жобу, нежели писать клиент, выделять сервер, шедулить, мониторить... Добавлено @ 15:35
Но и логику многих типичных ERP многие стремятся вынести на миддл. В том числе и Oracle corp. |
| Автор: irinazanuda 29.6.2012, 15:36 |
| Не по теме, но кто знает, я люблю гифки-- с помощью какого языка они делаются??? Тот я буду любить |
| Автор: LSD 29.6.2012, 19:00 | ||||
Я не могу сходу предложить удобного и легкого решения как состыковать СУБД и Java (да еще такого, чтобы понравилось дельфистам ).
Мидл проще масштабировать чем базу. Хотя у Оракла есть RAC, но там все не так радужно с масштабированием, а вот Кохеренс как раз масштабируется прекрасно. |
| Автор: Nikolja 29.6.2012, 21:25 | ||
При помощи литературного русского языка. ЛюбИте его! А программирования там не надо.И ещё немножко при помощи какого-нибудь графического редактора. А по Дельфи... Любят -- не любят. Вспоминается песня Трофима "Я скучаю по тебе": "Только в логику любовь никак не запихнуть" А если всё-таки рассуждать логично, то Delphi -- это не Microsoft. Потому-то одни его не любят, а другие -- ровно наоборот. |
| Автор: LSD 4.7.2012, 18:07 |
| Похоже что http://habrahabr.ru/post/147133/ зачем нужен MVC. |
| Автор: Zloxa 4.7.2012, 18:18 | ||
На сколько я могу судить, там больше говорится о "как", нежели о "зачем" |
| Автор: LSD 4.7.2012, 18:31 | ||
Если человек начал на практике применять что-то, то с высокой долей вероятности он понимает зачем он это делает. |
| Автор: Zloxa 4.7.2012, 19:56 | ||||
сейчас ты говоришь об одном человеке, раньше говорил о многих, используя термин "делфисты"
Я бы так не сказал. Вполне возможно человек просто поддался стадному инстинкту. Я не раз сталкивасля с ситуацией, когда человек следует паттерну потому лишь, что очень наслышан об этом паттерне, не более того. К тому же, излагаемое в этой статье, мне думается, подлежит определенной ревизии на прдемет действительного соответствия следования паттерну MVC. Вполне возможно, человек, поддавшийся стандному инстинкту, выдает желаемое за действительное. |
| Автор: LSD 5.7.2012, 11:22 | ||||||
Судя по коментам:
есть и другие понимающие дельфисты.
Делать "как все" это тоже мотивация, причем в зависимости от ситуации она может быть вполне разумной. |
| Автор: LSD 5.7.2012, 16:04 |
| Дельфисты продолжают свое http://habrahabr.ru/post/147198/, при этом они четко отдают себе отчет в том что дельфи и MVC плохо совместимы |
| Автор: Zloxa 5.7.2012, 16:40 | ||||
Я разумность не оспаривал. Я лишь указал что следование паттерну, не требует понимания, изначально тобой заявленного.
Бегло просмотрел, на сколько могу судить, тема "зачем", опять не раскрыта. |
| Автор: Akella 15.7.2012, 12:01 | ||||
я просто не могу понять, а зачем этот MVC-подход? что он реально дает, кроме того, что тебе потом скажут, что ты нереально крутой программер? |
| Автор: Akella 15.7.2012, 15:34 |
| я так думаю, что правильное применение ActionList и так даст приличный выигрыш без mvc в дельфи просто этот самый mvc нифиг не нужен |
| Автор: Shaggie 15.7.2012, 17:20 | ||
Независимо от задачи? Дельфи такой специфичный, оказывается, язык, что ему нет нужды отделять данные от способов их отображения и обработки? Наверное это очень удобно, всю логику нажатия кнопки в один единственный Button1.Click() засунуть, чтобы и в базу лезло, и интерфейс обновляло, и по сети перемигивалось. И копипастнуть в остальные 37 обработчиков кнопок. |
| Автор: Zloxa 15.7.2012, 17:52 | ||
Может кто нить подсказать, какой десктопный фреймоврк, библиотека классов и что-то вроде ориентирован на паттерн MVC? Я раньше полагал, что свинги его реализуют, но камрады в этом топике меня разуверили. |
| Автор: Akella 16.7.2012, 12:02 | ||
ты дельфи-то юзал хоть раз по нормальному? Добавлено через 1 минуту и 23 секунды Тут дело не в дельфи, тут дело в самом программисте. Захочет он использовать MVC/MVP, то будет использовать, а если ему нафиг оно ненуна, то не будет. |
| Автор: Alexeis 16.7.2012, 16:55 | ||
Он делает программу менее чувствительной к изменениям. Если есть правильная модель, то на ее основе можно делать различные представления. Можно изменить функционал сохранив вид. |
| Автор: k0rvin 17.7.2012, 12:35 | ||
Cocoa? |
| Автор: Akella 17.7.2012, 21:35 | ||
если опираться на ту нуДную статью и на пример с чекбоксом, то можно использовать DevExpress |
| Автор: Akella 18.7.2012, 10:17 | ||||
Наверное, имелось ввиду для Delphi? |
| Автор: k0rvin 18.7.2012, 13:28 | ||
По-моему имелось в виду вообще. |
| Автор: Akella 18.7.2012, 13:43 |
| Зачем ему вообще, если здесь речь о Delphi? |
| Автор: LSD 18.7.2012, 15:24 | ||
Дельфи не нужен |
| Автор: Akella 18.7.2012, 16:37 |
| говори токма за себя |
| Автор: Zloxa 18.7.2012, 19:33 | ||||
Паттерн MVC, как я думаю, придуман для веба. На вебе, ввиду гетерогенности, презентативный слой технологически изолирован от слоя логики, а попытки сделать прозрачным взаимодействие этих слоев пока нелепы. MVC это вынужденный компромисс переходного периода. Десктопные приложения, даже не будучи гомогенными, имеют куда более развитые средства взаимодействия промеж сообой. Казалось бы выдели прикладную логику в COM да дергай ее из любой морды, сервиса и бла-бла. Прикладная логика отдает сложный объект, вроде резалтсета - да бога ради, с этим можно как-то справиться. Особой нужды тут в следовании MVC как бы и не прослеживается. Вот и спрашивал, есть ли прецеденты. k0rvin, спасибо. К сожалению о cocoa судить не могу. В среде, где я вращаюсь это нечто экзотическое и совсем не на слуху. В общем делфи не такой уж и специфичный, оказывается язык.... Добавлено @ 19:37
Если уж на то пошлло..... классическая делфийская связка DataSet-DataSource-<data aware controll> как бы вполне себе в писывается в MVC. Когда-то я даже понимал зачем это надо, теперь, увы, забыл. |
| Автор: k0rvin 18.7.2012, 21:00 | ||
| Вообще-то, когда был "придуман" MVC, веба не было, о чем можно почитать хотя бы http://ru.wikipedia.org/wiki/Model-View-Controller#.D0.98.D1.81.D1.82.D0.BE.D1.80.D0.B8.D1.8F. Собственно кроме Cocoa, думаю, можно посмотреть современные реализации SmallTalk. Добавлено через 6 минут и 27 секунд
Я бы не стал этого утверждать. А смысл DataSource'а я так и не понял. |
| Автор: Zloxa 19.7.2012, 08:41 | ||||
Почему?
Если смотреть со стороны контролла, который может взять данные напрямую из датасета, то да, как бы не особо понятно зачем лишний слой. Но если смотреть от датасета, датасету нафиг не нужно знать какие контроллы от него ведутся, как и когда их обновлять, об этом знает датасурс. Емнип, датасурс так же управлятет буферами контроллов. У тебя уже есть грид, который показыват пять строк, ты динамически добавляешь новый, который будет уже показывать 10 строк. Данные надо считать, при этом позицию курсора не сбить... |
| Автор: Akella 20.7.2012, 10:56 | ||
| MVC было описано или придумано ещё в конце 70х. Я уверен, что если бы в Delphi был так сильно нужны приёмы MVC, то их бы уже давно жёстко применили, описали в справке, книгах и т.д. Как я уже говорил, то это дело программиста. Он может сделать жёсткую связку СУБД->SQL-запрос(DataSet, Query)->отображение на экране, а может сделать на уровне MVC, т.е. запрос изменил и данные отображаются другие. По идее в наследниках DataSet столбцы для отображения данных могут создаваться динамически в момент запуска приложения или в момент создания модуля. Вот пример. 1. Создаем таблицу в базе. 2. Создаем представление на основе таблицы (View). 3. В TQuery делаем запрос к представлению select * from view. 4. Соединяем TDBGrid с TQuery. В design-time никаких столбцов не создаем у TQuery, т.к. их TQuery создаст сам на основе выборки. 5. Теперь нам достаточно открыть TQuery и в гриде появятся нужные столбцы. 6. Допустим, что пользователь захотел, чтобы в гриде данные отображались в другом порядке или какой-то столбец не нужен. Изменяем представление (view): убираем оттуда столбец и меняем порядок других столбцов, хотя, на клиенте это всё тоже можно сделать настройками грида. 6а. Допустим, что пользователь хочет, чтобы в выборке больше не показывались записи из архива. 1. Изменяем представление (view): и добавляем там условие where deleted=0 и всё. 2. Приложение перекомпилировать не нужно. 6б. Допустим, что пользователь хочет, чтобы второй столбец был не текстовым, а датой и чтобы в гриде была при этом правильная сортировка, фильтрация, группирование и соответствующий редактор был, т.к. для даты нужен уже календарь. 1. Добавляем новое поле или изменяем тип старого. Изменяем представление (view): в запросе представления меняем второе поле или просто перекомпилируем в СУБД само представление (view). 2. Теперь TQuery в выборе получит второе поле уже не текстовое поле, а дата, грид создаст на основе типа поля уже соответствующий редактор. Чем вам не MVC? Добавлено @ 10:58
ну там есть некоторые события, которые помогают, например при связке Master-detail |
| Автор: Zloxa 20.7.2012, 21:04 | ||
Akella, в терминах MVC view это форма, а не вьюха СУБД. То что ты описал - совсем не MVC. |
| Автор: Akella 22.7.2012, 22:05 |
| и что с того, я просто применил не тот термин и всё |
| Автор: LSD 24.7.2012, 17:42 | ||
http://www.orindasoft.com/public/plsqlfeatures.php4?pdsrc=PLSQL смотрели? |
| Автор: Zloxa 24.7.2012, 18:27 |
| LSD, спасибо, поковыряю |
| Автор: Akella 25.7.2012, 14:27 |
| MVC - это типа построеное визуального тырфейса, на основе данных и модели? Просто напросто в дельфи не используют динамическое построение тырфейса во время исполнения программы (run-time). Поэтому оно нафиг и не нужно. Ну или используют редко. |
| Автор: LSD 25.7.2012, 14:33 | ||
MVC это разделение на слои, данные отдельно, представление этих данных отдельно. |
| Автор: Alexeis 25.7.2012, 14:56 | ||
Так чем же Delphi и MVC не совместимо? Пишешь структуры данных, связи, создаешь обработчики для классов модели. На обработчики вешаешь обновление представления. У форм свои обработчики, которые обновляют структуры данных. То что компоненты хранят в себе данные, так это можно рассматривать как кеширование, позволяющее не дергать по 100 раз в сек модель, ведь скорость доступа к ее данным может быть недостаточно быстрой. |
| Автор: LSD 25.7.2012, 15:20 | ||
А где ты увидел утверждение, что дельфи несовместимо с MVC? |
| Автор: Alexeis 25.7.2012, 15:25 |
| Ну я так грубо выразился, в том смысле, что проектирование приложений по патерну MVC вызывает проблемы или неудобства. |
| Автор: Akella 26.7.2012, 09:06 | ||||
ну так в дельфи это всё есть с самого рождения, можно сказать |
| Автор: LSD 26.7.2012, 13:34 | ||
Расскажи мне про слой данных в компоненте TListBox |
| Автор: Alexeis 26.7.2012, 14:34 |
| Там нет слоя данных, только строки, причем насколько я знаю они хранятся непосредственно в виндовом контроле без собственного кеширования. Некоторые насилуют нетипизированный указатель на Objects, но это скорее затычка для тех кому нужно, что-то по быстрому на коленке накидать. Модель данных это собственные массивы / списки, если это БД компонент, то для него источник данных базы будет моделью. Контроллер работает через механизм обработчиков источника данных и/или обработчиков компонента. |
| Автор: Akella 22.8.2012, 08:45 |
| http://www.cgdevtools.com/demo/JQueryDemoIW12_ISAPI.dll/0fm5zoi0hxnbyw1gl3htt11y8wqj/ |
| Автор: LSD 18.10.2012, 11:34 | ||
http://habrahabr.ru/post/154607/
|
| Автор: kemiisto 18.10.2012, 13:25 |
| Всё, можно удалять раздел Delphi. Embarcadero разрешил. |
| Автор: serger 18.10.2012, 13:27 |
| Чувак в комментах защищает Delphi - а сам использует его как мелкий разработчик. Он распинается - как же Delphi удобен для таких как он. http://habrahabr.ru/post/154607/#comment_5278791 вообще показательная ветка. Доказательство того что компания рубит сук на котором сидит... |
| Автор: Zloxa 18.10.2012, 13:30 | ||
Это цитата или мнение? Воспринимается как цитата, но больше похоже на мнение. |
