• С чего и где начать обучению React, Redux?

    maxfarseer
    @maxfarseer
    https://maxpfrontend.ru, обучаю реакту и компании
    Присоединяюсь к Михаилу - язык нужен. В тех ссылках что он вам скинул - Dan (автор и видео и самого redux) говорит достаточно понятно.

    Я по весне писал объемный redux туториал , там react 0.14 (но он очень близок к 15) и остальные пакеты "постарее", но вы можете брать его за основу, а пакеты ставить новые. Единственное, тогда еще не было курса №2 из другого ответа, поэтому я не использовал "селекторы". Но это не помешает вам погрузиться в мир redux.

    P.S. курс по react тоже есть.
    Ответ написан
    2 комментария
  • С чего и где начать обучению React, Redux?

    miraage
    @miraage
    Старый прогер
    От создателя Redux.
    И учите английский. Это на нем надо свободно разговаривать в нашей жизни.

    https://egghead.io/courses/getting-started-with-redux
    https://egghead.io/courses/building-react-applicat...
    Ответ написан
    Комментировать
  • Задачи по javascript?

    @RLatypov
    Ответ написан
    Комментировать
  • Есть ли инструкции по настройке сайта перед размещением в интернете?

    gr1mm3r
    @gr1mm3r
    50% ответа в правильном вопросе. Остальное мануал.
    Только внимательный и пытливый вопрошающий может найти в анналах хабра 2 чеклиста для размещения сайта.
    Чек-лист из 68 пунктов и
    Чек лист в комментариях от пользователя rebra боле...
    Переносить сюда по причинам огромного количества материала не буду.
    Ответ написан
    Комментировать
  • Как правильно технически организовать веб-разработку?

    IRC
    @IRC
    Django developer & Atlassian DevOps engineer
    - Dev & Production сервера понятно. Нужно ли делать локал-сервер у разработчика? Стоит ли физически разделять дев и продакшен или достаточно разных виртуал-хостов и баз данных?

    Зависит от масштаба проекта. На начальном этапе у разработчика всегда должна быть возможность проверить написанное локально -- это быстро и удобно. Как, например, в моем случае встроенный сервер Django. В будущем, когда проект становится большим -- можно прибегнуть к автоматизации этого процесса через среды сборки на тестовые стенды.

    Физически (как я понял по разным железкам) разделять dev и prod имеет смысл только тогда, когда это требуется для правильного функционирования системы (т.е. prod занимает ресурсы физического сервера на 70-80%).
    Когда дойдете до таких масштабов -- решение само придет. Сейчас идите по пути максимального сокращения расходов (VPS или один выделенный сервер в ДЦ).

    Кстати, советую сразу откинуть идеи (если такие появляются в команде) "да у меня дома комп мощный, на первое время потянет", т.к. переносить все равно придется в скором времени из-за ряда неудобств.

    А в качестве выделенного сервера хорошо подойдет https://www.soyoustart.com/ie/essential-servers/ с установленным VMware ESXi. Дальше уже крутите виртуалки какие хотите.

    - Где и какие делать репозитории кода? Никаких серверов у нас в офисе не будет и собственно самого офиса тоже ;)

    Путь 1: Github/Bitbucket в облаке
    Путь 2: GitLab/Bitbucket Server у себя на сервере.

    - Нужна ли специализированная task management (типа, Jira)? Сейчас используем для управления задачами WorkSection. Стоит ли для разработки использовать что-то отдельное специализированное? Я так понимаю, что та же Jira может отслеживать коммиты в git как процесс выполнения задач - это было бы круто!

    Нужна! И это должно быть с нулевого дня начала вашей работы. Иначе, когда зашьетесь в тоннах переписок в месенджерах и Google Docs'ах, будете вспоминать тот день, когда было лень потратить время на организацию работы.

    - нужен ли отдельный баг-трекер? Выделенных тестировщиков пока не предвидится.

    Для кого? Для пользователей вашим софтом? См. ответ выше.

    - Стоит ли использовать Scrum? Или просто тупо идти по задачам?

    Тупо идти по задачам никогда не получится. Нет такой самоорганизации у людей. Получите гораздо больше головной боли в решении косяков других людей в своей роли ПМ. Изучите методологии. Мы используем Scrum + TDD.

    - Нужна ли какая то вики для отдела разработки? Что туда записывать, чтобы это не было большим оверхедом для разрабов и имело реальную пользу.

    Нужна! Вот прям как трекер задач. И привычка туда записывать все по проекту тоже нужна. Разрабатываете API -- супер! Сначала опишите его в Вики, потом начинайте кодить. И все в таком духе. Все полезные ссылки по проекту, доступы к стендам и пр. -- все надо хранить не в переписке или облаках, а и именно в единой отправной точке.

    Еще удобно использовать тот же Confluence для проведения встреч. Там есть готовые шаблоны для этого. Позволяет легко фиксировать все вопросы и принятые решения.

    - Что еще забыл?

    Способы ведения проекта в Git забыли, такие как GitFlow.
    Контейнеризация от Docker для упрощения/ускорения работы разработчиков/тестеров/админов.

    PS. Еще один вопрос не могу понять: должны ли запросы на доработки софта идущие от других отделов проходить через меня как управляющего разработкой (я оцениваю целесообразность и ставлю задачу разрабам)

    Должны.

    или лучше чтобы они напрямую контачили с разработчиками?

    Напрямую с разрабом -- только для обсуждения уже поставленной в план задачи, а для постановки задачи -- с ПМ и всей командой (если Scrum)

    Не будет ли это с моей стороны лишней тратой времени?

    Это -- ваша непосредственная работа.
    Ответ написан
    2 комментария
  • Лучшие книги для изучения JavaScript в области разработки интерфейсов (Frontend)?

    dhat
    @dhat
    You Dont Know JS мне понравился (Я новичек). Кроме того, от этого же автора есть много видеокурсов на Frontend Masters.
    Ответ написан
    5 комментариев
  • На каком основании писать заявление при краже репозитария?

    iiiBird
    @iiiBird
    Пока ты спишь - твой конкурент совершенствуется
    не перестают удивлять начинающие стартаперы... ничего вы не докажете. смиритесь. если дело принципиальное и вам не лень выложить за все разбирательства и суды от 100к+ то вперед. может че и выйдет, а так советую вам забить. будет уроком в след раз все письменно оформлять и закреплять нотариально заверенными документами и договорами.
    Ответ написан
    Комментировать
  • Экспресс обучение frontend разработке. Как подступиться?

    @sarathorn
    php программист, веб-дизайнер, коллекционер
    Из SASS и LESS стоит выбрать что-то одно, в препроцессорах нет ничего сложного.

    Если речь о вёрстке макетов для небольшой вебстудии, то про все страшные слова по типу Angular, React, Backbone можно забыть, как и о необходимости в чём-то серьёзнее связки HTML+CSS+jQuery.

    Бустрап (любое другое творение для ускорения работы) будет плюсом не только для работодателя, но и лично для вас. Изучается за пару дней.
    Ответ написан
    3 комментария
  • Экспресс обучение frontend разработке. Как подступиться?

    webinar
    @webinar Куратор тега Веб-разработка
    Учим yii: https://youtu.be/-WRMlGHLgRg
    пункты 1,2 и 3 - обязательно
    4 - весьма опционально, зависит от работодателя. Иногда и вовсе не требуется. Желательно иметь общее представление, в идеале неплохо знать 1 из них. Сейчас весьма перспективен и популярен AngularJS
    5. - это backend. Да есть странные компании, которые требуют, но я бы их сторонился. Из этого неплохо было бы иметь представление о php и его шаблонизаторах, но достаточно весьма поверхностное для frontend.
    6. Еще не все требуют, но многие. Но опять таки для frontend достаточно понимать как "запулить реквест". Думаю на достачном для Вас уровне за день можно освоить.

    Добавить в список: svg, canvas. Желательно немного разбираться в google и yandex api (карты, плееры и т.д.)
    Ответ написан
    Комментировать
  • Как найти стабильную удалённую работу Web разработчику? Реально ли?

    saintbyte
    @saintbyte
    Django developer
    Чем крупнее предприятие тем долбанутей там руководство и меньше кайфа для разраба. Только стартапы только хардкор.
    Ответ написан
    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 комментария
  • Воровство дизайна, что будет?

    Sanes
    @Sanes
    Будет стыдно. Или нет?
    Ответ написан
    Комментировать
  • Какой Web-фреймворк для Node.js выбрать?

    Pinsky
    @Pinsky
    Кофеиноникотиновая смесь в backend-код
    Koa.js и Total.js посмотрите. Думаю Koa вам подойдет больше даже
    Ответ написан
    Комментировать
  • Возможна ли переквалификация в разработчики после 30 без профильного высшего образования?

    copist
    @copist
    Empower people to give
    Не будет смены специальности без потерь. К потерям надо готовиться. Семье надо объяснить причину смены специальности. Потери будут либо в деньгах, либо в свободном времени.

    В свободное (очевидно, внерабочее) время читать, смотреть, думать и делать pet projects - в этом я не оригинален. Иллюзий по поводу программирования питать не надо. У многих разработчиков 12-14 часой рабочий день, особенно у фрилансеров: 4-6 часов покодить + время на поиск новых заказов + время на общение с старыми/новыми клиентами + время на организационную деятельность + время на маркетинг самого себя. Офисные программисты работают несколько свободнее по времени, но уверен, что многие после работы ещё вштыривают проектик для себя или шабашат по мелким заказам.

    Хочу озвучить ещё четыре варианта.

    1. Мне известны уже несколько случаев, когда человек уходил на сдельную работу или на 1/4 ставки или на почасовку на основном месте работы и увеличивал количество часов на изучение второй специальности. Или устраивался на новое место на почасовку или на четверть ставки для стажировки, а то и на должность джуна. Сам так делал. Очень эффективно.

    2. Выходные, праздники и отпуск не для ремонта или отдыха, а для ускоренной реализации своих проектов. Я кучу людей знаю, которые работают без отпуска, включая махинации с увольнением/восстановлением, чтобы просто получить компенсацию и работать дальше. Не вижу ничего сложного в том, чтобы отпуск потратить на стажировку или самообразование. Если новая работа приносит удовольствие, то можно развернуть свои собственные мысли так, чтобы новая работа считалась отдыхом (самомотивация, аутотренинг, самогипноз - называйте как хотите). Не замечали, что 8 часов нелюбимой работы тянутся долго-долго, а 8 часов любимого занятия (хобби, увлечение) пролетают незаметно?

    3. Административный отпуск. Он, конечно, не оплачивается, но если подвернулось интересное дело, то можно попробовать, потрогать, пощупать, оценить свои ощущения и если не уверен - вернуться в своё уютное тёплое гнёздышко на старом месте работы. Административный отпуск хорош тем, что его можно устроить в любое время без согласования отпускных графиков и отказать в нём не могут. Так что сразу, как подвернётся интересное дело - можно с головой нырнуть, устроить себе интенсивное погружение.

    4. Попробовать совмещать должности на старом месте работы. Попросить руководителя дать несложную работу из соседнего отдела программистов. Я сам встречал маркетологов-программистов, аналитиков-программистов, менеджеров-программистов. Им просто это интересно. При этом зарплата будет прежняя, а может быть повысится - как договоритесь. Ещё можно уговорить послать на курсы переквалификации, организация оплатит и время и курсы - ничего не потеряешь.

    Ещё варианты плавного перехода придумать?

    Кто хочет - найдёт 1000 способов, кто не хочет - найдёт 1000 причин (Конфуций)
    Ответ написан
    6 комментариев
  • Возможна ли переквалификация в разработчики после 30 без профильного высшего образования?

    fedorez
    @fedorez
    Хатуль мадан
    Если вас это немножко подбодрит, могу сказать что это смог провернуть мой бывший командир корабля (я в прошлом офицер ВМФ, но быстро понял что ступил не на ту дорожку и вернулся к любимым с детства компам), капитан 1-го ранга, хорошо за 50... а командир корабля - это ещё и очень особенный клад и уклад сознания... у нас был старенький комп - селерон под Миллениум, на котором мы в свободное от вахты и печати отчётов время гоняли Диабло. Кэп увлёкся. потом со скуки начал читить - там можно было открывать файлы своего персонажа и что-то накручивать по его параметрам... через это начал ковыряться и изучать. Я ему книжек подкинул. Кэп скучал - за него службу тянул перспективный и роющий землю старпом. Потом я уволился, уехал. Потом сильно удивился узнав, что выйдя на пенсию кэп увлёкся программированием настолько, что купил макбук ретина и что-то разрабатывает под iOS, что-то морское специфичное и за деньги.
    Но правда там очень неслабая подушка безопасности в виде военной и более того, корабельной пенсии была...
    Но если уж человек после 50 смог - вы сможете после 30 однозначно)) вопрос организации.
    Ответ написан
    1 комментарий
  • Как правильно организовать push уведомления на сайте?

    BupycNet
    @BupycNet
    Основатель PushAll
    Лучше ещё уведомления при закрытой вкладке сделайте https://pushall.ru/blog/whatispushnotifications

    К слову - вполне реально сделать например в хром и Firefox вообще через service workers с Push API. Т.е. если вкладка открыта пуш может ещё и данные обновлять на странице. если закрыта - будет приходить оповещение на экран
    Ответ написан
    Комментировать
  • С чего начинается CI?

    akubintsev
    @akubintsev
    Опытный backend разработчик
    CI - это автоматизированная сборка проекта на основе версионного контроля и прогон тестов.

    Собственно, начинать надо с задачи реализации деплоя.
    Деплой сделать - задача нетривиальная. Есть для этого разные инструменты и универсального решения нет. Отладить процедуру деплоя нужно для сборок в CI и для продакшена/стейджа.
    Лично я для своего последнего маленького проекта для выкладки в продакшн выбрал deploybot.com - в принципе всё, что нужно есть, в том числе и хорошая интеграция с DigitalOcean.

    Что касается инструмента для CI, то из бесплатных обычно пользуются Jenkins. Я пробовал в последнем проекте PHP CI - тоже годно, но не настолько гибкий инструмент.

    Выкладку на продакшн/стейдж можно настроить по-разному. Например по коммиту в специальную ветку, по ключевым словам в коммите или вообще вручную. На прод однозначно стоит делать выкладку вручную.

    А, еще один немаловажный момент. Для успешного функционирования этого всего дела нужно внедрить версионирование схемы БД и фикстуры (для CI).

    Жизненный цикл у нас был такой. Тимлид определяет некий не большой, но и не очень маленький набор фич, которые должны попасть в новую версию приложения. Все тикеты связаны с версиями. И поэтому может случится так, что даже готовую фичу он определит в другую версию продукта.
    Каждая готовящаяся к релизу версия получает свою ветку в git и там делается мердж нужных коммитов с фичами. Каждый коммит автоматически тестируется в CI.
    Когда все фичи сделаны и коммиты слиты, то можно залить на стейдж сервер и погонять вживую версию в условиях близких к боевым. И наконец, если всё хорошо, то делается деплой на продакшн.
    Ответ написан
    Комментировать
  • Как эффективно изучать JS?

    Taraflex
    @Taraflex
    Ищу работу. Контакты в профиле.
    Конспекты пишите в тетрадку.
    Ответ написан
    1 комментарий
  • ООП в высоконагруженных проектах считается устаревшим?

    Adamos
    @Adamos
    Баланс.
    Если проект реально высоконагруженный, но простой, как табуретка - то человек прав, чем меньше в коде будет абстракций, тем меньше оверхеда.
    Но если проект не только высоконагруженный, но и сложный - вы мозг сломаете, делая его функционально. Функции хороши там, где нужны простые решения. Если вы можете разобрать всю архитектуру на простые решения - вам не нужно ООП. Если не можете - то без него проект захлебнется в собственной сложности.
    Ответ написан
    3 комментария