¿Cómo enumerar los procesos que esta ejecutando la máquina?

Es una pregunta que me hacen o leo frecuente.


Utilizando el Api de Win32, lo mejor es usar la función EnumProcs que esta disponible en este articulo de la Knowledge Base de Microsoft.


En el mundo .net es algo más sencillo, basta utilizar el método GetProcesses de la clase Process. Tambien hay una entrada sobre el tema en la Knowledge Base, que explica como hacerlo en VB.net pero el código en C# es bien simple:


using System.Diagnostics;



Process[] running = Process.GetProcesses();
    foreach(Process p in running)
        Console.WriteLine(p.ProcessName);

Simplemente protestar, no vale…

Habla mi vecino de blog, Sergio Vazquez sobre que hacer para convertirse en un buen programador. Para mi la clave sin duda esta en que te apasione la actividad de escribir código, pero esto solo es una precondición. Además hay que hacer un motón de otras cosas, empezando por asumir que no se puede llegar a ser un buen programador sin escribir millones de lineas de código. Tengo mis serias dudas sobre si se puede ser buen jefe de proyecto, arquitecto, o analísta sin haber escrito mucho código.


Entre los comentaríos a ese articulo, yo recomiendo los dos libros que más me han influido como programador, y que creo que me han convertido en mejor programador.

‘Code Complete’ de Steve McConnell
‘The pragmatic programmer’ de Andrew Hunt y David Thomas

A parte de esto uno de los comentarios, firmado por gogoz, viene a decir que como vas a ser un buen programador, si te dan un análisis ‘que da pena’. Bueno, pues aquí va lo que yo haría, justo depués de protestar (los que me conocen saben que protestar e intentar dar soluciones son dos de mis grandes aficiones, por ese orden).


Empezaria por explicar al analísta que el análisis no es adecuado y dejarle claro los motivos por los que no lo entiendes. Un buen analísta entendería que si el destinatario de un análisis no lo entiende o lo acepta es porque no es un buen análisis.


Lo segundo, explicarle que el único que puede estimar con precisión lo que va llevar implementar algo es la propia persona que lo va ha implementar. Esta demostrado que si quien va a realizar la tarea no participa en la estimación está tiene mucha probabilidad de ser erronea. La bibliografía sobre gestión de proyectos de software esta llena de justificaciones a esto, así que no me voy a extender.


Tecero, como probablemente el autor de un mal análisis no va a entender nada de lo anterior, pues simplemente trataria de hacer el mejor trabajo posible en la situación en la que te encuentras, sin caer en la desmotivación. Empezando por tratar de mejorar el diseño, solo las mejoras obvias, el 20% de mejoras que proporciona el 80% de mejora. Y no me preocuparia demasiado por las restricciones de tiempo, incluso el análista que no es muy habil sabe que no ha proporcionado estimaciones de tiempo realistas.


Por último, si la situación se repite, empezaria a enviar curriculums. Aunque parezca mentira hay empresas donde las cosas funcionan de manera diferente y los analístas realmente saben hacer análisis.


En relación a este tema, es muy interesante el articulo de Joel sobre como mejorar las cosas siendo un simple peón.