Portada
mis comunidades
otras secciones
#5:
#4 Meneame empezó a programarse antes de que PHP tuviese una implementación a objetos seria... Y ha seguido creciendo con esa filosofía. Y no tener una separación MVC estricta y que la mayor parte del código se ejecute a modo scripts... Funciona, pero el coste de desarrollar nuevas funcionalidades es altísimo.
Comentarios
Menéame es una puta mierda, pero es mi puta mierda.
#13 Estaba inspirado en Digg, pero programado desde cero.
#0@admin despues de leer el código de menéame, y el de este repo, yo tendría muy claro que el camino a seguir es migrar todo el core cueste lo que cueste si se quiere seguir manteniendo.
Otra cosa es que se este ahorrando para el ferrari
#1 Me lo tomo como un halago.
#2 Aunque prefiero otras alternativas a Symfony como framework, lo cierto es que ayuda y mucho a sabiendo donde deben de estar las cosas a encontrarlas. Además por suerte PHP ha evolucionado muchísimo desde que se creó esta plataforma... Pero muchas de esas mejoras no se encuentran en un código que lleva desde PHP ¿3? Creciendo https://github.com/gallir/Meneame?files=1
#3 Por lo que veo en el composer.lock parece que usan la 5.3 de PHP. Yo sólo domino PHP como lenguaje de servidor (bueno, y Javascript en Nodejs), así que no puedo comparar con otros lenguajes como Java. Lo que sí sé es que PHP ha mejorado muchísimo el rendimiento con la versión 7 (es el doble de rápido más o menos). Respectro a Symfony lo mismo, no uso otros frameworks para PHP pero utilizo Symfony desde hace muchos años, y una vez lo dominas es muy práctico. Y aprovecho para recomendar a@admin que actualicen a PHP7, que es no es complicado y realmente vale la pena: http://php.net/manual/es/migration70.php
#4 Meneame empezó a programarse antes de que PHP tuviese una implementación a objetos seria... Y ha seguido creciendo con esa filosofía. Y no tener una separación MVC estricta y que la mayor parte del código se ejecute a modo scripts... Funciona, pero el coste de desarrollar nuevas funcionalidades es altísimo.
#5 Ya veo. Realmente poco escalable. El Ferrari pesa supongo.
#6 lo que #5 describe no hace al programa mas o menos escalable. En todo caso lo hace mas o menos mantenible y extensible.
#8 Sí, tienes razón. Para añadir funcionalidades podrías ir añadiendo scripts en este caso. Gracias por el apunte.
#8 Quería decir que incluso es posible que no sea menos extensible. Menos mantenible seguro.
#5
Y no tener una separación MVC estricta y que la mayor parte del código se ejecute a modo scripts...
MVC no es la única forma de organizar los módulos o componentes lógicos de tu programa.
De hecho, muchos arquitectos defendemos que es un patrón viejuno y que hay muchas mejores formas de hacer las cosas.
Sobre lo de la ejecución a "modo de scripts", eso es un detalle implementátivo de la plataforma, y creo que la forma de ejecución del programa no tiene nada que ver con su arquitectura.
#5 menéame no era un fork de digg?
#4 #3 la versión actual soporta desde PHP 5.3 a 7.2. Actualmente desarrollamos con PHP 7.2 como base.
Hay que tener en cuenta que es un software muy muy viejo, creado como un experimento y con un modelo muy complicado de extender, pero pasarlo todo a un framework (yo personalmente uso Laravel 5.6) podría/será una locura.
#10 yo no sé como os lo montaís con los 100.000€ de ganancias; pero te sobra para reconstruir Menéame en menos de 6 meses (y tocándote los huevos). Faltan ganas y visión de futuro, total, con el script que es Menéame se podría aguantar otros 10 años. Y en ese sentido le doy la razón a
dseijo: para qué, mejor monto una 'tienda'en wordpress que vende productos de Amazón. Es la filosofía del emprendendor cuñao.
#12 100.000 ganancias, 0 beneficio. Son dos conceptos muy distintos.
Un pequeño comentario, viendo ficheros como este:
https://github.com/msalsas/MsalsasVotingBundle/blob/master/Tests/Entity/VotePositiveTest.php
Los seters y los geters, igual que los constructores no se testean, por que testarlos no proporciona ningún feedback. Además, si te empeñas en testearlos (no deberías), intenta usar un assert lógico por test, de esta forma, cada test testea un caso concreto, no una amalgama de cosas.
Al obligarte a hacer un assert lógico por test, eleva el coste de testear clases acopladas, donde proliferan de forma exponencial los posibles casos, como consecuencia de su acoplamiento o de sus multiples responsabilidades. Elevar ese coste es interesante, puesto que aumenta el feedback recibido en esos casos.
#9 Gracias por tus consejos. Los tendré en cuenta. Precisamente tengo pendiente refactorizar y mejorar los tests.