Portada
mis comunidades
otras secciones
#4:
Pero si lo ves en un editor medio decente que te avise de que está en UTF8, al pasarlo a ISO-8859-2 ves:
public void HelloWorld()
">
lo cual confirma mi teoría talibán de que todo lo que no sea ASCII de 7bit es un invento del maligno y debe de alejarse con fuego de nuestros terminales.
public void HelloWorld()
">
lo cual confirma mi teoría talibán de que todo lo que no sea ASCII de 7bit es un invento del maligno y debe de alejarse con fuego de nuestros terminales.
#2:
Que idea tan retorcida, sádica y cruel... genial, me la apunto. 
#9:
La mayoría de los editores te avisarán de que hay algo raro.
Y si no te avisan creo que la solución más habitual a este tipo de problemas es borrar la línea y escribirla de nuevo, con lo que no te va a bloquear más allá de un solo minuto. Vamos, yo es lo que haría.
Pero como chorradita tiene su gracia.
Y si no te avisan creo que la solución más habitual a este tipo de problemas es borrar la línea y escribirla de nuevo, con lo que no te va a bloquear más allá de un solo minuto. Vamos, yo es lo que haría.
Pero como chorradita tiene su gracia.
#16:
#11 Te juro que esta mañana tenía un script en PHP que en local iba bien y en el servidor daba error 500.
Había añadido 3 lineas nuevas. Así que las borre para ver si esa era la causa del error. Con esas líneas, error 500. Sin ellas, todo correcto.
Al final las reescribí de otra forma y ya funciona. Nunca sabré que demonios estaba causando el error 500. Pero vamos, que la solución fue borrar y reescribir.
Cuando algo me da error y me parece que el código está bien y no tengo ni idea de que puede ser lo borro y lo reescribo. (Siempre que hablemos de un código pequeño, claro)
Había añadido 3 lineas nuevas. Así que las borre para ver si esa era la causa del error. Con esas líneas, error 500. Sin ellas, todo correcto.
Al final las reescribí de otra forma y ya funciona. Nunca sabré que demonios estaba causando el error 500. Pero vamos, que la solución fue borrar y reescribir.
Cuando algo me da error y me parece que el código está bien y no tengo ni idea de que puede ser lo borro y lo reescribo. (Siempre que hablemos de un código pequeño, claro)
#7:
En Netbeans señala el ; y explica claramente illegal character: u037E
#modo_aguafiestas
#modo_aguafiestas
Comentarios
Pero si lo ves en un editor medio decente que te avise de que está en UTF8, al pasarlo a ISO-8859-2 ves:
public void HelloWorld()
">
lo cual confirma mi teoría talibán de que todo lo que no sea ASCII de 7bit es un invento del maligno y debe de alejarse con fuego de nuestros terminales.
#4 A mi me pasa al contrario, considerando que 8859-X son alfabetos limitados el UTF-8 para mi es el estandar, y si algo no está en eso se convierte. Si un usuario quiere mensajear a otro en chino con mi aplicación, es la única manera.
¿Qué motivos pondrías para considerar 8859-X como más deseable?
#28 no, el iso 8859 no lo encuentro más deseable. El ASCII 7 bit sí. Porque soy un talibán.
#4 Otro de HOST aqui... te paso un link http://www.dinoland.com.ar/phpBB3/
#31 no entiendo qué quieres decir con "otro de HOST" pero bueno, gracias por el link.
#4 Al revés, ves eso porque tu editor no es decente. Me gustaría saber de que forma programarías siendo ruso o chino en ASCII de 7 bits. Ser talibán no es algo deseable...
#57 soy español y programo en ASCII de 7bit. Mi código está exclusivamente en inglés. Así es como garantizo que cualquier otro programador del mundo lo vea y lo entienda correctamente.
Cuando he recibido código en ruso, que lo he hecho, me he cagado en sus muelas. Siempre digo que se entiende mejor el mal inglés que el buen [inserte aquí su idioma].
Para la interfaz de usuario sí me parece bien UTF-8. El código, siempre inglés.
#60 Concuerdo con lo del código siempre en inglés, pero... Y la docu que va asociada al proyecto, los .md o cualquier referencia dentro del propio repositorio? El encoding no debería ser una limitación, tu teclado tiene ñ y tildes por algo.
#62 la documentación y el resto de cosas técnicas las hago también en inglés. La aplicación de cara al usuario UTF-8 (*) y con todas las cadenas aparte para que sea fácilmente localizable. Normalmente las pongo en TMX, que es xml estándar de software de traducción.
Como ves soy un talibán amable con el usuario.
(*) Excepción con apps solo para Asia, en ese caso el UTF-16 ocupa un poquito menos debido a que la mayor parte de los caracteres necesitan al menos 2 bytes, y para eso existe.
#4 todo lo que no sea ASCII de 7bit es un invento del maligno
僕関係いない
Que idea tan retorcida, sádica y cruel... genial, me la apunto.
#2 es mucho mejor que la de pegar el trozo de postit en el lector óptico del ratón.
#13 ¡Jjaa, hoy estáis sembrados!!
La mayoría de los editores te avisarán de que hay algo raro.
Y si no te avisan creo que la solución más habitual a este tipo de problemas es borrar la línea y escribirla de nuevo, con lo que no te va a bloquear más allá de un solo minuto. Vamos, yo es lo que haría.
Pero como chorradita tiene su gracia.
#9 Eso lo dices ahora por que sabes que te estan troleando, pero yo no recuerdo borrar una linea de codigo en mi vida por un error.
Si lo tengo hecho con algún bloque de código por que me estaba tocando las pelotas y prefería reescribirlo/replantearlo de otra manera, pero fue más por problema de lógica que por un error.
#11 Te juro que esta mañana tenía un script en PHP que en local iba bien y en el servidor daba error 500.
Había añadido 3 lineas nuevas. Así que las borre para ver si esa era la causa del error. Con esas líneas, error 500. Sin ellas, todo correcto.
Al final las reescribí de otra forma y ya funciona. Nunca sabré que demonios estaba causando el error 500. Pero vamos, que la solución fue borrar y reescribir.
Cuando algo me da error y me parece que el código está bien y no tengo ni idea de que puede ser lo borro y lo reescribo. (Siempre que hablemos de un código pequeño, claro)
#16 ¿Problemas de salto de línea Windos quizá? En un servidor UNIX el salto de linea Windows se ve como ^M.
#16 od -xc $fichero.
#16 Yo suelo comentar partes para intentar aislar un problema de esos pero nunca borro, siempre intento averiguar cual fue el problema.
#16
Cuando algo me da error y me parece que el código está bien y no tengo ni idea de que puede ser lo borro y lo reescribo. (Siempre que hablemos de un código pequeño, claro)
¿¿¿¿¿en serio??????? Yo esas cosas las he visto con AS2, las vi en Visual Studio 95... Si estás trabajando con PHP Storm, has escrito algo bien y solo funciona al reescribirlo que alguien le de un buen meneo al servidor porque algo está muy muy mal configurado y os van a petar polstergeist cada dos por tres.
¿Y pasaba test, la herramienta de integración continua que tengáis y todo? Tenéis un marrón jugoso, jugoso.
O lo escribiste mal y habrías terminado antes buscando el problema
#16 Algún servicio que no había levantado correctamente o estaba levantando en ese momento.
#16 por cierto yo no podría vivir con la duda de cual era el problema
sin contar que si lo hubieras cazado te hubiera valido para que no te volviera a suceder, o en caso de que te sucediera contemplar la posibilidad de ese error, ahora no sabes ni que era ni cual era la solución, estas condenado a repetir dicho error y la próxima vez se reproducirá de forma aleatoria. Yo de ti acababa con mi vida cuanto antes.
#16 Venga, pega esas tres líneas, que lo estás desando... Ahora nos dejas con la intriga a todos.
EDITO: Una de los problemas más típicos de la situación que mencionas suele ser el uso de una función que no está definida ( está definida en tu local pero no en el servidor, por diferentes versiones de php ).
#50 Pues algo así:
Esto funcionaba en local, y daba error 500 en el servidor
if ( empty( trim( $datos[$e] ) ) )
Al ponerlo así, funciona en ambos
$datos[$e] = trim( $datos[$e] );
if ( empty($datos[$e]) )
#61 empty se usa sobre un Array, y lo estás usando sobre un string ( el resultado de trim ), según lo estricto del servidor, o si realmente el Array está vacío en un sitio o en otro, puede pasar lo que comentas.
Perdón por el StackOverOffTopic
Edito: gracias por pegar el codigo, ya me quedo más tranquilo...
#64 empty no se usa (únicamente) sobre arrays, se usa sobre cualquier tipo de variable, y, desde php 5.5, también se puede usar sobre expresiones.
me da que el problema de #50 era precisamente que en local tuviese una versión >5.5 y en servidor no.
de la doc. de php:
Nota:
Antes de PHP 5.5, empty() sólo soportaba variables; cualquier otra cosa provocaría un error del intérprete. En otras palabras, lo siguiente no funcionaría: empty(trim($nombre)). En su lugar, utilice trim($nombre) == false.
http://php.net/manual/es/function.empty.php
#67 Sí, es el problema original que me imaginaba en #50:
"Una de los problemas más típicos de la situación que mencionas suele ser el uso de una función que no está definida ( está definida en tu local pero no en el servidor, por diferentes versiones de php )"
En este caso, es porque funcionan de forma distinta en distintas versiones, y tu explicación es la correcta.
#16 Yo recuerdo hace años que tenia dos lineas código que hasta el día de mi muerte jurare que estaban bien. Pero fallaba el hijo puta con una excepción genérica indescifrable. Después de mil pruebas ya desesperado puse
try catch (Exception e)
Y funcionaba a la perfeccion. Ni puta idea de por qué. Alguna condicion de carrera o algo raro que al repetirse 2 milisegundos despues ya funcionaba, supongo. Y asi se quedo
#11 Borrarla no, pero comentarla, sí.
#11 En un minuto probablemente no, pero cuando llevas 10 minutos intrigado de por qué el editor te marca en rojo esa línea, lo primero que haces es comentarla, y cuando ves que está ahí el problema, entonces pasas a reescribirla.
#40 No es mi caso y estoy bastante seguro que la mayoría lo que hace es buscar y corregir el error no reescribirla.
Y 10 minutos para encontrar un error en una linea es bastante improbable, o te esta marcando incorrectamente la linea (algo bastante común) y el error esta antes y te estas cegando tontamente con esa linea o no se me ocurre otra cosa que alguien te metiera una troleada como la que se menciona.
#41 Eso es lo que haces cuando no llevas 10 minutos mirando una línea que a todas luces tiene una sintaxis correcta. Cuando ha pasado un tiempo prudente, la reescribes. 1 minuto no, pero más de 10 minutos, si tienes un IDE decente, no le dedicas.
#41 #40 #11 después de 10 minutos mirando y probando una línea de código que aparentemente está bien lo que ocurre es que vas a tener que comprar un ratón o un teclado nuevo, depende del nivel de frustración y de la fuerza con que les acabes dando...
#54 Sobretodo si al final era algo evidente que no veias
#55 siempre es algo evidente que no ves
És como cuando te dan con el coche y dicen "perdón, no te había visto". Joder, es que si me vés y no paras ya te vale!
Bromas a parte, sí, acostumbra a ser algo tan evidente que precisamente por lo evidentemente ni lo habías visto.
En Netbeans señala el ; y explica claramente illegal character: u037E
#modo_aguafiestas
#7 eso te pasa por usar Netbeans
#7 Yo diría que cualquier editor medio normal de los que existen ahora.
Es lo más cruel y malvado que he visto nunca
Como putear a tus alumnos 101
JAJAJA ME PARTO
Ah no espera, que (al igual que el resto de programadores serios) uso un IDE que me avisa al instante de estas gilipolleces.
Buena forma de joderle la mañana al becario
#6 Centenares de becarios lanzándose por las ventanas
Mas viejo que el mear de pie
Un buen IDE te detecta esta mierda (expected semicolon).
Prueba a meter un "alt-255" por el código --- Yo lo suelo utilizar en mis passwords
#14 Como intentes logearte desde UNIX vas a flipar.
#19 En Linux me funciona, unix hace mucho que lo migramos ya
#14 ya sabemos un dígito de tu password
#14 Hace 20 años, le hice la putada del meneo a un amigo pero con el alt-255 en clases practicas de C++, eso si que era difícil de detectar. A las dos horas, se lo arreglé sin que se enterara y todo aquello para él hoy día, fue una experiencia paranormal.
Muajajaja.
cualquiera con un poco de experiencia programando se ha topado con este tipo de problemas y sabe que puede haber algun caracter extraño que incluso no se ve por cuestiones de charsets y demás. Borra el caracter y lo vuelve a escribir, o lo revisa con editores especificos y ya.
Bastaría un 'git diff' para mostrar la manipulación. Esto no engaña ni al becario
Tienes que tener un editor muy chungo para que no te detecte eso 😂
Poco me iba a durar la broma, probándolo en PHPStorm me señala el ; del mal y me dice "Expected: semicolon"
"Programadores" de medio pelo que necesitan un IDE que los rescate de errores. En mis tiempos, el Spectrum lo programábamos a pelo y goma.
Iba a venir a decir eso que algunos compiladores no te lo dejan procesar cuando ay alguna incoherencia
#34 En cambio, te dejan escribir con todas las faltas de ortografía que quieras
... es broma, ya sé que es el corrector o algo así, era por hacer el chistecillo
#34 ay ay ay !
hostia cuanto hijputismo
Eso no es un error es una cabronada. Hoy voy a proteger un código así en el tfs a ver si el compi se da cuenta de porqué falla
Eso no es una broma, es una putada increible.
#51 La verdad es que mola mucho más tu versión
Que chorrada. Como broma, funciona mejor lo de capturar la pantalla, ponerla de fondo y ocultar los iconos.
#27 o lo de matar a su familia, su perro y quemar su casa.
Como las bromas de los del pueblo de Gila
#39 me habéis matado a un hijo, ¡pero lo que nos hemos reído!
En VStudio 2015 no cuela --> Unexpected character ";". Invalid token.
#44 Si no se trata de que cuele o no cuele. En ningun compilador va a colar porque es que ese caracter no es el semicolon normal, es otro caracter diferente y va a dar siempre error de compilación. De lo que se trata, segun el articulo, es de que cuando el compilador diga que no puede, el desarrollador se quede flipando diciendo "¿como que no?" y se "rebane los sesos". Pero como ya he dicho antes y otros ya lo han apuntado tambien, esto no engaña ni al becario. Con un minimo de experiencia sabes perfectamente cual es el problema.
#46 los sesos se 'devanan' ( devanarse los sesos, http://www.wordreference.com/definicion/devanar ), pero si el desarrollador "se rebana los sesos" por un error tan tonto, qué le vamos a hacer...
Hay gente súper dramática
#48 por eso lo he puesto entrecomillado, que hay que "esplicarlo" todo jajaja