Como conseguí mi primer trabajo de programador sin ser ingeniero de software y lo que aprendí de ello.

Este post es más una anécdota personal que otra cosa, pero al final pondré lo que aprendí de ella. Quien sabe, puede ser que alguno de mis errores te sirva para no cometerlo.

Tal como dice en mi perfil en este blog, mi carrera no es como ingeniero de software, sino como ingeniero en mecatrónica, que si bien están relacionadas, no son lo mismo para nada. Para los que no sepan mecatrónica se encarga de juntar la mecánica con la electrónica, agregando toques de programación, pero principalmente orientada a microcontroladores. Al menos en mi carrera no vimos absolutamente nada de desarrollo web, móvil, etc. Entonces ¿Cómo chingados llegué a dedicarme de lleno a la programación? El resumen es que fue una combinación de suerte, curiosidad y atrevimiento.

Siempre me han interesado dos cosas: En primer lugar aprender lo más nuevo en tecnología, como implementarlo y hacer algo con ello, en segundo lugar emprender. Estas dos cosas hicieron que decidiera aprender iOS para programar en iPhone porque quería hacer una app por si me surgía una idea millonaria 🤑; el problema: No tenía para comprar un iPhone y cuando busqué un curso resultó que necesitaba una Mac que tampoco tenía así que me fui por Android, tomé un curso gratuito, resultó que necesitaba saber Java que tampoco sabía 😅 así que tomé otro curso de Java puro. En fin, aprendí lo básico para hacer aplicaciones súper sencillas, esto lo hice mientras hacía una maestría en machine learning, pero la verdad no le veía mucho futuro para lo que yo quería que era emprender.

En fin, al terminar la maestría volví a mi ciudad natal, pensaba tomarme un mes de vacaciones y empezar a buscar empleo relacionado con mecatrónica o con machine learning, aunque de esto último tenía pocas esperanzas. Pero después de solo un par de días de haber llegado mi primo al que le había contado que había tomado los cursillos estaba en la computadora y me dijo «Oye wey, aquí buscan a alguien de Android, ¿Tú sabes de eso que no?», revisé la solicitud de empleo y en efecto buscaban desarrollador de apps móviles con Android, como buen mexicano (E imagino que cualquier hispanohablante ya que todos nos parecemos en esto) pensé «Chingue su madre, vida solo hay una, voy a aplicar», ojo que yo solo sabía lo más de lo más básico no solo de Android sino de programación en general, pero envié mi currículum y no pasaron más de 15 minutos cuando me respondieron que me presentara al día siguiente a una entrevista.

Sobra decir lo nervioso que iba, lo gracioso es que un efecto de cuando me pongo nervioso es que además de las rodillas siento que me tiembla la mandíbula, pero creo que es solo una sensación mía que nadie nota (afortunadamente), bueno pues ese día iba temblando como pocas veces en la vida. Recuerdo solo dos de las preguntas que me hicieron, la primera era si usaba Eclipse o Android Studio, Android Studio acababa de salir ese año y es con el que había aprendido, así que pensé «Al menos en esta pregunta ya me fue bien», luego de varias preguntas me dijeron que iba a tener una semana de prueba donde tendría que implementar un login con la API de Facebook y otras cosas que involucraban hacer requests a internet, y aquí viene otra cosa graciosa, la segunda pregunta que recuerdo fue «¿Prefieres que las respuestas a los requests sean con XML o con JSON?», yo no tenía np idea de qué era XML ni JSON 😵‍💫😂, pero había escuchado algo de HTML entonces pensé «Bueno, si XML se parece en el nombre a HTML pues deben ser algo parecido» como JSON no me sonaba de nada le respondí que XML, me dijeron que empezaba ya al siguiente día, nos dimos la mano y me fui corriendo a mi casa a investigar qué demonios era XML y JSON, busqué mucha teoría y ejemplos y en todos ellos recomendaban usar JSON con Android por sencillez y porque las librerías se ajustaban mejor.

Llegué al siguiente día y una de las primeras cosas que le dije a mi jefe (Quien también fue quien me entrevistó) fue «¿Sabes qué? Pensándolo mejor prefiero JSON». Hice la primera semana de prueba y después de quemarme la cabeza día y noche pude lograr lo que me pedían y me quedé a trabajar, ahí aprendí a programar algo de iOS y también algo de web y lo que aprendí me impulsó a conseguir mi siguiente empleo en Estados Unidos, otra cosa curiosa es que una pregunta común en las entrevistas de trabajo que he hecho desde entonces es ¿Cuál ha sido uno de tus retos más grandes en un trabajo y que lo hayas podido resolver? y les cuento esta misma anécdota después de casi 10 años.

