Ответы пользователя по тегу Веб-разработка
  • Как разделить поток на несколько файлов в Gulp.js?

    voidnugget
    @voidnugget
    Программист-прагматик
    var merge = require('merge-stream');
    gulp.task('sass-global', function () {
      var merged = merge();
      global_css.forEach((entry) => {
        merged.add(gulp.src(entry)
          .pipe(plugins.plumber({errorHandler: plugins.notify.onError("<%= error.message %>")}))
          .pipe(plugins.sourcemaps.init())
          .pipe(plugins.sass())
          .pipe(plugins.autoprefixer({
            browsers: prefix_list,
            cascade: false
          }))
          .pipe(plugins.csscomb('./dev/libs/comb/research.json'))
          .pipe(plugins.sourcemaps.write('./'))
          .pipe(gulp.dest('./public/css')));
      });
    
      return merged;
    });


    Типа так
    Ответ написан
    9 комментариев
  • Безопасны ли сервисы для realtime приложений?

    voidnugget
    @voidnugget
    Программист-прагматик
    Насколько безопасно пропускать данные через этот сервис?

    Если для вас не безопасен https, то тут уже ничего не поделать, непосредственно сам сервис вмешиваться не станет из-за нюансов с законодательством. А mitm возможен только с вашего сервера в pusher.

    Можно ли (сложно ли) сделать такое приложение без сторонних сервисов?

    Сложность заключается в отсутствии нормальной многопоточности с коробки
    В случае с ruby / python / php нужно использовать очереди на beanstalkd / celery / sidekiq.

    У приложений на node.js / golang / java естественно такой проблемы нет, и производительность в раз 10 выше.

    В браузер обычно пушат через socket.io / sock.js или SSE.
    Ответ написан
  • Хотим на сайте перейти на webp, стоит ли?

    voidnugget
    @voidnugget
    Программист-прагматик
    Стоит.
    Ничего не мешает откатится на jpeg / png по потребности.
    Ответ написан
    2 комментария
  • Есть ли на практике нынче отдельный "чистый" верстальщик в продакшене при разработке FrontEnd'a web-приложений?

    voidnugget
    @voidnugget
    Программист-прагматик
    Сейчас современная вёрстка не обходится без кучи сторонних инструментов типа gulp, stylus, sass, csslint и прочего, которые мало того что и время экономят так и очень пересекаются с фронтом. Хотя, на практике, даже стабильных полифилов для относительных метрик, да и для анимации, сейчас нет :( А отзывчивость в пикселях - неуважение к себе (адаптивность немного с другой оперы).
    Ответ написан
    1 комментарий
  • Будущее у RestFull сайтов?

    voidnugget
    @voidnugget
    Программист-прагматик
    Я лично выбрал для себя реакт, так как он спокойно пререндерится в node.js и с небольшими плясками с cqrs-es'ом его можно заставить очень и очень хорошо работать, но это не для простых смертных и большинству адептов недоступно. Будущее есть - нормальных инструментов нет.
    Ответ написан
  • Удобно и практично ли использовать шаблонизаторы (Jade и т.п.) в мелких проектах?

    voidnugget
    @voidnugget
    Программист-прагматик
    Конкретно в случае с Jade - очень целесообразно в проектах разнообразной сложности.
    При условно низком пороге вхождения он очень сильно упрощает и ускоряет разработку.
    Хотя если это сайт на 3 страницы, то и emmet справится )
    Ответ написан
    Комментировать
  • Какие лучшие фриланс биржи для новичка?

    voidnugget
    @voidnugget
    Программист-прагматик
    Проще всего тут же на тёплом-ламповом фрилансиме.
    Ответ написан
    Комментировать
  • Какую архитектуру(mvc, hmvc...) выбрать для интернет магазина?

    voidnugget
    @voidnugget
    Программист-прагматик
    На самом деле всё равно на чём писать магазин, так как это банальный CRUD и AAA сервисы, на практике обычно даже до нормальной модели БД не доходит.

    Браузерные SPA (одностраничные приложения) сулят проблемами с SEO, а нормально написать на react'е изоморфное приложение не каждый сможет, да и prerender.io с angular.js не всегда хорошо себя ведёт, хотя можно поиграться и рендерить angular.js в jsdom'e... в общем найти человека который в этом всём нормально разбирается сейчас очень сложно.

    Для описанной архитектуры аля CQRS-ES нужны бюджеты от 3000$+, что, собственно точно не самая лучшая идея для среднестатистического магазина, либо нужен энтузиазм разработчиков на котором далеко не уедешь, и мотивировать одним лишь энтузиазмом очень сложно. Готовых решений в этом плане просто нет в природе, а проверить не пишут ли там пятиколёсные велосипеды не всегда представляется возможным.

    Проще взять любой среднестатистический РНР фреймворк и не заморачивать себе одно место, покрыть нормально тестами (Codeception к примеру), прикрутить полнотекстовый поиск и отчёты, разобраться как правильно реализовать ААА, убедится что у вас нормализирована модель БД. В последнее время, я всё реже и реже вижу даже 3тью нормальную форму, про остальные 3 история умалчивает.

    Если у вас есть нормальный бюджет, 8000-10000$ на разработку магазина - можно думать о всех, описанных выше, вещах, но вам нужно правильно организовать процесс разработки и контроль качества, разобраться в мотивации разработчиков, и только потом можно будет думать не тратятся ли эти деньги не понятно на что, потому что, на моём веку люди так миллионы у.дмурдских е.жей запускали в космос изобретая никому ненужное нечто, и среди таких контор есть даже IBM, Logitech, и TI.

    В общем для начала стоит разобраться в более простых вещах, а потом пытаться строить андроидов, иначе нас всех ждёт Skynet им. Kokaas'a.

    p.s. php для меня уже года 2 как мёртв, а в 7ом будет больше от Java чем от php.
    Ответ написан
    5 комментариев
  • Книги по архитектуре веб приложений?

    voidnugget
    @voidnugget
    Программист-прагматик
    Нет таких. Сейчас MV* (mvc mvp mvvm hmvc) потиху отходит на второй план, есть очень много вещей которые с его помощью, к сожалению, нельзя нормально реализовать. Довольно медленно развивается тема реактивных приложений, но нет нормальных юзабельных реализаций с RAD'ом, про полноценное SOA история вообще умалчивает. Всё где есть push-нотификации, близкие к реальному времени, требует нормального CQRS-ES'a, там тоже приходится писать костыли и ничего готового нет. Кодогенерация в зачаточном состоянии, а существующие реализации scaffolding'a у меня, лично, не вызывают ничего кроме ухмылки.

    В общем пойду писать CQRS-ES SOA фреймворк под golang когда появится возможность.
    Ответ написан
    Комментировать
  • Один универсальный фреймворк или несколько под каждую задачу?

    voidnugget
    @voidnugget
    Программист-прагматик
    Знаком почти со всеми популярными MVC-фреймворками которые сейчас есть на рынке, и даже с Catalyst'ом :)
    Нет универсальных решений - у всех есть свои недостатки.

    Ввиду движений в сторону реактивностей от себя могу выделить Play2 / Xitrum и Grails.
    Но у них тоже хватает проблем с производительностью, хоть они и на много (очень-очень много) быстрее тех же рельсов или джанги, или всяких симфоний / Yii2 и экспрессов с Sails.js'ами.

    Вот что писал раньше по поводу того же питона.
    Ответ написан
  • На каком языке(фреймворке) лучше писать бекэнд для сервиса бронирования?

    voidnugget
    @voidnugget
    Программист-прагматик
    Сейчас требования на рынке возросли в 3-4 раза по сравнению с тем что было 2-3 года назад. PUSH-нотификации по вэбсокетам (или comet'у) и в мобильные приложения требуют асинхронности и в случае с PHP / Python / Ruby реализовуются довольно костыльно - прикручивают очереди Celery / Beanstalkd / Gearmand / RabbitMQ. В итоге умирает вертикальное масштабирование решения в рамках одного сервера из-за накладных расходов на коммуникацию. Микросервисную архитектуру стоит внедрять в рамках нескольких машин, и профилировать накладные расходы на коммуникацию.

    Также существует очень много проблем с PHP / Python / Ruby / Node.js c долгосрочной поддержкой - слишком часто отваливается обратная совместимость у существующих библиотек и зависимостей. Часто меняется API самой платформы.

    Из фреймворков сейчас веселее всего с Play2 / Xitrum / Grails.
    У них есть свои недостатки, но они будут шустрее всего остального в десятки,а в случае с рельсами - в сотни, раз.

    С Node.js куча проблем.

    Опять же там много заморочек с архитектурой - нужно внедрять SOA и CQRS-ES для реактивностей, и это уже не банальное MVC к которому все так привыкли. Подобный подход просто требует TDD/BDD и приёмочных тестов для фронтенда.
    Ответ написан
    4 комментария
  • Почему страницы Facebook открываются без загрузки впрочем и Вконтакте тоже - это Ajax?

    voidnugget
    @voidnugget
    Программист-прагматик
    В общем там браузерная шаблонизация - нужно смотреть в сторону Angular / Ember / Meteor / React + rx.js
    Cейчас вопрос с SEO и браузерной шаблонизаций обычно решается либо дублированием шаблонов на сервере и в браузере, но основе Jade к примеру, либо гоняют рендер в браузере или node.js, как это делается с React'ом или prerender.io.

    Ну вот к примеру learni.st написан на Angular'е и отлично индексируется гуглем.

    Сейчас наиболее перспективным является GWT-way, когда серверные шаблоны прозрачно транслируются в браузерные, и все изменения модели передаются посредством push нотификаций и по вэбсокетам или comet'у (socket.io / sock.js). Но для этого нужно ещё реализовать нормальную поддержку Virtual DOM суррогата, так как это сделано в React'e. В нём кстати самый толковый рендер DOM'a, из-за этого рождаются вундервафли типа ngReact.

    В общем вопрос фронтенда за последние 3 года очень сильно усложнился с появлением различных MVC-подобных браузерных подходов, и jQuery уже "прошлый век". Сейчас всё упирается в реактивности с асинхроном и многопоточностями, а с ними в PHP / Ruby куча проблем. В Python этих проблем меньше, но и костыли там тоже встречаются, а в node.js вообще их нет... но производительность обоих решений оставляет желать лучшего.

    Пробуйте golang, или Typesafe Stack / Grails.
    На фронтенде веселее всего с React rx.js и socket.io / sock.js, но для коммуникации можно и что-то своё написать.
    Ответ написан
    Комментировать
  • На чем писать бекенд?

    voidnugget
    @voidnugget
    Программист-прагматик
    Видел 100500 примеров как не надо писать RESTful сервисы.
    Главное понимать задачи DataMapper'ов в рамках RESTful сервисов и AAA.
    "Одна табличка - один CRUD контроллер с логикой" - путь в никуда.

    Из бэкендов сейчас стоит двигать в сторону Typesafe Stack или Groovy Grails, и забыть про этот тупой РНР ширпотреп.

    Play2 - прост как дверь, и достаточно быстрый, не без overhead'ов, но и выбирать сейчас особо не с чего :(
    Если Scala не является препятствием можно двигать к Xitrum'у, но у него нет энтерпрайсной поддержки.
    На Grails оч удобно реализовывать RAD приложения, правда производительность не очень. Но сравнивать можно только с jRuby или jyton'ом.

    Python / PHP / Ruby / Node.js не подходят для реактивных приложений, и долгосрочная поддержка просто сущий ад. В общем рано или поздно приходится пилить Push нотификации и асинхронности и там обычно прикручивают Celery / Gearmand / Benstalk / RabidMQ etc естественно работает это не ахти ввиду накладных расходов на коммуникацию.

    p.s. А, да, точно и зачем русским РНР программистам говорить о важности TDD/BDD ?...
    Ответ написан
    8 комментариев
  • Какие самые реальные и действенные проекты\работы\фриланс для python-программиста?

    voidnugget
    @voidnugget
    Программист-прагматик
    Пишу на питоне ещё с 15 лет (2.4+)... ненавижу его runtime и архитектуру. Язык хороший - реализация никакущая. Ну да его синтаксис достаточно упрощён, но и за синтаксический сахар приходится платить сложностями отладки и поддержки.

    Сейчас же почти все известные мне конторы не используют питон в продакшенах с более-менее высокой нагрузкой. Яндекс тому пример. Чаще питон используется для решения прикладных задач администрирования, так как это делается, к примеру, в SaltStack. Все дружно слезают с питона, РНР и рельсов на Golang, Java/Scala, и иногда даже Groovy - производительность выше в десятки раз, и managed runtime на много стабильнее. Правда в случае с JVM очень сильно раздувается куча в виду избыточности объектной модели (оператву жрёт как дурное, а я байтики считать привык). Сейчас это должно лечится с помощью Project Graal и Truffle, правда пока до этого дошёл только jRuby, который тоже в пару десятков раз быстрее Ruby. По идее и Groovy тоже должен переползти как-то ... Вот про jyton ничего не знаю.

    Много моих знакомых слезло на Golang с Ruby и Питона.
    Стоит попробовать - он достаточно простой и идиоматичный, вот рефлексию стоит обходить стороной - она очень медленная, впрочем как и везде. Работу может и не найдёте сразу, но после реализации пары простых проектов будет проще предлагать в качестве целевой платформы.

    Фрилансить с питоном начать можно, но очень желательно опробовать ещё хотя бы пару окружений и фреймворков типа Groovy Grails, или Typesafe Stack. Сейчас требования рынка возросли в пару раз за последние два года - нужны ассинхронности/многопоточности, push-нотификации в мобильные приложения и по вэбсокетам/комету. И это всё с богатыми js-фронтендами на всяких там Angular'ах и React'ах. Естественно можно крутить костыли типа Celery / Gearmand / Beanstalk / RabidMQ, но накладные расходы на коммуникацию слишком большие :( Компилируемые языки со своими Managed Runtime'ами позволяют строить монолитные приложения в которых подобные решения избыточны в рамках одной и той же машины, а если это куча нод в кластере то нужно мерить/думать.

    Django сейчас сложно поддерживать так как он достаточно сильно развился за последние 3 года, и я очень сомневаюсь что сохранится совместимость новых версий со старыми.

    А вот с pyramid (pylons) и SQLAlchemy можно строить достаточно хорошие приложения. У них есть enterprise поддержка и соответствующие гарантии.

    Типовые задачи на питоне:
    - написать какой-то мелкий скрипт с Gui на PyQT / Pyside для какой-то аналитики и отрисовки графиков, иногда попадаются задачки с gstreamer'ом
    - написать какое-то простое RESTful CRUD приложение, в стиле "одна табличка БД - один контролеер", это конечно же тонна копипасты и мне больше нравятся DataMapper'ы по типу TastyPie. Иногда люди хотят чистого Tornado или Flask'a, так как им не нравится overhead в джанге и pylons.
    - написать скрипты для деплоя чего-то, обычно люди не знают про SaltStack.

    В плане архитектуры питонистам чужды различные SOA с CQRS-ES'ом, потому что сам компилятор не располагает. Хотя её достаточно просто поддерживать.

    Проблема всех проектов на Node.js / Python / Ruby это отсутствие долгосрочной поддержки библиотек и фреймворков - часто ломается обратная совместимость, и нужно постоянно следить за состоянием всех зависимостей. Опять же нужен TDD/BDD для того что это всё хорошо контролировать. Тестируешь руками - себя не уважаешь.

    Ну и вроде всё ...
    p.s. я опубликую на хабре статью сегодня-завтра "Freelance - you're doing it wrong" там поделюсь опытом работы и основными организационными проблемами в рамках удалённой работы и фриланса, покажу разницу между ними.
    Ответ написан
    6 комментариев