Main

Hottest News

Editar news

  • [eze] Una cosa es que haya control de calidad, y otra que trabajen por trabajar. POR EL AMOR DEL CIELO, activad *y usad* el corrector ortográfico del firefox, que va *por defecto* activado. Puede que tengáis que instalarle el diccionario español (ni idea de cómo va en ubuntu configurado), lo tenéis en http://addons.mozilla.org . Si sale en rojito, o es palabro técnico, o no lo tiene el diccionario (puede pasar, hay muchos adverbios con -mente que no se come bien)… Pero por lo menos miradlo!. Ahorraremos typos (erratas), acentos-fest, etc.
  • [Adri] He creado un script de bash para automatizar algunas cosas de los repos bazaar. El script te permite ejecutar un comando bazaar sobre todos los repos que tengas en un directorio. Así puedes hacer pull/merge en todos con un sólo comando y bajar todos los cambios, o ver el log conjunto… A mí me resulta útil, y si se os ocurren funcionalidades, pedidlas. Las dudas de esto, a mí. Lo he subido a http://www.hdlorean.com/autobzr.sh
  • [salva & dani] ya tenemos CSS propio y ahora los comentarios desaparecen al imprimir (ojo: no en las previews). Como no está todo actualizado, cuando veáis un bloque de comentarios incluis el siguiente codigo en vez del troncho del style. IMPORTANTE: el +++Comentario tiene que estar dentro del DIV y cuando peguéis un enter despues de un DIV, lo cierra automáticamente (el muy c*br*n) así que ATENTOS.
[[div class="comentarios" ]]
+++ Comentarios: 
[[module Comments title="" hide="true"]]
[[/div]]
  • (eze) Movidas las historias y casos de uso a version-sin-merged-detrás. Ahora son doc:casos-de-uso e historias-de-uso. Recordad usar los comentarios (K)
  • (eze) IMPORTANTE!!! Cuando queráis comentad algo, lo hacéis en la página de comentarios de cada página. Por defecto quedan ocultos a gervás, y en la barra de la izq tenemos "forum : recent posts" para ver lo que la gente va diciendo. MUUUCHO más cómodo ^ ^.
    Como nuestro tiempo es finito administrando la wiki, si en alguna página faltase u encontráseis comentarios por el código o en las líneas, añadid una sección comentarios así:
