![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
Hola a todos:
Me presento, me llamo Rubén Alcolea Zapata soy de Cuba y me dedico desde hace tres años a enseñar informática a principiantes, lo mismo enseño las cuestiones básicas de Linux, Windows que Delphi. (Pero la pasión es Delphi) Las cuestiones básicas de que hablo son las más elementales, como usar variables, los diferentes tipos ventanas, usar componentes, etc. a pesar de llevar tres años en esto me considero un princípiate ya que todos los días aprendo algo nuevo y compartir el código siempre nos dará la posibilidad de la mejoría. Es difícil que en un campo tan amplio como es la programación podamos ser expertos en todo. Es comprensible las reservas de muchos de los compañeros, pero es indudable que con independencia del nivel de conocimiento que se tenga, compartir código es provechoso a todos, sea de la manera que sea. Lo importante aquí es implementar, fijar reglas, definir una forma y procedimiento para lograrlo de manera organizada a través del club pero no limitado a este. |
|
#2
|
||||
|
||||
|
O definir un mercado...
Y un conjunto de usuarios objetivo... Formas de recibir remuneracion (ya sea economica o social o de puro orgullo, etc...) Formas de financiar la operacion... (costos basicos: Hosting, dominio, administracion de sitio web, etc...) Objetivos en documentacion, ayudas y formas de soporte.. Tipo de organizacion... Vamos a hacer un ejemplo. Como lo del sistema contable no es tan buena idea, pero es una idea conocida, hagamoslo con el: 1- Mercado: - Mercado grande: Oportunidades: NULAS. Esta cogido por Sap, PeopleSoft. Nada que ver aqui. - Mercado Empresa Mediana: Requiere un ERP: Contable, Facturacion, Nomina, Pedidos, Formas y reportes personalizados, Fuerte capacidad de integracion, Muy configurable, Requiere soporte "on site" para hacer ajustes = Una empresa de soporte, etc... Es posible, pero es muy dificil sin un musculo financiero detras nuestro. Y esta el problema que cada legislacion es diferente. En un lugar como USA; esto pega: USA es MUUUUYYY grande. Pero en paises como los nuestros? Si hacemos un equipo de Colombianos, Peruanos, Mexicanos, Venezolanos... a que legislacion le pegamos primero? * Mercado PYME: Quizas. Pero penetrar este mercado con baja tecnologia, desordenes severos en organizacion, pobre administracion... Sin embargo, es un mercado objetivo realista. Y de hecho, aqui lo de "personalizable" no es tanto. Lo brutal es en facilidad de uso. Que de paso no es un fuerte en muchos desarrolladores, a lo que va despues lo de la organizacion mas abajo... Supongamos que amanecimos dementes y elegimos a este... - Usuarios: Usuarios <> Mercado. Aqui *usuarios* es al tipo de personas que debemos CONVENCER. Pista: No es al gerente. Es al contador que maneja varias PYMES, seguido de los que manejan los POS, seguido de la secretaria.... mas o menos es asi... - Formas de remuneracion: Esto es inverso: La pregunta es: Que tantos costos queremos administrar y que tanto dinero y/o esfuerzo vamos a emplear en sufragarlos. Si no estamos hablando de dinero, sino de orgullo es lo mismo: Cuanto esfuerzo en tener un API clara vamos a soportar a cambio de poder recibir admiracion? etc... Pista: Si nos tenemos que movilizar al sitio del cliente, estamos fritos. Requiere una operacion comercial tipica. - Financiar la operacion: Lo del hosting, administracion del sitio, etc... es facil. Arrancamos en sourceforge y listo. Me preocupa es: 1- Compromiso: Quien le va a jalar 1 año en pleno a esto. 1 año es un tiempo correcto en tener un software version 1 de estas caracteristicas... Y esto es lo duro: Quien lo va a hacer con real compromiso: No que deje tirado esto a mitad del camino. Al menos debe ser 1. Y 1 persona en un sistema ERP? Ni loco. Si con un software como MUTIS que es de lo mas tecnico que me puedo imaginar es duro, no quiero saber lo que seria para mi hacer un ERP... aparte del tiempo a otros proyectos que me dan de comer, quiero decir.. Esta es la financiacion #1 en open source, creo yo 2- Mercadeo, mercadeo, mercadeo. Como lograr diseños bonitos, iconitos cheveres, anuncios en google, como promocionar el proyecto, quien visita a los entes que les puede interesar esto?, etc... El punto es que si vamos a hacer un proyecto en sourceforge donde solo lo conozcan programadores? Nada que ver aqui señores: Vendamos empanadas. * Objetivos en documentacion, ayudas y formas de soporte.. Muertos sin esto. Y mejor desde el principio. Sin documentacion y soporte, muertos en este mercado, el mediano y el grande. * Tipo de organizacion No creo que sirva un comite. Un comite es un conjunto de peludos que no deciden. Para arrancar, debe haber un proyecto ideado, pensado y estructurado por una sola mente. Creo que esto es muy dificil, pero no veo como lograr la meta de 1 año en lo que sea que se haga a punta de "preguntemosle a todos que base de datos elegir o que plataformas escogemos". No. Si se decide Oracle: Es Oracle y punto. Sin ñiñerias.Que es Firebird¿ I'm sorry lo mucho amante de MySql. No hay manera de algo realista si no se cierran las opciones y si no se eliminan caracteristicas. De mil cosas para hacer, no se pueden sino 100. Esas 100 dicen que el costo en depuracion es mas baja a menos opciones. 1 Motor de BD 1 OS 1 Lenguaje. Mas adelante si despega veremos... Y lo peor, esta mente debe conocer el mercado y debemos confiar en eso. Luego quizas un jerarquia a lo apache? Esto que acabo de hacer es mas o menos lo que se me ocurre. No quiere decir que tiene que ser asi, pero el chiste aqui es que sin: - mercado objetivo - usuarios objetivo - como financiar la operacion - estructura clara del proyecto - objetivos de mercadeo Dudo avanzemos mucho.... Obviamente, las cosas variaran mucho de acuerdo a cada punto. No es lo mismo lo que hay que hacer para mercadear lazarous (que hay que convencer a desarrolladores) que un mini-erp (que son usuarios finales), y si en unas cosas debemos ser muy fuertes (ej: mas le vale que tecnicamente lazarous sea bueno vs. mas le vale que el minierp sea facil de usar, aunque tecnicamente puede ser mas debil) y otras mas flexibles (bueno, si el peludo es un programador que lea el codigo, documentacion? es para niños!, sino que vuelva a la escuelita vs vamos a hacer un peliculita en flash para ver como resuelve los problemas de negocio con el mini-erp una empresa y de paso quitamos la jerga tecnica. Esa es para la peliculita e flash del administrador de sistemas) y asi por el estilo... Otra alternativa es ir armando infraestructura. Y me parece mas viable desde el punto de vista de inmediates. Ej: Yo tengo un motor de indexacion TU tienes CRM basado en web. Juntemos lo tuyo y lo mio, y tenemos un CRM con mejor busqueda. Yo tengo un CRM. TU tienes habilidades de documentacion Juntemos mi CRM y tu documentacion, y tenemos un CRM mejor etc...
__________________
El malabarista. Última edición por mamcx fecha: 13-05-2006 a las 18:10:30. |
|
#3
|
||||
|
||||
|
¡Hola a todos!
Deseo felicitar a Mario Montoya, uno de los más visionarios desarrolladores de software, y de los pocos que no se ven impedidos mentalmente a exponer sus puntos de vista públicamente en foros tan estratégicos como Club Delphi. Ojalá hubiera más valientes (¿o debería decir inteligentes?) como él, y algún consultor de SAP, PeopleSoft, Oracle, Borland, SUN, Google, Microsoft o Firuláis Systems demostrara la mitad de esa humildad compartiendo parte de su conocimiento de manera humanista y generosa en uno de estos desafiantes y castellanos tableros de mensajes. Me pregunto por qué hay tan pocos MESTROS que escriben en foros. ¿El nivel de vida o de ingenio es directamente proporcional al desprecio? Les dejo esta reflexión a aquellos lectores cuya gran sabiduría les brota por las cuencas de los ojos al grado de no dejarles ver el botón Responder. Cita:
![]() Ahora, pasando al terreno de las ideas, puedo decir que éstas van y vienen en mi cabeza todo el tiempo. Algunas son ya realizables, otras (como la herencia insertada) deben esperar a que otras personas reciban la misma luz, otras ya se volvieron anacrónicas de tanto meditarlas, y unas cuantas más son hurtadas de mi cerebro por el satélite telepático de Echelon mientras duermo .Me gustaría participar en algún proyecto colaborativo que resulte interesante para la comunidad hispana de programadores Delphi. Estoy a sus órdenes como PB y PO siempre que una idea pueda ser convertida en un proyecto organizado, sustentable, prometedor y realista. Si les parece comencemos con una lluvia de ideas. ¿Quién quiere ser el primero en exponer? Un abrazo en los tableros. Al González. ![]() |
|
#4
|
||||
|
||||
|
Yo veo 2 problemas principales:
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#5
|
||||
|
||||
|
No exageres. Visionario???
El asunto es que quizas tengo mucha afluencia para escribir. Pero en persona es otra cosa.. es como el dicho de que nadie es profeta en su casa, donde "casa" es el mundo externo y el extranjero escribiendo. Pero lo que si ocurre es que de errores propios y de ver como los demas se equivocan y de ves en cuando aciertan uno debe aprender algo... Lo de que resulte algo sencillo, mejor. Lo de lluvias de ideas es un buen comienzo. Ok. Para lo de ideas, enfoquemonos en un conjunto de maximo 2-3 problemas a resolver, 2-3 caracteristicas que vamos a promover como puntos fuertes. Lo mas importante, o eso he leido, sobre un producto es la diferenciacion. Y la peor diferenciacion es lo barato o gratis... eso del "open source" es gratuito? Suena atrayente pero si es la *unica* diferenciacion, siempre es posible hacer que algo sea aun mas gratuito (por ejemplo, si la financiacion es soporte, lo mas gratuito es prescindir del soporte!) Problemas a resolver, a quienes. 3 puntos *maximo* a destacar (y de paso un buen mercaderista nos regañaria por tener tantos, la idea es 1 solo). Que tal este: correo. Problemas: - SPAM - Inseguro - Anti-privacidad Como resolverlo? No se si se han dado cuenta que mucha gente prefiere usar messenger para pasarse informacion... y como se odia el correo... bastante! Asi que la idea es un servicio de mensajes. Como? RSS + SSL + Semi-Foro + Centralizado + Gateway de recepcion de correos (importante hacer puente con sistemas legados) + Integracion con sistemas de almacenamiento remoto. Mercado objetivo: 1- Pymes de 5-500. El asunto es un software social 2- Grupo de trabajadores remotos Puntos a destacar: 1- Comunicacion fluida 2- Totalmente seguro y privado 3- Antispam Donde cojer conceptos: http://www.basecamphq.com/ Que habria que hacer: 1- Un servicio centralizado 2- Gateways SMTP + Defensa anti-spam de este gateway 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 de mails a sistemas legados, como exchange, dominio om outlook Inversion? 1- Un servidor + hosting con buena seguridad 2- Un plan de mercadeo Ya se que es dificil y que conceptos de mejorar la experiencia de los correos se han intentado. El objetivo es no mejor el mail. Es nulificarlo. La idea es hacer un hibrido entre un cliente de correo, compartir archivos y messenger. Suena algo dificil, pero me parece que se puede hacer entre 3-5 personas disciplinadas en unos 6-8 meses. De meterme en esto, es con un proposito comercial. En mi pais estamos conformando un cluster tecnologico y ya estamos unas 10 empresas del area, tengo como penetrar mercado. Pero el proyecto como tal, open source, o sea la *tecnologia*, pero la operatividad y servicio, comercial Que les parece?
__________________
El malabarista. |
|
#6
|
||||
|
||||
|
Les tengo otro, que me quede con ganas de hacerlo:
Problema a resolver: Los usuarios no saben mucho de sistemas. Nosotros si. Pero no nos encuentran a nosotros y se quedan con el tecnico en sistemas que no sabe o con el hijo del tio que esta aprendiendo sistemas. Puntos a destacar: 1- Encuentre asistencia tecnica con personal qualificado 2- Tarifa plana. Nada de costos ocultos (en cuanto al servicio como tal) Mercado objetivo: 1- Usuarios finales 2- Empresas medianas a pequeñas 3- Con acceso a internet y que puedan pagar con tarjetas debito o credito Como se resuelve: Un sistema messenger + vnc + asistencia remota. Un servicio donde nerds se incriben en areas de experiencia . Ej: Peludos administradores de linux. Dementes con experiencia en .NET Un cliente de chat o estilo messenger o jabber o lo que sea, con la opcion de (si el cliente lo permite) tomar control por medio de un vnc. Un servicio. Un sistema central que cobra, digamos, 10 US la hora (se harian tarifas *planas* por areas de trabajo). Al nerd que dio la ayuda, se le da un %, ejemplo 70% y el resto para mantener la operacion del servicio. Donde esta lo open source? La plataforma de asistencia remota + tecnica. Que habria que hacer? - Integra con un servidor jabber (asi nos ahorramos el servidor de mensajeria?) - Un cliente liviano, que se instale en segundos y que se desintale facilmente. Que pueda atravesar firewalls. Que incluya opcionalmente VNC - Un sistema interno donde los expertos puedan chatear entre si cuando necesiten mas de una mano - Un sistema de puntajes. Expertos con niveles. Mas experto, mas $ - Un area donde ganar el dercho a ser experto con algunas preguntas que pueden darse gratuitas. Una ves el experto demuestra su interes, hace parte del combo. - La opcion de que el experto mas cercano geograficamente al lugar del cliente, pueda hacer contacto real para los casos donde es necesario asistencia directa. - Un sitio web de inscripcion de expertos. -Los clientes no se inscriben. Bajan software, pregunta (grupo de expertos conectados cojen el requerimiento de ayuda), alguien lo agarra, lo resuelve, el cliente paga. Si no se resuelve, se le devuelve? Donde ver ideas: https://www.copilot.com/ La diferencia? A quien se le da ayuda se le da un porcentage (en este servicio, el cliente le paga a copilot y el que ayuda no recibe nada) De este proyecto tengo disponibles los requerimientos y tengo la plataforma de comercio electronico. Como notan, ven que no aparece *mucho* el software. Estoy hablando de problemas y de como resolverlo. De infraestructura y de objeivos a resolver con software. Luego, de ultimo, si madura el objetivo final, miramos la parte concreta. Como estoy muy enfocado a algo comercial, por las razones que expuse, quiero dejar claro: 1- El software resultante sera 100 % open source, bajo cualquier tipo de licencia. No me importa. 2- Cualquiera entonces puede montar servicios competidores como le plazca. Por ejemplo, el mismo servicio de asistencia tecnica transformarlo a asistencia legal 3- Me apunto a ayudar en definir aspectos de mercadeo y en colaborar con la plataforma de comercio electronico. 4- Si nos vamos por otro lado, me encantaria que pudieran contar con MUTIS, como software de indexacion, o lo que sea. Lo que quiero en definitiva, es que vean como meta final como ayudaran a las personas. Como soy empresario y veo empresas, asi pienso y me enfoco, pero no tiene que ser asi: Que tal un software para educar niños, multimedia? o unom para ayudar al medio ambiente? No se... solo que seria genial que dijeran "estos peludos del club delphi hicieron algo genial como esto o aquello" algo que sobresalga, asi sea un poquito ![]()
__________________
El malabarista. |
|
#7
|
||||
|
||||
|
mamcx: Impresionante.
Justo todo lo contrario que yo, que no se me ocurren ideas para nada. Hay que madurar sobre lo que has explicado, me gustan los proyectos que se te han ocurrido, geniales. Pienso que además de open source, por supuesto, deben ser independientes de la plataforma, que se puedan ejecutar en cualquier sistema operativo, o mejor aún, que sean basado en web, que funcionen con cualquier navegador estandar, así no se excluye a nadie, use el sistema operativo que sea. Si llegásemos a hacer algo como el primer proyecto que has detallado, de verdad que se hablaría del clubdelphi, seguro, porque es algo muy importante hoy en día y parece que no acaban de cuajar soluciones a cosas como el spam y correo indeseado. También es cierto que me parecen unos proyectos complejos, ojalá pueda aportar mi granito de arena. Me he ilusionado... hay que madurar bien la idea... voy a echar a andar la neurona que me queda... ![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#8
|
||||
|
||||
|
Tener ideas es muy facil... el problema es llevarlas a cabo
![]() Ok... que tal si sacamos un conjunto de proyectos y luego armamos una encuesta? Es solo llenarnos de ideas, un monton.... y luego vamos descartando.
__________________
El malabarista. |
|
#9
|
||||
|
||||
|
¡Hola a todos!
El mercado del tiempo, esfuerzo y precisión es uno de los más jugosos. Y no hablo de fabricar relojes, sino de ayudar a las personas a ahorrar tiempo, conservar energía y evitar errores en sus tareas cotidianas. Dentro de algunas décadas será un estándar aceptado que las interfaces de usuario estén diseñadas de forma que puedan pensar y ayuden a los usuarios a realizar tareas cotidianas de manera cada vez más rápida, precisa y automatizada. Mientras tanto, existen millones de interfaces de usuario no pensantes que podrían ser automatizadas sin necesidad de reconstruir su código. Hace tiempo que tengo la vaga idea de crear un robot o asistente de automatización que pueda ser utilizado por millones de usuarios Windows alrededor del mundo. Seguramente ya hay herramientas de este tipo, sería cuestión de estudiarlas y analizar que gran diferencia podríamos darle a nuestro producto. Imagino un mundo feliz donde un usuario del departamento de Contabilidad pueda agregar un nuevo botón dentro de la ventana de captura «Comisión» que utiliza todos los días. Un botón que ejecute una macro previamente grabada por él mismo. La macro podría realizar, por ejemplo, las tareas de elegir en un cuadro combinado (combo box) a «Felipe Pérez», moverse al cuadro de grupo «Viáticos» e introducir las cantidades de 1200, 800, 700 y 300 en los cuadros de «Transporte», «Hospedaje», «Alimentación» y «Otros gastos», respectivamente. El botón de la macro podría tener como título «Viáticos Felipe a Madrid», y el usuario podría colocarlo en cualquier lugar vacío de la forma, o bien, en lugar de un botón, tendría acceso a la macro a través de un menú local (popup menu).Recuerden que las macros existen para darle al usuario mismo la oportunidad de enriquecer la sistematización de un proceso; el escenario del ejemplo anterior pudo haber sido contemplado desde el análisis del sistema, pero debemos admitir que siempre habrá situaciones operativas que ni el analista ni los programadores consideren. Roboface* sería una herramienta extremadamente útil para millones de usuarios Windows. El mercado es grandísimo, por lo que se puede ganar mucho tanto en un esquema de licencias payware, como por soporte u otra clase de servicios en un esquema de licencias gratuitas. Técnicamente es relativamente fácil manipular muchos de los controles contenidos en una ventana de aplicación Win32 en ejecución, y con el advenimiento de .NET supongo que será aún más fácil trabajar con los objetos de una interfaz de usuario, a no ser que Microsoft haya reforzado la seguridad** en ese aspecto. De cualquier manera, existen millones de contadores, oficinistas, programadores y todo tipo de usuarios informáticos que recibiríamos con agrado la capacidad de crear macros en cualquiera de las aplicaciones que tenemos instaladas en nuestras computadoras. Y no macros tan simplonas como las del casi inútil Administrador de Tareas de Windows, sino macros al detalle, como es posible en Word y Excel (y aún en éstas herramientas hay muchas cosas inherentes a la interfaz de usuario que no se pueden automatizar con los mecanismos disponibles). ¿Qué les parece la idea? ¿Profundizamos en el tema? Un abrazo automático. Al González. ![]() * Por lo pegajoso del nombre, seguramente Roboface ya existe como nombre registrado; quizá habría que buscar otro nombre para el producto. ** Habría que redefinir el concepto de seguridad en interfaces de usuario en relación con la balanza de esfuerzo-recompensa (costo-beneficio). Última edición por Al González fecha: 15-05-2006 a las 20:18:58. |
|
#10
|
||||
|
||||
|
Cita:
// Saludos |
|
#11
|
||||
|
||||
|
Cita:
![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#12
|
||||
|
||||
|
¡Hola a todos!
Cita:
Cita:
Cita:
Un abrazo aclaratorio. Al González. ![]() |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
|