Ответы пользователя по тегу JavaScript
  • Асинхронность и чистые функции несовместимы?

    yurakostin
    @yurakostin
    Front-end developer
    Здравствуйте.

    Курите функциональное программирование. Дмитрий Беляев вам в целом всё правильно сказал: запрос, вывод в консоль, чтение из глобальной области видимости, запись в файл и всё прочее - сайд эффекты, которые в идеале нужно выполнять на границе "чистого" и "грязного" миров. Во фронтенд разработке, к сожалению, эта граница практически отсутствует, так как всё время есть какие-то события, какие-то запросы туда-сюда, и вот это вот всё, но тем не менее, вы можете писать код так, чтобы он был лучше, чище, понятнее; был прост в поддержке, и т д.

    По вашему вопросу. Логика асинхронных операций в библиотеке типа fp-ts вынесена в Task, и все преобразования над данными можно реализовывать чисто.

    Но начать лучше, пожалуй, с наиболее адекватного введения в ФП. Будьте готовы к тому, что мозг будет отказываться воспринимать информацию, и если вам не зайдёт - возвращайтесь в ФП позже. Это немного другой мир, но он по-своему прекрасен.
    Ответ написан
    Комментировать
  • Как сделать поиск по коду при нажатии на кнопку?

    yurakostin
    @yurakostin
    Front-end developer
    Здравствуйте.

    Постарайтесь перестать думать через вёрстку, и через поиск элементов.
    Я понимаю, что у вас тут всё рендерится сервером, но тем не менее.

    Если у вас все данные доступны на клиенте, тогда можете сделать так.

    А ещё проще при изменении данных фильтров отсылать запрос на сервер, и получать либо разметку, либо данные для рендера.
    Ответ написан
    Комментировать
  • Что можно сделать для портфолио начинающему react js программисту?

    yurakostin
    @yurakostin
    Front-end developer
    Покажите на github-е, что вы развиваетесь.
    Сделайте один проект так как умеете сейчас.
    Добавьте в него eslint, prettier(если их ещё нет).
    Научитесь видеть проблемы в своём коде.
    Потом сделайте другой проект, но уже с использованием, например хуков(если не используете сейчас).
    Потом добавьте TypeScript.
    Потом... потом начните писать на Haskell =)

    Ваша задача как разработчика, прийти на проекте, быстро в него погрузиться и быстро начать решать задачи бизнеса. Чем шире ваша экспертиза, тем качественнее и быстрее вы работаете.
    Поэтому делать кучу однообразных Todo - плохая затея.
    Нет смысла делать разные проекты, если всё, что вы там делаете - запрашиваете данные и отображаете их.
    Научитесь работать с картами, например Yandex или 2GIS.
    Научитесь работать с браузерным audio API.
    Ответ написан
  • Стоит ли идти в веб-разработку?

    yurakostin
    @yurakostin
    Front-end developer
    Идти или нет
    Идти в веб разработку стоит по двум причинам:
    • Веб разработка, как и любое другое ремесло - занятие, которое нужно попробовать, чтобы понять, нравится оно или нет, а значит, если вам интересно, то попробуйте, но не ждите быстрого результата. Редкий художник/писатель быстро/дорого продаёт свои работы в первый год, пока он осваивает ремесло. Возможно аналогия не самая удачная, но, надеюсь, понятная. (PS: я учился вебу год перед тем как попасть на первую работу)
    • Умение программировать учит по-другому думать и смотреть на решение любых проблем. Хотя далеко не у всех программистов системный подход к решению задач.


    Направление в разработке
    С направлением есть нюансы, которые актуальны, по крайней мере для меня ( эти нюансы справедливы для любой сферы деятельности человека).

    Предположим, что вы выучили всё, что нужно и нашли работу. И первый год уже учитесь на работе, решая бизнесовые задачи, и вы счастливы, получая деньги и делая то, что вам интересно.
    Проходит 2 года и вы чувствуете что набили оскомину, что ваша работа вас уже не радует.
    Это может говорить о том, что:
    • Вы выросли и вам нужно просить дать вам больше ответственности и других задач, или менять работу с повышением.
    • Вы выгорели на текущей работе от горящих сроков, токсичных коллег или руководства. В этом случае, если на вопрос "нравится ли мне делать то, что я делаю?" ваш внутренний голос отвечает "да, я всё ещё это люблю, я просто устал от негатива, сроков, недосыпа, etc", тогда имеет смысл поменять компанию.
    • Если же вы понимаете, что не испытываете никакой радости в принципе, а вся эйфория была только от того, что у вас был хороший заработок, тогда, к сожалению, IT - не ваше.


    Дальше, если вы всё-таки остались в IT, наступает прикольный момент, когда вы думаете, что изучили всё, что было можно изучить, или хотели бы заняться чем-то другим: мигрировать с веба на мобилки; мигрировать с интерфейсов на геймдев; мигрировать с фронта на бэкенд; etc.
    Тут наступает новый момент выбора, и у вас, очевидно, два варианта:
    • Остаться там, где вы есть.
    • Мигрировать.


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

    Очень условный совет на счёт более раннего определения предпочтительного направления заключается в том, что нужно бесконечно учиться и пробовать разное. Ваша работа(опять же, так было и есть у меня) не заканчивается после того как вы ушли из офиса(или закрыли ноутбук, работая удалённо).
    После завершения рабочих обязанностей вам нужно самую малость отдохнуть, а дальше открывать ноутбук и пробовать писать игру/мобильное приложение/бэкендовый сервис/и т д. Только так вы поймёте, что вам нравится больше. Важно, помнить, что новая область всегда будет казаться сложнее того, что вы знаете, но если вам интересно - не опускайте руки.

    У меня тоже получилось многословно =)

    PS: всё написанное выше - не инструкция, а мой личный опыт и суждения.
    Ответ написан
    2 комментария
  • Как подгрузить новости из БД по нажатию кнопки?

    yurakostin
    @yurakostin
    Front-end developer
    Круто, что вы ставите перед собой и решаете задачи. Как я понял, ваше решение работает, и это отлично.

    Теперь поставьте перед собой две цели:
    • Сделать ваш код лучше. Например, использовать фреймворк, или пару библиотек, или хотя бы fetch, чтобы не писать столько лютого кода. Разбейте ваш код на части, абстрагируйте его. Уйдите от императивщины в сторону ООП, или ФП
    • Сами подумайте над тем как сделать лучше. Не существует единственно правильного решения задач. Особенного в js =). Всё, что вы сделали другой, более опытный разработчик сделает немного иначе, но и только. В идеале вам нужно пройти этот путь. Например, как написали выше, уменьшить количество запросов. Если у вас есть дома доска, встаньте рядом с ней(ну или воспользуйтесь старой доброй тетрадью), возьмите мел или маркер, и нарисуйте данные, которые вы получаете. Их можно как-то скомпоновать? Можно ли вообще иначе подойти к решению? Как сделать его оптимальнее, уменьшив количество запросов? Как унифицировать решение? Вероятно вы пройдёте долгий путь, но ваша экспертиза возрастёт.
    Ответ написан
    Комментировать
  • Как сбежать с фриланса?

    yurakostin
    @yurakostin
    Front-end developer
    Английский учить стоит однозначно.

    И если вам понравилось на upwork и с удалёнки в целом можно не съезжать, то возможно, что именно английский вам и стоит сейчас прокачивать в первую очередь.
    А там уже вся зарубежная(а значит более актуальная) информация будет более доступной для понимания.

    Ну или же искать компанию, которая готова взять вас с горящими глазами на обучение на не очень большую зп. И фигачить на работе(по рабочим задачам) и дома - учить js, фреймворки, сопутствующие API и библиотеки, а также, разумеется алгоритмы и структуры данных и паттерны и так далее, и тому подобное, словом, расширять кругозор себя как разработчика.
    Ответ написан
  • Как правильно вставлять в DOM c помощью js?

    yurakostin
    @yurakostin
    Front-end developer
    Попробуйте взглянуть на это: https://jsfiddle.net/z5gacj4s/2/
    Ответ написан
    Комментировать
  • Как писать Толковый ООП код в JS?

    yurakostin
    @yurakostin
    Front-end developer
    На мой вкус там, где ООП - там паттерны, а где паттерны - там не обязательно должно быть ООП.
    Вы должны понимать, зачем вы создаёте все ваши классы. Какую проблему они решают.

    Вот достаточно популярный ресурс по паттернам.

    Если вы хотите прям ООП-ООП, то у вас более половины вашего кода должно быть написано иначе(а ещё лучше на ООП языке типа Java). Не должно быть просто вызовов функций: вся работа через объекты. Никаких `$toolbar.append` и прочего.

    Опять же, я могу быть глубоко не прав, но js ни ООП, ни ФП подход не реализует в полной мере. Поэтому только и остаётся, что писать в каком-то гибридном стиле. Возможно, что это огромная проблема языка, возможно наоборот.
    Ответ написан
    Комментировать
  • Где лучше применять функциональное программирование в JavaScript?

    yurakostin
    @yurakostin
    Front-end developer
    Привет.

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

    К слову про RxJs. Я "̶н̶е̶ ̶ч̶и̶т̶а̶л̶,̶ ̶н̶о̶ ̶о̶с̶у̶ж̶д̶а̶ю̶"̶ , не изучал его, но слышал, что в библиотеке всё построено на ФП, и это одна из моих целей к изучению.

    Как с ФП так и с ООП можно решать определённые типы задач. И порой код выглядит очень усложнённым, если мы пытаемся применить ФП для решения ООП задачи и наоборот.
    Отчасти нам повезло, что js позволяет делать и так, и эдак, и не заключает нас в рамки использования какой-то одной концепции.

    Забавная статья про ФП и ООП

    Очень годный цикл из трёх докладов на тему ООП, и почему оно нам нужно. Здесь Антон рассказывает о том, что такое доменная сложность, и этот доклад очень повлиял на моё восприятие ФП и ООП подходов. Теперь, если нужно принять решение, какой подход использовать, я спрашиваю себя, с какой доменной сложностью я столкнулся.

    Согласитесь, что до возникновения определённых требований(пока не представляю каких), нет смысла реализовывать функциональность сложения чисел с использованием ООП.

    Я даже не знаю как это правильно реализовать на ООП...
    class Sum {
        static sum(a, b) {
            return a + b;
        }
    }
    
    class Sum {
        constructor(a, b) {
            this.a = a;
            this.b = b;
        }
        
        sum() {
            return this.a + this.b;
        }
    }


    При том, что в функциональном стиле это arrow function в одну строку
    const sum = (a, b) => a + b;


    А в haskell это вообще великолепно:
    sum :: Int -> Int -> Int
    sum a b = a + b


    Есть, кстати, великолепный учебник по Haskell.

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

    • решал поставленную задачу
    • был легко поддерживаемым
    Ответ написан
    Комментировать
  • Решать задачи VS Продолжать учиться?

    yurakostin
    @yurakostin
    Front-end developer
    Вы что-нибудь умеете? Вы учились, или решали задачи чтобы этому научиться?
    Ответ написан
    Комментировать
  • Как систематизировать изучение JS?

    yurakostin
    @yurakostin
    Front-end developer
    Ссылок, собственно, дофига..

    https://learn.javascript.ru/
    https://github.com/getify/You-Dont-Know-JS
    jstherightway.org
    largescalejs.ru
    shop.oreilly.com/product/9780596517748.do
    https://habr.com/company/ruvds/blog/337042/

    У Кантора вполне себе систематизированный учебник. Именно с него я начал, когда понял, что jquery для меня недостаточно.
    Но дело не только в том, что вы читаете учебник. Я уже 100500 раз, наверное, это говорю, но:
    1. Вы должны решать все задачи, которые есть в списке задач к главам.
    2. Важно ещё пытаться применить полученные знания где-то: в своей работе, или в какой-то выдуманной задаче. То есть, например, нужно использовать `Array.prototype.filter` столько раз, чтобы не возникало больше вопросов "как оно работает?", чтобы руки "помнили".

    Разумеется, это всё нужно для того, если вы хотите во фронт. Пласт информации огромный. Сам js, браузерные API, и прочее-прочее..

    Может быть, что всё выше - оффтоп, но дело в том, что нет систематизированного подхода, как мне кажется.
    Есть знакомые, которые умеют работать только с DOM-ом и событиями, а как работать с данными в js, что такое замыкания - не знают. А сайт Ильи Кантора им почему-то кажется сложным.

    Просто решайте разные задачи: работайте с данными; рисуйте на canvas, svg; манипулируйте DOM-ом; используйте service worker-ы; etc.. Это и будет расширять ваш кругозор..
    Но начать я бы советовал всё-таки с учебника Ильи ;)
    Ответ написан
    Комментировать
  • Как правильно реализовать подписку в паттерне Observer?

    yurakostin
    @yurakostin
    Front-end developer
    Фактически есть тот, кто издаёт новости и тот, кто хочет их получать.

    Таким образом есть две сущности: Издатель и Подписчик.

    Издатель извещает о том, что что-то произошло.
    Подписчик реагирует на это происшествие.

    Так у нас получается что-то такое:

    Подписчик
    methods:
    + отреагировать на событие

    Издатель
    props:
    - подписчики

    methods:
    - оповестить подписчиков
    + добавить подписчика
    + удалить подписчика
    + издать новость

    Если уйти от псевдокода, то получится следующее:

    class Publisher {
        constructor() {
            this._subscribers = [];
            this._state = {};
        }
    
         get state() {
            return this._state;
        }
    
        set state(value) {
            this._state = Object.assign({}, this._state, value);
            // Неявный вызов, можно, наверное, сделать лучше
            this._notifySubscribers();
        }
    
        _notifySubscribers() {
            this._subscribers.forEach((subscriber) => subscriber.notify(this._state))
        }
    
        addSubscriber(subscriber) {
            this._subscribers.push(subscriber);
        }
    }
    
    class Subscriber {
        constructor(name) {
            this.name = name;
        }
    
        notify(state) {
            console.log(`${this.name}: i received a new data: `, state);
            console.log('\n\n')
        }
    }
    
    const publisher = new Publisher();
    const subscriber1 = new Subscriber('John');
    const subscriber2 = new Subscriber('Jane');
    const subscriber3 = new Subscriber('Mary');
    
    publisher.addSubscriber(subscriber1);
    publisher.state = {a: 1};
    
    publisher.addSubscriber(subscriber2);
    publisher.state = {b: 2};
    
    publisher.addSubscriber(subscriber3);
    publisher.state = {c: 3};


    Код рабочий.

    Надеюсь, что я вас нигде не обманул и всё объяснил правильно.
    Ответ написан
    Комментировать
  • Абстракция в JavaScript?

    yurakostin
    @yurakostin
    Front-end developer
    Простите, а что вы подразумеваете под абстракцией в js?

    Есть, например, абстрактные классы. Об этом можно почитать в книгах про паттерны. Абстрактные классы, да не буду заброшен я помидорами за неточность, это классы, методы которых могут быть не описаны.

    class Animal {
        constructor({name, age}) {
            if (this.constructor.name === 'Animal') {
                throw new Error(`${this.constructor.name}: can not create instance of abstract class`);
            }
            
            this.name = name;
            this.age = age;
        }
    
        name() {
            return this.name;
        }
    
        age() {
            return this.age;
        }
    
        /*
         * Абстрактный метод
        */
        talk() {}
    }
    
    class Dog extends Animal {
        talk() {
            console.log('Bark!')
        }
    }
    
    const animal = new Animal({
        name: 'Jack',
        age: 5
    }); // выбросит ошибку
    
    const dog = new Dog({
        name: 'Jack',
        age: 5
    });
    dog.talk(); // Bark!


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

    Мне кажется, что вы задали не очень корректный вопрос, или сами не понимаете, что хотели вообще спросить.
    Ответ написан
    Комментировать
  • Как работает Let на Java Script Es2015?

    yurakostin
    @yurakostin
    Front-end developer
    Если не ошибаюсь, то `one` и `two` объявляются в данном случае как свойства глобального объекта. Собственно, это можно легко проверить, если написать в вашем коде:

    console.log(window.one, window.two, window.five);

    С таким объявлением нужно быть осторожным.
    Лучше всегда через var, let, const объявлять, да и вы наверняка это сами знаете.
    Ответ написан
    Комментировать
  • Какой код начать писать на JS?

    yurakostin
    @yurakostin
    Front-end developer
    Не покупайте пока никаких книг. Завершите две основные части learn.javascript.ru.

    Среди ответов была интересная мысль про морской бой.
    Вот пусть это будет вам первая задача.
    Задача интересная.
    Сделайте очень простую реализацию. Без бэкенда и прочего, чтобы всё было максимально просто.
    Пусть будет видно сразу два игровых поля - ничего страшного.

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

    Потом всегда можно допилить, чем вы скорее всего не займётесь, но уже приобретёте хороший опыт.
    Ответ написан
    Комментировать
  • Что входит в обязанности frontenda (вопрос к работающим)?

    yurakostin
    @yurakostin
    Front-end developer
    Frontend разработчик сейчас понятие чертовски широкое.

    Думаю, что реально крутой frontend developer умеет следующее:

    • Верстать. Доступно, кроссбраузерно, адаптивно, резиново и так далее.
    • На отлично знать VanilaJS.
    • Уметь собирать проекты: стили, js, шрифты, шаблоны - всё. Webpack, пожалуй - наше всё. Ибо, насколько я помню gulp и grant - таск-менеджеры. А с этой задачей прекрасно справляется npm. Соответственно.
    • Уметь настраивать webpack и при этом помнить, что есть готовые решения для сборки.
    • Уметь как работать с npm.
    • Уметь работать с двумя-тремя популярными фреймворками. Например Vue.js,
      Angular.js, React.js + Redux.js. Представлять плюсы и минусы каждого из решений.
    • Уметь писать код. Тоже очень широкое понятие. Но, я, пожалуй, остановлюсь на том, что хороший фронтендер должен писать код, придерживаясь code style-а; выделять общие части в отдельные функции/классы и т д; давать адекватные имена переменным/функциям/классам etc. В общем держать свой код в чистоте и порядке.
    • Уметь читать чужой код. Это очень непростая работа. Нужна высокая сосредоточенность, внимательность.
    • Уметь покрывать свой код тестами.
    • Уметь планировать архитектуру клиентской части приложения. Я бы даже сказал, что очень пригодится умение писать UML схемы. Мы же не jquery карусель собрались писать на такой должности.
    • Понимать на простом уровне как работает HTTP. Как клиент отправляет данные, как их считывает сервер, как отдаёт ответ, и т д.
    • Интересоваться смежными областями. В первую очередь backend. Благо можно не учить php, ведь есть nodejs. Это тот же самый javascript, так что думаю, что шикарный фронтендер должен уметь писать и на nodejs, понимать нюансы его работы.
    • Знать больше чем html, css, js. Уметь, например, программировать на python/erlang/ClosureScript/php/c/haskell/подставь своё. Это расширяет кругозор.
    • Следить за новинками в своей области и интересующих смежных областях.
    • Уметь работать с git.
    • Уметь работать с командной строкой. На мой взгляд уметь только cd, ls, mkdir, chmod, chown и touch - не серьёзно.


    Думаю, что если ещё посижу, то напишу ещё что-нибудь, но думаю, что основная мысль понятна - нужно уметь и знать много всего.

    Список этот может показаться пугающим. Но фишка в том, что всё сразу изучить нельзя. Двигайтесь по пунктам не спеша, разбираясь в тонкостях, нюансах.
    Изучение чего-либо процесс не быстрый, но если вам нравится то, что вы делаете, то усилия окупятся обязательно.
    Ответ написан
  • Что посоветуете почитать для левелапа в JS?

    yurakostin
    @yurakostin
    Front-end developer
    Есть мнение, что нужно изучать другие языки.
    Например, я неоднократно слышал, что те js разработчики, которые попробовали Haskell или ClojureScript, начинают мыслить по-другому.
    Посмотрите доклад Александра Соловьёва, там он немного об этом говорит (да и сам доклад просто прелесть).

    Важно понимать, что у одной задачи может быть несколько решений. Какое из них лучше вы сможете понять только с опытом. Но когда вы учите другие языки, проникаетесь их духом, когда смотрите, как кодят другие люди, когда участвуете в OpenSource проектах, вы становитесь лучше, вы знаете больше способов решений.

    Гениальные решения приходят либо спонтанно, либо путём трудов. Но в любом случае и то и другое доступно для вас.
    Ответ написан
    Комментировать
  • Где используются прототипы, наследование в JS приложениях?

    yurakostin
    @yurakostin
    Front-end developer
    Здравствуйте.
    На самом деле всё проще.
    Не обижайтесь, но вы просто не так хорошо знаете сам javascript.

    1. prototype - ссылка на прототип объекта.
    Array.prototype, Number.prototype. В нём хранятся методы и свойства этого объекта, а также... (далее переходим к __proto__)

    2. __proto__ - тоже ссылка на прототип. Например, введите в консоли [] и раскройте ветвь. У вас всего два свойства. Одно - length - количество элементов в массиве. Другое - __proto__. А где же все методы, которые мы можем использовать с массивами filter, map, slice и так далее? Они лежат в __proto__. Более подробно здесь.

    3. inheritance соответственно - наследование. JS построен на прототипной парадигме (надеюсь, я тут не наврал). Array наследуется от Object. Это можно легко увидеть, посмотрев Array.prototype. Там вы увидите тот самый __proto__, являющийся ссылкой на Object.prototype. Вся инфа по ссылке выше.

    4, 5. call и apply постепенно уходят из обихода, но тем не менее про них важно знать и уметь ими пользоваться. Эти методы позволяют вызвать функцию в контексте, который вам необходим.

    Например вам нужно вызвать метод какого-то объекта, который работает с this в контексте другого объекта, у которого этого метода нет. Вы можете сделать следующее:
    var o_1 = {
    	name: 'Peter',
    	hello: function () {
    		console.log('Hello, ' + this.name);
    	}
    };
    
    var o_2 = {
    	name: 'Jane'
    };
    
    o_1.hello.call(o_2); // Фактически вы говорите "вызови метод такой-то для объекта такого-то"


    Для передачи аргументов в "заимствованную" функцию оба метода принимают аргументы, каждый по-своему.
    var o_1 = {
    	name: 'Peter',
    	hello: function () {
    		console.log('Hello, ' + this.name);
    	},
            sum: function (a, b) {
    		console.log(`${this.name} sum a and b to ${a + b}`);
    	}
    };
    
    var o_2 = {
    	name: 'Jane'
    };
    
    o_1.sum.call(o_2, 2, 4);
    o_1.sum.apply(o_2, [1, 2]);


    Отличие между этими двумя методами в том, как они принимают аргументы, которые попадут в функцию.
    call принимает список аргументов, начиная со второго, а apply, соответственно, принимает массив.

    Также, ничто не мешает вам вызвать функцию, которая не нуждается в контексте, для этого первым аргументом можно передать null.

    var o = {
    	sum: function (a, b) {
    		console.log(a + b);
    	}
    }
    o.sum.call(null, 1, 2);
    o.sum.apply(null, [1, 2]);


    Подробнее тут.

    6. bind тоже довольно простая штука. Отчасти он похож на предыдущие два метода, за исключением того, что он не вызывает функцию сразу же.
    Основная его задача - вернуть функцию, которая будет вызвана для нужного вам контекста.

    var o = {
    	a: 1,
    	b: 2,
    	sum: function () {
    		console.log(this.a + this.b);
    	}
    };
    
    var o2 = {
    	a: 10,
    	b: 20
    };
    
    var o2Sum = o.sum.bind(o2);
    
    o2Sum();


    Также с помощью bind можно каррировать функции.
    Всё есть здесь

    PS: надеюсь, код не содержит ошибок и я нигде не налажал и всё правильно рассказал.
    Ответ написан
    4 комментария
  • Как применять знания javascript?

    yurakostin
    @yurakostin
    Front-end developer
    Довольно распространённая проблема.
    Вам нужен либо ментор, который будет помогать вам развиваться, либо просто используйте собственное воображение.

    Задач можно придумтаь, сколько угодно. И даже, если вы будете делать хотя бы тот же самый плагин попапов, то это НЕ ПЛОХО. Вы должны написать велосипед. Вы должны сделать работу, которую кто-то уже сделал 1000+ раз. Хорошо бы, чтобы после своей реализации вы посмотрели чужие.

    Отрисуйте с помощью js элемент, добавьте ему стилей, какие вам нравятся. Потом заставляйся этот элемент по клику "прыгать" по экрану в случайные места. При чём, если какая-то часть элемента будет попадать за границу экрана - делайте так, чтобы она всё-таки попадала в экран.

    Или заставьте тот же элемент передвигаться по экрану с помощью клавиш-стрелок.

    А если вам больше нравится с данными работать, то найдите генератор JSON данных. С помощью js сформируйте на основе этих данных таблицу, потом добавьте сортировку по названиям колонок.

    И так далее. Программирование очень творческий процесс. Не без исключений, конечно, но вам в начале пути нужно именно фантазировать. Придумывать задачи, которые было бы можно(или даже нельзя) реализовать с помощью программирования, и делать это.

    Успехов.

    PS: На эту тему можно много рассказать, предложить, поэтому как всегда много букв, прошу прощения.
    Ответ написан
    Комментировать
  • Как эффективно развивать себя как разработчика?

    yurakostin
    @yurakostin
    Front-end developer
    Вставлю свои пять копеек.

    Начну как всегда, наверное издалека, уж извините.

    У меня стало довольно мало времени на то, чтобы разрабатывать дома: ребёнок, удалённость жилья от места работы и т д.
    И вот ушедшие три дня выходных я потратил на ресёрч некоторых вещей.
    Прочитал почти половину документации по Vue, запустил hello world на clojure script, ну и галопом по европам прошёл по реализациям FRP на js, остановивишь на cellx. С ней просидел весь вечер.
    И вот только после этого я ощутил то забытое чувство, когда узнаёшь что-то новое, расширяешь кругозор.

    К чему я это всё?

    Я вспомнил, что до переезда, до ребёнка, я "летел" домой и до часу-двух ночи изучал что-то новое. Читал книги/статьи/какие-либо источники, и задавал себе вопросы "А что если сделать так?", "А если применить этот метод?", "А если вызвать с этим параметром?", etc, и пробовал на все свои вопросы найти ответы.
    А также я постоянно хотел что-то "напилить". Свой сайт, какой-нибудь маленький проект. Какой-нибудь маленький плагин. Можно продолжать бесконечно..

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

    Но - как в рекламе - и это ещё не всё.

    Ещё есть важные аспекты, которые делают из вас хорошего разработчика:
    1. Умение и можно сказать любовь читать чужой код. Читать, понимать(править?). Дело в том, что на любых проектах, особенно тех, где большая кодовая база была написана до вас, вам придётся разбираться в коде, и соответственно чтение и правка чужого кода будет занимать примерно 65-85% вашего времени.
    2. Отсутствие боязни перед чтением документации. Кто-то бежит смотреть статьи, где люди пишут свой опыт внедрения или, извините "пробования" какой-либо технологии или инструмента, и упускает огромный пласт информации, который описан в документации. Пласт, который может затянуть старт использования, но помочь вам быть абсолютно в теме того, с чем и как вы собираетесь рабоать.
    3. Третий пункт, немного связан со вторым. Вам нужно знать английский. На уровне достаточном чтобы понимать эту самую документацию. А также читать статьи зарубежных разработчиков. Ведь почти всё, что мы учим, сделано за бугром, и в связи с тем, что английский - международный язык, все более менее популярные библиотеки/фреймворки/инструменты, а точнее документация к ним, существуют на английском языке как минимум.

    Это всё, я думаю, более менее объективные пункты.. Ээмм, ну ладно, субъективно-объективные.. Ну короче вы поняли =)

    О ещё более субъективных, пожалуй, писать не буду. И так уже много букв, извините.
    Ответ написан
    Комментировать