The killer ClubDelphi application... (antes: aportarias tu codigo?)

[mamcx]

Hay un tipo de software/aplicacion que es ESPECIAL:

El programa ASESINO.

Ejemplos de programas asesinos:

- Office es THE KILLER para Windows.
- Apache es THE KILLER para servidores Web.
- Ruby On Rails es THE KILLER para ruby y Web 2.0
- Delphi es THE KILLER para pascal y aplicaciones nativas
- Skype THE KILLER en voip.
- Google THE KILLER buscador.

y asi sucesivamente. Hay una aplicacion que catapulta todo.

Solo por emocionarnos, o por soñar, siguiendo la propuesta de http://www.clubdelphi.com/foros/showthread.php?t=1254 (Seria bueno que quienes llegaron tarde se lean el thread), imaginemos

THE KILLER CLUBDELPHI APPLICATION



La aplicacion que hara famosa la mas mejor comunidad (no garantizo la certeza cientifica de la afirmacion) de Delphi y afines.


Como la idea anterior quedo en veremos, pues aqui voy:

1. Quien no sabe para donde va, no llega a ninguna parte.

Se presupone que si es del ClubDelphi seria un desarrollo comunitario y open source. Se presupone que se basaria en la capacidad y herramientas que usamos. Seria *ideal* una integracion de productos/tecnologias existentes VS crear una tecnologia como tal.

Asi que las propuestas deben tener:

- Titulo

- Problema a resolver

- Como se puede resolver

- Mercado objetivo (Usuario final, pymes, gobierno, desarrolladores). Mas de uno no es buena idea. UN MERCADO, uno solo. UNO.

- Ejemplos de ideas similares, quienes son la competencia (si estamos bien enfocados, la competencia es un/unos programas de suficiente distribucion masiva que den resultados tan tan pobres que un recien llegado va a deslumbrar)

- Tareas a desarrollar (los modulos a grandes rasgos)

- Menos de 3 razones por las cuales se puede considerar una aplicacion ASESINA. Los TOP -3 puntos que hay que machacar (machacar: Verbo de uso popular en Colombia que denota la accion de aplastar brutalmente algo).

3.

1,2,3.

Si llegas a 3, paras.

3 sera el numero maximo de puntos.

4 no es igual a 3..

3 es es limite superior.

0 y -n no son respuestas validas.

En conclusion, maximo 3, bien?

- Porque es buen negocio hacerlo. Buen negocio = porque hay que dedicarle tiempo, que va a devolver a quienes lo hacen (plata? reconocimiento? experiencia?)

- 10.000 puntos si se arma una idea aun mas simple de lo que es posible para la muy cerrada menta de un programador. Simple mata a complejo. Complejo es de pendejos!

2. Quien no sabe decir no, nunca termina.

Cosas que NO se deberian especificar:

- Herramientas a usar
- Peleas sobre MS, Linux, Open Source, el clima y los resultados del mundial.
- Mas de 3 razones para ser THE KILLER.
- Mas de 1 mercado objetivo.
- Una aplicacion que compite con otra KILLER. Reemplazos de Office, Apache, Linux, etc... es una perdida de tiempo. Se necesita mucho dinero. El proximo IPOD se lo dejamos a google.
- Un ERP.
- Un videojuego.
- Esto no se puede
- No creo que podamos
- Dejemoselo a otros
- No tengo tiempo
- Ustedes estan locos
- mamcx esta loco (ya lo se, no me lo repitan)

3. Hay que acabar en esta decada

Lo mas dificil. Deseo que lo que sea que se haga sea posible en MENOS de 6 meses. Contando 1 hora diaria de programacion seria para un equipo de unos 10 (que creo es lo que se armaria al principio).

Si demora mas de 6 meses, la agotacion nos va a matar. La aplicacion asesina no puede ser lenta, dormilona e indecisa. ASESINA. Eso es ;)

6 meses. Maximo. A lo google.

4. Necesitamos unos 10 que se le apunten.

La comunidad ayuda, pero debe haber 10 que encabezen. 10 pùede ser demasiado, pero es mi numero porque:

- Un peludo que se encarge de marañar con sourceforge o lo que sea. Postee informacion y eso.

Yo he hecho eso y me agota. Incluso tengo la Beta de MUTIS (que funciona mas o menos) y hace unos 3 meses esta descansando en mi disco duro...

- Unos -5 peludos que programen

- Unos 2 peludos que prueben

- Un peludo que se encargue de los asuntos aleatorios, como conseguir iconitos.

- Un par de peludos que nos hagan barra! (coordinadores?)

- 1 peludo que documente

Menos peludos puede ser. Pero creo que necesitamos todos comer. Y en mi experiencia con MUTIS (que no he acabado por falta de tiempo y de ayuda :( ) no creo poder dedicar mas de 2 horas a la semana, 2 horas serias si, pero no mas de 2.

Como ven, esto es un terriblemente restrictivo conjunto de leyes que arbitraria y dictatorialmente se me ocurrio (no me odien por ello!). Pero yo quiero una aplicacion ASESINA, y no se hace con mimos ;)


P.D. Mejores ideas son aceptadas de como plantear. Pero tiene que ser duras, aterrizadas y bofeteadoras. Algo serio. Si no es serio, me ponga a ver Oggy y las cucarachas.

[mamcx]

A proposito, como favor especial a los administradores, en base a la propuesta del hilo anterior, es posible darle stiky?

Y en la medida que hayan propuestas, ir haciendo un poll? Y cerramos a un # maximo? (10-20?)

[dec]

Hola,


A proposito, como favor especial a los administradores, en base a la propuesta del hilo anterior, es posible darle stiky?

¿Qué significa stiky? :cool:

A mí no me parece mala la idea de llevar a cabo algún programa en equipo. Si se me permite dar mi opinión (menudo equipo sino se me permitiera :D) diría que no se utilizara Delphi para llevarla a cabo.

Delphi es un programa propietario. Un lenguaje propietario, también. Si se piensa llevar a cabo un programa para liberarlo bajo licencia GPL me gustaría trabajar con un lenguaje libre, gratuito y multiplataforma.

Me estoy refiriendo a PHP, naturalmente. A LAMP, para ser más exactos: Linux, Apache, MySQL y PHP. Admito quitar de la ecuación a GNU/Linux, pero, no definitivamente: un programa desarrollado en Windows con PHP, MySQL y Apache podría llevarse a cabo (continuarse, mejorarse y utilizarse) también en GNU/Linux.

Además elegir algo como lo que menciono, en mi opinión, es muy interesante en no pocos aspectos: se trataría de llevar a cabo un desarrollo Web, un programa "ejecutable" en cualquier navegador (más o menos moderno) y en cualquier sistema operativo (ídem de ídem).

Propondría también una aplicación a la cual asesinar. Es cierto que con bastante miedo, o con no poco respeto. Hablo de WordPress, ni más ni menos. Un Gestor de Contenidos Web muy popular, conocido, utilizado, valorado, y con una comunidad detrás que quita el hipo, envidiable, por numerosa, activa, original y capacitada.

Hay decenas, cientos de Gestores de Contenidos. WordPress sólo hay uno. Dos o tres se le pueden comparar. Quizás algunos más, pero, WordPress es mucho WordPress, en mi opinión. Sin embargo, ahí tenemos las herramientas, completamente gratuitas: MySQL, Apache y PHP. Están a la disposición de cualquiera que quiera utilizarlas.

Si existe un coste (Servidor Web, espacio Web, etc.), lo cierto es que este siempre será menor que si además tuviésemos que sumarle el precio de las licencias de los respectivos productos propietarios conque trabajar, por ejemplo, con ASP, de Microsoft. Y, si es que decidiera llevar a cabo algún programa para Windows... (con Delphi, digo) bueno, no existiría coste en Servidor Web, etc., pero, las licencias no las quita ni el Papa.

Y no pienso en cualquier licencia. Pienso en que alguien quisiera echar una mano en el proyecto. Pienso en aquellos que quisieran contribuir con Plugins, por ejemplo, al programa. Pienso en la cantidad de licencias que implica un desarrollo sobre un entorno propietario y, al menos para mi economía, bastante caro, por cierto.

Me gustaría terminar, por el momento, defendiendo la tesis de que no sería demérito en absoluto que aquí en el ClubDelphi nos pusiéramos de acuerdo para llevar a cabo un programa escrito en PHP. Todo lo contrario. No creo que una cosa tenga que ver con la otra y estoy dispuesto a argumentarlo si es preciso. ;)

Y bueno... no digo más que bastante he dicho ya por el momento... ¡matar a WordPress! ¡Válgame SanFermín por la osadía! ¿Y tú qué opinas de todo esto? :D

[Neftali [Germán.Estévez]]

Delphi es un programa propietario. Un lenguaje propietario, también. Si se piensa llevar a cabo un programa para liberarlo bajo licencia GPL me gustaría trabajar con un lenguaje libre, gratuito y multiplataforma.
Me estoy refiriendo a PHP, naturalmente. A LAMP, para ser más exactos...

¿Cual es el procentaje de usuarios del ClubDelphi que están capacitados para trabajar en un proyecto serio con PHP (LAMP ni lo había oído en mi vida)?

Sé que tú conoces PHP David (además de Delphi), pero me temo que entre los usuarios del ClubDelphi, quitando los que han entrado una vez y no vuelven, los que no están activos, los que no tienen conocimientos suficientes, los que no tienen tiempo suficiente, los que no les apetece,... ¿Cuantos pueden trabajar en un proyecto con PHP/LAMP? (A mi ya me descarta por completo).
No dudo que sea posible, pero no creo que sea este el foro para "lanzar" un proyecto en ese lenguaje (apenas ha habido 15 mensajes en el foro de PHP en 2 semanas).

Es una simple opinión.

[dec]

Hola,


Sé que tú conoces PHP David (además de Delphi),...


Bueno. Ambas cosas son una exageración, y no es falsa modestia. :cool:

Lo que pasa es que (aunque no lo mencioné lo hago ahora) el desarrollo del proyecto que fuese también serviría para aprender Neftalí. Por ejemplo, si se quiere asesinar a WordPress... más vale comenzar estudiando a WordPress, el código fuente de WordPress, en buena medida.


(...) pero me temo que entre los usuarios del ClubDelphi, quitando los que han entrado una vez y no vuelven, los que no están activos, los que no tienen conocimientos suficientes, los que no tienen tiempo suficiente, los que no les apetece,... ¿Cuantos pueden trabajar en un proyecto con PHP/LAMP? (A mi ya me descarta por completo).


Bueno. Es cierto que este Foro principalmente cuenta con gente interesada en Delphi. Empero, creo que hay bastantes personas capaces de atacar un proyecto escrito en PHP con más o menos soltura. Por si esto fuera poco, no sólo sería necesario programar, sino probar, documentar, diseñar, gráficos, ideas, recursos de todo tipo, etc., etc., etc.

Ahora bien, ¿qué nos ofrece PHP? ¿Qué nos ofrece LAMP? ¡Herramientas de código abierto, sin coste alguno además, sin problemas de licencias! Y no pocas librerías, clases, código fuente, en fin, del que podríamos partir, o en el que en todo caso podríamos apoyarnos.

Cuando uno hace un programa en Delphi... un programa de código abierto, que pueda ser extendido mediante módulos o plugins (preferiblemente por el mayor número de programadores (o personas interesadas, puesto que se procuraría ofrecer un API que hiciera relativamente sencilla la tarea), ¿no es una cortapisa de entrada el tener que contar con un entorno de programación que cuesta miles de dólares?

Yo creo que lo es, y es por esto que preferiría un lenguaje de programación, unas herramientas y un entorno "libre", de código abierto, multiplataforma y gratuito por añadidura. ¿No te apetecería adentrarte un tanto en PHP y en lo que implica? ¿No querrías participar, para aprender, en un proyecto fuera de Delphi? Yo creo que no estaría mal, que sería una experiencia, algo curioso e interesante. ¿No? :)