Ahora, esto es lo que aprendí:

  1. Si te gusta algo apréndelo sin importar si no va directamente ligado con tu carrera, la carrera no es la que nos dice qué es lo que haremos siempre, es muy válido cambiar. Yo ahora no volvería a mecatrónica, y no porque no me guste, pero la programación me gusta mucho más.

  2. El NO ya lo tienes, si te llama la atención un trabajo aplica a ello, lo peor es que te digan que no y si en serio te gusta mucho ese empleo, puedes preguntarles si puedes volver a aplicar en 6 meses por ejemplo. Si te contara las veces que me han rechazado en una empresa, fácilmente han sido más de 15.

  3. La parte técnica es más fácil de lo que parece al principio, la parte difícil es aventarse, tuve la suerte de haber quedado en esa empresa jeje, porque desde entonces no me importa mucho si siento que vale la pena arriesgarse. Claro que mucho ojo: Si estás en una empresa y quieres cambiarte a otra no te lanzas así nada mas, primero asegura el otro trabajo antes de renunciar, en esto «Nunca midas la profundidad del río con los dos pies al mismo tiempo».

  4. Normalmente estás más capacitado(a) de lo que piensas. El síndrome del impostor está muy cabrón. Yo iba muy nervioso, pero resultó que al final ya sabía más de lo que creía. Por si no lo sabes el Síndrome del impostor es el que te hace sentir que todos los demás son más inteligentes y habilidosos que tu, en especial al llegar a un nuevo lugar como un nuevo empleo, pero la realidad es que así como tu piensas eso los demás también los están pensando.

Bueno, espero que te haya gustado la anécdota y en especial que te haya servido al menos en lo más mínimo. Si es así te invito a suscribirte al blog y a la Comunidad Hackaprende y a dejar tus dudas y comentarios.

El .gitignore que mejor me funciona en Android

Para los que no lo sepan, .gitignore es un archivo que se puede usar en cualquier proyecto que use git y que sirve para ignorar otros archivos que no queremos en nuestro repositorio (Si no sabes qué es git te recomiendo este video), ya sea por seguridad o porque no son necesarios, por ejemplo archivos como certificados, contraseñas, etc. o autogenerados por la IDE que estamos usando. Dependiendo del proyecto es el .gitinore que necesitarás, este es el que yo uso en Android y me sirve de maravilla:

#built application files
*.apk
*.ap_
*.aab
                           
# files for the dex VM
*.dex
                            
# Java class files
*.class
                            
# generated files
bin/
gen/
                            
# Local configuration file (sdk path, etc)
local.properties
                        
# Windows thumbnail db
Thumbs.db
                
# OSX files
.DS_Store
                            
# Android Studio
*.iml
.idea
#.idea/workspace.xml - remove # and delete .idea if it better suit your needs.
.gradle
build/
.navigation
captures/
output.json 
    
#NDK
obj/
.externalNativeBuild

Lo tomé de aquí y me sirve muy bien, ojo que este documento puede ir cambiando conforme cambian las cosas en Android, aunque no es común que suceda. Como recomendación final, te recomiendo que tu primer commit sea agregar el .gitignore a tu proyecto para no tener problemas después ya que se complica un poco ignorar los archivos una vez que ya los pusimos en el repositorio.

Si te ha servido el artículo te invito a suscribirte al blog y a las redes sociales habidas y por haber 😛.

Parcelables en Android-Kotlin con ‘kotlin-parcelize’

Kotlin cada vez nos facilita más la vida, no dudes que en un futuro solo escribas «Kotlin, por favor desarróllame una app bonita sin errores y que se venta como pan caliente» y lo haga por sí solo (Es broma pero muchos clientes en serio creen que así funciona 😛)

Una de las cosas que se han vuelto muy fáciles es pasar objetos completos entre activities usando intents, para esto tenemos que implementar algo llamado Parcelable en la clase y esto convierte a los objetos a un formato que pueda ser enviado a través de un intent, a este proceso se le llama «serialización».

Supongamos que tenemos una clase Person:

Person(val name: String,
val age: Int,
val weight: Double,
val height: Double)

En vez de hacer esto:

val intent = Intent(this, OtherActivity::class.java)
intent.putExtra("name", person.name)
intent.putExtra("age", person.age)
intent.putExtra("weight", person.weight)
intent.putExtra("height", person.height)
startActivity(intent)

Podemos hacer esto:

val intent = Intent(this, OtherActivity::class.java)
intent.putExtra("person", person)
startActivity(intent)

Como dije arriba, para poder hacer esto la clase Person debe implementar Parcelable, antes esto era una tarea aburrida y repetitiva pero ahora basta con hacer lo siguiente: Primero agregamos el plugin de kotlin-parcelize en el archivo build.gradle(app)

plugins {
    id 'com.android.application'
    id 'kotlin-android'
    ...
    id 'kotlin-parcelize'
}

Luego vamos a la clase Person y agregamos @Parcelize en la parte superior, también implementamos Parcelable así:

