Estos son un resumen de los pasos para instalar un servidor DNS en un servidor Ubuntu:

1.-Instalar software

Tenemos que instalar el paquete bind9. Si utilizamos apt-get ejecutamos la siguiente instrucción:

sudo apt-get install bind9

En el caso de que no tengamos disponible la utilidad apt-get tendremos que instalar el paquete y TODAS sus dependencias por el método tradicional:

sudo dpkg -i bind9_9.3.2-2ubuntu1.12_i386.deb

2.- Creación del fichero named.conf.local

Tenemos que editar el siguiente fichero para definir las zonas (nombres de dominio) que queramos configurar:

sudo vi /etc/bind/named.conf.local

E introducimos lo siguiente, reemplazando 2 variables:

- Reemplazamos server.com por el dominio que nosotros deseemos:
- Reemplazamos 0.168.192 por la dirección de la red al revés, por ejemplo, si estuvieramos en una red 10.228.20.x, introduciríamos 0.20.228.10

# This is the zone definition. replace example.com with your domain name
zone "server.com" {
        type master;
        file "/etc/bind/zones/server.com.db";
        };

# This is the zone definition for reverse DNS. replace 0.168.192 with your network address in reverse notation - e.g my network address is 192.168.0
zone "0.168.192.in-addr.arpa" {
     type master;
     file "/etc/bind/zones/rev.0.168.192.in-addr.arpa";
};

3.- Editar el fichero de opciones named.conf.options

sudo vi /etc/bind/named.conf.options

En este fichero sólo tenemos que establecer la dirección IP de nuestros DNS de la red. En el caso de que el servidor DNS que estamos montando no sepa resolver el dominio, reenviará la petición a estos DNS

forwarders {
      # Replace the address below with the address of your provider's DNS server
      123.123.123.123;
	  123.123.123.124;
};

4.- Crear los ficheros de configuración de nuestra zona:

sudo mkdir /etc/bind/zones

Miramos el nombre del fichero que habíamos definido en el fichero /etc/bind/named.conf.local, en nuestro caso es /etc/bind/zones/server.com.db
y cremos el fichero:

sudo vi /etc/bind/zones/server.com.db

En este fichero ya es donde tenemos que definir la equivalencia entre ips y dominios:

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     server.com. root.server. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@ IN NS  server.com.
server.com IN A 1.1.1.1
server1 IN A 1.1.1.2

IMPORTANTE: Eliminar todos los comentarios de la forma //, A mí me dio problemas. Y ojo también con los “.” después del nombre del dominio, no se pueden eliminar.

El siguiente punto de configuración es crear el fichero de reverse DNS zone, que a partir de una ip nos dirá el dominio.

Nos fijamos en el fichero que habíamos definido en el fichero /etc/bind/named.conf.local, en nuestro caso teníamos: file “/etc/bind/zones/rev.0.168.192.in-addr.arpa”;
Por lo que el fichero sería:

sudo vi /etc/bind/zones/rev.0.168.192.in-addr.arpa

//replace server.com with yoour domain name, ns1 with your DNS server name.
// The number before IN PTR server.com is the machine address of the DNS server. in my case, it's 1, as my IP address is 192.168.0.1.
@ IN SOA ns1.example.com. admin.example.com. (
                        2006081401;
                        28800;
                        604800;
                        604800;
                        86400
)

                     IN    NS     ns1.server.com.
1                    IN    PTR    server.com
120					 IN    PTR    server2

IMPORTANTE: El número “1″ que tenemos en la última fila es la dirección de la máquina de la red, por ejemplo, si tenemos un servidor con ip 192.168.0.120, el número que tenemos que poner es 120.

5.- Configurar este DNS en nuestra máquina (/etc/resolv.conf)

Introducimos el nuevo servidor DNS y dejamos también por si acaso el servidor DNS original de nuestra red.

search server.com
nameserver 192.168.0.1
nameserver 1.1.1.1

6.- Reiniciar el servicio bind y probar el servidor DNS

Por último reiniciamos el servicio bind y probamos que funciona.

sudo /etc/init.d/bind9 restart

Hay varias utilizades para saber si funciona: dig, nslookup y ping:

dig server.com
dig server1.server.com
nslookup 192.168.0.1
ping server1.server.com

Referencia:

https://help.ubuntu.com/6.06/ubuntu/serverguide/C/dns.html

https://help.ubuntu.com/community/BIND9ServerHowto

http://es.wikipedia.org/wiki/Domain_Name_System

1.- Instalación servidor NFS Server Support

$ sudo apt-get install nfs-kernel-server nfs-common portmap

sudo dpkg -i portmap_6.0.0-2ubuntu1_i386.deb

dpkg -s nfs-kernel-server

sudo dpkg -i portmap_6.0.0-2ubuntu1_i386.deb

