IDE para desarrollo web en cliente

Posted: noviembre 13th, 2013 | Author: | Filed under: Sin categoría | Tags: , , , | 2 Comments »

Estoy buscando un IDE (o editor de código) para desarrollo web centrado en el cliente (JavaScript, HTML y CSS). Tras duckduckgodear un poco ya tengo una lista de los entornos que voy a me gustaría probar, no necesariamente en este orden:

  • Webstorm. De jetbrains. No es libre ni gratuito pero sale muy bien parado en las comparativas.
  • Sublime Text. Tampoco libre ni gratuito, pero al igual que el anterior muy bien valorado.
  • Eclipse. Con plugins para desarrollo web o la versión pre-empaquetada.
  • Emacs. Que nunca decepciona cuando inviertes suficiente tiempo en él.
  • Aptana. Lo he estado usando para python y va aceptable.
  • NetBeans. A pesar de que nunca lo he usado tiene críticas entusiastas.
  • Brackets. Un editor libre creado por Adobe con muy buena pinta. (actualizado 26/Junio/2014)
  • Atom. Un editor libre creado por GitHub, basado en nodejs. También con muy buena pinta, pero por ahora sin binarios para Linux. (actualizado 26/Junio/2014)
  • Mozilla Web IDE. Todavía parece bastante verde, y no tengo claro que sea lo que busco, pero parece que Mozilla ha intentando montar un IDE directamente en Firefox. El target principal de aplicaciones es su sistema para moviles FirefoxOS pero debería valer para la web.(actualizado 26/Junio/2014)

Por ahora voy a empezar con Aptana e iré contando. ¿Vosotros que usais?

 


Como funciona git reset y porqué no usar git-flow

Posted: octubre 12th, 2013 | Author: | Filed under: Sin categoría | Tags: , , | No Comments »

Scott Chacon demistifica en el siguiente vídeo git reset, que es probablemente uno de los comandos más complejos de entender de git.

En su blog y en este gist hay alguna explicación adicional.

Hacia el final de la charla le preguntan que opina de git flow, lo que le permite explicar porque no le gusta y recomienda leer el workflow que siguen en github. Merece la pena leerlo.


Tres podcast de JavaHispano sobre legislación

Posted: septiembre 14th, 2013 | Author: | Filed under: Sin categoría | Tags: , , , , | No Comments »

Si eres desarrollador hay un par de aspectos de la legislación de las que deberías tener ciertas nociones. Propiedad intelectual, LOPD, LSSICE, Licencias de Software, Software Libre,… son conceptos que si bien seguramente no tienes porque dominar, al menos te deberían sonar. Ultimamente he oído tres podcasts de JavaHispano donde tocan alguno de estos aspectos que no está de más escuchar:

  • Propiedad intelectual del software. Que responde a preguntas como ¿Qué derechos tiene un programador asalariado sobre el software que escribe? con respuestas como basicamente ninguna a no ser que pacte previamente.
  • Ley de Protección de Datos Personales (LOPD): Desde que es la ley hasta que debería saber un desarrollador para que sus programas estén adaptados a la ley. O sentencias y explicaciones como que Internet no es considerado por la ley una fuente accesible al público y por tanto, a pesar de que alguien ponga una dirección de correo en una web un tercero no tiene legitimidad para emplear ese correo en una campaña de publicidad.
  • Introducción y reflexiones sobre Software libre. ¿Qué es el software libre?. Diferencias entre la OSI y la FSF. Tipos de licencias, … El podcast es bastante opinativo como ellos mismos reconocen y no estoy de acuerdo con algunas de las cosas que dicen. Pero si no tienes mucha idea es una buena introducción.

Y tu. Conoces otras fuentes básicas de legislación, licencias, etc. que todo desarrollador de software debería leer.


Libro: Beggining Ruby: From novice to proffesional de Peter Cooper

Posted: junio 17th, 2013 | Author: | Filed under: Sin categoría | Tags: , , , | No Comments »


He terminado estos días de leer el libro de Peter Cooper, Beginning Ruby: From Novice to Professional (Expert’s Voice in Open Source)
, es una segunda edición del 2009 publicada por Apress. El libro se puede comprar en Amazon o desde la página del autor.

Tiene 658 páginas, pero entre espacios en blanco, índice de referencias, índice de contenidos y secciones prescindibles para quien ya sepa algo de programación se queda en bastantes menos. Además, es fácil de leer.

