Configuración para un mejor performance en apache

febrero 21, 2008 at 8:24 pm (ajax, Desarrollo Web General, html, WAS)

Que tal a todos se preguntara porque hay tan poco tiempo entre los post que he publicado, esto porque ya tengo preparada la información, por lo general redacto el articulo y después lo publico, bueno en fin en este post les dejare una de las posibles configuración para mejorar el rendimiento de una aplicación web atraves del Apache, espero encuentren este mini artículo de utilidad.

 

Para
obtener un mayor rendimiento de nuestras aplicaciones he llegado
através de la información que proporciona yahoo con el
yslow para firefox a la siguiente configuración del apache
para producción, esta configuración es muy útil
si estás construyendo una aplicación con AJAX, o en si
para cualquier tipo de aplicación.

Estas
lineas de configuración montan el cache en apache, agregan
compresión a los responses del servidor por medio del deflate,
y agrega la cabecera expires para guardar cierto tipo de archivos del
lado del cliente.

Para
modificar la configuración del apache tenemos que modificar el
archivo httpd.conf

#montar
modulo de cache para el apache

LoadModule
cache_module modules/mod_cache.so

<IfModule
mod_cache.c>

<IfModule
mod_disk_cache.c>

CacheRoot
“C:/Archivos de programa/Apache Software
Foundation/Apache2.2/cache”

CacheSize
1000000

CacheEnable
disk /ebcomm2

CacheDirLevels
5

CacheDirLength
3

CacheDefaultExpire
3600

CacheIgnoreCacheControl
On

CacheMaxExpire
31536000

</IfModule>

</IfModule>

#
Configuracion del modo deflate y gzip para compresion de datos

SetOutputFilter
DEFLATE #filtro por el que saldran los responses

SetInputFilter
DEFLATE #filtro con el que se tomaran los request

BrowserMatch
^Mozilla/4 gzip-only-text/html #tipo de compresion de acuerdo al
navegador

BrowserMatch
^Mozilla/4\.0[678] no-gzip

BrowserMatch
\bMSI[E] !no-gzip !gzip-only-text/html

SetEnvIfNoCase
Request_URI \

#Cargar
modulos para agregar header expires a los archivos

LoadModule
expires_module modules/mod_expires.so

ExpiresActive
On #Activa el expires header

ExpiresByType
application/x-javascript “now plus 1 years 1 minutes”
#guarda en cache los archivos tipo application/x-javascript

ExpiresByType
image/gif “now plus 1 years 1 minutes”

ExpiresByType
image/jpeg “now plus 1 years 1 minutes”

ExpiresByType
text/css “now plus 1 years 1 minutes”

ExpiresByType
image/png “now plus 1 years 1 minutes”

ExpiresByType
text/js “now plus 1 years 1 minutes”

ExpiresByType
text/javascript “now plus 1 years 1 minutes”

Permalink Dejar un comentario

SQL Best Practices

febrero 21, 2008 at 8:22 pm (otros)

 Que tal Buen día a todos, hoy me dí a la tarea de escribir un poco sobre la utilización de SQL en general quizá no abunde mucho en el tema pero espero que los comentarios les sean de utilidad al planear sus querys.

Al
trabajar con SQL ya sea SQL Server, Oracle, o MySQL tenemos que tener
en cuenta ciertos puntos considerados como mejores prácticas
sin importar sobre que servidor estemos trabajando, esto nos ayudara
a optimizar nuestros tiempos en la base de datos y generar código
mas legible y mantenible, los puntos considerados como best practice
son los que a continuación les menciono.

1.-
Siempre utiliza joins explicitos, es decir si queremos hacer un INNER
JOIN tecleamos o nos aseguramos de ponerlo así, INNER JOIN y
no con un simple JOIN, tampoco se debe de usar los coma JOIN, si se
quiere utilizar se debe de utilizar un CROSS JOIN así ya se ha
hecho consientemente esa decisión, además las
condiciones de un JOIN deben de ir en un ON o en un USING, las
condiciones de un JOIN no deben de ir en el WHERE.

2.-
Siempre utiliza parantésis para separar tus consultas así
sera más fácil distinguirlas por ejemplo