+++ Comentarios: 
[[div style="margin-left: 50px; font-size:90%; width:80%; border:solid 1px #999999; padding:5px; margin-bottom:4px;" ]]
[[module Comments title="" hide="true"]]
[[/div]]
  • [salva] Pasaos por la nueva página de módulos, miraos el snapshot-core y bienvenidos a una wiki con comentarios xP
  • (eze) Lo estamos dando lo estamos regalando!!! Mirad launchpad y entended, al fin, cómo se integran bazaar con la propuesta modelo desarrollo y con http://launchpad.net. Consultadme dudas… Pero leedlo, porfa ^^.
  • (eze) TURRON DE NAVIDAD!!! A precio de saldo!!! Por favor leedlo y entendedlo; ahí documentamos el proceso de desarrollo. Cualquier comentario es bienvenido…
  • (robs) Puede alguien averiguar como se linkan anchors desde otra página??? desde la misma si se puede pero desde otra…Spiderman help me! Ok, hay que pegar todo así: [[[nombre-pagina#ancla]]], solo [[[#ancla]]] si es dentro de la misma página, o [[[nombre-pagina#ancla | lo que aparece en el enlace]]].
  • (eze) Al fin la primera edición del Libro Gordo de Petete. Ya en tiendas.
  • (Adri) Mirad la sección ideas antes de seguir rellenando casos de uso, creo que hace falta una estandarización.
  • (eze) Pre-migración!! A la vista de que el includefest es un coñazo con solo child pages, ya que había que ir incluyendo una a una… usaremos una solución de compromiso.
  1. Todo a una sola sección, una detrás de otra (ved casos-de-uso).
  2. Poner los headings bien (lo del ++).
  3. Para edición concurrente, si los headings están bien hay una opción en la barra de abajo en +options que es "edit sections". Le das, y aparece un botoncito "edit" en cada sección (y las secciones las saca de los headings). Con eso se puede hacer edición concurrente.
  • Probablemente Beagle no esté en los labos!!

Ideas

Editar ideas

Podemos utilizar esta página como sustituto de la lista de correos. Que cada uno vaya añadiendo en la primera línea lo que tenga que decir. Si son respuestas, lo podéis poner en cursiva después de cada línea. Si ponéis vuestro nombre delante, mejor que mejor para saber quién dice qué.

A comprehensive test suite, on the other hand, lets you be more open to big landings on trunk, because you know that the tests protect the functionality that people had *before* the landing. A test suite is like a force-field, protecting the integrity of code that was known to behave in a particular way yesterday, in the face of constant change. Most of the projects I’m funding now have adopted a tests-before-landings approach, where landings are trunk are handled by a robot who refuses to commit the landing unless all tests passed. You can’t argue with the robot! The beauty of this is that your trunk is “always releasable”. That’s not *entirely* true, you always want to do a little more QA before you push bits out the door, but you have the wonderful assurance that the test suite is always passing. Always.

So, branch-friendly VCS’s and test-driven development make all the difference. Work on your feature till it’s done, then land it on the trunk during the open window. For folks who care about the release, the freeze window can be much narrower if you have great tests.

En concreto:

* If a command takes more than 1 second, show the "busy" cursor. This tells users to hold their horses and not click on anything else until the normal cursor returns.
* If a command takes more than 10 seconds, put up an explicit progress bar, preferably as a percent-done indicator (unless you truly can't predict how much work is left until the operation is done).


People don't know the workflow or the steps, they don't know the expected outcome, and they don't know the basic concepts that they'll be manipulating.

  • [Salva] Deberíais actualizar vuestros módulos porque es una forma bastante rápida de estar al tanto de los cambios.
  • [Eze] aunque ignoro si seguís leyendo el front de vez en cuando… He aquí un link para la gente del ui que os puede interesar si tenéis un ratito para leer: http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html
  • [Eze] Reunión cuanto antes (martes? como máximo!) para poner en condiciones la entrega de noviembre, que se entrega el jueves => se le envía a Gervás el miércoles como tarde. Mientras tanto, no dejéis de ver este vídeo http://youtube.com/watch?v=o3TGM0T1CvE … entenderéis por qué mola ZFS, por qué *también* resolverá nuestro proyecto cuando tire en linux, y por qué uso bsd (joder, hay que ser notas para hacer ese video! XDD).
  • [Salva] A mi me parece la opción más correcta. Entonces el nombre del proyecto queda en HD Lorean y para código, carpetas de instalación y demás usos: hdlorean ¿no?
  • [eze] nombre del proyecto. Como veo que cada uno lo escribe como le da la gana, propongo ser consistentes. Mi voto es para HD Lorean en todo lo que sea documentación, y hdlorean en todo lo que sea código (de hecho ya está así en launchpad). Ni HDLorean, ni HD-Lorean, ni HDlorean, ni HdLorean…
  • [Fede] Poll: El código, y casi que la documentación y el interfaz gráfico no deberíamos tirarlo en inglés? Fede vota . (Adri) yo tira código en inglés. Aunque los comentarios no los he tirado en inglés, sí los doxygen. Adri vota (Salva) Por mi, también lo tiraría todo en inglés. Salva vota [Eze] Yo voto yes y os jorobo el parser XD. //
  • [Eze] Otro Proyecto hermano que me he encontrado. En los comments les ponen que por qué no usan rdiff-backup… Habría que explorar qué es, pero *creo* que soluciona lo de xdelta de almacenar cambios… En slashdot hablan del tema (pero no salimos :P)
  • [salva] Ahora que he visto que se pueden hacer includes dentro de includes porqué no volvemos al modelo original con todo bien ordenadito por listas. Ahora tan solo habría que hacer un sólo include por cada item nuevo. Lo digo porque, aunque se que es un coñazo reformatear para dárselo a Gervás, no podemos olvidar que la wiki tiene que servir nuestra comunicación. //(eze) Ya, pero con casos de uso e historias es un coñazo y seguro que se olvida meterlo a doc:printable, con lo que nos toca ir detrás de la gente a añadirlo; con la edición por secciones funciona también, y además ahora empezaremos a darle bastante tute a los casos de uso porque toda funcionalidad de código hay que documentarla en caso de uso … Así en realidad es más cómodo trabajar.
  • [salva] Para los deprecated, por qué no los borrais pero diciendo que sólo los renombre a deleted:blablabla o por qué no hacemos una categoría deprecated y así mucho mejor? Así nos ahorramos nombres como casos de uso merged que no son demasiado humanos, os parece? (eze) Arreglados los casos de uso y las historias; me parece bien lo de deleted: (de hecho es el borrar por defecto, solo que default no todos podemos borrar páginas)
  • (eze) Os ruego que cuando hagáis una página que cuelga de documentación no uséis un único "+" para encabezados; empezad siempre por "++". Así reservamos el nivel 1 para donde se incluya esa página (por ejemplo printable y todo queda colocadito y precioso en la tabla de contenidos. Gracias…
  • (eze) He estado recolocando un poco todo, metiendo anchors donde faltaban, etc. He vuelto a romper la tabla de riesgos en tres separadas; si no es un sacrosanto *cognazo* editar un riesgo en las tres partes en las que se compone. Alternativamente: componer las tres tablas en una… Pero yo no me presento voluntario para *eso*, así que he seguido editando en las tres separadas. Para ahorrar follones de inclusión están incluidas tanto en riesgos como en el printable (todo sigue funcionando, en resumen). Os agradeceré que me deis el visto bueno con esto y los riesgos curremos en tablas separadas (total, son tres solamente y nunca cambian).
  • [Adri] http://hdlorean.wikidot.com/estandar-casos-de-uso <~~ ¡Leedlo!
  • [Fede] Estoy haciendo la documentacion "printable" pero es lo puto peor, hay que andar incluyendo cada página hija si quieres que salga en el sitio printable, y esto nos crea problemas. Creo que si vamos a migrar, pues migramos a algo en lo que se pueda decir [[include fulanito:ChildPages]], y si no, se acabó el crear nuevas páginas por cada caso de uso, y lo que editamos son las secciones de la misma página: casos de uso.
  • [Salva] He dedicado esta mañana a organizar cosillas y lo que me dijiste, Eze, sobre la navegación, ya está hecho. Además, he cambiado algunas listas por mapas autogenerados y creo que todo queda bastante mejor. He sacado de documentación todos los includes (pero siempre se puede volver atrás) porque me parece una redundancia. Para eso no listamos las partes. Weno, espero que os gusten los cambios. Esta es mi última contribución esta semana. Pasad una buena semanita y, por favor, avisadme de cualquier cosa importante. Un abrazo.
  • [Salva] Una cosa referente a tutos, si vais a poner codigo utilizad la forma [[code style type="lenguaje-programacion"]] porque colorea la sintaxis.
  • [Salva] Avisadme de lo comentado en la reunión por favor. Ando hasta arriba de lios pero solo por esta semana.
  • (Carlos) Ayer en clase vimos los riesgos, y Gervás nos dijo que deberíamos ir empezando a pensar en ellos. Esta tarde en la reunión habrá que dividirse para casos de uso y riesgos, no os parece?
  • (eze) Un tutorial de cómo usar rsync para snapshots.
  • (eze) Una review decente de Leopard entero, y Time Machine en particular. (Fede) Imperdible también la parte de FSEvents, que vendría a ser el inotify+beagle que hay en Leopard.
  • (eze) Empezados los tutoriales
  • [Jorge] Se había comentado la posibilidad de ofrecer un API para thirds…pero no aparece nada en las historias(y por supuesto tampoco en los casos de uso). Dejo el comentario aquí… y en la próxima docutón lo hablamos. (eze) lo que más se parece es lo del juego, convendría ampliarlo con otra nueva para buscar un correo o un log de mess. También falta el de "busco por contenido en trac^Wbeagle y me busca en la historia". //
  • [Salva] Para las listas y demás, yo no pondría toda la lista sino sólo el enlace a la misma porque si no, hay que estar actualizando en todas partes. Si os parece bien, las borro en algunos sitios.
  • (eze) Tengo una propuesta de modelo de desarrollo. Es un poco tochazo, pero os pediría que la miraseis con un poco de atención y me dijeseis si os parece razonable. He intentado ser lo más claro posible, palabrita.
  • (adri) He estado mirando y junto con Eze, creemos que es mucho mejor usar Beagle que Tracker. Tracker no dispone de un API de alto nivel para desarrollo de aplicaciones externas y Beagle sí. La pega es que Beagle está en C#, pero no os creáis que el C de Tracker es una maravilla, he ojeado el código y los ficheros de 1500 lineas tienen una media de 15 comentarios, así que… Además Beagle es más maduro y tiene más documentación. Además, mirando el código de Beagle, tiene muchos más comentarios y está orientado a objetos como dios manda. http://beagle-project.org/Development y http://beagle-project.org/Architecture_Overview
  • No podriamos usar el wiki como forma de entregarle a Gervas las cosas?Se le podría invitar y asi podría ver cuando quisiera las cosas que vamos haciendo, incluso podría poner comentarios de esto me gusta esto o esto no (si el lo cree oportuno claro)Que os parece si se lo comentamos?nos va a decir que tararí EMHO
  • Y cito de una review de nuestra "inspiración": //[…] leads to a remarkable change in mindset: I just installed a new version of a program I’m beta testing, and realized that if it didn’t work, I could quickly roll back to the previous version via Time Machine. Claro, eso rula solo en ese-OS porque allí los programas instalados son carpetas sin +… Pero vaya canteo más chulo.
  • Hector me ha facilitado un página que seguro que nos viene muy bien para facilitarnos el trabajo. Me ha dicho que entregaron 40 casos de uso.
  • He cambiado los casos de uso y se han reordenado. Ver nota en el cuerpo del wiki o comentarios del fuente de casos de uso… así no hay que actualizar las listas a mano, pero se ordenan solos por orden alfabético. qué-era-cada-uno sigue estando en la historia (lo bueno de la wiki es que *no* se pierden datos al editar).
  • He abierto página en launchpad, pero como no sabía la licencia la he dejado pendiente, y ello ha bloqueado la creación a falta de que canonical apruebe una licencia de "aún no está decidido, pero como mínimo GPL". Veremos si logro recuperarlo. Convendría decidir la licencia (aunque si vamos a usar código GPL está decidida de antemano: GPLv2).
  • Por si nos sirve: HOWTO_Backup de gentoo
  • Idea de uso: según me comentaban hoy sobre TimeMachine, una feature gorda y no-fea es que tú haces una búsqueda con spotlight, y si no te aparece ningún archivo tienes un botón para buscar en la historia del finder. Le das, y van pasando las vistas de las carpetas hacia atrás hasta que aparece la que tiene el ->contenido<- que has buscado (puede ser una frase dentro de un archivo, vaya). Para ESO queremos tocar en Tracker. Sin meternos en metáforas visuales tan tensas, podemos hacer lo de ir pasando hacia atrás la barra de tiempo, y quizá un osd tipo amarok (ventana o mensaje sobre todas las demás) con un reloj y las agujas moviéndose cuando toques la barra del tiempo (con el reloj de Cairo p.e.?). Usabilidad!!!
  • ¿Escribimos tutoriales para nosotros mismos en el wiki?
  • Voluntarios para volcar los correos que han circulado ya? gracias robs

*[Ender] Se podría hacer que se instalara directamente al conectar un disco duro con el paquete incluido? Sería genial llevar el disco externo al labo y que se instalase ahí de pro

TODO


Editar TODO (por hacer)

Prioridad ALTA

  1. Establecer calendarios de quedadas. Ver cuándo quedamos y eso para ponernos de acuerdo… Aunque falte siempre alguien, mientras no sea siempre el mismo *ejem ;)* no pasa nada.
  2. Solucionar el tema de la wiki (voluntarios para scripting wikidot->mediawiki? Aunque solo sea para backups por si hay que hacer docufest!).

Prioridad MEDIA

  1. Establecer calendarios de trabajo (Gervás lo "recomienda"). Para bien o para mal no somos 30 así que no puede haber "solo documentadores" o "solo integradores", nos tocará mojarnos un poco a todos.
  2. Revisión de calidad de la documentación: lectura de todo y clarificación donde sea necesario (p.e. riesgos). También incluiría los items de prioridad baja como poner los anchors o conectar historias con casos. ; conectar historias con casos mediante esos anchors también, etc. Es prioridad media porque es lo que entregamos a Gervás…

Prioridad BAJA

  1. Poner anchors en las páginas que tengan muchas secciones referenciables independientemente (como casos de uso, que ya está hecho)
  2. Pensar más casos de uso (irán surgiendo, creo)


Miscelánea

¡No dejéis de sugerir / hacer cambios al wiki!

IMPORTANTE:

  • Cuando creemos subpáginas de algo, si sois tan amables cuando las guardéis haced _una_ cosita más: en las opciones de la página (abajo a la dcha, donde está lo de "edit" haced page-options -> parent, y meted la página "padre".
  • Si ponéis en la descripción de los cambios lo que habéis metido (aunque sean tres palabras) luego es más cómodo ver la historia de cambios de la página… Pero vaya, es más útil para cambios "grandes".

Glosario-no-serio-aun
Correos
Tutoriales

He aquí nuestro proyecto de "inspiración": http://www.apple.com/es/macosx/features/timemachine.html

Para el que quiera, una página que he movido (el antiguo start): Manual de cómo se usa este percal (venía en el inicio)

Sintaxis wiki

Calendario (avisad a quien no le funcione, que habrá que añadiros uno a uno para que lo veáis).
podemos usarlo p.e. para cuando Gervás ponga fechas de entrega de alguna cosa

Cambios recientes en el wiki

recomiendo New pages y source (no all), 10 por página. Lamentablemente no me deja ponerlo así por defecto
al que quiera un feed RSS de la página y sus cambios, en [[admin:manage]] - Notifications lo tiene.

Revision types:  ALL
 new pages
 source changes
 title changes
 page name changes
 tags changes
 metadata changes
 files changes
From categories:
Revisions per page:
page 1123...next »
apuntes: Cuestiones Teóricas S 15 Jun 2008 17:36 (rev. 51) jotum
otro perrito piloto
apuntes: Cuestiones Teóricas S 15 Jun 2008 17:32 (rev. 50) jotum
¬¬
apuntes: Cuestiones Teóricas S 15 Jun 2008 17:31 (rev. 49) jotum
comments
apuntes: Cuestiones Teóricas S 15 Jun 2008 14:07 (rev. 48) Salvador
apuntes: Cuestiones Teóricas S 15 Jun 2008 14:02 (rev. 47) Salvador
apuntes: Cuestiones Teóricas S 15 Jun 2008 14:01 (rev. 46) Salvador
apuntes: Cuestiones Teóricas S 15 Jun 2008 13:59 (rev. 45) Salvador
apuntes: Cuestiones Teóricas S 15 Jun 2008 13:54 (rev. 44) Salvador
apuntes: Cuestiones Teóricas S 15 Jun 2008 13:51 (rev. 43) Salvador
apuntes: Cuestiones Teóricas S 15 Jun 2008 13:50 (rev. 42) Salvador
apuntes: Cuestiones Teóricas F 15 Jun 2008 13:47 (rev. 41) Salvador
File "organizacion octubre-noviembre.png" renamed to "organizacion-octubre-nov.png".
apuntes: Cuestiones Teóricas F 15 Jun 2008 13:47 (rev. 40) Salvador
File "organizacion mayo.png" renamed to "organizacion-mayo.png".
apuntes: Cuestiones Teóricas F 15 Jun 2008 13:46 (rev. 39) Salvador
File "organizacion marzo.png" renamed to "organizacion-marzo.png".
apuntes: Cuestiones Teóricas F 15 Jun 2008 13:46 (rev. 38) Salvador
File "organizacion integracion.png" renamed to "organizacion-integracion.png".
apuntes: Cuestiones Teóricas F 15 Jun 2008 13:45 (rev. 37) Salvador
File "organizacion enero-febrero.png" renamed to "organizacion-enero-febrero.png".
apuntes: Cuestiones Teóricas F 15 Jun 2008 13:45 (rev. 36) Salvador
File "organizacion diciembre.png" renamed to "organizacion-diciembre.png".
apuntes: Cuestiones Teóricas F 15 Jun 2008 13:45 (rev. 35) Salvador
File "organizacion abril.png" renamed to "organizacion-abril.png".
apuntes: Cuestiones Teóricas S 15 Jun 2008 13:44 (rev. 34) Salvador
apuntes: Cuestiones Teóricas S 15 Jun 2008 13:41 (rev. 33) Salvador
apuntes: Cuestiones Teóricas S 15 Jun 2008 13:40 (rev. 32) Salvador
page 1123...next »
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License