Ну, в целом я с вами согласен, но я бы смог работать с человеком, который не понимает в алгоритмы, но понимает в красоту кода, что после него хотя бы можно оптимизировать написанное без особого труда. Потому как встречались разработчики, которые замечательно разбираются в таких вещах, но пишут код, сложность которого зашкаливает и в котором кроме них никто не разбирается. Этот код работает и работает быстро, а разраб сел на высокую зарплату и теплое место. Казалось бы, всюду плюсы. Ан нет.
Очень странно, что перечислив достаточно низкоуровневые вещи, вы упустили вещи уровнем повыше: работа компиллятора, GC, транзакции в базах данных и многое другое. Это тоже вещи, с которыми сталкивается «каждый уважающий себя разработчик ПО». Но какой смысл знать, сколько места занимает указатель в 64хбитной системе, если ты написал код, который после компилляции никогда не освободит этот указатель?
Нужно ли мне уметь написать красно-черное дерево, если оно уже есть в стандартной библиотеке и покрыто всевозможными тестами, или мне достаточно знать ситуации, когда его следует/не следует использовать?
Хватит ли времени на изучение всего вами перечисленного одновременно с перечисленным и не перечисленным мной? Мне кажется, нет. А тут, простите, ни слова еще не сказали об архитектуре приложений, в которой, на мой взгляд, любой уважающий себя программист тоже должен разбираться. И как же быть с новыми технологиями, в зоопарке которых (и это уже не мое мнение, а реальное положение рынка труда) мы все обязаны свободно плавать?
Это, конечно, тема для холивора. Но я понимаю людей, которые предпочитают знание интерфейса знанию реализации. Они, конечно, меньше похожи на седых старцев-волшебников, но тоже имеют свое право считаться «уважающими себя разработчиками ПО».
Но есть ли по-вашему какой-то необходимый предел низкоуровневости знаний? Скажем, нужно ли знать особенности интерфейса взаимодействия процессора с северным мостом? Или, если это был неудачный пример, достаточно ли знать сложность сортировки бинкучи или нужно уметь доказать эту сложность?
Как узнать, в какой момент лучше уже не лезть в эту степь? Думаю, вы не станете спорить, что понимать в программировании все невозможно да и бессмысленно.
Откуда ViewModel должна получить свое состояние? Откуда она знает что модель изменилась? Интересные вопросы.
Ну, а ответы на них почему не даны? Исходники открытые. Я понимаю, что статья про реакт, но немного провокационно получается упомянуть нокаут и сделать вид, что там что-то непрозрачно и непонятно.
Computed-property вычисляются при своей инициализации и биндятся на все прочие ko.observable и ko.computed, которые были вызваны при этом вычислении, если что.
Как бывший и в некоторой степени нынешний фронтенд выражаю общее профессиональное чаяние, что вы не будете писать свой движок рендеринга и воспользуетесь вебкитом или хотя бы геко. Аналогично с JS. Скажите, мы же сможем спать по ночам?
Ну я вот например в большей части ТЗ по сайтам встречал формулировку «кроссбраузерность с поддержкой IE8+». То есть, сама поддержка IE8 не считалась необходимой частью понятия кроссбраузерности. И это разумно — поскольку годы идут, и некоторые браузеры становится настолько невостребованными, что выпадают из термина «кроссбраузерности».
Мне кажется, в конкретных проектах вообще не имеет смысл использовать этот термин, поскольку, ну, вы им хвастаться что ли собрались? У нас кроссбраузерно сверстано, вуху! И все вокруг: «Ну офигеть теперь!»
Так что имеет смысл говорить о кроссбраузерности только в опенсорсных решениях / библиотеках. Но и в них — кроссбраузерность это достаточно размытое и субъективное понятие. Кто-то полезет смотреть в java-браузерах на старых нокиях, кто-то запустит IE6 под виртуалочкой. А кто-то прочекает в последних версиях хрома, фф и оперы и останется доволен. И опыт последних лет подсказывает, что прав будет только последний.
Вот это уже звучит хреново совсем. Серверная валидация обязана присутствовать, в противном случае любой чуть знакомый с http поломает вам все, что только можно поломать.
Спасибо большое! Что касается сажания не-программиста, наверное так запросто все-таки не получится: JS дружелюбен, но очень разборчив в друзьях. Впрочем, иными утрами каждый из нас в некотором роде «не-программист».
Вообще отлично ложится на любую подобную библиотеку. Я, собственно, даже упомянул вскользь Rx.js от мелкомягких. Просто чего отбойным молотком гвозди забивать, когда моя задача в определенных рамках предсказуема, и вполне можно обойтись самым что ни на есть обычным молотком.
Сомневаюсь, что эти ребята будут чинить здания — для таких задач, конечно, эти алгоритмы вряд ли подходят. Но в статье о таких задачах речи и не идет, там указаны гораздо менее требовательные к времени задачи, но не менее опасные — исследование, например, жерла вулкана или радиоактивной зоны. Вы не всегда сможете обеспечить нормальную связь с «материнским кораблем» для ботов в таких условиях, а значит, у вас не будет возможности, или она будет критично мала, управлять их движением.
Впрочем, не буду заниматься диванной аналитикой и самоустранюсь из данной дискуссии =)
Почему вы считаете имитацию живой природы иррациональной? Для совместного одновременного движения роботов необходимо держать информацию о передвижении каждого бота в удаленном узле. При работе в опасных условиях (а именно это, насколько я понял, предполагается главным назначением ботов) это может быть рискованно. Подобное же движение гораздо более безопасно: при гибели бота задача все равно выполняется. А вариант хранить пути всех ботов в каждом боте — это уже совсем иррационально; при более-менее сложной задаче и большем количестве ботов это может потребовать астрономического количества ресурсов, вдобавок необходимо каким-то образом проводить перерасчет траектории в случае отказа одного из ботов для всех остальных.
<sarcasm>
Зачем читать и изучать фреймворк, если можно не изучать? Давайте все изобретем свой собственный велосипед. Возможные баги? Пфф, я лучше сам наступлю на грабли, чем воспользуюсь чужим маршрутом. Кроссбраузерность? Да никто уже не пользуется старыми ослами и линухом! </sarcasm>
Ну, знаете, обычно это бывает в формате:
— Да вы сами посмотрите на карте памяти, там только фотографии моей жены!
— Мы посмотрим, посмотрим, обязательно все посмотрим. А вы пока скажите, сколько вам платит Google? И кому вы собирались продать видео?
Может быть, мне очень везет с дизайнером, может быть, мне просто везет по жизни, но на написание CSS у меня уходит ну крайне мало времени и сил. Цвета хранить в переменных нет никакого смысла — и вот почему: дизайнер наш понимает, что цвет ради цвета — это моветон, и поэтому цветом выделяет только те места, которые реально несут какую-то дополнительную нагрузку. Серый цвет? Дополнительные, необязательные данные. Красный цвет? Ошибка. Это совершенно справедливо можно положить в классы типа «nonimportantdata» и «error». Я, конечно, крайне негативно отношусь к классам типа «hidden» или «left», или, упаси Боже, «gray»/«blue». Но, на мой взгляд, если дизайнер использует цвет просто потому что цвет здесь выглядит круче — это далеко не самый хороший дизайнер.
Конечно, так устроен трудовой процесс во многих конторах: есть менеджер, который «я-начальник-ты-дурак», который даже может взять и написать дизайнеру: «сделай-ка тут шрифт покрупнее, а тут синий цвет». Мне кажется, уже в этом месте подход абсолютно неверный. Работа дизайнера не подлежит микроменеджменту, если он, конечно, не джуниор (или как там у дизайнеров джуниоры называются). А на выходе получаются интерфейсы, где цвет содержимого никак не связан с самим содержимым, используется пяток разных цветов, десяток размеров шрифта и прочая, прочая. И тут, конечно, без переменных никуда.
TLDR-версия. Вот я лично считаю препроцессоры этаким управленческим костылем, попыткой верстальщиков совладать с плохим дизайнером и самодуром-менеджером.
Ну круто, когда это все в коробке есть, а не писать свой велосипед для адекватных мок-объектов? Это все-таки связано с тем, что Jasmine, как и QUnit они себя позиционируют как именно движки для тестирования работы JS в браузере. Ну мой внутренний Роберт Мартин кричит, что если какая-то часть кода может по-разному работать в разных средах, то ее надо вынести в абстракцию и покрыть комментариями. И потом не придется париться, запуская тесты в разных браузерах. Но это чисто мои тараканы.
Ни слова не сказано про mock-объекты, а именно их использование в юнит-тестах требует писать качественный код. Умение, например, разнести в разные части кода работу с DOM, DOMEvents и логикой модуля, — имхо, золотое умение. И не покрывать тестами и так покрытый тестами jQuery, а тестировать логику работы модуля, а не его отображения.
var MyExample = function (options, view) {
var _view = view,
_displayed = false;
this.show = function () {
if (!_displayed) {
_displayed = true;
_view.show();
}
};
this.hide = function () {
if (_displayed) {
_displayed = false;
_view.hide();
}
};
};
В таком коде нам совершенно наплевать, каким образом реализуется работа с DOM при попытке показать модуль — может там просто documentgetElementById("MyId").style.display = true, а может $("#MyId").fadeIn(2000);.
Впрочем, не уверен, что jasmine поддерживает полноценные мок-объекты по прототипу. Все-таки в spy есть одно ограничение — приходится писать название методов в строки. Моя EDI не поддерживает смартинпут в кавычках. Может, кто-то объяснит, как создавать моки в Jasmine без перебивания руками всех нужных методов?
Ну, занимаюсь я этим в кадровом агентстве с уклоном в IT, так что руководство там вполне себе прогрессивное. Документов не брали, хватило резюме и рекомендаций. Ставка 1 килорубль в академический час, но во мне играет альтруистическая жилка (или скорее жилка учительской тирании), и я вожу занятия астрономическими часами за те же деньги.
Собственно, я даже высшим образованием обделен, и если при работе в школе это вызывало определенные проблемы, то здесь всем, конечно, все равно. Начиная с определенной даты трудового стажа =).
Веду курсы по верстке для студентов и желающих повысить квалификацию. В среднем возраст учащихся — 20-22 гг. Проблемы один в один ваши, разве что с трудоустройством все было более чем гладко.
Нужно ли мне уметь написать красно-черное дерево, если оно уже есть в стандартной библиотеке и покрыто всевозможными тестами, или мне достаточно знать ситуации, когда его следует/не следует использовать?
Хватит ли времени на изучение всего вами перечисленного одновременно с перечисленным и не перечисленным мной? Мне кажется, нет. А тут, простите, ни слова еще не сказали об архитектуре приложений, в которой, на мой взгляд, любой уважающий себя программист тоже должен разбираться. И как же быть с новыми технологиями, в зоопарке которых (и это уже не мое мнение, а реальное положение рынка труда) мы все обязаны свободно плавать?
Это, конечно, тема для холивора. Но я понимаю людей, которые предпочитают знание интерфейса знанию реализации. Они, конечно, меньше похожи на седых старцев-волшебников, но тоже имеют свое право считаться «уважающими себя разработчиками ПО».
Как узнать, в какой момент лучше уже не лезть в эту степь? Думаю, вы не станете спорить, что понимать в программировании все невозможно да и бессмысленно.
Ну, а ответы на них почему не даны? Исходники открытые. Я понимаю, что статья про реакт, но немного провокационно получается упомянуть нокаут и сделать вид, что там что-то непрозрачно и непонятно.
Computed-property вычисляются при своей инициализации и биндятся на все прочие ko.observable и ko.computed, которые были вызваны при этом вычислении, если что.
Мне кажется, в конкретных проектах вообще не имеет смысл использовать этот термин, поскольку, ну, вы им хвастаться что ли собрались? У нас кроссбраузерно сверстано, вуху! И все вокруг: «Ну офигеть теперь!»
Так что имеет смысл говорить о кроссбраузерности только в опенсорсных решениях / библиотеках. Но и в них — кроссбраузерность это достаточно размытое и субъективное понятие. Кто-то полезет смотреть в java-браузерах на старых нокиях, кто-то запустит IE6 под виртуалочкой. А кто-то прочекает в последних версиях хрома, фф и оперы и останется доволен. И опыт последних лет подсказывает, что прав будет только последний.
Впрочем, не буду заниматься диванной аналитикой и самоустранюсь из данной дискуссии =)
<sarcasm>Зачем читать и изучать фреймворк, если можно не изучать? Давайте все изобретем свой собственный велосипед. Возможные баги? Пфф, я лучше сам наступлю на грабли, чем воспользуюсь чужим маршрутом. Кроссбраузерность? Да никто уже не пользуется старыми ослами и линухом!
</sarcasm>— Да вы сами посмотрите на карте памяти, там только фотографии моей жены!
— Мы посмотрим, посмотрим, обязательно все посмотрим. А вы пока скажите, сколько вам платит Google? И кому вы собирались продать видео?
Конечно, так устроен трудовой процесс во многих конторах: есть менеджер, который «я-начальник-ты-дурак», который даже может взять и написать дизайнеру: «сделай-ка тут шрифт покрупнее, а тут синий цвет». Мне кажется, уже в этом месте подход абсолютно неверный. Работа дизайнера не подлежит микроменеджменту, если он, конечно, не джуниор (или как там у дизайнеров джуниоры называются). А на выходе получаются интерфейсы, где цвет содержимого никак не связан с самим содержимым, используется пяток разных цветов, десяток размеров шрифта и прочая, прочая. И тут, конечно, без переменных никуда.
TLDR-версия. Вот я лично считаю препроцессоры этаким управленческим костылем, попыткой верстальщиков совладать с плохим дизайнером и самодуром-менеджером.
В таком коде нам совершенно наплевать, каким образом реализуется работа с DOM при попытке показать модуль — может там просто
documentgetElementById("MyId").style.display = true, а может$("#MyId").fadeIn(2000);.Впрочем, не уверен, что jasmine поддерживает полноценные мок-объекты по прототипу. Все-таки в spy есть одно ограничение — приходится писать название методов в строки. Моя EDI не поддерживает смартинпут в кавычках. Может, кто-то объяснит, как создавать моки в Jasmine без перебивания руками всех нужных методов?
Собственно, я даже высшим образованием обделен, и если при работе в школе это вызывало определенные проблемы, то здесь всем, конечно, все равно. Начиная с определенной даты трудового стажа =).