Кто-то еще покупает комплектующие с прилавка, а не через интернет??? В том же ДНСе всегда выбираю на сайте, заказываю, оплачиваю, прихожу забираю в удобном магазине. Продавцы у прилавков крайне редко могут что-то дельное подсказать.
Что касается повышения цен на видеокарты при росте спроса — так это вроде естественно. Это бизнес ведь, а не фонд благотворительности.
Можно ли рассчитывать на появление учебного курса «с нуля»? Например, чтобы школьник начал изучать программирование, ничего об этом заранее не зная, и поступательно пришел к описанному в статье курсу?
Так то да, проще всего сделать рядом временную таблицу с нужными данными, а потом подменить ею оригинальную. Но когда в базу постоянно идет запись, а таблицы еще и связаны внешними ключами — проблема удаления больших объемов становится весьма актуальной.
А как в ReactOS определят, что присланный им код написан после просмотра исходников Windows, если участникам проекта ReactOS запрещено даже смотреть на исходники Windows? Если они не знают, как выглядит код MS, то как они смогут сравнить присланный код с кодом MS? Отказ в принятии кода под предлогом «плагиат на MS» автоматически означает знакомство с кодом MS участниками ReactOS?
Вроде в российском законодательстве закреплено отсутствие личной материальной ответственности работника за ущерб, совершенный на рабочем месте. Наказание в рамках трудового договора, срезание премий — это пожалуйста. Взыскивать с сотрудника убытки, если он сам не подписал на бумаге таковую свою ответственность — нельзя. На сколько я знаю.
Для узкоспециализированных решений — вполне может пригодиться. Только бы еще адекватное разложение параметров из урл увидеть, а не эти жуткие костыли через регулярки и перлы. Middleware появится в любом случае, как только нам понадобится обработать аплоад фоток, отправку почты и прочие прикладные задачи. И встанет вопрос — а надо ли тащить middleware в субд, если у нас есть отдельный middleware с кучей ништяков вроде тестируемости, расширяемости, модульности и прекрасного абстрагирования?
Следующим шагом в развитии данного решения станет превращение postgres в аналог субд cache, где можно писать код прямо в базе человеческим языком. Либо, автору следует (согласно его же постулатам) сменить религию и в качестве монолитного бэкэнда использовать cache.
Возможно, всё то, что автор данной статьи хотел воплотить в своих необычных фантазиях, которые так высокохудожественно обернул в своем тексте, уже сделано в Cache: http://www.intersystems.com/ru/our-products/cache/tech-guide/chapter-4/ — там и nginx не нужен для того, чтобы обработать http запрос. Роутинг, разбор входных данных, обработку данных и выдачу результата делает один единственный СУБД сервер, и не надо писать костыли по связке nginx + postgres.
Но за стремление к исследованиям и интересный стиль изложения — однозначно плюс. Даже если твое творение окажется никому не нужным костылём — это всё равно будет бесценным опытом.
А можно ли купить подписку БЕЗ вашего хостинга и CMS? Например, я хочу создать дизайн и скачать его себе, чтобы добавить нужную автоматизацию, впилить нужные скрипты и навесить на уже готовый сайт?
Если тебе спускают подробное ТЗ на каждую задачу, где всё описано от и до — то да, ты кодер, и можешь строчить абы что и абы как, лишь бы побыстрее и в спецификацию уложиться. А если тебе нужно сначала принять решение «как это сделать», чтобы вписать в архитектуру и не нагородить костылей, и лишь потом фигачить код, то тут уже спешка и попытки «не думать» могут привести к плачевным результатам в виде будущих факапов и необходимости рефакторинга.
Поэтому, было бы интересно сначала узнать о типе решаемых автором статьи задач и об организации рабочего процесса и постановки этих задач. От этого очень много зависит в режиме работы программиста. Я бы даже сказал — всё.
А я разве призывал каждый if выносить в отдельный метод и тестировать его? Это вы сами придумали и обвиняете меня в своих фантазиях. Это вы, а не я, придумал мифические 100500 методов. Если вы профан в грамотной структуризации кода и не понимаете, зачем нужны тесты, то не надо с такой примитивной позицией прыгать по комментами и строчить ахинею, пытаясь доказать неизвестно что.
А какая разница, что выкидывать — 100500 мелких блоков, или один большой, если надо выкидывать? А вот когда у вас есть метод на 200 строк кода, и вы вносите два изменения в начале и в конце — вам придется внести изменения во все 20 тестов, т.к. тестом покрыт весь метод от и до. Если в каждом из двух мелких изменений нужно проверить по 3 варианта развития событий, то ваши 20 тестов превратятся сначала в 60 тестов, а потом ещё в 210. Чтобы проверить все варианты событий. И вот вам надо внести правку в третье место, где тоже надо отследить 3 варианта развития событий…
Что делать? Если ваш большой метод разбит на части, и все они покрыты 20-ю тестами изначально, то каждая правка принесет по +3 теста на конкретный отдельный блок. Т.е. 20+3+3 = 26 тестов. Есть разница — 26 тестов или 210? Грубые подсчеты, конечно, но отражают действительность. Сложность поддержки тестов на отдельный метод растет в экспоненциальной прогрессии от кол-ва строк в нем.
нужно поправить 5 мест в основном коде и еще 80 в тестах
То для того, чтобы такого не было, нужно дробить огромные методы с убер-логикой на маленькие логически оформленные блоки (методы). Тогда каждый блок кода можно протестировать отдельно, и изменение одной строчки в убер-методе не приведет к необходимости переписывать 80 тестов.
Что касается повышения цен на видеокарты при росте спроса — так это вроде естественно. Это бизнес ведь, а не фонд благотворительности.
Следующим шагом в развитии данного решения станет превращение postgres в аналог субд cache, где можно писать код прямо в базе человеческим языком. Либо, автору следует (согласно его же постулатам) сменить религию и в качестве монолитного бэкэнда использовать cache.
Возможно, всё то, что автор данной статьи хотел воплотить в своих необычных фантазиях, которые так высокохудожественно обернул в своем тексте, уже сделано в Cache: http://www.intersystems.com/ru/our-products/cache/tech-guide/chapter-4/ — там и nginx не нужен для того, чтобы обработать http запрос. Роутинг, разбор входных данных, обработку данных и выдачу результата делает один единственный СУБД сервер, и не надо писать костыли по связке nginx + postgres.
Но за стремление к исследованиям и интересный стиль изложения — однозначно плюс. Даже если твое творение окажется никому не нужным костылём — это всё равно будет бесценным опытом.
Поэтому, было бы интересно сначала узнать о типе решаемых автором статьи задач и об организации рабочего процесса и постановки этих задач. От этого очень много зависит в режиме работы программиста. Я бы даже сказал — всё.
Что делать? Если ваш большой метод разбит на части, и все они покрыты 20-ю тестами изначально, то каждая правка принесет по +3 теста на конкретный отдельный блок. Т.е. 20+3+3 = 26 тестов. Есть разница — 26 тестов или 210? Грубые подсчеты, конечно, но отражают действительность. Сложность поддержки тестов на отдельный метод растет в экспоненциальной прогрессии от кол-ва строк в нем.
То для того, чтобы такого не было, нужно дробить огромные методы с убер-логикой на маленькие логически оформленные блоки (методы). Тогда каждый блок кода можно протестировать отдельно, и изменение одной строчки в убер-методе не приведет к необходимости переписывать 80 тестов.