UTNianos

Recurro a los expertos en busca de opiniones y sugerencias, para un proyectito que quiero hacer.
Mi especialidad es Smalltalk, pero quiero intentar salir de esa zona, y meterme en otros lenguajes, así que me parece una buena oportunidad.

Tengo que hacer un pequeño servidor, que reciba conexiones vía TCP, y responda a ciertas consultas. Las condiciones son las siguientes:
- entorno gráfico
- plataforma windows
- la aplicación debe ser portable
- las respuestas que el servidor devuelve pueden ser configuradas a mano, o sea que deben poder persistirse y editarse (en una BD o archivos de texto)

¿Qué lenguaje me recomiendan usar? ¿Qué soporte de datos?

C

base MySQL o PostgreSQL

Si sos de Palermo Javascript en Node.js y metele un MongoDB.

---

Si te gusta la aventura, Go.

(05-06-2014 22:34)Dem0 escribió: [ -> ]C

base MySQL o PostgreSQL

Si sos de Palermo Javascript en Node.js y metele un MongoDB.

---

Si te gusta la aventura, Go.

Dem0 ¿y cómo lo hago portable? necesitaría un servidor de BD corriendo (que lo podría hacer portable), pero me parece demasiado. estaba pensando en algo como lite sql, ¿no va?

no tengo idea qué queres hacer

solamente usé sql lite para un par de boludeces locales en python. Si te anda, y la idea es guardar metadata de un par de reglas, supongo sí.

---

también podrías hacer como dijiste arriba y usar texto pelado...

¿Portable de que no necesite instalación o portable de que con un poquín de laburo te lo lleves a Mac/Linux?


¿Orientarlo al tooling que se usa en Web no sirve? Onda, exponer algo REST, ¿o algo así?


Justo justo para este caso de uso no creo que te convenga alejarte de ST...

para la portabilidad, podes usar SQLite, es excelente para estas cosas.

Para desarrollar, podes optar por C#, te bajas el VisualStudio express y no tenes problemas de licencia. Sino lo haces en mono.
Sino mandate a bajar de nivel. y hacelo en C...

EN cuanto al resto de la portabilidad.
Para Mac y Linux, tenes Mono. Si lo haces en NetFramework 2, te aseguro por experiencia que no vas a tener ningun problema en lo absoluto, y si no le pifio las versiones mas nuevas estan migradas y sin bugs en un 95%...

Si la portabilidad de la que hablas, es que no se meta en el registro, bla bla bla... y que te quede un ejecutable y nada mas, lo podes hacer con cualquier lenguaje, bah, con C tenes casi asegurado ese punto, pero dependes de las APIs de windows.

Por experiencia, si vas a programar en C o C++, programate los socket vos como en linux, no uses capas intermedias de microsoft, porque a mi me dieron dolores de cabeza.

SQLite, es un "intermedio" entre una base de datos ACID y una plantilla de excel ...

En el software, lo tratas como cualquier server SQL, pero en disco, tenes un solo archivo donde se guarda la BBDD... para poder usarlo, tenes que tirar en la misma carpeta del ejecutable las DLL (que creo que es una sola) que usas para el SQLite.

Abrazo de gol

si tiene que trabajar a nivel de TCP me parece al pedo meterse con REST y "APIs" web.

---

para portabilidad entre SO podes independizar el core escribiendo libs para cada SO .es cuestión de ver los trade-offs entre eso y tener que lidiar con interpretes/vms/etc.

No se que tipo de aplicacion de consultas queres ahcer pero tene en cuenta que SQLite no es concurrente, es monousuario. Hacelo en python, y si son consultas sencillas montate un servidor xml. Si no necesitas concurrencia usa SQLite, sino mySQL. Postgres es muy pesado para una app de ese estilo, no se justifica.

¿nos podes comentar un poco más del servicio del sistema?

gracias a todos por la info!

(06-06-2014 01:04)Desert69 escribió: [ -> ]¿Portable de que no necesite instalación o portable de que con un poquín de laburo te lo lleves a Mac/Linux?

portable en el sentido que me lo copio en un pendrive o donde sea, y lo llevo a otro lado listo para usar.
no tiene que ser multiplataforma, solo windows.

lo que quiero hacer es un emulador de una aplicación comercial que se usa en el sector financiero.

la funcionalidad es bien básica: se levanta en un puerto de escucha donde recibe conexiones, y responde respuestas predefinidas a consultas de los clientes.
es multiusuario, pero no me importa el acceso a la BD porque las respuestas predefinidas son como mucho 20, así que las puedo levantar cuando inicia el servicio y mantenerlas en memoria.

para que se den una idea, sería un "chat server" bien pavo como hacemos de 1er ejemplo de sockets al empezar a cursar SO.

ya estuve viendo que C# me facilita mucho las cosas (gracias .NET) y el tema de sockets está casi todo resuelto. creo que voy a apuntar para ese lado, sobre todo porque no quiero dedicarle mil años, sino que quisiera tenerlo funcionando en una semana como mucho.

y dada la simpleza, creo que para los datos me voy a tirar a archivos planos, XML o JSON en su defecto.

no lo dudes, usa C# y XML.... te olvidas....
Tiras un using de net.socket y un TCPClient... y usas las clases y saraza que te da C# para los XML...

Como exagerado, el soft va a tener 5 archivos de C# y unas 600 lineas entre todos los archivos contanto el codigo autogenerado...

Hay que ir a la simpleza, lo haces con una pestaña con google abierta y listo... en una tarde lo tenes andando...
Para TCP, usa los eventos del TCPClient para la escucha... y a otra cosa mariposa... no deberias ni meterte en la programacion multithreading, la resuelve el mismo TCPClient!


Abrazo!

(09-06-2014 11:52)sebasthian777 escribió: [ -> ]no lo dudes, usa C# y XML.... te olvidas....
Tiras un using de net.socket y un TCPClient... y usas las clases y saraza que te da C# para los XML...

Como exagerado, el soft va a tener 5 archivos de C# y unas 600 lineas entre todos los archivos contanto el codigo autogenerado...

Hay que ir a la simpleza, lo haces con una pestaña con google abierta y listo... en una tarde lo tenes andando...
Para TCP, usa los eventos del TCPClient para la escucha... y a otra cosa mariposa... no deberias ni meterte en la programacion multithreading, la resuelve el mismo TCPClient!


Abrazo!

perfecto!

esta semana veo si me pongo a ver un poco.