Revisión droidcon SF

Hola Habr! Mi nombre es Alexander Kolobanov, soy un líder de equipo de Android en FunCorp. En noviembre, estaba en un droidcon en San Francisco. Debajo del corte, una pequeña reseña de la conferencia, notas de viaje y algunas fotos.

¿Por qué volar tan lejos?

Las conferencias de Droidcon se llevan a cabo no solo en los EE. UU., Sino también en Europa. Volar allí es cada vez más barato, pero según mi experiencia, puedo decir que la ubicación geográfica lo decide. Cuanto más cerca esté la conferencia de la sede de Google y otras compañías de TI, es más probable que participen en ella oradores famosos.

Además, diferentes organizadores en diferentes lugares, y solo su nombre los une. Por lo tanto, debe mirar cada ciudad por separado. En mi opinión, droidcon NYC es generalmente un sombrero de copa. Desde Europa, mencionaría droidcon London, una conferencia digna sobre la calidad de la organización y el nivel de los informes. Para los desarrolladores de Android de Europa, es quizás el principal. droidcon en Berlín y Viena, donde también visité, son más adecuados para principiantes y desarrolladores de nivel intermedio, y los oradores eminentes y los informes incondicionales sobre ellos son muy raros.

Si comparamos el droidcon SF con sus homólogos rusos, sus organizadores piensan menos en cosas como la comida (hay café, está bien) y la conveniencia de los participantes. Nadie envía planes detallados sobre cómo llegar allí, 20 recordatorios de que su conferencia será pronto, no hace bots y plataformas para la discusión y todo lo demás. Sin ceceo, navegación súper detallada y una elegante variedad de nishtyakov. Aquí, en primer lugar (así como en el segundo y tercero), la parte técnica y el nivel de los informes. Esto no significa que un par de informes más o menos pueden filtrarse en el programa, pero en general droidcon SF es una conferencia de desarrolladores para desarrolladores, donde solo hay contenido de alta gama y oradores eminentes.

Dado todo esto, diría que el programa de la conferencia en San Francisco fue de alto nivel. No hubo informes francamente hacky con el recuento de tutoriales de developer.android.com.

Transporte y otros gastos.

Estados Unidos no es un país barato, y si vuela desde nuestras partes, es poco probable que pueda ahorrar mucho en vuelo. Además, todos necesitan un nivel diferente de comodidad para vivir, y lo que es aceptable para uno no es adecuado para otro.

Un consejo universal que siempre funciona: tome los boletos y reserve el alojamiento con anticipación. Puede intentar buscar entradas con descuento y observar más de cerca las ventas. Hay mucha información sobre tales cosas en los sitios web y en grupos especializados en redes sociales dedicados a ahorrar en viajes. Debería buscar aerolíneas de rango medio, que a menudo ofrecen un servicio no peor que caro y empinado. Bueno, en general, en el trasatlántico, generalmente el servicio está al nivel de todos, independientemente de la clase. Las aerolíneas de bajo costo no vuelan a tales distancias (y bueno, probablemente). Y dado que el costo de un vuelo es una parte importante del presupuesto de viaje, es mejor combinar un viaje a la conferencia con unas vacaciones, si, por supuesto, existe esa oportunidad. Hay algo para ver y hacer en los Estados Unidos.









Los taxis en los estados son tradicionalmente caros. Por lo tanto, un consejo: use el transporte público o el uso compartido del automóvil (esto es cuando un taxi recoge a varias personas que viajan en rutas similares y comparten el costo del viaje). Entre ciudades es mejor viajar en autobús o alquilar un automóvil. El precio del estacionamiento en la ciudad es muy alto, y las condiciones son difíciles y extrañas (por ejemplo, no se puede estacionar de 8 a.m. a 10 a.m.el segundo jueves del mes, quédese y cuente), mientras que las pistas son muy convenientes y seguras, y las personas en el camino son en su mayoría no agresivas y predecibles .

Si hablamos de vivienda, entonces aquí no podrá ahorrar mucho, especialmente en ciudades tan caras como San Francisco. Para los amantes, hay entrenadores de surf, pero el resto es el mismo: reserve con anticipación.



Lugar