dpkg -s nfs-kernel-server

2.-Ejecutar el servicio portmap

Tendremos que tener habilitado el servicio portmap. Ejecutamos:

sudo dpkg-reconfigure portmap

Al configurar portmap seleccionar la opción =not= bind loopback.

sudo /etc/init.d/portmap restart

3.- Editar el fichero /etc/exports

El fichero /etc/exports es el fichero que hay que crear para definir los directorios compartidos en el servidor NFS. Lo editamos:

sudo vi /etc/exports

Algunos ejemplos de configuraciones:

For Full Read Write Permissions allowing any computer from
192.168.1.1 through 192.168.1.255

/files 192.168.1.0/24(rw,no_root_squash,async)

Or for Read Only from a single machine

/files 192.168.1.2 (ro,async)

4.- Arrancar el servicio nfs-kernel-server

sudo /etc/init.d/nfs-kernel-server restart

Después de hacer cambios en el fichero /etc/exports se deben de exportar estos cambios al servidor

sudo exportfs -a

5.- Instalar el cliente de NFS

sudo apt-get install portmap nfs-common

sudo dpkg-reconfigure portmap

Al configurar portmap seleccionar la opción =not= bind loopback.

sudo /etc/init.d/portmap restart

6.- Montar la partición

Para conocer los directorios que podemos montar:

showmount -e "ip-nfs-server"

sudo mount  hostRemoto:/SharedDirectoio /mountDirectory

Posibles problemas

Puede haber algún problema en la comunicación debido al firewall del cliente o servidor.

Se puede comprobar el status del firewall con la orden:

sudo ufw status numbered

El puerto por defecto suele ser el 111

sudo ufw allow 111

Documentación:

http://ubuntuforums.org/showthread.php?t=249889

Lo mejor de todo, sin duda los profesores. Es un lujo poder asistir a un curso en el que las personas que te están enseñando son los ingenieros del core de liferay, que trabajan día a día desarrollando sobre el producto y se conocen la implementación de las clases, cualquier duda, en 5 segundos miran el código fuente y la resuelven. Otra ventaja de que los profesores tengan tan buen conocimiento del producto es que según se avanza en el curso van dando consejos sobre la mejor manera de orientar algún problema típico del desarrollo de portales.

Lo peor, la duración, en 3 días sólo da tiempo a verlo casi todo por encima pero sin profundizar en nada, hubiera sido un lujo seguir 2 días más con algún ejercicio un poco más completo donde se englobaran todos los conceptos explicados en los 3 días anteriores.

La conclusión es que es un curso que a la larga sale muy rentable, y la diferencia con respecto a otros cursos no oficiales es que los profesores trabajan día a día desarrollando el core de Liferay y esto se nota.

Los profesores:

http://www.liferay.com/es/web/julio.camarero

http://www.liferay.com/es/web/juan.fernandez

1.- Backup repositorio

$ svnadmin dump /var/svn/repository/  > /var/svn/repository.dump

2.- Mover el repositorio entre máquinas

scp ficheroOrigen userHostRemoto@host:ficheroDestino

3.- Creación del nuevo repositorio

svnadmin create /var/svn/repository

4.- Importar el dump del repositorio en el nuevo servidor svn

svnadmin load /var/svn/repository < repository.dump

Si teníamos también una instancia de Trac asociada a ese repositorio también es posible realizar un backup o hacer una migración al nuevo servidor Trac

1.- Backup de trac

trac-admin /pathToTracEnvironment hotcopy <backupdir>

2.- Mover el backup entre máquinas

Si hay que mover el directorio entre máquina usamos la orden rsync o scp como antes

 rsync -avz /directory userHostRemoto@host:directory

3.- Restaurar el entorno de trac:

1.- Inicializar el entorno

a) trac-admin /pathToEnvironment initenv

b) Copiar los directorios del backup a este nuevo directorio

c) Ejecutar el comando upgrade trac-admin /pathToEnvironment upgrade

d) Cambiar los permisos para que el usuario del apache pueda leer y escribir sobre este directorio

<portlet>
	<portlet-name>sample</portlet-name>
	<portlet-class>org.springframework.web.portlet.DispatcherPortlet</portlet-class>
	<supports>
		<mime-type>text/html</mime-type>
		<portlet-mode>view</portlet-mode>
	</supports>
	<portlet-info>
		<title>Sample Portlet</title>
	</portlet-info>
</portlet>

Modificar archivo web.xml

<servlet>
    <servlet-name>ViewRendererServlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.ViewRendererServlet</servlet-class>
</servlet>

<servlet-mapping>
    <servlet-name>ViewRendererServlet</servlet-name>
    <url-pattern>/WEB-INF/servlet/view</url-pattern>
</servlet-mapping>

Añadir los beans controladores de spring web-flow

