Oberon space
General Category => Общий раздел => Тема начата: DIzer от Декабрь 21, 2012, 06:27:42 am
-
Предлагаю желающим высказаться на эту тему..
Моя точка зрения - ВРАГУ
-
Всё лучшее -- детям же!!!
-
Всё лучшее -- детям же!!!
Geniepro, не понимаю - с чего такая любовь к детям... осторожнее, я слышал, сейчас за это в тюрьму посадить могут....
-
Всё лучшее -- детям же!!!
Geniepro, не понимаю - с чего такая любовь к детям... осторожнее, я слышал, сейчас за это в тюрьму посадить могут....
Если дети будут заниматься ЭТИМ с блекбоксом под присмотром info21 -- то всё будет в порядке. Хотя... может быть info21 просто не все фотки опубликовал о своём классе двенадцатилеток? о_О
-
Если дети будут заниматься ЭТИМ с блекбоксом под присмотром info21 -- то всё будет в порядке. Хотя... может быть info21 просто не все фотки опубликовал о своём классе двенадцатилеток? о_О
то есть вы рекомендуете его 12 летним детям под чутким руководством info21? - Accepted
-
то есть вы рекомендуете его 12 летним детям под чутким руководством info21? - Accepted
Ну да, вроде бы положительный опыт уже имеется: http://www.inr.ac.ru/~info21/troitsklicej/vtorojetap.htm
-
http://oberspace.dyndns.org/index.php/topic,403.msg11738.html#msg11738
-
http://oberspace.dyndns.org/index.php/topic,403.msg11738.html#msg11738
Принимаю это как согласие.. и резюмирую
Из ответа Ильи
следует:
Что ББ -
1. "для многих, кто мечтает послать нахрен мейнстрим!"
2. его следует послать нах - поскольку там содержится фактическое согласие с высказыванием Geniepro...
-
Предлагаю желающим высказаться на эту тему..
Моя точка зрения - ВРАГУ
Развлекаешься? :-)
На самом деле чем этот ужасный ББ хуже чем турбопаскаль, который до сих пор широко используется?
Единственный минус для обучающегося - отсутствие автоматической подсветки синтаксиса (ключевые слова капсом не могут ее заменить).
-
На самом деле чем этот ужасный ББ хуже чем турбопаскаль, который до сих пор широко используется?
Отладчика нет.
-
На самом деле чем этот ужасный ББ хуже чем турбопаскаль, который до сих пор широко используется?
Отладчика нет.
Зато после трапа есть удобная инспекция всего состояния системы. Удобней чем то что у борланда в отладчике.
-
Зачем же до трапа доводить?
-
Зачем же до трапа доводить?
Дык понаффтыкать ассертов, что бы если программа работает не так как предполагалось сразу же вскрытие сделать.
-
Зачем же до трапа доводить?
Дык понаффтыкать ассертов, что бы если программа работает не так как предполагалось сразу же вскрытие сделать.
Да, с трапами нужно дружить. Как и с исключениями. Не понимаю почему их многие пытаются избегать.
-
то есть вы рекомендуете его 12 летним детям под чутким руководством info21? - Accepted
Ну да, вроде бы положительный опыт уже имеется: http://www.inr.ac.ru/~info21/troitsklicej/vtorojetap.htm
С тех пор, однако, уже 4-5 лет прошло, этим пятиклассникам уже лет 17.
Любопытно, чем они щас занимаются, стали ли они программистами и если да, то на чём же программируют...
-
Развлекаешься? :-)
На самом деле чем этот ужасный ББ хуже чем турбопаскаль, который до сих пор широко используется?
Единственный минус для обучающегося - отсутствие автоматической подсветки синтаксиса (ключевые слова капсом не могут ее заменить).
Отчасти, просто в очередной раз пытаюсь составить (скорректировать) ЦЕЛОСТНОЕ мнение о ББ , не вдаваясь в детали... - ибо в коровне это по понятным причинам это сделать нельзя - там одна точка зрения.
Насчет минусов для обучающегося - это частности (при желании я могу более специфично высказаться на эту тему - за последние пару лет я поработал над этой темой)
-
На самом деле чем этот ужасный ББ хуже чем турбопаскаль, который до сих пор широко используется?
Отладчика нет.
хотелось бы ответов "в тему" - КОМУ (какой категории пользователей) ВЫ МОГЛИ БЫ РЕКОМЕНДОВАТЬ ББ - В ТЕКУЩЕМ СОСТОЯНИИ.
-
Могу смело ББ порекомендовать тем, кого задолбал "мейнстрим" (то есть все обычное) и хочется чего-то эдакого, не как у всех.
PS. Между прочим, если бы я в свое время 8 лет не использовал BeOS как основную OS, то до оберонов я бы скорее всего не добрался бы.
-
хотелось бы ответов "в тему" - КОМУ (какой категории пользователей) ВЫ МОГЛИ БЫ РЕКОМЕНДОВАТЬ ББ - В ТЕКУЩЕМ СОСТОЯНИИ.
Я сам не стал жрать этот фрукт, поэтому никому порекомендовать не могу.
-
Могу смело ББ порекомендовать тем, кого задолбал "мейнстрим" (то есть все обычное) и хочется чего-то эдакого, не как у всех.
PS. Между прочим, если бы я в свое время 8 лет не использовал BeOS как основную OS, то до оберонов я бы скорее всего не добрался бы.
Do not accepted ,ибо идентично с точкой зрения Ильи (№1)
-
хотелось бы ответов "в тему" - КОМУ (какой категории пользователей) ВЫ МОГЛИ БЫ РЕКОМЕНДОВАТЬ ББ - В ТЕКУЩЕМ СОСТОЯНИИ.
Я сам не стал жрать этот фрукт, поэтому никому порекомендовать не могу.
НИКОМУ - эквивалентно нах (точка зрения Ильи №2) - not accepted.
-
Do not accepted ,ибо идентично с точкой зрения Ильи (№1)
Наверно я не ясно выразился. Есть беженцы (которым в мейнстриме не уютно), которые ищут себе место для постоянного проживания -- это, насколько я понял, случай Ильи.
А есть туристы, которым скучно в мейнстриме, они не ищут место постоянного проживания (жить и в мейнстриме можно), они путешествуют. Политкорректно такие путешествия называются так: "использовать ББ для самообучения и повышения квалификации".
-
Do not accepted ,ибо идентично с точкой зрения Ильи (№1)
Наверно я не ясно выразился. Есть беженцы (которым в мейнстриме не уютно), которые ищут себе место для постоянного проживания -- это, насколько я понял, случай Ильи.
А есть туристы, которым скучно в мейнстриме, они не ищут место постоянного проживания (жить и в мейнстриме можно), они путешествуют. Политкорректно такие путешествия называются так: "использовать ББ для самообучения и повышения квалификации".
Понятно.. малограмотным чудакам которые хотят быть "не такими как все" -так?
-
Понятно.. малограмотным чудакам которые хотят быть "не такими как все" -так?
И им тоже. Но также грамотным, но скукчающим.
А еще - IT-археологам.
-
ИМХО единственный фатальный недостаток BB - это отсутствие развития.
Есть еще некоторые серьезные недостатки (отсутствие поддержки многопоточности, привязка к wintel, и т.д.), но они не фатальны.
Component Pascal - один из лучших языков на сегодня. (лучше имхо только C# в некоторых моментах)
BlackBox - лучшая из худших сред разработки. :D
-
ИМХО единственный фатальный недостаток BB - это отсутствие развития.
Есть еще некоторые серьезные недостатки (отсутствие поддержки многопоточности, привязка к wintel, и т.д.), но они не фатальны.
Component Pascal - один из лучших языков на сегодня. (лучше имхо только C# в некоторых моментах)
BlackBox - лучшая из худших сред разработки. :D
в тему, ПЛИЗ
-
Понятно.. малограмотным чудакам которые хотят быть "не такими как все" -так?
И им тоже. Но также грамотным, но скукчающим.
А еще - IT-археологам.
Принято
-
инициативным разработчикам
-
инициативным разработчикам
это как?
-
инициативным разработчикам
это как?
берёшь рашпиль и за дело
-
инициативным разработчикам
это как?
берёшь рашпиль и за дело
понятно - дрочунам?
-
дрочунам?
это, как раз, неинициативные - их всё устраивает
-
дрочунам?
это, как раз, неинициативные - их всё устраивает
не вы не так меня поняли, это те кто берет напильники (дрочевые - они же рашпили) и "дрочат" по поводу и без оного...
-
Могу смело ББ порекомендовать тем, кого задолбал "мейнстрим" (то есть все обычное)
Я бы не называл "мейнстрим" обычным.
Я под словом "мейнстрим" ощущаю те технологии, которые базируется на чувстве "собственной значимости ИКТ".
Оппозиция же к "мейнстриму" - это любые технологии, построенные "скромно", с минимализмом, чтобы сохранить мозги людям чистыми для реальной работы.
Такие тенденции - всюду: идут лесом сложные СУБД, взамен приходят такие, которые можно сделать за полгода (NoSQL и проч.; посмотрите, например, на lectorium.tv лекции "Яндекса" про СУБД).
Идут лесом J2EE, появляются такие фреймворки, как Play!.
И т.п.
-
Добавлю, что ББ также вполне можно рекомендовать тем у кого рассчетные задачи, причем задачи не ложащиеся 1 в 1 на какой-либо известный метод (то есть взять матлабик и в одну строчку все записать не выйдет). Причем не эпизодические задачи, а постоянные - в этом случае в ББ можно свить вполне уютное гнездо (видимо уютней чем то, что свили в Энергии на PL/I). Единственное что - задачи должны быть не критичны к времени исполнения (то есть постоянный множитель не должен быть критичен), ибо компилятор не оптимизирующий и не оптимальный.
Также, пожалуй, можно порекомендовать тем, кто экспериментирует с алгоритмикой (скажем изобретает очередной улучшизм алгоритма A*) - гнездо также можно свить уютное, где цикл разработки будет короче.
Да, это все при условии, что у людей нет времени, или им не интересно, изучить какой-нибудь "большой" ЯП. То есть не IT-профи.
-
Ещё есть такая задачка:
- получить короткий "круг" от совершенного новичка в программировании до грамотного кадра. На базе мейнстрима максимум, на что хватает ИТ-компаний - это подбирать на старших курсах (в надежде, что хоть что-то заложено на младших). А уложить всю подготовку от "нуля" и до полноценного сотрудника года в два - нереально на базе мейнстрима.
А очень, между прочим, соблазнительно для ИТ-компании - не выискивать на выпуске подходящих, а без особых затрат "вылепить" и уже "прикормить" в том возрасте, когда он ещё учится и не "загружен житейским геморроем" :)
Однако сегодня для ИТ-компаний этап начального формирования программиста - тайна за семью печатями. "Самозарождение". Остаётся только рыскать в поисках уже "самозародившихся" (самостоятельно или благодаря таки ВУЗу).
У меня есть пример цикла от полного "нуля" до создания реального небольшого приложения (на КП/ББ) ценой в $4000 длиной в год. Это очень способный парень, но в ИТ был совершенно "чист".
-
Могу смело ББ порекомендовать тем, кого задолбал "мейнстрим" (то есть все обычное)
Я бы не называл "мейнстрим" обычным.
Я под словом "мейнстрим" ощущаю те технологии, которые базируется на чувстве "собственной значимости ИКТ".
Оппозиция же к "мейнстриму" - это любые технологии, построенные "скромно", с минимализмом, чтобы сохранить мозги людям чистыми для реальной работы.
Эмм.. То есть Scala, Common Lisp и Haskell - это мейнстрим, а вот Си и Java (язык) оппозиция мейнстрму? ;-)
Давай все же придерживаться изначальных значений слов. А то ведь и слово "професионал" можно произносить ругательно (есть некоторые товарищи, которые его так и произносят, видимо делетанты это их всё).
Такие тенденции - всюду: идут лесом сложные СУБД, взамен приходят такие, которые можно сделать за полгода (NoSQL и проч.; посмотрите, например, на lectorium.tv лекции "Яндекса" про СУБД).
Идут лесом J2EE, появляются такие фреймворки, как Play!.
При этом и NoSQL и Play! это мейнстрим :-)
У меня ощущение складывается, что ты смешиваешь мейнстрим с ынтырпрайзом :-)
Ынтырпрайз он не базируется на чувстве собственной значимости IT, он базируется на солидных компаниях и их чувстве собственной значимости. Пример - Corba, SAP, J2EE, COM.
-
Добавлю, что ББ также вполне можно рекомендовать тем у кого рассчетные задачи, причем задачи не ложащиеся 1 в 1 на какой-либо известный метод (то есть взять матлабик и в одну строчку все записать не выйдет). Причем не эпизодические задачи, а постоянные - в этом случае в ББ можно свить вполне уютное гнездо (видимо уютней чем то, что свили в Энергии на PL/I). Единственное что - задачи должны быть не критичны к времени исполнения (то есть постоянный множитель не должен быть критичен), ибо компилятор не оптимизирующий и не оптимальный.
Также, пожалуй, можно порекомендовать тем, кто экспериментирует с алгоритмикой (скажем изобретает очередной улучшизм алгоритма A*) - гнездо также можно свить уютное, где цикл разработки будет короче.
Да, это все при условии, что у людей нет времени, или им не интересно, изучить какой-нибудь "большой" ЯП. То есть не IT-профи.
т.е. это эквивалентно
1. дрочунам (людям у который есть постоянный "зуд" ) от программирования
2. Исследователям ведущим разработки в изолированных областях, не требующих серьезных вычислительных ресурсов, по несчастью, не умеющих программировать вообще (соответственно не знающих иных альтернатив)
так?
-
Да, со смыслами слов иногда туго.
Тем не менее, "мейнстримовое мышление" - это именно типа того, что я описал.
Инструменты тут не сами по себе показатель.
-
При этом и NoSQL и Play! это мейнстрим :-)
У меня ощущение складывается, что ты смешиваешь мейнстрим с ынтырпрайзом :-)
По объективным причинам (усложнять дальше некуда) анти-мейнстрим становится мейнстримом :)
Сейчас любить NoSQL модно, но года 4 назад расскажи я кому-нибудь тут, что так оно и будет, меня бы закидали чем-нибудь :)
-
Я бы не называл "мейнстрим" обычным.
Я под словом "мейнстрим" ощущаю те технологии, которые базируется на чувстве "собственной значимости ИКТ".
Оппозиция же к "мейнстриму" - это любые технологии, построенные "скромно", с минимализмом, чтобы сохранить мозги людям чистыми для реальной работы.
Такие тенденции - всюду: идут лесом сложные СУБД, взамен приходят такие, которые можно сделать за полгода (NoSQL и проч.; посмотрите, например, на lectorium.tv лекции "Яндекса" про СУБД).
Идут лесом J2EE, появляются такие фреймворки, как Play!.
И т.п.
Вы так говорите, будто NoSQL могут заменить сложную SQL СУБД. Это две параллельные ветки, а никак не альтернатива друг другу.
То же касается и остального мэйнстрима.
-
Нюансов много, но то, что навороченные СУБД не масштабируются, не адаптируются к высокой нагрузке и к нерегулярным, изменчивым данным - це факт.
И никакую РСУБД в крупных проектах теперь не встретишь без ORM (Object-Realtion-Mapping). Но при такой схеме использования РСУБД становится во многом "тупо хранилищем", основная сложная функция, оставляемая за РСУБД - это разные выборки, которые не опишешь императивно (гуляя от ID к ID).
И аутентификация, и многое другое оказывается уровнем выше.
Так что рано или поздно неиспользуемые при ORM-режиме "рудименты" просто "отвалятся".
ORM - объективная необходимость, но он сам по себе "гибриден", сложен. Значит, произойдёт некий виток упрощения.
-
Я, может быть, отбрасываю ряд нюансов, деталей, выражая своё ощущение главной тенденции...
Когда никто даже помыслить не может "жить без СУБД", а ты делаешь "No-СУБД"-решения, просто потому, что не хочешь вляпываться в избыточную сложность чужих СУБД, а потом тройку лет спустя все носятся с воплями "No-SQL, No-SQL", то, наверное, ощущение моё не совсем беспочвенное, а? :)
-
Нюансов много, но то, что навороченные СУБД не масштабируются, не адаптируются к высокой нагрузке и к нерегулярным, изменчивым данным - це факт.
А можно конкретнее? Какие именно СУБД вы имеете ввиду?
Что в вашем понимании "масштабирование"?
Что в вашем понимании адаптация к высокой нагрузке?
И что такое нерегулярные изменчивые данные? ???
-
Нюансов много, но то, что навороченные СУБД не масштабируются, не адаптируются к высокой нагрузке и к нерегулярным, изменчивым данным - це факт.
И никакую РСУБД в крупных проектах теперь не встретишь без ORM (Object-Realtion-Mapping). Но при такой схеме использования РСУБД становится во многом "тупо хранилищем", основная сложная функция, оставляемая за РСУБД - это разные выборки, которые не опишешь императивно (гуляя от ID к ID).
И аутентификация, и многое другое оказывается уровнем выше.
Так что рано или поздно неиспользуемые при ORM-режиме "рудименты" просто "отвалятся".
ORM - объективная необходимость, но он сам по себе "гибриден", сложен. Значит, произойдёт некий виток упрощения.
Вы просто не в теме :).
Расскажите IBM, о том что DB/2 не масштабируется, не адаптируется к высокой нагрузке и т.п.
ORM ORM`у рознь. Есть такие, которые полностью абстрагируют приложение от базы, да и сами от базы отстранены (hibernate, например), а есть такие, которые не теряют связь с подлежащей базой (например, iBatis) при этом весь SQL пишется ручками, как и его маппинг на высокоуровневые объекты.
В первом случае, имеем высокую переносимость. Разрабатываем на одной базе, тестируем на другой, эксплуатируем на третьей. Во втором, - можем получить максимально высокую производительность.
-
2 Илья
Вы кстати сами себе противоречите. Обычно защищаете формальное построение системы, а тут конкретная технология.
В реляционных СУБД главное слово "реляционные". Т.е. конкретная математическая концепция.
А NoSQL - это технология. И более того эта технология для других задач предназначена.
-
Ну, по поводу проблемы "нерегулярной изменчивой структуры данных" моё мнение можно узнать в двух моих статьях:
http://objectsystems.ru/files/Object_Systems_2011_Proceedings.pdf
Ермаков И.Е. XML-СУБД как возможная основа для объектных технологий ИС. Технология MULTYF
http://objectsystems.ru/files/2011WS/Object_Systems_2011_Winter_Session_Proceedings.pdf
Ермаков И. Е. Применение XML-СУБД в задачах автоматизации бизнеса.
Я не горячий сторонник XML-СУБД, но использовал их из реальной необходимости поиска альтернативы традиционным реляционкам. В статьях как раз рассмотрен сей тернистый путь... "поиска альтернативы" :)
По поводу масштабируемости - ну, я не знаю, Вы в теме hi-load, следите за этой темой? Сейчас материалов море.
Чтобы не быть голословным, скажу только из личного опыта. В одной автоматизированной системе межрегионального масштаба, "нутро" которой я знаю (это платформа из серии "электронная школа", муниципальные услуги и проч., которая используется в неск. регионах) проверка прав пользователей на выполнение той или другой операции, выполняемая на базе PostgreSQL, стала основным стопором производительности. Пришлось всё, что касается пользователей, сессий, аутентификации, ролей, проверки прав на операцию, перенести на MongoDB.
Язык - Java, Play! Framework.
-
2 Илья
Вы кстати сами себе противоречите. Обычно защищаете формальное построение системы, а тут конкретная технология.
Грешен, не раз уже в данной дискуссии употребляю термины в "интуитивном", а не в точном смысле :)
В реляционных СУБД главное слово "реляционные". Т.е. конкретная математическая концепция.
А NoSQL - это технология. И более того эта технология для других задач предназначена.
Но эта математическая концепция воплощена в конкретных технологиях. И все реализации обладают неким общим подмножеством свойств и недостатков.
Я же не говорил про реляционную МОДЕЛЬ ДАННЫХ. А именно про РСУБД. Что есть класс технологий, а не математическая концепция.
-
Расскажите IBM, о том что DB/2 не масштабируется, не адаптируется к высокой нагрузке и т.п.
Угу, ещё давайте рассмотрим DB/2 на базе As/400... Это не мейнстрим, друзья мои :) Это как раз интересное альтернативное решение. Правда, очень дорогое.
И нагрузка в Enterprise и нагрузка в онлайн-сервисах - это две большие разницы.
Я не уверен, что оно выдержит то, что держат BigTable, Tarantool и проч.
-
Короче: ключевая моя мысль в том, что 1) у меня всегда было ощущение, имеющиеся на рынке "обычные" СУБД (независимо от их частных отличий) спроектированы без учёта "принципа Калашникова", содержат много "мусора", посему целесообразно выбирать какие-то альтернативные им варианты и 2) что ход развития событий подтверждает это моё ощущение из п. 1.
-
По поводу масштабируемости - ну, я не знаю, Вы в теме hi-load, следите за этой темой? Сейчас материалов море.
Чтобы не быть голословным, скажу только из личного опыта. В одной автоматизированной системе межрегионального масштаба, "нутро" которой я знаю (это платформа из серии "электронная школа", муниципальные услуги и проч., которая используется в неск. регионах) проверка прав пользователей на выполнение той или другой операции, выполняемая на базе PostgreSQL, стала основным стопором производительности. Пришлось всё, что касается пользователей, сессий, аутентификации, ролей, проверки прав на операцию, перенести на MongoDB.
Язык - Java, Play! Framework.
Ах вы в этом смысле. Ну тык это забивание гвоздей микроскопом.
Использовать РСУБД для межрегиональной распределенки с туевой хучей запросов в секунду (ведь в этом проблема?) - это странная идея.
И более того это возможно ошибка проектирования, а не СУБД.
-
При этом и NoSQL и Play! это мейнстрим :-)
У меня ощущение складывается, что ты смешиваешь мейнстрим с ынтырпрайзом :-)
По объективным причинам (усложнять дальше некуда) анти-мейнстрим становится мейнстримом :)
Сейчас любить NoSQL модно, но года 4 назад расскажи я кому-нибудь тут, что так оно и будет, меня бы закидали чем-нибудь :)
Да это все суета сует. Все же просто. 10 лет назад начался бум веб-сайтов как всяких интернет-магазинов, так и просто хомячков да форумов. Появились хостинги для подобные проектов. Вопрос - где хранить данные и как с ними работать? (настройки там, сообщения форумов, прочий контент) В файлах? Сложно, не надежно. И вообще писать медленно. SQL тут самое оно, ибо просто и гибко. А SQL-субд отлично окучивала за раз сотни таких сайтов одновременно. Там выбор оправдан был.
А потом что? Потом таких товарищей, которые имеют опыт создания сайтов, стало очень много. И не все они продолжали сидеть и клепать исключительно веб, то есть это стало проникать и на десктоп и даже мобилки. Вот такой товарищ написал 10 сайтов, и хочет например написать теперь десктопную игрушку "крестики-нолики". В ней ему нужно хранить где-то настройки и top 10 игроков. Думаешь он будет заморачиваться с файликами? Конечно нет. Он возьмет SQL (sqlite в лучшем случае, но может и MySql поднять) и будет работать как привык. Ему эти буковки уже знакомы и не требуется ломать голову над чем-то новым. Просто сел, написал.
Дело дошло до того, что СУБД стали встраивать с телефоны (скажем в симбиане оно есть).
Вот и все причины популярности SQL-DBMS. Причем кто писал десктоп приложения без sql, те так и пишут. Для хранения данных обычно своя балалайка не выделенная в СУБД. Это как бы даже не NoSQL, это NoDBMS. Да и некоторые серверные приложения тоже.
-
Нюансов много, но то, что навороченные СУБД не масштабируются, не адаптируются к высокой нагрузке и к нерегулярным, изменчивым данным - це факт.
Эмм.. Не факт :-) Во-первых основная фича SQL-DBMS'ов в том, что оно крайне гибкое. Если изменилась структура данных, нужно как-то иначе их вытаскивать и обрабатывать, то это сделать можно достаточно быстро. То есть прежде всего SQL дает удобстно. Скорость там всегда была вторичной.
Для скорости есть OLAP.
А вот проблемы с масштабированием лежит в самой реляционной модели данных - реляционка нормально в принципе не масштабируется. И вот поэтому NoSQL.
И никакую РСУБД в крупных проектах теперь не встретишь без ORM (Object-Realtion-Mapping). Но при такой схеме использования РСУБД становится во многом "тупо хранилищем", основная сложная функция, оставляемая за РСУБД - это разные выборки, которые не опишешь императивно (гуляя от ID к ID).
Не правда. Скажем в знакомой фирме пишущей сурьезный банковский говнософт широко используются хранимые процедуры и вообще у них там PLSQL. В качестве языка общего назначения там java, которая по сути работает тонкой прослойкой между скажем субд и вебом. И это реально крупный проект.
-
Чтобы не быть голословным, скажу только из личного опыта. В одной автоматизированной системе межрегионального масштаба, "нутро" которой я знаю (это платформа из серии "электронная школа", муниципальные услуги и проч., которая используется в неск. регионах) проверка прав пользователей на выполнение той или другой операции, выполняемая на базе PostgreSQL, стала основным стопором производительности. Пришлось всё, что касается пользователей, сессий, аутентификации, ролей, проверки прав на операцию, перенести на MongoDB.
Язык - Java, Play! Framework.
Play вообще не фонтан. Очень медленная технология. Spring будет на порядок производительнее (если не на два порядка). К тому же, для повышения производительности, можно было использовать iBatis.
Кстати, тоже знаю систему регионального масштаба из серии "электронная школа", но она ещё не внедрена. И тоже на Play
-
Я, может быть, отбрасываю ряд нюансов, деталей, выражая своё ощущение главной тенденции...
Когда никто даже помыслить не может "жить без СУБД", а ты делаешь "No-СУБД"-решения, просто потому, что не хочешь вляпываться в избыточную сложность чужих СУБД, а потом тройку лет спустя все носятся с воплями "No-SQL, No-SQL", то, наверное, ощущение моё не совсем беспочвенное, а? :)
NoDBMS != NoSQL же. NoSQL всегда (во всех контекстах упоминаемых) подразумевает наличие СУБД.
NoDBMS это банально, избито и применяется дофига где. Это мейнстрим :-)
PS. Даже БЛОКНОТ использует NoDBMS! Да что там, даже мой hello world :-)
-
И нагрузка в Enterprise и нагрузка в онлайн-сервисах - это две большие разницы.
Да нет. Это примерно одна и та же разница :-) Ынтырпрайз он знаешь ли тоже большой и энергичный бывает, не менее энергичный чем скажем пользователи вконтактика.
Например потому, что ни SQL ни NoSQL которые лепятся для онлайн сервисом не справлялись с ынтырпрайз нагрузкой, была буквально в этом году допилена новая СУБД - HANA (http://en.wikipedia.org/wiki/SAP_HANA). Вот она как раз ынтырпрайзные нагрузки держит и правильно обрабатывает.
-
Для скорости есть OLAP.
ну мля - OLAP.а только здесь для скорости не хватало..... ;D
-
А лекции про БД на lectorium.tv от мужичка из Яндекса посмотреть стоит :)
Как раз стержневая нить в том, что к каждому занятию обучающимся предлагается сделать какой-либо механизм - и в итоге они убеждаются (и лектор подчёркивает и убеждает) в том, что всё это реально сделать своими руками, при этом в "боевом" варианте - все современные штуки из мира СУБД. Реально послать нах Ораклы и проч., и сделать просто и эффективно.
P.S. Только прошу не думать, что я сужу по конкретной лекции. Они просто подтвердили все мои убеждения... А уж темой СУБД я интересуюсь с 2004-го года.
У меня даже интерес к Оберонам появился именно под соусом "а какой простой язык можно легко встроить в свою СУБД" :)
-
А лекции про БД на lectorium.tv от мужичка из Яндекса посмотреть стоит :)
Как раз стержневая нить в том, что к каждому занятию обучающимся предлагается сделать какой-либо механизм - и в итоге они убеждаются (и лектор подчёркивает и убеждает) в том, что всё это реально сделать своими руками, при этом в "боевом" варианте - все современные штуки из мира СУБД. Реально послать нах Ораклы и проч., и сделать просто и эффективно.
При условии что на это время есть и ресурсы (квалифицированные работники). А не как обычно - вот тебе два phpшника и один jsQueriст, и нужно сделать мегауберштуку. Срок - вчера. Финансирование - на две недели максимум.
-
Возвращаясь к теме "зачем ББ".
Вот сейчас запустил Скайп, которым пользуюсь не очень часто, и опять полчаса искал в дебильном пиктограммном интерфейсе пункт, добавляющий новый контакт.
И сразу представляется документ с командерами и параметрами....
AddContact.... Connect.... Call...
Мячта.
-
Возвращаясь к теме "зачем ББ".
Вот сейчас запустил Скайп, которым пользуюсь не очень часто, и опять полчаса искал в дебильном пиктограммном интерфейсе пункт, добавляющий новый контакт.
И сразу представляется документ с командерами и параметрами....
AddContact.... Connect.... Call...
Мячта.
А я себе сразу представил фантазию разработчиков которые будут называть эти функции так как им хочется и вообще как придется. В результате предется либо в интерфейс модуля лезть, либо доки читать. Нафиг-нафиг. Плавали, знаем.
PS. Вообще, у тебя похоже скайп какой-то не правильный, или ты его не умеешь готовить. Вот скажи, в каком месте тут пиктограммы? Нашел сразу, хотя уже и не помню когда кого-то последний раз в скайп добавлял.
-
Возвращаясь к теме "зачем ББ".
Илья - тема то ДРУГАЯ (я вообще удивляюсь , каким образом вы делаете так, что студенты вас слушают - ибо в очередной раз убеждаюсь, что вы даже в "свободной беседе" не можете держать в голове больше 2-3 тезисов и адекватно реагировать на них)
-
DIzer, ваша личная неприязнь к ...... начинает несколько утомлять. Чесна чесна :)
-
Мягко сказано.
-
Добавлю, что ББ также вполне можно рекомендовать тем у кого рассчетные задачи, причем задачи не ложащиеся 1 в 1 на какой-либо известный метод (то есть взять матлабик и в одну строчку все записать не выйдет). Причем не эпизодические задачи, а постоянные - в этом случае в ББ можно свить вполне уютное гнездо (видимо уютней чем то, что свили в Энергии на PL/I). Единственное что - задачи должны быть не критичны к времени исполнения (то есть постоянный множитель не должен быть критичен), ибо компилятор не оптимизирующий и не оптимальный.
Также, пожалуй, можно порекомендовать тем, кто экспериментирует с алгоритмикой (скажем изобретает очередной улучшизм алгоритма A*) - гнездо также можно свить уютное, где цикл разработки будет короче.
Да, это все при условии, что у людей нет времени, или им не интересно, изучить какой-нибудь "большой" ЯП. То есть не IT-профи.
Т.е. для непрофессиональных программистов, например, физиков, химиков и т.д. info21 похоже продерживается (или придерживался?) того же мнения: From novel mathematics to efficient algorithms. Do we have proper SD foundation to build future? (http://arxiv.org/pdf/hep-ph/0202033v2.pdf)
-
Т.е. для непрофессиональных программистов, например, физиков, химиков и т.д. info21 похоже продерживается (или придерживался?) того же мнения
...
Похоже.
Ну, очень похоже.
:)
-
DIzer, ваша личная неприязнь к ...... начинает несколько утомлять. Чесна чесна :)
ilovb - это просто констатация факта(и суть вещей не изменилась за последнии 3 года), по отношению к человеку который САМ себя назвал преподавателем вуза, профессионалом, управленцем с более чем 10 летним стажем, программистом с пеленок, и мало того - ПОУЧАЕТ всех кого не лень (а в коровнике вдобавок к поучениям было еще использование эцилопов для расправы...) - а как известно назвался груздем -полезай в кузов... т.е. соответствуй. Тем кто не "в теме" моя позиция может показаться излишне жестокой, но честь мундира обязывает(ничего личного, и тем более чувства неприязни)... , она относится только к людям которые взяли на себя определенную ответственность. К вам же г-да Ilovb, Berserker -я претензий не имею.
-
Т.е. для непрофессиональных программистов, например, физиков, химиков и т.д. info21 похоже продерживается (или придерживался?) того же мнения
...
Похоже.
Ну, очень похоже.
:)
мало... вот у нас провинциальный университет.. и то , как первые, так и вторые имеют курсы(с практическими занятию) по MAPLу или MATLABу - нужны еще доп. ограничивающие условия на множество таких пользователей - опять господа, вы пренебрегаете двумя последними словами в формулировке топика.. речь идет об определении множества пользователей ББ - для ТЕКУЩЕГО ЕГО СОСТОЯНИЯ, и подразумевается ЛИЧНАЯ ОТВЕТСТВЕННОСТЬ человека дающего рекоммендацию
-
DIzer, ваша личная неприязнь к ...... начинает несколько утомлять. Чесна чесна :)
ilovb - это просто констатация факта(и суть вещей не изменилась за последнии 3 года), по отношению к человеку который САМ себя назвал преподавателем вуза, профессионалом, управленцем с более чем 10 летним стажем, программистом с пеленок, и мало того - ПОУЧАЕТ всех кого не лень (а в коровнике вдобавок к поучениям было еще использование эцилопов для расправы...) - а как известно назвался груздем -полезай в кузов... т.е. соответствуй. Тем кто не "в теме" моя позиция может показаться излишне жестокой, но честь мундира обязывает(ничего личного, и тем более чувства неприязни)... , она относится только к людям которые взяли на себя определенную ответственность. К вам же г-да Ilovb, Berserker -я претензий не имею.
и в догонку... ilovb.. вы плохо себе представляете , что такое ЛИЧНАЯ неприязнь в моем исполнении...- примером личной неприязни. - служит реакция на ИНФО21 от отмежевавшегося AlexUs'a, или моя реакция на гопнобыдло - см. конец топика "на гране цензуры"...
-
Илья - тема то ДРУГАЯ (я вообще удивляюсь , каким образом вы делаете так, что студенты вас слушают - ибо в очередной раз убеждаюсь, что вы даже в "свободной беседе" не можете держать в голове больше 2-3 тезисов и адекватно реагировать на них)
Нет, просто иногда невозможно разделить какую-либо систему факторов на части. Они "играют" вместе, как единое целое, по отдельности теряя силу и смысл. Давно всем тут известный пример - Обероны как языки и как среды.
С факторами "за ББ" тоже именно так.
Я и пытаюсь донести, несколько сумбурно иногда, всю совокупность соображений. Для "загрузки в голову" как единое целое. Можно принять, можно отвергнуть, но сначала попытаться "загрузить" целиком, а не цепляться к отдельным словам.
А студентам я мозги особо не промываю на темы мейнстримов :) Просто даю восходящую цепь примеров и упражнений, после которой они пишут "кирпичи" для программ с уверенностью в каждой строчке, без "блужданий" и тыкания. Это резко контрастирует с тем, что они могут почерпнуть где-то ещё, так что убеждать и агитировать за что-то не приходится. Доверяют.
-
Нет, просто иногда невозможно разделить какую-либо систему факторов на части. Они "играют" вместе, как единое целое, по отдельности теряя силу и смысл. Давно всем тут известный пример - Обероны как языки и как среды.
С факторами "за ББ" тоже именно так.
....
Илья тема-" Кому можно рекомендовать ББ - в текущем состоянии!" - ну к чему эти словесы.. если вы ДЕЙСТВИТЕЛЬНО возвращаетесь к топику..- ilovb - ну что вы на это скажете....
-
Что-то мне это напоминает...
А, вот:
«Потереть лишние сообщения, чтобы привести их в соответствие с правилами». Вместо реальной жизни (где все, как есть) — морок виртуального мира (где все, как НАДО), вместо свободной и радостной формы самовыражения — «приведение в соответствие». Суть ФИДО: никакого самоволия, армейская муштра, зашоренность рядовых «салаг», хамское тыканье якобы ради утверждения равенства в отношениях, а на самом деле — лишь во имя утверждения автократии модераторской банды.
-
«Потереть лишние сообщения, чтобы привести их в соответствие с правилами». Вместо реальной жизни (где все, как есть) — морок виртуального мира (где все, как НАДО), вместо свободной и радостной формы самовыражения — «приведение в соответствие». Суть ФИДО: никакого самоволия, армейская муштра, зашоренность рядовых «салаг», хамское тыканье якобы ради утверждения равенства в отношениях, а на самом деле — лишь во имя утверждения автократии модераторской банды.
а х.з. но, вроде, вначале образования коровника они такими не были (то есть насчет заговора - это вряд ли.. скорее от отупения вследствие выбранного курса).
-
Что-то мне это напоминает...
А, вот:
«Потереть лишние сообщения, чтобы привести их в соответствие с правилами». Вместо реальной жизни (где все, как есть) — морок виртуального мира (где все, как НАДО), вместо свободной и радостной формы самовыражения — «приведение в соответствие». Суть ФИДО: никакого самоволия, армейская муштра, зашоренность рядовых «салаг», хамское тыканье якобы ради утверждения равенства в отношениях, а на самом деле — лишь во имя утверждения автократии модераторской банды.
Я не очень понял к чему это, но с конкретно этим, тем что процитировано я все же не согласен. Во-первых FIDO не было столь уж авторитарным, точнее оно не было в этом плане однородным. Во-вторых модераторы там не были высшей властью. В-третьих обращение на "ты" мне не кажется и никогда не казалось хамским (и уж тем более к утверждению автократии мода и комода это никакого отношения не имело), ну и наконец, но самое главное - модераторы не имели технической возможности проводить премодерацию, и не могли удалять сообщения которые уже прилетели. А прилетали сообщения пачками раз в неделю скажем. Поэтому в ФИДО ситуация, скажем подобная той что на оберонкоре, сложиться не могла в принципе.
-
Это я про DIzer'а, который пытается загнать народ в стойло в своей теме.
-
В-третьих обращение на "ты" мне не кажется и никогда не казалось хамским (и уж тем более к утверждению автократии мода и комода это никакого отношения не имело)
это дело личное, но раз так то нефиг осуждать людей для которых естественно послать нах.. также как тыкнуть
-
Это я про DIzer'а, который пытается загнать народ в стойло в своей теме.
а вон оно что... ну тогда я пас... что то не помню я про тыканье... , да и модерировать у меня нет никаких прав- а насчет стойла.. хм - моих сообщений (в этой теме) не так уж много -их без проблем можно разобрать ;) все они направлены были на уточнение ТЕХ ответов которые шли в тему.. в х.ю про базы данных я не лез..(сорри, кроме насмешившего меня пассажа об ОЛАПЕ) и прочие отнорки разве нет? И потом Peter Almazov - не нравится тема, не участвуйте в ней, хотите поговорить о другом - заводите топик.., хотите сделать отнорок в этой- да без проблем в чем проблема то?
-
А в стойло вас загоняет Peter Almazov - если загоняет конечно... не Дизер, а ваша ограниченность
-
Т.е. для непрофессиональных программистов, например, физиков, химиков и т.д. info21 похоже продерживается (или придерживался?) того же мнения
...
Похоже.
Ну, очень похоже.
:)
мало... вот у нас провинциальный университет.. и то , как первые, так и вторые имеют курсы(с практическими занятию) по MAPLу или MATLABу - нужны еще доп. ограничивающие условия на множество таких пользователей - опять господа, вы пренебрегаете двумя последними словами в формулировке топика.. речь идет об определении множества пользователей ББ - для ТЕКУЩЕГО ЕГО СОСТОЯНИЯ, и подразумевается ЛИЧНАЯ ОТВЕТСТВЕННОСТЬ человека дающего рекоммендацию
Да, как раз это хотел ответить. info21 советует ББ для химикофизиков без ограничений, я все же ограничения ввожу. Ситуация когда ББ не применим или слабо применим:
1) Имеем рассчетную задачу. Задача достаточно тяжелая и время счета - месяцы. Нужно успеть к концу скажем квартала. Тут постоянный множитель в производительности может сильно сыграть роль - на фортране, или Си современном посчитается за месяц, на ББ посчитается за 2-3 месяца. Не успеем. Особенно если учесть, что для распараллеивания рассчетов в ББ придется поизвращаться.
2) Опять же имеем рассчетную задачу. Специфика задачи такова, что она достаточно памятежручая. Ну, скажем нужны какие-то несчастные 10 Гб ОЗУ. На Фортране/Си/жабе проблем нет, а вот в ББ придется как-то извращаться, причем не на уровне алгоритмики даже, а на уровне системном, чуждом физику/химику. Ведь ББ 32битный и больше 4 Гиг ну никак не сможет эффективно использовать (даже если выпилить винду).
3) Ах, опять рассчетная задача. Только задача теперь действительно тяжелая. На персоналке её считать не катит. Нужен кластер. То есть нормальный такой суперкомпьютер с тысячами ядер, сотнями и тысячами гигабайт ОЗУ и спецлинуксом на борту. Куда тут ББ приткнуть?
4) Если у нас уже есть богатая библиотека скажем уникальных численных методов, писанная потом и кровью нашими предками, которую традиционно используют и к которой все привыкли, то она скорее всего на Фортране, в крайнем случае на Си или PL/I. Предлагается переписывать все с нуля в ББ? Не вариант.
5) В ряде случаев проще и правильней использовать готовые имеющиеся на рынке инструменты - MatLab, ANSYS и т.п.
Таким образом ББ хорош либо для одиночки который делает что-то уникальное (либо если ему важнее процесс нежели результат, то есть например если студент делает лабу), либо для сплоченного коллектива который опять таки делает что-то достаточно уникальное. В принципе, скажем мне в работе ББ мог бы пригодиться, если бы я занимался чисто исследованиями в плане анализа фотоплетизмограмм, и мне не требовалось бы это все пускать, так сказать, в продакшн, запихивая эти алгоритмы то на линуксячий сервер, то в iPhone, то еще куда-то. Причем как сами алгоритмы, так и их реализация должна быть уже отлажена. Время одной итерации (исследовали явление (ряд экспериментов) -> попробовали алгоритмы -> запихали в конечное устройство) где-то месяц-два. Алгоритмы сами по себе не тяжелые, так что на множитель было бы пофик. Но увы-с. Кстати, по этой же причине, почему ББ я и не думаю использовать, у нас MatLab используется только на самом первоначальном этапе, а иногда не используется вовсе.
Да, и шестое: боюсь, info21 совершил стратегическую ошибку концентрируясь именно на непрофессионалах, взращивая именно их на ББ - ко времени когда они окончательно взрастут, ББ окончательно превратится в хлам. Чтобы ББ не превратился в хлам, нужны люди - программисты-профессионалы, которые поддерживали бы его в кондиции. Перетащили бы на 64 бита например, сделали бы оптимизацию у компилятора нормальную (хотя бы не ломающую семантику кода) и так далее. Если бы у НПО Энергия не было бы того товарища который пилит и совершенствует PL/I-компилятор, который перетащил его с ms-dos'а 16ти битного в современную винду, PL/I сейчас там не использовася бы. А ведь он-то явно презренный профессионал.
-
Это я про DIzer'а, который пытается загнать народ в стойло в своей теме.
Да ладно, это обычное бурчание топикстартера, который хочет чтобы топик был таки тот который он стартанул, а не произвольный. Ну и ответы на вопросы, думаю Дизер таки хотел услышать.
-
Да, как раз это хотел ответить. info21 советует ББ для химикофизиков без ограничений, я все же ограничения ввожу. Ситуация когда ББ не применим или слабо применим:
......
с пунктами ознакомлен.... а теперь Алексей сделайте поправку на то что современные Матлабы и Маплы... это не просто пакеты подпрограмм, но платформы для вычислений.. которые имеют свои ЯП (и интеграцию с другими ЯП) средства поддержки распараллеливания, облачных вычислений, .. и т.д. (и они РАЗВИВАЮТСЯ) - что с учетом ЭТИХ поправок останется на долю ББ? кому таки вы ОТВЕТСТВЕННО (что бы человек был вам благодарен за эту рекомендацию, имея возможность засунуть в одно место тухлое яйцо или даже еще хуже - если ваш совет приведет к ущербу) его порекомендуете?
-
Да ладно, это обычное бурчание топикстартера, который хочет чтобы топик был таки тот который он стартанул, а не произвольный. Ну и ответы на вопросы, думаю Дизер таки хотел услышать.
1. не совсем так - в темах этого форума я сделал столько отнорок... что не считаю себя вправе требовать - выполнения строгих правил от других ( более того, с таким составом как у нас это просто ИМХО -невозможно)
2. Разумеется да.. и все мои "попытки загнать народ в стойбище" - направлены на уточнение ответов по этому топику.. - и опять я ничего в этом плохого не вижу, не хочешь - не отвечай.
-
Да, как раз это хотел ответить. info21 советует ББ для химикофизиков без ограничений, я все же ограничения ввожу. Ситуация когда ББ не применим или слабо применим:
......
с пунктами ознакомлен.... а теперь Алексей сделайте поправку на то что современные Матлабы и Маплы... это не просто пакеты подпрограмм, но платформы для вычислений.. которые имеют свои ЯП (и интеграцию с другими ЯП) средства поддержки распараллеливания, облачных вычислений, .. и т.д. (и они РАЗВИВАЮТСЯ) - что с учетом ЭТИХ поправок останется на долю ББ? кому таки вы ОТВЕТСТВЕННО (что бы человек был вам благодарен за эту рекомендацию, имея возможность засунуть в одно место тухлое яйцо или даже еще хуже - если ваш совет приведет к ущербу) его порекомендуете?
А это было с учетом поправок :-)
За maple не скажу, он вне моего поля зрения. Но матлаб имеет абсолютно отвратительную "интеграцию" с другими ЯП. Ну, то есть для моих задач он подходит не лучше ББ - один фиг весь код писаный в матлабе потом на сях переписывать. Экспортировать написанное в сишечку он так и не научился нормально.
Также свой ЯП матлаба это и радость и печаль. Радость от приятного сахарка для работы с векторами/матрицами. Печаль - от скорости интерпретации и от динамической типизации. Как только бОльшая часть не тривиального алгоритма становится написана на их ЯП, так сразу грабли. И по скорости выполнения, и по ошибкам (ибо динамическая типизация). То есть это когда код твой матлабовский не является просто простым клеем для вызовов матлабовских же функций (фильтры там всякие, и алгоритмы), которые писаны, на самом деле, на сях :-)
PS. Тут еще такая штука: иногда (а может быть и довольно часто) разобраться с каким-нибудь мат. методом (ну, например с очередным методом построения цифровых фильтров) и реализовать его на С++ (на другом я не пробовал) бывает быстрее чем разобраться с матлабом, чтобы заставить его делать ровно то, что тебе нужно. То есть надавно вот было - я разбирался с неким методом по учебнику/статьям и затем реализовывал его на С++ (ибо надо сразу было проверить как оно будет шевелиться в боевых условиях, и вообще не имеет особого смысла закапываться в алгоритмы которые мы не сможем применять на нужных железяках) а другой человек, имеющий опыт работы с матлабом, разбирался как сделать примерно то же, но в матлабе (найти за какие ниточки его подергать чтобы он сделал что нужно). Времени это заняло у нас одинаково. Причем для меня предметная область эта была внове, а у того товарища там был опыт.
Я не утверждаю что так бывает всегда и везде, но вот, бывает. В некоторых проектах.
Если бы мы специализировались не на мобильно-облачном сегменте, а на чём-то более стационарном (скажем пульт для дежурной медсестры для наблюдения за состоянием пациентов), то я вполне могу себе представить ББ в качестве основной платформы для разработки и распространения. Ну, а поскольку мы все ж таки в том числе программисты-профессионалы, подтянуть ББ в случае нужды наверно было бы можно. :-) Хотя задача в общем то не шибко памятежоркая, так что 64бита не актуально было бы.
PS. Но вообще, с учетом все этих пунктов из предыдущего моего сообщения, я вообще хз кто решится ББ использовать. Ведь никто не может (из не программер-профи) дать зуб на отсеченье, что вот завтра ему не потребуется большую фортрановскую либу прикручивать, или там задача не отмасштабируется. То есть, самый верный, самый основной путь по которому ББ может просочиться - это путь выбора по умолчанию. Если человек с детства привык к ББ, то у ББ есть шанс появиться на рабочем месте вчерашнего школьника-студента, а ныне научного сотрудника.
-
BB удобен для макетирования и экспериментов. Т.е. его имхо можно рекомендовать архитекторам для создания работающего прототипа будущей системы. Для создания готовой системы в нынешних реалиях, как это не печально, он не годится.
Т.е. BB для прототипирования (http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D1%82%D0%B8%D0%BF%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5) архитектуры как VB для прототипирования интерфейса пользователя
-
BB удобен для макетирования и экспериментов. Т.е. его имхо можно рекомендовать архитекторам для создания работающего прототипа будущей системы. Для создания готовой системы в нынешних реалиях, как это не печально, он не годится.
Т.е. BB для прототипирования (http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D1%82%D0%B8%D0%BF%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5) архитектуры как VB для прототипирования интерфейса пользователя
ну про это я упоминал еще в коровнике.. но будучи занудой - таки спрошу - а кому вы его порекомендуете?
-
Тык там написано кому:
...его имхо можно рекомендовать архитекторам...
-
PS. Но вообще, с учетом все этих пунктов из предыдущего моего сообщения, я вообще хз кто решится ББ использовать.
вот и я также - хотя без особых проблем могу перевести как на него , так и на xds - пару групп студентов.. но если честно задавать себе вопрос.. а нафига это нужно и попробовать честно ответить на него... то увы...
-
Тык там написано кому:
...его имхо можно рекомендовать архитекторам...
Ни в коем случае. Архитектурить архитектуру для програмного продукта на языке программирования общего назначения, который отличен от реального языка на котором будет реализован софт - в корне не верно.
-
А на чем тогда архитектурить?
-
А на чем тогда архитектурить?
На том же на чем будет потом реализовываться продакшн-версия.
+ каля-маля на бумажке/доске (эстеты могут использовать UML)
-
Тык там написано кому:
...его имхо можно рекомендовать архитекторам...
понял - уточнение - этот совет с учетом текущих реалий рынка подобных решений (приложений для проектирования софта) или нет?
-
2 valexey
Это если оно позволяет безболезненно и быстро прототипировать. Ну наверно на жабе или там додиезе еще можно, а если c++?
-
блин, вопрос запоздал - очевидно что нет (он касался степени ответственности за предложение)
-
понял - уточнение - этот совет с учетом текущих реалий рынка подобных решений (приложений для проектирования софта) или нет?
Вы про UML? Я не особо верю в него. Давно хочу попробовать и оценить, но все руки не доходят.
-
понял - уточнение - этот совет с учетом текущих реалий рынка подобных решений (приложений для проектирования софта) или нет?
Вы про UML? Я не особо верю в него. Давно хочу попробовать и оценить, но все руки не доходят.
не я про степень вашей ответственности за совет (насчет прототипирования по)...
-
2 valexey
Это если оно позволяет безболезненно и быстро прототипировать. Ну наверно на жабе или там додиезе еще можно, а если c++?
А какие проблемы? Что ж это за архитектор такой, который не умеет прототипировать на с++ (если c++ основной язык реализации)?
Но возможно мы понимаем под прототипированием/архитектуриванием что-то разное. Уточни пожалуйста, что ты под этим подразумеваешь? У меня ощущение, что от твоего архитектуривания как-то гуём наносит...
-
ОК. Вот к примеру я собираюсь писать текстовый редактор.
Прототип я буду писать в BB, т.к. он идеален для этих целей.
1. У меня есть возможность не отвлекаться на язык, т.к. CP очень прост и строг. Т.е. я уверен что не буду гулять по граблям и тратить на них время.
2. У меня есть возможность анализировать работу системы от и до без особого напряга, т.к. доступна вся метаинформация.
3. В CP очень стройное ООП. Очень удобно описывать интерфейс модулей естественным образом, и практически прямолинейно отражать свои мысли в абстракциях.
4. В CP сложно напороться на глупую ошибку.
5. CP - это наверно единственный язык который реально можно изучить в короткий срок и знать целиком. Других языков (не скриптовых) могущих этим похвастать я не знаю.
6. Среда разработки и прототип могут бесшовно взаимодействовать в процессе разработки. Таким наверно только Squeak может похвастаться.
Задача прототипа ведь не дать готовый результат. Его задача дать разработчику обозреть и пощупать свои мысли и идеи в работающей системе. Язык и среда прототипирования не обязаны быть языком и средой реализации. Точно также схема на бумаге не обязана быть правильным cpp классом. Архитектура приложения - это не описание полей и методов классов, точно также как архитектура здания - это не описание строительных материалов ;) А вот пластмассовый макет, напечатанный на 3D принтере уже дает представление об архитектуре и вскрывает недостатки, которые в мысленном образе было сложно увидеть.
ps И вообще я из своего скромного опыта разработки убедился, что сложную систему с первого раза построить невозможно. Первый блин всегда будет комом сколько не усерайся, т.к. причины фейла тут обычно мало зависят от способностей разработчика. И нужно быть готовым что первую реализацию придется перепроектировать с нуля. Так вот имхо использование BB может сделать этот этап (создания прототипа и перепроектирования) максимально безболезненным.
-
ОК. Вот к примеру я собираюсь писать текстовый редактор.
Гуевый пример не интересен. Давай по другому.
К примеру я хочу написать серверное приложение (скажем, гм, форум). Как мне в прототипировании тут поможет ББ? Чем он, для прототипирования, тут будет лучше чем C++ или Go? И, тем более, почему он будет лучше, чем RoR какой-нибудь.
Не хочешь форум? Ок. Я создаю новый ЯП. Хочу набросать прототип. Скажи пожалуйста, почему мне тут для прототипирования больше годится ББ нежели AntlrWorks + Java?
ЯП слишком специфичная область? Ну, ок. Я просто пишу прототип для решения той твоей задачки. Как думаешь, в ББ я бы это решил быстрее и правильнее, чем на С++? (а то мое решение было именно что прототипом написанным быстро и грязно). Оно было бы короче? Работало бы быстрее? Спокойно кушало бы UTF8 сразу?
PS. Кстати, ты осознаешь, что описанное тобой прототипирование к построению архитектуры приложения никакого (почти) отношения не имеет? Это две совершенно разные фазы разработки.
-
Еще уточнение:
Я не в коей мере не утверждаю что BB можно взять как есть и ваять прототип. Для начала придется организовать себе песочницу. Например однозначно придется написать нормальный профайлер.
-
Гуевый пример не интересен. Давай по другому.
К примеру я хочу написать серверное приложение (скажем, гм, форум). Как мне в прототипировании тут поможет ББ? Чем он, для прототипирования, тут будет лучше чем C++ или Go? И, тем более, почему он будет лучше, чем RoR какой-нибудь.
1. Почему гуевый? Каким это образом соотносится архитектура текстового редактора с гуем? ???
Гуй и архитектура тут вроде две мало влияющие друг на друга задачи.
2. Про форум не скажу, ибо очень слабо представляю как это делается (сетевые/интернет приложения/сервисы).
Не хочешь форум? Ок. Я создаю новый ЯП. Хочу набросать прототип. Скажи пожалуйста, почему мне тут для прототипирования больше годится ББ нежели AntlrWorks + Java?
При чем тут архитектура? Если имеется ввиду архитектура языка, то кроме бумаги и мозга тут ничего не поможет, ибо язык - это штука нематериальная. Если архитектура компилятора (не реализация там парсера или генератора, а именно архитектура) то имхо BB идеален.
ЯП слишком специфичная область? Ну, ок. Я просто пишу прототип для решения той твоей задачки. Как думаешь, в ББ я бы это решил быстрее и правильнее, чем на С++? (а то мое решение было именно что прототипом написанным быстро и грязно). Оно было бы короче? Работало бы быстрее? Спокойно кушало бы UTF8 сразу?
Опять при чем тут архитектура? И да ты называешь довольно специфические области, для которых есть специализированные инструменты (которые и созданы по причине специфичности области)
Да и задача эта мизерная... чего там архитектурить то?
PS. Кстати, ты осознаешь, что описанное тобой прототипирование к построению архитектуры приложения никакого (почти) отношения не имеет? Это две совершенно разные фазы разработки.
Возможно я ошибаюсь. Это моя имха из личного опыта. Как это ни странно звучит, но наверно большая часть моей работы заключается в проектировании архитектуры бизнес приложений. Что такое ошибка проектирования знаю не по наслышке. Сам допустил кучу и допускаю такие ошибки постоянно :)
И в том что архитектура очень мало связана со средством реализации меня никто не переубедит.
-
1. Почему гуевый? Каким это образом соотносится архитектура текстового редактора с гуем? ???
Так ты определись уже - ты прототип ваяешь, или уже архитектуру боевой системы строишь?
-
На самом деле чем этот ужасный ББ хуже чем турбопаскаль, который до сих пор широко используется?
Отладчика нет.
И это - правильно! :)
-
1. Почему гуевый? Каким это образом соотносится архитектура текстового редактора с гуем? ???
Так ты определись уже - ты прототип ваяешь, или уже архитектуру боевой системы строишь?
Не понял вопроса. Ты как-то связываешь прототип с гуем?
-
На самом деле чем этот ужасный ББ хуже чем турбопаскаль, который до сих пор широко используется?
Отладчика нет.
И это - правильно! :)
Нет, не правильно. Я уже неоднократно говорил почему. И для обучения не правильно и для работы не правильно. Другое дело, что нельзя давать обучающемуся только такие задачи, где применим пошаговый отладчик. В мире полно задачь, где он не применим вообще или его использование сильно затруднено (хотя инструментарий все поддерживает).
-
1. Почему гуевый? Каким это образом соотносится архитектура текстового редактора с гуем? ???
Так ты определись уже - ты прототип ваяешь, или уже архитектуру боевой системы строишь?
Не понял вопроса. Ты как-то связываешь прототип с гуем?
Связь прототипа с гуем конечно же может быть (если задача то гуевая). Но ты то явно как-то связываешь прототипирование с архитектурой. И вот это уже не верно.
-
Но ты то явно как-то связываешь прототипирование с архитектурой.
Ну тык самым прямым образом связываю...
А ты другого мнения на сей счет? ???
-
Вот нашел статью, которая примерно соответствует моим представлениям о прототипировании:
http://dtf.ru/articles/read.php?id=44070
Помимо реализации в прототипе элементов из уже готового списка особенностей игры немаловажным моментом является и работа по созданию этого списка. Ведь как правило, в голове геймдизайнера находится огромное количество идей и мыслей, а решение о внесении той или иной идеи в список обусловлено больше субъективным суждением об ее интересности и реализуемости. Конечно, это не относится к фичам проверенным многими играми, но, тем не менее, даже они не всегда могут дружно уживаться с придуманными геймдизайнером. Именно в этом случае и должно помогать прототипирование. Ведь куда дешевле проверить свою идею на функционирование до внесения ее в дизайн-документ, вместо того чтобы проводить данное действие, когда проект уже глубоко увяз в разработке и при этом еще и выяснить, что она не работает, так как надо.
Ответ прост: было бы неплохо иметь некий инструментарий, в котором была бы следующая функциональность:
Возможность проведения теоретических изысканий: балансировка игры, проверка работоспособности и функционирования механики игры, сбор статистических данных, вывод необходимой информации в виде графиков и диаграмм, проведение различных математических расчетов.
Возможность прототипирования игровых диалогов и связанных с ними геймплейных моментов.
Возможность быстрого создания прототипа без знания сложных языков программирования.
Возможность быстрого изменения параметров и функциональности прототипов.
Возможность легкого использования полученных в ходе прототипирования данных.
После анализа исходных данных, а также имеющегося временного отрезка, было решено в качестве средства создания подобного программного продукта использовать в качестве языка программирования C#, а в качестве среды - Visual Studio .NET 2005. Почему был выбран C#, можно пояснить очень коротко - это быстро, гибко и визуально.
-
И насчет текстового редактора. Под архитектурой оного я подразумеваю то, что описано в книге "Проект Оберон" в главе 5.2. Управление текстом.
У тебя книга есть на сколько я помню. Если почитаешь эту главу, то станет понятно, почему я не связываю архитектуру со средством реализации. И почему прототипирование архитектуры не связываю с гуем.
И возможно станет понятно почему я считаю что в BB создать прототип текстового редактора гораздо проще чем на cpp.
ps И, кстати, гуй и логический интерфейс пользователя для меня разные вещи. Первый рисуется, а второй описывается схемой.
-
Если бы мы специализировались не на мобильно-облачном сегменте, а на чём-то более стационарном (скажем пульт для дежурной медсестры для наблюдения за состоянием пациентов), то я вполне могу себе представить ББ в качестве основной платформы для разработки и распространения. Ну, а поскольку мы все ж таки в том числе программисты-профессионалы, подтянуть ББ в случае нужды наверно было бы можно. :-) Хотя задача в общем то не шибко памятежоркая, так что 64бита не актуально было бы.
А какие преимущества в этой задаче у блекбокса перед, ну хотя бы, сишарпом или явой?
-
Но ты то явно как-то связываешь прототипирование с архитектурой.
Ну тык самым прямым образом связываю...
А ты другого мнения на сей счет? ???
Да, конечно.
Прототипирование нужно для того, чтобы понять предметную область, рассмотреть идеи, возможно показать потенциальному заказчику/потребителю. Конечным результатом серии прототипов является составленое ТЗ на реализации задачи (если конечно в ходе прототипирования не выяснилось, что идея не жизнеспособная). Прототипы могут клепаться на чем угодно вообще, причем людьми любой квалификации. Тут главное - БЫСТРО. Прототипов лепится множество, смотрятся возможные вариации и так далее. Все они выбрасываются.
После того как тонна прототипов написана, выброшена и ТЗ составлено, начинают свою работу архитекторы. Создается архитектора будущего приложения. В ТЗ обозначено что должно быть, и примерно очерчено куда это все может расширяться. Архитектор читает все это, включает свою параною на максимум, и закладывает в архитектуру точки расширения с учетом своей паранои с одной стороны, и исходя из бюджета и наличных кадров с другой. Архитектор также проектирует протоколы взаимодействия, основные абстракции, масштабируемость (с учетом многопоточности всякой), портируемость и так далее. Он принимает основные решения. Естественно он это делает с учетом языка на котором все это будет реализовываться (кстати, также он может и язык выбирать). В процессе архитектор может в принципе строить свои, архитекторные, прототипы. Естественно они уже пишутся на языке реализации. И очень часто не только не работают, но даже и не собираются во что-то цельное :-) На выходе архитектора имеем документ с описанием всего этого + каркас (набор скажем спецификаций основных пакетов, если у нас Ада) на базе которого будет строиться конечное приложение.
Пейсатель прототипов имеет право свой прототип ваять хоть на брейнфаке, но архитектор не имеет права использовать язык отличный от языка реализации. Ибо архитектура очень сильно зависит от языка программирования. Архитектура для пролога будет одной, а для смалтолка совсем другой.
Я видел приложение на С++ которые были спроектированы джавистами - это ужасно. Равно как и наоборот.
-
Ну в общем понятна разница наших взглядов. :)
По большому счету разница сконцентрирована в этом предложении:
Прототипы могут клепаться на чем угодно вообще, причем людьми любой квалификации.
Я считаю наоборот, что созданием прототипа и перепроектированием должен заниматься самый квалифицированный человек в команде, т.е. архитектор.
Также как в статье, которую я привел, эту роль выполняет геймдизайнер (который в игрострое и есть архитектор)
Я видел приложение на С++ которые были спроектированы джавистами - это ужасно. Равно как и наоборот.
Да ладно, я видел приложение 1С написанное сиплюсплюсниками. Всем офисом ржали, а потом еще и материли его/их на чем свет стоит. ;D
-
Ну в общем понятна разница наших взглядов. :)
По большому счету разница сконцентрирована в этом предложении:
Прототипы могут клепаться на чем угодно вообще, причем людьми любой квалификации.
Я считаю наоборот, что созданием прототипа и перепроектированием должен заниматься самый квалифицированный человек в команде, т.е. архитектор.
А смысл?
Также как в статье, которую я привел, эту роль выполняет геймдизайнер (который в игрострое и есть архитектор)
Нет, не является. Геймдиз является внутренним заказчиком. Он говорит что делать, но не как делать. Геймдиз является человеком погруженным в предметную область, но он также имеет крайне низкую квалификацию в плане програмной инженерии.
А вот архитектор принимает уже конкретные инженерные решения.
-
Тык архитектор - это и есть имхо внутренний заказчик/постановщик.
И да - архитектор погружен в предметную область иначе такой "архитектор" будет тупо обычным инженером.
Представь себе архитектора фотошопа, который ничего не смыслит в графике и не знает чем и как занимаются дизайнеры.
-
Тык архитектор - это и есть имхо внутренний заказчик/постановщик.
И да - архитектор погружен в предметную область иначе такой "архитектор" будет тупо обычным инженером.
Представь себе архитектора фотошопа, который ничего не смыслит в графике и не знает чем и как занимаются дизайнеры.
Нет. Архитектор не есть внутренний заказчик. Точнее, внутри конторы обычно же цепочка, точнее как минимум дерево (или вообще граф). Где родитель твой есть твой внутренний заказчик. Так вот, геймдиз - это тот, кто пишет сценарий к игре, тот кто отвечает за геймплей и так далее. Но он НЕ отвечает за геймплей, НЕ отвечает и не принимает решение по используемым технологиям. Он не решает какова будет архитектора кластера серверной части World Of Tanks, ибо он в этом ни в зуб ногой. Это все решает архитектор. Вплоть до основных абстракций. И да, архитектор он инженер. И он является внутренним заказчиком уже для тимлидов например. Которые руководят группами программистов лепящих конкретный кусок функционала, а также тимлиды являются основными программистами в группе.
Если говорить о прототипах.. До частенько действительно не имеет значения кто именно их лепит. Тот же геймдиз может иметь под собой 5 дешевых программистов-студентов которые будут быстро прототипировать его бред. 1 прототип - 1 студентодень. Затем геймдиз смотрит что из этого всего получилось, все выбрасывается и пошла новая итерация. Пока оно не приблизится к чему-то вменяемому.
Причем если в геймдеве это еще не столь ярко выражено, то в менее креативных областях софтостроениях, это выражено сильнее. Приходит кому-нибудь в голову идея - а давайте скрестим текстовый редактор и медиа плеер! Вдруг чо получится? Ну, ок. Давайте слепим прототип - берется студент и сажается на эту задачу. Он что-то там лепит на вижуалбейсике, абсолютно ужасное внутри, но как-то работающее и падающее всего то раз в полчаса. И вот он прототип. Можно оценивать жизнеспособность идеи. Зачем автору идеи самому воплощать эту хрень, или дергать архитектора от текущих архитекторских задач на такую фигню (которая в 99% случаев не выстрелит)?
-
Он не решает какова будет архитектора кластера серверной части
Сильно сомневаюсь что в wargaming этим занимался главный архитектор.
-
Он не решает какова будет архитектора кластера серверной части
Сильно сомневаюсь что в wargaming этим занимался главный архитектор.
Абсолютно точно этим не занимался главный геймдиз :-) И да, архитектура кластера входит в круг задач для архитекторов.
У меня просто есть знакомый геймдиз, и я знаю чем они занимаются. Также на работе я периодически общаюсь с архитекторами, и знаю чем занимаются они. Ну, а поскольку я в отделе стратегических разработок, весь процесс прототипирования у меня происходит на глазах. И это все таки разные сущности и этапы разработки :-)
-
Абсолютно точно этим не занимался главный геймдиз :-) И да, архитектура кластера входит в круг задач для архитекторов.
Откуда такая инфа?
Можно ссылочку?
Я вот его нашел:
С 1997 года работает в сфере IT. В последнее время - ведущий разработчик проекта World of Tanks, заявленная должность - главный гейм-дизайнер проекта World of Tanks.
http://world-of-tank.livejournal.com/716.html
И как бэ он полностью соответствует моему представлению об архитекторе.
-
Абсолютно точно этим не занимался главный геймдиз :-) И да, архитектура кластера входит в круг задач для архитекторов.
Откуда такая инфа?
Можно ссылочку?
Я вот его нашел:
С 1997 года работает в сфере IT. В последнее время - ведущий разработчик проекта World of Tanks, заявленная должность - главный гейм-дизайнер проекта World of Tanks.
http://world-of-tank.livejournal.com/716.html
И как бэ он полностью соответствует моему представлению об архитекторе.
То есть по твоему архитектор это менеджер? :-D (да, менеджеры тоже работают в сфере IT, если работают в соответствующей компании).
Серб никогда не отвечает на технические вопросы. Он отвечает на окологеймплейные вопросы и общую политику компании в плане игроков. Он не архитектор, он геймдиз. Он ковыряется в истории танкостроения, лазает по архивам, пописывает рассказики. Но он не инженер, он не архитектор. И естественно он не архитектурил кластер. Максимум его технической компетенции и влияния на техническую часть - это сказать что, например, они не будут считать данные (попадания там и так далее) на стороне клиента (ибо очевидно что это открывает дорогу читерам). Ну и расставляет приоритеты типа - в следующем релизе физика, или поддержка многоядерности. Но это не архитекторные вопросы, это чисто менеджерско-маркетоидная работа.
Вот тебе пример реальной задачи которой занимается архитектор (то есть это пример из жизни а не выдумки): провести исследование и выбрать множество (возможно один) кодеков для поддержки мобильных терминалов (то есть чтобы VoIP-софтфон работал на смартфонах) нашей системой.
-
Э нет, valexey, вот он то как раз и есть архитектор. Ибо его ошибка будет самой дорогой.
Вот тебе пример реальной задачи которой занимается архитектор (то есть это пример из жизни а не выдумки): провести исследование и выбрать множество (возможно один) кодеков для поддержки мобильных терминалов (то есть чтобы VoIP-софтфон работал на смартфонах) нашей системой.
У вас там своя специфика. И суть вашей работы от меня бесконечно далека. Вполне возможно что ваш главный архитектор занимается подбором кодеков.
то есть это пример из жизни а не выдумки
А я ссылку значит выдумал, и должность ему приписал?
-
И еще ты имхо смешиваешь архитектора проекта "игра" и архитектора "игрового движка". Это обычно разные люди, и более того второй подчинен первому.
-
Э нет, valexey, вот он то как раз и есть архитектор. Ибо его ошибка будет самой дорогой.
Самой дорогой ошибкой будет ошибка маркетологов или даже учредителей компании. Значит ли это, что они архитекторы? :-)
Вот тебе пример реальной задачи которой занимается архитектор (то есть это пример из жизни а не выдумки): провести исследование и выбрать множество (возможно один) кодеков для поддержки мобильных терминалов (то есть чтобы VoIP-софтфон работал на смартфонах) нашей системой.
У вас там своя специфика. И суть вашей работы от меня бесконечно далека. Вполне возможно что ваш главный архитектор занимается подбором кодеков.
А кроме них это никто сделать и не сможет.
то есть это пример из жизни а не выдумки
А я ссылку значит выдумал, и должность ему приписал?
В каком месте про его должность упоминается слово "архитектор"?
-
И еще ты имхо смешиваешь архитектора проекта "игра" и архитектора "игрового движка". Это обычно разные люди, и более того второй подчинен первому.
Опять мимо :-)
Движок у них (WoT) вообще покупной, и очевидно, что разработчики именно движка не зависят от геймдиза и/или архитектора WoT. :-)
Хотя-я само понятие "движог" весьма расплывчато и условно. Так что тут мы можем скатиться снова в терминологический спор о том, что же на самом деле есть "движок" игры.
-
В каком месте про его должность упоминается слово "архитектор"?
:o
Тык там написано "ведущий разработчик", что как бэ есть синоним слова "архитектор".
-
Опять мимо :-)
Движок у них (WoT) вообще покупной, и очевидно, что разработчики именно движка не зависят от геймдиза и/или архитектора WoT. :-)
Как это мимо? Наоборот в самую точку. Это значит что скорее всего кластер архитектурили не они :)
-
В каком месте про его должность упоминается слово "архитектор"?
:o
Тык там написано "ведущий разработчик", что как бэ есть синоним слова "архитектор".
Эмм.. У меня должность "ведущий инженер-разработчик". :-) Значит ли это, что я какой-то там где-то там архи-тектор? ;-)
PS. Периодически шутим по поводу того, куда именно ведущий :-)
PPS, А Серб таки имеет должность - главный гейм-дизайнер.
-
Если бы мы специализировались не на мобильно-облачном сегменте, а на чём-то более стационарном (скажем пульт для дежурной медсестры для наблюдения за состоянием пациентов), то я вполне могу себе представить ББ в качестве основной платформы для разработки и распространения. Ну, а поскольку мы все ж таки в том числе программисты-профессионалы, подтянуть ББ в случае нужды наверно было бы можно. :-) Хотя задача в общем то не шибко памятежоркая, так что 64бита не актуально было бы.
А какие преимущества в этой задаче у блекбокса перед, ну хотя бы, сишарпом или явой?
Алексей, ты как-то пропустил этот вопрос Евгения, а было бы интересно услышать твой вариант ответа :)
-
Если бы мы специализировались не на мобильно-облачном сегменте, а на чём-то более стационарном (скажем пульт для дежурной медсестры для наблюдения за состоянием пациентов), то я вполне могу себе представить ББ в качестве основной платформы для разработки и распространения. Ну, а поскольку мы все ж таки в том числе программисты-профессионалы, подтянуть ББ в случае нужды наверно было бы можно. :-) Хотя задача в общем то не шибко памятежоркая, так что 64бита не актуально было бы.
А какие преимущества в этой задаче у блекбокса перед, ну хотя бы, сишарпом или явой?
Алексей, ты как-то пропустил этот вопрос Евгения, а было бы интересно услышать твой вариант ответа :)
Да, действительно. Я просто, помнится, поразился абсурдности вопроса.
Если кратко - то у ББ преимущество перед C#/Java в том, что на java/c# мне бы пришлось вначале написать ББ :-)
То есть ББ это почти готовая среда для исследований, разработки, и вполне себе построения готового диспетчерского пульта.
Прежде всего конечно исследования. Как мой рабочий процесс происходит, когда я в фазе исследований? Я цепляю наш датчик на себя. Побегал/попрыгал/по морозцу погулял. Данные накопил. Пришел в офис, слил эти данные на комп. Построил графики исходных данных, построи график того что там начитал текущий алгоритм. Начал в них таращиться. У-упс, алгоритм лажает. Пошел, чаю/какавы себе заварил, думаю почему лажает. Понял почему лажает - потому что он на такие извращения в принципе не рассчитан. Значит что? Значит надо образовываться - пошел читать исследования да патенты в интернет. Начитался. Понял что вот-это вот не прокатит для реалтайма, даже и пробовать не стоит. А вот это вот можно и попробовать, если модифицировать вот так.
Ну и что? Ну я сажусь и спокойно реализую этот метод. Реализовал. Надо проверять. Сую в него данные (а данные это массив как минимум за несколько минут, и одна секунда это например 100 значений), и мне, чтобы оценить, надо увидеть исходный график данных, обработанный, и ту информацию которую оттуда получилось вытащить. Запустил - увидел графики, понял что в коде лажа, поправил, снова запустил. Опять лажа. Поправил, запустил. Лажа, но уже другая, явно концептуальная. Выкинул метод, пошел думать дальше. И так N раз.
На N+1 раз вроде бы получается. О-ке-й. Теперь запускаем этот алгоритм в реалтайме (графики бегут на экране живьем), цепляем на себя датчик и начинаем моделировать житейские ситуации. Ну там, поотжиматься, побегать, походить. Поприседать. Упасть. Случайно уронить датчик... И все это краем глаза смотря на монитор и что там происходит, что там с алгоритмом. Не сдохло ли, не начал ли алгоритм излишне фантазировать о моих эволюциях.
И если и после этого работает, значит что? Значит надо поделиться с товарищами по разработке достигнутыми результатами. Значит надо написать некий документ с описанием метода, с кодом и с примерами данных и графиками. И здорово если оно будет сразу живым а не на скриншотах (хотя скриншоты никто не отменял) и народ сразу сможет прогнать это, не отходя от кассы, на образцах своих данных. Это в идеале конечно. И ББ мог бы позволить довольно близко к этому идеалу приблизиться.
-
Вот-вот :)
У некоторых такая схема работы в голове не помещается.
Между прочим, много у кого такие задачи есть, если покопаться. Не все осознают их специфику - и не отделяют часто от других задач (например, на работе хренарит ынтырпрайз на Джаве - когда надо какую-то личную задачу решить - берёт ту же самую Яву).
-
Вот-вот :)
У некоторых такая схема работы в голове не помещается.
Между прочим, много у кого такие задачи есть, если покопаться. Не все осознают их специфику - и не отделяют часто от других задач (например, на работе хренарит ынтырпрайз на Джаве - когда надо какую-то личную задачу решить - берёт ту же самую Яву).
Я, кстати, забыл одну проблему с ББ, которая даже в моем случае встала бы - проблема с системой контроля версий. Бинарная сущность составных документов пакостит.
В общем, идея то хороша, только её надо бы причесать под современное положение дел (когда это все разрабатывалось системы контроля версий были, прямо скажем, не шибко распространены).
PS. Ну, ява то хороша, если там j2ee не трогать. Но она ж язык. Ну, + IDE. То есть для чисто программерских целей там все ок. Но для вот таких вот исследований IDE не достаточно.
-
Уже лет 5 как работаем с SVN и бинарными исходниками.
Не могу понять проблемы, которую ты озвучил.
Мерджить несколько веток правок через SVN в модульном языке смысла нет. Ибо ответственность за модуль чёткая. Если возникает вариативность - то через модули реализации. В крайнем случае это такое исключение, что можно и через F9 слить потом.
Смотреть, что именно поменялось... Хм, не знаю, лезть в старые версии модуля приходится раз в год... Я даже не помню команд для этого.
Потому что стиль несколько другой: сделали реализацию как "заваренный ящик", используем. Вносим исправления, если вдруг что. А супер-вариативности, нелинейности развития в исходнике одного модуля не бывает.
Если вдруг нам надо экспериментировать и что-то старое (какой-то кусок, допустим) сохранить - то лучше это сделать явно в складке, прямо в модуле или под ним. Или в документе рядом с ним.
-
Уже лет 5 как работаем с SVN и бинарными исходниками.
Не могу понять проблемы, которую ты озвучил.
Мерджить несколько веток правок через SVN в модульном языке смысла нет. Ибо ответственность за модуль чёткая. Если возникает вариативность - то через модули реализации. В крайнем случае это такое исключение, что можно и через F9 слить потом.
Смотреть, что именно поменялось... Хм, не знаю, лезть в старые версии модуля приходится раз в год... Я даже не помню команд для этого.
Потому что стиль несколько другой: сделали реализацию как "заваренный ящик", используем. Вносим исправления, если вдруг что. А супер-вариативности, нелинейности развития в исходнике одного модуля не бывает.
Если вдруг нам надо экспериментировать и что-то старое (какой-то кусок, допустим) сохранить - то лучше это сделать явно в складке, прямо в модуле или под ним. Или в документе рядом с ним.
Понимаю что не понимаешь. :-) Потому, что используете svn причем скорее всего без вменяемой веб-морды, потому, что привыкли работать именно так. Я не критикую ваш подход, просто пытаюсь донести, что бывает и иначе.
Например один мой проект живет в bitbucket'e (там mercurial). И там дико удобно просматривать комиты и дифы между ними. Прямо через веб-морду. Также там можно оставлять коментарии к комиттам. Это крайне удобно. И не нужно никаких команд помнить. Удобно также смотреть исходники прямо там.
Модульность КП к схеме разработки имеет ну очень слабое отношение. То что там есть ключевое слово module волшебным образом не отменяет зависимости между модулями. То есть я полагаю что серьезных отличий от java/c# там не будет. Также не будет и отличий в случае грамотной организации богомерзких инклюдов в c++ (а с исклюдами обычно проблем таки нет, все давно чисто на автомате обходят эти грабли). Жесткая привязка модулей к людям без дублирования опять же опасна - человек заболел/уехал в отпуск, а в его штуке обнаружилась бага или недофича. Причем помним что раньше её вроде бы не было. И что? Приплыли? Впрочем, это ж еще обнаружить надо, где именно и что именно глючит. Такие забавные интерференции особенностей реализации приводящих в совокупности к багам бывают...
Короче, рабочий процесс достаточно слабо зависит от языка. И не надо пытаться все коллективы со всеми проектами под одну единственно верную гребенку причесывать. Я просто описал чего бы мне нехватало при использовании ББ. И описал преимущества ББ. Неудобство - следствие особенностей реализации. Достоинства - следствие концепции.
PS. А бинарные блобы в системе контроля версий это все же ущербно - они слабо для хранения блобов подходят, в частности у некоторых имеем перерасход дискового пространства.
-
Для просматривания "коммитов и дифов между ними" единственный аргумент - когда постороннему человеку надо изучить эволюцию кода?
Или есть другие причины?
-
Для просматривания "коммитов и дифов между ними" единственный аргумент - когда постороннему человеку надо изучить эволюцию кода?
Или есть другие причины?
Ну, во-первых я например интересуюсь всегда что делают "соседи". Во-вторых мне там удобно посмотреть и что я сделал. То есть каков сухой остаток от эволюции кода за день. Сие весьма приводит мысли в порядок.
Ну и раз в неделю/месяц осматриваю куда ушел исходный код. Я не доверяю человеческой памяти, она всегда лжет. Точнее, искажает картину. Поэтому редпочитаю сверяться с более точными источниками периодически. В результате лучше общую картину себе представляю.
-
То есть ББ это почти готовая среда для исследований, разработки, и вполне себе построения готового диспетчерского пульта.
...
Это в идеале конечно. И ББ мог бы позволить довольно близко к этому идеалу приблизиться.
А не лучше ли для этой цели использовать то, что для таких задач было разработано. LabView, например?
И я так и не понял, какие же преимущества у того же Блекбокса перед сишарпом конкретно в этой задаче. Для сишарпа тоже полно всяких компонентов, строящих графики и всё такое. Чем тут документы блекбокса лучше простых гуишных форм -- опять же непонятно...
-
В каком месте про его должность упоминается слово "архитектор"?
:o
Тык там написано "ведущий разработчик", что как бэ есть синоним слова "архитектор".
Эмм.. У меня должность "ведущий инженер-разработчик". :-) Значит ли это, что я какой-то там где-то там архи-тектор? ;-)
Конечно, при условии что у тебя есть свой проект.
ведущий разработчик проекта World of Tanks
-
И я так и не понял, какие же преимущества у того же Блекбокса перед сишарпом конкретно в этой задаче. Для сишарпа тоже полно всяких компонентов, строящих графики и всё такое. Чем тут документы блекбокса лучше простых гуишных форм -- опять же непонятно...
Тем, что ваши компоненты и гуишные формы разработаны так, как будто они очень важны - и требуют они моря внимания к себе.
В то время как в ББ, если не стоит задача презентабельности, можно забить на очень многие "шаблоны массовых приложений".
Посмотрите на этот UI, для которого не было написано ни одной строчки кода для работы с UI, только команды.
(вложение)
Подписи сделаны как вложенные маленькие текстовые вьюшки, поэтому модуль In читает только сами параметры, игнорируя подписи к ним.
А теперь прикиньте, сколько времени Вы будете делать на шарпе такое, с возможностью скопировать-вставить-сохранить-загрузить наборы параметров при комп. экспериментировании... И как весело будет изменять код, когда добавляется новый параметр или новая функция...
Как же, блин, туго доходит "в народ" идея текста как UI.
-
Как же, блин, туго доходит "в народ" идея текста как UI.
По-моему Вы какой-то Матлаб пытаетесь слепить из Блекбокса.
Другой вопрос -- надо ли это в обычном десктопном софте?
-
А теперь прикиньте, сколько времени Вы будете делать на шарпе такое, с возможностью скопировать-вставить-сохранить-загрузить наборы параметров при комп. экспериментировании... И как весело будет изменять код, когда добавляется новый параметр или новая функция...
Если это нужно чисто для экспериментов, а не как коммерческое приложение (а Ваша картинка на комерческое приложение никак не тянет), то на сишарпе будет тупо набор переменных в исходнике. Изменил, выполнил, посмотрел результат...
-
Если это нужно чисто для экспериментов, а не как коммерческое приложение (а Ваша картинка на комерческое приложение никак не тянет), то на сишарпе будет тупо набор переменных в исходнике. Изменил, выполнил, посмотрел результат...
Вы отдайте этот набор переменных прикладнику-машиностроителю. И объясните ему, что такое компилировать, отбилдить и проч.
Кстати, и для коммерческого приложения - прикладного пакета - такой интерфейс вполне подходит. Т.е. если можно рискнуть предложить самое удобное, пусть и не похожее на стандарты - то вперёд. А если в вашей рыночной нише всё так засижено, что пользователь посмотрит, испугается, закроет - и пойдёт качать ещё один аналог, то конечно, хрену...
-
По-моему Вы какой-то Матлаб пытаетесь слепить из Блекбокса.
А до Вас за 10 лет только дошло, что это одна из фишек - использование универсального ЯП в среде, которую можно "долепить" покруче уровня Матлаба? (Вы его, кстати, ещё купите... Ну или используйте какую-нить Maxima).
На долгом проекте будет обязательно такая точка (через N месяцев) когда выгоды от применения более предментно-ориентированного, но неуниверсального инструмента, сравняются с геморроем от того, что он неуниверсальный и неприспособленный для серьёзного программирования. В частности, вообще не позволяет сделать вменяемую архитектуру.
-
А уж для обучения как переоценить возможность получить, не программируя ГУИ вообще, юзабельные прикладные инструменты, считай, на любой лабе, хоть по алгоритмам, хоть по ЧМ, хоть по программированию статистики какой-нибудь...
-
Если это нужно чисто для экспериментов, а не как коммерческое приложение (а Ваша картинка на комерческое приложение никак не тянет), то на сишарпе будет тупо набор переменных в исходнике. Изменил, выполнил, посмотрел результат...
Вы отдайте этот набор переменных прикладнику-машиностроителю. И объясните ему, что такое компилировать, отбилдить и проч.
Кстати, и для коммерческого приложения - прикладного пакета - такой интерфейс вполне подходит. Т.е. если можно рискнуть предложить самое удобное, пусть и не похожее на стандарты - то вперёд. А если в вашей рыночной нише всё так засижено, что пользователь посмотрит, испугается, закроет - и пойдёт качать ещё один аналог, то конечно, хрену...
Для прикладника-машиностроителя нужно делать нормальный интерфейс, а не такой, как на Вашем скриншоте -- где-то что-то не так нажал и хер разберёшься потом.
Всё равно что серьёзные расчёты в экселе делать...
Почему ваш инфо21 свою физику программирует, а не в экселе считает?
-
Всё равно что серьёзные расчёты в экселе делать...
Почему ваш инфо21 свою физику программирует, а не в экселе считает?
если это шутка, то весьма херовая...
-
Всё равно что серьёзные расчёты в экселе делать...
Почему ваш инфо21 свою физику программирует, а не в экселе считает?
если это шутка, то весьма херовая...
Про расчёты в Экселе:
Researchers Finally Replicated Reinhart-Rogoff, and There Are Serious Problems. (http://www.nextnewdeal.net/rortybomb/researchers-finally-replicated-reinhart-rogoff-and-there-are-serious-problems)
О вычислениях в Экселе (http://scholar-vit.livejournal.com/324502.html)
Таки я остаюсь при мнении, что серьёзные расчёты в экселе лучше не делать...
по данным некоторых исследований 84% всех Эксельных таблиц содержат ту или иную существенную ошибку (Впрочем, возможно, что сам подсчет тоже проводили в Экселе, и доверять ему нельзя)
-
Таки я остаюсь при мнении, что серьёзные расчёты в экселе лучше не делать...
по данным некоторых исследований 84% всех Эксельных таблиц содержат ту или иную существенную ошибку (Впрочем, возможно, что сам подсчет тоже проводили в Экселе, и доверять ему нельзя)
Дело не в этом (точнее - не только в этом) -Инфо21 как минимум занимается творчеством...(решает НЕ типовые задачи, либо создает новые алгоритмы (модифицирует известные)) - эта деятельность идет в противоречии с философией Эксела -- использовать преимущественно ГОТОВЫЕ алгоритмы на более менее ТИПОВЫХ задачах. Я говорю про то, что даже если бы в Экселе не было ни одной ошибки - он бы им пользоваться вероятно не стал...
-
Таки я остаюсь при мнении, что серьёзные расчёты в экселе лучше не делать...
по данным некоторых исследований 84% всех Эксельных таблиц содержат ту или иную существенную ошибку (Впрочем, возможно, что сам подсчет тоже проводили в Экселе, и доверять ему нельзя)
Дело не в этом (точнее - не только в этом) -Инфо21 как минимум занимается творчеством...(решает НЕ типовые задачи, либо создает новые алгоритмы (модифицирует известные)) - эта деятельность идет в противоречии с философией Эксела -- использовать преимущественно ГОТОВЫЕ алгоритмы на более менее ТИПОВЫХ задачах. Я говорю про то, что даже если бы в Экселе не было ни одной ошибки - он бы им пользоваться вероятно не стал...
Примерно это же и к матлабу относится. Поэтому когда у нас идет фаза ковыряния DSP/математики, я сочетаю и эксель и матлаб и свое, полностью самописное на С++. Для разных подэтапов.
-
по данным некоторых исследований 84% всех Эксельных таблиц содержат ту или иную существенную ошибку (Впрочем, возможно, что сам подсчет тоже проводили в Экселе, и доверять ему нельзя)
Ещё раз про баги в этих ваших экселях:
Борьба с тридцатилетним багом (http://habrahabr.ru/post/198174/)
-
Таки я остаюсь при мнении, что серьёзные расчёты в экселе лучше не делать...
по данным некоторых исследований 84% всех Эксельных таблиц содержат ту или иную существенную ошибку (Впрочем, возможно, что сам подсчет тоже проводили в Экселе, и доверять ему нельзя)
Дело не в этом (точнее - не только в этом) -Инфо21 как минимум занимается творчеством...(решает НЕ типовые задачи, либо создает новые алгоритмы (модифицирует известные)) - эта деятельность идет в противоречии с философией Эксела -- использовать преимущественно ГОТОВЫЕ алгоритмы на более менее ТИПОВЫХ задачах. Я говорю про то, что даже если бы в Экселе не было ни одной ошибки - он бы им пользоваться вероятно не стал...
Примерно это же и к матлабу относится. Поэтому когда у нас идет фаза ковыряния DSP/математики, я сочетаю и эксель и матлаб и свое, полностью самописное на С++. Для разных подэтапов.
Хотел бы узнать: зачем использовать C++, если для моделирования Матлаб - самое то? Производительность неустраивает или что-то другое? Во-всяком случае, сестра Матлаба - Julia - очень даже производительный язык, почти наравне с Фортраном (если судить по оценкам производительности с их сайта).