La conferencia se realizó en el Mission Bay Conference Center. Está ubicado en uno de los edificios de la Universidad de California en San Francisco. En el mismo edificio, por cierto, hay una biblioteca, un gimnasio y una cafetería. Había suficiente espacio, incluso a pesar del gran número de participantes (más de 800). En los pasillos, a veces teníamos que empujar, pero había suficiente espacio en los pasillos para todos, nadie estaba de pie junto a las paredes.

El centro de conferencias Mission Bay está ubicado muy cerca del centro de la ciudad (a 10 minutos en taxi del centro). Aquí tenemos que hacer un comentario: San Francisco en sí es una ciudad bastante compacta. Desde el centro hasta el aeropuerto, tome unos 40 minutos en taxi (un poco más en la hora pico). Por lo tanto, los problemas para llegar allí no deberían surgir en principio. Lo único con el transporte público en esa área es bastante complicado, así que preferí tomar un taxi.

A la conferencia se le asignaron 2 pisos, dos salas en cada uno: grandes y pequeños. El registro, donde se emitieron insignias y camisetas, estaba justo en la entrada. A pesar de la gran cantidad de participantes, todo fue muy rápido. Le tomó solo un par de minutos obtener una insignia. Una pequeña cola surgió en la mañana justo antes de la nota clave. Y las camisetas, por cierto, se distribuyeron en cantidades casi ilimitadas, y no solo en el registro, sino también en muchos puestos. Solo asi.

Detrás del área de registro había un gran salón, desde el cual todos ya se estaban dispersando en los pasillos. También tenía un área de exhibición con stands de empresas patrocinadoras (por cierto, había más de ellas en el segundo piso, y los edificios eran más densos) y puntos de café. Directamente desde el pasillo puedes ir a un pequeño parque ubicado dentro del campus. Agradable y confortable.

Momentos organizacionales

Todo estaba bien organizado, pero un poco inusual en comparación con las conferencias rusas. Definitivamente hubo menos alboroto y más atención a los informes y al aspecto técnico. De la "comida" solo había té y café. Prestamos mucha más atención a los coffee breaks, la restauración y la nutrición en general. Aquí, aparte de las bebidas calientes, no había nada. Más precisamente, a la hora del almuerzo todavía llevaban refrigeradores con latas de "Cola". Si quieres comer, allí, a la vuelta de la esquina, hay una cafetería donde puedes comprar un sándwich. No hay súper cuidado e hiper custodia para ti. Y, por cierto, esa era la norma.

El almuerzo en sí también era bastante nominal: una manzana, papas fritas y, de nuevo, un sándwich. Alimentado formalmente, pero no más. Muchos estudiantes fueron a almorzar en el mismo parque en bancos.

Pero vale la pena señalar especialmente la parte técnica de la organización. Prácticamente no hubo problemas con WIFI, aunque estaba abierto desde el campus. Los altavoces se configuraron y se conectaron muy rápidamente, en un par de minutos. Durante el informe, monitoreamos constantemente para que todo funcionara bien. Incluso redujeron y agregaron sonido casi instantáneamente cuando el altavoz, por ejemplo, comenzó a hablar más alto o más bajo. En general, no noté un solo problema y un problema con el equipo, todo fue excelente. A menos que en todos los informes se usen micrófonos alrededor del pasillo, pero los mismos oradores hablaron las preguntas que se les hicieron.

De lo inusual: me gustó mucho la habitación tranquila. Solo una habitación donde puedes entrar, tomar el té, sentarte con una computadora portátil en silencio y descansar del ruido de una gran conferencia.

El programa

