Хотелось бы понять чем подкреплена такая «самодельная» крипютовалюта?
Например выпустил я икс-коин, и изначально они есть только у меня. Я например, вместо того, чтобы работать за еду, могу требовать оплату икс-коинами, вместо гамбургеров. Но, чтобы получить икс-коины, закачзчик сперва должен их у меня купить. Получается он заплатит дважды. Ерунда получается. Где в моих рассуждениях ошибка?
люблю когда статья расширяет кругозор. Про механического турка историческая отсылка понравилась. Жаль чаще статьи ограничиваются техническим минимумом, без лирических отступлений.
да, и тестировщик интуитивно (по опыту) знает какие комбинации стоит проверить а какие бессмысленно. позитивный кейс тестировщик даже проверять не станет, его уже 100 раз проверил разработчик.
У нас приложение поделено на функциональные разделы. У каждого раздела свой подрядчик. Мы делаем три раздела из двенадцати. В каких-то командах четверо пишут ui-автотесты на один раздел, у нас один пишет на три.
Я — отдельная команда. Нашего тимлида по-поводу автотестов дергает техлид заказчика. Мое дело держать автотесты «в зеленом секторе». Не дергают моего тимлида он не дергает меня. И никому нет особенно дела как у меня там дела, пока все нормально. Правда я еще багрепорты пишу. Если бы не это наверное бы не знали как и звать :) И можно было бы передать ответственность за написание автотестов разработчикам, но это сьедает столько времени, что лучше не надо. Пусть пишут код. А «Команда-Я» как нибудь бегом широкими прыжками на хвосте.
Соглашусь, был бы рад, если бы мне дали какого нибудь студента в помощники, но проект строго бюджетирован.
В принципе считаю что лучше брать на автоматизацию специально людей. Но не из-за пирамид на графике. Просто они по другому смотрят на продукт.
Когда тестировщик приходит к программисту прояснить принцип работы куска функционала, программист часто говорит или думает «о, обьяснил и сам лучше понял» — это очень ценный диалог. Тестировщик может задавать наивные вопросы. Мне кажется это имеет положительное влияние на вырабатывание качественно другого подхода к разработке. Но на это нужно время. Время. Его всегда мало.
я честно говоря подумал тоже самое. Но обьясню. Если понаблюдать за развитием языков программирования, то одни появляются чтобы избавиться от недостатков других. Но и они не получаются без недостатков. Поэтому возникает резонный вопрос, а надо ли оно в таком количестве. На самом деле надо — потому что прийти к совершенству можно только через эволюцию или революцию. Но скорее через революцию, потому что при эволюции мы пользуемся знанием предыдущих поколений, а они не совершенны и максимум, что получится в конце эволюции — идеальная раскоряка :) А при революции создается что-то принципиально новое. Получается, продолжу рассуждение, что если посредством революции не получилось идеального результата, скорее всего нет смысла его улучшать, а нужно готовить следующую революцию.
У немцев тоже есть эта аналогия с мячом только из футбола. И смысл такой.: не можешь реализовать ситуацию — передай мяч. Вполне позитивный смысл. Не тормозить ход дела без причины.
Намедни купил и начал играть в D:OS EE, а тут такое совпадение. Игра бесспорно уникальная.
Хотелось бы узнать почему отказались от локализованой озвучки. Это частое явление среди игр и хотелось бы узнать отчего так происходит, что при одинаковой цене за копию одни игры полностью дублированы (например тот же Диабло 3), а другие нет.
имхо, работа программиста сродни работе переводчика. Он переводит из человеческого языка в машинный. Мне эта аналогия кажется достаточно точной чтобы предположить что все проблемы связанные автоматизированным переводом будут и у системы автоматизированой кодогенерации.
Клиент обратился: «А можете сделать и маркетинг кит?» — «А почему бы и нет — это ведь дополнительные деньги!» И вот в этот момент происходит главная ошибка молодой компании — создание маркетинг кита — это увеличение объема ..
Я просто выделил из этого примера систематическую ошибку, которой страдают компании, с учетом личного опыта.
а есть такие руководители, что от их присутствия или отсутствия ни тепло ни холодно :) И это плохие руководители. Любая компания будет продолжать работать в отсутствие руководителя. Просто раньше для принятия решения бежали к начальнику перекладывая решение на него, а без начальника или переложат решение на кого-то другого или примут его сами. Вот тезис, что черезмерная вовлеченность начальника в деятельность сотрудников делает сотрудников несамостоятельными, возможно верен.
Я думаю что причина краха IT-предприятий именно в том, что они набирают проекты не сверяясь с ресурсом и компетенциями. Т.е чтобы этого избежать нужно делать то, что ты умеешь делать хорошо, и не браться за то, о чем имеешь смутное представление. И обычно так фирмы себя и ведут. Но в кризисные времена, когда есть риск потерять заказы, они могут начать «метаться», а этого делать нельзя. (Кому интересно, почитайте вот яндекс-поиск: "почему нельзя снижать цены в кризис" — из той же оперы)
мне бросилось в глаза, что например «ведение финансов» это деятельность, а «отправить письмо» это действие. В картинке с облачками их представили одинаково. Атомарные действия и процессы нельзя ставить рядом.
Процессы состоят из атомарных действий и решений.
И по второму моменту: фирма берет все заказы подряд, не обязательно разбираясь в специфике заказа: «мы же IT-компания».
У нас такая ситуация как раз наличествует. Взяли еще один проект, дополнительную часть приложения, одну часть которого мы уже делаем. А оказалось что над разными компонентами одной и той же системы не одинаково просто работать. Понятно что фирма ведет себя как фирма, бизнес, деньги, и это для оррганизации правильно. Но вот то что человеческий ресурс при этом планируется после получения заказа… За это надо ставить к стенке и вести серьезный разговор. И сразу, иначе посмотрят что «ну тянут ребята» и притащат еще один проект.
А вообще мне кажется анализ процессов «на салфетке» это опасно. Перераспределение говна киселя не приводит к уменьшению общего количества киселя.
Да, при таком подходе есть недостаток, что завалившийся тест перекрывает «видимость» на следущий за ним функционал. И пока причина не будет устранена, эти перекрытые части остаются непротестироваными. С другой стороны, по скольку багрепорты пишу тоже я, а мой ресурс не бесконечен, такой подход работает. Писать тест так чтобы он выполнялся в любом случае, заставило бы нас сильно залезать во внутреннее состояние системы, а это во первых на нашей системе очень сложно (при проектировании тестируемость в нее не закладывали), во вторых черевато побочными эффектами.
Я подразумевал, что из экономического факультета произрастают менеджеры. На западе это распространенный карьерный путь. Вы видимо имели ввиду экономиста в его первородном виде: экономист-оптимизатор.
Если бы только правило Гудхарта включали в программу обучения экономистов, то бестолковых менеджеров было бы немножко меньше.
Почитав про когнитивные искажения и антипаттерны вообще начинашь верить в то, что картофельный клубень куда рациональнее человека.
Я еще несколько раз перечитал ваш ответ, и понял что же меня при первом прочтении резануло: по вашей логике продукт со сломаным логином можно выдавать пользователю? И зачем оно ему если он даже зайти в систему не сможет?
То что другая команда за 200 километров от нас после такого фейла чинит логин в срочном порядке не значит что все курят, все работают дальше, над своим функционалом. У нас такая система что для работы мы можем откатить сторонние артефакты назад, и проапдейтить свою ветку и работать с работающей версией логина.
У нас некоторые по три-четыре недели артефакты не обновляют.
И тесты у меня не совсем все друг за другом идут, а только шаги пользовательских сценариев, Один пользовательский сценарий у кого-то это один тест, а у меня test-suite (тестовый набор). Kаждый шаг в них это свой тест, чтобы в тест-репорте видно было с какого места последовательность запнулась. На каждый сценарий (тестовый набор) свой setup и teardown. T.e. их можно рапараллелить по тестовым наборам. Но не каждый тест в отдельности.
Чтобы вы представляли масштаб, то над чем мы работаем по обьему функционала схоже с ванильной Android OS. Наша работа только несколько компонент во всей системе.
Ну у нас такая ситуация, что не мы выполняем тесты мы их только пишем и анализируем результаты. Инструмент у нас самописный и приложение embedded. И результат автоматизированных тестов мы получаем только на следующий день, хотя новый билд у ручных тестировщиков уже сегодня, и соотв. информация «рабочий» ли билд известна уже сегодня. Т.е автоматизация не перед ручным тестированием, а после ручного смоук теста. Да, после. И все были бы рады, если бы автоматизация могла предоставить общую картину состояния билда, а она и предоставляет, только заказчик собирает все результаты в общий процент и смотрит на него. А контекстов штук двенадцать, разные команды, все пишут свои тесты. Кроме того у нас кроме красного результата есть еще и желтый, желтый результат не отображается в статистике, и не я это придумал. Вобщем все весьма и весьма грустно.
Ну да, можно сказать, что заказчик не серьезно подходит к автоматизации.Ведь она даже в бюджет команд не заложена. Чистая прихоть заказчика.
Так что, как правильно все проходили а в жизни по разному бывает. И добрых книжных истин хватает везде, а информации как же люди справляются в жизни — об этом в основном никакой информации.
Меня просто не устраивает когда догму пытаются втюхать так как будто вот только так и правильно. Как правильно разрабатывать об этом десятилетиями спорят, наверное потому что серебрянной пули нет. Так и тут.
Но спасибо вам за ответ, здравая мысль она вдохновляет.
Например выпустил я икс-коин, и изначально они есть только у меня. Я например, вместо того, чтобы работать за еду, могу требовать оплату икс-коинами, вместо гамбургеров. Но, чтобы получить икс-коины, закачзчик сперва должен их у меня купить. Получается он заплатит дважды. Ерунда получается. Где в моих рассуждениях ошибка?
Я — отдельная команда. Нашего тимлида по-поводу автотестов дергает техлид заказчика. Мое дело держать автотесты «в зеленом секторе». Не дергают моего тимлида он не дергает меня. И никому нет особенно дела как у меня там дела, пока все нормально. Правда я еще багрепорты пишу. Если бы не это наверное бы не знали как и звать :) И можно было бы передать ответственность за написание автотестов разработчикам, но это сьедает столько времени, что лучше не надо. Пусть пишут код. А «Команда-Я» как нибудь бегом широкими прыжками на хвосте.
Соглашусь, был бы рад, если бы мне дали какого нибудь студента в помощники, но проект строго бюджетирован.
В принципе считаю что лучше брать на автоматизацию специально людей. Но не из-за пирамид на графике. Просто они по другому смотрят на продукт.
Когда тестировщик приходит к программисту прояснить принцип работы куска функционала, программист часто говорит или думает «о, обьяснил и сам лучше понял» — это очень ценный диалог. Тестировщик может задавать наивные вопросы. Мне кажется это имеет положительное влияние на вырабатывание качественно другого подхода к разработке. Но на это нужно время. Время. Его всегда мало.
У немцев тоже есть эта аналогия с мячом только из футбола. И смысл такой.: не можешь реализовать ситуацию — передай мяч. Вполне позитивный смысл. Не тормозить ход дела без причины.
Хотелось бы узнать почему отказались от локализованой озвучки. Это частое явление среди игр и хотелось бы узнать отчего так происходит, что при одинаковой цене за копию одни игры полностью дублированы (например тот же Диабло 3), а другие нет.
Я просто выделил из этого примера систематическую ошибку, которой страдают компании, с учетом личного опыта.
Процессы состоят из атомарных действий и решений.
И по второму моменту: фирма берет все заказы подряд, не обязательно разбираясь в специфике заказа: «мы же IT-компания».
У нас такая ситуация как раз наличествует. Взяли еще один проект, дополнительную часть приложения, одну часть которого мы уже делаем. А оказалось что над разными компонентами одной и той же системы не одинаково просто работать. Понятно что фирма ведет себя как фирма, бизнес, деньги, и это для оррганизации правильно. Но вот то что человеческий ресурс при этом планируется после получения заказа… За это надо ставить к стенке и вести серьезный разговор. И сразу, иначе посмотрят что «ну тянут ребята» и притащат еще один проект.
А вообще мне кажется анализ процессов «на салфетке» это опасно. Перераспределение
говнакиселя не приводит к уменьшению общего количества киселя.Почитав про когнитивные искажения и антипаттерны вообще начинашь верить в то, что картофельный клубень куда рациональнее человека.
То что другая команда за 200 километров от нас после такого фейла чинит логин в срочном порядке не значит что все курят, все работают дальше, над своим функционалом. У нас такая система что для работы мы можем откатить сторонние артефакты назад, и проапдейтить свою ветку и работать с работающей версией логина.
У нас некоторые по три-четыре недели артефакты не обновляют.
И тесты у меня не совсем все друг за другом идут, а только шаги пользовательских сценариев, Один пользовательский сценарий у кого-то это один тест, а у меня test-suite (тестовый набор). Kаждый шаг в них это свой тест, чтобы в тест-репорте видно было с какого места последовательность запнулась. На каждый сценарий (тестовый набор) свой setup и teardown. T.e. их можно рапараллелить по тестовым наборам. Но не каждый тест в отдельности.
Чтобы вы представляли масштаб, то над чем мы работаем по обьему функционала схоже с ванильной Android OS. Наша работа только несколько компонент во всей системе.
Ну да, можно сказать, что заказчик не серьезно подходит к автоматизации.Ведь она даже в бюджет команд не заложена. Чистая прихоть заказчика.
Так что, как правильно все проходили а в жизни по разному бывает. И добрых книжных истин хватает везде, а информации как же люди справляются в жизни — об этом в основном никакой информации.
Меня просто не устраивает когда догму пытаются втюхать так как будто вот только так и правильно. Как правильно разрабатывать об этом десятилетиями спорят, наверное потому что серебрянной пули нет. Так и тут.
Но спасибо вам за ответ, здравая мысль она вдохновляет.