Профиль пользователя заблокирован сроком с 18 ноября 2017 г. и навсегда по причине: спам
  • Как эффективнее всего изучать yii2?

    slo_nik
    @slo_nik Куратор тега Yii
    Добрый день.
    Читать документацию, смотреть проекты на github, пытаться написать своё решение для какой-либо задачи....
    Вот несколько ссылок, которые Вам помогут:
    1) rmcreative.ru (блог одного из разработчиков yii2)
    2) https://github.com/samdark/yii2-cookbook (рецепты от того же разработчика)
    3) www.elisdn.ru/blog/tag/Yii2 (один из блогов, где можно учиться работать с yii2)
    4) https://github.com/yiisoft/yii2/tree/master/docs/g... (документация на русском от разработчиков yii2)
    Ответ написан
    1 комментарий
  • Есть ли практические бесплатные видео уроки по Laravel 5?

    @sosnovskiy
    Рекомендую laracasts (можно скачать бесплатно с торрентов) полезно, как начинающим, так и более опытным.
    Ответ написан
    Комментировать
  • Как определить реальную рыночную стоимость проекта по разработке веб-приложения?

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

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Без примера тестовых задач, это очень абстрактный разговор )

    AFAIK на фрилансе исчезающе мало заказов с такими костами, соответственно и людей готовых за них браться.
    Среднестатистический разработчик привык или брать мелкие проекты (неделя-две), либо работать по часовому рейту не занимаясь глобальной оценкой.
    Даже просто прочитать и осмыслить тз на объемный проект это 2-3 часа минимум, - далеко не все будут этим заниматься без подтверждения реальной заинтересованности заказчика.

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

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

    Плохое cover letter
    Плохое портфолио
    Слишком низкая цена

    Причин может быть море

    На UpWork с ценами ситуация не менее интересная по моему профилю. Цены явно ниже раза в 4, чем это вообще реально сделать.
    Вы определитесь, вы даете цену в 2 раза ниже рынка, или на рынке цена в 4 раза ниже чем Вы готовы делать? ;-)

    PS
    Разместил на fl.ru проект, который исходя из моего понимания и по результатам обсуждения с программистами, с которыми я сотрудничаю никак не может стоить меньше 150 000 руб
    Как говорил классик: наш главный ресурс это люди. Умеете находить качественных разработчиков за разумные деньги - будет Вам счастье и успех. Не умеете -не суйтесь в агентский бизнес.
    Ответ написан
    2 комментария
  • Как определить реальную рыночную стоимость проекта по разработке веб-приложения?

    dimasmagadan
    @dimasmagadan
    Учитывайте при определении "реальной" стоимости такие факторы:
    1 Основная масса проектов (как бы там не писали заказчики что у них все "уникальное") - типовые.
    Наработав некоторую базу проектов, можно собирать следующие на основе уже написанного кода.
    Сборка вашего проекта из готовых кусков + некоторое допиливание могут запросто выйти дешевле, чем написание с нуля.

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

    @jaxel
    Очень сложно определить реальную стоимость разработки для крупных задач. В серьёзных конторах может 100-200 тысяч от бюджета уйти на составление подробного ТЗ и оценку стоимости проекта. И даже в этих случаях бывают промахи процентов в 20-30% бюджета.

    Для меня лично оценить задачу - всегда проблема. Даже по хорошему ТЗ на подробную оценку может денёк уйти. Делать такую оценку для "потенциального" заказчика - очень расточительно.

    В большинстве случаев, я оцениваю в часах время разработки понятных моментов задания, добавляю предполагаемую оценку не совсем понятных моментов, умноженную на 2, и оценку совсем не понятных моментов ТЗ, умноженную на 3. Умножаю полученное время на часовую ставку и получаю примерную стоимость проекта.

    Цифра озвучивается заказчику, как ориентир. Так как она весьма приблизительная, стараюсь договориться на почасовую оценку работы. Особенно при плохом или непонятном ТЗ.

    Удаётся не всегда. Бывает, что по этой цифре и работаем. Иногда времени уходит больше, иногда меньше. И ничего с этим не сделать.

    А по конкретным задачам может быть много нюансов.
    • У первого исполнителя могут быть готовые наработки, и он сделает заказ за 3 дня и 22к рублей.
    • У второго наработок нет, но он хороший спец, использует для задачи правильные инструменты, и сделает за 2 недели и 70к.
    • У третьего тоже нет наработок, и в добавок он не умеет выбрать правильный инструмент. Начнёт пилить без фреймворков и прочего, потратит на это пол-года и 300к рублей.
    • Четвёртый просто не поймёт сложность задания. Запросит 30к и начнёт пилить сложный кастомный прокт на вордпрессе. В итоге просто не сможет его закончить:)

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

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    По-скольку, Вы - архитектор ПО, у Вас УЖЕ должна быть схема бизнес-процесса будущего проекта.
    Разбейте свою задачу на более мелкие подзадачи (исходя из функциональных блоков на схеме или их совокупностей) и приценитесь по каждой из них в отельном проекте: "Требуется разработать функциональный модуль, который позволяет ....".
    Потом - суммируете средние цены и получите более-менее точную цену для реализации проекта по средне рыночной фриланс-стоимости.
    Ответ написан
  • Как оценить адекватность заказчика? Стоит ли тратить время на длительные переговоры до начала работы?

    @WapGeaR
    Программист
    Вот наслушаются таких чудаков, как Melanitta. Сам послушал подобное и попробовал себя в сфере "less 100$" в итоге 3 подряд заказчика-мудака и такая же реакция поддержки: "Он же не сказал что нужен вирус, он просто описал функционал, поэтому мы к нему меры не примем" и job success 50%, затем период адаптации и 2 заказа >700$ + адекватность клиентов.
    Резюмирую:
    - Начинайте со ставки, которая для вас приемлема, не занижайте свою цену.
    - Не ищите дешевые заказы, если хотите крупных - берите их.
    - Не важен опыт на upwork, важен опыт работы и умение находить общий язык.
    Ответ написан
    Комментировать
  • Первый проект для изучения PHP фреймворков - что делать?

    nepster-web
    @nepster-web
    " ООП знаю" - поверьте, не знаете.

    С Yii2 не советую начинать обучение. В качестве обучения возьмите Laravel5.2 или symfony3 или zend3, все что угодно но не в коем случае не Yii2. Иначе у вас будет не правильное понимание OOP, SOLID и еще многих бестпрактик.

    Что касается паттернорм, в принцепи невозможно написать хороший код с длительным обслуживанием без: PSR, DI, Repository, Entity/DTO/VO, тестов и тп. Поэтому если вы не знаете хотя-бы одно из этих слов, прежде чем что-то писать и учить, прочитайте книгу по ООП. Иначе ничего хорошего вы не напишите.
    Ответ написан
  • Помощь с началом обучения Yii 2?

    vakorovin
    @vakorovin
    Разработчик
    К словам Максима добавлю вот еще что, берите тестовые задания в компаниях, которые набирают yii-разработчиков. Это конечно же не учебник, но задания могут отражать потребности компании. Для себя самого очень полезно понимать, чего ты еще не можешь, а где преуспел.
    Ответ написан
    Комментировать
  • Помощь с началом обучения Yii 2?

    webinar
    @webinar Куратор тега Yii
    Учим yii: https://youtu.be/-WRMlGHLgRg
    www.elisdn.ru/blog/tag/Yii2

    там и текст и запись вебинаров есть

    А вообще лучше доки читать и гайд официальный:
    www.yiiframework.com/doc-2.0/guide-README.html
    Ответ написан
    8 комментариев
  • Изучение python не для новичков, с чего начать?

    @yociyavi
    "Я прочитал 10 книг по езде на велосипеде, но так и не научился ездить на нем".
    Для того чтобы научится что-то делать, нужно это делать. Параллельно почитывая теорию.
    Напишите пару сайтов для себя: блог, туду лист и прочие. За одно и портфолио будет.
    Ответ написан
    Комментировать
  • На чём лучше вести локальную разработку?

    boramod
    @boramod
    Упрощенно.

    Вагрант — система управлением конфигурацией конкретной машины.
    Докер — запуск изолированных процессов на машине.

    Докер.
    Это не виртуальная машина, а запуск изолированных процессов. Т.е., запущенный процесс думает, что он один единственный, и ничего вокруг нет. Это работает на уровне ядра Linux. Без использования виртуальных машин.

    В терминологии Докера есть Images и Containers.
    Image — образ, шаблон, на основе которого запускается Container.
    Image строится на основе какого-либо базового образа ОС.

    Container — сервис, запущенный и построенный на базе Image.

    Таким образом, вы можете построить несколько образов, например, образ для Nginx, образ для PHP, образ для MySQL. Вдобавок, вы можете построить несколько образо, для каждой желаемой версии PHP, MySQL и т.п.

    Каждый из этих образов будет иметь у себя в базе какую-либо ОС. Т.е., происходит изолирование окружения, на котором работает Docker.
    На базе построенных образов вы можете запускать Containers, т.е., непосредственно строить рабочее окружение. Каждый запущенный контейнер думает, что он запущен один, в образе наследуемой ОС. Но на самом деле, это всего лишь отдельный процесс, работающий на уровне ядра Linux, без виртуализации. Т.е., у вас нет накладных расходов на виртуальные машины. Изолирование контейнеров выполняется на уровне ядра.

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

    Оба инструмента хороши. Но у каждого свое назначение.

    Vagrant — великолепный инструмент для конфигурации удаленных машин с нуля, VDS/VPS и т.п.
    Docker — великолепный инструмент для быстрого развертывания/переконфигурации рабочего окружения, практически без изменения системы, на которую он устанавливается.
    Ответ написан
    6 комментариев
  • С какими знаниями стоит начать изучение Yii2?

    kimono
    @kimono
    Web developer
    Начать изучение PHP слёту с фреймворков - плохая затея. Вы мало что поймете. Изобретите сначала свои велосипеды, доработайте, удалите их с создайте снова, допилите и т.д. Начните с необходимого:
    - Запросы в базу, обертка к PDO, триггеры, внешние ключи, поиск, индексы и т.д.
    - Формы, экранирование кавычек, фильтр HTML и т.д.
    - Валидация данных, в том числе и для уменьшения кол-ва повторяемого кода
    - Кеширование (фрагментов кода, запросов), применение тегов при кешировании
    - Роутинг, все запросы через index.php (как и почему)
    - Всевозможные хелперы (на все случаи жизни)
    - MVC - своя реализация
    - Трейты, абстрактные классы, интерфейсы, неймспейсы, всевозможные виды методов, наследование классов и т.д.
    После того, как вы в любом месте вашего кода сможете нагородить что угодно из этого набора - идите и скачивайте популярный и хорошо документированный фреймворк и начинайте писать. Если вы сразу начнете вникать в чужой код - значит ваши велосипеды были близки к истине.
    Ответ написан
    Комментировать
  • Правильно ли я понял принципы REST?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Читать и писать куки может только фронтэнд.


    Нет, так как это вполне себе stateless механизм. Он действует как токен.

    Мне нужен ACL, и за него, конечно же, будет отвечать сервер


    403 статус код. Все остальное опционально.

    Итого — логика бэкенда заключается лишь во взаимодействии с БД и в ACL, не более того.


    зависит от проекта.

    Вся бизнес-логика — на фронте


    Зависит от проекта. Если у вас пользователи никак не взаимодействуют друг с другом и нет общих данных - то да. В этом случае вам даже бэкэнд не нужен особо. Достаточно завернуть в мидлвэр rest интерфейс к какой монге.

    А если есть общее для нескольких пользователей состояние то вам придется часть бизнес логики вынести на сервер. Он будет выступать в роли единого источника правды.

    Может быть, фронтенд при необходимости будет хранить своё состояние самостоятельно,


    Rest только про взаимодействие клиента и сервера. Ему без разницы что там делает клиент или что там делает сервер.

    Довольно хорошо принципы и ограничения описывающие restful описаны тут:

    www.restapitutorial.ru/lessons/whatisrest.html

    к сожалению вся остальная информация не полная. Например нет упоминаний как работать с PATCH методом.
    Ответ написан
    2 комментария
  • С какими знаниями стоит начать изучение Yii2?

    kentuck1213
    @kentuck1213
    Учим:
    1 - ООП в php.
    2 - MVC патерн.
    А вообще я вам предлогаю начать с Laravel. У него дока по понятней задокументирована в отличии от Yii да и кода меньше.
    Ответ написан
  • Для чего нужен Docker?

    @spotifi
    Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

    Докер - это двойная изоляция. Изоляция того, что лежит внутри контейнера Докера от операционной системы и изоляция операционной системы от того, что лежит внутри Докер. Изоляция подразумевает изоляцию всех файлов, портов, приоритетов.

    Это почти виртуальная машина. Почти, да не совсем.


    Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

    Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

    С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

    Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

    Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

    Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

    Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

    Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

    Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

    Контейнеры существовали и до Docker. Докер, строго говоря, это всего лишь очень удобный набор инструментов, собранных воедино, для управления контейнерной виртуализацией. Но очень удобный.

    Зачем это используется?

    Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

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

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

    Более того - изначально разработчик программного обеспечения тестирует программу в контейнере Докер, с определенными настроками. И в этом же (или с такими же настройками) контейнере Докера программа уезжает на сервер.

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

    До этого люди мучались, придумывали хитрые инсталяторы...

    Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

    Другими словами:
    • Докер-контейнер нужно использовать для отладки.
    • Тот же Докер-контейнер нужно использовать и на сервере.


    Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

    Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

    Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

    UPD:

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

    Разработчик отдает весь свой результат в систему CI (обычно через git)
    CI на каждый новый коммит делает с помощью Docker образ для тестирования.
    Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
    Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

    То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
    А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

    Основная идея - что тестировали, ровно то и запускаем на боевом сервере. Один-в-один, включая те же самые файлы (не такие же, а именно те же самые).
    Ответ написан
    18 комментариев
  • Для чего нужен Docker?

    @viiy
    Linux сисадмин \ DevOps
    Представьте что нет никакой ложки докера.

    1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема - вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

    2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

    3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

    4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

    Все запущенные процессы Docker помещает в изолированную среду процессов, файловой системы и сетевого стека. Есть много особенностей по работе с Docker, т.к он предполагает, что в одном контейнере вы запускаете один процесс. Если вам нужно запустить целый набор демоном, тут появляются проблемы, нужно писать шелл-скрипт, который все это поднимет в контейнере. Так же есть особенности по сети, файловой системе. Для кого то Docker спасение и решение всех проблем, но я как сисадмин от этого всего не в восторге.
    Ответ написан
    15 комментариев
  • Имеет ли смысл использовать REST(ful) API для работы самого вебсайта?

    dimasmagadan
    @dimasmagadan
    Имеет.

    Например, у вас бэкенд сайта на WordPress, а морда сайта сделана как приложение на backbone или react каком-нить.
    В этом случае проще будет воспользоваться готовым rest api и не писать свой код.

    Ну или у вас может быть не весь сайт как js приложение, а только какой-то раздел.
    Или можно ту же подгрузку записей при скролле через rest api реализовать, или еще что-то такое.

    В общем, везде, где вам нужно отправить ajax запрос к сайту и получить обратно данные, можно использовать rest api. Заметьте - не обязательно нужно, а можно. Что лучше, стоит на конкретном сайте/примере смотреть.
    Ответ написан
    Комментировать