import kotlinx.parcelize.Parcelize

@Parcelize
Person(val name: String,
       val age: Int, 
       val weight: Double, 
       val height: Double) : Parcelable

Y listo, ya con eso podemos pasar los objetos de tipo Person entre activities.

Espero que te sirva este pequeño consejo, si es así te invito a suscribirte y dejar tus comentarios o dudas o lo que sea.

¿Cómo tomamos decisiones para avanzar rápido en nuestros proyectos?

Hace un par de años trabajé como director de una empresa muy innovadora que tenía una buena cantidad de proyectos en construcción al mismo tiempo, realmente era muy genial estar desarrollando tantas cosas tan nuevas a la vez.

En fin, era mi primer puesto a tan alto nivel y tenía que tomar decisiones para la empresa todos los días a toda hora. Aprendí mucho, pero algo que me quedó marcado es que tomar decisiones es una tarea más agotadora de lo que parece, yo lo veo así: Cuando te levantas en la mañana tienes la batería recargada🔋 y durante el día cada decisión que tomas te quita un poco de energía, así que solo tienes energía para un cierto número de decisiones a lo largo del día, después de decidir una cierta cantidad de cosas quedas tan agotado que empiezas a tomar decisiones erróneas 😵‍💫. Un error que cometí fue el de no delegar lo suficiente cuando era posible y querer estar presente en cada decisión.

Cuando estás desarrollando un proyecto desde cero, las decisiones a tomar se elevan un 10 a la chorrocientas potencia (Me inventé ese número 😛, pero sí son muchas), desde decisiones de negocio como el nombre que llevará y cómo vas a cobrar, a decisiones de diseño como qué colores se manejarán, cómo será el logo y tipografías, pasando por decisiones técnicas como qué lenguajes de programación usarán.

Como ya he dicho en otras ocasiones, tengo 3 socios que hemos estado trabajando en diferentes proyectos por un poco más de 2 años, para esto hemos desarrollado muy informalmente una forma de tomar las desiciones que hasta ahora me ha parecido genial, nos ha funcionado de maravilla y por eso la comparto aquí.

En Bunu, cada uno de nosotros tiene habilidades muy diferentes y se queda con tareas afines a estas habilidades, por ejemplo hay alguien encargado de la electrónica, del diseño mecánico, de la programación, del marketing, de hacer relaciones con los clientes, ventas, etc.

Para tomar las decisiones sin que sea abrumador seguimos estos principios:

  • Si es una decisión sencilla como elegir el color de un botón, usar un redondeo en el diseño, usar una arquitectura de programación en concreto. El encargado toma la decisión sin tener que avisarnos a todos cada vez, si la persona lo desea se avisa en un grupo por chat que se va a hacer algo para pedir una opinión, pero como nuestra comunicación es asíncrona no necesariamente esperamos a que alguien o todos respondan para continuar trabajando. Muchas veces más que preguntar es presumir lo que estamos haciendo a los demás 😎. Esto también aplica si es una decisión donde quien está haciendo la tarea es el único experto del equipo en ese tema, por ejemplo si alguien sabe Android y los demás no, pues no tiene mucho caso preguntarles si usa una arquitectura en concreto. O si alguien sabe de web esa persona decidirá qué framework usar.

  • Si es una decisión compleja como el diagrama de negocios, cómo vamos a cobrar, si se va a necesitar un gasto fuerte para algo o el nombre del producto. Aquí sí lo comentamos entre todos, aunque tratamos de verlo con tiempo porque de nuevo, la comunicación es asíncrona y no esperamos que todos estén disponibles todo el tiempo, también estas cosas las vemos en una reunión semanal que tenemos los lunes.

  • Manejamos un software de chat llamado Basecamp para comunicarnos, en él creas tareas e invitas a los que pueden aportar a esas tareas, si alguien no está directamente relacionado con un tema y no cree que pueda aportar en él, ni siquiera entra en el chat y no se le pide que lo haga a menos que de verdad pueda aportar algo, también si siente curiosidad puede entrar como «oyente» sin problemas, tampoco es que lo excluyamos. Por ejemplo, supongamos que la tarea en curso es sobre diseño mecánico para fijar los tornillos de una pieza, la persona de ventas no tiene mucho que aportar ahí, entonces no se le invita al chat a menos que quiera hacerlo por curiosidad.

  • Asumimos que el 99% de las tareas no son urgentes, entonces tratamos de poner en espera las decisiones hasta el momento que se requieran. Tratamos de prever con tiempo si se necesitará algo en el futuro para irlo comentando con quien pueda ayudarnos y cuando lleguemos a ese punto ya se tenga una respuesta.

  • Asumimos que todas las decisiones que tomamos son para el bien del proyecto, si hay errores en una decisión no buscamos culpables. Confiamos en las decisiones que toman los demás sin estarles preguntando por qué están haciéndolo de esa manera, sí preguntamos, pero más por curiosidad o porque creemos que podemos aportar algo, nunca por micromanagement.

  • Creemos que la peor decisión es no decidir nada, vamos por rapidez y experimentación y evitamos el parálisis de análisis.

  • Finalmente, una pregunta que podría surgir es: si muchas decisiones se hacen sin tener que esperar o preguntar a los demás ¿Entonces cómo sabemos lo que cada quién está haciendo? En primer lugar, realmente no nos interesa qué está haciendo cada quién en todo momento, eso se ve en los resultados, en segundo lugar, como mencioné arriba, nos encanta presumir, siempre estamos posteando en el chat «Oigan miren lo que logré», «Uff esto no me sale ¿Alguna idea?», «Chequen como funciona esto». Es comunicación asíncrona pero constante. Por cierto, trabajamos 100% remotamente, si fuera en persona sería aún más fácil comunicarlo.

