Вот интересно, если долго медитировать на такую штуку, возникнет ли _ощущение_ 4D-реальности? И знает ли история людей, у которых возникало подобное ощущение?
P.S. классно бы было на подобную штуку в движении посмотреть в стерео.
> Я программист. Поэтому, меня всегда потрясают вещи, которые «просто работают».
…
> это и есть оскорбление все раздутых, коммерческих, дорогих BPEL-for-Web-Services-on-J2EE (or .NET) серверов приложений и т.д.
К великому сожалению, нынче вещи, которые «просто работают» не продать :(
Эмиссия денег должна зависеть от состояния экономики. То есть требуется встроить механизм, увеличивающий массу например пропорционально количеству совершаемых транзакций за единицу времени. Как общий показатель активности экономики.
Сама идея цифрового обмена интересна. Но проблема в объемах. Насколько я понял, ВСЕ клиенты хранят ВСЕ блоки и транзакции на своих машинах? Вы представляете какой объем транзакций совершается только одной из бирж за минуту? А крупной сетью магазинов? И это все предлагают хранить на компьютере-кошельке финального пользователя? Ну-ну…
> В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами.
Это очень и очень спорный вопрос. Можно доказывать вплоть до обратного.
В современной экономике 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.
P.S. классно бы было на подобную штуку в движении посмотреть в стерео.
…
> это и есть оскорбление все раздутых, коммерческих, дорогих BPEL-for-Web-Services-on-J2EE (or .NET) серверов приложений и т.д.
К великому сожалению, нынче вещи, которые «просто работают» не продать :(
Сама идея цифрового обмена интересна. Но проблема в объемах. Насколько я понял, ВСЕ клиенты хранят ВСЕ блоки и транзакции на своих машинах? Вы представляете какой объем транзакций совершается только одной из бирж за минуту? А крупной сетью магазинов? И это все предлагают хранить на компьютере-кошельке финального пользователя? Ну-ну…
Это очень и очень спорный вопрос. Можно доказывать вплоть до обратного.
В современной экономике 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.