Depuración de JavaScript

En The 16 JavaScript debugging tips you probably didn’t know se explican 16 técnicas que ayudan a depurar el código JavaScript:

  1. debugger
  2. Display objects as a table
  3. Try all the sizes
  4. How to find your DOM elements quickly
  5. Benchmark loops using console.time() and console.timeEnd()
  6. Get the stack trace for a function
  7. Unminify code as an easy way to debug JavaScript
  8. Quick-find a function to debug
  9. Black box scripts that are NOT relevant
  10. Find the important things in complex debugging
  11. Watch specific function calls and arguments
  12. Quickly access elements in the console
  13. Postman is great (but Firefox is faster)
  14. Break on node change
  15. Use page speed services
  16. Breakpoints everywhere

El lenguaje que casi se convierte en CSS

Muy interesante el artículo The Languages Which Almost Became CSS que dice:

When HTML was announced by Tim Berners-Lee in 1991 there was no method of styling pages. How given HTML tags were rendered was determined by the browser, often with significant input from the user’s preferences. It seemed, however, like a good idea to create a standard way for pages to ‘suggest’ how they might prefer to be rendered stylistically.

But CSS wouldn’t be introduced for five years, and wouldn’t be fully implemented for ten. This was a period of intense work and innovation which resulted in more than a few competing styling methods which just as easily could have become the standard.

While these languages are obviously not in common use today, I find it fascinating to think about the world that might have been. Even more surprisingly, it happens that many of these other options include features which developers would love to see appear in CSS even today.

¿Por qué no todo el mundo es un buen programador?

Muy interesante la pregunta y la respuesta planteadas en Why is everyone not a programmer? en Quora:

While just about anyone, at almost any age or IQ level, can learn the concepts of writing code, to become an employable, professional software developer with any hope of long-term success, a person needs:

  • Logical thinking skills.
  • Excellent problem-solving skills.
  • A methodical approach to solving problems.
  • A passion for software development.
  • A willingness and ability to keep learning new things (e.g., languages, paradigms, design patterns, libraries, frameworks, data structures, algorithms, etc.) throughout their entire career. The learning never ever stops in this business. If you stop learning, you will fall behind and limit your opportunities.
  • Excellent written and oral communication skills. From writing documentation or code comments to providing feedback in code reviews to making presentations to defending your design decisions, communication is key in this business.
  • Patience. You need a lot of this. The list of people and situations that will try your patience is too long to even begin to list here.
  • Persistence. You need a lot of this, especially after you’ve been chasing a difficult bug for many hours or days.
  • Attention to even the most minute detail. One binary digit (bit) can have a huge effect on how something works or doesn’t work.
  • Attention to quality.
  • A willingness and ability to dive in and learn about the domain you’re writing code for, to gain a better understanding of client/user needs, terminology, concepts, etc. For example, if you’re programming financial systems, you need to learn about financial concepts. If you’re developing statistical software, you need to dig in and learn about statistics. If you’re developing simulations, you might need to roll up your sleeves and learn about astrophysics, string theory, ecological systems, etc. If you’re writing network software, you need to learn about networking. If you’re writing software to drive industrial chemical processes, you need to learn about the chemicals and processes you’re working with. (See this answer for an example.) Device drivers require learning about hardware devices. Process control software might require learning about chemical reactions. The list goes on and on.

    (One of the many things I enjoy about software development is all the other areas I’ve had a chance to learn about over the decades, in addition to the typical computer science and software engineering arenas.)

  • Compassion and empathy for the next developer who needs to read/maintain your code.
  • Compassion and empathy for the users of the software you’re developing.
  • The ability to read and interpret technical information quickly, and apply it to the task at hand (e.g., hardware datasheets, algorithm descriptions, best practices, etc.).

This is not an exhaustive list, but it gives you a general idea of the attributes you need for long-term success in software development.

Obviously, not everyone has all of these attributes. Although some can be learned/acquired, some are more fundamental to the personality and life experience of the individual.

Just as not everyone can become a professional brain surgeon, astronaut, soldier, aeronautical engineer, nurse, teacher, firefighter, lawyer, concert pianist, rock star, actor, cinematographer, carpenter, plumber, architect, sculptor, rocket scientist, pilot, etc., not everyone can be a professional software developer.

That said, I strongly believe in people — of all walks of life — having the opportunity to learn new skills, improve themselves, change careers, make themselves more employable, and go after their dreams.

In addition to being a software developer, I have taught software engineering and computer science courses to many aspiring software developers, across many ages, races, economic backgrounds, religions, previous careers, etc. Some have gone on to success in this field. Others have used the opportunity to discover that software development was not for them. A software development career is not for everyone. But, all should have the opportunity to learn and decide for themselves.

 

¿Por qué la página “home page” se llama “home page”?

Muy interesante y nostálgico lo que se explica en Why Do We Call it a Homepage?:

Berners-Lee imagined that each person would have their own little space on the web. They could add whatever bookmarks or notes they wanted to their page. They could make it public or keep it private. When they opened their browsers, they would be met with their personal website. And using their browser they could quickly make updates and publish changes to their site. The web, in other words, was meant to go both ways. We were meant to be both participants and consumers.

That space on the web, Berners-Lee called it a home page. It made sense. It was a digital “home” on the web. A space you could come back to and add the discoveries you made surfing the web. And that’s how the word home page began to circulate.