• Как тестировать вёрстку автоматически?

    kresh
    @kresh
    Вот инструмент от Yandex - Gemini
    Ответ написан
    Комментировать
  • Как тестировать вёрстку автоматически?

    dimasmagadan
    @dimasmagadan
    есть вот такая штука
    galenframework.com
    но я ее не осилил: для моих задач слишком навороченное. если будут по ней вопросы, мне лучше не задавать.

    вот тут про них обзорная статья, если документацию читать долго
    https://www.smashingmagazine.com/2015/04/visual-te...
    Ответ написан
    Комментировать
  • Как работает react js?

    maxfarseer
    @maxfarseer
    https://maxpfrontend.ru, обучаю реакту и компании
    Возможно вам поможет подробный курс на русском языке по react.js
    Ответ написан
    Комментировать
  • Какую книгу по go выбрать?

    @JekaMas
    Я бы предложил легкую вводную книгу www.golangbootcamp.com
    Затем более глубокую www.amazon.com/Programming-Language-Addison-Wesley...
    Отдельно советую по БД и Golang: https://www.vividcortex.com/resources/the-ultimate...
    И по concurrency (но эту книгу стоит с осторожностью) - www.amazon.com/Mastering-Concurrency-Go-Nathan-Koz...
    И две обязательные к прочтению
    devs.cloudimmunity.com/gotchas-and-common-mistakes... - на удивление эти ошибки 90% разработчиков делают. Практически настольное пособие.
    golang.org/doc/effective_go.html - стандарт, что тут добавить.

    Про интерфейсы тут - https://habrahabr.ru/post/276981/
    Про то, как работает конкурентность в Go(а по сути runtime) - https://habrahabr.ru/company/ua-hosting/blog/269271/

    Что хорошо - большая часть этих ресурсов полностью бесплатны.
    Ответ написан
    1 комментарий
  • Go IDE

    @benoni
    программер-любтель, иногда подрабатываю фрилансом
    Ответ написан
    Комментировать
  • Почему в javascript {} + [] возвращает 0, а [] + {} возвращает "[object Object]"?

    Ivanq
    @Ivanq
    Знаю php, js, html, css
    В начале кода JS считает {} пустым блоком кода. Получается {} + [] == +[], а +[] равно 0. Когда сначала идет массив, к пустому массиву прибавляется {}, и получается [] + {} = "" + {} = ({}).toString(). Массив является разным объектом из-за этого:
    [].toString() == "";
    +[] == 0;
    +[x] == x;
    +[x,y,z] == NaN; // Ой, это неправильно!
    +[x,y,z] != +[x,y,z] // NaN != NaN
    Ответ написан
    1 комментарий
  • Почему в javascript {} + [] возвращает 0, а [] + {} возвращает "[object Object]"?

    @Aves
    {} + [] - пустой блок кода и приведение массива к числовому значению
    [] + {} - приведение массива к строковому значению и добавление строкового значения пустого объекта

    В таблице результат '==': зелёный, серый, синий true, остальное false, объекты сравниваются по ссылке.
    Ответ написан
    4 комментария
  • Как динамически изменять пути в gulp?

    @yaroslavgrishajev
    Если не ошибаюсь, то достаточно просто указать путь типа 'src/**/*.*'

    Пересмотрел вопрос :)
    Плагин gulp-rename делает то, что Вам нужно. Там в документации это описано: можно на лету поменять путь указанный в gulp.src (например заменить sass на css).

    У меня это выглядело вот так:

    var gulp = require('gulp'),
        sass = require('gulp-sass'),
        rename = require('gulp-rename');
    
    gulp.task('sass', function () {
        gulp.src('./src/**/*.scss') 
            .pipe(sass({
                includePaths: ['./src/']
            }))
            .pipe(rename(function(path){
    
                    // path.dirname = 'module-a(b)/sass' - это то, что задано в gulp.src
            	path.dirname = path.dirname.replace( "sass", "css" );
    
                    // path.dirname = 'module-a(b)/css' - а теперь мы поменяли так, как нам нужно
            	return path; 
    		  }))
            .pipe(gulp.dest('./src/')); // и тогда все сложится в src/module-a(b)/css - в нужную папку модуля
    });
    
    gulp.task('default', ['sass']);


    Но там уже как душе угодно можно плясать.
    Ответ написан
  • Можно ли считать, что Bootstrap теряет актуальность?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    Ну что за бред. Бутстрап живее всех живых и вообще готовится к выходу новая его версия.
    Кроме того, главная фича сегодняшнего бутстрапа в модульности. При сборке проекта через Grunt/Gulp и т.п. вы можете выбрать, какие элементы подключить. Многие используют из него только Grid, так как он очень удобен.

    И вообще, удобнейшая вещь для программистов. Когда нужно запустить приложение, но нет ни фронтендера, ни дизайнера.
    Ответ написан
    Комментировать
  • Что вы посоветуете использовать сейчас React+Flux или Angular?

    @Mycolaos
    Почему бы не React+Flux+Angular?

    React это представление.
    Flux это архитектура.
    Angular это фреймворк.

    P.S.: React очень удобен. Если попробуете, рискуете что он вам понравится. В любом случае получите ценный опыт.
    Ответ написан
    1 комментарий
  • Как использовать react-dom и react-router вместе?

    Как же так искать можно?!

    https://github.com/rackt/react-router/blob/v1.0.0-...

    Замените React.render на ReactDOM.render вот и все
    Ответ написан
    2 комментария
  • Почему не все серверы пишутся на Node js?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
    Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

    2. Ответ на абстрактный вопрос:
    а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
    б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
    в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

    UPD
    hbrmdc
    У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
    Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

    1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
    JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

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

    2) Личные предпочтения обоснованные привычками это основной аргумент.
    Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
    Мне нужна новая команда на новый проект.
    Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
    PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
    Собственно на этом выбор и закончен.

    На малопопулярных языках пишут в случаях:
    a) это мелкий сервис с неявными перспективами который можно переписать за неделю
    б) это проект "для души" разработчика.

    Получается замкнутый круг на самом деле.
    Менеджер смотрит резюме, резюме на node.js нет =>
    Менеджер не начнет проект на node.js =>
    Не возникнет вакансия на node.js =>
    Разработчик анализируя вакансии не увидит вакансий на node.js =>
    Разработчик будет учить что то другое =>
    Менеджер смотрит резюме, резюме на node.js нет...

    Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)
    Ответ написан
    13 комментариев
  • Как развиваться в программировании, если мотивируют только деньги?

    Ronnie_Gardocki
    @Ronnie_Gardocki
    Я у мамы фронтендщик.
    Хотите денег - делайте себе имя. Пилите вещи для опенсорса (гитхаб и подобное)/демки и какие-нибудь статьи (с этим чуть посложнее, ибо нужен норм английский, либо можно писать по-русски и потом переводить с чьей то помощью). Параллельно с этим будете получать заказы на фрилансе (клиенты сами будут на вас выходить) для повышения квалификации, портфолио и естественно получения адекватных денег. В отличии от стандартной офисной работы в снг, рост тут далеко не линейный. В снг офисе (не компании топ уровня, хотя и там не уверен что все сладко) зачастую с трудом можно получать прибавку в 10-30% раз в 4-12 месяцев, а иногда вообще единственный способ повышения зп это переход в офис другой компании. На том фрилансе, который я описал выше, никто не мешает повышать часовой рейт по 5 баксов каждый раз после выполнения 1/2 проектов. 3 месяца назад стартовал с 30, сейчас веду проекты по 35, следующие будут по 40. К концу года планирую дойти до 50+.
    Ну а если фриланс вам не интересен в долгосрочной перспективе, то имея за плечами некий вклад в коммьюнити и неплохое портфолио, будет не особо тяжело найти работу в какой-нибудь зарубежной компании.
    Ну и само собой вам надо быть хорошим специалистом :)
    Ответ написан
    6 комментариев
  • Как развиваться в программировании, если мотивируют только деньги?

    Jump
    @Jump
    Системный администратор со стажем.
    Обратитесь к психологу с вашей проблемой.
    Здесь технический ресурс, а не линия психологической поддержки.
    Ответ написан
    6 комментариев
  • Гибридные мобильные приложения. За ними будущее?

    @Shannon
    Это не серебряная пуля, но в принципе решает часть задач, иногда можно полностью отказаться от нативной разработки. Хоть тема и не нова, но обсуждать имеет смысл только решения, которые появились относительно недавно (crosswalk, intel xdk, framework7). До этого всё было тормознуто и html5-приложения в итоге заработали дурную славу.

    Краткий ответ: Да, html5 приложение на данный момент уже может заменить нативное в ряде случаев, так как при использовании правильных технологий оно получится достаточно близким к нативному.

    Есть тонкости. Многие думают, что Cordova/PhoneGap это и есть тот самый фрейморк в котором и кроется секрет производительности или тормозов итогового приложения. На самом деле есть 2 разные по сути вещи:
    Cordova/PhoneGap - это фрейворк, который соберет html5 приложение в apk и т.д. По сути это просто конструктор, никак не влияющий на производительность итогового приложения. Он позволяет взять html5 приложение, добавить плагины, для работы с камерой/gps/рекламой, и в итоге получить аналог нативного. Но так сложилось, что почти все публичные примеры из коллекции phonegap тормознутые, и поэтому многие так и думают, что html5 тормознутые.

    Дело в том, что есть фреймворки вроде cordova, а есть html5 фреймворки и это разные вещи, и их нельзя ставить в один ряд. Сама по себе cordova не тормозная и не быстрая, она работает так и только так, как работает html5-приложение (которое запросто можно запустить просто в браузере, и нажав в браузере "добавить на рабочий стол", оно будет работать как автономное приложение). Соотвественно, если html5 фреймворк быстр и отзывчив, то разница с нативным приложением будет незначительна.

    Второй момент. Так как html5 приложение, это лишь html+js, и запускается он внутри webview, то скорость приложения так же зависит от скорости движка webview. Допустим, на ios с этим все хорошо, а вот на андроид с этим хорошо только начиная с 5.х версий. На старых версиях андроида очень тормозной webview.
    Эту проблему с тормозным webview вполне успешно решила Intel представив проект crosswalk. При использовании crosswalk стандартный webview заменяется на последнюю версию chromium, что означает поддержку новым фич, больше плавности, скорости и т.д.
    Само собой, чем свежее crosswalk, тем быстрее и стабильнее работает итоговое html5 приложение.

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

    Есть 2 очень быстрых html5 фреймворка (по субъективным тестам, framework7 выигрывает в скорости и плавности), это framework7 и ionic - они решают многие проблемы тормозов, задержек, залипаний присущих стандартному использованию js.
    Соотвественно, например, используя framework7, время отклика нажатий, реакции на свайпы и т.д. будет аналогично тому, что и в нативном приложении. Оба вреймворка содержут набор фич, реакций на типичные для приложений событий, а так же набор всех стандартных и расширенных компонентов, которые потребуются при разработке, и которые подключаются парой строчек в html файле в нужном месте. Они уже имеют встроенные стили, в итоге все компоненты и приложение в целом выглядит как нативное (один в один) ios8 или material design, никакой инородности. При этом их легко настроить через css.

    Чуть подробнее можно посмотреть в статье "Быстрое кроссплатформенное HTML5 приложение на Framework7" - habrahabr.ru/post/257889 или аналогичных (про ionic например) там же
    В итоге, на момент написания статьи, на гаджетах 5 летней давности всё работает примерно на 10-15% хуже чем аналогичное нативное решение. Если сейчас перекомпилировать со свежим crosswalk (в intel xdk, кстати, это делает даже совсем просто, достаточно нажать build и выбрать crosswalk), то разница будет еще менее заметна.

    Так что, сходу отмахиваться от этого направления не обязательно, нужно лишь быть готовым к немного другим проблемам, чем при разработке нативного приложения.
    Ответ написан
    Комментировать
  • Arduino: Есть ли датчики подсчета кол-ва использованной воды?

    eapeap
    @eapeap
    Сисадмин, Беларусь
    электронный счетчик воды
    электронный счетчик электроэнергии как писал Александр Комарчук - ставить после "официального"
    Или порешать вопросы с водоканалом и энергосбытом, и заменить свои счетчики на электронные.
    Ответ написан
    3 комментария
  • Как бороться со страхом использовать Javascript на сервере?

    @dbalakov
    Я бы сказал, что многое зависит от задачи, я последние пару лет использую ноду для реста - но это удобно, когда живешь в мире "плавающего" кода - если есть четкое ТЗ и план развития на пару лет, которые не будет менять - возможно, есть другие решения, может я бы выбрал стек на java - просто за счет зрелости платформы и библиотек, если же хостимся на винде и конектимся только с виндовых приложений - я бы поставил под вопрос rest и использовал C# (прекрасный и гибкий язык).
    У любого решения есть минусы и плюсы и необходимо смотреть на саму задачу, в идеале, имея за плечами опыт использования платформы в продакшне.
    Ответ написан
    Комментировать
  • Как бороться со страхом использовать Javascript на сервере?

    DIITHiTech
    @DIITHiTech
    Fullstack javascript developer
    Все люди любят привычные вещи, некоторые ж вовсе будут до последнего за них держатся, переживая фазу отрицания =)) отрицания того, что новый инструмент является гораздо лучше заточенным под текущую задачу, но все же пытаются найти хоть какие то мелкие изъяны, дабы успокоить себя, что переходить незачем, при этом не замечая огромных проблем в текущем своем инструменте. Сейчас как раз это переживают phpешники с nodejs, когда собираются строить асинхронные приложения вместо классических сайтов.
    Как минимум то, что на обеих концах используется один язык, уже огромный плюс - написал модуль и используешь что на фронтенде, что на бекенде - красота, никто не любит повторяться как в смутные времена php+js. С ужасом вспоминаю времена, когда приходилось фильтровать ввод юзера на фронте, потом писать тоже на php на бекенде...бррр..
    Ответ написан
    Комментировать
  • Как бороться со страхом использовать Javascript на сервере?

    MarcusAurelius
    @MarcusAurelius Куратор тега Node.js
    автор Impress Application Server для Node.js
    Бороться со страхом бесполезно, так вся жизнь на борьбу уйдет.
    Если они боятся или не хотят, то им уже ни чем не помочь, кроме своего примера.
    Только личным опытом и примером переубедите.
    Ответ написан
    Комментировать
  • Как бороться со страхом использовать Javascript на сервере?

    Я думаю страх очень простой - из-за отстуствия ощущения поддержки. Большого Брата вроде MS или Оракла не стоит за Node.js. Я конечно не хочу сказать, что всем на него плевать и никто не предложит поддержку - другое дело, насколько эти фирмы на слуху.
    Смежным вопросом является доступность важных для коммерческой разработки вещей. Если вы ранее использовали WCF - не удивительно, что после такой махины, которая из коробки поддерживает огромное количество стандартов для олдскульных XML веб-сервисов (с безопасностью, адресацией и т.д.), и даже REST-сервисы, многие захотят идти в ноду и заново собирать себе там необходимые инструменты и библиотеки, даже если они есть (что конечно надо сначала проверить).
    Ну и, наконец, основным субъективным фактором является желание использовать полученные навыки. У WCF довольно приличный порог входа, и разбираться нужно реально долго, прежде чем можно чтото применить на практике с пониманием происходящего. Это как с WPF последнее время народ негодует - все потратили N месяцев на изучение (один XAML чего стоит), а от майкрософта за последние 6 лет толком не новшеств ни обновлений не было, все смотрят на переписанный с нуля ASP.NET (который теперь всю платформу ведет в правильное русло), и завидуют. Так и вы приходите весь в белом и говорите - забейте на ваш багаж корпоративного дотнета, все идем в ноду.
    Ответ написан
    5 комментариев