|
Página 1 de 2
|
Recolector: Organiza Tus Códigos Fuentes
| Autor |
Mensaje |
 jsbsan 
Analista Programador
Registrado: Septiembre 2009
Mensajes: 4175
Edad: 51 Ubicación:  dos hermanas, sevilla
|
 Recolector: Organiza Tus Códigos Fuentes
Recolector, es un programa para organizar los códigos fuentes. Gestiona mediante una base de datos SQLite, información tanto el código fuente como información del autor, versión, descripcion, nombre del articulo, url, y tags o etiquetas, que nos van a ayudar a buscarlos.
http://jsbsan.blogspot.com/2011/10/...es-codigos.html
Espero que os resulte util.
Saludos.
|
#1 Domingo, 09 Octobre 2011, 21:39 |
|
 |
Shell
Analista Programador
Registrado: Marzo 2010
Mensajes: 5278
Edad: 53 Ubicación: Al otro lado de la pantalla
|
Re: Recolector: Organiza Tus Códigos Fuentes
Te ha quedado muy bien.
Tengo que ver el control editor, que no lo conocía.A simple vista me creía que era un textarea.
Pero antes tengo que terminar de acabar tu programa del Listín, ando por la parte de archivos recientes.
Me pasare por la web y veré las mejoras.
Te decantaste por gb.qt.
¿ Tuviste algún problema con algún control que te lo pedía ? Editor supongo.
Veo que pudiste crear las relaciones con MySQL Workbench.Es algo que tengo pendiente de aprender con SQLite3.
Saludos.
=================== Gambas Básico
"No es un bug, es una característica no documentada"
|
#2 Lunes, 10 Octobre 2011, 09:29 |
|
|
jsbsan
Analista Programador
Registrado: Septiembre 2009
Mensajes: 4175
Edad: 51 Ubicación: dos hermanas, sevilla
|
Re: Recolector: Organiza Tus Códigos Fuentes
Hola Shell:
Citar: Te decantaste por gb.qt.
¿ Tuviste algún problema con algún control que te lo pedía ? Editor supongo.
Si, para que aparezca el control editor en la ventana de controles, necesitaba tener activada el gb.qt y gb.qt.ext
Citar: Veo que pudiste crear las relaciones con MySQL Workbench
No, ese programa solo lo use para dibujar la base de datos con sus tablas y relaciones. Para hacer el diagrama podia haber usado Dia, o hacerlo a mano (que es como realmente lo hice), pero quedaba mejor presentado hecho con el programa. 
Para crear la base de datos, y las tablas, use la herramiente que viene incluido en gambas el adminitrador de bases de datos.
Voy a subir un video para que veais como se usa el programa.
Saludos
Nota:
Si veis algún bugs, o alguna mejora me lo comentáis para añadirsela.
***************** ULTIMA HORA **************************
10/10/2011: Mientras realizaba el video, encontré un problema en la edición, ya lo he resuelto y podies descargaros la version v.0.0.3 en mi blog.
última edición por jsbsan el Lunes, 10 Octobre 2011, 20:19; editado 1 vez |
#3 Lunes, 10 Octobre 2011, 18:28 |
|
|
Shell
Analista Programador
Registrado: Marzo 2010
Mensajes: 5278
Edad: 53 Ubicación: Al otro lado de la pantalla
|
Re: Recolector: Organiza Tus Códigos Fuentes
Hola Julio.
Después de ver el vídeo.
Añades tres registros sobre el tema de los acentos y eñes.
El que no pertenece a Pablo y a Soplo.A lo mejor sobra. Entonces, ¿ como borrarlo ?.
Ya tienes otra opción que añadir al programa.El poder borrar un registro.
Saludos.
=================== Gambas Básico
"No es un bug, es una característica no documentada"
|
#4 Jueves, 13 Octobre 2011, 09:06 |
|
|
jsbsan
Analista Programador
Registrado: Septiembre 2009
Mensajes: 4175
Edad: 51 Ubicación: dos hermanas, sevilla
|
Re: Recolector: Organiza Tus Códigos Fuentes
Si se puede borrar un registro, (hay un boton para ello, pero creo que no lo comente en el video  ).
Lo que no existe la posibilidad de borrar un tag o etiqueta que ya no este en uso...
Me lo apunto para añadirlo...
¿alguna cosillas mas que veais que falta?...estoy apunto de terminar una nueva version con alguna mejoras... 
|
#5 Jueves, 13 Octobre 2011, 17:39 |
|
|
codificador
Analista Programador
Registrado: Junio 2010
Mensajes: 420
Edad: 114 Ubicación: 
|
Re: Recolector: Organiza Tus Códigos Fuentes
creo que una versión web seria buena 
pero no se si se volvería popular o no
al menos seria mas fácil de ocupar que las wikis
|
#6 Jueves, 13 Octobre 2011, 17:50 |
|
|
jsbsan
Analista Programador
Registrado: Septiembre 2009
Mensajes: 4175
Edad: 51 Ubicación: dos hermanas, sevilla
|
Re: Recolector: Organiza Tus Códigos Fuentes
Lo de la web "dinamica" es buena idea.... pero ¿quien le pone el cascabel al gato?
Aunque al programa se le podria añadir alguna opcion de subir o bajar articulos...habrá que ponerse a pensar...Tambien tiene un inconveniente, a lo mejor lo que uno considera interesante a otra persona no le interesa, además podrian haber entradas duplicadas...
En fin, a pensar se ha dicho...
Saludos
|
#7 Jueves, 13 Octobre 2011, 20:43 |
|
|
jsbsan
Analista Programador
Registrado: Septiembre 2009
Mensajes: 4175
Edad: 51 Ubicación: dos hermanas, sevilla
|
Re: Recolector: Organiza Tus Códigos Fuentes
Ya tengo terminada la nueva version 0.1.1, del recolector:
Mejoras:
- Visualizacion de datos, ya no se ponen en gris, simplemente no te deja escribir, si no estas en modo Insertar o Editar
- Busquedas dinamicas: mientras escribes en el textbox de buscar, va realizando la busqueda y filtrado de datos
PUBLIC SUB TextBoxBuscar_KeyPress()
IF Asc(Key.text) > 47 AND Asc(Key.text) < 122 THEN
'vuelvo a presentar la lista de tags
consulta = BaseDatos.tagsDinamica(conexion, TextBoxBuscar.text & Key.text)
GridViewListaTag.Rows.Count = consulta.Count
ENDIF
END
PUBLIC SUB GridViewListaTag_Data(Row AS Integer, Column AS Integer)
consulta.moveTo(row)
GridViewListaTag.Data.text = Str(consulta[GridViewListaTag.Columns[column].text])
END
He tenido que filtrar los valores del key.text, para que no se puedan hacer consultas sino es cuando el usuario ha escrito un numero o letra, ya que si borra y paso ese valor del key.text a una sentencia sql, daba error.
Y en el módulo BaseDatos
-Subbusqueda: realiza subbusqueda de consultas
'---------------------------- subbusquedas ----------------------
PUBLIC FUNCTION ArticulostagsDinamica(conexion AS Connection, texto AS String, texto2 AS String) AS Result
DIM s1, s2, s3 AS String
s1 = "SELECT idtags FROM listatags WHERE DescripcionTags='" & TEXTO & "'"
s2 = "SELECT id FROM tags where idtags IN (" & s1 & ")"
s3 = "SELECT id,articulo,descripcion FROM articulo WHERE id IN (" & s2 & ")"
IF texto <> "" THEN
'busca en la misma subconsulta, que articulo contenga texto2
sentenciasql = "SELECT id,articulo,descripcion FROM articulo WHERE articulo LIKE '%" & texto2 & "%' "
ELSE
sentenciasql = s3
ENDIF
TRY varresult = conexion.Exec(sentenciasql)
RETURN varresult
END
PUBLIC FUNCTION DescripciontagsDinamica(conexion AS Connection, texto AS String, texto2 AS String) AS Result
DIM s1, s2, s3 AS String
s1 = "SELECT idtags FROM listatags WHERE DescripcionTags='" & TEXTO & "'"
s2 = "SELECT id FROM tags where idtags IN (" & s1 & ")"
s3 = "SELECT id,articulo,descripcion FROM articulo WHERE id IN (" & s2 & ")"
IF texto <> "" THEN
'busca en la misma subconsulta, que articulo contenga texto2
sentenciasql = "SELECT id,articulo,descripcion FROM articulo WHERE descripcion LIKE '%" & texto2 & "%' "
ELSE
sentenciasql = s3
ENDIF
TRY varresult = conexion.Exec(sentenciasql)
RETURN varresult
END
- Y ademas añado el modulo de update, para que el usuario pueda comprobar si su version es la mas actualizada o debe actualizarla.
Saludos
|
#8 Domingo, 16 Octobre 2011, 10:27 |
|
|
jguardon
Administrador
Registrado: Septiembre 2009
Mensajes: 2708
Edad: 57 Ubicación: Granada
|
Re: Recolector: Organiza Tus Códigos Fuentes
Hola Julio
Para no repetir código innecesariamente, podrías haber agrupado los dos últimos métodos "ArticulostagsDinamica" y "DescripciontagsDinamica" en uno sóllo, añadiendo un último parámetro opcional del tipo booleano, o incluso string, de manera que usando ese parámetro se sustituya el campo de búsqueda en la "sentenciasql" según convenga.
PUBLIC FUNCTION ADtagsDinamica(conexion AS Connection, texto AS String, texto2 AS String, Optional descripcion AS Boolean ) AS Result
DIM s1, s2, s3, opt AS String
IF descripcion THEN
opt = "descripcion"
ELSE
opt = "articulo"
ENDIF
s1 = "SELECT idtags FROM listatags WHERE DescripcionTags='" & TEXTO & "'"
s2 = "SELECT id FROM tags where idtags IN (" & s1 & ")"
s3 = "SELECT id,articulo,descripcion FROM articulo WHERE id IN (" & s2 & ")"
IF texto <> "" THEN
'busca en la misma subconsulta, que articulo contenga texto2
'sentenciasql = "SELECT id,articulo,descripcion FROM articulo WHERE " & opt & " LIKE '%" & texto2 & "%' "
' otra forma de escribir sentencias usando substitución:
sentenciasql = subst$("SELECT id, articulo, descripcion FROM articulo WHERE &1 LIKE '%&2%' ", opt, texto2)
ELSE
sentenciasql = s3
ENDIF
TRY varresult = conexion.Exec(sentenciasql)
RETURN varresult
END
La idea es conseguir un código más corto y limpio, y sobre todo no repetir código, aunque a veces resulta difícil, está claro.
Fíjate también en el uso de Subst$() para realizar las sustituciones mediante comodines. También lo podíamos haber usado en las demás sentencias sql.
El condicional del principio que evalúa el parámetro descripcion, podría haberse escrito de este modo, ahorrando unas líneas de código y resultando más elegante:
opt = IIf(descripción = TRUE, "descripcion", "articulo")
Incluso podríamos quitar la comparación explícita " = TRUE"...
Bueno, cositas como estas proporcionan un poco más de calidad al código
Saludos
===================
Jesús Guardón
Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".
"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"
|
#9 Domingo, 16 Octobre 2011, 11:13 |
|
|
fabianfv
Analista Programador
Registrado: Octobre 2009
Mensajes: 495
Edad: 50 Ubicación: 
|
Re: Recolector: Organiza Tus Códigos Fuentes
Una crítica constructiva:
PUBLIC FUNCTION ADtagsDinamica(conexion AS Connection, texto AS String, texto2 AS String, Optional descripcion AS Boolean ) AS Result
DIM s1, s2, s3, opt AS String
IF descripcion THEN
opt = "descripcion"
ELSE
opt = "articulo"
ENDIF
s1 = "SELECT idtags FROM listatags WHERE DescripcionTags='" & TEXTO & "'"
s2 = "SELECT id FROM tags where idtags IN (" & s1 & ")"
s3 = "SELECT id,articulo,descripcion FROM articulo WHERE id IN (" & s2 & ")"
IF texto <> "" THEN
'busca en la misma subconsulta, que articulo contenga texto2
'sentenciasql = "SELECT id,articulo,descripcion FROM articulo WHERE " & opt & " LIKE '%" & texto2 & "%' "
' otra forma de escribir sentencias usando substitución:
sentenciasql = subst$("SELECT id, articulo, descripcion FROM articulo WHERE &1 LIKE '%&2%' ", opt, texto2)
ELSE
sentenciasql = s3
ENDIF
TRY varresult = conexion.Exec(sentenciasql)
RETURN varresult
END
En el sentido de lo que expresó Jesús Guardón, y a pesar de la mejora que implican sus modificaciones, aún hay unos cuantos problemas en ese código:
- El nombre de la función no comunica la intención del programador, no dice qué es lo que quiso hacer, cuál es la tarea que la función debe cumplir, a menos que se pueda adivinar qué significa AD. Por supuesto, se puede tener una idea más o menos clara de la tarea que debe cumplir la función al leer su código, pero la idea de un nombre (el de la función en este caso) es que comunique de forma concisa el objetivo de la rutina.
El nombre de la función es como un contrato. Como programador le pones nombre a un función y te comprometes a escribir código que corresponda con el significado que dicho nombre expresa.
Cualquier otro programador que lee ese código cuenta, entonces, con una declaración explícita por parte del programador original respecto del propósito de la función y en consecuencia puede, por ejemplo, verificar que el código cumple con el propósito explicitado o introducir modificaciones respetando el contrato original.
- Los argumentos "texto" y "texto2" tienen el mismo problema.
- El argumento "descripcion" se sabe que es una descripción, pero no se sabé qué es lo que describe. Si esta función es parte de un objeto bien diseñado, el significado del nombre se completa con el contexto y entonces es correcto, pero en el caso contrario es poco significativo.
- Las variables locales s1, s2, s3, y opt tienen el mismo problema: sus nombres no son "intention revealing".
La elección de nombres sin significados precisos puede ser un indicio claro de que el programador aún no conoce adecuadamente el dominio de la aplicación, pero aún en caso de que sí lo comprenda el principal problema que se deriva es que los nombres producen confusión.
Esta confusión consiste en que el lector no puede comprender el dominio del problema y de la solución al leer el código y por lo tanto no está en buenas condiciones de mejorar el diseño y cualquier modificación que pueda introducir es más propensa a errores. Además, la única forma obvia en que un programador responsable evitaría este problema sería invertir una cantidad de tiempo innecesariamente excesiva en "comprender el código".
Dicho de otro modo y generalizando: la elección de nombres sin significado, con poco significado o con un significado que no se corresponde con el dominio (del problema o de la solución) conduce a que no sea posible razonar adecuadamente sobre el problema y en consecuencia sobre cuál es la mejor forma de solucionarlo.
- Las consultas SQL se pueden resumir y de esa forma hacer que el código sea mucho más expresivo y eficiente. No lo explicaré porque me extendería demasiado, pero la clave pasa por utilizar joins o subquerys.
- La sentencia SQL dentro de la estructura condicional también me parece innecesaria (como consecuencia de un pobre diseño de la consulta inicial).
- Esta función puede escribirse con 10 líneas de código en vez de las 20 líneas que aproximadamente tiene. Esto en algunos lenguajes podría ser algo malo porque acortar el código significaría ofuscarlo, pero en gambas si el programador se esmera sólo un poco, se puede lograr un código mucho más expresivo con la mitad del código (o menos).
Tenemos que comprender que el código lo escribimos en un "lenguaje de programación", entonces la palabra "lenguaje" no nos debe pasar desapercibida. El problema subyacente es que los lenguajes de programación se diseñaron históricamente con una visión de sentido único: los lenguajes deben permitir escribir código que pueda comprender la computadora.
Pero en realidad esto es tarea del compilador (la máquina virtual o el intérprete) y no el objetivo de los lenguajes. Los lenguajes se deben diseñar para que los humanos podamos comprenderlos, lo que se puede resumir en la frase: "el código se escribe una vez, pero se lee cientos de veces", donde quienes leen ese código cientos de veces son personas, no máquinas.
gambas no es el lenguaje más expresivo en este sentido, pero ocupa un muy buen un lugar en el "ranking de los lenguajes humanoides". De modo que un programador gambas debería destacarse por escribir código que explote adecuadamente sus características (código idiomático) y una de esas características es la concisión y la claridad expresiva del código (para un lector humano).
Aún faltarían analizar varias cosas, pero para ello sería indispensable observar el contexto. Lo que puedo asegurar es que el esfuerzo que implica aprender, sucesivamente, a escribir código de mayor calidad se ve recompensado por el incremento la productividad del programador, pero especialmente por la grata sensación que produce la auto-superación.
Saludos.
=================== Cómo programar con Gambas
Speed Books: informática libre.
|
#10 Domingo, 16 Octobre 2011, 16:41 |
|
|
|
|
 Temas parecidos
 Temas parecidos
|
|
Página 1 de 2
|
Usuarios navegando en este tema: 0 registrados, 0 ocultos y 1 invitado
Usuarios registrados conectados: Ninguno
|
No puede crear mensajes
No puede responder temas
No puede editar sus mensajes
No puede borrar sus mensajes
No puede votar en encuestas
No puede adjuntar archivos
Puede descargar archivos
No puede publicar eventos en el calendario
|
|
|
|
|
Foro 
