Developer

[Job] Help create the Windows version of Framer – React developer in Amsterdam

TL;DR: Framer are looking for a React developer based in Amsterdam to create the Windows version of the app with help from my team. Apply here.

Framer is only available on OSX

One of the things that annoy me the most is operating system dependence. It is frustrating to see a great new tool you want to use but it isn’t available on your platform. Not everyone can afford Apple hardware or wants to do everything in Windows or Android. I personally use several operating systems and it annoys me that I can’t use the same tool stack. Instead you need to learn different ones for each OS (Keynote/Powerpoint anyone?). It feels like the 90s.

That’s why I was happy when Framer contacted me and asked me to help them find someone to work on the Windows version of their great tool. The great news is that you’re not only going to work for a cool company. You also get to work directly with our team here to ensure that the port is going to be a great product. At Microsoft we have a dedicated team helping people to port apps. This team has deep insight into what to do and what to avoid to create an app that takes advantage of the things Windows 10 offers.

So, if you are:

  • A React Native developer who wants to build a great, well-used app for a big community
  • Have Windows experience and supporting more than Chrome/OSX in your WebView
  • Look for a full-time position in Amsterdam, The Netherlands

Apply now, and we can soon bridge another support gap that that is well over-due.

This is a short time offer, Framer are looking to hire someone ASAP and bring out the Windows version within a few months. The new Framer version is close to Alpha release internally.

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 comes after senior developer?

A few weeks ago a company approached me if I’d be available to give a series of talks and Q&A for senior developers. Their question was how to deal with the problem that there seems to be an upper limit to technical careers. At one time in our career we have a decision to make if we want to keep being technical or moving into management. It sounds odd, but there is a lot of truth to it.

A gap in company hierarchies

Throughout my career I found that there is a limited amount of levels you can climb as a technical person. This sounds unfair, especially in companies that pride themselves on being technical. The earlier you are in your career, the more annoying this seems.

When we start, we love being developers. We see technology solve problems in a logical and enjoyable fashion. Much less icky, slow and error-prone as human communication. It makes us believe that you can solve everything with technology. Which is great, as this is also what excites us. People excited about their jobs work better.

On the whole we earn good money, have a high-quality work environment and feel we could do this forever. Sometimes we get too excited about developing. We don’t realise that we burn out or are being taken advantage of. I’ve seen product managers trying to make a mark by releasing a product before the deadline. They then coerce junior developers to work too much or cut corners. At the cost of endangering the quality and even the security of the product. And the mental health of the developer.

Seeing this dedication it feels weird not to have technical role models to look up to. At a certain level in the company it seems you need to stop coding and do things we don’t like to do instead.

What annoys us?

We love to complain about things at work. As developers we are quick to blame things beyond our control for failures. It can’t be the problem of the technology or our skill, right? We’re excited about what we do, and that means only good things can come out of that.

Often we see products go wrong. Most of the time because of business decisions that make no sense to us. Business decisions that interfere with our development plans. People get allocated elsewhere, budgets of exciting products get cut. Products we’d love to see go live as their technology is cool and innovative.

Meetings are plentiful, not productive and get us out of our development zone. Why should I sit in a room talk about what I do when the version control comments do the same job?

Time and allocation estimations keep being wrong. Either we’re allocated to a project that doesn’t need us, or we don’t have enough people. We run out of time when developing products and often by the time we release, the market stopped caring. Or our competitor was faster.

Whilst underestimating it ourselves, we often see other engineers burn out. There is a huge churn of people and it is tough to build teams when people keep leaving and new ones get hired. It is hard to keep up good quality in a product when the team keeps changing. It is tough to innovate when you spend a lot of time showing people the ropes. And innovation is something our market seems to be running on. It is also what excites us as developers, We want to do new, cool, things and talk about them.