Es muy importante señalar que no es falta de interés en lo que están haciendo los demás, al contrario, si alguien necesita ayuda lo menciona en el chat y todos estamos dispuestos a ayudarnos, pero como dije al inicio del artículo, cada quien es experto en cosas diferentes y trabajar de esta manera nos ayuda a avanzar mucho más rápido, en especial en las etapas tempranas del proyecto.

¿Qué te parece esta forma de tomar decisiones? ¿Crees que funciona o es perjudicial? Te invito a suscribirte y dejar tus comentarios.

Hacklab: Listas con diferentes diseños en Android

Los headers, footers y listas con diferentes diseños en sus elementos son muy pero muy usuales en las apps móviles, solo falta ver estas apps famosas, todas ellas tienen más de un diseño en sus elementos:

Lo raro es que siendo tan usuales no haya muchos tutoriales sobre cómo lograr esto, es por eso que decidí hacer este Hacklab donde explico como implementar Headers, Footers y elementos con diferentes diseños en una misma lista. Para esto vamos a crear una app que muestre la cuenta en un restaurante.

Acá te dejo un enlace al Hacklab:

Si quieres ver más Hacklabs o saber qué es un Hacklab acá te dejo todos los que tengo, iré subiendo más cada vez.

Primera actualización de Bunu – Un servicio para los amantes del café

Hace un par de meses compartí un proyecto que estábamos iniciando y que ayudará a los amantes del café a que nunca se queden sin su taza mañanera. El servicio se llama Bunu y ahora que tenemos 3 meses desarrollándolo creo que es tiempo de poner una actualización de cómo nos ha ido y qué sigue, a ver si nuestro camino puede servir a alguien más.

Al iniciar el proyecto nos propusimos un tiempo de 3 meses para lanzar un MVP, (Si no sabes qué es un MVP te invito a ver este otro artículo). Ya llegamos a los 3 meses y estamos a punto de lanzarlo, aunque resultó todo un reto porque tuvimos que aprender cosas que ninguno del equipo era experto, la principal de ellas fue IoT (Internet of Things), aunque ¿Qué proyecto no necesita que aprendas algo? ahora ya tenemos una báscula totalmente funcional, segura y capaz de conectarse a internet, actualizar su propio software, entre otras características necesarias para que Bunu funcione como reloj suizo.

A la par con el desarrollo, hemos empezado una campaña de marketing, aunque todavía no a gran escala, pero ya tenemos páginas en redes sociales y empezamos a postear aquí y allá sobre lo que estamos haciendo. Muy pronto arrancaremos con todo en esta parte. Acá están nuestras páginas

https://www.facebook.com/bunucafe

https://www.instagram.com/bunucafe/

Acá unas fotos que me gustaron mucho 😎:

Puede ser una imagen de texto que dice "Algunas cosas son mejor en dark mode U bunu"

Otra parte en la que no somos expertos pero que tuvimos que aprender fue la parte del hardware desde la electrónica hasta el diseño e impresión 3D, después de muchas horas y de echar a perder mucho material, por fin estamos produciendo la báscula, te dejo orgullosamente unas fotos de fracaso 😅 y otra de éxito:

Por otra parte, ya tenemos trato con algunas marcas de café que están listas para cuando les digamos que podemos arrancar, empezaremos enviando algunos prototipos a nosotros mismos y a personas cercanas para probar que no truene todo 🤣, y después de probarlo por un par de semanas empezaremos con los envíos a un grupo seleccionado que se haya suscrito en nuestra página web y desee adquirir su base.

Creo que vamos bien y por buen camino, hemos avanzado mucho considerando que este es un proyecto alterno y todos tenemos nuestros trabajos del día a día, muy pronto estaré subiendo otra actualización. Mientras acá te dejo el enlace a nuestra página web recién estrenada, espero que el proyecto te guste tanto como a nosotros y nos puedas apoyar compartiendo en redes sociales.

https://bunucafe.com

Haz tareas que aporten valor

