Ingeniería de Software en Google (Registro nro. 1004)
[ vista simple ]
| 000 -CABECERA | |
|---|---|
| campo de control de longitud fija | 17041nam a22001937a 4500 |
| 003 - NUMERO DE CONTROL DE IDENTIFICACIÓN | |
| campo de control | OSt |
| 005 - FECHA Y HORA DE LA ÚLTIMA TRANSACCIÓN | |
| campo de control | 20250403140417.0 |
| 008 - DATOS DE LONGITUD FIJA--INFORMACIÓN GENERAL | |
| campo de control de longitud fija | 230418b |||||||| |||| 00| 0 eng d |
| 020 ## - NÚMERO INTERNACIONAL ESTÁNDAR DEL LIBRO (ISBN) | |
| Número Internacional Estándar del Libro (ISBN) | 978-958-778-851-8 |
| 040 ## - FUENTE DE LA CATALOGACIÓN | |
| Centro catalogador/agencia de origen | B-ISTTENA |
| 041 ## - CÓDIGO DE LENGUA | |
| Código de lengua del texto/banda sonora o título independiente | Esp |
| 245 ## - MENCIÓN DE TÍTULO | |
| Título | Ingeniería de Software en Google |
| Resto del título | Lecciones sobre programación aprendidas a lo largo del tiempo |
| Mención de responsabilidad, etc | Titus Winters; Tom Manshreck y Hyrum Wright |
| 250 ## - MENCIÓN DE EDICIÓN | |
| Mención de edición | 1ra Ed. |
| 260 ## - PUBLICATION, DISTRIBUTION, ETC. | |
| Lugar de publicación, distribución, etc. | Colombia |
| Nombre del editor, distribuidor, etc. | Marcombo,S.L |
| Fecha de publicación, distribución, etc. | 2022 |
| 300 ## - DESCRIPCIÓN FÍSICA | |
| Extensión | 620 P. |
| Dimensiones | 23.8 x 16.3 cm. |
| 505 ## - NOTA DE CONTENIDO CON FORMATO | |
| Nota de contenido con formato | INDICE<br/>-Prólogo<br/>-Prefacio.<br/>-Parte I. Tesis<br/>1. ¿Qué es la ingenieria de software?<br/>-Tiempo y cambio<br/>-Ley de Hyrum..<br/>-Ejemplo: ordenación hash<br/>-¿Por qué no aspirar a que «nada cambie»?.<br/>-Escala y eficiencia..<br/>-Políticas que no escalan.<br/>-Políticas que escalan adecuadamente.<br/>-Ejemplo: actualización del compilador. Desplazamiento hacia la izquierda Contrapartidas y costes.<br/>-Ejemplo: rotuladores.<br/>-Aportaciones a la toma de decisiones<br/>-Ejemplo: compilaciones distribuidas<br/>-Ejemplo: decidir entre tiempo y escala Revisar decisiones, cometer errores Ingeniería de software frente a programación Conclusión<br/>-Resumen<br/>2. Cómo trabajar bien en equipo<br/>-Ayúdeme a ocultar mi código<br/>-El mito del genio<br/>-La ocultación se considera perjudicial....<br/>-Detección temprana<br/>-El factor autobús...<br/>-Ritmo del progreso<br/>-En resumen, no se esconda.<br/>-Todo es cuestión de equipo.<br/>-Los tres pilares de la interacción social<br/>-¿Por qué importan estos pilares?...<br/>-Humildad, respeto y confianza en la práctica.<br/>-Cultura post mortem sin sentimiento de culpa Ser Googley<br/>-Conclusión<br/>-Resumen.<br/>-3. Compartir conocimientos.<br/>-Desafios para el aprendizaje.<br/>-Filosofia.<br/>-Preparación del escenario: seguridad psicológica<br/>-Tutoria.<br/>-Seguridad psicológica en grupos grandes.<br/>-Aumente sus conocimientos<br/>-Haga preguntas<br/>-Comprenda el contexto.<br/>-Escalado de las preguntas: pregunte a la comunidad.<br/>-Chats de grupo<br/>-Listas de correo electrónico<br/>-YAQS: plataforma de preguntas y respuestas<br/>-Escalado del conocimiento: siempre hay algo que enseñar<br/>-Horas de oficina<br/>-Charlas y clases de tecnologia<br/>-Documentación..<br/>-Código<br/>-Escalado de los conocimientos de la organización.<br/>-Cultivar la cultura de compartir el conocimiento. <br/>-Establecimiento de fuentes canónicas de información.<br/>-Manténgase al día.<br/>-Legibilidad: tutorías estandarizadas a través de la revisión del código ¿Qué es el proceso de legibilidad?.<br/>-¿Por qué someterse a este proceso?<br/>-Conclusión.<br/>-Resumen.<br/>4. Ingenieria para la equidad<br/>-Los prejuicios son la norma.<br/>-Comprensión de la necesidad de la diversidad.<br/>-Desarrollo de capacidades multiculturales. <br/>-Hacer que se pueda procesar la diversidad <br/>-Rechazo de enfoques singulares.<br/>-Desafio a los procesos establecidos Valores frente a resultados Mantener la curiosidad, seguir adelante.<br/>-Conclusión<br/>-Resumen.<br/>5. Cómo liderar un equipo<br/>-Gerentes y líderes en tecnologia (y ambos)<br/>-El gerente de ingenieria.<br/>-El líder en tecnología.<br/>-El gerente lider de tecnología<br/>-Pasar de la función de colaborador individual a la función de liderazgo.....<br/>-Lo único que hay que temer es..., bueno, todo<br/>-Liderazgo de servicio<br/>-El gerente de ingenieria.<br/>-«Gerente» es una palabra de cuatro letras<br/>-El gerente de ingeniería en la actualidad<br/>-Antipatrones.<br/>-Antipatrón: contratar a personas fáciles de manejar<br/>-Antipatrón: ignorar a las personas de bajo rendimiento.<br/>-Antipatrón: ignorar los problemas de carácter personal.<br/>-Antipatrón: ser amigo de todos<br/>-Antipatrón: comprometer el listón de contratación<br/>-Antipatrón: tratar al equipo como si fueran niños.<br/>-Patrones positivos.<br/>-Perder el ego<br/>-Ser un maestro zen.<br/>-Ser catalizador<br/>-Eliminar obstáculos<br/>-Ser maestro y mentor.<br/>-Establecer metas claras<br/>-Ser honesto.<br/>-Rastrear la satisfacción<br/>-La pregunta inesperada.<br/>-Otros consejos y trucos<br/>-Las personas somos como las plantas<br/>-Motivación intrínseca frente a motivación extrínseca.<br/>-Conclusión<br/>-Resumen.<br/>-6. Liderazgo a escala<br/>-Siempre hay que decidir.<br/>-La parábola del aeroplano.<br/>-Identificación de las orejeras.<br/>-Señalar las contrapartidas clave Decidir y, después, repetir Siempre hay que dejar solo al equipo.<br/>-Su misión: formar a un equipo «autónomo>>> División del espacio del problema..<br/>-Siempre hay que mantenerse escalando El ciclo del éxito<br/>-Lo importante frente a lo urgente.<br/>-Aprender a dejar caer pelotas al suelo.<br/>-Proteja su energia.<br/>-Conclusión.<br/>-Resumen.<br/>7. Medición de la productividad de la ingenieria.<br/>-¿Por qué debemos medir la productividad de la ingeniería?<br/>-Triaje: ¿vale la pena medirlo?.<br/>-Selección de métricas significativas con objetivos y señales.<br/>-Objetivos<br/>-Señales<br/>-Métricas.<br/>-Uso de datos para validar métricas.<br/>-Actuar y realizar un seguimiento de los resultados..<br/>-Conclusión.<br/>-Resumen.<br/>8. Guias de estilo y normas.<br/>-¿Por qué tenemos normas?.<br/>-Creación de normas<br/>-Principios rectores.<br/>-Guía de estilo<br/>-Cambio de las normas<br/>-El proceso.<br/>-Árbitros de estilo<br/>-Excepciones<br/>-Orientación.<br/>-Aplicación de las normas.<br/>-Comprobadores de errores.<br/>-Formateadores de código.<br/>-Conclusión<br/>-Resumen.<br/>9. Revisión del código<br/>-Flujo de revisión del código.<br/>-Cómo funciona la revisión de código en Google.<br/>-Beneficios de la revisión de código.<br/>-Corrección de código<br/>-Comprensión de código.<br/>-Coherencia del código.<br/>-Beneficios psicológicos y culturales.<br/>-Compartir conocimientos<br/>-Mejores prácticas de la revisión de código.<br/>-Sea cortés y profesional<br/>-Escriba cambios pequeños.<br/>-Escriba descripciones de los cambios que tengan calidad.<br/>-Mantenga al mínimo el número de revisores<br/>-Automatizar donde sea posible.<br/>-Tipos de revisiones de código...<br/>-Revisiones del código greenfield..<br/>-Cambios de comportamiento, mejoras y optimizaciones.<br/>-Corrección de errores y reversiones.<br/>-Conclusión.<br/>-Refactorizaciones y cambios a gran escala<br/>-Resumen<br/>10. Documentación <br/>-¿Qué calificar como «documentación»?<br/>-¿Por qué es necesaria la documentación?<br/>-La documentación es como el código<br/>-Conozca a su audiencia.<br/>-Tipos de audiencias<br/>-Tipos de documentación<br/>-Documentación de referencia<br/>-Documentos de diseño<br/>-Tutoriales<br/>-Documentación conceptual.<br/>-Páginas de destino<br/>-Revisiones de la documentación.<br/>-Filosofia de la documentación<br/>-QUIÊN, QUẾ, CUÁNDO, DÓNDE Y POR QUÉ.<br/>-El principio, la parte central y el final<br/>-Parámetros de la documentación de calidad. <br/>-Documentación obsoleta<br/>-¿Cuándo necesita a escritores técnicos?.<br/>-Conclusión.<br/>-Resumen..<br/>11. Descripción general de las pruebas<br/>-¿Por qué escribimos pruebas?<br/>-La historia de Google Web Server<br/>-Pruebas al ritmo del desarrollo moderno<br/>-Escribir, ejecutar, reaccionar.<br/>-Ventajas de probar el código. <br/>-Diseño de un conjunto de pruebas.<br/>-Tamaño de las pruebas..<br/>-Alcance de las pruebas<br/>-Regla de Beyoncé<br/>-Nota sobre la cobertura del código.<br/>-Pruebas a escala de Google...<br/>-Dificultades de un gran conjunto de pruebas<br/>-Historial de pruebas en Google..<br/>-Clases de orientación.<br/>-Pruebas certificadas<br/>-Pruebas en los aseos.<br/>-La cultura de pruebas actualmente.<br/>-Límites de las pruebas automatizadas<br/>-Conclusión.<br/>-Resumen.<br/>12. Pruebas unitarias<br/>-Importancia del mantenimiento.<br/>-Prevención de pruebas frágiles<br/>-Esfuércese en lograr pruebas que no cambien.<br/>-Pruebas a través de API públicas.<br/>-Comprobar el estado, no las interacciones..<br/>-Escriba pruebas claras<br/>-Haga que las pruebas sean completas y concisas.<br/>-Pruebe los comportamientos, no los métodos.<br/>-No ponga la lógica en las pruebas.<br/>-Escriba mensajes de error claros.<br/>-Pruebas y uso compartido de código: DAMP, no DRY<br/>-Valores compartidos.<br/>-Configuración compartida<br/>-Helpers compartidos y validación.<br/>-Definición de infraestructura de pruebas<br/>-Conclusión.<br/>-Resumen.<br/>13. Dobles de pruebas.<br/>-El impacto de los dobles de pruebas en el desarrollo del software. Dobles de pruebas en Google<br/>-Conceptos básicos..<br/>-Un ejemplo de dobles de pruebas.<br/>-Costuras..<br/>-Marcos de trabajo de simulación<br/>-Técnicas para utilizar los dobles de pruebas.<br/>-Simulación<br/>-Stubbing..<br/>-Pruebas de interacción<br/>-Implementaciones reales<br/>-Preferencia de las implementaciones reales a las aisladas. <br/>-Cómo decidir cuándo utilizar una implementación real<br/>-Simulación<br/>-¿Por qué son importantes las simulaciones?.<br/>-¿Cuándo deben escribirse las simulaciones?.<br/>-Fidelidad de las simulaciones.<br/>-Las simulaciones se deben probar<br/>-Qué hacer si no hay una simulación disponible?.<br/>-Stubbing.<br/>-Los peligros de abusar del stubbing.<br/>-¿Cuándo es adecuado utilizar stubbing?<br/>-Pruebas de interacción.<br/>-Preferencia de las pruebas de estado a las pruebas de interacción. <br/>-¿Cuándo son apropiadas las pruebas de interacción?.<br/>-Mejores prácticas para las pruebas de interacción<br/>-Conclusión.<br/>-Resumen.<br/>14. Pruebas más grandes.<br/>-¿Qué son las pruebas más grandes»?.<br/>-Fidelidad..<br/>-Brechas frecuentes en las pruebas unitarias<br/>-¿Por qué no realizar pruebas más grandes?.<br/>-Pruebas de gran tamaño en Google..<br/>-Pruebas más grandes y el tiempo.<br/>-Pruebas más grandes a escala de Google.<br/>-Estructura de una prueba grande<br/>-El sistema bajo prueba.<br/>-Datos para la prueba..<br/>-Verificación<br/>-Tipos de pruebas más grandes.<br/>-Prueba funcional de uno o más binarios interactivos.<br/>-Pruebas de los navegadores y dispositivos <br/>-Pruebas de rendimiento, carga y estrés.<br/>-Pruebas de la configuración de implementación <br/>-Pruebas exploratorias.<br/>-Pruebas de regresión de diferencias A/B<br/>-UAT<br/>-Sistemas de sondeo y análisis canario <br/>-Recuperación en caso de catástrofe e ingeniería del caos<br/>-Evaluación al usuario<br/>-Grandes pruebas y el flujo de trabajo del desarrollador.<br/>-Creación de pruebas grandes<br/>-Ejecución de pruebas grandes.<br/>-Propiedad de las pruebas grandes<br/>-Conclusión.<br/>-Resumen.<br/>15. Depreciación.<br/>-¿Por qué hacer depreciación?.<br/>-¿Por qué es tan dificil la depreciación?<br/>-Depreciación durante el diseño<br/>-Tipos de depreciación Depreciación recomendada.<br/>-Depreciación obligatoria.<br/>-Advertencias de depreciación <br/>-Gestión del proceso de depreciación.<br/>-Propietarios de los procesos.<br/>-Hitos<br/>-Depreciación de las herramientas..<br/>-Conclusión<br/>-Resumen.<br/>-Parte IV. Herramientas<br/>16. Control de versiones y gestión de ramas.<br/>-¿Qué es el «control de versiones»?.<br/>-¿Por qué es importante el control de versiones?.<br/>-VCS centralizado frente a VCS distribuido<br/>-Fuente de verdad.<br/>-Control de versiones frente a gestión de dependencias.<br/>-Gestión de ramas<br/>-El trabajo en curso es similar a una rama<br/>-Ramas de desarrollo.<br/>-Ramas de versión<br/>-Control de versiones en Google.<br/>-One-Version<br/>-Escenario: varias versiones disponibles<br/>-La norma «One-Version" Casi sin ramas longevas<br/>-¿Qué pasa con las ramas de versión?.<br/>-Monorepos<br/>-Futuro del control de versiones<br/>-Conclusión..<br/>-Resumen<br/>-17. Code Search<br/>-La interfaz de usuario de Code Search.<br/>-¿Cómo utilizan los Googlers Code Search?.<br/>-¿Dónde?.<br/>-¿Qué?<br/>-¿Cómo?<br/>-¿Por qué?<br/>-¿Quién y cuándo?<br/>-¿Por qué una herramienta web independiente?<br/>-Escala.<br/>-Vista global del código sin necesidad de configuración.<br/>-Especialización<br/>-Integración con otras herramientas para desarrolladores.<br/>-Presentacición de las API.<br/>-Impacto de la escala en el diseño.<br/>-Latencia de la consulta de búsqueda<br/>-Latencia del indice<br/>-Implementación de Google<br/>-Indice de búsqueda.<br/>-Clasificación<br/>-Selección de contrapartidas.<br/>-Completitud: repositorio en head.<br/>-Completitud: todos los resultados frente a los más relevantes.<br/>-Completitud: head versus ramas versus toda la historia versus espacios de trabajo.<br/>-Expresividad: token frente a subcadena frente a expresión regular.<br/>-Conclusión.<br/>-Resumen.<br/>18. Sistemas de compilación y filosofia de la compilación<br/>Propósito de un sistema de compilación. <br/>-¿Qué sucede si no existe un sistema de compilación? <br/>-Pero todo lo que necesito jes un compilador!<br/>-¿Scripts de shell al rescate?<br/>-Sistemas de compilación modernos.<br/>-Todo se trata de dependencias.<br/>-Sistemas de compilación basados en tareas.<br/>-Sistemas de compilación basados en artefactos.<br/>-Compilaciones distribuidas. <br/>-Tiempo, escala, contrapartidas <br/>-Tratamiento de los módulos y las dependencias..<br/>-La utilización de módulos detallados y la regla <br/>-Minimización de la visibilidad de los módulos <br/>-Gestión de dependencias<br/>-Conclusión<br/>-Resumen<br/>19. Critique, herramienta de revisión del código de Google.<br/>-Principios de las herramientas de revisión del código.<br/>-Flujo de revisión de código....<br/>-Notificaciones.<br/>-Nivel 1: realización de un cambio.<br/>-Diferenciaciones.<br/>-Resultados del análisis.<br/>-Integración estricta de herramientas.<br/>-Nivel 2: revisión de la solicitud.<br/>-Niveles 3 y 4: comprensión y comentarios del cambio.<br/>-Comentarios<br/>-Comprensión del estado de un cambio<br/>-Nivel 5: aprobación del cambio (puntuación del cambio).<br/>-Nivel 6: confirmación del cambio.<br/>-Después de la confirmación: seguimiento del historial.<br/>-Conclusión<br/>-Resumen<br/>20. Análisis estático<br/>-Características del análisis estático eficaz<br/>-Escalabilidad.<br/>-Usabilidad<br/>-Lecciones clave para hacer que el análisis estático funcione.<br/>-Céntrese en la satisfacción de los desarrolladores.<br/>-Haga que el análisis estático forme parte del flujo principal de trabajo del desarrollador.<br/>-Permita la contribución de los usuarios<br/>-Tricorder: plataforma de análisis estático de Google. <br/>-Herramientas integradas.<br/>-Canales de retroalimentación integrados<br/>-Sugerencias de correcciones.<br/>-Personalización por proyectos<br/>-Presubmits..<br/>-Integración en el compilador<br/>-Análisis durante la edición y navegación por el código.<br/>-Conclusión.<br/>-Resumen<br/>21. Gestión de dependencias.<br/>-¿Por qué resulta tan dificil la gestión de dependencias?.<br/>-Requisitos conflictivos y dependencias de diamante.<br/>-Importación de dependencias....<br/>-Promesas de compatibilidad Consideraciones al hacer la importación. <br/>-Cómo gestiona Google la importación de dependencias.<br/>-Gestión de dependencias, en teoría.<br/>-Nada cambia (también conocido como el «modelo de dependencias estáticas»).<br/>-Versionado semántico..<br/>-Modelos de distribución por paquetes.<br/>-Live at Head..<br/>-Limitaciones de SemVer..<br/>-SemVer puede que asegure una compatibilidad superior a la real SemVer podría exagerar..<br/>-Motivaciones<br/>-Minimum Version Selection.<br/>-Entonces, ¿funciona Sem Ver?.<br/>-Gestión de dependencias con recursos infinitos <br/>-Exportación de dependencias<br/>-Conclusión.<br/>-Resumen.<br/>22. Cambios a gran escala<br/>-¿Qué es un «cambio a gran escala»?<br/>-¿Quién negocia con las LSC?<br/>-Obstáculos a los cambios atómicos<br/>-Limitaciones técnicas<br/>-Fusión de conflictos.<br/>-Sin cementerios encantados<br/>-Heterogeneidad.<br/>-Pruebas<br/>-Revisión de código<br/>-Infraestructura LSC.<br/>-Políticas y cultura..<br/>-Comprensión de la base de código<br/>-Gestión de cambios..<br/>-Pruebas<br/>-Soporte del lenguaje.<br/>-El proceso LSC.<br/>-Autorización.<br/>-Creación de cambios<br/>-Fragmentación y envío.<br/>-Limpieza<br/>-Conclusión.<br/>-Resumen.<br/>23. Integración continua.<br/>-Conceptos de I.<br/>-Bucles de retroalimentación rápida.<br/>-Automatización.<br/>-Prueba continua<br/>-Desafios de la IC..<br/>-Pruebas herméticas.<br/>-Integración continua en Google<br/>-Caso de estudio de IC: Google Takeout.<br/>-Pero no puedo permitirme IC.....<br/>-Conclusión<br/>-Resumen.<br/>24. Entrega continua.<br/>-Modismos de entrega continua en Google.<br/>-La rapidez es un deporte de equipo: cómo dividir una implementación en partes manejables<br/>-Evaluación de cambios en el aislamiento: funciones de protección de banderas<br/>-La lucha por conseguir agilidad: configuración de un tren de lanzamiento..<br/>-Ningún binario es perfecto.<br/>-Cumpla con su fecha límite de lanzamiento<br/>-Calidad y enfoque en el usuario: envie solo lo que se utilice. <br/>-Desplazamiento a la izquierda: tomar antes decisiones basadas en los datos.<br/>-Cambio de la cultura del equipo: creación de disciplina en el despliegue<br/>-Conclusión<br/>-Resumen.<br/>25. La computación como servicio<br/>-Dominio del entorno informático<br/>-Automatización del trabajo<br/>-Contenerización y tenencia múltiple<br/>-Resumen<br/>-Escritura de software para la computación gestionada<br/>-Arquitectura para el fracaso.<br/>-Trabajos por lotes frente a trabajos de servicio.<br/>-Gestión del estado.<br/>-Conexión a un servicio.<br/>-Código único<br/>-CaaS con el tiempo y la escala.<br/>-Los contenedores como abstracción<br/>-Un servicio para gobernarlos a todos..<br/>-Configuración enviada.<br/>-Elección de un servicio informático.<br/>-Centralización frente a personalización<br/>-Nivel de abstracción: sin servidores<br/>-Público versus privado<br/>-Conclusión<br/>-Resumen.<br/>-Parte V. Conclusión<br/>-Epílogo<br/>-Índice.<br/> |
| 650 ## - | |
| Término de materia o nombre geográfico como elemento de entrada | CALIDAD DE SOFTWARE |
| 942 ## - ELEMENTOS DE PUNTO DE ACCESO ADICIONAL (KOHA) | |
| Código de la institución [OBSOLETO] | B-ISTTENA |
| Tipo de ítem Koha | Libros |
| Fecha de Catalogación | 18/04/2023 |
| Catalogador | Erika Calapucha |
| Fecha de adquisición | 14/04/2023 |
| Localización permanente | Fecha de adquisición | Fuente de adquisición | Número de inventario | Código de barras | Número de copia | Costo, precio normal de compra | Tipo de ítem Koha |
|---|---|---|---|---|---|---|---|
| Instituto Superior Tecnológico Tena | 04/14/2023 | DONACIÓN | ISTT-DS-0216 | ISTT-DS-0216 | Eje. 1/1 | 59.00 | Libros |