Si ruby no es el primer lenguaje que aprender mi recomendación es empezar por el apéndice A. De un vistazo rápido tienes una gran parte de la sintaxis básica del lenguaje, que ya te permite empezar a hacer alguna prueba.

A partir de ahí lo más fácil es leer el libro en orden, es fácil identificar aquellas secciones prescindibles, como la de instalar ruby en distintos sistemas operativos del capítulo 1, la introducción a ppo del 2, los operadores básicos del 3,… Sobre todo en los primeros capítulos hay cosas básicas que pueden saltarse, y a partir de la mitad del libro algunas cosas muy específicas que se pueden leer en diagonal, simplemente saber que existen y volver a ellas si en algún momento te hace falta.

Me gusta del libro que empieza despacio, siendo asequible para alguien con poca experiencia previa en programación pero avanza rápido y gradual hacia temas más avanzados cubriendo un montón de aspectos del lenguaje que pueden hacer falta. Incluye comentarios sobre estilo del código, tests automáticos (esta parte podía estar un poquito mejor) y desarrollo web, incluido un capítulo sobre rails que te da para dar los primeros pasos en ese framework.

También me gusta que hay bastantes pequeños snippets de código autoejecutables y dos capítulos enteros de aplicaciones un poco más completas, el capítulo 12 en el que desarrollas un bot con el que dialogar es una gozada.

Lo que menos me gusta es que a pesar de que cubre ruby 1.9, se nota que está escrito para la 1.8 y luego actualizado.
En definitiva un buen primer libro para quien ya sepa programar y quiera aprender como ruby puede solucionar alguna de sus necesidades


Libros de ruby para principiantes

Posted: mayo 18th, 2013 | Author: | Filed under: Sin categoría | Tags: , , , | No Comments »

Tras mi rápida visita a Ruby a través del Mr Neighborly’s humble little ruby book he estado buscando otros libros para principiantes que me dieran una visión más amplia del lenguaje. Recopilo algunos de los libros que se suelen recomendar con mis propias impresiones sobre lo que he leído de ellos. No he leído ninguna así que puedo equivocarme en las apreciaciones, si no estás de acuerdo deja un comentario.

Beginning Ruby: From Novice to Professional, Second Edition

.

Está reconocido como uno de los mejores libros para novatos, avanza desde las cosas más sencillas hasta cubrir hasta iniciarte en temás más complejos como ruby on rails o testing. Combina bastantes ejemplos pequeños de código con algunos más grandes.

The Ruby Programming Language

.

Considerado más bien de nivel intermedio, busca transmitir las interioridades del lenguaje, aunque se suele considerar como uno de los mejores libros para aprender. Uno de los autores del libro es Yukihiro Matsumoto el creador de Ruby.

  • Versión de Ruby empleada: 1.8 y 1.9
  • Páginas: 448
  • Año de la última edición: 2008

Programming Ruby: The Pragmatic Programmer’s Guide


Fue el primer libro en inglés publicado sobre Ruby y es probablemente el libro más referenciado. Pero se ve que también tiene unos cuantos detractores. Hay una cuarta edición del libro publicado por ahora como borrador que cubre la versión 1.9 y la 2.0. Para ruby 1.8 se puede comprar la segunda edición.

La primera edición del libro sobre ruby 1.6, de 2001 se puede consultar online en ruby-doc y en rubycentral

  • Versión de Ruby empleada:1.9 y 2.0
  • Páginas: 1000
  • Año de la última edición: 2013 (en borrador)

The Well-Grounded Rubyist


Entre nivel inicial e intermedio, parece pensado pensado para quien tiene cierta idea y quiere conocer las particularidades del lenguaje con más profundidad. Muestra un montón de pros y contras del lenguaje y sus idioms pero no llega a desarrollar un proyecto de código concreto. Es otro de los libros más mencionados.

  • Versión de Ruby empleada: 1.9
  • Páginas: 487
  • Año de la última edición: 2009


Conclusiones

Lo que yo estoy buscando es un libro fácil de leer y que tenga algún ejemplo realista de código y no pequeños snippets, por ello me he decidido darle una oportunidad al Beggining Ruby. Trataré de contar que tal está cuando lo acabé.

Referencias

Otros libros

Sobre Ruby también hay bastantes libros gratuítos:

