Developer Evangelism interview on

This morning ran a segment about new job titles based on an interview with me a few weeks ago. In the interview about developer evangelism I answered a few questions and – more importantly – covered the difference between sales and developer relations. Here are my full answers to their questions:

Article screenshot

In layman’s terms, how would you describe your job?

A developer evangelist (or developer advocate which is a term many prefer now) is an expert who helps developers use the products of a company and technical people in the company to get the time and support to write excellent products. The job is a communicator role between the technical experts of a company, the outside world, but also different departments of a company. Working in tech is a taxing job although it doesn’t look that way. A lot of people have demands but are not interested in understanding what you do – they just want the work done. The job of the developer evangelist is to bridge that gap. By creating learning materials, presentations and help with communication in between departments. Developers are excellent at solving technical problems and building great software. But many have neither the time nor the drive to communicate their efforts well to others. This is what we do.

Would it be fair to say you work as a sort of salesman for companies to encourage other people to purchase things from the company? Or purchase apps for example?

No, not at all. This is the job of a sales department and their main goal is to artificially create demand for a product. As a developer evangelist you help the product on a technical level. You create example projects using the product. You collect and collate outside feedback, triage it and then bring it to the busy technical team. You help people with technical issues. You create demand in the technical community by talking about the product and showing how it makes the life of developers easier.
If you do a classic sales pitch in the form of “you don’t need to understand this, our product magically fixes all your problems” you’re dead as a developer relations person. You need to have the technical knowledge and properly understand how the product works, not simply sell it. Of course, we’re all creating demand and interest, so in a way we are sales people. But what we sell is knowledge about the inner workings of the product to the outside. You sell your company as a place using cool tech to other developers. We sell outside interest back to the company helping it to priotitise product roadmaps. Good DevRel work doesn’t necessarily result in more product sales. Instead it helps with hiring new talent and ensure people in the company are happy. A company with a fixed product does not need a developer evangelist. When your product offers more granular access to its features using for example an Application Programming Interface (API) then you should consider bringing this role up.

As a comparison, consider a car company. The sales people are there to sell cars – customers don’t need to know the internals. A devrel person would be the one explaining mechanics how to maintain the engine. The person should present at conferences why your cars have great technology and are good for the environment. And explain that your company is much more than just a maker of cars. We create interest and explain how things work so people from the outside can contribute. We don’t sell products.

On your Linkedin you say, ‘I like to take complex technical things and translate them to various audiences in an understandable format’. Is that for people working for companies like Microsoft? Or the general public?

That depends on the event or publication I am asked to reach out to. I’ve explained tech and products of my former and current companies internally to our own people of other departments. I explained them to outside developers working for other, similar companies. I worked withthe open source community as a whole, designers, product managers, project managers and at one time also to people working in the unemployment office. That’s the “various audiences” bit in there.

The general public is less interested in the inner workings of products. It makes more sense to give this communication channel to marketing. However, a good developer evangelist works very closely with sales and marketing to make sure that your company advertisements and press releases don’t overpromise or make it impossible for your developers to deliver in time.

The job of a developer evangelist is to make technical issues easier to understand. This also means to help your company to communicate to the general public without dazzling them with buzzwords.

You don’t only to explain the how but also the why. And the why differs from audience to audience and needs different explanation materials. This could be a very well documented and explained piece of code, an exciting use case and demo app or a presentation. It boils down to being a good communicator and feel empathy with the audience. Far too many technical documentation assumes a perfect audience and thus fails to spark interest. Other information materials show a shiny best scenario but never explain what to do when things go wrong. As a devrel person you need to find a good middle ground.

How does one go about becoming a developer evangelist?

The perfect scenario is to move an interested developer of the product into the role. You need to know the products and technologies inside and out to be a good developer evangelist. People in technology have had their fair share of overpromise and slick sales people telling us things work that do – in fact – not. So you need to have the right “street credibility” or you’re just a sales person that tries to reach a very hostile audience. Personally I was in a lead developer role in a company when I transitioned. I didn’t see any more ways to get promoted on a technical level without moving into management. So I proposed the role of developer evangelist to help the company to improve our internal and external communication. I was lucky to find a sympathetic ear as this is a big issue for a lot of companies.

To start, you need to know what you want to talk about. You can’t only be a good presenter or writer, you also need to know the technical details and know what the market as a whole is doing. For developers or technical project managers who consider a role in DevRel it is a great idea to do a competitive analysis and find out what gets developers excited and how it relates to your company. Then you can start selling the idea of this role to your company. One thing to remember is that only your own excitement sells. If you don’t care about the technology you are supposed to promote or you don’t understand it, you will fail.

Do you developer evangelists work in every tech company? For example, is there a developer evangelist attempting to sell Candy Crush to developers or people looking for the next app to play?

I am pretty shocked how far this has grown. When I wrote the developer evangelism handbook there were only a few companies that had devrel departments. Now almost every technical startup has them.

However, the example of Candy Crush or next app to play is nothing a developer evangelist should do – at all.

King, the company behind Candy Crush most likely has developer evangelists. Instead of telling people about their new games they talk to game developers how to use their analytics, scoring mechanism and other internal features of games. Developer Relations (DevRel) is a hot topic now and a lot of people try to jump on the bandwagon. It kind of washes out the idea of what it is meant to do – improve communication between technical and non-technical people. Developers are a sought after community. They are early adopters and often they are ahead of the next wave of change in our markets. It is tough to hire talent, and it is even harder to retain them. A functioning DevRel department is there to make the technical people in your company be understood and proud of what they are doing. It is not about going to events and giving out T-Shirts.

