• Для чего в БЭМ т.н. "первый уровень вложенности", то есть "блок__элемент"?

    mrusklon
    @mrusklon
    Не получается? Яростно гугли!
    мое имхо , бэм нужен только для того чтоб любой блок можно было вырезать и вставить в любое место и не сломать при этом сss , с вашим примером:
    .calculator__button {}
    а если будет так и кнопок у вас 10 вариаций , когда перенесете , возможно будут сложности.
    .calculator .button

    в целом вижу смысл в этой технологии только в ультра больших проектах и сайтах в 100500 страниц ручной верстки которые постоянно меняются.
    Ответ написан
    1 комментарий
  • Насколько сейчас актуальна поддержка браузеров без поддержки Javascript

    @1nd1go
    Мое мнение такое, что базовый функционал должен быть предоставлен без работающего JS. Рушечки для голосования и т.п. можно и пропустить. Главное чтобы, когда человек заходил без JS'а, сайт не падал, а продолжал работать и выдавал что-то вразумительное (а еще лучше не показывал того, что без JS не работает).
    Ответ написан
    2 комментария
  • Какую операционную систему использовать для разработки на Python?

    @AVKor
    Да.
    Минусов нет.
    Debian.
    Сочетается наилучшим образом со всем, что не относится к "решениям MS".
    Ответ написан
    Комментировать
  • Какую операционную систему использовать для разработки на Python?

    @vanillathunder
    Ставь linux mint перейти с windows будет проще всего.
    Ответ написан
    Комментировать
  • Почему говорят что jquery не нужен?

    ThunderCat
    @ThunderCat Куратор тега JavaScript
    {PHP, MySql, HTML, JS, CSS} developer
    Скрипач не нужен, родной (с)
    Аргументы против jq:
    - современные браузеры достаточно хорошо поддерживают единый синтаксис современного екмаскрипт(native js)(на самом деле нет).
    - сторонняя библиотека, работает медленнее чем натив и в основном состоит из с-сахара (тоже не совсем правда)
    - тащить еще один ресурс весом от 64 кб до 200 кб, еще и со сторонних ресурсов замедляет загрузку( правда, но бред)
    Аргументы за:
    - Современные браузеры как и всегда один другого "ровнее", всегда есть косяки и "нюансы", на которые еще и попадаешь обычно в самый неподходящий момент, в жк обычно все работает одинаково везде, ну или лучше чем в нативе.
    - В жк реализована куча плюшек в 1 функцию которые в нативе занимают "многабукав", не каждый начинающий напишет их правильно, да и профи не все напишут оптимально, уверен что в большинстве случаев написанный нативом функционал будет хуже аналога из жк.
    - размер мин пакета жк 64 кб, и все они лежат на быстрых цдн серверах. Думаю это последнее что может повлиять на скорость загрузки страницы.
    - есть ОГРОМНОЕ количество скриптов написанных с учетом жк, не использовать их глупо, писать свой велосипед - вообще только в целях обучения(не берем крайние случаи когда плагин писал упоротый пингвин).
    - Синтаксис и краткость записи - вообще вне конкуренции.
    - Старые браузеры никто не отменял, часто заказчик требует чтобы работало в ие8, натив не канает или доставляет море анального удовольствия.
    Вывод: Если ты крут в жс, еще и работаешь в ангуларе/ещечетамдляфронта и тебе нужно сделать 2 действия в очень современных браузерах - jquery не нужен, и ты это сам знаешь. Если слова ангулар, вуе и проч для тебя не больше чем шум листвы за окном, а навесить плагинов и эффектов нужно - jquery наше все.

    UPD: для всех кто там отписался а ля "в связи (...), исчезновением проблемы совместимости со старыми IE (что и было основным назначением jQuery)." - свежачок
    Ответ написан
    4 комментария
  • Интернет-магазин на Falcon и VueJS?

    neuotq
    @neuotq
    Прокрастинация
    Почему Falcon, а не Django? Хочешь построить микросервисную архитектуру? Иначе все же лучше взять Django, который сократит велосипедостроение, многие вещи уже там сделаны.
    Ну и самое главное, обычно для интернет магазинов важен момент с SEO, а значит если javascript не синхронный, то скорее всего будут некоторые трудности. А значит для части страниц нужно использовать рендер на стороне сервера.
    А так, конечно же можно сделать интерактивное приложение магазин, никаких других больших проблем быть не должно.
    Ответ написан
    4 комментария
  • Интернет-магазин на Falcon и VueJS?

    copist
    @copist
    Empower people to give
    Описанная тобой схема, при которой приложение разбито на две части: клиентское на JS и серверное, которые обмениваются данными через открытое API по HTTP - называется Rich Internet Application или Single Page Application. Реализуется на любом стеке. PHP/Python/NodeJS/Ruby/Go/C#/Java и др. с одной стороны и Vue/Angular/Meteor/React и др. (тыщи их) с другой стороны.

    (Упомянуя схема "микросервисная архитектура" по сути декомпозиция серверной части на незаввисимые модули с открытым API, совсем не обязательно реализовано через HTTP. Частный случай SPA/RIA.)

    Проблему назову одну. Только она не даёт покоя. Она выматывает душу, нервы и кошелёк.

    Интернет магазин должен быть открыт для индексации поисковым ботам, а HTML генерится в runtime на JavsScript. Только Google умеет выполнять JS, и то весьма посредственно. Остальные вообще JS не трогают. Есть два решения:
    для индексации сразу рисовать HTML на стороне сервера
    или снимать "отпечатки" HTML c приложения через виртуальный браузер, что сбоит

    Отрисовка HTML на стороне сервера (server side render) может быть реализована тремя способами:
    * подменять выдачу через серверный язык программирования, то есть вместо шаблонизации в Vue рисовать в Falcon - блин, две шаблонизации, две логики работы с данными (через AJAX и напрямую из базы)
    * имитировать исполнение JS на сервере (хм, это возможно опять же несколькими способами) - тут вообще танцы с бубном
    * отказаться от PHP/Python/Ruby и др. в пользу NodeJS и изоморфного фрейморка, например MeteorJS или VueJS (Nuxt)

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

    P.S. Про Google: проверено, глючит в тех местах, где клиентский JS начинает подкачку данных через HTTP - гугль обрывает рендеринг и в поисковом индексе лежат пустые HTML страницы. Толку от них никакого.
    P.P.S Снятие "отпечатков" HTML для SPA можно через специальные сервисы (prerender.io или brombone.com) или сделать самостоятельно, например через PhantomJS или Electron. В любом случае для проекта с десятком тысяч страниц это расходы на оплату сервиса, либо на мощный сервер. И электрон и фантом виснут, а HTML довольно большие и со временем забивают диск/базу. Опят же надо не забывать про то, что страницы требуют подгрузки данных через AJAX, надо чуть подождать.
    Пример: web-mastery-gauge.ru сделан на Angular, для поисковиков HTML отрисовывается через prerender.io - для проекта с 15 страницами это вообще никакой сложности не вызывает.
    P.P.P.S. SPA просто идеально для реализации той части пользовательского интерфейса, которая не индексируется поисковыми ботами. Например, то доступно только авторизованным пользователям. В этом случае не требуется server side render и 75% проблем отпадают. В том же интернет-магазине может быть админка - её можно сделать на VueJS.
    Ответ написан
    6 комментариев
  • Есть ли смысл использовать формы?

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

    teke_teke
    @teke_teke
    programador
    делайте на формах. не пихайте js везде, где попало. рендерите страницу на сервере. отдавайте клиенту готовую.

    javascript может быть отключен, да. более того, мне кажется, сейчас его даже чаще отключают или блокируют js скрипты и запросы, потому как больше людей становится осведомлёнными про уязвимости и потерю приватности при включенном js.
    Ответ написан
    4 комментария
  • Насколько сейчас актуальна поддержка браузеров без поддержки Javascript

    Pr0Ger
    @Pr0Ger
    я лично против сайтов, которые вешают огромный баннер, что включите JS или ничего не увидете
    базовый функционал должен быть доступен и без JS, т.е. прочитать тот материал из-за которого пришел на сайт; опционально можно показать табличку, что часть фич не будет доступно (хотя многие кто ставят NoScript это и так понимают)
    Ответ написан
    5 комментариев
  • Насколько сейчас актуальна поддержка браузеров без поддержки Javascript

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

    А вот когда такого предупреждения нет, то очень беситпосетителю непонятно, что то, что он видит в окне браузера вовсе не то, что разработчик хочет ему показать.
    Ответ написан
    Комментировать
  • Насколько сейчас актуальна поддержка браузеров без поддержки Javascript

    shurshur
    @shurshur
    Сисадмин, просто сисадмин...
    Не включаю JS на твиттере. Мне неинтересно, чтобы браузер блокировал мне правую кнопку мыши, чтобы средняя работала как левая и чтобы я не мог открыть нужное мне в отдельной вкладке. Кто они такие, чтобы мешать мне пользоваться интернетом так, как я привык?

    Это так, лирика. Но всё равно — сайт по-хорошему должен работать и без JS. Уж по крайней мере если на сайте, например, опубликованы тексты некоторой тематики — их должен без труда читать любой. Вот какие-нибудь закладки-репосты-комментарии можно считать достаточно вторичными элементами функциональности, чтобы забить на их поддержку.
    Ответ написан
    Комментировать
  • Какая должна быть правильная длина логина?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Логин: 3-20 знаков, любые символы алфавита (выбранного пользователем) языка сайта и/или цифры и/или один из знаков: "-" или "_".
    Также, можете использовать E-MAIL для авторизации в поле логина,
    НО ПОМНИТЕ!: E-MAIL != LOGIN
    Пароль: от 8-50 знаков, любые символы, обязательно содержащий не менее ДВУХ ЛЮБЫХ знаков препинания и/или знаков цифр.
    Например:
    Логин: Дикий_Макс, Fox, Turbo-500
    Пароли: "soft_342" или "DEMO-927" или "b@ck5pace" или "h@br@h@br"
    ......подходят под требования.
    Ответ написан
    2 комментария
  • TOR. Как создать поддомен в .onion?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Комментировать
  • Что с pip'ом в Python?

    LazyTalent
    @LazyTalent
    Data Engineer, Freelancer
    Прежде, чем сидеть грустить, может быть стоило изучить инструменты, которыми пользуешься?
    Ответ написан
    1 комментарий
  • Почему все хотят django?

    @dustyattic
    Всем хорош Django, все у него есть, но...
    Django - это коробочный продукт, со всеми достоинствами и недостатками, присущими коробочным продуктам. То есть внутри большой коробки, называемой Django, есть много других коробочек, содержимое которых прекрасно состыковано с самим продуктом и с другими коробочками. Поэтому разработчик на Django чувствует себя вольготно. А если у него возникает проблема, то большое комьюнити всегда поможет.
    Я разработал на Django только один проект. Возможно, будь проект простым, я до сих пор бы использовал Django. Но проект оказался неожиданно сложным. Написание кода для обработки данных из некоторого количества таблиц с довольно запутанными связями показало мне, что у Django, несмотря на его популярность, совершенно никудышный ORM. Используя Django, я половину обращений к таблицам реализовывал в чистом SQL, а затем стыковал результаты с данными полученными с помощью ORM. У меня все получилось. Но осадок остался. Поэтому следующую версию того же проекта, и все последующие тоже, я написал на Flask, используя в качестве ORM небезызвестный SQLAlchemy.
    Я не жалею времени, потраченного на изучение Django. Это хороший опыт. Те, кто используют Django, чувствуют себя защищенными. Они часть большого дружного сообщества, где можно найти любую поддержку.
    Но я также не жалею, что я ушел от Django. У Django вся магия ( регистрация, авторизация, работа с сессиями и многое-многое другое) спрятана под капотом, я просто подключал компоненты и использовал их. Используя Django, я делал многие вещи автоматически, совершенно не задаваясь вопросом как эти вещи работают. Уйдя от Django, я лучше стал понимать то, чем занимаюсь каждый день.
    Можете мне поверить на слово, на Flask-е возможно писать очень большие проекты, с большим количеством кода. При этом реализация всей магии ложится на Вас. Это просто вопрос доверия. Используя Django, Вы доверяете всю магию Django, не используя его, Вы доверяете всю магию себе.
    Ответ написан
    Комментировать
  • Какие алгоритмы нужно знать веб разработчику?

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

    В веб-разработке важно чтобы запрос к серверу занял как можно меньше времени. Для этого нужно быстро обратиться к БД, что-то посчитать и вернуть ответ. Пользователь не любит ждать. Порой нужно использовать техники кеширования данных и некоторые другие оптимизации.
    По-моему, основными факторами задержки являются:
    1. неоптимальные запросы к БД
    2. неоптимальный выбор структур данных и, как следствие, понижение скорости работы и повышенные требования к памяти
    3. повторяющиеся операции в коде
    4. блокирующие операции в коде
    5. неоптимальная отдача статического контента сервером
    Ответ написан
    Комментировать
  • Хостинг сайтов на Django и как определится чего именно я хочу?

    @deliro
    Django обычно хостят на VPS. Это виртуальный изолированный сервер. Провайдеров тысячи: Digital Ocean, vultr, linode, simple cloud и т.д. Грубо говоря, это равносильно тому, что ты установишь себе на ПК, допустим, чистый Ubuntu Server и сам всё настроишь. Никакие "админы" ничего с ним не сделают.

    Как понять сколько людей на нем сможет тусить

    Нагрузочное тестирование + реальная статистика + профилирование. Всё зависит от кода и его качества. И это последнее, о чём надо думать при запуске. Вот как будет большая посещаемость — тогда и будешь оптимизировать.
    Ответ написан
    Комментировать
  • Как округлить произвольное десятичное число без встроенных функций round и модуля math?

    @nirvimel
    Дело в том, что в математике не существует десятичных чисел.
    Существуют: натуральные, целые, рациональные, вещественные, комплексные, и.т.д. Но десятичных чисел НЕТ!
    Десятичная система счисления - это лишь форма записи для восприятия чисел человеком.
    Но сами числа не волнуют разные формы записи, в которой человек их может (или не может) воспринимать.
    В вычислительной технике все числа физически хранятся и обрабатываются в двоичной форме. Но это опять же только форма записи, это не делает сами числа "двоичными" (будто какими-то особенными). Десятичная система счисления в вычислительной технике используется кране редко. К вашему случаю это 100% не имеет никакого отношения, как и ко всем языкам высокого уровня (это число ассемблерные заморочки, которые были актуальны (минимум) лет тридцать пять назад).

    Теперь поговорим об округлении вещественных чисел:
    Дробная часть вещественного числа равна остатку от его деления на единицу. Целая часть соответственно равна разности самого числа и его дробной части.
    Чтобы сохранить определенное количество разрядов после запятой число следует сначала сдвинуть влево на соответствующее число разрядов, взять его целую часть и сдвинуть обратно в право на столько же разрядов. Сдвиг влево/вправо реализуется умножением/делением на основание системы счисления, возведенное в степень равную количеству сдвигаемых разрядов.
    Ответ написан
    Комментировать