Здравствуйте, lboss, Вы писали:
M>>Короче я вижу Ваше предложение так. Вам все равно на чем писать продукт и Вы доверяете в этом разработчику.
L>Нет — я этого не говорил. Я сказал что у меня несколько проектов: часть на С#, часть на C++.
M>>Вы не называете зарплатную вилку, не называете никаких конкретных требований к разработчику.
L>Требования: адекватность оценок, и хороший код — они заявлены.
M>>Вы не уверены в своей способности определить хорошего разраба по тестовому заданию и потому наначаете испытательный срок.
L>Испытательный срок назначается всегда. Кроме кода, есть ещё много факторов влияющих на работу работника: семейные обстоятельства, конфликтность, умение понимать задание, умение задавать вопросы если что-то не понятно и т.д. Это можно увидить только проработав с человеком некоторое время.
M>>А может не уверены, что в дальнейшем "всё будет хорошо", и вы сами не потеряете интерес к проекту по куче возможжных причин, вроде "получается дорого", "получается долго", "а вроде и не надо", "а есть проект поважнее".
L>Э... вообще не ясно что тут ответить...
Да ладно. Я прекрасно понимаю что Вы хотели написать. Не надо объяснять очевидного. Я писал про то, какое впечатление создает ваше предложение.
M>>Ваше "могу трудоустроить официально" можно читать как "захочу — устрою официально, не захочу — не устрою". "прошу рассматривать как испытательный срок" — это звучит как "как хочу так и делаю, а вы рассматривайте это как хотите".
L>Нет — просто кому-то это важно, кому-то нет. Мне не важно — мне важен результат.
Вот-вот. Вам важен результат, а о том, кому Вы работу предлагаете Вы вообще подумали? Да, что значит "могу трудоустроить официально"? Для Вас, что это какая-то проблема? Я давно уже не слышал про черные схемы.
M>>Вы пытаетесь сделать оценку финансовых и трудовых затрат на проект путем анализа пришедших Вам предложений. Проблема в том, что Вы все равно не будете уверены объективная ли это стоимость проекта или Вам просто попался такой разраб. Вы будете счастливы, только если затраты получатся низкими в сравнени с Вашими ожиданиями и возможностями.
L>Я сам профессиональный разработчик, и долго работал на аутсорсинге. Более того частично буду участвовать в разработке "для души". Тут я как раз не вижу проблем.
Кхм. Проблема в том, что Вы будете пытаться компенисровать свое недовольство результатом (результат/затраты) постоянным давлением на разраба ("Ну вообще-то на такую работу нужно никак не 2 недели", "Ну вот ты тут неделю убил на какой-то баг, какая тебе премия?"). Если бы у Вас было четкое представление о затратах на проект, то Вас волновало бы только выполнение графика работ, а не то, как именно работает разраб и на что траит большую часть времени.
Да, опытные люди от фразочки "частично буду участвовать в разработке "для души"" побегут сломя голову. Не дай Бог работать с начальником, который заглядывает тебе через плечо и постоянно говорит, что он сам сделал бы лучше/быстрее/сильнее.
M>>Та же картина с тестовым заданием. Вы ведёте себя как инвестор с пачкой денег, который садится и говорит "Удивите меня". Что значит "чем более похоже тем лучше"? На сколько важна та или иная фича? Какой вес имеет каждая фича, качество, цена? Вы пишете "данную задачу можно решить как сложно так и очень просто и эффективно". А вам как надо? В любом проекте выбирается тот или иной стиль разработки в зависимости от таких условий как критичность задачи, зарплата, временные рамки, критичность каждой фичи. "Просто и эффективно", это значит что у меня не будет времени оформлять и коментировать код, возможно, что код будет нерасширяем, возможно с урезаными фичавми. "Сложно" — значит много кода, опять же возможно плохо коментированного, зато с хорошей архитектурой, с легко добавляемыми фичами. Насколько важен стиль кодирования, тестируемость?
L>Передёргиваете однако. То что Вы описали очень важные моменты, когда у вас есть заказчики и вы как-то пытаетесь упорядочить работу с ними, чтобы не сделать того чего они не просили. То есть Вы пытаетесь со мной поговорить как PM с заказчиком. Я похожие спитчи сам не раз прогонял — не надо.
Вот Ваша вакансия как раз очень похожа на размещение заказа. Вам правильно посоветовали рентАкодера. Если хотите отдать распределение баланса время/качество/деньги разрабу, то это самый настоящий контракт на работу, а никак не прием сотрудника.
L>У меня другая ситуация — я ищу человека на fulltime, с которым мне будет комфортно работать, поэтому поставил задачу так как я её и планирую ставить в дальнейшем. И ожидаю вопросов/понимая и качества кода, который и будет в дальнейшем.
Аха, Вы ожидаете вопросов и понимания? Ну то есть нужно чтоб разраб еще и требования умел из клиентов выколупывать? Вы сами ставите себя на позицию не работодателя, а заказчика, причем заказчика геморройного.
M>>Вот Вы пишите "что вообще странно — если QT — то вроде как поддержка межплатформенности, тогда как тут вяжется Intel IPP". Причем тут вообще межплатформенность? Вы про неё и слова не написали в исходном посте. Или Вам принципиальна платформенная чистота проекта? Сколько ещё таких скрытых требований?
L>Боюсь Вы не внимательно прочитали ветку. Было задание, человек мне написал письмо с предложением, я ему ответил, что его предложение мне не подходит, он написал в ветке, что считает что я не прав. Я ему и ответил, что не считаю использование Qt и Intel IPP разумным использовать в данном случае (я имел в виду что QT очень не дешевое решение). В своём письме человек ещё обосновывал использование QT тем, что можно потом на UNIX портироваться, на что я заметил, что тогда не логичным будет завязываться на Intel IPP (так как это вообще привязка на определённые типы процессоров). Ни какого отношения к "скрытым требованиям технического задания" это не имеет.
"QT очень не дешевое решение"? Кхм.
M>> "Оцениваю насколько человек продумал решение и оно обосновано". Если я писал первое что пришло в голову что б сделать быстро, в Вашей ситуации это достаточно обоснованное решение? Я, например, сталкивался с ситуациями, когда каждый час на счету.
L>Да именно это я хотел — первое что приходит в голову, потом мы обсуждаем и находим решение. Если оказывается что оно эффективно, то есть хорошая доля вероятности, что мы и дальше сможем работать столь же эффективно.
Вы понимаете, что само по себе возникновение такого вопроса опустит Вашу вакансию в самый конец списка?
M>>Вы говорите человеку, что remoting медленный протокол, что тупо передавать целые скриншоты это тяжко для сети. Ну дык, а где требования по аппаратным ресурсам? Короче, у Вас собеседование пройдет только телепат, который угадает все Ваши представления о том каким должно быть решение.
L>Странное утверждение. Просто опыт: вы на YouTube смотрели видео? Оно тормозит? Наверно задумывались почему?
Просто опыт: у меня данные между серверами передаются быстрее чем поднимаются с винтов. Нифига не тормозит. Наверно потому что 10 Гигабит.
M>> Или Вы думаете, что знаете как надо делать ПРАВИЛЬНОЕ ПО? Нифига Вы не знаете. И никто не знает. Потому нормальные работодатели не ленятся, а пишут, что в их представлении есть ПРАВИЛЬНО.
L>Я рабою в разработке коммерческого ПО уже 15 лет... наверно кое-что понимаю.
Не факт. Чем можете похвастаться? Почему-то такие монстры как Яндекс, Касперский или Агнитум не брезгуют подробно расписывать что они хотят от разрабов. Тоже не вчера в бизнес пришли.
M>>"поэтому стратегия одна — максимально качественный код за минимальные деньги — но качество прежде всего (ну и время разработки и прочее)" — ну это вообще цирк "И того, и другого... можно без хлеба" (c) Винни-Пух.
L>Одни эмоции... по моему Вы тут начали сами себя распалять.
Конечно эмоции. Спокойно это читать невозможно.
M>>Вы пишите "главное: это время за которое деньги вернуться и процент прибыли над затратами, который я получу от реализации проекта". Такими терминами можно разговаривать с ПМами, а не с разрабами. Для разраба есть интересный проект, который он хочет сделать и есть деньги, которые он хочет получать по ходу работы на проектом. Конечно, он хочет делать качественный продукт и довести проект до конца до того как он ему надоест. Прибыль, которую Вы получите с проекта, волнует его меньше, чем судьба очередного марсохода. Заведите себе хорошего ПМ'а.
L>Спрашивали про вилку з/п — я сказал что она не сильно важна и написал почему — основы того как считаются деньги.
Я понял что Вы написали. Я говорю, что так Вы нормальных разрабов не привлечете.
M>>Вы поймите, что для разраба такая вакансия это тоже целый проект, который потребует кучи затрат. И при том вообще не понятно как оценить риск не получить работу, Вы же не называете зарплатную вилку, что бы понять какой уровень будет у конкурентов по вакансии, совершенно не понятно какое впечатление могут произвести продемонстрированные скилы, как вообще надо писать код — быстро и как попало или долго и ПРАВИЛЬНО (а как правильно?). M>> На такую вакансию пойдут только те, у кого нет других вариантов. Оно Вам надо?
L>Знаете, у меня только один совет: будьте честными — пишите как умеете и как привыкли. И старайтесь расти — для этого тратьте время на развитие, а не на игры в CS или диспуты о том какие все недоумки вокруг. Не бойтесь — хороший менеджер вас всегда увидит и будет стараться удержать любой ценой. Со временем придут и деньги.
Я умею писать быстро, умею писать быстрый код, умею писать качественно, умею писать раширяемо, умею писать тестируемое, умею писать читаемо. Вам как надо?
L>А то вы тут написали: я вообще не понял, что вы хотите от меня услышать? Что-то себе напридумывали, понавешивали каких-то ярлыков, в чём-то меня обвиняете. Вы ж поймите — лично Вам я не должен ни чего: я решаю свою задачу, найти человека который бы сработался со мной — всё. Делаю это так как считаю нужным. Да формат несколько провакационный, но свою задачу он решает.
Сомневаюсь, что Вы найдете адеквата. А если кто-то к Вам по глупости и попадет, то все равно не сработаетесь. Потом будете писать про невменяемых российских разработчиков и про то, как здорово работать с индусами через оДеск. За державу обидно.
L>Наверно если бы я был просто hr я бы и написал что вы хотите: з/п от сих до сих, 100 метров от такого-то люка, всё по КЗОТ. И что бы мне это дало?
Например пачку резюме от адкеватных разрабов.
Здравствуйте, lboss, Вы писали:
M>>Вы говорите человеку, что remoting медленный протокол, что тупо передавать целые скриншоты это тяжко для сети. Ну дык, а где требования по аппаратным ресурсам? Короче, у Вас собеседование пройдет только телепат, который угадает все Ваши представления о том каким должно быть решение.
L>Странное утверждение. Просто опыт: вы на YouTube смотрели видео? Оно тормозит? Наверно задумывались почему?
Ютуб не так уж и хорошо работает, подлагивает иногда, хотя уменя инет 10 мегабит чего ему заглаза хватает.
Но это сравнение в корне не корректно. Фоновая передача видео неимеет ничего общего с интерактивной реалтайм работой ремоута:
— Видео можно кешировать и оно с запасом на перед закачивается, в ремоуте такого неполучится.
— В видео происходит сжатие потока, т.е. сжимается кубик состоящий из нескольких кадров, в случае с ремоутом в сжатие участвует лишь один кадр — потенциальная степень сжатия вразы меньше.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, lboss, Вы писали: ...
Знаете, по моему, Вы пытаетесь проецировать на меня свой негативный опыт работы с заказчиком. В результате из малого количества фраз строите какие дикие теории и обвиняете меня Бог пойми в чём. Опять повторюсь: лично Вам я ни чего не должен, в том числе не должен перед Вами оправдываться или отчитываться в своих поступках: не хотите со мной работать: я не повешусь, я переживу. Не думаю, что есть хоть какой-то смысл продолжать дальше беседу.
Здравствуйте, bobik123, Вы писали:
B>Здравствуйте, lboss, Вы писали:
B>А как черный цвет на исходной картинке от черного цвета в результате XOR? Или я что-то недопонял?
Хм... если на исходной картинке и на новой картинке цвета совпадают, то в результате XOR получится 0 — то есть черный цвет. Свойством операции XOR является не потеря данных: то есть если Вы к получившейся картинке сделаете операцию XOR с оригинальной, то вы получите текущую картинку. От сюда получается: надо один раз передать базовую картинку, а потом для передачи новой картинки, делать XOR с базовой — в результате в местах которые не поменялись будет черный цвет, который хорошо сожмётся при передаче. На стороне клиента надо будет просто сделать XOR и базовой картинкой и получите текущую.
В реальности, есть пару но: 1. если сжимать jpeg или чем-то похожим, то там будет потеря цвета, в результате картинка на клиенте будет плыть — придётся периодически пересылать базовую картинку целиком, 2. чтобы не накапливать разницу, надо базовую картинку всё время менять на текущую. Но тут возникают сложности такого порядка: по идее если вы транслируете потоковое видео, то разные клиенты с разной скоростью принимают данные. И хорошо бы было пропускать кадры в середине если клиент медленный... В общем если интересно — об этом проще почитать.
N_>Ютуб не так уж и хорошо работает, подлагивает иногда, хотя уменя инет 10 мегабит чего ему заглаза хватает. N_>Но это сравнение в корне не корректно. Фоновая передача видео неимеет ничего общего с интерактивной реалтайм работой ремоута: N_>- Видео можно кешировать и оно с запасом на перед закачивается, в ремоуте такого неполучится. N_>- В видео происходит сжатие потока, т.е. сжимается кубик состоящий из нескольких кадров, в случае с ремоутом в сжатие участвует лишь один кадр — потенциальная степень сжатия вразы меньше.
Вот видите как хорошо: видно вы в теме. Хотя последнее утверждение спорно — кто сказал что при пропускной способности в 25 кадров нельзя сжимать по 5 кадров — глаз это заметит?
M>Вот Ваша вакансия как раз очень похожа на размещение заказа. Вам правильно посоветовали рентАкодера. Если хотите отдать распределение баланса время/качество/деньги разрабу, то это самый настоящий контракт на работу, а никак не прием сотрудника.
Мазай прав, ваше объявление смахивает на поиск готового решения и мозгов, которые бы его поддерживали. Вы даже задекларировали готовность за это заплатить. Все остальное, это шелуха. Таковы реалии бизнеса.
L>В реальности, есть пару но: 1. если сжимать jpeg или чем-то похожим, то там будет потеря цвета, в результате картинка на клиенте будет плыть — придётся периодически пересылать базовую картинку целиком, 2. чтобы не накапливать разницу, надо базовую картинку всё время менять на текущую. Но тут возникают сложности такого порядка: по идее если вы транслируете потоковое видео, то разные клиенты с разной скоростью принимают данные. И хорошо бы было пропускать кадры в середине если клиент медленный... В общем если интересно — об этом проще почитать.
Ага, вспомнил немного.. На самом деле я когда-то делал похожую штуку но уже напроч забыл что за проблемы были. Вроде как раз описанный мной способ с прямоугольниками (кстати, в каком-то опенсорсе есть тот же способ) показался самым простым чтобы не заморачиваться с разницей и расплытием.
Суть: делаешь скриншот — это база. Его отсылаем. Далее делаем еще скриншот и сравниваем по частям (memcmp тогда гораздо быстрее работало чем StretchBlt\BitBlt) с исходным. Накапливаем разницу и решаем послать ли нам изменившиеся пережатые прямоугольники или опять весь целиком. Отсылаем то, что решили, текущим делаем последний скриншот и так далее.
А в случае с mirror драйвером нам просто нет нужны снимать скриншоты — он нам говорит что изменилось и мы эти части отсылаем. Как-то так вроде было...
Здравствуйте, lboss, Вы писали: N_>>- В видео происходит сжатие потока, т.е. сжимается кубик состоящий из нескольких кадров, в случае с ремоутом в сжатие участвует лишь один кадр — потенциальная степень сжатия вразы меньше. L>Вот видите как хорошо: видно вы в теме. Хотя последнее утверждение спорно — кто сказал что при пропускной способности в 25 кадров нельзя сжимать по 5 кадров — глаз это заметит?
Сжимать то по несколько кадров можно, но в случае РДП нет смысла. Пользователю актуальна только последняя картинка, а не видео что том происходило до этого. Т.е. из присланых 5-ти кадров лишь один будет показан пользователю, остальные 4-ре ненужны. А значит использовать алгоритмы применяемые в видео невыйдет( они оперируют с толстой пачкой из последовательных кадров).
B>А в случае с mirror драйвером нам просто нет нужны снимать скриншоты — он нам говорит что изменилось и мы эти части отсылаем. Как-то так вроде было...
Ну с этим я согласен. Хотя к данной задаче оно вряд-ли имеет отношения — задание вроде тестовое, а тут целый драйвер — сложно это. Если делать в реальном проекте — то этот вопрос можно было рассмотреть.
В VNC (на сколько я помню — давно исходники смотрел), просто перехватывались WM_PAINT у окон и эти прямоугольники считались нужными к передаче. Вариантов много.
N_>Сжимать то по несколько кадров можно, но в случае РДП нет смысла. Пользователю актуальна только последняя картинка, а не видео что том происходило до этого. Т.е. из присланых 5-ти кадров лишь один будет показан пользователю, остальные 4-ре ненужны. А значит использовать алгоритмы применяемые в видео невыйдет( они оперируют с толстой пачкой из последовательных кадров).
Не все алгоритмы так себя ведут. В общем, если Вы участвуете в конкурсе, буду рад с вами пообщаться после среды. Если нет — всё равно спасибо.
Здравствуйте, Дед Пихто, Вы писали:
ДП>Мазай прав, ваше объявление смахивает на поиск готового решения и мозгов, которые бы его поддерживали. Вы даже задекларировали готовность за это заплатить. Все остальное, это шелуха. Таковы реалии бизнеса.
Насчёт "смахивает", Вы правы. Мазай не прав, что из этого "смахивает" вывел целую теорию заговора.
Реально я деньги пообещал по простой причине — все мы люди занятые, и делать тех задание людям достаточно высокой квалификации довольно грустно — делаешь крутой код, и даже если тебя берут тебе эти часы не оплачивают. Понятно я не мог оплачивать всем приславшим код, поэтому сделал половинчатое решение — пообещал оплату только победителю. Результат получился немного не тот что я хотел: люди всё равно не делают задание, но интерес к теме поднялся, а это вызвало поток резюме — так что я не жалею.
А так, спасибо, что не даёте вакансии уйти с первой строчки Но можно уже не помогать — я более менее очертил круг людей, с которыми буду говорить после среды: кто прислал адекватные предложения — надеюсь всё получится
Всем спасибо, резюме ещё принимается до среды, включительно — не забывайте присылать примеры кода.
Здравствуйте, lboss, Вы писали:
L>Не все алгоритмы так себя ведут. В общем, если Вы участвуете в конкурсе, буду рад с вами пообщаться после среды. Если нет — всё равно спасибо.
Резюме я вам отослал, но делать тестовые задания обьемом более 1-го часа не в моих правилах. Это уже работа которая должна оплачиваться.
B>>А в случае с mirror драйвером нам просто нет нужны снимать скриншоты — он нам говорит что изменилось и мы эти части отсылаем. Как-то так вроде было... L>Ну с этим я согласен. Хотя к данной задаче оно вряд-ли имеет отношения — задание вроде тестовое, а тут целый драйвер — сложно это. Если делать в реальном проекте — то этот вопрос можно было рассмотреть. L>В VNC (на сколько я помню — давно исходники смотрел), просто перехватывались WM_PAINT у окон и эти прямоугольники считались нужными к передаче. Вариантов много.
Вариантов много, у меня тогда небыло возможности использовать хуки, поэтому были скриншоты..
lboss пишет:
> В VNC (на сколько я помню — давно исходники смотрел), просто > перехватывались WM_PAINT у окон и эти прямоугольники считались нужными к > передаче. Вариантов много.
ага, это именно поэтому оно некоторые owner draw окошки не показывает?
L>С уважением, Вадим. L>E-Mail: vadim@iv-soft.ru L>С уважением Вадим.
После увиденного в этой ветке, будьте добры предоставить references в количестве не менее трех от Ваших предыдущих работников а мы решим стоит ли иметь с Вами дело.
Здравствуйте, Олег К., Вы писали:
L>>С уважением, Вадим. L>>E-Mail: vadim@iv-soft.ru L>>С уважением Вадим. ОК>После увиденного в этой ветке, будьте добры предоставить references в количестве не менее трех от Ваших предыдущих работников а мы решим стоит ли иметь с Вами дело.
ОК>С уважением, Олег.
Здравствуйте, lboss, Вы писали:
L>Здравствуйте, barn_czn, Вы писали: L>Я думаю ближе к среде напишу статистику предложенных решений со своим оценками — может кому интересно.
Здравствуйте, MScanner, Вы писали:
MS>И где обещанное, собственно говоря?
Вот оно:
Всего пришло 47 заявок.
Из низ 9 было не рассматривалось по причинам:
1. Нет примера кода, только резюме (я напоминал, но не дошло) — 7
2. Являются командами (хотя я написал, что ищу разработчика) — 2
29 заявок было отклонено из-за стиля кода (тут смешано — у некоторых несколько ошибок сразу, поэтому сумма процентов не равна 100!):
~30% "голимый" С стиль (это когда мешанина из С и С++ стилей/классов, в результате получается что-то страшное)
~80% — сильно начальный уровень знаний и не внимательность. Пример, который запомнился:
BOOL bOk = TRUE;
if(bOk)
{
bOk = DoSmt();
bOk = TRUE;
}
if(bOk)
{
.... //Ну и дальше в том же стиле.
~60% "изобретание велосипедов" — SmartPtr, CriticalSection, CString и прочее, кто во что горазд. Часто реализации с ошибками — зачем тогда вообще этим заниматься?
~30% использование технологий, которые знает автор (или хочет изучить!), а не которые эффективны проекте: remoting, WCF и т.п.
6 человек были отклонены из-за завышенных требований.
Так как сам я такой проект сделал на 15 часов, завышенными считалось выполнение проекта более чем за 150 часов, без внятного объяснения почему так много (один человек написал, что нужно более 1000 часов, и расписал что имеет в виду под этим — он не был отклонён: расчёт разумный, на большой проект).
Собственно осталось 3 человека.
Лучшим решением было простое решение на DirectShow. Человек его не использовал до этого, поэтому наброски кода были достаточно не опытные, но направление и стиль, понравился. Было запрошено 4 часа по рейту $15. Собственно сейчас веду переговоры о найме.
2 других:
Один расписал большой проект более 1000 часов с грамотным обоснованием. Хотя я не открывал вакансию PM, но тут я буду думать.
Другой предложил меньше 10 часов по $10 и написал код, к сожалению уровень достаточно начальный, но правильный, тоже буду думать и общаться — может junior'ом возму.
А вообще резюме:
На rsdn сильно начальный уровень людей тусит (по сравнению с моими ожиданиями). В следующий раз пойду на hh.ru — так похоже эффективней. Плюс есть какие-то странные люди: все из себя крутые, а как просишь код прислать, встают в позу: ты типа, кто такой чтоб меня оценивать: у меня тут написано 10 лет С++ — значит я крут... — такая позиция мне не понятна.
Без обид: кому отказал, резюме у меня есть — возможно ещё пообщаемся, а кто только начинает: крепитесь — молодым всегда трудно в начале.
Аха, Вы ожидаете вопросов и понимания? Ну то есть нужно чтоб разраб еще и требования умел из клиентов выколупывать? Вы сами ставите себя на позицию не работодателя, а заказчика, причем заказчика геморройного.
"И того, и другого... можно без хлеба" (c) Винни-Пух.
