Рубрика «Блог компании Google»

О недавних обновлениях Google Play Trust & Safety - 1

В рамках наших постоянных усилий по повышению доверия и безопасности пользователей в Google Play мы регулярно проверяем наши политики и правила, чтобы обеспечить положительный опыт разработчикам и пользователям. 16 апреля, в нашем Android блоге для разработчиков, мы анонсировали апрельское обновление политик и правил Google Play, которые дают пользователям больший контроль над их данными, ужесточают политики и правила представления платных подписок, и помогают предотвратить попадание мошеннических приложений в Google Play.

Этой статьей мы бы хотели ещё раз обратить внимание русскоговорящих Android разработчиков и пользователей на недавние изменения политик Google Play, и немного подробнее рассказать о двух наиболее значимых изменениях: более прозрачных для пользователей предложениях платной подписки и ограничении доступа приложений к геолокации.

Читать полностью »

image

Экосистема вокруг Google Ассистента развивается невероятно быстро. В апреле 2017 года пользователям были доступны всего 165 экшенов, а сегодня только на английском их – более 4500. Насколько разнообразным и интересным станет русскоязычный уголок вселенной Google Ассистента, зависит от разработчиков. Есть ли формула «идеального экшена»? Зачем отделять код и контент от сценария? О чем нужно помнить, работая над разговорным интерфейсом? Мы попросили команду Just AI, разработчиков технологий разговорного AI, поделиться лайфхаками по созданию приложений для Google Ассистента. На платформе Aimylogic от Just AI созданы несколько сотен экшенов, среди которых есть весьма популярные – в игру «Да, милорд» сыграли уже более 140 тысяч человек. Как правильно построить работу над экшеном мечты, рассказывает Дмитрий Чечёткин, руководитель стратегических проектов Just AI.

Взболтать, но не смешивать: роль сценария, контента и кода

Читать полностью »

image
Динамическое электронное письмо, созданное с использованием технологии AMP, российскими разработчиками из ecwid.ru

Проект AMP задумывался, чтобы улучшить пользовательский опыт в сети, а это значит и работу с электронной почтой, когда она происходит в вебе. Для большинства из нас функции электронной почты почти не изменились с момента ее появления (при этом, большинство из нас, очевидно, это появление не застали). Ну а суть AMP в обеспечении скорости и безопасности, поэтому не разработать AMP для электронной почты было нельзя. Казалось бы, как JavaScript в почте может быть хорошей идеей, но благодаря фреймворку AMP пользователи смогут взаимодействовать с письмами в реальном времени, не опасаясь за безопасность своих данных.

"Как?" — вы спросите? Ответ под катомЧитать полностью »

There are a lot of posts about what a typical coding interview at Google looks like. But, while not as widely described and discussed, there is also quite often a system design interview. For an SRE position it’s NALSD: non-abstract large system design. The key difference between SWE and SRE interviews consists in these two letters: NA.

What to think during NALSD interview - 1 So, what is the difference? How to be prepared for this interview? Let’s be non-abstract, and use an example. To be more non-abstract, let’s take something from the material world, such that you won’t be asked the exact same thing at the real interview (at least, not at the Google interview) :)

So, let’s design a public library system. For the paper books, like you have seen everywhere around. The whole text below was written all at once within around one hour, to roughly show you the areas that you should be able to cover / touch during the interview. Please excuse some disorder, that’s how I think (therefore I am).
Читать полностью »

Я описывал ранее типичное кодинг-интервью. Помимо кодинга почти всегда есть вопрос на проектирование систем. (Large) System Design. В случае собеседований на SRE, это еще более интересный (как по мне) зверь — NALSD. Non-abstract large system design. Главное отличие между SWE и SRE именно в этих буковках “NA”.

О чем думать на NALSD собеседовании - 1 В чем же отличие, и как подготовиться к нему? Давайте разберём на примере. В качестве примера возьмём что-то весьма материальное, что-то такое, что точно никто никогда не спросит на реальном собеседовании (в гугл) :)

Например — давайте спроектируем библиотеку. Для бумажных книг, обычную такую. Весь текст ниже был написан в один присест за примерно час, чтобы примерно показать что можно успеть, и что важно успеть. Так что уж простите за сумбурность, но я так мыслю (а значит, так существую).
Читать полностью »

Привет! Сегодня мы поговорим о процессе настройки и кастомизации CMS WordPress. Часто приходится слышать, что она годится лишь для небольших сайтов, а для сайтов СМИ с массивным трафиком она не подходит (хотя обратных примеров много). Еще одна особенность WordPress — отсутствие предустановленных продвинутых инструментов для журналистов, редакторов и всех, кому нужны дополнительные возможности при публикации новостей и статей, включая кастомное оформление материалов.

