• Что посоветуете еще подучить что бы тянуть на Junior PHP разработчика?

    gobananas
    @gobananas
    finishhim.ru
    Да всё у вас в порядке для джуна, дальше только опыт. Всё правильно выше сказали про требования конкретной компании - этого не угадаешь. Где-то mongodb нужен где-то postgresql где-то трейты юзают и php7 а кто-то на 5.3 сидит ещё. Ваших знаний считаю достаточно.
    Ответ написан
    Комментировать
  • Что посоветуете еще подучить что бы тянуть на Junior PHP разработчика?

    @Fortop
    Tech/Team lead
    Для джуна уже более чем неплохой стек (при условии, что действительно знаете, а не думаете, что знаете)

    Так что есть смысл расти выше к мидлу.

    • Подтянуть использование ООП (те самые абстрактные классы и интерфейсы).
    • Обязательно Composer, посмотреть некоторые пакеты которые есть на packagist
    • Разобраться в key-value БД, очередях.
    • Познакомиться с патернами.
    • Добрать еще 1-2 фреймворка из разряда Zend/Symfony (но не Yii, Codeigniter, Kohana) и Slim/Zend Expressive
    • Разобраться с REST
    • API
    Ответ написан
    7 комментариев
  • В программисты или в тестировщики (идти)?

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

    Людей с улицы сейчас очень много, так что конкурировать будет с кем. Если человек покажет себя перед работодателем как человек с хорошими теоретическими знаниями, который не только знает, но и понимает: как, где и когда эти знания применять, человек, который не просто хочет "войти в айти", а действительно желает работать и развиваться в области тестирования ПО, то у такого кандидата есть все шансы.

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

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

    saboteur_kiev
    @saboteur_kiev Куратор тега Программирование
    software engineer
    Нужно понимать, что "люди с улицы", обычно подразумеваются как люди без айтишного бэкграунда, без адекватного образа мышления. Даже при всем желании, такие не смогут вырасти до хорошего специалиста в силу отсутствия таких качеств, как любопытство, умение концентрироваться на задачах, желание вообще разобраьтся как это все работает. Поэтому если такой и устроится, и даже сможет выполнять служебные обязанности, врядли будет расти как специалист.

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

    10 лет назад тестировщиком было устроиться проще, компании, которые начали специализироваться на тестировании и компании, которые вводили у себя профессиональное тестирование, находились в начале своего активного роста. Профессия, особенно в странах СНГ, как таковая была еще не очень устоявшаяся.

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

    Куда вам идти выбирать лично вам. Работать можно вообще в любой сфере, где вы можете работать.
    Ответ написан
    Комментировать
  • В программисты или в тестировщики (идти)?

    x67
    @x67
    Какая работа по душе, туда и идите. Если бы грузчики получали больше инженеров (а иногда так и есть), я бы все равно не пошел работать грузчиком потому что не люблю рутинную монотонную изнурительную работу. С другой стороны, кто-то не любит напрягать мозг - он идет грузчиком. Это ничего не значит, просто каждому свое. Из своего опыта добровольного и бесплатного опыта бета-тестера могу сказать, что это рутинное и неинтересное занятие, от которого сильно тянет в кроватку. Но есть прекрасные тестировщики, балдеющие от своей работы. Кто прав? Тот кто сделал для себя правильный выбор.
    Ответ написан
    Комментировать
  • Как постепенно внедрять vue.js?

    leahch
    @leahch
    3D специалист. Dолго, Dорого, Dерьмово.
    С аяксами достаточно просто, я использую библиотеку axios.js.
    Я сейчас тоже перевожу свой проект на vue, постепенно его изучая. Все, что можно, отдается по ajax, все что должно быть в рамках SEO, отдается со стороны сервера, со стороны vue, использую привязку к модели или вызовы по v-click и подобным. Для какого-то интерактива, использую пользовательские директивы. Например кастомная директива связывает конкретный товар из списка товаров с его показом, если он есть в корзине, которая загружается по аякс. В общем, сначала ломал себе мозг, как связать список товаров на странице с корзиной, вот нашел очень хорошее решение -пользовательская директива, и для СЕО хорошо, и интерактивно в обе стороны, и с элементом можно творить все что угодно.
    Сейчас делаю пользовательскую директиву, которая подменяет href в ссылках пагинации, на параметры фильтров, которые рисуются через компоненты vue.
    Ответ написан
    3 комментария
  • Как отправить письмо в Mailgun?

    IvanTheCrazy
    @IvanTheCrazy
    Это же Rails, а значит это скорее всего сделано за вас: https://github.com/jorgemanrubia/mailgun_rails
    Настраиваете, а потом отправляете обычным способом через ActionMailer
    И mailgun - это сервис для отправки транзакционных email, тут подписки не требуются (только в тестовом режиме - в нем вы можете отправлять email только на подтвержденные адреса)
    Ответ написан
    2 комментария
  • Почему говорят что jquery не нужен?

    ThunderCat
    @ThunderCat Куратор тега JavaScript
    {PHP, MySql, HTML, JS, CSS} developer
    Скрипач не нужен, родной (с)
    Аргументы против jq:
    - современные браузеры достаточно хорошо поддерживают единый синтаксис современного екмаскрипт(native js)(на самом деле нет).
    - сторонняя библиотека, работает медленнее чем натив и в основном состоит из с-сахара (тоже не совсем правда)
    - тащить еще один ресурс весом от 64 кб до 200 кб, еще и со сторонних ресурсов замедляет загрузку( правда, но бред)
    Аргументы за:
    - Современные браузеры как и всегда один другого "ровнее", всегда есть косяки и "нюансы", на которые еще и попадаешь обычно в самый неподходящий момент, в жк обычно все работает одинаково везде, ну или лучше чем в нативе.
    - В жк реализована куча плюшек в 1 функцию которые в нативе занимают "многабукав", не каждый начинающий напишет их правильно, да и профи не все напишут оптимально, уверен что в большинстве случаев написанный нативом функционал будет хуже аналога из жк.
    - размер мин пакета жк 64 кб, и все они лежат на быстрых цдн серверах. Думаю это последнее что может повлиять на скорость загрузки страницы.
    - есть ОГРОМНОЕ количество скриптов написанных с учетом жк, не использовать их глупо, писать свой велосипед - вообще только в целях обучения(не берем крайние случаи когда плагин писал упоротый пингвин).
    - Синтаксис и краткость записи - вообще вне конкуренции.
    - Старые браузеры никто не отменял, часто заказчик требует чтобы работало в ие8, натив не канает или доставляет море анального удовольствия.
    Вывод: Если ты крут в жс, еще и работаешь в ангуларе/ещечетамдляфронта и тебе нужно сделать 2 действия в очень современных браузерах - jquery не нужен, и ты это сам знаешь. Если слова ангулар, вуе и проч для тебя не больше чем шум листвы за окном, а навесить плагинов и эффектов нужно - jquery наше все.

    UPD: для всех кто там отписался а ля "в связи (...), исчезновением проблемы совместимости со старыми IE (что и было основным назначением jQuery)." - свежачок
    Ответ написан
    4 комментария
  • Сделал RESTful API, что дальше?

    ajaxtelamonid
    @ajaxtelamonid
    Laravel
    Да, это делается для клиента. Клиент может быть браузером, мобильным приложением, веб-приложением другого разработчика, который получает от вас данные по api и т.п.
    В браузере html из полученного json делается при помощи javascript-фреймворков (vue.js, react.js). В мобильных приложениях - внутренними средствами языка, там тоже html не нужен. Тому, кто берёт у вас данные - тоже html не нужен.

    Прежде чем писать RESTful API вам следовало понять, какую задачу вы хотите решить.
    Ответ написан
    Комментировать
  • Cakephp3 admin plugins?

    @shell_execute
    Вам стоит обратить внимание на репозиторий, который ведет разработчик CakePHP - awesome-cakephp.

    Несколько ссылок из этого репозитория:
    Users plugin
    CakeManager plugin
    Dashboard plugin
    Ответ написан
    Комментировать
  • Что лучше выбрать из Zend Framwork 3 для портала MVC или Expressive?

    @novrm
    Вы забыли указать ваш уровень познания Zend Framework.
    Если вы начинающий - реализовать портал (с модулями блога, магазина и скорее всего еще какой-то хотелки - на поддоменах, но в рамках 1 проекта) на Zend Framwork 3 - извините - это для вас будет неподъемная задача.

    Если у вас средний уровень знаний по Zend Framework - пишите на Zend Framework 3.

    Если вы считаете себя асом - можете писать на Zend Framework Expressive.

    Дело в том, что к Expressive мало сторонних модулей. Вам все придется писать самому.
    Ответ написан
    Комментировать
  • Проект на ZF1 - как перейти на более новый фрейм?

    @AlexndrNovikov
    Solution Architect in Spiral Scout
    Многое конечно зависит от специфики проекта, но примерный алгоритм действий в общем случае такой:

    1. Выбираете новый фреймворк (или без него, на ваше усмотрение). Решаете делать новый функционал на нем и только на нем. ZF2/3 ли, Symfony, Laravel - разницы никакой, что вам нравится. Готовьтесь к тому, что придется бизнес логику переписать полностью (если интеграция с фреймворком была жесткой, как обычно делают PHP разработчики). Если была завязанность на абстракциях и модульная структура - вас можно поздравить, переход будет безболезненным и быстрым.
    2. Приготовьтесь, что работы станет больше, чем просто на ZF1 задачи решать и дальше. Постарайтесь не просесть слишком по производительности.
    3. Есть список URL, перенесенных в новое приложение. Решение о том, какому приложению отдать обработку запроса, находится в точке входа в приложение. (в index.php, например. Т.е если обычно там происходит просто инициализация приложения, то перед ним теперь должна быть бизнес-логика определения, какому приложению дать ход, этакий свой мини-роутер. Если переписано - отдаете новому приложению. по дефолту старому)
    4. Если у вас не было тестов - именно тут вы начнете понимать, почему они были нужны :)

    Ну и по факту получается, что у вас некоторое время будет 2 приложения, которые надо параллельно разрабатывать. Старое помечаете как немодифицируемое. Приходит задача - сначала переносите ее на новый фрейм, тестируете, если работает как надо - в своем мини-роутере направляете соответствующие запросы в новое приложение. Постепенно с 0% до 100% доводите - и можно выкидывать старый фреймворк и микро-роутер в индексе, вы переехали.

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

    Wolfnsex
    @Wolfnsex Куратор тега PHP
    Если не хочешь быть первым - не вставай в очередь!
    Изучил весь httpd.conf, перекопал кучу гайдов по highload (они старые и с сомнительными советами типа "отключить лишние модули"
    Один из первых модулей, который стоит отключить у Apache'а, для скорости - это поддержку файлов .htaccess, сама эта поддержка производительности не добавляет, а наличие этих файлов - уж и подавно.

    1) Это у всех VPS так называемый "мощный" процессор медленнее, чем на каком-то жалком хостинге, пусть и с VIP-тарифом?
    Нет, возможно это у Вас, персонально, какой-то дрянной VPS-хостер, или того хуже, тариф аки "OpenVZ, мы не перепродаём проданные ресурсы... ну разве что раз 10, но больше не перепродаём"

    2) Поможет ли в такой ситуации FastCGI?
    FastCGI - это режим работы PHP, напрямую, на производительность в значительной степени он не влияет, более того, сама логика работы FCGI (если сравнивать Apache-FCGI и Apache-mod_php) будет медленнее, по тому как для взаимодействия FastCGI будет использоваться сокет ("обычный" или unix-сокет), что подразумевает сетевое взаимодействие, вместо непосредственной работы интерпретатора PHP "внутри" сервера. Думаю, Вам поможет несколько другое (постараюсь описать ниже).

    3) Почему не популярны фишки типа eAccelerator (кеширование AST и т.п.)?
    Понятия не имею, почему они не популярны и откуда у Вас такая статистика... Но, возможно, дело в том, что eAccelerator морально и физически устарел, и если верить например, вот такой банальной статье (нет, я не работаю с такой "шедевральной" CMS как "Битрикс", просто это первое упоминание про eAccelerator, которое пришло мне в голову) - с версиями PHP выше 5.3 не работает.

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

    4) Что еще может помочь?
    Ну так, сходу, по памяти (варианты могут быть не связаны между собой):
    1. Отказ от поддержки .htaccess в Apache или хотя бы сокращение их количества
    2. Установка Nginx в качестве фронтального сервера, для отдачи статики
    3. Полный отказ от Apache вообще и переход на Nginx+FCGI (только не подумайте, я очень люблю Apache за его гибкость в настройке и широкие возможности, другой вопрос, что мало кому эта гибкость фактически нужна и мало кто способен его грамотно, качественно и полноценно настроить... Nginx в этом плане будет куда попроще). Почему FCGI? По тому, что другой приемлемый способ взаимодействия Nginx'а с PHP мне не известен. Настройка FCGI-пула - обязательна.
    4. OpCache - с версии 5.5 встроено "искаропки", к включению и настройке - настоятельно рекомендуется. Я не знаю, как обстоят дела с CMS и используете ли Вы CMS на сайте, но из моей практики, скорость работы PHP-фреймворков возрастает в среднем 8-20 раз.
    5. HHVM, как альтернатива
    6. Проверка:
    а) Того, что дело действительно в PHP. В частности, стоит собрать все логи сервера, например, сколько длились запросы, в БД, их количество и так далее.
    б) Проверка скорости работы дисковой подсистемы... Не буду "тыкать пальцем", но одно время я арендовал довольно большое кол-во VPS'ок у одного популярного хостера, и в какой-то момент, я заметил, что средняя скорость работы дисковой подсистемы - 1.4Кбайт/сек., при этом "отказы" (аки "невозможно записать блок") были примерно в 50% случаев... это продлилось не очень долго, но и через несколько месяцев, у этого же хостера, тарифы с "обычным HDD", почему-то обладали более быстрой дисковой подсистемой, нежели тарифы с "быстрыми SSD"... можно сделать выводы...
    в) Проверить реальную скорость работы процессора, не редко она отличается от завяленной достаточно сильно.

    P.S. Если Вы сформулируете вопрос(ы) более точно - я смогу дать более точные рекомендации, если конечно они Вам нужны :)

    P.P.S. Есть вариант решения проблемы вообще "в лоб", самый наверное сложный и пожалуй самый производительный в ряде случаев. Это Varnish + тонкая настройка оного, позволяет выдавать большую часть страниц из кэша (оперативной памяти) за наносекунды, иногда позволяет обслуживать очень много тысяч запросов в минуту, при этом, это не просто кэширование кода или что-то подобное... это кэширование целиком страниц и/или ответов сервера. Среди прочего - позволяет "не трогать бэкенд вообще", т.е. при запросе страницы, может не быть ни обращений к БД, ни выполнения того же PHP (или любого другого) кода, на стороне сервера. Требует довольно тонкой настройки, не очень подходит для сайтов "на CMS", для сайтов на фреймворках - требует изначально корректного подхода к разработке и продумывания того, что и как будет/должно кэшироваться. При некорректном подходе - наиболее вероятный результат - работать будет, но не так быстро как хотелось бы, а часть сайта вообще может перестать нормально функционировать. Есть так же другие решения, но с учётом довольно общих формулировок вопроса - говорить о них довольно сложно.

    Ах, да, забыл важную деталь... Почему "хостинги" используют Apache и не откажутся от него (совсем)? В большей степени по тому, что Apache позволяет делегировать часть настроек пользователю через .htaccess. При этом, для статики не редко стоит всё тот же Nginx, который, как Вы понимаете, подобным образом делегировать часть настроек пользователю не позволяет, в виду чего для этих задач не подходит и не "буксует" на этом (в отличии от Apache'а). В т.ч. и по этому, мы на 99% отказались от "хостингов" (по причине наличие Apache'а, и невозможности от него избавиться или самостоятельно настроить, и как следствие "тормозов" которые приходят вместе с подобным подходом).
    Ответ написан
    5 комментариев
  • Что с Mikrotik?

    icCE
    @icCE
    youtube.com/channel/UC66N_jRyZiotlmV95QPBZfA
    >
    MikroTik-CRS125-24G-1S-RM


    Не надо использовать Switch как роутер. Тем более слабый, тем более с bonding.
    Все ресурсы у него будут уходить на CPU. Это Switch !!!
    Посмотрите на его блог диаграмму. Вы уже не первый кого я встречаю, кто из 125 делает роутер.

    CRS125-24G-1S-160620160458.png

    Вот буквально в этом месяце в мерседес центре видел. При этом у них есть в наличие 2011.
    Ответ написан
    21 комментарий
  • Django конвертация timezone?

    @clopik
    Вам необходимо установить библиотеку pytz. А далее можно использовать код вида:

    import pytz
    
    from django.utils import timezone
    from django.views.generic import TemplateView
    
    
    class PageView(TemplateView):
        template_name = 'page.html'
    
        def get_context_data(self, **kwargs):
            context = super(PageView, self).get_context_data(**kwargs)
            context['dt'] = timezone.datetime(2000, 12, 31, 12, 0, 0, tzinfo=pytz.UTC)
            return context

    И далее в шаблоне:

    {% load tz %}
    
    {% timezone "Europe/Paris" %}{{ dt }}{% endtimezone %}
    Ответ написан
    1 комментарий
  • Git: Что следует добавлять в гитигнор при работе с Django?

    fox_12
    @fox_12 Куратор тега Django
    Расставляю биты, управляю заряженными частицами
    В папки окружения что-либо вносить - плохая идея. К примеру вашу модель User чудесно можно переопределить или наследовать не трогая окружение django.
    Ответ написан
    1 комментарий
  • Какие расширения входят в ваши "джентельменские" наборы для Битрикс, Joomla и WordPress?

    Punkie
    @Punkie
    Wordpress:
    Advanced Custom Fields - Управление кастомными полями, важнейшая штука. Даже купил PRO версию с developer лицензией
    Akismet - фильтр спама для форм на фронтэнде
    Custom Post Types UI - Удобное управление кастомными типами записей и таксономиями
    Duplicator - Удобнейший плагин для бекапов
    Cyr to Lat - автоконвертация ссылок в латынницу
    FakerPress - генерация "рыбного" наполнения сайта. Важно для тестов пагинации и т.п.
    Regenerate Thumbnails - Плагин, который принудительно пересоздает нужные размеры картинок по запросу. Важнейшая штука при создании темы.
    Reveal Template - Полезный плаг, который показывает текущий используемый файл шаблона во время разработки темы.
    WPML - универсальная платформа для внедрения мультиязычности в сайт. Платный.
    Contact Form 7 - самый лучший плагин для контактных форм на фронтэнде.
    Ну и WooCommerce, если это магазин.

    Из полезных сайтов:
    https://codex.wordpress.org/ - официальная документация по Wordpress
    https://css-tricks.com/snippets/wordpress - хорошая подборка полезных сниппетов
    https://generatewp.com/ - полезнейший сервис генерации кода для вставки в тему. Избавляет от изнурительного процесса гугления рутинных штук.
    Ответ написан
    1 комментарий
  • Сколько придется создать моделей и отношений?

    class Category(models.Model):
        parent = models.ForeignKey('self', null=True)
        title = models.CharField(...)
    
    class Product(models.Model):
        title = models.CharField(...)

    Яблоко Гольден, это товар категории Фрукт, подкатегории Яблоко, подподкатегории Гольден.
    Гибрид, это подкатегория имеющая две родительские категории. Следовательно: parent = models.ManyToManyField('self', null=True)

    Лучший сорт - это просто булевое значение ->
    # in class Category
    is_best = models.Boolean(default=False)
    Ответ написан
    2 комментария