07 marzo 2007
Copiar y pegar
Artículo escrito por el profesor Horst Bussenius C. Psicólogo, un profesor que me hizo clases en la Universidad, artículo que copio y pego en mi blog XD, para no perderlo y el cual me pareció muy interesante y te hace reflexionar (a quienes estudiamos).
Cuando un profesor da a su clase una tarea o trabajo de investigación, espera que sus alumnos lean sobre el tema, se informen, y luego hagan una síntesis que debe ser redactada para entregársela.
Un trabajo de esta naturaleza tiene varios objetivos:
1. El objetivo obvio de que los alumnos aprendan algo nuevo.
2. Desarrollar su capacidad para buscar y procesar información.
3. Que sus alumnos aprendan a redactar.
Sin embargo las facilidades de la informática han estado transformando esto, y haciendo que estos objetivos se pierdan o al menos se trunquen. En efecto, hoy en día muchos alumnos buscan en internet el trabajo, y lo bajan para presentarlo como un trabajo propio. Yo diría que en la enseñanza media es la norma, pero también se da en los estudios superiores, lo que es más preocupante.
Los signos reveladores del copiar/pegar son por lo general bastante obvios: una redacción más elaborada de lo habitual, que parece impropia del alumno que entrega el informe, y el uso de algunas palabras más cultas y de poco uso. Además de la intuición del profesor, existe también la herramienta de poner en el buscador "buscar frase", con lo cual es más fácil determinar la fuente en la cual se basó el alumno para su trabajo; trabajo "entre comillas" por lo demás, porque simplemente fue un "copiar-pegar", sin esfuerzo propio.
En mi labor docente me he encontrado con todo tipo de casos. En algunos me ha tocado observar lo que en psicopedagogía se llama "copia servil", un síntoma asociado a algunas patologías de escritura, y que consiste en copiar todo, sin ningún juicio crítico. Ejemplo típico de esto es encontrarse en un trabajo de dos páginas frases como "tema que trataremos en la parte final del libro", o "el tema tratado en el capítulo anterior".
Otros casos similares que me ha tocado observar fue en una monografía la expresión "ver tabla uno", sin que haya ninguna tabla, que sin embargo sí estaba con toda seguridad en el escrito original.
Todo esto nos muestra la dificultad enorme que tiene hoy el alumnado para redactar, y que es una falencia que está presente incluso en los estudios superiores. Pero en realidad se da a todo nivel. La gente no sabe expresarse por escrito.
Un caso muy jocoso lo viví en una oportunidad al entregar una tarjeta de navidad a una señora. Ella se sorprendió de mi gesto, y como no me tenía considerado entre las personas a quien entregaría tarjeta, se apresuró a buscar un pretexto para esconderse un rato, y reaparecer con una tarjeta. En mi tarjeta yo le había puesto "que tenga un buen año"; y en la de ella decía… "y usted también"…
No es fácil determinar por qué la gente no redacta hoy en día, pero sin duda confluyen una serie de factores. Quizás por falta de tiempo, o simplemente porque no aprendieron a redactar, o porque poner algo por escrito es más comprometedor que solo decirlo, ya que el texto queda y las palabras en cambio "se las lleva el viento"; o bien una dosis de pereza, o simplemente poca motivación, o porque han leído muy poco.
Lo cierto es que la redacción es una competencia importante, que no debería perderse, y deberían hacerse esfuerzos a nivel educacional para que los alumnos desarrollen esta habilidad, y aprendan incluso a disfrutar de una buena redacción.
Horst Bussenius C., Director Psicología Unap
Cuando un profesor da a su clase una tarea o trabajo de investigación, espera que sus alumnos lean sobre el tema, se informen, y luego hagan una síntesis que debe ser redactada para entregársela.
Un trabajo de esta naturaleza tiene varios objetivos:
1. El objetivo obvio de que los alumnos aprendan algo nuevo.
2. Desarrollar su capacidad para buscar y procesar información.
3. Que sus alumnos aprendan a redactar.
Sin embargo las facilidades de la informática han estado transformando esto, y haciendo que estos objetivos se pierdan o al menos se trunquen. En efecto, hoy en día muchos alumnos buscan en internet el trabajo, y lo bajan para presentarlo como un trabajo propio. Yo diría que en la enseñanza media es la norma, pero también se da en los estudios superiores, lo que es más preocupante.
Los signos reveladores del copiar/pegar son por lo general bastante obvios: una redacción más elaborada de lo habitual, que parece impropia del alumno que entrega el informe, y el uso de algunas palabras más cultas y de poco uso. Además de la intuición del profesor, existe también la herramienta de poner en el buscador "buscar frase", con lo cual es más fácil determinar la fuente en la cual se basó el alumno para su trabajo; trabajo "entre comillas" por lo demás, porque simplemente fue un "copiar-pegar", sin esfuerzo propio.
En mi labor docente me he encontrado con todo tipo de casos. En algunos me ha tocado observar lo que en psicopedagogía se llama "copia servil", un síntoma asociado a algunas patologías de escritura, y que consiste en copiar todo, sin ningún juicio crítico. Ejemplo típico de esto es encontrarse en un trabajo de dos páginas frases como "tema que trataremos en la parte final del libro", o "el tema tratado en el capítulo anterior".
Otros casos similares que me ha tocado observar fue en una monografía la expresión "ver tabla uno", sin que haya ninguna tabla, que sin embargo sí estaba con toda seguridad en el escrito original.
Todo esto nos muestra la dificultad enorme que tiene hoy el alumnado para redactar, y que es una falencia que está presente incluso en los estudios superiores. Pero en realidad se da a todo nivel. La gente no sabe expresarse por escrito.
Un caso muy jocoso lo viví en una oportunidad al entregar una tarjeta de navidad a una señora. Ella se sorprendió de mi gesto, y como no me tenía considerado entre las personas a quien entregaría tarjeta, se apresuró a buscar un pretexto para esconderse un rato, y reaparecer con una tarjeta. En mi tarjeta yo le había puesto "que tenga un buen año"; y en la de ella decía… "y usted también"…
No es fácil determinar por qué la gente no redacta hoy en día, pero sin duda confluyen una serie de factores. Quizás por falta de tiempo, o simplemente porque no aprendieron a redactar, o porque poner algo por escrito es más comprometedor que solo decirlo, ya que el texto queda y las palabras en cambio "se las lleva el viento"; o bien una dosis de pereza, o simplemente poca motivación, o porque han leído muy poco.
Lo cierto es que la redacción es una competencia importante, que no debería perderse, y deberían hacerse esfuerzos a nivel educacional para que los alumnos desarrollen esta habilidad, y aprendan incluso a disfrutar de una buena redacción.
Horst Bussenius C., Director Psicología Unap
16 agosto 2006
Unicode (UTF-8)
Uno de los graves problemas de la gran red es la internacionalización. Desde un principio, la internacionalización de contenidos siempre fueron definidos por unos pocos estándares, entre ellos los americanos como es el ASCII y algunos corporativos como es el de Microsoft Western Windows-1252. Esto por lo general hace que la mezcla de varios idiomas en un documento traiga bastantes dolores de cabeza.
A veces, cuando intentamos convertir documentos o mezclamos los encodings, las cosas terminan siendo como esta palabra Iñtërnâtiônà lizætiøn, ¿Símbolos raros eh?
La cuestión es, ¿cómo podemos ofrecer un encoding de archivo que soporte todos estos idiomas? Hay uno, se llama UTF-8, pertenece a Unicode. Hay varias formas de UTF, entre ellas la más popular la UTF-8, siguiéndoles UTF-12 y hasta un UTF-32.
Unicode se define con esta frase:
Unicode es un estándar industrial cuyo objetivo es proporcionar el medio por el que un texto en cualquier forma e idioma pueda ser codificado para el uso informático.
Resumiendo qué es Unicode y ventajas de usar UTF-8:
1. Soporte a todos los caracteres.
2. Compatibilidad entre páginas (véase compartir RSS, agregadotes)
3. Compatibilidad entre programas.
4. Menos configuraciones y cosas raras en el servidor.
Usar UTF-8 beneficiaría a todas aquellas páginas que de alguna forma u otra necesitan ofrecer un soporte de internacionalización a externos, en este caso las personas. Yendo más al grano, si usas en tu weblog UTF-8 por ejemplo, le ofreces a aquella gente que no habla tu idioma poder expresarse con el suyo, que puede ser japonés o ruso y utilizando su set de caracteres.
Το Unicode vπαρέχει έναν μοναδικό αριθμό για κάθε χαρακτήρα, η ο οποίος πλατφόρμα, το της οποίας πρόγραμμα, η του οποίου γλώσσα.
Si tu página no está codificada con UTF-8, probablemente cuando alguien escriba con un set de caracteres diferentes al que tu has seleccionado el texto se verá lleno de símbolos raros. Entonces, el problema surge a la vista. Para ello tenemos Unicode que nos brinda un soporte universal para que cada documento tenga la capacidad de mostrar diferentes sets de caracteres diferentes.
やれ打つな蝿が手をすり足をする
Oh, no la aplastes! / la mosca frota sus manos / frota sus pies
Kobayashi Issa 一茶 (1762-1826)
UTF-8 es que puede representar directamente todos los caracteres Unicode. Tener todo este soporte abre muchas puertas y da rienda suelta a la creatividad porque no.
¿Nunca han visto una que otra página web que se dedique a recopilar noticias de otro sitios usando RSS? ¿Comentarios mal codificados? Habrán notado que algunas de las noticias fueron directamente importadas de UTF-8 a una página y servidor que sólo acepta y sirve iso-8859-1. Esto se debe a que no han implementado UTF-8 todavía. Si lo hubieran implementado, probablemente no tendrían que hacer movidas raras de conversión antes de guardar un dato en la base de datos.
Otro punto a favor es la semántica del documento. Al estar escrito en UTF-8, no hace falta un navegador para interpretar el documento sino cualquier programa que utilice UTF-8 (la gran mayoría) para el set de caracteres. Esto también me beneficia para el que busca algo en Google por ejemplo, ya que Google no leerá mi documento lleno de códigos ISO sino palabras escritas en otro idioma, que es muy diferente.
Pasarse a UTF-8 no es tan fácil como copiar y pegar. Primero porque tenés que comprender qué cosas hay que configurar para que todo salga como una joya.
Extraido de Minid.net
Más información en UTF-8 en Wikipedia
A veces, cuando intentamos convertir documentos o mezclamos los encodings, las cosas terminan siendo como esta palabra Iñtërnâtiônà lizætiøn, ¿Símbolos raros eh?
La cuestión es, ¿cómo podemos ofrecer un encoding de archivo que soporte todos estos idiomas? Hay uno, se llama UTF-8, pertenece a Unicode. Hay varias formas de UTF, entre ellas la más popular la UTF-8, siguiéndoles UTF-12 y hasta un UTF-32.
Unicode se define con esta frase:
Unicode es un estándar industrial cuyo objetivo es proporcionar el medio por el que un texto en cualquier forma e idioma pueda ser codificado para el uso informático.
Resumiendo qué es Unicode y ventajas de usar UTF-8:
1. Soporte a todos los caracteres.
2. Compatibilidad entre páginas (véase compartir RSS, agregadotes)
3. Compatibilidad entre programas.
4. Menos configuraciones y cosas raras en el servidor.
Usar UTF-8 beneficiaría a todas aquellas páginas que de alguna forma u otra necesitan ofrecer un soporte de internacionalización a externos, en este caso las personas. Yendo más al grano, si usas en tu weblog UTF-8 por ejemplo, le ofreces a aquella gente que no habla tu idioma poder expresarse con el suyo, que puede ser japonés o ruso y utilizando su set de caracteres.
Το Unicode vπαρέχει έναν μοναδικό αριθμό για κάθε χαρακτήρα, η ο οποίος πλατφόρμα, το της οποίας πρόγραμμα, η του οποίου γλώσσα.
Si tu página no está codificada con UTF-8, probablemente cuando alguien escriba con un set de caracteres diferentes al que tu has seleccionado el texto se verá lleno de símbolos raros. Entonces, el problema surge a la vista. Para ello tenemos Unicode que nos brinda un soporte universal para que cada documento tenga la capacidad de mostrar diferentes sets de caracteres diferentes.
やれ打つな蝿が手をすり足をする
Oh, no la aplastes! / la mosca frota sus manos / frota sus pies
Kobayashi Issa 一茶 (1762-1826)
UTF-8 es que puede representar directamente todos los caracteres Unicode. Tener todo este soporte abre muchas puertas y da rienda suelta a la creatividad porque no.
¿Nunca han visto una que otra página web que se dedique a recopilar noticias de otro sitios usando RSS? ¿Comentarios mal codificados? Habrán notado que algunas de las noticias fueron directamente importadas de UTF-8 a una página y servidor que sólo acepta y sirve iso-8859-1. Esto se debe a que no han implementado UTF-8 todavía. Si lo hubieran implementado, probablemente no tendrían que hacer movidas raras de conversión antes de guardar un dato en la base de datos.
Otro punto a favor es la semántica del documento. Al estar escrito en UTF-8, no hace falta un navegador para interpretar el documento sino cualquier programa que utilice UTF-8 (la gran mayoría) para el set de caracteres. Esto también me beneficia para el que busca algo en Google por ejemplo, ya que Google no leerá mi documento lleno de códigos ISO sino palabras escritas en otro idioma, que es muy diferente.
Pasarse a UTF-8 no es tan fácil como copiar y pegar. Primero porque tenés que comprender qué cosas hay que configurar para que todo salga como una joya.
Extraido de Minid.net
Más información en UTF-8 en Wikipedia
26 junio 2006
Sugerencias para la creación de un Slogan
Un slogan, es una proposición que define brevemente o representa la misión de una organización.
El desarrollo de las marcas y los mercados de imágenes ha convertido a los slogans en una sentencia breve y dramática que sintetiza los beneficios funcionales y simbólicos de una marca o producto.
Un slogan debe enfatizar algo esencial y si es posible, distintivo de su organización. Desde creencias hasta características y beneficios particulares, un slogan debería explicar por qué una firma es única, o por lo menos, establecer su mensaje principal o ventaja competitiva.
Los slogans han sido parte de la comunicación de las marcas desde el comienzo del Marketing como disciplina.
Los slogans exitosos tienden ha respetar estas simples reglas
- Cortos y simples (3-4 palabras)
- Afirmación positiva
- Recordable
- Atemporal
- Incluye un beneficio / característica clave
- Es original, no es usado por ninguna otra empresa
TIPOS DE SLOGANS
Descriptivos: Tienden a describir lo que la empresa hace
Emocionales: Tienden a expresar un sentimiento relacionado con las empresas
SUGERENCIAS PARA EL DESARROLLO DE UN SLOGAN
1. Piense primero su negocio, y luego su slogan: Un slogan es la síntesis de toda la estrategia de Marketing. Para hallar las 3-4 palabras adecuadas, es necesario que Ud. conozca su mercado, su producto y su competencia:
Mercado: conocer a quién se dirige y cuál es el tipo de discurso que sus clientes comprenden.
Producto: conocer las características de su producto /servicio y los beneficios percibidos por sus clientes.
Competencia: conocer los impulsores de diferenciación de su producto.
Estos aspectos están articulados en su Estrategia de Marketing. Para comunicar su estrategia con éxito, es necesario que haya sido desarrollada previamente. Una vez que Ud. tenga una posicionamiento de empresa / producto / servicio definido, encontrará más fácilmente el concepto a comunicar, y finalmente el slogan que comunique su posicionamiento.
2. Si no es breve y recordable, no es un slogan: Los slogans extensos generan numerosos conflictos, tanto desde un punto de vista gráfico como semántico. Aplicar un slogan extenso en tamaño pequeño (tarjetas de visita, por ejemplo) es gráficamente dificultoso, y perjudicial para la apariencia de la pieza a diseñar.
Durante el proceso de diseño de su logotipo, la inclusión del slogan impacta en la disposición (layout) del diseño. Un slogan extenso obliga al diseñador a adecuar el tamaño del nombre de empresa para mantener su prominencia. Consecuentemente, el isotipo (el "símbolo") debe proporcionarse al nombre y al slogan. Como resultado, el isologotipo queda condicionado por el slogan, en lugar de ser diseñado para comunicar el concepto de su empresa / producto.
Comunicacionalmente, un slogan extenso no genera el impacto buscado, porque incrementa su complejidad lingüística y sintáctica. El slogan se convierte en un objeto de desciframiento que acentúa la mediatización propia del lenguaje. Al desviarse el foco de atención del logotipo al slogan, la "idea" atrás del slogan devora al logotipo.
3. Es mejor bueno después, que malo ahora: La creación de un slogan exige consideraciones y definiciones previas. Si no dispone de un slogan al momento de generar una pieza de comunicación, es preferible no incluirla en ella. Se evitará correcciones posteriores, desperdicio de impresos y principalmente, sus clientes no verán un cambio de mensaje que usualmente es interpretado como un indicio de improvisación y falta de profesionalismo.
Autor: Andrea Nelson
http://www.ars-logo-design.com/ar_slogan.htm
El desarrollo de las marcas y los mercados de imágenes ha convertido a los slogans en una sentencia breve y dramática que sintetiza los beneficios funcionales y simbólicos de una marca o producto.
Un slogan debe enfatizar algo esencial y si es posible, distintivo de su organización. Desde creencias hasta características y beneficios particulares, un slogan debería explicar por qué una firma es única, o por lo menos, establecer su mensaje principal o ventaja competitiva.
Los slogans han sido parte de la comunicación de las marcas desde el comienzo del Marketing como disciplina.
Los slogans exitosos tienden ha respetar estas simples reglas
- Cortos y simples (3-4 palabras)
- Afirmación positiva
- Recordable
- Atemporal
- Incluye un beneficio / característica clave
- Es original, no es usado por ninguna otra empresa
TIPOS DE SLOGANS
Descriptivos: Tienden a describir lo que la empresa hace
Emocionales: Tienden a expresar un sentimiento relacionado con las empresas
SUGERENCIAS PARA EL DESARROLLO DE UN SLOGAN
1. Piense primero su negocio, y luego su slogan: Un slogan es la síntesis de toda la estrategia de Marketing. Para hallar las 3-4 palabras adecuadas, es necesario que Ud. conozca su mercado, su producto y su competencia:
Mercado: conocer a quién se dirige y cuál es el tipo de discurso que sus clientes comprenden.
Producto: conocer las características de su producto /servicio y los beneficios percibidos por sus clientes.
Competencia: conocer los impulsores de diferenciación de su producto.
Estos aspectos están articulados en su Estrategia de Marketing. Para comunicar su estrategia con éxito, es necesario que haya sido desarrollada previamente. Una vez que Ud. tenga una posicionamiento de empresa / producto / servicio definido, encontrará más fácilmente el concepto a comunicar, y finalmente el slogan que comunique su posicionamiento.
2. Si no es breve y recordable, no es un slogan: Los slogans extensos generan numerosos conflictos, tanto desde un punto de vista gráfico como semántico. Aplicar un slogan extenso en tamaño pequeño (tarjetas de visita, por ejemplo) es gráficamente dificultoso, y perjudicial para la apariencia de la pieza a diseñar.
Durante el proceso de diseño de su logotipo, la inclusión del slogan impacta en la disposición (layout) del diseño. Un slogan extenso obliga al diseñador a adecuar el tamaño del nombre de empresa para mantener su prominencia. Consecuentemente, el isotipo (el "símbolo") debe proporcionarse al nombre y al slogan. Como resultado, el isologotipo queda condicionado por el slogan, en lugar de ser diseñado para comunicar el concepto de su empresa / producto.
Comunicacionalmente, un slogan extenso no genera el impacto buscado, porque incrementa su complejidad lingüística y sintáctica. El slogan se convierte en un objeto de desciframiento que acentúa la mediatización propia del lenguaje. Al desviarse el foco de atención del logotipo al slogan, la "idea" atrás del slogan devora al logotipo.
3. Es mejor bueno después, que malo ahora: La creación de un slogan exige consideraciones y definiciones previas. Si no dispone de un slogan al momento de generar una pieza de comunicación, es preferible no incluirla en ella. Se evitará correcciones posteriores, desperdicio de impresos y principalmente, sus clientes no verán un cambio de mensaje que usualmente es interpretado como un indicio de improvisación y falta de profesionalismo.
Autor: Andrea Nelson
http://www.ars-logo-design.com/ar_slogan.htm
19 junio 2006
Tutorial para presentaciones en PowerPoint o Similares
Este es un post que encontre muy interesante y se los presento. Empieza asi:
Como estudiantes llega un momento en nuestra vida académica en que debemos enfrentarnos al terrible dilema de expresar lo que sabemos ignoramos cuando los profesores pronuncian las temibles palabras “tienen que hacer una presentación de un tema hermoso y desconocido”… ¡Caos, Terror, Confusión, Crisis, Pánico! … Pero no temas, he aquí la solución a todos vuestros problemas:
Como buenos estudiantes estamos listos para enfrentarnos a las presentaciones con el famoso Power Point o programas similares. Después de varios años he observado algunos vicios en mis presentaciones (y en especial en las presentaciones ajenas), así que en esta ocasión te diré la mejor manera de hacer la peor presentación de tu vida porque para hacer buenas presentaciones solamente hay que tener un poco de sentido común…
Lo primero que debes hacer es olvidarte de quién será tu público. Si habrá varios expertos en tu tema lo mejor sería fingir demencia y usar palabras sencillas para que se note que puedes explicarlo con palabras simples. Si tus oyentes están menos informados que tú, entonces lo mejor sería que uses palabras técnicas y rebuscadas para que al no entenderte parezca que sabes más que los expertos.
El Contenido debe ser el peor del universo
Si le pones mucho texto a cada diapositiva no tendrás que aprenderte nada, es más, no tendrás que saber absolutamente nada porque vas a leer sin parar (y sería muchísimo mejor si lees monótonamente o si lo haces como si estuvieras aprendiendo a leer). En caso de que te dé flojera escribir entra a internet y haz “copipeits” (copy-paste, copia y pega) de lo primero que veas… no importa que esté en portugués, creerán que erespolidiota políglota (no le quites los enlaces, se ven bien las palabras subrayadas). Esta técnica tiene beneficios adicionales: si logras hacerla aburrida tu público se dormirá y no tendrás que preocuparte por los nervios.
Cuando necesites presentar datos que no entiendas consíguete una tabla incomprensible y ponla, cuando llegue el momento de explicarla di algo como “los datos se muestran en esta tabla, pero son muchos así que me la voy a saltar” o “… como se muestra en esta tabla, pero no es importante”. Si algún ñoño te pregunta sobre la tabla dile algo como “ahi luego te paso la presentación para que veas los datos”. La gracia de este truco es que podrás saltarte la parte complicada de tu investigación.
En caso de que no puedas hacer una oración larga puedes contar con la famosa técnica de -cantinflear- usa muchas palabras para decir algo sencillo o para despistar a la gente y que parezca que has dicho todo lo que tenías que decir. Infalible.
Lo mejor que puedes hacer para tener una pesima presentación es seguir las tres reglas de oro:
1. Mala redacción
2. Mala ortografía
3. Pésima redatsión y Pésima hortografía
Si la presentación es incómoda y fea… ya lo hiciste.
Los colores contrastantes son lo de hoy (son extremos), abusa de lo brillante porque seguro estarás en un lugar con las luces apagadas. Si no te gusta usar colores chillantes puedes sustituirlo por una fotografía de muchos colores y letras multicolor.
Sugerencia: Fondo verde chillón, letras amarillo-pollo o rosa-mexicano. Fondo con una foto de la playa y letras azul cielo en el cielo.
La animación del texto y las imágenes son buenas para tu presentación porque mantendrán la atención de tu público; pero eso no lo queremos, mejor ponle sonido de máquina de escribir y que se tarde muchísimo en aparecer tu texto que conseguiste con copipeits, así dura más tu presentación y dará la impresión de que hablaste mucho.
Si por alguna misteriosa razón aparece una diapositiva al revés… pásate a la siguiente y deja a todos con la duda, nadie se atreverá a preguntar y si algún infeliz lo hace dile que ignore ese detalle.
Ten en cuenta que las imágenes pequeñas son útiles, en especial cuando las agrandas y muestras una borrosa y pixelada imagen que nadie comprenderá, eso puede ayudarte a evitar tópicos complicados.
Si la presentación es un asco, sólo falta que lo hagas mal para cumplir tu objetivo
Al momento de hacer tu presentación es normal que los nervios te ataquen, así que para empeorarlo todo aprovecha esta situación y deja que las mariposas se adueñen de tu ser.
Tartamudea tanto como puedas (y no olvides cantinflear, como mencioné antes).
Si tienes muletillas al hablar… abusa de ellas y si no usas ninguna puedes alargar las muletillas cortas como: -esteeeee…. , mmmh… , yyy…- o bien utilizar las famosas muletillas de unión (entonces, luego, y despues, etc) y si no te parece suficiente puedes aprovechar de las preguntas que dejan sitio para silencios como -¿me siguen?, ¿me entienden?, ¿me explico?, ¿sí queda claro?. Si todas esas fallan siempre podrás abusar de la odiosa tosesita o el aún más desesperante carraspeo para “afinar la garganta” (si parece pedrada es pura coincidencia *ejem*).
Crúzate de brazos, “baila” o si lo prefieres quédate firme o en posición de -descanso-
Si utilizarás un apuntador láser ten en cuenta que la lucecita es atractiva, agítala sin parar y disfruta de las grandes posibilidades como señalar los renglones que vas leyendo o hacer círculos alrededor de una ecuación o imagen que quieras remarcar y si ninguno aplica… agita tu puntero y finge que señalas algo que no está ahi (tampoco es pedrada, pero suele suceder…).
No hables, mejor susurra. Busca el punto exacto en que el público te oye pero no te entiende y si alguien se queja haz como los japoneses: enfádate y háblable más bajo.
Y naturalmente, nunca hables hacia el público. Habla hacia el proyector, hacia el portátil, hacia la mesa, hacia el suelo… todo menos hablar hacia el público
Y para terminar
Estos son sólo algunos consejitos para que hagas de tus presentaciones lo más odioso del planeta, espero que sea de gran utilidad y recuerda: no practiques antes de hacer tu debut, enfréntate al toro por los cuernos y termina tu presentación diez minutos antes de la clase. Si te sabes algún otro fabuloso tip no olvides pasarnos la receta para que podamos ser mejores cada día.
La regla del 10/20/30: una presentación PowerPoint no debería tener más de 10 hojas, no durar más de 20 minutos y no tener ningún tipo de letra menor de 30.
Extreaido de Alquimistas del Diseño
Como estudiantes llega un momento en nuestra vida académica en que debemos enfrentarnos al terrible dilema de expresar lo que sabemos ignoramos cuando los profesores pronuncian las temibles palabras “tienen que hacer una presentación de un tema hermoso y desconocido”… ¡Caos, Terror, Confusión, Crisis, Pánico! … Pero no temas, he aquí la solución a todos vuestros problemas:
Como buenos estudiantes estamos listos para enfrentarnos a las presentaciones con el famoso Power Point o programas similares. Después de varios años he observado algunos vicios en mis presentaciones (y en especial en las presentaciones ajenas), así que en esta ocasión te diré la mejor manera de hacer la peor presentación de tu vida porque para hacer buenas presentaciones solamente hay que tener un poco de sentido común…
Lo primero que debes hacer es olvidarte de quién será tu público. Si habrá varios expertos en tu tema lo mejor sería fingir demencia y usar palabras sencillas para que se note que puedes explicarlo con palabras simples. Si tus oyentes están menos informados que tú, entonces lo mejor sería que uses palabras técnicas y rebuscadas para que al no entenderte parezca que sabes más que los expertos.
El Contenido debe ser el peor del universo
Si le pones mucho texto a cada diapositiva no tendrás que aprenderte nada, es más, no tendrás que saber absolutamente nada porque vas a leer sin parar (y sería muchísimo mejor si lees monótonamente o si lo haces como si estuvieras aprendiendo a leer). En caso de que te dé flojera escribir entra a internet y haz “copipeits” (copy-paste, copia y pega) de lo primero que veas… no importa que esté en portugués, creerán que eres
Cuando necesites presentar datos que no entiendas consíguete una tabla incomprensible y ponla, cuando llegue el momento de explicarla di algo como “los datos se muestran en esta tabla, pero son muchos así que me la voy a saltar” o “… como se muestra en esta tabla, pero no es importante”. Si algún ñoño te pregunta sobre la tabla dile algo como “ahi luego te paso la presentación para que veas los datos”. La gracia de este truco es que podrás saltarte la parte complicada de tu investigación.
En caso de que no puedas hacer una oración larga puedes contar con la famosa técnica de -cantinflear- usa muchas palabras para decir algo sencillo o para despistar a la gente y que parezca que has dicho todo lo que tenías que decir. Infalible.
Lo mejor que puedes hacer para tener una pesima presentación es seguir las tres reglas de oro:
1. Mala redacción
2. Mala ortografía
3. Pésima redatsión y Pésima hortografía
Si la presentación es incómoda y fea… ya lo hiciste.
Los colores contrastantes son lo de hoy (son extremos), abusa de lo brillante porque seguro estarás en un lugar con las luces apagadas. Si no te gusta usar colores chillantes puedes sustituirlo por una fotografía de muchos colores y letras multicolor.
Sugerencia: Fondo verde chillón, letras amarillo-pollo o rosa-mexicano. Fondo con una foto de la playa y letras azul cielo en el cielo.
La animación del texto y las imágenes son buenas para tu presentación porque mantendrán la atención de tu público; pero eso no lo queremos, mejor ponle sonido de máquina de escribir y que se tarde muchísimo en aparecer tu texto que conseguiste con copipeits, así dura más tu presentación y dará la impresión de que hablaste mucho.
Si por alguna misteriosa razón aparece una diapositiva al revés… pásate a la siguiente y deja a todos con la duda, nadie se atreverá a preguntar y si algún infeliz lo hace dile que ignore ese detalle.
Ten en cuenta que las imágenes pequeñas son útiles, en especial cuando las agrandas y muestras una borrosa y pixelada imagen que nadie comprenderá, eso puede ayudarte a evitar tópicos complicados.
Si la presentación es un asco, sólo falta que lo hagas mal para cumplir tu objetivo
Al momento de hacer tu presentación es normal que los nervios te ataquen, así que para empeorarlo todo aprovecha esta situación y deja que las mariposas se adueñen de tu ser.
Tartamudea tanto como puedas (y no olvides cantinflear, como mencioné antes).
Si tienes muletillas al hablar… abusa de ellas y si no usas ninguna puedes alargar las muletillas cortas como: -esteeeee…. , mmmh… , yyy…- o bien utilizar las famosas muletillas de unión (entonces, luego, y despues, etc) y si no te parece suficiente puedes aprovechar de las preguntas que dejan sitio para silencios como -¿me siguen?, ¿me entienden?, ¿me explico?, ¿sí queda claro?. Si todas esas fallan siempre podrás abusar de la odiosa tosesita o el aún más desesperante carraspeo para “afinar la garganta” (si parece pedrada es pura coincidencia *ejem*).
Crúzate de brazos, “baila” o si lo prefieres quédate firme o en posición de -descanso-
Si utilizarás un apuntador láser ten en cuenta que la lucecita es atractiva, agítala sin parar y disfruta de las grandes posibilidades como señalar los renglones que vas leyendo o hacer círculos alrededor de una ecuación o imagen que quieras remarcar y si ninguno aplica… agita tu puntero y finge que señalas algo que no está ahi (tampoco es pedrada, pero suele suceder…).
No hables, mejor susurra. Busca el punto exacto en que el público te oye pero no te entiende y si alguien se queja haz como los japoneses: enfádate y háblable más bajo.
Y naturalmente, nunca hables hacia el público. Habla hacia el proyector, hacia el portátil, hacia la mesa, hacia el suelo… todo menos hablar hacia el público
Y para terminar
Estos son sólo algunos consejitos para que hagas de tus presentaciones lo más odioso del planeta, espero que sea de gran utilidad y recuerda: no practiques antes de hacer tu debut, enfréntate al toro por los cuernos y termina tu presentación diez minutos antes de la clase. Si te sabes algún otro fabuloso tip no olvides pasarnos la receta para que podamos ser mejores cada día.
La regla del 10/20/30: una presentación PowerPoint no debería tener más de 10 hojas, no durar más de 20 minutos y no tener ningún tipo de letra menor de 30.
Extreaido de Alquimistas del Diseño
01 junio 2006
Las 20 respuestas que más utilizan los programadores cuando sus programas no funcionan
He leido en un blog este post y me ha parecido muy gracioso, y también muy verdadero, yo personalmente he utilizado más de 10 de los que quí aparecen.
¿Cuantos de estos has utilizado tú?
Las 20 respuestas que más utilizan los programadores cuando sus programas no funcionan:
20. “Pues es raro…”
19. “Nunca había pasado antes.”
18. “Pues ayer funcionaba…”
17. “¿Cómo es posible?”
16. “Tiene que ser un problema de tu hardware.”
15. “¿Qué hiciste mal para lograr que fallara?”
14. “Algo debe de estar mal en tus datos.”
13. “¡Si no he tocado ese módulo en meses!”
12. “Debes de estar usando una versión anterior.”
11. “Es sólo una desafortunada coincidencia.”
10. “¡Es que no lo puedo probar todo!”
9. “ESTO, no puede ser la causa de ESO.”
8. “Funciona, pero no lo he probado.”
7. “¡Alguien debe de haber cambiado mi código!”
6. “¿Has comprobado que no haya algún virus en tu sistema?”
5. “Ya se que no funciona, ¿pero te gusta?”
4. “No puedes utilizar esa versión en tu sistema”
3. “¿Por qué quieres hacer eso?”
2. “¿Y tú dónde estabas cuando se colgó el programa?”
Y la respuesta número uno de los programadores con programas que no funcionan es:
1. “¡EN MI MÁQUINA SI FUNCIONA!”
Extreaido de Mundo Geek
¿Cuantos de estos has utilizado tú?
Las 20 respuestas que más utilizan los programadores cuando sus programas no funcionan:
20. “Pues es raro…”
19. “Nunca había pasado antes.”
18. “Pues ayer funcionaba…”
17. “¿Cómo es posible?”
16. “Tiene que ser un problema de tu hardware.”
15. “¿Qué hiciste mal para lograr que fallara?”
14. “Algo debe de estar mal en tus datos.”
13. “¡Si no he tocado ese módulo en meses!”
12. “Debes de estar usando una versión anterior.”
11. “Es sólo una desafortunada coincidencia.”
10. “¡Es que no lo puedo probar todo!”
9. “ESTO, no puede ser la causa de ESO.”
8. “Funciona, pero no lo he probado.”
7. “¡Alguien debe de haber cambiado mi código!”
6. “¿Has comprobado que no haya algún virus en tu sistema?”
5. “Ya se que no funciona, ¿pero te gusta?”
4. “No puedes utilizar esa versión en tu sistema”
3. “¿Por qué quieres hacer eso?”
2. “¿Y tú dónde estabas cuando se colgó el programa?”
Y la respuesta número uno de los programadores con programas que no funcionan es:
1. “¡EN MI MÁQUINA SI FUNCIONA!”
Extreaido de Mundo Geek
05 enero 2006
eXtreme Programming
La programación extrema (eXtreme Programming) o XP, es una disciplina de desarrollo basada en la simplicidad. XP aparece para, que equipos pequeños que necesitan desarrollar software rápidamente, puedan realizarlo en un ambiente donde los requisitos cambian rápidamente.
La metodología de Desarrollo de Software, siempre necesitará ser modificada para adaptarla a los requisitos particulares del cliente y de las circunstancias. XP no es ninguna excepción.
Hay doce prácticas para aplicar XP:
El proceso de planteamiento o juego de la planificación
Permite que el XP cliente defina el valor de negocio y las características deseadas, y utiliza las valoraciones de coste proporcionadas por los programadores, para elegir si necesita ser desarrollado o dejar aparcado. Con este proceso es fácil llevar el proyecto a “buen puerto”.
Entregas pequeñas
La idea es producir rápidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad, pero constituyan un resultado de valor para el negocio.
Metáfora
Una metáfora, es una historia compartida que describe cómo debería funcionar el sistema. El sistema es definido por una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. La metáfora consiste en formar un conjunto de nombres que actúen como vocabulario para hablar sobre el dominio del problema.
Diseño simple
Se debe diseñar la solución más simple que puede funcionar y ser implementada en un momento determinado del proyecto. La complejidad innecesaria y el código extra debe ser removido inmediatamente.
Pruebas
La producción de código está dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el código y son ejecutadas constantemente ante cada modificación del sistema. En este desarrollo y pruebas constantes, la automatización para apoyar esta actividad es crucial.
Refactorización (Refactoring)
La refactorización es una actividad constante de reestructuración del código con el fin de remover duplicación de código, mejorar legibilidad, simplificarlo y hacerlo más flexible para facilitar los posteriores cambios. Para mantener un diseño apropiado, es necesario realizar actividades de cuidado continuo durante el ciclo de vida del proyecto.
Programación en parejas
Toda la producción de código debe realizarse en parejas de programadores. Muchos errores son detectados conforme son introducidos y la tasa de errores del producto final son mucho menores, los diseños son mejores y el tamaño del código menor, los problemas de programación se resuelven más rápido, se transfieren los conocimientos de programación entre los miembros del equipo, varias personas entienden las diferentes partes del sistema, mejora el flujo de información y la dinámica del equipo.
Propiedad colectiva
Cualquier programador puede cambiar cualquier parte del código en cualquier momento. Esta práctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la vez que algún programador sea imprescindible para realizar cambios en alguna porción de código.
Integración continúa
Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema puede llegar a ser integrado y construido varias veces en un mismo día. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea incorporado definitivamente. La integración continua a menudo reduce la fragmentación de los esfuerzos de los desarrolladores por falta de comunicación sobre lo que puede ser reutilizado o compartido. Esto es esencial para un proyecto controlado.
40 horas por semana
Se debe trabajar un máximo de 40 horas por semana. No se trabajo horas extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que debe corregirse. El trabajo extra desmotiva el equipo. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificación para cambiar el ámbito del proyecto o la fecha de entrega.
Cliente in-situ
El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte del éxito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportará mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. Algunas recomendaciones propuestas para dicha situación son las siguientes: intentar conseguir un representante que pueda estar siempre disponible y que actúe de interlocutor del cliente, contar con el cliente al menos en las reuniones de planificación, establecer visitaqs frecuentes de los programadores al cliente para validar el sistema, anticiparse a los problemas aosociados estableciendo llamadas telefónicas frecuentes y conferencias, reforzando el compromiso de trabajo en equipo.
Estándares de programación
Es indispensable que se sigan ciertos estándares de programación. Estos mantienen el código legible para los miembros del equipo, facilitando los cambios.
Todas estas prácticas, se refuerzan entre sí.
Fuente original seraKesi.com
Extreme Programming
La metodología de Desarrollo de Software, siempre necesitará ser modificada para adaptarla a los requisitos particulares del cliente y de las circunstancias. XP no es ninguna excepción.
Hay doce prácticas para aplicar XP:
El proceso de planteamiento o juego de la planificación
Permite que el XP cliente defina el valor de negocio y las características deseadas, y utiliza las valoraciones de coste proporcionadas por los programadores, para elegir si necesita ser desarrollado o dejar aparcado. Con este proceso es fácil llevar el proyecto a “buen puerto”.
Entregas pequeñas
La idea es producir rápidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad, pero constituyan un resultado de valor para el negocio.
Metáfora
Una metáfora, es una historia compartida que describe cómo debería funcionar el sistema. El sistema es definido por una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. La metáfora consiste en formar un conjunto de nombres que actúen como vocabulario para hablar sobre el dominio del problema.
Diseño simple
Se debe diseñar la solución más simple que puede funcionar y ser implementada en un momento determinado del proyecto. La complejidad innecesaria y el código extra debe ser removido inmediatamente.
Pruebas
La producción de código está dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el código y son ejecutadas constantemente ante cada modificación del sistema. En este desarrollo y pruebas constantes, la automatización para apoyar esta actividad es crucial.
Refactorización (Refactoring)
La refactorización es una actividad constante de reestructuración del código con el fin de remover duplicación de código, mejorar legibilidad, simplificarlo y hacerlo más flexible para facilitar los posteriores cambios. Para mantener un diseño apropiado, es necesario realizar actividades de cuidado continuo durante el ciclo de vida del proyecto.
Programación en parejas
Toda la producción de código debe realizarse en parejas de programadores. Muchos errores son detectados conforme son introducidos y la tasa de errores del producto final son mucho menores, los diseños son mejores y el tamaño del código menor, los problemas de programación se resuelven más rápido, se transfieren los conocimientos de programación entre los miembros del equipo, varias personas entienden las diferentes partes del sistema, mejora el flujo de información y la dinámica del equipo.
Propiedad colectiva
Cualquier programador puede cambiar cualquier parte del código en cualquier momento. Esta práctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la vez que algún programador sea imprescindible para realizar cambios en alguna porción de código.
Integración continúa
Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema puede llegar a ser integrado y construido varias veces en un mismo día. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea incorporado definitivamente. La integración continua a menudo reduce la fragmentación de los esfuerzos de los desarrolladores por falta de comunicación sobre lo que puede ser reutilizado o compartido. Esto es esencial para un proyecto controlado.
40 horas por semana
Se debe trabajar un máximo de 40 horas por semana. No se trabajo horas extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que debe corregirse. El trabajo extra desmotiva el equipo. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificación para cambiar el ámbito del proyecto o la fecha de entrega.
Cliente in-situ
El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte del éxito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportará mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. Algunas recomendaciones propuestas para dicha situación son las siguientes: intentar conseguir un representante que pueda estar siempre disponible y que actúe de interlocutor del cliente, contar con el cliente al menos en las reuniones de planificación, establecer visitaqs frecuentes de los programadores al cliente para validar el sistema, anticiparse a los problemas aosociados estableciendo llamadas telefónicas frecuentes y conferencias, reforzando el compromiso de trabajo en equipo.
Estándares de programación
Es indispensable que se sigan ciertos estándares de programación. Estos mantienen el código legible para los miembros del equipo, facilitando los cambios.
Todas estas prácticas, se refuerzan entre sí.
Fuente original seraKesi.com
Extreme Programming
02 noviembre 2005
Nomenclatura propuesta para la denominación de Funciones/Procedimientos y/o Variables
Cuando escribimos un programa y definimos variables, funciones o procedimientos acostumbramos a colocarle un nombre descriptivo que nos dice de cierta manera que guarda la variable o que hace la función.
Ejemplo: si guardamos la suma de algún procedimiento en una variable, le podríamos poner a la variable SUMA, o si alguna función realiza una suma de dos números, le colocamos como nombre a la función SumaDosNumeros( ), etc.
Pero la descripción que le damos a nuestra variable o función, no nos entrega más información, como por ejemplo en el caso de una variable, el ámbito de la variable, el tipo de dato de la variable, la funcionalidad de la variable si es pasada la variable por referencia o por valor, etc. En el caso de una función podría interesarnos conocer el alcance de la función, el resultado que nos devuelve la función (tipo de dato), etc.
Es por todo lo anterior que se propone una nomenclatura para la denominación de Funciones/Procedimientos y/o variables:
1º Funcionalidad del identificador
v : Variable
p : Parámetro
f : Función o Procedimiento
c : Constante
t : Tipo Definido por el Usuario -(Cuando se crea)
2º Alcance de Identificador
p : Private
g : Global o public
l : Local
v : ByVal
c : ByRef
3º Tipología de resultado para function, variable (atributo), parámetro
s : String
o : Object
i : Integer
l : Long
b : Boolean
t : Tipo Definido por el Usuario-(Cuando se usa)
v : Variant
n : Sin resultado (ejecución como procedimiento)
Por ejemplo si tenemos la variable denominada SUMA en nuestro código, podriamos usar la nomenclatura y denominarla de la siguiente manera:
VPI_SUMA // En este caso se trata de una variable, de tipo privada y con tipo de dato Integer.
Luego para nuestra función SumaDosNumeros( ), podriamos usar la nomenclatura y nos quedaría:
FLI_SumaDosNumeros( ) // En este caso se trata de una función con ámbito local y devuelve un Integer.
Nomenclatura para la denominación objetos gráficos
SynthText : txt
SynthList : lst
PushButton : cmd
CheckBox : chk
Label : lbl
Grids (Grilla) : grd
Frame : fra
Form : frm
Nomenclatura propuesta por el Sr. David Contreras, docente de la Universidad Arturo Prat de Iquique.
Ejemplo: si guardamos la suma de algún procedimiento en una variable, le podríamos poner a la variable SUMA, o si alguna función realiza una suma de dos números, le colocamos como nombre a la función SumaDosNumeros( ), etc.
Pero la descripción que le damos a nuestra variable o función, no nos entrega más información, como por ejemplo en el caso de una variable, el ámbito de la variable, el tipo de dato de la variable, la funcionalidad de la variable si es pasada la variable por referencia o por valor, etc. En el caso de una función podría interesarnos conocer el alcance de la función, el resultado que nos devuelve la función (tipo de dato), etc.
Es por todo lo anterior que se propone una nomenclatura para la denominación de Funciones/Procedimientos y/o variables:
1º Funcionalidad del identificador
v : Variable
p : Parámetro
f : Función o Procedimiento
c : Constante
t : Tipo Definido por el Usuario -(Cuando se crea)
2º Alcance de Identificador
p : Private
g : Global o public
l : Local
v : ByVal
c : ByRef
3º Tipología de resultado para function, variable (atributo), parámetro
s : String
o : Object
i : Integer
l : Long
b : Boolean
t : Tipo Definido por el Usuario-(Cuando se usa)
v : Variant
n : Sin resultado (ejecución como procedimiento)
Por ejemplo si tenemos la variable denominada SUMA en nuestro código, podriamos usar la nomenclatura y denominarla de la siguiente manera:
VPI_SUMA // En este caso se trata de una variable, de tipo privada y con tipo de dato Integer.
Luego para nuestra función SumaDosNumeros( ), podriamos usar la nomenclatura y nos quedaría:
FLI_SumaDosNumeros( ) // En este caso se trata de una función con ámbito local y devuelve un Integer.
Nomenclatura para la denominación objetos gráficos
SynthText : txt
SynthList : lst
PushButton : cmd
CheckBox : chk
Label : lbl
Grids (Grilla) : grd
Frame : fra
Form : frm
Nomenclatura propuesta por el Sr. David Contreras, docente de la Universidad Arturo Prat de Iquique.
