El problema es más serio de lo que parece, y merece la pena reflexionar sobre él. Montamos sistemas distribuidos, autoescalables, lo que queramos.... que dependen para aprovisionarse de un punto único de fallo. Si tienes una configuración de autoescalado y te llega un arreón de tráfico, que no te pille GitHub por los suelos, o tus máquinas igual empiezan a aparecer con una versión antigua del software.
Ahora bien, también merece la pena reflexiona sobre la contingencia y su solución, que igual te añade una complejidad que no merece la pena para una incidencia que sucede de higos a brevas.
Por aquí ya está funcionando de nuevo. Pero sí, un GitHub caído a día de hoy durante mucho tiempo es algo que resultaría en un impacto mucho mayor del que mucha gente se cree. Por ejemplo, hoy quería estudiar un proyecto alojado allí y si no estuviera up de nuevo me habría quedado de brazos cruzados...
#16 Hace tiempo bitbucket nos hizo una jugada parecida (en realidad lleva varias) y nos vimos con una mano delante y otra detrás en un momento jodido con una aplicación en producción que no podíamos actualizar. Decidimos desarrollar un plan b para estos caso, un deploy basado en un script de fabric que hiciera un upload del codigo fuente en la maquina local hacia la remota, para no depender exclusivamente del pull en el repo remoto.
Y si, cuando te suceden estas cosas la palabra "descentralizado" la puedes usar de papel del vater.
#17 no creo que tenga el día para conversar pero sería muy interesante que nos contará los que o los porque y como correr en circulo con los brazos en alto
Yo para los proyectos privados uso un gitlab que montamos en la empresa en un contenedor con docker. Nada que envidiar a github. Para los públicos los tengo por duplicado en los dos sitios.
#16 En realidad si trabajas en un programa con git, sí que puedes trabajar aunque el servidor esté caído. Lo que no podrás hacer será enviar tus cambios o descargar los cambios que haya hecho otro.
#29 Podría ser otra posibilidad y seguro hay más, pero donde añades ese remote? te lo montas tú o pagas un privado de github? Usamos fabric para otras cosas así que esta solución era sencilla de llevar a cabo sin tener que lidiar con otros servicios de terceros.
#27 ¿ Desde cuando usar absolutamente todas las herramientas open source es un requisito para desarrollar código libre ? Muchos de grandes desarrolladores de software libre usan mac, como el creador de Gnome.
#16 lo de 'igual tus servidores aparecen con una versión antigua del software' me ha matado. Hemos entendido que es Github? Porque ninguna aplicación se conecta a Github en tiempo de ejecución para descargar una librería. Lo peor que te puede pasar como dice #31 es que no puedas hacer pull/push, pero puedes seguir trabajando, que para algo es descentralizado.
#27 desde que mac es Unix, es más cómodo desarrollar en mac que en Linux, y años luz que en Windows. Tanto en la nube, cómo en local, como en virtual. Y hace mucho ya que es Unix. He probado mucho las 3 plataformas, y Mac gana con diferencia.
(Por cierto, por si no lo sabes, que sea Unix implica que puedes hacer pracricamente lo mismo por consola en Mac que en Linux en lo que a entorno de desarrollo se refiere).
#9 Un ordenador que no tienes que mantener, que mantiene gente muy especializada en ello, y mucho más barato por que el precio se comparte entre los diferentes clientes.
#16 si el mismo problema te ocurre en local, muy dificilmente te saldrá más barato y rápido arreglarlo. El problema es que incluso muchas empresas grandes no tienen un plan B para cuando cae
#13 Pues no es de lo más bárbaro que he oído/leído, mira a #19 con su "deploy basado en un script de fabric que hiciera un upload" ¡Anglicismos, anglicismos everywhere!
#48 Para poder seguir trabajando, nosotros tenemos nuestro propio servidor de GIT, con backups y demas.
Eso de que saben hacerlo mucho mejor que yo... saben mantener SUS ENTORNOS mejor que yo, pero si me monto lo mio propio seguro que sabre yo mejor mantenerlo que ellos.
#40 Colaboro en un proyecto open source, y de lejos, el mas coñazo es OSX, despues la cosa varia entre algunos linux (archlinux) y Windows y el mas facil los linux basados en debian (mientras no quieras usar clang en ubuntu 15.10).
Eso si, para programar, donde este el Visual Studio que se quiten los demas IDEs.
#43 Gente muy especializada en ello... ains que me parto.
Normalmente una empresa compra el "software" para montar una cloud. Cuando falla la cloud, esta empresa tiene que "abrir ticket" con el soporte del fabricante y pasar los niveles de soporte 1 y 2 para que te atienda alguien que sabe de lo que le estás hablando y que su solucion no sea: "apague y encienda el router o reinicie su computadora".
Es lo que da la ignorancia (no te estoy llamando ignorante, no van por ahi los tiros), pero en todas las casas cuecen habas.
#57 Hombre, si contratas una empresa de mierda, pues recibes mierda. Github no es precisamente una empresa de mierda, y responde muy bien. Llevo años trabajando en una conocida eshop internacional con más de 60 developers en sus oficinas de Barcelona y bien considerada en el mundillo dev. Y tenemos nuestro código en github, e intentamos externalizar todo lo que sea infrastructura. Y nos va mejor desde que lo hacemos así. No te hablo desde la ignorancia.
Ahora mismo no tengo claro cuánto estoy autorizado a comentar (todo pasó mientras yo dormía y no estaba yo de guardia, así que me estoy poniendo al día de la situación) pero ya estamos recuperados casi al 100%. Imagino que habrá un post-mortem oficial a lo largo del día, ya lo enlazaré por aquí cuando se publique.
Yo te cuento por qué creo que es mejor para un dev.
- Tienes el sistema listo para trabajar en una hora aprox con sencillos pasos a traves de consola (incluyendo IDEs, BDD, herramientas de consola, entornos virtuales...).
- En todas las puestas a punto del entorno que he hecho en mac todo ha funcionado a la primera (en linux era más bien lo contrario, y no hable de hace mucho).
- Las actualizaciones de Mac dificilmente dan problemas.
-Es mucho más rápido que un Linux, y desarrollando proyectos grandes con un IDE con analizador de código automático, se nota y mucho.
Se me ocurren estas de momento. Linux esta muy bien, y IOS se basa eb Unix como él, pero para un desarrollador no es ni de lejos la opción más eficiente. La más barata si. La más "libre" si. Pero no aporta el mismo valor al negocio de la empresa.
Y repito, no soy un fanboy Mac, he trabajado mucho en Linux y estaba convencido de que era lo mejor, hasta que prpbé Mac y vi como mi eficiencia crecía exponencialmente.
#52 A mí Eclipse me da todo lo que necesito en Java y Python, y apostaría a que en C++ también. En mi curro la gente se tira los trastos a la cabeza por que unos usan VS 2008 y otros 2013.
#51 Primero, es lo suyo mantener un servidor propio como plan B, eso ya lo he dicho antes, hacéis lo correcto (en mi opinión, en la de mi CEO, no merece la pena la inversión).
Segundo, claro que no sabrán mantener tus sistemas mejor que tu, pero estoy bastante convencido de que saben mantener bastante mejor sus servidores que tu los tuyos. Y no digo que tu los mantengas mal.
#59 lo que dice #57 es verdad. Incluso con ProSupport en empresas como Dell o HP, tienes que perder el tiempo haciendo comprobaciones rutinarias para que eleven la incidencia a ingeniería y no te pidan que apagues y enciendas. Incluso cuando llamamos desde sistemas nos toman por lelos.
#66 para nada. Simplemente me ha resultado curioso lo de "Mac es el más coñazo", así por que si. Me interesa saber qué razones tiene para pensar lo contrario que todos los devs que conozco.
#16 De todas maneras GitHub es centralizado, pero la filosofía de Git no. Lo suyo es que trabajes sobre tus copias locales y "ya si eso" mandes los cambios a un repo remoto. Esto no es subversion.
#70 no te puedo decir porque no desarrollo en Mac, pero como usuario de Debian por más de 10 años, te diré que para programar, en el caso más sencillo, solo tengo que hacer un "sudo apt-get install eclipse-cdt build-essential", y aquí los que se pegan para dejar funcionando un compilador son mis compañeros que no salen de Win7
#70 El tener que dar soporte a 100s de personas y los que mas problemas porcentualmente al numero de usuarios han tenido en el proyecto en el colaboro han sido los de *BSD y despues los de OSX.
#72 No se, yo no veo la dificultad en dejar funcionando Visual Studio, otra cosa es que un proyecto requiera X o Y librerias y quieran usar Visual Studio Express teniendo Visual Studio Community totalmente gratis.
Ya ha vuelto. Qué Github esté caído es algo irrelevantísimo, ya que siempre podemos seguir trabajando con nuestro repositorio local, as usual. Y cuando vuelva el servicio, subimos los cambios y punto. As usual.
#53 Por eso solo usamos paquetes. Si el paquete no existe, lo creamos. Y se guarda en un repositorio privado que nosotros controlamos. Tambien es una buena practica tener todo esto documentado y usar 'baselines' para definir versiones de la combinacion de SO + middleware + aplicacion, y luego las configuraciones aparte, con algun gestor de configuraciones.
Que sea opensource o no es irrelevante. Es simplamente una buena practica, en mi opinion.
Desde Gitlab, cuando un proyecto esta listo para ser liberado, siempre se puede hacer el repositorio publico. Todo es cuestion de visibilidad y luego de que capacidad tengas.Incluso tal vez algunas cosas se pueden poner en github, pero nunca nada de lo que dependan tus operaciones deberia ser gestionado por terceros, salvo que las garantias sean muy altas y con contrato, y asumiendo el posible riesgo y si es posible tener un plan para mitigarlo.
Aviso, tenemos que hacer algunas operaciones de mantenimiento dentro de poco. Esperamos que no haya otra caída del servicio, pero ahora puede ser un buen momento para que todos los que lo necesitéis hagáis pull y push
#35 No es un requisito, naturalmente, pero sería ser más consecuente porque si sólo apoyas el soft, pero no el sistema operativo ni el hardware (esto es mucho más dificil), pues la libertad es más reducida ¿no?
#89 No te voy a negar que se puede ver como dices, pero creo que olvidamos que en la realidad tenemos que vivir con todo tipo de contradicciones y en cierta forma eso es lo que nos hace humanos.
Tampoco creo que sea mejor o peor, no llevar una ideología hasta las últimas consecuencias, al final tendrías que vivir como stallman.
#48 No te tomes a mal este comentario, no olvides que estás contestando a alguien que te dice "ventajas y desventajas". Y es exactamente eso, ganas algo pero pierdes en otras cosas...
Sobre que las ventajas sean más importantes que las desventajas es algo que cada uno debe evaluar en cada situación particular. Me parece importante resaltar que es verdad, con la nube pierdes muchas cosas, y eso hay que tenelo presente.
¿para qué quieres controlarlo? A ti que te importa, cada uno tiene sus necesidades.
#59 Tampoco estoy de acuerdo, mientras más grande eres más tienes que estandarizar procedimientos internos. Tampoco digo que no sea mejor, pero vamos, ya digo en otro comentario que estoy muy deacuerdo en que es un tema de compromisos y de qué necesitas.
![GitHub caido. Los desarrolladores de todo el mundo declaran hoy dia de nieve.[ENG]](https://peta.meneame.net/backend/media?type=link&id=2553981&version=0&ts=1453944966&image.jpeg)
De todas formas, mil gracias al proyecto, desde luego. Sólo ha estado caido como media hora desde que se colgó la noticia.
Ahora bien, también merece la pena reflexiona sobre la contingencia y su solución, que igual te añade una complejidad que no merece la pena para una incidencia que sucede de higos a brevas.
Y si, cuando te suceden estas cosas la palabra "descentralizado" la puedes usar de papel del vater.
Nunca es tarde para aprender esa valiosa lección.
Practicamente todo lo que usamos lo hospedmos nosotros mismos, en nuestros servidores.
[02:20:29] <ccrs> gyazo.com/240069c4d087934d8a02dd29dfa94087
Edito: por lo que veo puede ser de 2 a 5?
status.github.com
i.imgur.com/6IwYkcI.png
(Por cierto, por si no lo sabes, que sea Unix implica que puedes hacer pracricamente lo mismo por consola en Mac que en Linux en lo que a entorno de desarrollo se refiere).
Ventajas y desventajas, como siempre.
ctrld.blogspot.com.es/2006/05/breviario-de-spanglish-tcnico.html
Quiero decir, claro que son ventajas y desventajas, pero en este caso las ventajas son mucho más importantes que las desventajas.
Comparto en github.
Eso de que saben hacerlo mucho mejor que yo... saben mantener SUS ENTORNOS mejor que yo, pero si me monto lo mio propio seguro que sabre yo mejor mantenerlo que ellos.
Eso si, para programar, donde este el Visual Studio que se quiten los demas IDEs.
Aún así, que github se caiga es un problema. Por ejemplo, no puedes actualizar las dependencias de un proyecto symfony o similar.
www.wordreference.com/es/translation.asp?tranword=snow day
Normalmente una empresa compra el "software" para montar una cloud. Cuando falla la cloud, esta empresa tiene que "abrir ticket" con el soporte del fabricante y pasar los niveles de soporte 1 y 2 para que te atienda alguien que sabe de lo que le estás hablando y que su solucion no sea: "apague y encienda el router o reinicie su computadora".
Es lo que da la ignorancia (no te estoy llamando ignorante, no van por ahi los tiros), pero en todas las casas cuecen habas.
P.D. los 29 votos a favor son de hipsters
Ahora mismo no tengo claro cuánto estoy autorizado a comentar (todo pasó mientras yo dormía y no estaba yo de guardia, así que me estoy poniendo al día de la situación) pero ya estamos recuperados casi al 100%. Imagino que habrá un post-mortem oficial a lo largo del día, ya lo enlazaré por aquí cuando se publique.
Yo te cuento por qué creo que es mejor para un dev.
- Tienes el sistema listo para trabajar en una hora aprox con sencillos pasos a traves de consola (incluyendo IDEs, BDD, herramientas de consola, entornos virtuales...).
- En todas las puestas a punto del entorno que he hecho en mac todo ha funcionado a la primera (en linux era más bien lo contrario, y no hable de hace mucho).
- Las actualizaciones de Mac dificilmente dan problemas.
-Es mucho más rápido que un Linux, y desarrollando proyectos grandes con un IDE con analizador de código automático, se nota y mucho.
Se me ocurren estas de momento. Linux esta muy bien, y IOS se basa eb Unix como él, pero para un desarrollador no es ni de lejos la opción más eficiente. La más barata si. La más "libre" si. Pero no aporta el mismo valor al negocio de la empresa.
Y repito, no soy un fanboy Mac, he trabajado mucho en Linux y estaba convencido de que era lo mejor, hasta que prpbé Mac y vi como mi eficiencia crecía exponencialmente.
Segundo, claro que no sabrán mantener tus sistemas mejor que tu, pero estoy bastante convencido de que saben mantener bastante mejor sus servidores que tu los tuyos. Y no digo que tu los mantengas mal.
trinitycore.atlassian.net/wiki/display/tc/Requirements + trinitycore.atlassian.net/wiki/display/tc/Core+Installation
Voto irrelevantísima.
Que sea opensource o no es irrelevante. Es simplamente una buena practica, en mi opinion.
Desde Gitlab, cuando un proyecto esta listo para ser liberado, siempre se puede hacer el repositorio publico. Todo es cuestion de visibilidad y luego de que capacidad tengas.Incluso tal vez algunas cosas se pueden poner en github, pero nunca nada de lo que dependan tus operaciones deberia ser gestionado por terceros, salvo que las garantias sean muy altas y con contrato, y asumiendo el posible riesgo y si es posible tener un plan para mitigarlo.
Tampoco creo que sea mejor o peor, no llevar una ideología hasta las últimas consecuencias, al final tendrías que vivir como stallman.
Sobre que las ventajas sean más importantes que las desventajas es algo que cada uno debe evaluar en cada situación particular. Me parece importante resaltar que es verdad, con la nube pierdes muchas cosas, y eso hay que tenelo presente.
¿para qué quieres controlarlo? A ti que te importa, cada uno tiene sus necesidades.