Как научить программировать свою девушку, если ты не педагог, но она в тебя верит

Как думаете, возможно ли на описанных мною этапах, практиковать ваш метод?
Идея завершаемых за 10-15 минут задач мне очень нравится. Это «детский» подход, который, как мне кажется, на взрослого человека может подействовать с не меньшим успехом.
Главное — постараться подобрать действительно интересные задания, желательно применимые в конечном проекте.

Как научить программировать свою девушку, если ты не педагог, но она в тебя верит

Я потому-то и решил попробовать по-другому, что видел множество примеров неудачного погружения через вёрстку.
Здесь, пожалуй, кроме первоначальной заинтересованности, стоит учитывать темперамент человека, усидчивость, склонность к тому или иному образу мышления. Я, к сожалению, не большой мастер в этом, поэтому буду пробовать так, как описал.
Хотя любые советы, само собой, приветствуются!

Как научить программировать свою девушку, если ты не педагог, но она в тебя верит

Честно говоря, подобные мысли были. Просто в какой-то момент мне подумалось, что нужно попробовать посмотреть на эту ситуацию с другой стороны: многие из нас пришли в программирование, в том числе и в веб-программирование, не из вёрстки, а из старых добрых геометрических анимаций QBasic — возможно, этот путь не так прост, но если он протоптан, то почему бы не попробовать провести через него другого человека?

С другой стороны, конечно, это может не сработать. Но я надеюсь, что интерес к сотворению чего-то, полезного для себя любимой, сыграет свою роль, и всё получится!

Как научить программировать свою девушку, если ты не педагог, но она в тебя верит

Это очень сложно для новичка, вы правы! Именно поэтому я и взялся писать об этом на Хабр, ведь, хоть я и описал порядок по пунктам, но кто знает, как оно пойдёт дальше, а «Хабр всё помнит».
В общем-то, цель этой статьи, как и всего будущего цикла (надеюсь, возможность будет), опробовать описанный метод, зафиксировать все грабли, попавшиеся на пути, и рассказать всё это коллегам, чтоб помочь им, внезапно очутившимся в похожей ситуации, своим опытом, каким бы он по итогу ни оказался.

Еще раз о веб-компонентах…

Хорошая ссылка. Она должна была быть в этой статье.

Еще раз о веб-компонентах…

Внутренний интерфейс хрома — это не в счёт, так как внезапно не нуждается в поддержке ie, edge, safari)

А вот ютюб — это да, проглядел я, мой косяк)

Еще раз о веб-компонентах…

Ваши аргументы в статье не объективны. Вот вы говорите, что необходимо отказаться от популярных фреймворков/библиотек, ради «скорости, сокращения непомерного объема зависимостей, сокращения самой зависимости от зависимостей.»

React (react + react-dom) сам по себе тянет за собой 5(!) зависимостей:

• loose-envify
• js-tokens
• object-assign
• prop-types
• schedule

Вы вот серьёзно? Непомерного количества?

И так у вас везде.

Вы уповаете на Polymer. Ок, вопросов нет, забавная игрушка с возможной перспективой. Но скажите, почему Google всё ещё не отказался от Angular, если использование Web Components настолько быстрее/лучше/красивей/зеленее?
Почему вы такие вопросы в статье обходите стороной? Где объективизм?

Вы говорите, что все решения начинались как велосипеды, но это больше похоже на слова зелёного джуна (которым вы-то, скорее всего, не являетесь, что ещё больше пугает), неспособного разобраться в теме, не пришедшего к пониманию того, что все сегодняшние популярные решения — это старые (читай проверенные временем) решения «портированные» из других языков, парадигм и т.д.

