10 ms·

Chrome developer tools to master

152 points by rohithasrk 8y ago

SurrealSoul 8y ago
One thing that wasn't touched here is that you can actually map the developer tools to your local files. My old co-worker used Dev tools as his text editor. Pretty nifty!
- kaycebasques 8y ago
  Tutorial on this workflow here: https://developers.google.com/web/tools/chrome-devtools/workspaces/ https://developers.google.com/web/tools/chrome-devtools/work...
0xfeba 8y ago
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 the network debugging tools to find the error. Spraying console.log statements everywhere is a red flag to me. So far, the test seems to work well.
- deleted 8y ago
  [deleted]
- deleted 8y ago
  [deleted]
- codezero 8y ago
  I have a similar interview question, but I have a few layers on top of it, not all of which are required to progress through the interview: 1. Send CSP headers that prevent some of the JS from executing. This is really obscure to most people, but if you look at the console and search the internet for the error, it gives you a good idea. This gets you thinking about the script. 2. Include a simple JS syntax error in the AJAX call. It helps prime them to figure out why the call, once the error is fixed, still doesn't work, rather than having them try to think about the entire front-end as a source for potential problems. I like to make sure that people are generally guided to the problem to solve, but also to test them along that path. A lot of debugging involves things a few steps/layers removed from the actual problem before you get to the point of solving it, so it's fun to test those steps too, as each can lead you down a wrong/different path.
  - 0xfeba 8y ago
    Those are all good ideas, thanks! I made it super easy, it's an invalid URL. Everything else is setup, but having a few more non-required steps would allow me to be more granular between two otherwise good candidates.
- fermuch 8y ago
  And what is the the second test?
  - 0xfeba 8y ago
    Not so much debugging. Same create-react-app setup, but increment a counter on a button press. The solution is to add an event handler (which requires binding or an arrow function for the right context), and increment a state variable. That and the debugging example are surprisingly effective at weeding out people who have "React" sprayed all over their resume but can't do one of the most common things. We had one person who apparently had no fear of "3-1 pair programming with strangers" and instantly came up with the solution. She ended up taking a better offer though. Can't blame her. I wouldn't do as well as she did, and I wrote the damned thing.
- judofyr 8y ago
  Can’t you just ask them if they have experience with the Chrome debugger? And if that’s such a deal breaker for you, you can teach them in the first week? I mean, it’s not like the Chrome debugger is such a complicated beast. Even if you have no experience with it, you can probably learn 90% of the useful tricks in a few hours.
  - barbegal 8y ago
    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 straight away without a holding hand.
    - judofyr 8y ago
      I see that knowledge about Chrome debugger probably correlates with knowledge about other tasks, but there has to be some false negatives, no? And mostly I find it a bit dishonest. If you have a preferred way to solve a problem in a company you should state it up-front: "Find this bug by using the debugger, not console.log, because that's the way we do it here". If the method does not matter, you should let they solve it their own way and see how efficient they are. > 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 straight away without a holding hand. Right, and that will show when they use so much time adding console.log everywhere without finding the bug. Measure the time and understanding of the problem/code/solution, not the tool.
      - figgis 8y ago
        They didn't make a simple "if you can't use developer tools X way then I'm not hiring you" statement. >So far, two ways to pass: Would mean that they understand there are a hundred different paths to solve a simple problem. What is being looked for is familiarity with the tools you are expected to know. And littering a shit ton (not just a simple "Started-HH:MM:SS.mmm" or "Stopped-HH:MM:SS.mmm" with timestamps) of console.log statements when you first start debugging is a pretty fair red flag.
- adrianhel 8y ago
  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 paranoia. They are too good to doubt as an initial user. It may have flaws, but ir's like doubting your compiler. It is probably you. If the person has a lot of logging you should ask hir why. Lacking experience in a given language is not a real objection to a quality developer. Lacking general programming ability would definitely be.
  - adrianhel 8y ago
    hir: him/her
    - allannienhuis 8y ago
      'them' works pretty well for this case.
- adrianhel 8y ago
  I would be alarmed if the person was an > medium level dev and did nor know what was up within 30s. For entry level, it's not as easy. If a person did not find out within 45m, I probably wouldn't hire them.
- hartator 8y ago
  Lol, depending on the typo in the URL, I would probably think the service is just down, and it's not part of test.
  - brobinson 8y ago
    I would be scared of a service where a 404 response means it's down.
