Задать вопрос
Профиль пользователя заблокирован сроком с 18 ноября 2017 г. и навсегда по причине: спам
  • Хочу добавить на свой веб-сервис OAuth2 авторизацию, если ли материалы, как это сделать?

    hbuser
    @hbuser
    Как и сказали, здесь или здесь можно почитать о самом принципе авторизации. Могу подтвердить слова в первой ссылке о том что, процедура, описанная там, применима к любым соц. сетям, т.к. используется один и тот же протокол. Только ссылки будут другие. А если говорить о конкретной технической реализации, то - вот здесь. Там и общая информация и конкретно по всем необходимым для русского человека соц. сетям. Мне помогло. Плюс, можете глянуть сюда. Это мой вопрос. Никто ответа не дал, поэтому сам себе ответил. Думаю, этой информации будет достаточно. Мне хватило.
    Ответ написан
    Комментировать
  • Есть ли лаконичная книга по Python?

    www.diveintopython3.net В печатном виде она около трехсот страниц.
    Ответ написан
    2 комментария
  • Какой идеальный путь начинающего веб-разработчика?

    ali_aliev
    @ali_aliev
    Разработчик на Django/Python, JavaScript
    Python+Django и конечно же JavaScript. С питоном разберетесь быстро (если прочтете Лутца проблем никаких быть не должно). Django тоже не сложный фреймворк, достаточно прочесть официальную документацию. У JavaScript-а очень много подводных камней, слабо типизированный язык, читать придется много и учиться постоянно. Еще вам необходимо будет знать хотя бы на базовом уровне верстку, прочтите книгу "Влад Мержевич - вёрстка веб-страниц". Обязательно изучить SQL (он очень простой, любая книжка подойдет но я советую начать с "Понимание SQL", Мартина Грабера), далее PostgreSQL учебник тыц и тыц. Вот вроде бы и все, двигайтесь в этом направлении.
    Ответ написан
    Комментировать
  • Какой идеальный путь начинающего веб-разработчика?

    valemak
    @valemak
    Фрилансер
    Этап 1. Тактический.
    Так как Вы планируете начать зарабатывать как можно скорее, то PHP. Выучив азы, не особо мешкая переходите к изучению внутренностей WordPress. Кроме вёрстки будете писать плагины, заработки увеличатся.

    Этап 2. Стратегический.
    Итак, Вы относительно быстро худо-бедно освоили PHP на уровне программиста средней паршивости, и даже карябаете какие-то плагины под Wordpress, без особых проблем находя заказики на фриланс-биржах. Всё это замечательно, но это путь в никуда. Обеспечив себе кусок хлеба с маслом, начинайте тянуться к прекрасному: Python+Django. Изучив азы языка, запускайте собственные проекты. Длительное время Ваш путь к дзену не будет приносить денег, но однажды Вы проснётесь владельцем супер-мега-стартапа который принесёт вам миллионы долларов (во всяком случае на такой разворот есть лучик надежды). И стартап будет, конечно же на Питоне, а не на Пыхе.
    Ответ написан
    6 комментариев
  • Какой выбрать минималистический php-фреймворк для json-restful-api?

    Grigorieff
    @Grigorieff

    Я бы взял laravel, плюс его в том что он конкретно для REST и сделан.

    Ответ написан
    1 комментарий
  • Что должен уметь backend-разработчик?

    la0
    @la0
    Всё несколько попроще.
    Вы должны знать иметь хоть что-то сделанное своими руками на той бэкенд связке, с которой работает конкретный заказчик/работодатель; ну и нормально работающую голову.
    А не «я ничего не знаю, учите мня и платите мне 100500 за это».
    В скором времени вы и знать будете (и не только ответ на данный вопрос) и уметь.
    Также, присмотритесь к инструментам командной работы (любые системы контроля версий).
    Ответ написан
    Комментировать
  • Что должен уметь backend-разработчик?

    anathem
    @anathem
    На счет php, как подметили, — совсем не обязательно. Логично предположить, что это может быть любой язык, используемый для бэкэнда, — php, ruby, python и т.д. Так же JavaScript может быть использован в качестве языка для бэкэнда в упомянутом node.js.
    В любом случае, если имеется ввиду веб, — JS (и jQuery, ввиду распространенности) обязательно, т.к. использование того же AJAX-а — это все же компетенция бэкэнд-разработчика, а он на JS как раз и основан. Знание верстки так же пригодится, — ведь бэкэнд и фронтэнд, — это часть целой системы и внедрять верстку в проект, вероятнее всего, прийдется тоже бэкэндщику )
    Так что, думаю, «да» :)
    Ответ написан
    4 комментария
  • Идея простого проекта веб-приложения

    Сделайте то чего Вам лично не хватает. Вы либо найдете уже готовое решение, либо сделаете что-то полезное для себя.
    Ответ написан
    2 комментария
  • Идея простого проекта веб-приложения

    @TyVik
    У меня тоже такая задача была — написал простенький список покупок, который умеет уведомлять об изменении через смс. Жена осталась довольна, теперь им вместо листочков пользуемся.
    Ответ написан
    Комментировать
  • Идея простого проекта веб-приложения

    slpdmn
    @slpdmn
    Лучше всего какой-нибудь сайт-шутку. Один мой знакомый, напр, лет двадцать назад запулил в инет страничку с простой кнопкой с надписью «безделометр» и счетчиком нажатий. Весь офис на ушах стоял и рекорды ставил. А ему параллельно пришлось осваивать идентификацию пользователей, хранение результатов, сообщения о промежуточных рекордах (это явасрипт уже) и т.п.
    Нарисуй, напр, муху, которая по экрану ползает и мышкой ее прибивай. Или для девушки напиши что-нибудь, калькулятор размеров там… Напр, какой нужен размер брюк (по канону Мерилин) при заданном объеме груди? Ну и меняй каноны.
    Ответ написан
    Комментировать
  • Идея простого проекта веб-приложения

    un1t
    @un1t
    Есть куча разнных баг-трекеров и систем ведения проектов, но мне лично не одна не нравиться. Хочется относительно простенький трекер для небольших команд 3-5 человек.
    Ответ написан
    1 комментарий
  • PHP ООП

    @alesto
    Зандстра Мэтт — PHP. Объекты, шаблоны и методики программирования
    Ответ написан
    1 комментарий
  • Тонкости оценки стоимости работы?

    alekciy
    @alekciy
    Вёбных дел мастер
    >умножать начальный эстимейт на 2-2.5
    Рекомендую «правило пи». Умножать на 3.14

    Касательно оценки сроков. Ведите статистику. Берется проект, разбивается на этапы и задачи, каждая оцениваться, не важно на сколько. А потом берем и выполняем задачи засекая время. Причем время нужно стартовать с момента начала работы над задачей и останавливать когда все полностью готово (т.е. что бы в это время вошли даже такие мелкие действия как запустить редактор, сходить покурить). После этого сесть и проанализировать, почему сроки не сошлись и какая в среднем ошибка (в процентах от запланированного). На следующем проекте провести такой же трекинг, опять оценить ошибку. И на следующем. И на следующем. Через некоторого количество проектов оценка теоретическая начнет сходиться с реальным уровнем работ.

    Более точного метода чем сбор статистики лично я не знаю. А это приходится делать в таком виде, потому что теже задачи другим разработчиком был бы оценены в другое время и потратил бы он время на их реализацию другое. Поэтому сейчас только через личную статистику, имхо.
    Ответ написан
    2 комментария
  • Тонкости оценки стоимости работы?

    opium
    @opium
    Просто люблю качественно работать
    Разбиваете задачу на подзадачи, у каждой выставляете часы, часы умножаете на стоимость вашего часа, смету отправляете заказчику, цена адекватна и обоснована.
    любые изменения влекут изменения в часах, если их нужно меньше продукт будет стоить дешевле, если больше то дороже, тоже все прозрачно и понятно заказчику.
    ни один человек не написал как он будет писать хабр, выкладки по часам и подзадачам, так что всех кто там писал можно слить. аналог хабра поднять на лайвстрите два дня с допилкой, то есть 16 часов умноженных на 500 рублей 8 000 рублей, стоит аналог хабра на лайвстрите, можно разбить на подзадачи и более детальную смету по цене. Данное время взято из моего реального опыта.
    Ответ написан
    2 комментария
  • Тонкости оценки стоимости работы?

    Wott
    @Wott
    1. поговорить не пробовали? спросить что конкретно заказчик имел в виду, как он себе это представляет и вообще детали раскрыть. Как правило одно, максимум двух, писем с вопросами хватает что бы получить достаточно информации для оценки стоимости работ.

    Лично мне ответы сразу с ценой на заявку в пару фраз кажутся спамом.

    2. Сроки плывут всегда. Нужно обладать недюжинным опытом и отменным профессионализмом что бы выполнить все как задумывалось.
    Я помню восхищался преподом по общей биологии, который весь урок ярко, насыщенно рассказывал, устраивал мини тесты, успевал ответить на кучу вопросов и так далее, но всегда звонок звенел именно тогда когда наконец он смотрел на часы в конце урока. Так вот — в работе так не бывает.
    Можно закончить раньше, можно напрячься и, за счет другого занятия, успеть вовремя, но всегда есть отклонения. Можно их скрывать оперируя крупными или размытыми сроками ( например «в течении недели»). Можно закладывать буфер на всякий случай. А можно сроками нормально управлять — общаться с заказчиком, сообщать ему планы, корректировать планы, если проявились проблемы или увеличилось количество работы, или наоборот удалось все сделать раньше. В обратную сторону заказчик может определить приоритеты важные для него, простимулировать, если надо быстрее или наоборот.
    Ответ написан
    1 комментарий
  • Книги Python

    starodubcev
    @starodubcev
    Извините, не выдержал
    goo.gl/Uzc51
    Ответ написан
    1 комментарий
  • Оценка проекта по времени, когда не ясно, что за проект?

    yadeveloper
    @yadeveloper
    Такие заказчики бывают. Как было сказано выше, без полного объема информации, вы не сможете дать нормальный эстимейт. Однако есть выход и из этой ситуации. Наверняка же есть какие то базоые требования к реализации, которые точно нужно будет делать? Дайте эстимейт на этот кусок работы, заложите поправку в 2.5 раза и сделайте примечание, что этот эстимейт только для конкретного куска работы, информация по которому у вас есть. Далее просто будем делать правки, по мере поступления задачи. На вопрос вида «мне нужна полная цифра», отвечайте «пол-года и будем значительно сокращать по мере поступления информации» :)

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

    Если что то не учли, предупредите менеджера\клиента сразу по ситуации, не откладывайте разговор на потом. Не бойтесь сказать, что вам нужно больше времени. Поверьте, гараздо хуже не выполнить работу в обещанный клиенту срок, чем заложить больше времени с учетами рисков.

    При планировании — закладывайте риски. Есть задача, делится на 2 этапа. Первый этап может быть сделан за 1 день, если все будет хорошо, но вот тут и тут могут возникнуть сложности на решение которых может потребоваться еще 1-2 дня. А вот второй пункт — неясен. Может быть 1 день, может быть 2 дня, в зависимости от успешности первого пункта. Но давайте возьмем здесь 3 дня + 1 на собственное тестирование\проверку реализации бизнес требования.

    Именно такое, развернутое эстимейтирование, позволит вам избежать множества проблем, перейти на нормальный рабочий график. Клиент будет понимать, почему вам нужно больше времени (или может понадобиться) и вы будете спокойны, зная, что у вас в запасе еще есть время.
    Ответ написан
    5 комментариев
  • Книги по ООП в PHP

    Awake
    @Awake
    Рулю разработкой ;-)
    PHP. Объекты, шаблоны и методики программирования. Автор: Марк Зандстра.

    Шикарная книга.
    Ответ написан
    2 комментария