We face the issue that we keep having new people but there is never enough time for training. When we read the technology news feeds there seems to be so much to look at but it is beyond our reach. Instead we spend our time re-educating joiners on how things work in our company. And it feels that we ourselves fall behind whilst our job is to be inspiring to junior developers.

What are we worried about?

As developers in the trenches and in the flow of excitement we worry about a lot of things. We find that keeping up with technologies is a full-time job. If you’re not on the bleeding edge you will only get boring work or someone will take your job. This is odd considering the amount of job offers we get and how starved for talent our market is. But we worry and we stress out about it. Younger, fresher people seem to be much quicker in grasping and using new tech as we are.

We also see coding as a fun thing and we don’t want to stop doing it. We remember that we had no respect for people who didn’t write code but use products instead. We don’t want to be those people, but it seems that to advance our careers, we need to.

Turning the tables

It is a good thing that these thing annoy us as they are an opportunity for us to turn the tables. By shifting into a role that is a technical hybrid you can battle some of these annoyances. The hierarchy gap is an indicator that there is a rift between the technical staff and management. A gap that is costly and hinders our companies from innovating and being a place where people want to work.

It is painful to see how clumsy companies are in trying to keep their techies happy. We do team building exercises, we offer share options. We pay free lunches and try to do everything to keep people in the office. We print team T-shirts and stickers and pretend that the company is a big, happy family. We pay our technical staff a lot and wonder why people are grumpy and leave.

All these things are costly and don’t have the impact our companies hope for. The reason is that they lack respect and understanding. When the basic needs of humans are met there is no point adding more creature comforts. There is no point earning more money when you have even less time outside work to enjoy it.

What gets us going is a feeling of recognition and respect. And only peers who’ve been in the same place can give that. There is no way to give a sincere compliment when you can’t even understand what the person does.

And this is where we have our sweet spot. Our companies struggle for relevance in comparison to others as much as we do with out peers. And often they lack input from us. Instead of implementing what has always been done a certain way we can bring a reality check. The market keeps changing and it is up to us to remind our companies what excites technical talent.

There may be a path already available to you – or you have to invent one to do that. In any case, your first job is to become visible to your company as someone who cares and wants things to change. This means partnering with HR, hiring and PR. It also means selling yourself to management as someone ready to change things around.

Becoming a fixer of bigger problems…

The fun thing to remember is that as a company in the technology space, everybody has similar worries. Think you are worried about falling behind? Your company is much more worried, and you are closer to the subject than the people running it.

Research what worries you, share how you keep up to date and what it means for your company. It makes sense for a company to get the gist of a new technology from someone who can verify it. A lot more sense than falling for a hype and buy a third party product or consulting on the subject.

Often we’re asked to implement something hot and cool that doesn’t make any sense. The reason was most likely some PowerPoint circulating in upper management. A presentation based on what excites the tech press and not what makes your product better. Try to be there with advice creating that PowerPoint before you have to deal with its impact.

Retention of talent is another thing every company worries about. Churn and burnout of engineers is a big issue. Try to offer solutions – things that help you and keep you here. Every engineer coming through the door is a 20,000 GBP investment. Even before they wrote their first line of code or got access to the repository. Every engineer staying at your company is a worth-while investment. Making sure you help find your company ways to keep people is a big plus for you.

Another way to shine is by bringing in new talent. It is a competitive market out there and it is hard for a company to find new engineers. As developers we’ve grown weary of terrible job offers. It is not uncommon to see demands like five year experience for a one year old technology. You can help prevent your company from such embarrassment. Work with your hiring department to draft sensible job descriptions. Even better, go to events and meetups. Look through pull requests and comments on repos to spot possible candidates.

Find ways to encourage your engineers to hire by word-of-mouth. This is is how I found my last five jobs and this is also how I made up for some income gaps. A company that pays a bonus for each hired person has employees as advocates. People we trust are more likely to be good colleagues. Better than random people you have to filter out with a good interview process. Try to make your company visible where developers are by being a great example, and you may stir interest.