- ruckusing 8y ago
  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.
  - 0xfeba 8y ago
    You're hired.
- ghostbrainalpha 8y ago
  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.
  - 0xfeba 8y ago
    Well, I'm not and (do not want to be) a manager, but I've turned into lead dev of this project after the former lead left (we're friends though so I had a heads up way ahead of time). But we started this procedure together after just miserable results from "just talking" to candidates. Keep in mind most of the candidates were (and all are now) contractors. We did whiteboarding at first. It didn't seem effective and I hated it anyway. We could only ask very simple things, write a for loop, write any kind of recursive function that counts to 10, etc. So I setup a project with create-react-app and IntelliJ IDEA. I give a brief intro to the IDE, showing that saved changes are built automatically, and usually reloads in the browser automatically and they just have to worry about the particular fetch call in one case, or adding the code (I don't say event handler) to handle a button press. The code is 30 lines in one, and 40 lines in the other problem, including braces, imports, etc. I understand how intense interviewing can be but these, to me and our team, are super easy problems. I've gotten a fair bit of heat for that post, but no real suggestions on how to improve the process.
- ramblerman 8y ago
  > So far, the test seems to work well. How would you know.
  - 0xfeba 8y ago
    We haven't had to fire anyone hired after utilizing it.
- augbog 8y ago
  doesn't the console tell you an error happens when trying to make that request? unless the typo URL is actually a valid URL that returns a 200 response
  - 0xfeba 8y ago
    It sure does, they have to open the debugger to find that out though. I do give them the hint that "I would use the debugger".
    - augbog 8y ago
      Ah nice -- yeah we have a similar interview that tests debugging as well so glad to hear other people do it. We have found it really effective as it is a skill that is often overlooked in technical interviews but is something you do on a day-to-day basis. We have it so some tests fail despite the fact they LOOK like they should pass. Props to you for having a practical technical interview :)
- CyberDildonics 8y ago
  Sounds like you are weeding out people who don't know how to use the one tool you are using. Debugging is about narrowing down the problem until you can isolate it, and ultimately understand the problem to figure out exactly what it is.
  - 0xfeba 8y ago
    The Chrome dev tools are more well-known than that. But I would let them use Firefox, or whatever they want. Even connect VS code or some other IDE to the browser if they wish (as someone else mentioned). It's really more open ended than everyone here is making it out to be. I was just saying that so far, people open the dev tools or they just notice the URL is malformed in the source code. Or, they just freeze up and can't write a console.log in the right place to begin with.
michael_michael 8y ago
As the author notes, most of these tips can be applied to Firefox (or Edge) as well.
codezero 8y ago
This is great, besides the Sources tab, I use DOM and Event breakpoints a ton to debug a lot of problems. Something, I'm not sure if most people know, if you break somewhere (whether event or DOM), you can access the currently in scope variables directly in the console. It's extremely useful for finding out what's going on with something in the middle of hairy code at a specific point in time.
- slig 8y ago
  It's also possible to change the value of these variables and test different code paths.
  - codezero 8y ago
    You're right! I was going to say that, but I didn't remember off the top of my head if that was true :)
- kaycebasques 8y ago
  More on the different types of breakpoints available in Chrome DevTools: https://developers.google.com/web/tools/chrome-devtools/javascript/breakpoints https://developers.google.com/web/tools/chrome-devtools/java...
kornish 8y ago
One thing I didn't see in the article: As well as setting breakpoints, one can trigger the debugger by including the statement debugger; in a script. Then, having the Dev Tools console open when that statement executes will automatically hop you into the debugger with access to variables in scope, etc. Easier IMO than manually setting breakpoints, especially when working with some transpiled languages.
- fermuch 8y ago
  For transpiled languages: if you set up source maps correctly, you can access the non-transpiled language and the devtools will set up rules on the correct places (in this case, breakpoints, which also jump automatically to the original source instead of the transpiled version)
  - 52-6F-62 8y ago
    This works great with TypeScript
