#60 n0
#60 Mejor no pierdas mucho tiempo posteando en foros o no te dara tiempo a acabar tu webapp en ensamblador antes de que se acabe el sol.
Reconozco que facilita mucho las cosas con módulos y plugins ya hechos, como este
Pero no, sigue sin gustarme. Y a modo de curiosidad, alguna gran empresa ha basado su desarrollo en un framework? Y más si tiene algún tipo de pasarela de pago, pregunto, no lo sé eh.
#68 No tengo nada en contra del PHP, es solo que me ha hecho gracia lo de "que gran compañia usa un framework?"
#65 Me gustaría saber que relación existe entre el uso de un framework y una pasarela de pago ^.
Reinventar la rueda es muy del S.XX.
Jejeje, me río yo de los frameworks. No es por ser hater, pero ni 10 días con CI y ayer descubrí un bug en su función encrypt / decrypt.
Resulta que al hacer un decrypt de una cadena encriptada con el propio encrypt, al final del resultado mete unos caracteres en ascii "invisibles", que son como cruces raras. PERO NO SE MUESTRAN en ningún sitio. Ilustro con un ejemplo antes de continuar porque es raro de explicar:
- Tenemos esta cadena: ff48dfs9fddklbm13k13d90nsna
- El resultado esperado tras desencriptar es: 2,10
- Hago ctrl + c y ctrl + v del resultado y pega esto: 2,10+++++++++++++++ (las cruces esas de mierda que no son visibles a simple vista ni aparecen por el código)
Prosigo. Digamos que al resultado le hago un explode con el splitter "," y los campos los voy añadiendiendo a una consulta mysql para insertarlos en una tabla.
Tendré en el [0] -> 2 y en el [1] -> 10
Ambos campos en la tabla son del tipo int (importante), ejecuto la consulta y... ERROR. Por qué da error? Si he usado métodos prácticamente iguales para hacer consultas con encriptado y desencriptado y lo hacía bien... Me da por pensar y veo que en las otras consultas anteriores, los campos son de tipo varchar, por lo que esos caracteres especiales (las putas cruces) seguían añadiéndose a la consulta igualmente, pero al introducirse se esfuman, es decir desaparecen. Justo el mismo comportamiento que con mis datos de tipo int, al copiar y pegar las cruces desaparecen a simple vista (pero están ahí).
Con los tipo varchar funciona porque mete esos caracteres invisibles raros a la consulta pero al ser de tipo texto se los fuma y la query entra.
Con los tipo int los caracteres chungos no se los fuma y peta la query.
Solución: cuando el último campo del array es de tipo int hay que añadir el splitter (en mi caso una coma) al final, para que deje toda la mierda de caracteres esos por detrás totalmente ignorados.
Fuck yea! ¬¬
#72 Creo que no es mala idea que dejes de usar un framework abandonado por el desarrollador.
Jejeje, me río yo de los frameworks. No es por ser hater, pero ni 10 días con CI y ayer descubrí un bug en su función encrypt / decrypt.
Resulta que al hacer un decrypt de una cadena encriptada con el propio encrypt, al final del resultado mete unos caracteres en ascii "invisibles", que son como cruces raras. PERO NO SE MUESTRAN en ningún sitio. Ilustro con un ejemplo antes de continuar porque es raro de explicar:
- Tenemos esta cadena: ff48dfs9fddklbm13k13d90nsna
- El resultado esperado tras desencriptar es: 2,10
- Hago ctrl + c y ctrl + v del resultado y pega esto: 2,10+++++++++++++++ (las cruces esas de mierda que no son visibles a simple vista ni aparecen por el código)
Prosigo. Digamos que al resultado le hago un explode con el splitter "," y los campos los voy añadiendiendo a una consulta mysql para insertarlos en una tabla.
Tendré en el [0] -> 2 y en el [1] -> 10
Ambos campos en la tabla son del tipo int (importante), ejecuto la consulta y... ERROR. Por qué da error? Si he usado métodos prácticamente iguales para hacer consultas con encriptado y desencriptado y lo hacía bien... Me da por pensar y veo que en las otras consultas anteriores, los campos son de tipo varchar, por lo que esos caracteres especiales (las putas cruces) seguían añadiéndose a la consulta igualmente, pero al introducirse se esfuman, es decir desaparecen. Justo el mismo comportamiento que con mis datos de tipo int, al copiar y pegar las cruces desaparecen a simple vista (pero están ahí).
Con los tipo varchar funciona porque mete esos caracteres invisibles raros a la consulta pero al ser de tipo texto se los fuma y la query entra.
Con los tipo int los caracteres chungos no se los fuma y peta la query.
Solución: cuando el último campo del array es de tipo int hay que añadir el splitter (en mi caso una coma) al final, para que deje toda la mierda de caracteres esos por detrás totalmente ignorados.
Fuck yea! ¬¬
lo copio y pego para tenerlo para siempre XD
#78 La verdad es que con tus comentarios arrogantes sin ningún fundamento acerca de la utilización de frameworks estás dejando claro lo "buen" programador que eres.
#80 Decir que 'me cago en codeigniter y que un desarrollo desde cero es n veces mejor que un framework' muestra arrogancia, además de ignorancia.
La ignorancia tiene arreglo, se cura aprendiendo.
Tu opinión sobre los frameworks basada en tu supuesta experiencia es lo que te hace parecer un mal programador.
EDIT: Ya te contesté una vez en referencia a este tema y no recibí respuesta, te lo pongo aquí por si no lo viste: Post
#81 si lo vi pero pasé de contestar para no crear una discusión absurda, cosa que está pasando ahora, así que lo hago. Yo fui uno de esos que mencionas que se incorporó casi al final del desarrollo, te hablo de un proyecto de unos 25.000 archivos, y no, no exagero.
Durante los dos primeros días tuve que tener a otro desarrollador conmigo 24/7 explicándome la arquitectura del proyecto. Basta con saber eso para saber desenvolverte. No sé qué problema tienes la verdad, tanto para juzgarme como para evaluarme como programador, y mucho menos para criticar los proyectos desarrollados desde cero por empresas tochas, eso es lo que más me intriga.
¿Reinventar la rueda? Es conocer perfectamente todo lo que hace tu sistema, fin. ¿Acaso tú sabes todo lo que hacen los frameworks por detrás? Y por poner un ejemplo, mi post de #72 , un bug en su propio decrypter que me tiré un ratazo para "adivinar" qué cojones pasaba. En un desarrollo propio, cuando algo falla, sabes instantáneamente por qué. Pero bueno es solo un ejemplo.
Y sí, un desarrollo desde cero, siempre y cuando esté bien diseñado, programado y debuggeado, es mejor que un framework.
#82 El problema es el tiempo invertido. Yo no se tú, pero yo necesito varios proyectos para poder comer y necesito comer para poder vivir.
Pero vaya, ahora no te victimices que eres el primero que ataca a cualquier como si fueses un perrete rabioso. Con 27 años que tienes y los huevos peludos de currar, deberías estar a otros asuntos en vez de a ver quien usa un framework para poder decirlo lo malo que es y lo bueno que tú eres por hardcodear.
Yo también pase por la fase de "dile no a los frameworks" hace un par de años. Ahora me cuesta encontrar razones por las que no utilizar Laravel o Symfony para cualquier cosa.
Como dice #83 el tiempo invertido con un framework es menor que empezar desde cero, seguramente no el primer proyecto, pero mientras tu tal vez sacas un proyecto/desarrollo otro con framework te ha sacado 2 ( números randoms).
Y XXX programadores seguro que ven mejor que tu solo, a esto me refiero que un framework que usa más gente seguro que es más estable, que la programación que pueda hacer uno mismo.
Que no te gustan los frameworks, bien, pero cuando te pidan "rendir" en medidas de tiempo, vas a estar limitado, antes que uno que tire de framework seguramente.
#82 Hablas de tus frameworks como si los hicieras tu solo pero luego lo mezclas con entornos colaborativos. Lo dices como si conocieras a la perfección todo lo que hacen tus compañeros y como si vuestro código fuese limpio, casto y puro. Y seguro que también documentais todos de puta madre.
Estoy de acuerdo en que el código de uno mismo es lo mejor del universo (excepto cuando lo retomas varios meses después y te das cuenta de que eres un inútil y un vago). Pero entre el código de un compañero y el de un framework, el 99% de las veces me quedo con el framework.
#82 yo era como tú hace 3/4 meses hasta que me di cuenta del tiempo que perdía con el tema de interacción con la db y el rollo de la autenticación. Cuando con un framework son poquísimas líneas de código activar estas dos funciones básica y a parte que el código es 100 veces más sostenible que el mío de lejos.
Precisamente cuando el proyecto es muy grande, el framework te va a hacer la vida muchísimo más fácil. Si lo haces con un framework específico consigues que esa parte común que tienen todos los proyectos tenga un código revisado, documentado y mantenido por un equipo de personas que se dedican a fondo a ello.
De esta manera, cuando un tío nuevo en el equipo tenga que encontrarse con el monstruo que tenéis allí montado en vez de necesitar 48 horas con un senior para ponerle a medio currar podrá apañárselas mucho mejor el solo si habéis hecho un buen desarrollo siguiendo las convenciones y utilizando el framework como dios manda.
Yo en particular, SI conozco el framework con el que trabajo, además de haber hecho pequeñas contribuciones a su core. Porque me gusta saber como funcionan las cosas del framework que utilizo y puedo hacerlo porque está bien documentado y con un código que a muchos de nosotros ya nos gustaría poder tirar a la primera.
Existe el monkeypatching y si sabes como funciona el framework y hay partes que no te molan o convienen puedes moldearlas a tu gusto.
Porque eso de "conocer perfectamente lo que hace tu sistema" se podría aplicar a bajisimo nivel y entonces tendrías que montarte tu propia máquina, hacerte tu sistema operativo, etc. Conocer perfectamente tu sistema no es hacer algo desde abajo sin frameworks, conocer perfectamente tu sístema es conocer a fondo el lenguaje en el que trabajas, es saber la arquitectura de la aplicación, es conocer las reglas de los paradigmas para saber como seguirlas y cuando saltarselas, además de conocer el framework con el que trabajas todo lo posible.
Yo he trabajado en grandes proyectos para empresas muy tochas y si llego a soltar tus argumentos al CTO me hubiera largado de una patada directa en el ano a la cola del paro.