Te voy a contar una historia de uno de los principales errores que he cometido, aunque depende del cristal con que se mire porque aprendí mucho, pero desde el punto de vista emprendedor considero que sí fue un gran error.

Hace un par de años se me ocurrió una idea para mejorar el servicio de los restaurantes, haciéndolo más rápido, con menos errores y, para alguien introvertido como yo, más cómodo. Entonces creé Menumy, una aplicación para lograr resolver estos problemas, no entraré en detalle en el proyecto, en resumen después de alrededor de un año de operar tuvimos que cerrar la startup por algunas razones que nos dejaron mucho aprendizaje y que explico acá.

Para lanzar un producto de este tipo debes aprender bastantes cosas, lo cual es bueno, por ejemplo yo tuve que aprender a programar en backend así que aprendí Django con Python, tuve que aprender a vender, algo de HTML y CSS, algo de React, etc. etc., todo esto estuvo bien porque era esencial para construir el producto y agregaba valor, pero el error que cometí (Uno de tantos) fue el siguiente: Por entonces iba empezando a despegar una nueva tecnología llamada Docker, ahora ya es un estándar en la industria pero en ese tiempo que tu proyecto usara Docker era genial técnicamente hablando. En resumen Docker ayuda a que puedas configurar tus proyectos en cualquier ambiente (Linux, Windows, Mac) en minutos y que funcione en cualquiera de ellos para evitar el típico «En mi máquina sí funciona», ese es su principal uso.

En fin, solo por verme «Cool» y por mi amor por el aprendizaje decidí armar el proyecto usando Docker; ERROR. Sin exagerar el 33% del desarrollo de mi proyecto me llevó entender y configurar Docker, alrededor de 2 de los 6 meses de desarrollo, después de unas semanas ya lo estaba haciendo más por reto y porque me pesaba que el tiempo invertido fuera en vano.

Claro que aprender algo nuevo no es malo, si el objetivo hubiera sido aprender, pero el objetivo era lanzar un producto rápidamente, validarlo, iterar, mejorar y conseguir usuarios y clientes, y aprender Docker no me dio nada de esto en ese momento del proyecto, no lo iba a usar realmente, no había más desarrolladores y aunque hubiera el tiempo de haber configurado Docker no se iba a ver compensado en mucho tiempo. Al cerrar la app pude haber ahorrado dos meses de mi tiempo que pude haber usado o para crear otro producto o haberlo invertido en otras cosas como validación de la idea.

La enseñanza que me queda de esta historia es que Antes de tomar una decisión de irte por una tecnología o cualquier tarea para tu proyecto, como hacer tu logo o gastar en tarjetas de presentación, piensa si aporta valor. Si no, ponla en una lista de «tareas futuras» y olvídate de ella por el momento.

Estas son algunas cosas que no aportan valor al inicio de un proyecto:

  • Quebrarte la cabeza pensando en cosas que escalen.
  • Hacer cosas como logos, tarjetas de presentación, misión y visión de la empresa, organigramas, etc.
  • Ir a demasiados eventos de networking, emprendimiento, dar pláticas. Está bien ir y mejor si ayudas a otros, el error es pensar que estás siendo productivo y agregando valor a tu producto.
  • Aprender y usar tecnologías para agregar mucha seguridad (A menos que esa sea la propuesta de valor de tu producto) o para que todo quede mucho más robusto, como en mi caso con Docker.
  • Gastar tiempo en elegir herramientas de gestión de tareas (Jira, Trello, etc.), gestión de clientes (CRM), y hacer toda una estructura burocrática para llevar el proyecto. Todo esto solo te distraerá y en este punto es como tirarle a un pato con balas de elefante.
  • Tardarte mucho diseñando una pantalla, lo más probable es que esa pantalla cambiará en la siguiente iteración.
  • Tratar de cubrir casos que son muy improbables que sucedan.

Hay un dicho muy trillado que queda como anillo al dedo: «Es diferente estar ocupado que ser productivo», deja de lado las tareas que te mantienen ocupado(a) pero no aportan valor.

Espero que esta pequeña historia te sirva para no cometer el mismo error que yo :P, como siempre todas las dudas y comentarios son bienvenidos y te invito a suscribirte y seguirme en todas las redes habidas y por haber.

Haz cosas que no escalen al principio

Este artículo está basado en un artículo que me encanta de Paul Graham, llamado Do things that don’t scale. Paul Graham es uno de los directivos de YCombinator, una empresa que invierte en startups como Pinterest, Airbnb, Dropbox, etc, si piensas en una de las empresas famosas de Silicon Valley, ellos han invertido ahí.

