Как я понимаю, идеи того дзена, о котором пишет автор включают в себя:
1) жить настоящим, текущим моментом
2) воспринимать вещи такими, какие они есть
3) избавиться от дуальных стереотипов, очистить разум, сфокусироваться
Когда-то читал о том, что наш биполярный мир нужно воспринимать как единый. Радости и печали — две части целого, (3) и, если рассматривать свое эмоциональное состояние как данность (2), то пропадает важность конкретного состояния и приходит спокойствие. Как-то так.
Одно из основных преимуществ Qt в его интуитивности и единообразии, то, что называется solidity. Замечал, что там есть методы для всего, что только можно придумать. Можно сделать почти все, что нужно, и без грязных хаков и костылей. Документация обалденна, иерархия классов логична, конкретна и понятна. Инструментарий — без комментариев.
Не совсем понял к чему вы это написали? Я как раз говорил о том, что продукт должен быть достаточно гибким, чтобы у разработчиков была возможность подстроиться под требования рынка, но при этом достаточно жестким, чтобы не развалиться по пути к решению задачи.
В том, что у вас все модели исходят из интерфейсов — это не есть плохо.
Во-первых, очень удобно документировать: все что торчит наружу — торчит из интерфейса. И тестировать API тоже удобно.
Во-вторых, вы еще сотню раз подумаете, а нужен ли наружу тот метод, который вы хотите протащить. Должен ли он быть в этом месте, является ли он методом этого интерфейса? А может это уже совсем другой интерфейс?
В -третьих, совершенно не факт, что у вас не появится в будущем другой реализации. Однако наличие абстракций в разумных пределах не сильно повышает сложность кода. Это цена, которую необходимо и можно заплатить за гибкость.
А не задумывались почему так? Не раз встречался с фразами от потребителя: «Ну вы же специалист — ну что вам стоит?» Хотя в общем случае это правильно, что заказчих хочет чтобы лифт ездил и так и сяк. Хочет — надо сделать. Ведь софт (soft) — это мягкий, податливый. В отличие от харда (hardware) — который просто так и не изменить. И софт должен оставаться мягким вне зависимости от его сложности, его должно быть можно изменить так, как хочет заказчик. Это тоже одна из задач разработчика. Прослойка firmware — другое дело, кстати, она не сможет делать больше, чем заложено в железе.
Если заказчик просит изменить что-то, надо просто назвать ему соответствующую цену. И все вопросы сразу отпадут ;)
Скажем так, тестирование конечно важно. Даже и необходимо. Но все жа главная цель программирования — написать программу, а не тесты. И эта программа должна правильно делать то, что она должна делать.
Но тут возникает проблема — что считать правильным? Я для себя определил так: делать правильно — это делать сообразно требованиям осозанным мной и заказчиком в данный момент времени. Требования могут немного измениться в процессе разработки и надо закладывать такую гибкость, которая позволит недорого изменить функционал всвязи с этим. Ну а потом — рефакторинг. Вот тут будут незаменимы тесты как раз.
Сказать что перл крут — ничего не сказать. Когда выбирал себе скриптовый язык между перл и пхп 10 лет назал — стройность и строгость перла были ключевыми факторами. А еще 10 лет назад, когда был совсем маленьким программером — возможность выполнить перл-код из переменной была просто космос. О рефлексии тогда я ничего не знал. )) О, ностальжи…
Если уж автор приводит аналогию велосипеда — а велосипедной рамы, как некоего неделимого модуля системы, которые выполняет свою функцию надо иметь ввиду следующее:
1) рама — несущий элемент, ответсвенный, а значит дробление его на мелкие части повышает вероятность отказа или поломки.
2) рамы бывают разные, форма у них похожа, однако рамы не взаимозаменяемы (интерфейсы каретки, рулевой колонки, подседельной трубы разные)
3) если пользователю нужно получить наиболее надежный и целесосбразный вариант — реализация рамы делается под конкретного пользователя (карбон, титан и т.п.)
4) именно рама задает практически все свойства велосипеда.
Исторически сложилось, что рама хардтейла получила один съемный элемент — петух заднего переключателя — и то, для повышения ремонтопригодности и даже не на всех рамах этого типа он есть.
Я хочу сказать о том, что для каждого изменения в сторону развязывния кода нужны предпосылки. Считаю, что главной задачей разработчика в этой части является создание такого кода, который при необходимости несложно рефакторить и развязать. Хотя это конечно ИМХО.
Модуляризовать ради того, чтобы просто получить кучу модулей — раньше времени увеличить сложность продукта. Создать кучу интерфейсов, применить кучу паттернов просто так? Сложность (а соответственно и стоимость разработки) должна возрастать с ростом полезности, ведь так?
Но во-первых, нет проблем воспользоваться USB-концентратором для увеличения их количества. Во-вторых, я лишь указал на то, что есть решения, которые при небольших отличиях (не всем на тонком клиенте надо много USB, а если подключать не только клаву-мышку — все равно нужен будет хаб) — решение кубокса более законченное, что-ли. А еще, если девайс делается в коммерческих целях, то нужно учитывать конкурентов, не так ли?
А чем не устраивает вот это: www.solid-run.com/cubox? Честно говоря не увидел серьезных отличий в железе. А тут уже в корпусе все красиво сделано, и ценник не такой кусачий.
Поправьте меня, если ошибаюсь, но кажется ни одна противоугонная система не интегрируется в систему EFI. А «паук» это система, позволяющая обойти блокировку топливного насоса или имобилайзер. К мозгам имеет слабое отношение.
В этом случае надо левый светодиодик сделать зеленым, средний — желтым, а правый — красным. И по уровню их зажигать. Будет красиво двигаться стрелка и подсвечиваться. В темноте будет хорошо виден уровень загрузки невооруженным глазом.
А что значит юридическая ответственность? Если есть лицензионное соглашение, к примеру GPL — программа используется на свой страх и риск. И пользователь должен это понимать.
С другой стороны, если этой самой лицензией не ограничивается использование открытого кода в закрытых разработках — какая-либо компания может взять код, проревизить и выпустить продукт за деньги. И за эти самые деньги пользователь получит гарантию работоспособности. Юридически значимую.
Сам давно интересовался темой открытого EFI блока. Ввиду прогресса, который налицо интересно следующее:
— будет ли полностью открыта хардверная часть
— будет ли возможность заказывать пустой блок
— будут ли официальные мануалы по подключению на разные модели авто?
Это я к чему — вот у меня есть тоета, хочу я на нее поставить блок, но в автоэлектрике я два по пять. Хочу переходник сделать по мануалам и поменять официальный блок на кастомный. Прошить под мою тоету и дальше ковыряться с настройками. В идеале, для обывателя вот так было бы клево.
Надо будте такую штуку сделать, только не на индикаторах с магнитофона, а на стрелочных амперметрах… или вольтметрах. Черных таких, маленьких. И добавить немного инерционности, чтобы не дергались.
История говорит нам о том, что да, владельцы долларов начали истребовать золотое обеспечение в обмен на доллары. Но не говорит нам о том, что именно такое истребование было причиной отмены золотого стандарта. ;) В общем то не важно что было причиной, а что следствием. Но отмена золотого стандарта непосредственно связана с необходимостью создания управляемой инфляции.
На самом деле, касаемо биткойна интересно, что будет с форками, как они поведут себя? Если фантазировать то: биткойн становится все труднее добывать и цена его возрастает. Лайткойн будет добываться, но это будет все сложнее. Далее будет происходить перераспределение ресурсов (например долларов) в пользу более дешевых форков, что повлечет за собой стабилизацию цены биткойна и лайта и возрастание цены форков как следствие капитализации. То есть наличие форков как бы дополняет ограниченную эмиссию биткойна. Это как например использовать для расчетов золото и, к примеру барий. И то и другое ограниченный ресурс, но количество разное и спрос разный, и разная цена от этого. Поправьте если я не прав.
1) жить настоящим, текущим моментом
2) воспринимать вещи такими, какие они есть
3) избавиться от дуальных стереотипов, очистить разум, сфокусироваться
Когда-то читал о том, что наш биполярный мир нужно воспринимать как единый. Радости и печали — две части целого, (3) и, если рассматривать свое эмоциональное состояние как данность (2), то пропадает важность конкретного состояния и приходит спокойствие. Как-то так.
Во-первых, очень удобно документировать: все что торчит наружу — торчит из интерфейса. И тестировать API тоже удобно.
Во-вторых, вы еще сотню раз подумаете, а нужен ли наружу тот метод, который вы хотите протащить. Должен ли он быть в этом месте, является ли он методом этого интерфейса? А может это уже совсем другой интерфейс?
В -третьих, совершенно не факт, что у вас не появится в будущем другой реализации. Однако наличие абстракций в разумных пределах не сильно повышает сложность кода. Это цена, которую необходимо и можно заплатить за гибкость.
Если заказчик просит изменить что-то, надо просто назвать ему соответствующую цену. И все вопросы сразу отпадут ;)
Но тут возникает проблема — что считать правильным? Я для себя определил так: делать правильно — это делать сообразно требованиям осозанным мной и заказчиком в данный момент времени. Требования могут немного измениться в процессе разработки и надо закладывать такую гибкость, которая позволит недорого изменить функционал всвязи с этим. Ну а потом — рефакторинг. Вот тут будут незаменимы тесты как раз.
1) рама — несущий элемент, ответсвенный, а значит дробление его на мелкие части повышает вероятность отказа или поломки.
2) рамы бывают разные, форма у них похожа, однако рамы не взаимозаменяемы (интерфейсы каретки, рулевой колонки, подседельной трубы разные)
3) если пользователю нужно получить наиболее надежный и целесосбразный вариант — реализация рамы делается под конкретного пользователя (карбон, титан и т.п.)
4) именно рама задает практически все свойства велосипеда.
Исторически сложилось, что рама хардтейла получила один съемный элемент — петух заднего переключателя — и то, для повышения ремонтопригодности и даже не на всех рамах этого типа он есть.
Я хочу сказать о том, что для каждого изменения в сторону развязывния кода нужны предпосылки. Считаю, что главной задачей разработчика в этой части является создание такого кода, который при необходимости несложно рефакторить и развязать. Хотя это конечно ИМХО.
Модуляризовать ради того, чтобы просто получить кучу модулей — раньше времени увеличить сложность продукта. Создать кучу интерфейсов, применить кучу паттернов просто так? Сложность (а соответственно и стоимость разработки) должна возрастать с ростом полезности, ведь так?
Но во-первых, нет проблем воспользоваться USB-концентратором для увеличения их количества. Во-вторых, я лишь указал на то, что есть решения, которые при небольших отличиях (не всем на тонком клиенте надо много USB, а если подключать не только клаву-мышку — все равно нужен будет хаб) — решение кубокса более законченное, что-ли. А еще, если девайс делается в коммерческих целях, то нужно учитывать конкурентов, не так ли?
С другой стороны, если этой самой лицензией не ограничивается использование открытого кода в закрытых разработках — какая-либо компания может взять код, проревизить и выпустить продукт за деньги. И за эти самые деньги пользователь получит гарантию работоспособности. Юридически значимую.
— будет ли полностью открыта хардверная часть
— будет ли возможность заказывать пустой блок
— будут ли официальные мануалы по подключению на разные модели авто?
Это я к чему — вот у меня есть тоета, хочу я на нее поставить блок, но в автоэлектрике я два по пять. Хочу переходник сделать по мануалам и поменять официальный блок на кастомный. Прошить под мою тоету и дальше ковыряться с настройками. В идеале, для обывателя вот так было бы клево.
На самом деле, касаемо биткойна интересно, что будет с форками, как они поведут себя? Если фантазировать то: биткойн становится все труднее добывать и цена его возрастает. Лайткойн будет добываться, но это будет все сложнее. Далее будет происходить перераспределение ресурсов (например долларов) в пользу более дешевых форков, что повлечет за собой стабилизацию цены биткойна и лайта и возрастание цены форков как следствие капитализации. То есть наличие форков как бы дополняет ограниченную эмиссию биткойна. Это как например использовать для расчетов золото и, к примеру барий. И то и другое ограниченный ресурс, но количество разное и спрос разный, и разная цена от этого. Поправьте если я не прав.