y si lo que buscas es algún libro más avanzado, estos son los que suelen recomendar:


Libro: Mr Neighborly’s humble little ruby book

Posted: mayo 1st, 2013 | Author: | Filed under: Sin categoría | Tags: , , , | 1 Comment »

Estos días he estado leyendo el libro sobre ruby Mr Neighborly’s humble little ruby book. Aprovecho para hacer una pequeña reseña.

La razón de escoger este, es que es la primera referencia que aparece en la guía de inicio rápido de ruby on rails, y no quería invertir tiempo en buscar otra referencia. El libro se puede consultar de manera gratuita en html y pdf, aunque tiene una sección de donaciones. Está escrito en 2006 y usa ruby 1.8.5 con lo que algunas cosas pueden estar un poco desactualizadas. El pdf tiene 147 páginas pero de texto efectivo andará por las 130. Si te pasa como a mi, que algunos capítulos no te interesan mucho, se puede leer en unas 6 u 8 horas. El libro tiene un estilo desenfadado, con (malos) guiños cómicos al lector de tanto en tanto.

Entra de forma bastante rápida y práctica en temas de interés, sin perder demasiado tiempo en introducciones o aspectos muy básicos de oop o programación, habituales en este tipo de tutoriales. Desde luego es insuficiente para alguien sin experiencia previa, pero si conoces algún otro lenguaje dinámico como python, enseguida te ayuda a ver las mayores diferencias. De hecho a menudo hace comparaciones con otros lenguajes.

En el capítulo 4 hay una sección entera dedicada a la API de Windows, que para mi no tenía mayor interés, y otra sobre threads, que por ahora me llega con ojear.

El capítulo 5 está dedicado a lo que podríamos llamar networking (sockets, http, ftp, web services) y algo de base de datos. Si lo que buscas es conocimientos básicos de ruby para luego aprender rails, se puede saltar. Es mejor coger estos conceptos directamente a través de rails.

En el último capítulo habla un poco de testing lo cual está muy bien, porque tampoco es algo muy habitual.

Los dos anexos tampoco son de especial interés, y algunos de los enlaces que aparecen en ellos no funcionan.

En definitiva:

  • Se lee relativamente rápido
  • Si vienes de python te permite entender las mayores diferencias del lenguaje sin mucho problema
  • Seguramente hay cosas mejores por ahí

Tutorial básico de django south

Posted: octubre 24th, 2012 | Author: | Filed under: Sin categoría | Tags: , , , , | 15 Comments »

South es una app de django que permite modificar la estructura de la base de datos de una aplicación django cuando cambiamos el modelo (models.py).

El comando syncdb sólo crea nuevas tablas, pero no modifica tablas existentes, así que si en el modelo de una aplicación renombramos un campo de una tabla existente syncdb no realizará ese cambio en la base de datos. A este tipo de cambios en la base de datos se les denomina «migración del esquema» y es de lo que se encarga South.

Instalación

  1. pip install south
  2. Agregar «south» a INSTALLED_APPS
  3. Ejecutar syncdb antes de crear nuestros propios modelos. Está será la última (y única) vez, que necesitamos ejecutar este comando
    manage.py syncdb

Usar south en un una app nueva

  1.  Crear la aplicación, y empezar a rellenar el models.py
  2. Crear el script de migración inicial
    python manage.py schemamigration app_name --initial
  3. Hacer los cambios en la bbdd
    python manage.py migrate app_name

Usar south en una app ya creada

python manage.py convert_to_south app_name

En el caso de que haya otros desarrolladores en el equipo y cada cual esté usando su propia instancia de la base de datos, el resto de desarrolladores deberá migrar la primera versión en modo fake,
python manage.py migrate app_name 0001 --fake

el resto normal, así:
python manage.py migrate app_name

De lo contrario no podrán migrar su versión de la base de datos.

Migración de modelos

  1. Modificamos el models.py de nuestra aplicación
  2. Crear un nuevo script de migración
    python manage.py schemamigration app_name --auto
  3. Aplicar la migración a la bbdd
    python manage.py migrate app_name

Como funciona

Se puede decir que South funciona en varios niveles de abstracción disintos.

  • Añade una tabla en la base de datos que mantiene el estado actual de la base de datos. Es decir, guarda que migraciones se han aplicado.
  • Crea un directorio en la applicación, donde guarda para cada migración un fichero (script) con la información necesaria para realizarla
  • Añade varios comandos al manage.py