dmitriid 8y ago
There's no end to amazement at how great Chrome tools are. When you think "they can't get anything more into them", they throw in additional things. Anything from full-page screen captures to animation profilers. I've yet to scratch the surface of what they have to offer. And they add new stuff continuously. Once every few months you open DevTools to be greeted with a new What's new in DevTools". And then there's Safari (I'm on a Mac). I still prefer Safari to Chrome and Firefox. But their DevTools... &-10 years ago their DevTools where best-in-class, putting even Chrome's DevTools to shame. And then they not only stagnated, they regressed. Good luck using any part of whatever the Safari DevTools are anymore.
- degenerate 8y ago
  I didn't know about the screenshot! Found this article showing where it is: https://www.utilitylog.com/full-page-screenshot-chrome/ https://www.utilitylog.com/full-page-screenshot-chrome/
  - kaycebasques 8y ago
    Also supports screenshots of arbitrary sections of the viewport: https://developers.google.com/web/updates/2017/08/devtools-release-notes#screenshot-areas https://developers.google.com/web/updates/2017/08/devtools-r... And specific HTML nodes: https://developers.google.com/web/updates/2017/08/devtools-release-notes#node-screenshots https://developers.google.com/web/updates/2017/08/devtools-r...
adrianhel 8y ago
If Edge had shadow DOM anad as nice dev tools, there would be nothing keeping me to chrome. (We have polyfills for everything else.)
adrianhel 8y ago
Give the developer a simple task that is work relevant and 24h. If the person does it in 5m using some fancy trick, then you know they're a problem solver of high calibre. 1h-5h: They are probably adequate. 24h: junior or bad. Ask them about the trad offs they made. The 24h guy may not have made any, and may be the perfect maintainer. The 5m guy must have made some. Ask for their reasoning. It may be the reason to hire them. It may be the reason not to. Feel free to pay people for being tested.
- paulie_a 8y ago
  How do you know how long it took? Even with the fancy coding screen sharing software? I could have had an important phone call and walked away from the laptop.
kclay 8y ago
Can someone explain why the chrome browser simulator is so bad. I recently had to do some web work, normally don't deal with HTML . Anyways I tried to use the emulate view to test against iOS devices. Had QA test on a real device and it was all wrong. Ended up just getting a virtualbox of osx up to run the stimulator. Normally it isn't a problem using it but trying to line up slanted designs with pixel perfect placement wasnt working out at all.
- carelesswhisper 8y ago
  Ran into this recently, there’s a meta tag you have to set for it to properly target mobile and not just scale it down https://developers.google.com/web/tools/lighthouse/audits/has-viewport-meta-tag https://developers.google.com/web/tools/lighthouse/audits/ha...
- LiquidFlux 8y ago
  My understanding is that Chrome emulates viewports and little more, it doesn't support different rendering engines and such. You should use it to understand what various mobile devices might look like, great for prototyping, but it doesn't replace physical or truly virtualised devices ( as a service / VMs ) for testing.
Kagerjay 8y ago
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.maltewassermann.com/viewport-resizer/ http://lab.maltewassermann.com/viewport-resizer/. It is WAY better than chromes native responsive webdesign tool. When I first started developing I would always just go on stackoverflow and ask a dumb question. Now I consult my debugger and it answers everything I ever wanted to know. Knowing how to use a debugger means I can reverse engineer html/css on any site too, so thats a big bonus.
- NVRM 8y ago
  Wrong. Try again.
  - dang 8y ago
    Please don't post unsubstantive comments here.
    - deleted 8y ago
      [deleted]
- homero 8y ago
  Firebug and the new firefox debuggers are identical for me, not sure how chrome is better. Each has oddities.
- kaycebasques 8y ago
  FYI v55 is quite old by now... a quick check at chrome://version on my Mac shows that Chrome Stable is running v67...
  - madeofpalk 8y ago
    to be fair, chrome's versioning means that that's probably just like 2 weeks difference.
homero 8y ago
You can open it much quicker by just pushing F12
tchaffee 8y ago
I am getting an "NET::ERR_CERT_AUTHORITY_INVALID" error when trying to view the article.
- allannienhuis 8y ago
  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.
  - tchaffee 8y ago
    I'll check it out, but I get frequent updates for Chromium and Chrome. I'm usually on the latest stable release. Thanks for the suggestion.
kaycebasques 8y ago
Here are some of the latest tutorials from the official DevTools docs, if you're looking to learn new workflows: CSS basics: https://developers.google.com/web/tools/chrome-devtools/css/ https://developers.google.com/web/tools/chrome-devtools/css/ JS debugging basics: https://developers.google.com/web/tools/chrome-devtools/javascript/ https://developers.google.com/web/tools/chrome-devtools/java... Console basics: https://developers.google.com/web/tools/chrome-devtools/console/get-started https://developers.google.com/web/tools/chrome-devtools/cons... Finding ways to improve site speed: https://developers.google.com/web/tools/chrome-devtools/speed/get-started https://developers.google.com/web/tools/chrome-devtools/spee...

