Ну а просто «Хороший программист» в понимании профессии? Например хороший плиточник ровно кладет плитку, а программист? Может быть хороший программист это опытный программист, который постоянно держит себя в тонусе (не обязательно осваивает все новые тулзы и техники, но знает о них и возможно об особенностях их применения), даже при условии что работает на злую корпорацию которая использует его как печатную машинку.
Обычно первый пункт убивает в программисте программиста, тк сроки обычно невыполнимые (всякие менеджеры и другие гуманитарии любят много чего наобещать чтобы выиграть тендер, и по другим причинам) чтобы написать хороший код в рабочее время, поэтому обычно пишется абсолютный быстро-код. А да, на рефакторинг тоже редко бывает время, да и желание при таком подходе.
Mint -> Xubuntu -> Lubunut -> Arch LXDE. Последний год на Arch, менять не собираюсь так как он меня не раздражает как остальные, даже может наоборот :)
Сначала нужно получить представление о инструменте (именно эта информация и представлена), а потом уже если он (инструмент) заслужил и если будет необходимость или просто интерес (по поводу того что либа понравилась или наоборот) смотреть кто автор. Зачем нам лишняя информация. Авторитет или просто известность автора и популярность инструмента не всегда решают.
Да религия она такая, все крутится вокруг веры, понимать не нужно или невозможно. Но к счастью в JS религии дела обстоят немного по другому, некоторые адепты все же смогли постигнуть нирвану :)
Думаю что опытный проектировщик / архитектор / просто разработчик (в exUSSR бывает что это одно лицо) основываясь на своем и чужом опыте не станет использовать (только по той причине что «так сделать можно» и что так проще и быстрее) конструкции/методы/приемы/структуры которые по своей сути допускают проблемы.
Зачем изначально залаживать в разработку приложения опцию «кому-то придется лишний раз смотреть в mdn, а то и не только в mdn» когда этого можно избежать. Да и not defined не единственная особенность, другая проблема в пересечении функционала, если утрировано то типа как запустить вместе Mootools и Prototype :)
Вопрос не только в том чтобы сделать, но и в дальнейшей поддержке/развитии проекта при условии что разработку ведут разные люди/команды. Каждый из этих разработчиков может захотеть добавить в проект своих плюшек модифицирующих базовые классы. При этом если этот разработчик (любящий расширять базовые классы) ответственный ему придется смотреть все другие «чужие» исходники и проверять и тестировать не будет ли его код конфликтовать с чужими расширениями базовых классов. Думаете кто-то пойдет на это, или лучше выберет путь автономных самодостаточных расширяемых модулей?
Пример. Начальство дает задачу интегрировать в проект уже готовый функционал из другого проекта (скопипастить по простому, не в отдельном фрейме). Первый основной проект использует Mootools, второй Prototype, интегрировать нужно за один день, у начальства ведь такое понимание что если готово где-то уже, то берем и приклеиваем без проблем, однако не вегда так получается. Пример немного притянут за уши, но смысл думаю понятен.
Разумеется в принципе расширять базовые классы можно, вопрос в том насколько разумно это делать.
Именно, JS ведь не компилируемый (в IDE), это не Java где можно двумя кликами отследить всю иерархию наследования и вызовов любых методов, тут в илеале нужно держать всю иерархию в голове, а это не всегда возможно.
Как минимум 2 аргумента:
— Более явный вызов расширенных методов, легче отслеживать, рефакторить.
— Гарантия отсутствия «конкурирования» за одноименный методы/поля при подключении разных библиотек
Мне приходилось рефакторить веб часть больших проектов (JEE/J2EE), и я вполне понимаю и принимаю приведенную аргументацию.
Подумал о том же, то есть поменять библиотеку с Datejs (на то время ничего больше не попалось готового) на Moment. Проблема в том что Datejs расширяет встроенный класс и так просто отловить все ее добавки по всему проекту не получится (проект делался не одним поколением людей, и не все они были разработчиками судя по коду). Но в нашем случае весь «не стандартный» функционал либы Datejs используется только через свою обертку (типа CommonUtils.Date.format) так что поменять имплентацию на Moment не должно быть сложно :)
Поддерживаю. Мне тоже не нравится когда всякие либы засерают встроенные классы. Готов мирится с теми что добавляют не хватающих методов браузерам типа старых IE (типа each и тд), то есть приводят поведение к некоторому стандарту, все остальное пихать в свои обертки (неймспейсы/замыкания).
Представьте что будет если всякая либа захочет расширять встроенные классы, одна, вторая, третья, и наступит неминуемый хаос, библиотеки начнут перетирать методы друг дружки меняя ожидаемое поведение, будет весело :)
Действительно какой-то дикий бред, после этого может сложится впечатление что жава для придурков и неудачников. А вот приведенный ролик очень порадовал, драматично то как )
А зачем вообще приводить к Boolean если потом нет явного сравнения на истину (logtype === true), тут было бы достаточно this.type = logtype || «alert»;
Давно плотно пользуюсь (года 4, до сих пор вполне живые) можно сказать легендарными клавиатурами с клавишами «ножничного» типа BTC 6300C и Logitech UltraX, сейчас хочу попробовать кнопки «отсровного» типа. Кстати к A4Tech отношусь с обоснованным недоверием (имел неоднократный печальный опыт с их мышами), и другим советую.
Как бы я их понимаю, эту штука на Java, и в первую очередь хорошо бы было иметь возможность писать реализацию на Java, не все хотят или просто не могут себе позволить осваивать еще какой-то скрипт. Для гиков или просто интересующихся, ведется работа над возможностью работать с JavaFX с использованием скриптовых языков — JavaOne 2011: JavaFX 2.0 with Alternative Languages. Существуют мнения что наиболее удобной может быть связка JavaFX + Scala.
Похожая история, установлен родной софт LG с карточки памяти телефона. Запустил этот софт, он написал что есть обновления, нажал обновить, через какое-то время черно-желтый экран Emergency Mode, а я ведь даже не знал что он начал прошивать телефон, думал софт себя будет обновлять, а он решил убить телефон! Подумал уже хана, но вышел (на 4pda форуме) на альтернативный прошивальщик и все обошлось. Советую относиться к софту LG с недоверием.
Обычно первый пункт убивает в программисте программиста, тк сроки обычно невыполнимые (всякие менеджеры и другие гуманитарии любят много чего наобещать чтобы выиграть тендер, и по другим причинам) чтобы написать хороший код в рабочее время, поэтому обычно пишется абсолютный быстро-код. А да, на рефакторинг тоже редко бывает время, да и желание при таком подходе.
Зачем изначально залаживать в разработку приложения опцию «кому-то придется лишний раз смотреть в mdn, а то и не только в mdn» когда этого можно избежать. Да и not defined не единственная особенность, другая проблема в пересечении функционала, если утрировано то типа как запустить вместе Mootools и Prototype :)
Вопрос не только в том чтобы сделать, но и в дальнейшей поддержке/развитии проекта при условии что разработку ведут разные люди/команды. Каждый из этих разработчиков может захотеть добавить в проект своих плюшек модифицирующих базовые классы. При этом если этот разработчик (любящий расширять базовые классы) ответственный ему придется смотреть все другие «чужие» исходники и проверять и тестировать не будет ли его код конфликтовать с чужими расширениями базовых классов. Думаете кто-то пойдет на это, или лучше выберет путь автономных самодостаточных расширяемых модулей?
Пример. Начальство дает задачу интегрировать в проект уже готовый функционал из другого проекта (скопипастить по простому, не в отдельном фрейме). Первый основной проект использует Mootools, второй Prototype, интегрировать нужно за один день, у начальства ведь такое понимание что если готово где-то уже, то берем и приклеиваем без проблем, однако не вегда так получается. Пример немного притянут за уши, но смысл думаю понятен.
Разумеется в принципе расширять базовые классы можно, вопрос в том насколько разумно это делать.
Как минимум 2 аргумента:
— Более явный вызов расширенных методов, легче отслеживать, рефакторить.
— Гарантия отсутствия «конкурирования» за одноименный методы/поля при подключении разных библиотек
Мне приходилось рефакторить веб часть больших проектов (JEE/J2EE), и я вполне понимаю и принимаю приведенную аргументацию.
Представьте что будет если всякая либа захочет расширять встроенные классы, одна, вторая, третья, и наступит неминуемый хаос, библиотеки начнут перетирать методы друг дружки меняя ожидаемое поведение, будет весело :)