Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome developer tools to master

apsdehal.in

Post reply on HN
Print view View original

61–70 of 100 posts

Re: Chrome developer tools to master

#61

Post by ruckusing »

0xfeba wrote: post #3

I implemented two simple interview tests in order to weed out people who can't do simple debugging. In one, I hand them my laptop and give them a basic create-react-app sample that uses fetch on a remote URL, but there's a typo in the URL. I tell them it's supposed to fetch a remote REST API and parse the JSON but it doesn't work--how would you fix it? So far, two ways to pass: Just look at the source code, or use th…

Yeah I'd grab the URL and feed it to curl on the command line to start inspecting the HTTP traffic and start from there.

Re: Chrome developer tools to master

#62

Post by allannienhuis »

adrianhel wrote: post #28
adrianhel wrote: post #27

Earlier quoted context omitted.

Appreciate the simplicity of the test. With CRA-type debugging, my colleague thought that was how debugging was done with web dev in general (which would have been awesome!) He was fresh out of uni. A lot of console logging gives you a indicator that the person either doesn't know what is happening or that the person does not trust the CRA debugger. If (s)he doesn't trust such quality tools by default it is a sign of…

hir: him/her

'them' works pretty well for this case.

Re: Chrome developer tools to master

#63

Post by jasonkostempski »

bryanrasmussen wrote: post #29
judofyr wrote: post #19

Earlier quoted context omitted.

If you already know that the hammer is the best way to solve it, why wouldn't you ask them to solve it with a hammer? Using the right tool is tricky and there are cases where console.log is more efficient than a debugger: - It's a debugger you're not used to - The stack/application is complicated and works weirdly with the debugger (e.g. exceptions are captured and stack traces are lost) - Many things are happening a…

I prefer console logs to the debugger for the following reason - I tend to know about where the problem is. I've been working on this code, I know it's a couple things that could be breaking it in the way it's breaking. I prefer to console.log those things because I find stepping through code tedious, though I understand some people would prefer to use the debugger. If on the other hand it is code I don't know anythi…

You can make a conditional break point, put in arbitray js statements, such as console.log, and return false if you dont want to pause there. Best of both worlds and you dont have to clean up the code after.

Re: Chrome developer tools to master

#64

Post by allannienhuis »

tchaffee wrote: post #55

I am getting an "NET::ERR_CERT_AUTHORITY_INVALID" error when trying to view the article.

I got a bunch of those errors in chrome a year or so ago - turned out I was on a really old version of Chrome (I didn't realise auto-update wasn't working on their Beta stream at the time), and some ssl cert chain configs became stale (or something like that). Updating my browser fixed it.

Re: Chrome developer tools to master

#65

Post by subsection1h »

swaggyBoatswain wrote: post #42

Chrome developer tools is just a godsend. Its so much better than any other debugger I've worked with, and miles better than firefox debugging tool I personally use a chromium based browser called slimjet to do all of my development. It runs off v55 I think which is like 5 versions behind chrome. But its nice to have a dedicated app for debugging. One tool that I find I use everyday is this: http://lab.maltewasserman…

How is Chrome DevTools "miles better" than Firefox Developer Tools included with Firefox Developer Edition?

I checked your blog to see if you've written a detailed comparison. I saw that your latest blog post is about writing your first user script in 2018, and you didn't use the term "user script"[1][2]; instead, you used the term "Tampermonkey Scripting" as if Tampermonkey originated user scripts. Do you have enough experience with web development to adequately compare Chrome DevTools and Firefox Developer Tools?

[1] https://wiki.greasespot.net/User_script

[2] https://en.wikipedia.org/wiki/Userscript

Re: Chrome developer tools to master

#66

Post by lhnz »

jasonkostempski wrote: post #63
bryanrasmussen wrote: post #29

Earlier quoted context omitted.

I prefer console logs to the debugger for the following reason - I tend to know about where the problem is. I've been working on this code, I know it's a couple things that could be breaking it in the way it's breaking. I prefer to console.log those things because I find stepping through code tedious, though I understand some people would prefer to use the debugger. If on the other hand it is code I don't know anythi…

You can make a conditional break point, put in arbitray js statements, such as console.log, and return false if you dont want to pause there. Best of both worlds and you dont have to clean up the code after.