152 points by rohithasrk 8y ago

One thing that wasn't touched here is that you can actually map the developer tools to your local files. My old co-worker used Dev tools as his text editor. Pretty nifty!

kaycebasques 8y ago
Tutorial on this workflow here: https://developers.google.com/web/tools/chrome-devtools/workspaces/ https://developers.google.com/web/tools/chrome-devtools/work...

0xfeba 8y ago

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 the network debugging tools to find the error. Spraying console.log statements everywhere is a red flag to me. So far, the test seems to work well.

deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
codezero 8y ago
I have a similar interview question, but I have a few layers on top of it, not all of which are required to progress through the interview: 1. Send CSP headers that prevent some of the JS from executing. This is really obscure to most people, but if you look at the console and search the internet for the error, it gives you a good idea. This gets you thinking about the script. 2. Include a simple JS syntax error in the AJAX call. It helps prime them to figure out why the call, once the error is fixed, still doesn't work, rather than having them try to think about the entire front-end as a source for potential problems. I like to make sure that people are generally guided to the problem to solve, but also to test them along that path. A lot of debugging involves things a few steps/layers removed from the actual problem before you get to the point of solving it, so it's fun to test those steps too, as each can lead you down a wrong/different path.
- 0xfeba 8y ago
  Those are all good ideas, thanks! I made it super easy, it's an invalid URL. Everything else is setup, but having a few more non-required steps would allow me to be more granular between two otherwise good candidates.
fermuch 8y ago
And what is the the second test?
- 0xfeba 8y ago
  Not so much debugging. Same create-react-app setup, but increment a counter on a button press. The solution is to add an event handler (which requires binding or an arrow function for the right context), and increment a state variable. That and the debugging example are surprisingly effective at weeding out people who have "React" sprayed all over their resume but can't do one of the most common things. We had one person who apparently had no fear of "3-1 pair programming with strangers" and instantly came up with the solution. She ended up taking a better offer though. Can't blame her. I wouldn't do as well as she did, and I wrote the damned thing.
judofyr 8y ago
Can’t you just ask them if they have experience with the Chrome debugger? And if that’s such a deal breaker for you, you can teach them in the first week? I mean, it’s not like the Chrome debugger is such a complicated beast. Even if you have no experience with it, you can probably learn 90% of the useful tricks in a few hours.
- barbegal 8y ago
  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 straight away without a holding hand.
  - judofyr 8y ago
    I see that knowledge about Chrome debugger probably correlates with knowledge about other tasks, but there has to be some false negatives, no? And mostly I find it a bit dishonest. If you have a preferred way to solve a problem in a company you should state it up-front: "Find this bug by using the debugger, not console.log, because that's the way we do it here". If the method does not matter, you should let they solve it their own way and see how efficient they are. > 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 straight away without a holding hand. Right, and that will show when they use so much time adding console.log everywhere without finding the bug. Measure the time and understanding of the problem/code/solution, not the tool.
    - figgis 8y ago
      They didn't make a simple "if you can't use developer tools X way then I'm not hiring you" statement. >So far, two ways to pass: Would mean that they understand there are a hundred different paths to solve a simple problem. What is being looked for is familiarity with the tools you are expected to know. And littering a shit ton (not just a simple "Started-HH:MM:SS.mmm" or "Stopped-HH:MM:SS.mmm" with timestamps) of console.log statements when you first start debugging is a pretty fair red flag.
adrianhel 8y ago
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 paranoia. They are too good to doubt as an initial user. It may have flaws, but ir's like doubting your compiler. It is probably you. If the person has a lot of logging you should ask hir why. Lacking experience in a given language is not a real objection to a quality developer. Lacking general programming ability would definitely be.
- adrianhel 8y ago
  hir: him/her
  - allannienhuis 8y ago
    'them' works pretty well for this case.
adrianhel 8y ago
I would be alarmed if the person was an > medium level dev and did nor know what was up within 30s. For entry level, it's not as easy. If a person did not find out within 45m, I probably wouldn't hire them.
hartator 8y ago
Lol, depending on the typo in the URL, I would probably think the service is just down, and it's not part of test.
- brobinson 8y ago
  I would be scared of a service where a 404 response means it's down.