Do you believe developer evangelists are just one of the many jobs people need to embrace/learn to do in the 21st century. If so, how should people start learning?

It is for sure one of the newer jobs and one that still needs proper definition. However, I would disagree that people should start as developer evangelists. It is a role technical people should transition into once they know your company’s products and goals. That doesn’t mean though that the skillset needed for it isn’t a thing everybody should be learning. We’re at a stage where technology evolves faster than humans. In the very near future it will not be about who can program, but who can use intelligent products that work for us in a sensible manner. Knowing what is happening at the bleeding edge of technology and finding simple ways to explain it is a skill that will become more and more important. It is especially important to make a conscious decision to avoid the drama and hype about technology. Right now, the tech world is getting a bad reputation of being horrible people who only look out for themselves and don’t care about what our products do to people. It is a good time to disprove this impression.

The beauty of our time is that the internet is a great place to learn all kind of things. You can use online courses to try out ideas and technologies for yourself and play with them. There is no certificate for developer evangelism. We’re still at a very early stage. You can use that as an opportunity.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

CSS Grid and Grid Highlighter Now in Firefox Developer Edition

CSS Grid has just been uplifted to Firefox 52 Developer Edition (download it here!). With Chrome (and hopefully Safari and Edge) implementations coming shortly, using grid to build websites will soon be possible in release browsers across the board.

Grid allows users to decouple HTML from layout concerns, expressing those concerns exclusively in CSS. It adapts to media queries and different contexts, making it a viable alternative to frameworks such as Twitter’s Bootstrap or Skeleton which rely on precise and tightly coupled class structure to define a content grid.

Reducing the risks of fragility, code bloat, and high maintenance costs inherent in how we currently build on the web, grid really does have the potential to change the way we do layouts. Jen Simmons calls it Real Art Direction for the Web and Rachel Andrew has built Grid by Example to inform, share, and evangelize it. If you’re new to grid, be sure to have a look.

As you can see in the video, the grid highlighter tool will help get you started illustrating the grid in-page as you’re working. Additional tooling is planned for the near future to continually improve working with grid.

To access this tool, make sure you’re running an up-to-date version of DevEdition. Next, open a page that is known to have grid code—we recommend one of these demos for this. Open the Inspector via Developer ? Inspector. Select an element with the property display: grid;. To toggle grid lines, click the icon next to “grid” which will persist the lines permanently.

The Firefox Developer Tools team have planned a series of improvements to make working with grid easier in the future. You can follow our progress through these bugs:

The metabug for tracking this work is bug 1181227.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Can we stop bad-mouthing CSS in developer talks, please?

At almost every developer conference right now there will be a talk that features the following “funny GIF”:

funny CSS gif
Peter Griffin aka Family Guy trying to make some blinds close and making a total mess of it, randomly dragging the cords until he gives up and rips them off the window. With the caption CSS.

It is always a crowd pleaser, and can be a good introduction to the issues of CSS and some examples how to fix them. In most cases – and the likeliness of that increases with how “techy” the conference is – it is the start of a rant how bad CSS is, how its architecture is terrible and how inconsistent it is. And, and, and…

Here’s the thing: I am sick of this. It is not clever, it is not based in fact and it makes us appear as arrogant know-it-alls that want everything to work the way we are used to. It drives a firm divider between “developers” and “people who do web stuff”, aka “not real developers”. Which is nonsense. Arrogant, dangerous nonsense, not helping us – at all – to grow our developer community and be more exciting for a new, diverse, crowd to join.

Here’s a fact: we build incredibly complex, exciting and beautfiful things on the web. The most democratic distribution system of information and – by now – a high fidelity and exciting software platform. If you think you know every facet of this, you can do it all without relying on other experts to work with you, and in the one technology you like, you’re blinded by your own ambition. And an arrogant person I really could not be bothered to work with.

Yes, it is easy to poke fun at CSS and it’s Frankenstein-esque syntax. It is also easy to show that you can do all the things it does with other technologies. But that gives you no right – at all – to belittle and disregard the people who like CSS and took it as their weapon of choice to build great user interfaces.

In other words: if you don’t like it, don’t use it. Work with someone who does like it. It is a self-fulfilling prophecy that when you use a technology that you don’t take serious and you don’t like, the end result will be bad. It is a waste of time. When you complain about the issues you faced because you want the technology to bend to your comfort zone’s rules you really complain about your failure to use it. It doesn’t apply to those who happen to like the technology and play it to its strengths.

Another one that always crops up is the “CSS is awesome” coffee mug:

css is awesome mug

The joke here is that CSS is inadequate to fix that problem of overflowing text. Well, my question is how should that be handled? Overflow with scroll bars? That’s possible in CSS. Cutting the text off? Also possible. Shortening the text followed by an ellipsis? That’s also possible. Are either of those good solutions? No. The main thing here is that the text is too big to fit the container. And a fixed container is a mistake on the web. You can’t fix anything in an environment that by definition could be any size or form factor. So the mistake here is a “fixed container” thinking, not that CSS doesn’t magically do something to the text you can’t control. This, in interfaces, would really get you into trouble.

I challenge anyone to look at the mind-boggling things Ana Tudor does with CSS and tell me that’s not “real programming” and based on a “stupid language”.

See the Pen cube broadcast (pure CSS) by Ana Tudor (@thebabydino) on CodePen.

I challenge you not to see the benefit of flexbox and the ability it gives us to build dynamic interfaces that can adapt to different amounts of content and the needs of smaller versus bigger screens as explained by Zoe Mickley Gillenwater:

