Traducción online al Español del libro ”97 Things Every Programmer Should Know”, contiene todo tipo de consejos y recomendaciones para los profesionales de la programación informática: refactorización, código limpio, pruebas, aprendizaje contínuo, etc. Compilación realizada por
meneame.net/user/esparta
y otro general: 97cosas.com/programador/aplica-programacion-funcional.html
programmer.97things.oreilly.com/wiki/index.php/Contributions_Appearing
sijinjoseph.com/programmer-competency-matrix/
TDD
Quizás cabe aclarar que no soy traductor, sino alguien con ganas de aportar algo. Seguro habrá como esas, muchas cosas que no apliqué bien (a mí criterio personal). Es por ello que lo dejé en un repositorio público para que todos pudieran hacer las correcciones pertinentes del modo que más le acomode (push request, o issues).
Y para programar en general, un libro que hay que leer y releer: Code Complete: A Practical Handbook of Software Construction, Second Edition: Steve McConnell
Y mis 2 pesetas, indicado sobre todo a los que empezaron a programar con un lenguaje orientado a objetos (que tendemos más a abstraer, me parece):
Cuando programes, no intentes siempre hacer algo general, que funcione siempre, en todas las condiciones, y que sea reutilizable. Empieza con algo un poco más sencillo, ad-hoc al problema, y luego vas refinando (iterando) el modelo. Mucho más productivo
Mucho mejor explicado en: Coding Horror: The Rule of Three : www.codinghorror.com/blog/2013/07/rule-of-three.html
www.youtube.com/watch?v=israoiDALwk
N cosas que deberías saber sobre X
portada seguro
#15 Donde N suele ser múltiplo de 10. No es el caso.
Como currela en seguridad informática os suplico por el amor de Ritchie que nunca desarrolleis en
Java.
www.informationweek.com/attacks/java-still-not-safe-security-experts-s
samizdat.mines.edu/howto/HowToBeAProgrammer.html
"Premature optimization is the root of all evil."
A los desarrolladores con algo de experiencia, basta con que leáis los primeros capítulos de algún libro que habla de ella, para que cada dos por tres según lo leáis, penséis "joder, es lo que digo yo" y lo asociéis a algún proyecto en que hayáis participado.
97 Things Every Programmer Should Know, 97 Things Every Software Project Manager Should Know y 97 Things Every Software Architect Should Know.
Qué casualidad que todos sean 97.
Si hubiesen utilizado una metodología ágil de desarrollo, habrían descubierto que la estaban cagando desde la primera semana. Pero nada, hay quien sigue creyendo que funcionan las metodologías basadas en "Análisis completo" -> "Diseño completo" -> "Desarrollo completo" -> "Presentación al usuario", cuando suelen fracasar miserablemente.
Java, ASP, .NET y visual basic.
Windows, Linux: C (mayoritariamente)
Facebook, twitter: php/ruby/python
De todas formas coméntale a tu jefe que en las próximas aplicaciones que vas a utilizar Phyton o Ruby a ver que te dice.
Te iba a recomendar que mirases el significado de "mayoritariamente", pero me acabo de dar cuenta que ese palabro no existe, que se dice "mayormente", así que te voy a dar un positivo.
El lenguaje a utilizar también influye del tipo de proyecto que sea, por que como sea una aplicación para un banco o algo así serio no creo que sea buena idea hacerlo con PHP.
Claro, que como la versión orignal está en inglés... se da por hecho.
cout << N << " cosas que deberías saber sobre " << X << " grafeno bueno Monsanto malo" << endl
Edit
#16 GOTO
www.meneame.net/story/diez-frases-television-repetiamos-todos-egb
#29 No estaría mal, lo veo y aviso.
a -> b no significa b -> a
En donde trabajabas ? Sal de Espana y te daras cuenta de que la realidad es muy diferente a lo que dices.
En cuanto a lo de PHP en un banco, por que razon crees que seria menos fiable que otro lenguaje ?
Si lo que quieres es programar una aplicación de escritorio en Java (como por ejemplo un conocido IDE del que no sé si habréis oído hablar llamado Eclispe ), o ejecutas Java como tecnología en el servidor (cualquier tecnología de Servlets y derivados), esas vulnerabilidades son irrelevantes.
No es que lenguajes como php, ruby y phyton sean más seguros que java, es que en esos lenguajes directamente es imposible que estas vulnerabilidades se puedan dar, ya que ni siquiera ofrecen las características que Java ofrece que son las que a la postre causan estas vulnerabilidades. Si limitamos java a los usos posibles que ofrecen esos lenguajes, la seguridad es la misma.
En todo caso, es cierto que Oracle no está respondiendo bien a los problemas que se han encontrado. Pero sustituir esas aplicaciones de java por equivalentes en php, ruby y phyton es, en algunos casos, simplemente imposible, porque estamos hablando de código java que se ejecuta en el cliente (navegador). A veces se puede sustituir por código javascript (que es lo que se debe hacer cuando sea posible) o flash (que también está lleno de vulnerabilidades).
Pero incluso así Java permite algo que no se pude hacer fácilmente con javascript: firmar el código que se va a descargar para ser ejecutado y pedir al usuario exáctamente los permisos para las cosas que quieres hacer. En javascript no es posible porque no existe un consenso de cómo hacerlo que sirva para todos los navegadores.
Vale que si lo usas mal es un infierno, vale, pero si lo usas bien... symfony.com/es/what-is-symfony
¿Y facebook? En facebook programan en php pero luego lo pasan a c o c++ con hiphop.
Java en si no es inseguro, son inseguros los applets java en navegador. Pero por lo demás es como cualquier otro lenguaje. Sinceramente si trabajas en seguridad informatica deberias tener eso claro y no ir diciendo que java es inseguro. Una parte pequeña del ecosistema java es inseguro el resto no.
La pega es que todavía no es compatible con todo, precisamente hace unos días lo probé para una aplicación en Symfony2 de 400.000 líneas de código e iba "casi bien", Doctrine no arrancaba
También de que por intereses diversos se ha divulgado la falsa idea de que los desarrollos en PHP son menos seguros y no son orientados a objetos. Ni lo primero ni lo segundo es cierto (y aunque lo fuera, el Cobol tampoco es O.O. y se sigue utilizando masivamente).
Uno de ellos es una empresa de pagos internacionales a universidades americanas (mueven mucho dinero) y todo su software está montado en Ruby (combinando servicios en Rails, Sinatra, workers...).
A la empresa de desarrollo le interesa la metodología ágil, pero al cliente también le interesa porque obtiene algo útil a cambio... desde el principio. Si ve que el proyecto cuesta demasiado para lo que va obteniendo a las dos, tres semanas, se podría cancelar. Sin metodología ágil ¿a qué se llega si la empresa desarrolladora no cumple, al juzgado después de seis meses?
Hay múltiples pruebas de que el método tradicional supone sobrecostes increíbles: busca la sentencia de BSkyB contra EDS por ejemplo, o cómo la industria militar estadounidense pagó miles de millones de más en proyectos de software fracasados y ahora se ha pasado a metodologías ágiles.
Pero hasta la fecha no he conseguido convencer al cliente de que no le puedo cerrar el presupuesto, sinó darle cifras aproximadas, y eso no lo quieren, lo cual nos lleva de nuevo a las metodologías clásicas.