Los informes fueron en cuatro corrientes, casi de la mañana a la noche. El sitio abrió a las 8 a.m., y el primer informe comenzó a las 9. Todo terminó alrededor de las 7 p.m. Los hilos no tenían ningún tema claro. Lo más probable es que los organizadores distribuyeron los espacios por asistencia estimada para cada informe. Los temas principales incluyen CI / CD (como casi todas las conferencias de Android en los últimos años), pruebas de IU (de repente resultó que casi nadie las tiene), Kotlin (¿dónde estamos sin él ahora?), Arquitectura aplicaciones (reúne dos desarrolladores de Android, y pronto hablarán "por la arquitectura"). En una palabra, todo es bastante estándar aquí. No puedo decir nada interesante sobre keynote, simplemente lo fue. Hablaron sobre el hecho de que hacemos aplicaciones que están en el teléfono de casi todos, damos forma a este mundo y cómo las personas interactúan y se comunican en él. Pero recuerdo el discurso de clausura cómico (aunque no se planeó originalmente una comedia) de Romain Guy y Chet Haase, personas muy famosas en el mundo del desarrollo de Android que trabajaron durante mucho tiempo en Google y determinaron cómo se ve la plataforma ahora. Creo que muchos vieron sus actuaciones en Google I / O (por cierto, muy bueno) sobre aceleración de hardware, animaciones y renderizado. Si no miró, lo recomiendo encarecidamente. No quisiera hablar mucho sobre su charla final de comedia , porque volver a contar chistes es una actividad regular. Mejor ver por ti mismo.
Si intenta resaltar los principales informes, resultará ser puramente personal y dependerá de los que me resulten más interesantes. Aquí esta:

Cómo construir una tubería de pruebas de rendimiento desde cero por Valera Zakharov de Slack. Gran rendimiento, fuego directo. Muchos consejos buenos y prácticos y una experiencia interesante. Un informe sobre el hecho de que no debe crear su propia granja de dispositivos si no tiene un equipo separado que lo respalde. Y cuán importante es no solo hacer que la aplicación sea rápida, sino también constantemente, de compromiso a compromiso, para asegurarse de que se mantenga así y no permitir regresiones. Y si las pruebas a menudo "hacen ruido" y caen en vano, entonces cuestan un poco, porque pronto todos simplemente comenzarán a ignorarlas.

Diseño API centrado en humanos , Pierre-Yves Ricau, Square. El que crea LeakCanary y un montón de bibliotecas igualmente conocidas junto con otros desarrolladores de Square. Dijo cómo hacer una API externa para las personas. Hazlo intuitivo. Entonces, para minimizar el porcentaje de errores para quienes lo usan. Un buen informe no solo se trata de escribir una API externa, sino de cómo diseñar adecuadamente en general. Por cierto, después de todo, la API de cualquier módulo de su aplicación también debería ser fácil y lo más clara posible, ¿verdad?

Construyendo para el futuro en Snapchat , Ben Dodson, Gustavo Moura, inesperadamente, pero desde Snapchat. Acerca de cómo rehacer una aplicación que tiene más de 4 años, es bastante lenta y cambió el concepto varias veces en el transcurso de la vida. Y en general, ahora, antes que nada, la cámara y luego el chat. E incluso Retrofit no estaba cuando lo escribiste. La idea principal es que no tienes que apresurarte para reescribir todo. Sería bueno entender sus prioridades y lo que quiere, introducir métricas y cumplirlas estrictamente. Aunque algunos módulos se pueden reescribir desde cero. Y sí, esto, de hecho, ya es una aplicación diferente, y debe presentarse de alguna manera a los usuarios, a veces simplemente reemplazar silenciosamente un módulo por otro e intentar evitar que todo se caiga. Basado en hechos reales.

Hubo muchos informes interesantes y útiles. Puede resaltar la historia de los desarrolladores de Uber, cómo lucharon sin memoria. A menudo, no solo las pérdidas y el gran consumo de memoria conducen a ellos, sino también una gran cantidad de subprocesos. Después de todo, cada hilo asigna una pieza de memoria para sí mismo debajo de la pila, por ejemplo. Pocos subprocesos también son malos: las tareas que dependen unas de otras, debido a la falta de subprocesos, entrarán en el punto muerto de hambre de subprocesos (como llamaron a la situación cuando una tarea espera el resultado de otra, y la que está cursi carece de un subproceso para ejecutarse). La solución a esta situación es bastante simple: use una herramienta para subprocesos múltiples en toda la aplicación (eligieron Rx) y sepa cómo funciona. En el caso de Rx, por ejemplo, examine la diferencia entre planificadores.

Los desarrolladores de Facebook presentaron una nueva biblioteca para trabajar con imágenes Spectrum. Por tradición, la biblioteca de Facebook usa código nativo, incluido MozJPEG, que ahora es uno de los mejores códecs para JPEG. Capaz de codificar, comprimir, optimizar, agregar varias transformaciones. En general, una funcionalidad bastante interesante, que antes era bastante difícil de encontrar en una forma fácil de usar.