Zoe Mickley Gillenwater | Flexbox | CSS Day from Web Conferences Amsterdam on Vimeo.

I challenge you not to get excited about the opportunities of grid layouts as explained by Rachel Andrews:

I challenge you not to be baffled by the beauty of using type and shapes to build complex layouts that are not hindered by a fixed pixel thinking as explained by Jen Simmons.

I challenge you not to marvel at the power of CSS filters and blend modes and what they empower an artistic mind to do as explained by Una Kravets:

SmashingConf Freiburg 2016 – Una Kravets on Practical Blend Modes from Smashing Magazine on Vimeo.

So next time you think about using “the CSS joke”, please understand that people who care do not try to colour some text. CSS is a very expressive language to build complex interfaces that cater to a lot of varying user needs. If you can’t get your head around that – and I am admitting that I can’t anymore – have the decency to not belittle those who do. Applaud them for their efforts and work with them instead.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

What does a developer evangelist/advocate do?

I love it! What is it?

Today I was asked to define the role of a developer evangelist in my company for a slide deck to be shown at hiring events and university outreach. This was a good opportunity to make a list of all the tasks we have to do in this job and why we do them. It might be useful for you to read through, and a good resource to point people to when they – once again – ask you “but, do you still code?”.

First things first: Whenever you write about this topic there is a massive discussion about the job title ” evangelist” and how it is terrible and has religious overtones and whatnot. So if that is what bothers you, please choose below what you’d like to read and your browser will change it accordingly to give you peace of mind:

Now, what is a developer evangelist? As defined in my developer evangelist handbook:

A developer evangelist is a spokesperson, mediator and translator between a company and both its technical staff and outside developers.

What do you need to know to be one? First there are the necessary skills:

  • Great development skills – both in creating and explaining software and products
  • Excellent communication skills – this job is about reaching out, listening and distilling information
  • Excellent networking skills – you’re meant to collect contacts and keep them happy

Then there are also important skills to have:

  • Patience of a saint – you will need to have to explain your job over and over and will have to defend your lack of ”not writing code”
  • Strong sense of independence – your job is to help communication by aiding with your voice. You’re not in sales.
  • Excellent self-organising skills – you’re on the road a lot and if you don’t take care, you burn out quickly or get buried under an avalanche of requests.

Being a developer evangelist is a role that spans across several departments. Your job is to be a communicator. Whilst you are most likely reporting to engineering, you need to spend a lot of time making different departments talk to another. Therefore internal networking skills are very important. Your job also affects the work of other people (PR, legal, comms, marketing). Be aware of these effects and make sure to communicate them before you reach out.

As a translator, you have both outbound (company to people) and inbound (people to your company) tasks to fulfil. Let’s list most of them:

Outbound tasks

Be a social media presence

Provide a personal channel to ask about your company or products. People react much better to a human and interact more with them than with a corporate account. Be yourself – at no point you should become a corporate sales person. Do triage – point people to resources to use like feedback channels instead of talking on their behalf Don’t make decisions for your colleagues. Help them, don’t add to their workload.

Keep up to date with competition and market

You’re the ear on the ground – your job is to know what the competition does and what gets people excited. Use the products of your competition to see what works for you and their users and give that feedback to your teams. Detect trends and report them to your company.

Create openly available software products

You need to develop software products to keep up to date technically and show your audience that you’re not just talking but that you know what you’re doing. These should be openly available. In many cases, your company can’t release as freely as you can. Show the world that you’re trusted to do so. Building products also allows you to use tools outside developers use and feed back your experiences to your company

Participate in other products

Take part in other people’s open source products. That way you know the pains and joys of using them. Your job is to be available. By providing helpful contributions to other products people judge you by your work and how you behave as a community member, not as a company person. Analysing how other products are run gives you great feedback for your teams.

Participate in public discussions

A lot of discussion happens outside your company, on channels like Stackoverflow, Slack, Facebook Groups, Hacker News and many more. You should be monitoring those to a degree and be visible, bringing facts where discussions get heated. These are great places to find new influencers and partners in communication.

Participate in other publications

Taking part in other publications than your own and the ones of your company solidifies your status as a thought leader and influencer. Write for magazines, take part in podcasts and interview series. Help others to get their developer oriented products off the ground – even when they are your competition.

Create video tutorials

Creating short, informative and exciting videos is a great opportunity to reach new followers. Make sure you keep those personal – if there is a video about a product, help the product team build one instead. Show why you care about a feature. Keep these quick and easy, don’t over-produce them. These are meant as a “hi, look at this!”.

Participate and help with events

Present and give workshops at events. Introduce event organisers and colleagues or other presenters you enjoyed. Help promote events. Help marketing and colleagues at events to make your presence useful and yielding results.

Act as a “firewall” for internal teams

People working on products should spend their time doing that – not arguing with people online
Your job is to take negative feedback and redirect it to productive results
This means in many cases asking for more detailed reporting before working with the team to fix it.
It also means managing expectations. Just because a competitor has a cool new thing doesn’t mean your company needs to follow. Explain why.

Help dealing with influencers

If you do your job right and talk to others a lot, what other people call ”influencers” are what you call friends and contacts. Show them how much you care by getting them preview information of things to come. Make sure that communication from your company to them goes through you as it makes outreach much less awkward. Find new upcoming influencers and talk to your company about them.

Inbound tasks

Stay up to date and participate in products

There is no way to be a developer evangelist for a company if you don’t know about the products your company does. You need to work with and on the products, only then can you be inspiring and concentrate on improving them. Working on the products also teaches you a lot about how they are created, which helps with triaging questions from the outside.

