"«Монорельс» пока может и убыточен". «может»? Есть какие-то сомнения?)
Трамвай + эстакада над промзоной в районе пл. Останкино вышла бы дешевле. И никаких «космических технологий» от института теплотехники.
по поводу ваших тезисов о пробках — разве есть какие-то принципиальные противоречия с моими тезисами? Пробки не исчезнут пока не будет альтернативы — или стоять в пробке но в своём авто, или проехать пол-москвы за 20 минут но на общественном транспорте
основной мыслью моего длинного комментария является то, что для решения/снятия остроты проблемы пробок «высокие технологии», о кторых вы так много говорили в статье, не являются необходимыми. Достаточно уже существующих + реальная борьба с коррупцией (без этого для нас всегда всё будет «слишком дорого»). (Что конечно же не исключает автоматической диспетчеризации той же трамвайной сети.)
всё звучит оч классно и здорово. но:
«монорельс» убыточен (можете посмотреть в википедии + гдето мне встречались данные что для тех людей которых перевозит момнорельс на дотаци можно было просто всех перевезти на такси)
«Персональный автоматический транспорт» который запустили в Хитроу — идея прекрасная но пока для нас слишком дорого
«московске» пробки никаким расширением дорог не решить — просто потому что любой кому действтельно нужна машина — хоть какую развалюху — но смоет купить.
Единственным разумным и реалистичным вариантом мне видится:
Перехватывающие парковки в районе садового кольца. (если каетсчя что места нет — обратите внимание на тысячи «бизнессцентров» которые постоянно строятся. им почемуто место находится)
Внутри садового — плотная сеть троллейбусных маршрутов
Въезд внутрь садового запретить
перехватывающие парковки в районе мкада
сеть радиальных трамвайных маршрутов. причём — трамвайные пути должны быть проложены по отдельной полосе, куда запрещён въезд автомобилям.
Утром, когда поток большой — трамваи можно сцеплять в составы, днём — отцеплять в депо и/или пускать по кольцевым маршрутам
Трамвай кстати может развивать скорость до 75км/час. При необходимости можно сделать в отдельных местах для них эстакады — всё-равно дешевле монорельса.
И вот когда появится реальная альтернатива — добраться из бутово до садового кольца за 20 минут без толчеи, или стоять в пробке несколько часов — количество машин на дорогах станет меньше.
Заметьте — для этого не нужны ультрасуперкосмические технологии — достаточно обуздать коррупцию (строить дороги «интересней» чем прокладывать трамвайные пути)
Впрочем — возможно, что когда стартапноинвестиционный ажиотаж стихнет и толковые phpмидлы перестанут «хотеть и получать» 100т — схема о которой я говорил и станет лишена смысла. Ну или аутсорс в регионы — смотря что наступит раньше.
Ну вобще-то не правда. Никого ниоткуда и никуда я спускать не хочу.
Изначальный посыл был в том что rubbyrabbit предлагал спросить на собеседовании у кандидата про архитектуру, которой кандидат гордится.
Я высказал обоснованные сомнения в том что хорошая архитекутра может существовать и спросил — встречался ли rubbyrabbit с такой на собеседованиях в том смысле что насколько такой метод хорошо работает.
Я спроектировал проект. Я считаю своё решение очень хорошим и горжусь им. Но действительно ли оно хорошее? Убедиться в этом можно только обсудив его с кем то «со стороны».
Так вы обсуждали свою архитектуру, которой вы гордитесь, с кем-то со стороны?
>Вам известны такие примеры? Мне нет.
К сожалению известны
>Скажите это бухгалтеру или заказчику.
Странно что вы не упомянули запуск спутников на марс.
Да — ошибки в бухгалтерском по стоят денег (и потенциально очень больших).
Но процент уникального бухгалтерского ПО серди «легиона вебпроектов» не велик (заметьте — в своём комментарии я использовал слово «часто», а не «всегда»)
А вот ещё кстати терминологический пример.
DTO(Data transfer object) и VO(Value Object) иногда используются как синонимы или один вместо другого. Ничего страшного в этом нет, но в зависимости от того на какой литературе/статьях мы учились мы можем считать грамотным/неграмотным/совсем не грамотным.
«про изменчивость»
я имел ввиду вот что: «грамотность употребления терминов».
Мы задаём вопрос человеку. Он на него отвечает. В зависимости от того принимаем ли мы его ответ как правильный, мы принимаем решение — «грамотно» или «не грамотно». Можно закончить, а можно задать ещё вопрос — и величина итоговой «грамотности»изменится.
Получается что «грамотность» помимо того что зависит от нашего восприятия, так ещё и меняется с течением времени и зависит от длительности наблюдения.
тут спору нет. всё верно.
Моя ошибка. в своём комментарии я подразумивал легион вебпроектов. В них часто нет ничего сложного, часто цена ошибки ->0. для них часто достаточно будет одного адекватного опытного человека + группа джуниоров (от полу года разработки или пользования соответсвующим языком в своих поделках), часто «выращивание» джуниоров до уровня достаточного для поддержки такого проекта происходит очень быстро.
Я спросил — встречались ли вы с такими архитектурами. Вы ответили. Всё хорошо. Вы всё делаете «так».
А вы обсуждали эти архитектуры (те которые уже есть и которыми вы гордитесь) с кем-то ещё, кто не является вашим подчиненным и при этом тоже занимается разработкой?
согласен. и иногда, если честно, удивляет активное нежелание некоторых компаний признать очевидное и нанимать джуниоров. Часто ещё сопровождающееся плачем ярославны о том что — «ой мужиковкандидатов та толковых не осталось»
не троллинга ради, а чисто из профессионального любопытства. Вы с такими встречались? С архитектурами которыми человек гордится и которые действительно были бы хороши?
(в качестве пояснения почему у меня родился такой вопрос
У меня есть подозрение, что это невозможно. Если у нас «водопад» — то когда мы закончим «падать» — есть большой шанс, что «всё нетак» и мы быстро внесём изменения которые сделают нашу идеальную архитектуру — уже не идеальной.
Если у нас Agile или RUP с недлинными итерациями — то изменения архитектуры почти всегда отстают от изменения требований: новое требование — костыль, 2 костыля => изменение архитектуры.
Можно предположить что изначально была спроектирована архитектура «повышенной гибкости» — тогда она бдет «оч сложной» со всеми вытекающими.
Вот и получается что архитектура может быть идеальной когда архитектор что-то недоговаривает и все грязные места убраны под ковёр, или он уже не видит её недостатков.)
слова про неунизительную форму относились к моим словам о возможном использовании распространенных заблуждений с целью проверки кандидата на адекватность(в нашей отрасли очень распространено стремление выставить человека идиотом. в такой ситуации на о какой адекватности речи не идёт ибо мы сами ещё в младшей школе).
К «текущему подходу» они отношения не имели каким бы он ни был)
>нельзя использовать на собеседовании один инструмент
согласен (хотя у меня есть подозрение, что часто можно обходится и одним — «тестом на адекватность», но пока нет возможности убедится в этом на сколь-нибудь значащей выборке)
мои комментарии относились к вашему утверждению про «ребят», с целью показать что это не всегда так.
мораль в то, что для большинства проектов не оч важны ваши техскилы (если вы пишите на php допустим уже 2 года, то не так важно знакомы ли вы с SPL, использовали ли namespace или помнители вы что такое LSB), гораздо важней обща адекватность и то вольётесь ли вы в коллектив.
Ни вкоем случае не ставил целью «придираться».
«Грамотно употреблять терминалогию» — это свойство в реальном мире очень редко достигает значения 1 + имеет свойство меняться в зависимости от времени наблюдения)
А эти 2 распространенных заблуждения — легко проверить в неунизительной для кандидата форме диалога + одновременно с этим проверяется адекватность кандидата + можно потом продолжать разговор далее в более тонкие материи.
Например можно попросить кандидата спроектировать ну например «библиотеку книг» ну или там… сервис для отслеживания появления билетов на поезд. И когда начнется традиционный буллщитинг, вы задаёте традиционные вопросы почему он сделал именно так, а потом спрашиваете кандидата, что он думает по поводу ну например такого решения, и рисуете правильное решение (строго говоря «решение которое вам кажется правильным»). Если мы всё сделали правильно и не проявили неуважения — то тут станет видна способность кандидата вести диалог и в случае ошибки признать это, ну а заодно и наша способность быть тактичными в непростой ситуации и приводить аргументы.
«Но вот ребят которые грамотно употребляют терминологию, чаще всего понимают почему надо именно так, а не иначе.»
ох… даже на хабре часто можно видеть и по топикам и по комментариям следующие часто распространенные заблуждения:
1)любой автотест написанный на xUnit = юнит/модульный тест
2)«модель» из «MVC» = классы хранящие в себе значения соответсвующих записей в базе данных
носители этих заблуждений могут вполне неплохо жонглировать модными словечками, некоторые могут вполне себе даже быть архитекторами или тимлидами в своих компаниях.
Трамвай + эстакада над промзоной в районе пл. Останкино вышла бы дешевле. И никаких «космических технологий» от института теплотехники.
по поводу ваших тезисов о пробках — разве есть какие-то принципиальные противоречия с моими тезисами? Пробки не исчезнут пока не будет альтернативы — или стоять в пробке но в своём авто, или проехать пол-москвы за 20 минут но на общественном транспорте
основной мыслью моего длинного комментария является то, что для решения/снятия остроты проблемы пробок «высокие технологии», о кторых вы так много говорили в статье, не являются необходимыми. Достаточно уже существующих + реальная борьба с коррупцией (без этого для нас всегда всё будет «слишком дорого»). (Что конечно же не исключает автоматической диспетчеризации той же трамвайной сети.)
«монорельс» убыточен (можете посмотреть в википедии + гдето мне встречались данные что для тех людей которых перевозит момнорельс на дотаци можно было просто всех перевезти на такси)
«Персональный автоматический транспорт» который запустили в Хитроу — идея прекрасная но пока для нас слишком дорого
«московске» пробки никаким расширением дорог не решить — просто потому что любой кому действтельно нужна машина — хоть какую развалюху — но смоет купить.
Единственным разумным и реалистичным вариантом мне видится:
Перехватывающие парковки в районе садового кольца. (если каетсчя что места нет — обратите внимание на тысячи «бизнессцентров» которые постоянно строятся. им почемуто место находится)
Внутри садового — плотная сеть троллейбусных маршрутов
Въезд внутрь садового запретить
перехватывающие парковки в районе мкада
сеть радиальных трамвайных маршрутов. причём — трамвайные пути должны быть проложены по отдельной полосе, куда запрещён въезд автомобилям.
Утром, когда поток большой — трамваи можно сцеплять в составы, днём — отцеплять в депо и/или пускать по кольцевым маршрутам
Трамвай кстати может развивать скорость до 75км/час. При необходимости можно сделать в отдельных местах для них эстакады — всё-равно дешевле монорельса.
И вот когда появится реальная альтернатива — добраться из бутово до садового кольца за 20 минут без толчеи, или стоять в пробке несколько часов — количество машин на дорогах станет меньше.
Заметьте — для этого не нужны ультрасуперкосмические технологии — достаточно обуздать коррупцию (строить дороги «интересней» чем прокладывать трамвайные пути)
Но не согласен.
Впрочем — возможно, что когда стартапноинвестиционный ажиотаж стихнет и толковые phpмидлы перестанут «хотеть и получать» 100т — схема о которой я говорил и станет лишена смысла. Ну или аутсорс в регионы — смотря что наступит раньше.
Изначальный посыл был в том что rubbyrabbit предлагал спросить на собеседовании у кандидата про архитектуру, которой кандидат гордится.
Я высказал обоснованные сомнения в том что хорошая архитекутра может существовать и спросил — встречался ли rubbyrabbit с такой на собеседованиях в том смысле что насколько такой метод хорошо работает.
Так вы обсуждали свою архитектуру, которой вы гордитесь, с кем-то со стороны?
К сожалению известны
>Скажите это бухгалтеру или заказчику.
Странно что вы не упомянули запуск спутников на марс.
Да — ошибки в бухгалтерском по стоят денег (и потенциально очень больших).
Но процент уникального бухгалтерского ПО серди «легиона вебпроектов» не велик (заметьте — в своём комментарии я использовал слово «часто», а не «всегда»)
DTO(Data transfer object) и VO(Value Object) иногда используются как синонимы или один вместо другого. Ничего страшного в этом нет, но в зависимости от того на какой литературе/статьях мы учились мы можем считать грамотным/неграмотным/совсем не грамотным.
я имел ввиду вот что: «грамотность употребления терминов».
Мы задаём вопрос человеку. Он на него отвечает. В зависимости от того принимаем ли мы его ответ как правильный, мы принимаем решение — «грамотно» или «не грамотно». Можно закончить, а можно задать ещё вопрос — и величина итоговой «грамотности»изменится.
Получается что «грамотность» помимо того что зависит от нашего восприятия, так ещё и меняется с течением времени и зависит от длительности наблюдения.
Моя ошибка. в своём комментарии я подразумивал легион вебпроектов. В них часто нет ничего сложного, часто цена ошибки ->0. для них часто достаточно будет одного адекватного опытного человека + группа джуниоров (от полу года разработки или пользования соответсвующим языком в своих поделках), часто «выращивание» джуниоров до уровня достаточного для поддержки такого проекта происходит очень быстро.
А вы обсуждали эти архитектуры (те которые уже есть и которыми вы гордитесь) с кем-то ещё, кто не является вашим подчиненным и при этом тоже занимается разработкой?
мужиковкандидатов та толковых не осталось»(в качестве пояснения почему у меня родился такой вопрос
У меня есть подозрение, что это невозможно. Если у нас «водопад» — то когда мы закончим «падать» — есть большой шанс, что «всё нетак» и мы быстро внесём изменения которые сделают нашу идеальную архитектуру — уже не идеальной.
Если у нас Agile или RUP с недлинными итерациями — то изменения архитектуры почти всегда отстают от изменения требований: новое требование — костыль, 2 костыля => изменение архитектуры.
Можно предположить что изначально была спроектирована архитектура «повышенной гибкости» — тогда она бдет «оч сложной» со всеми вытекающими.
Вот и получается что архитектура может быть идеальной когда архитектор что-то недоговаривает и все грязные места убраны под ковёр, или он уже не видит её недостатков.)
К «текущему подходу» они отношения не имели каким бы он ни был)
согласен (хотя у меня есть подозрение, что часто можно обходится и одним — «тестом на адекватность», но пока нет возможности убедится в этом на сколь-нибудь значащей выборке)
мои комментарии относились к вашему утверждению про «ребят», с целью показать что это не всегда так.
«Грамотно употреблять терминалогию» — это свойство в реальном мире очень редко достигает значения 1 + имеет свойство меняться в зависимости от времени наблюдения)
А эти 2 распространенных заблуждения — легко проверить в неунизительной для кандидата форме диалога + одновременно с этим проверяется адекватность кандидата + можно потом продолжать разговор далее в более тонкие материи.
Например можно попросить кандидата спроектировать ну например «библиотеку книг» ну или там… сервис для отслеживания появления билетов на поезд. И когда начнется традиционный буллщитинг, вы задаёте традиционные вопросы почему он сделал именно так, а потом спрашиваете кандидата, что он думает по поводу ну например такого решения, и рисуете правильное решение (строго говоря «решение которое вам кажется правильным»). Если мы всё сделали правильно и не проявили неуважения — то тут станет видна способность кандидата вести диалог и в случае ошибки признать это, ну а заодно и наша способность быть тактичными в непростой ситуации и приводить аргументы.
ох… даже на хабре часто можно видеть и по топикам и по комментариям следующие часто распространенные заблуждения:
1)любой автотест написанный на xUnit = юнит/модульный тест
2)«модель» из «MVC» = классы хранящие в себе значения соответсвующих записей в базе данных
носители этих заблуждений могут вполне неплохо жонглировать модными словечками, некоторые могут вполне себе даже быть архитекторами или тимлидами в своих компаниях.