• Шаблоны с ThemeForest - как основа для сайтов на заказ, нужно ли заказчику об этом знать?

    PrinsAlbert
    @PrinsAlbert
    Есть возможность делай только свои дизайны, работы, этот путь тяжелее, но принесет репутацию, увжение и больше выгод.

    Люди не любят тех кто заимствует чужое, люди любят самих создателей.
    Ответ написан
    Комментировать
  • Какую php CMS выбрать frontend разработчику?

    rsvetlitskiy
    @rsvetlitskiy
    UX/UI designer, researcher and almost a developer.
    Попробуйте Modx Revolution
    Ответ написан
    2 комментария
  • На чем написать сервис наподобии fl.ru?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Скажу сразу я не программер, мне нужно знать на каком языке программирования лучше написать такой проект.


    Найдите разработчика, а он вам уже скажет на каком он будет это писать.

    Можно написать обсалютно любой функционал

    Да хоть брэйнфак. Серьезно, можно сделать что угодно на чем угодно. Все упирается в трудозатраты.

    Скорость загрузки сайта

    Как бы нибыл язык хорош и быстр все может загубить кривая архитектура и плохой выбор СУБД или архитектуры базы. В целом на вашем месте я бы этот параметр опустил бы в самый конец списка. Можно предьявить к разработчику нефункциональное требование по выдерживаемой нагрузке и времени генерации страниц. А далее пойдут кэширования всякие и т.д. Посмотрите на GitHub, он написан на крайне медленном RoR но в целом довольно шустро работает.

    Безопасность от взломов

    Дырки есть везде. Вопрос профессианализма разработчика и используемых средств разработки, настройки сервера и т.д.

    Распространенность

    На PHP написано ~80% всего WEB, но если брать качественные проекты то распределение по технологиям я думаю будет приблизительно одинаковое. Возможно Java тут будет выигрывать но и дороже выйдет существенно.

    Словом, все решает вменяемый разработчик. И да, это дорого и не быстро. Можно взять PHP, Ruby или еще чего и быстренько сделать MVP, пускай и не выдерживающий больших нагрузок и не на 100% то что вам нужно, но можно будет запустить проект раньше. В любом случае расчитывать на большой поток пользователей при старте проекта - тут либо надо нехило вкинуть денег в маркетинг или привести трафик откуда-то еще, либо не знаю.
    Ответ написан
    4 комментария
  • Веб-разработка - знаю что хочу, но не знаю с чего начать?

    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 комментарий