Keep product teams and internal engineering up to date

It is important to report to your product teams and engineers. This includes feedback about your own product, but also what positive and negative feedback the competition got. This also includes introducing the teams to people to communicate with in case they want to collaborate on a new feature.

Amplify messaging of internal teams

Your colleagues bring great content, it is your job to give it reach. Amplify their messages by spreading them far and wide and explaining them in an understandable fashion to different audiences. Tell other influencers about the direct information channels your teams have.

Coach and promote internal talent

It is great that you can represent your company, but sometimes the voice of someone working directly on a product has more impact. Coach people in the company and promote their presence on social media and at events. Connect conference organisers and internal people – make sure to check with their manager to have them available. Help people present and prepare materials for outreach.

Report on events and success of campaigns

Being at an event or running a campaign should be half the job. The other half is proving to the people in the company that it was worth it. Make sure to collect questions you got, great things you learned and find a good way to communicate them to the teams they concern. Keep a log of events that worked and those who didn’t – this is great information for marketing when it comes to sponsorship.

Help organising events

It is important to be involved in the events your company organises. Try not to get roped into presenting at those – instead offer to coach people to be there instead. Offer to be on the content board of these events – you don’t want to be surprised by some huge press release that says something you don’t agree with. Use your reach to find external speakers for your events.

Work with PR, legal and marketing

Your work overlaps a lot with those departments. Be a nice colleague and help them out and you get access to more budget and channels you don’t even know about. Make sure that what you say or do in your job is not causing any legal issues.

Give constructive feedback to the product teams and get questions answered

You’re seen as a approachable channel for questions about your products. Make sure that requests coming through you are followed up swiftly. Point out communication problems to your internal teams and help them fix those. Use external feedback to ask for improvements of your own products. It is easy to miss problems when you are too close to the subject matter.

Collate outside feedback and convert to constructive feedback

Your colleagues are busy building products. They shouldn’t have to deal with angry feedback that has no action items in it. Your job is to filter out rants and complaints and to analyse the cause of them. Then you report the root issue and work with the teams how to fix them.

Why take on this job?

Considering how full your plate is, the following question should come up:

Why would you want to become a developer evangelist (or developer advocate)?

There are perks to being someone in this role. Mostly that it is a natural progression for a developer who wants to move from a delivery role to one where they can influence more what the company does.

  • It bridges the communication gap – developers have a bad reputation when it comes to communication. Showing that someone technical can help understanding each other is a good move for our market.
  • It helps avoiding frustration – a lot of engineering is not needed, but based on false assumptions or misguided “I want to use this”. Good evangelism helps building what is needed, not what is cool.
  • It bridges age and culture gaps – if you’re not interested in a cutthroat competition in engineering, you have a chance to use your talent otherwise.

Before you jump on the opportunity, there are some very important points to remember:

  • Developer relations is not a starting position – most developer evangelists graduated from being developers in the same company. You need to know the pain to help prevent it.
  • There are part time opportunities though – engineers or people learning in the company can help with Devrel to ease into the job earlier.
  • Always be ready to prove your worth – measuring the impact of a developer evangelist is tough, you need to make sure you’re well organised in recording your successes.

It’s a versatile, morphing and evolving role. And that – to me – makes it really exciting.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Developer Edition 50: Console, Memory Tool, Net Monitor and more

Firefox Developer Edition 50 is here. It has numerous improvements that will help you work with script-initiated network requests, tweak indexedDB data, and much more. It also introduces something special we’ve all been really wanting for a while, so let’s get right to it:


A long awaited feature is finally coming to the dev tools, but we need your help in this final phase of testing. The source maps feature is currently preffed off by default, as we test before shipping it to everyone.

If you’re curious as to why this has been such a challenging issue, James Long wrote an excellent post on the matter: On the Road to Better Sourcemaps in the Firefox Developer Tools

Curious how the solution came about? I’ll paraphrase our own Joe Walker,

“Interns often don’t have all the background on how difficult bugs are, and sometimes jump into really challenging bugs—which is to say, yay interns! ”

So, a big thanks to Firefox Developer Tools’ intern Jaideep Bhoosreddy for figuring it out.

Source maps allow you to compact all your JavaScript files in one script in order to save download time for your users, or to compile from another format (like TypeScript or CoffeeScript) to Javascript, while maintaining a reference to the original files, so it’s not a nightmare to debug.

Source maps were supported in the debugger, but not in the console till now. This meant that any logged message had its location (the file and the line the log was emitted from) point to the compiled JavaScript file, but if said file was long and/or minified, this location info was barely usable.

Those times are over. The console will now show the original source, and not the compiled one anymore. You can view it in action in the gif below, with a CoffeeScript file:

Gif demonstrating source map support in console with a CoffeeScript file

Source map support in the console

Source map support is currently off by default and can be activated through a preference. Because there are various implementations in the wild depending on the tool used to build the source map file, we want to get some initial testing of the different variations. That’s where you come in.

Here’s how you can help:

To activate source map support in the console, please set the preference on.

  • Go to about:config
  • Search for devtools.sourcemap.locations.enabled
  • Double-click the line to toggle the value to true
  • Close and re-open the web console

about:config screenshot for enabling source map support

If you see anything that looks wrong, shout out to @firefoxdevtools on Twitter or let us know on the #devtools channel on IRC.

Network Stack Trace

In Firefox Developer Edition 50, the console now shows the stack trace that led to a network request in HTTP log message. This is on by default.

Screenshot of an HTTP log's stack trace in the console

