@2. У меня такое ощущение, что тактика Apple такова — выпускать хорошие
продукты и девайсы с заниженными возможностями.@
А разве так поступает только яблоко? Та же циска на своё сетевое оборудование ставит ограничение не более 5-ти лет, и не скрывает этого! Хотя их киски могут работать и до 20 лет, что подтверждают китайцы, которые купили в своё время оборудование с завершённым сроком службы, взломали защиту и пользуются до сих пор и не жалуются.
Ведь перенасыщение в бизнесе очень вредно — если ты придёшь на рынок и вывалишь всё сразу, то ты один раз продашь один продукт, а успех крупных компаний в том что они один продукт продают много раз! Но каждый раз с новой функциональность (незначительной порой — но всё же новой).
аналогия
Познакомился парень с девушкой и при первой встрече выложил ей все свои плюсы, все хорошие качества (сильный, умный, богатый, добрый, талантливый и прочее). При последующих встречах она будет воспринимать это как должное и требовать от него новых свершений (что бы избежать скуки). А так как ему (предположим) больше нечего рассказать о себе — то они расстанутся. Другой же, не такой сильный, умный, богатый, добрый, талантливый как первый, но будет рассказывать ей про себя понемногу, в итоге она проведёт с ним больше встреч, и каждый раз будет узнавать про него что-то новое, он и такой и такой и такой и вот такой. В конце концов их встречи увенчаются результатом (секс). Более того он будет регулярным.
Парень соблазняет девушку что бы получить регулярный секс. Компании соблазняют клиентов что бы получить регулярные продажи. Может немного натянуто — но общая мысль приблизительно такая: в бизнесе, любви, войне — правил нет и победителей не судят.
Ни о каком Agile речь не шла. А составлять акты — это идиллия разработки — которая прокатит только в юриспурденции и максимум в рекламе — редко в айти.
Один из интересных моментов — аппетит приходит во время еды, и после того как заказчик получает продукт он всегда хочет что-то дополнить и изменить, даже в процессе разработки, когда он наблюдает промежуточные результаты у него есть свои пожелания к изменениям. Как быть?
Описанный выше подход верен, в том смысле что думать и готовиться необходимо.
Однако время когда заказчик смотрит на тебя влюблёнными глазами после того, как ты ему расписал во всей красе будущий проект прошло.
Сейчас он, заказчик, после всех твоих «росказней» и ТЗ добавит ещё вагон «мелких требований» и в процессе разработки будет добавлять по «маленькой тележке» требований в день.
Как грамотно тут применять итеративный подход? У меня пока получается только интуитивно — но это же не выход. Кто подскажет?
Насчёт того, что InterSystems использует MapReduce — я несколько поторопился, прошу меня извинить. Но в Cache заложена база для организации распределённых вычислений — это и ECP и поддержка OpenVMS.
А зачем они это сделали — это вопрос к ним, может быть для того, что бы я мог выполнить свой дипломный проект и распределёно посчитать систолические матричные структуры :)))
каше ровно на столько мощная быстрая и надёжная — насколько умело её использовать (скажу по себе — используем мы её ещё недостаточно умело)
Можешь зайти на сайт — и посмотреть.
А в блоге буду продолжать писать.
set l="^Tree" //устанавливаем значение переменной
for { //цикл
set l=$query(@l) //берём следующий по очереди элемент дерева (алгоритм обхода функции $query сверху вниз затем справа налево)
quit:l="" //выходим из цикла когда всё обошли
set len=$querylength(l) //определяем глубину вложенности (вниз) текущего узла
for i=1:1:len {write " "} //печатаем отступы
write "(",$get(@l),") ",$querysubscript(l,len),! //печатем в скобках значение узла + его имя
}
сокращённый вариант
s l="^Tree" f { s l=$q(@l) q:l="" s len=$ql(l) f i=1:1:len {w " "} w "(",$g(@l),")",$qs(l,len),! }
В нодах действительно можно хранить всё что угодно — в глобалах Каше хранятся все коды классов скомпилированных и нескомпилированных программ. По большому счёту кроме деревьев там больше ничего нет. Хотя не имею личного опыта работы с ABS (Каше не основывается на абстрактных синтаксических деревьях) — может кто с ними (ABS) работал? Поделитесь опытом.
про скорость обработки таких деревьев я скромно умолчу — время рекурсивной обработки зависит от размера дерева логарифмически. То есть вывод по скорости дерева с миллионом узлов аналогичен select * From table (предположим что имеем там миллион записей). Насчёт сортировки тоже заморачиваться не стоит.
И вообще преобразовать табличные данные в деревянные — легко, обратная процедура не всегда возможна и очень ресурсоёмка (имеется ввиду на уровне БД а не интрефейса).
Наполнение пользовательской базы — будет Ваша основная проблема — если насобираете миллион пользователей — молодцы.
Но почему на хабре никто про Норберта Виннера не напишет, может мне набросать статейку?
@2. У меня такое ощущение, что тактика Apple такова — выпускать хорошие
продукты и девайсы с заниженными возможностями.@
А разве так поступает только яблоко? Та же циска на своё сетевое оборудование ставит ограничение не более 5-ти лет, и не скрывает этого! Хотя их киски могут работать и до 20 лет, что подтверждают китайцы, которые купили в своё время оборудование с завершённым сроком службы, взломали защиту и пользуются до сих пор и не жалуются.
Ведь перенасыщение в бизнесе очень вредно — если ты придёшь на рынок и вывалишь всё сразу, то ты один раз продашь один продукт, а успех крупных компаний в том что они один продукт продают много раз! Но каждый раз с новой функциональность (незначительной порой — но всё же новой).
аналогия
Познакомился парень с девушкой и при первой встрече выложил ей все свои плюсы, все хорошие качества (сильный, умный, богатый, добрый, талантливый и прочее). При последующих встречах она будет воспринимать это как должное и требовать от него новых свершений (что бы избежать скуки). А так как ему (предположим) больше нечего рассказать о себе — то они расстанутся. Другой же, не такой сильный, умный, богатый, добрый, талантливый как первый, но будет рассказывать ей про себя понемногу, в итоге она проведёт с ним больше встреч, и каждый раз будет узнавать про него что-то новое, он и такой и такой и такой и вот такой. В конце концов их встречи увенчаются результатом (секс). Более того он будет регулярным.
Парень соблазняет девушку что бы получить регулярный секс. Компании соблазняют клиентов что бы получить регулярные продажи. Может немного натянуто — но общая мысль приблизительно такая: в бизнесе, любви, войне — правил нет и победителей не судят.
Описанный выше подход верен, в том смысле что думать и готовиться необходимо.
Однако время когда заказчик смотрит на тебя влюблёнными глазами после того, как ты ему расписал во всей красе будущий проект прошло.
Сейчас он, заказчик, после всех твоих «росказней» и ТЗ добавит ещё вагон «мелких требований» и в процессе разработки будет добавлять по «маленькой тележке» требований в день.
Как грамотно тут применять итеративный подход? У меня пока получается только интуитивно — но это же не выход. Кто подскажет?
знаешь 90%
спрашиваешь о 10%
А зачем они это сделали — это вопрос к ним, может быть для того, что бы я мог выполнить свой дипломный проект и распределёно посчитать систолические матричные структуры :)))
Можешь зайти на сайт — и посмотреть.
А в блоге буду продолжать писать.
set l="^Tree" //устанавливаем значение переменной for { //цикл set l=$query(@l) //берём следующий по очереди элемент дерева (алгоритм обхода функции $query сверху вниз затем справа налево) quit:l="" //выходим из цикла когда всё обошли set len=$querylength(l) //определяем глубину вложенности (вниз) текущего узла for i=1:1:len {write " "} //печатаем отступы write "(",$get(@l),") ",$querysubscript(l,len),! //печатем в скобках значение узла + его имя }сокращённый вариант
s l="^Tree" f { s l=$q(@l) q:l="" s len=$ql(l) f i=1:1:len {w " "} w "(",$g(@l),")",$qs(l,len),! }И вообще преобразовать табличные данные в деревянные — легко, обратная процедура не всегда возможна и очень ресурсоёмка (имеется ввиду на уровне БД а не интрефейса).