I can type `console.log(blah)` into a text file and hit save much faster than I can search for the same file within Chrome right-click and then come up with a working conditional breakpoint dependent on the context around it and type this into a tiny input field.

If you understand the code and are currently writing it, it's almost always faster to debug with a `console.log`[0]. This seem to be the case whether you are coding in a browser or running unit tests: reaching for the debugger is slowwww.

To me, the debugging experience everywhere seems broken. Why is the only tool we have a breakpoint? What if I don't want to 'block' and just want to mark a point in the code which I want to capture a selection of information about? Why not let me visualise or filter these points, and then click through to see the callstacks and the state that was collected?

The whole DX seems to be built around the premise that I want to laboriously step through when I debug. While in 99% of cases as soon as I see some values I instantly know what I have done wrong.

The only times I normally use a debugger are when debugging problems on production sites, or when debugging complex problems in other people's code.

  [0] This might not be the case, if your IDE is extremely
      well-integrated with your text editor to the extent that you
      can add breakpoints as easily as you can add log statements.
Edit: I just checked and the latest version of VSCode has LogPoints. Perhaps that means others see room for improvement, too.

Re: Chrome developer tools to master

#67

Post by ghostbrainalpha »

0xfeba wrote: post #3

I implemented two simple interview tests in order to weed out people who can't do simple debugging. In one, I hand them my laptop and give them a basic create-react-app sample that uses fetch on a remote URL, but there's a typo in the URL. I tell them it's supposed to fetch a remote REST API and parse the JSON but it doesn't work--how would you fix it? So far, two ways to pass: Just look at the source code, or use th…

I really appreciate when people who actually conduct the interviews give honest information about how their decision making process works.

Especially because everyone will hammer the shit out of you and critique your thought process.

Even if you think this paticular criteria is random/inefficient, people are missing a major opportunity to get inside the head of a person who could hire them.

Re: Chrome developer tools to master

#68

Post by 0xfeba »

tchaffee wrote: post #53
barbegal wrote: post #15

Earlier quoted context omitted.

But if they don't know how to use the Chrome debugger then that probably correlates to not being able to do many other tasks. That few hours just teaching them how to use Chrome debugger turns into weeks of teaching them how to do lots of tasks. I have nothing against teaching new hires but for some businesses it is a significant cost so it makes sense to weed out applicants that won't be able to get stuck in straigh…

I don't know Chrome debugger because one of the first things I did was to get VS Code to control Chrome debugger so I can set breakpoints while looking at code with the font and highlighting I'm familiar with. Weeding out applicants is dangerous if you're not trying hard to disprove first impressions or wrong answers.

If you could explain or show how you connected VS code to act as the debugger for Chrome I would let you and you could use VS code instead. I would also be impressed.

I didn't mean to imply they had to use Chrome.

Re: Chrome developer tools to master

#69

Post by 0xfeba »

sehugg wrote: post #44
0xfeba wrote: post #30

Earlier quoted context omitted.

I do. I just verify. They can also use Firefox or any other browser's tools if they are more comfortable. We are not hiring junior devs, and even if so I would still probably ask. But experienced front end devs should know how to use a browser's debugger. Like others said, it's a flag that they potentially don't have problem solving skills. I mean, if they put a single console.log near what they think is going wrong…

I've written debuggers, and I still use console.log quite often. I would be pretty annoyed if I were silently judged on my choice of debugging tool.

Ok -- I suppose it's the only bad example I have encountered.

To put it another way, if the candidate just starts changing completely unrelated stuff, and continues to after I say "that's not the issue, think about XYZ." That's a red flag.

Re: Chrome developer tools to master

#70

Post by 0xfeba »

pvg wrote: post #41
0xfeba wrote: post #30

Earlier quoted context omitted.

I do. I just verify. They can also use Firefox or any other browser's tools if they are more comfortable. We are not hiring junior devs, and even if so I would still probably ask. But experienced front end devs should know how to use a browser's debugger. Like others said, it's a flag that they potentially don't have problem solving skills. I mean, if they put a single console.log near what they think is going wrong…

if they resort to console.logs, they are just randomly trying things. How does that follow? It's just another way to check the state of a program at a given point.

so far

That is, the people who start entering in console.logs, are entering them in in random places, not really troubleshooting.

Post reply on HN