«И это был один из немногих моментов, когда мой принцип «программы надо писать хорошо» меня подвел.»
Меня этот принцип подводит постоянно. Когда то, что ты пишешь, работает сразу и надежно, у принимающей стороны создается впечатление, что это от простоты задачи и вообще, не слишком ли много тебе платят. При этом рядом «косячит» деятель, которого вообще в профессию нельзя пускать. Но поскольку там «все сложно», баги так и лезут и все критические, их героически надо править и постоянные доклады о «победах» идут на самый верх — то вот кто и есть главный герой, получатель ништяков, бонусов и благодарностей.
Поскольку я давно далеко за пределами Родины, то иллюзий насчет столиц и больших городов не испытываю. Работал и в самых больших мировых IT компаниях — и на три буквы которая, и на две, и в не таких больших — везде примерно так. Ну может в гугле по-другому…
Прихожу к выводу, что если у вас сразу много денег и план на 10 лет вперед по развитию продукта — то вкладывайтесь в автоматизацию тестирования.
Если у вас стартап, где важны быстрота выхода первой бетты или продукт типа сделал раз и забыл — то нет смысла тратить время.
Я один чувствую некий диссонанс между принципами agile, в которых я готов подписаться под каждым словом, и кучей «методологий», «правильное» и одновременно жизнеспособное внедрение которых по слухам где-то существует но никто не видел?
Внедрение agile почему-то начинают именно с методологий, тулов для их поддержки и таймтрекинга.
А начинать надо бы наверное с консенсуса в компании на всех уровнях по поводу принципов.
И пока эти принципы не осознаны и не приняты всеми, внедрение каких-то методологий и тулов бессмысленно и вредно, IMHO.
Хотелось бы уточнить насчет случаев «различных задержаний в разных странах»…
Задержанные как-то пытались хотя бы минимально сохранять свою анонимность, или же, наоборот, в их открытых профилях были фотографии, друзья, реальные имена и т.д.?
Блокировщики рекламы — великое изобретение!
Пользуюсь на всех компьютерах уже много лет.
Если закроются сайты, живущие за счет рекламы, нисколько не буду сожалеть.
Появятся другие, имеющие более адекватную модель монетизации, повысится качество контента.
Я думаю, что практика работы с заказчиком по сбору требований не является специфической для agile и так же применима к waterfall. Это частное замечание.
А более общее. Проблема waterfall, на мой взгляд, вовсе не в методологии, а в изменении внешних условий.
Первое, и самое главное — резкое падение уровня технической подготовки IT аналитиков и менеджмента.
Если раньше, в 70-х, у менеджеров проектов и аналитиков IT компаний, обычно имелся инженерный, математический и т.п. диплом, то с какого-то времени этих специалистов начали готовить сразу, минуя инженерную ступень. Соответственно, они просто не в состоянии формализовать задачу на языке, понятном инженеру.
Частый пример из личного опыта, когда ПМ или аналитик на первом митинге с ходу заявляет: I'm not a technical person. Хочется сразу спросить, я что ты вообще делаешь тогда в IT компании? Иди вон в бургерную менеджери. Хотя, наверное, и там менеджер должен разбираться в качестве ингредиентов и уровне прожарки мяса. Но в IT это стало нормой в какой-то момент.
В результате, что-бы понять хоть что-то из требований, программистам пришлось начать разговаривать с заказчиком напрямую. А поскольку общего языка у них нет, то разговор ведется «на пальцах»: программисты что-то показывают, заказчик кивает или качает головой. Двигаться маленькими шажками. Капитан Кук и людоеды. Это и есть agile.
Это работает и все замечательно, аналитики стали не нужны. Ровно до тех пор, пока ваша предметная область тривиальна и легко описывается в общепонятных терминах. Т.е. пока Кук объясняет людоедам, что за вот эти вот бусы, он хотел бы получить вот тот вот остров и принцип мены понятен всем.
Но вот Куку понадобилось объяснить людоедам какой нибудь бином Ньютона. И что?
В переводе на современную ситуацию: это все очень замечательно, что вы нарисовали интернет банк как хотел заказчик. Сейчас и дети умеют работать с сайтами и перетаскивать что-то там мышкой и вполне могут понять и освоить сайт банка, и объяснить что им нравится, что нет. Но все это по сути лишь интерфейс.
Другое дело — внутренняя логика банковской системы. Для того чтобы понять внутренние процессы, желательно иметь профильное финансовое образование. И программисту со стороны так просто туда не сунуться — он не понимает даже терминологию. А когда дойдет до математики, у него волосы встанут дыбом от того, как финансисты издеваются над классической вышкой, к которой он привык. Там где у него ряды, выводы и пределы — у финансистов будет арифметика и магические константы. Вот тут и случаются грабли.
И в результате, мы на практике увидим, что в ядре системы у банка стоит какой нибудь мэйнфрейм который собственно и выполняет всю тяжелую логику. И написано там все на кобол или рпг в те времена, когда об agile еще не слыхивали.
Желание перенести все это на новую платформу перманентно присутствует. Но попытки часто оканчиваются печально. С наскоку, без грамотного изучения, понимания, формализации и документирования требований, многократной выверки оных, ДО начала всякого кодирования, вряд ли возможно.
Вот и стоят динозавры в банках, пыхтят и обсчитывают всякие опердни.
Так что, не в методологии дело. Дело все в людях. И не надо так уж нападать на waterfall. В ряде случаев без него не куда.
Я бы все же не советовал начинать с джуниора и небольшой зарплаты в ОАЭ.
Главный минус страны в том, что подданство не получить. Т.е. эмиратцами вы не станете никогда. А на западе обычно каждый год жизни там приближает к гражданству.
Второй минус — отношение и зарплата зависят от гражданства. Белый мистер из сша будет сразу получать совсем другие деньги при прочих равных.
Поэтому, мой совет — начинать в развитой европейской или североамериканской стране. Пока молодые — туда легче уехать и получить гражданство.
Потом можно ехать зарабатывать на БВ «белым мистером» из западной страны. Это будут хорошие деньги и перспектива «где встречать старость» более менее ясная.
Я склоняюсь скорее ко второму. Просто даже исходя из соображений стоимости содержания необходимых мощностей. Скорее глупость конкретных исполнителей, которые хотели отрапортовать об успешном внедрении и бешеной популярности национального сертификата.
Ну вот я просил выше показать сертификат гугла подписанный казахским СА — говорят, нет такого.
Поэтому не совсем понятно, действительно ли принято решение перепаковывать чужой трафик своим сертификатом.
Мне кажется такие действия сомнительными с точки зрения эффективности. Приложения могут проверять например хэши своих сертификатов. Есть и другие методы защиты. Т.е. я к тому, что эти приложения и сайты могут как раз таки не заработать если их трафик попытаются проксировать. В компании где я работаю, тоже ставили грандиозную задачу проксировать весь трафик. При том что на все офисные компьютеры нужный корневой сертификат был предустановлен. Танцы с бубном вокруг F5 продолжались больше месяца.Получили кучу жалоб и в результате HTTPS теперь просто тунелируется. Я конечно понимаю, что могут сказать мол ваши админы не достаточно компетентны. Но я не уверен, что они менее компетентны чем казахские, например.
Я считаю что само по себе желание сделать национальный CA никак не предосудительно, а даже похвально.
Другое дело, если государство решило заняться глобальным проксингом.
Утверждение, что «Знаменитая операционная система OS/400 для IBM AS/400 была реализована на Modula-2» не совсем правда.
Вот что по этому поводу пишет Франк Солтис, создатель AS/400:
"… Язык программирования VLIC, называвшийся PL/MP и использовавшийся со времен разработки оригинальной System/38, был основан на языке PL/I. MP в его названии расшифровывается как Machine Product — имя, которое часто использовалось для обозначения аппаратных средств и обоих слоев микрокода. Компилятор PL/MP, как и ассемблер IMPI, генерировал двоичные машинные команды IMPI.
… В течение ряда лет мы пытались использовать другие языки при разработке компонентов VLIC. Например, один из наших новейших трансляторов был написан на Modula-2, применялся также язык С. Однако, мы чувствовали, что ни один из них не подходит для проекта, основанного на объектно-ориентированной технологии. Выбор напрашивался сам собой — язык C++. Нам нужно было разрабатывать код ОС очень низкого уровня. Иногда, для достижения оптимальной производительности приходилось прибегать к ассемблеру, и С+ + легче позволял это. Ведь, фактически, язык С++ и есть современный вариант ассемблера…
Технология ООП не подвела: производительность программистов при разработке SLIC повысилась почти в четыре раза по сравнению с традиционной методикой. В период с июля 1992 года, было создано более миллиона строк кода на С+ + и более 7 000 классов.… "
Ф. Солтис, «Основы AS/400».
Меня этот принцип подводит постоянно. Когда то, что ты пишешь, работает сразу и надежно, у принимающей стороны создается впечатление, что это от простоты задачи и вообще, не слишком ли много тебе платят. При этом рядом «косячит» деятель, которого вообще в профессию нельзя пускать. Но поскольку там «все сложно», баги так и лезут и все критические, их героически надо править и постоянные доклады о «победах» идут на самый верх — то вот кто и есть главный герой, получатель ништяков, бонусов и благодарностей.
Поскольку я давно далеко за пределами Родины, то иллюзий насчет столиц и больших городов не испытываю. Работал и в самых больших мировых IT компаниях — и на три буквы которая, и на две, и в не таких больших — везде примерно так. Ну может в гугле по-другому…
Если у вас стартап, где важны быстрота выхода первой бетты или продукт типа сделал раз и забыл — то нет смысла тратить время.
Внедрение agile почему-то начинают именно с методологий, тулов для их поддержки и таймтрекинга.
А начинать надо бы наверное с консенсуса в компании на всех уровнях по поводу принципов.
И пока эти принципы не осознаны и не приняты всеми, внедрение каких-то методологий и тулов бессмысленно и вредно, IMHO.
А как перейти в тот регион, что справа, вы не сказали.
Задержанные как-то пытались хотя бы минимально сохранять свою анонимность, или же, наоборот, в их открытых профилях были фотографии, друзья, реальные имена и т.д.?
Пользуюсь на всех компьютерах уже много лет.
Если закроются сайты, живущие за счет рекламы, нисколько не буду сожалеть.
Появятся другие, имеющие более адекватную модель монетизации, повысится качество контента.
А более общее. Проблема waterfall, на мой взгляд, вовсе не в методологии, а в изменении внешних условий.
Первое, и самое главное — резкое падение уровня технической подготовки IT аналитиков и менеджмента.
Если раньше, в 70-х, у менеджеров проектов и аналитиков IT компаний, обычно имелся инженерный, математический и т.п. диплом, то с какого-то времени этих специалистов начали готовить сразу, минуя инженерную ступень. Соответственно, они просто не в состоянии формализовать задачу на языке, понятном инженеру.
Частый пример из личного опыта, когда ПМ или аналитик на первом митинге с ходу заявляет: I'm not a technical person. Хочется сразу спросить, я что ты вообще делаешь тогда в IT компании? Иди вон в бургерную менеджери. Хотя, наверное, и там менеджер должен разбираться в качестве ингредиентов и уровне прожарки мяса. Но в IT это стало нормой в какой-то момент.
В результате, что-бы понять хоть что-то из требований, программистам пришлось начать разговаривать с заказчиком напрямую. А поскольку общего языка у них нет, то разговор ведется «на пальцах»: программисты что-то показывают, заказчик кивает или качает головой. Двигаться маленькими шажками. Капитан Кук и людоеды. Это и есть agile.
Это работает и все замечательно, аналитики стали не нужны. Ровно до тех пор, пока ваша предметная область тривиальна и легко описывается в общепонятных терминах. Т.е. пока Кук объясняет людоедам, что за вот эти вот бусы, он хотел бы получить вот тот вот остров и принцип мены понятен всем.
Но вот Куку понадобилось объяснить людоедам какой нибудь бином Ньютона. И что?
В переводе на современную ситуацию: это все очень замечательно, что вы нарисовали интернет банк как хотел заказчик. Сейчас и дети умеют работать с сайтами и перетаскивать что-то там мышкой и вполне могут понять и освоить сайт банка, и объяснить что им нравится, что нет. Но все это по сути лишь интерфейс.
Другое дело — внутренняя логика банковской системы. Для того чтобы понять внутренние процессы, желательно иметь профильное финансовое образование. И программисту со стороны так просто туда не сунуться — он не понимает даже терминологию. А когда дойдет до математики, у него волосы встанут дыбом от того, как финансисты издеваются над классической вышкой, к которой он привык. Там где у него ряды, выводы и пределы — у финансистов будет арифметика и магические константы. Вот тут и случаются грабли.
И в результате, мы на практике увидим, что в ядре системы у банка стоит какой нибудь мэйнфрейм который собственно и выполняет всю тяжелую логику. И написано там все на кобол или рпг в те времена, когда об agile еще не слыхивали.
Желание перенести все это на новую платформу перманентно присутствует. Но попытки часто оканчиваются печально. С наскоку, без грамотного изучения, понимания, формализации и документирования требований, многократной выверки оных, ДО начала всякого кодирования, вряд ли возможно.
Вот и стоят динозавры в банках, пыхтят и обсчитывают всякие опердни.
Так что, не в методологии дело. Дело все в людях. И не надо так уж нападать на waterfall. В ряде случаев без него не куда.
Главный минус страны в том, что подданство не получить. Т.е. эмиратцами вы не станете никогда. А на западе обычно каждый год жизни там приближает к гражданству.
Второй минус — отношение и зарплата зависят от гражданства. Белый мистер из сша будет сразу получать совсем другие деньги при прочих равных.
Поэтому, мой совет — начинать в развитой европейской или североамериканской стране. Пока молодые — туда легче уехать и получить гражданство.
Потом можно ехать зарабатывать на БВ «белым мистером» из западной страны. Это будут хорошие деньги и перспектива «где встречать старость» более менее ясная.
Поэтому не совсем понятно, действительно ли принято решение перепаковывать чужой трафик своим сертификатом.
Мне кажется такие действия сомнительными с точки зрения эффективности. Приложения могут проверять например хэши своих сертификатов. Есть и другие методы защиты. Т.е. я к тому, что эти приложения и сайты могут как раз таки не заработать если их трафик попытаются проксировать. В компании где я работаю, тоже ставили грандиозную задачу проксировать весь трафик. При том что на все офисные компьютеры нужный корневой сертификат был предустановлен. Танцы с бубном вокруг F5 продолжались больше месяца.Получили кучу жалоб и в результате HTTPS теперь просто тунелируется. Я конечно понимаю, что могут сказать мол ваши админы не достаточно компетентны. Но я не уверен, что они менее компетентны чем казахские, например.
Другое дело, если государство решило заняться глобальным проксингом.
Вот что по этому поводу пишет Франк Солтис, создатель AS/400:
"… Язык программирования VLIC, называвшийся PL/MP и использовавшийся со времен разработки оригинальной System/38, был основан на языке PL/I. MP в его названии расшифровывается как Machine Product — имя, которое часто использовалось для обозначения аппаратных средств и обоих слоев микрокода. Компилятор PL/MP, как и ассемблер IMPI, генерировал двоичные машинные команды IMPI.
… В течение ряда лет мы пытались использовать другие языки при разработке компонентов VLIC. Например, один из наших новейших трансляторов был написан на Modula-2, применялся также язык С. Однако, мы чувствовали, что ни один из них не подходит для проекта, основанного на объектно-ориентированной технологии. Выбор напрашивался сам собой — язык C++. Нам нужно было разрабатывать код ОС очень низкого уровня. Иногда, для достижения оптимальной производительности приходилось прибегать к ассемблеру, и С+ + легче позволял это. Ведь, фактически, язык С++ и есть современный вариант ассемблера…
Технология ООП не подвела: производительность программистов при разработке SLIC повысилась почти в четыре раза по сравнению с традиционной методикой. В период с июля 1992 года, было создано более миллиона строк кода на С+ + и более 7 000 классов.… "
Ф. Солтис, «Основы AS/400».