Memory Tool

The Memory Tool is also now enabled by default. This is a must-have tool for debugging and maintaining top-notch app performance. It helps you to find and fix memory leaks in your application. If you want to learn more about it, check out the article on MDN or go read the Hacks post on Firefox’s New Memory Tool.

Network Monitor

In Firefox 49, the “Cause” column was added. It shows how a given network request is initiated, its type and, if available, the stack trace that led to it. The stack trace bubble now shows the frame asynchronous cause (XHR, Promise, setTimeout, etc.), similar to the debugger stack trace panel.

Screenshot of the Network Monitor panel showing a stack trace with an asynchronous cause

Furthermore, entries can be sorted by their cause by clicking on the column header. This could be helpful to quickly find all the network requests that were initiated by fetch for example.

JSON Viewer

The JSON Viewer was refined and shows data in a smarter manner:

Storage Inspector

Following the global effort by Mike Ratcliffe and Jarda Snajdr to improve the Storage Inspector, it is now possible to remove a single indexedDB entry through the context menu.

Screenshot of the context menu to remove an IndexedDB entry in Storage Editor


Service Workers are definitely the next big thing in Web development, providing a whole set of tools you can use to build progressive web apps that match native apps in functionality, with offline capabilities and push notifications.
Did you know that you can manage registered Service Workers in the about:debugging#workers page? This page now also shows push subscription endpoints and allows you to send a test notification with no more effort than the click of a button.

Screenshot of Push subscription endpoints in the about:debugging page

Other Notes

Icons: Icons across all the developer tools got even better in Firefox 50. They are now more consistent and look sharp as a knife.

Devtools tab icons in Firefox 49

Tab icons in Firefox 49
New devtools tab icons in Firefox 50

New tab icons in Firefox 50

WebAssembly: As Luke Wagner said in a previous blog post :

“WebAssembly is an emerging standard whose goal is to define a safe, portable, size- and load-time efficient binary compiler target which offers near-native performance”

WebAssembly files were already supported in the debugger, and they are now highlighted which make them look much nicer.

Screenshot of WebAssembly file syntax highlighting in debugger

WebAssembly file syntax highlighting

And to wrap up, a minor but useful change: the Style Editor can now be disabled to save some space if you don’t use it.

With that, we’ve completed the overview of Developer Edition 50. Download the latest update now and let us know what you think. One last thing, though. A lot of the improvements we covered in this post were made possible by awesome contributors. Big thanks to all of you.

The dev tools are written using standard HTML, Javascript and CSS, so if you have any front-end development experience, you can contribute too. If you want to help the dev tools to get even better, you can find easy bugs to start with in Everyone is welcome!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Developer Edition 49: Network Request Stack Traces and more

This week marks the release of Firefox Developer Edition 49! This post covers some of the big changes that landed in this release.

Request stack traces in Network Monitor

The Network Monitor now has a new “Cause” column that shows how a given network request is initiated. The column shows the type of the request, includes a tooltip with the loading document, and, most importantly, if a JavaScript stack trace is available, you can see it in a popup bubble.

The JavaScript stack trace is most interesting for XHR requests, but is available also for any other request that is directly or indirectly initiated by a script, like when a script inserts a <script> or <img> element into the page.

This feature is useful if you want to figure out why and from where on the page a particular HTTP request is issued. (See bug 1134073.)


Animation performance info in Inspector

You can use the Inspector panel to investigate details of your CSS and DOM animations. In Firefox 49, you can now get detailed performance information for your animations. If an animation property cannot be run on the compositor (i.e., cannot be hardware-accelerated), it is underlined in the expanded animation view, and an associated tooltip explains what’s going on.

In the example below, the transform and width properties cannot be accelerated at the same time. With this new tool in Inspector, you can now spot under-performing animations and learn what changes you need to make to accelerate them.

Read David Baron’s blog post if you want to learn more about how animations are optimized in Gecko. (See bug 1254408 for more detail.)


Reorganized context menu in markup view

The Inspector has a context menu with many actions, which was becoming long and unwieldy. Contributor Moaaz Sidat reorganized the menu, dividing it into several sub-menus. (See bug 1211613.)


Other improvements in the Inspector Panel

Firefox 49 adds support for #rrggbbaa and #rgba syntax for color values. The Inspector in developer tools now supports this syntax, too. (See bug 1271191.)


In the CSS rule editor, autocomplete now displays more possible properties, in a scrollable list. As a result, it’s much easier to find the value that is relevant to you, or learn about new CSS properties that you were not familar with previously. (See bug 1260419.)


In the markup view, self-closing tags like <br> are now displayed as <br></br> only if the doctype is XHTML. For normal HTML, the markup is now displayed in a more accurate and less verbose form. (See bug 820926.)

Links to MDN reference docs From Console JavaScript errors

When you see an unfamiliar error message in the Console, you no longer need to copy the message and search online for documentation. You can simply click on a direct link to the MDN reference page about the error that is a part of the message. Read a blog post by @floscholz and @mrrrgn to learn more about this feature and how you can contribute to make it better. (See bug 1179876.)


New color scheme for syntax highlighting

We thought our syntax highlighting colors were looking a little dated, so we changed them up in both the light- and dark-themed versions of Developer Edition Firefox. The new colors are optimized for accessibility: they have better contrast and are easier to distinguish in all situations.



Accessibility improvements

We’ve made important accessibility improvements throughout this release. Most developer tools UI elements now have a clearly visible focus indicator, the UI is navigable using the keyboard, and accessibility semantics in the Inspector panel were improved. (See bugs 1242694, 1242715, and 1242851.).

