Задать вопрос
  • На какой платформе лучше всего развертывать проект на Django?

    sergey-gornostaev
    @sergey-gornostaev Куратор тега Django
    Седой и строгий
    Если у вас количество серверов за десяток не выйдет и нет надобности быстро разворачивать новые чуть ли не ежедневно, вам не нужны Doker, Vagrant, Ansible. Вы — не Google.
    Ответ написан
    4 комментария
  • Организация работы с базой данных в docker?

    skobkin
    @skobkin
    Гентушник, разработчик на PHP и Symfony.
    1. Шарите дамп базы в контейнер (копировать не стоит, т.к. из-за слоёности образов, контейнер может получиться слишком жирным).
    2. При сборке запускаете наполнение БД (pg_restore database.dump / mysql < database.sql)

    А ещё, если работаете с Doctrine, то можно создавать БД средствами ORM и наполнять фикстурами.
    Ответ написан
    2 комментария
  • Рисование графиков, есть ли интересная статья или пример?

    dummyman
    @dummyman
    диссидент-схизматик
    Из jquerийных простенький morris и посложнее flot.
    Для Анжелы n3. Для любителей Ember Charts.
    Простенькие ChartJS и uvCharts.
    Очень легкий и хорошо разжеванный ChartList.
    Не менее хорошо разжеванный, но платный, ZingChart.
    Поддержку legacy обеспечит FusionCharts - обещают работу на IE6.
    Профессионалам понравится список фичей plotly.
    Вы бы конкретнее указывали какие графики вам нужны. А то все не подходят, а что нужно - секрет. Хотите создавать свою систему - читайте исходники существующих. - Врятли любая статья будет лучше и более полной чем исходники рабочих библиотек.
    Ответ написан
    5 комментариев
  • Как обновить страницу через AJAX в DJANGO?

    tema_sun
    @tema_sun
    Во вьюшке:
    def post(self, request):
            create_form = BookForm(request.POST)
            if create_form.is_valid():
                create_form.save()
                
            response = {"data": "goes here"}
    
            return HttpResponse(json.dumps(response), content_type='application/json')


    В js'e:
    $.ajax({
        method: 'post',
        url: your-url,
        data:  serialized-data
    }).done(function(response){
        console.log(response.data)
    });

    Ну или что-то аналогичное, если jquery не используете.
    Ответ написан
    6 комментариев
  • Как получить индекс итерации?

    Из вопроса не очень понятно что нужно сделать.
    3.4.5 Рендеринг коллекций
    С индексом
    Надеюсь это поможет.
    Ответ написан
    1 комментарий
  • Что посоветуете еще подучить что бы тянуть на Junior PHP разработчика?

    Я бы не назвал ваш уровень Junior. Если вы в состоянии самостоятельно
    - развернуть девелоп-среду
    - вести гит
    - писать код и обкладывать его тестами
    - настроить деплой

    то значит, в состоянии самостоятельно ставить себе задачи. А это уже на Миддла тянет )
    А у Миддла способ развиваться только один - практика. Самообучаемость, как видно, присутствует. Не зацикливайтесь на парадигмах, фреймворках и ЯП - берите проекты и выполняйте их
    Ответ написан
    1 комментарий
  • Как вывести статью только один раз?

    @rorc
    Удалить через шаблонизатор дубли здесь будет затруднительно, если это действительно нужно то лучше использовать обработку на этапе views, удалив дубли или выводя статьи через шаблонный тег, в коде которого проверять на совпадения.

    Архитектурная ошибка уже допущена на этапе проектирования url. {% url 'articles' article.slug article_page.slug %}. В любом случае будут дубли, т.к. адрес url будет /cat1/article /cat2/article/

    Способов избавиться от них два:
    1) Статьи отдельно, категории отдельно. /url/catalog/name /url/article/name
    В этом случае даже если выводится одна статья несколько раз, url уникален
    2) Одна главная категория, url на основании этой категории. Остальные категории второстепенные, отдельным списком.

    Для чего два вложенных цикла сделали тоже не очень понятно, обычно один цикл и url на основе запроса данных из таблицы по ключу.
    Ответ написан
    1 комментарий
  • Что посоветуете еще подучить что бы тянуть на 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 комментариев