Vamos empezando por el principio ¿Qué es escalar? En el área de las Startups y las empresas en general, escalar significa que el costo de llegar a pocos clientes y a muchos no aumente proporcionalmente. Ejemplos:

  • Un restaurante tradicional no es escalable o es poco escalable porque si hacer un platillo me cuesta $10 y yo lo vendo en $15 gano $5 por platillo, pero si lo vendo a 1000 clientes, me va a costar en proporción a esos 1000 clientes, es decir, me cuesta unos $10000. Claro, puedo aplicar comprar ingredientes por mayoreo pero no reduciré mucho el costo con eso.
  • Un videojuego es escalable porque llegar a 10 clientes me cuesta $10000 en desarrollo, pero llegar a 100 clientes me cuesta prácticamente lo mismo y llegar a 1000000 de clientes también, la inversión no sube proporcionalmente con las ganancias.

La segunda alternativa suena mucho mejor, y como suena tan bien tendemos a cometer el error de que cuando creamos un nuevo producto, en especial de software, queremos escalar desde el inicio, me atrevo a escribir este artículo porque este error lo he cometido más de una vez u.u. El problema con esto es que como en todo, es difícil iniciar desde 100, se inicia en 0 y se va subiendo poco a poco. Los primeros pasos al lanzar es encontrar tu nicho de mercado, que la gente lo use, te de retroalimentación y puedas mejorarlo, hay que verlo como un gran barril que quieras trasladar, primero hay que empezar a rodarlo poco a poco, con mucho esfuerzo, luego irá tomando tracción y, si no se rompe antes, empezará a rodar por si solo.

Supongamos que estás iniciando una empresa que te lave la ropa: Ordenas en línea, la recogen en tu casa y te la regresan lavada y planchada. Lo voy a explicar con qué hacer y qué no hacer al principio en diferentes casos.

NO: Hacer toda una plataforma para que muchos se suscriban, rentar lavanderías o crearles una app a lavanderías externas para que puedan recibir pedidos. Lanzar en toda la ciudad o incluso en varias ciudades a la vez.

SI: Hacer una página web sencilla, donde TU MISMO(A) vayas a recoger y entregar la ropa, tal vez contratar a alguien que lave y planche pero si es posible hacerlo tú mismo también.

Razón: Lo primero que quieres hacer es validar tu idea, conocer a tus clientes, conocer el problema y si realmente existe un problema, conocer los retos a los que te vas a enfrentar y resolverlos en pequeño para después poder enfrentarlos en grande. Además de no gastar mucho dinero hasta que veas que realmente funciona.


NO: Contratar personal.

SI: Hacer todo lo que puedas tu mismo.

Razón: Uno de los principales errores que cometemos es contratar personas al inicio, en especial en las empresas tecnológicas los sueldos son el gasto más alto que hay, y en específico un super error es subcontratar el núcleo de tu negocio.

NUNCA SUBCONTRATES EL NÚCLEO DE TU NEGOCIO


NO: Desarrollar toda una plataforma que te lleve muchos meses, que tenga mucha seguridad, que use cosas que no agreguen valor al proyecto en su etapa inicial.

SI: Hacer un Producto mínimo viable (MVP) que te permita validar la idea cuánto antes.

Razón: De nuevo, lo que quieres es validar la idea sin que te cueste mucho tiempo, dinero y esfuerzo.


NO: Trates de crecer si no puedes cumplir con la calidad que quieres.

SI: Crea algo que deleite a tus clientes, que les de una experiencia genial.

Razón: Es preferible tener menos clientes que ADOREN tu producto a más clientes que solo les guste. Cuando logres generar esa calidad a mayor escala entonces sí lánzate a más personas.


NO: Lances una campaña de marketing a todo el planeta para que se entere de la existencia de tu producto.

SI: Empezar en pequeño, tal vez en tu ciudad donde tengas un «ambiente controlado», o si se trata de un producto en linea, de un nicho muy específico de personas que puedan adorar tu producto, recuerda que en este punto deberás hacer casi todo manualmente.

Razón: Las Startups son muy frágiles al inicio, a menos que tengas mucho dinero un error puede costarte el quiebre de tu empresa, y un error común es querer llegar a personas que ni siquiera tenemos la posibilidad de atender en nuestra situación actual, y peor, pagando un costo muy alto de marketing.

¿Qué opinas de esto de «No escalar»? ¿Estás de acuerdo o no? te invito a suscribirte y dejar tus comentarios.

17 Cosas que he aprendido en mi carrera tecnológica