Nonsensical job offers are a symptom of a general problem with internal communication. This is rampant in our market. Developers hate managers, managers don’t get developers. You can mediate. It is a tight-rope walk at times as you don’t want to come across as someone trying to please management. But it is a necessary step, and if better communication is the result, worth your time and some arguments.

External communication and marketing is another department you can help with. How often did you facepalm reading advertising by your company? Help avoiding this in the future by being a technical advisor.

Overall, this is about being an ear on the ground for your company. To non-technical people in a company navel-gazing is common. The job of marketing is to make your company’s products look good. Often this means that people get a bit too excited about your own produce. They don’t compare, they don’t even have time to look at what others are doing. This is a good chance for you to keep up with what the competition is doing and tell what it means to your company. You’ve done the research for them, and that is worth a lot.

New skills that are old skills…

The fun part about being a coder is that you don’t have to deal with people. This ends when you want to move further up. Your “soft skills” are what will allow you to stay technical and have a new role. Your technical skill is an asset, but it is also limited – even when you don’t want to admit it yet. Being a technically skilled person with good communication skills is the sweet spot to aim for. The higher you communicate upward, the less people are interested in technical details. Instead they want to see results, impact and costs.

Sales people know that. Learn from how they work, but stay true to what you talk about. Instead of selling by hushing up bad aspects, sell your technical skill to prevent mistakes. Instead of bad-mouthing your companies’ competitors, be in the know about them and show your company what to look out for. We all sell something. Why not sell what excites you and your experience instead of having to patch what others messed up?

Flexibility is the key

My career took off when I stopped caring where and when I worked. Being open to travel is important. Most communication problems in companies are based on time difference. Be the one that is available when others are. Try to be open to any technology and listen to their benefits and problems. You will not live and die in one stack.

Things not to worry about…

You are not betraying the brotherhood of coders by moving up. They have no wrath worth worrying about. You will be asked constantly if you still code. But it is natural that you will lose interest in being on the bleeding edge all the time and doing the work. We all slow down and want a life besides chasing the cool. You will also wonder why the hell everything is so complex now when it used to be so simple. Even when you don’t code all the time, you won’t be bored. Consider this a chance to fix what always annoyed you.

You will be praised for things you haven’t done. Much like you are praised as a developer for things you don’t consider good. People can’t measure what is good, they see what you do and are impressed. Take the praise but make sure to share it with those who did the work.

Realities to prepare for…

Let’s re-visit the worries we have as developers and give them a reality check.

Keeping up with technologies is a full-time job. It is! So find a way to convince your company and managers that you are good at doing that. Remember that you need to free up a lot of time on your schedule to do that. This means not doing all the work but getting better at delegating. It also means giving more conservative estimates about your deliveries and deadlines. This can be tough to do. Especially when you made the mistake of establishing yourself as the person who can get things done – no matter what.

You can only understand a technology when you use it. True. But you will never have enough time to do that. Triage the evaluation and using of technology to your team. This is a great way to empower people and allow them to work on their communication skills. It is also a good way to keep your team interested. Allowing a developer to stop ploughing through a bug list and evaluate something new and shiny instead feels good. If you rotate these assignments you don’t cause jealousy or show favoritism. You don’t want your team to feel bored or underappreciated whilst others do cool stuff. So let them do cool stuff and keep buffers in your allocation planning that allows for it.

Younger, fresher people seem to be much quicker in taking on new tech as we are. True. So allow them to do that and be a good leader for them. You will get slower the older you get. You will be hindered by real life demands. The more experienced you are, the more likely you are to discard new things and stick to what you know. Let others inspire you. You might not be up to going all-in with some experimental technology. A younger person reporting to you can be and you can learn something by guiding them.

Coding is fun. We don’t want to stop doing that. True. You should never stop coding. But isn’t it time you earned the right to code what and when you want to? Things you know well are a great opportunity for a junior developer to learn. Don’t take that away from them. We shouldn’t be bored by our code. This leads to stagnation and is the antithesis of innovation.

