• На каком фреймворке писать онлайн чат?

    kleinmaximus
    @kleinmaximus
    Senior Full-stack Javascript Developer
    Использование сокетов и пр. никак не связано ни с Vue, ни с Реактом - и тот и другой отвечают только за слой представления. Делайте на том, что лучше знаете. Я бы выбрал Vue.
    Ответ написан
  • Кто писал свою CMS?

    Epsiloncool
    @Epsiloncool
    Программер, веб-девелопер, гейм-девелопер
    Да, писал на базе PHP. Основной идеей была модульность и автоматическое отслеживание изменений.

    1) Какой системой вдохновлялись или брали за образец?

    Никакой, считал все остальные CMS "недосистемами", недостойными подражания.

    2) Писали ли к ней инсталятор или предполагался другой способ установки?

    Нет, предполагалось, что это PHP скрипт, который начинает работать сразу после установки.

    3) Какой использовали визуальный редактор для админки? Один из 2 известных, что-то другое, или свой?

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

    4) Была ли у неё какая-то специализация - магазины, визитки, лендинги, что-то ещё?

    Нет, модульность подразумевала полную универсальность.

    5) Разделяли ли ядро и дополнительные модули?

    Да, ядро было небольшим, весь функционал был (предполагался) в модулях.

    6) Предусматривалась ли какая-то система шаблонов? (юзали ли шаблонизатор или на php)?

    Да, в качестве шаблонизатора для страниц можно было использовать plain-php или smarty-шаблонизацию.

    - Ну и если есть ссылки на репозитории кидайте кому не стыдно показать если в открытом доступе у вас.

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

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

    Нужно было просто посмотреть существующие CMS и использовать одну из них. Жаль потерянных лет.
    Ответ написан
  • Какой фреймворк выбрать?

    Непонятно, если вы намастрячились использовать Laravel (что, скорее всего, лучший выбор в мире PHP), зачем вы что-то ещё выбираете?
    Ответ написан
  • Можно не использовать шаблонизатор для NodeJS?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    > А как происходит дело в NodeJS ?
    Прими за исходную: работаешь со строкой, которую записываешь в body ответа. Не больше и не меньше. Да, можно сделать эту строку в виде "< html >< body >" + myContentVarHere + "< /body >< /html >", но зачем? Есть популярные шаблонизаторы: Jade, EJS, JQtemplates используй их.

    @Fesor
    > В целом PHP плохой шаблонизатор.
    Не согласен. PHP - stateless язык, который вполне себе ок шаблонизатор. Если верить википедии: PHP: Hypertext Preprocessor. Да, есть twig, да есть smarty, но эти шаблонизаторы только пародируют PHP. Результат их работы - это тот же PHP код, только кэшированный.

    > Пока у людей пишущих на php появляются такие мысли, над php будут продолжать смеяться.
    Над нами php-dev смеются потому что:
    1. Динамическая типизация. 5 + "5abc" + "abc5" по хорошему должно давать исключение в стиле "парень меняй драг диллера, это какое-то УГ!".
    2. Не консистентное API. С тем же if (!strpos(...)) наверняка хлебнули горя.
    3. Наличие миллиона стандартов. Да, есть PSR, расскажите о нем автору, знающему кохану.
    4. Что на счет scalar type hinting? Всего 20 лет прошло как в 7-ке это таки решили внедрить, и то с ограничениями на вывод.
    5. Что на счет демонов? Да, я знаю, можно, да я знаю как, но №;%: есть языки для этого приспособленные и php в их число не входит, это stateless язык!

    Я отошел от темы шаблонизаторов.
    Чем принципиально {{someVar}} лучше <?= $someVar; ?>, учитывая, что шаблон в любом случае приведется к нейтивному коду + за кэшируется?
    Ответ написан
  • Впечатления от sails.js?

    ColCh
    @ColCh
    Веб разработчик
    Я использовал Sails. И я перешел от него обратно к Express (и же Koa сюда же). Почему? Он слишком много работы берет на себя.

    Что мне делать, если я хочу использовать LiveScript \ JS ES6 (Babel) в качестве языка?
    Что мне делать, если я не использую не Grunt, а Webpack?

    В общем, он слишком монолитный. И слишком медленно развивается... По началу было прикольно и весело, но потом разонравился.
    Ответ написан
  • Как реализовать очень быстрый REST API на php вкупе с фреймворком?

    @FanatPHP
    Чебуратор тега PHP
    Что за шутки? Откуда цифра в 300 RPS?
    К РНР там гири привязывали, что ли?
    Какова доля РНР? Где тесты, показывающие, что бутылочное горлышко - РНР фреймворк, а не, скажем, база?
    Ответ написан
  • Можно ли обойтись одним запросом?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Мне кажется наиболее рациональное решение - выбрать все данные из Вашей таблицы за нужный период, и за 1 проход цикла в любом ЯП составить требуемую табличку.
    Ответ написан
  • Есть ли такие ресурсы на которых разбирают базовые проблемы вёрстки?

    @tef
    Вёрстка, это всегда проблема. Потому что html и css это одна большая проблема сама по себе.
    Всё что вы перечислили это мейнстримовый абстрактный кич. Я бы вообще не стал рассматривать это в отдельности, как что-то реально существующее. Всё что вам нудно это усвоить основные базовые понятия: строчный и блочный элемент, поток, позиционирование, z-index. А дальше уже делаете дизайн какой захотите с паралаксами, сетками и тд.
    По поводу ресурсов где рассматриваются проблемы вёрстки. Скажите, зачем вам чужие проблемы? Их на самом деле столько, что пером не описать.
    Просто верстайте. И когда натолкнётесь на проблему, либо изначально задумаете какую-нибудь конструкцию, которую не знаете как сверстать, то там уже можно будет и погуглить, почитать или задать конкретный вопрос.
    Всё дело в том, что сама по себе технология html и css, да и js, не идеальна. Причём далеко не идеальна. Скажем если мы возьмём идеальность за 100%, то нынешняя ситуация будет где-то процентов на 15-20, ну максимум 30.
    Ответ написан
  • Как добавить класс кнопке при hover?

    paradokso
    @paradokso
    Начинающий фронт-эндер
    в вашем коде во-первых, не хватает одной кавычки после имг. Во-вторых, ваш код гласит: "При наведении на элемент с классом контент с каждым изображением делаем Х". И зачем вы ховер в ховере вызываете?

    Уж лучше бы вы сделали стили для кнопки, которые включаются только при наведении на изоражение, аля: img:hover ~ button { /* стили*/}
    Ответ написан
  • Как лучше задать структуру для данных разных типов?

    @vsuhachev
    Наиболее подходящий вариант нельзя посоветовать не зная ваших объемов данных и того как вы планируете это использовать.

    Если время поиска не критично, типов данных мало, нужно простое и переносимое решение, то я бы посоветовал вариант 1 с сериализацией различных типов в строку.

    Вариант с постгревыми json/jsonb добавляет гибкости/производительности, но в json простые типы это число, строка и булев. Даты и прочих типов там нету. Для jsonb поддерживаются индексы. Это решение означает жесткую привязку к PG.

    Есть еще вариант похожий на 1, но с заданием разнотипных колонок и хранением в каждом свойстве его типа. Запросы будут выглядет как-то так
    SELECT * FROM profile_field_values
    WHERE 
      (property_field="дата рождения"
      and value_type="date" and value_date > ?)
    and
      (property_field="размер ноги"
      and value_type="integer" and value_integer < ?)

    По скорости вы выиграете, но получите сложности с реализацией и интеграцией всего этого в рельсы.

    Еще есть вариация на тему решения N3 - внешний сервис для поиска: Sphinx, Solr, etc...
    Ответ написан
  • Почему подавляющее большинство проектов до сих пор делают на CMS, а не на фреймворках?

    killmeslow
    @killmeslow
    WE
    1-ый вариант = Продаешь 10 битриксов в месяц
    2ой вариант = 0,5 сайтов на фреймворке в месяц
    Ответ написан
  • Что такое Less и Sass?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Лень двигатель прогресса. Хороший пример - принцип DRY - Don't repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

    Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:
    • организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
    • Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
    • Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
    • Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.


    Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

    • У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
    • С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
    • Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
    • Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.


    Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

    Далее уже шли какие-то модификации дальнейшие, вроде того же Stylus, где синтаксис упростили просто до нельзя.

    Личное мнение. На сегодняшний день я не вижу смысла использовать чистый CSS хоть на малых хоть на больших проектах. Вот вообще никакого.
    Ответ написан
  • Laravel или Yii - на чем лучше на данный момент начинать разработку сайта? В чем отличия?

    OnYourLips
    @OnYourLips
    Тут будут хвалить то, чем сами пользуются. В России популярнее Yii.
    Но я рекомендую попробовать оба, чтобы самому принять решение (в пользу Laravel) :)
    Ответ написан
  • Какое ваше мнение о Drupal?

    kalabro
    @kalabro
    Во-первых, я полностью согласна с @andead. Спасибо за отличный ответ, man!

    Позволю себе небольшие дополнения как битрикс-разработчик.
    1) Почему считается, что друпал сложно темизировать?

    Наговнокодить прямо в шаблоне большого ума не надо.

    Правильно темизировать и битрикс нелегко. Другой разговор, что оставить в шаблоне друпала $_SESSION в 100 раз хуже, чем оставить тоже самое в шаблоне битрикса. Процесс темизации и той, и другой CMS должен контролировать понимающий систему программист.

    2) Действительно ли друпал очень медленный? Медленней ли он того же битрикса?

    В битриксе каждый «блок» (часть страницы) можно независимо закешировать на основе идентификаторов групп пользователя, значений фильтра каталога и чего угодно. Обёртка $this->StartResultCache() как отче наш в любом коде и в стандартных компонентах из коробки. В итоге страница быстро собирается из кешей для людей с сессией, авторизацией и т.д. В друпале нужно стремиться к этому же, но для этого приходится писать свои кеш-плагины к Panels, шаманить с Expire и даже ESI и понимать всякие тонкости работы друпал-кеширования (drupalace.ru/tags/cache).
    В битриксе всякие панели производительности и мониторы качества из коробки. В друпале это "энтерпрайз"-услуга :)

    3) Этот вопрос к тем, кто имел дело с интернет-магазинами на друпале: стоит ли вообще делать на нем интернет-магазины? Мое мнение таково, что удобнее на битриксе

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

    5) Есть люди, которые сравнивают инфоблоки битрикса с нодами друпала. Как по мне - ноды в кипе с таксономией в пух и прах разбивают инфоблоки. У кого другое мнение и почему?

    Инфоблоки гораздо мощнее просто нод из коробки. Опыт работы с тем и другим >2 лет. Сравнивать можно сущности в друпале и инфоблоки в битриксе. Вот здесь уже друпал (вместе с Entity API, конечно) смотрится гораздо серьёзней и гибче. Битрикс выглядит глупо, когда нужно что-то странное, друпал же позволяет воротить что угодно.

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

    Webform/Entityforms гораздо проще битрикса в плане собственно форм, просто надо привыкнуть. А вот email-подсистема в друпале послабее. В друпале если что-то делают, то только со вселенским размахом :) Как пример, Message Stack :)

    Действительно ли вам показался друпал сложным в освоении (как программистам, разумеется) в сравнении с другими системами?

    Спустя 2 года я нахожу что-то новое и очень крутое в друпале или благодаря друпалу. Не могу ответить на этот вопрос, т.к. продолжаю учиться :)

    Как вы темизировали хлебные крошки и постраничную навигацию?

    Пользуясь случаем, пропиарю модуль Path Breadcrumbs, ко-мейнтейнером которого гордо являюсь. В нём переопределяется theme_breadcrumb() для добавления поддержки Rich Snippets: drupalcode.org/project/path_breadcrumbs.git/blob/c...
    С помощью того же hook_theme_registry_alter() вы можете заставить крошки темизироваться через файл, а не функцию.

    Друпал люблю больше из-за качества кода и сообщества.
    Ответ написан
  • Какое ваше мнение о Drupal?

    andead
    @andead
    друпал девелопер, фрилансер
    1) Почему считается, что друпал сложно темизировать?


    Друпал сложно правильно темизировать. Достаточно тяжело понять всю систему из theme функций/файлов, preprocess/process функций, theme sugestions, render массивов, различных pre_build/after_build/post_build калбаков, theme врапперов, кэширования и т.п. Наговнокодить прямо в шаблоне большого ума не надо.

    2) Действительно ли друпал очень медленный?


    Друпал, как и любая другая CMS, медленнее узкоспециализированных систем в виду своей избыточности. Голый друпал 7 на средней машине генерит странички за ~100 ms. Решайте сами, это очень медленно или нет.

    3) Этот вопрос к тем, кто имел дело с интернет-магазинами на друпале: стоит ли вообще делать на нем интернет-магазины?


    Если нет хорошего скила или денег на соответствующего разработчика, то не стоит.

    4) Если вы имели дело с формами на сайте, подскажите, как лучше их реализовать, чтобы получился некий аналог форм в битриксе


    Популярно — Webform. Правильно — Entityforms.

    6) Действительно ли вам показался друпал сложным в освоении (как программистам, разумеется) в сравнении с другими системами?


    Нет. Какой-нибудь Symfony 2 на порядок сложнее будет.

    7) Как вы темизировали хлебные крошки и постраничную навигацию? На мой взгляд, разработчики друпала были сильно не правы, не реализовав их через файлы шаблонов.


    Они реализованы theme функциями theme_breadcrumb и theme_pager. Функции мало чем отличаются от шаблонов — их так же можно переопределять, процессить и использовать через theme('...').
    Ответ написан