Other notable changes

In addition to the improvements above, we have polished various areas throughout the developer tools, in particular:

  • The about:debugging page displays a warning when service workers are disabled, whether by private browsing mode or by a pref. (See bug 1266415.)
  • Step by step, the Storage Inspector is becoming more editable. In this release, we are adding a context menu option to delete an IndexedDB database. (See bug 1205123.)
  • Network Inspector now shows the exact number of bytes if the response size is smaller than 1KB. (See bug 1263945.)
  • Pressing the ‘h’ key in the Inspector panel, which is a shortcut to hide the selected element, now also grays out the element markup. (See bug 1127572.)

Thanks to everyone who has contributed to this Developer Edition release! Grab a copy of the latest Developer Edition now and let us know what you think.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Developer Edition 48 – Firebug features, editable storage, inspector improvements and more…

This week marks the release of Firefox Developer Edition 48. In preparation for the arrival of multiprocess Firefox and the deprecation of the Firebug add-on, we are porting Firebug features to the built-in tools. We have also made tweaks to the current tools that we’ll cover in this post.

Firebug theme

As part of porting Firebug features to the built-in tools, we’re also porting the Firebug theme, giving Firebug users a more familiar environment to work with. This is the initial release of the theme so please let us know if you find any bugs and report them here. Here is a screenshot of the Firebug theme:

Firebug theme

DOM panel

The DOM panel is another feature we are porting from Firebug. This panel provides a handy tree view which allows you to browse and inspect the DOM structure of your page. Here’s a screenshot of the new tool:

DOM Panel screenshot

Editable storage

Editing support inside the storage inspector is one of the most frequently requested features. In this release, we added the ability to edit and delete cookies, local storage, and session storage entries. You can edit a cell by double-clicking on it. You can also delete entries by using the context menu.
Editable storage entries

Deletable cells

Geometry editor

In this release, we have added a new visual editing tool that allows you to easily tweak the positioning of any absolutely positioned or fixed-position element. You can change the values of the top, left, bottom and right properties using this tool. To launch the geometry editor, go to the Box Model tab in the inspector and click on the Geometry editor icon icon.

Geometry Editor

Memory tool improvements

The memory tool is now enhanced with a brand new tree-map view that gives a quick and intuitive visual overview of how memory is being used. This new view groups objects together by their types, which allows you to easily see the quantity of similar items (arrays when drawing canvas lines, scripts when loading a script-heavy website, etc.) taking up memory. Also, the size of each item in the map is proportional to the amount of bytes used, which allows you to easily see which items are taking up most of your memory.

Memory tool tree map

The memory tool provides a useful aggregate view that groups all instances of the same type of node. In this release, you can now click the ? icon to view all individual instances of a specified type in a separate view. You can also view the retaining paths of those individual nodes, using the retaining paths panel added in the previous release. This allows you to precisely pinpoint how a specific object is leaking when debugging your web app.

Aggregate view individual nodes

Finally, we have also added the ability to remove individual snapshots from the memory tool sidebar.

Inspector improvements

We have polished the user experience in the inspector to make it smoother and easier to use. The Rules view autocomplete now selects the most used property by default to make your authoring experience faster. For example, background will be selected instead of backface-visibility because it’s more frequently used. Here is a screencast of the feature in action:

Better rules view autocomplete

We have also improved the way long values are handled in the Rules view. A new multi-line mode specifically for long values lets you conveniently reach and select different parts of the value you’re editing.

Multi-line mode

The markup view now emphasises the relationship between a parent node and its children. The selected element now has a line underneath it that highlights the child nodes. This allows you to easily spot the selected element child nodes when the HTML markup is complex.

Parent child relationship

A quick way to switch between different angle units in the Rules view has been added. There is now a swatch next to angle values which you can shift-click to cycle between different units, similar to the colour values interaction. This feature was added by contributor Nicolas Chevobbe.

Cycle between angle units

Finally, we have added keyboard shortcuts to easily navigate between the markup view search results. You can now use Shift+Enter to navigate backwards within the search results. Also, Ctrl/Cmd+G and Ctrl/Cmd+Shift+G now work as aliases for Enter and Shift+Enter. These keyboard shortcuts were added by contributor Steve Melia.

Console improvements

The console has also received various tweaks that will make your daily experience with the tool more enjoyable. The first improvement comes from the set of Firebug features we’re porting. You can now expand network logs to inspect them and reveal a Firebug-style details view. Here is a screenshot:

Inline HTTP inspection

If you’re working with Map or Set objects, you can now view and inspect their individual entries from the console sidebar. This feature was added by contributor Jarda Snajdr.

Improved Map/Set inspection

Finally, we have added support for console.clear() to clear the console output.

about:debugging features

In preparation for the release of WebExtensions, we’ve added a feature that will be a great help to add-on developers. You can now reload add-ons from about:debugging, which allows you to quickly develop your add-on without having to re-install it every time you make a change.

Reloading add-ons with about:debugging

If you’re working with Service Workers, you’ll notice that we have added a way to unregister individual workers. Here is a screenshot:

Unregister service workers

Other notable changes

In addition to the changes above, we have polished various areas of the toolbox including:

Thanks to everyone who contributed to this release! Make sure to grab a fresh copy of Firefox Developer Edition and share your thoughts! If you have feedback about different Firebug features being ported, we’d love to hear your suggestions and constructive comments here.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Developer Edition 47 – User agent emulation, popup debugging and more