ruckusing 8y ago
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.
- 0xfeba 8y ago
  You're hired.
ghostbrainalpha 8y ago
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.
- 0xfeba 8y ago
  Well, I'm not and (do not want to be) a manager, but I've turned into lead dev of this project after the former lead left (we're friends though so I had a heads up way ahead of time). But we started this procedure together after just miserable results from "just talking" to candidates. Keep in mind most of the candidates were (and all are now) contractors. We did whiteboarding at first. It didn't seem effective and I hated it anyway. We could only ask very simple things, write a for loop, write any kind of recursive function that counts to 10, etc. So I setup a project with create-react-app and IntelliJ IDEA. I give a brief intro to the IDE, showing that saved changes are built automatically, and usually reloads in the browser automatically and they just have to worry about the particular fetch call in one case, or adding the code (I don't say event handler) to handle a button press. The code is 30 lines in one, and 40 lines in the other problem, including braces, imports, etc. I understand how intense interviewing can be but these, to me and our team, are super easy problems. I've gotten a fair bit of heat for that post, but no real suggestions on how to improve the process.
ramblerman 8y ago
> So far, the test seems to work well. How would you know.
- 0xfeba 8y ago
  We haven't had to fire anyone hired after utilizing it.
augbog 8y ago
doesn't the console tell you an error happens when trying to make that request? unless the typo URL is actually a valid URL that returns a 200 response
- 0xfeba 8y ago
  It sure does, they have to open the debugger to find that out though. I do give them the hint that "I would use the debugger".
  - augbog 8y ago
    Ah nice -- yeah we have a similar interview that tests debugging as well so glad to hear other people do it. We have found it really effective as it is a skill that is often overlooked in technical interviews but is something you do on a day-to-day basis. We have it so some tests fail despite the fact they LOOK like they should pass. Props to you for having a practical technical interview :)
CyberDildonics 8y ago
Sounds like you are weeding out people who don't know how to use the one tool you are using. Debugging is about narrowing down the problem until you can isolate it, and ultimately understand the problem to figure out exactly what it is.
- 0xfeba 8y ago
  The Chrome dev tools are more well-known than that. But I would let them use Firefox, or whatever they want. Even connect VS code or some other IDE to the browser if they wish (as someone else mentioned). It's really more open ended than everyone here is making it out to be. I was just saying that so far, people open the dev tools or they just notice the URL is malformed in the source code. Or, they just freeze up and can't write a console.log in the right place to begin with.

michael_michael 8y ago

As the author notes, most of these tips can be applied to Firefox (or Edge) as well.

codezero 8y ago

This is great, besides the Sources tab, I use DOM and Event breakpoints a ton to debug a lot of problems. Something, I'm not sure if most people know, if you break somewhere (whether event or DOM), you can access the currently in scope variables directly in the console. It's extremely useful for finding out what's going on with something in the middle of hairy code at a specific point in time.

slig 8y ago
It's also possible to change the value of these variables and test different code paths.
- codezero 8y ago
  You're right! I was going to say that, but I didn't remember off the top of my head if that was true :)
kaycebasques 8y ago
More on the different types of breakpoints available in Chrome DevTools: https://developers.google.com/web/tools/chrome-devtools/javascript/breakpoints https://developers.google.com/web/tools/chrome-devtools/java...

kornish 8y ago

One thing I didn't see in the article: As well as setting breakpoints, one can trigger the debugger by including the statement debugger; in a script. Then, having the Dev Tools console open when that statement executes will automatically hop you into the debugger with access to variables in scope, etc. Easier IMO than manually setting breakpoints, especially when working with some transpiled languages.

fermuch 8y ago
For transpiled languages: if you set up source maps correctly, you can access the non-transpiled language and the devtools will set up rules on the correct places (in this case, breakpoints, which also jump automatically to the original source instead of the transpiled version)
- 52-6F-62 8y ago
  This works great with TypeScript

dmitriid 8y ago

There's no end to amazement at how great Chrome tools are. When you think "they can't get anything more into them", they throw in additional things. Anything from full-page screen captures to animation profilers. I've yet to scratch the surface of what they have to offer. And they add new stuff continuously. Once every few months you open DevTools to be greeted with a new What's new in DevTools". And then there's Safari (I'm on a Mac). I still prefer Safari to Chrome and Firefox. But their DevTools... &-10 years ago their DevTools where best-in-class, putting even Chrome's DevTools to shame. And then they not only stagnated, they regressed. Good luck using any part of whatever the Safari DevTools are anymore.

