экстремальное программирование
а что программируем?
yo.
экстрим маст дай.
хотя в случае embedded applications без этого сложно
экстрим маст дай.
хотя в случае embedded applications без этого сложно
в общем так нельзя сказать
Для программистов - must die
Для начальства - даааааааааааааа
Пусть плбедят программисты!
Для начальства - даааааааааааааа
Пусть плбедят программисты!
в yandex'е его вроде применяют 
а что именно не нравится ? unit тесты что-ли ?
а что программируем?
Не суть важно. Я не вижу места где сабж рулил бы.
Я не вижу места где сабж рулил бы.
Очень серьезные аппаратные ограничения, особенно на объем памяти. И тогда без сабжа просто почти невозможно.
а что именно не нравится ? unit тесты что-ли ?Не только.
Я задействован в сабж проекте. Что мне не нравится из того, что я наблюдаю:
- Люди не обсуждают технические подробности реализации. Они обсуждают сроки и фичи. Программисты общаются на том же уровне, что манагеры.
- Нет критики кода. Никого не чморят если он криво пишет. Главное что бы писал быстро. Сроки важнее качества. Рефакторинг откладывается, т.к. заказчик не платит за рефакторинг того, за что он уже заплатил. Вытекающие последствия:
* до хера утечек памяти. Последнее игнорируется разработчиками и начальством, т.к. продукт перезапускается раз в неделю.
* Никогда не произносятся слова "не оптимальный подход/код/метод". Произносятся слова "мало памяти", "слабый процессор", "купите еще машин".
- Анализ кода отсутствует, Зато тысячи unit-testов. Если ты пишешь фукнцию которая возвращает квадрат числа разделенный на 2, то сначала ты должен написать программу-тест, которая вызывает эту функцию с аргументом 4 и проверить, что она возвращает 8. После чего этот тест добавляется к тысяче других которые крутятся бесконечно, что бы проверить не сломалось ли что-то. А я бля беру, читаю код и нахожу ошибку не покрытую этими тестами. И пытаюсь объяснить им, что вообразимых ошибок миллионы, а тестов тысячи. Вот живой пример: нахожу место где один профессор ожидает что read на SOCK_STREAM вернет ему то же число байт, что было послано в write на другой стороне сокета. Указываю на ошибку. Мне в ответ: "пиши тест, который это докажет." Я: "Иоп тваю! Какой смысл?" Ответ: "Тест будет работать и проверять не появится ли эта ошибка в будущем". Я: "Два write по 1000 байт каждый могут быть с той стороны прочитаны десятками тысяч комбинаций read. Для того, что бы доказать, что программа работает правильно нужно их все перепробовать. написание такого теста займет несколько дней. А проанализировать код займет полчаса и это будет научным подходом, а не работой с черным ящиком".
- до хрена лозунгов и девизов из XP книжек. Это начинает напоминать религию.
- качество кода таково, что его нельзя назвать работой на будущее. Его нельзя переносить в другие проекты. В голове не откладывается ничего умного. Разработчик чувствует себя кодером, а не ученым. Ведь один из лозунгов XP - пишите, а не планируйте.
Так Лева, по-моему мы говорим о разных вещах. Я о той херне, что описывается на http://xprogramming.ru/
кстати, а ты "Правила Ашманова" читал ?
www.ashmanov.com
www.ashmanov.com
Разработчик чувствует себя кодером, а не ученым.при какой методологии разработки промышленного ПО человек, который пишет код, чувствует себя ученым?
по поводу рефакторинга
http://xprogramming.ru/XPRules/Refactor.html
(признаюсь, что читать про XP начал только после твоего поста..........)
http://xprogramming.ru/XPRules/Refactor.html
(признаюсь, что читать про XP начал только после твоего поста..........)
кстати, а ты "Правила Ашманова" читал ?
www.ashmanov.com
Пролистал. В его речах много XP. Интересно, какова ротация кадров в его конторе?
Когда он думает.
при какой методологии разработки промышленного ПО человек, который пишет код, чувствует себя ученым?
Что ты зовешь "промышленным ПО"?
Еще одно наблюдение: XP всегда является шапкой, венцом программной структуры. Потому что делать какие либо надстройки над XP продуктом нельзя - они надстройки будут падать как карточный домик. Я часто спорю со своими боссами - если бы Linux, Oracle, Java и java-библиотеки используемые нами были написаны с тем же качеством что пишем мы, работало ли бы оно все? Мы полагаемся на программные продукты написанные совсем с другим подходом и поэтому они надежны. При этом мы сразу лошим нашего разработчика, когда в нем просыпается системный архитектор и он начинает думать и планировать. А ведь он делает то, что приводит к появлению нормального продукта, на который можно опираться и что-то строить поверх него.
отчасти, поэтому я и спросил: "что пишите?"
кто выдвигает и платит за требования "нормального продукта" и "строить поверх него"?
если ты уверен, что сможешь написать за те же сроки, то вопросы снимаются.
кто выдвигает и платит за требования "нормального продукта" и "строить поверх него"?
если ты уверен, что сможешь написать за те же сроки, то вопросы снимаются.
полностью согласен
для _нормального_ продукта время не должно быть определяющим фактором, к сожалению, в некоторых российских софтверных компаниях этого не понимают
для _нормального_ продукта время не должно быть определяющим фактором, к сожалению, в некоторых российских софтверных компаниях этого не понимают
слово "промышленного" можешь опустить.
Как называется эта методология?
или у ней нет названия и она еще не опубликована?
Как называется эта методология?
или у ней нет названия и она еще не опубликована?
> Рефакторинг откладывается,
Сами себе яму роете, а потом пинаете бедный XP.
зы
Весь смысл XP как раз в том, чтобы делать постоянные рефакторинги, которые чистят, упрощают код.
И именно для этого делают тесты, чтобы можно было с более спокойной душой проводить изменения.
Сами себе яму роете, а потом пинаете бедный XP.
зы
Весь смысл XP как раз в том, чтобы делать постоянные рефакторинги, которые чистят, упрощают код.
И именно для этого делают тесты, чтобы можно было с более спокойной душой проводить изменения.
я об этом и дал ссылочку
> Вот живой пример: нахожу место где один профессор ожидает что read на SOCK_STREAM вернет ему то же число байт, что было послано в write на другой стороне сокета. Указываю на ошибку. Мне в ответ: "пиши тест, который это докажет." Я: "Иоп тваю! Какой смысл?" Ответ: "Тест будет работать и проверять не появится ли эта ошибка в будущем". Я: "Два write по 1000 байт каждый могут быть с той стороны прочитаны десятками тысяч комбинаций read. Для того, что бы доказать, что программа работает правильно нужно их все перепробовать. написание такого теста займет несколько дней.
Вот ты подумал головой и нашел ошибку. Что тебе мешает написать тест, который будет проявлять эту ошибку?
В данном случае, смысл тестов не в том, чтобы все проверить, а в том, что если ты каким-либо образом нашел ошибку, то ты должен написать тест, который явно показывает ошибку , а не на пальцах все это показывать
Вот ты подумал головой и нашел ошибку. Что тебе мешает написать тест, который будет проявлять эту ошибку?
В данном случае, смысл тестов не в том, чтобы все проверить, а в том, что если ты каким-либо образом нашел ошибку, то ты должен написать тест, который явно показывает ошибку , а не на пальцах все это показывать
имхо, вы просто надергали из Xp-и те вещи, которые позволяют оправдать вашу безалаберность и разгильдяйство.
Такой подход с реальным применением XP не имеет ничего общего.
Такой подход с реальным применением XP не имеет ничего общего.
качество кода таково, что его нельзя назвать работой на будущее. Его нельзя переносить в другие проекты.
Ну значит такие кодеры, верно? XP не отменяет написание правильного кода, просто приоритеты другие.
у меня уже третья по счету контора, где работаю. и везде экстремальное программирование. такова особенность российского бизнеса.
По-моему, это бред --- доказывать очевидные вещи.
И тестами много не докажешь.
А правильность работы программы не докажешь точно.
---
...Я работаю антинаучным аферистом...
И тестами много не докажешь.
А правильность работы программы не докажешь точно.
---
...Я работаю антинаучным аферистом...
Еще раз для особо непонятливых.
1. Тест доказывает наличие ошибки.
2. Отсутствие ошибок тест не доказывает.
3. Тест доказывает, что что-то работает.
Простой пример:
1. Ты приходишь и говоришь - вот здесь ошибка
2. Разработчик: У-у! Это надо пару дней на исправление
3. Менеджер: Нафиг, нафиг такое исправление. Нам завтра прогу надо сдавать, а у нас еще основной функционал не сделан. Данная ошибка проявляется редко, поэтому можно ее сделать потом.
И все, вот это "потом" никогда не наступает.
Но если написать тест, который будет проявлять ошибку, то тогда в любой момент мы будем помнить, что ошибка есть, и что она не исправлена.
1. Тест доказывает наличие ошибки.
2. Отсутствие ошибок тест не доказывает.
3. Тест доказывает, что что-то работает.
Простой пример:
1. Ты приходишь и говоришь - вот здесь ошибка
2. Разработчик: У-у! Это надо пару дней на исправление
3. Менеджер: Нафиг, нафиг такое исправление. Нам завтра прогу надо сдавать, а у нас еще основной функционал не сделан. Данная ошибка проявляется редко, поэтому можно ее сделать потом.
И все, вот это "потом" никогда не наступает.
Но если написать тест, который будет проявлять ошибку, то тогда в любой момент мы будем помнить, что ошибка есть, и что она не исправлена.
т.е. фактически, база тестов - это база знаний о работоспособности программы.
Ты объясни, что мешает _не_писать_ этот тест, если и так ясно,
что есть зависимость от вот таких условий работы
и что условия не всегда выполняются?
Распределённые системы тоже так "тестировать?"
А СРВ?
---
...Я работаю антинаучным аферистом...
что есть зависимость от вот таких условий работы
и что условия не всегда выполняются?
Распределённые системы тоже так "тестировать?"
А СРВ?
---
...Я работаю антинаучным аферистом...
Шутку про нечётные числа помнишь?
"9 --- ошибка эксперимента."
---
...Я работаю антинаучным аферистом...
"9 --- ошибка эксперимента."
---
...Я работаю антинаучным аферистом...
Нашли ошибку. Есть два варианта действия:
1. Дать больно по шее. И сказать, чтобы он так больше не делал
2. Написать тест, подсунуть его программисту, разобрать вместе с ним, почему прога на данном тесте дохнет.
Внимание, вопрос:
После какого из вариантов программист осознает свою неправоту и не будет допускать аналогичных ошибок?
1. Дать больно по шее. И сказать, чтобы он так больше не делал
2. Написать тест, подсунуть его программисту, разобрать вместе с ним, почему прога на данном тесте дохнет.
Внимание, вопрос:
После какого из вариантов программист осознает свою неправоту и не будет допускать аналогичных ошибок?
Программа, пусть даже СРВ, дохнет у клиента при определенных условиях.
Твои действия?
Твои действия?
Для чистоты эксперимента, могу еще раз повторить:
Отсутствие ошибок тест не доказывает.
Поэтому тест пишется для других целей.
Отсутствие ошибок тест не доказывает.
Поэтому тест пишется для других целей.
После увольнения.
И принятия на работу не делающего таких ошибок.
Цель --- не обучить программиста.
Он программист,
так что должен знать, либо понять, когда ему указали.
А цель --- создать товар.
Ты объясни, как тестировать распределённые системы и СРВ.
---
...Я работаю антинаучным аферистом...
И принятия на работу не делающего таких ошибок.
Цель --- не обучить программиста.
Он программист,
так что должен знать, либо понять, когда ему указали.
А цель --- создать товар.
Ты объясни, как тестировать распределённые системы и СРВ.
---
...Я работаю антинаучным аферистом...
По обстоятельствам.
Дохнуть может от чего угодно.
---
...Я работаю антинаучным аферистом...
Дохнуть может от чего угодно.
---
...Я работаю антинаучным аферистом...
> И принятия на работу не делающего таких ошибок.
Сэр, живет в идеальном мире? В котором, существуют за нормальные деньги неделающие ошибок программисты?
> Ты объясни, как тестировать распределённые системы и СРВ.
Смотря на что тестировать... Что ты хочешь протестировать?
Сэр, живет в идеальном мире? В котором, существуют за нормальные деньги неделающие ошибок программисты?
> Ты объясни, как тестировать распределённые системы и СРВ.
Смотря на что тестировать... Что ты хочешь протестировать?
Если тест пишется для указания ошибки, то он нафиг не нужен.
Потому что ошибка уже указана.
---
...Я работаю антинаучным аферистом...
Потому что ошибка уже указана.
---
...Я работаю антинаучным аферистом...
Т,е. пожмешь плечами, скажешь "фиг его знает, что она сдохла", и будешь дальше работать, как ни в чем не бывало?
В каком виде указана? На словах? Ты говоришь, на словах, что ошибка есть, программист говорит, что ошибки - нет. И что дальше делать?
Например, СРВ.
Сколько мне надо будет ждать нужного мне итога "гонки?"
Может, проще было бы прочитать ещё раз исходники?
---
...Я работаю антинаучным аферистом...
Сколько мне надо будет ждать нужного мне итога "гонки?"
Может, проще было бы прочитать ещё раз исходники?
---
...Я работаю антинаучным аферистом...
АФАИК, дешевле один раз написать нагрузочное тестирование, которое будет запускать 100, 1000, 10000 потоков одновременно и проверять полученный результат.
ps
Просмотр исходников данное тестирование не отменяет.
ps
Просмотр исходников данное тестирование не отменяет.
Увольнять программиста, как несоотвестствующего квалификации.
Либо переводить его на менее ответственное направление.
Со всеми последствиями.
---
...Я работаю антинаучным аферистом...
Либо переводить его на менее ответственное направление.
Со всеми последствиями.
---
...Я работаю антинаучным аферистом...
2 метод борьбы с ошибками через просмотр исходных кодов иногда необходим.
2 при изменении дизайна, чем больше тестов, тем лучше.
2 при изменении дизайна, чем больше тестов, тем лучше.
И где взять человека, который будет работать вместо данного программиста?
> 2 метод борьбы с ошибками через просмотр исходных кодов иногда необходим.
Согласен.
Afaik, Code Review прописан одним из пунктов в xp-и
Согласен.
Afaik, Code Review прописан одним из пунктов в xp-и
"Изменение дизайна" --- это что такое?
---
"En Catala si us plau."
---
"En Catala si us plau."
Нет, за те же сроки не удастся написать не XP методами. Именно поэтому выбрано XP. Сроки важнее всего.
Простой пример:То есть тест нужен для того, что бы бороться с менеджером-мудаком? Может проще поменять отношение к ошибкам у менеджера? Кроме того, написание теста зачастую требует больше времени, чем фикс ошибки. И почти всегда требует больше времени, чем поиск другой ошибки.
1. Ты приходишь и говоришь - вот здесь ошибка
2. Разработчик: У-у! Это надо пару дней на исправление
3. Менеджер: Нафиг, нафиг такое исправление. Нам завтра прогу надо сдавать, а у нас еще основной функционал не сделан. Данная ошибка проявляется редко, поэтому можно ее сделать потом.
И все, вот это "потом" никогда не наступает.
Но если написать тест, который будет проявлять ошибку, то тогда в любой момент мы будем помнить, что ошибка есть, и что она не исправлена.
АФАИК, дешевле один раз написать нагрузочное тестирование, которое будет запускать 100, 1000, 10000 потоков одновременно и проверять полученный результат.Vladimir Butenko (http://mx.ru/Lists/CGatePro/Message/7471.html?Skin=Russian):
То, как он "просаживается" ни о чем не говорит. Речь идет именно о настоящей нагрузке, а не о 1000 одинаковых запросов от одного юзера. Когда падал FreeBSD, причем у людей с всего парой тысяч аккаунтов - то мы гоняли тесты на той же версии FreeBSD, на 100,000 аккаунтов, днями, с имитацией свопинга и еще хрен знает чего. И у нас на тестах - работало как часы. А в жизни падало. Timing, и всё. И проиммитировать его нельзя, потому что неизвестно, что иммитировать.
Почему Security Advisory для операционных систем выходят после описания проблемы, а не после proof of concept? Зачастую написать PoC очень сложно, и он либо появляется через неделю, или вообще не появляется. Тем не менее, ошибка исправляется сразу.
> Почему Security Advisory для операционных систем выходят после описания проблемы
... и на них обращают внимание только профессиональные параноики-админы ...
> а не после proof of concept?
... и только после этого - некоторые другие люди ...
... и на них обращают внимание только профессиональные параноики-админы ...
> а не после proof of concept?
... и только после этого - некоторые другие люди ...
Нет методологии и названия. Если ты задумываешься крепко при написании, а не пишешь в лоб, то программирование начинает быть похожим на науку.
слово "промышленного" можешь опустить.
Как называется эта методология?
или у ней нет названия и она еще не опубликована?
Кстати, область программ, где XP полностью прососет - это расчетные программы. Ты можешь написать программу за 2 дня вместо двух недель, но потом она украдет пару тысяч часов CPU времени на кластере. Вот такая экономия.
Речь идет не о пользователях ОС, которые ставят патч. В данном контексте их нет. Речь идет о разработчиках, которые исправляют проблему.
> Почему Security Advisory для операционных систем выходят после описания проблемы
... и на них обращают внимание только профессиональные параноики-админы ...
> а не после proof of concept?
... и только после этого - некоторые другие люди
Насколько я понимаю, быстрое исправление таких ошибок происходит по двум основным причинам
1) стремление автора к совершенству
2) пиар
Если для вашего менеджера эти причины не имеют существенного значения, то и получается
такой результат.
Разовью дальше - (2) подразумевает пиар для тех самых параноиков.
Если среди пользователей вашего продукта таких мало, то и понятно,
что ваш начальник не придаёт этому значения.
1) стремление автора к совершенству
2) пиар
Если для вашего менеджера эти причины не имеют существенного значения, то и получается
такой результат.
Разовью дальше - (2) подразумевает пиар для тех самых параноиков.
Если среди пользователей вашего продукта таких мало, то и понятно,
что ваш начальник не придаёт этому значения.
Кстати, область программ, где XP полностью прососет - это расчетные программы. Ты можешь написать программу за 2 дня вместо двух недель, но потом она украдет пару тысяч часов CPU времени на кластере.
Не думаю, что кому-то пришло в голову писать бы рассчетную программу, где нужны точность и скорость (работы используя XP. А вот когда ты пишешь нечто на заказ, под конкретного человека (контору которая платит деньги, большие, и через месяц после оплаты начинает усираться, бегать и доставать со всей силы... Вот тут без XP трудно. Только пользоваться им нужно грамотно. Пусть прога не будет рассчитана на миллионы/миллиарды конфигураций. Но она должна работать (и хорошо работать) на том, что стоит у заказчика и должна отвечать тербованиям качества ПО.
Короче - моя мысль - каждому овощу свое место. Но, правда так бывает только в идеальном мире
1) Является 2) в пределах одной личности.
Ты действительно считаешь что исправление security ошибок это PR? Или это было для поддержки флейма?
Ты действительно считаешь что исправление security ошибок это PR? Или это было для поддержки флейма?
намного чаще XP применяется в продуктах которые будут проданы десяткам покупателей.
> Ты действительно считаешь что исправление security ошибок это PR?
С учётом твоей поправки про вложение (1) в (2) - получается так.
Но я бы всё-таки рассматривал (1) отдельно.
Практика показывает, что многие вендоры избегают выпуска патчей, если могут.
То есть в тех случаях, когда это не нужно ни им, ни рынку.
> Или это было для поддержки флейма?
Да, я высказал своё мнение для поддержки флейма.
С учётом твоей поправки про вложение (1) в (2) - получается так.
Но я бы всё-таки рассматривал (1) отдельно.
Практика показывает, что многие вендоры избегают выпуска патчей, если могут.
То есть в тех случаях, когда это не нужно ни им, ни рынку.
> Или это было для поддержки флейма?
Да, я высказал своё мнение для поддержки флейма.
, намного чаще XP применяется в продуктах которые будут проданы десяткам покупателей.
Тогда это проблема разработчика, а не XP. Подумай, что бы было, если бы на всех маршрутизаторах винда стояла? А ведь местами такое встречается...
если руки не из задницы растут, то самое оно.
Похоже, что вы взяли из XP худшее, что там имеется. XP - это просто методология разработки. Она также несовершенна, как и любая другая. И весь вопрос только в правильности ее применения. Покажите мне, например, в России контору, в которой применяется pair programming. Да наши начальники желчью изойдутся, если узнают, что два программиста работаю с производительностью одного. И никакими доводами о качестве кода их не переубедить.
А читать по XP imho надо не xprogramming.ru (или не только а идеологов. Они, конечно, очень ладно бают, но свои мозги-то на что? Чтобы зерна от плевел отделять. Из XP можно почерпнуть весьма многое. Больше или меньше в зависимости от проекта. Например сейчас я работаю над очень большим проектом, который тянется уже хз, сколько времени, на котором масса народу. Он состоит из прорвы компонентов и над ним работает много народу. Казалось бы, какое такое XP? Но могу точно сказать, что без автоматического тестирования (unit tests) и автоматических сборок (читай continuous integration) - хана этому проекту
Такие пироги.
P.S. Ну что, кто тред про RUP заведет, а то пофлеймить охота
А читать по XP imho надо не xprogramming.ru (или не только а идеологов. Они, конечно, очень ладно бают, но свои мозги-то на что? Чтобы зерна от плевел отделять. Из XP можно почерпнуть весьма многое. Больше или меньше в зависимости от проекта. Например сейчас я работаю над очень большим проектом, который тянется уже хз, сколько времени, на котором масса народу. Он состоит из прорвы компонентов и над ним работает много народу. Казалось бы, какое такое XP? Но могу точно сказать, что без автоматического тестирования (unit tests) и автоматических сборок (читай continuous integration) - хана этому проекту
Такие пироги.P.S. Ну что, кто тред про RUP заведет, а то пофлеймить охота
Покажите мне, например, в России контору, в которой применяется pair programming.
Да не вопрос. Я в такой работал
И кстати, XP там реально помогало.Это говорит только о том, что руководство конторы более адекватно и правильно понимало, что такое XP (или наоборот - витало в облаках и не секло фишки, что вряд ли:). Мне вот такие конторы как-то не попадались... В основном imho начальство думает, что XP - это "быстре, быстрее, быстрее", и реально озабочено только тем, как бы побольше из программера выжать. Я не прав?
Не знаю, возможно, люди просто называют свой собственный устоявшийся процесс разработки "XP"...
XP это не "быстрее", это скорее ориентация на конечный результат. И планирование совсем другое, любая история может затянуться раз в 5, но никто за это разработчиков казнить не будет. "Выжимание соков" из кодеров - это как раз традиционная "ms project"-разработка, когда из тебя заранее пытаются выдавить сроки исполнения пока еще непонятного тебе таска.
И еще - почему-то обычно забывают про QA, а это в рамках XP становится самым важным подразделением. И имеют всегда в первую очередь QA, а не кодеров, которые в принципе за свой код особо и не ответственны. Пытаться выехать в XP со слабым QA - задача безнадежная.
XP это не "быстрее", это скорее ориентация на конечный результат. И планирование совсем другое, любая история может затянуться раз в 5, но никто за это разработчиков казнить не будет. "Выжимание соков" из кодеров - это как раз традиционная "ms project"-разработка, когда из тебя заранее пытаются выдавить сроки исполнения пока еще непонятного тебе таска.
И еще - почему-то обычно забывают про QA, а это в рамках XP становится самым важным подразделением. И имеют всегда в первую очередь QA, а не кодеров, которые в принципе за свой код особо и не ответственны. Пытаться выехать в XP со слабым QA - задача безнадежная.
Похоже, что вы взяли из XP худшее, что там имеется. XP - это просто методология разработки.Своя правда в этом есть.
XP - это просто методология разработки. Она также несовершенна, как и любая другая.XP отрицает планирование. От этого никуда не деться. Даже если все сотрудники гении и их код не нуждается в анализе и с первого раза они пишут хорошо, то планирование все равно очень важно. Ведь гениям пишущим разные компоненты нужно заранее продумать оптимальный интерфейс между ними. А ХР говорит - хуй с ним, пусть будет не оптимальный, процессоры наши мощны и многочисленны.
Вот еще один пример с моего места работы:
нужно хранить много данных в базе данных. В качестве основного языка программирования используется Java. Все программисты мыслят объектно, ведь это модно и очень соответствует идеологии ХР. Встает вопрос хранения данных. В любой книжке по SQL начиная от MySQL и заканчивая курсами Oracle написано - нужно очень тщательно продумать структуру базы заранее, и чем тщательнее это сделать, тем проще потом будет работать с ней. Думаю с этим все согласны. Но это же ни хуя не согласуется с ХР. Не думать, а печатать! Рождается такое решение - объекты Java сериализуются в бинарные последовательности байт, которые хранятся как BLOB. В итоге в базе несколько огромных таблиц, каждая из которых имеет два поля id и blob. Супер! Ничего не планировалось, и структуру базы больше не придется пересматривать, ведь мы можем пулять туда любые объекты. Да и программировать это все очень просто, намного проще чем реализовывать бизнес логику на SQL и PL/SQL.
Конечно в XP есть рефакторинг. Но вот по-моему рефакторинг описанного выше равносилен переписыванию с нуля.
И еще - почему-то обычно забывают про QA, а это в рамках XP становится самым важным подразделением. И имеют всегда в первую очередь QA, а не кодеров, которые в принципе за свой код особо и не ответственны. Пытаться выехать в XP со слабым QA - задача безнадежная.А я вот сел, почитал код и нашел ошибку, которую QA хрен нашел бы, разве что очень случайно. Думаю таких случаев масса. Наличие QA расслабляет программиста, вот ты сам говоришь, что они даже теряют ответственность.
> Ты действительно считаешь что исправление security ошибок это PR?То есть описывается уязвимость. PoC живого пока нет. Вендор исправляет ошибку. Это PR?
С учётом твоей поправки про вложение (1) в (2) - получается так.
Но я бы всё-таки рассматривал (1) отдельно.
А ХР говорит - хуй с ним, пусть будет не оптимальный, процессоры наши мощны и многочисленны
В любой книжке по SQL начиная от MySQL и заканчивая курсами Oracle написано - нужно очень тщательно продумать структуру базы заранее, и чем тщательнее это сделать, тем проще потом будет работать с ней. Думаю с этим все согласны. Но это же ни хуя не согласуется с ХР
То, что ты написал, не имеет никакого отношения к XP.
А я вот сел, почитал код и нашел ошибку, которую QA хрен нашел бы, разве что очень случайно. Думаю таких случаев масса. Наличие QA расслабляет программиста, вот ты сам говоришь, что они даже теряют ответственность.
Молодец, только при чем XP? XP не страхует от плохих программистов. И наличие QA ни фига не расслабляет, потому что ошибку исправлять тебе, и если из-за тебя сорвется релиз, то это запомнят надолго.
> То есть описывается уязвимость. PoC живого пока нет. Вендор исправляет ошибку. Это PR?
Да.
А по твоему, что?
Да.
А по твоему, что?
То, что ты написал, не имеет никакого отношения к XP.
Имеет. Цитаты с http://xprogramming.ru/XPRules/XPRules.html:
- Выбирайте самое простое решение
- Оставлять оптимизацию на потом.
Вот как раз по этим двум правилам и была придумана работа с базой. А планирование нормальной структуры таблиц, триггеров и хранимых процедур не может быть записано в одну короткую историю. Это совместная работа десятка человек в течение недели. Причем наброски кода будут появляться только на четвертый день.
Молодец, только при чем XP? XP не страхует от плохих программистов. И наличи
е QA ни фига не расслабляет, потому что ошибку исправлять тебе, и если из-за теб
я сорвется релиз, то это запомнят надолго.
Молодец, ты же только что говорил, что в ответственности QA, а не разработчик. Теперь получется, что разработчик будет отвечать. Так как же на самом деле?
> То есть описывается уязвимость. PoC живого пока нет. Вендор исправляет ошибку. Это PR?Исправление ошибки. Причем серьезной.
Да.
А по твоему, что?
А зачем исправлять ошибку, если за это не платят?
В случае компании - чтобы показать своё серьёзное отношение к безопасности - PR.
Если удаётся сделать вид, что ошибки нет (например, если эксплойта нет, можно сказать,
что его и не может быть тогда маза и не исправлять.
Если disclosure удаётся задержать или предотвратить - то же самое.
Чем меньше публика разбирается в безопасности, тем легче сделать вид,
что ошибки нет.
Твой менеджер, кроме того, может и сам верить, что если нет теста, то нет и ошибки,
это конечно клиника, а не PR
В случае компании - чтобы показать своё серьёзное отношение к безопасности - PR.
Если удаётся сделать вид, что ошибки нет (например, если эксплойта нет, можно сказать,
что его и не может быть тогда маза и не исправлять.
Если disclosure удаётся задержать или предотвратить - то же самое.
Чем меньше публика разбирается в безопасности, тем легче сделать вид,
что ошибки нет.
Твой менеджер, кроме того, может и сам верить, что если нет теста, то нет и ошибки,
это конечно клиника, а не PR
Вообще-то KISS (Keep It Simple Stupid) был известен еще со времен возникновения объектно-ориентированного дизайна как предмета изучения. Можно и скальпель Оккама вспомнить. XP всего-навсего смещает приоритеты.
Принцип оптимизации тоже был известен задолго до появления XP, и я удивлен, что ты его не знал раньше:
Don't code for performance. Don't use a "fast" language. Code for maintainability and use a language that improves that maintainability. Then profile your code, find out where the
bottlenecks are, and replace only those bits with performance-coded fast-language stuff. The result is that your code will effectively run just as fast as if you'd optimized all of it, but it'll be vastly more maintainable.
Пока что я вижу только большие проблемы в понимании, и, как следствие, в реализации XP в конкретной организации.
QA отвечает за индикацию ошибки, разработчик - за ее локализацию и исправление. Никаких чудес.
Принцип оптимизации тоже был известен задолго до появления XP, и я удивлен, что ты его не знал раньше:
Don't code for performance. Don't use a "fast" language. Code for maintainability and use a language that improves that maintainability. Then profile your code, find out where the
bottlenecks are, and replace only those bits with performance-coded fast-language stuff. The result is that your code will effectively run just as fast as if you'd optimized all of it, but it'll be vastly more maintainable.
А планирование нормальной структуры таблиц, триггеров и хранимых процедур не может быть записано в одну короткую историю
Пока что я вижу только большие проблемы в понимании, и, как следствие, в реализации XP в конкретной организации.
Теперь получется, что разработчик будет отвечать. Так как же на самом деле?
QA отвечает за индикацию ошибки, разработчик - за ее локализацию и исправление. Никаких чудес.
XP отрицает планирование. От этого никуда не деться. Даже если все сотрудники гении и их код не нуждается в анализе и с первого раза они пишут хорошо, то планирование все равно очень важно. Ведь гениям пишущим разные компоненты нужно заранее продумать оптимальный интерфейс между ними.
Это не планирование, а проектирование, пожалуй. К сожалению да, проектированию в XP отводится скромная роль "у сортира". Упор делается на последующий рефакторинг, но
а) иногда кривое, принятое в спешке решение потом годами сидит занозой в мягом месте
б) можно подумать, что программист в состоянии "плавно" рефакторить большие куски кода. Локально - сколько угодно, а вот на архитектуру проекта уже очень трудно повлиять.
XP-шники оправдываются тем, что, дескать, нельзя предвидеть последствия своего решения, так что нех и проектировать. Давайте хоть как-нибудь запустим эту хрень, а потом посмотрим, что с ней можно еще сделать. Признаться я несказанно рад, что такой подход не применяется, скажем в авиастроении.
А ХР говорит - хуй с ним, пусть будет не оптимальный, процессоры наши мощны и многочисленны.
Нет, нет. XP говорит, что потом, скорее всего во время следующей итерации, придут отцы и сходу прорефакторят.
Don't code for performance. Don't use a "fast" language. Code for maintainability and use a language that improves that maintainability. Then profile your code, find out where theЧто делать если ликвидация bottleneck подразумевает почти полное переписывание всего кроме UI? Зато maintainability описанного мною метода хранения сериализованных объектов очень высоко. Стоит ли maintainability производительности?
bottlenecks are, and replace only those bits with performance-coded fast-language stuff. The result is that your code will effectively run just as fast as if you'd optimized all of it, but it'll be vastly more maintainable.
А зачем исправлять ошибку, если за это не платят?Ты веришь в ответственность или только в PR?
Это не планирование, а проектирование, пожалуй. К сожалению да, проектированию в XP отводится скромная роль "у сортира". Упор делается на последующий рефакторинг, ноСогласен абсолютно со всем.
а) иногда кривое, принятое в спешке решение потом годами сидит занозой в мягом месте
б) можно подумать, что программист в состоянии "плавно" рефакторить большие куски кода. Локально - сколько угодно, а вот на архитектуру проекта уже очень трудно повлиять.
XP-шники оправдываются тем, что, дескать, нельзя предвидеть последствия своего решения, так что нех и проектировать. Давайте хоть как-нибудь запустим эту хрень, а потом посмотрим, что с ней можно еще сделать. Признаться я несказанно рад, что такой подход не применяется, скажем в авиастроении.
Нет, нет. XP говорит, что потом, скорее всего во время следующей итерации, придут отцы и сходу прорефакторят.
Т.к. в 99% случаев XP связано с бизнес процессом, то на следующей итерации происходит добавление фич.
Какая ответственность у корпораций? Им не положено, кроме юридической.
Всё, что сверх этого - PR.
У отдельных людей - допускаю. Иногда они и корпорациями управляют, но тогда
по-идее инвесторы могут строго спросить - а нафига ты наши деньги на невыгодное дело пускаешь?
Выходит - мотивация у людей может быть разная, но для бизнеса вредно всё, кроме PR.
Всё, что сверх этого - PR.
У отдельных людей - допускаю. Иногда они и корпорациями управляют, но тогда
по-идее инвесторы могут строго спросить - а нафига ты наши деньги на невыгодное дело пускаешь?
Выходит - мотивация у людей может быть разная, но для бизнеса вредно всё, кроме PR.
Don't code for performance... Code for maintainabilityКто-то из "Великих" сказал, что "предварительная оптимизация - источник всех бед". Подпишусь под каждым словом. Оптимизация не должна происходить в ущерб дизайну. Это справедливо для 99.9% всех коммерческих проектов imho. Мне к сожалению (а может быть с счастью...) довелось поучаствовать в проекте, где начальник был _очень_ озабочен оптимизацией (почему - чуть позже). Так он _заставлял_ программистов (и меня, грешного...) принимать _такие_ решения, что волосы дыбом вставали. Я уволился в тот момент, когда активно обсуждалось, почему GUI должен обрабатываться в "рабочем" потоке (и при этом не тормозить! несмотря на то, что "рабочий" поток иногда залипал на вводе-выводе и вычислениях. Оказывается GUI должен обрабатываться в том же потоке только потому, что при использовании 2х и более потоков мы можем лишиться преимущества single thread appartment - пряммых вызовов. А косвенные вызовы в другой appartment будут _тормозить_! (Это при том, что там их от силы 500 в секунду...).
А теперь истинная суть проблемы. Когда этот проект только начинался, нашелся не слишком пряморукий программер, писавший интерфейс к БД. Не сказать, чтобы структура БД была сложной, но запросы встречались весьма и весьма хитрые. Ничего не поделать. Так вот этот "талант" почти всегда вместо того, чтобы напрячь свои мозги, напрягал другое место и писал запросы в таком духе: выкачаем половину БД в оперативку клиента и тут уже циклами на C++ всё вычислим и результаты подготовим. Отчасти его можно понять - в его распоряжении был MySQL, средства которого до сих пор (afaik) не позволяют даже вложенных запросов, а ему там чуть не OLAP приходилось делать. Естественно, вся эта клюква ужасно тормозила и постепенно превратилась в паранойю начальника, которому на тормоза жаловались клиенты. Отсюда - борьба за производительность на всех стадиях разработки. Очень напоминает советскую "борьбу с вредителями Родины"...
Вот такая байка.
Стоит ли maintainability производительности?
Есть золотое правило - 80% производительности можно добиться, переписав 20% кода. Решение с BLOBами мне лично кажется сомнительным и в плане maintainability, и в плане производительности, и в плане простоты. Очень жаль, что в принятии подобных решений XP достается роль козла отпущения...
Так вот этот "талант" почти всегда вместо того, чтобы напрячь свои мозги, напрягал другое место и писал запросы в таком духе: выкачаем половину БД в оперативку клиента и тут уже циклами на C++ всё вычислим и результаты подготовим.Но ведь такое решение "лобалось" быстрее, чем продумывание структур таблиц и индексов. MySQL конечно слаб по возмодностям, но на нем тоже можно программировать быстро, а можно медленно, но так что бы быстро работало.
Производительность - это аспект (c)
Если не держать ее в голове с самого начала (заметь, я не говорю, что нужно писать на ассемблере! на выходе получится херня.
Если не держать ее в голове с самого начала (заметь, я не говорю, что нужно писать на ассемблере! на выходе получится херня.
Есть золотое правило - 80% производительности можно добиться, переписав 20% кода.И это правило работает в 80 % случаев.
Кроме того, зачастую виноват не код, а подход. Ты можешь писать форкающийся сервер, а можешь писать тредовый. Возможно переход с одного на другой приведет в повышению производительности. Но здесь нельзя ткнуть в конкретное место и сказать - "тормозит здесь".
Короче это правило часто работает в пределах одного файла или одного каталога. Но не всего проекта.
Решение с BLOBами мне лично кажется сомнительным и в плане maintainability, и в плане производительности, и в плане простоты.
Оно очень простое. Я не знаю java, но на перле я такое решение делал - это дважды два. maintainability высокое, так как разработчики не думают о SQL, они думают о своих любимых объектах. Объекты проще в поддержке, чем структура БД.
А в чём проблема тогда?
Это решение, получается, хорошо всем, кроме, возможно, производительности.
Если хватит производительности - останется.
Если нет - будет рефакторинг, никуда не денется
Это решение, получается, хорошо всем, кроме, возможно, производительности.
Если хватит производительности - останется.
Если нет - будет рефакторинг, никуда не денется
Кроме того, зачастую виноват не код, а подход. Ты можешь писать форкающийся сервер, а можешь писать тредовый. Возможно переход с одного на другой приведет в повышению производительности. Но здесь нельзя ткнуть в конкретное место и сказать - "тормозит здесь".
А профилирование на что?
Объекты проще в поддержке, чем структура БД.
Сомнительно, особенно если структура объекта изменится. И потом, как они запросы будут писать?
Производительность - это аспект (c)
Если не держать ее в голове с самого начала (заметь, я не говорю, что нужно писать на ассемблере! на выходе получится херня.
До тех пор, пока это не идет в ущерб дизайну. А на выходе получится в любом случае работающая система.
А профилирование на что?Хорошо, профилирование тебе покажет, что тормоза в fork + exec. Согласись, утверждать, что виноват 1 % кода там где выполняется fork + exec более чем глупо?
Хорошо, профилирование тебе покажет, что многие треды спят на каком-то большом мьютексе, пока один владеет им. И наделать много мелких нет возможности. Согласись, утверждать, что виноват 1 % кода где pthread_mutex_lock более чем глупо?
Узкое место может быть размазано по реализации.
Объекты проще в поддержке, чем структура БД.Сомнительно, особенно если структура объекта изменится. И потом, как они запросы будут писать?
Ты не прохавал мазы
Если структура изменится, то он точно так же сериализуется и ляжет в базу. А на следующем старте будет вынут. А запросы бывают двух видов: SELECT blob_f FROM table и SELECT blob_f FROM table WHERE id = foo;А в чём проблема тогда?Через 2 года кол-во и объем объектов обогнали кол-во памяти и мощь процессоров в серверах, которые постоянно апгрейдились. Своп не катит, т.к. Java располагает страницы так, что дергаются почти все. Нет такой, которая лежала бы хотя бы полчаса в свопе. Как только оперативная память кончается продукт уже не юзабелен. Сейчас вот посмотрим, что будет если на SCSI свопиться.
Это решение, получается, хорошо всем, кроме, возможно, производительности.
Если хватит производительности - останется.
Если нет - будет рефакторинг, никуда не денется
Так это на заказ или для внутреннего использования?
Если на заказ - то всё хорошо вроде - бабло срубили, теперь отдельно за рефакторинг заплатят.
Если для себя - похуже, но не страшно - 2 года проработало.
Зато быстро сделали.
Ведь чем дальше откладываешь инвестиции, тем лучше вроде как.
Если на заказ - то всё хорошо вроде - бабло срубили, теперь отдельно за рефакторинг заплатят.
Если для себя - похуже, но не страшно - 2 года проработало.
Зато быстро сделали.
Ведь чем дальше откладываешь инвестиции, тем лучше вроде как.
Если на заказ - то всё хорошо вроде - бабло срубили, теперь отдельно за рефакторинг заплатят.Заказчик хочет новых фич. Он не понимает как можно платить за рефакторинг. Он не знает такого слова.
> Заказчик хочет новых фич.
Производительность его устраивает?
Если нет - надо платить, однако
Производительность его устраивает?
Если нет - надо платить, однако
Хорошо, профилирование тебе покажет, что тормоза в fork + exec. Согласись, утверждать, что виноват 1 % кода там где выполняется fork + exec более чем глупо?
Хорошо, профилирование тебе покажет, что многие треды спят на каком-то большом мьютексе, пока один владеет им. И наделать много мелких нет возможности. Согласись, утверждать, что виноват 1 % кода где pthread_mutex_lock более чем глупо?
Узкое место может быть размазано по реализации.
Утверждать что-либо без профилирования тем более глупо. В твоем случае заранее неизвестно, насколько один вариант лучше другого, поэтому выбирать надо наиболее подходящий по принципам дизайна системы.
Если структура изменится, то он точно так же сериализуется и ляжет в базу.
Он не десериализуется, если были несовместимые изменения.
Рождается такое решение - объекты Java сериализуются в бинарные последовательности байт, которые хранятся как BLOB. В итоге в базе несколько огромных таблиц, каждая из которых имеет два поля id и blob. Супер! Ничего не планировалось, и структуру базы больше не придется пересматривать, ведь мы можем пулять туда любые объекты. Да и программировать это все очень просто, намного проще чем реализовывать бизнес логику на SQL и PL/SQL.Это все довольно просто и быстро рефакторится.
Конечно в XP есть рефакторинг. Но вот по-моему рефакторинг описанного выше равносилен переписыванию с нуля.
1. Анализируем, какие запросы нас не устраивают по производительности и могут быть перенесены на уровень базы.
2. на основе п.1 выделяем какие поля должны быть вынесены в базу
3. выносим из блоба эти поля непосредственно в таблицу
4. изменяем сериализацию, так чтобы она умела часть объекта сериализовать в поля таблицы.
5. изменяем запрос, чтобы он использовал поля из базы
Пример:
допустим у нас тормозит запрос: select Product where Price < 100
из таблицы: Id, blob делаем таблицу id, blob, price
меняем сериализатор (либо пишем универсальный сериализатор, которому дается имена полей, которые должны быть сохранены отдельно, либо пишем для каждого объекта свой сериалайзер)
на первых этапах, можно хранить данные и в blob-е, и в полях, тогда не надо будет трогать десериализатор.
Утверждать что-либо без профилирования тем более глупо. В твоем случае заранее неизвестно, насколько один вариант лучше другого, поэтому выбирать надо наиболее подходящий по принципам дизайна системы.Один уже выбран. Нельзя его превратить в другой переписав 20 %
Он не десериализуется, если были несовместимые изменения.Ясное дело, что содержимое базы должно быть синхронизировано с текущей версией кода. Можешь не продолжать спор, я вижу что это прекрасно работает. объекты меняются и все отлично ложится в базу и достается.
> Заказчик хочет новых фич.Он размышляет так: "Раньше не тормозило". В его голове не укладывается, что можно платить деньги без появления новой функциональности. Думаю все заказчики такие.
Производительность его устраивает?
> Он размышляет так: "Раньше не тормозило". В его голове не укладывается, что можно платить деньги без появления новой функциональности. Думаю все заказчики такие.
Отдел маркетинга на что? Пусть отрабатывают свои деньги.
Отдел маркетинга на что? Пусть отрабатывают свои деньги.
Это все довольно просто и быстро рефакторится. skip ... skip ... skipТаким образом мы просто сменим десериализацию на "заполнение" объекта. Возможно это даже будет быстрее, чем десериализация. Но будет большая нагрзука на клиент/сервер SQL. Ведь отдавать BLOBы проще, чем несколько полей. Самое главное - не будет изменена общая структура. Бизнес логика по прежнему будет в Java, а база будет просто "надежной файловой системой".
> Таким образом мы просто сменим десериализацию на "заполнение" объекта.
Главное мы уменьшили кол-во получаемых/сканируемых записей из базы для данного запроса.
ps
Реализация бизнес логики внутри базы увеличит производительность только на запросах, которые получают/обновляют только часть записей. Если для запроса необходимо просканировать все записи, то никакая база не поможет увеличить скорость.
Главное мы уменьшили кол-во получаемых/сканируемых записей из базы для данного запроса.
ps
Реализация бизнес логики внутри базы увеличит производительность только на запросах, которые получают/обновляют только часть записей. Если для запроса необходимо просканировать все записи, то никакая база не поможет увеличить скорость.
блобы хранятся в самой записи, или отдельным файлом?
> Если для запроса необходимо просканировать все записи, то никакая база не поможет увеличить скорость.
Маза, если таблица не помещается в память, просмотр базы быстрее, чем обход объектов в виртуальной
памяти с учётом свопинга - последовательный в основном доступ к диску против случайного.
Маза, если таблица не помещается в память, просмотр базы быстрее, чем обход объектов в виртуальной
памяти с учётом свопинга - последовательный в основном доступ к диску против случайного.
В данном случае, может лучше будет сделать свою базу, как, например, сделал lorien. Потому что sql-базы в первую очередь пишутся/оптимизируются под индексный доступ.
Если индексного доступа нет, то и особых преимуществ у sql-базы - нет.
Если индексного доступа нет, то и особых преимуществ у sql-базы - нет.
Ну типа в основном наверное будет индексный, но и полное сканирование само по себе может вполне нормально работать.
Если примерно в таком порядке, как ты написал, делать, то на каждом этапе будет прирост производительности.
Чего хочет от SQL, я не знаю, понятно же, что ничего чудесного внутри базы нет, и если алгоритм на Java будет всё ещё
работать медленно после устранения проблемы со свопингом, то откуда уверенность, что переписав это на PL/SQL или хз на
чем ещё, что-то ускорится.
Если примерно в таком порядке, как ты написал, делать, то на каждом этапе будет прирост производительности.
Чего хочет от SQL, я не знаю, понятно же, что ничего чудесного внутри базы нет, и если алгоритм на Java будет всё ещё
работать медленно после устранения проблемы со свопингом, то откуда уверенность, что переписав это на PL/SQL или хз на
чем ещё, что-то ускорится.
Один уже выбран. Нельзя его превратить в другой переписав 20 %
А кто сказал, что другой будет быстрее?
объекты меняются и все отлично ложится в базу и достается.
Так в чем проблема тогда?
Полностью согласен, я о том же.
Теоретический анализ.Один уже выбран. Нельзя его превратить в другой переписав 20 %А кто сказал, что другой будет быстрее?
В производительности.объекты меняются и все отлично ложится в базу и достается.Так в чем проблема тогда?
Главное мы уменьшили кол-во получаемых/сканируемых записей из базы для данного запроса.
Там еще такова структура объектов, что "недозаполненный" объект бесполезен. Нужно именно доставать объект полностью. Я похоже плохо пояснил в чем тормоза. Сейчас объясню. Тормоза в процессе сериализации и последующей линковки объектов друг с другом. Все они связаны друг с другом кучей перекрестных ссылок. Это все действительно просто и удобно в поддержке и понимании. Но только вот память не резиновая. Процесс старта длится минут 20, а потом сжирается полгига памяти. То есть тормоза не в работе с БД.
P.S. Блобы конечно хранятся в самой записи.
Чего хочет от SQL, я не знаю, понятно же, что ничего чудесного внутри базы нет, и если алгоритм на Java будет всё ещёТо, что сейчас держится в объектах должно быть в нормально структурированной базе. В объектах не должно быть данных, кроме тех с которыми работают непосредственно сейчас.
работать медленно после устранения проблемы со свопингом, то откуда уверенность, что переписав это на PL/SQL или хз на
чем ещё, что-то ускорится.
Смотри, в качестве аналога возьмем считалку траффика. Создается объект на каждого юзера, каждый платеж, каждый компьютер и т.п. Конечно такие монстроидные таблицы как детализация в память не грузятся. Дальше все это сидит в памяти. Предположим юзер заплатил бапки, вызывается user->in_money который по ссылкам находит объект его счета пополняет его, создает объект платежа, по ссылке лезет в объект компа и вызывает comp->razban. Все очень красиво и объекто. Куда более майнтайнабл чем хранимая процедура атомарно обновляющая таблицы users, comps, incomes.
А где вообще XP применяется? Не слышал о нем в крупных западных компаниях типа IBM или Microsoft. Да и в наших из тех, что знаю, им и не пахнет - RBC, CBOSS, Abbyy.
Надо ли это понимать так, что XP имеет смысл только для "небольших" програмных продуктов и фирм?
Надо ли это понимать так, что XP имеет смысл только для "небольших" програмных продуктов и фирм?
> В объектах не должно быть данных, кроме тех с которыми работают непосредственно сейчас.
А типа если объект будет десериализовываться, только когда к нему обратятся по ссылке?
А как только с ним работа закончится, обратно сворачиваться?
Вроде бы это не очень трудно, и требования к памяти сократятся.
А типа если объект будет десериализовываться, только когда к нему обратятся по ссылке?
А как только с ним работа закончится, обратно сворачиваться?
Вроде бы это не очень трудно, и требования к памяти сократятся.
А типа если объект будет десериализовываться, только когда к нему обратятся по ссылке?Я кстати это предлагал. Чего-то девелоперы не оценили... Может быть слишком уж часты к объектам обращения.
А как только с ним работа закончится, обратно сворачиваться?
Вроде бы это не очень трудно, и требования к памяти сократятся.
> То, что сейчас держится в объектах должно быть в нормально структурированной базе. В объектах не должно быть данных, кроме тех с которыми работают непосредственно сейчас.
Какая от этого польза?
А минусы получаем большие, как ты уже верно заметил, если все запихать в базу, то такого монстр очень тяжело менять.
Для гибридного случая, небольшие изменения очень хорошо проводятся.
> Создается объект на каждого юзера, каждый платеж, каждый компьютер и т.п.
Так значит надо первым рефакторингом, к тяжелым объектам применить паттерн "Lazy object", т.е. вместо объекта создается смарт-поинтер, которые уже только при реальных обращениях грузится из базы.
Причем такие объекты (например, самые неиспользуемые) могут периодически выгружаться из памяти, оставляя опять только smart-поинтеры.
Какая от этого польза?
А минусы получаем большие, как ты уже верно заметил, если все запихать в базу, то такого монстр очень тяжело менять.
Для гибридного случая, небольшие изменения очень хорошо проводятся.
> Создается объект на каждого юзера, каждый платеж, каждый компьютер и т.п.
Так значит надо первым рефакторингом, к тяжелым объектам применить паттерн "Lazy object", т.е. вместо объекта создается смарт-поинтер, которые уже только при реальных обращениях грузится из базы.
Причем такие объекты (например, самые неиспользуемые) могут периодически выгружаться из памяти, оставляя опять только smart-поинтеры.
Так значит надо первым рефакторингом, к тяжелым объектам применить паттерн "Lazy object", т.е. вместо объекта создается смарт-поинтер, которые уже только при реальных обращениях грузится из базы.Эта такая фича Java? Не знал. Интересная мысль.
Причем такие объекты (например, самые неиспользуемые) могут периодически выгружаться из памяти, оставляя опять только smart-поинтеры.
Это не фича Java-ы, это архитектурный паттерн, а далее уже надо думать, как его лучше будет реализовать для данного случая на данном языке.
Проблема в том, что на Java-е нет шаблонов, поэтому код для таких паттернов приходится генерить.
в 1.5 есть, но 1.5 ещё очень кривая
МВ. Там экстремальное не только программирование, а весь процесс работы всех сотрудников %).
> А где вообще XP применяется? Не слышал о нем в крупных западных компаниях типа IBM или Microsoft. Да и в наших из тех, что знаю, им и не пахнет - RBC, CBOSS, Abbyy.
AFAIK, в Микрософте на уровне отдельных команд применяется подход, имеющий много общего с XP-и.
> Надо ли это понимать так, что XP имеет смысл только для "небольших" програмных продуктов и фирм?
Скорее так: одного XP недостаточно для управления большим продуктом, поэтому надо XP совмещать с RUP-ом/MSF-ом и т.д.
AFAIK, в Микрософте на уровне отдельных команд применяется подход, имеющий много общего с XP-и.
> Надо ли это понимать так, что XP имеет смысл только для "небольших" програмных продуктов и фирм?
Скорее так: одного XP недостаточно для управления большим продуктом, поэтому надо XP совмещать с RUP-ом/MSF-ом и т.д.
сюдапочитай
там lazy objects используется тока в путь. да и вообще гораздо более прямая и быстрая замена вашим блобам.
там lazy objects используется тока в путь. да и вообще гораздо более прямая и быстрая замена вашим блобам.
MySQL, средства которого до сих пор (afaik) не позволяют даже вложенных запросов
вообще-то уже можно
, начиная с версии 4.1 правда пока есть только альфа-версияЭто значит, что версии до 5-ой всё равно ни хрена работать не будет. Могу раскопать пример, найденный сотрудником с моей бывшей работы, где простой сменой порядка операндов оператора = в where-кляузе можно было получить разный результат в индексированных таблицах...
понятно же, что ничего чудесного внутри базы нет, и если алгоритм на Java будет всё ещёОбычные SQL-СУБД пишутся с учетом работы с дисковой памятью, и сравнивать их с Java, которая работает в оперативной памяти, не правильно. Если данные умещаются в оперативке, то можно пользоваться (если конечно деньги есть) СУБД, которые сделаны под оперативку, типа TimesTen.
работать медленно после устранения проблемы со свопингом, то откуда уверенность, что переписав это на PL/SQL или хз на
чем ещё, что-то ускорится.
Есть ещё FastDB, если только память.
---
...Я работаю...
---
...Я работаю...
и ADO.NET
Смотри, в качестве аналога возьмем считалку траффика. Создается объект на каждого юзера, каждый платеж, каждый компьютер и т.п. Конечно такие монстроидные таблицы как детализация в память не грузятся. Дальше все это сидит в памяти. Предположим юзер заплатил бапки, вызывается user->in_money который по ссылкам находит объект его счета пополняет его, создает объект платежа, по ссылке лезет в объект компа и вызывает comp->razban. Все очень красиво и объекто. Куда более майнтайнабл чем хранимая процедура атомарно обновляющая таблицы users, comps, incomes.Почему такой подход более удобен в сопровождении (maintainability) не ясно. Структура классов будет напоминать сетевую модель данных. Данные по существу хранятся в объектах, связанных ссылками, т.е. структура данных будет напоминать сетевую модель данных. Кто-то из известных говорил: "Если хотите потерять данные, используйте сетевую модель".
Вообще, не так давно считалось, что объектные базы очень перспективное направление. Ну и где они сегодня? Фирма (названия не помню) лидер рынка объектных БД реализовывала некоторый механизм хранение С++-объектов. Так вот эта фирма была куплена малоизвестной фирмой, занимающейся реляционными БД.
Сейчас наиболее распространена n-уровневая архитектура приложений, в которой данные хранятся на первом уровне в рел. БД, а промежуточные уровни (которые реализуют безнес-логику, и для их реализации используется объектный подход) обмениваются данными с этой БД. Кстати, писать именно хранимую процедуру не обязательно, может промежуточный уровень будет работать напрямую с таблицами.
Но здесь опять все упирается в кол-во кода. и читабельность программы, а значит все упирается в стоимость написания, сопровождения, кол-во ошибок на единицу функциональности.
одно дело писать:
и совсем другое:
например
программист допустил такую ошибку:
credit = select credit from tarriff, users where tariff.id = users.tariffId and users.id = currentId;
через сколько времени эту ошибку увидят и исправят?
одно дело писать:
user.money -= user.tarrif.abonentPay;
if (user.money < user.tariff.credit)
user.comp.ban;
и совсем другое:
abonentPay = select abonentPay from tarriff, users where tariff.id = users.tariffId and users.id = currentUserId;
update money = money - abonentPay from users where users.Id = currentUserId;
money = select money from users where users.id = currentUserId
credit = select credit from tarriff, users where tariff.id = users.tariffId and users.id = currentUserId;
if (money < credit)
update ban=true from comp where comp.id = user.compId and users.id = currentUserId;
например
программист допустил такую ошибку:
credit = select credit from tarriff, users where tariff.id = users.tariffId and users.id = currentId;
через сколько времени эту ошибку увидят и исправят?
надо писать в соответствии с Microsoft Best Practices, тогда такой ошибки вообще не возникнет
Если дело всё в количестве кода, которое пишет программист, то на ADO.Net
выглядит так
Соответствующие SQL-запросы и классы-обертки VS генерит автоматически.
выглядит так
DS.Clear;
sqlDataAdapterTarriff.Fill(DS);
sqlDataAdapterComp.Fill(DS);
sqlDataAdapterUsers.Fill(DS);
//************************************************
DS.usersRow user=DS.users.FindByid(1);
user.money-=user.tarriffRow.abonentPay;
if(user.money < user.tarriffRow.credit)
user.compRow.ban=true;
//************************************************
sqlDataAdapterTarriff.Update(DS);
sqlDataAdapterComp.Update(DS);
sqlDataAdapterUsers.Update(DS);
Соответствующие SQL-запросы и классы-обертки VS генерит автоматически.
В данном случае Fill-ы по умолчанию будут выкачивать из базы таблицы полностью, что будет довольно накладно в случае большой базы.
да, я ожидал этого вопроса
1. В вашем подходе тоже все в памяти
2. В sqlDataAdapter можно написать select ... where..., SQL-запросы обновления VS сгенерит автоматически (проверено).
1. В вашем подходе тоже все в памяти
2. В sqlDataAdapter можно написать select ... where..., SQL-запросы обновления VS сгенерит автоматически (проверено).
В случае Lazy-объектов, как раз в память грузятся только те объекты, с которыми идет работа.
ты используешь Lazy-объекты?
я не знаю, что такое Lazy-объеты. имхо: это напоминает объектную базу, а об этом я уже писал...
я не знаю, что такое Lazy-объеты. имхо: это напоминает объектную базу, а об этом я уже писал...
Ado.Net тоже напоминает объектную базу. И что из этого?
то что ADO.Net использует преимущества реляционной модели хранения и управления данными, при этом реализация бизнес логики идет в объектном подходе. И прописывание связи реляционки и объектной модели идет автоматически.
Ну и в чем различие? Почему Ado.net это нормально, а ленивые объекты - нет?
Ленивые объекты используют преимущества реляционной модели хранения и управления данными, при этом реализация бизнес логики идет в объектном подходе. И прописывание связи реляционки и ленивых объектов идет автоматически.
да не, если под ними лежит реляционка, то всё замечательно. Я же сказал, что не знаю, что такое эти ленивые объекты. В роде как они в Java-е, а я типа .Net выбрал, их там вроде пока не видно, если не так пусть меня поправят...
Что это такое в двух словах я говорил выше.
ps
для .Net-а вот, например, первая попавшаяся ссылка.
http://www.versant.net/eu_en/solutions/dotNet_en
ps
для .Net-а вот, например, первая попавшаяся ссылка.
http://www.versant.net/eu_en/solutions/dotNet_en
ок, спасибо! я почитаю.
Поскольку ты уже знаком и с ADO.Net и с Lazy-объетами, напиши чем лучше или хуже та или другая технология?
P.S. Кстати, Microsoft в Ykon-е обещает везде .Net, интересно как там с этим будет...
я почитаю.Поскольку ты уже знаком и с ADO.Net и с Lazy-объетами,
напиши чем лучше или хуже та или другая технология? P.S. Кстати, Microsoft в Ykon-е обещает везде .Net, интересно как там с этим будет...
в дотнете любая функция - это ленивый объект, т.к. она может компиляться только при первом обращении
А вообще, выглядеть это может так:
А вообще, выглядеть это может так:
public class Lazy: IDisposable
{
Guid id;
public Lazy(Guid ID) {id=ID;}
string name=null;
pubic string Name
{
get
{
if(name==null)
name=DB.GetName(id);
return name;
}
public void Dispose{name=null;}
}
Ado.Net и паттерн "Lazy Object" - это ортогональные понятия, поэтому их нельзя сравнить.
Ado.Net - это технология доступа к данных, причем разноплановая (есть как низкоуровневый доступ - DBReader, так и доступ на уровне бизнес сущностей - типизированные датасеты).
Lazy object - это паттерн, применяющийся для оптимизации вычислений, активно применяется в тех же ФЯ, при работе с матрицами, при работе с базой на уровне бизнес-сущностей и т.д.
Поэтому Ado.Net и Lazy objects скорее дополняют друг друга, чем конфликтуют.
Ado.Net - это технология доступа к данных, причем разноплановая (есть как низкоуровневый доступ - DBReader, так и доступ на уровне бизнес сущностей - типизированные датасеты).
Lazy object - это паттерн, применяющийся для оптимизации вычислений, активно применяется в тех же ФЯ, при работе с матрицами, при работе с базой на уровне бизнес-сущностей и т.д.
Поэтому Ado.Net и Lazy objects скорее дополняют друг друга, чем конфликтуют.
для _нормального_ продукта время не должно быть определяющим фактором, к сожалению, в некоторых российских софтверных компаниях этого не понимаютК сожалению, многие не понимают, что _нормальный_ продукт, выпущенный не вовремя, никому не нужен...
Ado.Net и паттерн "Lazy Object" - это ортогональные понятия, поэтому их нельзя сравнить.
сам же говоришь, что и те и другие применяются при работе с базой на уровне бизнес-сущностей. Тогда почему их нельзя сравнивать?
небольшая аналогия:
ложка и тарелка - обе применяются для того, чтобы есть.
но сравнивать их между собой проблематично, и даже непонятно по каким критериям сравнивать.
ложка и тарелка - обе применяются для того, чтобы есть.
но сравнивать их между собой проблематично, и даже непонятно по каким критериям сравнивать.
есть одной ложкой или одной тарелкой в большинсте случаев проблематично, а Ado.Net без "Lazy Object" прекрасно обходится и наоборот.
восточные народы прекрасно обходятся без ложек, и ловко едят плов руками
в крестьянской семье - все тоже успешно обходятся без тарелок, и едят прямо из одного котелка.
т.е. Ado.Net и Lazy-объекты - это дополняющие друг друга объекты, также как дополняют друг друга богатство и здоровье: можно хорошо жить за счет одного богатства, можно хорошо жить за счет одного здоровься, но лучше хорошо жить за счет богатства и здоровья. И так же, как тяжело сравнить, что лучше богатство или здоровье, также тяжело сравнить, что лучше Ado.net или Lazy-объекты.
в крестьянской семье - все тоже успешно обходятся без тарелок, и едят прямо из одного котелка.
т.е. Ado.Net и Lazy-объекты - это дополняющие друг друга объекты, также как дополняют друг друга богатство и здоровье: можно хорошо жить за счет одного богатства, можно хорошо жить за счет одного здоровься, но лучше хорошо жить за счет богатства и здоровья. И так же, как тяжело сравнить, что лучше богатство или здоровье, также тяжело сравнить, что лучше Ado.net или Lazy-объекты.
начинаем далеко отклоняться от темы, но немного прокоментирую , по существу напишу чуть позже.
за счет одного богатства иногда жить не получится, например, если у человека рак или спид, то богатство ему не поможет.
Короче аналогия не совсем удачная, "хорошо жить" слишком неопределнное понятие.
, по существу напишу чуть позже.за счет одного богатства иногда жить не получится, например, если у человека рак или спид, то богатство ему не поможет.
Короче аналогия не совсем удачная, "хорошо жить" слишком неопределнное понятие.
хорошо разработанная (написанная) программа - это тоже очень эфемерное понятие.
Первый и наиболее важный для меня вопрос.
ADO.Net и в частности типизированные датасеты -- это объектное представление реляционной базы через реляционную схему.
FastObjects .NET -- это объектное описание предметной области.
Ты же сам писал, об отдельном описании данных .
Второй вопрос, который для меня менее интересен, это то, что FastObjects позволяют представить
Но отцы из Microsoft-а решили, что для тех приложений, где используется.Net, disconnected-модель работы с данными лучше. Ведь в ADO серверные update-курсоры были, а в ADO.Net их нет. Почему они так решили, написано в MSDN.
ADO.Net и в частности типизированные датасеты -- это объектное представление реляционной базы через реляционную схему.
FastObjects .NET -- это объектное описание предметной области.
Ты же сам писал, об отдельном описании данных .
Второй вопрос, который для меня менее интересен, это то, что FastObjects позволяют представить
Database as extension of main memory
Но отцы из Microsoft-а решили, что для тех приложений, где используется.Net, disconnected-модель работы с данными лучше. Ведь в ADO серверные update-курсоры были, а в ADO.Net их нет. Почему они так решили, написано в MSDN.
> Первый и наиболее важный для меня вопрос.
> Второй вопрос, который для меня менее интересен
А как сами вопросы выглядят?
ps
Или в данном случае, слово "вопрос" использовалось, как синоним слов тема, проблематика и т.д.?
> Второй вопрос, который для меня менее интересен
А как сами вопросы выглядят?
ps
Или в данном случае, слово "вопрос" использовалось, как синоним слов тема, проблематика и т.д.?
ps
Или в данном случае, слово "вопрос" использовалось, как синоним слов тема, проблематика и т.д.?
да
и хотел бы услышать твои коментарии
> Ты же сам писал, об отдельном описании данных здесь.
Ни то, ни другое на отдельное описание данных не тянет.
Под отдельным описанием данных мной понимается следующее:
1. Есть внешний язык
2. На этом языке мы описываем понятия(типы) и взаимосвязи между ними
3. Далее по этому описанию генерится база (генерация может быть, как автоматическая, так и полуавтоматическая)
4. Генерируются классы для доступа к базе. Эти классы могут использовать Ado.Net, могут использовать FastObject.Net и т.д.
> Но отцы из Microsoft-а решили, что для тех приложений, где используется.Net, disconnected-модель работы с данными лучше.
Здесь я согласен с Microsoft. Disconnected-модель намного проще в сопровождениии и масштабировании.
но, имхо, отсутствие курсоров не сильно мешает делать "Database as extension of main memory".
Ни то, ни другое на отдельное описание данных не тянет.
Под отдельным описанием данных мной понимается следующее:
1. Есть внешний язык
2. На этом языке мы описываем понятия(типы) и взаимосвязи между ними
3. Далее по этому описанию генерится база (генерация может быть, как автоматическая, так и полуавтоматическая)
4. Генерируются классы для доступа к базе. Эти классы могут использовать Ado.Net, могут использовать FastObject.Net и т.д.
> Но отцы из Microsoft-а решили, что для тех приложений, где используется.Net, disconnected-модель работы с данными лучше.
Здесь я согласен с Microsoft. Disconnected-модель намного проще в сопровождениии и масштабировании.
но, имхо, отсутствие курсоров не сильно мешает делать "Database as extension of main memory".
2. На этом языке мы описываем понятия(типы) и взаимосвязи между ними
В реляционной модели есть домены, взаимосвязи между которыми описываются с помощью отношений (таблиц). Так что в такой формулировке реляционная модель подходит. Ты чего-то не договариваешь
И какой толк с этих доменов?
Реляционная модель много беднее, чем реально необходимая модель данных.
Взять, например, наследование, полиморфные отношения, отношения родитель - подчиненная запись, деревья, мета-типы, мета-отношения и т.д. - все это, напрямую, нельзя выразить через реляционную модель.
Поэтому необходим внешний язык.
Реляционная модель много беднее, чем реально необходимая модель данных.
Взять, например, наследование, полиморфные отношения, отношения родитель - подчиненная запись, деревья, мета-типы, мета-отношения и т.д. - все это, напрямую, нельзя выразить через реляционную модель.
Поэтому необходим внешний язык.
полиморфные отношения
это что такое? все мои представления о полиморфизме связаны с виртуальными функциями в C++. Но это функции, а не данные.
Реляционная модель много беднее, чем реально необходимая модель данных.имхо, для описания данных это всё лишнее, поэтому ОО базы данных так и не состоялись.
Взять, например, наследование, полиморфные отношения, отношения родитель - подчиненная запись, деревья, мета-типы, мета-отношения и т.д. - все это, напрямую, нельзя выразить через реляционную модель.
В С++/C# это всё есть или будет, тогда почему ты говоришь, что FastObject.Net тоже не подходит.
Возьмем, например, библиотеку.
В библиотеке хранятся книги, журналы, газеты, CD/DVD-диски. это разные типы.
Еще есть карточка вещей, выданных посетителю.
Получается, что у каждой записи в карточке есть полиморфная связь - ссылка или на книгу, или на журнал, или на газету, или на диск.
В библиотеке хранятся книги, журналы, газеты, CD/DVD-диски. это разные типы.
Еще есть карточка вещей, выданных посетителю.
Получается, что у каждой записи в карточке есть полиморфная связь - ссылка или на книгу, или на журнал, или на газету, или на диск.
> имхо, для описания данных это всё лишнее, поэтому ОО базы данных так и не состоялись.
Спорное утверждение.
Тот же Cache в ряде проектов успешно используется.
У ООБД есть четкая ниша - это данные со сложной моделью, но при этом с малым кол-вом записей.
У реляционных БД есть большое преимущество - реляционная алгебра, которая позволяет оптимизировать запросы.
У ООБД такого фундамента нет, что мешает построению эффективных запросов.
> В С++/C# это всё есть или будет, тогда почему ты говоришь, что FastObject.Net тоже не подходит.
В C++/C# - этого всего тоже нет. Там есть средства, чтобы все это реализовать, но нет средств, чтобы это все описать.
Спорное утверждение.
Тот же Cache в ряде проектов успешно используется.
У ООБД есть четкая ниша - это данные со сложной моделью, но при этом с малым кол-вом записей.
У реляционных БД есть большое преимущество - реляционная алгебра, которая позволяет оптимизировать запросы.
У ООБД такого фундамента нет, что мешает построению эффективных запросов.
> В С++/C# это всё есть или будет, тогда почему ты говоришь, что FastObject.Net тоже не подходит.
В C++/C# - этого всего тоже нет. Там есть средства, чтобы все это реализовать, но нет средств, чтобы это все описать.
У ООБД есть четкая ниша - это данные со сложной моделью, но при этом с малым кол-вом записей.а как же gigabase?
У ООБД есть четкая ниша - это данные со сложной моделью, но при этом с малым кол-вом записей.
Попробуй рассказать это авторам ORCA
Там в Objectivity/DB загонялись терабайты...
> а как же gigabase?
Она мало похожа на объектную базу.
Скорее это реляционная база, которая умеет отдавать объекты, а не просто данные.
Фактически - это тоже самое, что, например, реляционная база + ado.net в одном флаконе.
Она мало похожа на объектную базу.
Скорее это реляционная база, которая умеет отдавать объекты, а не просто данные.
Фактически - это тоже самое, что, например, реляционная база + ado.net в одном флаконе.
AFAIK, реляционные базы будут побыстрее, особенно на незапланированных запросах.
В том примере, который я привел - нет. Сливают воду по полной программе, к сожалению.
> имхо, для описания данных это всё лишнее, поэтому ОО базы данных так и не состоялись.
Спорное утверждение.
Тот же Cache в ряде проектов успешно используется.
Вот вот только в ряде, а РДБ в подавляющем большинстве проектов.
У реляционных БД есть большое преимущество - реляционная алгебра, которая позволяет оптимизировать запросы.
У ООБД такого фундамента нет, что мешает построению эффективных запросов.
эффективных в смысле по производительности? т.е. ты утверждаешь, что РДБ доминируют только из-за производительности?
> Вот вот только в ряде, а РДБ в подавляющем большинстве проектов.
Но все равно мне непонятно, как из того, что РДБ чаще используется вытекает тот факт, что
Но все равно мне непонятно, как из того, что РДБ чаще используется вытекает тот факт, что
имхо, для описания данных это всё лишнее
> эффективных в смысле по производительности? т.е. ты утверждаешь, что РДБ доминируют только из-за производительности?
да, особенно по производительности на незапланированных запросах.
да, особенно по производительности на незапланированных запросах.
напрямую , типа экспериментальные данные. Обществу были предложенны ООБД, но оно выбрало РБД.
, типа экспериментальные данные. Обществу были предложенны ООБД, но оно выбрало РБД.Передергиваешь.
Обществу были предложены сетевые, иерархические и реляционные базы.
Общество выбрало реляционные базы, и вбухало кучу средств в развитие реляционных баз.
Далее были предложены ООБД.
Теперь общество мечется между развитыми реляционными базами и первыми ОО-базами.
Результат этих метаний пока не ясен, но все идет к тому, что ООБД потеснят РБД, Т.е. как минимум будет РБД с классами.
Обществу были предложены сетевые, иерархические и реляционные базы.
Общество выбрало реляционные базы, и вбухало кучу средств в развитие реляционных баз.
Далее были предложены ООБД.
Теперь общество мечется между развитыми реляционными базами и первыми ОО-базами.
Результат этих метаний пока не ясен, но все идет к тому, что ООБД потеснят РБД, Т.е. как минимум будет РБД с классами.
Результат этих метаний пока не ясен, но все идет к тому, что ООБД потеснят РБД,так уже лет 7 говорят, пик интереса к ООБД уже прошел
Т.е. как минимум будет РБД с классами.
смотря как туда эти классы прикрутят, РБД всегда требовался дополнительный язык для написания приложений
Sorry, offtopic!
РДБ, это видимо "Реляционные данных базы"... Я в одной фирме как-то работал, так у них такая функция была init_bd типа "инициализировать Bазу Dанных". Я незадумываясь вызвал ее init_db и потом 5 минут материл компилятор, что же ему не нравится?.. Ох уж эта транслитерация...
...что РДБ доминируют...
РДБ, это видимо "Реляционные данных базы"... Я в одной фирме как-то работал, так у них такая функция была init_bd типа "инициализировать Bазу Dанных". Я незадумываясь вызвал ее init_db и потом 5 минут материл компилятор, что же ему не нравится?..
Ох уж эта транслитерация...Оставить комментарий
sergey_m
Я считаю, что это полная херня. Здесь есть мои единомышленники?