This week marks the release of Firefox Developer Edition 47! In recent weeks, we’ve covered the DevTools reload add-on and service worker tooling, so be sure to check out those posts. In this post, we’ll cover the rest of the updates and changes in this Developer Edition release.

User Agent emulation

We have added the ability to emulate a custom user agent on any webpage from responsive mode. You can now simply type your new user agent string inside the “Custom User Agent” field. You can use this to check whether a site uses user agent sniffing. For example, you can type in a mobile browser user agent to see how a website would look on your phone.

Here is a screencast of the feature:
User Agent Emulation

Retaining paths as graph

In the previous release, we added a dominator view to help you debug memory-intensive applications. In this version, we’ve improved it by adding a retaining paths panel, which gives you a graph displaying all the nodes that are preventing a selected node from being garbage collected. This is particularly useful when you are debugging a possible memory leak. You can read more about this feature in the MDN documentation here.

Here is a screenshot of the graph:

Console multi-line input

The way multi-line input in the console is handled has been improved. When pressing the “Enter” key, the console will now detect whether your input is complete or not. If it is, pressing “Enter” will simply execute your command. If not, pressing “Enter” will add a new line to your input, so you can seamlessly continue writing your command.

Storage Inspector

The storage inspector now has support for cache storage, which is very useful if you’re debugging a service worker. Be sure to check Sole Penadés’ blog post that dives into the details of service worker debugging.

In addition to cache storage support, you can now filter the contents of the table using the search box located on the top toolbar. Here’s a screenshot of the feature:

Theme changes

In this release, we gave a visual tune-up to the toolbox. We have made small tweaks such as reducing the default tab width and adding new icons inside the memory tool, but we have also made some major changes. For example, we gave the light theme a complete makeover, to give it a lighter and more polished look and feel.

Here is a screenshot of the new light theme:
Refreshed light theme

We have also updated the debugger gutter style—conditional breakpoints are now highlighted in the gutter in orange. Here’s a screenshot:
New debugger gutter

Finally, we have moved the network monitor toolbar to the top to be more accessible and more consistent with the other tools.
Network monitor toolbar

Debugging popups for addons

In preparation for the release of WebExtensions, we are adding new features that will make add-on debugging easier. In this release, we’ve made inspecting popups much easier. You can now lock popups so they don’t disappear once you click away. To use this feature, you need to launch the Browser Toolbox and click the icon with the four squares located in the top-right corner of the toolbox. You can read more about how to debug your extensions here.

Here is a screencast showing this feature in action:

Other notable changes

In addition to the improvements above, we have polished various areas throughout the toolbox, in particular:

We have also removed the 3D view, since this feature conflicts with the multi-process version of Firefox. If you’d like to use the feature, you can install this add-on instead.

Finally, the font inspector has been disabled by default, since it will be reworked for future releases. You can re-enable the tool by toggling the devtools.fontinspector.enabled preference in about:config.

Thanks to everyone that has contributed to this Developer Edition release! Grab a copy of the latest Developer Edition now and let us know what you think.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Answering some questions about developer evangelism

I just had a journalist ask me to answer a few questions about developer evangelism and I did so on the train ride. Here are the un-edited answers for your perusal.

In your context, what’s a developer evangelist?

