• Стоит ли начинать изучение Vue.js с посредственными знаниями javascript?

    evgensenin
    @evgensenin
    Yii2 || Laravel, vue & nuxt
    Даже с начальными знаниями JS можно войти во Vue, только основы нужно и правда знать хорошенько - работа с объектами и массивами, напрямую работать с DOM возможно и не придется, замыкания (да, но несильно), транспорт (ajax, fetch), главное аналитический склад и пытливость ума, читая от корки до корки доку по Vue и постоянно гугля непонятные слова в учебниках, на stackoveflow (или тостере) - можно хорошо прокачаться.
    Как инструмент, vue очень крут даже для новичков.
    Ответ написан
    Комментировать
  • Как подключить и использовать yandex maps в angular?

    jamesgoodwin
    @jamesgoodwin
    Молодой разработчик
    Логика работы с Яндекс.картами в Angular "без компонента" точно такая же, как работа с Яндекс.картами "без Angular"(в обычном html).
    Ответ написан
    2 комментария
  • Какой UI кит выбрать для Angular 9?

    Xuxicheta
    @Xuxicheta Куратор тега Angular
    инженер
    Материал считается стандартом и поддерживается людьми из команды Angular и называется Angular components. Можно взять вариант без дизайна - @angular/cdk
    Помимо него иcпользуют prime-ng, Clarity Design System, NGX Bootstrap, Nebular.
    Тут список https://angular.io/resources?category=development
    Ответ написан
    Комментировать
  • Как бэкенд-разработчику поднять свой заработок?

    @Kostik_1993
    Web Developer
    Есть такой тип людей, хочу всего, но ничего не меняя. Вот недавно написал мне какой-то кент из Украинского села мол памагите хочу войти в айти, кинул мне тестовое задании с вопросом за сколько мы сможем его разобрать. Я спросил чего он хочет добиться от этого и он мне выдал что он в IT никто и звать его никак, но он хочет найти удаленку и получать бабосики. Я ему ответил что ему нужен опыт, нужно устроиться, а он мне.. вобщем долго писать лень выдержка из чата.
    Обратите внимание сколько у него не хочу!
    5e518c6fcbbc3449869916.png
    5e518d08c7389774923961.png
    Ответ написан
    3 комментария
  • Как использовать laravel passport для restfull api?

    Как-то переводил для себя по правам доступа в passport https://docs.google.com/document/d/1Agg8WbiAKP8vfm...
    Техническая сторона в документации описана достаточно хорошо.

    Главное определится, будет ли иметь доступ только ваше приложение или ещё сторонние.
    Ответ написан
    2 комментария
  • Как грамотно реализовать мультиязычность React и Laravel?

    Alex_Wells
    @Alex_Wells
    PHP/Kotlin
    Храните язык в локалсторадже и локализируйте на фронте, средствами фронта. Бэкэнд о локализации знать не должен.
    Ответ написан
    1 комментарий
  • Как грамотно реализовать мультиязычность React и Laravel?

    neuotq
    @neuotq
    Прокрастинация
    Главный спорный вопрос который вам стоит решить: где хранить статичный первод (надписи, что не меняются или меняются редко, например название кнопки - Отправить/Submit, те все то, что мы обычно не храним в БД и редко меняем).
    Варианта два:
    1. Использовать только реакт для этого, тогда берете пакет react-localization, там достаточно простые и понятные принципы, сложностей нет.
    Преимущества: фронт полностью отдельно живёт и не зависит от бэкенда, нет дополнительных прослоек, нет привязки к определенному бэекенду и тп

    2. Использовать возможности локализации Laravel. Но тут все таки все методы той или иной степени костыльности, либо как минимум добавляющий жесткую привязку фронтенд приложения к текущему стеку бэкенда
    Преимущества: можно использовать разные пакеты для интеграции средств редактивования статической локализации в бэкенде.

    Лично я всё же склоняюсь к первому варианту, так как люблю писать максимально (желательно полностью) назависимые фронтенд приложения.

    Теперь вторая часть вопроса. Уже касаемо динамических переводов (это контент, комментарии, и тп, условно говоря всё что мы храним в бд, или храними информацию о них в бд).
    Здесь я советую положится на Laravel, берёте пакет от spatie laravel-translatable, он позволяет быстро строить удобные интерфейсы редактирования/чтения переводов в БД, пишете простое API и ри инициализации react приложения получаете данные нужные вам локализации, либо даже отправляете все сразу (они хранятся в json поле mysql/ваше БД, даже доп преобразований особо не потребуется).
    Но вариант с отправкой только нужной мне нравится больше, смена локали событие редкое, а вот экономия на размере переданных данных будет существенная.

    Ну, а далее уже вешаешь всякие кеширования тп, чтобы всё летало и готово.
    Ответ написан
    3 комментария
  • Что мотивирует IT специалистов кроме ЗП?

    Robur
    @Robur
    Знаю больше чем это необходимо
    до 30 - самоуверждение. норм денег, чтобы хватало на все, технологии покруче, все эти печеньки, звания, возможность ходить с гордым видом собственной важности и вообще.
    после 30 - возможность делать осмысленные вещи, понимать ценность потраченного на работу времени, профессиональный рост (не в плане изучения очередной новой технологии), принимать ответственность за решения и сознавать свой вклад в то на что тратишь свою жизнь. Все это работает когда комфортный уровень жизни к которому привык в период до 30 сохраняется естественно.
    Ответ написан
    4 комментария
  • Что мотивирует IT специалистов кроме ЗП?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    У меня лично деньги на первом месте. Кроме них мотивирует возможность профессионального роста и престиж выполняемой работы.
    Ответ написан
    Комментировать
  • Как верстаются блоки со сложным вырезом?

    RAX7
    @RAX7
    на SVG вырез можно сделать хоть в форме котенка
    Ответ написан
    4 комментария
  • Когда стоит разделять приложения?

    sarapinit
    @sarapinit
    Точу водой камень
    1 кейс.
    У вас есть запросы на которые нужно отвечать быстро (текущее состояние) и какой-то сервис с отчетами. Когда пользователи запрашивают большой отчет скорость ответа текущего состояния начинает проседать. Тогда вы делаете отдельный сервис для отчетов, выносите его в отдельное приложение и на отдельную виртуалку. Таким образом вы изолируете потребляемые ресурсы и устраняете влияние сервисов друг на друга. Плюс получаете возможность отдельно масштабировать сервис отчетов во времена наибольшей нагрузки.

    2 кейс.
    У вас есть сервис авторизации для которого нужно учесть множество разных требований и стандартов по безопасности. Вы привлекаете отдельную команду для его разработки с определенными навыками. В этом случае вы изолируете ресурс "навыки разработки безопасных сервисов" чтобы команда не тратила свое время на другие фичи.

    3 кейс.
    Вы делаете несколько сложных сервисов и решаете распаралелить разработку на несколько команд. Одна команда делает "Кинопоиск", другая "Афишу". Все они обращаются к серверу авторизации из кейса 2 и бекендам из кейса 1.

    Итог.
    Разделение на несколько приложений - это либо логическое разделение, когда приложения делают разные и несвязанные вещи. В этом случае удобно думать о разных задачах как о разных приложениях. Отдельно их разрабатывать, деплоить и т.д.
    Либо это управление вычислительными мощностями. Когда разные части системы требуют разделения ресурсов, нелинейного масштабирования или имеют совсем разный режим работы (например АПИ для загрузки фоток и асинхронный воркер который делает превьюшки для этих фоток)
    Либо это управление на уровне человеческих ресурсов, когда приходится вводить в разработку несколько команд.
    Ответ написан
  • По вине заказчика удалили сайт, теперь требует вернуть исходники?

    inoise
    @inoise
    Solution Architect, AWS Certified, Serverless
    Вы сделали работу и сдали все. Если у вас не было договора где вы должны поддерживать работоспособность этого сайта то можно смело послать человека. Можете также ему сказать что исходный код был передан ему полностью и удален для сохранения его правообладания
    Ответ написан
    Комментировать
  • Поступить в университет или пойти на работу после школы?

    Zoominger
    @Zoominger
    System Integrator
    В университет, без вариантов.
    Всё равно потом придётся идти, так что бросайте свои инфантильные отмазки в духе "ой, мне надо это, ой, да я зняю лючше" и вперёд, грызть гранит науки.

    Лично я за работу после школы, так как быстрее вольюсь в IT-сферу,

    Угу, а мы тут с распростёртыми объятиями ждём недоучек, которые даже в шараге не смогли выучиться и на честном слове говорят о своей компетенции.

    Дальше не читал, советую прислушаться.
    Ответ написан
    2 комментария
  • Почему некоторые люди утврерждают что плохо использовать jQuery?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Во-первых, jQuery родилась во времена, когда каждый браузер реализовывал JS и DOM API по-своему, её основным назначением было сглаживать эти различия. В наше время это преимущество библиотеки уже утеряно. Во-вторых, jQuery не соответствует основному вызову современности - сложной кодовой базе. В развитом фронте код, использующий jQuery, быстро превращается в трудно сопровождаемую лапшу. Поэтому для простого фронта чаще стали использовать ванильный JS, а для сложного фреймворки типа React, Angular и Vue.
    Ответ написан
    23 комментария
  • Где найти простой скрипт авторизации PHP7+MySQL+SESSION+COOKIES?

    Immortal_pony
    @Immortal_pony Куратор тега PHP
    Ответ написан
    Комментировать
  • Знания Junior php разработчика?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    что должен знать идеальный джуниор (мое личное мнение):

    - Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
    - GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
    - Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
    - PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
    - Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
    - Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
    - Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
    - Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
    - Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
    - Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
    - Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
    - Уметь дебажить. xdebug, blackfire и тд.

    В целом где-то за годик весь этот список можно влегкую покрыть с нуля.

    p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

    Так же вещи вроде docker джуниорам знать не обязательно просто потому, что их врядли допустят сходу к управлению инфраструктурой. А так пару неделек на изучение и вперед.
    Ответ написан
    12 комментариев
  • Архитектура приложения на vue?

    TaPO4eg3D
    @TaPO4eg3D
    Rust, Python
    Если так сильно беспокоит архитектура приложения, то могу посоветовать взглянуть в сторону Nuxt.js. Этот фреймворк будет форсировать структуру приложения, а заодно и общий код-стайл.

    Про наименования файлов написано в официальной документации Vue.js. https://vuejs.org/v2/style-guide
    Ответ написан
    Комментировать
  • Как бороться со стрессом на работе?

    Zoominger
    @Zoominger
    System Integrator
    Лол, добро пожаловать в веб-программирование. Оно немного не такое радужное и весёлое, как рисуют в статечках на Хаброчке и комиксах от XKCD, да?

    Мой совет - меняйте сферу и/или место работы. Начните со второго, очевидно, это какая-то веб-студия с бесконечным потоком.

    Нет, серьёзно, смените место.
    Ответ написан
    2 комментария
  • Как бороться со стрессом на работе?

    sfi0zy
    @sfi0zy
    Creative frontend developer
    Мозг каждый день кипит так же, как в первый день. Шаг влево шаг вправо, и вот, я уже ничего не знаю и ничего не умею... ощущение, что на работе я как будто не прогрессирую, а наоборот деградирую...

    У меня такое было, когда я только перешел во фронтенд и пытался держать слишком много деталей о языках и инструментах в голове. Со временем понял, что это не имеет смысла - все меняется быстрее, чем я запоминаю. Перешел от мысли "я использую инструменты" к мысли "я делаю штуки" и сразу полегчало, стал держать в голове только общие идеи о том, как что-то делается, или что вообще бывает в какой-то области, а конкретные инструкции по применению отдельных инструментов изучаю по ходу дела. Изменил фокус своего самообразования, если это можно так назвать. В результате все препроцессоры слились в один, новые библиотеки становятся все менее сложными в освоении, поскольку идеи везде плюс-минус одинаковые и.т.д. Решения стало принимать гораздо проще. И аргументировать тоже. Иногда складывается такое впечатление, что у нас в отрасли совсем ничего не появляется нового уже лет пять, а то и больше. Да, я забываю как использовать флексы, путаю call() и apply(), гуглю свои же ответы на тостере, но это не важно. Голова занята решением проблем, в ней теперь нет никакой второстепенной информации и это очень здорово. Статьи писать тоже полезно оказалось - написал, "поставил на полочку", и забыл. А если будет нужно - можно достать и посмотреть. Таким образом вот эта вся фигня с закипанием мозгов практически ушла.
    Ответ написан
    1 комментарий