#3 No he llegado a ver el video completo, pero y si la maquina cambia la velocidad con la que se desplazan las luces de una tirada a otra?
Su dispositivo se ajusta desde el movil, tiene que ajustar desde que se detecta la luz hasta que se pulsa. En el caso de que cambie entre partidas o de forma dinamica la maquina tendria que reajustarse de la misma manera.
Para poder afirmar que hacen trampas deberia de tener un conjunto de pruebas un poco mas amplio
#27 El botón hay que pulsarlo cuando se enciende la luz, ni más ni menos.
#27 Muestra un gráfico donde aparecen los picos de luz, están separados por el mismo tiempo uno de otro, la luz no cambia de velocidad. Como te indican en otro comentario aunque lo hiciera no invalidaría ni las pruebas ni las conclusiones.
Para poder afirmar que hacen trampas deberia de tener un conjunto de pruebas un poco mas amplio
Al final del vídeo muestran el manual de instrucciones donde lo indica explícitamente.
#27 No he llegado a ver el video completo, pero ... Mira: como yo con tu comentario.
#2 Usa un script que hace uso de un servicio en internet (twilio) que permite hacer llamadas de forma automatica.
Como es un servicio, puede usar infinidad de numeros para hacer muchisimas llamadas (28 por segundo), de forma que satura sus centralitas y evita que la gente que pica en la estafa pueda llamarles.
Obviamente un numero de usuarios sera capaz de seguir llamando y picando en la estafa, pero gracias a que esta saturando la centralita, sera muy inferior al numero habitual.
Rojo y en el bosque. Fijo que nadie se confunde y se come una baya venenosa
#5 es que nadie que no conozca perfectamente bien lo que se lleva a la boca debería ir comiendo plantas por el bosque, que luego pasa lo que pasa. Ni tocando bichos, ya que estamos, que hay mucho tonto que le da por eso también.
Ni por el campo de secano, que es donde he encontrado yo los escaramujos toda mi vida, tampoco
#8 Mirad, un dinosaurio.
Javascript es el puto meteorito 
Javascript es muy mejorable, pero de ahí a decir que es una mierda y que C o Golang en los browsers será la salvación... cuando mayormente hay que seguir exponiendo métodos a JS o usar los que ya ofrece el lenguaje desde WebAssembly
Y no, no tiene puto sentido montar un UI en WebAssembly cuando lo puedes hacer en HTML/JS, no lo digo yo, lo dice John Carmak, que tiene pinta de saber de programación mas que todo Meneame junto...
#1 Es un problema muy orientado a JavaScript.
El problema es que no toda la gente conoce ES6 lo suficiente como para poder usar las funciones fat arrow y los métodos map y reduce de los arrays.
Obviamente es mucho mejor usar las sintaxis nueva y un transpiler para dispositivos que no lo soporten, pero tampoco entendí el drama cuando leí el articulo en dev.to
Y de postre decir que no hacen mención al rendimiento, seria interesante ver como se comportan los nuevos métodos en los distintos navegadores comparándolo con bucles for tradicionales.
#10 "Cojo otro niño, lo tiro por el pozo, y ya son 820 niños los que el pozo se ha tragado.."
"No estaras tirando a los niños por el pozo?"
"Que cosas dices"
#25 y open source para que hagas una UI/UX como es debido.
A mi no me gusta el modo headless que trae, pero no por ello voy llorando por ahi.
#29 ¿cómo se hace una de esas sin ser informático? Si fuese fácil de entender igual sí que me curraba una, porque, sí, el open source mola, pero no se puede negar que (en general) es feo de cojones. Pero feo, feo, feo.
#29 #37 Parece ser que no se puede hacer un critica de algo open source sin que salga el típico comentario de hazlo tu mismo.
Pues mira he trabajado como diseñador UI y bien agusto que participaría, pero no todos tenemos el tiempo necesario para hacerlo ni las ganas y eso no me quita potestad para comentar sus faltas.
Por otra parte, no todo el mundo tiene el conocimiento para participar en estos proyectos y su opinión es completamente válida. Es más, muchas veces encuentro más útiles los comentarios de gente que no sabe del tema ya que potencialmente va a ser el usuario final.
#34 tan sencillo como comisionar solo cuando se corrobora la sancion, de forma automatica.
Algun problema??
Asi estan mas motivados
Un paso gigante, me recuerda mucho a
https://www.rijksmuseum.nl/?lang=EN&gclid=CLyqxdDl08kCFU-6GwodoQcNJQ
Pero sigo esperando a que tengan una apuesta digital seria, veo las obras, pero no veo infografia sobre las mismas, ni una app para tablet/moviles que se pueda usar en una visita (no se si exite de antes y ahora han metido este contenido)
#88 o mucho ha cambiado o yo no supe usarlo para poder hacer filtrados interesantes
#67
Si usas man te tienes que saber el nombre del comando.
#man man
` man [-acdfFhkKtwW] [--path] [-m system] [-p string] [-C config_file] [-M pathlist] [-P pager] [-B browser] [-H htmlpager] [-S section_list] [section]
name ...
`
Osea, que tienes que memorizar si o si los comandos, nadie ha hablado de su uso completo a dedillo.
PD. Y la verdad, si no te sabes los atributos mas comunes de las herramientas que usas todos los dias...es para hacerselo mirar.
#35 Si eres administrador de sistemas *nix no te queda otra.
Y si eres desarrollador conocer los comandos de tu shell marcan la diferencia entre ser mediocre y ser eficiente.
#45 llevo 15 años de sysadmin de UNIX/Linux. No he intentado memorizar nada, aun hoy uso lapaginas man para ver opciones. No solo nunca me ha faltado trabajo, sino que siempre ha sido mejor pagado.
Creo que confundes memoria con inteligencia.
Conozco a gente que teclean a la velicidad de la luz y saben del memoria unas cuantas cosas, siempre las mismas. Suelen ser los sysadmins mas arrogantes y los que nunca cambian de trabajo.
#67
Si usas man te tienes que saber el nombre del comando.
#man man
` man [-acdfFhkKtwW] [--path] [-m system] [-p string] [-C config_file] [-M pathlist] [-P pager] [-B browser] [-H htmlpager] [-S section_list] [section]
name ...
`
Osea, que tienes que memorizar si o si los comandos, nadie ha hablado de su uso completo a dedillo.
PD. Y la verdad, si no te sabes los atributos mas comunes de las herramientas que usas todos los dias...es para hacerselo mirar.
#80 man -k
O otras busquedas. Obviamente tienes que saber que buscar, pero creo que no hace falta memorizar comandos hoy en dia.
En todo caso, a mi no me ha hecho falta.
#56 Emmmm, hay tantas cosas mal en tu post que da pereza incluso contestarte.
Para empezar, Metal Gear sera abanderado de Sony, ya que la saga empezó en el MSX, y han ido saliendo versiones para TODAS sus consola, no solo PS2 (con el 2 y el 3). Si han salido versiones para GBC, GC y Xbox, ademas de PC, XBOX + 360 parece que no importa
No tengo corazon ni ganas de comprarme 4 consolas para jugar a los juegos.
Sobre tu alegato contra Steam y plataformas online, por si no lo sabes, precisamente Steam se caracteriza por la distrubucion de parches de forma transparete. Ademas puedes jugar offline sin tener conexion y puedes compartir tu biblioteca de juegos.
A partir de ahi todo muy con pinzas.
#36 Cuñao al canto.
A mi me llaman ambimanco/ambizurdo, porque de toda la vida en los juegos, a los malos, nos han llamado mancos.
Para finalizar, MGSV:TPP es un juego de Konami, no de Sony. Yo lo estoy jugando en mi 360, asi que no se que tendra que esa compañia con la decision del gorro.
#44 Bueno, todo el mundo sabe que Metal gear solid ha sido siempre el abanderado de la PS2. Si juegas al MGS en 360 es que no tienes corazón.
No me acordaba de que era de Konami. Pero es que me da igual, la industria de los juegos trata a sus clientes como la mierda, eso es a lo que voy. Te compras un juego de 60 euros y te obligan a instalarte Steam, te cosen a publicidad, no dan buen soporte tecnico, ni de actualizaciones. Te obligan a estar conectado a Internet para jugar, a meter innuberables codigos de seguridad con la excusa de que es para que no nos roben el juego, pero la realidad es que es para que no se lo prestemos a un amigo y tenernos controlados. Yo soy de la epoca del parchis, y si te comprabas uno, podias jugar con 3 amigos sin que te mandaran cartas de parchis.com, además el juego tenia todas sus fichitas y funcionaba perfectamente sin tener que conectarte a ninguna red, y lo mejor de todo: NUNCA SE COLGABA.
En fin, creo que tiene mucho que ver con la educacion competitiva de ser mas que tus compñeros o eres una mierda y no solo eres una mierda, sino que te humillamos poniendote orejas de burro delante de todos tus "compañeros barra hijos de puta".
Y hasta aqui mi alegato a la pirateria y la cultura libre: Viva TPB! Vivan los FreeToPlay! Muera Wert!
#56 Emmmm, hay tantas cosas mal en tu post que da pereza incluso contestarte.
Para empezar, Metal Gear sera abanderado de Sony, ya que la saga empezó en el MSX, y han ido saliendo versiones para TODAS sus consola, no solo PS2 (con el 2 y el 3). Si han salido versiones para GBC, GC y Xbox, ademas de PC, XBOX + 360 parece que no importa
No tengo corazon ni ganas de comprarme 4 consolas para jugar a los juegos.
Sobre tu alegato contra Steam y plataformas online, por si no lo sabes, precisamente Steam se caracteriza por la distrubucion de parches de forma transparete. Ademas puedes jugar offline sin tener conexion y puedes compartir tu biblioteca de juegos.
A partir de ahi todo muy con pinzas.
#44 doy fe: "¡mira que eres malo, pareces manco!" (incluso al fútbol me lo han dicho 
)
#83 en su diario, que hay que comprar, mientras que de esta forma todo el mundo tiene derecho a ver la replica. Si los periodistas ven que no es cierto pueden aportar mas pruebas, y si el ayuntamiento de Madrid cree que se falta a la verdad (como descontextualizar o recortar unas declaraciones) puede responder en su plataforma.
No hay problema
En mi caso me cuesta horrores el visualizar imagenes cuando estoy consciente, cosa que no me pasa en sueños
#137
El comentario venia por lo de explicar al cliente que estas escribiendo test.
En teoria tu al cliente le das estimaciones, y dichas estimaciones deben de incluir los test, en caso de que trabajes con ellos. No vale que se hagan despues o esten fuera de planificacion. Eso no vale, porque despues vienen las prisas, las cosas no se prueban, y fallan en el momento mas tonto.
Y si, obviamente falta cultura en todos los lados, pero si tomamos al cliente como un ladrillo, poco va a cambiar la situacion.
Yo a los clientes que he visto mas contentos han sido con los que hemos sido mas sinceros y les hemos involucrado mas en los desarrollos. Y no hablo de metodologias AGILE, hablo de transparencia, que falta de eso mucho.
Cuidamos la calidad del codigo y del producto final de varias formas, aunque actualmente no estamos cuantificandola tal cual, aunque deberiamos de profundizar mas en ello.
La forma en la que lo hacemos es:
Formacion de los desarrolladores para que todo el mundo siga unas directivas desde el minuto 0. Nada de programar sin saber como se va a planificar.
Code review implicando a todos los desarrolladores
Revisiones automaticas de codigo que escupen desde errores de estilo a errores de codificacion
Test automaticos en todas las dependencias de terceros.
Tests automaticos en nuestro producto
Test no tan automaticos en los desarrollos (por dificultad, aunque siempre le damos vueltas nunca encontramos una forma real y facil de hacerlo)
Test por parte de equipo de QA
No es perfecto y tenemos bastantes lagunas, pero cada dia intentamos mejorar la calidad del codigo para que repercuta de forma positiva en propio beneficio
No es raro ir a eventos de desarrolladores o juntarte con ex compañeros o estudiantes y que cuando comentas estas cosas no tengan ni idea de que se esta hablando.
#127 sabes que los test se escriben antes del codigo, no?
Y el tema esta en que a los clientes no hay que tratarlos como esos entes opacos que sueltan la pasta y a los perros cuando las cosas no estan a tiempo.
Tal vez si se implica mas a todas las partes interesadas, los desarrollos irian mucho mas ligeros y sin tanto problema
#130 Sí claro, los tests se escriben antes, pero no se porque haces ese comentario, ¿acaso he puesto lo contrario? Lo que está claro es que la persona que hace los tests tiene que ser diferente a la que hace el código, dado que entonces con el test está programando la aplicación y no encontrará fallos diferentes. Además de que no siempre se escribe antes, porque los desarrollos son procesos iterativos, por lo que al final estás escribiendo tests de cosas que ya están programadas. Pero inicialmente el test se escribe antes.
Yo tengo de los dos tipos de clientes, de los que se implican y de los que no y se perfectamente que a unos les puedo pedir una validación cada 15 días y a otros sólo quieren tenerlo ya. Porque hay mucho cliente que quiere:
1. Que le leas la mente
2. Que hagas única y exclusivamente lo que te pide.
3. Que lo hagas para ayer.
4. Que lo hagas por el dinero que puede pagar. (Esto todos claro, si no es así no te conviene este cliente)
Te repito mi pregunta, te agradecería que me explicases en tu empresa/trabajo cómo medís la calidad del software y que por favor uses o expongas un atributo cuantificable para poder comparar correctamente dos códigos.
#137
El comentario venia por lo de explicar al cliente que estas escribiendo test.
En teoria tu al cliente le das estimaciones, y dichas estimaciones deben de incluir los test, en caso de que trabajes con ellos. No vale que se hagan despues o esten fuera de planificacion. Eso no vale, porque despues vienen las prisas, las cosas no se prueban, y fallan en el momento mas tonto.
Y si, obviamente falta cultura en todos los lados, pero si tomamos al cliente como un ladrillo, poco va a cambiar la situacion.
Yo a los clientes que he visto mas contentos han sido con los que hemos sido mas sinceros y les hemos involucrado mas en los desarrollos. Y no hablo de metodologias AGILE, hablo de transparencia, que falta de eso mucho.
Cuidamos la calidad del codigo y del producto final de varias formas, aunque actualmente no estamos cuantificandola tal cual, aunque deberiamos de profundizar mas en ello.
La forma en la que lo hacemos es:
Formacion de los desarrolladores para que todo el mundo siga unas directivas desde el minuto 0. Nada de programar sin saber como se va a planificar.
Code review implicando a todos los desarrolladores
Revisiones automaticas de codigo que escupen desde errores de estilo a errores de codificacion
Test automaticos en todas las dependencias de terceros.
Tests automaticos en nuestro producto
Test no tan automaticos en los desarrollos (por dificultad, aunque siempre le damos vueltas nunca encontramos una forma real y facil de hacerlo)
Test por parte de equipo de QA
No es perfecto y tenemos bastantes lagunas, pero cada dia intentamos mejorar la calidad del codigo para que repercuta de forma positiva en propio beneficio
No es raro ir a eventos de desarrolladores o juntarte con ex compañeros o estudiantes y que cuando comentas estas cosas no tengan ni idea de que se esta hablando.
#73 La calidad del SW va ligada a procedimientos y metodologias, negar eso es mucho negar.
Cuando hay legazy code de por medio, se puede ir introduciendo de forma escalonada dichas metodologias, empezar con un 0% de code coverage y poco a poco tener código seguro.
No es la panacea, pero obviamente es un paso que el 99% de la gente no se toma en serio, y luego pasan las mierdas que pasan.
Aqui somos muy de hacer QA con un ejercito de monos, en vez de invertir en un equipo que se encargue de hacer tests profesionales
Por cierto que AGILE poco tiene que ver con la calidad del código, pero bueno.
#95 Yo no niego la necesidad de una metodología o procedimiento. Niego la necesidad de las metodologías y procedimientos que surgen ¿Trending? o molones que sirven para venderte cursos de 8 horas a 1200€-3000€ que a duras penas puedes aplicar en tu día a día. Porque la metodología o procedimiento puede variar enormemente entre proyectos y clientes. Además de que en un proyecto no tiene porque trabajar una sola empresa.
A mí me gustaría ver a una persona en un sólo proyecto haciendo TDD. O explicarle a cualquier cliente que te ha pagado un 30% por adelantado que 1 mes o 2 meses después no va a ver nada porque estás escribiendo los tests.
La idea detrás del TDD me parece cojonuda, pero ponerla en práctica requiere de un dinero y una mentalidad que yo diría que pocos clientes se pueden permitir. Ahora bien, para un proyecto interno, una inversión para una propuesta a futuro perfecto.
Y yo ya te digo, si hablas de la calidad del software dime con que herramientas lo mides, entendiéndose como herramienta un atributo cuantificable con el que medirlo para saber que un código es de calidad y otro no. Y te lo pregunto porque parece que tú si sigues esto y me parecería interesante saber tu opinión.
#127 sabes que los test se escriben antes del codigo, no?
Y el tema esta en que a los clientes no hay que tratarlos como esos entes opacos que sueltan la pasta y a los perros cuando las cosas no estan a tiempo.
Tal vez si se implica mas a todas las partes interesadas, los desarrollos irian mucho mas ligeros y sin tanto problema
#130 Sí claro, los tests se escriben antes, pero no se porque haces ese comentario, ¿acaso he puesto lo contrario? Lo que está claro es que la persona que hace los tests tiene que ser diferente a la que hace el código, dado que entonces con el test está programando la aplicación y no encontrará fallos diferentes. Además de que no siempre se escribe antes, porque los desarrollos son procesos iterativos, por lo que al final estás escribiendo tests de cosas que ya están programadas. Pero inicialmente el test se escribe antes.
Yo tengo de los dos tipos de clientes, de los que se implican y de los que no y se perfectamente que a unos les puedo pedir una validación cada 15 días y a otros sólo quieren tenerlo ya. Porque hay mucho cliente que quiere:
1. Que le leas la mente
2. Que hagas única y exclusivamente lo que te pide.
3. Que lo hagas para ayer.
4. Que lo hagas por el dinero que puede pagar. (Esto todos claro, si no es así no te conviene este cliente)
Te repito mi pregunta, te agradecería que me explicases en tu empresa/trabajo cómo medís la calidad del software y que por favor uses o expongas un atributo cuantificable para poder comparar correctamente dos códigos.
#137
El comentario venia por lo de explicar al cliente que estas escribiendo test.
En teoria tu al cliente le das estimaciones, y dichas estimaciones deben de incluir los test, en caso de que trabajes con ellos. No vale que se hagan despues o esten fuera de planificacion. Eso no vale, porque despues vienen las prisas, las cosas no se prueban, y fallan en el momento mas tonto.
Y si, obviamente falta cultura en todos los lados, pero si tomamos al cliente como un ladrillo, poco va a cambiar la situacion.
Yo a los clientes que he visto mas contentos han sido con los que hemos sido mas sinceros y les hemos involucrado mas en los desarrollos. Y no hablo de metodologias AGILE, hablo de transparencia, que falta de eso mucho.
Cuidamos la calidad del codigo y del producto final de varias formas, aunque actualmente no estamos cuantificandola tal cual, aunque deberiamos de profundizar mas en ello.
La forma en la que lo hacemos es:
Formacion de los desarrolladores para que todo el mundo siga unas directivas desde el minuto 0. Nada de programar sin saber como se va a planificar.
Code review implicando a todos los desarrolladores
Revisiones automaticas de codigo que escupen desde errores de estilo a errores de codificacion
Test automaticos en todas las dependencias de terceros.
Tests automaticos en nuestro producto
Test no tan automaticos en los desarrollos (por dificultad, aunque siempre le damos vueltas nunca encontramos una forma real y facil de hacerlo)
Test por parte de equipo de QA
No es perfecto y tenemos bastantes lagunas, pero cada dia intentamos mejorar la calidad del codigo para que repercuta de forma positiva en propio beneficio
No es raro ir a eventos de desarrolladores o juntarte con ex compañeros o estudiantes y que cuando comentas estas cosas no tengan ni idea de que se esta hablando.
#2 Cuantos informáticos usan TDD/BDD, SOLID o cualquier metodologia para evitar desastres??
EL 99% del código no es determinante en la vida o muerte de las personas, y eso hace que el 99% de los desarrolladores seamos unos guarros del código de tres pares de pelotas.
Y cuando tienes a un tren a toda maquina, es muy difícil pararlo y cambiarlo de via.
Profesionalidad en nuestro mundo es lo que falta.
#63 Ninguna metodología evita desastres. Evita que vuelvan a aparecer si es que se identifica el porque ha sucedido.
La verdad es que me encanta cuando todo el mundo habla de todas estas metodologías como si fuesen la panacea. O bien es que sus proyectos son internos o bien es que son tremendamente pequeños. En la práctica tal y como las enseñan son casi imposibles de realizar. Por razones como:
- El proyecto lleva 10 años desarrollándose y sólo hay evolutivos, no vas a hacer tests de cosas de hace 10 años o que no sabes ni si se usan. Por lo que tu código nunca estará 100% probado.
- Con metodologias AGILE, no todos tus clientes validan tus desarrollos y por lo tanto o dejas de desarrollar o pasas del AGILE.
- Los requisitos de los clientes hacen que se cambien los modelos de datos de un dia para otro...
- La realidad te puede joder todo un diseño por algo que ningún actor conocía.
#73 La calidad del SW va ligada a procedimientos y metodologias, negar eso es mucho negar.
Cuando hay legazy code de por medio, se puede ir introduciendo de forma escalonada dichas metodologias, empezar con un 0% de code coverage y poco a poco tener código seguro.
No es la panacea, pero obviamente es un paso que el 99% de la gente no se toma en serio, y luego pasan las mierdas que pasan.
Aqui somos muy de hacer QA con un ejercito de monos, en vez de invertir en un equipo que se encargue de hacer tests profesionales
Por cierto que AGILE poco tiene que ver con la calidad del código, pero bueno.
#95 Yo no niego la necesidad de una metodología o procedimiento. Niego la necesidad de las metodologías y procedimientos que surgen ¿Trending? o molones que sirven para venderte cursos de 8 horas a 1200€-3000€ que a duras penas puedes aplicar en tu día a día. Porque la metodología o procedimiento puede variar enormemente entre proyectos y clientes. Además de que en un proyecto no tiene porque trabajar una sola empresa.
A mí me gustaría ver a una persona en un sólo proyecto haciendo TDD. O explicarle a cualquier cliente que te ha pagado un 30% por adelantado que 1 mes o 2 meses después no va a ver nada porque estás escribiendo los tests.
La idea detrás del TDD me parece cojonuda, pero ponerla en práctica requiere de un dinero y una mentalidad que yo diría que pocos clientes se pueden permitir. Ahora bien, para un proyecto interno, una inversión para una propuesta a futuro perfecto.
Y yo ya te digo, si hablas de la calidad del software dime con que herramientas lo mides, entendiéndose como herramienta un atributo cuantificable con el que medirlo para saber que un código es de calidad y otro no. Y te lo pregunto porque parece que tú si sigues esto y me parecería interesante saber tu opinión.
#127 sabes que los test se escriben antes del codigo, no?
Y el tema esta en que a los clientes no hay que tratarlos como esos entes opacos que sueltan la pasta y a los perros cuando las cosas no estan a tiempo.
Tal vez si se implica mas a todas las partes interesadas, los desarrollos irian mucho mas ligeros y sin tanto problema
#130 Sí claro, los tests se escriben antes, pero no se porque haces ese comentario, ¿acaso he puesto lo contrario? Lo que está claro es que la persona que hace los tests tiene que ser diferente a la que hace el código, dado que entonces con el test está programando la aplicación y no encontrará fallos diferentes. Además de que no siempre se escribe antes, porque los desarrollos son procesos iterativos, por lo que al final estás escribiendo tests de cosas que ya están programadas. Pero inicialmente el test se escribe antes.
Yo tengo de los dos tipos de clientes, de los que se implican y de los que no y se perfectamente que a unos les puedo pedir una validación cada 15 días y a otros sólo quieren tenerlo ya. Porque hay mucho cliente que quiere:
1. Que le leas la mente
2. Que hagas única y exclusivamente lo que te pide.
3. Que lo hagas para ayer.
4. Que lo hagas por el dinero que puede pagar. (Esto todos claro, si no es así no te conviene este cliente)
Te repito mi pregunta, te agradecería que me explicases en tu empresa/trabajo cómo medís la calidad del software y que por favor uses o expongas un atributo cuantificable para poder comparar correctamente dos códigos.
#137
El comentario venia por lo de explicar al cliente que estas escribiendo test.
En teoria tu al cliente le das estimaciones, y dichas estimaciones deben de incluir los test, en caso de que trabajes con ellos. No vale que se hagan despues o esten fuera de planificacion. Eso no vale, porque despues vienen las prisas, las cosas no se prueban, y fallan en el momento mas tonto.
Y si, obviamente falta cultura en todos los lados, pero si tomamos al cliente como un ladrillo, poco va a cambiar la situacion.
Yo a los clientes que he visto mas contentos han sido con los que hemos sido mas sinceros y les hemos involucrado mas en los desarrollos. Y no hablo de metodologias AGILE, hablo de transparencia, que falta de eso mucho.
Cuidamos la calidad del codigo y del producto final de varias formas, aunque actualmente no estamos cuantificandola tal cual, aunque deberiamos de profundizar mas en ello.
La forma en la que lo hacemos es:
Formacion de los desarrolladores para que todo el mundo siga unas directivas desde el minuto 0. Nada de programar sin saber como se va a planificar.
Code review implicando a todos los desarrolladores
Revisiones automaticas de codigo que escupen desde errores de estilo a errores de codificacion
Test automaticos en todas las dependencias de terceros.
Tests automaticos en nuestro producto
Test no tan automaticos en los desarrollos (por dificultad, aunque siempre le damos vueltas nunca encontramos una forma real y facil de hacerlo)
Test por parte de equipo de QA
No es perfecto y tenemos bastantes lagunas, pero cada dia intentamos mejorar la calidad del codigo para que repercuta de forma positiva en propio beneficio
No es raro ir a eventos de desarrolladores o juntarte con ex compañeros o estudiantes y que cuando comentas estas cosas no tengan ni idea de que se esta hablando.
Yo de lo que deduzco del articulo no ha logrado mas que compartir credenciales entre distintos dispositivos de una forma enrevesada.
Nada de descargar las películas en maxima calidad o de poder compartir credenciales de forma infinita entre usuarios.
#26 esto es el 2.0 del cardsharing que se hacia o sigue haciendo con D+
#26 Hombre, yo creo que un Camtasia o algo similar(bien hecho, claro) ya haces lo primero, lo segundo mayormente es lo que hacen aquí, pero sin credenciales, una cuenta desde la que puede ver cualquiera, es algo enrevesado(en realidad no tanto ahora que ya se sabe como) para el que lo monta, pero para el cliente es tan fácil como ir a un link.
#227 en teoria un examen tipo test no es mas facil de aprobar, estadisticamente son mas dificiles, ya que arriesgarse penaliza y no contestar no suma. En ingenieria solo he tenido una asignatura que tenia una parte tipo test, y te aseguro que todo el mundo suspende esa asignatura por dicha parte, ya que no hay tiempo y jugarsela era igual a suspenso.
Cuando la gente es consciente de esto aprueba.
Ahora bien, si haces tipo test en el que el fallo no penaliza y puedes sacar un 12 sobre 10, cosas que he visto, pues entonces los test son mas faciles, si
#227 #234 Ahí estoy a medias de acuerdo con cada uno, en principio un tipo test es más fácil porque tienes la respuesta es solo que no sabes cual es, y en general los profesores que hacen ese tipo de exámenes lo hacen precisamente por no complicarse demasiado ni al elaborar el examen ni al corregirlo. Así que en general me parece más aprobable que otros tipos de examenes.
El problema es que muchos exámenes de ese tipo son malos exámenes. Muchas veces tienes preguntas tontas que solo buscan confundir, o respuestas idénticas que solo se diferencian en algún dato irrelevante, a veces incluso las respuestas "correctas" son más que discutibles.
#50 Entiendo la necesidad de la insurgencia, pero por favor, no mezclemos un acto de defensa con lo que esta pasando ahora mismo.
Esta gente nace como una facción radical de AlQaeda, así que partimos de gente no muy aficionada a respetar los derechos humanos de sus iguales (mujeres, otras religiones)
Han fagocitado a la resistencia de Siria (como digo, tiene mucho sentido el alzamiento en Siria, pero no de esta forma)
Justificar a estos animales que están ejecutando civiles y voluntarios, asaltando ciudades de otras etnias practicando limpiezas etnicas, vendiendo a la gente como esclavos... eso es mucho justificar.
#58 Los primeros en perder la cabeza fueron los que pusieron en cargos de responsabilidad en el país, véase políticos, banqueros, mercaderes y demás chusma que agacho la cabeza y se frotó las manos ante la posibilidad de hacerse de oro bajo el manto protector del "ganador" norteamericano. Si alguien a entendido el significado de la palabra "regeneración" han sido ellos.
#76 +1
#91 Fíjate que llamas injustificable a algo que te han contado a su manera los medios de comunicación occidentales. El odio no es algo que se cocine en 10 minutos, se tardan años. No soy experto en las etnias de esa zona del mundo para sacar una conclusión definitiva, pero los masmedia occidentales tampoco y creo que sus querellas internas vienen de muy lejos. Ahora te pregunto ¿justificarías tu uno o varios ataques nucleares en la zona? Yo no, porque parece que es para lo que nos están preparando.
...y a los 16 negativos GRACIAS por hacer que el comentario #50 sea uno de los mas leídos del hilo, pringaos.
#2 Sublime no se puede usar en una empresa?
Supongo que te refieres a la trial, y no a la de pago.