Что есть инструмент?
До какого уровня абстракции требуется опуститься, чтобы познать его?
В противовес Вашему утверждению, хочу выразить более разумный лозунг — «Делай свое дело эффективно».
Расходуй свое время эффективно. Развивай себя эффективно.
Часовщик на рисунке дает нам ясное представление, к чему приводит узконаправленное развитие личности — старик в свои седые годы вынужден работать больными руками, ибо он все свои силы положил на познание примитивного инструмента. Таким ли видят свое будущее свидетели «текучих абстракций»?)
Насчет ul это я ошибся, надо было ol в пример ставить)
Я давно тестировал на маке через их встроенный voiceover и там примерно так все работало)
В общем отличия от NVDA видимо не значительные.
Теоретически, если сторонний верстальщик может с довольно высокой точностью понять что есть что в разметке другого верстальщика, то и машину можно научить думать подобным алгоритмом. Но опять же, лично мое мнение, что к тому времени и браузеров то не останется в привычном для нас виде и необходимость в этих разработках может отпасть сама собой)
Я не очень верю в это. Возьмем к примеру список задач. Если он помещен внутрь ul элемента, то скринридер дойдя до него скажет что-то типа: «Список элементов, пункт первый, полить цветы, пункт второй...» и т.д.
А если верстальщик засунет это все в div, то тогда скринридер будет просто читать всю страницу сплошным текстом без препинаний.
Ну или навигация сайта: пока верстальщик в nav не поместит ссылки, машина не поймет какая семантика у этой разметки. Это ведь может быть и просто облако тегов и ссылки на сайты спонсоров и вообще что угодно, пока автор контента сам явно не укажет какова роль у этих элементов. И никакая нейронная сеть не поможет)
Привет. Есть вопрос по скринридерам:
Допустим на странице имеется элемент input type=text aria-invalid=false. Если введенное пользователем значение не проходит валидацию, то необходимо присвоить атрибуту aria-invalid значение true. Это можно сделать двумя способами:
1) классическим — поменять значение атрибута через js;
2) современным (angular, react) — отрендерить компонент заново с измененным значением атрибута;
Так вот я давно читал о том, что второй способ не рекоммендуется, ибо скринридер не всегда может понять, что это изменился стэйт у старого элемента. Он иногда думает, что старый компонент исчез и вместо него появился новый, которого раньше небыло и от этого впадает в ступор. Интересно узнать ваш пользовательский опыт в этом моменте.
Согласен, знание о допустимых параметрах можно добавить к пониманию принципа, но как по мне, достаточно всегда отправлять на вход функции верные аргументы (которые описаны в ее документации), а что произойдет в случае ошибки — это уже не важно, ибо это будут последствия нарушения интерфейса.
Примерно так это можно делать, эмулируя проверку типов/интерфейса в JS:
Возьмем к примеру функцию из JS — Math.min()
Что будет являться достаточным пониманием принципа ее работы?
1) Она возвращает минимальное число из предоставленных аргументов;
2) Она возвращает минимальное число, действуя по алгоритму (далее идет описание алгоритма)
Сейчас заметил, что пропустил одно слово в своем первоначальном ответе. Я имел ввиду «внутреннее устройство алгоритмов сортировки». Разумеется, паттерны и алгоритмы близки по смыслу и знание алгоритмов тоже необходимо (где какой можно использовать). Но помнить точную реализацию сортировки… пожалуй нет)
В этом и дело, что зачастую спрашивают не то что важно по работе, а то что важно лично для вопрошающего)
Для меня важны паттерны и читабельность кода, но эти вещи напрямую связаны с программированием. Если стоит задача написать биржевого робота, то понимание всяких свечек, спредов и прогнозирование цены уж точно не должно входить в обязанности программиста. Для этого есть экономисты, которые консультируют программистов и помогают им перевести эти алгоритмы в программный код. Это мое личное мнение и я не претендую на то, что так должно быть везде. Мне просто кажется это самым адекватным подходом.
Однажды спорил с одним пожилым тимлидом, который сокрушался, что нынешнее поколение программистов не знает физику: «А вдруг понадобится написать программу для расчета силы тока, необходимой для передачи сигнала по медному кабелю с определенным сечением?»
Я ему возразил: «А вдруг понадобится рассчитать длину цепочки ДНК? Получается программист должен и биологию знать?»
Мне кажется, все эти вопросы по высшей математике или о внутреннем устройстве алгоритмов спрашивают только те, кто потратил время на их изучение и теперь ищет куда приткнуть полученные знания, демонстрируя кто здесь Альфа-программер: «Этот новичек даже второй закон Кирхгофа не знает… а вдруг завтра понадобится?»))
В таком случае проще сразу написать свой, чем переделывать чужое)
Там по сути не так уж много кода внутри: обсервер/медиатор и модули. Практически все фреймворки работают по этой схеме (правда некоторые предпочитают хранить стейт во внешней модели, а другие — внутри модуля в его замыкании, но это нюансы). Для CRUD-приложений еще может понадобиться некое подобие виртуального dom.
Придерживаюсь аналогичного мнения.
Только мой камень в огород фреймворков, сборщиков и транспилеров имеет немного иную форму:
Напишите свой продукт один раз на JS и больше не понадобится переписывать его на очередной хайповый фреймворк по прихоти 23-летнего сеньера, который увлекся функциональщиной и теперь лоббирует очередной HaskellScript в продакшн.
Найти человека, который знает javascript намного проще, чем выискивать уникальную смесь из скиллов, типа Vue, Redux, Gulp, LESS и т.д. Сообщество слишком раздроблено и объединять его надо под флагом чистого JS.
Вполне неплохое будущее)
Фронтендеры часто жалуются на обилие технологий, которые надо изучать. Мой подход позволяет им, при желании, отстраниться от нюансов CSS и HTML и позволить верстальщикам самим писать хаки для IE6 внутри стилей, а сеошникам писать в HTML свою микроразметку для поисковиков. Освободившееся время они могут потратить на тусовки и развлечения.
В моем будущем программист — свободный человек, который не беспокоится о том, что вышел очередной фреймворк. В будущем от Facebook и Google ему уготовано лишь «eat, sleep, code, repeat»))
Я не сторонник CSS-in-JS. Сейчас попробую объяснить почему.
Стили и html могут писать «низкооплачиваемые» участники процесса разработки, типа верстальщиков/дизайнеров.
Отверстав по стайл гайду все возможные состояния компонентов, они могут передать свою работу далее программисту, который привяжет внешнее состояние сверстанных компонентов к модели приложения/сайта.
Например:
Допустим у некой кнопки есть два состояния (нажата — зеленый бэкграунд, отжата — красный). Дизайнер написал стили для каждого состояния и повесил их на разные селекторы. Программист привязывает эти состояния к событиям в системе и при возникновении условного события buttonOn вешает на компонент соответствующий ему класс.
Как из этого всего можно сделать модули?
Тут необходим подход по типу Vue:
Помещаем в один файл с расширением .component разметку на html/jade, стили на css/scss, логику на js. Все это лежит тремя блоками в тегах div, style, script. Далее специальный сборщик все это обрабатывает и аккуратно раскладывает по полочкам: стили добавляет в css-файл, разметку подставляет в html и скрипты добавляет в js-файл.
Все просто и логично: верстальщик создал свою часть компонента, а программист — свою. И никаких десятков библиотек и препроцессоров в зависимостях. А то у React-сообщества уж сильно тяга к овер-инжинирингу проявляется)
если вы действительно хорошо разбираетесь и в языках, и в архитектуре, и в парадигмах, и умеете всем этим пользоваться — лучше языка чем JavaScript для общих задач вам не найти.
Порог входа в JavaScript был и остаётся очень низким, это даёт повод многим новичкам ругать то, в чём они не разобрались.
я, например, прекрасно читаю даже обфусцированный код библиотек, чего и вам желаю.
Перечитайте про duck typing и научитесь им пользоваться
А вообще, развивайте дисциплину кода, не всё время за юбкой IDE прятаться. Это не стёб, анализаторы это хорошо, но если для вас проблема такие ошибки — как-то вы не правильно программируете.
Общий посыл статьи понятен — язык великолепный, просто вы не умеете программировать)
const a = 5
const a = 4
VM1825:1 Uncaught SyntaxError: Identifier 'a' has already been declared
А если попробовать так:
const a = 5;
a = 4;
Насколько я помню, в этом случае значение останется равным пяти, но никаких уведомлений об ошибках не последует.
А галочку можно ведь и назвать «Хочу получить расширенный доступ к сети интернет, где присутствует запрещенный контент: экстремистские ресурсы, видеоматериалы включающие жестокое отношение к несовершеннолетним, а также сервисы для легализации средств полученных преступным путем»
Интересно, многие из народа осмелятся включить такую опцию?))
Явно платных нет. Однако во многих open source проектах тоже нет платных услуг по добавлению фич. Но это всегда можно обговорить с маинтейнерами и профинансировать ускоренное их внедрение, либо получить более расширенную консультацию по решению своих проблем с продуктом.
Я знаю о их недостатках. Качество материала там не очень, но у них можно быстро посмотреть в табличном виде подзабытые особенности некоторых html тегов или css свойств. На MDN оно порой не очень удобно организовано.
Что есть инструмент?
До какого уровня абстракции требуется опуститься, чтобы познать его?
В противовес Вашему утверждению, хочу выразить более разумный лозунг — «Делай свое дело эффективно».
Расходуй свое время эффективно. Развивай себя эффективно.
Часовщик на рисунке дает нам ясное представление, к чему приводит узконаправленное развитие личности — старик в свои седые годы вынужден работать больными руками, ибо он все свои силы положил на познание примитивного инструмента. Таким ли видят свое будущее свидетели «текучих абстракций»?)
Я давно тестировал на маке через их встроенный voiceover и там примерно так все работало)
В общем отличия от NVDA видимо не значительные.
А если верстальщик засунет это все в div, то тогда скринридер будет просто читать всю страницу сплошным текстом без препинаний.
Ну или навигация сайта: пока верстальщик в nav не поместит ссылки, машина не поймет какая семантика у этой разметки. Это ведь может быть и просто облако тегов и ссылки на сайты спонсоров и вообще что угодно, пока автор контента сам явно не укажет какова роль у этих элементов. И никакая нейронная сеть не поможет)
Допустим на странице имеется элемент input type=text aria-invalid=false. Если введенное пользователем значение не проходит валидацию, то необходимо присвоить атрибуту aria-invalid значение true. Это можно сделать двумя способами:
1) классическим — поменять значение атрибута через js;
2) современным (angular, react) — отрендерить компонент заново с измененным значением атрибута;
Так вот я давно читал о том, что второй способ не рекоммендуется, ибо скринридер не всегда может понять, что это изменился стэйт у старого элемента. Он иногда думает, что старый компонент исчез и вместо него появился новый, которого раньше небыло и от этого впадает в ступор. Интересно узнать ваш пользовательский опыт в этом моменте.
Примерно так это можно делать, эмулируя проверку типов/интерфейса в JS:
PS: лично я не понимаю вопросы типа «а что будет если функцию вызвать с неверными аргументами?». Неважно что будет. Надо просто ее вызывать правильно)
Что будет являться достаточным пониманием принципа ее работы?
1) Она возвращает минимальное число из предоставленных аргументов;
2) Она возвращает минимальное число, действуя по алгоритму (далее идет описание алгоритма)
Для меня важны паттерны и читабельность кода, но эти вещи напрямую связаны с программированием. Если стоит задача написать биржевого робота, то понимание всяких свечек, спредов и прогнозирование цены уж точно не должно входить в обязанности программиста. Для этого есть экономисты, которые консультируют программистов и помогают им перевести эти алгоритмы в программный код. Это мое личное мнение и я не претендую на то, что так должно быть везде. Мне просто кажется это самым адекватным подходом.
Я ему возразил: «А вдруг понадобится рассчитать длину цепочки ДНК? Получается программист должен и биологию знать?»
Мне кажется, все эти вопросы по высшей математике или о внутреннем устройстве алгоритмов спрашивают только те, кто потратил время на их изучение и теперь ищет куда приткнуть полученные знания, демонстрируя кто здесь Альфа-программер: «Этот новичек даже второй закон Кирхгофа не знает… а вдруг завтра понадобится?»))
Там по сути не так уж много кода внутри: обсервер/медиатор и модули. Практически все фреймворки работают по этой схеме (правда некоторые предпочитают хранить стейт во внешней модели, а другие — внутри модуля в его замыкании, но это нюансы). Для CRUD-приложений еще может понадобиться некое подобие виртуального dom.
Только мой камень в огород фреймворков, сборщиков и транспилеров имеет немного иную форму:
Напишите свой продукт один раз на JS и больше не понадобится переписывать его на очередной хайповый фреймворк по прихоти 23-летнего сеньера, который увлекся функциональщиной и теперь лоббирует очередной HaskellScript в продакшн.
Найти человека, который знает javascript намного проще, чем выискивать уникальную смесь из скиллов, типа Vue, Redux, Gulp, LESS и т.д. Сообщество слишком раздроблено и объединять его надо под флагом чистого JS.
Я не ратую за революцию… я за реставрацию)
Фронтендеры часто жалуются на обилие технологий, которые надо изучать. Мой подход позволяет им, при желании, отстраниться от нюансов CSS и HTML и позволить верстальщикам самим писать хаки для IE6 внутри стилей, а сеошникам писать в HTML свою микроразметку для поисковиков. Освободившееся время они могут потратить на тусовки и развлечения.
В моем будущем программист — свободный человек, который не беспокоится о том, что вышел очередной фреймворк. В будущем от Facebook и Google ему уготовано лишь «eat, sleep, code, repeat»))
Стили и html могут писать «низкооплачиваемые» участники процесса разработки, типа верстальщиков/дизайнеров.
Отверстав по стайл гайду все возможные состояния компонентов, они могут передать свою работу далее программисту, который привяжет внешнее состояние сверстанных компонентов к модели приложения/сайта.
Например:
Допустим у некой кнопки есть два состояния (нажата — зеленый бэкграунд, отжата — красный). Дизайнер написал стили для каждого состояния и повесил их на разные селекторы. Программист привязывает эти состояния к событиям в системе и при возникновении условного события buttonOn вешает на компонент соответствующий ему класс.
Как из этого всего можно сделать модули?
Тут необходим подход по типу Vue:
Помещаем в один файл с расширением .component разметку на html/jade, стили на css/scss, логику на js. Все это лежит тремя блоками в тегах div, style, script. Далее специальный сборщик все это обрабатывает и аккуратно раскладывает по полочкам: стили добавляет в css-файл, разметку подставляет в html и скрипты добавляет в js-файл.
Все просто и логично: верстальщик создал свою часть компонента, а программист — свою. И никаких десятков библиотек и препроцессоров в зависимостях. А то у React-сообщества уж сильно тяга к овер-инжинирингу проявляется)
Вот таким я вижу будущее компонентной разработки)
Общий посыл статьи понятен — язык великолепный, просто вы не умеете программировать)
А если попробовать так:
Насколько я помню, в этом случае значение останется равным пяти, но никаких уведомлений об ошибках не последует.
Интересно, многие из народа осмелятся включить такую опцию?))