Cómo trabajo: Doug Crockford de Yahoo! sobre JavaScript

 

 

 

  • Implemente rápidamente. Implementar inteligentemente
  • ¡Registro!

  • Índice
    1. Conoce a Doug Crockford
    2. Lecturas adicionales sobre SmashingMag:
      1. ¿Por qué crees que los programadores deberían estudiar la historia de la informática?
      2. ¿Cuáles fueron los rasgos de los programadores débiles que has visto a lo largo de tu carrera?
      3. ¿Cree que el dolor que sufre un programador al aprender un idioma contribuye a este apego poco saludable a utilizar un solo idioma?
      4. En Coders at Work , enfatizas la importancia de realizar lecturas de código con equipos. ¿Por qué cree que es importante presentar su código frente a otras personas?
      5. ¿Están mejorando los programadores en la empatía del usuario?
      6. ¿Cuánto de un idioma necesitas saber?
      7. ¿Qué enfoques dirías que tiene un maestro frente a un principiante?
      8. ¿Qué piensas sobre jQuery? Algunos entusiastas de JS sienten que esto libera a las personas de aprender JS de verdad.
      9. Cuando estabas desarrollando JSON, ¿fue difícil retroceder y no dedicarle demasiado?
      10. ¿Cómo se adoptó JSON?
    3. Mire a Doug Crockford en Google hablando sobre "JavaScript: The Good Parts"
    4. Más información sobre la saga JSON

    Bienvenido a la primera de una nueva serie de entrevistas llamada "Cómo trabajo". Estas entrevistas giran en torno a cómo los pensadores y creadores del mundo web diseñan, codifican y crean.

     

    El objetivo no es entrar en los matices específicos de su oficio (ya que esa información ya existe en línea), sino dar un paso atrás y aprender un poco sobre sus hábitos, filosofías y flujo de trabajo para producir un gran trabajo.

    Conoce a Doug Crockford

    El primero es Douglas Crockford, quien cree que JavaScript podría ser el lenguaje más elegante que existe. Descubra por qué cree que debería estudiar la historia de la informática, el valor de leer su código delante de otras personas y que jQuery es realmente algo bueno.

    Lecturas adicionales sobre SmashingMag:

    • Duane Bray de IDEO sobre la creación de excelentes experiencias digitales
    • Una entrevista con Matan Stauber
    • La entrevista de diseño UX de Nancy Dickenson

    Douglas Crockford es conocido como el chico de JavaScript. Es famoso no solo por su libro de O'Reilly JavaScript: The Good Parts , sino aún más por ser el visionario detrás del formato de datos JSON y de la herramienta JSLint . Apareció en el libro Coders at Work por sus contribuciones y filosofías sobre lo que JavaScript hizo bien y lo que no.

    Como nativo del sur de California, Doug tiene la constitución de un surfista; delgado y alto con pelo blanco y barba. Un veterano de Silicon Valley, trabajó en Atari Labs, fundó y trabajó en numerosas empresas emergentes de software, fue jefe de tecnología en Lucas Films y ahora tiene el envidiable trabajo de ser un evangelista de JavaScript en Yahoo!.

    Los créditos de las imágenes son para Eric Miraglia .

    Autodidacta (como lo son muchos de los grandes), dice que su objetivo es simplemente lograr que más personas codifiquen en JavaScript o en cualquier lenguaje. Si bien su trabajo diario puede ser el de evangelista de JavaScript, al hablar con Doug tienes la sensación de que realmente es un evangelista de la programación en general.

    A continuación se muestra una conversación que tuvo lugar en Bozeman, Montana, antes de una charla en la Universidad Estatal de Montana. Doug compartió libremente sus pensamientos sobre los grandes programadores, la empatía de los usuarios y cómo JSON le restauró la fe en la humanidad.

    ¿Por qué crees que los programadores deberían estudiar la historia de la informática?

    Bueno, el primer semestre de física es una clase de historia. Estudias a Galileo y Newton y todas sus contribuciones al campo y eso nos da una visión general de la física. Es un buen lugar para empezar.

     

    Ojalá CS hiciera eso. No parece tener suficiente valor en su historia y es una historia realmente sorprendente que está completamente descuidada. Es raro que gane la mejor idea. Entonces, hemos tomado caminos diferentes a lo largo de los años y tal vez no nos hayamos dado cuenta de por qué.

    Irónicamente, a pesar del ritmo de cambio en la tecnología, vemos en la historia del software que se necesita una generación para jubilarse o morir antes de que tengamos una masa crítica de mentes jóvenes brillantes para abrazar nuevas ideas.

    Creo que si la gente fuera más consciente de su historia, podría ver estos patrones más fácilmente.

    ¿Cuáles fueron los rasgos de los programadores débiles que has visto a lo largo de tu carrera?

    Esa es una pregunta fácil: falta de curiosidad. Estaban tan satisfechos con el trabajo que estaban haciendo que era lo suficientemente bueno (sin entender qué era "bueno") que no se esforzaron.

    Me impresionan mucho más las personas que siempre están aprendiendo. Los brillantes programadores con los que he estado siempre están aprendiendo.

    Ves a tantas personas que aprenden un idioma y pasan toda su carrera en ese idioma y, como resultado, no son tan buenos programadores.

    ¿Cree que el dolor que sufre un programador al aprender un idioma contribuye a este apego poco saludable a utilizar un solo idioma?

    Mi consejo a los programadores para evitar esta trampa es que aprendan muchos lenguajes diferentes. Estamos en una especie de renacimiento lingüístico en este momento y hay un montón de idiomas brillantes de los que aprender.

    Aprender nuevos idiomas requiere noches y fines de semana fuera del trabajo, y eso es un compromiso. Los grandes programadores son las personas que constantemente eligen un proyecto y se sumergen en él, aprendiendo un idioma de esa manera. Pirateking Ver anime gratis online

    En Coders at Work , enfatizas la importancia de realizar lecturas de código con equipos. ¿Por qué cree que es importante presentar su código frente a otras personas?

    Bueno, a lo largo de los años me di cuenta de que hay algunos programadores fantásticos que están completamente contentos de sentarse en su cueva todo el día escribiendo código brillante. Pero no interactúan mucho con su equipo, lo que significa que es una oportunidad perdida para asesorar a otros miembros.

    Como sabes, muchos programadores tampoco son los animales más aptos socialmente.

    Entonces, mi idea con las sesiones de lectura de códigos es proporcionar un foro donde las personas puedan reunirse y leer entre sí para sacarlos de sus cuevas. Los maestros leen para los principiantes y viceversa, como un ejercicio de formación de equipos.

    El truco para el éxito es establecer reglas con anticipación para que nadie reciba una paliza y todos sean respetuosos en sus comentarios. Tiene que ser una buena experiencia de aprendizaje para todos. Hay que tener cuidado con un equipo disfuncional, porque rápidamente puede destrozar al grupo. Pero siempre doy por finalizado el juego antes de que llegue tan lejos.

    Las reglas son que se trata de mejorar la calidad del código del que todos somos responsables, mejorar la calidad de nuestro equipo y mejorar nuestras capacidades individuales.

    Algunas personas ven esto como una terrible pérdida de tiempo. Sin embargo, descubrí que al hacer este ejercicio los errores se detectan con mucha anticipación y se puede evitar que un miembro del equipo se salga del camino. Pero repito, ese no es el objetivo, se trata de formar equipos.

     

    Con el tiempo, los maestros ayudan a mejorar a los principiantes y el rendimiento general del equipo mejora.

    ¿Están mejorando los programadores en la empatía del usuario?

    La mejor experiencia que tuve con la empatía fue trabajar en soporte de marketing. Hubo momentos en que salía al campo y tomaba de la mano a los clientes y veía de primera mano las consecuencias de algunas de las tonterías que les estábamos entregando.

    Me sorprendió cuando pasé a la programación de sistemas y cómo los programadores realmente despreciaban al cliente.

    Creo que todo programador debería trabajar en la atención al cliente del producto que ofrece.

    Es otro caso de sobreespecialización. “Sólo escribo el código”, es la respuesta que se obtiene y los programadores no lo ven como una oportunidad para mejorar la vida de las personas.

    ¿Cuánto de un idioma necesitas saber?

    Prácticamente todos los lenguajes de programación son demasiado grandes. Los estándares lingüísticos tienen dificultades para eliminar funciones innecesarias, pero como usuarios podemos optar por no utilizarlas.

    Yo diría que puedes hacerlo al 100% conociendo el 50% del idioma.

    El lenguaje que más me enseñó esa lección fue JavaScript, porque tiene más partes malas que buenas. Me dio una motivación muy fuerte para descubrir cuáles son las partes buenas y las malas, y cuál es el criterio para decidir qué está dentro o fuera.

    Y las partes buenas son tan buenas. Asegúrese de ver la charla técnica de Google de Doug titulada " JavaScript: The Good Parts ".

    ¿Qué enfoques dirías que tiene un maestro frente a un principiante?

    Cuando era oficial, era maximilista. Intenté utilizar todo el idioma. Si bien no sé si ahora me consideraría un maestro, ciertamente soy minimalista. He tratado de mejorar en el uso de la menor cantidad de lenguaje posible.

    Le doy mucho valor a la sencillez y el minimalismo.

    ¿Qué piensas sobre jQuery? Algunos entusiastas de JS sienten que esto libera a las personas de aprender JS de verdad.

    Hay algunas cosas realmente inteligentes en jQuery y creo que John Resig hizo un muy buen trabajo allí.

    Tengo un problema con que alguien haga algo sin entender lo que está haciendo. No voy a culpar a jQuery por atraer ese tipo de personas.

    Pero sí creo que hay otras bibliotecas AJAX que quizás estén haciendo un mejor trabajo y que no son tan accesibles. Sin embargo, creo que hay un lugar para todas estas cosas.

    Cuando estabas desarrollando JSON, ¿fue difícil retroceder y no dedicarle demasiado?

    Mis criterios de diseño fueron tres cosas: mínimo, contextual y un subconjunto de JavaScript.

    La última limitación era evitar que nos descarriláramos e inventáramos cosas nuevas. Tuvimos que usar solo cosas que estaban en JavaScript, lo que significaba que nuestro manejo de Unicode no era del todo correcto porque JS no es del todo correcto, lo cual fue decepcionante. No tenemos soporte adecuado para fechas porque JS no lo tenía. Pero podemos solucionar ambos problemas.

    Pero también significaba que cuando alguien proponía: "Oye, deberíamos hacer esta locura", podríamos decir "No". Entonces, teníamos un criterio realmente sencillo para evitar que se agregaran funciones adicionales.

     

    Una historia interesante sobre omitir cosas: a medida que nos acercábamos al lanzamiento de JSON, decidí eliminar la posibilidad de hacer comentarios. Al traducir JSON a otros idiomas, muchas veces el comentario era la parte más complicada. Al eliminar los comentarios redujimos la complejidad de los analizadores a la mitad; todo lo demás era demasiado simple.

    Una de las mejores características de JSON es que es estable. Si su programa funciona ahora, funcionará para siempre, y eso es algo atractivo.

    Todavía recibo notas de personas que dicen que tienen grandes ideas para la próxima versión. Pero no habrá una próxima versión. Siempre digo que eres libre de inventar un nuevo estándar y promoverlo tanto como quieras.

    ¿Cómo se adoptó JSON?

    Ya sabes, la adopción de JSON de alguna manera restauró mi fe en la humanidad porque fue una buena idea la que ganó, solo porque era una buena idea.

    Fue un caso en el que no hubo campañas de marketing ingeniosas. En 2001, comencé a trabajar en ello como una forma de vincular los navegadores al servidor. En ese momento, todos pensaban que había que usar XML o decían "es una gran idea, pero JSON no es un estándar". Entonces, compré json.org, hice un logotipo, abrí una página web y permaneció fuera de la red durante tres años.

    Mientras tanto, apareció AJAX y cuando se convirtió en la forma de escribir aplicaciones, JSON estaba ahí. Por supuesto, hubo una contrapromoción por parte de la comunidad XML.

    Pero cuando llegué a Yahoo! Algunos chicos de la empresa empezaron a pensar que estaba bien empezar a enviar API JSON a través de servicios web. Y los desarrolladores descubrieron que las aplicaciones se volvían más rápidas y más fáciles de escribir.

    De alguna manera despegó a partir de ahí, sin campañas ingeniosas. Así que por una vez ganó una buena idea basada en la simplicidad.

    Mire a Doug Crockford en Google hablando sobre "JavaScript: The Good Parts"

    En esta presentación de Google Tech Talks, Doug repasa las ideas detrás de su libro histórico, JavaScript: The Good Parts, y profundiza en las áreas de lo que JavaScript hizo bien y lo que no. Conozca la historia y los obstáculos comunes que encuentran los programadores cuando desarrollan con este lenguaje.

    Más información sobre la saga JSON

    En este vídeo, Doug cuenta la interesante historia de cómo se descubrió JSON y arroja algo de luz sobre cómo se convirtió en un estándar importante para describir datos en un interesante giro de los acontecimientos.

    (jvb) (il)

    Explora más en

    • Codificación
    • Flujo de trabajo
    • javascript





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Cómo trabajo: Doug Crockford de Yahoo! sobre JavaScript

    Cómo trabajo: Doug Crockford de Yahoo! sobre JavaScript

    Implemente rápidamente. Implementar inteligentemente ¡Registro! Índice Conoce a Doug Crockford

    programar

    es

    https://aprendeprogramando.es/static/images/programar-como-trabajo-doug-crockford-de-yahoo-sobre-javascript-795-0.jpg

    2024-05-20

     

    Cómo trabajo: Doug Crockford de Yahoo! sobre JavaScript
    Cómo trabajo: Doug Crockford de Yahoo! sobre JavaScript

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20