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