Posted by carsato on April 1, 2011 at 10:52pm
Hola
En el trabajo hay un debate abierto sobre varias herramientas. La del uso de git y svn, que al final ganó git por goleada y la del uso de vim / emacs / netbeans / eclipse como editores.
Mi posición es git+vim
Me gustaría conocer vuestras opiniones al respecto y de paso si es posible que comentarais las herramientas de desarrollo que usáis para conocer el tema y a ver si así entre todos mejoramos un poco cada uno de nosotros.
Muchas gracias
Un saludo
Comments
No hay herramientas mejores o
No hay herramientas mejores o peores, sino usuarios que saben sacarle el jugo como debe ser.
Y además dependiendo de las labores a llevar a cabo necesitaras unas u otras.
Oskar
"Un poco" en desacuerdo. Hay
"Un poco" en desacuerdo.
Hay herramientas mejores y peores dependiendo de la tarea, no del usuario.
No es lo mismo un martillo que una llave inglesa, aunque ambos te pueden servir para clavar un clavo. En el ejemplo está claro cual es la más productiva y a cual se adaptará antes el usuario. Sin embargo yo estoy más a favor de usar la llave inglesa ya que a demás te sirve para desenroscar tuercas de diferentes tamaños. Es decir, te dá mayor flexibilidad. Aunque hay que adaptarse a la tarea y la selección de la herramienta adecuada es un elemento importante de dicha adaptación, un cambio de herramienta puede significar disminución de la productividad. A demás tener que manejar diferentes herramientas implica tener que aprender a manejarlas.
Metáforas y rollos a parte, en mi opinión:
- El ratón prohibido. Totalmente de acuerdo con @carlescliment. Yo todavía no me acabo de quitar el vicio. Pero es muy malo. Mejorar en todo lo posible el uso del teclado (mecanografía incluida).
- El uso de la consola es fundamental. Con ello incluyo manejo básico de vim (o similares, vim es ubicuo a si que una muy buena opción), acceso a servidores o repositorios y demás comandos básicos. Aquí también se incluye Drush para trabajar con Drupal.
- El uso de un IDE casi fundamental. Eclipse y NetBeans están muy bien. Personalmente, he probado los dos y me quedo con eclipse (por el efecto llave inglesa, claro), aunque es cierto que es un poco monstruo.
Mi configuración de Eclipse: Eclipse PDT + Aptana estudio 2.0 plugin + Drupal for eclipse de XTND.US (http://xtnd.us/eclipse/install, http://groups.drupal.org/node/39938) + Plantillas para hooks (http://drupal.org/project/eclipse) + XSL Tools + subclipse + ...
Ahora mismo esto intentando añadir a la fiesta XDebug y otras herramientas para depurar PHP y JS, así como Less para el CSS (pero aún estoy en ello). Selenium y similares tambien están en esta lista.
Más info sobre DRupal y eclipse en http://drupal.org/node/75242.
Por último, aunque de forma muy suave, desaconsejo el uso de otros editores (especialmente Notepad++, que me ha jugado alguna pasada un poco rara) u otros IDEs, así como el uso de Dreamweaver, en cuanto sea posible, y muy cariñosamente desaconsejo el desarrollo en Windows... tu vida cambia, en serio. Pensandolo mejor lo de desarrollar en Windows lo desaconsejo sin suavidad. Creo que ese es el primer paso para mejorar la productividad.
Un saludo,
Alessandro MAscherpa.
Todos aquellos que dicen no
Todos aquellos que dicen no usar el ratón, pero todavía usan QUERTY en lugar de DVORAK deberían ser baneados de esta conversación ;)
:)
Lo último en productividad es esto: http://mail.google.com/mail/help/motion.html
Qué espectáculo sería unas
Qué espectáculo sería unas oficinas al completo utilizando eso durante 8 horas cada día!
Git y Vim
Git y Vim me han ayudado mucho a ser más productivo y llevar mejor control de los cambios y publicaciones. Aunque todavía no he investigado todo el potencial de Vim, lo que ya sé es suficiente para trabajar más rápido que con otros IDEs como Netbeans o Eclipse.
Senior Developer at Lullabot
https://www.lullabot.com/who-we-are/juampy-nr
Aunque es posible considerar
Aunque es posible considerar herramientas como Vim o Emacs IDEs (Entorno Integrado de Desarrollo), más bien parecen editores. La leche de potente, eso sí. Y con un alto grado de integración con muchas herramientas (sino todas las necesarias), gracias a la ejecución de comandos desde el propio IDE.
Aun que la ubicuidad de vim (o similares) y de la línea de comados los hacen opciones muy atractivas, creo que el IDE necesita de un entorno gráfico para facilitar ciertas funciones, como edición gráfica de modelos, pestañas y regiones para tener diferente funcionalidad a la vista... autocompletar... comparar versiones de código... conexión con repositorios de tareas... tareas de depuración de código... bla bla bla...
También tengo que decir que no he visto nada tan rápido como una persona editando código con vim. Pero es cierto que el trabajo del desarrollador no se reduce a "picar" código.
Aunque es cierto que cualquier tarea que se quiera realizar con un IDE como Eclipse o NetBeans se puede ejecutar desde la línea de comados con las diferentes herramientas que hay, y que se puede hacer de manera muy rápida, no se si es es la mejor mánera de ser productivo, ya que la productividad no incluye únicamente la velocidad. A parte, habría que comparar tambien los costes que tiene poner a alguien en un sistema de producción basado sólo con línea de comandos. Por la educación como usuarios de informática que hemos tenido la mayoría, creo que es más facil si el usuario empieza con entorno gráfico.
Por otra parte hay IDEs que integran consolas para ejecutar operaciones en la línea de comandos he incluso editar código directamente en ellas. Incluyendo otras bondades que ofrece el IDE. véase por ejemplo: http://www.aptana.com/products/studio3
Un saludo,
Alessandro.
Como dice Oskar opino que no
Como dice Oskar opino que no hay mejores ni peores si no que cada uno te da lo que buscas, o no.
Yo uso Kate y KDevelop principalmente por que simplemente modificando el .xml de PHP y alterando el diccionario de palabras puedo hacer lo que me de la gana con el realce de colores, tiene una flexibilidad que jamás nunca vi (por poner un ejemplo muy tonto die(); exit(); return; o var_dump(); son las únicas funciones que salen en rojo chillón, las estructuras de control en verde, los bucles en naranja, las funciones de Drupal (si si, incluirlas es super fácil) en azul y las de PHP en morado), NetBeans y Eclipse me parecen muy buenos editores pero ambos están hechos en Java y alguna que otra vez me ha pegado un pete inesperado que no me ha gustado tanto... a parte que no me deja pintar todo lo que a mi me gustaría como pasa con KDevelop y Kate.
En Windows Notepad++ y TortoiseSVN, en Linux KDevelop + RabbitSVN (quizá como no usamos repos Git no lo usamos aún, aunque yo en mi máquina lo tengo instalado así por verlo... je!)
Saludos.
<?phpecho $signature
?>
NetBeans y Eclipse me parecen
Veo que no solo me pasa el cierre de aplicaciones de Java.
Otro de los problemas de estos dos es su consumo de recursos. Con Geany consigues un resultado muy bueno, la única pega es que no se le puede incorporar la api de drupal sino sería simplemente genial (definir la versión de drupal en el proyecto para acceder a una u otra api).
Oskar
$ pmap 40724072: /bin/bash
$ pmap 40724072: /bin/bash /home/carles/apps/netbeans-6.9.1/bin/../platform/lib/nbexec --userdir /home/carles/.netbeans/6.9 --jdkhome /usr/lib/jvm/java-6-openjdk/jre --branding nb --clusters /home/carles/apps/netbeans-6.9.1/nb:/home/carles/apps/netbeans-6.9.1/bin/../ergonomics:/home/carles/apps/netbeans-6.9.1/ide:/home/carles/apps/netbeans-6.9.1/bin/../java:/home/carles/apps/netbeans-6.9.1/bin/../xml:/home/carles/apps/netbeans-6.9.1/bin/../apisupport:/home/carles/apps/netbeans-6.9.1/bin/../webcommon:/home/carles/apps/netbe
0000000000400000 876K r-x-- /bin/bash
00000000006da000 4K r---- /bin/bash
00000000006db000 36K rw--- /bin/bash
00000000006e4000 24K rw--- [ anon ]
0000000001a3a000 292K rw--- [ anon ]
00007f5b8920b000 1512K r-x-- /lib/libc-2.11.1.so
00007f5b89385000 2044K ----- /lib/libc-2.11.1.so
00007f5b89584000 16K r---- /lib/libc-2.11.1.so
00007f5b89588000 4K rw--- /lib/libc-2.11.1.so
00007f5b89589000 20K rw--- [ anon ]
00007f5b8958e000 8K r-x-- /lib/libdl-2.11.1.so
00007f5b89590000 2048K ----- /lib/libdl-2.11.1.so
00007f5b89790000 4K r---- /lib/libdl-2.11.1.so
00007f5b89791000 4K rw--- /lib/libdl-2.11.1.so
00007f5b89792000 248K r-x-- /lib/libncurses.so.5.7
00007f5b897d0000 2048K ----- /lib/libncurses.so.5.7
00007f5b899d0000 16K r---- /lib/libncurses.so.5.7
00007f5b899d4000 4K rw--- /lib/libncurses.so.5.7
00007f5b899d5000 128K r-x-- /lib/ld-2.11.1.so
00007f5b89a71000 252K r---- /usr/lib/locale/es_ES.utf8/LC_CTYPE
00007f5b89ab0000 1144K r---- /usr/lib/locale/es_ES.utf8/LC_COLLATE
00007f5b89bce000 12K rw--- [ anon ]
00007f5b89be1000 4K r---- /usr/lib/locale/es_ES.utf8/LC_NUMERIC
00007f5b89be2000 4K r---- /usr/lib/locale/es_ES.utf8/LC_TIME
00007f5b89be3000 4K r---- /usr/lib/locale/es_ES.utf8/LC_MONETARY
00007f5b89be4000 4K r---- /usr/lib/locale/es_ES.utf8/LC_MESSAGES/SYS_LC_MESSAGES
00007f5b89be5000 4K r---- /usr/lib/locale/es_ES.utf8/LC_PAPER
00007f5b89be6000 4K r---- /usr/lib/locale/es_ES.utf8/LC_NAME
00007f5b89be7000 4K r---- /usr/lib/locale/es_ES.utf8/LC_ADDRESS
00007f5b89be8000 4K r---- /usr/lib/locale/es_ES.utf8/LC_TELEPHONE
00007f5b89be9000 4K r---- /usr/lib/locale/es_ES.utf8/LC_MEASUREMENT
00007f5b89bea000 28K r--s- /usr/lib/gconv/gconv-modules.cache
00007f5b89bf1000 4K r---- /usr/lib/locale/es_ES.utf8/LC_IDENTIFICATION
00007f5b89bf2000 8K rw--- [ anon ]
00007f5b89bf4000 4K r---- /lib/ld-2.11.1.so
00007f5b89bf5000 4K rw--- /lib/ld-2.11.1.so
00007f5b89bf6000 4K rw--- [ anon ]
00007fff4cbc4000 132K rw--- [ stack ]
00007fff4cbff000 4K r-x-- [ anon ]
ffffffffff600000 4K r-x-- [ anon ]
total 10972K
Netbeans con 7 pestañas y 19 plugins activos.
¡10 megas no es para tanto!
A dia de hoy, Java arrastra
A dia de hoy, Java arrastra su estigma.. Yo uso Netbeans y un portátil nuevo llenito de RAM de todos los colores y no falla: 0 petes en 1 año. Estamos aquí contratando servidores de gigas de ram y gigas de disco duro y bien de CPU para una web 90% cacheada y luego arañamos meguillas para el IDE?
No cuadra.. to uso notepad++ cuando tengo que tocar un archivo, pero netbeans cuando tengo que trabajar en un proyecto con VCS, issue tracker, phpdoc, phpunit y no se que más.. No es comparable.
Kate/KDevelop
Yo también uso Kate y estoy empezando a ponerme serio con KDevelop ahora que ya tengo la versión con soporte para Git.
Me ha interesado mucho lo que comentas del resaltado de palabras, sabía que se podía tocar pero aún no me he puesto.
También hay un plugin para Kate/KDevelop con fragmentos de código para Drupal:
https://github.com/dereine/kate-drupal-snippets
No lo he podido probar mucho, pero tiene buena pinta, y estando en GitHub quizá se pueda ir extendiendo con la colaboración de todos ;-)
El concepto de repositorio
El concepto de repositorio distribuído de git se está imponiendo al centralizado de svn/cvs. La mayor facilidad para gestionar branches también está haciendo a muchos usuarios de subversion pasarse a git. Yo aún no lo he probado, así que no puedo hacer un análisis profundo.
Respecto a las herramientas de edición, desde luego el uso de vim es imprescindible si queremos defendernos, por ejemplo, en el acceso remoto a servidores. Sin embargo, para el día a día, aplicaciones como netbeans o eclipse ofrecen demasiadas ventajas. Me refiero, por ejemplo, a la integración de subversion en el editor, la comparación visual de diferencias (estilo meld), la apertura rápida de ficheros o el acceso a la documentación de una función al escribir su nombre.
Aún así hay que tener cuidado con los IDEs. La primera amenaza que presentan es que de ninguna manera tenemos que hacernos dependientes del IDE. Por ejemplo, muchos programadores que desarrollan en .NET son incapaces de hacer algo fuera de Windows/Plataforma de desarrollo. Por otra parte, el autofill y otras características pueden hacernos perezosos.
EDITO: En cualquier caso, para aumentar nuestra productividad debemos dedicar un tiempo a aprender los atajos de teclado y evitar llevar la mano al ratón a toda costa.
Respecto a las herramientas
Esto hace años que ya no se hace, o no se debería hacer, salvo para los archivos de configuración de apache o php, por decir algo. A día de hoy, si te tienes que conectar a un servidor para tocar un archivo en producción algo no está del todo definido en el proceso de staging.
En un servidor se ejecutan comandos, no se programa, o al menos en países civilizados no debería hacerse, creo..
Vale, pero pongamos que una
Vale, pero pongamos que una nueva necesidad de tu app necesita de un cambio en /etc/mysql/my.cnf.
¿Esto también debería formar parte del proceso de staging? Humildemente pregunto, me interesa realmente tu enfoque.
Bueno, es de los casos que
Bueno, es de los casos que comentabas, y a los que me refería yo.
A estas horas ya no rijo.
Casualmente ni php.ini ni
Casualmente ni php.ini ni apache*conf ni my.cnf requieren de sintaxis php, integración con VCS, y velocidad de edición, o al menos en mi opinión. Controlar la configuración de un servidor en producción es una buena práctica, ya que permite almacenar un registro de cambios, personas y razones.
Estoy de acuerdo en casi todo lo que cada uno ha expuesto, me refiero a que lo importante de la herramienta es que te permita trabajar. Habrá gente que pierda tiempo aprendiendo y luego lo aproveche programando y otros que lo enfoquen al revés, productividad alta desde el primer día sin posibilidad de mejorar (y conste, que no digo cual de los casos es cual). Yo personalmente prefiero un IDE que me deje trabajar con el ratón y con el teclado, para hacer lo que más rápido me resulte en cada caso.
Respecto al VCS, Git es bueno, muy bueno, y complejo, mucho, en muchos casos el 15% de las opciones son suficientes, realmente merece la pena el esfuerzo de aprender a usarlo para acabar haciéndolo? Hay proyectos en los que he tenido que trabajar con 3 VCS a la vez: cvs por los parches para los contrib de drupal, svn para los modulos propios, y mercurial para hacer backups incrementales del servidor. Al igual que el editor, el VCS bueno de verdad es el que tu necesitas, el que no te limita ni te complica.
Mi preferencia personal es bzr-svn-git-cvs en ese orden, y netbeans-vim-notepad++(y parecidos) en editores. Claro que para que funcione bien necesitas montar un entorno de desarrollo que te sirva, si no, estas vendido. Pero por tocar archivos, hasta con el notepad de toda la vida si hace falta :)
Controlar la configuración de
Esto es lo que me interesaba, sin querer desvirtuar el hilo. Tener los archivos de configuración de mysql, apache y php en el repo o no.
El lado oscuro que le veo es que, aunque el entorno de preproducción y el de producción deberían ser iguales, los entornos de los desarrolladores no tienen por qué ser iguales. Ni en capacidad de proceso, ni en memoria, ni en arquitectura del computador.
Por ejemplo, sobre un mismo proyecto puede haber personas que desarrollen en Mac (diseño, aplicaciones para móvil) conviviendo con desarrolladores sobre Linux.
Controlar versionado, pero no necesariamente clonar
Vamos a ver, aunque lo ideal sería que los entornos de desarrollo e integración fuesen exactos al de producción... esto no siempre es posible.
Que los distintos archivos de configuración de producción estén sometidos a control de versiones es estupendo (sobre todo en sistemas que evolucionan durante mucho tiempo)... ahora bien, esto no significa que deban emplearse esas mismas configuraciones ni siquiera para integración, ya que muchas pueden ser función del hardware subyacente y hay optimizaciones que ni siquiera merece la pena acomoter en integración.
Conste que hablo desde el punto de vista de un sysadmin.
Salu2
Precisamente porque tu punto
Precisamente porque tu punto de vista parte de sysadmin, le doy doble valor.
Por lo que entiendo, lo ideal es que se utilice el repositorio a modo consultivo y de historial de cambios, pero no como fuente en la configuración de los equipos locales ¿cierto?.
Muchas gracias por tu contestación!
Hace años que no llevo sistemas para equipos de desarrollo
Mi opinión es que si 2 servidores no son iguales y se están empleando para lo mismo lo más probable es que tengan que llevar configuraciones diferentes (o al menos sería lo óptimo).
La configuración de los servidores de producción muchas veces se hace demasiado rápido y se prueban cosas de forma sucesiva sin evaluar el impacto que han tenido... en este sentido un sistema de control de versiones o simplemente unos buenos comentarios documentando fechas, cambios, origen/motivo y resultados ya hace maravillas. ( Para un cuadro de herramientas más "profesionales" recomiendo mirar -> https://wiki.fourkitchens.com/display/PF/Stack+management+and+monitoring... ). Yo personalmente (y de momento) distribuyo configuraciones mediante un disco GlusterFS compartido entre servidores (que son casi clones), pero lo ideal es tocar en el repositorio y hacer el deployment usandolo como origen.
En cuanto a las máquinas de dev y staging de tipo servidor, han de procurar que al menos coincida la distribución del sistema operativo, número de bits y el nivel de actualización.... para evitar el mayor número de problemas en el paso a producción.
Las máquinas de desarrollo individuales (y aunque los puristas de los sistemas me crucificarán), prefiero que cada desarrollador tenga el control completo de su máquina... se supone que son "mayorcitos" y esa política permite que si alguien quiere implicarse más en las pruebas y el área de sistemas lo haga sin mayor complicación.
Salu2
Además de lo que ha incluido
Además de lo que ha incluido NITEMAN, la ventaja de los archivos de configuración habituales es que en muchos casos soportan incluir otros archivos de configuración adicionales, es decir, la configuración principal en un archivo (que puede ser compartido por todos los entornos) y la personalización en otro (que puede ser diferente para tipo de entorno), esto facilita mucho hacer deploy de repositorios sin cargarte los datos 'específicos' del entorno, que por otra parte no tienen porque estar guardados en el repo (como por ejemplo, credenciales).
@carlescliment, creo que ahora si que se empieza a desvirtuar el hilo un poco (ya que no estamos en el rant de herramientas, que pena!!). Si te parece podemos abrir otro hilo para esto, pero si NITEMAN se apunta!
Me parece buena idea abrir un
Me parece buena idea abrir un hilo nuevo así que si os parece bien doy por concluído este "branch" del hilo principal y después de comer escribo algo más o menos elaborado sobre staging para que me echéis una mano si disponéis de tiempo.
Un saludo y muchas gracias por vuestros consejos.
Tal vez sea muy principiante
Tal vez sea muy principiante para poder hablar de este tema, aunque debo de decir que desde que carsato inicio el tema he estado pendiente.
Al final hoy ha explotado, Estoy de acuerdo con que la persona siempre es ella y su circunstancia por lo tanto estamos ahí.
En estos momentos estoy realizando mis prácticas de estudiante, al llegar a la empresa y decirme que tenia nuevo lenguaje de programación y que usaban el vi, pues no se que comentar(bajon).
al llegar a la empresa he instalado un ubuntu y he descargado gvim del repositorio de https://github.com/akitaonrails/vimfiles.git, pues la verdad que he quedado un poco sorprendido, tal vez sea un buen paso para no usar el ratón.
Como VIM no hay nada igual, tal vez Emacs
Con todo respeto, quiero expresar que en Ideup! hemos asumido una mentalidad de productividad total con las herramientas, esto es, sacar el máximo de lo que usamos día a día. Yo he desarrollado en Eclipse, Netbeans, Geany, entre otros y os puedo asegurar que hay cosas que no se pueden hacer ni de coña en Netbeans / Eclipse. Lo que pasa es que la curva de aprendizaje es dura y si quieres adaptarte a VIM totalmente, tienes que entrarle a las entrañas y saber programar vimscripts, cosa que lleva su tiempecillo, yo he pasado varios fines de semana trasteando y personalizando algunas cosas.
Yo lo digo en Ideup! y lo repito aquí, un programador verdaderamente profesional usa o Emacs o VIM y se complementa algunas veces (cuando muy necesario) con Netbeans y Eclipse. La velocidad de programación que se obtiene para moverse en el código con VIM no la tiene ningún otro editor (excepto Emacs). Un usuario de VIM lo tiene muy fácil para usar Netbeans y Eclipse, pero... ¿al revés? Lógicamente cuesta y mucho, son horas de dedicación para dominarlo, para domarlo, para quererlo.
Si alguien se opone a mi postura yo no me quedo en la palabra, me voy a los hechos, os lo demuestro. Hacemos un mano a mano cuando quieran. Y para el que tenga curiosidad le invito a que vean http://vimcasts.org/ Comprobaréis que su Eclipse y su Netbeans no dan la talla.
Y si hay talento suelto por ahí que sepa Drupal y que quiera hacerse experto en VIM que lo diga y le invitamos a nuestras oficinas a que descubra el potencial de un editor profesional.
Como anexo os quiero dar un listado de plugins de VIM que son imprescindibles:
dbext - http://www.vim.org/scripts/script.php?script_id=356 (tira consultas a tu BD sin salir del VIM además de funciones de autocompletado)
FuzzyFinder - http://www.vim.org/scripts/script.php?script_id=1984 (para los amantes de spotlight) encuentra archivos sin tener que navegar por un árbol de directorios.
Hypergit - http://www.vim.org/scripts/script.php?script_id=2954 (integración de GIT en VIM)
EasyGrep - http://www.vim.org/scripts/script.php?script_id=2438 (Grep con interfáz simple para lanzar búsquedas en el código)
NerdCommenter - http://www.vim.org/scripts/script.php?script_id=1218 (comenta y descomenta código con un comando simple cc y cu)
Bisect - http://www.vim.org/scripts/script.php?script_id=2960 (muévete a la posición de código de la página actual partiendo por la mitad tus movimientos)
Gundo - http://www.vim.org/scripts/script.php?script_id=3304 (mantén un control de cambios visual con el undolist de vim, un control de versiones en tu editor que complementa a tu GIT)
Y otro día seguiré que estoy cansado... que alguien pregunte qué hace su Netbeans / Eclipse que quiera hacer en VIM y lo vamos discutiendo.
Para que veáis la potencia de los comandos en modo EX de VIM os paso este cheatsheet.
http://www.rayninfo.co.uk/vimtips.html
Muchos saludos, un abrazo. Por cierto, en Ideup! seguimos buscando desarrolladores Drupal de nivel, así que si alguien quiere que me lo diga.
No voy a ser yo quien te
No voy a ser yo quien te lleve la contraria. Creo que, seguramente, un experto en Vim edite más rápidamente que alguien que no lo es.
Sin embargo, la funcionalidad que ofrecen los siguientes plugins:
FuzzyFinder (SHIFT+ALT+o)
Hypergit (plugin equivalente)
EasyGrep (CTRL+f ALT+e)
NerdCommenter (CTRL+SHIFT+c)
las proporciona NetBeans con la instalación por defecto.
Por supuesto, estoy seguro de que con Vim también se pueden hacer cosas como:
- debugging (CTRL + F5)
- run tests (ALT + F6)
- code standards formatting (ALT + SHIFT + f)
- integración con Hudson y Jira (plugins equivalentes)
y muchas cosas más. Pero el coste de integrar todos esas funcionalidades es caro.
Por otra parte, cuando trabajas en un grupo de, digamos, 20 desarrolladores, formarlos a todos como expertos en vim no es sencillo.
He trabajado con gVim durante unos 3 años, y con Komodo y NetBeans en los dos últimos. En mi empresa siempre he defendido los editores "hardcore" como vi y xemacs, pero con el tiempo me he dado cuenta de que no es tan importante como yo pensaba. Si dominas tu IDE, sea cual sea, puedes acercarte (sí, sin llegar) a la productividad de un experto en vim con un coste de aprendizaje mucho menor.
Por último, me parece importante destacar que ni ser experto en Vim nos convierte en buenos programadores, ni programar en IDEs nos hace peores. La programación se parece bastante a la literatura. Si Dostoievsky viviese hoy y escribiese en Wordpad en lugar de en LaTeX, Crimen y Castigo no sería una obra peor.
¿Me estás retando a un duelo?...
Hola @citlacom.
... Te voy a a ahorrar la intriga: seguro que vim es más rápido.
Puede que "un programador verdaderamente profesional usa o Emacs o VIM", pero no creo que sea herramienta suficiente para un ingeniero. Aunque si pienso que es obligatorio conocerla y defenderse con ella.
Estoy completamente de acuerdo (100%) en que la velocidad de un desarrollador curtido en vim no es alcanzable desde Eclipse, NetBeans o similares. Gracias por el screencast, pero yo lo he visto con mis propios ojos y se de que estás hablando. Sin embargo coincido con @carlescliment en que la calidad de un trabajo de programación no se mide por lo rápido que se ha hecho (aunque la velocidad es importante) o que tecnología se usó. También coincido con él en que en un equipo de desarrolladores lo importante es homogeneizar la forma y las herramientas de trabajo, y tu mismo has mencionado que la curva de aprendizaje de vim al completo es durilla. En un equipo de trabajo es más importante el rendimiento global que el individual.
Muchas gracias por los enlaces y los comentarios sobre vim.
Ya que estais buscando personal, te recomiendo este libro: http://www.joelonsoftware.com/items/2007/06/05.html
Por último, quiero añadir que, aunque las herramientas marcan una diferencia y que hay unas más adecuadas que otras, aunque no nos pongamos de acuerdo en cuales (las opiniones en este hilo en particular, y en el mundo geek en general, lo demuestran), la herramienta más importante que usa un desarrollador no es ni vim ni Eclipse ni ....(pon aquí el software, el hardware o el mobiliario que quieras).... sino el cerebro.
Un abrazo a todos,
Alessandro Mascherpa.
El blog de Joel es de lo
El blog de Joel es de lo mejorcito.
Más bibliografía:
The Productive Programmer, en mi opinión un must-read.
The Passionate Programmer, muy inspirador.
El blog de Joel es de lo
Srry, duplicado
Yo he usado una rama bastante
Yo he usado una rama bastante diversa de herramientas hasta ahora para desarrollar Drupal, Eclipse/Aptana, Netbeans, Komodo (la versión de pago es excelente) en modo IDE, Coda, Textmate en modo "mac", y algunas otras.
Me parece que decir que un "verdadero profesional" usa vim o emacs es una afirmación bastante extremista, yo uso actualmente Eclipse, con varios plugins para cosas que hago habitualmente (las cosas con git por ejemplo las hago en línea de comandos) y no creo que ello me haga menos profesional que si usara vim, imagino que habrá quien se sienta más cómodo con algo menos visual como vim y quién prefiera un IDE más amigable.
Que una herramienta sea difícil de utilizar o tenga una curva de aprendizaje más pronunciada no la hace más profesional, solamente menos accesible.
Dejo este toque de humor que ha puesto carnau en IRC http://xkcd.com/378/
Decir que para ser
Decir que para ser verdaderamente profesional hay que usar VIM o Emacs, creo que es pasarse. La calidad de tu código no va influída por el programa que empleas para hacerlo. Además, todo el mundo sabe que los verdaderos programadores usan MS Paint: http://i.min.us/ikq8hS.gif
Yo lo digo en Ideup! y lo
Agradezco tu juicio de valor hacia la profesionalidad de algunos entre los que me incluyo.
Excelente aporte
Lo que te agradezco de este comentario es el montón de referencias que pones de VIM. En mi entorno de desarrollo estoy integrando sobre UBUNTU VIM+GIT para desarrollar para Drupal (estos dos últimos son nuevos para mi) , si tienes referencias de manuales y guías de valor (si pudiesen ser en español mejor) te agradecería un montón.
mis 2¢
Más allá del conato de incendio que se vislumbra quisiera comentar un par de cosas basado en mi experiencia:
en el trabajo usamos svn+trac --para nuestra escala no necesitamos otra cosa. Git está muy bien, y lo uso en otros ámbitos (drupal.org) pero no necesitamos "ir a la moda" migando nuestros repositorios a git ni nuestros tracs a redmine o cualquier cosa más sexy.
personalmente también he concluido que el uso del ratón es inversamente proporcional a mi productividad. Conocer los atajos de teclado es fundamental. Muchas veces recurro al ratón pero prefiero perder un poco de tiempo en aprender algún atajo que perpetuar el uso de ratón para esa tarea determinada.
en cuanto a editores: uso habitualmente vim y gedit. A la sombra de los siempre respetables vim/emacs o los featurerich netbeans/eclipse, gedit puede sonar a chiste. Sin embargo para mí es una herramienta sencilla con las 3 necesidades típicas: indentación, syntax highlight, buscar/reemplazar.
del resto: uso gnu/linux (debian en concreto) y la línea de comandos intensivamente. En línea de comandos es muy productivo conocer bien la shell y las típicas herramientas unix: grep, find, wc, chmod/chown,... y ya entrando en el ámbito drupal por supuesto es fundamental para mí el uso de devel, drush y asociados.
En resumen mis tareas de desarrollo (y administración) se basan en la línea de comandos, y dependiendo del entorno tiro de vim o bien de gedit. En escritorio aparte de gedit, firefox/mozilla, xchat/gaim no uso muchas otras aplicaciones habitualmente.
Video de presentación más que recomendable
Aunque puede que los contenidos del video sobrepasen los límites de la "discusión" os recomiendo ver:
http://xml-utils.com/2010/07/16/disponible-ya-el-video-de-la-charla-sobr...
Un saludo,
Alessandro.
Yo otro de la logia VIM, pero con matices
Kaixo
Grata discusión, yo como más de uno tengo el vim+git como elección para el desarrollo, la verdad que en mi caso el no sacar las manos del teclado es uno de sus grandes virtudes, entre otra tantas.
Os dejo mi backup de Vim con el .vimrc aqui: https://github.com/karlosgliberal/VimBackup, es un cumulo de apaños y caos personal, pero a mi me rula. Estoy migrando la conf a la solución que ofrece el gran tpope vim-pathgen https://github.com/tpope/vim-pathogen
En lo que respecta, creo que la ubicuidad de Vim lo hace muy poderoso y mas con si lo empaquetas con pathogen ya que tu conf la puedes instalar en cualquier terminal que te encuentres.
Por otro lodo si que veo que su curva es muy empinada y esto hace que no todo el mundo se apañe bien o quiera apañarse.
En investic aun teniendo los perfiles clásicos, diseñadores, maquetadores(css) desarrollador e integrador, todas acabamos usando un editor, pero no todos le van ha sacar el mismo rendimiento a la potencia de VIM. La elección es Komodo. Ya que una mala experiencia con eclipse les creo rechazo XD
De todos modos con la llegada de features+drush+git la forma de desarrolla creo que sea a simplificado en lo que al stagning se refiere y ahora el trabajo en local permitira configurar los IDES de nuevas formas un ejemplo de @gaborhojtsy con tower entorno para git http://twitter.com/#!/gaborhojtsy/status/41168317850988544
Salud
Aquí uno "poco pofesional"
Por suerte no entro en la categoría de desarrollador... pero como sysadmin utilizo joe (cuando no cat, grep, sed y demás hierbas), porque me resulta más comodo.
Y ya sé que las configuraciones no deberían tocarse en los servidores de producción sino gestionarse mediante control de versiones y deployment (no me crucifiqueis)... pero todos lo hacemos.
Salu2
Se ha planteado que para ser
Se ha planteado que para ser un buen programador hay que uar vim por el tema de no tener que usar el ratón.
En ese caso quizás nos tengamos que plantear el hecho de saber mecanografía y tener al menos 250 o 300 pulsaciones por minuto (se puede hacer) así mejoramos la productividad todavía mas.
No creo que la velocidad sea sinónimo de productiviad, la productividad debería reflejarse más bien en la calidad del trabajo, esto no solo es "picar código" sino planificar el código que hay que picar, porque se trabaja por esa línea y sobre todo documentar lo que se hace.
Por otro lado, también hay que diferenciar en las diferentes labores que se pueden llevar a cabo en drupal.
*Un arquitecto de software/jefe de proyecto no creo que este programando código más de un 10% de todo el proyecto el resto se encargará de ver módulos, soluciones de los módulos, rendimiento, etc... y para esto muy posiblemente utilice un navegador.
*Un diseñador de front end tendrá que hacer un uso intensivo de firebug, firephp, webdeveloper, la consola de jquery, etc... y para ello a día de hoy va a necesitar el ratón para manejarse y poder recorrer el dom a gusto en firebug entre otras cosas.
*Un programador e back end si que tendrá que programar de lo lindo, pero ya es opción personal de cada uno si usar la consola para las querys de myql o alguna otra herramienta con interfaces gráfica.
*Un sysadmin sobre todo utilizará consola, aquí que hablen los dos sysadmin que tenemos ,que vean que les ajuntamos :D
Pero quiero felicitar a Ideup por realizar una formación de herramientas a sus programadores, "personalmente creo" (opinión personal, que nos conocemos ilo ;) que es una muy buena política de empresa el definir herramientas a utilizar y dar una formación de las mismas para poder trabajar de forma homogénea en la empresa.
Un saludo
Oskar
Creo que este post va sobre
Creo que este post va sobre herramientas de desarrollo, no de roles en la organización.
Si hablamos de coches que consumen poco, nos da igual que el conductor conduzca cada día para ir al trabajo, sólo los fines de semana, o sea taxista. Lo que nos reúne aquí es averiguar qué coches tienen menor consumo.
La productividad sí está relacionada con la velocidad a la que trabajamos, entre otras cosas. Como que nuestro código no produzca trabajo futuro, es decir, que esté libre de bugs, documentado y sea fácilmente mantenible. Pero si en estos otros aspectos somos idénticos, y lo único que nos diferencia a tí y a mí es que tú utilizas mejor tu herramienta (abstenerse de comentarios jocosos), obviamente eres más productivo que yo.
Creo que este post va sobre
Yo me estaba refiriendo a diferentes tipos de desarrolladores con un nivel más o menos técnico y que tienen que desarrollar, no al todo el aspecto de profesionales dentro de una empresa.
No hablo de comerciales, directivos, administración, etc...
Y como he dicho, según que tipo de desarrollo se haga se necesitarán unas herramientas u otras.
Oskar
Me acabo de leer el hilo de
Me acabo de leer el hilo de un tirón y creo que está muy bien. Hay opiniones para todos pero también hay mucha información útil que en algunos casos conocía y en otros no ( la mayoría ).
Yo uso vim por lo mismo que uso Drupal. Se pueden hacer las cosas de otra forma, pero al final, si te lo puedes permitir, invertir tiempo en estas herramientas te va a reportar un beneficio que compensa el (mucho) tiempo extra que dedicaste/dedicas al principio. Me molan las herramientas libres porque dedicarles tiempo es un triple beneficio (para tí, para la herramienta y para el sitio donde curres), aunque es verdad que a veces se hace duro, sobre todo si la herramienta/programa no está algo maduro.
También es importante el rendimiento del equipo y el poder ponerse al tema sin tener que perder demasiado tiempo en configurar nada o aprender mucho, por lo que el uso de editores ricos en características es más que respetable. Quiero recordar aquí que "ni ser experto en Vim nos convierte en buenos programadores, ni programar en IDEs nos hace peores. La programación se parece bastante a la literatura. Si Dostoievsky viviese hoy y escribiese en Wordpad en lugar de en LaTeX, Crimen y Castigo no sería una obra peor." (carlescliment)
Me ha gustado el apunte del teclado dvorak, que no conocía creo que lo probaré a ver que tal, aunque solo sea por curiosidad.
Lo que si pienso implantar en mi vida diaria es http://mail.google.com/mail/help/motion.html y si tengo algo de tiempo me gustaría poder desarrollar el Drupal motion/gestures y el Vim motion. Podría llegar a ser realmente divertido una conferencia convención de estos programas.
Muchas gracias
Un saludo
Lo que si pienso implantar en
No se si querías dar un toque de humor, pero lo que yo he leído es que gmail motion es un April fool's de Google.
Este módulo dió mucho que hablar en su día: http://drupal.org/project/webcam_trigger
joe, pcambra, eso lo tienen
joe, pcambra, eso lo tienen ya hasta los de gormiti para los tazos que vienen en las bolsas de los muñecos, pero no deja de ser una broma de 'augmented reality', ya que los patrones de reconocimiento son demasiado fijos, no hablemos ya de movimiento.
Esta claro que programar mientras haces una clase de taichi delante de la webcam es lo que viene llamandose zen programming. Lo que no tengo claro es que si le ponemos esa misma cámara a jonhattan, automaticamente todas las issues se empezarían a marcar como won't fix :)
Si, era un toque de humor :)
Si, era un toque de humor :)
El módulo que comentas sería muy bueno para tratar de implementar un drupal motion.
La verdad es que seria la leche si drupal te reconociese algunos gestos. Podría llegar a ser un avance muy interesante en experiencia de usuario. Quien sabe, puede ser que algún día lleguemos a verlo. Es posible que cuando el reconocimiento de imágenes (en drupal) esté más avanzado sea posible hacer aplicaciones interesantes empleando una webcam.
Un saludo
A través del Kinetic, la
A través del Kinetic, la cámara de la Xbox, han logrado hacer realidad el Gmail Motion, aunque el video explicativo sigue pareciendo de broma. Lo de pegar el sello tiene su guasa.
Video
www.xacobe.net
Jaja, buen resumen!
Jaja, buen resumen!
Algunas herramientas
En mis primeras experiencias programando Drupal estoy utilizando Eclipse (super sencillo para programar) quiza no ganes esos segundos preciados pero me parece bastante potente y en mi opinion bien configurado esta perfecto para programar modulos drupal.
En esta URL se puede ver como configurar eclipse y ponerlo a punto para trabajar con drupal http://drupal.org/node/75242
ahora para que puedas sacarle el jugo a Drupal programando y extenderlo utiliza los modulos
devel
drush
saludos....
Para los que gustéis trabajar
Para los que gustéis trabajar con eclipse que sepáis que hay un Drupal-bundle para Apatana Studio 3.0 (una distro de eclipse) en preparación: https://github.com/HollyIT/Drupal-Bundle-for-Aptana
Aún no lo he probado pero pinta bien.
Y en general deciros (a los que no lo supieseis aún) que hay un grupo especifico para temas IDE en: http://groups.drupal.org/drupal-ide
Un saludo,
Alessandro Mascherpa.
Promovido al grupo Spanish
Todas las consultas técnicas se deben realizar en el grupo Spanish y opcionalmente en algún grupo geográfico de interés.
Gracias por su colaboración.
--
[develCuy](http://steemit.com/@develcuy) on steemit
Bueno como parece que nadie
Bueno como parece que nadie lo ha comentado tdavía yo opto por PHPStorm que aunque es de pago, recomiendo encarecidaemnte que lo proveis. Según se rumorea fue el ejemplo a seguir para eclipse, diferencias: sobre todo VELOCIDAD, eclipse muere con la velocidad en cuanto tienes varios proyectos y tiene que hacer acciones de indexado a todos ( por poner un ejemplo) además tiene integración con los controles de versiones sin más, amén de una interfaz muy usable para gestionar las actualizaciones y commits.
En el tema de vim solo puedo decir una cosa, todo desarrollador debería conocerlo ya que te saca de más de un apuro, se puede hacer todo lo que se puede hacer con cualquer IDE solo hay que tener tiempo de aprender.
Saludos.
PHPStorm sin duda
Pasé por netbeans, eclipse, zend studio, aptana y uno que otro mas, pero sin dudas, el día que estuvo en mis manos phpstorm, dejé de buscar.
No solo es rápido y consume poca ram. ademas entiende a la perfección jquery, css y php y definitivamente su asistente de código es una delicia.
He estado utilizando mucho
He estado utilizando mucho tiempo diferentes IDEs y herramientas todo-en-uno, pero al final acaba siendo un aniquilidador de memoria y CPU.
He pasado por Eclipse, Netbeans, Aptana, PHPStorm, Komodo y todos ellos acaban siendo de todo menos productivos cuando gestionan 2-3 proyectos medianamente grandes, ya que las múltiples funcionalidades como autocompletado, escaneo contínuo de las fuentes, comprobador de sintaxis, propiedades Git o SVN, etc. acaban ralentizando el IDE e incluso el sistema.
Mi solución es utilizar herramientas para cada cosa: estoy utilizando Sublime Text 2 como editor, Cornerstone para SVN, Tower para Git, Transmit para FTP, Sequel Pro para MySQL, Terminal para Bash...
Con estas combinaciones, incluso usando otros programas pero especialidados en una función, soy bastante productivo. Hacen una sola cosa, pero la hacen muy bien y de manera rápida.
vim indudablemente
Algunos compañeros opinan de que no existen buenos o malos editores de código, yo por otro lado creo que lo que le hace falta a un buen programador es simplemente una hoja de texto plano en donde escribir su arte.
El tunning que se le pueda hacer a un editor de texto está bien si agiliza la programación, sin embargo, existe una cantidad ilimitada de editores que al agregar un plugin la verga se cuelga, y es un poco fastidioso, por mi parte uso vim para progrmar en un equipo sin entorno gráfico con eso es suficiente para programar.
vim es un editor mas que suficiente, las únicas desventaja son que para programadores perezosos les será difícil aprender la cantidad de ajustes y plugins que posee este maravilloso editor; la curva de aprendizaje es muy grande y para aquellos programadores que les falte un dedo están jodidos.
mejores herramientas
me gusta mucho Sublime Text 2 como editor y me parece excelente Cornerstone para SVN, existen muchisimas para gestionar mysql
luis vidal