WHERE
(X=1) AND (Y=2)

WHERE
X=1 AND Y=2

3.-
Siempre hay que definir los nombres de los campos, no hay que
utilizar SELECT *, o el INSERT INTO tabla VALUES.

4.-Siempre
utiliza el timestamp del servidor, los servidores web pueden tener
fechas distintas o pueden ocasionar problemas con las fechas.

5.-
Los reportes por lo general tienen el mayor cuello de botella en el
tráfico de red, si se va a recibir información es mejor
recibirla en partes,

6.-
Limitar el uso de subconsultas correlacionadas, a menudo pueden ser
sustituidos con un JOIN.

7.-
Los JOIN no son necesariamente recursos intensos si se cuenta con
buena indexación, la mayor parte del tiempo un esquema
desnormalizado sin JOIN termina siendo peor que un esquema
normalizado con JOINs.

8.-
Trata de siempre escribir las instrucciones con mayusculas para poder
hacer una distinción en nuestros querys.

Espero
que esta información les sea de utilidad.

Saludos.

Permalink Dejar un comentario

HTML 5

enero 25, 2008 at 8:31 pm (html)

Que tal buen día a todos en el transcurso de estos días por medio de algunos blogs como ajaxian me entere que la W3C ha liberado las especificaciones técnicas del HTML 5, y al estarlas revisando me he encontrado con algunos tags bastante interesantes y netamente pensados o altamente utilizables para las redes sociales y en si para toda la web 2.0.

 

Algunos de los elementos que podemos encontrar dentro de este draft de la documentacion de HTML 5 son por ejemplo: 

  • article

  • dialog 

  • figure 

  • audio y video 

  • embed 

  • time 

  • canvas

  • command 

  • datagrid

  • event-source

  • progress

Y una modificacion especial para los elementos <input> ahora puedes asignarle como atributo lo siguiente:

  • datetime
  • datetime-local
  • date
  • month
  • week
  • time
  • number
  • range
  • email
  • url

En fin estas son algunas de las modificaciones que se vienen con html 5, para los que tengan tiempo denle un vistazo a este draft de las especificaciones del html

working draft HTML 5

Permalink 1 comentario

14 reglas para el alto performance de un sitio web

enero 16, 2008 at 8:29 pm (ajax, css, Desarrollo Web General, html, javascript, WAS)

En unos de mis tantos paseos por internet me encontre con una herramienta para firefox 1 y 2 que se llama yslow, esta herramienta realiza un chequeo de 14 puntos que la gente de la sección de performance de yahoo determino como mejores prácticas al momento de estar desarrollando sitios web. Después de haber probado por algunos días esta herramienta la recomiendo ampliamente ya te da una idea muy clara de que es lo que tienes que hacer con tu sitio si es que aun no lo has hecho, o bien si en este momento no desarrollas en web, creo que sería importante que tomáras estos puntos en cuenta para tu próxima aplicación. A continuación les dejo los 14 puntos y un enlace donde pueden obtener mayor información.

  1. Realizar un menor número de HTTP Requests
  2. Utilizar un Content Delivery Network Se refiere a utilizar un CDN para seleccionar la ubicación más cercana al usuario para entregarle el contenido del sitio.
  3. Agregar Expires Header Este tipo de cabeceras se agregan en el servidor web (por ejemplo en apache web server)
  4. Comprimir los componentes en Gzip 
  5. Insertar las CSS al inicio de la página
  6. Mover los Scripts al final
  7. Evitar las expresiones en CSS
  8. Hacer los JavaScript y CSS externos
  9. Reducir las busquedas de DNS
  10. Minificar JavaScript
  11. Evitar los redireccionamientos
  12. Remover los scripts duplicados
  13. Configurar ETags
  14. Hacer que Ajax sea cacheable(que se guarde en cache)

Saludos, espero que tengan un buen día.

Permalink 2 comentarios

Javascript log

enero 9, 2008 at 4:03 pm (javascript)

