• Почему нельзя переопределить construct при наследовании?

    kiff86: так а каким образом он будет обладать родительской функцией создания новых объектов, если ты эту функцию у потомков "отключаешь"? А изначальная цель public методов в том, что они доступны для вызова за пределами класса, а не в том, чтобы их переопределять. Это скорее следствие. Тем более что переопределять ты можешь и protected методы. А доступность ни в коем случае не должна меняться (и да, не имеет значения, является ли функция конструктором или нет. Конструктор отличается от обычной функции по сути только способом вызова), иначе в какой-то момент при попытке вызвать некий метод, который определен в родителе, но скрыт в потомке (или при попытке создания объекта) у тебя будет ошибка (если допустить, что такой код съест интерпретатор). В итоге становится невозможно применение полиморфизма.
  • Нужен ли JavaScript для работы с фреймворками?

    Александр Вульф: ну это уже какой-то довольно экзотический пример) Крайне мало таких людей, которые для создания веб-приложения/сайта на ноде пишут что-то подобное самостоятельно.
  • Нужен ли JavaScript для работы с фреймворками?

    Александр Вульф: единственное, почему так действительно можно сказать - это то, сколько смежных моментов есть у сервера (собственно, сервер, база данных, кеш, хранилище сессий и т.п.). А так - все тот же код: тоже асинхронный, тоже событийный, тоже есть модули на все случаи жизни.
    Вряд ли, например, выборка из базы сложнее, чем с помощью jQuery или даже какого-нибудь Angular.js отправить простейший запрос к серверу. Причем если и в том, и в другом случае использовать чистый ламповый ванильный JavaScript, то можно поспорить о сложности) Но, опять таки, в случае с сервером нужно дополнительно знать, как построить запрос к данной СУБД. Сложность сравнима на мой взгляд.
  • Нужен ли JavaScript для работы с фреймворками?

    А какая по сути разница, с чего начинать? Сервер не сложнее клиента, там просто другая среда. Если уж человек начинает с нуля, то разницы никакой.
  • Что лучше, написать собственный код для галереи или использовать уже существующие библиотеки?

    webdisigner: Пройти мимо можно было, но мне хотелось написать :) Я хотел донести простую мысль - "какой вопрос - такой ответ". Возможно, не донес. Тогда это мой промах, и я постараюсь пояснить:

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

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

    m325: потому что ты в setInterval не передаешь функцию rotated, а передаешь результат ее выполнения. Нужно не setInterval(rotated(), ...), а setInterval(rotated/* тут нет скобок */, ...).
  • Пройтись по каждому элементу добавляя класс с интервалом?

    m325: Попал только с each)
    i - просто индекс элемента, порядковый номер, начинающийся с нуля
    el - очередной элемент DOM, над которым мы совершаем какие-то действия.

    А мучать вопросами меня бессмысленно. Дело не в том, что я не хочу отвечать, а в том, что я не смогу дать должного объема знаний и, что не менее важно, опыта. Ты же, очевидно, не обладаешь ни тем, ни другим, поэтому лучше бы начать с чего-то более фундаментального, чем вывод слайдера на странице. С ходу могу порекомендовать книгу Флэнагана (JavaScript The Definitive Guide она вроде бы называется, есть на русском).
  • Пройтись по каждому элементу добавляя класс с интервалом?

    Давай я тебе просто дам решение, так как ты пока слишком мало знаешь, раз такие вопросы задаешь, но разобраться в этом всем тебе все равно нужно будет)
    var lastEl;
    $('.container_bb').each(function(i, el) {
        setTimeout(function() {
            if (lastEl) lastEl.removeClass('show');
            lastEl = $(el).addClass('show');
        }, i * 5000);
    });
  • Пройтись по каждому элементу добавляя класс с интервалом?

    m325: Можно - запоминай просто последний элемент в отдельную переменную и убирай у него класс.
  • Можно ли соваться на Одеск с таким уровнем работы(фронтэнд)?

    Emptyform: Спасибо! Приятно, что все не зря)

    Несколько строк в js - это образно, конечно. Если какой-то элементарный пример, то вот

    var slides = $('.slides'), current = slides.filter('.current').index(), time = 1000;
    setInterval(function() {
    
    slides.eq(current).removeClass('current');
    ++current;
    if (current >= slides.length) current = 0;
    slides.eq(current).addClass('current');
    
    }, time);
    // все анимации - в стилях


    Потом просто наращиваешь и делаешь более универсальным свой код. Скажем, добавить функционал для перелистывания - задача 10-15 минут один раз, далее используешь свои наработки. Вряд ли можно считать более выгодным (с точки зрения затрат по времени и количества лишнего кода) использование плагина.

    В итоге - постепенно учишься, заодно делаешь для себя наработки, которые улучшаешь по ходу получения новых знаний и опыта, экономишь время. Короче, сплошные плюсы. Понятно, что подход не является серебряной пулей для абсолютно любых проектов (и это тоже очень важно понять), но во многих случаях он выигрывает.
  • Можно ли использовать абсолютное позиционирование для верстки layout'а?

    Николай Марков: Ну вообще, если высота футера заранее известна, то абсолют и в этом случае подойдет. А если нет, то можно использовать js (опять-таки, если это в итоге будет оптимальным решением).
  • Почему не отправляется сабмит?

    9. Проверять не $_POST['submit'], а $_SERVER['REQUEST_METHOD'] != 'POST'.
    10. Добавить limit 1 в запрос
    11. Изменить условие elseif(mysqli_num_rows($query) == 0) на простой else
    12. При неудачной проверке делать редирект на ту же страницу (чтобы избежать перезагрузки POST запроса), сообщение об ошибке запоминать в $_SESSION и выводить над формой, например
  • Почему не отправляется сабмит?

    тогда уж проверять надо $_SERVER['REQUEST_METHOD'] == 'POST', а не скрытое поле.
  • Что не так с Node.js?

    С плюсами я и не пытаюсь сравнивать, я только сказал, что есть модули, которые написаны на сях. А с питоном некоторые тесты показывают, что нода быстрее. Просто вбей в гугл "python vs node.js performance" и сам убедишься. Я не утверждаю, что нода однозначно быстрее чего-то, но то, что производительность ее слабое место, сказать тоже нельзя.

    Одна инструкция yield не делает язык асинхронным. Async и await в C# - это, считай, синтаксический сахар для событий.

    "Никто" слишком громкое слово. Многие любят JavaScript таким какой он есть. Не все его понимают после языков вроде C#, Java, Python, Ruby. Оно и понятно, JS местами фундаментально отличается от них, при этом синтаксически оставаясь похожим, что может запутать. Синтаксический сахар для JS как раз призван сделать его более привычным для тех, кто перешел с других языков. Не нужно путать это с бедностью языка. Я согласен, что JS не идеален, но раз уж на то пошло, то в питоне this зачем-то передается как первый параметр в каждый метод класса, это ли не извращение?) А ES6 решит чуть ли не все проблемы с JS, в частности добавит сахара для определения класса, сделает немногословные конструкции для анонимных функций.

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

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

    И что за библиотеки к экспрессу ты писал?
  • Что не так с Node.js?

    un1t: Производительность у ноды хороша. Я бы не брался ее вот так вот просто с чем-то сравнивать, так как есть куча тестов с противоречивыми результатами, но нода во многих из них выглядит достаточно выгодно, в частности и по сравнению с python. Но все зависит от задач.
    И я не понимаю, почему ты упорно пытаешься выставлять ноду как плохую реализацию асинхронного подхода, тогда как JS всегда был и будет языком, на котором все делается асинхронно и делается, как показывает практика, неплохо. К тому же, ничто не стоит на месте и с выходом версии, поддерживающей ES6, все станет только лучше.
    Выбор библиотек тоже становится богаче с каждым днем, многие из них реализованы на сях. Но нода молодая технология, ей еще нужно догонять конкурентов, это да. Хотя, например, для фронтенд разработки на текущий момент инфраструктура ноды, пожалуй, самая богатая.
    А что за библиотеки для express?
  • Что не так с Node.js?

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