Portada
mis comunidades
otras secciones
#7 Obviamente, pensaba en el recurso lógico del sol. En Sevilla, donde vivo, la compañía municipal de autobuses tiene un enorme sistema de paneles solares que se utiliza sólo para dar sombra a los autobuses estacionados y protegerlos de la violencia del sol de este lugar. Que to sepa, una de las ciudades con más sol de España y con una gran instalación preparada para eso, no tiene ningún autobús eléctrico y mucho menos que se propulse con la energía más abundante en la ciudad: el sol.
No sé si se entiende mejor así.
¿Cuantos fabricantes fabrican autobuses electricos aparte de volvo?
¿Cuanto es la parte de instalar los sistemas de carga de los autobuses en la ciudad?
Relacionado
Así es el cargador gigante capaz de recargar autobuses eléctricos en 3 minutos
Así es el cargador gigante capaz de recargar autobuses eléctricos en 3 minutos
#31: Lo del asfalto es que los autobuses estropean el asfalto más que los coches. Se puede ver bien en las marcas viales, que a menudo aparecen distorsionadas, hay crestas longitudinales en el asfalto... y si hay alguna alcantarilla suele acabar habiendo algún bache alrededor. Todo esto es lo que más o menos suelo ver en mi ciudad.
Aquí se puede ver una rugosidad:
https://www.google.es/maps/@41.645075,-4.73354,3a,29.6y,205.26h,73.27t/data=!3m4!1e1!3m2!1sNhhbRpIfovwO3hogevFGoQ!2e0?hl=es
El desgaste del asfalto es a la cuarta potencia del peso que sostiene cada rueda, luego un aumento pequeño del peso se convierte en un efecto bastante mayor en el asfalto. No es ningún rollo, es un presupuesto que hay que tener en cuenta cuando se usan autobuses.
¿Qué ciudades están construyendo tranvias? Creo que les deberían decir que paren los planes inmediatamente.
Menos mal que en Barcelona o Valencia (entre muchas ciudades) no te hicieron caso.
Lo de poner autobuses o tranvías no es cuestión de gustos, sino de cada caso, si una ciudad tiene medio millón de habitantes (caso del envío) puede que sea mejor el tranvía, dependiendo del trazado urbano, calles, presupuesto... Por eso digo que es mejor poner el ahorro para una ciudad más pequeña, donde seguramente sólo haya autobuses.
Esto es como las impresoras, si en una oficina imprimes una hoja de media al día, te vale una impresora barata, si imprimes 2000 te interesa buscar algo que a la larga sea barato. Si quiero ofrecer un sistema de alimentación de tinta continua, no es una buena idea basar el ahorro en 2000 páginas al día, sino en una cantidad más moderada. Eso es lo que trataba de decir, ni más ni menos.
#32 Pero entiendo que los autobuses ya circulan por un montón de ciudades (los normales, no los electricos) desgastando asfalto y todo. Y que la construcción de una infraestructura de tranvia y el coste de los propios tranvías supera con mucho mucho a incluso asfaltar muchas veces las calles por las que pasan los autobuses y desgastan el asfalto.
#34 Pero es un poco como lo de las placas solares fv que eran "muy" caras en la época del incentivo a las renovables de la epoca de Zapatero y después debieron bajar de forma significativa.
Por eso realizaba la pregunta de la previsible bajada de precio de estos autobuses.
Tranvias que ya están construidos vale. Pero para la planificación de construcción de nuevos tranvias y lineas adicionales de tranvia habrá que tenerlo en cuenta muchísimo mas.
Sigo pensando que los "trenes" de los tranvias deben ser mucho pero muchísimo mas caros que incluso esos autobuses electricos de volvo.
Después para una posible, futura y previsible automatización de la conducción de estos vehiculos será mas fácil en los tranvias. Ya hay lineas de metro automaticas no sé en cuantos sitios.
Menuda puta mierda, la verdad. ¿Se supone que eso es un coche? Parece que regalan el carné de pintamonas en cualquier parte.
Pues varias preguntas:
- He visto que CartoDB está hecho con Ruby y JavaScript. ¿Qué ventajas e inconvenientes habéis encontrado al usar estos lenguajes? ¿Habéis tenido algún problema de escalabilidad debido a usar Ruby? La wikipedia dice que el backend está en Node.js, pero en GitHub, mirando por encima, yo veo Ruby.
- Al ser un proyecto de software libre, supongo que habréis visto como es usado para cosas bastante variopintas. ¿Cuál es el proyecto que más os ha llamado la atención?
#9
-Como dices CartoDB utiliza varios lenguajes de programación. Node.js lo utilizamos para las APIs (https://github.com/CartoDB/Windshaft) y como bien has dicho Ruby para el backend de la aplicación. Algún problema nos hemos encontrado por el camino, pero nada que nos bloqueara por completo.
- Mis proyectos favoritos siempre son los que tienen que ver con ciencia y simulaciones. Una de las cosas mas interesantes de los mapas es poder situarte en un lugar en el que no estás, en un momento en el que no estuviste. Por ejemplo este mapa en el que se simula el escape de Alcatraz de 1962 (https://cartodb.com/gallery/alcatraz-escapees/), este en el que detectamos deforestación en casi tiempo real (http://www.globalforestwatch.org/) o este sobre migración de especies (http://lifewatch.inbo.be/blog/posts/forward-trajectory-visualizations.html)
#67 ¿Teneis algún proyecto para detectar fuegos forestareles en tiempo real? Creo que es algo necesario, pero la verdad es que no tengo ni idea de si vuestra tecnología se puede aplicar a este campo.
Gracias
#213 No es ningún agujero de seguridad. Tienes un control absoluto sobre lo que se publica o no. Si decides tomar una decisión de diseño absurda (poner permisos de acceso en la parte pública del documento del usuario), sí, alguien podría modificarlo. Oh, sorpresa. Es más, esa parte del documento es opcional. Acabo de comprobar que mis cuentas de usuario no la tienen y es imposible hacer ningún cambio. Y no es algo de lo que me haya tenido que preocupar, básicamente por no ser subnormal.
Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así.
Que me parece muy bien que a ti no te gusta y prefieras Strongloop (que es al menos un orden de magnitud menos popular que Meteor, que está muy, pero muy bien financiado para ser un proyecto de software libre: http://techcrunch.com/2015/05/19/meteor-raises-20m-to-build-the-one-javascript-stack-to-rule-them-all/) me alegro por ti.
#216 "Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así."
No. De hecho, en un proyecto de trabajo, decidí rechazar Meteor en conjunto con el equipo por otras alternativas.
He trabajado en aplicaciones interactivas muy tochas y potentes y no he tenido que tocar Meteor.
Ah, y ni el consenso popular ni ponerle mucha a pasta a algo lo hacen bueno. Véase: mucho de Microsoft
#178 Sobre lo del XSS, que sí que es (o era, efectivamente) un problema de seguridad para el que tenías que instalar un módulo:
Esto es lo que dice Strongloops: https://docs.strongloop.com/display/public/LB/Security+considerations
Que instales un paquete de NPM. Guau, menuda mejora sobre Meteor, ¿eh?
#178 Por partes:
- Uf, vamos. Menudo "agujero" de seguridad. Que lo mencione en la documentación varias veces que es así por diseño, nada.
- De hace más de un año, antes de que hubiera salido la versión 1 y estuviera listo para producción.
- "La instalación de serie es insegura". Mencionar eso como un problema de seguridad me parece de traca ya, vamos Como si alguien fuera a hacer una aplicación comercial y no utilizar un sistema de publicaciones y subscripciones. Es un paquete que viene habilitado para el prototipado y poco más. Y, de nuevo, explícitamente mencionado en la documentación. De hecho, si despliegas la aplicación te ADVIERTE de que el paquete está activo y no deberías desplegar públicamente la aplicación con ese paquete. ¿Qué problema hay?
En cuando a lo que dices de cliente y servidor... En Meteor tienes código de cliente y código de servidor. Lo que te facilita Meteor es el desarrollo de aplicaciones interactivas mediante el uso de websockets. A lo mejor no tienes necesidad de tiempo real en tu aplicación. O quieres algo más estático. Bien, pues no uses Meteor. Pero no es muy diferente a usar Node.js para hacer una API y comunicarse con el cliente mediante websockets. De hecho, otros frameworks (como Rails 5.0) están intentando ofrecer algo parecido.
#183 Meter fallos de seguridad por diseño /// Es un problema. Que tengas tú que manejar esas cosas en un FW, cuando si usas un FW es precisamente para no tener ese tipo de problemas.
Si tengo necesidad de una aplicación interactiva, lo que haré será montar un servidor a pelo con ES6 y babel y el cliente pues ya vería, seguramente con React y unos cuantos componentes extra.
Sobre Strongloop, sencillamente se usa más para servidor, se está extendiendo y mejorando, tiene detrás comunidad y empresas, por lo que va a ser el FW recomendable.
Pero vamos, que esto es a título personal, usa lo que te dé la gana.
#213 No es ningún agujero de seguridad. Tienes un control absoluto sobre lo que se publica o no. Si decides tomar una decisión de diseño absurda (poner permisos de acceso en la parte pública del documento del usuario), sí, alguien podría modificarlo. Oh, sorpresa. Es más, esa parte del documento es opcional. Acabo de comprobar que mis cuentas de usuario no la tienen y es imposible hacer ningún cambio. Y no es algo de lo que me haya tenido que preocupar, básicamente por no ser subnormal.
Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así.
Que me parece muy bien que a ti no te gusta y prefieras Strongloop (que es al menos un orden de magnitud menos popular que Meteor, que está muy, pero muy bien financiado para ser un proyecto de software libre: http://techcrunch.com/2015/05/19/meteor-raises-20m-to-build-the-one-javascript-stack-to-rule-them-all/) me alegro por ti.
#216 "Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así."
No. De hecho, en un proyecto de trabajo, decidí rechazar Meteor en conjunto con el equipo por otras alternativas.
He trabajado en aplicaciones interactivas muy tochas y potentes y no he tenido que tocar Meteor.
Ah, y ni el consenso popular ni ponerle mucha a pasta a algo lo hacen bueno. Véase: mucho de Microsoft
#174 " cuando han de ir separados" Porque tú lo digas. ¿Qué carencias y fallos de seguridad tiene, según tú? Sospecho que no sabes muy bien de lo que hablas.
Angular lo menciono porque es popular, simplemente, para explicar que el uso de Meteor no te restringe de usar otras cosas. Con React debe de ser una combinación bastante buena, la verdad.
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#178 Por partes:
- Uf, vamos. Menudo "agujero" de seguridad. Que lo mencione en la documentación varias veces que es así por diseño, nada.
- De hace más de un año, antes de que hubiera salido la versión 1 y estuviera listo para producción.
- "La instalación de serie es insegura". Mencionar eso como un problema de seguridad me parece de traca ya, vamos Como si alguien fuera a hacer una aplicación comercial y no utilizar un sistema de publicaciones y subscripciones. Es un paquete que viene habilitado para el prototipado y poco más. Y, de nuevo, explícitamente mencionado en la documentación. De hecho, si despliegas la aplicación te ADVIERTE de que el paquete está activo y no deberías desplegar públicamente la aplicación con ese paquete. ¿Qué problema hay?
En cuando a lo que dices de cliente y servidor... En Meteor tienes código de cliente y código de servidor. Lo que te facilita Meteor es el desarrollo de aplicaciones interactivas mediante el uso de websockets. A lo mejor no tienes necesidad de tiempo real en tu aplicación. O quieres algo más estático. Bien, pues no uses Meteor. Pero no es muy diferente a usar Node.js para hacer una API y comunicarse con el cliente mediante websockets. De hecho, otros frameworks (como Rails 5.0) están intentando ofrecer algo parecido.
#183 Meter fallos de seguridad por diseño /// Es un problema. Que tengas tú que manejar esas cosas en un FW, cuando si usas un FW es precisamente para no tener ese tipo de problemas.
Si tengo necesidad de una aplicación interactiva, lo que haré será montar un servidor a pelo con ES6 y babel y el cliente pues ya vería, seguramente con React y unos cuantos componentes extra.
Sobre Strongloop, sencillamente se usa más para servidor, se está extendiendo y mejorando, tiene detrás comunidad y empresas, por lo que va a ser el FW recomendable.
Pero vamos, que esto es a título personal, usa lo que te dé la gana.
#213 No es ningún agujero de seguridad. Tienes un control absoluto sobre lo que se publica o no. Si decides tomar una decisión de diseño absurda (poner permisos de acceso en la parte pública del documento del usuario), sí, alguien podría modificarlo. Oh, sorpresa. Es más, esa parte del documento es opcional. Acabo de comprobar que mis cuentas de usuario no la tienen y es imposible hacer ningún cambio. Y no es algo de lo que me haya tenido que preocupar, básicamente por no ser subnormal.
Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así.
Que me parece muy bien que a ti no te gusta y prefieras Strongloop (que es al menos un orden de magnitud menos popular que Meteor, que está muy, pero muy bien financiado para ser un proyecto de software libre: http://techcrunch.com/2015/05/19/meteor-raises-20m-to-build-the-one-javascript-stack-to-rule-them-all/) me alegro por ti.
#216 "Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así."
No. De hecho, en un proyecto de trabajo, decidí rechazar Meteor en conjunto con el equipo por otras alternativas.
He trabajado en aplicaciones interactivas muy tochas y potentes y no he tenido que tocar Meteor.
Ah, y ni el consenso popular ni ponerle mucha a pasta a algo lo hacen bueno. Véase: mucho de Microsoft
#178 Sobre lo del XSS, que sí que es (o era, efectivamente) un problema de seguridad para el que tenías que instalar un módulo:
Esto es lo que dice Strongloops: https://docs.strongloop.com/display/public/LB/Security+considerations
Que instales un paquete de NPM. Guau, menuda mejora sobre Meteor, ¿eh?
#170 Básicamente, Meteor intenta ser una solución para cliente+servidor, cuando han de ir separados. Parece muy bonito y, de hecho, está hecho para dar una presentación bonita vendehumos y que digas: wow, quiero esto. Luego ves que tiene carencias e incluso fallos de seguridad.
Angular no sé ni por qué lo mencionas, cuando es bastante patraña.
#174 " cuando han de ir separados" Porque tú lo digas. ¿Qué carencias y fallos de seguridad tiene, según tú? Sospecho que no sabes muy bien de lo que hablas.
Angular lo menciono porque es popular, simplemente, para explicar que el uso de Meteor no te restringe de usar otras cosas. Con React debe de ser una combinación bastante buena, la verdad.
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#178 Por partes:
- Uf, vamos. Menudo "agujero" de seguridad. Que lo mencione en la documentación varias veces que es así por diseño, nada.
- De hace más de un año, antes de que hubiera salido la versión 1 y estuviera listo para producción.
- "La instalación de serie es insegura". Mencionar eso como un problema de seguridad me parece de traca ya, vamos Como si alguien fuera a hacer una aplicación comercial y no utilizar un sistema de publicaciones y subscripciones. Es un paquete que viene habilitado para el prototipado y poco más. Y, de nuevo, explícitamente mencionado en la documentación. De hecho, si despliegas la aplicación te ADVIERTE de que el paquete está activo y no deberías desplegar públicamente la aplicación con ese paquete. ¿Qué problema hay?
En cuando a lo que dices de cliente y servidor... En Meteor tienes código de cliente y código de servidor. Lo que te facilita Meteor es el desarrollo de aplicaciones interactivas mediante el uso de websockets. A lo mejor no tienes necesidad de tiempo real en tu aplicación. O quieres algo más estático. Bien, pues no uses Meteor. Pero no es muy diferente a usar Node.js para hacer una API y comunicarse con el cliente mediante websockets. De hecho, otros frameworks (como Rails 5.0) están intentando ofrecer algo parecido.
#183 Meter fallos de seguridad por diseño /// Es un problema. Que tengas tú que manejar esas cosas en un FW, cuando si usas un FW es precisamente para no tener ese tipo de problemas.
Si tengo necesidad de una aplicación interactiva, lo que haré será montar un servidor a pelo con ES6 y babel y el cliente pues ya vería, seguramente con React y unos cuantos componentes extra.
Sobre Strongloop, sencillamente se usa más para servidor, se está extendiendo y mejorando, tiene detrás comunidad y empresas, por lo que va a ser el FW recomendable.
Pero vamos, que esto es a título personal, usa lo que te dé la gana.
#213 No es ningún agujero de seguridad. Tienes un control absoluto sobre lo que se publica o no. Si decides tomar una decisión de diseño absurda (poner permisos de acceso en la parte pública del documento del usuario), sí, alguien podría modificarlo. Oh, sorpresa. Es más, esa parte del documento es opcional. Acabo de comprobar que mis cuentas de usuario no la tienen y es imposible hacer ningún cambio. Y no es algo de lo que me haya tenido que preocupar, básicamente por no ser subnormal.
Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así.
Que me parece muy bien que a ti no te gusta y prefieras Strongloop (que es al menos un orden de magnitud menos popular que Meteor, que está muy, pero muy bien financiado para ser un proyecto de software libre: http://techcrunch.com/2015/05/19/meteor-raises-20m-to-build-the-one-javascript-stack-to-rule-them-all/) me alegro por ti.
#178 Sobre lo del XSS, que sí que es (o era, efectivamente) un problema de seguridad para el que tenías que instalar un módulo:
Esto es lo que dice Strongloops: https://docs.strongloop.com/display/public/LB/Security+considerations
Que instales un paquete de NPM. Guau, menuda mejora sobre Meteor, ¿eh?
#20 Yo no me creo que esté en un puesto tan bajo, sinceramente. Y JavaScript tiene alguna idea interesante. Es hasta agradable de usar con ES6, la nueva versión.
#41 El ecosistema está muy verde, la verdad. Cientos de paquetes con escasa documentación que enseguida son reemplazados por nuevos paquetes que acaban siendo abandonados también. Creo que solo me gusta Meteor, y en cuanto te sales de los paquetes más populares, más te valdría escribirlo tú mismo.
#20 Eso es lo que dice toda la gente que no sabe JS o que piensa que es jQuery.
#43 Meteor ni si quiera es bueno, strongloop va bastante mejor. Lo suyo, además, es desacoplar cliente y servicor. El servidor en Node con el FW que quieras (todos verdes, eso sí) o te montas tú uno y un cliente en React con Flux.
#170 Básicamente, Meteor intenta ser una solución para cliente+servidor, cuando han de ir separados. Parece muy bonito y, de hecho, está hecho para dar una presentación bonita vendehumos y que digas: wow, quiero esto. Luego ves que tiene carencias e incluso fallos de seguridad.
Angular no sé ni por qué lo mencionas, cuando es bastante patraña.
#174 " cuando han de ir separados" Porque tú lo digas. ¿Qué carencias y fallos de seguridad tiene, según tú? Sospecho que no sabes muy bien de lo que hablas.
Angular lo menciono porque es popular, simplemente, para explicar que el uso de Meteor no te restringe de usar otras cosas. Con React debe de ser una combinación bastante buena, la verdad.
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#178 Por partes:
- Uf, vamos. Menudo "agujero" de seguridad. Que lo mencione en la documentación varias veces que es así por diseño, nada.
- De hace más de un año, antes de que hubiera salido la versión 1 y estuviera listo para producción.
- "La instalación de serie es insegura". Mencionar eso como un problema de seguridad me parece de traca ya, vamos Como si alguien fuera a hacer una aplicación comercial y no utilizar un sistema de publicaciones y subscripciones. Es un paquete que viene habilitado para el prototipado y poco más. Y, de nuevo, explícitamente mencionado en la documentación. De hecho, si despliegas la aplicación te ADVIERTE de que el paquete está activo y no deberías desplegar públicamente la aplicación con ese paquete. ¿Qué problema hay?
En cuando a lo que dices de cliente y servidor... En Meteor tienes código de cliente y código de servidor. Lo que te facilita Meteor es el desarrollo de aplicaciones interactivas mediante el uso de websockets. A lo mejor no tienes necesidad de tiempo real en tu aplicación. O quieres algo más estático. Bien, pues no uses Meteor. Pero no es muy diferente a usar Node.js para hacer una API y comunicarse con el cliente mediante websockets. De hecho, otros frameworks (como Rails 5.0) están intentando ofrecer algo parecido.
#178 Sobre lo del XSS, que sí que es (o era, efectivamente) un problema de seguridad para el que tenías que instalar un módulo:
Esto es lo que dice Strongloops: https://docs.strongloop.com/display/public/LB/Security+considerations
Que instales un paquete de NPM. Guau, menuda mejora sobre Meteor, ¿eh?
#148 bueno, pero ya es más que nadie. Lo que decías antes es mentira. Para muestra, un gráfico: http://i.imgur.com/fMfGvvP.png
Yo es oír la palabra "emprendedor" e instintivamente llevar la mano a proteger la cartera.
#4 Tampoco te pases. Los emprendedores son curritos que viven sobreviviendo y aunque tengan una empresa se les llama así para diferenciarlos de los empresarios que tienen empresas que van bien.
Emprendedor -> currito con empresa, que gana alrededor de 1000€/mes
Empresario -> tiene también empresa, pero gana mucho más.
#81 Un currito con empresa no es un emprendedor, sino un empresario. Gane 1000, 10000 o 100000 millones. Lo de "emprendedor" es un eufemismo que se inventaron porque queda más guay que llamarse "empresario". Y lo que ganen también es independiente de su honorabilidad personal y profesional.
#146 Supuestamente emprendedor se refiere al que innova y crear un nuevo modelo de negocio o mejora sustancialmente un modelo existente.
Me acuerdo de un juez que no quiso aplicar la ley del PP para favorecer a los emprendedores consistente en poder hacer contratos de trabajo con un año de período de prueba (el llamado contrato rajoy que no utiliza casi nadie). El juez argumentó que la ley hablaba de favorecer a los emprendedores y por tanto finalidad de la ley era poder probar durante un año esos nuevos modelos de negocio, y si no funcionaban, poder despedir gratis a los curritos. Y como el empresario era un hostelero de toda la vida que tenía el típico bar, el juez sentenció que no era ningún emprendedor, por tanto no aplicaba el contrato rajoy y tenía que indemnizar por despido improcedente al empleado que le había demandado.
#126 En facebook también, aunque los comentarios de twitter le atacan, en facebook le dan ánimos.
https://www.facebook.com/didacsanchezg
Cuando tenía 15 años estuve en Irlanda, con una familia. A todos los españoles nos sorprendía lo "ocasionales" que eran las duchas de los irlandeses. En mi casa, en concreto, el cuarto de baño estaba recubierto de una espesa moqueta gris.
Por otro lado... ¿"Noticia" de Mayo del 2008? ¿Con qué propósito?
#5 ¿Te ha dejado el noviete y era español? Para los curiosos, antes ponía "Mugrosos hijos de puta"
#7 Obviamente, pensaba en el recurso lógico del sol. En Sevilla, donde vivo, la compañía municipal de autobuses tiene un enorme sistema de paneles solares que se utiliza sólo para dar sombra a los autobuses estacionados y protegerlos de la violencia del sol de este lugar. Que to sepa, una de las ciudades con más sol de España y con una gran instalación preparada para eso, no tiene ningún autobús eléctrico y mucho menos que se propulse con la energía más abundante en la ciudad: el sol.
No sé si se entiende mejor así.
¿Cuantos fabricantes fabrican autobuses electricos aparte de volvo?
¿Cuanto es la parte de instalar los sistemas de carga de los autobuses en la ciudad?
Relacionado
Así es el cargador gigante capaz de recargar autobuses eléctricos en 3 minutos
Así es el cargador gigante capaz de recargar autobuses eléctricos en 3 minutos
#31: Lo del asfalto es que los autobuses estropean el asfalto más que los coches. Se puede ver bien en las marcas viales, que a menudo aparecen distorsionadas, hay crestas longitudinales en el asfalto... y si hay alguna alcantarilla suele acabar habiendo algún bache alrededor. Todo esto es lo que más o menos suelo ver en mi ciudad.
Aquí se puede ver una rugosidad:
https://www.google.es/maps/@41.645075,-4.73354,3a,29.6y,205.26h,73.27t/data=!3m4!1e1!3m2!1sNhhbRpIfovwO3hogevFGoQ!2e0?hl=es
El desgaste del asfalto es a la cuarta potencia del peso que sostiene cada rueda, luego un aumento pequeño del peso se convierte en un efecto bastante mayor en el asfalto. No es ningún rollo, es un presupuesto que hay que tener en cuenta cuando se usan autobuses.
¿Qué ciudades están construyendo tranvias? Creo que les deberían decir que paren los planes inmediatamente.
Menos mal que en Barcelona o Valencia (entre muchas ciudades) no te hicieron caso.
Lo de poner autobuses o tranvías no es cuestión de gustos, sino de cada caso, si una ciudad tiene medio millón de habitantes (caso del envío) puede que sea mejor el tranvía, dependiendo del trazado urbano, calles, presupuesto... Por eso digo que es mejor poner el ahorro para una ciudad más pequeña, donde seguramente sólo haya autobuses.
Esto es como las impresoras, si en una oficina imprimes una hoja de media al día, te vale una impresora barata, si imprimes 2000 te interesa buscar algo que a la larga sea barato. Si quiero ofrecer un sistema de alimentación de tinta continua, no es una buena idea basar el ahorro en 2000 páginas al día, sino en una cantidad más moderada. Eso es lo que trataba de decir, ni más ni menos.
#32 Pero entiendo que los autobuses ya circulan por un montón de ciudades (los normales, no los electricos) desgastando asfalto y todo. Y que la construcción de una infraestructura de tranvia y el coste de los propios tranvías supera con mucho mucho a incluso asfaltar muchas veces las calles por las que pasan los autobuses y desgastan el asfalto.
#34 Pero es un poco como lo de las placas solares fv que eran "muy" caras en la época del incentivo a las renovables de la epoca de Zapatero y después debieron bajar de forma significativa.
Por eso realizaba la pregunta de la previsible bajada de precio de estos autobuses.
Tranvias que ya están construidos vale. Pero para la planificación de construcción de nuevos tranvias y lineas adicionales de tranvia habrá que tenerlo en cuenta muchísimo mas.
Sigo pensando que los "trenes" de los tranvias deben ser mucho pero muchísimo mas caros que incluso esos autobuses electricos de volvo.
Después para una posible, futura y previsible automatización de la conducción de estos vehiculos será mas fácil en los tranvias. Ya hay lineas de metro automaticas no sé en cuantos sitios.
Menuda puta mierda, la verdad. ¿Se supone que eso es un coche? Parece que regalan el carné de pintamonas en cualquier parte.
Pues varias preguntas:
- He visto que CartoDB está hecho con Ruby y JavaScript. ¿Qué ventajas e inconvenientes habéis encontrado al usar estos lenguajes? ¿Habéis tenido algún problema de escalabilidad debido a usar Ruby? La wikipedia dice que el backend está en Node.js, pero en GitHub, mirando por encima, yo veo Ruby.
- Al ser un proyecto de software libre, supongo que habréis visto como es usado para cosas bastante variopintas. ¿Cuál es el proyecto que más os ha llamado la atención?
#9
-Como dices CartoDB utiliza varios lenguajes de programación. Node.js lo utilizamos para las APIs (https://github.com/CartoDB/Windshaft) y como bien has dicho Ruby para el backend de la aplicación. Algún problema nos hemos encontrado por el camino, pero nada que nos bloqueara por completo.
- Mis proyectos favoritos siempre son los que tienen que ver con ciencia y simulaciones. Una de las cosas mas interesantes de los mapas es poder situarte en un lugar en el que no estás, en un momento en el que no estuviste. Por ejemplo este mapa en el que se simula el escape de Alcatraz de 1962 (https://cartodb.com/gallery/alcatraz-escapees/), este en el que detectamos deforestación en casi tiempo real (http://www.globalforestwatch.org/) o este sobre migración de especies (http://lifewatch.inbo.be/blog/posts/forward-trajectory-visualizations.html)
#67 ¿Teneis algún proyecto para detectar fuegos forestareles en tiempo real? Creo que es algo necesario, pero la verdad es que no tengo ni idea de si vuestra tecnología se puede aplicar a este campo.
Gracias
#213 No es ningún agujero de seguridad. Tienes un control absoluto sobre lo que se publica o no. Si decides tomar una decisión de diseño absurda (poner permisos de acceso en la parte pública del documento del usuario), sí, alguien podría modificarlo. Oh, sorpresa. Es más, esa parte del documento es opcional. Acabo de comprobar que mis cuentas de usuario no la tienen y es imposible hacer ningún cambio. Y no es algo de lo que me haya tenido que preocupar, básicamente por no ser subnormal.
Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así.
Que me parece muy bien que a ti no te gusta y prefieras Strongloop (que es al menos un orden de magnitud menos popular que Meteor, que está muy, pero muy bien financiado para ser un proyecto de software libre: http://techcrunch.com/2015/05/19/meteor-raises-20m-to-build-the-one-javascript-stack-to-rule-them-all/) me alegro por ti.
#216 "Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así."
No. De hecho, en un proyecto de trabajo, decidí rechazar Meteor en conjunto con el equipo por otras alternativas.
He trabajado en aplicaciones interactivas muy tochas y potentes y no he tenido que tocar Meteor.
Ah, y ni el consenso popular ni ponerle mucha a pasta a algo lo hacen bueno. Véase: mucho de Microsoft
#178 Sobre lo del XSS, que sí que es (o era, efectivamente) un problema de seguridad para el que tenías que instalar un módulo:
Esto es lo que dice Strongloops: https://docs.strongloop.com/display/public/LB/Security+considerations
Que instales un paquete de NPM. Guau, menuda mejora sobre Meteor, ¿eh?
#178 Por partes:
- Uf, vamos. Menudo "agujero" de seguridad. Que lo mencione en la documentación varias veces que es así por diseño, nada.
- De hace más de un año, antes de que hubiera salido la versión 1 y estuviera listo para producción.
- "La instalación de serie es insegura". Mencionar eso como un problema de seguridad me parece de traca ya, vamos Como si alguien fuera a hacer una aplicación comercial y no utilizar un sistema de publicaciones y subscripciones. Es un paquete que viene habilitado para el prototipado y poco más. Y, de nuevo, explícitamente mencionado en la documentación. De hecho, si despliegas la aplicación te ADVIERTE de que el paquete está activo y no deberías desplegar públicamente la aplicación con ese paquete. ¿Qué problema hay?
En cuando a lo que dices de cliente y servidor... En Meteor tienes código de cliente y código de servidor. Lo que te facilita Meteor es el desarrollo de aplicaciones interactivas mediante el uso de websockets. A lo mejor no tienes necesidad de tiempo real en tu aplicación. O quieres algo más estático. Bien, pues no uses Meteor. Pero no es muy diferente a usar Node.js para hacer una API y comunicarse con el cliente mediante websockets. De hecho, otros frameworks (como Rails 5.0) están intentando ofrecer algo parecido.
#183 Meter fallos de seguridad por diseño /// Es un problema. Que tengas tú que manejar esas cosas en un FW, cuando si usas un FW es precisamente para no tener ese tipo de problemas.
Si tengo necesidad de una aplicación interactiva, lo que haré será montar un servidor a pelo con ES6 y babel y el cliente pues ya vería, seguramente con React y unos cuantos componentes extra.
Sobre Strongloop, sencillamente se usa más para servidor, se está extendiendo y mejorando, tiene detrás comunidad y empresas, por lo que va a ser el FW recomendable.
Pero vamos, que esto es a título personal, usa lo que te dé la gana.
#213 No es ningún agujero de seguridad. Tienes un control absoluto sobre lo que se publica o no. Si decides tomar una decisión de diseño absurda (poner permisos de acceso en la parte pública del documento del usuario), sí, alguien podría modificarlo. Oh, sorpresa. Es más, esa parte del documento es opcional. Acabo de comprobar que mis cuentas de usuario no la tienen y es imposible hacer ningún cambio. Y no es algo de lo que me haya tenido que preocupar, básicamente por no ser subnormal.
Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así.
Que me parece muy bien que a ti no te gusta y prefieras Strongloop (que es al menos un orden de magnitud menos popular que Meteor, que está muy, pero muy bien financiado para ser un proyecto de software libre: http://techcrunch.com/2015/05/19/meteor-raises-20m-to-build-the-one-javascript-stack-to-rule-them-all/) me alegro por ti.
#216 "Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así."
No. De hecho, en un proyecto de trabajo, decidí rechazar Meteor en conjunto con el equipo por otras alternativas.
He trabajado en aplicaciones interactivas muy tochas y potentes y no he tenido que tocar Meteor.
Ah, y ni el consenso popular ni ponerle mucha a pasta a algo lo hacen bueno. Véase: mucho de Microsoft
#174 " cuando han de ir separados" Porque tú lo digas. ¿Qué carencias y fallos de seguridad tiene, según tú? Sospecho que no sabes muy bien de lo que hablas.
Angular lo menciono porque es popular, simplemente, para explicar que el uso de Meteor no te restringe de usar otras cosas. Con React debe de ser una combinación bastante buena, la verdad.
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#178 Por partes:
- Uf, vamos. Menudo "agujero" de seguridad. Que lo mencione en la documentación varias veces que es así por diseño, nada.
- De hace más de un año, antes de que hubiera salido la versión 1 y estuviera listo para producción.
- "La instalación de serie es insegura". Mencionar eso como un problema de seguridad me parece de traca ya, vamos Como si alguien fuera a hacer una aplicación comercial y no utilizar un sistema de publicaciones y subscripciones. Es un paquete que viene habilitado para el prototipado y poco más. Y, de nuevo, explícitamente mencionado en la documentación. De hecho, si despliegas la aplicación te ADVIERTE de que el paquete está activo y no deberías desplegar públicamente la aplicación con ese paquete. ¿Qué problema hay?
En cuando a lo que dices de cliente y servidor... En Meteor tienes código de cliente y código de servidor. Lo que te facilita Meteor es el desarrollo de aplicaciones interactivas mediante el uso de websockets. A lo mejor no tienes necesidad de tiempo real en tu aplicación. O quieres algo más estático. Bien, pues no uses Meteor. Pero no es muy diferente a usar Node.js para hacer una API y comunicarse con el cliente mediante websockets. De hecho, otros frameworks (como Rails 5.0) están intentando ofrecer algo parecido.
#183 Meter fallos de seguridad por diseño /// Es un problema. Que tengas tú que manejar esas cosas en un FW, cuando si usas un FW es precisamente para no tener ese tipo de problemas.
Si tengo necesidad de una aplicación interactiva, lo que haré será montar un servidor a pelo con ES6 y babel y el cliente pues ya vería, seguramente con React y unos cuantos componentes extra.
Sobre Strongloop, sencillamente se usa más para servidor, se está extendiendo y mejorando, tiene detrás comunidad y empresas, por lo que va a ser el FW recomendable.
Pero vamos, que esto es a título personal, usa lo que te dé la gana.
#213 No es ningún agujero de seguridad. Tienes un control absoluto sobre lo que se publica o no. Si decides tomar una decisión de diseño absurda (poner permisos de acceso en la parte pública del documento del usuario), sí, alguien podría modificarlo. Oh, sorpresa. Es más, esa parte del documento es opcional. Acabo de comprobar que mis cuentas de usuario no la tienen y es imposible hacer ningún cambio. Y no es algo de lo que me haya tenido que preocupar, básicamente por no ser subnormal.
Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así.
Que me parece muy bien que a ti no te gusta y prefieras Strongloop (que es al menos un orden de magnitud menos popular que Meteor, que está muy, pero muy bien financiado para ser un proyecto de software libre: http://techcrunch.com/2015/05/19/meteor-raises-20m-to-build-the-one-javascript-stack-to-rule-them-all/) me alegro por ti.
#216 "Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así."
No. De hecho, en un proyecto de trabajo, decidí rechazar Meteor en conjunto con el equipo por otras alternativas.
He trabajado en aplicaciones interactivas muy tochas y potentes y no he tenido que tocar Meteor.
Ah, y ni el consenso popular ni ponerle mucha a pasta a algo lo hacen bueno. Véase: mucho de Microsoft
#178 Sobre lo del XSS, que sí que es (o era, efectivamente) un problema de seguridad para el que tenías que instalar un módulo:
Esto es lo que dice Strongloops: https://docs.strongloop.com/display/public/LB/Security+considerations
Que instales un paquete de NPM. Guau, menuda mejora sobre Meteor, ¿eh?
#170 Básicamente, Meteor intenta ser una solución para cliente+servidor, cuando han de ir separados. Parece muy bonito y, de hecho, está hecho para dar una presentación bonita vendehumos y que digas: wow, quiero esto. Luego ves que tiene carencias e incluso fallos de seguridad.
Angular no sé ni por qué lo mencionas, cuando es bastante patraña.
#174 " cuando han de ir separados" Porque tú lo digas. ¿Qué carencias y fallos de seguridad tiene, según tú? Sospecho que no sabes muy bien de lo que hablas.
Angular lo menciono porque es popular, simplemente, para explicar que el uso de Meteor no te restringe de usar otras cosas. Con React debe de ser una combinación bastante buena, la verdad.
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#178 Por partes:
- Uf, vamos. Menudo "agujero" de seguridad. Que lo mencione en la documentación varias veces que es así por diseño, nada.
- De hace más de un año, antes de que hubiera salido la versión 1 y estuviera listo para producción.
- "La instalación de serie es insegura". Mencionar eso como un problema de seguridad me parece de traca ya, vamos Como si alguien fuera a hacer una aplicación comercial y no utilizar un sistema de publicaciones y subscripciones. Es un paquete que viene habilitado para el prototipado y poco más. Y, de nuevo, explícitamente mencionado en la documentación. De hecho, si despliegas la aplicación te ADVIERTE de que el paquete está activo y no deberías desplegar públicamente la aplicación con ese paquete. ¿Qué problema hay?
En cuando a lo que dices de cliente y servidor... En Meteor tienes código de cliente y código de servidor. Lo que te facilita Meteor es el desarrollo de aplicaciones interactivas mediante el uso de websockets. A lo mejor no tienes necesidad de tiempo real en tu aplicación. O quieres algo más estático. Bien, pues no uses Meteor. Pero no es muy diferente a usar Node.js para hacer una API y comunicarse con el cliente mediante websockets. De hecho, otros frameworks (como Rails 5.0) están intentando ofrecer algo parecido.
#183 Meter fallos de seguridad por diseño /// Es un problema. Que tengas tú que manejar esas cosas en un FW, cuando si usas un FW es precisamente para no tener ese tipo de problemas.
Si tengo necesidad de una aplicación interactiva, lo que haré será montar un servidor a pelo con ES6 y babel y el cliente pues ya vería, seguramente con React y unos cuantos componentes extra.
Sobre Strongloop, sencillamente se usa más para servidor, se está extendiendo y mejorando, tiene detrás comunidad y empresas, por lo que va a ser el FW recomendable.
Pero vamos, que esto es a título personal, usa lo que te dé la gana.
#213 No es ningún agujero de seguridad. Tienes un control absoluto sobre lo que se publica o no. Si decides tomar una decisión de diseño absurda (poner permisos de acceso en la parte pública del documento del usuario), sí, alguien podría modificarlo. Oh, sorpresa. Es más, esa parte del documento es opcional. Acabo de comprobar que mis cuentas de usuario no la tienen y es imposible hacer ningún cambio. Y no es algo de lo que me haya tenido que preocupar, básicamente por no ser subnormal.
Si tienes que hacer una aplicación interactiva, pues tendrás que trabajar más que yo con Meteor. Esto es así.
Que me parece muy bien que a ti no te gusta y prefieras Strongloop (que es al menos un orden de magnitud menos popular que Meteor, que está muy, pero muy bien financiado para ser un proyecto de software libre: http://techcrunch.com/2015/05/19/meteor-raises-20m-to-build-the-one-javascript-stack-to-rule-them-all/) me alegro por ti.
#178 Sobre lo del XSS, que sí que es (o era, efectivamente) un problema de seguridad para el que tenías que instalar un módulo:
Esto es lo que dice Strongloops: https://docs.strongloop.com/display/public/LB/Security+considerations
Que instales un paquete de NPM. Guau, menuda mejora sobre Meteor, ¿eh?
#20 Yo no me creo que esté en un puesto tan bajo, sinceramente. Y JavaScript tiene alguna idea interesante. Es hasta agradable de usar con ES6, la nueva versión.
#41 El ecosistema está muy verde, la verdad. Cientos de paquetes con escasa documentación que enseguida son reemplazados por nuevos paquetes que acaban siendo abandonados también. Creo que solo me gusta Meteor, y en cuanto te sales de los paquetes más populares, más te valdría escribirlo tú mismo.
#20 Eso es lo que dice toda la gente que no sabe JS o que piensa que es jQuery.
#43 Meteor ni si quiera es bueno, strongloop va bastante mejor. Lo suyo, además, es desacoplar cliente y servicor. El servidor en Node con el FW que quieras (todos verdes, eso sí) o te montas tú uno y un cliente en React con Flux.
#170 Básicamente, Meteor intenta ser una solución para cliente+servidor, cuando han de ir separados. Parece muy bonito y, de hecho, está hecho para dar una presentación bonita vendehumos y que digas: wow, quiero esto. Luego ves que tiene carencias e incluso fallos de seguridad.
Angular no sé ni por qué lo mencionas, cuando es bastante patraña.
#174 " cuando han de ir separados" Porque tú lo digas. ¿Qué carencias y fallos de seguridad tiene, según tú? Sospecho que no sabes muy bien de lo que hablas.
Angular lo menciono porque es popular, simplemente, para explicar que el uso de Meteor no te restringe de usar otras cosas. Con React debe de ser una combinación bastante buena, la verdad.
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#175 No lo digo yo, lo dicen las buenas prácticas. El cliente y el servidor tienen funcionalidades distintas, además de que no es lo mismo el servidor http que una o varias APIs para la aplicación, etc.
Meteor tiene cosas como esto: http://joshowens.me/the-curious-case-of-the-unknowing-leaky-meteor-security/
Necesitas un módulo para algo tan básico como XSS: https://meteorhacks.com/xss-and-meteor
La instalación de serie es insegura y tienes que cambiarla (hasta se llama "insecure" e, paquete, lol): http://joshowens.me/meteor-security-101/
#178 Por partes:
- Uf, vamos. Menudo "agujero" de seguridad. Que lo mencione en la documentación varias veces que es así por diseño, nada.
- De hace más de un año, antes de que hubiera salido la versión 1 y estuviera listo para producción.
- "La instalación de serie es insegura". Mencionar eso como un problema de seguridad me parece de traca ya, vamos Como si alguien fuera a hacer una aplicación comercial y no utilizar un sistema de publicaciones y subscripciones. Es un paquete que viene habilitado para el prototipado y poco más. Y, de nuevo, explícitamente mencionado en la documentación. De hecho, si despliegas la aplicación te ADVIERTE de que el paquete está activo y no deberías desplegar públicamente la aplicación con ese paquete. ¿Qué problema hay?
En cuando a lo que dices de cliente y servidor... En Meteor tienes código de cliente y código de servidor. Lo que te facilita Meteor es el desarrollo de aplicaciones interactivas mediante el uso de websockets. A lo mejor no tienes necesidad de tiempo real en tu aplicación. O quieres algo más estático. Bien, pues no uses Meteor. Pero no es muy diferente a usar Node.js para hacer una API y comunicarse con el cliente mediante websockets. De hecho, otros frameworks (como Rails 5.0) están intentando ofrecer algo parecido.
#178 Sobre lo del XSS, que sí que es (o era, efectivamente) un problema de seguridad para el que tenías que instalar un módulo:
Esto es lo que dice Strongloops: https://docs.strongloop.com/display/public/LB/Security+considerations
Que instales un paquete de NPM. Guau, menuda mejora sobre Meteor, ¿eh?
#148 bueno, pero ya es más que nadie. Lo que decías antes es mentira. Para muestra, un gráfico: http://i.imgur.com/fMfGvvP.png
Yo es oír la palabra "emprendedor" e instintivamente llevar la mano a proteger la cartera.
#4 Tampoco te pases. Los emprendedores son curritos que viven sobreviviendo y aunque tengan una empresa se les llama así para diferenciarlos de los empresarios que tienen empresas que van bien.
Emprendedor -> currito con empresa, que gana alrededor de 1000€/mes
Empresario -> tiene también empresa, pero gana mucho más.
#81 Un currito con empresa no es un emprendedor, sino un empresario. Gane 1000, 10000 o 100000 millones. Lo de "emprendedor" es un eufemismo que se inventaron porque queda más guay que llamarse "empresario". Y lo que ganen también es independiente de su honorabilidad personal y profesional.
#146 Supuestamente emprendedor se refiere al que innova y crear un nuevo modelo de negocio o mejora sustancialmente un modelo existente.
Me acuerdo de un juez que no quiso aplicar la ley del PP para favorecer a los emprendedores consistente en poder hacer contratos de trabajo con un año de período de prueba (el llamado contrato rajoy que no utiliza casi nadie). El juez argumentó que la ley hablaba de favorecer a los emprendedores y por tanto finalidad de la ley era poder probar durante un año esos nuevos modelos de negocio, y si no funcionaban, poder despedir gratis a los curritos. Y como el empresario era un hostelero de toda la vida que tenía el típico bar, el juez sentenció que no era ningún emprendedor, por tanto no aplicaba el contrato rajoy y tenía que indemnizar por despido improcedente al empleado que le había demandado.
#126 En facebook también, aunque los comentarios de twitter le atacan, en facebook le dan ánimos.
https://www.facebook.com/didacsanchezg
Cuando tenía 15 años estuve en Irlanda, con una familia. A todos los españoles nos sorprendía lo "ocasionales" que eran las duchas de los irlandeses. En mi casa, en concreto, el cuarto de baño estaba recubierto de una espesa moqueta gris.
Por otro lado... ¿"Noticia" de Mayo del 2008? ¿Con qué propósito?
#5 ¿Te ha dejado el noviete y era español? Para los curiosos, antes ponía "Mugrosos hijos de puta"
#7 ¿Cómo que no reconocen? Ese podría ser uno de los muchos catalanes que ha votado a Ciudadanos u otras opciones no abiertamente independentistas?