He intentando asociar un SmartWatch Sony 3 con un Sony Xperia y me ha sucedido que a la hora de asociar el bluetooth me da un fallo de que no se puede asociar vincular debido a que el PIN o clave son incorrectas. Creo que esto puede suceder debido a que los dispositivos ( como el SmartWatch Sony 3) que permiten asociar sin preguntar la clave de forma explicita en verdad si que la piden solo que suelen ser del tipo 1111 o 0000 y si el dispositivo que se quiere asociar no prueba con esas claves simples entonces falla.
La forma en que he conseguido asociar los dos dispositivos es dandole la vuelta. Es decir, he asociado el SmartWatch Sony 3 con otro dispositivo que si que dejaba vincularse, una vez que el SmartWatch Sony 3 ya permitia usar sus funcionalidades he buscado el Sony Xperia y ha sido el SmartWatch Sony 3 el que se ha vinculado asociado al Sony Xperia.
Una vez conseguido esto ya estan vinculados asociados y ya se pueden usar conjuntamente.
domingo, 29 de noviembre de 2015
miércoles, 25 de noviembre de 2015
Socket en C++. Visual Studio Express 2015
A continuación se muestra como crear un socket en c++.
Este codigo funciona correctamente en el Visual Studio Express 2015
Este codigo lo he sacado del https://msdn.microsoft.com
#include "stdafx.h"
#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif
#include <windows.h>
#include <winsock2.h>
#include <ws2tcpip.h>
#include <iphlpapi.h>
#include <stdio.h>
#pragma comment(lib, "Ws2_32.lib")
struct addrinfo *result = NULL, *ptr = NULL, hints;
#define DEFAULT_PORT "27015"
int main() {
ZeroMemory(&hints, sizeof(hints));
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
hints.ai_flags = AI_PASSIVE;
WSADATA wsaData;
int iResult;
// Initialize Winsock
iResult = WSAStartup(MAKEWORD(2, 2), &wsaData);
if (iResult != 0) {
printf("WSAStartup failed: %d\n", iResult);
return 1;
}
// Resolve the local address and port to be used by the server
iResult = getaddrinfo(NULL, DEFAULT_PORT, &hints, &result);
if (iResult != 0) {
printf("getaddrinfo failed: %d\n", iResult);
WSACleanup();
return 1;
}
SOCKET ListenSocket = socket(result->ai_family, result->ai_socktype, result->ai_protocol);
if (ListenSocket == INVALID_SOCKET) {
printf("Error at socket(): %ld\n", WSAGetLastError());
freeaddrinfo(result);
WSACleanup();
return 1;
}
iResult = bind(ListenSocket, result->ai_addr, (int)result->ai_addrlen);
if (iResult == SOCKET_ERROR) {
printf("bind failed with error: %d\n", WSAGetLastError());
freeaddrinfo(result);
closesocket(ListenSocket);
WSACleanup();
return 1;
}
freeaddrinfo(result);
if (listen(ListenSocket, SOMAXCONN) == SOCKET_ERROR) {
printf("Listen failed with error: %ld\n", WSAGetLastError());
closesocket(ListenSocket);
WSACleanup();
return 1;
}
SOCKET ClientSocket;
ClientSocket = INVALID_SOCKET;
// Accept a client socket
ClientSocket = accept(ListenSocket, NULL, NULL);
if (ClientSocket == INVALID_SOCKET) {
printf("accept failed: %d\n", WSAGetLastError());
closesocket(ListenSocket);
WSACleanup();
return 1;
}
closesocket(ListenSocket);
char recvbuf[512];
int iSendResult;
int recvbuflen = 512;
// Receive until the peer shuts down the connection
do {
iResult = recv(ClientSocket, recvbuf, recvbuflen, 0);
if (iResult > 0) {
printf("Bytes received: %d\n", iResult);
// Echo the buffer back to the sender
iSendResult = send(ClientSocket, recvbuf, iResult, 0);
if (iSendResult == SOCKET_ERROR) {
printf("send failed: %d\n", WSAGetLastError());
closesocket(ClientSocket);
WSACleanup();
return 1;
}
printf("Bytes sent: %d\n", iSendResult);
}
else if (iResult == 0)
printf("Connection closing...\n");
else {
printf("recv failed: %d\n", WSAGetLastError());
closesocket(ClientSocket);
WSACleanup();
return 1;
}
} while (iResult > 0);
iResult = shutdown(ClientSocket, SD_SEND);
if (iResult == SOCKET_ERROR) {
printf("shutdown failed: %d\n", WSAGetLastError());
closesocket(ClientSocket);
WSACleanup();
return 1;
}
closesocket(ClientSocket);
WSACleanup();
return 0;
}
Este codigo funciona correctamente en el Visual Studio Express 2015
Este codigo lo he sacado del https://msdn.microsoft.com
#include "stdafx.h"
#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif
#include <windows.h>
#include <winsock2.h>
#include <ws2tcpip.h>
#include <iphlpapi.h>
#include <stdio.h>
#pragma comment(lib, "Ws2_32.lib")
struct addrinfo *result = NULL, *ptr = NULL, hints;
#define DEFAULT_PORT "27015"
int main() {
ZeroMemory(&hints, sizeof(hints));
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
hints.ai_flags = AI_PASSIVE;
WSADATA wsaData;
int iResult;
// Initialize Winsock
iResult = WSAStartup(MAKEWORD(2, 2), &wsaData);
if (iResult != 0) {
printf("WSAStartup failed: %d\n", iResult);
return 1;
}
// Resolve the local address and port to be used by the server
iResult = getaddrinfo(NULL, DEFAULT_PORT, &hints, &result);
if (iResult != 0) {
printf("getaddrinfo failed: %d\n", iResult);
WSACleanup();
return 1;
}
SOCKET ListenSocket = socket(result->ai_family, result->ai_socktype, result->ai_protocol);
if (ListenSocket == INVALID_SOCKET) {
printf("Error at socket(): %ld\n", WSAGetLastError());
freeaddrinfo(result);
WSACleanup();
return 1;
}
iResult = bind(ListenSocket, result->ai_addr, (int)result->ai_addrlen);
if (iResult == SOCKET_ERROR) {
printf("bind failed with error: %d\n", WSAGetLastError());
freeaddrinfo(result);
closesocket(ListenSocket);
WSACleanup();
return 1;
}
freeaddrinfo(result);
if (listen(ListenSocket, SOMAXCONN) == SOCKET_ERROR) {
printf("Listen failed with error: %ld\n", WSAGetLastError());
closesocket(ListenSocket);
WSACleanup();
return 1;
}
SOCKET ClientSocket;
ClientSocket = INVALID_SOCKET;
// Accept a client socket
ClientSocket = accept(ListenSocket, NULL, NULL);
if (ClientSocket == INVALID_SOCKET) {
printf("accept failed: %d\n", WSAGetLastError());
closesocket(ListenSocket);
WSACleanup();
return 1;
}
closesocket(ListenSocket);
char recvbuf[512];
int iSendResult;
int recvbuflen = 512;
// Receive until the peer shuts down the connection
do {
iResult = recv(ClientSocket, recvbuf, recvbuflen, 0);
if (iResult > 0) {
printf("Bytes received: %d\n", iResult);
// Echo the buffer back to the sender
iSendResult = send(ClientSocket, recvbuf, iResult, 0);
if (iSendResult == SOCKET_ERROR) {
printf("send failed: %d\n", WSAGetLastError());
closesocket(ClientSocket);
WSACleanup();
return 1;
}
printf("Bytes sent: %d\n", iSendResult);
}
else if (iResult == 0)
printf("Connection closing...\n");
else {
printf("recv failed: %d\n", WSAGetLastError());
closesocket(ClientSocket);
WSACleanup();
return 1;
}
} while (iResult > 0);
iResult = shutdown(ClientSocket, SD_SEND);
if (iResult == SOCKET_ERROR) {
printf("shutdown failed: %d\n", WSAGetLastError());
closesocket(ClientSocket);
WSACleanup();
return 1;
}
closesocket(ClientSocket);
WSACleanup();
return 0;
}
martes, 3 de noviembre de 2015
Incertidumbre de culminación de tareas
Cuando se le asigna una tarea a un programador para que la cumpla (en general voy a hablar de tareas que lleva varios días culminarla pero también se puede aplicar a tareas pequeñas) hay varias metricas que se usan para evaluar el grado de avance o resultado si ya esta terminada:
Todas las metricas que se usen se pueden ser mejor o peores para conocer el estado del desarrollo y llevar a la culminación de la tarea dependiendo de la incertidumbre de culminación de la tarea que presenta el desarrollador encargado de la tarea.
La incertidumbre de culminación de tareas es la probabilidad de que un programador haya implementado una tarea de acuerdo a como el responsable quiere que lo haga.
Cuando el responsable de una tarea piensa (diseña) la tarea no habria mejor persona para acometerla que esa misma persona (no lo va a hacer porque lo que tiene que hacer es diseñarla para que lo haga otros y esa persona pueda hacer otra cosa) y si esa persona acometiera la tarea es casi seguro que al hacerlo se encontrara con realidades (esto es mejor asi, esto asi no sale, etc..) que variarían la forma que tenia pensada en que se acomete la tarea y posiblemente hasta cambios de diseño. Con esta premisa, es lógico pensar que otra persona (un desarrollador) presenta una incertidumbre de culminación de tareas muy alto.
Para evitarlo, es básica la formación continua de los programadores y asegurarse de que comprenden el marco de trabajo que se usa para el desarrollo del proyecto. Pero es muy optimista pensar que con esto vale, se deben usar técnicas con mas supervisión como programación extrema. Quizas la mejor opción es seleccionar un dia al azar y pasar la mayor parte del dia sentado en el sitio del programador, hablar con el, ver como plantea las cosas, que esta haciendo, que es lo que ha entendido, etc.. La claves es asegurarse de que ha entendido el marco de trabajo y que va a culminar la tarea como espera el responsable que se va a resolver.
- Grado de avance respecto a lo planificado.
- Calidad del desarrollo.
- % de pruebas superadas.
- Revisiones de código.
- etc...
Todas las metricas que se usen se pueden ser mejor o peores para conocer el estado del desarrollo y llevar a la culminación de la tarea dependiendo de la incertidumbre de culminación de la tarea que presenta el desarrollador encargado de la tarea.
La incertidumbre de culminación de tareas es la probabilidad de que un programador haya implementado una tarea de acuerdo a como el responsable quiere que lo haga.
Cuando el responsable de una tarea piensa (diseña) la tarea no habria mejor persona para acometerla que esa misma persona (no lo va a hacer porque lo que tiene que hacer es diseñarla para que lo haga otros y esa persona pueda hacer otra cosa) y si esa persona acometiera la tarea es casi seguro que al hacerlo se encontrara con realidades (esto es mejor asi, esto asi no sale, etc..) que variarían la forma que tenia pensada en que se acomete la tarea y posiblemente hasta cambios de diseño. Con esta premisa, es lógico pensar que otra persona (un desarrollador) presenta una incertidumbre de culminación de tareas muy alto.
Para evitarlo, es básica la formación continua de los programadores y asegurarse de que comprenden el marco de trabajo que se usa para el desarrollo del proyecto. Pero es muy optimista pensar que con esto vale, se deben usar técnicas con mas supervisión como programación extrema. Quizas la mejor opción es seleccionar un dia al azar y pasar la mayor parte del dia sentado en el sitio del programador, hablar con el, ver como plantea las cosas, que esta haciendo, que es lo que ha entendido, etc.. La claves es asegurarse de que ha entendido el marco de trabajo y que va a culminar la tarea como espera el responsable que se va a resolver.
lunes, 19 de octubre de 2015
No hagas las tareas de los demas
Aunque parezca una tonteria tener que recordarlo y aunque creas que no haces el trabajo de los demas, es mas comun de lo que crees. El problema no es realmente que pierdas un tiempo que puedes dedicar a tu propio trabajo, el problema es estas perjudicando a largo plazo a la persona(1) a la que ayudas y estas afectando a la estructura del todo el equipo(2). ¿Por que?
1) Pejudicas a largo plazo a la persona a la que ayudas porque esta persona no aprende a hacer su trabajo o sabrá hacerlo pero no de forma correcta.
2) Si el trabajo X que deberia estar haciendo una persona A lo hace una persona B, eso quiere decir que el trabajo X se realiza en la zona B cuando un jefe o responsable piensa que se hace en la zona A. Si se detecta un fallo en el trabajo X entonces el jefe o responsable pensara que el problema esta en A cuando en realidad el trabajo problematico lo esta haciendo B. Esto es como si un individuo A acude a un medico con algun problema, le indica que la solucion es tomar unas pastillas, se las toma un individuo B y esperes que mejore el individuo A.
Hay que gastar esfuerzo en intentar que cada uno haga su trabajo. Por lo que cada individuo tiene que estar seguro que esta haciendo lo que tiene que hacer y asegurarse que las personas que lo rodean hacen el suyo. Cuando un individuo tiene que asegurarse que las personas que lo rodean hacen se trabajo se puede encontrar tres escenarios:
- La persona que no hace su trabajo es un superior: No tienes que hacer nada. Es responsabilidad de otro.
- La persona que no hace su trabajo es un subordinado: Hay que examinar el trabajo de
1) Pejudicas a largo plazo a la persona a la que ayudas porque esta persona no aprende a hacer su trabajo o sabrá hacerlo pero no de forma correcta.
2) Si el trabajo X que deberia estar haciendo una persona A lo hace una persona B, eso quiere decir que el trabajo X se realiza en la zona B cuando un jefe o responsable piensa que se hace en la zona A. Si se detecta un fallo en el trabajo X entonces el jefe o responsable pensara que el problema esta en A cuando en realidad el trabajo problematico lo esta haciendo B. Esto es como si un individuo A acude a un medico con algun problema, le indica que la solucion es tomar unas pastillas, se las toma un individuo B y esperes que mejore el individuo A.
Hay que gastar esfuerzo en intentar que cada uno haga su trabajo. Por lo que cada individuo tiene que estar seguro que esta haciendo lo que tiene que hacer y asegurarse que las personas que lo rodean hacen el suyo. Cuando un individuo tiene que asegurarse que las personas que lo rodean hacen se trabajo se puede encontrar tres escenarios:
- La persona que no hace su trabajo es un superior: No tienes que hacer nada. Es responsabilidad de otro.
- La persona que no hace su trabajo es un subordinado: Hay que examinar el trabajo de
La motivación ¿es una clave?
La motivación es la clave para que los trabajadores dejen de tener un rendimiento bajo y se conviertan en los mejores. En las películas, el peor equipo de la liga en verdad es el mejor solo que le faltaba motivación. La motivación es la clave del éxito ¿verdad? ¿o no? No puede que esta idea no sea mas que una leyenda urbana o, como pasa tanto en informática, la idea es buena pero en la practica todo el mundo sabe que no es así.
La motivación es una tactica proactiva ante un desarrollo que puede ser beneficioso para el resultado final. Pero tambien puede ser perjudicial (por ejemplo que la excesiva motivación se consiga con dinero y al final el coste total del proyecto sea desorbitado). Ademas puede crear el efecto "dios" en los programadores haciéndoles creer que son mejores de lo que en realidad son.
Seamos prácticos, esta por demostrar que la motivación sea "clave". Mas "clave" que la motivación es la frustración. Empíricamente, no se puede demostrar que la motivación tenga un efecto realemente positivo pero se puede demostrar que la frustración si tiene un efecto negativo. Por lo que es mas importante evitar la frustración que conseguir la motivación.
Un programador motivado estará mas contento y con ganas de hacer cosas pero ¿Eso te garantiza que lo que haga esta bien? ¿sea entable?. Esto no se puede saber.
Pero con el enfoque de la frustración. Si el programador esta frustrado esta claro que va a tardar mas en hacer sus trabajos y que serán de peor calidad.
Ademas, retomemos el efecto "dios". Es mejor que un programador piense ante una tarea que no a podido acometer:
1º uff, no me esta saliendo y no lo entiendo. ¿que puedo hacer?.
o que piense:
2º Eso estaba bien desde el principio. Solo falla esto en concreto y eso no puede hacerlo nadie.
La 1 (frustración) es una situación mas dura sin duda pero tambien es una situación que se puede afrontar y se puede resolver la clave esta en ayudar al programador a llegar a una solución.
En la 2 (motivación) mejor que lo dejes como esta o que lo haga otro programador. En el punto en el que esta, ese programador nunca va a dar la vuelta.
La motivación es una tactica proactiva ante un desarrollo que puede ser beneficioso para el resultado final. Pero tambien puede ser perjudicial (por ejemplo que la excesiva motivación se consiga con dinero y al final el coste total del proyecto sea desorbitado). Ademas puede crear el efecto "dios" en los programadores haciéndoles creer que son mejores de lo que en realidad son.
Seamos prácticos, esta por demostrar que la motivación sea "clave". Mas "clave" que la motivación es la frustración. Empíricamente, no se puede demostrar que la motivación tenga un efecto realemente positivo pero se puede demostrar que la frustración si tiene un efecto negativo. Por lo que es mas importante evitar la frustración que conseguir la motivación.
Un programador motivado estará mas contento y con ganas de hacer cosas pero ¿Eso te garantiza que lo que haga esta bien? ¿sea entable?. Esto no se puede saber.
Pero con el enfoque de la frustración. Si el programador esta frustrado esta claro que va a tardar mas en hacer sus trabajos y que serán de peor calidad.
Ademas, retomemos el efecto "dios". Es mejor que un programador piense ante una tarea que no a podido acometer:
1º uff, no me esta saliendo y no lo entiendo. ¿que puedo hacer?.
o que piense:
2º Eso estaba bien desde el principio. Solo falla esto en concreto y eso no puede hacerlo nadie.
La 1 (frustración) es una situación mas dura sin duda pero tambien es una situación que se puede afrontar y se puede resolver la clave esta en ayudar al programador a llegar a una solución.
En la 2 (motivación) mejor que lo dejes como esta o que lo haga otro programador. En el punto en el que esta, ese programador nunca va a dar la vuelta.
jueves, 8 de octubre de 2015
Hacer login programaticamente contra j_security_check
Os adjunto un codigo para hacer login programaticamente contra un servidor con seguridad estandar de Java (un tomcat para ser exacto).
Con este codigo, el ultimo System.out.print muestra una pagina protegida (en el ejemplo index.html esta protegida)
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.MalformedURLException;
import java.net.URL;
public class Cliente {
public static void main(String[] agrs) throws MalformedURLException,
IOException {
HttpURLConnection connection = (HttpURLConnection) new URL("http://localhost:8080/servletname/index.html").openConnection();
connection.setInstanceFollowRedirects(false);
BufferedReader reader = new BufferedReader(new InputStreamReader(connection.getInputStream()));
reader.close();
String cookie = connection.getHeaderField("Set-Cookie");
cookie = cookie.substring(0, cookie.lastIndexOf(';'));
String location = "http://localhost:8080/servletname/j_security_check?j_username=a&j_password=a";
connection = (HttpURLConnection) new URL(location).openConnection();
connection.setRequestMethod("POST");
connection.setRequestProperty("Cookie", cookie);
connection.setInstanceFollowRedirects(false);
location = connection.getHeaderField("Location");
connection = (HttpURLConnection) new URL(location).openConnection();
connection.setRequestProperty("Cookie", cookie);
connection.setInstanceFollowRedirects(true);
BufferedReader in = new BufferedReader(new InputStreamReader(
connection.getInputStream()));
String inputLine;
while ((inputLine = in.readLine()) != null)
System.out.println(inputLine);
}
}
Con este codigo, el ultimo System.out.print muestra una pagina protegida (en el ejemplo index.html esta protegida)
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.MalformedURLException;
import java.net.URL;
public class Cliente {
public static void main(String[] agrs) throws MalformedURLException,
IOException {
HttpURLConnection connection = (HttpURLConnection) new URL("http://localhost:8080/servletname/index.html").openConnection();
connection.setInstanceFollowRedirects(false);
BufferedReader reader = new BufferedReader(new InputStreamReader(connection.getInputStream()));
reader.close();
String cookie = connection.getHeaderField("Set-Cookie");
cookie = cookie.substring(0, cookie.lastIndexOf(';'));
String location = "http://localhost:8080/servletname/j_security_check?j_username=a&j_password=a";
connection = (HttpURLConnection) new URL(location).openConnection();
connection.setRequestMethod("POST");
connection.setRequestProperty("Cookie", cookie);
connection.setInstanceFollowRedirects(false);
location = connection.getHeaderField("Location");
connection = (HttpURLConnection) new URL(location).openConnection();
connection.setRequestProperty("Cookie", cookie);
connection.setInstanceFollowRedirects(true);
BufferedReader in = new BufferedReader(new InputStreamReader(
connection.getInputStream()));
String inputLine;
while ((inputLine = in.readLine()) != null)
System.out.println(inputLine);
}
}
viernes, 21 de agosto de 2015
Sin reaccion
Supongamos el siguiente caso:
Un programador termina un desarrollo. El responsable evalue al desarrollo y encuentra varios fallos. Se los indica al programador. El programador los soluciona. El responsable vuelve a evaluar los cambios pero sigue viendo el fallo. Se lo dice al programador. El programador indica al responsable que ya esta solucionado.
Lo normal es que el responsable ya no compruebe mas resultado y se fie del programador (no es lo mas correcto pero no se suele tener mas tiempo en el proyecto para mas).
Al tiempo, el evaluador (o otro miembro del equipo del proyecto) sigue encontrado fallos ya detectados y que el responsable ya le indico al programador que lo solucionara.
¿Que se ha hecho mal? Hay muchas cosas (que el responsable pruebe hasta que no vea fallos, fases de pruebas, etc..) que se puede hacer pero normalmente no hay tiempo para hacerlo por lo que lo unico que queda es FIARTE de que el programador lo va a hacer correctamente tras una (o como mucho dos) evaluación.
¿Que ha pasado? Factores a tener en cuenta:
La frustración que produce la tarea. Hacer codigo nuevo gusta, volver a un codigo que el programador creia terminado y ajustarlo no gusta.
Desconocimiento funcional de lo que se tiene que hacer.
Falta de responsabilidad con lo desarrollado. Un programador lo que quiere es terminar lo mas rapido posible y luego si hay un fallo pues intentar justificarlo con que es un fallo del grupo.
¿Que hacer para paliar estos factores?
Evaluar mientras el codigo sea nuevo.
Antes de picar nada de codigo, se debe asegurar que los programadores saben lo que tiene hacer correctamente y cual es la solucion propuesta
Suena horrible pero la solución es ser puñetero y quisquillos. Hay que mirar codigo, explicar porque ser ha hecho esto asi o asa y criticar. Con mano izquierda pero hay que ser puñetero que se justifiquen los desarrollos. Asi no solo se consigue mas calidad, se consigue que el programador sienta una relación mas estrecha con lo que ha programado.
Un programador termina un desarrollo. El responsable evalue al desarrollo y encuentra varios fallos. Se los indica al programador. El programador los soluciona. El responsable vuelve a evaluar los cambios pero sigue viendo el fallo. Se lo dice al programador. El programador indica al responsable que ya esta solucionado.
Lo normal es que el responsable ya no compruebe mas resultado y se fie del programador (no es lo mas correcto pero no se suele tener mas tiempo en el proyecto para mas).
Al tiempo, el evaluador (o otro miembro del equipo del proyecto) sigue encontrado fallos ya detectados y que el responsable ya le indico al programador que lo solucionara.
¿Que se ha hecho mal? Hay muchas cosas (que el responsable pruebe hasta que no vea fallos, fases de pruebas, etc..) que se puede hacer pero normalmente no hay tiempo para hacerlo por lo que lo unico que queda es FIARTE de que el programador lo va a hacer correctamente tras una (o como mucho dos) evaluación.
¿Que ha pasado? Factores a tener en cuenta:
La frustración que produce la tarea. Hacer codigo nuevo gusta, volver a un codigo que el programador creia terminado y ajustarlo no gusta.
Desconocimiento funcional de lo que se tiene que hacer.
Falta de responsabilidad con lo desarrollado. Un programador lo que quiere es terminar lo mas rapido posible y luego si hay un fallo pues intentar justificarlo con que es un fallo del grupo.
¿Que hacer para paliar estos factores?
Evaluar mientras el codigo sea nuevo.
Antes de picar nada de codigo, se debe asegurar que los programadores saben lo que tiene hacer correctamente y cual es la solucion propuesta
Suena horrible pero la solución es ser puñetero y quisquillos. Hay que mirar codigo, explicar porque ser ha hecho esto asi o asa y criticar. Con mano izquierda pero hay que ser puñetero que se justifiquen los desarrollos. Asi no solo se consigue mas calidad, se consigue que el programador sienta una relación mas estrecha con lo que ha programado.
Suscribirse a:
Entradas (Atom)