Вы говорите, что рынок должен пойти за Web Components, потому как они отвечают его требованиям «к надежности, скорости разработки, скорости загрузки, стоимости поддержки и т. д».
Возможно! Но чтоб рынок поверил в это, нужно сначала рынку показать, что это решение используется и поддерживается крупными игроками (надежность), что на рынке есть достаточное количество специалистов, работавших с этим решением (скорость разработки и стоимость поддержки), что есть реальные исследования, говорящие о том, что Web Components быстрее грузятся, нежели популярные сегодня решения, честные исследования, учитывающие кэширования популярных версий из cdn, например, учитывающих минификацию сорсов.

Я вас уверяю, ни по одному из этих пунктов Web Components не выиграют. И именно поэтому они на сегодняшний день не популярны.

Вы так защищаете Web Components, как будто на них кто-то нападает, как будто кто-то спорит с тем, что идеи сами по себе хорошие.

Нет же, всё круто, всё правильно, просто использование этих технологий сегодня не даёт никакого профита.

Вот если бы гугл выкатил хотя бы один свой боевой проект, написанный на собственном Polymer, тогда можно было бы о чём-то говорить, а пока этого нет, разговор этот имеет смысл только в разрезе собственных поделок.

Еще раз о веб-компонентах…

Вы в очередной раз пытаетесь заставить нас смотреть на сравнение тёплого с мягким.

React, Vue, Angular, etc. предлагают не только и не столько собственную реализацию решений, на которых основаны web components, сколько модель работы с данными.
Писать собственные реализации flux-хранилищ, описывать собственную реактивную модель — это либо очередной велосипед, либо опять-таки куча зависимостей, от которых якобы нас спасут web components…

А обвинять людей в использовании чего-то модного и нежелании знать ничего другого — это, знаете ли, так себе. Мы в массе своей создаём продукты для бизнеса, условия диктует рынок, а не мы…

Аналоги в Python и JavaScript. Часть третья

for (i=0; i<items.length; i++) {
    console.log(items[i]);
}

Это не слишком красивая запись, и немного сложная для новичков — такая запись не выглядит естественно

Это мы, конечно, приехали. Итераторы, генераторы, спреды, регулярки — это для новичков самое то, а старый-добрый for — это не красиво, немного сложно и неестественно)
Ещё, пожалуй, стоит оградить новичков от while, а то не приведи господь им узнать, что в этом цикле можно остаться навсегда))

ЗЫ: это не претензия, и уж тем паче не к автору ПЕРЕВОДА)
Просто забавно))

Указатели C как лингвистический парадокс

Здесь нужно понимать несколько моментов.

С одной стороны, да, всё всегда упирается в синтаксис, поскольку работаем мы [программисты] с кодом; понятие «переменная» и «указатель» справедливы только для кода, непосредственно железо в этих понятиях не нуждается и ими не оперирует.
Поэтому формально я с вами согласен, да.

С другой же стороны, если посмотреть на ситуацию комплексно, то мы сможем свести все причины проблем с указателями всего-то к двум:

1. Непонимание сути указателей;
2. Незнание синтаксиса.

Так вот суть в том, что решить первую проблему лингвистическими аналогиями — невозможно. Здесь нужно просто объяснять человеку, что есть память, что есть переменная. Когда если человек разберётся с этим, тогда вопрос сложности восприятия синтаксиса стоять не будет, так как синтаксис не нужно понимать, синтаксис нужно просто выучить. Вне зависимости от языка (я сейчас даже не о технических, не об ЯП — обо всех: русский, английский, etc.) синтаксис — это аспект, который не требует понимания, он требует только зубрёжки.
Но здесь мы сталкиваемся со второй проблемой: вы можете зубрить что угодно и сколько угодно, но пока вы не поймёте сути темы — толку ноль.

Именно поэтому у людей и возникают проблемы с такими казалось бы несложными вещами как указатели: они либо путают порядок, в котором должно обучаться, либо выполняют лишь одно из двух действий.

Резюмируя, статья интересная, правда. Для тех, кто итак всё понимает.
Новичкам же от неё толку будет ноль, поскольку она не решает ни одной из вышеперечисленных проблем)