Los ficheros de migración generados en deben subirse al repositorio para que el resto de los desarrolladores pueda también realizar la migración.

Referencias

Nota: Editado el 7/Marzo/2015 para añadir el comentario de Mauricio.


Emacs y análisis estático de código en python

Posted: julio 22nd, 2012 | Author: | Filed under: Sin categoría | Tags: , , , | 1 Comment »

Gracias a Cartolab he podido seguir dándole una vuelta al análisis de código estático en python. La idea era reducir los incómodos errores que se producen porque te equivocas al escribir el nombre de una variable o cosas parecidas de las que no te das cuenta has que ejecutas el código. Tratar de detectar estos errores de la forma en que lo veíamos en el artículo anterior sigue sin ser demasiado productivo y aquí es donde entra en juego la extensión para emacs Flymake.

Lo que hace Flymake es «pedirle» a emacs que esté continuamente realizando ciertos análisis sobre el código o tratando de compilarlo y/o ejecutarlo. En realidad flymake es un plugin bastante genérico que funciona del siguiente modo:

  1. Si al abrir un nuevo buffer está marcado como «a chequear», flymake programa un temporizador para el buffer. La forma de marcar buffers suele ser en función de la extensión del archivo que abramos
  2. Crea una copia temporal de los buffers abiertos cada cierto tiempo
  3. Ejecuta un programa externo sobre la copia del buffer. Este programa puede ser gcc, make u otra cosa como una herramienta de análisis estático de código.
  4. Parsea la salida que produce el programa externo y da una salida visual en el buffer actual para representar los posibles errores.

Activar flymake

Activar flymake junto a alguna de las herramientas que veíamos en el post anterior es bastante fácil. Flymake viene instalado por defecto, así que sólo tenemos que tener en el path los ejecutables a las herramientas de análisis, y añadir a nuestro .emacs las instrucciones para que se activen con los ficheros python.

flymake con pyflakes:

(when (load "flymake" t)
(defun flymake-pyflakes-init ()
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-inplace))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list "pyflakes" (list local-file))))
(add-to-list 'flymake-allowed-file-name-masks'("\\.py\\'" flymake-pyflakes-init)))

flymake con pylint (el comando epylint es un modo especial de pylint para trabajar con emacs)

(when (load "flymake" t)
(defun flymake-pylint-init ()
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-inplace))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list "epylint" (list local-file))))
(add-to-list 'flymake-allowed-file-name-masks'("\\.py\\'" flymake-pylint-init)))

flymake con pep8
(when (load "flymake" t)
(defun flymake-pylint-init ()
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-inplace))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list "pep8.py" (list "--repeat" local-file))))
(add-to-list 'flymake-allowed-file-name-masks'("\\.py\\'" flymake-pylint-init)))

Por otro lado también podriamos configurar flymake para hacer que se pasarán las tres herramientas de forma automática pero yo lo veo innecesario dado que la información que proporcionan es en muchos casos redudante y estamos disminuyendo el rendimiento del ordenador.

Además de indicarle a flymake con que herramienta queremos trabajar, tenemos que activarlo para los buffers que nos interesen. Esto podemos hacerlo de varios modos:

  • Manual. Activando el modo menor de flymake. M-x flymake-mode
  • Que active el modo menor flymake cuando estemos en el modo python. Añadiendo al .emacs
    (add-hook 'python-mode-hook 'flymake-mode)
  • O que active el modo flymake en base a las extensiones de fichero que le hemos pasado anteriorme (flymake-allowed-file-name-masks)
    (add-hook 'find-file-hook 'flymake-find-file-hook)

Configurar flymake

Por defecto flymake ilumina (highlight) la línea de código donde se produce el error, empleando un color u otro en función de si es un error o un warning. Al dejar el ratón encima de la línea con el error (hover) nos muestra la descripción del error.

Para cambiar los colores que se emplean por defecto podemos emplear algo parecido a esto:

'(flymake-errline ((((class color)) (:background "LightPink" :foreground "black"))))
'(flymake-warnline ((((class color)) (:background "LightBlue2" :foreground "black"))))

Para que subraye en lugar de hacer highlight de la línea con el error:

'(flymake-errline ((((class color)) (:underline "red"))))
'(flymake-warnline ((((class color)) (:underline "yellow")))))