Ah, pero, también es una simple opinión. ;)

[Casimiro Notevi]

Todo dependerá de lo que finalmente se decidiera hacer, no se puede decir de primera hora si usar LAMP (linux,apache,mysql,php) o WDF (windows,delphi,firebird) :D porque primero es decidir qué hacer y luego según lo que sea, requerirá unas herramientas u otras.

[dec]

Hola,


Todo dependerá de lo que finalmente se decidiera hacer, no se puede decir de primera hora si usar LAMP (linux,apache,mysql,php) o WDF (windows,delphi,firebird) :D porque primero es decidir qué hacer y luego según lo que sea, requerirá unas herramientas u otras.

Bueno. Como mi idea partía de matar (aunque sea un poquito :D) a WordPress he pensado en Apache, MySQL y PHP como herramientas a tener en cuenta. No me veo matando a WordPress con Delphi, la verdad, porque sería como tratar de matar moscas a cañonazos, me parece a mí. Y, por otro lado, eligo PHP y no ASP, por ejemplo, quizá porque le tenga cierto apego a PHP, es cierto, pero, por otros motivos también, como que LAMP no implica ASP, porque es un lenguaje propietario de Microsoft.

O sea, que, en esta ocasión no he puesto el carro antes que los bueyes... ¡para variar! :D

[Neftali [Germán.Estévez]]

Lo que pasa es que (aunque no lo mencioné lo hago ahora) el desarrollo del proyecto que fuese también serviría para aprender Neftalí.

La experiencia me dice que el desarrollo de un proyecto con cierta embergadura no es el lugar más apropiado para aprender (desde cero). No es bueno para quien aprende, ni para quien programa.

¡Herramientas de código abierto, sin coste alguno además, sin problemas de licencias! Y no pocas librerías, clases, código fuente, en fin, del que podríamos partir, o en el que en todo caso podríamos apoyarnos.


¿Lazarus no sería una buena opción para eso?
Creo que sería una opción "más cercana y accesible", si es que se quiere algo libre.

[dec]

Hola,


La experiencia me dice que el desarrollo de un proyecto con cierta embergadura no es el lugar más apropiado para aprender (desde cero). No es bueno para quien aprende, ni para quien programa.

¿Porqué?


¿Lazarus no sería una buena opción para eso?

Creo que sería una opción "más cercana y accesible", si es que se quiere algo libre.

Sí. Creo que un proyecto de estas características debería ser libre y de código abierto. Por varios motivos. En cuanto a Lázarus... no; no creo que sea un buen entorno de programación actualmente, ni para Windows ni para Linux. Y no es que no me gustase decir otra cosa.

[Neftali [Germán.Estévez]]

¿Porqué?

El código del proyecto se resiente, ya que las personas que programen no tienen la suficiente experiencia para asegurar que lo que están haciendo es correcto (y si hay alguien que debe ir revisando no sirve de nada) y las personas/programadores también, porque el ritmo de aprendizaje no lo marca la lógica/libro/manual con una coherencia, sino que lo marca la necesidad del proyecto y ese ritmo de aprendizaje (o esa línea a seguir) no siempre es el correcto (tal vez en algunas cosas empiezas a "hacer la casa por el tejado"); No se si me explico.

El primero lo he sufrido mucho en mis carnes y:
* Se pierde mucho tiempo
* Se generar muchos errores (por inexperiencia)
* Se genera un descontento y una frustración al tener que "revisar" por parte de una segunda persona código que ha hecho otra y del que no te puedes fiar (simplemente por inexperiencia).

[pepon386]

Aquí se está poniendo en duda el uso de Delphi pero, ¿esto no es un foro sobre Delphi? Lo lógico sería usar Delphi como herramienta principal, recurriendo a otras para cosas que no se puedan hacer con Delphi (¿las hay?).
También se cuestiona el uso de una herramienta de desarrollo que tiene un coste "elevado". Si uno no lo usa comercialmente, puede acceder a la licencia de estudiante (más barata), o a una cedida por alguien amablemente, siempre que no se vaya a usar comercialmente. Pero si se dedica profesionalmente al mundo de la programación... ¿no sería lógico que ya tuviese su licencia adquirida?. Puede que alguien no esté de acuerdo conmigo, pero según veo yo, si utilizas una aplicación para sacar provecho económico, deberías de tener una licencia registrada de dicha aplicación. A lo mejor lo que se debería de precisar es la versión de la herramienta a usar: Standard, Professional, Architect.

[Ñuño Martínez]

Como ya dije en este hilo (http://www.clubdelphi.com/foros/showthread.php?p=146812#post146812), FreePascal+Lazarus es una buena alternativa a Delphi. Una gran ventaja es que a nivel de lenguaje (se llama Pascal y no es propietario) son compatibles en un 99'9%.

De todas formas, hasta que no se sepa lo que se va a hacer y quién va a participar, no debería hablarse de las herramientas a utilizar. Es más, si el proyecto se lo merece, es posible que haya partes que se puedan escribir en otros lenguajes como C, Lua, PHP, JavaScript, etc.

[dec]

Hola,


El código del proyecto se resiente, ya que las personas que programen no tienen la suficiente experiencia para asegurar que lo que están haciendo es correcto (y si hay alguien que debe ir revisando no sirve de nada) y las personas/programadores también, porque el ritmo de aprendizaje no lo marca la lógica/libro/manual con una coherencia, sino que lo marca la necesidad del proyecto y ese ritmo de aprendizaje (o esa línea a seguir) no siempre es el correcto (tal vez en algunas cosas empiezas a "hacer la casa por el tejado"); No se si me explico.


Bueno. No estoy de acuerdo con la mayoría de lo que has dicho en ese párrafo Neftalí. Trataré de exponer porqué. En primer lugar creo que revisar el código fuente del proyecto sirve de mucho, de hecho no quedaría más remedio que hacerlo, y creo que forma parte del desarrollo. Ya he dicho que, si se quiere matar a WordPress, habrá que leer el código fuente de WordPress.

No creo que se llegase a hacer la casa por el tejado, porque, antes de escribir la primera línea de código el proyecto tendría que estar lo suficientemente cimentado como para ponerse a ello. Es cierto que uno se puede poner a programar compulsivamente de la noche a la mañana, pero, ¿estamos hablando de un proyecto a medio/largo plazo, o de ponernos a programar de la noche a la mañana a ver qué sale?

En fin. Creo que incluso para alguien que apenas sepa nada de PHP (que es mi caso, por cierto) podría resultar de provecho colaborar (en la medida de sus posibilidades) en el desarrollo de un proyecto en equipo. Sigo creyendo que serviría como experiencia (luego veríamos si buena o mala, que de todas se aprenden algo) y hasta que quien no sepa (aparentemente) podría acaso sorprender con sus aportaciones, por decirlo de algún modo.

Otrosí reconozco que no tengo experiencia trabajando en equipo. Y que nunca he trabajado en un proyecto de lenguaje desconocido hasta entonces. Así que por experiencia, lo que se dice por experiencia, no puedo hablar y no hablo.


Aquí se está poniendo en duda el uso de Delphi (...)


No es cierto, al menos no puedes decirlo por mí. Ya he dicho porqué eligiría PHP, en este caso: he propuesto una aplicación asesina que llevar a cabo, y esta no podría estar escrita en Delphi debido a sus características. Es lógico, me parece, y si no corregidme, pero, no estoy poniendo en duda Delphi como herramienta en absoluto, no es esa mi intención y no creo que en ningún modo pueda colegirse algo así de lo que he dicho.


¿esto no es un foro sobre Delphi?


Prefiero pensar que, aunque el nombre sea ClubDelphi, aquí se reúne una comunidad de programadores dispuestos a echarse una mano, entre otras cosas. De hecho en los Foros hay apartados para varios lenguajes de programación, no sólo se trata en ellos de Delphi, y no creo que esto sea un error, sino todo lo contrario. Incluso puede que sea así porque no puede ser de otro modo. Y la realidad está ahí.


También se cuestiona el uso de una herramienta de desarrollo que tiene un coste "elevado".


Para un proyecto de código abierto, desarrollado en equipo y cuya licencia fuera a ser de código abierto, sí, verdaderamente, el coste de la herramienta tiene su barrera de entrada. Eso es innegable. Más, desde el momento en que se pueden utilizar herramientas que son gratuitas: no las versiones personales (y capadas) sino las que todo el que quiera puede utilizar, cualquiera que sea su nivel.

Pero, me estoy yendo por las ramas, y no me hace falta: he hablado de matar a WordPress y digo una vez más que Delphi no me parece la mejor herramienta para llevarlo a cabo. Me refiero a eso y a nada más. El párrafo anterior lo mantengo, salvo que se me den razones suficientes para no hacerlo, pero, en el caso del asesinato de WordPress que he planteado, Delphi sería demasiado "bruto", por decirlo de alguna manera, y nos acabaría cogiendo la policía. ¿Y no es lo que queremos, verdad?


Si uno no lo usa comercialmente, puede acceder a la licencia de estudiante (más barata), o a una cedida por alguien amablemente, siempre que no se vaya a usar comercialmente. Pero si se dedica profesionalmente al mundo de la programación... ¿no sería lógico que ya tuviese su licencia adquirida? (...)


Si uno lo usa comercialmente, sin duda, creo que tienes razón. Pero, ¿y si no se va a usar comercialmente? ¿Y si no se va a negociar con la licencia del programa, sino que, como mucho, los negocios vendrían de otro sitio? Piensa únicamente en todos aquellos programadores que quieran desarrollar un Plugin para el hipotético programa... ¿los obligarías a comprar Delphi? O, lo que es lo mismo, ¿impedirías que muchos de ellos pudieran colaborar por no poder pagar la licencia de Delphi?


Puede que alguien no esté de acuerdo conmigo, pero según veo yo, si utilizas una aplicación para sacar provecho económico, deberías de tener una licencia registrada de dicha aplicación


A grandes rasgos yo, desde luego, esoy de acuerdo contigo. Pero, puesto que preferiría un proyecto de código abierto a uno cerrado, pienso que Delphi no es la herramienta más adecuada. Es posible que me equivoque, eso no lo dudo, porque no sería la primera vez ni sería la última.


A lo mejor lo que se debería de precisar es la versión de la herramienta a usar: Standard, Professional, Architect.


A lo mejor; aquí estamos por el momento hablando sobre el asunto. ¿Para asesinar a qué aplicación, dices tú? :D


De todas formas, hasta que no se sepa lo que se va a hacer y quién va a participar, no debería hablarse de las herramientas a utilizar.


Completamente de acuerdo. Yo propongo asesinar a WordPress. ¿Qué herramientas propones tú para llevar a cabo el magnicidio, si es que no te parece mal, quiero decir, supuesto el caso que no vieras mal un proyecto así? Porque, a otros proyectos (sin conocerlos), otros lenguajes, probablemente, otras herramientas. O sea que sí, que hay que esperar a ver qué se va a hacer para comenzar a vislumbrar cómo llevarlo a cabo. :)

[roman]

¿Por qué hablan tanto de matar a WordPress? Me parece haber entendido de lo que escribió mamcx que es esto precisamente lo que no hay que hacer: un sustituto para una aplicación killer. ¿Cuál sería el beneficio, objetivo?

// Saludos

[kuan-yiu]

Yo actualmente (en verano) no tengo tiempo para dedicarle a un proyecto, pero soy muy buena con "los extras":
* Se me da bien hacer la ayuda.
* Sé redactar, maquetar texto, puedo escribir tanto en formato científico como para principiantes.
* Uso habitualmente diversos programas de edición gráfica, así que puedo hacer iconos propios, imágenes...

[mamcx]

Chicos, chicos...