A partir de un informe sobre Kotlin llamado Kotlin avanzado , podría descubrir que está avanzado en Kotlin, si sabe qué son infix y tailrec, distinga entre in y out para el tipo genérico, sabe sobre dónde y las clases selladas. Bueno, también puedes construir un dsl similar en lambdas.

También hubo buenos informes sobre la arquitectura de la interfaz de usuario de Tinder y Netflix. Los primeros crean, por así decirlo, una IU reactiva en estados que se cambian a través de acciones y usan LiveData y ViewModel de componentes arquitectónicos para esto. Este último hizo sus propios componentes, encerrando una parte de la lógica junto con la Vista, y los conectó a través de su implementación del bus de eventos.

Así que hubo muchos buenos informes, y la mención de cada uno que merezca atención probablemente tomará una docena de páginas. No era que ningún informe fuera francamente malo. Pero personalmente, no me gustó el informe de Romain Guy sobre fotografía. Ni siquiera se trata de cómo tomar fotos de su aplicación, sino simplemente de la teoría de la fotografía. Él es, por supuesto, un desarrollador respetado, pero la gente paga dinero por una conferencia sobre desarrollo de Android, y no por un curso de fotografía.

Red

Como tal, no había espacio para la comunicación con los altavoces o al menos una zona especial. Los oradores, por regla general, después de su presentación respondieron a las preguntas de la audiencia, y luego los invitaron a continuar la conversación informalmente, al estilo de "Estaré aquí hasta el final - atrapa, pregunta, me alegraré". Pero hay un matiz. Casi todas las compañías de las que provenían los oradores tenían puestos donde no solo los oradores, sino también otros desarrolladores de la compañía estaban pasando el rato, por lo que venir y hacer la pregunta de interés no fue un problema. Así que las gradas eran interesantes y a veces muy animadas.

¿Quién debe visitar droidcon SF?

Vale la pena visitar esta conferencia para aquellos que desean escuchar los informes aplicados de desarrolladores famosos, y luego también preguntar personalmente cómo y qué funciona para quién. El ambiente es muy abierto y amigable. Pero no recomendaría ir a la conferencia para aquellos que tienen poca experiencia. Los informes son bastante complicados, el ritmo de la conferencia es muy alto. 8 conferencias al día es duro. Tan grave que Slack, por ejemplo, entregó un kit de supervivencia, una bolsa con vitaminas y pastillas para el dolor de cabeza, en sus puestos. Y, como saben, en cada chiste solo hay una fracción del chiste. Además, al menos esta vez, muchos temas no solo se referían a la programación, sino también a la infraestructura, su experiencia y práctica. Por lo tanto, los líderes de equipo y los gerentes de desarrollo también podrán encontrar contenido adecuado para ellos en droidcon SF.

Si bien el tema de CI, las pruebas y todo lo relacionado con él todavía está vivo y es muy relevante, podría valer la pena ir a los ingenieros de control de calidad y DevOps. Por cierto, una de mis observaciones interesantes: en aquellas empresas que estuvieron representadas, a menudo hablan simplemente de ingenieros y no los dividen en desarrolladores, probadores e infraestructura. Esto se manifiesta en el hecho de que muchos pueden cambiar su rol y, como desarrollador, ir, por ejemplo, a un equipo de infraestructura. Por qué no, todavía ingenieros.

Impresión general

La impresión general es extremadamente positiva. Esperaba informes más débiles, pero casi no hubo "recorridos". En principio, estaba listo para la organización de los alimentos, o más bien, su ausencia. Esperaba que pudiera haber problemas para entender todo lo que se dijo, pero la mayoría de los oradores hablaron claramente y no aceleraron realmente, por lo que, en principio, no hubo problemas. A veces solo tomaba un poco acostumbrarse al acento. Y la organización técnica y la comunicación informal claramente excedieron las expectativas. Y esta no es solo mi opinión. Hubo muchas discusiones interesantes en el pasillo y en las gradas entre los informes.





PD Los enlaces a continuación son reseñas de otras conferencias extranjeras de nuestro blog:
droidcon Vienna
Atlassian
droidcon londres
Goto berlin
Cumbre web