Recomendamos a nuestros estudiantes en Launch Academy (www.launchacademy.com) que produzcan algo que les apasione.
Para algunos, es un problema persistente que han querido resolver por sí mismos. Los ejemplos de nuestra cohorte actual incluyen una aplicación de seguimiento de distracciones y una aplicación de tarjeta flash diseñada con capacidad de respuesta que lo ayuda a estudiar. Para otros, se trata de un pasatiempo o algo que surgió entre amigos. Alguien en nuestra clase actual está construyendo una aplicación de búsqueda de baños para su hermana debido a un momento particularmente desafiante que tuvieron en Maine un fin de semana :-). Para muchos otros, las aplicaciones se originan como ideas de inicio o para saciar una necesidad que tenían en su trabajo anterior. Un estudiante está creando una aplicación realmente genial que coloca a los pacientes en una lista de espera para los médicos si hay cancelaciones.
El denominador común en todos los proyectos es que hay una historia para contar dónde encontraron un dolor y crearon una aplicación como un medio para curarlo. Encontramos que crea un gran diálogo durante el proceso de la entrevista de esa manera.
- ¿Alguien ha tratado de usar algoritmos de procesamiento de lenguaje natural en jerga legal que aproveche la estructura del documento?
- ¿Cómo comienza la computadora a ejecutar la BIOS cuando está encendida?
- ¿Hay algo como la filosofía computacional?
- ¿Cuál es el significado de determinista y no determinista en informática?
- ¿Cuál es la mejor aplicación para compartir archivos grandes en Android?
Nuestros estudiantes (Lanzadores) se obsesionan especialmente si la idea ya se ha hecho. Recuerde el objetivo: mostrar sus habilidades de codificación. No se confunda con la creación de un MVP para el que pueda recaudar fondos. No tiene que ser una idea revolucionaria, solo tiene que brindarle una oportunidad desafiante para mostrar lo que puede hacer.
Lo llamamos un “juguete rompible” porque buscamos que muestre un camino de desarrollo y mejora. Tener un interés en el dominio es fundamental, porque lo alienta a seguir superando los desafíos técnicos.
Recomendamos que se incluyan los siguientes componentes técnicos:
- Pruebas de aceptación y pruebas unitarias (junto con estadísticas de cobertura de código relevantes)
- Un diagrama ER que muestra un modelo de datos interesante o convincente.
- Integración de API de algún tipo (¿se puede sindicar el contenido a Facebook o Twitter? ¿Existe una fuente de datos interesante con la que se pueda vincular?)
- Autenticacion y autorizacion
- Uso de objetos de servicio bien probados u Objetos de rubí simples (PORO) para demostrar una comprensión de los fundamentos de rubí
- Integración de algún código interesante de terceros como state_machine, simple_form o JQuery plugins por una razón apropiada
- Un diseño receptivo o móvil primero
- Algunos JavaScript que interactúan con un punto final JSON a través de AJAX (idealmente con pruebas unitarias)
- Un rico historial de confirmaciones que muestra la evolución de la aplicación y sus aprendizajes como desarrollador. ¡Los commits de refactorización son geniales para este tipo de cosas!