Hace poco di una plática a los alumnos de una preparatoria que quieren entrar a carreras tecnológicas y dije «Qué rayos, voy a compartirla también en mi blog, podrían servirle a alguien» así que aquí están:

  1. Lo que aprendas por tu cuenta multiplica x10 lo que aprendes en la escuela: La escuela tiene un límite de lo que te puede enseñar. Conforme avanzas a niveles más altos, te darás cuenta que ser autodidacta es lo que diferencia a los que más saben de los que no.

  2. Trabajar es cansado, pero te llevará a muchos lugares: Figurativamente y literalmente, el trabajo duro SIEMRE reditúa, si no triunfas aprendes.

  3. La pasión se hace. La frase correcta no es «Sigue tu pasión» sino «Construye tu pasión»: Pensamos que la gente nace con una pasión, pero esta se construye a base de esfuerzo y disciplina, recuerda esto la siguiente vez vayas a mitad de un proyecto y no te sientas «apasionado». El aburrimiento mata más proyectos que la competencia.

  4. Lo académico y el emprendimiento van por caminos muuuy diferentes. Al menos donde a mi me tocó estudiar, las escuelas tienen sus propias incubadoras pero son demasiado lentas para lo que se necesita en el emprendimiento. Si tienes ganas de emprender, hazlo sin esperar a que una institución te apoye.

  5. Lo que aprendes en la escuela y lo que necesitarás en el trabajo son cosas muy distintas. Aún así en la escuela aprendes cosas muy importantes, como la disciplina y a cumplir con un objetivo.

  6. El inglés es tan, o incluso más importante que el conocimiento técnico.]

  7. Una buena negociación vale más que un buen currículum. Siempre tírale arriba al sueldo.

  8. El síndrome del impostor es canijo y todos lo tenemos. ¿Sientes que no perteneces y que todos son más inteligentes que tú? El de tu izquierda y el de tu derecha también sienten lo mismo acerca de ellos mismos, no dejes que esto te limite.

  9. Si no te gusta lo que haces, salte de ahí. Es más fácil decirlo que hacerlo y no me refiero a que te salgas a lo burro, pero sí empieza a buscar alternativas y cuando tengas una segura ya te sales. Pero la vida es muy corta para estar donde no quieres.

  10. Conoce un poco de todo, pero el dinero está en especializarte en algo. Ahí está el $$$.

  11. Las calificaciones son buenas para el ego. Pero los méritos y los proyectos personales ayudan mucho a encontrar un buen trabajo.

  12. Júntate con los buenos, con los do’ers y con quienes sepan más que tú. Frase trillada pero muy cierta: Eres el resultado de las 5 personas con las que más te juntas.

  13. Mejor hecho que perfecto. El error más grande que he cometido en mis emprendimientos es tardar mucho en hacer las cosas por querer que sean perfectos. ¡Lánzate ya!

  14. El aprendizaje nunca se acaba, JAMÁS. Entre más rápido te acostumbres menos sufrirás en el futuro.

  15. Con conocimiento tecnológico puedes hacer lo que te venga en gana, desde zapatos a carros Tesla.

  16. La vida es muuuuuy cara, ten más de una fuente de ingresos, aprende finanzas personales, invierte y ahorra.


  17. La vida es un juego, la meta (Al menos para mi) es ser feliz. Busca qué te hace feliz y oriéntate en esa dirección. Para mi la felicidad es enseñar a otros lo que sé, pasar mucho pero mucho tiempo con familia y amigos y comer tacos 🌮😋.

Micro tutorial de SQLite

¿Qué es SQLite?

SQLite es un sistema de bases de datos relacionales, es una implementación «light» de un lenguaje utilizado a nivel mundial para programar y mantener bases de datos, llamado SQL (Structured Query Languaje). SQLite viene incluido en Android de manera que las apps pueden tener bases de datos privadas. SQL puede ser usado para crear, buscar y mantener bases de datos.

Este es un pequeñísimo tutorial que te ayudará en los cursos de Android completo con Java y Android completo con Kotlin, para estos no es necesario que conozcas SQL al 100%, pero si quieres un tutorial más completo te dejo este otro.

Tutorial de SQLite (Inglés)

Si quieres probarlo, sigue las siguientes instrucciones

Obtén SQLite

  1. Descarga SQLite de http://sqlite.org/download.html
  2. Abre la terminal y ve a la carpeta donde quieras guardar tu base de datos. Crea una nueva base de datos llamada emonitor.db e inicia SQLite shell escribiendo lo siguiente (SQLite shell reconocerá los comandos de SQLite):sqlite3 emonitor.db
  3. Si quieres enlistar todos los comandos escribe:
  4. .help
  5. Para enlistar todas las bases de datos:.databasesEn una app puedes tener múltiples bases de datos o, como te mencioné, una base de datos con múltiples tablas

