Ну так этот язык ведь заточен под конкретную цель — эффективно упаковывать-распаковывать данные.
При чем тут схемы, индексы? О таких сущностях протобуф не знает.
Они что, свои метаданные в протобуф пакуют?
Автор еще упоминает какие-то анотации. Что интересно под этим подразумевается?
И главное, зачем городить?
"Мы используем Protocol Buffers для схем данных (и правил изменения схем) чтобы держать все слои распределённой системы синхронизированными, включая мобильные приложения, веб-сервисы и хранилище данных. Мы аннотируем схемы деталями конфигурации, такими как имена талиц и индексов, правилами валидации записей, такими как максимальная длина строк или допустимые диапазоны значений чисел."
Не совсем представляю, а как это можно делать. Они схему БД на протобуфе пишут?
… и код покрывается красным. Причем, по причинам, далеко не всегда очевидным тем, кто начинает разбираеться с языком.
Вообще, есть хороший доклад на эту тему. Полностью согласен со всеми замечаниями Антона, а вот ответы из зала, мол все так и задумано, выглядят не всегда убедительно.
Но я бы добавил еще и отсутствие фреймворка.
В докладе говорится о том, что с котлином не заработал mockito и пришлось писать довесок, причем все равно криво.
Вообще, мне весело читать теоретические рассуждения на тему того, что Play нефик делать подружить с Kotlin. Пример работающего проектика можно?
Отличная новость! Расскажите пожалуйста, как использовать Play с Kotlin?
Судя по вашему комментарию, все проблемы там решаются за пару часов.
Ну и исходя и популярности фреймворка, уже все давно решено, не так ли?
С удовольствием почитаю подробную инструкцию по имплементации.
Ну и если вас не затруднит, примеры успешных проектов в такой связке.
Заранее спасибо.
Чей-то как-то так себе. Выбор между Spring и проектами с непонятной перспективой куда комитят пару человек для серьезного проекта и не выбор вовсе. Помнится давно были разговоры о Play. Теперь, я так понимаю, эта тема заглохла окончательно. Может тогда все же пора заняться серьезно вопросом фреймворка, а не упавать на авсь мол что-то такое само взрастет? Уже сколько лет ведь…
«И это был один из немногих моментов, когда мой принцип «программы надо писать хорошо» меня подвел.»
Меня этот принцип подводит постоянно. Когда то, что ты пишешь, работает сразу и надежно, у принимающей стороны создается впечатление, что это от простоты задачи и вообще, не слишком ли много тебе платят. При этом рядом «косячит» деятель, которого вообще в профессию нельзя пускать. Но поскольку там «все сложно», баги так и лезут и все критические, их героически надо править и постоянные доклады о «победах» идут на самый верх — то вот кто и есть главный герой, получатель ништяков, бонусов и благодарностей.
Поскольку я давно далеко за пределами Родины, то иллюзий насчет столиц и больших городов не испытываю. Работал и в самых больших мировых IT компаниях — и на три буквы которая, и на две, и в не таких больших — везде примерно так. Ну может в гугле по-другому…
Прихожу к выводу, что если у вас сразу много денег и план на 10 лет вперед по развитию продукта — то вкладывайтесь в автоматизацию тестирования.
Если у вас стартап, где важны быстрота выхода первой бетты или продукт типа сделал раз и забыл — то нет смысла тратить время.
Я один чувствую некий диссонанс между принципами agile, в которых я готов подписаться под каждым словом, и кучей «методологий», «правильное» и одновременно жизнеспособное внедрение которых по слухам где-то существует но никто не видел?
Внедрение agile почему-то начинают именно с методологий, тулов для их поддержки и таймтрекинга.
А начинать надо бы наверное с консенсуса в компании на всех уровнях по поводу принципов.
И пока эти принципы не осознаны и не приняты всеми, внедрение каких-то методологий и тулов бессмысленно и вредно, IMHO.
Хотелось бы уточнить насчет случаев «различных задержаний в разных странах»…
Задержанные как-то пытались хотя бы минимально сохранять свою анонимность, или же, наоборот, в их открытых профилях были фотографии, друзья, реальные имена и т.д.?
Блокировщики рекламы — великое изобретение!
Пользуюсь на всех компьютерах уже много лет.
Если закроются сайты, живущие за счет рекламы, нисколько не буду сожалеть.
Появятся другие, имеющие более адекватную модель монетизации, повысится качество контента.
Я думаю, что практика работы с заказчиком по сбору требований не является специфической для agile и так же применима к waterfall. Это частное замечание.
А более общее. Проблема waterfall, на мой взгляд, вовсе не в методологии, а в изменении внешних условий.
Первое, и самое главное — резкое падение уровня технической подготовки IT аналитиков и менеджмента.
Если раньше, в 70-х, у менеджеров проектов и аналитиков IT компаний, обычно имелся инженерный, математический и т.п. диплом, то с какого-то времени этих специалистов начали готовить сразу, минуя инженерную ступень. Соответственно, они просто не в состоянии формализовать задачу на языке, понятном инженеру.
Частый пример из личного опыта, когда ПМ или аналитик на первом митинге с ходу заявляет: I'm not a technical person. Хочется сразу спросить, я что ты вообще делаешь тогда в IT компании? Иди вон в бургерную менеджери. Хотя, наверное, и там менеджер должен разбираться в качестве ингредиентов и уровне прожарки мяса. Но в IT это стало нормой в какой-то момент.
В результате, что-бы понять хоть что-то из требований, программистам пришлось начать разговаривать с заказчиком напрямую. А поскольку общего языка у них нет, то разговор ведется «на пальцах»: программисты что-то показывают, заказчик кивает или качает головой. Двигаться маленькими шажками. Капитан Кук и людоеды. Это и есть agile.
Это работает и все замечательно, аналитики стали не нужны. Ровно до тех пор, пока ваша предметная область тривиальна и легко описывается в общепонятных терминах. Т.е. пока Кук объясняет людоедам, что за вот эти вот бусы, он хотел бы получить вот тот вот остров и принцип мены понятен всем.
Но вот Куку понадобилось объяснить людоедам какой нибудь бином Ньютона. И что?
В переводе на современную ситуацию: это все очень замечательно, что вы нарисовали интернет банк как хотел заказчик. Сейчас и дети умеют работать с сайтами и перетаскивать что-то там мышкой и вполне могут понять и освоить сайт банка, и объяснить что им нравится, что нет. Но все это по сути лишь интерфейс.
Другое дело — внутренняя логика банковской системы. Для того чтобы понять внутренние процессы, желательно иметь профильное финансовое образование. И программисту со стороны так просто туда не сунуться — он не понимает даже терминологию. А когда дойдет до математики, у него волосы встанут дыбом от того, как финансисты издеваются над классической вышкой, к которой он привык. Там где у него ряды, выводы и пределы — у финансистов будет арифметика и магические константы. Вот тут и случаются грабли.
И в результате, мы на практике увидим, что в ядре системы у банка стоит какой нибудь мэйнфрейм который собственно и выполняет всю тяжелую логику. И написано там все на кобол или рпг в те времена, когда об agile еще не слыхивали.
Желание перенести все это на новую платформу перманентно присутствует. Но попытки часто оканчиваются печально. С наскоку, без грамотного изучения, понимания, формализации и документирования требований, многократной выверки оных, ДО начала всякого кодирования, вряд ли возможно.
Вот и стоят динозавры в банках, пыхтят и обсчитывают всякие опердни.
Так что, не в методологии дело. Дело все в людях. И не надо так уж нападать на waterfall. В ряде случаев без него не куда.
Я бы все же не советовал начинать с джуниора и небольшой зарплаты в ОАЭ.
Главный минус страны в том, что подданство не получить. Т.е. эмиратцами вы не станете никогда. А на западе обычно каждый год жизни там приближает к гражданству.
Второй минус — отношение и зарплата зависят от гражданства. Белый мистер из сша будет сразу получать совсем другие деньги при прочих равных.
Поэтому, мой совет — начинать в развитой европейской или североамериканской стране. Пока молодые — туда легче уехать и получить гражданство.
Потом можно ехать зарабатывать на БВ «белым мистером» из западной страны. Это будут хорошие деньги и перспектива «где встречать старость» более менее ясная.
Я склоняюсь скорее ко второму. Просто даже исходя из соображений стоимости содержания необходимых мощностей. Скорее глупость конкретных исполнителей, которые хотели отрапортовать об успешном внедрении и бешеной популярности национального сертификата.
При чем тут схемы, индексы? О таких сущностях протобуф не знает.
Они что, свои метаданные в протобуф пакуют?
Автор еще упоминает какие-то анотации. Что интересно под этим подразумевается?
И главное, зачем городить?
Не совсем представляю, а как это можно делать. Они схему БД на протобуфе пишут?
Вообще, есть хороший доклад на эту тему. Полностью согласен со всеми замечаниями Антона, а вот ответы из зала, мол все так и задумано, выглядят не всегда убедительно.
Но я бы добавил еще и отсутствие фреймворка.
В докладе говорится о том, что с котлином не заработал mockito и пришлось писать довесок, причем все равно криво.
Вообще, мне весело читать теоретические рассуждения на тему того, что Play нефик делать подружить с Kotlin. Пример работающего проектика можно?
Судя по вашему комментарию, все проблемы там решаются за пару часов.
Ну и исходя и популярности фреймворка, уже все давно решено, не так ли?
С удовольствием почитаю подробную инструкцию по имплементации.
Ну и если вас не затруднит, примеры успешных проектов в такой связке.
Заранее спасибо.
Меня этот принцип подводит постоянно. Когда то, что ты пишешь, работает сразу и надежно, у принимающей стороны создается впечатление, что это от простоты задачи и вообще, не слишком ли много тебе платят. При этом рядом «косячит» деятель, которого вообще в профессию нельзя пускать. Но поскольку там «все сложно», баги так и лезут и все критические, их героически надо править и постоянные доклады о «победах» идут на самый верх — то вот кто и есть главный герой, получатель ништяков, бонусов и благодарностей.
Поскольку я давно далеко за пределами Родины, то иллюзий насчет столиц и больших городов не испытываю. Работал и в самых больших мировых IT компаниях — и на три буквы которая, и на две, и в не таких больших — везде примерно так. Ну может в гугле по-другому…
Если у вас стартап, где важны быстрота выхода первой бетты или продукт типа сделал раз и забыл — то нет смысла тратить время.
Внедрение agile почему-то начинают именно с методологий, тулов для их поддержки и таймтрекинга.
А начинать надо бы наверное с консенсуса в компании на всех уровнях по поводу принципов.
И пока эти принципы не осознаны и не приняты всеми, внедрение каких-то методологий и тулов бессмысленно и вредно, IMHO.
А как перейти в тот регион, что справа, вы не сказали.
Задержанные как-то пытались хотя бы минимально сохранять свою анонимность, или же, наоборот, в их открытых профилях были фотографии, друзья, реальные имена и т.д.?
Пользуюсь на всех компьютерах уже много лет.
Если закроются сайты, живущие за счет рекламы, нисколько не буду сожалеть.
Появятся другие, имеющие более адекватную модель монетизации, повысится качество контента.
А более общее. Проблема waterfall, на мой взгляд, вовсе не в методологии, а в изменении внешних условий.
Первое, и самое главное — резкое падение уровня технической подготовки IT аналитиков и менеджмента.
Если раньше, в 70-х, у менеджеров проектов и аналитиков IT компаний, обычно имелся инженерный, математический и т.п. диплом, то с какого-то времени этих специалистов начали готовить сразу, минуя инженерную ступень. Соответственно, они просто не в состоянии формализовать задачу на языке, понятном инженеру.
Частый пример из личного опыта, когда ПМ или аналитик на первом митинге с ходу заявляет: I'm not a technical person. Хочется сразу спросить, я что ты вообще делаешь тогда в IT компании? Иди вон в бургерную менеджери. Хотя, наверное, и там менеджер должен разбираться в качестве ингредиентов и уровне прожарки мяса. Но в IT это стало нормой в какой-то момент.
В результате, что-бы понять хоть что-то из требований, программистам пришлось начать разговаривать с заказчиком напрямую. А поскольку общего языка у них нет, то разговор ведется «на пальцах»: программисты что-то показывают, заказчик кивает или качает головой. Двигаться маленькими шажками. Капитан Кук и людоеды. Это и есть agile.
Это работает и все замечательно, аналитики стали не нужны. Ровно до тех пор, пока ваша предметная область тривиальна и легко описывается в общепонятных терминах. Т.е. пока Кук объясняет людоедам, что за вот эти вот бусы, он хотел бы получить вот тот вот остров и принцип мены понятен всем.
Но вот Куку понадобилось объяснить людоедам какой нибудь бином Ньютона. И что?
В переводе на современную ситуацию: это все очень замечательно, что вы нарисовали интернет банк как хотел заказчик. Сейчас и дети умеют работать с сайтами и перетаскивать что-то там мышкой и вполне могут понять и освоить сайт банка, и объяснить что им нравится, что нет. Но все это по сути лишь интерфейс.
Другое дело — внутренняя логика банковской системы. Для того чтобы понять внутренние процессы, желательно иметь профильное финансовое образование. И программисту со стороны так просто туда не сунуться — он не понимает даже терминологию. А когда дойдет до математики, у него волосы встанут дыбом от того, как финансисты издеваются над классической вышкой, к которой он привык. Там где у него ряды, выводы и пределы — у финансистов будет арифметика и магические константы. Вот тут и случаются грабли.
И в результате, мы на практике увидим, что в ядре системы у банка стоит какой нибудь мэйнфрейм который собственно и выполняет всю тяжелую логику. И написано там все на кобол или рпг в те времена, когда об agile еще не слыхивали.
Желание перенести все это на новую платформу перманентно присутствует. Но попытки часто оканчиваются печально. С наскоку, без грамотного изучения, понимания, формализации и документирования требований, многократной выверки оных, ДО начала всякого кодирования, вряд ли возможно.
Вот и стоят динозавры в банках, пыхтят и обсчитывают всякие опердни.
Так что, не в методологии дело. Дело все в людях. И не надо так уж нападать на waterfall. В ряде случаев без него не куда.
Главный минус страны в том, что подданство не получить. Т.е. эмиратцами вы не станете никогда. А на западе обычно каждый год жизни там приближает к гражданству.
Второй минус — отношение и зарплата зависят от гражданства. Белый мистер из сша будет сразу получать совсем другие деньги при прочих равных.
Поэтому, мой совет — начинать в развитой европейской или североамериканской стране. Пока молодые — туда легче уехать и получить гражданство.
Потом можно ехать зарабатывать на БВ «белым мистером» из западной страны. Это будут хорошие деньги и перспектива «где встречать старость» более менее ясная.