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

Hacklab: Implementando arquitectura MVP en Android con Kotlin

Hace algunas semanas anuncié una serie de mini proyectos que vamos a estar creando y que van a abordar temas muy concretos de diseño y programación, estos mini proyectos serán gratuitos y los hemos llamado Hacklabs.

En esta ocasión te presento el segundo Hacklab, en el cual aprenderás lo siguiente:

  • Qué es la arquitectura MVP (Model, View, Presenter) y las partes que la componen.
  • Cómo implementar MVP en Android con Kotlin.
  • Cómo manejar errores con MVP.

Esto lo aprenderás en una serie corta de videos también cortos. Como siempre, conciso y al grano, like a thunder ⚡️.

Decidí hacer este Hacklab porque es un tema extremadamente útil y del que te preguntan mucho en entrevistas de trabajo, pero la información que encontré (incluso en inglés) me pareció confusa, MVP puede ser complejo de entender al inicio pero una vez que le tomas el hilo es pan comido 🍞.

Sin más, te dejo aquí el primero de los videos del Hacklab y te invito a ver la lista completa en el canal de Youtube. Espero que te sirva y como siempre tus comentarios, dudas o lo que sea es bienvenido, también te invito a suscribirte al canal y al blog para recibir más contenido que te pueda servir.

Bunu: Un side project para los amantes del buen café.

Como he dicho en posts anteriores tengo 3 socios junto con los cuales creamos proyectos de todo tipo y los lanzamos para validarlos, uno de los aspectos por los que decidimos crear este equipo es que tenemos habilidades distintas y complementarias, pero algo que los 4 tenemos en común es que amamos el café, en lo personal tomo dos tazas diarias ☕️🤩.

Este año comenzamos con un nuevo proceso para lanzar productos, cuidamos que los productos que desarrollemos sean a la vez útiles para nosotros y divertidos de crear, y en la primera lluvia de ideas nos decidimos por Bunu.

Un problema que tenemos los que amamos el café es quedarnos sin el, podemos pedirlo o ir al supermercado pero normalmente lo tomamos en la mañana y lo necesitamos para el desayuno o para antes de ir al trabajo, además de que muchas veces conseguir un café de calidad no es tan sencillo si no hay cafés de especialidad cerca de tu casa, y menos sencillo si quieres conocer nuevas variedades. Lo sé, no es un problema de vida o muerte, es un problema más bien de nicho, pero creemos que es lo suficientemente importante para los que de verdad les gusta el buen café.

Es por eso que empezamos a crear Bunu, un servicio para que jamás te quedes sin café. Funciona de la siguiente manera: En nuestra página web podrás elegir el café que más te guste, tal como lo necesitas: Tipo de tueste, marca, tipo de molienda, etc. Y te lo enviaremos directamente a tu casa, pero eso no es todo, junto con tu primer pedido también adquirirás una base inteligente, coloca tu bolsa de café sobre la base inteligente y esta “sabrá” cuando te estés quedando sin café y nos notificará para enviarte otra bolsa y que te llegue justo a tiempo, así siempre tendrás café fresco y delicioso.

Estamos muy contentos con este proyecto, sobre todo porque resuelve un problema que tenemos y en el proceso nos hará aprender muchas cosas tanto técnicas como Internet of Things e inteligencia artificial, y por supuesto también soft skills, como ventas y más sobre este apasionante mundo del café. Estaré contando más sobre el proceso y cómo nos va en próximos posts.

Muy pronto tendremos la fase Beta del proyecto, si te interesa saber más y ser de los primeros en enterarte cuando esté disponible te invito a suscribirte con el siguiente botón.

Como ordenar los packages de tus apps (Package by features, not layers)

Esta es la manera que me ha funcionado mejor para ordenar las carpetas (Packages) de mis aplicaciones, en especial en Android pero también en otros lenguajes y frameworks como Django y NodeJs. La manera es el siguiente: Ordena tus packages por características, no por capas.

Vamos a verlo con un ejemplo.

Supongamos que tienes una app de Android que tiene 3 pantallas: Main, Details y Settings, además de que trae información de internet. Al ordenar por capas, los packages de tu app se verían algo así.

  • Activities
  • ViewModels
  • Repositories.
  • Services.

Ahora, si ordenamos la misma app por características, se verá algo así:

  • Main
  • Details
  • Settings
  • Api

Ahora, en la programación interviene mucho el feeling y no hay respuestas correctas o incorrectas, pero la forma que más me ha funcionado a mí es la segunda. Esta forma me permite detectar más rápido qué clases se relacionan entre sí, buscar errores y hacer debug de manera más fácil, en especial cuando la aplicación crece mucho.