В то же время поклонники WordPress утверждают, что CMS подходит как для лендингов, так и для сайтов с миллионным трафиком. Истина где-то посередине. У WordPress есть недостатки, но при желании их можно избежать, одновременно усилив положительные возможности CMS. О том, как это сделать, сегодня и поговорим.
Читать полностью »

В августе 2018 года Flutter стал самой запрашиваемой кроссплатформенной технологией на Stack Overflow.

image

В нашем блоге Артем Зайцев, Android-разработчик Surf, и Евгений Сатуров, Android-тимлид Surf, расскажут, почему и как так получилось:

Кроссплатформенные решения давно привлекают желающих быстро и незатратно запустить MVP-продукт одновременно под несколько платформ. Причина проста — единая кодовая база. Ее легче поддерживать: артефакты централизованы, нет дублирования логики и правок одних и тех же багов под каждую из платформ. Да и людей для ее поддержки и создания требуется меньше — нет необходимости содержать двух нативных разработчиков.

Читать полностью »

В последние недели участилась волна статей на хабре о том, как проводятся собеседования.

Как собеседует Google: чему быть, чего не миновать - 1 Google ищет инженеров постоянно. Как SRE, могу точно сказать, что вы нужны в наших рядах. Печеньки на мини кухнях и кофе в кофемашинах ждут вас. Всего-то нужно пройти собеседование. Это сложно, но реально — когда-то я уже описывал свою историю как соискателя, а сейчас уже в числе прочего занимаюсь и проведением собеседований. Так что сейчас я расскажу, как мы проводим собеседования с инженерами.

Нет, я не стал HRом. Процесс собеседования предполагает сперва разговор с HR. Это общая беседа “что-куда-зачем” (то есть описание процесса для вашего конкретного случая) и тот самый всеми любимый скрининг из опросника с несколькими вариантами ответов. Скрининг мне в своё время показался весьма базовым, подозреваю, что вы отвечали на такие вопросы уже сотню раз. Затем собеседования будут проводиться уже инженерами — вашими будущими коллегами (близкими или далёкими, это уже как получится, наша планета весьма небольшая).

Читать полностью »

От Калининграда до Владивостока - 1

Привет! Ровно полторы недели назад, в самой западной части России – Калининграде, прошла некоммерческая конференция GDG DevFest Kaliningrad 2018, организованная сообществом разработчиков Google Developers Group Калининград. Тем самым ребята открыли в России сезон ДевФестов, которые пройдут в самых разных регионах и городах, от Калининграда до Владивостока, включая центральный и южные регионы, а также Сибирь. Специально для вас, тех, кто живет и читает нас по всей России, мы и написали эту статью, в которой вы сможете узнать кто такие GDG, что такое GDG DevFest и в каких городах они пройдут этой осенью и зимой. Добро пожаловать под кат.
Читать полностью »

Первые десять лет в Гугле я работал обычным инженером: запускал на картах общественный транспорт, улучшал поиск и отлавливал спам в ютьюбе. В какой-то момент обнаружилось, что по соседству с командами SWE (Software Engineers) существуют какие-то загадочные SRE (Site Reliability Engineers), которые живут в продакшене и всё знают про инфраструктуру, конфиги и мониторинг. Обычно они приходили к нам с непонятными графиками и настойчиво рекомендовали что-нибудь переписать в нашем сервисе, чтобы он взрывался аккуратно и по кусочкам, а не целиком и вместе со всеми соседями. Или строили какой-нибудь кусок инфраструктуры, волшебным образом решающий все наши проблемы раз и навсегда. Или сообщали, что второго релиза на этой неделе не будет, потому что один датацентр смыло ураганом, а рядом с другим хоронили лошадь и перерубили магистральный кабель. Через некоторое время стало понятно, что к этим людям можно приходить с самыми разнообразными проблемами, и уходить с решениями, найденными парой уровней абстракции ниже, чем ты ожидаешь от своего собственного продукта («вы, конечно, заплатили за нужный объем трафика, но вот здесь он у вас тупо не влезает в свитч, стоящий наверху стойки»).

В итоге мне стало интересно, как выглядит всё это SRE изнутри, и я подался в Mission Control – программу ротации, позволяющую провести полгода в роли SRE, получить ценного production-опыта и, при желании, вернуться в свою прежнюю команду делиться приобретёнными знаниями. Я вместо этого остался, как и две трети моих нынешних коллег по Video Processing SRE, тоже переквалифицировавшихся из обычных инженеров. Теперь я сам пугаю SWE непонятными графиками и эвакуирую ютьюбные видео из горящих датацентров, с перерывами на мирный созидательный кодинг. Оказалось, что за пятнадцать лет внутри Гугла выросла здоровая и эффективная SRE-организация со своими практиками, принципами и методами – но о них никто не знает, потому что из тех кто попадал туда, еще никто не возвращался назад.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js