• Какие книги прочитать по js в 2020?

    @AlexCraft
    Software engineer
    У книг есть одна проблема - они устаревают еще на стадии подготовки к изданию. Книги лучше читать по совсем фундаментальным вещам, которые не меняются: алгоритмы, паттерны и т.д. То, что Вы ищете не найти в книгах (быстро устаревает). Читайте живые стандарты: MDN, JavaScript.info, доки по React / Vue / Angular. Меняйте тип источника: не заходит документация — смотрите курсы с практикой (Youtube, Udemy), слушайте подкасты.
    Ответ написан
    Комментировать
  • У вас есть какие-то интересные идеи для проектов, на которые нету времени?

    Jump
    @Jump
    Системный администратор со стажем.
    У вас есть какие-то интересные идеи для проектов, на которые нету времени?
    Разумеется.
    Можете поделиться им, т.к. времени у меня мейчас просто завались, а идей нет)
    Конечно могу. Счет куда выслать?
    Ответ написан
    3 комментария
  • Зачем нужно ООП в javascript?

    для того же, для чего и в других языках
    Ответ написан
    1 комментарий
  • Фрилансеры, где хранить деньги?

    miraage
    @miraage
    Старый прогер
    Откройте ИП с налогообложением УСП/ПСН и забудьте все эти проблемы.
    Ответ написан
    3 комментария
  • Как выгоднее выводить деньги с апворка, ип или payoneer?

    @andrew8712
    Я вроде как-то считал, у пионера ~5-7% комиссия выходит.
    У ИП на УСН 7%, а не 6%. Не забывайте страховые взносы за доходы свыше 300 тыс. - это +1%. Плюс $30 за вывод. Плюс нужно платить налог еще и за комиссию апворка, плюс еще 18% НДС на нее :) Это если все по закону делать. Но сейчас можно использовать патентную систему налогообложения, там нужно заплатить 6% не с заработанной суммы, а с потенциального дохода, который устанавливается правительством региона для каждого вида деятельности. Например, в моем регионе на разработку ПО потенциальный доход - 356 000 руб. В итоге, на налоги и страховые взносы уйдет где-то 50к в год, ну и плюс НДС 18% за комиссию апворка. Получается выгоднее, чем пионер, если доход больше 1 млн.
    Ответ написан
  • Meteor.js расцветает или чахнет?

    PQR
    @PQR
    Не согласен с предыдущим оратором (@geeek), в частности с утверждением
    В общем если хочешь быть в тренде - бери
    - Meteor совсем не в тренде.

    Если дать краткий и резкий ответ на вопрос "расцветает или чахнет?" - отвечу: интерес к Meteor чахнет, не смотря на все усилия команды разработки.

    Компания MDG (Meteor Development Group) подняла $31M инвестиций (https://www.crunchbase.com/organization/meteor) и хотела всё сделать круто, стать мейнстримом, а потом зарабатывать на хостинге Meteor проектов - такой план монетизации. Хостинг они, кстати, сделали. И в какой-то момент было много хайпа вокруг Meteor, казалось, что всё идёт по плану. Полтора года назад вышел Meteor 1.0 (октябрь 2014), потом была пара хороших релизов, которые убрали всю "сырость": Meteor 1.1 и 1.2.

    Но в середине 2015 стало понятно, что никаким мейнстримом они не стали, мейнстрим нынче React!
    Не смотря на простоту старта и скорость разработки с Meteor, были очевидны следующие минусы:

    1. Собственная система пакетов со своим центральным репозиторием https://atmospherejs.com - посмотрите на счётчики скачивания пакетов, это крохи по сравнению с npm. Посмотрите на активность разработки основных пакетов - всё очень тухленько.

    2. Собственная система сборки. С одной стороны всё работает из коробки, с другой стороны в неё не вклинишься (это сложно). Плюс всякие странные условности, что всё в глобальном пространстве имён и ваши js файлы загружаются в алфавитном порядке. В Meteor 1.3 частично решили проблему, ходят слухи, что в будущем будут использовать webpack.

    3. Собственный шаблонизатор blaze (похож на handlebars). В начале blaze выглядел хорошо, но теперь все внезапно пишут на React и многие потирают руки в ожидании Angular 2, в итоге blaze оказался ещё один велосипедом, с которым не понятно что делать.

    4. На бекенде всё ещё Node 0.10. Даже с Node 0.12 Meteor уже не работает из-за некоторых бинарных зависимостей! Обещали в будущих версиях обновиться с поддержкой Node 4.

    5. Метеор сильно завязан на MongoDb. Чтобы реактивно доставлять новые/изменившиеся данные от сервера в бразуер они парсят логи Mongo. Были попытки сделать аналогичное для SQL баз, но не увенчались успехом. В итоге встречайте их новый проект Apollo, который поверх GraphQL и не привязан к конкретной реализации бекенда www.apollostack.com А что теперь будет со старым добрым DDP?

    6. Ваше Meteor приложение одной командой можно упаковать в мобильное приложение Cordova - выглядит круто, но сейчас время ReactNative и вот мы читаем обсуждения на форумах, что возможно, они таки интегрируются с ReactNative, но когда?

    Подводя итог: ребята из MDG подняли кучу денег и хотели сделать всё сами: свои пакеты, свою сборку, свой шаблонизатор, свой реактивный протокол (DDP) и чтобы всё работало из коробки. И они сделали это!

    Только это оказалось никому не нужно, т.к. для пакетов все сидят на npm, сборка должна быть гибкой (и поэтому у нас есть gulp и webpack), самый модный шаблонизатор нынче - это React, реактивный протокол GraphQL и базы на сервере люди любят разные, а не только MongoDb. А Meteor, по сути, остался на обочине всей экосистемы и движухи вокруг JavaScript. Поняв это, MDG начали двигаться в сторону JS комьюнити и первый шаг сделан: Meteor 1.3 поддерживает нормальные модули ES2015, npm пакеты, рендринг через React и Angular. Но Meteor 1.3 - это куча костылей поверх старого велосипедного Meteor. Почитайте их планы на будущее в официальном блоге, хотя бы в этом посте: info.meteor.com/blog/announcing-meteor-1.3 - им по сути предстоит переписать всё заново! И первые ласточки такого "переписывания" - это выделение проекта Apollo.

    Возможно, со второй попытки они всё сделают правильно и Meteor 2.0 действительно выстрелит. Если только у них деньги не закончатся раньше.

    Сейчас можно взять Meteor и эффективно зарабатывать на маленьких/средних фриланс проектах, когда нужно сделать быстро и не думать о долгосрочной поддержке.
    Если же вы делаете большой продукт, то вас ждут большие потрясения и изменения в экосистеме Meteor.
    Ответ написан
    4 комментария
  • Какую фантастику порекомендуете, где главный герой программист/инженер?

    @teugen
    Призрак алкоголизма.
    Удивительно, что никто ещё не упомянул Понедельник начинается в субботу.

    В некотором роде Мы Замятина. И, конечно, Гиперболоид инженера Гарина.
    Ответ написан
    2 комментария
  • Как убедить начальство отказаться от велосипедов?

    evnuh
    @evnuh
    Поиск Гугл помог мне, впусти и ты его в свой дом
    Не волнуйтесь, вас уволят и правильно сделают. И вот почему.
    Начну со стороны хорошего бизнесмена:
    У него уже есть cms и crm, которую он пилил 5 лет, умеет продавать и знает. Да, так получилось, свой велосипед, ужасно написанный, но это его не волнует до тех пор, пока она кормит и его и всех его подопечных. Отказаться от неё означает не только огромные временные затраты на смену всего, начиная от обучения программистов как её пилить, заканчивая обучением всех, кто будет её касаться. Так же это означает поддержка уже двух систем, старых клиентов со старой и новых с новой. Но самое главное - это высокий риск того, что продавать её будет тяжелее.

    Со стороны хорошего разработчика:
    А хорошему разработчику вообще до фени, с чем ему работать. Спросите у опытных. Эмоционировать при виде говнокода и велосипедов - это максимализм юного программиста. Разработчики с опытом умеют погружаться в любой велосипед, в любой говнокод и работать с ним. А потому что они уже навидались и в своё время тоже кричали и пытались перевернуть мир, но, кому это надо? Вы - наёмный работник, вы не должны писать красивый код, вы должны решать бизнес задачи. Бывалые так и делают, просто иногда про себя вздыхая, т.к. чувство прекрасного всё же не убить :)
    Ответ написан
    18 комментариев
  • Как быть с поддержкой свойств в JS?

    Taraflex
    @Taraflex
    Ищу работу. Контакты в профиле.
    Использовать babel + не забыть подключить https://babeljs.io/docs/usage/polyfill/
    Ответ написан
    Комментировать
  • Съехал текст кто виноват и где искать проблему?

    Symphony
    @Symphony Куратор тега CSS
    Съехал текст кто виноват и где искать проблему?

    На такие вопросы ответ простой:
    – Признаю, это сделал я, проблему ищите в Гибралтаре
    Ответ написан
    Комментировать
  • Как использовать Gulp и его модули глобально, без установки в каждый проект?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Вообще говоря можете по устанавливать gulp и другие пакеты глобально

    npm install gulp package1 package2 ... -g


    Однако это путь в никуда и так делать очень не рекомендую. В один прекрасный момент вы обновите версию одного из пакетов неудачно, и все ваши проекты загнутся разом, а так - только один. По сему не рекомендую так стрелять себе в ногу
    Ответ написан
    5 комментариев
  • Стоит ли изучать JavaScipt и C# одновременно с нуля?

    morozovdenis
    @morozovdenis
    Конечно нет. Эволюционно мозг человека сложился так что С++ и С# можно одновременно изучать, но JS и C# нет. Когда вы будете изучать JS вы будете тут же забывать C# полностью и наоборот. Вот C++ хороший, он сочетается с C#.
    Ответ написан
    1 комментарий
  • На западе не заказывают верстку? Или я туплю и не могу найти?

    Bandicoot
    @Bandicoot
    Вась-программист
    На Западе более зрелый рынок, я так понимаю. Рано или поздно так будет и у нас. Зачем сначала заказывать макет у одного фрилансера, затем верстку у другого и натяжку на движок у третьего, когда это может выполнить один человек? Это же все из одной оперы, фронтэнд. Может я ошибаюсь, поправьте
    Ответ написан
  • Что нельзя/проблематично реализовать на node.js?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Real-time computing проблематично. Больше в голову ничего не лезет. Ну и да, писать на ноде десктопный софт (не CLI) это извращение.

    Вы только поймите, можно почти все сделать и на brainfuck. Вопрос в эффективности. О PHP вот тоже все плохо говорят, даже те кто на своих любимых js/ruby говнокодит в контроллерах только. И что? Будьте выше этого.

    p.s. На самом деле все говно кроме пчел. Это суровая реальность. Нет ничего универсального и подходящего под все спектры задач. Так же есть еще субъективные факторы.
    Ответ написан
    4 комментария
  • Нужно ли в javascript думать о private свойствах и методах?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Инкапсуляция это всегда хорошо. Вопрос в том нужны ли вам приватные методы и свойства? Они хороши в контексте классов, что бы разграничить интерфейс и реализацию. В JS же объект является интерфейсом. То есть он не может иметь скрытого состояния. Точнее может но не в самом объекте, а в другом каком...

    В Python-мире есть такая точка зрения по поводу отсутствия модификаторов досупа, которая выражается выражением "We're all consenting adults here" (все мы тут взрослые люди). То есть по мнению большинства поставить _ перед названием приватных методов достаточно что бы разработчики их не использовали. В JS даже это крайне не рекомендуется делать, так как у вас есть скоупы и все что нужно спрятать вы можете сокрыть там. Так же в ES6 появится WeakMap которые помогут хоть немного упростить разруливание скрытого состояния и уменьшит вероятность утечек памяти.

    Если посмотреть на фреймворки, например AngularJS активно использует $$ перед именем приватного свойства или метода. Причем в добавох в jsdoc эти свойства отмечены как private и если указать соответствующие опции для минификаторов, то те переименуют эти свойства и тогда разработчику будет уже тяжело предсказать как оно будет называться в следующем релизе.
    Ответ написан
    7 комментариев
  • Нужно ли в javascript думать о private свойствах и методах?

    @bromzh
    Drugs-driven development
    В питоне вообще нет модификаторов доступа, и все поля доступны по прямому доступу. И ничего страшного в этом нет. В js такая же ситуация. Более того, все эти заморочки с private заставляют зачастую генерить кучу геттеров и сеттеров, которые будут нарушать инкапсуляцию. Так что заморачиваться не стоит, ведь даже в яве можно с помощью ухищрений добраться до приватных полей через рефлексию.

    Решение может быть таким: обозначать какие-то внутренние переменные и методы с символа подчёркивания. Они по-прежнему будут публичными, но для разработчика это знак, что такое поле не понадобится при использовании твоей библиотеки. А методы и переменные, необходимые только для одного публичного метода какого-нибудь класса можно делать локальными, чтобы не плодить кучу полей.
    Ответ написан
    1 комментарий
  • В чем же сила Node.js ?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Сила в том что все знают JS. Кто может писать на PHP/Ruby/Python? Те кто пишут на PHP/Ruby/Python соответственно (и скажем по 10%-15% от количества каждых кто может писать хотя бы на двух из трех языков. Кто может писать на JS? Все фронтэндеры + добрых каких 60%-70% от всех этих php/ruby/python/java/c# разработчиков...

    Что это дает? ОГРОМНЕЙШЕЕ комьюнити... большая часть быдло конечно но засчет огромнейшего количества разработчиков инструментарий начал просто очень быстро развиваться. Кому нужен инструмент написанный на Ruby если его можно написать на JS и его сможет поддерживать на порядок больше людей?

    Вопрос производительности по началу стоял как основная фишка языка. Все кричали наконец-то, V8 на сервере, асинхронность! Самый быстрый интерпритируемый язык на планете и все такое. Но на деле все чуть сложнее. JS реально быстрый. По сравнению с тем же Ruby он в разы быстрее! Но по большому счету на это адекватным людям плевать с высокой колокольни, так как js нифига не асиинхронный. JS работает в один поток. Причем в этом же потоке работает и сборщик мусора. Если он начнет все чистить - все замрет. Обычно это не сильно большая проблема но как-то забавно. Асинхронное в JS только работа с IO которая на плюсах/си реализована...

    Революционности так же нету. JS на сервере не новая идея и практиковался еще лет за 5 до. Просто это была очень удачная реализация да ктому же если бы не V8 то так же все было бы не так круто.

    Что до сравнения с PHP и т.д. - это инструменты для разных сфер. PHP - разработка web-сайтов. node.js - демоны, инструменты разработки, шины данных, доставка данных и т.д. Для всего остального PHP подходит больше. Есть правда пара интересных проектов главная цель которой устранить дублирование кода на сервере и на клиенте.... но подходят эти наработки пока только для очень простых проектов (хотя все относительно).

    Если вас прям плющит от нового, быстрого, современного, с клевым дизайном и тоже где повлиял гугл - golang.
    Ответ написан
    11 комментариев