degenerate 8y ago
I didn't know about the screenshot! Found this article showing where it is: https://www.utilitylog.com/full-page-screenshot-chrome/ https://www.utilitylog.com/full-page-screenshot-chrome/
- kaycebasques 8y ago
  Also supports screenshots of arbitrary sections of the viewport: https://developers.google.com/web/updates/2017/08/devtools-release-notes#screenshot-areas https://developers.google.com/web/updates/2017/08/devtools-r... And specific HTML nodes: https://developers.google.com/web/updates/2017/08/devtools-release-notes#node-screenshots https://developers.google.com/web/updates/2017/08/devtools-r...

adrianhel 8y ago

If Edge had shadow DOM anad as nice dev tools, there would be nothing keeping me to chrome. (We have polyfills for everything else.)

adrianhel 8y ago

Give the developer a simple task that is work relevant and 24h. If the person does it in 5m using some fancy trick, then you know they're a problem solver of high calibre. 1h-5h: They are probably adequate. 24h: junior or bad. Ask them about the trad offs they made. The 24h guy may not have made any, and may be the perfect maintainer. The 5m guy must have made some. Ask for their reasoning. It may be the reason to hire them. It may be the reason not to. Feel free to pay people for being tested.

paulie_a 8y ago
How do you know how long it took? Even with the fancy coding screen sharing software? I could have had an important phone call and walked away from the laptop.

kclay 8y ago

Can someone explain why the chrome browser simulator is so bad. I recently had to do some web work, normally don't deal with HTML . Anyways I tried to use the emulate view to test against iOS devices. Had QA test on a real device and it was all wrong. Ended up just getting a virtualbox of osx up to run the stimulator. Normally it isn't a problem using it but trying to line up slanted designs with pixel perfect placement wasnt working out at all.

carelesswhisper 8y ago
Ran into this recently, there’s a meta tag you have to set for it to properly target mobile and not just scale it down https://developers.google.com/web/tools/lighthouse/audits/has-viewport-meta-tag https://developers.google.com/web/tools/lighthouse/audits/ha...
LiquidFlux 8y ago
My understanding is that Chrome emulates viewports and little more, it doesn't support different rendering engines and such. You should use it to understand what various mobile devices might look like, great for prototyping, but it doesn't replace physical or truly virtualised devices ( as a service / VMs ) for testing.

Kagerjay 8y ago

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.maltewassermann.com/viewport-resizer/ http://lab.maltewassermann.com/viewport-resizer/. It is WAY better than chromes native responsive webdesign tool. When I first started developing I would always just go on stackoverflow and ask a dumb question. Now I consult my debugger and it answers everything I ever wanted to know. Knowing how to use a debugger means I can reverse engineer html/css on any site too, so thats a big bonus.

NVRM 8y ago
Wrong. Try again.
- dang 8y ago
  Please don't post unsubstantive comments here.
  - deleted 8y ago
    [deleted]
homero 8y ago
Firebug and the new firefox debuggers are identical for me, not sure how chrome is better. Each has oddities.
kaycebasques 8y ago
FYI v55 is quite old by now... a quick check at chrome://version on my Mac shows that Chrome Stable is running v67...
- madeofpalk 8y ago
  to be fair, chrome's versioning means that that's probably just like 2 weeks difference.

homero 8y ago

You can open it much quicker by just pushing F12

tchaffee 8y ago

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

allannienhuis 8y ago
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.
- tchaffee 8y ago
  I'll check it out, but I get frequent updates for Chromium and Chrome. I'm usually on the latest stable release. Thanks for the suggestion.

kaycebasques 8y ago

Here are some of the latest tutorials from the official DevTools docs, if you're looking to learn new workflows: CSS basics: https://developers.google.com/web/tools/chrome-devtools/css/ https://developers.google.com/web/tools/chrome-devtools/css/ JS debugging basics: https://developers.google.com/web/tools/chrome-devtools/javascript/ https://developers.google.com/web/tools/chrome-devtools/java... Console basics: https://developers.google.com/web/tools/chrome-devtools/console/get-started https://developers.google.com/web/tools/chrome-devtools/cons... Finding ways to improve site speed: https://developers.google.com/web/tools/chrome-devtools/speed/get-started https://developers.google.com/web/tools/chrome-devtools/spee...