• ООП в Javascript, наследование: как реализовать подобное?

    alexey-m-ukolov
    @alexey-m-ukolov Куратор тега JavaScript
    У вас почти всё верно, только пара синтаксических ошибок и одна логическая:
    var put = function(elem, text) {
      var text = encodeURIComponent(text);
      return {
        now: function(a) {
          var a = encodeURIComponent(a) || '';
    
          return {
            add: function() {
              elem.outerHTML += text + a;
            },
            replace: function() {
              elem.outerHTML = text + a;
            },
          }
        },
        after: function(time) {
          // do smth
        },
      }
    }
    
    put(document.getElementById("div_id"), "Hello ").now("world!").replace();
    Ответ написан
    3 комментария
  • Как быстрее перейти с Less на Sass (scss)?

    delphinpro
    @delphinpro Куратор тега Вёрстка
    frontend developer
    По-моему во всех трех популярных препроцессорах нет никакой принципиальной разницы. Чуть-чуть различается синтаксис, но это дело привычки. Я не ощущаю никакого дискомфорта при работе с любым из них, хотя большую часть времени приходится работать с sass.
    Ответ написан
    Комментировать
  • XMLHttpRequest; Как закэшировать результаты запросов до перезагрузки страницы?

    AppFA
    @AppFA
    Frontend developer at Yandex
    Ну можно как-то так, завести кэш, проверять есть ли в нем текущая страница, если да - то отдавать её, если нет - отправлять запрос, ложить в кэш:
    'use strict';
    
    let cache = {};
    let url = '/index.php?page=1';
    
    const page = document.querySelector('.page');
    
    if (!cache[url]) {
        fetch(url)
            .then((response) => {
                return response.text();
            })
            .then((data) => {
                cache[url] = data;
                page.innerHTML = data;
            });
    } else {
        page.innerHTML = cache[url];
    }
    Ответ написан
    Комментировать
  • Javascript; for vs forEach, что быстрее в 2016?

    allishappy
    @allishappy
    Вообще быстрее for, как мне кажется. Потому что forEach - это метод. Вызов любой функции затормаживает интерпретатор. И если у вас очень большой массив, то за секунду у вас вызовется огромное количество функций.
    Ответ написан
    1 комментарий
  • Javascript; for vs forEach, что быстрее в 2016?

    @lega
    В движках где forEach/map оптимизируются скорость примерно такая же как и у for, там где нет, for быстрее т.к. вызов функции на каждой итерации дополнительно грузит.
    Ответ написан
    Комментировать
  • Как получить значение из предложенного JSONP с помощью чистого JavaScript?

    Rou1997
    @Rou1997
    Это не JSON, а JSONP. JSON выглядит так:
    {
      "files": [
        {
          "type": "js",
          "name": "script"
        },
        {
          "type": "html",
          "name": "file"
        }
      ]
    }
    Ответ написан
    7 комментариев
  • Как эффективно работать целый день?

    @sarathorn
    php программист, веб-дизайнер, коллекционер
    Мне 20 лет, живу отдельно от родителей, зарабатываю фрилансом. Самое важное - организовать свой день.

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

    В моём случае физическая нагрузка или простая прогулка не улучшают продуктивность, с другой стороны залипание в ютюб/вк или чтение статей могут свести все старания на 0.

    Серьёзно мешают работать уведомления о письмах, сообщениях... звонки... В случае с работой в офисе будут отвлекать коллеги. Смело посылайте всех нафиг. Даже босса. Босс потом спасибо скажет, когда вы сделаете все задачи в срок или даже раньше.

    8 часов подряд кодить каждый день... Вы серьёзно? На этой неделе мои результаты такие: воскресенье - 12 часов кодинга, понедельник - 8, вторник - 8, среда - 6, четверг - 4, пятница - 3, суббота (сегодня) - нет ни малейшего желания, но очень надо хотя бы пару часов... Вы просто перегорите. Настраивайтесь на 4, максимум на 6 часов кодинга в день. Остальное время можно заполнить чтением документаций, проработкой прототипов на бумаге, обсуждениями с коллегами и боссом.

    Если ситуация требует 8-16 часов кодинга подряд (такое, увы, бывает), то меня спасают две вещи:
    1) Сериалы. Второй монитор, второй ПК, планшет или даже смартфон вам в помощь. Берёте сериал, который УЖЕ смотрели и включаете. Он должен быть интересный, но уже знакомый, это два обязательных требования. Так он не будет отвлекать от работы (сюжет же уже знаком, а половину реплик вы можете произнести вместо актёров), но создаст иллюзию отдыха. В моём случае можно всё привести к такому выражению: 60 минут кодинга = 80 минут кодинга под сериал. НО! Так я могу выдерживать 12-16 часов без особых усилий. Что в итоге даёт больше результата, чем 6-8 часов чистого кодига после которых я просто убитый на пару дней.
    2) Кофеин. Обычный кофеин. Кофе я не пью, а энергетики слишком дорогие для регулярного применения. Есть замечательная альтернатива - Кофеин-бензоат натрия. ~30рублей в аптеке за 6 таблеток. Максимальная разовая доза - 6 таблеток, она же 300мг кофеина. 1-2-3 таблетки мой организм может не заметить, а при шести я начинаю разговаривать сам с собой. Грань очень тонкая, но при правильной дозировке получается неплохой boost к производительности. Внимание! Кофеин может повышать давление и пульс, а также имеет ряд побочных эффектов. Передозировка может убить. Я не несу ответственности за последствия приёма кофеина.

    Смесь кофеина и прогулки (зима, 3 часа ночи, -20C) может породить тонну гениальных идей, увы, лишь 1 из сотни имеет шанс на успех в реальном мире.

    Вообще, я для себя вывел важную закономерность. Мотивация - фигня. Желание получить больше денег и когда-нибудь улететь на неделю на Мальдивы не приведёт к результату, рано или поздно, но мозг решит, что гораздо правильней работать в 2 раза меньше, но отдохнуть на местном водоёме с друзьями и шашлыками. Гораздо интереснее обстоит дело с чувством вынужденной необходимости. Проще говоря, с кнутом. Я не сделаю работу и меня уволят. Я не успею вовремя и меня лишат премии. Я облажаюсь и все будут смеяться надо мной... Вот это работает.

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

    Непосредственно программирование (как и дизайн) идёт легче, если есть план и схемы. В моём случае при работе над back-end у меня 70% времени уходит на проектирование и проработку мелочей на бумаге, лишь 30% времени это сам кодинг. При работе с фронт-эндом я где-то 60-70% времени работаю, а 30-40% проектирую. Я так понимаю, вас не заставляют именно кодить 8 часов. Вас заставляют 8 часов сидеть на рабочем месте. Вот и прикиньте, что из них лишь где-то 3-4 часа будут самим кодингом. Хотя... Если работы очень много, вы не единственный кодер в конторе и есть более опытные, которые и берут на себя всё проектирование... ух... тогда остаётся только монотонно стучать по клаве...

    Ещё очень важный момент. ОБЯЗАТЕЛЬНО ОТДЫХАЙТЕ! В выходные не должно быть ни единой мысли о работе, после работы займитесь хобби, уберитесь дома, погуляйте, сходите в спорт зал, почитайте книгу, посмотрите кино, поспите в конце-концов. Никакой работы за пределами рабочего места. Этот трюк заставит мозг ассоциировать рабочее место с рабочим процессом, а значит уже не нужно будет самому его мотивировать работать. Это работает крайне просто. Если вы видите очень красивую девушку да ещё и без одежды, то кое-что что происходит с одним очень важным органом и мозг начинает работать совершенно иначе. И вот теперь в поле зрения попадает ваше кресло и ваш рабочий комп, мозг пробегается по ассоциациям и понимает, что надо работать. В паре с состоянием вынужденной необходимости всё сработает на ура.

    Перерывы - спорный момент. Мне проще проработать, например, 6 часов без перерывов (только если на отойти до туалета или до кухни, чтобы налить воды и стащить печеньку), чем 6-8 с перерывами. Я очень много времени и сил трачу на переключение с одного вида деятельности на другой.

    По поводу еды. В момент приёма и пищи и где-то следующий час я способен только читать и смотреть, но никак не творить.
    Ответ написан
    10 комментариев
  • Можно ли получить данные из массива более коротким путем?

    webinar
    @webinar Куратор тега PHP
    Учим yii: https://youtu.be/-WRMlGHLgRg
    Все нормально, как вариант можно написать через
    php.net/array_map
    или
    php.net/manual/ru/function.array-walk.php
    Но в данном случае наверное нет смысла.
    Ответ написан
    Комментировать
  • Есть ли перспективы у фреймворка PHP Phalcon?

    pro_co_ru
    @pro_co_ru
    Старший инженер-программист
    Я вот уже играюсь с php7.0.8-dev + Phalcon 2.1.x
    На работе у нас активно разрабатывают проекты с использованием Phalcon.
    Думаю что Phalcon стоит изучить, хотя мне больше нравится Laravel.

    И у меня вопрос, может кто знает, при переходе с PHP5 на PHP7 на сколько % стало шустрее работать Phalcon, а на сколько % Laravel ?

    Ну и интересно было бы увидеть сравнение скорости работы этих фреймвороков на 5 версии PHP, и на PHP7.
    Ответ написан
    3 комментария
  • Что вы думаете по поводу Captcha.one? Является ли она действительно защищенной?

    @MoonMaster
    Программист и этим все сказано
    Где-то давненько видел презентацию программы, которая может отвечать на поставленный вопрос. И судя по видео она делала это довольно хорошо. Так что думаю, что она не является больно защищенной.
    Ответ написан
    Комментировать
  • Стоит ли отказываться от заказа?

    @Agin Автор вопроса
    Или мне стоит написать в саппорт?
    Ответ написан
    3 комментария
  • Как уйти с распутья технологий?

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

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

    А так по моему важнее не инструмент, а умение им пользоваться. Начинать следует с алгоритмов, а язык использовать как инструмент.
    Хотя откладывать изучение языка тоже нельзя - практика важнее теории. Так что в комплексе - постигай алгоритмы на практике, по мере необходимости, и запоминай их.

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

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

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

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

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

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

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

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

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

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

    С третьим - придешь, когда поймешь, что тебе это нужно. Из-под палки не учатся.

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

    С первым все просто: не можешь что-то решить - отложи, и спустись на ступеньку ниже по шкале сложности.
    Есть такой психологический феномен: от решенных задач ты получаешь удовлетворение, силы и мотивацию двигаться вперед, от нерешенных - негатив, апатию, потерю воли и мотивации.
    Причем мозг устроен так, что запоминается лишь негатив. Поэтому крайне важно решать задачи, и не допускать незавершенных задач. Отложи, но не забрасывай.
    Нерешенная задача - это как психологический запой, нечто вроде депрессии: одна нерешенная задача тянет за собой другую нерешенную задачу, и так быстро уходишь на дно, теряя мотивацию и веру в себя. Замкнутый круг. Ты находишься именно в нем.

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

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

    Сложность задачи не особо влияет на мотивацию, а вот факт решения/нерешения - влияет сильно. Не решил - значит не осилил, не осилил - значит не достоин, не достоин - значит иди ко дну и не рыпайся. Это как импотенция: импотент - значит не мужик, не мужик - значит никто, ничего не достоин и об тебя можно ноги вытирать. Подсознание портит всю малину, так что не следует давать ему шанса - лучше решить задачу попроще, чем не решить по сложнее.
    Ответ написан
    7 комментариев
  • Имеет ли смысл использовать REST(ful) API для работы самого вебсайта?

    dimasmagadan
    @dimasmagadan
    Имеет.

    Например, у вас бэкенд сайта на WordPress, а морда сайта сделана как приложение на backbone или react каком-нить.
    В этом случае проще будет воспользоваться готовым rest api и не писать свой код.

    Ну или у вас может быть не весь сайт как js приложение, а только какой-то раздел.
    Или можно ту же подгрузку записей при скролле через rest api реализовать, или еще что-то такое.

    В общем, везде, где вам нужно отправить ajax запрос к сайту и получить обратно данные, можно использовать rest api. Заметьте - не обязательно нужно, а можно. Что лучше, стоит на конкретном сайте/примере смотреть.
    Ответ написан
    Комментировать
  • Что лучше использовать для аутентификации: сессии или куки?

    @VZVZ
    Reverse-Engineer, Software Developer, Architect
    Авторизацию я как-то не изучал, но что-то не вижу никакой логической разницы между сессиями и куками.
    Во-первых, сессии разве бывают без куков?
    Во-вторых, если куки (допустим, в куках хранится токен - для примера) хранятся ТОЛЬКО на клиенте, то как сервак будет проверять, верный ли ему токен сует клиент, и от какого вообще аккаунта (юзера) этот токен? Значит, опять же токен и на серваке храниться должен, либо в БД, либо в файлах, возможно с примением редиса...

    Короче, по-моему, сессии - это лишь частный случай решения на базе куков.

    UPD: да и сам вопрос "что лучше" изначально абсурдный. Вроде очевидно, что раз есть 2 инструмента для одной и той же задачи, значит, один лучше для одних случаев, другой - для других. И без уточнения задачи ответить "что лучше" нельзя.
    Ответ написан
    Комментировать
  • Стоит ли использовать компонент Forms (формы)?

    nepster-web
    @nepster-web
    по сути компонент Forms есть наверно во всех фраэмворках и создан только с целью облегчить разработчику жизнь. Поэтому использовать этот компонент или нет, решать вам. Просто без него, вам придется в ручную делать различные проверки данных.

    На примере Yii2, там работа с формами достаточно гибкая, есть полная интеграция в бутсрап, которая рисует все поля за вас в пару строк, если нужно кастомизировать вне бутстрапа, можно использовать более гибкий вариант, но кода будет больше.

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

    В общем в вашем случае смотрите по ситуации. Если что-то очень кастомное, то пишите сами, но кода будет больше, можно написать свой компонент для форм для конкретного проекта, а если задачи достаточно стандартные, лучше использовать готовое решение фраэмворка.
    Ответ написан
    5 комментариев
  • Как сделать авторизацию клиента "как у Habrahabr"?

    HoHsi
    @HoHsi Автор вопроса
    Под личные поиски:
    =======================
    *Данный метод называется SSO
    Ответ написан
    Комментировать
  • Какие символы разрешить в логине (имени пользователя)?

    @Akela_wolf
    Extreme Programmer
    Я бы разрешил латинские и русские буквы (если сайт включает русскоязычную аудиторию, конечно), пробел, дефис и подчеркивание, а также цифры и спецсимволы. Минимальная длина - 3-4 символа, максимальная длина - на ваше усмотрение (12-16 символов или даже больше).

    Логин регистронезависимый (то есть star guardian и Star Guardian - одинаковый логин). Также сделал бы список запрещенных логинов, таких как root, admin, moderator, support, helpdesk и т.п., которые можно использовать для социальной инженерии, чтобы представиться кем-либо из администрации сайта.
    Ответ написан
    Комментировать
  • Какие символы разрешить в логине (имени пользователя)?

    trevoga_su
    @trevoga_su
    xpoint.ru/forums/programming/theory_algorythms/thr...
    xpoint.ru/forums/internet/theory/thread/22534.xhtml

    никакого стандарта на это нет. упор в любых проверках делается на то, бы пользователь не вводил логин/пароль в стиле ^vasya_$123#*& а потом забывал свои логины/пароли.
    стандартного алфавита a-z0-9 с парой символов для разделения (- или _) вполне хватит на много миллионов пользователей.
    Ответ написан
    Комментировать
  • Как урезать свой перфекционизм?

    isqua
    @isqua
    Научу HTML, CSS, JS, BEM и Git
    Чтобы перестать делать лучше то, что ещё не сделано до конца, нужно понять одну простую истину: Запущенный проект лучше, чем не запущенный.

    Давайте потренируемся:
    • Что лучше: запущенный проект с несжатыми стилями или незапущенный со сжатыми?
    • Что лучше: не запущенный проект с десятью страницами или запущенный с тремя?
    • Что лучше: запущенный проект c jQuery или не запущенный без jQuery?


    Надеюсь, вы смогли выбрать! Как узнать, что пора запустить проект? (Под запуском я имею в виду «показать людям». Например, если вы решили написать библиотеку, давайте считать «проект запущенным», если вы выложили её на гитхаб) Нужно прикинуть, сколько времени вам надо на разработку и умножить на два. Если получилось больше двух недель, то стоит разбить проект на части и прикинуть так про каждую часть. Соответственно, ставите дедлайны.

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

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

    Удачи!
    Ответ написан
    4 комментария