dimonchik2013: стартап у которого требования постоянно меняются никогда не взлетит. Это не разработка уже, а бездумное исполнение хотелок очень креативного владельца, которые должен фильтровать им.
wonder-kid: вы очень невнимательно читаете и книги, и комментарии. Изменения будут обязательно, я не спорю, но хороший пм должен уметь построить процесс так, чтобы программисты не работали постоянно все меняя. Требуется изменение - обсуждаем необходимость, затраты, решаем когда оно появится, записываем в план максимально безболезненным способом. Все. И именно про это у Де Марко, а не про строгий план, который не меняется. Меняется, но без суеты и паники.
wonder-kid: "Любой практик вам расскажет, что если вы делаете проект длинной больше месяца, то план за это время поменяется, и не раз" - любой практик Вам расскажет, что такое происходит у плохого ПМа. ПМ на то и нужен, чтобы команда не металась от изменения к изменению каждый месяц, а действовала по четкому плану. Изменения естественно будут, но они должны утверждаться на последующие итерации после уже утвержденных иначе Вы застрянете в постоянной доработке и улучшении (исключения бывают, но это опять же провал ПМа). В этом смысле Вам как раз стоит перечитать еще раз эту книгу, так как Вы описали как раз антипример из нее.
блин, я сдаюсь. Еще один гениальный ответ добавился :(
"В .NET есть библиотека SignalR. Идея в том, что она проверяет, поддерживает ли браузер веб-сокеты, long polling, forever frames или server sent events" - походу взаимодействие без браузера вообще какая-то немыслимая вещь. ТС, короче рецепт судя по всему прост - ставим браузер, ставим .NET, пишем приложение на C#, которое будет общаться сбраузером через вебсокет, в свою очередь приложение на C# должно через командную строку (по другому никак походу, сокеты НЕВЕРОЯТНО сложная вещь) общаться с python клиентом. И заканчиваем тем, что в браузере еще добавляем общение через вебсокет с сервером на пхп. Профит :)
Сергей: какие изыскания? Любой более-менее нормальный программист знает что такое сокет и с чем его едят. Такая статья есть и находится она в документации к php, python и вообще любому языку программирования. Зачастую с примером кода клиента и сервера.
Сергей:
"Это более универсальный способ соединения в веб" смешно. Ребята и не знали )
"Потому что, сегодя у вас питон, а завтра html страница." - ага, а завтра на кофеварку захочу установить
"Если бы он не был бы новичком, таких вопросов не задавал бы." поэтому вы ему как новичку вместо простой работы с сокетами (специально посмотрел - простой пример даже на пхп займет около 15 строк) предлагаете реализовать вебсокет, который мало того, что имеет кучу версий стандартов (которые в случае перехода в веббраузер придется в той или иной степени поддерживать), так еще и требует реализацию определенного формата хэндшейков + сообщений? Ну в принципе да, пусть страдает и учится )
Сергей Блин, зачем советовать, если даже не знаешь что и как?! Так еще и проголосовал кто-то за этот ответ. Какие нахрен вебсокеты? Почитайте хоть на википедии зачем это и почему появилось. Поколение html5, блин. Чем вас обычные сокеты не устраивают? Сервер следит за переменной. Изменилась - бродкастим ее на все подключенные сокеты. Клиент смотрит на сокет не пришло ли чего. Все. Задачка на десяток строк кода. Нет блин, давайте накрутим вебсокеты, прикрутим еще очереди и обязательно все в облако, а то модно. А, да, еще лучше всего вообще это на ноде сделать, а то в интернете примеры кода только под js есть )
_ umr: на удаленке важны самодисциплина и умение решать задачи самостоятельно. У джуниоров как минимум второе отсутствует по определению, а с первым и так проблемы у большинства.
Ilia Okhre: А Вы далеко прошли? Ближе к концу клиентского js появляются интересные задачки и проекты + начинающему можно будет указать хоть какие-нибудь проекты в портфолио.
xmoonlight: флаг Вам в руки ) Но как уже говорили выше - или Вы делаете шаблонные проекты, где это применимо, или пока еще не набили свои шишки (судя по дате публикации прошло всего чуть более полгода)
xmoonlight: а почему "профессионалы" в кавычках ) Фриланс это предпринимательская деятельность в миниатюре со всеми вытекающими. А вот если работник у Вас в штате, то перекладывать на него свои риски неправильно и неэффективно.
"Работник стал таскать 10 кирпичей, зная что если он не справится" - вот именно про это я и говорю. Работник в среднем может таскать даже 12! кирпичей, но он знает, что если что-то случится (форс-мажор пусть даже и не по его вине) и он вместо 12 принесет меньше, то ему меньше заплатят. Получается, что работник заинтересован сказать, что может носить 8 кирпичей (коллега ведь таскает 8 и ничего) и получать за это не напрягаясь свои деньги. А ведь при правильной организации работы Вы могли получить сотрудника в 1.5 раза более эффективного, чем его коллеги.
xmoonlight: честно не совсем понял Ваш "вброс" ) "его личные условия, на которые он согласился с собой" - сегодня согласился, завтра понял, что сглупил и нашел другую работу. Надо создавать комфортные условия для работника, чтобы у него сохранялась мотивация работать с тобой.
"А у вас хватит мотивации и харизмы?! )))" лучше спросить у моей текущей команды, но пока никто не жаловался ;)
"Оплата всегда ведётся по прогнозируемым трудозатратам вместе с разработчиками." А Вам не кажется, что такой подход приведет к тому, что рабочий, который может нести 10 кирпичей за раз будет искусственно занижать свои способности, так как если он вдруг споткнется и уронит кирпичи, то Вы ему не оплатите ничего, хотя споткнувшись он нашел давно потерянные другими рабочими грабли?
Прогнозы хорошо, но если Вы мне покажете человека, который может с точностью до часа сказать сколько у него займет решение задачи, то я очень удивлюсь и захочу его себе в команду :) А если кто-то будет всегда вынужден неспрогнозированные затраты оплачивать самостоятельно, то его мотивация быстро сойдет на нет и человек попросту уволится.
Сергей: "объясните мне как в этой портянке (после пьянки) найти последнее обновление для 6ки" - Вам объяснили, чего Вы еще хотите? Пожаловаться? Ну так это на какой-нибудь ithappens.me