Указатели C как лингвистический парадокс

В статье поднимается вопрос непонимания начинающими темы указателей и предлагается решать это объяснением синтаксиса (посредством странной аналогии).
Для объяснения темы указателей как таковых существует множество более удачных аналогий, часть из которых приведена комментаторами выше (хотя мне искренне не понятно, что может быть непонятного в определении из условной Викидепии).
Для объяснения же синтаксиса существуют документация, туториалы и т.д.
Объяснять синтаксис технического языка на примере конструкции из живого — это, как минимум, странно и долго. Как максимум — отпугнёт и разочарует.

Но за попытку спасибо)

Основы JavaScript для начинающих разработчиков

Особенно нравится, что стрелочные функции — это, оказывается, тоже синтаксический сахар)
Хорошо, что хоть let и const синтаксическим сахаром не назвали, ага)

Решаем проблему миллиона открытых вкладок или «помогаем железу выживать»

function now() {
    return new Date().getTime();
}

Лучше заменить на

function now() {
    return Date.now();
}

Исчезающие фреймворки

Софту, варящему кофе, типизация, возможно, и не нужна в силу тривиальности решений.
А вот в процессе разработки крупных проектов, где львиная доля бизнес-логики делегирована клиенту, вы, попробовав в течение пары недель тот же TypeScript, очень быстро вспомните все прелести статической типизации.

Это не говорит о том, что на ES6 невозможно писать, да. Можно, конечно, но в «большой тройке», например, о которой вы так часто говорите, либо уже ушли от ваниллы (Angular и в некотором смысле React), либо жалеют, что не ушли (Vue).
Всё-таки её [статической типизации] пользу трудно переоценить)

Испанское футбольное приложение La Liga сделало своих пользователей невольными доносчиками

Читаю ваш комментарий через хабр-приложение. С телефона. В трамвае. Удобно. Удобнее, чем в мобильном браузере.

Моя история создания мотивационного приложения (iOS и Android) для дочери с дочерью на Unity и C#

Очень приятный стиль! Давайте ещё!)

Провалы футурологов. Идеи из фильмов, которые не осуществились

Чтобы пользоваться световым мечом необходимо быть чувствительным к Силе. В противном случае, есть огромная вероятность самовыпилиться. Отсутствие веса у «лезвия» обязательно даст о себе знать. Это что касается людей.
Дроидов же вооружать мечами было бы слишком накладно, учитывая редкость и дороговизну кайбер-кристалов. Кроме того, дроид, будучи не чувствительным к Силе, всегда будет менее эффективно пользоваться мечом, хотя и не самоубьётся.

Единственным исключением был Генерал Гривус. Но он не дроид, а киборг, причём явно чувствительный к Силе.
Хотя в итоге его это не спасло)

Провалы футурологов. Идеи из фильмов, которые не осуществились

Звёздные войны, как и вселенные DC и Marvel, — это фантастика в рамках отдельно взятых вселенных или измерений.
Так что нет, далеко не все фантасты имеют целью заглянуть в будущее.

Это сродни тому что заявить, что Дж. Р. Р. Мартин или Дж. Р. Р. Толкин заглядывали в прошлое))

Когда и почему стоит использовать стрелочные функции ES6, а когда нет

Во-первых, это всё равно не объясняет необходимости ввода переменной button, а во-вторых, windows.self не будет работать внутри класса.
Но да, ваш пример всяко лучше аутентичного из статьи)

Когда и почему стоит использовать стрелочные функции ES6, а когда нет

Высосанные из пальца примеры — это, конечно, наше всё))

var button = document.getElementById('press');
button.addEventListener('click', () => {
    this.classList.toggle('on');
});

Зачем здесь использовать this? Зачем мы объявляли button, если потом не используем? Забавно, конечно)

var button = document.getElementById('press');
button.addEventListener('click', () => button.classList.toggle('on'));