Otra cosa que me funciona es usar un modelo híbrido de ambos cuando las apps se vuelven más complejas, veamos el siguiente ejemplo, este es de una app que tengo llamada Todogs, estoy agregando una pantalla de perfil donde podrás agregar perfiles de tus perros para llevar registro de sus vacunas, entre otras cosas. En este caso creé un package “profile”, pero como dentro de este package necesito varias pantallas: Ver, crear, enlistar, editar, lo puse de esta manera.

Cómo puedes ver en este caso tengo una carpeta “Profile”. Como tengo perfil de persona y perfil de perro creé una subcarpeta dogProfile, dentro de ella tengo las clases necesarias para los perfiles de los perros, pero aparte, como cada acción (Crear, editar, enlistar) necesita su propia pantalla, ViewModel, etc. creé una sub-sub-carpeta para cada una de ellas, de esta manera tengo todo bien estructurado, lo cual lo hace fácil y rápido de encontrar.

¿Qué opinas de esta manera de acomodar todo? Tus comentarios y feedback son más que bienvenidos como siempre, no olvides suscribirte al blog, a las redes sociales, a mi canal de Youtube, a los cursos y a todo lo que quieras para seguir aprendiendo más sobre diseño, programación y emprendimiento.

Aprende a cambiar el idioma en SolidWorks

Normalmente cambiar el idioma en un programa es una tarea que resulta sencilla, simplemente vamos a las opciones y al apartado de idiomas y desde ahí podemos seleccionar el que necesitemos.

En SolidWorks esta tarea se vuelve en ocasiones complicada, principalmente porque en el menú de opciones no hay una sección dedicada exclusivamente al lenguaje.

Si todo está configurado correctamente tienes que hacer clic en el engrande de opciones y te aparecerá la siguiente ventana:

Las dos opciones marcadas tienen que estar desactivadas para tener SolidWorks en español.

En occasions estas opciones están deshabilitadas, provocando que no podamos cambiar el idioma, eso puede ser debido a que la región de tu computadora no está configurada correctamente o que el paquete de idiomas no esté instalado. En el siguiente video te explicamos paso a paso cómo solucionarlo.

Suscríbete al canal de Hackaprende 3D para mas contenido así

Hacklabs: La nueva manera de aprender con Hackaprende

Muchas veces ya conocemos un lenguaje, un framework o una tecnología y sabemos usar al menos sus partes principales, pero necesitamos aprender a implementar algo concreto. Un ejemplo es que ya sepamos programar en Android pero nunca se nos había presentado el problema de crear una lista que tenga secciones.

El problema es que no sabemos por dónde buscar. Claro, siempre está StackOverflow, pero muchas veces no ahonda lo suficiente, también podemos buscar un curso pero en primer lugar no necesitamos todo un curso, solo saber cómo implementar la lista, y en segundo lugar, no sabemos si el curso incluye realmente lo que necesitamos saber.

Es por eso que decidí empezar a crear una nueva sección en mi canal de Youtube, la llamo Hacklabs. Cada Hacklab es una serie de videos, como siempre cortos y al grano, que te enseñarán una habilidad, una herramienta, una librería, etc. como el ejemplo de arriba, con lo que al terminar serás un experto en ese tema específico. La duración dependerá del Hacklab pero trataré de ser lo más conciso posible sin dejar fuera nada importante para que aprendas bien y cuanto antes.

Así que sin más te presento el primero de ellos 🥳, por supuesto el del ejemplo de arriba 😁. A continuación te dejo el primer video y aquí puedes ver el Hacklab completo: RecyclerView (Expandible) con grupos en Android con Kotlin, construyendo un Tiny Netflix.

Si tienes algún tema que te gustaría aprender no dudes en dejarlo en los comentarios para agregarlo a la lista de ideas, también te invito a suscribirte al blog y al canal en caso de que no lo hayas hecho para recibir el contenido que vayamos subiendo.

Nuevo año, nuevos proyectos: Experimentando con un nuevo proceso.

Quienes me conocen saben que me apasiona el emprendimiento, llevo algunos años intentándolo, algunas veces logrando cosas geniales y en la mayoría productos que nunca ven la luz o que simplemente no “pegan” 😁, pero en todos los casos aprendiendo mucho.