Crea una Tabla para la base de datos (CREATE TABLE)

  1. Usa el comando CREATE TABLE para crear una tabla nueva llamada «earthquakes». Cada fila va a representar un terremoto y cada columna un parámetro de ese terremoto, vas a tener 6 columnas: ID, magnitude, place, longitude, latitude y timestamp.
  2. En el comando CREATE TABLE, cada columna es separada por comas, donde debes escribir el nombre de la columna y el tipo de dato que contendrá. También debes especificar que la columna debe ser no nula (NOT NULL). Debes especificar la columna _id como primary key y como valor de tipo entero (INTEGER PRIMARY KEY)

    CREATE TABLE earthquakes( _id INTEGER PRIMARY KEY, magnitude REAL NOT NULL, place TEXH NOT NULL, longitude TEXT NOT NULL, latitude TEXT NOT NULL, timestamp TEXT NOT NULL);Puedes ver los tipos de datos aquíNota: Las palabras de SQLite pueden ser minúsculas y también funciona, pero son mayúsculas para que sean más fáciles de leer, además de que es lo usual
  3. Lista todas las tablas con el siguiente comando y revisa que la tabla earthquakes fue creada.tables
  4. Usa el comando SELECT para retornar todas las filas en la tabla earthquakes. el símbolo * significa «todas las columnas». En este punto no se retornará nada porque la tabla está vacía. SELECT * FROM earthquakes;

Inserta Filas (INSERT)

  1. Usa el comando INSERT para insertar una fila nueva en la tabla. El siguiente comando INSERT inserta una fila en la tabla earthquakes para un terremoto con una magnitud de 4.5, a 25km SW de Lisboa, con una longitud de -105.56 y latitud de 94.21 (Estoy inventando los datos ;-)) y un timestamp del 17 de enero de 2017 a las 5:36 p.m, el _id de la fila es 1. INSERT INTO earthquakes VALUES(1,4.5,'25km SW of Lisboa','-105.56','94.21','1484631364');
  2. Consulta todas las filas de la tabla y verás la fila que acabas de insertar (En bases de datos a una consulta se le conoce comúnmente como Query por su traducción en inglés).SELECT * FROM earthquakes;
  3. Habilita los nombres de las columnas y haz el Query de nuevo..header on SELECT * FROM weather;
  4. Experimenta insertando otras 3 filas en la tabla.INSERT INTO earthquakes VALUES(2,2.1,'100km S of Hawaii','27.3','70.21','20140626');
     INSERT INTO earthquakes VALUES(3,5.5,'200km N of Tokio','105.98','54.58','20140627');
     INSERT INTO earthquakes VALUES(4,3.0,'150km E of New Zeland','-102.42','81.15','20140628');Haz un query a todas las filas para verificar que se insertaronSELECT * FROM weather;

Consulta filas (QUERY)

  1. Practica haciendo consultas (queries) donde proveas una selección con el comando WHERE para seleccionar el número de filas que serán retornadas en el resultado. No olvides el punto y coma al final de la sentencia.Este query retorna filas de la tabla earthquakes donde la columna timestamp es exactamente igual a 20140626.
    SELECT * FROM earthquakes WHERE timestamp == 20140626;
  2. Este query retorna filas de la tabla donde la columna timestamp está entre los valores 20140625 y 20140628. Sin embargo, no todas las columnas son regresadas, solo regresaremos las 4 columnas especificadas (_id, timestamp, magnitude, y place) de las filas que pasan el filtro.SELECT _id,timestamp,magnitude,place FROM earthquakes WHERE date > 20140625 AND date < 20140628;
  3. Este query retorna filas donde la magnitud mínima es mayor o igual a 3. De las filas que pasan el filtro, las ordenamos en orden incremental (ascending or “ASC”) max temperature. The first row of the result that is printed out to the command line will be the row (with min temperature >= 18) with max temperature that is lowest out of all rows, so that subsequent rows will have higher max temperature.SELECT * FROM earthquakes WHERE magnitude >= 3;

Actualizar Filas (UPDATE)

  1. También puedes actualizar filas existentes con el comando UPDATE. El siguiente comando actualiza la tabla estableciendo la latitud a 100 y la longitud a 150 cuando la fecha sea mayor a 20140626 pero menor a 20140627.UPDATE earthquakes SET latitude = 100, longitude = 150 where date >= 20140626 AND date <= 20140627;Imprime de nuevo la tabla para que veas que los valores se actualizaron!SELECT * FROM earthquakes;

Borrar Filas (DELETE)

Usa el comando DELETE para borrar filas de una tabla, de acuerdo al criterio de selección. En este caso, borraremos cualquier fila donde la magnitud sea menor a 2 

DELETE FROM earthquakes WHERE magnitude < 2;

Borrar Columnas (ALTER TABLE)

Si ya lanzaste una versión de tu aplicación para los usuarios, y decides que necesitas cambiar el esquema de la base de datos como añadir columnas, entonces necesitarás actualizar tu base de datos con el comando ALTER TABLE.

Nota: En general, no deberías alterar una tabla para borrar columnas porque estarás borrando datos y otras tablas podrían depender de esa columna. En vez de eso, establece todos los valores de esa columna a null.

Borrar Tabla (DROP TABLE)

Para borrar una tabla, utiliza el comando DROP TABLE. Verifica que ya no hay más tablas en la base de datos.

DROP TABLE earthquakes; .tables