En esta cápsula continuamos con la implementación de las funciones de nuestro menú manipulando listas genéricas y usando objetos.
Recuerden que el código de la cápsula se encuentra en Avanet.
lunes, 22 de agosto de 2011
Cápsula #3 C#.NET: Control de errores, objetos y listas
En esta nueva cápsula aprenderemos un control básico de errores y empezaremos a manejar objetos o entidades para manipular los datos de nuestra aplicación, además de usar una lista genérica para almacenar los datos.
Recuerden que el código de la cápsula se encuentra en Avanet.
Recuerden que el código de la cápsula se encuentra en Avanet.
jueves, 18 de agosto de 2011
Propiedad Intelectual y Software
He de confesar que escribo este post después de varias horas leyendo sobre derechos de autor y propiedad intelectual, y con un tanto de vergüenza confieso que hasta hoy ignoraba detalles sobre este tema, que me parece como profesional debía conocer mucho antes.
Pues bien, con el ánimo de compartir un poco de lo que he aprendido leyendo, les resumo un poco las ideas que encontré y que espero haber entendido correctamente.
Actualmente yo trabajo en una empresa comercial, por lo que mi rol en este caso tiene que ver, con quien tiene los derechos de autor frente a una solución de software que enviamos a construir a un proveedor.
Aclaremos 2 cosas básicas, una cosa es el derecho de autor y otra la propiedad industrial. En el primero nos encontramos con que los derechos de autor son de dos tipos, morales y patrimoniales. Los derechos morales tienen que ver con la autoría del software, en el caso que les planteo pareciera claro que la autoría es de aquel que lo construye, pero en un foro bastante interesante encontré la explicación de alguien que te pone a pensar un poco sobre qué es la autoría.
Alguien ligeramente podría decir que la autoría es del cliente, porque finalmente es él quien se ideó la propuesta de software que está enviando a construir. Pues bien, esto no es tan simple, en el proceso de elicitación de requisitos, ocurre que muchas veces no solo se trata de recibir unas definiciones concretas por parte de los clientes, sino además tratar de aclarar y develar sus necesidades, y entre otras sugerir mejoras a las solicitudes iniciales. No sé que tanto les haya ocurrido a ustedes, en los proyectos que yo he participado hasta antes de tener el rol de cliente, como proveedores proponíamos bastantes mejoras a las solicitudes que se nos hacían.
Volviendo al tema entonces de la autoría, si de un proyecto de creación de software surgiera una demanda en la cual se debatiera la autoría moral de alguien, se procedería a establecer el porcentaje en el cual el cliente es autor y el proveedor es autor, un proceso que no debe resultar nada fácil, porque no se trata del número de componentes o documentos generados, si no de cuál es el aporte de las ideas de cada quien, puesto qué los derechos de autor, no protegen la idea si no la materialización.
En esta perspectiva, muchos podrían preocuparse, sin embargo recuerden que nos falta una parte, y son los derechos patrimoniales, pues bien, los derechos patrimoniales son la facultad que tiene alguien sobre una obra de modificarla, difundirla, venderla y distribuirla. Pues bien, estos derechos se pueden, ceder, regalar y negociar.
Ahora bien, en una relación contractual, los derechos patrimoniales son de aquel quien envía a construir la obra, esto puede ser lo que muchos damos por sentado, pero evidentemente es mejor entender el por qué. Así pues, el cliente por ley es dueño de aquello por lo que ha pagado, y como jamás está de más eso de dejar escritas las cosas, el tema de ceder los derechos patrimoniales y de que el proveedor no puede vender o distribuir la pieza de software que ha construido para un cliente, debe dejarse explicito en los contratos de software, al igual que cualquier clausula de confidencialidad en la que el proveedor se comprometa a no revelar datos particulares del negocio del cliente.
¿Significa entonces esto que yo no puedo utilizar lo que aprendí en un proyecto para atender a otro cliente? No, eso no es lo significa, volviendo a la frase de lo que se protege es la materialización y no la idea, el conocimiento no es algo sobre lo que se pueda colocar una restricción, el delito estaría en usar las mismas piezas de software para construir software para otro cliente, sin su expresa autorización, pero incluso reusar la idea y construir un nuevo software es legal (al menos en mi entendimiento).
Después de todo esto, en mi rol de cliente quedó un tema por resolver y es ¿cómo proteger entonces las ideas? Pues bien, de acuerdo a mi lectura, no todas las ideas son susceptibles de ser protegidas, cosa que tiene mucho sentido, un ejemplo son las cosas que son imprescindibles para la humanidad, como los procedimientos médicos o las formas de hacer negocios, las teorías científicas o los métodos matemáticos, tampoco las ideas que son obvias o que un especialista podría deducir fácilmente al enfrentarse a un caso particular.
Las ideas que se pueden proteger tienen que ver con invenciones de productos nuevos por ejemplo, o con cambios a procedimientos o al uso de un invento, obviamente demostrando que esto representa una mejora sustancial, así que si lo que hace nuestro negocio es algo realmente valioso, es posible proteger la idea al menos temporalmente, ya que ni los derechos autor ni la propiedad industrial conceden derechos indefinidamente, cada uno según el país tiene un límite de años en que es válido.
Hablando de este tema de patentes hay que decir que el solo hecho de pensar en patentar el software es una situación al extraña, el solo hecho de pensar en que ante un pleito van a poder comprobar que un software es copia de otro solo por cumplir por ejemplo con el mismo propósito parece una locura, en esta profesión idearse soluciones de software similares a otras para resolver un mismo problema, aún sin conocer la que ya existía es una posibilidad evidente. Sin embargo y a pesar de las polémicas que generan las patentes de software, es algo que ocurre en la actualidad y para lo que incluso hay movimientos en contra.
Al nivel de la propiedad industrial me gustaría no dejar sin nombrar que es posible proteger el diseño industrial a nivel de las formas en que se presenta un producto para diferenciarlo y también el secreto industrial que puede estar más relacionado con los modelos, procesos o elementos propios de un negocio y que requieren no ser divulgados puesto que representan una ventaja competitiva de una compañía frente a otras.
Me apoyo en esto último para hacer un llamado de atención al tema de confidencialidad, si bien cuando yo era contratista y empleada de casas de software, pensaba que era exagerada la cantidad de papeles que tenía que firmar constantemente cediendo ciertos derechos sobre las cosas que hacía y también comprometiéndome a cuidar cautelosamente la información de mis clientes, ahora que estoy del otro lado de la barrera entiendo un poco más la preocupación de los clientes en cuidar su negocio, basado en el esfuerzo y el capital que se invierten en ellos. Además tanto a clientes como proveedores con o sin experiencia en el ámbito del software, por favor, preocúpense más por entender la necesidad de realizar buenos contratos de software en los que las partes estén de acuerdo con sus responsabilidades, algo que escuche hoy en una reunión y que sonó algo jocoso pero que tiene su toque de realismo es que "es mejor un mal acuerdo que un buen pleito".
En fin, no soy ni mucho menos una fuente oficial para esto, espero no haberme pifiado en algún concepto, igual si es así espero sus observaciones y comentarios, y le recomiendo iered.org para consultar sus dudas, en especial este par de links que me ilustraron muchísimo, gracias mi compañero @hernandgr por compartírmelos.
El Derecho de Autor en la Era Digital
Propiedad Intelectual en Software
Además les comparto los links a la normatividad vigente en Colombia, que me ha compartido @caroca0315
DECRETO 1360 DE 1989
LEY 23 DE 1982
Aquí otros links de utilidad de la Organización Mundial de Propiedad Intelectual
Decisión nro 344 del 21 de octubre de 1993 - Régimen Común sobre Propiedad
Decisión nro 351 del 17 de diciembre de 1993 - Régimen Común sobre Derecho de Autor y Derechos Conexos
Pues bien, con el ánimo de compartir un poco de lo que he aprendido leyendo, les resumo un poco las ideas que encontré y que espero haber entendido correctamente.
Actualmente yo trabajo en una empresa comercial, por lo que mi rol en este caso tiene que ver, con quien tiene los derechos de autor frente a una solución de software que enviamos a construir a un proveedor.
Empezaré por decir que esto no tiene que ver con en que escenario o con que recursos construyas el software, tiene que ver con qué participación tiene el "constructor" por así decirlo en la creación o invención de la idea. Además no sobra recordarles que el concepto de software no solo refiere al código fuente si no a todos los artefactos derivados del proceso de desarrollo de software.
Aclaremos 2 cosas básicas, una cosa es el derecho de autor y otra la propiedad industrial. En el primero nos encontramos con que los derechos de autor son de dos tipos, morales y patrimoniales. Los derechos morales tienen que ver con la autoría del software, en el caso que les planteo pareciera claro que la autoría es de aquel que lo construye, pero en un foro bastante interesante encontré la explicación de alguien que te pone a pensar un poco sobre qué es la autoría.
Alguien ligeramente podría decir que la autoría es del cliente, porque finalmente es él quien se ideó la propuesta de software que está enviando a construir. Pues bien, esto no es tan simple, en el proceso de elicitación de requisitos, ocurre que muchas veces no solo se trata de recibir unas definiciones concretas por parte de los clientes, sino además tratar de aclarar y develar sus necesidades, y entre otras sugerir mejoras a las solicitudes iniciales. No sé que tanto les haya ocurrido a ustedes, en los proyectos que yo he participado hasta antes de tener el rol de cliente, como proveedores proponíamos bastantes mejoras a las solicitudes que se nos hacían.
Volviendo al tema entonces de la autoría, si de un proyecto de creación de software surgiera una demanda en la cual se debatiera la autoría moral de alguien, se procedería a establecer el porcentaje en el cual el cliente es autor y el proveedor es autor, un proceso que no debe resultar nada fácil, porque no se trata del número de componentes o documentos generados, si no de cuál es el aporte de las ideas de cada quien, puesto qué los derechos de autor, no protegen la idea si no la materialización.
En esta perspectiva, muchos podrían preocuparse, sin embargo recuerden que nos falta una parte, y son los derechos patrimoniales, pues bien, los derechos patrimoniales son la facultad que tiene alguien sobre una obra de modificarla, difundirla, venderla y distribuirla. Pues bien, estos derechos se pueden, ceder, regalar y negociar.
Ahora bien, en una relación contractual, los derechos patrimoniales son de aquel quien envía a construir la obra, esto puede ser lo que muchos damos por sentado, pero evidentemente es mejor entender el por qué. Así pues, el cliente por ley es dueño de aquello por lo que ha pagado, y como jamás está de más eso de dejar escritas las cosas, el tema de ceder los derechos patrimoniales y de que el proveedor no puede vender o distribuir la pieza de software que ha construido para un cliente, debe dejarse explicito en los contratos de software, al igual que cualquier clausula de confidencialidad en la que el proveedor se comprometa a no revelar datos particulares del negocio del cliente.
¿Significa entonces esto que yo no puedo utilizar lo que aprendí en un proyecto para atender a otro cliente? No, eso no es lo significa, volviendo a la frase de lo que se protege es la materialización y no la idea, el conocimiento no es algo sobre lo que se pueda colocar una restricción, el delito estaría en usar las mismas piezas de software para construir software para otro cliente, sin su expresa autorización, pero incluso reusar la idea y construir un nuevo software es legal (al menos en mi entendimiento).
Después de todo esto, en mi rol de cliente quedó un tema por resolver y es ¿cómo proteger entonces las ideas? Pues bien, de acuerdo a mi lectura, no todas las ideas son susceptibles de ser protegidas, cosa que tiene mucho sentido, un ejemplo son las cosas que son imprescindibles para la humanidad, como los procedimientos médicos o las formas de hacer negocios, las teorías científicas o los métodos matemáticos, tampoco las ideas que son obvias o que un especialista podría deducir fácilmente al enfrentarse a un caso particular.
Las ideas que se pueden proteger tienen que ver con invenciones de productos nuevos por ejemplo, o con cambios a procedimientos o al uso de un invento, obviamente demostrando que esto representa una mejora sustancial, así que si lo que hace nuestro negocio es algo realmente valioso, es posible proteger la idea al menos temporalmente, ya que ni los derechos autor ni la propiedad industrial conceden derechos indefinidamente, cada uno según el país tiene un límite de años en que es válido.
Hablando de este tema de patentes hay que decir que el solo hecho de pensar en patentar el software es una situación al extraña, el solo hecho de pensar en que ante un pleito van a poder comprobar que un software es copia de otro solo por cumplir por ejemplo con el mismo propósito parece una locura, en esta profesión idearse soluciones de software similares a otras para resolver un mismo problema, aún sin conocer la que ya existía es una posibilidad evidente. Sin embargo y a pesar de las polémicas que generan las patentes de software, es algo que ocurre en la actualidad y para lo que incluso hay movimientos en contra.
Al nivel de la propiedad industrial me gustaría no dejar sin nombrar que es posible proteger el diseño industrial a nivel de las formas en que se presenta un producto para diferenciarlo y también el secreto industrial que puede estar más relacionado con los modelos, procesos o elementos propios de un negocio y que requieren no ser divulgados puesto que representan una ventaja competitiva de una compañía frente a otras.
Me apoyo en esto último para hacer un llamado de atención al tema de confidencialidad, si bien cuando yo era contratista y empleada de casas de software, pensaba que era exagerada la cantidad de papeles que tenía que firmar constantemente cediendo ciertos derechos sobre las cosas que hacía y también comprometiéndome a cuidar cautelosamente la información de mis clientes, ahora que estoy del otro lado de la barrera entiendo un poco más la preocupación de los clientes en cuidar su negocio, basado en el esfuerzo y el capital que se invierten en ellos. Además tanto a clientes como proveedores con o sin experiencia en el ámbito del software, por favor, preocúpense más por entender la necesidad de realizar buenos contratos de software en los que las partes estén de acuerdo con sus responsabilidades, algo que escuche hoy en una reunión y que sonó algo jocoso pero que tiene su toque de realismo es que "es mejor un mal acuerdo que un buen pleito".
En fin, no soy ni mucho menos una fuente oficial para esto, espero no haberme pifiado en algún concepto, igual si es así espero sus observaciones y comentarios, y le recomiendo iered.org para consultar sus dudas, en especial este par de links que me ilustraron muchísimo, gracias mi compañero @hernandgr por compartírmelos.
El Derecho de Autor en la Era Digital
Propiedad Intelectual en Software
Además les comparto los links a la normatividad vigente en Colombia, que me ha compartido @caroca0315
DECRETO 1360 DE 1989
LEY 23 DE 1982
Aquí otros links de utilidad de la Organización Mundial de Propiedad Intelectual
Decisión nro 344 del 21 de octubre de 1993 - Régimen Común sobre Propiedad
Decisión nro 351 del 17 de diciembre de 1993 - Régimen Común sobre Derecho de Autor y Derechos Conexos
miércoles, 10 de agosto de 2011
Sobre las ideas y los errores en eso de emprender
Hace algún tiempo discutía con un amigo sobre su teoría de cometer errores para poder aprender, mi punto se centraba en que si bien el aprendizaje de los errores genera conocimiento y experiencia, buscar el error como estrategia no me resulta una actitud ni mucho menos correcta, si bien sigo pensando a hoy lo mismo, sobre el hecho de trabajar en pro de no equivocarse y de hacer las cosas lo mejor posible, el día de ayer aprendí gracias a @Ruta_N y su Workshop de Medios Convergentes y Móvil, algo que evidentemente replantea mi concepto sobre "el perfeccionismo".
Tres de los conferencistas nos compartieron sus experiencias: @betancur (Mi profe, de quien soy fan #1), @hugo_pardo y @rabble. Si bien sus consejos estaban enfocados a la industria del software, las ideas son aplicables al emprendimiento en general.
Entre sus historias e ideas, lo que me dejó bastante pensativa fue el ver la cantidad de aprendizaje que han tenido de lo que no ha salido "tan bien" y el nivel de satisfacción que sienten con sus experiencias vividas. Muchos de nosotros soñamos con tener la gran idea, trabajar por ella y ser exitosos, creo que pocos imaginamos el escenario de cometer un gran error antes de alcanzar esa idea exitosa.
No intento decir que hay que dejar de soñar con que las cosas salgan bien, pero si que algunos de nosotros (hablo en especial por mí) deberíamos darnos más amenudo esa oportunidad del riesgo y de fallar, de perder, de volver a empezar, de usar la experiencia del error para alcanzar cosas mayores, de no desistir, de intentar cosas nuevas, rutas diferentes para alcanzar las cosas que queremos.
Por otro lado en el sin fin de ideas que nos dejaron en la mente a los participantes, nos recordaron un concepto que si bien es una idea clara para muchos en áreas como el Marketing, no lo es tanto para otras profesiones, en las cuales esa necesidad de tener el gran logro e implementar una idea hasta que luzca como la soñamos, se vuelve una constante, ese concepto es el Mínimo Producto Viable. Este concepto consiste en trabajar por implementar nuestra idea por etapas y lograr exponerla al público objetivo en un punto donde generando satisfacción a una necesidad, o bien creándola, e invirtiendo un esfuerzo y tiempo mucho menor del que costaría implementar la idea completa, podamos llegar a ese mercado donde nuestra idea puede generarnos desde retroalimentación, hasta ingresos iniciales, e irla creciendo en una constante exploración de aquello que busca la gente que se vincula o consume el producto final de nuestra idea, sea lo que este sea.
Algunas de sus historias de hecho se centraron en contarnos como, dedicaron tanto tiempo a construir una idea, que cuando ya se vió lista y cuidadosamente construida para salir al mercado, otro evento inesperado ocurrió, dejando tanto trabajo y dedicación sin efecto, situación que podría haber sido diferente o bien que habría generado mayor rentabilidad de no haber esperado por generar la idea perfecta, si no por explotarla desde el inicio cuando evidentemente era viable.
Siempre he insistido en la necesidad de aprender de personas como ellos, en escuchar aquellos que ya han recorrido ciertos caminos, y minimamente evitarse ciertos pasos de lo que no ha salido bien, eso no garantiza el éxito, ni tampoco garantiza que puedas evitar repetir los mismos errores, pero definitivamente aprender de las experiencias de otros es absolutamente necesario, tanto como lo es aprender de los errores propios.
Les comparto la grabación de la conferencia de @betancur
Tres de los conferencistas nos compartieron sus experiencias: @betancur (Mi profe, de quien soy fan #1), @hugo_pardo y @rabble. Si bien sus consejos estaban enfocados a la industria del software, las ideas son aplicables al emprendimiento en general.
Entre sus historias e ideas, lo que me dejó bastante pensativa fue el ver la cantidad de aprendizaje que han tenido de lo que no ha salido "tan bien" y el nivel de satisfacción que sienten con sus experiencias vividas. Muchos de nosotros soñamos con tener la gran idea, trabajar por ella y ser exitosos, creo que pocos imaginamos el escenario de cometer un gran error antes de alcanzar esa idea exitosa.
Cuando no conocemos las historias detrás de éxitos como Twitter, Flickr o Groupon, ideas que no fueron concebidas inicialmente como lo que son actualmente, si no que derivan de encontrar en otra idea que no salió tan bien aquello que tenia valor, necesariamente te cuestiona.
No intento decir que hay que dejar de soñar con que las cosas salgan bien, pero si que algunos de nosotros (hablo en especial por mí) deberíamos darnos más amenudo esa oportunidad del riesgo y de fallar, de perder, de volver a empezar, de usar la experiencia del error para alcanzar cosas mayores, de no desistir, de intentar cosas nuevas, rutas diferentes para alcanzar las cosas que queremos.
Por otro lado en el sin fin de ideas que nos dejaron en la mente a los participantes, nos recordaron un concepto que si bien es una idea clara para muchos en áreas como el Marketing, no lo es tanto para otras profesiones, en las cuales esa necesidad de tener el gran logro e implementar una idea hasta que luzca como la soñamos, se vuelve una constante, ese concepto es el Mínimo Producto Viable. Este concepto consiste en trabajar por implementar nuestra idea por etapas y lograr exponerla al público objetivo en un punto donde generando satisfacción a una necesidad, o bien creándola, e invirtiendo un esfuerzo y tiempo mucho menor del que costaría implementar la idea completa, podamos llegar a ese mercado donde nuestra idea puede generarnos desde retroalimentación, hasta ingresos iniciales, e irla creciendo en una constante exploración de aquello que busca la gente que se vincula o consume el producto final de nuestra idea, sea lo que este sea.
Algunas de sus historias de hecho se centraron en contarnos como, dedicaron tanto tiempo a construir una idea, que cuando ya se vió lista y cuidadosamente construida para salir al mercado, otro evento inesperado ocurrió, dejando tanto trabajo y dedicación sin efecto, situación que podría haber sido diferente o bien que habría generado mayor rentabilidad de no haber esperado por generar la idea perfecta, si no por explotarla desde el inicio cuando evidentemente era viable.
Siempre he insistido en la necesidad de aprender de personas como ellos, en escuchar aquellos que ya han recorrido ciertos caminos, y minimamente evitarse ciertos pasos de lo que no ha salido bien, eso no garantiza el éxito, ni tampoco garantiza que puedas evitar repetir los mismos errores, pero definitivamente aprender de las experiencias de otros es absolutamente necesario, tanto como lo es aprender de los errores propios.
Les comparto la grabación de la conferencia de @betancur
“He encontrado que siempre aprendo más de mis errores que de mis éxitos. Si no estas cometiendo errores es porque no te estas arriesgando lo suficiente”. John Sculley.
Suscribirse a:
Entradas (Atom)