Hace un par de años me asocié con 3 grandes amigos con diferentes habilidades y empezamos a construir cosas entre los 4, aunque el año 2020 si fue algo difícil, para ser sincero si nos detuvo un poco (O más bien un mucho) a seguir construyendo. Sé que el cambio de año no es más que una vuelta al sol, pero es un pretexto para renovar energías y empezar con todo, así que decidimos “ponernos las pilas” e idear un plan para que este año desarrollemos cosas muy geniales.

TL;DR -> La idea en resumen es la siguiente: Vamos a proponer ideas, seleccionar una de ellas y desarrollarla muy rápidamente para lanzar un MVP en máximo 3 meses, luego dar otros 3 meses para vender y promover la idea y así poder validar si es buena o no. Mientras la idea es validada, empezaremos con la siguiente. El punto es probar tantas ideas como sea posible sin que cada una de ellas nos lleve mucho tiempo.

Este es el proceso que definimos, está basado en el libro de Make: The bootstrapper’s handbook, de Pieter Levels, aunque con algunas adecuaciones hacia nuestra forma de trabajar.

  1. Lluvia de ideas:
    Un viernes hacemos una videollamada con lluvia de ideas que hayamos pensado cada quien, de ahí debe salir una idea que será la siguiente por hacer.
  2. Sprint con idea seleccionada:
    El siguiente lunes empezamos con todo a darle a la idea con un Sprint, del cual obtendremos un prototipo súper rápidamente y lo probamos. Eso nos dará muy buena retroalimentación de si es factible, si se puede hacer, si es buena idea o no. El viernes de esa misma semana lo sabremos y decidiremos si continuar o mejor empezamos con otra idea.
  3. Desarrollo:
    Si la idea pasa el Sprint, desarrollamos por un máximo de 3 meses. Aquí también comenzamos a hacer ruido en redes sociales para encontrar a quién le pueda ser útil el producto, de esta manera para cuando el producto esté terminado ya tendremos una comunidad con quien compartir.
  4. Lanzamiento:
    Lanzamos un MVP libre de bugs cañones en redes sociales y plataformas como Product Hunt, Reddit, Hacker news, etc.
  5. Medición de reacciones de lleno:
    Aquí mientras nos dedicamos a seguir promoviendo volvemos al paso 1, mientras se desarrolla la siguiente idea una persona se dedica al 100% a seguir promoviendo y midiendo reacciones con la idea anterior. Esto dura otros 3 meses.
  6. Evaluamos resultados de la idea:
    Evaluamos la idea de acuerdo a si tiene potencial o no:
    – Si vemos que no va por ningún rumbo la apagamos.
    – Si vemos que tiene mucho potencial invertimos más tiempo, puede ser que hasta tiempo completo.
    – Si vemos que es un posible generador de ingresos pero no como para dedicarle tiempo completo la dejamos pero para que solo genere ingresos residuales y solo damos mantenimiento en caso de necesitarlo.
  7. Se termina ciclo de idea 1, continúa idea 2 y empieza idea 3.

El proceso se resume en este diagrama:

Por supuesto que no todos los proyectos se pueden hacer de esta manera, hay proyectos que necesitan un ciclo más largo para ser probados, es por ello que decidimos acotar nuestros proyectos a estos puntos.

Los proyectos deben tener estas características:

  1. Fáciles y rápidos de hacer con lo que sabemos o necesitemos aprender: Máximo 3 meses de desarrollo para tener algo funcional que sea lanzable al mercado.
  1. Orientados a que sea un negocio rentable y monetizables desde un inicio o, si necesitan tiempo para empezar a ser monetizables, que en ese tiempo no nos esté costando dinero ni mucho tiempo de nuestra parte.
  1. Escalables digitalmente: Que puedan tener muchos usuarios y obtenerlos de forma puramente o al menos mayormente digital, sin tener que estar yendo a visitar clientes físicamente.
  2. Si es un producto B2B, que tenga un ciclo de venta rápido: Es decir que las puedas comprar en un clic, sin que tengan que llevar la decisión de semanas a sus jefes o dueños de la empresa.

Por si te lo preguntas no, no sabemos si este proceso va a resultar en algo 😅. Es un experimento que se ajusta a la forma en que nos gusta trabajar, al tiempo que tenemos y a nuestras habilidades, también creemos que se irá modificando con el tiempo conforme a las experiencias que tomemos. Lo que sí sabemos es que vamos a aprender bastante, que este proceso nos ayudará a entrar en acción y que será un año divertido, así que ¡A darle!.

¿Qué opinas de este proceso? ¿Crees que es bueno o se te ocurre algo mejor? Toda la retroalimentación es bienvenida.