Ven?

2. Quien no sabe decir no, nunca termina.

Cosas que NO (NO <> SI ) se deberian especificar:

- Herramientas a usar
- Peleas sobre MS, Linux, Open Source, el clima y los resultados del mundial.

Un ASESINO no descarta herramientas, ni se queda con la Katana porque quiere. Que le toco usar una alfiler? Alfiler sera.

Llevan varias post, y ya se distrajeron. Malos Jedis seran, con sabiduria Yoda dira!

Para empezar un proyecto, hay cosas que definitivamente no se pueden hacer. Las herramientas antes del trabajo? Si aun no se sabe que hay que hacer!

Volviendo a lo poco que se, que desarrollo sitios web y usamos DotNetNuke, phpNuke y he probado, sin mentir, al menos 30+ herramientas estilo "Wordpress" la verdad les digo: Una aplicacion de escritoria seria GENIAL. El internet no es estable, no es rapido, no es facil de manejar varios sitios, etc...

Reformatiemos la propuesta:

Titulo

- Problema a resolver

- Como se puede resolver

- Mercado objetivo (Usuario final, pymes, gobierno, desarrolladores). Mas de uno no es buena idea. UN MERCADO, uno solo. UNO.

- Ejemplos de ideas similares, quienes son la competencia
- Tareas a desarrollar (los modulos a grandes rasgos)
- Menos de 3 razones por las cuales se puede considerar una aplicacion ASESINA.
- Porque es buen negocio hacerlo.
- 10.000 puntos si se arma una idea aun mas simple de lo que es posible para la muy cerrada menta de un programador.

[dec]

Hola,


¿Por qué hablan tanto de matar a WordPress? Me parece haber entendido de lo que escribió mamcx que es esto precisamente lo que no hay que hacer: un sustituto para una aplicación killer. ¿Cuál sería el beneficio, objetivo?


Bueno. En realidad soy yo el que hablo de matar a WordPress. ¿Que para qué? ¿Vale para cumplir un sueño? :D

Ampliando... justificando... diría que tal vez puedan darse mejoras en WordPress. Para empezar sería algo con el objetivo de mejorar a WordPress. ¡Un programa desarrollado por españoles para el mundo! Je, je, je. En fin. Es el programa que se me ha ocurrido asesinar, pero, estoy abierto a otras posibles víctimas. :cool:

En cuanto a la aplicación "Killer"... no lo he dicho antes, pero, creo que Mario se confunde con eso. Una aplicación líder está ahí arriba, en el olimpo de los intocables, venerada por todos y utilizada por muchos, y entonces llega la aplicación "Killer", que se la carga, la manda al infierno y, ¿para qué? ¿Para ser "Killer"? ¡No! Para ser líder, obviamente. ¿Me explico? ;)

[Neftali [Germán.Estévez]]

Creo que no me has entendido David.

...creo que revisar el código fuente del proyecto sirve de mucho, de hecho no quedaría más remedio que hacerlo, y creo que forma parte del desarrollo. Ya he dicho que, si se quiere matar a WordPress, habrá que leer el código fuente de WordPress.

Me refiero a revisar el código fuente de otro programador (alguien como yo, por ejemplo, que no conoce PHP); El código que yo escriba (para hacer algo serio) debería ir alguien detrás mío revisándolo y corrigiéndolo. Y eso no es manera de trabajar.

...No creo que se llegase a hacer la casa por el tejado, porque, antes de escribir la primera línea de código el proyecto tendría que estar lo suficientemente cimentado como para ponerse a ello. Es cierto que uno se puede poner a programar compulsivamente de la noche a la mañana, pero, ¿estamos hablando de un proyecto a medio/largo plazo, o de ponernos a programar de la noche a la mañana a ver qué sale?

No me refiero al proyecto, sino a mi, como "persona que aprende PHP".
(1) Si aprendiera PHP hoy con un manual lo haría con una cronología (la del manual) que suele estar estudiada y sigue un orden lógico.
(2) Si me pongo a programar en el proyecto la cronología de mi aprendizaje, la marcan mis necesidades dentro del proyecto; Y Eso no es correcto.

Lo que quiero explicar, es que por mi parte la premisa de un lenguaje como PHP me "descalifica totalmente del proyecto"; Me autodescalifoco yo, porque considero (yo mismo) que sería una "carga" para ese proyecto.

[mamcx]

(Perdona dec, me emocione con Katana!)

Ups, confundi a marcos con dec. Ultimamente estoy con lios de identificacion!

Titulo:

Katana Web system: La plataforma de creacion de sitios Web asesina.

Problema a resolver:

EL problema *nuke: Sitios "encajonados" dificiles de diseñar. Generacion de sitios que no se conforman a estandares Web. Dificil editar.

Como se puede resolver

Con un CMS que tenga nula interferencia con el diseño y que solo genere codigo (x)html valido.

Mercado objetivo:

Diseñadores Web (adivinen porque)

Ejemplos de ideas similares:

Se propuso WordPress. Muy cerca.

WordPress es casi THE KILLER, pero no el mercado Latino, creo....

Tareas a desarrollar

De tarea....

ES ASESINA PORQUE:

- Sera mas facil actualizar contenido
- Los diseñadores tendran libertad total

Porque es buen negocio hacerlo.

Porque si atraemos a los mejores diseñadores, atraemos los mejores clientes.

[roman]

¡Válgame! ¡Cuánta contradicción!

[dec]

Hola,


¡Válgame! ¡Cuánta contradicción!


Je, je, je, je... ¡Noooooo! :D :D :D

[Ñuño Martínez]

A ver si lo he entendido bien:

Katana Web System (supongo que el nombre puede cambiar ;)) es una aplicación que permitirá diseñar y gestionar sitios web con facilidad. ¿Lo he pillado? ¿No?

Yo estuve a punto de hacer algo, ejem... parecido en PHP puro y duro, pero lo dejé pasar. Entre otras cosas, ya hay alternativas: Quanta+ (http://quanta.kdewebdev.org/) o Bluefish Editor (http://bluefish.openoffice.nl/index.html). Claro que yo nunca he usado WordPress y tal vez esté metiendo la pata hasta el fondo...

[mamcx]

Es la idea.

Ahora, la trampa aqui es el mercado objetivo. Denle una vuelta a los mejores diseñadores web y a los mejores diseños, ganadores de premios. Noten que casi ninguno usa una herramienta asi. Preguntense porque, si hay como 2000 de ellas. Miren que efectivamente, algunos si usan WordPress. Analicen que ninguno usa *nuke.

Ahora, necesitamos un diseñador web bueno, que nos diga que lo que estamos haciendo esta bien.

[mamcx]

Reiterando una idea anterior:

Titulo:

Servatana communicator: Lo que correo debio ser.

Problema a resolver:

Correo. Comunicacion entre usuarios PRIVADA y SEGURA.

Como se puede resolver

Los estudios muestran que muchos usuarios prefieren un progrma IM como messenger y que entre los jovenes estadounidenses ya se usan mas las web sociales que el correo tradicional.

Creando una infraestructura que reutiliza la tecnologia actual pero que extrae lo mejor de cada una.

RSS + SSL + Semi-Foro + Centralizado + Web2.0 + Gateway de recepcion de correos (importante hacer puente con sistemas legados) + Integracion con sistemas de almacenamiento remoto.

Mercado objetivo:

PYMES. Una alternativa a usar messenger + correo + exchange + outlook + .... que estan separados y que el flujo de trabajo es muy improductivo.

Estudios muestran que estas tecnologias han reducido notablemente la eficiencia y generan millones de dolares en perdidas...

Ejemplos de ideas similares:

http://www.basecamphq.com/

Es muy buen concepto. Son MINI apliaciones, una para cada cosa, pero en conjunto la idea que expongo.

Quizas se pueda reducir aun mas y seguir el ejemplo de ellos. Liberar por etapas.

Tareas a desarrollar

1- Un servicio centralizado
2- Gateways SMTP + Defensa anti-spam de este gateway + comunicacion SSL + ID unicos de cada cliente. No hay anonimato
3- Brutalmente simple interface de usuario.
4- Superfacil hacer parte del sistema y tambien *salirse de el*
5- Explorar si es posible hacer un gateway de messenger
6- Exportador/importador de mails a sistemas legados, como exchange, dominio om outlook
7- Interface Web2.0
8- Un semi-messenger para instalar en el cliente


ES ASESINA PORQUE:

- El correo nos tiene enloquecidos
- Mayor privacidad, seguridad y fluidez al combinar multiples servicios en uno

Porque es buen negocio hacerlo.

Porque puede ser convincente para las empresas la idea.

[Ñuño Martínez]

La idea de pequeños programas que trabajan conjuntamente me gusta. De hecho, mi opinión es que todas las aplicaciones deberían hacerse de esa forma.

Lo de un cliente de mensajería también me gusta. Ahora estoy usando GAIM (MSN y Yahoo! Messenger) y para correo utilizo SquirrelMail, que no está mal pero me mata con lo del SPAM y que no me marca como "no leídos" los mensajes que no estén en la bandeja de entrada...

Yo también voy a aportar mi propio proyecto:

Titulo:

Salamanca desktop.

Problema a resolver:

Aulas informáticas en colegios. Este año estuve como monitor en una y existían numerosos problemas:

Respecto a los usuarios, especialmente niños pero vale para cualquier usuario con poca experiencia,
Les cuesta comprender el concepto de rendimiento, es decir, cómo afecta lo que hace el usuario a la velocidad del ordenador. En especial, los niños tienden a ser impacientes y pulsan los botones o los iconos varias veces si no hay una reacción inmediata, abriendo así varias instancias (ventanas) del mismo programa, haciendo que vaya aún más lento, haciendo que estén más impacientes, así que pulsan más veces... Es la pescadilla que se muerde la cola.
Es difícil que entiendan que hay partes de la pantalla a la que no tienen acceso porque son bloqueadas por otra aplicación o por una ventana, por ejemplo, cuando aparece un mensaje de aviso o error.
No saben qué hacer cuando aparece un aviso, especialmente problemático cuando una página web solicita que se instale un plug-in...
Guardan una cosa (documentos, imágenes) y luego no pueden encontrarla, no borran lo que no necesitan...Respecto a administrador, incluso el experimentado,
Es difícil mantener todos los ordenadores con sus programas.
Es difícil mantener todos los ordenadores sanos. Incluso es difícil programar una hora para una tarea. Varias veces dejaba a los ordenadores buscando errores en el disco de datos y ha aparecido algún profesor que necesitaba urgentemente utilizar uno de ellos...
Es difícil saber dónde está el problema y quién lo estropeó, ya que todo el mundo mete mano: alumnos, profesores, técnicos... todos quieren instalar su programa, configurar el ordenador a su gusto, guardar sus datos ellos puedan encontrarlos, que nadie toque sus cosas...
Como se puede resolver

La idea que tenía era crear un sistema basado en cliente/servidor en el que el servidor (profesor o monitor del aula de informática) mantiene los usuarios y los programas que están instalados. Los programas se instalan y configuran en el servidor y este lo propaga en los clientes durante el encendido. El servidor también tendrá acceso a lo que están haciendo los clientes, incluso podrá intervenir para evitar actos no deseados.

Los usuarios (clientes) no tienen por qué usar siempre el mismo ordenador ya que los documentos se guardan en el servidor. El ordenador cliente hace una limpieza de sí mismo al encenderse, no al apagarse (los niños de 8 años tienden a apagar los ordenadores "a lo bruto").

Por último, que se note bien claramente qué ventanas se pueden utilizar y cuales no. Para ello veo dos soluciones:
Sólo una aplicación puede estar activa en cada momento. Algo al estilo PalmOS, en la que sólo puedes acceder a una de las aplicaciones porque ocupan toda lapantalla.
Sombrear las las ventanas inactivas, dejándolas en penumbra (o transparentes) en lugar de cambiar sólo el color de la barra de título.

Mercado objetivo:

Colegios, cyber, aulas informáticas en general...

Ejemplos de ideas similares:

No conozco ninguna, ni comercial ni gratuita.

Tareas a desarrollar

Pensado así, a lo bruto, casi habría que crear un sistema operativo... Tengo un documento por aquí con lo que pensé en su día. Si el proyecto interesa puedo subirlo a la red.

ES ASESINA PORQUE:

- Se podrá enseñar y gestionar un aula informática.

Porque es buen negocio hacerlo.

Hay escuelas y centros educativos que están pidiendo uno a gritos.

Bueno, aquí esta.

[kuan-yiu]

Me recuerda terriblemente a los "terminales tontos" que usé hace un montón de años en la facultad.

[Ñuño Martínez]

Pues precisamente me inspiré en los viejos terminales COBOL que utilizaba mi padre hace cuarenta años. Creo que para el ámbito educativo es lo mejor (o casi) ya que se puede controlar mejor.

Hay que tener en cuenta que no serían ordenadores de "propósito general" por lo que no importa si se les quita algo de "inteligencia".

[mamcx]

Creo que en este caso en vez de hacer un SO seria hacer un escritorio personalizado.

Se puede hacer un shell personalizado para Windows, como atestiguan quienes hacen software para cybercafe.

O un desktop para linux. Aunque eso me parece mas asustador ;)