As defined quite some time ago in my handbook (

“A developer evangelist is a spokesperson, mediator and translator between a company and both its technical staff and outside developers.”

This means first and foremost that you are a technical person who is focused on making your products understandable and maintainable.

This includes writing easy to understand code examples, document and help the engineering staff in your company find its voice and get out of the mindset of building things mostly for themselves.
It also means communicating technical needs and requirements to the non-technical staff and in many cases prevent marketing from over-promising or being too focused on your own products.
As a developer evangelist your job is to have the finger on the pulse of the market. This means you need to know about the competition and general trends as much as what your company can offer. Meshing the two is where you shine.

How did you get to become one?

I ran into the classic wall we have in IT: I’ve been a developer for a long time and advanced in my career to lead developer, department lead and architect. In order to advance further, the only path would have been management and discarding development. This is a big issue we have in our market: we seemingly value technical talent above all but we have no career goals to advance to beyond a certain level. Sooner or later you’d have to become something else. In my case, I used to be a radio journalist before being a developer, so I put the skillsets together and proposed the role of developer evangelist to my company. And that’s how it happened.

What are some of your typical day-to-day duties?

  • Helping product teams write and document good code examples
  • Find, filter, collate and re-distribute relevant news
  • Answer pull requests, triage issues and find new code to re-use and analyse
  • Help phrasing technical responses to problems with our products
  • Keep in contact with influencers and ensure that their requests get answered
  • Coach and mentor colleagues to become better communicators
  • Prepare articles, presentations and demos
  • Conference and travel planning

How often do you code?

As often as I can. Developer Evangelism is a mixture of development and communication. If you don’t build the things you talk about it is very obvious to your audience. You need to be trusted by your technical colleagues to be a good communicator on their behalf, and you can’t be that when all you do is powerpoints and attend meetings. At the same time, you also need to know when not to code and let others shine, giving them your communication skills to get people who don’t understand the technical value of their work to appreciate them more.

What’s the primary benefit enterprises hope to gain by employing developer evangelists?

The main benefit is developer retention and acquisition. Especially in the enterprise it is hard to attract new talent in today’s competitive environment. By showing that you care about your products and that you are committed to giving your technical staff a voice you give prospective hires a future goal that not many companies have for them. Traditional marketing tends to not work well with technical audiences. We have been promised too much too often. People are trusting the voice of people they can relate to. And in the case of a technical audience that is a developer evangelist or advocate (as other companies tend to favour to call it). A secondary benefit is that people start talking about your product on your behalf if they heard about it from someone they trust.

What significant challenges have you met in the course of your developer evangelism?

There is still quite some misunderstanding of the role. Developers keep asking you how much you code, assuming you betrayed the cause and run the danger of becoming yet another marketing shill. Non-technical colleages and management have a hard time measuring your value and expect things to happen very fast. Marketing departments have been very good over the years showing impressive numbers. For a developer evangelist this is tougher as developers hate being measured and don’t want to fill out surveys. The impact of your work is sometimes only obvious weeks or months later. That is an investment that is hard to explain at times. The other big challenge is that companies tend to think of developer evangelism as a new way of marketing and people who used to do that can easily transition into that role by opening a GitHub account. They can’t. It is a technical role and your “street cred” in the developer world is something you need to have earned before you can transition. The same way you keep getting compared to developers and measured by comparing how much code you’ve written. A large part of your job after a while is collecting feedback and measuring the success of your evangelism in terms of technical outcome. You need to show numbers and it is tough to get them as there are only 24 hours in a day.
Another massive issue is that companies expect you to be a massive fan of whatever they do when you are an evangelist there. This is one part, but it is also very important that you are the biggest constructive critic. Your job isn’t to promote a product right or wrong, your job is to challenge your company to build things people want and you can get people excited about without dazzling them.

What significant rewards have you achieved in the course of your developer evangelism?

The biggest win for me is the connections you form and to see people around you grow because you promote them and help them communicate better. One very tangible reward is that you meet exciting people you want to work with and then get a chance to get them hired (which also means a hiring bonus for you).
One main difference I found when transitioning was that when you get the outside excited your own company tends to listen to your input more. As developers we think our code speaks for itself, but seeing that we always get asked to build things we don’t want to should show us that by becoming better communicators we could lead happier lives with more interesting things to create.

What personality traits do you see as being important to being a successful developer evangelist?

You need to be a good communicator. You need to not be arrogant and sure that you and only you can build great things but instead know how to inspire people to work with you and let them take the credit. You need to have a lot of patience and a thick skin. You will get a lot of attacks and you will have to work with misunderstandings and prejudices a lot of times. And you need to be flexible. Things will not always go the way you want to, and you simply can not be publicly grumpy about this. Above all, it is important to be honest and kind. You can’t get away with lies and whilst bad-mouthing the competition will get you immediate results it will tarnish your reputation quickly and burn bridges.

What advice would you give to people who would like to become a developer evangelist?

Start by documenting your work and writing about it. Then get up to speed on your presenting skills. You do that by repetition and by not being afraid of failure. We all hate public speaking, and it is important to get past that fear. Mingle, go to meetups and events and analyse talks and articles of others and see what works for you and is easy for you to repeat and reflect upon. Excitement is the most important part of the job. If you’re not interested, you can’t inspire others.

How do you see the position evolving in the future?

Sooner or later we’ll have to make this an official job term across the market and define the skillset and deliveries better than we do now. Right now there is a boom and far too many people jump on the train and call themselves Developer “Somethings” without being technically savvy in that part of the market at all. There will be a lot of evangelism departments closing down in the nearer future as the honeymoon boom of mobile and apps is over right now. From this we can emerge more focused and cleaner.
A natural way to find evangelists in your company is to support your technical staff to transition into the role. Far too many companies right now try to hire from the outside and get frustrated when the new person is not a runaway success. They can’t be. It is all about trust, not about numbers and advertising.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Developer Edition 46 – More memory tooling, improved @media sidebar and more

Firefox Developer Edition 46 is now here! In this version, we’ve added various memory profiling features and improved many of our current tools as well. This post covers some of the big changes that landed in this release.

Dominator view in the memory tool

A new view is now available within the Memory Tool that will aid in debugging and profiling memory intensive web applications. Dominator view provides insight into object memory allocation. This is a cumulative view indicating the size of the objects (shallow) and any referenced objects (retained) that are currently allocated. This allows you to easily see the impact a particular object is having on memory. Using this view also lets developers quickly locate the code responsible for creating a specific object. You can read more about this feature here.

Here’s a screenshot of the Dominator view:

Screenshot of the dominators view in Firefox DevTools

Performance tool and GC profiling

The performance tool now allows you to include allocations in your recordings. This is useful to help you reduce the amount of GC done in your web app for more responsiveness. You can enable allocations in the performance tool by clicking on the settings cog, then by checking the “Record Allocations” menu item.

Here’s a screenshot of the Allocations view:

Screenshot of 'allocations view' in performance tool

Emscripten demangling feature

When compiling native code through Emscripten, you will notice that the function names are changed by the compiler. We’ve now added support for demangling C function names in the profiler call tree, so you can easily refer to your original uncompiled code (development notes)

Style Editor and @media queries

Firefox Developer Tools provides a Responsive Design View, used to develop responsive websites that can respond to accommodate many screen sizes. You can use this view along with the media query sidebar to quickly see which media rules are currently activated for a given screen size selection. The new release of the media query sidebar now provides quick links on each media rule that automatically adjust the screen view size in the Responsive Design View. You can check the development notes here.

Here’s a screencast of the feature in action:

Media query links

Always-on Debugger

Also, the debugger will now always pause on debugger statements when the toolbox is opened, even if the panel hasn’t been activated yet. You can read James Long’s blog post for more technical detail.

More polish

In addition to the improvements above, we’ve also polished many areas of the toolbox, in particular:

Thanks to everyone that has contributed to this Developer Edition release! Grab a copy of the latest Developer Edition now and let us know what you think!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)