We remember that we had no respect for people who didn’t write code but use products instead. I sincerely hope you grew up. Software Development is a service. We build things to empower people to achieve goals. The more complex these systems are, the more we move away from coding. There is no medal for being hard-core. First to market is a thing.

Other realities you have to face are things you may not be familiar with or you are in denial about. These things happen though – all the time.

There will be a time when you are too senior to be assigned work. You might as well take action on that. Make sure that you have junior engineers you trust to do that work and be the firewall for them. When you are too senior to do a job, make sure you help the product owners find the right people in your team. Your job is to take the demands from top down and translate them to manageable chunks for your team.

Anything you do can get canned at the last moment for reasons beyond your control. Take it in stride and learn from the mistakes you made. Be stringent in noting down what went wrong. That way you don’t repeat the mistakes.

You are diving into the deep end of corporate politics. Who you know, and who you impress is often more important than what you know. Networking internally is a big thing. Concentrate on corporate levels, not on individuals. People leave.

Things to start with…

I hope you found some things that resonated with you here. There are many ways to get into a place where you can stay technical and move up in your company hierarchy. Most are fresh though and companies need to change age-old approaches to the topic. It is exciting to be part of that change though.

A few things that helped me get to this place are kind of obvious:

Consider contributing to open source. Either by participating in projects or open sourcing your own products. Open source is by default a communication channel. It helps you find talent as people join your company knowing your product. It helps your company become more visible to developers. And it gives your team a sense of achievement. Even when some internal product goes pear-shaped, there is something out there. Even when people leave the company, they have something to take with them. Contribution to open source is portable. You can show the outside world your skills – no matter who pays your wage.

Look for events and meetups to attend. Instead of taking your team to the bowling alley or an escape room to do team bonding, why not attend an event? You learn something, you can talk to people about your work and you get out together. Many events also offer jam sessions or B-Track events which are a great opportunity to submit a talk. Of course, you can also host a meetup or guest presenters at your office.

Foster an internal culture of communication. When you get people to attend events on company time, ask for them to present about the event in the office later. This helps with a few things. It means you know they went there and paid attention. It means others who couldn’t go get the information. And it means your team already gets used to presenting to a group which is important later in meetings. Often technical people know solutions, but don’t speak up in meetings as they don’t see the point. The more we get used to it, the more we embrace the idea that our points only get rewarded when we tell people about them. There are many ways to foster communication and some are a lot of fun to do. Like lightning talks about solved issues in products or even something as silly as Powerpoint Karaoke.

Aim beyond the finish line

The main thing to remember as a senior developer struggling with having no role to aim for is to aim beyond that role. Your company invested a lot in you and relies on your judgement when it comes to technical delivery. It also relies on you to lead a team and keep them happy. You also deserve to be happy and to make that happen you can’t keep things as they are.

One of the biggest mistakes we make as technical people is to make ourselves irreplaceable. We put a lot of effort into our technical products and it is hard to let go. Often we stay in a position even after all the joy went out of it and we don’t believe in the company any longer. Because we want to finish that project and see it go out of the door.

The seemingly sad fact of the matter is that nobody is irreplaceable. And that project the company keep stalling on isn’t going anywhere. And if you left to pursue other things not everything will go to pot, either. The main step to get ahead in your career is to understand that. You are replaceable and you have to take an active role in it. Hire people that are technically better and more interested in new tech than you are. Don’t be afraid of them moving into your role. Instead support them and find worthy replacements. Change in companies is a given, you can be part of those driving it or worry about how it will affect you. I’ve always rolled with the punches and it served me well. Hopefully you can do the same.

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 Evangelism interview on news.com.au

This morning news.com.au 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:

Console

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

about:debugging

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 http://firefox-dev.tools/. 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.)

image00

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.)

image05

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.)

image03

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.)

image07

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.)

image06

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.)

image01

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.

image04

image02

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)