O algo mucho mas sencillo, una aplicacion de pantalla completa. Con sus propios iconos y ya es mas simple reposicionar ventanas al interior de esta.

Pero en ningun caso es tan simple. Ademas que requiere conocimientos de como reconfigurar (windows o linux), pero me parece posible.

[cancerbero]

Me parece una idea interezante para poder desarrollarla ademas q ayudaria al docente a poder controlar a los alumnos y podria realizar hasta un control sobre los examenes que el alumno daria para en base al desempeño del curso se pueda ver donde existen mas fallas en el aprendizaje, como un tutor inteligente, me gustaria participar del proyecto.

Cancerbero-Bolivia:rolleyes:

[Al González]

¡Hola a todos!

En términos generales, estoy de acuerdo con Mario Montoya. Pero me parece importante que lo primero a definir sean las reglas generales de participación en este ejercicio de idealización colectiva de un proyecto de software. Una vez definidas esas reglas, pedirle a los moderadores que nos auxilien para hacer que se cumplan las mismas, y proceder a definir las etapas del proceso, las cuales sugiero sean o contengan a las siguientes:

1. Definición del modelo de trabajo. ¿Cómo vamos a trabajar una vez que se defina el producto de software a desarrollar? ¿Qué metodología emplearemos? ¿DTE, Extrema, etc.? Definir la forma en que los desarrolladores de Club Delphi (o de otras comunidades Web de programación) "deben" o pueden desarrollar este tipo de aplicaciones de forma Colaborativa y a distancia. Definir el modelo de trabajo sin pensar todavía en el producto, lenguaje de programación o sistema operativo; un modelo que nos sirva para éste y muchos otros desarrollos en grupo.

2. Definición del proyecto. ¿Qué vamos a hacer?
2.1. Lluvia de ideas bajo un esquema similar al propuesto por Mario:

Nombre (título o nombre interno / temporal del proyecto de software).
Objetivo (problema a resolver).
Mecanismos (cómo se puede resolver o desarrollar algo así).
Mercado (mercado objetivo bajo cualquier clasificación pero bien definido).
Similitudes (ejemplos de otros productos similares ya existentes en el mismo mercado definido anteriormente).
Ventajas y desventajas (puntos a favor y en contra del nuevo producto en comparación con otros similares, y otras razones de peso que se deban considerar como importantes factores de riesgo u oportunidad).
Tecnologías (herramientas, lenguajes y bibliotecas de programación sugeridas o necesarias para el desarrollo de ese producto).

2.2. Votación de las ideas planteadas y determinación del producto de software a desarrollar.

3. Formación del equipo. Convocatoria para la integración del equipo de trabajo. Determinación de las áreas del proyecto que cada participante cubrirá en base a sus habilidades, disposición, interés, experiencia y gusto.

4. Análisis preliminar. Análisis general previo al desarrollo para confirmar la viabilidad del proyecto y poder estimar el tiempo y otros recursos necesarios para su desarrollo.

5. Estimación de costos. Análisis y determinación del tiempo necesario para el desarrollo del proyecto. Basado en la cantidad de horas que cada participante estime para cada una de las tareas que se le asignen, y considerando que en este caso se tratará de un desarrollo cooperativo donde no hay pago directo de honorarios.

6. Calendarización. Elaboración del calendario desglosado del proyecto, estableciendo las fechas de entrega para cada parte en que se divida el mismo (ejemplo: Juan necesita seis horas para el diseño visual de la pantalla de registro de usuarios, lo iniciará el 5 de septiembre y lo entregará el día 11).

Agradecería a los presentes que me ayudaran a mejorar el esquema que propongo, y que no se propongan más ideas de productos antes de dejar definido el esquema. Preparar la cancha antes de jugar en ella.

Un abrazo organizado.

Al González. :)

[jorge1987]

A mi me parece que si va a ser una app que promocione a los users de "ClubDelphi", es mas que ovio, que tiene que estar desarrollada en Delphi, y sino, creamos www.clublazarus.com, y la hacemos en lazarus ( quien pueda, ja ).

Saludos :D:D

[mamcx]

No indipensablemente.

Es por eso que la eleccion de herramienta no puede ir al principio, porque si no estan los requerimientos no se sabe que se va a hacer.

Sin embargo si seria una eleccion obvia Delphi, siendo este el clubdelphi, no necesariamente seria la unica opcion. Podria ser que la solucion requiera un hibrido entre cliente nativo y servicios de internet, o incorporar lenguaje de scripting como python o algo asi.

[jorge1987]

Bueno eso es cierto, entonses lo dejamos para despues, entonses, en que quedamos, que aplicacion vamos a intentar hacerla volar?

Saludos :D:D

[Ñuño Martínez]

Como ha dicho Al Gonzalez, con el que estoy completamente de acuerdo, primero habrá que definir el modelo de trabajo. Si no hay objeciones, querría ser el primero en hacer una proposición.

