Bueno, hoy queda inaugurada la serie de charlas 2010. En 2008 hubieron una seguidilla de eventos atractivos, peo últimamente se han reducido mucho. Siempre me gustó participar y tenemos: BarCamp, CodeCamp, PalermoValley, PHP, Python, IEEE.
Bueno, subo el pdf de PyAr, que hoy a partir de las 10:30am de argentina empezarán a dar sobre lenguaje Python (Python Argentina y Colectivo La Tribu, Ciclo 2010 de Charlas Abiertas de Python), gratis (pero a la gorra). Ayudando con los gastos a las personas que ayudan a que esto salga adelante.
Distribuidas a lo largo de varios sábados del segundo semestre del año, cubren temas desde lo más principiante a temas muy avanzados, cerrando incluso con un taller.
También, y aún no se confirmaron todas las charlas, se viene CodeCamp 2010! el evento será el 4 de Septiembre a partir de las 9hs en la Universidad de Palermo (Mario Bravo 1050, CABA). Presenta desarrollo de software con herramientas Microsoft. El año pasado hubieron muchas “manzanas dando vueltas” y este año no creo que sea la excepción. Me gustó, valió la pena. Hay mucha gente programando (y muy jóvenes la mayoría) con buenas ideas. Hay que preinscribirse, aunque todavía no está abierta la misma. Para mas info pueden seguir en twitter a @masaez.
Buen comienzo de semestre!! :D
wfranck – Walter J Franck
En un principio la idea era hacer un blog técnico, de trabajos de la facultad.
Pero no puedo evitar cosas que los noticieros de argentina no muestran. De más está decir de todas las acciones que están relacionadas con el patrimonio de Gran Bretaña, de los U$S 1.400.000 de impuestos que aportó el último año al reino (justo con toda la crisis, es una ayuda para la reina y los recortes de presupuesto). Además de la importancia de que esta empresa siga funcionando no entiendo cómo. Tenemos datos interesantes como que en los ‘80 las perforaciones se hacían a 200-300 metros de profundidad y hoy llegan a los 3000 como es el caso de BP. solución? OK, suspendamos las perforaciones marítimas (que son al rededor del 10% del total), y vamos a estar todos de acuerdo con ello dado la cuestión ecológica; pero recuerde la ley de oferta y demanda: si baja la oferta, ante una demanda constante el precio se incrementará :( !!!
estamos hasta las manos!
Algunas imágenes desde 9GAG, todo lo relacionado con el desastre de BP
Otro de los podcast que escucho religiosamente es Cafe Brasil, el de este señor: Luciano Pires. Está en portugués, es un podcast que se publica una o dos veces por semana, con música y temas de actualidad de interes general.
Luciano es ejecutivo, periodista, escritor.
Presta un espacio de opinión, y es un podcast para escuchar algo de música y conocer algunas ritmos nuevos.
Quizás lo mas llamativo del podcast es el orden y la relación entre la presentación de los temas de contenido, la música, las introducciones y conclusiones. Puede que no sea innovador en los temas, pero sí lo es en la prolijidad con buena producción y puesta al aire, con personas muy capaces detras de escena.
Hoy no tengo ningún compañero del tipo geek con el que pueda disfrutar de una charla y disfrutar una charla que no tenga nada que ver de los tiempos de entrega, de nuevos proyectos con destino incierto, etc etc.
¿En serio?.. mañana tengo que .. y la semana pasada con todos los cambios y problemas de servidor.. … Y esta gente sólo piensa en tiempos de entrega y trabajos realizados. Es poco triste pero es en cierta manera la realidad.
Y podría pasarme el día entero comentando sobre nuevas tecnologías: Java, struts, spring, jpa, jsf, jsp, servlets, eclipse, netbeans, oracle, sun, db2, mvc, hibernate, maven, groovy, grails. Todo desordenado.. pero bien podría integrar todo esto y escribir 200 páginas.
suena bien? no importa en lo más mínimo. Podría hacer una presentación de todo esto y nadie prestaría atención en lo más mínimo, porque yo: programdor, no existo. Soy un enigma.
No tienen ni idea de quién escribió esa ventanita tan útil. No te vana conocer. No les importa de porqué lo diseñó así o de otro modo. No importa porqué cuando lograste terminar la solución, ya no necesitaban tu trabajo. Solo eres importante porque gastas tu vida en el software manteniéndo sus programas.
Para toda la empresa sólo sos aquel pedazo de software. Apenas sos un destornillador con DNI. Ellos solo quieren que ajustes los tornillos de su software y se acuerdan de tí cuando tengan que arreglar nuevamente el sistema.
Vamos a probar un experimento. Un programita que usa todos los días. Diga con qué herramientas está hecho, el nombre de 4 personas relacionadas (sin mirar para arriba). No puero hacer solo eso con lo que yo trabajo.
Bueno, digamos que usted puede hacer todo eso. Usted sabe tiene todo el conocimiento de la gente que hace sus herramientas, pero ¿puede suted decir honestamente que usted sabe tanto de ellos como lo hace con las herramientas que usted hizo? Sea honesto consigo mismo y mire lo mucho que sabe sobre la gente detras de su equipo que lo hace como un arte en sí mismo.
Los programaadores famosos no son muy famosos por sus programas, sino por el negocio que crearon alrededor de su idea. Su fama no está basada en un código impresionante, está vinculado con algo fuera de ello que luego la gente asocia a este concepto.
Por eso creo (el autor del artículo original y yo): No Hay Programadores Famosos.
Y lo de ser conocido, no ayuda mucho en tu carrera de programción en determinados aspectos, los clásicos aspectos que suelen provocar migraña.
Todavía tengo que hacer entrevista de programador como todos los demás. Por mucho código que hice, tengo que resolver ejercicios de factoriales, ordenar vectores, consultas sql. No importan todos esos servidores web, servidores, bases de datos, lenguajes que has manejado. No importa cuántas copias de tu software hayas hecho tienes que demostrar que puedes hacer software.
Ser exitoso no ayuda en mi profesión. De hecho, hace más difícil porque ahora por alguna extraña razón la gente piensa que mi fama significa que no puedo “codear”.
Ahora solo pienso en pasar un buen rato con lo que sé mientras pueda hacerlo. Tal vez hacer lo que mas me gusta como hobbie (y trabajo).
En poco tiempo, creo que los programadores simplemente no serán más que los trabajadores de fábrica.
Los programadores se olvidan de las obras de otros programadores, y serán absorvidos por completo en esta ceguera, eliminando el incentivo de proiducir y compartir con otros programadores: el reconocimiento.
Disfrutemos este momento, hasta que el día que ser programador sea sinónimo de ser un ciudadano de segunda clase.
Uno de los podcast que más me gustan de Dixo (creo que es un canal), es el de Nadia Molina.
Como narra en iTunes Store …”No hay voz más franca y cálida que la de Fernanda Tapia. Ganadora del Premio Nacional de Periodismo, cuenta con más de 28 años de carrera como columnista perspicaz, locutora de gran culto en la radio y conductora consolidada en la televisión.”…
Solo un momento en el tren mientras viajamos al trabajo y cerramos los ojos para dejarnos llevar, escuchar pensamientos y pasarla bien.
Les dejo un fragmento que escuché en este podcast.
Ya todo lo llenas tu, yo no soy nada en ti y te voy a dejar al fin.
Al fin tu eres feliz ni lo vas a notar.
Soy dolor que nunca te ha dolido, soy amor que a fuerza se ha metido, soy una simple comparsa y por eso me voy.
No sufriré tu altivez, aunque puedas vivir con el mundo a tus pies, y mi más grande amor tan pequeño lo vez. Me haces menos y ese es mi coraje, y si no te gusta lo que traje: adios; pues de algún modo seguiré mi viaje.
Y es noticia de esta semana los recortes que se están produciendo en distintos países de europa debido a la crisis que apareció en Grecia y se “contagiaron” varios países.
Hay unos ítems interesantes que llaman mucho la atención, viéndolo desde el punto de vista de un ciudadano del 3er mundo y desde “Argentina” con un riesgo país que desde la crisis (aunque se le presta atención) sobrepasa la luna.
Todo es de la querida República Federativa Alemana:
-A pesar de entrar en crisis, ofrese ayuda a Grecia. Con muchas pre-condiciones pero tratando que un grande no caiga afectando alrededor.
-Otra, el motiva escribir este post. Alemania recortará una gran parte del presupuesto en todos los áreas. Recortará presupuesto militar, subvenciones, ayudas a desempleados por familia, etc etc. Recortará “todas las áreas” con dos excepciones.
Y, cómo ítem aparte, las excepciones en las que no se recortará el presupuesto son:
Educación e
Investigación
En conferencia de prensa el gobierno dejó que esto al momento es una decisión cierta y ninguno de los periodistas presentes y, luego de la aprobación, todos los partidos habrían estado de acuerdo (tengan en cuenta que siempre está el gobierno con todos los opositores y es extraño que todos apoyen unánimemente las mociones).
Recuerdo que hace unos años una profesora preguntó en clase sobre qué considera como prioridad: Invertir en salud (hospitales) o educación (escuelas). resultado de la votación: ganó salud. Hasta ese día nunca me había dado dado gusto “perder”.
La profesora corrigió ese resultado y dio las razones de porqué: claro, sabiendo las respuesta es fácil dar justificativos.
Pero es triste ver que en argentina no tenemos planes desarrollo a largo plazo que lamentablemente los gobiernos jamás tienen en cuenta porque su mandato dura máximo 8 años perdiendo elecciones por no dar resultados concretos, gastos fácilmente cuantificables y la imposibilidad de mostrar a los habitantes que el gobierno no da ganancias a las arcas de la nación si sigue con un plan educativo.
Bueno, viniendo de Alemania, no extraña saber porqué cuenta con buenos ingenieros.
…jamás hubiese prestado tanta atención para lograr este “diseño”.
Se me ocurre una nueva forma de componer. Bueno, despues de todo en sistemas además de diagramas de flujo contamos con UML, Patrones de Diseño, Metodologías Ágiles… no garantízan el éxito pero ayudan a tener un diseño consistente !
Observen que hay un error:
Es un bucle infinito!(habría que intentar rediseñarlo y hacerlo recursivo :P )
Hemos llegado a un punto donde la programación orientada a objetos no alcanza a satisfacer nuestras necesidades de rendimiento y modularidad. Donde la herencia no cumple nuestras espectativas y las utilidades deben atravesar todos los niveles de programación para cumplir algunas funciones específicas igual de útiles en todas las capas del negocio, funcionando aún sobre el nivel de jerarquía planteado por la POO.
Intro
ok, empezando con mi artículos teóricos: un “nuevo” paradigma.
Un paradigma, entre tantas ideas, es una forma de representar y manipular el conocimiento. Pero en sí los mismos establecen límites e indican como comportarse dentro del mismo concepto para alcanzar el éxito. Un cambio paradigmático es por lo tanto un nuevo conjunto de reglas.
Cuando cambia un paradigma todos retornamos a cero. Es decir, se pierden las ventajas de un conocimiento previo, mas surge una nueva correlación de ganadores y perdedores; una nueva forma de percibir la realidad.
Paradigma de programación
La ingeniería del software está compuesta por una serie de pasos que abarcan los métodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniería en software; básicamente, una forma de concebir la realidad.
Es un modelo básico de diseño y desarrollo de programas, una colección de modelos conceptuales que juntos modelan el proceso de diseño y determinan, al final, la estructura de un programa.Un paradigma de programación representa un enfoque particular o filosofía para la construcción del software. No es mejor uno que otro sino que cada uno tiene ventajas y desventajas. También hay situaciones donde un paradigma resulta más apropiado que otro.
Programación imperativa
Programación lógica
Programación funcional
Programación estructurada o declarativa
Programación dirigida por eventos
Programación modular
Programación Orientada a Aspectos
Programación orientada a objetos
Programación con restricciones
Programación por capas
Programación a nivel funcional (John Backus)
Programación a nivel de valores (John Backus)
Si bien puede seleccionarse la forma pura de estos paradigmas al momento de programar, en la práctica es habitual que se mezclen, dando lugar a la programación multiparadigma.
Programación Orientada a Aspectos (POA)
Es una nueva metodología de programación que aspira a soportar la separación de competencias para los aspectos, esta expansion se da debido a que en a POO se escribe bastante codigo para realizar una accion en si, lo cual ocasiona que ese codigo se disperse y se vuelva dificil de controlar. Los objetos, a modo de ejemplo, se pueden hacer referencia a un animal, en este caso un perro, con sus distantas caracteristicas, a esas caracteristicas son conocidas en POA como Aspectos. Como bien se sabe un perro en toda su vida util va cambiando su apariencia, pasa de ser un cachorro a un perro adulto, por lo cual sus caracteristicas/aspectos dejan de ser las mismas en forma de metafora la POA trabaja exactamente igual.
Gracias a la POA se pueden encapsular los diferentes conceptos que componen una aplicación en entidades bien definidas, eliminando las dependencias entre cada uno de los módulos. De esta forma se consigue razonar mejor sobre los conceptos, se elimina la dispersión del código y las implementaciones resultan más comprensibles, adaptables y reusables.
El principal objetivo de la POA es la separación de las funcionalidades dentro del sistema:
Por un lado funcionalidades comunes utilizadas a lo largo de la aplicación.
Por otro lado, las funcionalidades propias de cada módulo.
Cada funcionalidad común se encapsulará en una entidad.
En la segunda y tercera generación se tienen conjuntos de elementos agrupados por tonalidades, y en cada conjunto conviven distintas formas, lo que nos indica que la descomposición del sistema se hace en base a las funciones (tonalidades), y que los datos quedan esparcidos por todos los conjuntos.
Con las descomposiciones tradicionales no se aislan bien estos otros aspectos, sino que quedan diseminados por todo el sistema enmarañando el código que implementa la funcionalidad básica, y yendo en contra de la claridad del mismo. Se puede afirmar entonces que las técnicas tradicionales no soportan bien la separación de competencias para aspectos distintos de la funcionalidad básica de un sistema, y que esta situación claramente tiene un impacto negativo en la calidad del software.
La programación orientada a aspectos (POA) es una nueva metodología de programación que aspira a soportar la separación de competencias para los aspectos antes mencionados. Es decir, que intenta separar los componentes y los aspectos unos de otros, proporcionando mecanismos que hagan posible abstraerlos y componerlos para formar todo el sistema. En definitiva, lo que se persigue es implementar una aplicación de forma eficiente y fácil de entender.
POA es un desarrollo que sigue al paradigma de la orientación a objetos, y como tal, soporta la descomposición orientada a objetos, además de la procedimental y la descomposición funcional. Pero, a pesar de esto, POA no se puede considerar como una extensión de la POO, ya que puede utilizarse con los diferentes estilos de programación ya mencionados. El estado actual de la investigación en POA es análogo al que había hace veinte años en la programación orientada a objetos.
Implementación
Los aspectos no suelen ser unidades de descomposición funcional del sistema, sino propiedades que afectan al rendimiento o la semántica de los componentes. Algunos ejemplos de aspectos son, los patrones de acceso a memoria, la sincronización de procesos concurrentes, el manejo de errores, etc.
Como se puede observar, en la versión tradicional estos mismos bloques de funcionalidad quedan repartidos por todo el código, mientras en que la versión orientada a aspectos tenemos un programa más compacto y modularizado, teniendo cada aspecto su propia competencia.
Los lenguajes orientados a aspectos definen una nueva unidad de programación de software para encapsular las funcionalidades que cruzan todo el código. Para que ambos (aspectos y componentes) se puedan mezclar, deben tener algunos puntos comunes, que son los que se conocen como puntos de enlace, y debe haber algún modo de mezclarlos.
Los puntos de enlace son una clase especial de interfaz entre los aspectos y los módulos del lenguaje de componentes. Son los lugares del código en los que éste se puede aumentar con comportamientos adicionales. Estos comportamientos se especifican en los aspectos.
El encargado de realizar este proceso de mezcla se conoce como tejedor (del término inglés weaver). El tejedor se encarga de mezclar los diferentes mecanismos de abstracción y composición que aparecen en los lenguajes de aspectos y componentes ayudándose de los puntos de enlace.
En las aplicaciones orientadas a aspectos, sin embargo, además del compilador, hemos de tener el tejedor, que nos combine el código que implementa la funcionalidad básica, con los distintos módulos que implementan los aspectos, pudiendo estar cada aspecto codificado con un lenguaje distinto.
Una ayuda para poder identificar la segmentación de un programa es :
Análisis y diseño orientado a objetos:
Sustantivos: candidatos a clases o atributos.
Verbos: candidatos a métodos.
Análisis y diseño orientado a asepctos:
Adverbios y adjetivos: candidatos a aspectos.
Transacción segura, registro permanente, evento
Definen conceptos que tienen sentido independientemente a los sustantivos y verbnos a los que se aplican.
¡OJO! También pueden ser candidatos a subclases e interfaces.
Síntesis de Funcionalidades Básicas
Aspect (Aspecto) es la funcionalidad que se cruza a lo largo de la aplicación (cross-cutting) que se va a implementar de forma modular y separada del resto del sistema. El ejemplo más común y simple de un aspecto es el logging (registro de sucesos) dentro del sistema, ya que necesariamente afecta a todas las partes del sistema que generan un suceso.
Join point (Punto de Cruce o de Unión) es un punto de ejecución dentro del sistema donde un aspecto puede ser conectado, como una llamada a un método, el lanzamiento de una excepción o la modificación de un campo. El código del aspecto será insertado en el flujo de ejecución de la aplicación para añadir su funcionalidad.
Advice (Consejo) es la implementación del aspecto, es decir, contiene el código que implementa la nueva funcionalidad. Se insertan en la aplicación en los Puntos de Cruce.
Pointcut (Puntos de Corte) define los Consejos que se aplicarán a cada Punto de Cruce. Se especifica mediante Expresiones Regulares o mediante patrones de nombres (de clases, métodos o campos), e incluso dinámicamente en tiempo de ejecución según el valor de ciertos parámetros.
Introduction (Introducción) permite añadir métodos o atributos a clases ya existentes. Un ejemplo en el que resultaría útil es la creación de un Consejo de Auditoría que mantenga la fecha de la última modificación de un objeto, mediante una variable y un método setUltimaModificacion(fecha), que podrían ser introducidos en todas las clases (o sólo en algunas) para proporcionarlas esta nueva funcionalidad.
Target (Destinatario) es la clase aconsejada, la clase que es objeto de un consejo. Sin AOP, esta clase debería contener su lógica, además de la lógica del aspecto.
Proxy (Resultante) es el objeto creado después de aplicar el Consejo al Objeto Destinatario. El resto de la aplicación únicamente tendrá que soportar al Objeto Destinatario (pre-AOP) y no al Objeto Resultante (post-AOP).
Weaving (Tejido) es el proceso de aplicar Aspectos a los Objetos Destinatarios para crear los nuevos Objetos Resultantes en los especificados Puntos de Cruce. Este proceso puede ocurrir a lo largo del ciclo de vida del Objeto Destinatario:
Aspectos en Tiempo de Compilación, que necesita un compilador especial.
Aspectos en Tiempo de Carga, los Aspectos se implementan cuando el Objeto Destinatario es cargado. Requiere un ClassLoader especial.
Aspectos en Tiempo de Ejecución.
Diseño en la programación mediante Lenguajes de Aspectos. Tendencias que persiguen.
Los lenguajes de aspectos de dominio específico soportan uno o más de estos sistemas de aspectos que se han ido mencionando en las secciones anteriores (distribución, coordinación, manejo de errores, …), pero no pueden soportar otros aspectos distintos de aquellos para los que fueron diseñados. Los lenguajes de aspectos de dominio específico normalmente tienen un nivel de abstracción mayor que el lenguaje base y, por tanto, expresan los conceptos del dominio específico del aspecto en un nivel de representación más alto.
Si contrastamos estos dos enfoques, propósito general versus propósito específico, se tiene que los lenguajes de aspectos de propósito general no pueden cubrir completamente las necesidades. Tienen un severo inconveniente: Permiten la separación del código, pero no garantizan la separación de funcionalidades, es decir, que la unidad de
aspecto solamente se utiliza para programar el aspecto. Sin embargo, esta es la idea central de la programación orientada a aspectos. En comparación con los lenguajes de aspectos de propósito general, los lenguajes de aspectos de dominio específico fuerzan la separación de funcionalidades (Ej. COOL, RIDL).
Problemas de los Lenguajes Base:
Con respecto a los lenguajes de dominio específico, puede tener bastante importancia el hecho de escoger un lenguaje base. Se tiene que tener en cuenta que los puntos de enlace solamente pueden ser los que se identifiquen en el lenguaje base. Si necesitamos separar las funcionalidades, debemos recordar que el lenguaje base debe restringirse después de que se hayan separado los aspectos. Lo que implica quitar módulos del lenguajes base, que puede no haber sido diseñado para esto e implica un conocimiento con profundidad del mismo (mas dificil que haber creado uno desde cero).
Los lenguajes de aspectos de propósito general son menos difíciles de implementar por encima de un lenguaje de programación existente, ya que no necesitan restringir el lenguaje base.
Ventajas de programar la implementación de POA
Las ventajas que tiene el capturar los aspectos ya desde la fase de sieño son claras:
Facilita la creación de documentación y el aprendizaje, porque implica el diseño por completo de los mismos.
Facilita la reutilización de los aspectos, ya que conocemos la estructura interna y podemos adaptarlos a la nueva problemática.
Ventajas de la utilización de POA
Disminución del código disperso distribuido por toda la aplicación (scattered code).
Implementación un única vez en una ejecución de multimples comportamientos en forma simultánea.
A menudo, hace falta escribir líneas de código que están distribuidas por toda o gran parte de la aplicación, para definir la lógica de cierta propiedad o comportamiento del sistema, con las consecuentes dificultades de mantenimiento y desarrollo. El hecho es que hay ciertas decisiones de diseño que son difíciles de capturar, debido a que determinados problemas no se pueden encapsular claramente de igual forma que los que habitualmente se resuelven con funciones u objetos. Es allí donde la POA encuentra su espectro y donde debe encontrar cabida a nuevas teorías y técnicas que establezcan principios para su desarrollo, que en la actualidad la POO y el uso de Patrones de Diseño, tecnologías más utilizadas actualmente, no alcanzan acaparar.
Conclusión
La separación de los aspectos a todos los niveles (diseño, codificación y ejecutable) es un paso importante que se ha comenzado a dar, pero que aún hay que refinar, sobre todo en cuestiones de eficiencia.
Los entornos de programación orientada a aspectos que han habido hasta ahora no soportan una separación de funcionalidades suficientemente amplia, el lenguaje de aspecto soporta el dominio de aspecto parcialmente, no se sostiene adecuadamente la restricción del lenguaje base, o bien no se cuenta suficientemente desarrollada la idea de implementación que solucione un problema sin incurrir en otro aumentando la complejidad y disminuyendo el tiempo de desarrollo, mantenimiento u tiempo necesario de proceso.
Bueno, llegan los finales y aunque no me voy a presentar para prepararlos bien y hacer mi querido resumen a conciencia, sí estoy haciendo los parciales y trabajos prácticos.
ó ¿porqué elegiría una carrera que tengo que estudiar todos los días porque en 8 años no me va a servir para nada lo que aprendí el día de hoy?
Programar es como tener hijos y los hacerlos a tu medida. Podés jugar a ser dios, que hagan todo lo que quieras y como quieras; es jugar a crear. Es un lego de bits pero con fichas ilimitadas.
Podes asumir toda la responsabilidad, la delegás a frameworks y tenés poco tiempo usas un CMS :( que hagan parte o todo el trabajo, según tus necesidades.
Jugás a la creación con código máquina o usas algún IDE.
Encontrás todas las opciones que quieras. Te gusta lo libre, maleable y en un punto muy dificil pero a niveles atómicos, usá linux. Vas a trabajar? windows. Querés algo fácil, lindo y estás dispuesto a pagar el precio: mac.
Querés jugar? programa juegos.
Sino, como nueva opción programar para celulares, web, hardware, y muchas decenas de etcétera.
Trabajar a distancia, en tu casa, en la oficina, en grupo o solo, con gente de otros países, para la tele, el diario, la música, en todos los tipos de industrias que imagines o todas las naciones que quieras.
Podés ser reconocido mundialmente e incluso tener un perfil reservado.
Está demostrado que con la llegada de internet, los informáticos son las personas mas sociables que otras áreas, de hecho todo el día lo hacen por medio de todo tipo de medios: chat, redes sociales, canales irc agrupados por especialidad, portales, etc.
Tenés una idea y lo directamente fabricás a gran escala, no hay problemas de presupuesto.
No hay límites ni fronteras, los defines tú mismo.
Las tecnologías quedan viejas, pero el conocimiento no.
(dicho de otra manera, no terminás de aprender nunca y si no hay algo inventado están las puertas abiertas para ello)
No hay límites de exportaciones como sí es el caso de otros productos.
Entre los puntos fuertes del país se destacan el transporte y la infraestructura de comunicaciones, y la disponibilidad y el uso de las TIC´s (tecnologías de la información). “De hecho, en Argentina el Gobierno ofrece muchos servicios en línea, y, del mismo modo, las empresas utilizan Internet para realizar transacciones comerciales”
Somos autocríticos, perfeccionistas, muy detallistas, inquietos. Nunca sacamos una versión definitiva.
Hay que hacer un paréntesis a los cortes de energía eléctrica o cuando estamos sin wifi; Y nos ponemos a modelar con UML, Patrones, Maquetar…
Finalmente:
SEA CREATIVO !!! Cuanto todo parezca perdido, usa la imaginación.
En los momentos de crisis: sólo la imaginación es más importante que el connocimiento. Albert Einstein
Nada mejor que plasmar la imaginación en lineas de código! :P
Hace unos años encontré un artículo de Oscar Vilches (28-08-02 http://www.inf.udec.cl/revista/edicion1/ovilches.htm), en el cual me voy a estar copiando :P, hacia los futuros colegas informáticos, orientado hacia aquellos que actualmente estudian sistemas o hayan terminado. Contando un poco acerca de la experiencia que, como informáticos debemos enfrentar al ingresar al ambiente laboral “informático” por primera vez.
No es una crítica a lo que sucede en el medio informático, sino solamente un comentario que ayuda a no desanimarse al empezar a trabajar por primera vez en éste área (comentarios que recuerdo muy muy a menudo, luego de 2 años en sistemas)
Para muchos de los que odian programar deberán enfrentarse a este terror en el inicio de su vida profesional, a hacer cosas que desde primer año de facultad los docentes afirman que no se debe hacer (y significa desaprobar en un examen) y, sin embargo, es muy habitual en el trabajo.
La imagen del ingeniero informático, sentado en un escritorio, manejando proyectos, es sólo para unos pocos privilegiados, o para personas con un grado de experiencia mayor a 5 años (el que sabe sabe, el que no es jefe).
La realidad es que cuando ingresamos al campo laboral vamos a hacer de todo, desde limpiar una pc, hasta mantener códigos de mas de 10 años de antigüedad. (aunque los últimos años ha cambiado esto por las inútiles consultoras especializadas en TI que te derivan a departamentos de sistemas en los que difícilmente hagamos mas de una tarea y bien limitada dentro de nuestros conocimientos)
Además, se enfrentarán a la idea que tiene la mayoría de las personas con relación a los profesionales de la informática. Nos creen expertos en todo lo concerniente a la computación, como desde el último truco de un macro en Word, hasta cómo hacer que un torno mecánico, conectado a un computador, moldee una nueva plantilla (esto es copiado del texto original, pero en una oportunidad me lo pidieron)
Sinceramente nunca he utilizado macros en Word, aunque tengo alguna idea de cómo funciona un torno y cosas así por experiencia de unos meses en una metalúrgica con funcionamiento de máquinas neumáticas. Sin embargo, si me prestan el manual de ambos podríamos entrar a conversar, porque esta debe ser una característica como ingeniero, ingeniárselas ante una nueva situación y no vivir de recetas de cocina para cada situación a la que nos enfrentaremos.
Estos comentarios pueden parecer decepcionantes para jóvenes que tienen aspiraciones que van mas allá de los tecnicismos, sin embargo no hay que desanimarse, si bien esta primera etapa en nuestras vidas no es muy gratificante para el espíritu ingenieril, es una muy buena escuela para tener una mejor visión para posteriorres trabajos de mayor nivel y por que no decirlo, formar nuestras propias empresas.
Este background técnico, nos permitirá tomar decisiones en base a fundamentos prácticos y no solo teóricos, finalmente, nos lleva a ser mejores profesionales. En resumen, para los que están prontos a abandonar el alma mater de la Universidad, fuerza, que todo cambio es para mejor.
Para empezar, arreglaron el tema del MySQL caido del host, a último momento del fin de semana subo el WP aunque sin modificaciones (ni logo de la web ni nada) y ahora queda empezar la semana estudiando y trabajando (y peleando con los analistas) a full.
La primer idea era hacerlo casero, pero el lenguaje que menos idea tengo es precisamente php. Y no estoy suficientemente convencido para ir hasta cuspide a comprar la bilia de php. (esto despues de haber borrado un backup con el maquetado de una semana, de puro css y jQuery)
Y así preparo los primeros post que estaré subiendo regularmente. Un poco de lenguajes de programación, marketing, cooperativismo, música, inteligencia emosional; cosas de las que puedo hablar por algunos años de lectura, estudio y experiencia. Sobre todo porque hay cosas que me hubiese gustado encontrar en internet en su momento y nunca estaban como los quería.
Otro de los podcast que escucho religiosamente es 
Como narra en 
