Denis Neklyudov es interesante para los desarrolladores de Android por varias razones. Está involucrado en el Android Dev Podcast, habla en conferencias, asiste a las cumbres de GDE, en general, participa en la vida de la comunidad de varias maneras. Y dado que ahora vive en los Estados Unidos y trabaja en Lyft, puede comparar la situación occidental con la rusa.
Y en la víspera de Mobius 2019 Piter, donde
habla sobre "arquitectura con un enfoque en la escala", le preguntamos un poco sobre todo esto. ¿Cómo puede un podcast ruso ser de interés para los oyentes occidentales? ¿Qué se siente al trabajar donde cuentan cientos de desarrolladores móviles? ¿Qué hay de malo con las soluciones de Google para desarrolladores de Android? ¿Y qué tiene de malo usar teléfonos inteligentes en general?
Podcasts
- Usted participa en Android Dev Podcast , y recientemente también apareció Flutter Dev Podcast : ¿cómo sucedió este "incipiente"?- Inicialmente, yo era el troll Flutter más importante. Los que estuvieron en la cumbre de GDE no te dejarán mentir. Le dije directamente a los principales gerentes de Google: ¿qué tipo de oficio es este, cómo puedes ponerlo junto a nuestro serio Android para adultos?
Pero un par de meses después de decir todo esto, fueron liberados, yo mismo intenté todo con mis propias manos, miré lo que puedes hacer al respecto y me di cuenta de que esto no era un juguete en absoluto.
Al principio, percibimos que había algún tipo de máquina virtual, JavaScript. Y luego resultó que todo está compilado en código nativo, y realmente funciona rápido en ambas plataformas. Al mismo tiempo, el ajuste es lo suficientemente viejo para una plataforma tan experimental, al parecer,. Y resultó que el lenguaje Dart no es tan malo. Sí, Kotlin no nos es familiar, pero es un lenguaje muy adulto y bueno con todos los encantos de los lenguajes de programación modernos.
Cambié de opinión y quedó claro que Flutter tenía perspectivas. Incluso React Native, Xamarin y otros marcos de terceros se han extendido, y aquí el soporte de Google e incluso los rumores sobre el nuevo sistema operativo Fuchsia, donde se usarán Dart y Flutter en primer lugar.
Pero no cubriremos todas las noticias de Flutter en Android Dev Podcast. Y luego tuve la idea de que sería bueno hacer un podcast por separado. Me dirigí a mi viejo amigo de los años universitarios, Zhenya Saturov, y le dije: “¿Quieres tomar la iniciativa? No voy a sacar el segundo podcast, pero eres más joven, tal vez lo tomes ". Y así nació Flutter Dev Podcast.
- Cuando la misma compañía de Google desarrolla el desarrollo nativo de Android y Flutter, puede que no esté claro para los desarrolladores novatos "bueno, ¿a dónde debo ir?" ¿Esto te parece un problema?- Si los principiantes no pueden decidir, ¡dejen que vayan inmediatamente al desarrollo de juegos en Unity! Pero en serio, hay un efecto descrito, pero Google ha estado sentado en dos sillas durante tanto tiempo: web y nativo. Hay cosas como las aplicaciones web progresivas que también se están desarrollando en Google. Parece que hay plataformas nativas, ¿por qué estás agitando tu PWA? Y también hay iniciativas como WebAssembly relacionadas con la ejecución de todo lo que es posible en el navegador (Google era originalmente del mundo de la web).
Por lo tanto, Google no es la primera vez que crea diferentes trabajos para diferentes categorías para resolver el mismo problema. Este es un coloso tan grande donde en el interior hay diferentes pequeñas empresas que luchan entre sí. Por lo tanto, no es sorprendente que haya competencia dentro de una corporación.
- Continuando con el tema de los podcasts: la compañía Lyft, donde trabaja, este año tiene su propio podcast sobre desarrollo móvil. ¿Tienes algo que ver con esto?- Comenzaron antes de que yo viniera: cuando la compañía va a hacer un podcast, no está "grabado, presentado", sino un largo proceso de acordar de qué puede hablar, de lo que no puede hablar. Pero prometieron invitarme a uno de esos temas (no llamaron al anfitrión).
Hay muchos podcasts sobre desarrollo móvil; recientemente apareció
otro idioma ruso. Creo que cuanto más haya, mejor: la calidad de aquellos que quieren estar en la cima es mayor. Pero está claro que los oyentes tienen que consumir más y más materiales. Es lo mismo con mitaps, conferencias, plataformas para informes.
- También hay un podcast The Context con Artyom Zinnatullin , y dado que ahora estás trabajando con él en la misma compañía, la pregunta es, ¿quieres unir fuerzas de alguna manera?- Que yo sepa, Artyom ya se perdió algunas ediciones de The Context debido al alto empleo en el trabajo. Pero también viene a nosotros en Android Dev Podcast con alegría, todo depende de los temas. Artyom no edita ediciones, pero viene con la opinión de expertos. Y a menudo me gusta editar, y aquí hacemos cosas completamente diferentes.
- Cuando participa en podcasts en idioma ruso mientras vive en el extranjero, ¿se siente como dos vidas paralelas, donde su podcast no se escucha en el trabajo, y en el podcast sabe algo sobre su trabajo solo por sus palabras?- En Singapur, esto no se sintió, pero en los Estados Unidos realmente se siente que estos son dos mundos diferentes. En Rusia me conocen, mi nombre ya tiene algo de peso. Nadie me conoce en los Estados Unidos, y en respuesta a las palabras "Tengo un podcast" preguntan por qué no lo escucharon. Porque él está en ruso. Aquí, por supuesto, pierdo.
Por lo tanto, mi iniciativa personal es hacer lanzamientos en inglés del podcast, hablar más en inglés para expandir la audiencia. Lo que estamos discutiendo en Rusia es igual de relevante en Occidente, hay muchos nichos sin llenar. Me parece que los temas que abordamos en el podcast serían buenos para cubrir más a menudo aquí.
- Los oyentes de habla inglesa ya tienen podcasts como Fragmented : ¿qué crees que puede proporcionar Android Dev Podcast, que no tienen?- Siempre quise creer que estamos más cerca del oyente. No tratamos de ser objetivos y, a menudo, nuestra opinión personal sigue siendo la opinión personal expresada en público. Pero al mismo tiempo, esta opinión tiene una gran experiencia detrás de nosotros, y no estamos avergonzados en nuestras declaraciones.
Quizás en Occidente simplemente no vaya, así que Fragmentado es un podcast más refinado, donde no hay suficientes antecedentes, detalles y dificultades (que muchos simplemente no entienden). En la búsqueda de una gran cantidad de audiciones para una audiencia amplia, algunos podcasts eliminan temas complejos para la discusión.
- Hablando no sobre los podcasts, sino sobre el desarrollo de Android, ¿sientes una diferencia notable entre los EE. UU. Y Rusia?- Creo que si. Todavía no estoy listo para juzgar estrictamente, pero el sentimiento principal (no tan difícil como en Singapur) es que todos están muy poco interesados en su profesión y sus habilidades. Aquí, cuando la compañía tiene muchos desarrolladores en la misma plataforma, las personas simplemente se sientan y hacen sus tareas, para ellos Android no es su vida, ni su pasión, ni su pasatiempo, sino simplemente una lista de tareas que deben implementar.
Gran escala en desarrollo móvil
- Trabajas en una empresa donde hay más de cien desarrolladores móviles. ¿Hacen constantemente la pregunta "Tienes una aplicación de aproximadamente una pantalla, ¿qué debe hacer esa multitud allí?"- Yo mismo inicialmente pregunté sobre esto. La respuesta llega cuando entras en todo esto.
En primer lugar, no podemos decir que tenemos una aplicación de pantalla única. Para empezar, hay dos aplicaciones (conductor y pasajero), y luego, si hablamos de la experiencia del pasajero, tenemos una aplicación con autos, scooters, bicicletas, autos autónomos y con diferentes chips para diferentes regiones (pago y usuario) .
Y en segundo lugar, muchas dificultades vienen con la escala. Hay mucho trabajo relacionado con pensar a través de métricas, crear experimentos, rastrear cómo va su trabajo anterior. La escala en forma de millones de usuarios afecta el tiempo de desarrollo, ahora lo entiendo mejor.
Estamos divididos en pequeños subcomandos multifuncionales, donde todos son responsables de una sección. Alguien es responsable del viaje, alguien de bicicletas y scooters, y así es como se forman dos docenas de equipos diferentes, en los que hay dos o tres desarrolladores. Soy responsable de la parte relacionada con la identificación del usuario. Y me gustaría ver a otro colega aparecer para esta parte, aumentando nuestro contador total.
Si hablamos de los desarrolladores de aplicaciones pequeñas, que están llenas entre nuestros lectores, resulta que simplemente constamos de una docena de aplicaciones pequeñas dentro de una grande.
La situación es similar en muchas aplicaciones grandes. Y la división en equipos de características y desarrollo impulsado por métricas, donde las métricas lo impulsan todo, y el enfoque de inicio, cuando hacemos MVP por primera vez, y luego lo llevamos a un buen estado: para algunos es en forma de todo el producto, y para alguien en forma de una característica interna. Incluso Google pone a sus pequeños equipos de tal manera que son como una startup, y trata de minimizar la burocracia y los largos ciclos de desarrollo.
- ¿Y cómo se ve el trabajo de un empleado en particular en tal situación? ¿Puedes hablar sobre alguna de tu voluminosa tarea?- Me llevó dos meses crear un perfil de usuario, aunque no es difícil en sí mismo. La pantalla en sí es nueva, anteriormente el usuario no tenía un perfil, solo había configuraciones. Además del hecho de que era necesario completar el acabado, resultó que desde el punto de vista arquitectónico, faltaban algunos componentes, me llevó a la arquitectura, ayudar a los chicos.
También decidí experimentar con Dagger, también tomó tiempo. También era necesario pensar en las métricas, construir un tablero de instrumentos, recopilar análisis del éxito del experimento, tomó tiempo. Luego comencé a agregar pantallas existentes desde la configuración a las pantallas internas del perfil y actualizar.
La actualización de acuerdo con la "regla de exploración" requería refactorizar lo que se tocó. La refactorización para la última arquitectura también tomó algo de tiempo. Además, tenemos un sistema de diseño y algunos componentes no se implementan a partir de los últimos elementos aprobados. Qué esperar para el equipo que escribe estos elementos, lo tomé y los ayudé a copiar su trabajo para que no se bloqueen.
De todo esto, se formaron dos meses de trabajo, que a primera vista parecieron un par de semanas.
- Cuando desea "experimentar con Dagger" durante la tarea, ¿se alienta a tales experimentos?- Depende del nivel del ingeniero. Creo que si él es un ingeniero de nivel de entrada, entonces él y el gerente tienen una clara comprensión de que no está distraído por ningún experimento arquitectónico, porque él mismo todavía está verde para esto.
Y de parte de ingenieros experimentados, está directamente en sus responsabilidades contribuir a algo amplio: en toda la organización, o al menos en toda la aplicación. Por lo tanto, no hay a dónde ir: incluso si no es muy interesante involucrarse en la arquitectura, pero desea desarrollarse, debe conectar su vida con algo más que características.
- Y si experimentaste y el resultado fue exitoso, ¿se convierte en una política general o puede permanecer dentro del equipo?- Muy raramente, permanece dentro de un equipo. Por lo general, si alguien comienza un experimento, esto es inmediatamente consistente con el equipo de arquitectura central y posteriormente se considera una buena práctica general. Por ejemplo, ahora dos equipos están experimentando con Redux en paralelo para comprender cuál de nosotros ganará, cuál será la solución más universal, y comenzaremos a usarla en toda la empresa.
- El aumento en el número de personas en un equipo también es el crecimiento del "papeleo" cuando no codifica, sino que hace algo relacionado. Está claro que esto es necesario, pero ¿cuánto ralentiza esto al desarrollador en comparación con la forma en que en un pequeño proyecto "simplemente presentaría"?- De nuevo depende del nivel de ingeniero. Si el ingeniero es de nivel medio o principiante, entonces no hay ningún requisito para que él escriba muchos documentos, se sienta y descubre las características bajo la supervisión de su ingeniero superior. Pero el ingeniero senior ya está adquiriendo responsabilidades administrativas, como en cualquier otra empresa. No puede salirse con la suya hablando con su jefe si se trata de una startup, o escribiendo documentos para su gerente, si se trata de una gran empresa.
- Cuando crea una aplicación de Android para un taxi, ¿los problemas y problemas actuales son casi los mismos que en otras aplicaciones grandes, o tiene sus propios detalles?- Los problemas que enfrentamos son muy similares. Por ejemplo, el problema del ensamblaje multimódulo agrega a los ingenieros de infraestructura las mismas preocupaciones todos los días, por lo que no es sorprendente que Uber, Facebook, Airbnb y Lyft utilicen el mismo sistema de construcción Buck.
Otros también lo miran, alcanzando nuestra escala, y esto confirma que los problemas son los mismos. Paralelamente, se producen los mismos procesos; por ejemplo, todos se vuelven reactivos lentamente. Bueno, alguien es más conservador, alguien todavía tiene devoluciones de llamada, sin reactividad e incluso sin Kotlin, porque la escala y las calificaciones de los desarrolladores no lo permiten.
La diferencia con la situación en el CIS es que a menudo nos acercamos y decimos: "Chicos de Gradle, ayuden con algo". Es decir, mientras que el CIS utiliza herramientas escritas en el Valle, aquí también nos comunicamos constantemente entre nosotros.
¿Google tiene razón?
- Recientemente, Jake Wharton recibió varias críticas sobre las soluciones de Google para el desarrollo de Android, y usted estuvo de acuerdo con algo de esto. ¿Qué crees exactamente que Google está haciendo mal?- Hubo una discusión de que no era necesario llamar al ViewModel y poner el contexto en él. Con esto, creo, muchos también estarán de acuerdo. Estoy muy molesto porque muchos perciben las bibliotecas de Google como una fuente innegable y la más correcta.
Los candidatos acuden a nuestras entrevistas, y 9 de cada 10 usan componentes de arquitectura de Android para resolver las tareas que les asignamos para describir el diseño de la aplicación que escribirían. Aquí no puedo estar en desacuerdo con Jake en que ViewModel tiene problemas controvertidos, aunque a todos realmente les gusta el ciclo de vida.
En cuanto a la biblioteca de Data Binding, Android Summit fue indicativo este otoño, donde en un chat con chimenea cinco de cada diez preguntas fueron sobre algo que no funciona en Data Binding. La herramienta era demasiado poderosa y, en mi opinión personal, nunca se me ocurrió para el ensamblaje rápido y de múltiples módulos. Pero al mismo tiempo, todos lo tomaron como verdad.
De hecho, es bastante conveniente, pero Google, en mi opinión, no asignó suficientes recursos para continuar apoyándolo. Y luego la comunidad se rompió: confiaron en Google, pero no recibimos suficiente apoyo.
"Algunas personas no están contentas con el hecho de que muchas de las soluciones de Google han aparecido solo en los últimos años:" Una buena cuchara para la cena, has estado encorvado durante años y la comunidad se ha dado cuenta, y ahora te has despertado. ¿Qué opinas sobre esto? ¿Por qué la empresa se comporta de esta manera y es mala?- Veo todo esto desde el punto de vista de la asignación del presupuesto y desde el punto de vista de la estrategia de algunos gerentes superiores separados que anteriormente tenían un punto de vista o eran solo otras personas, pero ahora han cambiado, con un enfoque diferente.
Es decir, esto no es Google, sino solo un par de personas que toman decisiones en el equipo de asignación de recursos de Android. Entonces obtuvieron recursos, desarrolladores y desarrolladores de bibliotecas que querían hacer precisamente eso: había soluciones de Google. ¡Y definitivamente es bueno que hayan aparecido! Estoy más molesto por una comunidad que cree incondicionalmente lo que se les dijo y no da ninguna evaluación crítica.
- Google, en un reciente video tutorial de desarrollo de Android sobre Udacity, ofrece una combinación de cosas básicas que todos necesitan y soluciones como Data Binding. ¿Ves el problema en que los principiantes que no estén familiarizados con el contexto los percibirán como una verdad indiscutible y no como una opción opcional?- Los cursos en video sobre Udacity son una historia aparte. He estado familiarizado con los cursos de Android allí desde 2016, cuando hicimos el primer curso de Study Jam sobre ellos. Allí, en general, todo salió a la perfección, las cosas básicas se explicaron perfectamente. Pero de las ocho lecciones en el curso, dos están en el medio: temas de ContentProvider indigestas, intransitables y muy complejos. ¿Por qué un principiante sabe cómo está estructurado ContentProvider? Ya en 2016 no estaba claro.
Todavía tenía preguntas sobre cómo componen los temas y colocan los acentos. Por lo tanto, las palabras de que todo está mezclado allí ahora, no me sorprenden en absoluto. Pero los cursos de video, a los que vale la pena rendir homenaje, generalmente son siempre un tema complicado. Se vuelven obsoletos tan pronto como los apagas.
Es muy difícil preparar material de buena calidad. Hay muchos lugares en la comunidad donde puede obtener nuevas fuentes de actualizaciones y una comprensión de lo que está sucediendo y cómo. Pero si los principiantes nos leen: vaya a trabajar en cualquier empresa que se dedique al desarrollo móvil, allí se le enseñará de inmediato cómo hacer todo bien. Algo más o menos relevante, hagámoslo saber, de boca en boca.
- Aquí, los principiantes tendrán una pregunta "cómo llegar allí sin experiencia, si aún no han pasado un año en los cursos".- Esta es una muy buena pregunta. Creo que muchas empresas adecuadas tomarán la informática para el conocimiento básico sin conocer ningún marco. Debido a que siempre puede encontrar el marco y obtener conocimientos básicos sobre la resolución de algoritmos, el conocimiento de la programación orientada a objetos y el juicio adecuado es difícil de obtener en algún lugar. Esta es la base. Con la base te llevarán. Y si también tienes inglés, entonces las puertas generalmente están abiertas para ti.
- Anteriormente, estaba interesado en la plataforma Android Things, y recientemente todo se ha vuelto bastante triste para ella. ¿Qué conclusión debemos sacar de la historia? ¿Que nunca puede confiar plenamente en las grandes empresas y que necesita usar cualquier plataforma con la expectativa de que mañana no se convierta?- Conclusión: que necesitamos monitorear las tendencias. Este no es el primer año que existe la tendencia de que cualquier dispositivo electrónico, ya sea una aspiradora o un microondas, comience a ser controlado desde la nube, como si nosotros, paranoicos, no estuviéramos tristes por eso.
Android Things como plataforma está demasiado sobrecargado para tareas simples de Android, mientras que no ayuda mucho en términos de la nube o algún tipo de aprendizaje automático (debido, nuevamente, a problemas de rendimiento). Esto sugiere que Android Things no es tan genial. Pero yo mismo fui quien hasta el último creía que esta plataforma es al menos una solución a los problemas que las piezas de hierro con Kickstarter dejan de actualizar. Que Google al menos actualizará el sistema operativo y lanzará parches de seguridad.
, : , Google Cloud Next , IoT Google - , — .
— , , . ?— Telegram- , , TikTok —
, - — . — . — , .
— , . , , .
— , TikTok ?— - , - , . , , — . , .
— 90 Seconds, — ? ?— . , . , Telegram, WhatsApp Google Docs, . B2B-, , . , , , — .
— , , . Twitter, — , ?— , , Telegram. , . , Twitter.
— : Mobius?— , . , over engineering, , .
, , , 60 ( Android). — , . , «2-5 2 » .