<bean id="portletModeControllerMapping" class="org.springframework.web.portlet.handler.PortletModeHandlerMapping">
<property name="portletModeMap">
<map>
<entry key="view" value-ref="flowController" />
</map>
</property>

<property name="interceptors">
<list>
<ref bean="authenticationPortletInterceptor"/>
</list>
</property>
</bean>

<bean id="flowController" class="org.springframework.webflow.executor.mvc.PortletFlowController">
<property name="flowExecutor" ref="flowExecutor" />
<property name="defaultFlowId" value="fwLogin" />
</bean>

<!-- Default View Resolver -->

<bean id="viewResolver" 
class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="cache" value="true"/>
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>
<property name="prefix" value="/WEB-INF/view/"/>
<property name="suffix" value=".jsp"/>
<property name="contentType" value="text/html; charset=UTF-8"/>
</bean>

<!-- Creates the registry of flow definitions for this application -->
<flow:registry id="flowRegistry">
<flow:location path="/WEB-INF/context/flows/**/fw*.xml"/>
</flow:registry>

<!-- Launches new flow executions and resumes existing executions -->
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="singlekey">
<flow:execution-attributes>
<!-- execution redirects don't apply in a Portlet environment -->

<flow:alwaysRedirectOnPause value="false"/>
</flow:execution-attributes>
</flow:executor>

Modificar las jsps

Cada enlace tendrá que construirse de la forma:

<portlet:renderURL var="mainUrl">
 <portlet:param name="_flowId" value="fwMain" /> 
</portlet:renderURL>

<a href="${mainUrl}">Texto del enlace </a>

Formularios:

<portlet:actionURL var="userSubmitUrl">
 <portlet:param name="_flowId" value="fwUserUpdate" />
 <portlet:param name="_flowExecutionKey" value="${flowExecutionKey}" />
</portlet:actionURL>

<form:form commandName="userUpdate" action="${userSubmitUrl}" method="post" acceptCharset="ISO-8859-1">
 <p>
  <label for="login"><spring:message code="user.update.form.field.login" /></label>
   <form:input cssClass="text" path="login" disabled="true"/>
 </p>
<input class="button" name="_eventId_insert" value="Value" />" type="submit"/>

Para más información consultar la documentación oficial de Spring MVC:

http://static.springsource.org/spring/docs/2.0.x/reference/portlet.html

Desde mi punto de vista estos son los fallos más comunes:

1.- Análisis de requisitos insuficientes.

Para poder terminar un proyecto es necesario recopilar los requisitos funcionales de éste, si esta captura no se realiza formalmente durante esta primera fase tendrá que hacerse durante la fase de diseño o peor aún durante la fase de desarrollo. Ya hay un término que describe esto: IKIWISI (I’ll know it when i see it). El cliente no sabe lo que quiere o no se le involucró lo suficiente durante la captura de requisitos, y las consecuencias son que el cliente querrá cambiar o añadir nuevos requisitos cuando vea el trabajo ya finalizado, es decir, al final de la fase de desarrollo.

Si la gestión del proyecto se basa en esta anti-metodología IKIWISI del prueba-error será imposible que el proyecto no se retrase y se multipliquen los costes. Si comparamos este proyecto software con un proyecto más simple, por ejemplo, pintar una habitación, en esta anti-metodología el pintor empezaría a pintar la habitación sin que el cliente se involucrase en la decisión de elegir el color. Cuando el pintor haya terminado de pintar 3 paredes en azul se las enseñaría al cliente, y este opinará que el color es muy frío,  preferiría uno más cálido, ahora el pintor si quiere contentar al cliente tendrá que lijar las 3 paredes y decide pintarlas de rojo, cuando ya están terminadas se las enseña de nuevo al cliente, pero por desgracia el rojo le parece demasiado cálido. Después de varios días de tensión porque se multiplican los costes y se retrasa el proyecto, acuerdan pintar la habitación en naranja y cerrar el proyecto. Después de una semana de retraso,  el pintor termina las cuatro paredes en naranja y el cliente por fin está medio contento. Es lo que al final quería, pero tras un retraso considerable, y unos costes que se multiplicaron por 3. Si se hubiese realizado adecuadamente la captura de requisitos, ambos se hubieran ahorrado los retrasos y los sobrecostes.

2.-Cambios frecuentes en los requisitos.

Al no haber un documento  funcional donde se describa lo que se acordó, el cliente tiene total libertad para cambiar los requisitos a su libre albedrío y cuantas veces quiera. Si hubiese un documento formal donde se describan los requisitos sería mucho más fácil para el jefe de proyecto oponerse a estos cambios, si no tiene nada, al final acabará cediendo a todos los cambios y nuevos requisitos porque no tiene a qué agarrarse.

3.-Planificación no realista.