Supongo que será un proyecto de código abierto y de libre distribución, al estilo GPL (por cierto, que yo tengo una licencia adaptada a la legislación europea aprobada por un abogado, pueden echarla un vistazo aquí (http://www.burdjia.com/negocio/licencias/)).

En estos casos se suelen utilizar dos modelos de gestión, la cátedra y el bazar. Brevemente:
En la cátedra hay uno o varios administradores que se encargan de dirigir el proyecto. Estos administradores son los que deciden todo: cómo será el proyecto, quién trabajará en él, qué tareas realizará cada colaborador, qué calendario se seguirá... Sus decisiones pueden ser más o menos dictatoriales, pero nadie que no pertenezca al grupo de catedráticos tiene poder de decisión. Un ejemplo de cátedra es el proyecto Open Office (http://www.openoffice.org/).
El bazar es casi opuesto: existe uno o varios administradores, pero estos se limitan a recibir las colaboraciones y a montarlas dentro del proyecto. No suelen existir pautas respecto a cual será la evolución futura del proyecto y vale casi todo, siempre que entre dentro de las características básicas del proyecto. Un ejemplo de bazar es el proyecto Allegro (http://alleg.sourceforge.net/).
Seguro que pueden completarse estas definiciones, pero creo que sirven para hacerse una idea.

Una buena estrategia suele ser empezar con un modelo de cátedra y más adelante, cuando el proyecto ha madurado y existen varias versiones estables, se puede abrir más hacia el modelo bazar sin miedo ya que esa madurez hará que el proyecto crezca con una guía mínima.

Esta es mi opinión.

[EDIT]Hay veces que corro demasiado, y creo que esta es una de esas ocasiones...

[Casimiro Notevi]

Como ha dicho Al Gonzalez, con el que estoy completamente de acuerdo, primero habrá que definir el modelo de trabajo. Si no hay objeciones, querría ser el primero en hacer una proposición.

Supongo que será un proyecto de código abierto y de libre distribución, al estilo GPL (por cierto, que yo tengo una licencia adaptada a la legislación europea aprobada por un abogado, pueden echarla un vistazo aquí (http://www.burdjia.com/negocio/licencias/)).

En estos casos se suelen utilizar dos modelos de gestión, la cátedra y el bazar. Brevemente:
En la cátedra hay uno o varios administradores que se encargan de dirigir el proyecto. Estos administradores son los que deciden todo: cómo será el proyecto, quién trabajará en él, qué tareas realizará cada colaborador, qué calendario se seguirá... Sus decisiones pueden ser más o menos dictatoriales, pero nadie que no pertenezca al grupo de catedráticos tiene poder de decisión. Un ejemplo de cátedra es el proyecto Open Office (http://www.openoffice.org/).
El bazar es casi opuesto: existe uno o varios administradores, pero estos se limitan a recibir las colaboraciones y a montarlas dentro del proyecto. No suelen existir pautas respecto a cual será la evolución futura del proyecto y vale casi todo, siempre que entre dentro de las características básicas del proyecto. Un ejemplo de bazar es el proyecto Allegro (http://alleg.sourceforge.net/).Seguro que pueden completarse estas definiciones, pero creo que sirven para hacerse una idea.

Una buena estrategia suele ser empezar con un modelo de cátedra y más adelante, cuando el proyecto ha madurado y existen varias versiones estables, se puede abrir más hacia el modelo bazar sin miedo ya que esa madurez hará que el proyecto crezca con una guía mínima.

Esta es mi opinión.

[EDIT]Hay veces que corro demasiado, y creo que esta es una de esas ocasiones...


:confused::confused::confused: La Catedral y el Bazar (http://biblioweb.sindominio.net/telematica/catedral.html), de Eric. S. Raymond :confused::confused::confused:

[jorge1987]

Como ha dicho Al Gonzalez, con el que estoy completamente de acuerdo, primero habrá que definir el modelo de trabajo. Si no hay objeciones, querría ser el primero en hacer una proposición.

Supongo que será un proyecto de código abierto y de libre distribución, al estilo GPL (por cierto, que yo tengo una licencia adaptada a la legislación europea aprobada por un abogado, pueden echarla un vistazo aquí (http://www.burdjia.com/negocio/licencias/)).

En estos casos se suelen utilizar dos modelos de gestión, la cátedra y el bazar. Brevemente:
En la cátedra hay uno o varios administradores que se encargan de dirigir el proyecto. Estos administradores son los que deciden todo: cómo será el proyecto, quién trabajará en él, qué tareas realizará cada colaborador, qué calendario se seguirá... Sus decisiones pueden ser más o menos dictatoriales, pero nadie que no pertenezca al grupo de catedráticos tiene poder de decisión. Un ejemplo de cátedra es el proyecto Open Office (http://www.openoffice.org/).
El bazar es casi opuesto: existe uno o varios administradores, pero estos se limitan a recibir las colaboraciones y a montarlas dentro del proyecto. No suelen existir pautas respecto a cual será la evolución futura del proyecto y vale casi todo, siempre que entre dentro de las características básicas del proyecto. Un ejemplo de bazar es el proyecto Allegro (http://alleg.sourceforge.net/).
Seguro que pueden completarse estas definiciones, pero creo que sirven para hacerse una idea.

Una buena estrategia suele ser empezar con un modelo de cátedra y más adelante, cuando el proyecto ha madurado y existen varias versiones estables, se puede abrir más hacia el modelo bazar sin miedo ya que esa madurez hará que el proyecto crezca con una guía mínima.

Esta es mi opinión.

[EDIT]Hay veces que corro demasiado, y creo que esta es una de esas ocasiones...


Si tengo que analizar los ejemplos utilizados, a mi me parece que el modelo de OpenOffice es un buen modelo, nose ustedes, espero mas comentarios al respecto.

Saludos :D:D

[Al González]

¡Hola a todos!

Mis colaboradores y yo actualmente experimentamos con un modelo llamado DTE. Aquí algo que publiqué al respecto el año pasado:

http://www.clubdelphi.com/foros/showthread.php?t=25463

Ojalá se retome también ese hilo, porque realmente pienso que la Red Colaborativa DTE sería algo muy bueno para todos.

Y aunque el esquema DTE aún está en proceso de maduración, creo que por ser el planteado un proyecto sin altas presiones económicas o de tiempo, podríamos darnos el lujo de probarlo en él.

Un abrazo distribuido.

Al González. :)

[Ñuño Martínez]

No he leído tu artículo entero, sólo las dos primeras partes, pero me parece algo realmente interesante y que, de imponerse en España, me ayudaría mucho a encontrar trabajo (¿Por qué es tan difícil que los empresarios entiendan que soy el mejor? :D).

Por ahora estoy completamente de acuerdo con ese sistema de distribución del trabajo, y no es incompatible (a mi parecer) con el sistema "Cátedra" y aún menos con el "Bazar" de los que hablé antes.

Me sentiría realmente orgulloso por colaborar en un proyecto así, que podría derivar en un producto y un paradigma revolucionarios... :cool:

[jorge1987]

Y, en que quedamos?

Saludos :D:D

[Ñuño Martínez]

Yo voy a estar desconectado durante 10 días en un pueblo a decenas de kilómetros del ordenador más cercano (BIEEEEEEEEEEEN:D), pero quiero que sepan que esto me interesa así que cuenten con migo si llegan a alguna conclusión en este tiempo.

[Al González]

¡Hola a todos!

...No he leído tu artículo entero, sólo las dos primeras partes, pero me parece algo realmente interesante...
Gracias por el comentario, pero creo que te has perdido de la mejor parte (la Red Colaborativa).

Por cierto, si alguien quiere publicar mi artículo en su Web, siéntase con la libertad de solicitarme el texto original.

Anoche estuve pensando que sería conveniente revisar la organización de las especialidades ahí propuestas. Después de haber ganado algo de experiencia en este experimental modelo, creo que sería adecuado colocar PO (la programación escrita para las interfaces de usuario), PB y PL —Programación de Lógica de negocios (nueva)— como subespecialidades de una nueva especialidad abreviada como "PR" (Programación). Y considerar RE como parte de DO (diseño visual de las interfaces de usuario), o sea, no mutuamente exclusivas. En cuanto a MD aún tengo mis dudas de si debe aparecer o dónde debe ir, ya que todavía no he puesto en práctica esa especialidad de manera formal, aislada o explícita.

Algo que me faltó agregar en mi propuesta hecha en este hilo (sobre el esquema de trabajo), es que también es importante definir la normativa de desarrollo, es decir, las reglas de estándares, estilos, nomenclaturas y demás que deberán seguirse durante el desarrollo del software, para no sólo trabajar bajo el mismo lenguaje sino también hablar el mismo idioma. Este asunto suele generar polémica cuando existe demasiado apego u obstinación a la manera de programar de cada uno, y para mí es uno de los parámetros clave que determina si una persona tiene o no facilidad para integrarse al trabajo en equipo; si antepone o no los objetivos del grupo a sus gustos personales.

En resumen, reiterando mi propuesta y, claro, si la mayoría de los interesados están de acuerdo, definamos el esquema general de trabajo y luego el proyecto de software.

Un abrazo esperando comentarios.

Al González. :)

[Casimiro Notevi]

¡Hola a todos!


Gracias por el comentario, pero creo que te has perdido de la mejor parte (la Red Colaborativa).

Por cierto, si alguien quiere publicar mi artículo en su Web, siéntase con la libertad de solicitarme el texto original.

Anoche estuve pensando que sería conveniente revisar la organización de las especialidades ahí propuestas. Después de haber ganado algo de experiencia en este experimental modelo, creo que sería adecuado colocar PO (la programación escrita para las interfaces de usuario), PB y PL —Programación de Lógica de negocios (nueva)— como subespecialidades de una nueva especialidad abreviada como "PR" (Programación). Y considerar RE como parte de DO (diseño visual de las interfaces de usuario), o sea, no mutuamente exclusivas. En cuanto a MD aún tengo mis dudas de si debe aparecer o dónde debe ir, ya que todavía no he puesto en práctica esa especialidad de manera formal, aislada o explícita.

Algo que me faltó agregar en mi propuesta hecha en este hilo (sobre el esquema de trabajo), es que también es importante definir lanormativa de desarrollo , es decir, las reglas de estándares, estilos, nomenclaturas y demás que deberán seguirse durante el desarrollo del software, para no sólo trabajar bajo el mismo lenguaje sino también hablar el mismo idioma. Este asunto suele generar polémica cuando existe demasiado apego u obstinación a la manera de programar de cada uno, y para mí es uno de los parámetros clave que determina si una persona tiene o no facilidad para integrarse al trabajo en equipo; si antepone o no los objetivos del grupo a sus gustos personales.

En resumen, reiterando mi propuesta y, claro, si la mayoría de los interesados están de acuerdo, definamos el esquema general de trabajo y luego el proyecto de software.

Un abrazo esperando comentarios.

Al González. :)

Eso es algo esencial, es lo primero que hago cuando inicio un nuevo proyecto: entregar a cada uno un documento con las normas a seguir para la nomenclatura de todos los datos. Y si cualquier parte no cumple esa norma, no pasa al proyecto final hasta que haya sido corregida.
De esta forma, el código se hace facilmente comprensible para cualquier persona que participa en el proyecto, casi como si fuese su propio código (siempre hay pequeñas diferencias sin importancia.

[xander]

Aqui por lo que he visto todo mundo habla de sistemas de gestión y Delphi, entonces hagan un sistema de gestión de facturas, pedidos y esas yerbas que use multimonedas, multi-impuestos, que este hecho en Delphi y que funcione en la Web... listo ahi tienen el proyecto.

En muchas cosas de esas hay expertos aqui

[mamcx]

Como ya expuse, el problema de ese tipo de proyectos es que demanda un mayor personal NO programador, sino soporte tecnico, contadores, ventas, etc...

Ademas, que precisamente: Es muy tipico. Y muy especifico, no es nada facil lograr que un sistema de gestion se acomode a cada legislacion y pais y mantenerlo al pie con ellas.

Sin embargo, veo que han sido pocas las ideas... abran su mente!

[xander]

en todos los proyectos necesitas dar soporte, los usuarios son re-buenos para hacer estupideces, la parte de contabilidad y ventas la conocen los programadores que son quienes precisamente han hecho las aplicaciones para estas áreas... igual se podría hacer una encuesta para ver quienes de los que estan dispuestos a entrarle le conocen a estos rollos. Sin meterse con las legislaciones de cada pais se podría limitar a manejar lo que es común en todos... por ejemplo es común que cada quien quiera manejar sus inventarios con tal o cual modelo de inventarios.... llevar el control de las entradas y salidas, ventas, costos, sistemas de costeo y proyecciones... es lo común de lo que todo mundo habla y lo que cada quien anda siempre haciendo por su cuenta.

Siempre todos los sistemas se tratan de contar y sumar... generalmente no se sale de ahí... eso es toda la gestión... reportear cuantos y cuanto de esto y aquello... yo sigo viendo que esa sería una buena aplicación para empezar

[Casimiro Notevi]

en todos los proyectos necesitas dar soporte, los usuarios son re-buenos para hacer estupideces, la parte de contabilidad y ventas la conocen los programadores que son quienes precisamente han hecho las aplicaciones para estas áreas... igual se podría hacer una encuesta para ver quienes de los que estan dispuestos a entrarle le conocen a estos rollos. Sin meterse con las legislaciones de cada pais se podría limitar a manejar lo que es común en todos... por ejemplo es común que cada quien quiera manejar sus inventarios con tal o cual modelo de inventarios.... llevar el control de las entradas y salidas, ventas, costos, sistemas de costeo y proyecciones... es lo común de lo que todo mundo habla y lo que cada quien anda siempre haciendo por su cuenta.

Siempre todos los sistemas se tratan de contar y sumar... generalmente no se sale de ahí... eso es toda la gestión... reportear cuantos y cuanto de esto y aquello... yo sigo viendo que esa sería una buena aplicación para empezar

Pues yo creo que se debería hacer algo más "especial", diferente, algo que llame la atención y no una simple facturación.

Aunque tampoco quiero hablar demasiado porque quién sabe si luego no puedo participar porque no tenga conocimientos en lo que se vaya a hacer.

[jorge1987]

Pues yo creo que se debería hacer algo más "especial", diferente, algo que llame la atención y no una simple facturación.

Aunque tampoco quiero hablar demasiado porque quién sabe si luego no puedo participar porque no tenga conocimientos en lo que se vaya a hacer.

Claro, osea algo orientado a mostrarselo al mundo, y que sepan que clubdelphi esta ahi, no algo que solo usen las empresas, o los que programan ERPs, o algo por estilo.

Nose, no se me ocurre algo que podriamos hacer ahora, pero estoy pensando, pero lo que estoy seguro, es que ami no me parece viable, un proyecto de software de gestion, para hacer el clubdelphi kiler application.

Saludos :D:D

[Sick boy]

Hola a todos,

Pues yo creo que se debería hacer algo más "especial", diferente, algo que llame la atención y no una simple facturación.
Yo también apuesto por algo "especial" en lugar de un TPV (que por otro lado quitaría el pan a muchas pequeñas empresas).

Quieren algo especial y deslumbrante?? Apuesten por la inteligencia artificial.

Desde que aprendí SQL siempre he tenido la idea de que se puede hacer cualquier cosa, y que la capacidad para acumular y gestionar datos es asombrosa. El problema del SQL es que un usuario "tipico" no es capaz de utilizarlo, la sintaxis es estricta, y es fácil cometer errores.

Las interfaces de bases de datos se limitan a filtros, groups y order by, aun no he visto ninguna que construya sentencias SQL personalizadas en función de lo que el usuario necesite.

Se que lo que voy a proponer es largo y complejo, pero también es revolucionario y sorprendente.

Propongo un gestor de información que "hable" con el usuario, y devuelva la información que necesite.
Quizas alguien conoció a HERBIE, un programa de MSDOS que podía mantener pseudoconversaciones con el usuario. Almacenaba la información de esas conversaciones y después intentaba ser coherente.

La idea del sistema sería construir una nueva capa para el SQL, con un parseador sintactico configurable para diferentes idiomas, donde las palabras claves son dinamicas y definibles por el usuario.
De este modo es usuario puede teclear:
El telefono de luis es 900 100 200 100.
El sistema localiza "telefono" como un campo perteneciente a las tablas "amigos", "contactos", "trabajo" y pregunta al usuario:
Luis es un amigo, un contacto o un trabajo.
Cuando el usuario responde el sistema añade el dato a la tabla correspondiente.
Mas adelante el usuario necesita el dato y teclea:
Dame el telefono de luis
Y el sistema lo busca por todas las tablas y devuelve la información.

Este es un ejemplo muy básico, solo para que se vea un poco la idea.
El projecto final sería capaz de hacer busquedas mucho más complejas, crear las bases de datos que necesite, añadir nuevos campos, indexar imagenes y textos, etc...
El sistema debe poder aprender de las costumbres del usuario, e intentar ofrecerle la respuesta con el minimo espuerzo y las minimas preguntas. también debe poder aprender palabras claves para "atajos", recordar las consultas más usadas, ejecutar consultas periodicas o al iniciar la aplicación, etc...

Sería el gestor de información definitivo, intuitivo para el usuario final, sin tener que montar un sistema de asistencia o mantenimiento (salvo actualizaciones) y con capacidad para gestionar una gran cantidad de datos.

Y pensando a lo grande, usuarios de todo el mundo podrían intercambiar o publicar sus tablas con datos muy especificos. Por ejemplo, despieces de motores, almanaques, vademecums, etc... en general, cualquier cosa que ahora se pasa en hojas de excell o tablas access.

Si alguien esta interesado, tengo muchas más ideas sobre este tema, mucho más elaboradas de las que he expuesto aquí, asi que solo tienen que expresar su interes en este post y continuaré añadiendo sugerencias.

También he sopesado las contras, las soluciones a las contras y gran cantidad de inconvenientes, pero todos se pueden resolver con trabajo y tiempo (algo de lo que no dispongo lo suficiente como para desarrollar este proyecto yo solo).

Para el trabajo propongo Delphi y Firebird, ambos tienen lo necesario para este proyecto. Bueno, a FB le falta el "full text search" que sería muy interesante, pero se puede intentar suplir de algun modo.

Si has leido hasta aquí te doy las gracias, jejejeje, espero que alguien este interesado.

[Neftali [Germán.Estévez]]

Eso es algo esencial, es lo primero que hago cuando inicio un nuevo proyecto: entregar a cada uno un documento con las normas a seguir para la nomenclatura de todos los datos.

No se si lo sabéis, supongo que sí; Pero comentaros que hay un documento de Borland sobre estandard de programación (estilos de ódigo, nomenclaturas, espacios, comentarios,...); Lo digo porque así nadie "impone" su estilo propio.
Link (http://community.borland.com/article/0,1410,10280,00.html).

Basándose en ese documento hay un formateador de código de la Jedi (http://jedicodeformat.sourceforge.net/).

Y por Internet se puede encontrar algun otro gratuíto; Este en concreto (http://www.dow.wau.nl/aew/DelForExp.html) funciona bastante bien (yo lo uso) y es configurable; Para los que nos interesa variar alguna de las premisas estandard que se definen.

[Casimiro Notevi]

No se si lo sabéis, supongo que sí; Pero comentaros que hay un documento de Borland sobre estandard de programación (estilos de ódigo, nomenclaturas, espacios, comentarios,...); Lo digo porque así nadie "impone" su estilo propio.
Link (http://community.borland.com/article/0,1410,10280,00.html).

Basándose en ese documento hay un formateador de código de la Jedi (http://jedicodeformat.sourceforge.net/).

Y por Internet se puede encontrar algun otro gratuíto; Este en concreto (http://www.dow.wau.nl/aew/DelForExp.html) funciona bastante bien (yo lo uso) y es configurable; Para los que nos interesa variar alguna de las premisas estandard que se definen.

Tranquilo, no voy a imponer nada porque tampoco voy a ser el jefe del proyecto, eso es seguro :)

[Neftali [Germán.Estévez]]

...no voy a imponer nada porque tampoco voy a ser el jefe del proyecto
No me refería a tí, Casimiro; Me refería en una forma genérica a todos nosotros; Cada uno tenemos nuestro estilo y nuestras manías (por ejemplo, a mi me gusta poner el then..begin en la misma línea -aunque el documento de Borland diga lo contrario-).

Me pareció que una forma de no dicidirnos por la de nadie (ni de que alguien deba hacer ese documento) es escoger una ya existente.

Disculpa si me expliqué mal.

[Casimiro Notevi]

No me refería a tí, Casimiro; Me refería en una forma genérica a todos nosotros; Cada uno tenemos nuestro estilo y nuestras manías (por ejemplo, a mi me gusta poner el then..begin en la misma línea -aunque el documento de Borland diga lo contrario-).

Me pareció que una forma de no dicidirnos por la de nadie (ni de que alguien deba hacer ese documento) es escoger una ya existente.

Disculpa si me expliqué mal.

Ya supose que no te referías a mí :)

[jorge1987]

Bueno, quedamos estancados otra vez, alguna idea para el proyecto, o esta agonizante y a punto de morir?

Saludos :D:D

[Sick boy]

Bueno, quedamos estancados otra vez, alguna idea para el proyecto, o esta agonizante y a punto de morir?
En mi opinión, el proyecto descansa en paz :eek:

Hace cuatro días que expuse una idea, y ni un triste comentario, ni bueno ni malo.

Además, el forero que inició el hilo acaba de hacer una convocatoria para volcarse con otro proyecto, MUTIS (que es muy interesante), dando a entender (en mi opinión) que ya no interesa lo que pueda salir de este hilo.

saludos

[Casimiro Notevi]

Creo que debemos (los que tengamos, que no es mi caso de momento) dar ideas, más ideas, más ideas...

Además hay que tener en cuenta que estamos en agosto, que hay muchos de vacaciones, que está todo un poco "enlentecido".

Lo de "mutis" está muy interesante, aunque no es un proyecto para "cualquiera"

[mamcx]

No se preocupen con lo de MUTIS, de hecho soy yo el que me preocupa: Lo arranque hace mas de un año y *apenas* tengo una beta seudo-decente.

No solo MUTIS es lo que estoy trabajando, tengo otros proyectos que giraran alrededor de el.

Pero no compara. MUTIS es una libreria, no una aplicacion. Y yo quiero un APLICACION, una libreria es algo aburrido que hacen programadores para luego hacer cosas interesantes.

Lo que pasa con este hilo, es que nos alejamos del eje principal: Generar ideas y nos vamos por otras cosas, lo cual no esta mal, pero quizas distrae un poco.

Pero no dejen que muera. Aqui se expusieron ideas buenas... y como todo, a veces hasta la idea mas estupida (como la pagina del millon de dolares) puede mejorarse con una excelente ejecucion.

Sacar ideas es la mejor forma de hacer algo, porque nos invita a soñar.

[mamcx]

sickboy yo se que la idea de meterle "IA" suena interesante, pero hay que pensar muy bien que tipo de IA.

Como expuse en un post en mi blog

http://www.solucionesvulcano.com/blog/2006/03/jugo-de-naranja-sabor-artificial.html

La IA no es algo artificial que es inteligente, sino algo que por mecanismos artificiales (a lo magico) *parece* como si lo fuera. La IA es algo muy tramposo y puede terminar pareciendo muy estupido (por ejemplo, el asistente de Office).

Por otro lado, bien usada puede terminar interesante, como en el caso de los filtros de SPAM. El punto, que he aprendido con MUTIS, es que procesar texto libre es una tarea endemoniada.

Pero no pierdas esperanza! Para el sitio de www.paradondevamos.com (no esta completo, sean misericordiosos!) estoy armando un webbot de messenger que funciona como una operadora telefonica, lo que pasa es que muy "tonto" y hasta que no tenga un sabor a naranja artificial no lo saco.

Pero me suena la idea. Trabajala mas, reducelo a algo simple y como se puede ejecutar.

[Sick boy]

Pero me suena la idea. Trabajala mas, reducelo a algo simple y como se puede ejecutar.
La tengo trabajada, y le he dado muchas vueltas.
Se los pros y los contras, y también se como ejecutarla, aunque es un trabajo largo.

sino algo que por mecanismos artificiales (a lo magico) *parece* como si lo fuera
Evidente, los PCs no piensan. Y la magia no existe, pero que no se entere nadie :p

Se necesitaria un analizador sintactico, como el que utilizan los compiladores, o los IDEs.

Reducir la idea:
Realizar un gestor de información que cree y gestione las bases de datos utilizando expresiones "reales" en lugar de SQL, y que tenga la capacidad de aprender nuevas expresiones del usuario y devolverle la información como a él le gusta.

Solo espero que alguien me diga que es una locura, o por el contrario, que lo ve viable y/o se interese un poco. No es mucho pedir.

Como ya dije anteriormente, me extenderé más si alguien se interesa, de lo contrario no voy a perder más tiempo.

[mamcx]

Hay una razon por la cual no es buena idea interfazar el SQL: Es muy estricto. Adicionalmente, las estructuras de tablas varian mucho y de acuerdo a cada desarrollo pueden tener interpretaciones diferentes. Luego esta el hecho que el idioma natural es "ambiguo" lo que complica mucho la cosa.

Pero por ejemplo, interfazando a un motor de indexacion ya es mucho mas simple. De hecho, es lo que hago con el webbot: Tengo una serie de comandos como:

carnes poblado?

y el corre una busqueda de texto libre sobre la BD. Tambien algo como

donde queda pinky?

y responde. Es mucho mas facil interfazar con un motor de busqueda porque en parte, ya hizo esta labor:

- Transformacion de texto es tokens
- Generacion de ranking
- Habilidad de ejecutar consultas de texto libre, booleans, fuzzy, rangos, etc...
- tokenizacion de la consulta

y muchas labores mas.

Lo que digo es que algo como askjeeves es mucho mas realizable y practico para el usuario final.

Por ultimo, no hay necesidad de olvidar la BD. Es muy habitual indexar los registros y guardar el ID de la BD, tonces, luego de la busqueda se hace un merge de la informacion contra la BD y se recupera mas informacion.

[Sick boy]

OK, entendido.

[AzidRain]

He estado leyendo con interés y precisamente hace algun tiempo traigo por ahi una idea que no he puesto en practica por no contar ni con el tiempo ni con los suficientes conociemientos de programación para un proyecto de ese tamaño.

Pues bien, se trata de un sistema de gestión para tiendas de comercio al detalle tipo autoservicio (el tamaño no importa pues debe funcionarle al que tiene una tiendita o a todo una cadena de supermercados). No se trata de un clon de alguna herramienta de ASPEL (en Mexico) o algo similar por otros lares. Este sistema permitiría al cliente controlar todos los aspectos de su negocio desde que entra la mercancía hasta que sale (por ventas, desperdicio, robo, etc.) manteniendo un estricto control de inventarios. Además el sistema le hace pedidos, controla proveedores y trabaja prácticamente solo. Unicament hay que ir atendiendo las "alertas" que genere.

Trabaje muchos años en Wal-Mart por lo que conozco perfectamente como funciona su sistema de gestión, el cual es una de las bases de su éxito aqui en America. El sistema que ocupan lo desarrollaron ellos, esta basado en varios lenguajes, pero principalmente C y COBOL (si, COBOL), corre en servidor UNIX con INFORMIX como BD. Este sistema controla desde inventarios, pedidos, pagos de facturas, caja general, etc. únicamente el POS se maneja con un sistema propietario de IBM. Cuento con material de consulta (reportes, pantallas, etc.) por si hiciera falta.

El mercado sería precisamente las PYMES ya que contarían con un sistema muy poderoso que resuelva todos sus requerimientos de software en uno solo. Mas que un software sería una solución completa.

A ver que opinan...

[Ñuño Martínez]

¡Buf! Me fuí de casa un par de semanas y ya me perdí...:confused: ¿En qué punto estamos? ¿Ya estamos eligiendo el tipo de aplicación?

[mamcx]

Bueno, creo que en resumen:

- El mercado final apunta a pymes
- La aplicacion tiene mas fuertemente componentes de escritorio


Pero no veo que haya una respuesta positiva de forma amplia a las propuestas...

[AzidRain]

Coincido en que el mercado debe ser PYMES, pues precisamente son las que más requieren de Software Open Source (aunque empresas monstruo ya estan cambiandose a este software). Ahora bien, pienso que debe basarse en componentes de escritorio debido a que si nos vamos a aplicaciones Web hay pocas opciones relacionadas con Delphi (PHP, java, etc.) a no ser .NET, pero entonces caeríamos precisamente en lo que no queremos.

Además, a reserva de lo que piensen, hay una mayor base de programadores mas o menos preparados para desarrollar apliaciones de escritorio en Delphi que aplicaciones Web (al menos en el Club).

Lo interesante de la aplicación es que igual le sirva a una pequeña empresa Argentina que a una mediana Española o Mexicana. Independientemente de la internacionalización. El ideal es que esta aplicación o mas bien suite de aplicaciones en su caso, se vuelva un standard para software Open Source, que es precisamente lo que es una "Killer App" como dice el titulo del hilo. Algo asi como SAP lo es para la gestón de empresas de producción...

Claro que parece que sería un proyecto de muchos meses y mucho trabajo, pero en estos tiempos cuantas aplicaciones respetables andan por ahi, obra de mas de uno que empezó con la misma intención del OS?

SAludos

[Casimiro Notevi]

No sé, no sé.... parece que el objetivo se está enfocando hacia la típica gestión comercial para pymes y eso no es una "killer application", seguro que no.

Aunque no sabría decir el qué, pero debe ser algo "especial", algo que esté poco "poblado" y que sea "necesario", aunque todavía no exista ninguna que ocupe o sobresalga en ese lugar del mercado. Algo que sea un "boom", por poner un ejemplo, aunque no quiero decir que sea algo así, es sólo un ejemplo: Surgen sitios como youtube y la gente tiene "necesidad" de descargarse los videos, entonces surge javi Moya y crea una utilidad para descargarte todos esos videos. El resultado, Javi Moya es conocido en todo el mundo y su utilidad es descargada millones de veces, su página web está casi colapsada siempre y ... él sabrá ya cómo sacar beneficio de eso, suponiendo que quiera un beneficio, puede que se conforme con el "reconocimiento".

En fin, quiero dar a entender que debe hacerse algo necesario, especial, diferente y útil para la mayoría de gentes. Y no creo que una utilidad/gestión para pymes sea algo así, a ver quién es el "guapo" que luego va a intentar vendérsela a un empresario... salvo que sea la maravilla de las maravillas, que lo veo difícil.

[mamcx]

Ok, que tal esto:


Titulo:

Tentaculos P2p. P2P seguro y sencillo

Problema a resolver:

Compartir informacion por red WAN.

Como se puede resolver

Mediante un sistema de archivos distribuidos que permita de forma simple (al igual que funciona con el Windows Explorer) poner archivos en carpetas "publicas" cerradas.

Mercado objetivo:

Pymes otra vez y usuarios remotos que trabajan con ellas.

Ejemplos de ideas similares:

http://www.shellplus.com/examples/shellplus-documents-example.html

Tareas a desarrollar [/SIZE]

1- Un servicio des-centralizado
2- Gateways Sistema archivos + FTp + Servicios en linea de backups como Amazon A9
3- Shell de windows que tenga la funcionalidad basica de mover, copiar, renombrar, etc... con sincronizacion?

Existiria algo como este esquema:

- Root
-- Seguros (Carpeta de archivos que requieren contraseña)
-- Publicos (Carpeta de archivos que son de libre acceso)
-- Remotos
--- FTP
--- Amazon A9
--- Google Drive
--- GMAIL

Ya van captando...

4- Gateways de autenticacion con la seguridad integrada de windows, active directory, bases de datos, y archivos INI de claves y usuarios

5- Puenteo a los proxies, atravesar proxy
6- Respeta configuracion de seguridad que ponga el admin de red
7- Transporte comprimido + encriptado + escaneo de virus

Pienso seria bueno tener dos versiones: La gratuita y la empresarial (que agregaria conectividad con autenticacion integrada + directorio activo) y una metodologia de plugins, o algo asi...


ES ASESINA PORQUE:

- Mandar archivos por correo es un bodrio
- Habria un transporte seguro que no requiere un servidor SFTP ni un conocimiento tecnico especial
- Permite compartir de forma simple archivos a toda la organizacion

Porque es buen negocio hacerlo.

- Porque compartir informacion es la actividad #1 en una empresa. Lo que sea que apunte a esto, es bueno...

[jorge1987]

Y por que no, una version, que sea para users comunes, que te permita intercambiar archivos con un amigo, seleccionas los archivos o carpetas a compartir, te conectas por por ej, un nombre de usuario, o por la ip, al mismo programa, que lo tiene un amigo tuyo, y se intercambian cosas, o le pasas el ultimo video que hiciste, que pesa 350 Mb, y pasarselo por el msn, seria un bodria, postearlo en youtube no se puede, llevarselo a la casa no, porque vivie muy lejos, y publicarlo en el ares o el emule, no queres, porque es algo tuyo privado.

Yo les planteo una necesidad, que hoy surge mucvho entre los adolescentes y el resto de los usuarios tambien, aun yo mismo necvesito una aplicacion asi, pero nunca eh tenido ganas de desarrollarla yo solo.

Saludos :D:D

[mamcx]

Claro, tendria una version para personas comunes... pero la idea es que ese mercado no es muy "lucrativo" no solo en terminos de plata sino de economia en general...

Y si, tambien conozco el dolor cuando mi hermano me pide le pase videos y animaciones de 3D por messenger o que las suba al ftp...

auch!

[maeyanes]

Eso que pide jorge1987 ya lo hace la última versión del messenger, con la funcionalidad de carpetas compartidas...

Saludos...

[mamcx]

Mmmm... es cierto... aunque si mas no recuerdo fue luego quitada porque a los administradores de redes no les gusto el que una aplicacion de consumidor (que no es algo muy seguro) tenga semejante caracteristica?

[maeyanes]

Pues hasta ahora la versión que vengo usando, que es la última, sigue teniendo esa funcionalidad...


Saludos...

[AzidRain]

A ver, se supone que una "killer app" no es necesariamente algo super nuevo o nunca visto, simple y llanamente debe ser una aplicacion que te resuelva el problema que tengas. No se trata de desarrollar un Messenger con esteroides o un Super navegador o algo asi...mas bien aplicaciones que resuelvan problemas actuales del usuario. Así aseguras que ese usuario se quede con tu aplicación y la promueva y si es Open Source pues con mayor razón.

Mi propuesta no es la "típica" aplicación de gestión de las cuales hay muchas efectivametne pero ninguna ha sido capaz de volverse un estandar, una PYME que quiera controlar toda su operación necesita al menos 3 aplicaciones.

Por ke digo que es un candidato a "KIller app", empecemos por cuales son los principales problemas de las empresas actuales (comerciales).

1.- La merma (mercancía que "desaparece") sin control (nadie sabe nadie supo)
2.- No contar con información confiable de desplazamientos
3.- Inventarios elevados de cosas que no se venden y muy bajos de lo que
si se vende (no hay información suficiente para hacer un pedido adecuado)
4.- Dificultad para levantar inventarios físicos (la mayoría tienen que cerrar un día completo para hacerlo, ¿Por que no hacerlo con la tienda abierta?)

y asi sucesivamente.

Creo que a pesar de que aqui la mayoría somos Ingenieros o profesionales relacionados con teconología, nuestros clientes no lo son (por eso nos contratan). No podemos diseñar pensando en lo que a nosotros nos gustaría en una aplicación, sino más bien en lo que el cliente realmente espera.

Si una aplicación:

1.- Es sencilla de operar. No hay que tomar cursos para usarlo
2.- Resuelve los problemas actuales de la empresa
3.- Permite tomar mejores decisiones
4.- Es un medio para aumentar las ganancias
5.- Me ayuda a un mejor control de los dineros
5.- Y encima...no cuesta nada

Entonces sí que es una killer app

Saludos


3.-

[mamcx]

AzidRain, la idea es buena, pero no me parece viable, en parte por lo que ya expuse sobre las razones por las cuales una aplicacion contable/erp no es buena idea.

Ademas, este tipo de aplicaciones se complica mucho, debido a las necesarias personalizaciones.

Entre otras cosas, para lograr lo que dices es necesario por ejemplo lectores de codigo de barras y otros artilugios que hacen que la parte de "no cuesta nada" se vaya diluyendo mucho.

En mi opinion, ese tipo de software le va mejor con una estructura comercial y una operacion de mercadeo normal... y aqui somos en terminos generales desarrolladores, asi que creo es mejor enfocarnos en lo que si podemos hacer muy bien y no en lo que necesitemos aprender a hacerlo bien (si te fijas postee un mensaje pidiendo ayuda por una aplicacion contable minima... hacer esto es ponernos a aprender inventarios 101 y no creo que cualquiera se le mida).

[mamcx]

Otra cosa, es bueno que recordemos que lo que sea que se haga, debe ser factible en menos <=6 meses por un equipo de unos <10 personas. La razon? los proyectos open source necesitan despegar muy rapido para ser viables y ademas, si desgasta mucho nos vamos a quedar a mitad del camino.

[jorge1987]

Dejen de pensar como empresarios, todos estan pensando software para pymes, y aca hablamos de una app killer, no de una app para comercializar, queremos hacer una app, que llegue a hacer algo como lo hacen, google, youtube, etc.. son cosas que no estan orientadas a las pymes, son cosas orientadas a todas las ramas sociales, al mundo entero, dejen de restringirse en el enfasis de pensar apps para empresas, no creo que vallamos a desarrollar un software comercial, asi dudo mucho mas, que este enfocado a las Pymes.

Bueno nose, ese es mi punto de vista.

Saludos :D:D

[Behemot]

Hola a todos

He estado siguiendo su discución por cual software desarrollar, les voy a dar una idea.
Deben empezar con un programa corto en desarrollo, pero que se vea el producto, este primero debe ser
un modulo de un programa macro. Veo que estan pensando mucho en pymes creo que por aquello de los $$$,
bueno que les parece hacer un software para pymes que maneje la documentación que entra y sale de una
empresa. p.e. caso de uso: llega una carta al contador, esta es recibida en un punto de recolección de
toda la información de la empresa, la carta es abierta y escaneada con datos adicionales tales como
remitente, fecha y hora de llegada, dirigida al usuario x (el contador), debe ser respondida (si/no),
antes de la fecha x, etc,. En la pc del contador le debe salir un aviso que tiene correspondencia, y
se manejaran controles como si la recibio, si la respondio, si tiene que mandar copia a la gerencia,
etc.
Bueno que les parece!. En fin la idea es hacer algo que resuelva problemas y les cuento que este
programa de manejo de documentos es muy atractivo a las empresas y seguramente va a tener muy buena
salida. A este modulo se le puede colgar otro por ejemplo de mensajería (intranet), otra chat entre
terminales, otra usuarios que estan activos, estos ultimos los tengo desarrollados en clipper (si soy
cliperiano y di mi salto a delphi), y tengo otras ideas de hace mucho tiempo, por ejemplo un programa
de reconocimiento de voz y un sistema experto que maneje LN (lenguaje natural) esto para las ayudas de
mis programas, incluyendo el agent de microsoft y todo esto se le puede ir añadiendo al programa de ...
llamemoslo "SISTEMA DE DOCUMENTACION Y COMUNICACION" en su sigla "SIDOCO" y despues hacemos otro modulo
que maneje voz sobre ip, etc, etc, etc, que tal les parece la idea? y seguramente ustedes ya estan
pensando en otras opciones o modulos. Este programa es aplicable a cualquier tipo de empresa. Otra idea
mas que tengo es utilizar, moviles, wireless, video conferencia. Bueno no mas por ahora. Eso si todo en
DELPHI/FIREBIRD.
Saludos,
M.R.

[mamcx]

Titulo:

ChequeaEsto, la solucion a los usuarios compulsivos!

Problema a resolver:

Al levantarme, chequeo 6 cuentas de correo y borro el 70% de los mensajes que muchos ya no son spam, otros me informan de los tickets de soporte de mis paginas y voy hacia a esas paginas a terminar de enterarme. Miro unos 8 sitios web, como el clucbdelphi. Voy a los foros de Borland y miro que hay de interesante, luego a joelonsoftware, al tiempo.com.co a saber a como esta el dolar solo como nota social.

Tengo cuentas en varios foros, tantas, que ya no se donde estoy.

Y es una jodida y tonta manera de perder 2+ horas de mi tiempo. Chequeando esto.


Como se puede resolver

Extendiendo el concepto de los feeds/RSS. La idea es que en vez de visitar cada pagina, hay un canal de noticia o feeds que puedes descargar pa' saber si vale la pena ir hasta alla.

Pero no todo tiene feeds, como el correo, y los newsgroups, y no todo se resuelve con feeds. Por ejemplo, yo quiero saber si todos los sitios de mis clientes esten vivitos y coleando. Eso es una noticia, pero no es un feed.

Propongo un sistema UNIVERSAL de noticias que mediante plugins, se pueda recibir una notificacion de lo que sea y que me ahorre al menos 1+ hora diaria.

Lo bueno de esta idea, es que es mucho mas simple de lograr: Se define un cliente basico, un contrato o interface y cada programador hace el plugin que le interese. Por ejemplo, plugin de PINGS cada 1/2 hora. Plugin de la pagina de ClubDelphi. Plugin que detecta cuando una pagina se actualiza. Lector de Feeds, etc... y se va agregando!

Mercado objetivo:

Todos nosotros. Segun datos, las empresas pierden millones y mas importante aun, YO pierdo mi tiempo en estas idioteces. Salvenmen!

Ejemplos de ideas similares:

Cientos!

- Los RSS readers
- IncrediMail, que sale un muñequito con "You have mail, sir!"
- Messenger y su molesta danza de "se conecta tal, otra vez, te llego un correo"
- Outlook, si esta abierto, notifica de eventos
- etc...

Pero ninguno UNIVERSAL.

Tareas a desarrollar


1- Una interfaze que agrupe temas de notificacion (correos, paginas, eventos, noticias, etc...). Una cosa bien bonita y bien chevere, con graficos y barras e idioteces asi. Algo lindo de ver.

2- Un conjunto de plugins que hacen solo 2 cosas:

a. Saber si hay algo nuevo
b. Informar que hay algo nuevo y donde

3- Un sistema de CALLATE. Yo no quiero una cosa que a cada movimiento este prendiendo alarmas. Mas bien, quiero algo que me de un sumario solo cuando yo lo necesite, como un informe bien chevere:

"Mira cretino esquizofrenico de la informacion: Te han llegado 70 correos y ya te mande a la basura a 27 que se que no los quieres pero eres un cobarde y no los marcas como SPAM. A proposito, del ClubDelphi ya te respondieron, y estos son los nuevos temas. 25 de tus clientes te van a llamar hoy porque tu hosting es un asco. Preparate!. El dolar esta 2.500 pesos y no vas a poder hacer nada al respecto.

En los newsgroups de Borland, asi va la cosa. La temperatura es 25 grados a la sombra. Saca la playera!

De tu outlook, acuerdate de llamar a ese tipo que esta en tu lista de aborrecidos.

Hoy compraron por la tienda otro sitio web. Un futuro cliente insatisfecho! Iepa!!!!

"

Me captan, no?

3a - Multilenguaje: A proposito, me gustaria algo que REALMENTE intentara ser gracioso. Habria un estilo serio.... o sea, ser gracioso seria otro "idioma" de la interface.

"Te llegaron 12 correos. 5 de tus amores y 3 a ponerte problema"

vs

"12 correos. 5 de tus conocidas y 3 de tus clientes"

4- Un sistema de reglas de chequeo. Por ejemplo, mail cada hora, newsgroups a mediodia. Este exacto mail recien prenda el equipo pero solo si lo prendi en la mañana.

5- Puenteo a los proxies, atravesar proxy
6- Un sistema automatizado de clasificacion como con los filtros Bayesian. Algo similar al entrenamiento de SPAM pero mas libre.

Por ejemplo, crear categorias como AMIGOS, TRABAJO, ALERTAS y que automaticamente me mande CADA evento a estas carpetas. Luego, un esquema de importancia.

Es muy importante hacer la manera de encuadrar los habitos de chequeo del usuario. Estoy hablando de gente con problemas de compulsion por la informacion como YO, gente loca. Si el condenado software no es tan compulsivo como yo, no me sirve. Por ejemplo, como ya dije, yo chequeo todo de una al prender el equipo y voy revisando unas cada 2 horas ciertas cosas.


ES ASESINA PORQUE:

- Yo pierdo mucho tiempo
- Las empresas pierden mucho dinero si yo pierdo mucho tiempo, especialmente la mia
- La mayoria de los chequeos son tontamente mecanicos

Porque es buen negocio hacerlo.

- Porque ya salimos de la era del correo y estamos en la era de multiples canales de informacion. La mayoria de esa informacion, se puede transformar en hechos noticiosos y con un buen sistema de representacion visual, en algo manejable. Con grafiquitos, eso es.

- Porque se puede extender facilmente. Por ejemplo, podemos tener el cliente gratis e ir a una empresa y ofrecer el plugin que informa a cartera cuando del sistema de facturacion alguien ya pago. Cool! no?

- Porque si es mi idea, tiene que servir!!!! :p

[seoane]

Titulo:

ChequeaEsto, la solucion a los usuarios compulsivos!


Me gusta, a esta última me apunto.

Me gusta:
Poder consultar todo de una vez sin depender de los feeds.

Los plugin. Esta me parece una grandiosa idea. Una vez creada la interface la aplicación crecerá gracias los propios usuarios, cada vez que a uno le surja una necesidad, si dispone de las habilidades necesarias, creara una solución que los demás podrán utilizar. Muchos de los software open source que andan por ahí nacieron de la necesidad de un solo programador.

Me parece una idea actual. Hoy en día cada vez se pueden ver mas aplicaciones en la red, web 2.0 lo llaman :) , estaría bien una aplicación que nos ayudara a organizar todos esos servicios.


Lo dicho, espero que esta idea prospere.

[mamcx]

Tambien me sono bastante. Primer beneficio de la meta de empezar a levantarme a las 6 a.m.!

[maeyanes]

A mi también me parece algo interesante... cualquier cosa, cuenten conmigo...

[Bicho]

Quizá estemos ante el gran proyecto sobre el que andaban buscando.

A mí tambien me parece una idea genial, una especie de recordatorio, junto con todo el correo y paginas que visitamos diariamente.

Duda que pueda sacar tiempo para apuntarme (quien sabe alomejor puedo sacar algo de tiempo cuando esté desarrollado y hacer algún plugin), pero desde aquí tienen todo mi apoyo y cualquier duda intentaré ayudar.

Saludos

[jorge1987]

Suena interesante, y es muy parecido a todos mis dias a las 6 de la mañana, al fin 1 propuesta mas que intersante, igual, no significa que sea la unica, yo le doy mi voto de fe a esta ultima, pero animo a quienes tengas mas ideas, a postearlas aqui.

Saludos :D:D

[mamcx]

Ok, que tal si para el 30 de agosto cerramos el listado de propuestas y armo una encuesta para medir preferencias?

La idea es no tener esto para siempre.

Por otro lado, no hay que olvidar que la eleccion de una opcion no elimina las otras. El solo hecho de ponerse uno a pensar en ideas es un muy buen paso y seria bueno que fuera solo un primer paso para algo mejor...

[Casimiro Notevi]

Titulo: ChequeaEsto, la solucion a los usuarios compulsivos! [...]

- Porque si es mi idea, tiene que servir!!!! :p
Muy interesante.

[nemesio]

Yo creo que ya es hora de sacar todas las propuestas en una encuesta y comenzar a votar para obtener la applicación que se va a desarrollar y comenzar con el proyecto.

Saludos

[mamcx]

Ok, lo que este entonces para el proximo lunes, se queda en la encuesta.

Asi que quienes esten indecisos, a moverse!

[jorge1987]

Ok, entonses, estoy a la espera de la encuesta.

Saludos :D:D

[Al González]

¡Hola a todos!

En términos generales, estoy de acuerdo con Mario Montoya. Pero me parece importante que lo primero a definir sean las reglas generales de participación en este ejercicio de idealización colectiva de un proyecto de software. Una vez definidas esas reglas, pedirle a los moderadores que nos auxilien para hacer que se cumplan las mismas, y proceder a definir las etapas del proceso, las cuales sugiero sean o contengan a las siguientes:

1. Definición del modelo de trabajo. ¿Cómo vamos a trabajar una vez que se defina el producto de software a desarrollar? ¿Qué metodología emplearemos? ¿DTE, Extrema, etc.? Definir la forma en que los desarrolladores de Club Delphi (o de otras comunidades Web de programación) "deben" o pueden desarrollar este tipo de aplicaciones de forma Colaborativa y a distancia. Definir el modelo de trabajo sin pensar todavía en el producto, lenguaje de programación o sistema operativo; un modelo que nos sirva para éste y muchos otros desarrollos en grupo.

2. Definición del proyecto. ¿Qué vamos a hacer?
2.1. Lluvia de ideas bajo un esquema similar al propuesto por Mario:

Nombre (título o nombre interno / temporal del proyecto de software).
Objetivo (problema a resolver).
Mecanismos (cómo se puede resolver o desarrollar algo así).
Mercado (mercado objetivo bajo cualquier clasificación pero bien definido).
Similitudes (ejemplos de otros productos similares ya existentes en el mismo mercado definido anteriormente).
Ventajas y desventajas (puntos a favor y en contra del nuevo producto en comparación con otros similares, y otras razones de peso que se deban considerar como importantes factores de riesgo u oportunidad).
Tecnologías (herramientas, lenguajes y bibliotecas de programación sugeridas o necesarias para el desarrollo de ese producto).

2.2. Votación de las ideas planteadas y determinación del producto de software a desarrollar.

3. Formación del equipo. Convocatoria para la integración del equipo de trabajo. Determinación de las áreas del proyecto que cada participante cubrirá en base a sus habilidades, disposición, interés, experiencia y gusto.

4. Análisis preliminar. Análisis general previo al desarrollo para confirmar la viabilidad del proyecto y poder estimar el tiempo y otros recursos necesarios para su desarrollo.

5. Estimación de costos. Análisis y determinación del tiempo necesario para el desarrollo del proyecto. Basado en la cantidad de horas que cada participante estime para cada una de las tareas que se le asignen, y considerando que en este caso se tratará de un desarrollo cooperativo donde no hay pago directo de honorarios.

6. Calendarización. Elaboración del calendario desglosado del proyecto, estableciendo las fechas de entrega para cada parte en que se divida el mismo (ejemplo: Juan necesita seis horas para el diseño visual de la pantalla de registro de usuarios, lo iniciará el 5 de septiembre y lo entregará el día 11).

Agradecería a los presentes que me ayudaran a mejorar el esquema que propongo, y que no se propongan más ideas de productos antes de dejar definido el esquema. Preparar la cancha antes de jugar en ella.

Un abrazo organizado.

Al González. :)

Pasaba por aquí para ver cómo va el proyecto. ;)

[Casimiro Notevi]

Es que cuando no hay tiempo... es que no hay tiempo.
Pienso que existen 3 niveles/etapas en la vida de una persona:
1. Juventud, vive en casa de tus padres
2. Trabajas, tienes que pagar vivienda, comida, ropa, servicios, etc.
3. Jubilado, con suerte, si has tenido una buena etapa 2, cobrás una pensión.

Así que llego a la conclusión de que tan sólo tienes tiempo para cosas así en la etapa 1 y en la 3. Aunque algunos afortunados tienen tiempo en la etapa 2, pero normalmente son funcionarios, empleados que trabajan medio día y tiene el resto libre, son pocos, o tienen otra afición.

Los que trabajamos para vivir, por mucho que nos duela, no tenemos tiempo para otras cosas :(.

[Ñuño Martínez]

Cinco años, jolines. Y nada. Mi único consuelo es que cada día que pasa estoy más cerca de la fase 3. Espero que cuando llegue tenga suerte.