![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
Siguiendo el ejemplo de movorack, si tienes el directorio
Código:
/photos/2010/04/33025/img1.jpg Código:
http://tuservidor.com/photos/2010/04/33025/img1.jpg Código:
deny from all Código:
http://www.terawiki.clubdelphi.com/archivos/Delphi/Tools/CloneDelphiWizard.zip Código:
http://www.terawiki.clubdelphi.com/archivos/Delphi/Ejemplos De todas formas, hay que tener en cuenta, que el Apache debe estar configurado para procesar archivos .htaccess. // Saludos |
|
#2
|
||||
|
||||
|
Ya entiendo, me dice que no tengo permisos.
Ya puedes dejarlo como estaba ![]() Por cierto, aunque no lo he hecho yo directamente, sí he colaborado en bastantes cosas de un proyecto parecido que hicimos en mi trabajo hace varios años. Era, y es, como un sistema de ventas con carrito de la compra, navegas por los artículos, ves las fotos, las amplias, etc. y haces el pedido de las unidades que quieras. Está hecho en php con firebird y los datos de los artículos y los pedidos los almacena directamente en el otro servidor, donde está la gestión comercial de la empresa. Pero yo no "piqué" el código. En este caso me tocará a mí, seguro. La principal diferencia es que este nuevo proyecto es prácticamente todo fotos, es lo principal, y es también el motivo de pensar no almacenarlas en la base de datos, porque un millón de fotos a sólo 1 mega por cada una son... un millón de megas. Pues no sé cómo hice las cálculos, pero había sacado mucho más, si es así entonces sería sólo 1 giga de base de datos. Creo que me equivoco en algo.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#3
|
||||
|
||||
|
Algo de lo que no hablas es cuantos accesos concurrentes hay, cuales son los parametros de confiabilidad y tiempo en linea y como rayos se manejaran los backups!
Puedes leer algo general sobre hacer aplicaciones escalables y robustas aqui: http://www.slideshare.net/mmalone/sc...django-1393282 (Es en django, que es lo que recomendaria pa usar: PHP es como usar C++, con la legibilidad del PERL... pero bueno son lecciones que se pueden aplicar a lo que sea, esta desactualizado en cuanto no hay nada maduro en Nosql, ahora SI). Con respecto a lo de las imagenes, la mejor explicacion sobre este tema y todos los demas la vi aqui: http://www.slideshare.net/fbrunel/ja...rlin-sept-2007 (Es una presentacion larga pero ponle mucho cuidado a donde arranca en "Pay attention in how you store the files" y muestra las diferentes estrategias.) Yo hosteo en www.joyent.com y me ha ido bien, y esta gentes es muy experta en estos temas. Valdria la pena que tal como recomiendan en la presentacion, evaluaras opensolaris/zfs/zones como infraestructura.... El manejo de los archivos, si terminan siendo masivos, depende mucho de que tan bueno sea el array de almacenamiento en red. Otra alternativa, es no usar un BD relacional sino una NOSQL (ya te mencionaron algunas) pero estoy usando MongoDB con GridFS (http://api.mongodb.org/python/1.4%2B...dfs/index.html) que es su API para almacenamiento MASIVO y GRANDE de archivos. Mongo hace backuos en caliente, o mejor dicho, prendes otro servidor, lo metes en la lista, se sincroniza y apagas. Tambien hay un metodo de hacer backup de forma tradicional. Es muy bueno! Pero el chiste en este caso es que tengas al MENOS 2 servidores que se repliquen entre si (Mongo es muy != a BD relacionales, replicacion es algo natural y sin lios). AL usar Mongo, no hay problemas de como rayos almacenes los archivos. Y NO TIENES QUE ABANDONAR LA BD. Puedes acceder a la BD de mongo usando cualquier driver (hay para python, php, .net, etc) para el manejo de archivos y la BD pa lo demas. Mongo es lo que usa SourceForge. Una unica advertencias: Mongo en un solo servidor no es "confiable" en el sentido que se pueden perder datos si hay un crash (=MySql sin transacciones). Los desarrolladores de Mongo apuntan a que la unica forma confiable es federar los datos, y en cierta forma tienen razon. Lo que me lleva a que me parece MUY mala idea hostiar "en casa". Como muestra la presentacion de joyent, hay tantas cosas que hay que hacer bien que me parece mejor usar un proveedor externo (amazon, joyent, mediatemple, etc...). De lo contrario, buenas UPS, servidores redundantes, buen sistema de almacenamiento en RAID (o mejor aun: Solaris+ZFS). La BD? Pa lo que mencionas cualquiera daria la talla, excepto por lo de los archivos. Hay o Mongo o ZFS u otro sistema de archivos robusto + estrategia de almacenamiento. Prueba ademas, usar Cherokee (mas rapido que apache) y/o nginx (mas veloz para servir archivos estaticos. Si no tienes una carga alta por segundo, con cherokee creo que matas todo de un solo tiro. http://www.cherokee-project.com/doc/ Muestra que tienes proxy reversos, balanceos, modulo para generar links a archivos temporales (lo que impide el lio que menciona roman) y mas cosas con lo que 1 solo servidor te cubre como a 5. Una BUENA aplicacion web, usa URLS que no estan ligadas al sistema de archivos (o url limpias o bonitas como le llaman). Con django/rails es lo normal que las URLs representen el mapeo a las vistas asi que no hay nada de eso de usar .htacces y cosas asi raras (y es comun usar un servidor web independiente, no apache, para servir archivos).
__________________
El malabarista. |
|
#4
|
||||
|
||||
|
Je, je. Sé que PHP te causa roña, pero mira que compararlo con PERL
![]() Una cosa, todo esto que planteas es interesante, pero, ¿no estamos aplicando algo así como el anti-KISS principle? Es decir, se trata de una aplicación donde básicamente sólo hay que subir fotos con unos cuantos datos extra. Por otra parte, esto de que con django/rails te olvidas de usar .htaccess está por verse. Esto es, no mezclemos cosas. Si tu servidor web es apache, por más que uses django o rails, los archivos está ahí al alcance de todos, a menos que lo impidas. // Saludos |
|
#5
|
||||
|
||||
|
Son muchas opciones, posibilidades, formas, lenguajes, sistemas, etc... y casi que complica más conocer tantas opciones que no saberlo
![]() No lo he dicho antes, según pregunta mamcx, teniendo en cuenta las actuales llamadas de teléfono, los emails y fax que reciben, (que es el sistema que usan actualmente para las incidencias) se ha hecho un cálculo que indica que serán entre 100 y 200 conexiones simultáneas constantes las que recibirá el sistema. En principio, aunque nuestro cliente quiere montar el servidor en sus oficinas, yo creo que se le convencerá para no hacerlo así, se contratará un VPS en algún sitio que vaya bien, o un servidor dedicado. La idea es instalar un linux server, seguramente debian o ubuntu y sistema de arhivos ext4, el servidor web será cherokee con casi toda seguridad. Todos los servidores que hemos montado desde 1998 llevan Linux y en ese aspecto estamos muy seguros. El programa web inicialmente se había pensado: php + firebird + fotos (dentro/fuera) Lo de php no me convence demasiado, pero tampoco quiero perder mucho tiempo en aprender algún lenguaje "raro", y php por lo que he visto está muy documentado. Lo de las fotos, ahora que he pensado en el tamaño, tampoco me parece muy excesivo, porque aunque guardaran todas las fotos a 10 megas, la base de datos tendría 10 Gigas con un millón de fotos. Ahora mismo están manejando en red local una base de datos de algo más de 20 Gigas. Algo que sí tengo en duda es, suponiendo que se use php, ¿existe algún "componente" para manejar firebird que no sean los propios controladores que trae php?. Otra cosa que no he comentado es que se pretende que la página web sea "moderna", ágil, fácilmente modificable para poner cosas nuevas, alguna oferta temporal, información variada, encuestas a los usuarios, etc. y que sea cómodo de poner y quitar esas cosas, estilo de como se hace con los "plugins" de blogger, wordpress y sitios así. Ahora mismo, aparte del lenguaje a usar, lo que más me preocupa son las fotos (dentro/fuera), ya que el sistema que se ha comentado más arriba, lo de thumbnail me parece estupendo para no estar moviendo imágenes enormes.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#6
|
||||
|
||||
|
Si el proyecto no es para ayer, ¿por qué no te planteas usar Python? Sirve que nos enseñas
![]() En cuanto al hosting, conozco cierto proveedor que es muy bueno ![]() // Saludos |
|
#7
|
||||
|
||||
|
Cita:
Cita:
![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#8
|
||||
|
||||
|
Pegate una mirada a http://www.djangoproject.com/. Se podria decir que por mucho, es la razon por lo que mas de uno empezo en python
![]() En cuanto al lenguaje, es como lo mas parecido en cuanto a Delphi sobre el hecho de que es FACIL de leer. La comunidad de python premia la legibilidad, como en Delphi. No existe eso de mezclar html, css, js, python, todo a la vez (no por defecto, como en php). Lo que lleva a que el codigo sea de muy facil mantenimiento. Tiene muchas buenas cualidades, pero es dificil apuntarse solo a una. La legibilidad seguro es el #1, luego vienen un monton de cosas que se van juntando. Un argumento en contra de PHP? Pues python es MAS potente. De seguro. Pensar en php sin web? no. Pensar en python sin web? Claro!. Es posible hasta hacer aplicaciones de escritorio, y hay unas muy buenas (pero en OSX, las que conozco). PHP cuando hay que hacer algo fuera de su core, pues toca meter c u otra cosa. Un punto en favor de PHP? Es como el VB: Todos y todas lo usan, y se despliega en cualquier cosa, en hosting mediocres sin problemas. Tambien, que PHP es directo web. No hay que usar un framework como django (o turbogears, o pylons, u otro) para hacer tu primera paginita web. Con todo, lo que hablas de carga y demas no descalifica aPHP en lo absoluto. Igual en manos competentes es una buena eleccion. ---- Aunque el peso de las imagenes no es nada excesivo, de todas maneras es bueno tener en cuenta las recomendaciones de la presentacion que te pase. Es muy facil degradar el sistema de archivos si no se particiona el almacenamiento de las imagenes. Ademas, seguro hay muchas otras como los thumbails que hacen sumar. Servir muchos archivos chicos es tan dificil como pocos grandes. Una ultima recomendacion? Usa algo como http://www.balsamiq.com/products/mockups/desktop para hacer sketchs de la aplicacion, irse derecho con cherokee, probar desde el principio con MUCHAS imagenes (es posible generarlas o usar un banco de imagenes), ten listo el plan de emergencias (backups) y haz la aplicacion simple. A veces (y esto es pa roman ) el uso de herramientas diferentes, plataformas, tecnicas, etc, conduce a lo simple. La parte dificil es elegir, entender y probar, pero hay ganancia en ver como lo resuelven otros y porque elegieron lo que eligieron.
__________________
El malabarista. |
|
#9
|
||||
|
||||
|
Cita:
Aqui se me prendio la alarma de una! Una cosa es una cosa (sistema realmente importante de fotos) y lo demas es lo demas (CMS de entretenimiento al departamento de ventas y demas). Es caracteristico de los usuarios querer que su sistema (por ejemplo) de contabilidad ademas le mande cartas de felicitaciones animadas en gif a sus clientes, envie mails masivos y controle el marketing viral en facebook. Lo he vivido! De entrada, yo diria que no. Si tu cliente quiere eso, pues hombre, que monte wordpress y listo el pollo. Y como metes a tu sistema? Ah, facil. Pa eso puedes: - usar un dominio como appfotos.tucliente.com - Compartir la BD de usuarios y/o utilizar un sistema federado como OpenID, o LDAP o una BD central omlo que sea. - Usar un API rest en tu aplicacion, para poner lo relevante en el CMS e integrar con plugins alla - O permitir enlazar con IFRAME segementos de codigo html, para mostrar widget y pendejadas de esas. No mezcles ambas cosas. Te saldra un chicharron tremendo. Usa un CMS probado pa contentar a tu cliente e implementa libre de ataduras el sistema que REALMENTE te estan solicitando.
__________________
El malabarista. |
|
#10
|
||||
|
||||
|
Por cierto, python puede usar firebird sólo en windows.
Otro detalle: todo debe ser software libre. Cada vez estoy más confuso ![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#11
|
||||
|
||||
|
Cita:
Cita:
__________________
El malabarista. |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Consejos para empezar con firebird | seoane | Firebird e Interbase | 21 | 22-03-2007 05:14:33 |
| Consejos para última compilación | Pedro-Juan | OOP | 2 | 14-03-2007 20:44:11 |
| Consejos para ahorrar. | marcoszorrilla | La Taberna | 3 | 03-02-2007 01:59:55 |
| Obtener información de Proyecto DLL (ProductVersion) | ContraVeneno | API de Windows | 2 | 02-02-2007 19:30:15 |
| Consejos para ventanas modales ? | Tecnic2 | OOP | 14 | 16-10-2006 22:37:20 |
|