Oberon space
General Category => Общий раздел => Тема начата: igor от Февраль 27, 2011, 07:59:02 am
-
Мне нужна система подготовки программистов-конструкторов, способных решать задачи любой сложности по созданию системного ПО (с упором на наиболее актуальные направления - middleware и СУБД). Созданию в коллективе, созданию с нуля, в режиме "технологической независимости".
А вот отсюда по подробней плиз. Насколько технологическая независимость должна быть независима и зачем ставится такое условие и такая задача?
Поддерживаю Илью Ермакова. Необходимо стремиться к технологической независимости.
Но прошу не передёргивать. Это не то же самое, что отрицать все существующие технологии.
Веские основания должны быть для того чтобы использовать какую-либо технологию, а не для того чтобы НЕ использовать.
Скажем Блэкбокс, по моему убеждению, совершенно напрасно замешан на COM. Для этого не было никаких веских оснований, зато должно было усложнить портирование на Линукс. По поводу оснований даже страшно предположить (неужели "прогиб" под Microsoft? :( Не, не верится...)
-
Скажем Блэкбокс, по моему убеждению, совершенно напрасно замешан на COM. Для этого не было никаких веских оснований, зато должно было усложнить портирование на Линукс. По поводу оснований даже страшно предположить (неужели "прогиб" под Microsoft? :( Не, не верится...)
Были основания и очень серьезные ( только вы их не видете, или не хотите ;D ) - получить желаемый результат в условиях ограниченных возможностей и срубить бабло
-
К независимости чего от чего, и до какой степени?
-
К независимости чего от чего, и до какой степени?
Независимости любых новых проектов от "винегрета" всевозможных технологий в той степени, к которой это определяется целями и задачами самого проекта.
Мысль "Чем больше я использую всевозможных технологий в своём новом проекте, тем круче будет мой проект" - не верна.
-
... и срубить бабло
Не знаю на счёт бабла, а вот награду в номинации "за технологическое совершенство" они получили. (Но я бы не стал этим гордиться.)
-
Мысль "Чем меньше я использую всевозможных технологий в своём новом проекте, тем круче будет мой проект" - также не верна.
Вообще крутость проекта не зависит от используемых технологий. Важно соответствие результата поставленным задачам.
-
Скажем Блэкбокс, по моему убеждению, совершенно напрасно замешан на COM. Для этого не было никаких веских оснований, зато должно было усложнить портирование на Линукс. По поводу оснований даже страшно предположить (неужели "прогиб" под Microsoft? :( Не, не верится...)
Ответ:
http://forum.oberoncore.ru/viewtopic.php?f=2&t=3288
-
Мысль "Чем меньше я использую всевозможных технологий в своём новом проекте, тем круче будет мой проект" - также не верна.
Я же просил не передёргивать :)
Использование какой-либо технологии, как я уже написал, должно определяться целями и задачами проекта. Следует также помнить, что "приковать" себя цепями к какой-нибудь технологии в начале реализации проекта легко, а вот отвязаться потом от неё - не соизмеримо трудно.
-
... и срубить бабло
Не знаю на счёт бабла, а вот награду в номинации "за технологическое совершенство" они получили. (Но я бы не стал этим гордиться.)
"на счёт бабла," -это им не удалось.
"награду в номинации "за технологическое совершенство" они получили." - это приятный побочный эффект
"(Но я бы не стал этим гордиться.)" - неудивительно, вы же не любите побочные эффекты.... :-*
-
Следует также помнить, что "приковать" себя цепями к какой-нибудь технологии в начале реализации проекта легко, а вот отвязаться потом от неё - не соизмеримо трудно.
Зачем же цепями? Можно просто веревочками. Не нужно необдуманно завязываться на сторонние решения, это да. Обдуманно – можно. В случае необходимости стороннее решение просто выкидывается и вместо него втыкается другое – стороннее или свое, велосипедное. На то архитектор в проекте и существует, чтобы подобное развитие событий предусмотреть и соломки понавтыкать туда, куда следует.
-
"награду в номинации "за технологическое совершенство" они получили." - это приятный побочный эффект
"(Но я бы не стал этим гордиться.)" - неудивительно, вы же не любите побочные эффекты.... :-*
Спасибо, посмеялсо ;D
-
"награду в номинации "за технологическое совершенство" они получили." - это приятный побочный эффект
"(Но я бы не стал этим гордиться.)" - неудивительно, вы же не любите побочные эффекты.... :-*
Спасибо, посмеялсо ;D
Завсегда ;)
-
В случае необходимости стороннее решение просто выкидывается и вместо него втыкается другое – стороннее или свое, велосипедное.
Увы, но зачастую стороннее решение выкидывается весьма не просто. Пример - тот же COM в Блэкбокс.
Хочу обратить ваше внимание и на такое явление. Многие фирмы плодят новые технологии как из рога изобилия. Microsoft, например. Они это делают, потому что это им коммерчески выгодно. А теперь подумайте, какое отношение их мотивы имеют к Вашему проекту.
-
В случае необходимости стороннее решение просто выкидывается и вместо него втыкается другое – стороннее или свое, велосипедное.
Увы, но зачастую стороннее решение выкидывается весьма не просто. Пример - тот же COM в Блэкбокс.
Хочу обратить ваше внимание и на такое явление. Многие фирмы плодят новые технологии как из рога изобилия. Microsoft, например. Они это делают, потому что это им коммерчески выгодно. А теперь подумайте, какое отношение их мотивы имеют к Вашему проекту.
COM из BB просто не выкидывается потому, что архитекторы не озаботились заранее. Либо, что вероятней, никто не предполагал, что оно через 10 лет будет кому-то ещё нужно в том виде, в котором разрабатывалось сразу :-)
А нашему проекту пофиг, в отличае от ББ, у нас компонентная архитектура :-)
-
А нашему проекту пофиг, в отличае от ББ, у нас компонентная архитектура :-)
Ах.. Ах .. Ах - это что? гнусный намек на то что создатели ББ лоханулись с архитектурой...Последователи Вирта - да как Вы смеете , к конце концов ( прошу прощение если последнии два слова нецензурны) :)
-
Конец концов.. Это уже что-то из разряда функций высших порядков :-)
-
Конец концов.. Это уже что-то из разряда функций высших порядков :-)
Проще, концам - конец ;)
-
Скажем Блэкбокс, по моему убеждению, совершенно напрасно замешан на COM. Для этого не было никаких веских оснований, зато должно было усложнить портирование на Линукс. По поводу оснований даже страшно предположить (неужели "прогиб" под Microsoft? :( Не, не верится...)
НЕ COM!!!!
В ББ сделано ИМХО ГОРАЗДО лучше. Профи С++ признавались, что на освоение "мутных" концепций COM уходило до полугода. Модули-компоненты в ББ не требуют стольких усилий... Вообще усилий по изучению не требуют - все естественно и понятно.
-
В ББ сделано ИМХО ГОРАЗДО лучше. Профи С++ признавались, что на освоение "мутных" концепций COM уходило до полугода. Модули-компоненты в ББ не требуют стольких усилий...
Я говорил не о том, что Блэкбокс предлагает для использования объектную модель COM, а о том, что он реализован с применением COM.
-
Скажем Блэкбокс, по моему убеждению, совершенно напрасно замешан на COM. Для этого не было никаких веских оснований, зато должно было усложнить портирование на Линукс. По поводу оснований даже страшно предположить (неужели "прогиб" под Microsoft? :( Не, не верится...)
НЕ COM!!!!
В ББ сделано ИМХО ГОРАЗДО лучше. Профи С++ признавались, что на освоение "мутных" концепций COM уходило до полугода. Модули-компоненты в ББ не требуют стольких усилий... Вообще усилий по изучению не требуют - все естественно и понятно.
ИМХО, основная проблема в понимании COM в том, что он проецируется на конкретный язык (С++) и на нем же объясняется как это работает. Понятно, что нифига непонятно будет :) Сейчас вспоминаю - агрегация в COM, например, уже чего там только не написано было про нее, магия какая-то. А ведь это просто агрегация :)
P.S. COM в винде не умрет, даже не надейтесь :) Альтернативы в каких-то задачах (виндовый shell, например) ему по-прежнему нет.
-
НЕ COM!!!!
В ББ сделано ИМХО ГОРАЗДО лучше. Профи С++ признавались, что на освоение "мутных" концепций COM уходило до полугода. Модули-компоненты в ББ не требуют стольких усилий... Вообще усилий по изучению не требуют - все естественно и понятно.
Не признаюсь! Далеко не всем приплюснытым профи приходилось разбираться в COM'e, например вот мне было не нужно :-) Ведь COM он где-то там… на винде…
-
В ББ сделано ИМХО ГОРАЗДО лучше. Профи С++ признавались, что на освоение "мутных" концепций COM уходило до полугода. Модули-компоненты в ББ не требуют стольких усилий...
Я говорил не о том, что Блэкбокс предлагает для использования объектную модель COM, а о том, что он реализован с применением COM.
Да, уже понял... :)
-
Объясните уже кто-нибудь из "поддерживающих", что такое "технологическая независимость"? А то уже вторая страница заканчивается, а не очень понятно, о чём разговор... :-\\
-
Например, это наличие отечественных поставщиков по всем категориям системного софта. Пока у нас это имеется только по СУБД, некоторым компиляторам, ОС устаревшего класса. Одна "ласточка" в middleware - это реализация Java Platform - JET от Excelsior.
-
Ах.. Ах .. Ах - это что? гнусный намек на то что создатели ББ лоханулись с архитектурой...Последователи Вирта - да как Вы смеете , к конце концов ( прошу прощение если последнии два слова нецензурны) :)
Вы бы не трепались на темы, Вам неведомые, например, о программной архитектуре.
Про недоработки в ББ я Вам могу изложить больше, чем может нафантазировать любой зритель со стороны.
Как ВСЕ НОРМАЛЬНЫЕ ЛЮДИ, Оминк не пытались сразу объять необъятное, а итерационно строили систему, последовательной доводкой прототипов. Которые с самого начала применялись в реальных задачах, а не выдумывались "от балды". То, что мы имеем сейчас, - это одна из итераций. Рабочий, отлично эксплуатируемый, опережающий по общей совокупности качеств практически всё известное... но прототип. Который нужно бы ещё один-два раза прореинжинирить - до исчезновения "шероховатостей" и "времянок".
-
Ах.. Ах .. Ах - это что? гнусный намек на то что создатели ББ лоханулись с архитектурой...Последователи Вирта - да как Вы смеете , к конце концов ( прошу прощение если последнии два слова нецензурны) :)
Вы бы не трепались на темы, Вам неведомые, например, о программной архитектуре.
Про недоработки в ББ я Вам могу изложить больше, чем может нафантазировать любой зритель со стороны.
Как ВСЕ НОРМАЛЬНЫЕ ЛЮДИ, Оминк не пытались сразу объять необъятное, а итерационно строили систему, последовательной доводкой прототипов. Которые с самого начала применялись в реальных задачах, а не выдумывались "от балды". То, что мы имеем сейчас, - это одна из итераций. Рабочий, отлично эксплуатируемый, опережающий по общей совокупности качеств практически всё известное... но прототип. Который нужно бы ещё один-два раза прореинжинирить - до исчезновения "шероховатостей" и "времянок".
Да нууу...а не вы ли "всеведущий архитектор" с полгода назад на форуме трепались - о "технологическом совершенстве и красоте архитектуры ББ" - которую почему то , никто не замечает :-* , а сейчас у вас точка зрения изменилась али как?
-
Таки предлагаю определиться, текущий ББ либо прототип, и тогда егов продакшн пускать нельзя, либо это таки уже продукт, и тогда там имеются ошибки архитектуры (вроде впаяного в Hosts COM'a) но в продакшн его пускать можно.
-
Есть дисер Шиперского "Insight EthOS" - про архитектурные решения, разработанные на самой начальной стадии ББ.
http://forum.oberoncore.ru/viewtopic.php?f=60&t=1966
Эта работа, как и другие Шиперского, фундаментальна для современной архитектуры ПО - и сие есть факт.
Так же, как фундаментален ББ, в котором, в основном, эта архитектура из EthOS перенесена.
И есть вопрос реализации конкретных модулей, каких-то отдельных программных интерфейсов и т.п. Где остаются "времянки" или компромиссы.
Суть хорошей архитектуры ПО как раз в том, чтобы дать возможность плюнуть на конкретные детали и отложить их уточнение на как можно более поздний этап. И получить рабочий и эволюционирующий прототип.
И как раз эволюция и безболезненная, стабильная, совершенно безглючная эксплуатация прототипов - доказательство успешности архитектуры. Ни в какой из бета-версий не было выявлено ни одной проблемы, которая проявилась бы в падениях среды и софта на её основе или вообще в каком-либо непредсказуемом поведении.
-
Таки предлагаю определиться, текущий ББ либо прототип, и тогда егов продакшн пускать нельзя, либо это таки уже продукт, и тогда там имеются ошибки архитектуры (вроде впаяного в Hosts COM'a) но в продакшн его пускать можно.
В том и суть, что при нормальной разработке не должно быть границы между "продакшном" и "прототипом".
Как можно раньше выходить на эксплуатацию (при этом стабильную) - и запускать процесс эволюции.
А все эти альфы, беты, патчи нужно постепенно оставлять прошлом.
-
В том и суть, что при нормальной разработке не должно быть границы между "продакшном" и "прототипом".
Как можно раньше выходить на эксплуатацию (при этом стабильную) - и запускать процесс эволюции.
А все эти альфы, беты, патчи нужно постепенно оставлять прошлом.
Т.е. ты таки за экстремальное программирование? :-)
-
В том и суть, что при нормальной разработке не должно быть границы между "продакшном" и "прототипом".
Как можно раньше выходить на эксплуатацию (при этом стабильную) - и запускать процесс эволюции.
А все эти альфы, беты, патчи нужно постепенно оставлять прошлом.
Т.е. ты таки за экстремальное программирование? :-)
+1000 :-*
-
А кстати, что предполагается делать с операционкой? Ведь это альфа и омега независимости. Ужель опять линукс? Если да, то не понятно зачем тот же JET, когда есть OpenJDK – можно использовать с тем же успехом что и линукс например.
Да, и с железом что?
-
В том и суть, что при нормальной разработке не должно быть границы между "продакшном" и "прототипом".
Как можно раньше выходить на эксплуатацию (при этом стабильную) - и запускать процесс эволюции.
А все эти альфы, беты, патчи нужно постепенно оставлять прошлом.
Т.е. ты таки за экстремальное программирование? :-)
Да, в экстремальном программировании много хороших зерён.
Итерационность, пригодность прототипов для эксплуатации, парное программирование (или взаимный аудит кода)...
Но оно должно быть хорошо методически обеспечено (программисты обучены писать правильный и единообразный код, архитектура должна строиться компонентно и т.п.).
Плюс в XP есть неправильная установка - "надо думать только о том, чтобы заработало". Но.. чтобы правильно вести машину, надо смотреть не под колёса, а вперёд, с интервалом опережения в 5 секунд :) Так и тут. Надо думать не о сегодняшнем прототипе, а о том, чтобы можно было легко сделать и завтрашний, и послезавтрашний - т.е. упор делать не на кодировании, а на архитектуре и более мелких проектных приёмах, которые позволяют не "замораживать" сегодняшний вариант, а откладывать уточнения на как можно позже.
-
А кстати, что предполагается делать с операционкой? Ведь это альфа и омега независимости. Ужель опять линукс? Если да, то не понятно зачем тот же JET, когда есть OpenJDK – можно использовать с тем же успехом что и линукс например.
Да, и с железом что?
Что-что... "Эльбрус-3М", например, доводить до массового применения. В том числе налаживать выпуск спец. техники типа тонких клиентов и т.п.
Операционка... Сложный вопрос, ибо её роль сегодня падает (сверху образуется прослойка middleware для того же Software-As-Service, а любая бизнес-автоматизация будет делаться уже только по этой технологии - даже если сервер для сервиса будет находиться у самой компании, а не у стороннего поставщика). Можно подождать, пока роль ещё упадёт - и сделать ОС уже в этой новой роли, просто как прослойку между оборудованием и платформой выполнения.
-
Угу. В екстремальном программировании таки много уделяется именно сработанности народа. В частности должен быть единый стиль программирования, ну или не единый, но чтобы каждый легко воспринимал стиль каждого.
Да, а выхлоп повышается не только и не столько благодаря аудиту кода, а з за того, что по сути раз уж собрались вдвоем, то придется работать (слежение друг за другом), а например не в форум писать :-) Вместо внешнего надсмотрщика работник смотрит на работником кнут у каждого в руках. + знания по коду дублируются в головах, следовательно увольнять/менять народ можно более свободно. Правда эта методика хорошо работает для средний и ниже среднего программистов. Для сильных программистов она не работает (дает обратный результат – производительность и качество кода снижается), были исследования на эту тему.
-
Что-что... "Эльбрус-3М", например, доводить до массового применения. В том числе налаживать выпуск спец. техники типа тонких клиентов и т.п.
Сколь я помню, альбрус-3м у нас даже не производится. В тайване его делают. Как и эльбрусы которые спарки.
Операционка... Сложный вопрос, ибо её роль сегодня падает (сверху образуется прослойка middleware для того же Software-As-Service, а любая бизнес-автоматизация будет делаться уже только по этой технологии - даже если сервер для сервиса будет находиться у самой компании, а не у стороннего поставщика). Можно подождать, пока роль ещё упадёт - и сделать ОС уже в этой новой роли, просто как прослойку между оборудованием и платформой выполнения.
Дык она давным давно в этой роли. Сверху операционки сидит какой-нибудь позикс и вперед. :-) Что там под позиксом никого по большей части не интересует. Главное чтобы драйвера были и был стандартный позикс.
Вообще, такое ощущение, что вы там пытаетесь соорудить нечто на черный день, например чтобы в случае войны в стране было всё своё, и от сигнала со спутника вся IT-инфраструктура не сдохла. Так вот – значимость ОСи для такой задачи не падает, возможно даже возрастает.