Задать вопрос
  • Веб-разработка - знаю что хочу, но не знаю с чего начать?

    Murmurianez
    @Murmurianez
    JavaScript Developer
    Во фронте базовый стандарт такой:
    js, jquery, css(LESS, SASS или что-нибудь подобное на базовом уровне), requirejs, bootstrap(Я предпочитаю Foundation, но CSS-фреймворки далеко не для всех проектов - обычно на старте добавляю, потом постепенно выпиливаю), backbone(если хотите больше времени тратить на разработку, а не бодание с фреймвороком - выбирайте его, а не Angular, Ember...), React привлекателен, но сам пока не пробовал.

    Backend - если совсем PHP не знаете и пофиг что учить - лучше возьмите Python или Ruby (сам не пробовал, но поступил бы так, если бы не node.js=)))
    Ответ написан
    3 комментария
  • Как брать заказы на назработку сайтов, со своeго сайта, eсли нeт портфолио?

    MikhailDobriy
    @MikhailDobriy
    Dirty Little Helper
    Ни в одном из реализованных мной заказов не фигурировало моё прошлое портфолио.
    Все заказчики заинтересованы в своих целях и поставленных задачах, а не в том, чё и где вы кому-то сделали (во всяком случае так мне показывает мой опыт).

    Главное определите для себя ниши проектов. Самое приятно работать над теми сайтами, где вы что-то да вдупляете или искренне любите. Например, если вы любите мобильные игры, то заказчик сайта по проекту игры охотнее будет работать с вами, если вы проявите свой личный интерес и азарт в их проекте не только в погоне за баблом, но и в погоне за крутым расширенным результатом. Такой заказчик не будет смотреть какие вы крутые сайты делали для постельного белья, теплообменников или квартир в Северодвинске =)
    Ответ написан
    Комментировать
  • Зачем нужен RESTful API?

    gadfi
    @gadfi
    https://gamega.org
    Я не хочу вас обидеть и не могу давать оценку вашим професиональным навыкам по одному посту, поэтому не принимайте ниже написанное на свой счет.
    Это в целом распространенная проблема в индустрии, имя которой фреймворкоорииентированные программисты ─ странный вид разработчиков которые думают не категориями алгоритмов, патернами или технологиями, а категориями фреймвокров, не задумываясь что под капотом и как это работает (я не отрицая нужность фреймворков и не призываю писать все с нуля, это другая крайность тру программистов).
    Я понимаю назначение REST, но я пока не нахожу смысл его использования Django. Так как существуют дефолтные методы обработки информации таких типов как json, xml, yml...

    Вы не совсем верно понимаете что такое rest, это не просто json/xml формат данных. Вам никто не мешает вместо модуля rest api использовать стандартный модуль для работы с json (ровно как и написать его самому) и реализовать апи руками, без дополнительных модулей.
    Если совсем коротко то REST это делать все максимально понятно и просто, так чтоб даже без документации было все понятно. CRUD прекрасно ложиться на HTTP-методы GET, POST, PUT и DELETE

    Как вы правильно сказали это просто архитектура, нужна она вам в вашем проекте или нет решать вам. А что до кода ... ну не будете вы использовать готовый модуль, но к тому что нужно описывать модели и тд все равно придете, да это не обязательно и можно не делать так как то что творится у вас не сервере клиент не знает, все что он должен знать это документация, но вам же этот код поддерживать.
    Ответ написан
    Комментировать
  • Зачем нужен RESTful API?

    @marazmiki
    Укротитель питонов
    Вы вот тут про REST пишите, а имеете в виду, вероятно, django-rest-framework (лучшее, на мой взгляд, существущее решение для организации RESTful API для джанги).

    Для начала ответьте себе на вопрос: а нужен ли вообще API Вашему сайту. Если объективно нужен (например, с сайтом взаимодействует мобильное приложение, причём не только читает данные, но и отправляет; или фронтэнд построен таким образом, что от сервера требуются только данные, а отрисовка HTML происходит на клиенте; или Вы предоставляете информацию "неживым" пользователям — роботам), то RESTful API хороший выбор. И DRF, соответственно, тоже.

    Если всего этого нет и Вас вполне устраивает схема, когда бэкенд генерирует весь HTML и отдаёт его клиенту, то DRF, REST, да и вообще API в целом не нужны.
    Ответ написан
    1 комментарий
  • Как брать заказы на назработку сайтов, со своeго сайта, eсли нeт портфолио?

    marina_k
    @marina_k
    Веб-разработка
    В сети можно найти много проектов, которые реализованы плохо или устарели, но имеют популярность и трафик. Предложите владельцам таких ресурсов переделать их бесплатно или за рекламу. Будет кейс, будет опыт, будет серьезный выполненный проект. Просто как идея.
    Ответ написан
    Комментировать
  • Как брать заказы на назработку сайтов, со своeго сайта, eсли нeт портфолио?

    demavair
    @demavair
    Однажды когда я создавал рекламное агентство, я поступил следующим образом. Собрал команду из 9-ти человек и предложил им сотрудничать со мной в производстве видеорекламы, на что они согласились, после чего я попросил их выслать мне все их работы. И так у меня собралось более 50 работ, среди которых были крутые рекламы. Поступайте также. Вероятно у вас есть, люди с которыми вы сотрудничаете. Соберите все их работы и возьмите согласие, что вы будете их показывать клиентам. Желаю удачи!
    Ответ написан
    Комментировать
  • Как в WP сгенерировать миниатюру с первого изображения в галерее в посте?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    WP генерит все размеры для изображений (в том числе и миниатюры) при загрузке. То есть, если картинка уже у вас вставлена в галерею в пост - миниатюра к тому времени давно сгенерирована. Вопрос в том, как ее получить. А это совсем не сложно:
    if( ! has_shortcode( $post->post_content, 'gallery' ) ) :
        $images = get_post_gallery_images( $post );
    endif;

    Теперь в переменной $images у вас массив URL всех изображений в галерее. Как вытянуть первое, думаю, понятно. Как получить нужный размер - тоже.
    Ответ написан
    1 комментарий
  • Что должно быть в серьезном ТЗ?

    @oganesyankaren
    Технический писатель/аналитик
    У вас отсутствует четкая структура ТЗ. Я предложил бы вам 2 варианта переделывания:

    1) Быстрый. Добавить в начало ТЗ разделы про цель интернет-магазина (зачем он нужен) и задачи, которые предстоит решить для достижения цели. Дальше описать структуру ИМ, далее описать каждую страницу структуры - какой функционал должен быть, как должен работать интерфейс и т.п. После описания страниц разместить прочие, важные в рамках вашего проекта требования: SEO, мультиязычность, перенос данных (если есть), админка, верстка, и т.п.

    2) Менее быстрый. Все тоже самое, что в п.1 +
    добавить раздел с описанием используемых в ИМ сущностей, списков, функциональных возможностей, например:
    -Тип данных "Новость", атрибуты "Заголовок (строка)", "Содержимое (html)";
    -Список "Новости", состоит из новостей (тип данных "Новость"), сортировка по дате по убыванию.

    А в описании страниц сослаться на соответствующие сущности, списки, и функциональные возможности, например:
    Страница "Новости" должна включать в себя одноименный список. Каждый элемент списка должен являться ссылкой на страницу соответствующей новости.

    Это позволит лучше проработать логику проекта, выявить спорные и неоднозначные моменты на этапе проектирования.

    С другой стороны важно отметить, что если ТЗ в текущем виде гарантированно обеспечит одинаковое понимание всеми участниками проекта, и учитывает все необходимые моменты, то оставляйте в таком виде, зачем вам делать лишнюю работу.
    Ответ написан
    Комментировать
  • Как брать заказы на назработку сайтов, со своeго сайта, eсли нeт портфолио?

    Ashlst
    @Ashlst
    Фанат эстетики и красивых решений.
    Добрый день.
    Иногда,подрабатываю фрилансом. Портфолио,как такового,нет. Первый заказ взял благодаря тому,что сделал небольшое демо и отправил его заказчику (модуль для opencart). Я считаю,что главное показать заинтересованность проектом,но если есть портфолио это огромный плюс.
    Также согласен с Василий по поводу:
    сайт нужен для того что бы потенциальный, обработанный, убежденный клиент уже готовый тратить деньги глянул реквизиты куда своё бабло переводить. Ну еще потом отзыв оставить.
    Ответ написан
    Комментировать
  • Что должно быть в серьезном ТЗ?

    @NETChaser
    Что-то как-то все размазано... и не систематизированно...
    Ничего не написанно про workflow магазина, ничего про интерфейсы для работников, а это самое главное.
    Про интеграцию с бухгалтерией.
    Мультиязычность? Какая? Только интерфейс или Каталог товаров тоже должен быть мультиязычным?
    Вообщем ещё надо заказчика пытать ещё долго в плане требований... и если вы профи лучше не упоминать
    вещи касающиеся технологий (в большинстве случаев JavaScript, Flash, HTML5, Кодировка и DOCTYPE
    Кроссбраузерность Микроразметка, микроформаты и микроразметка для заказчика пустой звук)
    Так же заказчика будет интересовать насколько эффективен workflow, что бы нанимать работников поменьше.
    Ответ написан
    Комментировать
  • Что сейчас в тренде в мире PHP CMS и фреймворков с точки зрения правильной архитектуры и реализации?

    afi13
    @afi13
    Все зависит от поставленной задачи, сделать многоязычный каталог гораздо проще и быстрее на Drupal, e-commerce на Prestashop или другой CMS заточенной под магазины, серьезные крупные проекты лучше делать на фреймворках Symfony, Yii, Laravel. Но делать сайт-визитку с помощью Symfony - это стрелять из пушки по воробьям. Для каждой задачи свой инструмент.
    Ответ написан
    2 комментария
  • Что сейчас в тренде в мире PHP CMS и фреймворков с точки зрения правильной архитектуры и реализации?

    webinar
    @webinar Куратор тега Yii
    Учим yii: https://youtu.be/-WRMlGHLgRg
    Yii или SYMFONY. Но сделать e-commerce проще на готовой cms.
    Ответ написан
    Комментировать
  • Почему в jQuery невозможно манупулировать с созданным элементом?

    Petroveg
    @Petroveg
    Миром правят маленькие с#@&ки
    Работайте, по возможности, с всплывающим событием. Так вы застрахуетесь от проблем при динамическом добавлении элементов

    $(document).on('click', '.butt', function () {
    	console.log($(this)); // это и есть наш элемент с классом butt
    });

    В вашем коде ищутся все элементы по селектору в момент выполнения инструкции, а затем им устанавливается слушатель на событие. Всё, что добавлено после этого, не имеет такого слушателя.
    Ответ написан
    Комментировать
  • Как организовать команду по разработке сайтов и правильно делегировать задачи?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    1. Искать адекватных фрилансеров с похожим стилем мышления и взглядами - так больше шансов что сработаетесь. Объединяться не только по работе за деньги, но и придумать себе дополнительное сотрудничество, например, какой-нибудь совместный Open Source проект, или коммерческий продукт - и тем и другим может быть плагин/тема для WordPress или что-то подобное. Например, тема в двух вариантах - бесплатная Lite для WordPress.org и промо себя любимых, платная Pro для ThemeForest. Такая дополнительная работа позволит всегда быть в одной лодке и теснее работать на общее благо, это отразится и на коммерческих проектах. Кроме того, это всегда бонус и для клиента - например, в заказах по WordPress клиент видит, что я и мои ребята висим на WordPress.org как разработчики плагинов/тем, один у нас вообще в ядро WP контрибьютит. Это большой плюс в карму.

    2. Не увеличивать команду без надобности. 1 человек фронтенд, 2й - бекенд. Дизайнер на первых порах лучше проектно. Расти строго по мере острой необходимости, хотя новых людей надо искать заранее и тестировать в реальной работе. То есть, должно быть постоянное "ядро" команды, и еще несколько на подхвате. Поначалу они на подхвате (и работают себе самостоятельно в остальное время), со временем кто-то из них переместится в ядро, по мере роста.

    3. Со студиями/агентствами надо работать в обратном направлении. У многих из них часто бывают завалы и нехватка собственного ресурса, вы должны быть подрядчиками у них, а не наоборот.

    4. Бюджеты. Самое главное :) Кто-то умный когда-то сказал:
    The kind of clients we attract is directly related to our rates

    Что означает, что качество клиентов прямо зависит от ваших цен. И второе, из опыта - геморроя плюс-минус одинаково в проекте с бюджетом 200$, и в проекте с бюджетом $2000. Времени и усилий на поиск/привлечение клиента тратится столько же. И чаще всего те, кто платит $2000 больше ценят время, работу, и не имеют мозг без острой на то необходимости (см. цитату выше).

    5. Снижать стоимость привлечения клиента (под стоимостью подразумевается и время, и деньги). Повторные / постоянные клиенты - наше все. Оставлять клиентов на поддержке, делать так чтобы они обращались повторно с доработками / развитием своих проектов, приходили с новыми заказами, советовали другим. Например, я вчера закончил интересный проект для повторного клиента. Первым заказом были небольшие фиксы платного шаблона, 2 часа работы / $60, через биржу. Спустя некоторое время он обратился уже за целым сайтом для бизнеса своего отца. Адекватный бюджет. Сделали, запустили вчера. У него уже опять готов список новых фич для этого сайта, через месяц где-то вернется с ними и снова загрузит работой. Имея хотя бы с десяток таких клиентов, можно заполнить половину рабочего времени, не тратя время на поиски новых клиентов. И гемора с ними нет, и с оплатами никаких проблем, и т.д.

    6. Для того, чтобы п.5 в реальности происходил, недостаточно просто делать работу вовремя и хорошо. Нужно клиенту помогать, обучать его, советовать. Недавно был случай - клиент пришел со стандартной задачей пофиксить платный шаблон под его требования. Поковырявшись в этом ужасе и задав кучу правильных вопросов стало понятно, что этот шаблон ему вообще не подходит для этих задач. Проект был переориентирован в разработку с нуля, из $120 бюджет сменился на совсем другие цифры. Задача ведь не просто кнопки понажимать и что-то там накодить, а помочь клиенту решить его задачи. Ему результат в целом важен, а не количество строк кода, которые вы написали, или насколько правильно этот код отформатирован.

    7. Снижать себестоимость разработки. Накапливать типовые решения, код, который можно (и нужно) использовать повторно. В случае с готовыми CMS (а это самый распространенный формат работы) - покупать девелоперские неограниченные лицензии на те плагины, которые существенно экономят время. Мы, например, купив однажды ACF Pro для WordPress существенно уменьшили себе объем работы на каждом проекте. Сейчас будем брать Gravity Forms или Ninja Forms для того, чтобы решить вопрос с формами и кастомными фронтендами, которые жрут кучу времени и сил в разработке даже со своими наработками. Плюс какие-то мелкие решения, которые часто нужны.

    8. Написать для себя стратегию развития. Четко понимать, куда хотим прийти и в какие сроки (плюс-минус), четко определить, что делать, что двигает в этом направлении, а что нет. Тогда будет шанс из кучки фрилансеров вырасти в студию или что-то в этом роде. Без стратегического видения фриланс - это белка в колесе и замкнутый круг. Вечная погоня за небольшими деньгами "на пожрать и отложить на отпуск". Стратегия может быть разной, например, "вырасти в студию", "создать свои коммерческие проекты / онлайн-сервисы", "стать богом в одной конкретной сфере и собирать сливки со всех фриланс бирж - получать самые жирные проекты в этой нише" и т.д.
    Ответ написан
    1 комментарий
  • Имеет ли смысл использовать автоматизированную рекламную систему или эффективнее нанять специалиста?

    solomakin
    @solomakin
    Head of online marketing
    У меня был опыт всех трех ситуаций, которые вы описали:
    Настраивал рекламу сам без опыта и знаний.
    Работал в агентстве Icontext.
    Работал с автоматизированными системами elama и aori.

    Самому без опыта работы сейчас сделать эффективный контекст нереально. Работать будет, но надо ведь оценивать эффективность, управлять ставками, бить и разорять конкурентов и т.д. А всему этому долго учиться.
    Фрилансеры тоже очень разные попадаются, кто-то сделает еще хуже чем если попытаетесь сделать сами. Уровень "профессионалов" с бирж фриланса очень печальный.
    Автоматизированные системы для человека неопытного - лучший выбор, там максимально упрощенные интерфейсы, делать нужно всего по-минимуму.
    Из минусов таких автоматизированных программ, пожалуй, скажу, что вы не накроете и 20% потенциального трафика. Программы, которыми я пользуюсь для сбора семантического ядра (KeyCollector+ интеграция со SpyWords + wordstat и google keyword planner + всевозможные макросы для Экселя и шаблоны медиапланов) позволяют зацепить все тематические, брендовые, конкурентные, околотематические запросы и выжать максимум из контекста, а елама так не умеет. Елама управляет ставками и обновляет данные раз в 30 минут, а сервис primecontext - раз в 10 минут, поэтому я могу обыграть любого конкурента с любой системой управления ставками.
    Методы обработки ключевых слов и алгоритмы написания текстов объявлений позволяют сократить в 5 раз время создания объявлений, хоть я и делаю это руками, но качество гораздо выше, чем у любой автоматизированной системы.
    Честно, я очень долго плевался, попробовав эти сервисы, самому настраивать проще и удобнее, а главное - ты точно знаешь, что получил 100% от проделанной работы. Системы же накладывают ограничения.
    Обратитесь к профессионалу, которому доверяете, либо идите в агентство, которое себя зарекомендовало. Только так сейчас без опыть настройки РК можно сделать что-то хорошее.
    Надеюсь, совет вам поможет.
    Ответ написан
    1 комментарий
  • Что можно предложить заказчику, у которого нет готовой верстки?

    mramor
    @mramor
    нечего о себе рассказывать.
    Когда только начинал - делал сайты за бесценок, ситуация примерно таже. Рисовал на бумажке набросок макета при клиенте. Обговаривал примерно элементы, если он терялся или ему плевать, то все проще - подбирал на свой вкус какой-то бесплатный шаблон или просто верстку, подходящую под стиль к лого ( если оно цветное ) или что мне понравится в определенный момент и мне кажется, что будет уместно, то и брал.
    Никогда не предлагал несколько вариантов - выбирал только один, но с возможными не глобальными допилами, где-то что-то добавить\изменить.

    Почему не показывал несколько - здесь я уже наобжигался, причем неоднократно:
    1) Заказчик не знает что выбрать из предложенного. Начинает метаться между вариантами.
    2) Заказчик хочет, чтобы в первом была часть второго, а то и третьего и четвертого, а там верстка разная, разные библиотеки, это практически надо шаблон с нуля сверстать получается. Не выгодно.
    3) Личная трата времени на подбор нескольких подходящих вариантов, особенно когда в голову не лезут мысли как что должно выглядеть :)

    Насчет показа какого-нибудь ресурса с готовыми верстками - это мазохизм. Я такое тоже практиковал, но быстро отказался, ибо клиент выбирает что-то такое супер пупер, кучи элементов, в плане информационных блоков, виджетов и тд...а наполнять нечем, ладно у вас еще 6 разделов, а бывает так, что кроме адреса и телефона организации заказчик нифига дать не может, но шаблон выбирает под какой-нибудь крупный информационный ресурс, причем убирая все "лишние" блоки шаблон начинает превращаться в полное УГэ :) Либо он смотрит сайт и получается как в пункте 1.
    Ответ написан
    Комментировать
  • Сложно ли написать свой блог на nodejs?

    MarcusAurelius
    @MarcusAurelius Куратор тега Node.js
    автор Impress Application Server для Node.js
    Блог это конечно же решаемая задача для ноды, но эта ниша уже занята другими языками и фреймворками, поэтому блоги на ноде пишут редко, подробнее посмотрите вот этот мой ответ о том, что лучше писать на ноде, что имеет смысл, а что нет: Что можно написать на Node.js?
    Мой Вам совет, учите сначала платформу, смотрите видеоуроки тут https://learn.javascript.ru/nodejs-screencast пробуйте свои сыли на практике тут nodeschool.io и выбирайте готовый движек для блогов тут https://github.com/sindresorhus/awesome-nodejs
    Сделать блог это может означать:
    1. Взять движек блогов и сделать на нем блог
    2. Написать движек блогов и сделать на нем блог
    Делать блог на голом экспрессе, это почти то же, делать блог вообще на голой ноде, это можно только если Вы уже профессионал и хорошо понимаете, что делаете. Иначе нужно идти по первому варианту и брать все готовое, вот еще одно место где это готовое можно поискать: nodeframework.com
    Например: https://ghost.org/ или hexo.io
    Ответ написан
    Комментировать
  • Как посадить свой сайт на CMS?

    @archelon
    Готовый сверстанный макет проще всего перенести на MODx.
    Если вы уверенно работаете с html, то разобраться с этой системой особого труда не составит.
    Есть подробная документация, много пошаговых уроков на русском языке, вменяемое русскоязычное сообщество (modx.ru, https://modx.pro/).
    Ответ написан
    Комментировать
  • Как посадить свой сайт на CMS?

    Punkie
    @Punkie
    CSS-Tricks. Старые уроки правда, но принципы рассказаны досконально.
    Ответ написан
    Комментировать