Incluso teniendo en cuenta el mejor de los casos, donde hay un análisis de requisitos bien documentado, no se suelen tener en cuenta muchas series de factores que van a influir seguramente en la planificación. Estos factores pueden ser: vacaciones del personal, fiestas, posibles bajas, posibles inclemencias del tiempo, fallos técnicos, etc…

Para contrarrestar estos imprevistos los jefes de proyecto pueden añadir más presión al equipo de programadores, pero esto será sólo un parche y no conseguirá hacer mejor software mediante esta estrategia, aparte de otros muchos inconvenientes que pueda tener. Los programadores bajo presión trabajan más rápido, pero no trabajan mejor.

“People under time pressure don’t work better; they Just work faster.”

Tom DeMarco & Timothy Lister.

Referencias:

http://www.joelonsoftware.com/articles/fog0000000036.html

http://www.joelonsoftware.com/articles/PickingShipDate.html

http://garciagonzalezdavid.wordpress.com/2008/08/12/the-art-of-project-management/

http://garciagonzalezdavid.wordpress.com/2006/10/31/peopleware-productive-projects-and-teams/

http://es.wikipedia.org/wiki/The_Mythical_Man-Month

Resumiendo, todos los puestos en esta oficina tienen las siguientes características:

• Todas las oficinas son privadas, para que te concentres en el código y no interrumpan todo el tiempo. Aquí en España lo más normal es que haya gente hasta en los pasillos con mesas supletorias. Además, todas tienen ventanas para que te relajes con las buenas vistas de Nueva York.
• Mesa motorizada ajustable en altura, para trabajar de pie si me da la gana. Aquí te tienes que conformar con lo justo para el portátil.
• Monitores de 30″, incluso algunos puestos tienen hasta 2 monitores. Y yo pasándome 8 horas con un portátil de 15,4″.
• Comedor gratuito, bonito y espacioso para comer todo el mundo a la vez. Se acabó eso de llevar tuppers.
• Coffee bar gratuíto. Fruta en todos los puestos, snacks, una nevera llena de bebidas. Mirar las fotos y comparad.
• Biblioteca
• Varias salas de reuniones de diferentes tamaños. Allí no se pelean por resevar la sala.

Bueno, sólo quería demostrar que son diferentes las cosas allí y aquí, y espero que poco a poco aquí vayamos cogiendo todo lo bueno de allá y no al revés.

Oficinas de Fog Creek en Nueva York

Para más información: el blog de Joel Spolsky y el álbum de Picasa con las fotos de las oficinas.

Estas son mis razones por las que defiendo que es mejor un buen desarrollador que 10 noramalillos:

1. Con menos código generan más funcionalidad. Al diseñar mejor las clases y las funciones repiten menos código, así con menos líneas generan más funcionalidad. Al tener menos código fuente que revisar el tiempo empleado en detectar y corregir bugs se minimiza.
2. Generan código más limpio y más fácil de leer. Al ser más sencillo de leer también es más fácil de extender y corregir bugs.
3. Generan más código en menos tiempo. Conocen mejor el api y tardan menos en implementar las funciones.
4. El código tiene menos proporción de bugs.
5. Al utilizar (siempre que sea necesario) patrones de diseño su código es más fácil de extender y modificar.
6. El código está mejor documentado y tiene mejores comentarios, por lo tanto, es más sencillo de extender o modificar por futuros programadores.
7. Los programas son más eficientes. Conocen mejor la estructura de los diferentes tipos de datos y la complejidad de sus funciones, por lo tanto siempre los tendrán en cuenta a la hora de diseñar una función.

Por tanto, generan código más eficiente, en menos tiempo, mejor documentado, con menos bugs y mucho más sencillo de leer, extender y corregir.
Por todas estas razones me gustaría ser mejor programador.

Un vídeo de Simón Hergueta.

Scott Berkun trabajó durante 10 años en Microsoft Corporation y en este libro refleja un montón de lecciones aprendidas durante este tiempo. Prácticamente cubre todo lo relacionado con la gestión de proyectos:

• Cómo tomar las buenas decisiones
• Cómo hacer especificaciones y análisis de requisitos
• Qué hacer con las buenas ideas
• Cómo ganar liderazgo y confianza
• La verdad sobre las estimaciones
• Qué hacer cuando todo va mal

Como en todos los libros que he leído, también está basado en una experiencia en la industria del software estadounidense que es muy diferente de la española, tal y como veo como están por aquí las cosas no es fácil aplicar todos los consejos que se encuentran aquí.

En definitiva, es un gran libro con una cantidad enorme de consejos, métodos e historias para ser un buen manager, pero hay que tener en cuenta que todos estos capítulos se hacen difíciles de asimilar por lo que, por lo menos a mí, me resultó bastante difícil de leer.

Para quien se anime a leerlo, lo puede encontrar en Google Books de forma gratuíta.