maxidato

  Exactamente: ni vos, ni nadie, puede ver las contraseñas de los usuarios si usás Google Authentication. Y eso es intencional , por seguridad. ¿Cómo funciona? Cuando un usuario se registra con su contraseña: Firebase nunca guarda la contraseña en texto plano . En su lugar, la cifra (hash + salt) y guarda ese resultado cifrado en su sistema. Ni siquiera Google tiene acceso directo a la contraseña original. ¿Por qué es bueno que ni el administrador pueda verla? Porque: Protege a los usuarios si el sistema es hackeado. Evita problemas legales (la ley muchas veces prohíbe guardar contraseñas sin cifrado). Da confianza al usuario: sabe que su clave no la ve nadie. Lo que vos sí podés ver como administrador es: El email del usuario. Cuándo se registró o inició sesión. Su UID (identificador único). Si verificó el email, etc. Pero jamás la contraseña . ¿Querés que te diga qué podés guardar vos en la base de datos además de lo que gestiona Authentication?

 ¡Perfecto! Vamos con una explicación clara, simple y directa de Jamstack, ideal para tu enfoque de desarrollo con HTML/CSS y JSON. --- ¿Qué es Jamstack? Jamstack es una arquitectura moderna de desarrollo web que se basa en separar el frontend (interfaz de usuario) del backend (lógica de servidor) y usar tecnologías modernas para hacer sitios rápidos, seguros y fáciles de escalar. --- ¿Qué significa JAM? J = JavaScript → Usado para interactividad y lógica del sitio. A = APIs → Servicios externos o funciones que procesan datos, como formularios, comentarios, etc. M = Markup (HTML) → Contenido generado de forma estática (pre-renderizado) como archivos HTML. --- Metodología Jamstack La idea central es que el sitio se genera antes (build), en lugar de hacerlo al momento que el usuario lo visita. Ejemplo: no tenés PHP generando HTML en tiempo real, sino que ya está listo. --- Pasos básicos en un flujo Jamstack: 1. Pre-generación de contenido (build): Usás datos (como tu JSON) para gener...

  Se me ocurrio otra idea Es que al repositorio de la version web vieja la ponga como privada y le cambie el nombre asi no borro el historial Y ahora creo otro repositorio con el mismo nombre anterior de la pagina web, osea antes se llamaba portafolio que usaba esa carpeta github Pero cambie su nombre a portafolio-antiguo Entonces creo que ya tengo libre el nombre portafolio para poner mi version web nueva esto es posible? ******** ¡Sí! ¡Tu idea es excelente y totalmente posible! Estás aplicando perfectamente la lógica de GitHub. Acá te confirmo punto por punto: --- 1. Cambiar el nombre del repositorio viejo a portafolio-antiguo y hacerlo privado Esto preserva todo el historial de tu versión anterior. Nadie más podrá acceder, y vos lo tendrás guardado como referencia personal. Al cambiar el nombre, ese nombre queda libre para usar en otro repositorio. --- 2. Crear un nuevo repositorio llamado portafolio Ahora podés subir ahí tu nueva versión limpia. Si activás GitHub Pages en es...

 Bien me parece razonable copiar los archivos en un repositorio privado Osea luego borro los archivos de la version vieja del repositorio publico que se sirge github pages Pero como github es un control de versiones Todas las modificaciones quedan en el repositorio publico sobre mi web antigua? _______ ¡Excelente decisión! Hacer una copia en un repositorio privado es la mejor forma de tener tu backup sin exponerlo. Y sí, ahora viene un punto clave que entendiste perfecto: --- GitHub guarda el historial completo del repositorio, incluso si borrás archivos del repositorio público. Eso significa que: Aunque borres los archivos de la versión vieja de tu web en la rama main, Siguen estando en el historial de commits anteriores. Cualquiera puede revisar los commits viejos y ver los archivos antiguos si el repo es público. --- ¿Cómo evitar que tu versión vieja siga accesible en el historial? Si querés eliminar completamente todo rastro de esa versión (incluso del historial), tenés dos opc...

 Pero si la gente entra ami perfil de github De forma manual veran la rama nueva donde guarde mi version antigua de mi web? Buena pregunta. Acá va la respuesta clara y directa: Sí, si tu repositorio es público, cualquier persona puede ver todas las ramas. Cuando alguien entra a tu repositorio en GitHub, puede hacer clic en el menú desplegable de ramas (donde dice main o branch:) y ver todas las ramas, incluyendo v1-backup o cualquier otra que hayas creado. Pero ojo: eso no significa que sea fácil de encontrar. Si no mencionás esa rama ni la usás para GitHub Pages, la mayoría de la gente ni se va a dar cuenta de que existe. Aun así, no está realmente oculta, solo poco visible. --- ¿Querés que esté 100% oculta y solo accesible por vos? Entonces lo ideal es: Crear un nuevo repositorio privado Ahí guardás tu versión antigua, y nadie puede acceder, salvo vos (o quienes autorices). Pasos: 1. En GitHub, creá un nuevo repo privado llamado, por ejemplo, mi-web-v1-backup. 2. Subí ahí tu vers...

  ¡Genial! Acá tenés un ejemplo completo de cómo podría verse tu portafolio textual , tal como se presentaría en tu sitio o como texto de presentación en GitHub o incluso en tu propio README.md del portafolio. Voy a usar proyectos inventados pero realistas, con nombres creativos y links simulados. Después podés reemplazar los datos por los tuyos: Portafolio Web de Juan Dev ¡Hola! Soy Juan, desarrollador web enfocado en HTML y CSS puro. Me especializo en maquetación semántica, responsive design sin frameworks, y buenas prácticas de accesibilidad. A continuación te comparto algunos de mis proyectos destacados. Cada uno tiene su demo en línea y su documentación en GitHub. Proyectos 1. Sitio web de cafetería - “Café Aroma” Vista en vivo: https://juandev.github.io/cafe-aroma Repositorio con documentación: https://github.com/juandev/cafe-aroma Un diseño limpio y minimalista para una cafetería ficticia. Maquetado 100% en HTML5 y CSS3, con foco en Flexbox y diseño responsiv...

 ¡Totalmente normal! Un archivo **`README.md` largo no es problema**, siempre y esté bien estructurado. De hecho, muchos proyectos profesionales (como los de GitHub) tienen `README.md` extensos y detallados. Aquí te explico cómo manejarlo sin perder calidad: --- ### **📌 ¿Es normal que un `.md` sea largo?**   **Sí**, especialmente si documentas:   - **Contexto técnico** (cómo funciona tu paginación).   - **Instrucciones de instalación**.   - **Problemas y soluciones**.   - **Capturas o GIFs**.   Ejemplo de proyectos con `README.md` largos:   - [VS Code](https://github.com/microsoft/vscode)   - [React](https://github.com/facebook/react)   --- ### **🚦 Cuándo dividir tu documentación**   Si supera las **10 páginas**, considera:   #### **Opción 1: Un solo `README.md`**   - **Ventaja**: Todo en un lugar.   - **Recomendado** si:     - Es fácil ...