Другой пример - биологически активные добавки. Мы знаем, что принимать витаминки в принципе полезно. Но если вы едите фрукты круглый год - то может принимать что то еще - пустая трата денег. А если вас кто то будет уверять, что они позволят вас вылечить от болезни - и что это лекарство - то это уже обман.
Упражнения конечно полезны. Но нужно правильно создавать ожидания от этих упражнений - чтобы не было потом разочарований. Бейтс заявлял, что можно вылечить близорукость упражнениями - но это не так. Это на деле как зарядка по утрам - полезно, но принципиально тело не изменишь. Также нужно представлять себе то, какие усилия к этому нужно приложить (периодические упражнения по 5 минут каждые 2 часа например - это не мало). И можеи игра не стоит свеч. Зависит от вашего образа жизни. В компании, где я работаю мы обязаны по требованиям эргономики ставить специальную программу, которая заставляет делать перерывы в работе и заниматься упражнениями (легкой зарядкой и для глаз).
То есть проблема метода Бейтса в том, что 1) Его теория и предпосылки асболютно точно ошибочны. 2) Он опровержен статистическими исследованиями. Какие тут еще доказалтельства нужны непонятно. Сам Бейтс шарлатаном не был конечно - он просто жил очень давно - когда еще офтальмологии как науки практически не было. Но сегодня есть очень много организаций, которые возраждают вот такие устаревшие теории, опровергнутые наукой и пользуясь неосведомленностью населения. Это настоящие шарлатаны, которые зарабатывают за счет нашего здоровья. В России этот метод Жданов продвигает по моему. Жаль, что для многих людей официальная наука и разные сомнительные организации стоят на одном уровне доверия.
Есть официальное мнение офтальмологии по этому поводу. Если не увлекаться теорией заговоров - то глупо ему не верить. Ну загуглите вопрос.
Если очень интересны подробности - то сама теория Бейтса про аккомодации по причине изменения формы глазного яблока в результате психических напряжений устарела. То есть в начале прошлого века - когда жил Бейтс еще мало что знали просто про глаза. Поэтому его теория не казалась абсурдом в то время. Но сегодня науке точно известно, что все на деле совершенно не так устроено, как считал Бейтс. При этом он не оставил после себя никаких надежно установленных статистических исследований. Такие исследования проводили потом много раз самые разные ученые - и неизменно убеждались, что его метод не работает. И речь всего лишь о временных незначительных улучшениях зрения у некоторых людей из-за упражнения для глаз. Есть современные упражнения для глаз не по методу Бейтста - которые куда эффективнее. Но зрения они не вернут и значительно не улучшат.
"Люди, которые Вам пишут про необратимость Вашего случая не являются офтальмолагами" - найдите хоть одного офтальмолога, который порекомендует метод Бейтса. В офтальмологии как науке его считают шарлатаном. Станьте сам офтальмологом и разберитесь почему - если для вас это не аргумент.
@ksvark Слишком мало информации чтобы сказать что то определенное. Вы говорите что показатели улучшились. Но какие еще есть значимые показатели, кроме времени разрядки аккумулятора у устройства? Если ваша батарея стала быстрее разряжаться - значит наоборот - стало хуже. Разрядку с отключением делать не противопоказано - если только устройство не останется разряженным сколько нибудь долго - тогда аккумулятор испортиться - а вот полезно ли это - вопрос спорный. Считается что у эппла какие то особенные аккумуляторы и они рекомендуют иногда делать полную разрядку-зарядку. Но на официальном сайте эппла www.apple.com/ru/batteries мне не удалось найти этой информации. Для современных батарей полная разрядка-зарядка это в принципе не полезно, а может быть и очень вредно, если оставить разряженный аппарат на какое то время. Однако это иногда может быть полезно для того, чтобы устройство правильно определяло заряд (но не для самого аккумулятора). Вместо разных статей "гиков" читайте официальные руководства и инструкции. Там обычно все написано.
Что касается "раскачки" - для современных аккумуляторов (литиевых) такого термина не существует. Они всегда просто уменьшают емкость со временем. И чем активнее его использовать - тем быстрее.
В вашем случае - вы либо испортили ваш аккумулятор, либо ваше устройство неправильно определяет его заряд, либо он разряжается быстро из-за каких то настроек вашего устройства, программ и т.д. В первом случае вы уже ничего не сделаете, во втором - читайте руководства, в третем - настройте устройство (режимы аккумулятора и т.д) и программы на нем.
Нет никаких компилируемых и интерпретируемых языков. Язык может быть строго и нестрого типизирован, иметь или не иметь безопасности типов и т.д. И эти признаки едва пересекаются с тем компилируемая ли платформа. Для многих языков программирования есть и компиляторы и интерпретаторы одновременно.
Конечно платформа налагает часто специфику на разработку. Но на мой взгляд самая главная особенность разработки под веб и современной разработки в целом это широкое использование виртуальных машин. А будет ли интерпретироваться исходный код не так уж важно.
Просто под веб популярны языки программирования, которые позволяют писать быстро дорогой в поддержке и небезопасный код. Например PHP — скриптовый язык ставший популярным в вебе. Это связано с тем, что зачастую маленькие веб продукты, которые создаются конвеерно одним двумя людьми не требуют серьезной дальнейшей поддержки или расширения. Требования изначально фиксированы и несложны.
Зачастую такие программные платформы используют и для серьезных решений если используются готовые каркасы которые нужно просто немного доработать.
Нельзя сказать что веб — это нижний уровень развития программиста. Скорее наоборот — эта самая активно развивающаяся сфера разработки сегодня. Все новое прежде всего создают для веба. И конечно дело не ограничивается веб сайтами — это веб сервисы, распределенная архитектура, restful api, клиенты под разные платформы базирующиеся на веб сервисах, приложения на html5. Огромное количество проектов разрабатывается и на джаве и под дот нет.
Пороги для изучения веб технологий не менее серьезные чем для изучения C++ под виндоус. Но мыслить там надо на совершенно других уровнях абстракции. Потому что технологические решения и платформы куда более развиты и разнообразны.
Проблема тех людей, которые долго работали на уходящих в небытие платформах не в том, что надо изучить веб технологии. А в том, что надо наверстать колоссальный багаж знаний который они упустили работая в мире, который более статичен.
Не понимаю о чем вы говорите. Есть правило, по которому покупатель может отказаться от предустановленной операционной системы для любого ноутбука с соответствующим денежным возмещением. Да — это может быть непросто сделать. Но многие магазины сразу продают лептопы с несколькими операционными системами на выбор либо вообще без нее, ставя туда Free DOS.
Вот сходу нагуглил ценам.нет. В фильтре поставьте нужные операционные системы (либо DOS/Free DOS) и фильтр по процессорам i3/i5/i7 — это укажет лептопы которые вышли после 2009 года. И посмотрите на результат. У меня вышло около 70-и всех ценовых категорий.
И предустановленный виндовс вероятно стоит все таки поменьше чем 100 баксов. А по поводу мирового заговора против России — рекомендую избавиться от телевизора.
Eddy_Em — вы не совсем правы. Многие люди работают с маленьким экраном — и это не проблема. Я вас уверяю, что даже на 13 дюймах вполне можно комфортно работать.
По поводу видеокарты — это неправда. Даже видеокарты, которые есть в i процессорах встроенные поддерживают внешние мониторы — а уж приличные видеокарты тем более. То есть для всех современных лептопов это не так. Я сомневаюсь что такая проблема есть даже на очень древних и очень дешевых лептопах.
Ну а про жесткий диск — вынужден вас шокировать — мне хватает 128Гб ссди диска для всех моих задач. Я даже не представляю зачем вам десяток терабайтных винтов — у вас там порностудия что ли дома? На дворе век облачных хранилищ. Есть NAS — сы для фанатов «все свое храню в кармане».
Но ставить файлохранилище в свой десктоп — это даже не смешно по моему.
Хотя может вы просто прикалываетесь — и я вас не понял.
Не видел я в требованиях автора вопроса большие диски и много оперативы. Можно подключить диски по юсби. Если на нетбуке полноценная ось — то скорость чтения должна удовлетворять задачам автора. Ну а много оперативной памяти, мощный процессор и крутая видюха тут вроде вообще не в тему. Речь ведь о сетевом хранилище. Конфигурацию нужно подбирать так чтобы хватало мощности для этого, но не больше — меньше расход электроэнергии, пассивное охлаждение — если возможно. Именно такие задачи и решают производители NAS-ов, а не то, как туда покруче железо воткнуть.
И я думаю ели автор может взять нетбук на барахолке — то речь будет идти не об 11 тысячах руб, а намного дешевле.
mifki
Я посмотрел ссылку, которую вы дали. Возможно вы неправильно поняли автора комментария. Он говорил об оверинжениринге. О том, что при чрезмерном увлечении абстракциями и паттернами можно не улучшить а ухудшить качество кода. А вовсе не о том, что вопросы рефакторинга из умных книжек это ерунда. Более того, рефакторинг — близкий друг принципа KISS. Потому что писать код просто — это не значит писать его кое как.
И как раз во время рефакторинга обычно удаляют лишний код и ненужные конструкции.
А для того, чтобы выявить те или иные проблемы включая переусложненность кода и используют запахи кода, которые указывают на скрытые проблемы. Одним из таких индикаторов проблем в коде являются методы с большим количеством параметров. Сами по себе они не большая проблема — но указывают на проблемы с объектной моделью приложения.
Есть люди которые очень хорошо знают все советы умных дядек в книжках и говорят что это ерунда. Есть люди, которые не знают эту кухню и тоже говорят, что это ерунда. Но их слова несут совершенно разный смысл. Слова первых не стоит понимать буквально.
Я не хотел обидеть вас и ваши творения. В данном слове из моих уст не было негативного оттенка.
Думаю большинство используемых пользователями программ действительно маленькие, если сравнивать количество. Но большая часть разработчиков все таки трудится в больших проектах (ну я так думаю). И разумеется вопросы качественного кода и рефакторинга имеют смысл лишь в проектах с достаточным количеством людей.
В проектах которые пишет один человек это не так актуально — как правило в таких проектах код вообще не отличается качеством. И дело тут не в компетенции людей. Даже если разработчик очень крут — когда он один у него не будет стимула писать качественный код. Он будет уверен что его код хорош — но будет ошибаться — потому что проверить его все равно не кому.
Именно поэтому такие проекты и называют столь не полюбившимся вам словом «поделка». Без менторства вне команды невозможно научится писать качественный код. Просто потому, что он там никому не нужен. Но на крупных проектах он очень важен.
Там используют правила рефакторинга. И поставленный автором вопрос — это тема Code Smells, а вовсе не правил хорошего кода, хотя не уверен что он это понял.
Я только что выкинул и написал заново один из проектов компании, хочу переписать еще два с половиной, но пока не уговорил начальство.
mifki — судя по всему вы работаете с поделками а не с серьезными промышленными продуктами.
Качество кода = стоимость поддержки и расширения — всей дальнейшей эволюции продукта.
Соль в том, что стоимость внесения изменений в программные продукты со временем растет экспоненциально. И лишь используя специальные методики контроля качества кода это можно изменить. Об этом много написано. И если вы в своей практике этого не видите — то это не значит что теория туфта. Просто к вашему конкретному случаю это не очень применимо. Речь о больших продуктах, а не о тех которые может на коленке написать один человек. Когда работают команды на протяжении N лет приспосабливая систему к новому бизнесу — все на много порядков сложнее.
Практически раньше такие проекты гарантированно вели к краху в перспективе.
Большое количество аргументов в коде — это запах серьезной проблемы: отсутствия непрерывного рефакторинга старого кода. То есть человек вместо того, чтобы переработать объектную модель — добавляет новые аргументы. Это может даже говорить об отсутствии вообще адекватной объектной модели. Поддерживая число аргументов в коде (а это очень простое правило для разработчика — потому что нарушение выявить легко) — мы будем вынуждены перерабатывать объектную модель и реагировать на такие проблемы.
Если у вас очень сложная логика, то у вас будет много тестов — я не понимаю что в этом плохого. Плохо то, что у вас сложная логика. Есть там принцип персональной ответственности, декомпозиция. Сложность написания тестов — всего лишь индикатор переусложненной лигики.
Можно разбить сложный метод на несколько используя средства для автоматизированного рефакторинга и после этого тестировать их отдельно.
Можно упростить архитектуру приложения, чтобы как в вашем случае значения не влияли друг на друга и т.д.
Главное изолировать то, что вы тестируете от всего остального. И речь не только о сигнатуре метода, который вы тестируете, но и о всех остальных внешних зависимостях в коде. Их нужно мокать.
Вообще разработка с использованием модульных тестов требует архитектурной готовности системы. И большое количество состояний тестов — это именно проблема дизайна системы. Это значит что модули ваши слишком связаны друг с другом и нужно их разрабатывать так, чтобы они были менее связаны.
Думаю, что можно. Так как веб драйверы не используют общих ресурсов и независимы то должно быть можно одновременно запускать тесты на разных браузерах.
Лично у меня они запускаются последовательно.
Однако стоит помнить что IE не может стоять несколько версий на одной машине. А тестировать на разных версиях IE обычно требуется.
TDD и QA разумеется никак не связаны совершенно. TDD — это чисто девелоперская практика для быстрого и эффективного написания кода, с использованием модульных тестов.
Она базируется на Agile ценностях и является одной из практик XP.
