Я думаю в перспективе это скорее орбитальное оружие. Отсутствие взрывающихся частей делает безопасным его хранение. Электричество можно получать от Солнца, будет долго накапливаться, зато не нужна огромная силовая установка. Разгон до 6-9к км/ч при выстреле с орбиты вниз позволит иметь, я думаю, достаточно хорошую точность. И никакой отдачи.
А самое главное по конвенциям провести можно. Ну правда, конденсаторы и стальные болванки — кто сказал что это оружие? Нифига, это мирные отряды космической самообороны :)
Стальной снаряд, разогнанный с помощью электромагнитного поля можно отклонить от курса с помощью другого электромагнитного поля. Даже наводить не надо. Привет силовым щитам. Будущее наступает.
694 дня для одного человека
347 дней для двоих
174 дня для четверых
87 дней для восьмерых
44 дня для шестнадцати
22 дня два тридцати двух
11 дней для шестидесяти четырех
6 дней для ста двадцати восьми
3 дня для двухсот пятидесяти шести
256 человек могут уничтожить 6 миллионов зомби за 3 дня. Выстрел в голову за 10 секунд при том что цели не скрываются, а идут толпой — это с очень большим запасом на перезарядку, на почесать нос, на передохнуть, на смениться. Работая в несколько смен одна тысяча солдат вполне обеспечит среднюю скорострельность на таком уровне. Да даже если две тысячи. Все-равно соотношение сил получается 1 к 3000-6000. При таком раскладе опасность зомби не выглядит такой уж опасной.
Думаю с танками проблем будет куда больше — они будут застрявать, ломаться, обслуживать их нужно будет в толпе зомбей. При этом танк не сможет задавить 3000-6000 зомби за раз, увязнет. А стрелковые гнезда на высотках легко обеспечиваются сбросом ресурсов с вертолетов. И в течении максимум недели основная часть угрозы будет устранена.
Вероятность это одно, а факты другое. Две атомные бомбы взорваны в боевых целях, две АЭС взорвались в мирное время. Может когда ядерная война начнется то в пересчете взрывов на тысячу лет аварии и будут иметь значительно меньшую вероятность, но пока что имеем две аварии за 30 лет и ни одного боевого взрыва за это же время.
Книга «Мировая война Z», книга, а не фильм, дает достаточно простой и по размышлениям выглядящий реалистичным ответ на этот вопрос. Суть в том что зомби можно просто перестрелять. Если не брать фантастическую скорость, а брать реалистичных «некроамериканцев» с ограниченной подвижностью то засев на крыше дома нужно будет вести прицельную стрельбу по головам на расстояние от 30 до 100 метров, что не так сложно даже из охотничьего оружия. Делая по 5-6 прицельных выстрелов в минуту один человек будет убивать огромное количество зомби, а отряд армейских стрелков очистит город за несколько суток. Главное боеприпасы и хорошая точка. Ну и чтобы зомби сами перли на укрепления, чего от них вполне можно ожидать.
В книге после применения всего хайтека, напалма, взрывчатки и техники так и поступили — собрали армию стрелков, разработали прием для приманивания толпы зомбаков и устроили рубилово на пару суток. После чего основная их масса была уничтожена и дальше уже нужно было вылавливать оставшиеся единицы. Что, конечно, совершенно отдельный вид спорта.
Сосичная модель коммуникации мне понравилась. А идущие после этого тезисы о защите от манипуляций, первым шагом к которой является их знание и узнавание натолкнули меня на мысль.
Ведь никто пока не перепрошивал людей. Все эти способы манипуляции и воздействия родились одним путем — путем анализа поведения этих самых людей. То-есть по сути америка не создана, она открыта, но она всегда была там. Люди пользовались, пользуются и будут пользоваться этими способами манипуляций и воздействия независимо от того знают они об этом или нет. Просто знающие будут делать это сознательно и будут иметь больший арсенал, в сравнении с теми кто полагается только на природное чутье.
Но для человека, который хочет защититься и с этой целью приобретает знания все люди превращаются в манипуляторов. И вся коммуникация превращается в набор различных способов манипуляции. Как с этим жить?
Это не праздный вопрос. Я не великий комбинатор но уже теряю доверие к людям, потому что за невинными когда-то фразами вижу конкретные техники. И как мне теперь научиться разобрать это техника или просто так получилось?
Хотя есть и приятные моменты — редкие встречи с людьми искренними своим несовпадением ни с одним паттерном. Только вот боюсь это просто от недостаточного знания этих паттернов.
А вторая проблема — за любыми своими словами и действиями начинаешь подозревать попытки манипуляции и как честный человек страдаешь от этого. Стараешься так не делать. И выглядишь идиотом, ибо любое разумное общение нет нет да и воздействует на окружающих.
Где-то я слышал фразу вроде «Мы даем людям оружие, учим их убивать, но не учим жить с этим». Кажется в какой-то передаче об американской армии и социализации ветеранов боевых действий.
Как эту проблему решают тренера по коммуникации?
У меня в корридоре три лампочки накаливания по 40 ватт в трех светильниках. За 15 лет после последнего ремонта одну из этих лампочек я не менял ни разу, одну менял один раз и еще одну около 4 раз. Одинаковые светильники, одинаковые лампочки накаливания купленные в магазине. В чем же секрет? Он прост — первой лампочкой пользуются очень редко и по чуть-чуть, второй немного чаще, третья же находится у входной двери и используется очень часто.
Я купил себе два люминисцентных светильника на стену и за год поменял в обоих лампочки по три раза. Понял что это нифига не экономия. Купил той же фирмы уже светодиодный светильник — работает до сих пор на том же месте что и те, то-есть с тем же режимом использования и от той же розетки.
Наверное все-же дешевая электроника на светодиоды влияет не так пагубно, как на люминисцентные лампы.
А цена что этого светодиодного светильника что тех люминесцентных была одинаковой.
Я планирую при ремонте поставить для квартиры один хороший преобразователь тока и пустить на осветительную проводку отдельную линию в 12В. Как раз для того чтобы не иметь проблем с подключением светодиодных ламп, люстр и прочего.
Если электрик подключит 360 вольт на обычную люстру то там тоже так выгорит внутренняя проводка что заменой лампочек не отделаешься — нужно будет менять всю люстру. Или жить в постоянном страхе замыкания и пожара.
Из всех инди игр ролик этой заинтересовал меня больше всего. То-есть я врядли бы купил эту игру и играл в нее, но я в принципе давно не играю в игры такого плана. И то что эта привлекла меня своей оригинальностью — дорогого стоит. Так что я думаю сама идея стоящая, а то что случилась неудача с ее финансированием — не должно останавливать.
Что, как по мне, стоит сделать? Стоит скачать крякнутый юнити со всеми нужными модулями, доделать движок (судя по видео он уже есть хотя бы частично) и выпустить на нем один-два качественных уровня. В которые реально можно играть. И с этим идти либо к издателю либо на кикстартер (придется найти американца, насколько я понимаю тамошнюю систему, себе в компаньены). И когда появятся деньги — купить уже эти лицензии на юнити чтобы очистить совесть и иметь законную возможность продавать свой продукт через издателя.
Рано продумывать продолжение. Не нужно сейчас выдумывать новые фичи. Это, конечно, очень интересное занятие, но для финансового успеха нужно сделать релиз готового продукта, хоть насколько-нибудь законченой версии. Пускай эта тень только бегает, прыгает и кидает копье, а четыре разных врага только бегают за ней и кусают — но чтобы это все реально работало, можно было в это играть и можно было с достаточно малыми затратами дорисовывать новые уровни на старых возможностях и постепенно добавлять возможности новые.
В общем посылаю лучи добра, мне кажется у вас есть реальный шанс на успех и это действительно стоящая идея.
Вцелом я согласен с выраженной мыслью. Тем более что она не сходится с выраженным в статье, а претензии у меня именно к статье.
А вот человек для завязывания шнурков рано или поздно появится. Либо этот процесс будет автоматизирован/упразднен. Доказательств у меня аж два.
Первое теоретическое: когда-то один человек и убивал мамонта, и свежевал его, и резал, и готовил, и ел. А теперь цепочка людей от выращивающего животных до поедающего мясо состоит из нескольких десятков разных профессий. И представитель одной зачастую даже не представляет себя в роли представителя другой. То что сейчас нам кажется очевидным и элементарным, тем что должен уметь каждый человек через сотню другую лет может быть уже совсем иначе. Ведь пару сотен лет назад каждый уважающий себя джентельмен был обязан уметь фехтовать и стрелять, а сейчас этим занимаются либо спортсмены, либо бандиты либо милиция либо армия. Ну либо любители, в порядке хобби.
Ах да, второе практическое. Я не умел завязывать шнурки где-то до 10-11 лет. То-есть у меня получалось, но плохо, поэтому мне их обычно завязывала мама. При этом я был первым учеником в классе, я читал и писал с первого класса лучше других, знал математику, легко все запоминал. Голова работала отлично, а мелкая моторика рук не очень. Когда появится нейроинтерфейс для управления компьютером — дай бог чтобы программисты вообще ходить не разучились и за них этого не делали «узкие специалисты».
Кстати пока писал подумал… А ведь такой человек есть! Только вместо того чтобы завязывать другим шнурки он оптимизировал процесс: молнии, липучки, резинки. Обувь без шнурков — это и есть результат работы специального человека по завязыванию шнурков. И кто скажет что он справился со своей работой не быстрее и качественнее обывателя?
Этому есть простое объяснение — статья обязывает разработчика к чему-то. А разработчик действительно не виноват. Я согласен с тем что он может — он может и дебаггинг на стороне клиента сделать, и ТЗ улучшить и тестирование провести и научиться с людьми общаться. Но ведь еще он может поменять картридж в принтере, может поуправлять проектом, поносить коробки с этажа на этаж. Он все это может, но не должен как пытается убедить нас автор статьи.
Разделение труда такая штука когда каждый делает наилучшим образом именно свой участок работы и не лезет в другие. Есть человек ответственный за ТЗ? Пусть он составляет ТЗ, не отбирай у него хлеб, это не пойдет на пользу ни ему, ни тебе ни ТЗ. Есть процесс баг-трекинга? Не влезай мимо него в исправление багов, иначе ты рискуешь сделать лишнюю, не нужную и не оплаченную работу которая к тому же не будет учтена в будущем планировании менеджментом и в реализации аналогичной фичи реализатором, а так же не будет проверена тестировщиком.
Своими действиями на чужом поле мимо процедур ты не просто получаешь дополнительный опыт в смежных областях, ты отнимаешь его у других и одновременно рушишь стройную производственную систему. К сожалению даже сами управляющие зачастую этого не понимают и являются инициаторами такого разрушения. А потом удивляются что бардак, что никакая система не работает значит все эти системы отстой, мы придумаем свою — все делают всё и работают в поте лица на общее благо как только могут.
Статья начинается с того, как хорошо что программисты уже не меняют картриджы, а являются специализированными разработчиками. Поэтому:
1. Параметры на компьютере пользователя — не проблема разработчика. Как и неправильно составленный баг-репорт. У нас же целый отдел обеспечения качества, который непонятно чем вообще занимаются!
2. Проблема разработчика — делать по ТЗ. А ТЗ — проблема аналитика. Если разработка выполнена по ТЗ — какие могут быть вопросы к разработчику?
3. Взаимодействие разработчика с тестером — хорошо. Позиционирование разработчика как «последний рубеж» единственно несущий ответственность за качество всей разработки — либо плохо либо признак ситуации когда разработчик один и он же и тестер и аналитик и архитектор. А над ним стоит только менеджер, который капает на мозг сроками.
5. Работа разработчика — разрабатывать. А вот работа менеджера — обеспечивать процесс. Менеджер должен знать язык разработчика, а не наоборот. Если разработчик знает язык менеджера — это очень хороший разработчик, который наверное сам скоро станет менеджером, потому что платят больше. Кстати именно от разбиения на порции рождается ответ «готово на 99%» :)
7. Слова, слова, я подозреваю что дело не в формулировке, а в сути. Если посыл будет мягким — он все-равно будет посылом и именно это не нравится автору. Да и опять же — разработчик не должен уметь общаться с людьми, он должен уметь разрабатывать. А менеджер должен уметь его понимать.
4. Вопрос вкуса, навеное. Когда мне начинают задавать наводящие вопросы и я догадываюсь что там косяк — мне кажется что со мной обращаются либо как с ребенком либо пытаются подтрунивать. Лучше сразу сказать — я считаю этот код плохим потому что. Если мне будет что ответить — я отвечу. И в споре родится истина. Если не будет — признаю свою неправоту и запомню как надо.
Но при этом есть очень обидчивые на прямое указание ошибки люди, которым как раз и надо задавать наводящие вопросы создавая эффект будто они сами нашли ошибку и более хороший путь решения. Тоже бывает, все мы разные.
Просто описание моего предыдущего места работы! Самое смешное — там уже растеряли весь отдел разработки и были вынуждены заполнить его студентами. Интересно на кого теперь давят эти администраторы и как делают карьеру.
Такое ощущение что статья написана не разработчиком, а каким-нибудь менеджером. Причем таким матерым менеджером, который в разработке никогда не участвовал, а сразу заканчичвал «Менеджмент и маркетинг» (это, кстати, в моем понимании ругательство и оскорбление :))
Но чтобы не быть голословным нужно аргументировать. Так что детализирую свои претензии по пунктам.
1. А у меня на компе работает. «Я разработчик, я не хочу настраивать ИДЕ, я хочу клац-клац, Ф5 и в продакшн». Слава богу мы уже не те программисты, которые картриджы меняли. Если у меня на компе работает — значит код рабочий, пускай админ разбирается с косяками настройки окружения. Если код написан в соответствии с требованиями, на указанном в требованиях языке, на указанной версии языка, с разрешенными требованиями библиотеками — не проблема программиста заниматься его запуском где-либо кроме собственной машины.
2. До тех пор пока можно порезаться даже безопасной бритвой, если проявить смекалку и фантазию — я буду называть мудаков мудаками. Тем более что режусь я регулярно, мудак эдакий. Задача разработчика — предоставить решение поставленной задачи в поставленных условиях. Если клиент потенциально — дебил способный на что угодно — значит тот кто составлял ТЗ должен был учесть это. Менеджер должен был учесть это и сказать аналитику, аналитик должен был учесть это и описать в ТЗ. А разработчик должен просто предоставить решение, соответствующее требованиям. Если в требованиях чего-то нет — в решении этого тоже может не быть.
3. Тестеры нифига не протестировали, чем они вообще занимаются? Если я — последний рубеж — прошу разделить зарплату отдела тестирования между отделом разработки и упразднить этот отдел «контроля качества» за необоснованностью его существования. Одно дело если тестер попытался что-то сделать, а оно в принципе не работает, но тут смотри пункт 1 — у меня на компьютере запускается. Если нет то это клинический случай. А если тестер нашел хитрый баг на специфической комбинации параметров при совмещении модулей от нескольких разработчиков — то на то он и нужен, этот тестер.
4. Если это писал я то я идиот. Иногда полезно это осознавать. Если речь идет о формулировке то я согласен — не стоит так грубо говорить в команде, слова можно подобрать другие. Но если код — говнокод — его автор должен быть найден и тыкнут носом. Даже если это я сам. В образовательных целях, очевидно же что кто-то умнее и опытнее, а кто-то нет, как можно передать опыт от человека к человеку или осознать что ты стал лучше чем был когда-то если не находить говнокод и не признавать его низкое качество?
5. Формулировка дурацкая, конечно. Но есть такая хорошая шутка что надпись 99% Complete при установке виндоус радует только первые полчаса. Любой разработчик знает что бывает вроде бы мелкая проблема решение которой может потребовать неопределенно долгого времени. А так как разработчики это инженеры, а не менеджеры, они не приучены ни врать ни блефовать, и если не могут дать точный ответ о необходимом времени — дают такой точный ответ, какой умеют. Потому что если я скажу «будет готово через 3 часа», хотя сам в этом не уверен и через три часа готово не будет я не смогу как менеджер сказать «Ну, не получилось, нужно еще три недели», вместо этого я буду чувствовать себя плохо, моя мотивация упадет, самооценка пострадает, эффективность понизится, лояльность к команде, поставившей меня в такие условия ухудшится… ну в общем я надеюсь понятно для менеджера выразился.
Вообще менеджер или тим-лид это «прокладка» между разработчиком и человеком. И он обязан уметь понимать язык разработчика и переводить на человеческий. Поэтому он должен выслушать тираду про проблему с jQuery, задать наводящие вопросы и в документе написать «ориентировочно 3 часа, высокий риск задержки».
6. Да, возможно всё. Но мне несколько раз доводилось говорить «Это невозможно». Почему? Это была экспертная оценка аналитика, исходя из понимания сложности задачи, затрат на ее выполнение и имеющихся ресурсов. Если разработчик говорит что что-то невозможно значит этому есть причины. Можно до них докопаться, выяснить насколько они оправданы и либо согласиться с такой оценкой либо найти пути решения. Но если разработчик говорит «это невозможно» не вдаваясь в подробности менеджеру, с которым давно работает — этому менеджеру следует подумать, скорее всего его умственные способности были оценены негативно.
Впрочем, этот пункт — поле для отдельной полемики об устанавливаемых задачах и предоставляемых ресурсах на их решение. Как говорится «Менеджер думает что если взять 9 женщин то можно родить ребенка за месяц».
7. Если у человека есть определенная профессиональная гордость и она обоснована — разве это не хорошо? Если время человека стоит больше, значительно больше чем время другого человека, который мог бы решить эту задачу и он сообщает об этом — это замечательно! Это возможность оптимизации затрат. Конечно иногда нецелевое использование ресурсов оправдано, но чаще всего нанятый владельцем бизнеса менеджер просто не задумывается о том, что забивает гвозди микроскопом и выступает с позиции «тебе за это платят — делай что я говорю». Очень печальная ситуация, которая не способствует развитию, зато способствует деградации, потере самоуважения, понижению мотивации, ухудшению отношения к коллективу, толкающему на это, пониижению эффективности труда разработчика и в результате приводит к увольнению. И должно уволиться несколько хороших разработчиков чтобы высокое начальство наконец догадалось что проблема в менеджере и наконец-то от него избавилось.
Если разработчику предложить помыть полы в рабочее время он скорее всего тоже не согласится. Причем чам выше зарплата этого разработчика тем более вероятно что он не согласится. Так вот есть в нашей области задачи, сложность которых аналогична мытью полов и является оскорбительной для достигнутого человеком профессионального уровня. И чем выше уровень — тем больше таких задач. Хотя у нас, конечно, люди как правило работы не боятся и сеньер девелоперы бодро носят мебель или коробки с чем попало, потому что у компании видимо нет денег на грузчиков.
Извиняюсь за пропитанный негативом к менеджменту текст. Но люди считающие других «ресурсами» несколько надоели своим отсутствием желания понимать область, в которой работают. Особенно ту часть области где оказывается что вокруг тоже люди, ничуть не хуже себя любимого.
Читаю ваши статьи и удивляюсь — неужели это и есть бизнес с человеческим лицом? Очень хотелось бы видеть всю информацию по ведению этого бизнеса в одном месте. В книге. Лучше всего — электронной и бесплатной :) Думаю по вашему ноу хау можно организовать и совершенно другой вид деятельности. Главное сам подход к ведению дела.
Устройство, конечно, интересное, но в приведенной выше истории с тысячей гривен поменяется только что будет унесен/разбит звонок за 2к гривен. Сомнительный выход из ситуации.
Вообще по характеристикам съемки можно поставить веб-камеру за 10 баксов и подключить ее проводом к компьютеру/планшету/телефону. Или за 30 баксов камеру с вайфаем. Все равно у гика который будет ставить такой глазок есть домашний вайфай. А там уже и качество видео и фото будет лучше и поток без оплаты GSM трафика и возможность удаленного управления через домашний сервер.
Несомненное достоинство этого девайса — детектор движения, который позволяет записывать если кто трется у двери долго. Это хорошо.
Несомненный недостаток — полное отсутствие механической части. Разрядилась батарейка/заглючил софт/хакеры взломали девайс/применена ЕМП пушка — все, что за дверью узнать невозможно.
Я все-же думаю что вещи вроде дверного звонка, дверного глазка, домашнего телефона и прочие постоянного использования и необходимости должны быть комплексными — с примитивной, всегда работающей на простейших принципах частью и дополнительной навороченой, работающей если все хорошо.
А самое главное по конвенциям провести можно. Ну правда, конденсаторы и стальные болванки — кто сказал что это оружие? Нифига, это мирные отряды космической самообороны :)
347 дней для двоих
174 дня для четверых
87 дней для восьмерых
44 дня для шестнадцати
22 дня два тридцати двух
11 дней для шестидесяти четырех
6 дней для ста двадцати восьми
3 дня для двухсот пятидесяти шести
256 человек могут уничтожить 6 миллионов зомби за 3 дня. Выстрел в голову за 10 секунд при том что цели не скрываются, а идут толпой — это с очень большим запасом на перезарядку, на почесать нос, на передохнуть, на смениться. Работая в несколько смен одна тысяча солдат вполне обеспечит среднюю скорострельность на таком уровне. Да даже если две тысячи. Все-равно соотношение сил получается 1 к 3000-6000. При таком раскладе опасность зомби не выглядит такой уж опасной.
Думаю с танками проблем будет куда больше — они будут застрявать, ломаться, обслуживать их нужно будет в толпе зомбей. При этом танк не сможет задавить 3000-6000 зомби за раз, увязнет. А стрелковые гнезда на высотках легко обеспечиваются сбросом ресурсов с вертолетов. И в течении максимум недели основная часть угрозы будет устранена.
В книге после применения всего хайтека, напалма, взрывчатки и техники так и поступили — собрали армию стрелков, разработали прием для приманивания толпы зомбаков и устроили рубилово на пару суток. После чего основная их масса была уничтожена и дальше уже нужно было вылавливать оставшиеся единицы. Что, конечно, совершенно отдельный вид спорта.
Ведь никто пока не перепрошивал людей. Все эти способы манипуляции и воздействия родились одним путем — путем анализа поведения этих самых людей. То-есть по сути америка не создана, она открыта, но она всегда была там. Люди пользовались, пользуются и будут пользоваться этими способами манипуляций и воздействия независимо от того знают они об этом или нет. Просто знающие будут делать это сознательно и будут иметь больший арсенал, в сравнении с теми кто полагается только на природное чутье.
Но для человека, который хочет защититься и с этой целью приобретает знания все люди превращаются в манипуляторов. И вся коммуникация превращается в набор различных способов манипуляции. Как с этим жить?
Это не праздный вопрос. Я не великий комбинатор но уже теряю доверие к людям, потому что за невинными когда-то фразами вижу конкретные техники. И как мне теперь научиться разобрать это техника или просто так получилось?
Хотя есть и приятные моменты — редкие встречи с людьми искренними своим несовпадением ни с одним паттерном. Только вот боюсь это просто от недостаточного знания этих паттернов.
А вторая проблема — за любыми своими словами и действиями начинаешь подозревать попытки манипуляции и как честный человек страдаешь от этого. Стараешься так не делать. И выглядишь идиотом, ибо любое разумное общение нет нет да и воздействует на окружающих.
Где-то я слышал фразу вроде «Мы даем людям оружие, учим их убивать, но не учим жить с этим». Кажется в какой-то передаче об американской армии и социализации ветеранов боевых действий.
Как эту проблему решают тренера по коммуникации?
У меня в корридоре три лампочки накаливания по 40 ватт в трех светильниках. За 15 лет после последнего ремонта одну из этих лампочек я не менял ни разу, одну менял один раз и еще одну около 4 раз. Одинаковые светильники, одинаковые лампочки накаливания купленные в магазине. В чем же секрет? Он прост — первой лампочкой пользуются очень редко и по чуть-чуть, второй немного чаще, третья же находится у входной двери и используется очень часто.
Наверное все-же дешевая электроника на светодиоды влияет не так пагубно, как на люминисцентные лампы.
А цена что этого светодиодного светильника что тех люминесцентных была одинаковой.
Если электрик подключит 360 вольт на обычную люстру то там тоже так выгорит внутренняя проводка что заменой лампочек не отделаешься — нужно будет менять всю люстру. Или жить в постоянном страхе замыкания и пожара.
Что, как по мне, стоит сделать? Стоит скачать крякнутый юнити со всеми нужными модулями, доделать движок (судя по видео он уже есть хотя бы частично) и выпустить на нем один-два качественных уровня. В которые реально можно играть. И с этим идти либо к издателю либо на кикстартер (придется найти американца, насколько я понимаю тамошнюю систему, себе в компаньены). И когда появятся деньги — купить уже эти лицензии на юнити чтобы очистить совесть и иметь законную возможность продавать свой продукт через издателя.
Рано продумывать продолжение. Не нужно сейчас выдумывать новые фичи. Это, конечно, очень интересное занятие, но для финансового успеха нужно сделать релиз готового продукта, хоть насколько-нибудь законченой версии. Пускай эта тень только бегает, прыгает и кидает копье, а четыре разных врага только бегают за ней и кусают — но чтобы это все реально работало, можно было в это играть и можно было с достаточно малыми затратами дорисовывать новые уровни на старых возможностях и постепенно добавлять возможности новые.
В общем посылаю лучи добра, мне кажется у вас есть реальный шанс на успех и это действительно стоящая идея.
Вцелом я согласен с выраженной мыслью. Тем более что она не сходится с выраженным в статье, а претензии у меня именно к статье.
А вот человек для завязывания шнурков рано или поздно появится. Либо этот процесс будет автоматизирован/упразднен. Доказательств у меня аж два.
Первое теоретическое: когда-то один человек и убивал мамонта, и свежевал его, и резал, и готовил, и ел. А теперь цепочка людей от выращивающего животных до поедающего мясо состоит из нескольких десятков разных профессий. И представитель одной зачастую даже не представляет себя в роли представителя другой. То что сейчас нам кажется очевидным и элементарным, тем что должен уметь каждый человек через сотню другую лет может быть уже совсем иначе. Ведь пару сотен лет назад каждый уважающий себя джентельмен был обязан уметь фехтовать и стрелять, а сейчас этим занимаются либо спортсмены, либо бандиты либо милиция либо армия. Ну либо любители, в порядке хобби.
Ах да, второе практическое. Я не умел завязывать шнурки где-то до 10-11 лет. То-есть у меня получалось, но плохо, поэтому мне их обычно завязывала мама. При этом я был первым учеником в классе, я читал и писал с первого класса лучше других, знал математику, легко все запоминал. Голова работала отлично, а мелкая моторика рук не очень. Когда появится нейроинтерфейс для управления компьютером — дай бог чтобы программисты вообще ходить не разучились и за них этого не делали «узкие специалисты».
Кстати пока писал подумал… А ведь такой человек есть! Только вместо того чтобы завязывать другим шнурки он оптимизировал процесс: молнии, липучки, резинки. Обувь без шнурков — это и есть результат работы специального человека по завязыванию шнурков. И кто скажет что он справился со своей работой не быстрее и качественнее обывателя?
Разделение труда такая штука когда каждый делает наилучшим образом именно свой участок работы и не лезет в другие. Есть человек ответственный за ТЗ? Пусть он составляет ТЗ, не отбирай у него хлеб, это не пойдет на пользу ни ему, ни тебе ни ТЗ. Есть процесс баг-трекинга? Не влезай мимо него в исправление багов, иначе ты рискуешь сделать лишнюю, не нужную и не оплаченную работу которая к тому же не будет учтена в будущем планировании менеджментом и в реализации аналогичной фичи реализатором, а так же не будет проверена тестировщиком.
Своими действиями на чужом поле мимо процедур ты не просто получаешь дополнительный опыт в смежных областях, ты отнимаешь его у других и одновременно рушишь стройную производственную систему. К сожалению даже сами управляющие зачастую этого не понимают и являются инициаторами такого разрушения. А потом удивляются что бардак, что никакая система не работает значит все эти системы отстой, мы придумаем свою — все делают всё и работают в поте лица на общее благо как только могут.
1. Параметры на компьютере пользователя — не проблема разработчика. Как и неправильно составленный баг-репорт. У нас же целый отдел обеспечения качества, который непонятно чем вообще занимаются!
2. Проблема разработчика — делать по ТЗ. А ТЗ — проблема аналитика. Если разработка выполнена по ТЗ — какие могут быть вопросы к разработчику?
3. Взаимодействие разработчика с тестером — хорошо. Позиционирование разработчика как «последний рубеж» единственно несущий ответственность за качество всей разработки — либо плохо либо признак ситуации когда разработчик один и он же и тестер и аналитик и архитектор. А над ним стоит только менеджер, который капает на мозг сроками.
5. Работа разработчика — разрабатывать. А вот работа менеджера — обеспечивать процесс. Менеджер должен знать язык разработчика, а не наоборот. Если разработчик знает язык менеджера — это очень хороший разработчик, который наверное сам скоро станет менеджером, потому что платят больше. Кстати именно от разбиения на порции рождается ответ «готово на 99%» :)
7. Слова, слова, я подозреваю что дело не в формулировке, а в сути. Если посыл будет мягким — он все-равно будет посылом и именно это не нравится автору. Да и опять же — разработчик не должен уметь общаться с людьми, он должен уметь разрабатывать. А менеджер должен уметь его понимать.
4. Вопрос вкуса, навеное. Когда мне начинают задавать наводящие вопросы и я догадываюсь что там косяк — мне кажется что со мной обращаются либо как с ребенком либо пытаются подтрунивать. Лучше сразу сказать — я считаю этот код плохим потому что. Если мне будет что ответить — я отвечу. И в споре родится истина. Если не будет — признаю свою неправоту и запомню как надо.
Но при этом есть очень обидчивые на прямое указание ошибки люди, которым как раз и надо задавать наводящие вопросы создавая эффект будто они сами нашли ошибку и более хороший путь решения. Тоже бывает, все мы разные.
Но чтобы не быть голословным нужно аргументировать. Так что детализирую свои претензии по пунктам.
1. А у меня на компе работает. «Я разработчик, я не хочу настраивать ИДЕ, я хочу клац-клац, Ф5 и в продакшн». Слава богу мы уже не те программисты, которые картриджы меняли. Если у меня на компе работает — значит код рабочий, пускай админ разбирается с косяками настройки окружения. Если код написан в соответствии с требованиями, на указанном в требованиях языке, на указанной версии языка, с разрешенными требованиями библиотеками — не проблема программиста заниматься его запуском где-либо кроме собственной машины.
2. До тех пор пока можно порезаться даже безопасной бритвой, если проявить смекалку и фантазию — я буду называть мудаков мудаками. Тем более что режусь я регулярно, мудак эдакий. Задача разработчика — предоставить решение поставленной задачи в поставленных условиях. Если клиент потенциально — дебил способный на что угодно — значит тот кто составлял ТЗ должен был учесть это. Менеджер должен был учесть это и сказать аналитику, аналитик должен был учесть это и описать в ТЗ. А разработчик должен просто предоставить решение, соответствующее требованиям. Если в требованиях чего-то нет — в решении этого тоже может не быть.
3. Тестеры нифига не протестировали, чем они вообще занимаются? Если я — последний рубеж — прошу разделить зарплату отдела тестирования между отделом разработки и упразднить этот отдел «контроля качества» за необоснованностью его существования. Одно дело если тестер попытался что-то сделать, а оно в принципе не работает, но тут смотри пункт 1 — у меня на компьютере запускается. Если нет то это клинический случай. А если тестер нашел хитрый баг на специфической комбинации параметров при совмещении модулей от нескольких разработчиков — то на то он и нужен, этот тестер.
4. Если это писал я то я идиот. Иногда полезно это осознавать. Если речь идет о формулировке то я согласен — не стоит так грубо говорить в команде, слова можно подобрать другие. Но если код — говнокод — его автор должен быть найден и тыкнут носом. Даже если это я сам. В образовательных целях, очевидно же что кто-то умнее и опытнее, а кто-то нет, как можно передать опыт от человека к человеку или осознать что ты стал лучше чем был когда-то если не находить говнокод и не признавать его низкое качество?
5. Формулировка дурацкая, конечно. Но есть такая хорошая шутка что надпись 99% Complete при установке виндоус радует только первые полчаса. Любой разработчик знает что бывает вроде бы мелкая проблема решение которой может потребовать неопределенно долгого времени. А так как разработчики это инженеры, а не менеджеры, они не приучены ни врать ни блефовать, и если не могут дать точный ответ о необходимом времени — дают такой точный ответ, какой умеют. Потому что если я скажу «будет готово через 3 часа», хотя сам в этом не уверен и через три часа готово не будет я не смогу как менеджер сказать «Ну, не получилось, нужно еще три недели», вместо этого я буду чувствовать себя плохо, моя мотивация упадет, самооценка пострадает, эффективность понизится, лояльность к команде, поставившей меня в такие условия ухудшится… ну в общем я надеюсь понятно для менеджера выразился.
Вообще менеджер или тим-лид это «прокладка» между разработчиком и человеком. И он обязан уметь понимать язык разработчика и переводить на человеческий. Поэтому он должен выслушать тираду про проблему с jQuery, задать наводящие вопросы и в документе написать «ориентировочно 3 часа, высокий риск задержки».
6. Да, возможно всё. Но мне несколько раз доводилось говорить «Это невозможно». Почему? Это была экспертная оценка аналитика, исходя из понимания сложности задачи, затрат на ее выполнение и имеющихся ресурсов. Если разработчик говорит что что-то невозможно значит этому есть причины. Можно до них докопаться, выяснить насколько они оправданы и либо согласиться с такой оценкой либо найти пути решения. Но если разработчик говорит «это невозможно» не вдаваясь в подробности менеджеру, с которым давно работает — этому менеджеру следует подумать, скорее всего его умственные способности были оценены негативно.
Впрочем, этот пункт — поле для отдельной полемики об устанавливаемых задачах и предоставляемых ресурсах на их решение. Как говорится «Менеджер думает что если взять 9 женщин то можно родить ребенка за месяц».
7. Если у человека есть определенная профессиональная гордость и она обоснована — разве это не хорошо? Если время человека стоит больше, значительно больше чем время другого человека, который мог бы решить эту задачу и он сообщает об этом — это замечательно! Это возможность оптимизации затрат. Конечно иногда нецелевое использование ресурсов оправдано, но чаще всего нанятый владельцем бизнеса менеджер просто не задумывается о том, что забивает гвозди микроскопом и выступает с позиции «тебе за это платят — делай что я говорю». Очень печальная ситуация, которая не способствует развитию, зато способствует деградации, потере самоуважения, понижению мотивации, ухудшению отношения к коллективу, толкающему на это, пониижению эффективности труда разработчика и в результате приводит к увольнению. И должно уволиться несколько хороших разработчиков чтобы высокое начальство наконец догадалось что проблема в менеджере и наконец-то от него избавилось.
Если разработчику предложить помыть полы в рабочее время он скорее всего тоже не согласится. Причем чам выше зарплата этого разработчика тем более вероятно что он не согласится. Так вот есть в нашей области задачи, сложность которых аналогична мытью полов и является оскорбительной для достигнутого человеком профессионального уровня. И чем выше уровень — тем больше таких задач. Хотя у нас, конечно, люди как правило работы не боятся и сеньер девелоперы бодро носят мебель или коробки с чем попало, потому что у компании видимо нет денег на грузчиков.
Извиняюсь за пропитанный негативом к менеджменту текст. Но люди считающие других «ресурсами» несколько надоели своим отсутствием желания понимать область, в которой работают. Особенно ту часть области где оказывается что вокруг тоже люди, ничуть не хуже себя любимого.
Вообще по характеристикам съемки можно поставить веб-камеру за 10 баксов и подключить ее проводом к компьютеру/планшету/телефону. Или за 30 баксов камеру с вайфаем. Все равно у гика который будет ставить такой глазок есть домашний вайфай. А там уже и качество видео и фото будет лучше и поток без оплаты GSM трафика и возможность удаленного управления через домашний сервер.
Несомненное достоинство этого девайса — детектор движения, который позволяет записывать если кто трется у двери долго. Это хорошо.
Несомненный недостаток — полное отсутствие механической части. Разрядилась батарейка/заглючил софт/хакеры взломали девайс/применена ЕМП пушка — все, что за дверью узнать невозможно.
Я все-же думаю что вещи вроде дверного звонка, дверного глазка, домашнего телефона и прочие постоянного использования и необходимости должны быть комплексными — с примитивной, всегда работающей на простейших принципах частью и дополнительной навороченой, работающей если все хорошо.
А вообще я думаю это порочная практика — делать диодные индикаторы под управлением ПО. Они все-же должны быть хардварными.