Эмиссия денег должна зависеть от состояния экономики. То есть требуется встроить механизм, увеличивающий массу например пропорционально количеству совершаемых транзакций за единицу времени. Как общий показатель активности экономики.
Сама идея цифрового обмена интересна. Но проблема в объемах. Насколько я понял, ВСЕ клиенты хранят ВСЕ блоки и транзакции на своих машинах? Вы представляете какой объем транзакций совершается только одной из бирж за минуту? А крупной сетью магазинов? И это все предлагают хранить на компьютере-кошельке финального пользователя? Ну-ну…
> В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами.
Это очень и очень спорный вопрос. Можно доказывать вплоть до обратного.
В современной экономике IT-компании переходят от понятий продукта к понятию сервиса, который не размывает грань между разработкой и поддержкой. 95% проектов достается крупным компаниям, которые имеют постоянных клиентов. Цены на рынке более-менее устоявшиеся. Причем, основные затраты уходят отнюдь не на разработку, а на т.н. огранизацию «сервиса» (на зарплату менеджерам, инфраструктура, etc...).
Скажу курьезную фразу, но для такого вида бизнеса (сервис) делать качественные и законченные продукты невыгодно. Вы поставляете решение, и заинтересованы в постоянном спросе на него (а не разовом заказе!). А для этого Вы должны поставлять всегда наполовину сделанное решение.
> По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики
Классический пример неэффективно работающей компании. Огромные обороты при плачевном качестве продуктов, разрабатываемом на аутсорсинге (в Индии). Оборот, получаемый от продаж не идет ни в какое сравнение с затратами на разработку. Активно пытается пропехнуть свои Rational, крича о том, что все работают неэффективно. ))
Кораздо полезней было бы сделать подобную оболочку с SQL-ем. Инкапсулировать билдер запросов, батч, транзакции. Наподобии criteria в Hibernate, только более организованно и строго.
Просто Вы не видели статьи на других языках. В русской вики статьи достаточно глубоки и качественны (спасибо БСЭ!), особенно в научном и техническом разделах. Например большинство испанских — «Вася Пупкин», и это при том, что это третий язык в мире.
Не совсем понятно как поляки и итальянцы смогли выбраться в топ.
Между прочим, туалет — это лицо компании. А по его расположению можно судить о том, какое в компании отношение к представителям того или иного отдела. Понятно, что «боковушка у туалета» не самое козырное место, а реальные поцаны не сидят у параши.
Если же туалет общий — где-то на этаже, то большая вероятность, что компания самая заурядная, делящая этаж с кучей подобных ей быдлокомов.
Какая же вы лучшая компания? У вас даже туалета в офисе нет!
Чтобы там компании в проспектах ни рисовали, реальность везде одинаковая, ибо везде работают те же люди.
Тут, видимо, не совсем аплет. Делается крафтинг через Browser Environment. Обычно каким-то образом запускают классы, валяющиеся в кеше браузера, но уже не как аплеты, а обычные приложения, в обход песочницы.
Не вижу преимуществ перед assert-ами. Чем плохи контракты:
1. Требует конфигурирования дополнительных библиотек и средств компиляции.
2. Для выражения условий контрактов отсутвует поддержка codeassist в IDE, что делает написание оных неприятным.
3. Обычный javadoc с @param понятнее и нагляднее, нежели @Required, к тому же вылезает тултипом в любой IDE в codeassist. По сути javadoc — это и есть контракт.
> 5. Через пару месяцев появится что-то лучшее. Помните моду на нетбуки? Их называли будущим компьютеров. Теперь их место заняли планшеты.
Если планшет — очевидное продолжение нетбука, то на место планшета сложно придумать что-нибудь. Разве что двусторонний планшет )) или гибкую электронную газету. Но во всяком случае, это еще не скоро.
А вот цена на плашнеты будет падать, и очень быстро.
В отличие от обычных денег биткоины гарантируют аутентичность их владельца, поскольку на содержимое ключа полностью зависит выполненных транзакций. Естественно существуют гейты для конвертации биткоинов в другие валюты.
Дело в том, что деньги с момента их напечатания и вброса в массы ввиде кредита поднимаются вверх по финансовой пирамиде, а затем уходят с товарного рынка и больше никогда туда не возвращаются. В итоге деньги становатся виртуальными и служат исключительно как средство политической власти, начиная с долей акций компаниях и кончая кредитными обязательствами целых государств. Поэтому цифры в 50млрд никак не сопоставимы с ценами на реальные товары и услуги, в масштабах которых мы привыкли мыслить.
Есть другая идея 4D: одну из осей спроецировать на «время». То есть будет меняющаяся 3D сцена. Для возможности полного просмотра, камера должна перемещается внутри текущего 3D-среза сцены, плюс дополнительный контрол, который перемещает «время» вперед-назад (напрмер колесо мыши). Всегда интересовал вопрос: если долго «бегать» по такой сцене, возникнет ли когда-нибудь полное 4D-восприятие?
> Каждое утро на собрании начальник спрашивает тебя: «Что ты вчера делал?».
> — Багу исправлял.
Автор целый день исправлял багу в одном методе! Налицо эффективность TDD! Это не просто язвительное замечание. Производительность людей, зацикленных на TDD, реально такая. И ничего сложней валидатора они как правило не пишут. Вы хоть примеры-то для разнообразия поинтересней придумайте, а то одни валидаторы…
> — Слушай, я тут твой код дебажу-дебажу, а всё никак не могу понять, как это работает?
Так надо было по-русски прямо в коде и написать:
/** Энкодит букву по алгоритму:…
Например если на вход подать А, то получится Б */
public String encodeLetter( String letter )
Да-да, прямо в коде, не надо бояться! И ошибки не будет, и лишний тест не надо писать, и коллега сразу сообразит что к чему. Это называется контрактом. А в Вашем случае прекрасно сработает и это:
public String encodeLetter( String letter ) { return «Б» }
И будет соответствовать «спецификации».
> assertTrue(validateEmail(«tina.turner@music.info»)); // 4 letters now allowed!
Где спецификация самого метода? С каких хренов 4 буквы not allowed? Где это написано? При чем тут тесты? А 5 буквами как дела обстоят? А с доменом-поддоменом? Рановато +1 в карму…
Дело на самом деле не в этом. За всем этим стоит крупный испанский телеком Telefónica (он же O2 в других странах). По их словам, гугл сделал нерентабельным дальнейший вклад в инфраструктуру сетей, поскольку доход с окучки финальных пользователей полностью переходит гуглу. Провайдер запросил модель, при которой часть отчислений с показа рекламы гуглем их пользователям, переходит к ним. Иначе грозились ухудшить качество связи с сервисами гугла. Гугл отказался в агрессивной форме и заявил, что в противном случае сам двинет на рынок телекомов с гигабитным эзернетом в дома. Это вызвало бурную реакцию в среде телекомов. Тут же последовали иски из Германии о сборе данных о пользователях. Теперь вот в Испания подтянулась. Вобщем, Гугл щас будут в Европе давить.
Есть в современном такие люди — советчики. У них широкий кругозор, однако знания достаточно поверхностны. Тем не менее, они считают, что этих знаний им более чем достаточно, чтобы иметь твердое мнение что и как должно работать.
Контрактное программирование — разумная замена параноидальному TDD. Однако на практике точного javadoc-описание функции и assert-ов бывает более чем достаточно.
Код для проверки в строках аннотаций вводить тяжело, так как отсутствует поддержка GUI.
Их продукты находятся в стадии постоянной альфы, а в качестве платформы для тестов используются клиенты и их продакшн сервисы. Зачастую заявленный функционал продукта (иногда даже базовый и критический) просто не работает — это значит, что продукт не был ни разу опробован перед тем, как продан. Из Rational у меня базовый инструмент Websphere Integration Developer. Для нормальной работы 2Гб памяти было маловато. Запускается минут пять (сейчас вроде подправили — побыстрее стал). И это при том, что сам WAS пускался на другой тачке. Постоянно что-то отваливается или глючит, до сих пор при Copy-Paste и Ctrl-Z в BPEL-е портит проект, несколько раз запарывал workspace.
Фиг знает. В Java есть классы HtmlURLConnection, но HTMLEditorKit. Есть ZipInputStream, но и GZIPInputStream. Есть как XMLReader, так и XmlReader. Короче, надо писать так, чтобы было понятно — остальное IDE исправит.
Кстати, по правилам как назвать переменную urlConnection или uRLConnection? )))
Пардон, а под чем тогда автор подписывается как разработчик? Под мегасуперпуперпрограммойкотораярешитвсепотребностиклиентаисделаетегодовольным?
Да, нормальный анализ — это уже полпроекта. И на западе для этого нанимают специальных людей, которые стоят дорого, и которые пишут функциональные реквизиты. И надо сказать, это того стоит. Затем в дело вступают менеджеры, назначая цену на проект, а уже потом разработчики.
Другое дело, что клиент не хочет платить за спецификацию (и зачастую сам не знает что хочет), но уже просит назвать цену. В этом случае вкладываться можно использовать метод пошаговой детализации (или прогрессивного jpeg-а как его назвал Лебедев). Делается общий набросок проекта примерно что хочет клиент. Затем уточняются детали первого уровня, создается модель функционального core, и каждая из задач оценивается в минимаксных рамках. По завершении работы должен быть создан рабочий прототип системы. Общая проработка задач должна быть ровно настолько, чтобы с одной стороны быть функциональным, а с другой не превышать баланс. Дальнейшая детализация, второстепенный функционал и пожелания клиента откладывается на вторую фазу, которая оценивается отдельно.
IBM — жирная неповоротливая и неуправляемая компания. Поддерживается госдепом США и по сути монополист по части государственных тендеров. Основной бизнес был продажа мейнфреймов и интегральных решений на их основе, пока ситуация на рынке не начала меняться, и компания не двинула в сторону аутсорсинга.
Политика в области рынка была по большей мере странной. Компания берется практически за все, но никогда ничего не доводит до конца, в результате чего сектор рынка бывает отъеден менее мажорными, но более шустрыми компаниями. IBM несправедливо до самого последнего момента обходила рынок небольших компаний и частных лиц, а именно там сейчас находится основная масса потребителей.
При хорошем финансирования компания стала инкубатором инновационных проектов. Однако наиболее успешные проекты всегда отпочковывались в самостоятельные компании. Всмомним историю с Майкрософтом или САПом. Другие разработки были просто нагло скопированы и использованы другими (напр. есть один такой крупный производитель одной базы данных). Другие же, менее везучие проекты были просто загублены на корню (кто помнит ОС/2, хотя тысячи их).
Качество программных продуктов IBM оставляет желать лучшего. Собственно, это даже не продукты, а некие наработки, при помощи которых специалисты IBM окучивают клиентов. Представьте себе Microsoft Office к которому идет инструкция по установке и конфигурации на 250 страниц. Работать после установки как правило отказыватеся. Затем выясняется, что Продукт работает с WinXP SP2 и не работает с SP3. Для работы требуется скачать фикспак размером с сам Продукт. Установив и добившись чтобы редактор запускался, остаешься приятно удивлен интерфейсом программы — все редактирование текста осуществляется через систему команд и вспомогательных скриптов, в меню услужливо вынесены команды Load и Save. Любое неверное действие выдает непонятную ошибку с кодом и за ней 5 экранов стек трейса. Клиент осознает, что интерфейс отнюдь не интуитивный, и разобраться с Продуктом самому ему не представляется возможным. IBM естественно предлагает платные курсы по работе с Продуктом на английском языке, читаемые индусом, живущим в Ирландии. После обучения на экране, наконец, появилась фраза «Hello world!». Вставка картинок в текст отнесена к разделу трансцендентальной магии — все знают, что можно, но не знают как. Даже на курсах у преподавателя не получалось. Поэтому картинки аккуратно приклеиваются на лист уже после печати. Очень часто метод редактирования, описаный в документации не работает, и приходистся обращаться на форумы. Иногда выясняется, что перед использованием команды ее нужно сконфигурировать вручную в пяти разных конфигах, а иногда дают заклинание, которое надо копипейстнуть в нужное место. В один прекрасный момент редактор запарывает большой документ. Открываешь в службе поддержки PMR (как, у Вас нет платной поддержки?), тебе обещают восстановить документ. Присылают консультора за 800 долларов в день, который делает анализ и говорит, что ваш метод редактирования текста неправильный и дает рекоммендации по правильному редактированию, однако не решает проблемы. Кроме того, при такой нагрузке на текстовый процессор рекомендуется кластерная архитектура типа Golden и даже за символическую плату предлагает ее настроить (однако при этом все документы будут утеряны). После нескольких месяцев служба поддержки сообщает, что поддержка этой версии программы завершена, и Вам следует проапгрейдиться до более новой. Для осуществления миграции служба предоставит команду специалистов.
Сама идея цифрового обмена интересна. Но проблема в объемах. Насколько я понял, ВСЕ клиенты хранят ВСЕ блоки и транзакции на своих машинах? Вы представляете какой объем транзакций совершается только одной из бирж за минуту? А крупной сетью магазинов? И это все предлагают хранить на компьютере-кошельке финального пользователя? Ну-ну…
Это очень и очень спорный вопрос. Можно доказывать вплоть до обратного.
В современной экономике IT-компании переходят от понятий продукта к понятию сервиса, который не размывает грань между разработкой и поддержкой. 95% проектов достается крупным компаниям, которые имеют постоянных клиентов. Цены на рынке более-менее устоявшиеся. Причем, основные затраты уходят отнюдь не на разработку, а на т.н. огранизацию «сервиса» (на зарплату менеджерам, инфраструктура, etc...).
Скажу курьезную фразу, но для такого вида бизнеса (сервис) делать качественные и законченные продукты невыгодно. Вы поставляете решение, и заинтересованы в постоянном спросе на него (а не разовом заказе!). А для этого Вы должны поставлять всегда наполовину сделанное решение.
> По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики
Классический пример неэффективно работающей компании. Огромные обороты при плачевном качестве продуктов, разрабатываемом на аутсорсинге (в Индии). Оборот, получаемый от продаж не идет ни в какое сравнение с затратами на разработку. Активно пытается пропехнуть свои Rational, крича о том, что все работают неэффективно. ))
Не совсем понятно как поляки и итальянцы смогли выбраться в топ.
www.artlebedev.ru/everything/toilets/
Между прочим, туалет — это лицо компании. А по его расположению можно судить о том, какое в компании отношение к представителям того или иного отдела. Понятно, что «боковушка у туалета» не самое козырное место, а реальные поцаны не сидят у параши.
Если же туалет общий — где-то на этаже, то большая вероятность, что компания самая заурядная, делящая этаж с кучей подобных ей быдлокомов.
Чтобы там компании в проспектах ни рисовали, реальность везде одинаковая, ибо везде работают те же люди.
1. Требует конфигурирования дополнительных библиотек и средств компиляции.
2. Для выражения условий контрактов отсутвует поддержка codeassist в IDE, что делает написание оных неприятным.
3. Обычный javadoc с @param понятнее и нагляднее, нежели @Required, к тому же вылезает тултипом в любой IDE в codeassist. По сути javadoc — это и есть контракт.
Если планшет — очевидное продолжение нетбука, то на место планшета сложно придумать что-нибудь. Разве что двусторонний планшет )) или гибкую электронную газету. Но во всяком случае, это еще не скоро.
А вот цена на плашнеты будет падать, и очень быстро.
> — Багу исправлял.
Автор целый день исправлял багу в одном методе! Налицо эффективность TDD! Это не просто язвительное замечание. Производительность людей, зацикленных на TDD, реально такая. И ничего сложней валидатора они как правило не пишут. Вы хоть примеры-то для разнообразия поинтересней придумайте, а то одни валидаторы…
> — Слушай, я тут твой код дебажу-дебажу, а всё никак не могу понять, как это работает?
Так надо было по-русски прямо в коде и написать:
/** Энкодит букву по алгоритму:…
Например если на вход подать А, то получится Б */
public String encodeLetter( String letter )
Да-да, прямо в коде, не надо бояться! И ошибки не будет, и лишний тест не надо писать, и коллега сразу сообразит что к чему. Это называется контрактом. А в Вашем случае прекрасно сработает и это:
public String encodeLetter( String letter ) { return «Б» }
И будет соответствовать «спецификации».
> assertTrue(validateEmail(«tina.turner@music.info»)); // 4 letters now allowed!
Где спецификация самого метода? С каких хренов 4 буквы not allowed? Где это написано? При чем тут тесты? А 5 буквами как дела обстоят? А с доменом-поддоменом? Рановато +1 в карму…
Код для проверки в строках аннотаций вводить тяжело, так как отсутствует поддержка GUI.
Кстати, по правилам как назвать переменную urlConnection или uRLConnection? )))
Да, нормальный анализ — это уже полпроекта. И на западе для этого нанимают специальных людей, которые стоят дорого, и которые пишут функциональные реквизиты. И надо сказать, это того стоит. Затем в дело вступают менеджеры, назначая цену на проект, а уже потом разработчики.
Другое дело, что клиент не хочет платить за спецификацию (и зачастую сам не знает что хочет), но уже просит назвать цену. В этом случае вкладываться можно использовать метод пошаговой детализации (или прогрессивного jpeg-а как его назвал Лебедев). Делается общий набросок проекта примерно что хочет клиент. Затем уточняются детали первого уровня, создается модель функционального core, и каждая из задач оценивается в минимаксных рамках. По завершении работы должен быть создан рабочий прототип системы. Общая проработка задач должна быть ровно настолько, чтобы с одной стороны быть функциональным, а с другой не превышать баланс. Дальнейшая детализация, второстепенный функционал и пожелания клиента откладывается на вторую фазу, которая оценивается отдельно.
Политика в области рынка была по большей мере странной. Компания берется практически за все, но никогда ничего не доводит до конца, в результате чего сектор рынка бывает отъеден менее мажорными, но более шустрыми компаниями. IBM несправедливо до самого последнего момента обходила рынок небольших компаний и частных лиц, а именно там сейчас находится основная масса потребителей.
При хорошем финансирования компания стала инкубатором инновационных проектов. Однако наиболее успешные проекты всегда отпочковывались в самостоятельные компании. Всмомним историю с Майкрософтом или САПом. Другие разработки были просто нагло скопированы и использованы другими (напр. есть один такой крупный производитель одной базы данных). Другие же, менее везучие проекты были просто загублены на корню (кто помнит ОС/2, хотя тысячи их).
Качество программных продуктов IBM оставляет желать лучшего. Собственно, это даже не продукты, а некие наработки, при помощи которых специалисты IBM окучивают клиентов. Представьте себе Microsoft Office к которому идет инструкция по установке и конфигурации на 250 страниц. Работать после установки как правило отказыватеся. Затем выясняется, что Продукт работает с WinXP SP2 и не работает с SP3. Для работы требуется скачать фикспак размером с сам Продукт. Установив и добившись чтобы редактор запускался, остаешься приятно удивлен интерфейсом программы — все редактирование текста осуществляется через систему команд и вспомогательных скриптов, в меню услужливо вынесены команды Load и Save. Любое неверное действие выдает непонятную ошибку с кодом и за ней 5 экранов стек трейса. Клиент осознает, что интерфейс отнюдь не интуитивный, и разобраться с Продуктом самому ему не представляется возможным. IBM естественно предлагает платные курсы по работе с Продуктом на английском языке, читаемые индусом, живущим в Ирландии. После обучения на экране, наконец, появилась фраза «Hello world!». Вставка картинок в текст отнесена к разделу трансцендентальной магии — все знают, что можно, но не знают как. Даже на курсах у преподавателя не получалось. Поэтому картинки аккуратно приклеиваются на лист уже после печати. Очень часто метод редактирования, описаный в документации не работает, и приходистся обращаться на форумы. Иногда выясняется, что перед использованием команды ее нужно сконфигурировать вручную в пяти разных конфигах, а иногда дают заклинание, которое надо копипейстнуть в нужное место. В один прекрасный момент редактор запарывает большой документ. Открываешь в службе поддержки PMR (как, у Вас нет платной поддержки?), тебе обещают восстановить документ. Присылают консультора за 800 долларов в день, который делает анализ и говорит, что ваш метод редактирования текста неправильный и дает рекоммендации по правильному редактированию, однако не решает проблемы. Кроме того, при такой нагрузке на текстовый процессор рекомендуется кластерная архитектура типа Golden и даже за символическую плату предлагает ее настроить (однако при этом все документы будут утеряны). После нескольких месяцев служба поддержки сообщает, что поддержка этой версии программы завершена, и Вам следует проапгрейдиться до более новой. Для осуществления миграции служба предоставит команду специалистов.
Навеяно линейкой продуктов Websphere…