Para hacer que el fringe derecho se muestre un indicador de en que líneas hay errores podemos usar rfringe. Aunque yo no he sido capaz de hacerlo funcionar.

Mostrar la descripción del error en el minibuffer. Esto es imprescindible cuando se trabaja en modo -nw.

(defun my-flymake-show-help ()
(when (get-char-property (point) 'flymake-overlay)
(let ((help (get-char-property (point) 'help-echo)))
(if help (message "%s" help)))))
(add-hook 'post-command-hook 'my-flymake-show-help)

Aunque el código anterior a mi me funciona, para mostrar el error en el minibuffer se suele emplear el plugin flymake-cursor.

Moverse a través de los errores. Podemos emplear los comandos M-x flymake-goto-prev-error para ir al error anterior, o M-x flymake-goto-next-error para ir al siguiente. También podemos vincularlos a determinadas teclas:

(global-set-key [TECLA] 'flymake-goto-prev-error)
(global-set-key [TECLA] 'flymake-goto-next-error)

Links relacionados


Herramientas de análisis de código estático en Python

Posted: abril 3rd, 2012 | Author: | Filed under: Sin categoría | Tags: , , , | 2 Comments »

Programar es fácil, y puede hacerse con el bloc de notas. Escribir buen código es bastante más complicado, por ello existen un montón de herramientas que pueden ayudarnos. Un tipo de herramientas que he empezado a usar (en python) ultimamente son las de análisis estático de código. Estas herramientas examinan tu código (sin ejecutarlo) en busca de ciertos patrones, alertando de «code smells», incroguencias de estilo, posibles bugs, código repetido e incluso dando consejos sobre rendimiento o encapsulamiento en algunos casos.

En python tenemos disponibles distintos analizadores de código, y es habitual ver preguntas sobre cual es mejor. Las cuatro herramientas de este tipo para python están actualizadas a las últimas versiones en los repositorios de ubuntu. Para instalarlas:

sudo apt-get install pyflakes pep8 pychecker pylint

Pyflakes

Pyflakes parece la más sencilla de las cuatro herramientas que he usado. Hace pocas comprobaciones del tipo, imports no usados, variables asignadas y no empleadas, …
No chequea el estilo, ni advierte sobre posibles bugs, aunque dicen que es de las más rápidas, por lo que es la que la gente suele usar como «chequeador de código automático» en IDEs como PyDev o emacs.

pep8

pep8 valida el estilo de nuestro código (de forma bastante rigurosa) contra el estándar de estilo PEP8 de Python. Puede ayudar a detectar «code smells», pero no chequea «errores». Comprueba cosas como que las líneas no tengan más de 80 caracteres, los nombres de variables tengan un determinado formato, …

Para chequear un fichero llega con hacer:
pep8 nombre_de_ficheros.py

Aunque habitualmente se lanza con más opciones para obtener más información:
pep8 --show-source --show-pep8 nombre_de_ficheros.py

Cuando lo lanzamos con –show-pep8 proporciona bastante información sobre la regla de estilo que estamos rompiendo por lo que resulta útil para ir interiorizándolas.

Pychecker

Pychecker es la más antigua pero ahora está algo parado. La última versión 0.8.19 es de enero de 2011 y la anterior del 2008. PyChecker si que es bastante potente en cuanto a la detección de posibles bugs o errores como el de usar una variable antes de asignales un valor, llamar a un método que no existe, … En general detecta bastantes de esos errores que se cometen en python (cuando no se usa un IDE que ya detecte estas cosas)
Parámetros interesantes.
–blacklist=unittest Este módulo de python saca algún error con pychecker, así que para evitar ruido le decimos que no lo chequee.

Pychecker tiene, imho, un problema gordo, y es que ejecuta el código para chequearlo, no es realmente una herramienta de análisis estático, por lo que su uso es más bien desaconsejable.

Pylint

Pylint es una especie de mezcla entre pep8 y pychecker puesto que hace análisis tanto del estilo del código como de posibles bugs. Tiene un montón de características, es extensible mediante plugins, …

El informe que proporciona sobre el código es bastante extenso, clasifica los errores por su gravedad, … Como tiene muchas opciones es conveniente echarle un ojo al tutorial y al manual aunque no hace falta para ver su potencial.

Los parámetros más interesantes de pyling son:

  • –reports=n Para que sólo nos saque los posibles errores y no imprima las estadísticas e informes. Puede ser útil ver el informe de vez en cuando, pero si vamos a pasar el chequeo muchas veces sólo mete ruido.
  • –include-ids=y Por defecto no nos muestra el código de error completo. Con esto hacemos que nos lo muestre para poder obtener más información sobre él si no lo entendemos (Esto lo haríamos con pyling –help-msg=ERROR_CODE)
  • –disable=C0111 Esto hace que no se chequeen, los errores C0111, que indican que todos los métodos deberían tener un docstring. Me gusta eliminarlos porque soy de los que piensan que «los comentarios apestan»

Para que la línea de comandos no se vuelva muy complicada estás opciones pueden indicarse en un fichero de configuración para que sean usadas por defecto

Como y cuando usarlas

Lo que me gusta de estas cuatro herramientas es que no hay excusa para no usarlas. Son realmente sencillas, rápidas, y ayudan a hacer un código más legible y mantenible.

Por ahora, para acostumbrarme a ellas, lo que hago es al inicio de cada sesión de trabajo paso las cuatro herramientas en el siguiente orden:

  1. pep8 –show-source –show-pep8 *.py
  2. pylint –reports=n –include-ids=y –disable=C0111 *.py
  3. pychecker –blacklist=unittest *.py
  4. pyflakes *.py

Lo hago así porque me gusta la información sobre el estilo que proporciona pep8, y tras solucionar los errores de pylint ni pychecker ni pyflakes me están proporcionando ayuda adicional así que es probable que pronto deje de usarlos. De hecho cuando me acostumbre a la guía de estilo de pep8 es probable que sólo use pylint.

Como el proyecto en el que la estoy probando apenas son 6 o 7 clases de alrededor de 200 líneas, está forma de trabajar me resulta cómoda y me permite aprender a usarlas, pero está claro que en otros contextos puede no ser lo más adecuado.

En el próximo artículo de esta serie hablaremos sobre como integrar estas herramientas en emacs, al estilo de las sugerencias de eclipse u otros IDE, y otras aproximaciones un poco más sofisticadas de como integrarlas en nuestro flujo de trabajo.

¡Prueba y cuéntame!

Actualización 20/Julio: He añadido algún enlace y desaconsejado el uso de pychecker por las razones que ya están incluídas en el propio artículo.


Trabaja upstream y facilita que los demás también lo hagan

Posted: octubre 18th, 2011 | Author: | Filed under: General | Tags: , | 2 Comments »

No os perdáis los artículos enlazados por Andrés sobre los costes de no trabajar upstream. En resumen:

La mayoría de desarrollos basados en software libre se mantienen en «local». Para satisfacer las necesidades de un cliente puede llegar un momento en que sea necesario parches una aplicación. Si estos parches no son integrados en la rama principal de un proyecto en la mayoría de las ocasiones nos veremos en la necesidad de actualizar nuestro código con el del repositorio principal. Bien porque hayan corregido errores que nuestro cliente reporta, porque queramos mantener nuestro código actualizado …

Cada vez que actualicemos nuestro código tendremos que comprobar que nuestros parches siguen correctamente integrados, independientemente del tamaño del proyecto esto acaba volviéndose un verdadero quebradero de cabeza. Tendremos que sacar nuestros propios ejecutables de la aplicación …
Si nuestros parches se encuentran upstream son otros los que se encargan de todo este trabajo.

Trabajar upstream tampoco es gratis. Es probable que otros desarrolladores hagan comentarios a tu código y pidan otra aproximación, el mantenedor exigirá un formato de código determinado etc … Además la realidad es que los mantenedores serán menos propensos a incluir tus cambios cuanta menos participación tengas en el proyecto.

Se debe por tanto trabajar upstream. En general si. Si tu código difiere mucho es importante hacerlo porque te ahorrará horas de mantenimiento que compensarán el integrar tus parches.
Si tus parches son pequeños a veces lleva más tiempo integrarlos que manterlos en local. Pero subirlos incrementará tu reputación en el proyecto de modo que cuando necesites integrar porciones más grandes de código o incluso ayuda para desarrollar alguna característica el resto de la comunidad estará predispuesto a ayudarte.

Integrar código en upstream es también una forma de decirle a tus (posibles) clientes, ey, yo puedo hacer eso que pedís y mantenerlo.