Текст в большей степени порадовал как хороший пример PR-текстов. Если он был написан лично кем-то из 37 signals — аплодирую стоя их мастерству.
«когда сотрудники изучают свою предметную область на всё более глубоком уровне и становятся высококлассными специалистами… хотят стать мастерами своего дела»,«мы поощряем сотрудника новыми, более сложными задачами в рамках его компетенции»
Хорошие рассуждения применительно к… сотруднице тех.поддержки. Или к верстальщику или к 80% разработчиков.
В двойне вызывает уважение, то что люди по всему миру повторяют за ними и друг за другом эти мантры убеждая себя и других в том, что это правильно и только так и надо.
Когда тебе надо {создавать креативную видимость} (слова в фигурных скобках меняются местами, не теряя общего смысла) работы. Эдакую «движуху» — да неплохое местечко. Очень «в тренде».
Но когда тебе нужно работать, и работа хоть немного связана с концентрацией- такие места ещё хуже чем опенспейсы. Эдакие места где всегда происходит что-то «интересненькое» и бесконечные ряды «павлинов» по очереди взгромождаются на жердочку и демонстрируют собравшимся свой красивый хвост.
Я бегло его смотрел. в большей степени читал стенограмму на RT
И мне не ясно в какой момент приехали пожарные. А RT пытается создать впечатление что пожарные могли всё спасти но не стали.
А я вот вижу ситуацию например так: приехала пожарная машина — дом уже полыхает. И вот подбегает какой-то господин и требует тушить. И вот у командира расчёта мысль в голове:
1)все живы
2)имущество уже не спасти, часть сгорело часть придёт в негодность после тушения
3)Соседним домам ничего не угрожает
4)Этот милый господин решил рискнуть и немного сэкономить (а у нас на станции например новые гидранты никак не закупят) а теперь требует (я вот подозреваю что именно в форме требования) меня «заплатить» и начать тушить. Если я прикажу «тушить» — как минмум премии лишат, завставят заплатить из своего кармана за выезд, как максимум уволят.
Ситуация более чем реалистичная, и в такой ситуации я вполне понимаю решение командира расчета.
1. Дело не в «поколениях». Просто «традиции строительства» там другие и если это не какая-нибудь аляска/канада, то «дом» это стропила + иногда утеплитель обшитые фанерой. В любом случае — дерево занимается хорошо и быстро и с определённого момента тушить уже бессмысленно.
2. Причём тут «все богатые».
Речь о том, что до недавнего времени — обычный «средний» работающий человек «там» (во многих развитых странах) жил лучше чем «здесь». Никто не говорит что «там всё хорошо».
«Про нудения» — тут мысль больше в том, что они нудят. Ну разогнали в окленде народ — ситуация не изменилась. Водя камень точит. У нас же — обычно всем всё-равно. Только сейчас в крупных городах начинается какое-то движение (правда ИМХО пока в бОльшей степени не конструктивное).
Про «пока платишь — ты член общества, перестал — уже нет» и прочие «всемирные кризисы» — опять же — у нас всё абсолютно тоже самое. Только периода «рассвета» так и не было. Обычный трудяга как не мог заработать на квартиру, так и не сможет.
И уж как «торгующий на бирже» вы знаете, что случиться у нас как только потребление нефти и стали упадёт в остальном мире из-за кризиса.
Многие ситуации могут быть описаны с разных сторон и RT по моим наблюдениям — тот ещё инструмент пропаганды.
Касательно случая с пожарными — у меня вот сложилось несколько мыслей:
1)Дома в той местности деревянно-щитовые. С определённого момента «тушение» как таковое уже не имеет смысла. Важно чтобы огонь не перешёл на соседние постройки. И если соседним постройкам ничего не угрожает, то и нет смысла расчехлять оборудование (и потом ещё выговор получить или вообще быть уволенным)
2)Мне не понятно, почему если в той местности действуют такие правила оплаты пожарной службы («по подписке») — человек на неё не подписался.
3)Опять же — из материала ясно только, что нет федеральной пожарной службы, и в каждой местности вопрос решается по своему. У меня вот закрался вопрос — а не были ли те пожарные которые приехали «продолжением» услуг страховой компании, которая страхует людей от пожара ну и чтобы минимизировать свои риски — содержит пожарную службу.
4)Учитывая как в «америках» любят нудеть по любому поводу, если бы такой порядок финансирования пожарных не устраивал сколь-нибудь большое количество людей — они бы давно своим нудением изменили этот порядок.
В общем, часто всё не так как кажется. Читайте Фрикономику, смотрите на вещи шире.
P.S. Вы так удивляетесь, как будто «у нас» полиция поголовно работает лучше и взяток не берёт.
Времена «социализма» может и прошли, но когда по тому же дискавери рассказывают про какую-то американскую женщину, которая работает на какой-то «дефолтной» (не особо престижно и не особо оплачиваемой) работе, одна растит ребёнка и у неё свой дом (да в их пригородах/suburb'ах, но всё же) и автомобиль.
Или когда мне на почту приходит рассылка информационная на тему аренды жилья в берлине в котором предлагается например 1комн. квартира-студия 40 с небольшим метров (это чуть больше чем средняя хрущевская 2шка по площади) с мебелью и балконом лоджией недалеко от центра берлина за чуть меньше чем 360евро / мес + коммунальные платежи.
То кажется что социализм наступил уже много где.
Так что не надо про «социализм» и про «саночки». Слишком много коррупции + неэффективное расходование бюджета — вот и ввп не растёт и производительность труда рабочих специальностей никакая
Ох. Если честно — ничего особенного, выходящего за рамки «тестирование может улучить качество продукта» знать не нужно.
Если к нашему продукту объективно не предъявляется высоких требований и цена ошибки мала — мы в принципе вполне можем и забить на отдельное тестирование ибо оно стоит дороже, чем урон от возможных ошибок.
Если же на качественном уровне декларируется «качество» и есть лишние ресурсы на его обеспечение, то можно «попробовать».
Итак у нас есть группа разработчиков, которая выпускает релиз. Его ведь кто-то проверяет и находит некоторое количество ошибок + потребители находят некоторое количество багов.
В течении некоторого времени — собирается статистика, что на каждые N строк разработчики делают столько то ошибок, и столько-то из них проходит через smoke-тестирование и находится клиентами.
Если числа большие и цена их высока и достаточна для организации службы тестирования — то вперёд.
Организовали, проработали некоторое время — посмотрели снова на статистику — и вот тут и становится ясно:
нужно ли нам тестирование, может ли оно улучшить качества продуктов, или мы и без службы тестирвоания хорошо живём.
Пара слов о метриках: часто можно видеть, что в качестве метрики «эффективности» работы отдела тестирование выступает количество найденых багов. По моему разумению такая метрика ведёт к конфликту между разработкой и тестированием.
Гораздо лучше использовать метрику «количество багов найденных клиентом» — чем эта величина выше — тем хуже работает разработка и тестирование ВМЕСТЕ.
Приглашаю на время конференции влиться в нашу международную организацию Peace Data, которая занимается анализом и обработкой больших объёмов данных в интересах сельского хозяйства.
> Вы не правы. Не все можно выразить как эффективность.
Так я этого и не утверждал)
По поводу «ширины/глубины» терминов: люди часто используют термин «конверсия» и для обозначения отношения просмотра объявлений к кликам и отношения кликов к целевым действиям и для отношения просмотров к целевым действиям. Так что не вижу тут ни проблемы ни противоречия. Точно так же вместо слова «конверсия» могли бы использовать «эффективность».
Я говорил в большей степени, о том, что определённый класс людей с целью лучше продавать свои услуги от консультанта-КО — создают всё новые и новые термины для уже существующих понятий (Я был бы не против «конверсии», если бы это не была суть уже существующая «эффективность»). А всё остальные их с радостью начинают повторять — дабы и на них снизошла часть ореола от очередного само-провозглашенного гуру.
всё больше и больше bullshit bingo в нашей отрасли…
Lean,Waste,value… в чём принципиальное отличие от просто стремления к «эффективности»? Выдвигаем гипотезу, строим метрики, быстро делаем быстро «из пластилина», смотрим на результат, и если отношение затрат к результату нас устраивает — подтягиваем тяжелую артиллерию.
Забавно, что в каждой отрасли, люди в своём стремлении казаться более «умными»/«профессиональными»/т.д… изобретают новые термины для совершенно банальных вещей. Так например в том же интернет-и-прочем-маркетинге — для всё той же банальной и скучной «эффективности» придумали «КОНВЕРСИЮ».
в начале статьи «инкапсуляция это ууу плохо», и в конце — «инкапсуляция» как метод борьбы с инкапсуляцией. Вы правда не видите подвоха? Проблема с вашим кодом вовсе не в инкапсуляции
Хорошей хозяйке на заметку: большинство т.н. «проектов» похожи друг на друга как близнецы-братья и «сложных» и «амбициозных» задач там просто нет. Более того — значительная часть вполне может быть сделана «тяп-ляп» и будет б.м. работать. Люди с развитыми аналитическими способностями это замечают очень быстро и как только им становится не интересно программирование ради программирования (что тоже происходит довольно быстро) — все потуги «мотивировать» их «сложными» задачами приведут только к одному: на вас буду смотреть как на идиота.
Видимо на вопросы ответа не будет…
По поводу вашего интереса к психологии и коммуникациям — если он действительно есть — кажется разумным пройтись по топикам посвященным тарантулу и обсудить в лс эти вопросы с авторами комментариев с большим числом минусов. Из этого топика — попробуйте написать например с spmbt выше по тексту.
Выглядит интересно.
Не совсем понял из документации, поддерживаются/планируются ли какие-то то команды-примитивы для синхронизации (CAS, putIfAbsent и т.п.)?
Планируется ли UDP интерфейс?
Он одно поточный или многопоточный? Интересует насколько различалась производительность в в многоядерных системах в вариантах «количество потоков по числу каналов памяти + затраты на обеспечение когерентности кешей» vs «один поток».
Компания mail.ru уже заменила все memcache на тарантул?
А по поводу негативной реакции людей. Тут как мне кажется дело в том, что когда компания mail.ru рассказывает о тарантуле — перебарщивают с хвалебными эпитетами. Я понимаю, что проделана большая работа, и люди ей в целом скорей всего гордятся. Но просто людьми, судя по негативной реакции, это воспринимается как хвастовство.
Например «В некотором смысле, Tarantool можно сравнить c Nginx, который разрабатывался в Rambler, и только через некоторое время обрел заслуженную славу и признание сообщества, будучи открытым проектом.» — нет — пока нельзя сравнить: «славы» и «признания сообщества» тарантул пока не обрёл. Тексты в части «Чем я могу помочь» — тоже, уверен, вызывают отторжение у читателей.
У вас есть свои сильные стороны. Акцентируйте внимание на них. Всё будет хорошо.
Есть задача: единообразно обойти коллекцию классов и в зависимости от типа текущего элемента коллекции выполнить некоторые действия.
Если ей решить в виде кучи if instance of — получится мрак, если её решить используя двойную диспетчеризацию — - получится то что все называют «паттерн Visitor». Но как-то мне это кажется недостаточным для того чтобы плодить понятия и создавать «паттерн» и дальше пытаться насаждать его.
«Как видим, тут нет базового класса visitor'a и базового посещаемого класса, а также ключевого слова accept. Вместо этого голый double dispatch :)» Естественно там нет всех этих buzzwords — они же являются частью маркетинговых украшений — зрите в корень.
Ещё любителям «паттернов»:
В чём принципиально отличие DTO и ViewModel, ChainofResponibility от последовательности Proxy которые в свою очередь являются применением принципов SOLID к проектированию. С сожалением прихожу к выводу, что отрасль поражает мода на bullshiting пришедшая из маркетинга, когда простые вещи у которых уже есть название стараются называть всё новыми и новыми терминами.
Пользуясь случаем спрошу: мне одному кажется что т.н. «патттерн Visitor» — это не более чем double-dipatch (+адаптация для языков в которых нет перегрузки методов) в новой маркетинговой упаковке?
Ещё бы добавил, что «правильный подход к проектированию» даёт ещё один значимый бонус, о котором часто забывают: масштабируемость процесса разработки. Т.е. грубо говоря — возможность сократить срок разработки за счёт добавления к нему людей. Это происходит за счёт простой вещи: наше ПО это 100500 микро-ситуаций «клиент»->«сервис». И если «сервис» будет не конкретным классом а интерфейсом, то разделить работу между 2 сотрудниками: одному разрабатывать «клиент»и тестироваться с помощью мока сервиса, а другому — разрабатывать реализацию сервиса и тестировать его тестом на основ контракта. Ясно что скорость увеличится не в 2 раза из-за необходимости дополнительно создать 2 комплекта для тестирования, но если в команде и так пишутся автотесты — то не так важно. Так же очевидно, что эффективность такого подхода тем выше, чем ближе наш клиент->сервис к ситуации взаимодействия 2х крупных компонент.
«когда сотрудники изучают свою предметную область на всё более глубоком уровне и становятся высококлассными специалистами… хотят стать мастерами своего дела»,«мы поощряем сотрудника новыми, более сложными задачами в рамках его компетенции»
Хорошие рассуждения применительно к… сотруднице тех.поддержки. Или к верстальщику или к 80% разработчиков.
В двойне вызывает уважение, то что люди по всему миру повторяют за ними и друг за другом эти мантры убеждая себя и других в том, что это правильно и только так и надо.
Когда тебе надо {создавать креативную видимость} (слова в фигурных скобках меняются местами, не теряя общего смысла) работы. Эдакую «движуху» — да неплохое местечко. Очень «в тренде».
Но когда тебе нужно работать, и работа хоть немного связана с концентрацией- такие места ещё хуже чем опенспейсы. Эдакие места где всегда происходит что-то «интересненькое» и бесконечные ряды «павлинов» по очереди взгромождаются на жердочку и демонстрируют собравшимся свой красивый хвост.
Странный документ, но если числа реальные, то как-то я даже почувствовал себя немного спокойней.
И мне не ясно в какой момент приехали пожарные. А RT пытается создать впечатление что пожарные могли всё спасти но не стали.
А я вот вижу ситуацию например так: приехала пожарная машина — дом уже полыхает. И вот подбегает какой-то господин и требует тушить. И вот у командира расчёта мысль в голове:
1)все живы
2)имущество уже не спасти, часть сгорело часть придёт в негодность после тушения
3)Соседним домам ничего не угрожает
4)Этот милый господин решил рискнуть и немного сэкономить (а у нас на станции например новые гидранты никак не закупят) а теперь требует (я вот подозреваю что именно в форме требования) меня «заплатить» и начать тушить. Если я прикажу «тушить» — как минмум премии лишат, завставят заплатить из своего кармана за выезд, как максимум уволят.
Ситуация более чем реалистичная, и в такой ситуации я вполне понимаю решение командира расчета.
2. Причём тут «все богатые».
Речь о том, что до недавнего времени — обычный «средний» работающий человек «там» (во многих развитых странах) жил лучше чем «здесь». Никто не говорит что «там всё хорошо».
«Про нудения» — тут мысль больше в том, что они нудят. Ну разогнали в окленде народ — ситуация не изменилась. Водя камень точит. У нас же — обычно всем всё-равно. Только сейчас в крупных городах начинается какое-то движение (правда ИМХО пока в бОльшей степени не конструктивное).
Про «пока платишь — ты член общества, перестал — уже нет» и прочие «всемирные кризисы» — опять же — у нас всё абсолютно тоже самое. Только периода «рассвета» так и не было. Обычный трудяга как не мог заработать на квартиру, так и не сможет.
И уж как «торгующий на бирже» вы знаете, что случиться у нас как только потребление нефти и стали упадёт в остальном мире из-за кризиса.
Касательно случая с пожарными — у меня вот сложилось несколько мыслей:
1)Дома в той местности деревянно-щитовые. С определённого момента «тушение» как таковое уже не имеет смысла. Важно чтобы огонь не перешёл на соседние постройки. И если соседним постройкам ничего не угрожает, то и нет смысла расчехлять оборудование (и потом ещё выговор получить или вообще быть уволенным)
2)Мне не понятно, почему если в той местности действуют такие правила оплаты пожарной службы («по подписке») — человек на неё не подписался.
3)Опять же — из материала ясно только, что нет федеральной пожарной службы, и в каждой местности вопрос решается по своему. У меня вот закрался вопрос — а не были ли те пожарные которые приехали «продолжением» услуг страховой компании, которая страхует людей от пожара ну и чтобы минимизировать свои риски — содержит пожарную службу.
4)Учитывая как в «америках» любят нудеть по любому поводу, если бы такой порядок финансирования пожарных не устраивал сколь-нибудь большое количество людей — они бы давно своим нудением изменили этот порядок.
В общем, часто всё не так как кажется. Читайте Фрикономику, смотрите на вещи шире.
P.S. Вы так удивляетесь, как будто «у нас» полиция поголовно работает лучше и взяток не берёт.
Или когда мне на почту приходит рассылка информационная на тему аренды жилья в берлине в котором предлагается например 1комн. квартира-студия 40 с небольшим метров (это чуть больше чем средняя хрущевская 2шка по площади) с мебелью и балконом лоджией недалеко от центра берлина за чуть меньше чем 360евро / мес + коммунальные платежи.
То кажется что социализм наступил уже много где.
Так что не надо про «социализм» и про «саночки». Слишком много коррупции + неэффективное расходование бюджета — вот и ввп не растёт и производительность труда рабочих специальностей никакая
Если к нашему продукту объективно не предъявляется высоких требований и цена ошибки мала — мы в принципе вполне можем и забить на отдельное тестирование ибо оно стоит дороже, чем урон от возможных ошибок.
Если же на качественном уровне декларируется «качество» и есть лишние ресурсы на его обеспечение, то можно «попробовать».
Итак у нас есть группа разработчиков, которая выпускает релиз. Его ведь кто-то проверяет и находит некоторое количество ошибок + потребители находят некоторое количество багов.
В течении некоторого времени — собирается статистика, что на каждые N строк разработчики делают столько то ошибок, и столько-то из них проходит через smoke-тестирование и находится клиентами.
Если числа большие и цена их высока и достаточна для организации службы тестирования — то вперёд.
Организовали, проработали некоторое время — посмотрели снова на статистику — и вот тут и становится ясно:
нужно ли нам тестирование, может ли оно улучшить качества продуктов, или мы и без службы тестирвоания хорошо живём.
Пара слов о метриках: часто можно видеть, что в качестве метрики «эффективности» работы отдела тестирование выступает количество найденых багов. По моему разумению такая метрика ведёт к конфликту между разработкой и тестированием.
Гораздо лучше использовать метрику «количество багов найденных клиентом» — чем эта величина выше — тем хуже работает разработка и тестирование ВМЕСТЕ.
Адрес… выберите сами адрес любого бизнессцентра
Так я этого и не утверждал)
По поводу «ширины/глубины» терминов: люди часто используют термин «конверсия» и для обозначения отношения просмотра объявлений к кликам и отношения кликов к целевым действиям и для отношения просмотров к целевым действиям. Так что не вижу тут ни проблемы ни противоречия. Точно так же вместо слова «конверсия» могли бы использовать «эффективность».
Lean,Waste,value… в чём принципиальное отличие от просто стремления к «эффективности»? Выдвигаем гипотезу, строим метрики, быстро делаем быстро «из пластилина», смотрим на результат, и если отношение затрат к результату нас устраивает — подтягиваем тяжелую артиллерию.
Забавно, что в каждой отрасли, люди в своём стремлении казаться более «умными»/«профессиональными»/т.д… изобретают новые термины для совершенно банальных вещей. Так например в том же интернет-и-прочем-маркетинге — для всё той же банальной и скучной «эффективности» придумали «КОНВЕРСИЮ».
По поводу вашего интереса к психологии и коммуникациям — если он действительно есть — кажется разумным пройтись по топикам посвященным тарантулу и обсудить в лс эти вопросы с авторами комментариев с большим числом минусов. Из этого топика — попробуйте написать например с spmbt выше по тексту.
Почему автор назвал своё решение «кеширующий декоратор» а не «кеширующий прокси»?
Не совсем понял из документации, поддерживаются/планируются ли какие-то то команды-примитивы для синхронизации (CAS, putIfAbsent и т.п.)?
Планируется ли UDP интерфейс?
Он одно поточный или многопоточный? Интересует насколько различалась производительность в в многоядерных системах в вариантах «количество потоков по числу каналов памяти + затраты на обеспечение когерентности кешей» vs «один поток».
Компания mail.ru уже заменила все memcache на тарантул?
А по поводу негативной реакции людей. Тут как мне кажется дело в том, что когда компания mail.ru рассказывает о тарантуле — перебарщивают с хвалебными эпитетами. Я понимаю, что проделана большая работа, и люди ей в целом скорей всего гордятся. Но просто людьми, судя по негативной реакции, это воспринимается как хвастовство.
Например «В некотором смысле, Tarantool можно сравнить c Nginx, который разрабатывался в Rambler, и только через некоторое время обрел заслуженную славу и признание сообщества, будучи открытым проектом.» — нет — пока нельзя сравнить: «славы» и «признания сообщества» тарантул пока не обрёл. Тексты в части «Чем я могу помочь» — тоже, уверен, вызывают отторжение у читателей.
У вас есть свои сильные стороны. Акцентируйте внимание на них. Всё будет хорошо.
Если ей решить в виде кучи if instance of — получится мрак, если её решить используя двойную диспетчеризацию — - получится то что все называют «паттерн Visitor». Но как-то мне это кажется недостаточным для того чтобы плодить понятия и создавать «паттерн» и дальше пытаться насаждать его.
«Как видим, тут нет базового класса visitor'a и базового посещаемого класса, а также ключевого слова accept. Вместо этого голый double dispatch :)» Естественно там нет всех этих buzzwords — они же являются частью маркетинговых украшений — зрите в корень.
Ещё любителям «паттернов»:
В чём принципиально отличие DTO и ViewModel, ChainofResponibility от последовательности Proxy которые в свою очередь являются применением принципов SOLID к проектированию. С сожалением прихожу к выводу, что отрасль поражает мода на bullshiting пришедшая из маркетинга, когда простые вещи у которых уже есть название стараются называть всё новыми и новыми терминами.