Buen día a todos, desde hace tiempo que tenía este código para generar un logger para javascript, este logger imprime mensajes en una pantalla popup. Creo que esta pequeña funcion que vemos a continuación les sera de utilidad a muchos de los que tenemos que programar en javascript ya que no siempre se puede contar con un log de donde estan ocurriendo los errores, más sin embargo aun sigo recomendado que lo mejor es utilizar firebug ya que cuenta con un mayor número de herramientas.   function log(message) { if (!log.window_ || log.window_.closed) {
var win = window.open(“”, null, “width=400,height=200,” +
“scrollbars=yes,resizable=yes,status=no,” +
“location=no,menubar=no,toolbar=no”);
if (!win) return;
var doc = win.document;
doc.write(“<html><head><title>Debug Log</title></head>” +
“<body></body></html>”);
doc.close();
log.window_ = win;
}
var logLine = log.window_.document.createElement(“div”);
logLine.appendChild(log.window_.document.createTextNode(message));
log.window_.document.body.appendChild(logLine);
}
Para imprimir los mensajes en el log lo único que tenermo que hacer es llamar a la función log() dentro de tu código.
for (var i = 0; i < 10; i++) {
log(“This is log message #” + i);
}   Bueno pues espero que les sea de utilidad, no olviden estar poniendose en contacto con nosotros por medio del correo electrónico para tratar de postear sobre temas más diversos y que sean de interes para todos ustedes.  

Permalink Dejar un comentario

explicando GWT

enero 4, 2008 at 4:19 pm (ajax, Frameworks integration, javascript)

Vía ajax hispano me encontre con este artículo que les dejo a continuación para que lo chequen a mi me parecío muy bueno por eso se los pongo a su disposición.

Saludos y empezamos nuevo año con ganas renovadas.

google tool kit frame work ajax creacion sitios web java españolMe hago eco de uno de los
mejores artículos que he leído sobre el tema de google toolkit, he visto
conveniente citarlo aquí antes de hacer algo que seguramente no dejaría tan
claro. Un especial agradecimiento a Edgardo Balduccio de gadmonks por este fantástico
artículo.

Google lanzó su Google Web Toolkit
(ver los Destaques del día) y eso me produjo dos sensaciones opuestas:

1. Alegría. Que el creador de Gmail ponga a disposición un
framework completo (quizá el propio) para desarrollar aplicaciones en AJAX en su
estilo -único- es muy gratificante para aquellos desarrolladores que apreciamos
la manera en que Google hace las cosas.

2. Cierta decepción. Cuando bajé el framework, lo “instalé” (está entre comillas porque la
instalación se remite a ser copiado al disco duro en una carpeta cualquiera) y
ejecuté su aplicación de prueba (pueden verla funcionando aquí mismo) percibí que está íntegramente orientado al
lenguaje JAVA. Lo primero que pensé es en mis clientes (podría ser de mucha
utilidad), pero lamenté el hecho de que ese entorno resulta impopular a la hora
de ser integrado en weblogs y aplicaciones simples en PHP.

Aún así, para aquellos que estén interesados en la mecánica de este nuevo
regalo de google, me permitiré explicar algunos detalles de su
funcionamiento.

Requisitos

  • Java: Sun Java 2 Runtime Environment 1.4.2+ [Download]
  • Sistema operativo: Windows XP, Windows 2000, o Linux w/
    GTK+ 2.2.1+
  • Hardware: ~100MB de espacio en el disco, 512MB RAM

Cómo funciona

El GWT funciona de dos maneras:

1. Hosted mode

Este modo de ejecución es a través de un Apache
Tomcat
que viene incorporado y sirve para debuggear la aplicación
en ciernes. Para ver cómo funciona este modo de ejecución, escojeremos el mismo
ejemplo que mostramos aquí (Kitchen Sink); deberemos entrar en la carpeta
samples, luego en KitchenSink y ejecutar el archivo
KitchenSink-shell.cmd. Este comando iniciará el servidor de
aplicaciones Tomcat y abrirá un navegador (¿vieron? Google ya tiene su
navegador, aunque sea para probar sus aplicaciones) que apuntará a nuestro
localhost en el puerto 8888 (para no interferir con otros servicios
http que podamos tener activos) con la aplicación en ejecución (si quieren ver
la aplicación -de nuevo- está aquí publicada en Gadmonks).

2. Web mode (compilado)

Fíjense que existe otro archivo “cmd”:
KitchenSink-compile.cmd. Ejecuten este comando y verán cómo el
framework compila la aplicación y la guarda dentro de una carpeta llamada
www en la que encontraremos otra con el nombre completo del
package java (en este caso www\com.google.gwt.sample.kitchensink.KitchenSink).
Dentro de esta última carpeta veremos algunos archivos HTML y XML que conforman
a la aplicación que podrá ser ejecutada desde cualquier navegador sin necesitar
del TOMCAT, pues -aunque resulte difícil entenderlo-, traduce todo el código
puro JAVA a javascript.

Estructura

El GWT genera archivos para Eclipse, aún así la programación puede ser efectuada a través
de cualquier IDE Java (yo me acostumbré a usar el JDeveloper de
Oracle, es gratuito y puede bajarse directamente desde la web).
Estas herramientas nos permitirán realizar el debug de la aplicación, es decir,
verificar el recorrido del código en ejecución para detectar errores
eventuales.

Para crear una nueva aplicación, usaremos el comando applicationCreator.cmd
(es necesario tener una ventana de línea de comandos abierta pues requiere de
argumentos y en ella se nos informa dónde están guardados los archivos que
fueron generados). El argumento de este comando es el nombre que le daremos al
package, por ejemplo:

CODE:

  1. applicationCreator
    com.blogatronica.client.Prueba

El client es necesario, si no, nuestro proyecto no será
creado y dará un mensaje de error.

El comando generará una serie de carpetas, de acuerdo con el nombre de
nuestro package (en java siempre es así) dentro de la carpeta src en el
path del framework. En nuestro caso, el path será:
src\com\blogatronica\client y
src\com\blogatronica\public.

Dentro de public encontraremos el archivo Prueba.html y
dentro de client el código fuente en java, un archivo llamado
Prueba.java.

En Public.html está la llamada al javascript que será
generado en la ejecución (gwt.js), tanto en Host mode como en Web mode. Este
javascript será el que gerenciará todo el código generado.

La aplicación generada de prueba es el típico Hello world! que
aparecerá luego de que apretemos un botón. Para ejecutarla, pueden ver que el
framework generó en su path tanto el archivo de ejecución como el de
compilación, en este caso Prueba-shell.cmd y
Prueba-compile.cmd.

El archivo Prueba.java funda la clase de esta manera:

JAVA:

  1. public class Prueba implements EntryPoint {
  2. /**
  3.    * This is the entry point
    method.
  4.    */
  5. public void onModuleLoad() {
  6.   final Button button =
    new Button(“Click
    me”
    );
  7.   final Label label =
    new Label();
  8.   button.addClickListener(new ClickListener() {
  9.     public void onClick(Widget sender) {
  10.       if (label.getText().equals(“”))
  11.         label.setText(“Hello
    World!”
    );
  12.       else
  13.         label.setText(“”);
  14.     }
  15.   });

El código es muy simple, si cuando apretamos el botón el label está
vacío, escribirá “Hello world!” si no, sacará lo que está escrito y lo dejará
vacío. Pueden ver el ejemplo publicado aquí también.

Cuando el código es compilado, genera un archivo de javascript para cada
navegador, y describe a los navegadores de la siguiente manera (en el archivo
*nocache.html):

JavaScript:

  1. window["prop$user.agent"] = function() {
  2. var v = window["provider$user.agent"]();
  3. switch (v) {
  4.   case “ie6″:
  5.   case “moz”:
  6.   case “oldmoz”:
  7.   case “opera”:
  8.   case “safari”:
  9.     return v;
  10.   default:
  11.     parent.__gwt_onBadProperty(“com.blogatronica.Prueba”, “user.agent”, ['"ie6"', '"moz"', '"oldmoz"', '"opera"', '"safari"'], v);
  12.     throw null;
  13. }
  14. };

Podemos ver que los navegadores soportados son el Explorer, Mozilla, Netscape
(oldmoz), Opera y Safari.

Conclusión

Estas descripciones no esperan ser un detalle exhaustivo del funcionamiento
del GWT, sí acercar a los desarrolladores interesados -por querer usarlo o por
curiosidad- el mecanismo primario de un framework que podría facilitarle la vida
a más de uno a la hora de desarrollar alguna aplicación que nuestro trabajo nos
traiga a las manos. La versión es beta y en el sitio indica que esperan el
feedback de la gente para ajustarlo. A mí me pareció, en las pocas pruebas que
hice, muy estable, en ningún momento dio ningún error. Para los que prefieran
alguna cosa más fácil, les recomiendo el Google Page
Creatorv

Permalink 2 comentarios

Instalando Tomcat 5.5.x en Linux

diciembre 21, 2007 at 7:04 pm (linux)

 

En esta seccion descargaremos e instalaremos el Apache Tomcat 5.5.15, para esta descarga no es necesario construir el paquete desde el codigo ya que descargaremos la versión binaria.

1.- Descargamos la versión binaria de nuestra preferencia del siguiente link http://tomcat.apache.org/download-55.cgi. Escogemos el archivo con extensión tar.gz de la sección core section para 5.5.15.

2.- Ahora nos movemos hacia el directorio donde descargamos el tomcat y extraemos los archivos usando el siguiente comando

cd /mydownloads (Asegurate de cambiar al directorio donde descargaste el tomcat)

tar xvzf apache-tomcat-5.5.15.tar.gz

3.- Ahora deberíamos de tener un nuevo directorio llamado apache-tomcat-5.5.15, movemos este directorio a la dirección donde debería de estar instalado, una vez más escogemos el directorio /usr/lib/. Este directorio sera identificado como CATALINA_HOME en la documentacion del Tomcat.

mv apache-tomcat-5.5.15 /usr/lib

4.- A continuación nos movemos al directorio /usr/lib/.

cd /usr/lib

5.- Creamos un link simbolico llamado apache-tomcat que apunte a CATALINA_HOME con el siguiente comando.

ln -s apache-tomcat-5.5.15 apache-tomcat

Esto nos ahorrara el tener que hacer cambios en los scripts de startup y shutdown del tomcat cada vez que se actualize, y si así se quiere nos permite tener varias versiones del tomcat e ir intercambiandolas entre si.

6.- Ahora deberíamos de poder iniciar y detener Tomcat desde el directorio CATALINA_HOME/bin. Si estas utilizando otro shell que no sea el bash, necesitaras de agregar el sh al inicio del comando.

cd /usr/lib/apache-tomcat/bin

sh startup.sh

Ahora en este paso deberíamos de poder probar si Tomcat está instalado y corriendo, esto lo haremos abriendo un browser y tecleando la siguiente dirección http://localhost:8080.

7.- Para apagar el servidor se ejecuta la siguiente linea de comando.

sh shutdown.sh

 

Permalink Dejar un comentario

Instalando el jdk 5.0 en linux

diciembre 21, 2007 at 6:38 pm (linux)

Instalando el JDK (Java Development Kit)

Para poder correr tomcat debemos de tener instalado el JDK y establecer la variable de entorno JAVA_HOME para identificar la ubicación del entorno del JDK en nuestro sistema, para fines de la demostración se ha elegido el JDK 5.0, para su instalación debemos de proceder con los siguientes pasos:

1.- Puedes descargar el JDK 5.0 del siguiente link http://java.sun.com/j2se/1.5.0/download.jsp.

2.- Da click en aceptar para aceptar la licencia

3.- A continuación elegimios el archivo linux self-extracting, de la lista de archivos de descarga.

4.- Se descarga a cualquier directorio que nosotros definamos y lo convertimos en un archivo ejecutable por medio del siguiente comando:

chmod +x jdk-1_5_0_06-linux-i586.bin

5.- Ahora ejecutamos el archivo:

./jdk-1_5_0_06-linux-i586.bin

6.- Ahora deberiamos de tener un directorio nuevo llamado j2sdk1.5-sun. Ahora cambiamos el directorio de lugar a donde debería de correr. Por ejemplo /usr/lib/

mv j2sdk1.5-sun /usr/lib

7.- Ahora creamos un link simbolico llamado jdk para JAVA_HOME con el siguiente comando, esto permite que podamos cambiar facilmente entre diferentes jvms que alguna vez necesitemos

cd /usr/lib

ln -s j2sdk1.5-sun jdk

8.- Ahora necesitamos establecer la variable de entorno JAVA_HOME. Agregamos lo siguiente al final del archivo /etc/profile justo despues de “export PATH”

JAVA_HOME=”/usr/lib/jdk”

export JAVA_HOME

/etc/profile es ejecutado al iniciar y caundo un usuario se loggea en el sistema. Para poder actualizar el entorno se requiere de un logout y un login para que tome los cambios.

9.- Tenemos que verificar que JAVA_HOME este definido correctamente a traves del siguiente comando que nos debería de arrojar un resultado como el siguiente /usr/lib/jdk.

echo $JAVA_HOME

10.- Ahora probamos Java con el siguiente comando, este comando nos debería de regresar lo siguiente /usr/bin/java. Si es así hemos instalado correctamente el jdk

which java

Permalink Dejar un comentario

Compartiendo carpetas de Linux con Windows

diciembre 21, 2007 at 5:05 pm (linux)

Que tal a todos después de unos días sin algún post me tope ayer con alguien que me pregunto como podiamos compartir una carpeta de una maquina linux con una maquina windows entonces después de darle una idea de como solucionarlo me propuse escribir esto en el blog y pues aquí vamos.

Si suponemos que tenemos dos servidores, uno windows y otro en linux, y queremos que alguna carpeta del servidor de linux pueda ser vista y utilizada por el servidor de windows debemos de ejecutar los siguientes pasos.

Ubuntu -> 10.9.111.1 (Máquina Linux)
Windows -> 10.9.111.2 (Máquina Windows)
Primero que nada tenemos que dar de alta al usuario que es que se estaria comunicando con el servidor linux, en este ejemplo lo haremos de la siguiente manera.
           sudo useradd -s /sbin/nologin winuser sudo smbpasswd -a winusuer
Ya que creamos el usuario debemos de añadir en la lista de host los nombres asociados de la siguiente forma. Editamos el archivo lmhost:
           sudo gedit /etc/samba/lmhosts
y encontramos:
           127.0.0.1       localhost
Se deben añadir los nombres asociados a la dirección IP que se tenga dentro de la red local, separados con un espacio de tabulador, quedando así:
      127.0.0.1      localhost
      10.9.111.1    Ubuntu
      10.9.111.2    Windows
Ahora debemos de configurar el archivo de configuración de samba /etc/samba/smb.conf
    sudo gedit /etc/samba/smb.conf

El archivo de configuración contiene y nos permite modificar las siguientes directivas, como lo son las siguientes:

workgroup permite asignar el grupo de trabajo deseado:
workgroup = winlinux
server string para hace un comentario breve del servidor.
server string = Servidor Samba %v en %L
hosts allow permite determinar la lista de control de acceso que definirá que máquinas o redes podrán acceder hacia el servidor:
hosts allow = 10.9.111. 127.
interfaces permite establecer desde que interfaces de red del sistema se escucharán peticiones. Samba no responderá a peticiones provenientes desde cualquier interfaz no especificada. Esto es útil cuando Samba se ejecuta en un servidor que sirve también de puerta de enlace para la red local, impidiendo se establezcan conexiones desde fuera de la red local.
interfaces = 10.140.111.254/24
Este es un ejemplo que funciona en general:
Nombre del recurso a compartir [comun] 

Comentario acerca del recurso                

comment = Directorio compartido 

Ruta completa del recurso        

path = /home/comun
Permitir o no el acceso como usuario invitado. El valor puede ser Yes o No.
guest ok = Yes
Otra forma de permitir el acceso como usuario invitado. El valor puede ser Yes o No.
public = Yes 
Permitir mostrar el recurso en las listas de recursos compartidos. El valor puede ser Yes o No.
browseable = Yes
Permitir la escritura, es opuesto a read only. El valor puede ser Yes o No.

«writable = Yes» es lo mismo que «read only = No».
writable = No
usuarios o grupos que pueden acceder al recurso compartido. Los valores pueden ser nombres de usuarios separados por comas o bien nombres de grupo antecedidos por una @.
valid users = winuser,@winusers 
Usuarios o grupos que pueden acceder con permiso de escritura. Los valores pueden ser nombres de usuarios separados por comas o bien nombres de grupo antecedidos por una @.
write list = winuser
Usuarios o grupos que pueden acceder con permisos administrativos para el recurso. Es decir, podrán acceder hacia el recurso realizando todas las operaciones como super-usuarios. Los valores pueden ser nombres de usuarios separados por comas o bien nombres de grupo antecedidos por una @.
admin users = winuser
Al igual que directory mode, define que permiso en el sistema tendrán los subdirectorios creados dentro del recurso.
directory mask  = 0755
Define que permiso en el sistema tendrán los nuevos archivos creados dentro del recurso.
create mask = 0644  
Se permite en el ejemplo el acceso a cualquiera como recurso de solo lectura salvo para el usuario winuser. Todo directorio nuevo que sea creado en su interior tendrá permiso 755 y todo archivo que sea puesto en su interior tendrá permiso 644.
Ocultar y denegar acceso a archivos.
Se utiliza hide dot files para mantener ocultos los archivos de sistema que comienzan con un punto:
hide dot files = Yes 
Se utiliza veto files para especificar la lista, separada por diagonales, de aquellas cadenas de texto que denegarán el acceso a los archivos cuyos nombres contengan estas cadenas. Por ejemplo, denegar el acceso a los archivos cuyos nombres incluyan la palabra «Security» y a los que tengan extensión «.tmp»:
veto files = /*Security*/*.tmp/  Montar unidades de red.
Para poder visualizar desde Linux las máquinas Windows e interactuar con los directorios compartidos por estás, es necesario
Desde el entorno de GNOME.
Este incluye un módulo para Nautilus que permite acceder hacia los recursos compartidos a través de Samba sin necesidad de modificar cosa alguna en el sistema. Solo hay que hacer clic en Servidores de red en el menú de GNOME.
Iniciar Samba
Por primera vez es necesario ejecutar:
sudo  /etc/rc.d/init.d/smb  start
Para reiniciar el servicio es necesario ejecutar:
sudo   /etc/rc.d/init.d/smb  restart 
Para que se inicie automáticamente en nuestro equipo ejecutar:
sudo   /sbin/chkconfig  –add  smb

Espero que este artículo les sea de utilidad, por lo pronto seguire respondiendo a sus preguntas y exponiendo mis comentarios a través de este medio. Un saludo a todos.

Permalink Dejar un comentario

Struts Framework UML Diagram

diciembre 18, 2007 at 12:53 am (Frameworks integration)

Después de algunos post que he presentado aquí en el blog les presento la estructura del framework de struts para que se pueda ver como efectuar una interacción con este framework, particularmente tengo la creencia que si vamos a utilizar algún tipo de MVC utilicemos algo que nos sirva y de ahi la importancía de evaluar los frameworks antes de realizar el analisis de cualquier aplicación, para que nos sirve struts:El Framework nos ayuda a desarrollar aplicaciones web basadas en el modelo MVC, para hacerlo nos dota de tres componentes claves en el desarrollo de dichas aplicaciones que son, un request handler que provee el desarrollador que es mapeado a una URI estándar, un response handler que transfiere el control a otro recurso que complete el response y por último una libreria de tags que ayuda al desarrollador a crear formas interactivas con server pages (JPS).Struts trabaja bien con aplicaciones REST convencionales así como con nuevas tecnologías como SOAP y AJAX.La página del proyecto de  apache eshttp://struts.apache.org/ Y aquí esta la documentación completa del framework. Mientras tanto les dejo el diagrama de UML de como esta formado struts y como se debería de interactuar con el.Struts uml imagen de. http://rollerjm.free.fr/pro/Struts11.htmlEn este diagrama las clases de azul representan las clases creadas por el usuario, en este caso el desarrollador mientras que las demás clases son las clases que nos provee el framework.Este post estuvo algo corto pero espero les haya sido de utilidad.

Permalink Dejar un comentario

Página siguiente »

Seguir

Get every new post delivered to your Inbox.