Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
269 lines (136 sloc) 39 KB
What do you and your team at Telefonica do?
So, I’m part of the, what we call the platform team. We have different teams at Telefonica, one is focused on front end development in Gaia, and the other one is focused on the platform itself, like Gecko, Gonk and maybe external services. So we work in several parts of the FirefoxOS stuff, from Gecko to Gaia, to services like the SimplePush server, which telefonica also have their own implementation. I’ve personally worked on things like the REL interface layer, payments, applications API and other Web APIs, and almost always jumping from Gecko to Gaia and back. Most recently, I started working on this Loop project, which like I said, is Telefonica and Mozilla’s WebRTC service.
Am I allowed to mention Loop in the article?
Yeah, I think so.
So, you actually mentioned, Gecko, Gaia, and a lot of the other projects you guys are working with. How do you work with Mozilla, and how did Telefonica get involved working with Mozilla?
Well, that’s a longer story. How did we get involved? Well, we started working on a similar project as FirefoxOS, but instead of being based on Gecko, we were working with WebKit. So we were creating this open web device platform based on webkit. When we heard about Mozilla doing the same with Gecko, we decided to contact you and started working on the same thing. Our previous implementation was based on a closed source port of webkit and it was really hard to work that way. Since then, my day to day work is just like any other member of Telefonica’s FirefoxOS team, which I believe is pretty much the same as any other Mozilla engineer working on B2G. I mean we have a lot of bug mail, reviews, patches to write, etc. Personally, because I’m not part of any FirefoxOS functional team, I am what is called at some point a “free agent”. I have to interact with different teams so I don’t have a fixed schedules of meetings per week. Sometimes I do weekly meetings with some teams and other weeks, I have meetings with other teams.
You are a free agent, so you float between groups? Dude, that’s awesome! How did you pull that off?
Yeah, you can learn a lot floating between teams. It’s hard to context switch, but it’s really educational and different.
That’s really interesting, I have more questions about that because it’s a side project that’s interesting to me. You are known as a great architect, developer, and inter-company coordinator. For Firefox Accounts on FirefoxOS, you brought together people from Telefonica, Telenor, and Mozilla. What do you think are challenges, what challenges are present when you have to work across three different companies that aren’t present when you just have to work within your own company or group even?
It has given me quite a challenge and experience, especially during the first days of FirefoxOS. We started working with Mozilla back in 2011, and it took some time for both companies to find a common work flow that fit well for both parts. I mean, we were coming from a telco culture where many things were closed and confidential by default, as opposed to the openness and transparency of Mozilla. For some of us coming from other open source projects, it wasn’t that hard to start working in the open and to be ready to discuss and defend our work on public forums. But, for other members of the team it took some time to get used to that new way of working, and new way of presenting our work. Also, because we were following agile methodologies in Telefonica while Mozilla wasn’t still doing it, we had to find this common workflow that suits both parts. It took some time to do it, a lot of management meetings, a lot of discussions about it. Regarding working with other telco companies, the experience has also been quite good so far, especially with Telenor. We still have to be careful about the information that we share with them, because at the end of the day, we are still competitors. But that doesn’t mean we cannot work with them in a common target like what happened with Firefox Accounts. I personally work them in Amsterdam, in their office. They are two persons here in Amsterdam, it’s a small office.
Sergi, and who else is there?
Jan.
I have not met him or her.
They are a peer of the keyboard application in Gaia, and they allow me to work with them in the office.
That’s really interesting.
Sometimes I have to exit the room when I have a call with my managers and I have to speak about confidential stuff.
Do they ever ask you to leave the room and say “hey, we’ve got some confidential stuff we’ve gotta do. Get out!”
Not yet, but they probably will at some point.
It sounds like basically in 2011 and earlier on, when Mozilla and Telefonica were both starting out on this process, both sides had to change a bit. You know, some people at Telefonica had to get used to working in the open, and some people at Mozilla had to change their methodologies. You mentioned agile in particular. I feel like, I dunno, this is only my impression, and it’s a far off impression because I don’t have a lot of experience, that things like Gecko. They are on these very long development processes. Even 6 works is quite long in a normal agile world of 1 week or 2 week sprints. How did you guys decide what common practices to come up with? Did you just hash it out in rooms or did you just say “hey, maybe we should try this?” How did you come up with this common culture to get everybody to go together instead of getting everybody working against each other?
I think for this agile methodology, we focused more on the front end parts because as you said, Gecko already has a very known process and a very known way of developing. It has it’s own train mechanism of 6 weeks. As I said, we have two different teams in Telefonica, the platform team and the front end team. The ones doing the most, the biggest effort of finding that common workflow were the front end team because we started working on Gaia and Gaia was a new project with no fixed methodologies. They tried to find the common methodology for Gaia. In the meantime, the people working on the task were trying to learn the Gecko process and also we are in the middle between working with the Gaia team and working with Gecko engineers. I don’t know if we really found the workflow, the perfect workflow, but I think we are doing good. I mean we participate in agile methodologies, but when it turns out that we need to do Gecko development and we need to focus on that, we just do it their way.
Has Gecko development, do you think has changed since B2G has been introduced? Are they becoming a little bit more flexible, or have they modified their process?
Gecko came before we started working on FirefoxOS, but what I can see looking at the different teams is that B2G development in Gecko is quite different from Desktop development. Especially the review process, we have, I think, different standards for each part. I don’t know if it has changed, but I can see differences in teams at least.
What are the biggest differences between the Gecko team and the Gaia team do you think? Would it just be the train schedules, or you just mentioned the standards for review. How are they different?
For certain the Gecko team works with Mercurial, different development process. Gaia started with Github and Github issues, then they moved to Bugzilla so they finally had a more similar development process as Gecko using Bugzilla as the common issue tracker. But, I think when they did this FirefoxOS functional teams, the development process started to be more similar from the desktop team to the B2G team. What I said about differences, I mean differences in the code, the way they review the code, we have different standards in B2G and different standards in Gecko, for the code specific stuff.
That’s interesting, I skipped a question, but it touches on what you were just saying. In a multi-disciplinary project, a multi-company project, how important do you think things like common standards, like style guides and common processes, you just mentioned the bug tracker in particular moving from Github to Bugzilla. How important do you think common, common process and things like that are, and especially style guides, tools, how important are they to making a project succeed?
Well, I believe when talking about software engineering, standards are very important in general. But, I don’t care if you call it SCRUM or KANBAN or SCRUMBAN or whatever, or if you, that Git workflow or Mercurial workflow, or if you use Google or Mozilla’s Javascript style guide, but totally need some common processes and standards, especially in large engineering groups like open source, or Mozilla development in general. but when talking about this the lines are very thin. It’s quite easy to fail spending too much time defining and defending the usage of these standards and common processes and losing the focus on the real target. So, I think shouldn’t forget these are only tools, they are important, but they are only tools to help us, and help our managers. We should be smart enough to be flexible about them when needed. We do a lot of code reviews about code style, but in the end what you want is to land the patch and to fix the issues. If you have code style issues, I want you to fix them, but if you need to land the patch to make a train, land it and file a follow on bug to fix the issues, or maybe the reviewer can do it if they have the chance.
I actually do that quite often on our projects over on GitHub. I’ll just basically, if I have a couple of nits about something, I’ll just, you know, add a commit to their pull request and say “yeah, good to go. Merge it!” So, for newcomers. I was the newcomer in October to B2G and I had to be educated on some of these standards and I don’t know if I was educated so well, or I just refused to be educated and whatnot. Whenever new people come into the project, how can you go about educating them about the standards that already exist?
I would say, at first, documentation. But, you probably suffered the lack of documentation about it. So, I guess reviews and day to day work, where people are already familiar with these standards participate in this education process. There are also tools like linters or git and mercurial hooks to enforce some of these standards.
I would actually say documentation was not the problem that I had in October. I found there was too.. Lack of documentation was not the problem, there was too much documentation and I could not filter out what was meaningful to me, or what was applicable to what I needed to do, because there was SO much about B2G development, and you know, flashing phones, there’s like a million different phone pages, and I’m just like, “I don’t even know where to start.” That was one of my issues with FirefoxOS development when I tried it for those, that month and a half or two months. So, FirefoxOS code is what, Gonk, which is linux basically, Gecko and Gaia. Each system is quite large, complex, and intimidating to a newcomer. I feel Gecko in particular is intimidating. You regularly submit patches to Gecko and Gaia. You had to go about learning all of these systems somehow. Whenever you want to go dive into a project, you have a task to do, how do you go about learning the system you are getting ready to dive into?
I’m afraid there is no magic technique. What works for me might not work for others for sure. So, what I try to do is to read as much documentation as possible inside and outside of the code, if it’s possible. I try to ask the owners of that code when needed, and also if that’s possible, because sometimes they just don’t work in the same code or they are not available. I try to avoid reading the code line by line at first and I always try to understand the big picture before digging into the specifics of the code. I think that along the years, you somehow develop this ability to identify patterns in the code and to identify common architectures that help you understand the software problems that you are facing. You can see that just by doing a diagonal read of the code. I mean, we have this colleague at Telefonica that used to study in, I think it was Sweden, he did a research project about people with experience in development and new comers to development work. They used to record their eyes when they read code, and for new comers, they were reading line by line.
I saw, I could swear I saw an article along these lines in Slashdot maybe six months ago, and I found it fascinating.
Yeah, it’s really cool. So, people with experience in programming did, easily do a diagonal read of the code. It’s just like “scrolling, scrolling”, looking for the function names or common patterns. I guess it’s that way. You develop that ability, and you try to focus on the big picture. In the end, you can also use old fashioned debugger techniques like printing to the console.
That’s basically how I approach things as well. I would say my biggest, where I suffer the most is not reading the documentation beforehand. Sometimes I’ll try to find where the “main” would be if it were a C program, and then try to fit the large blocks together from there. And yeah, I should read the documentation more. There’s one learning thing for me already.
Yeah, asking sometimes helps a lot, unfortunately it is hard for people to just jump into IRC and ask a question like “hey, I’m looking at that code, can you guide me with a few words?” That really helps.
I did an interview last week with Yvan Boiley, I don’t know if you met him yet, he’s a security engineer from Mozilla. He was saying whenever they do security reviews on high risk projects, or projects that have the ability to cause lots of damage if they go wrong, the first thing they look for is documentation. He said the reason the first thing they look for is documentation, he said, usually the better documented the code, the fewer security problems they end up finding. He says what happens is if developers take the time to write the documentation, they have usually taken the time to actually think through how data flows through the whole system. Developers that don’t have any documentation, generally haven’t put as much thought into it. He said basically, if there is no documentation, we have to assume the absolute worst about the code, and it’s going to be a freaking disaster and there is going to be security problems everywhere.
Yeah, that’s quite true, and I think the extrapolation to that theory that can be applied to tests. I mean tests can serve somewhat as an index and a guide to what the code does. When you do a review, I usually start by looking at the tests to see what the coder has thought, and what edge cases has he considered to write the actual code. I think it’s a common approach, if the developer has spent the time in the documentation, it means probably the code is well written.
So here’s a question, something that I wrote a couple of weeks ago. I was writing a little email about how I do code review. It talked in particular, I wrote in particular about tests. One of the red flags whenever I am reviewing a particular patch, because I go straight to tests quite often as well, and if they modify existing tests, I put a higher level of scrutiny into the code review than if they only add new tests, if that makes sense. Because if it modifies existing behaviour, then I wonder “Is there a potential regression here from the existing behaviour?” If it’s only additive, then I can be quite sure that at least the current, you know the current behaviours are still in tact and hopefully it’s only adding new behaviours. But if it modifies existing behaviours, then I have to go, I have to go talk to the designers and say “hey, is this intended, is this how it’s supposed to work?” and it does get a bit more scrutiny then.
Yeah, that makes a lot of sense. When you see a test fix, something is going on. Maybe it was wrong, but you have to be careful about modifying tests.
When you start coding in unfamiliar territory, say the first time you jumped into Gecko, you know. How do you ensure your changes don’t cause unintended side effects? Is testing a large part of this?
Yeah, basically tests, tests and more tests. You need tests, smoke tests, black box tests, tests in general. Also at first, you depend a lot on what the reviewer said, and you trust that the reviewer, or you can ask QA or the reviewer to add tests to the patch.
So, say let’s flip this on its head and you are the reviewer and you are reviewing somebodies code. Again, do you rely on the tests whenever you say “OK, this code adds this patch, this functionality. How do we make sure it doesn’t break something over there?”
I usually test the patches that I have review if I think the patch can cause any regression. I also try and run the tests on the “try” server, or ask the developer to trigger a “try” run.
OK, so tests.. A lot of tests.
Yeah, now that we are starting to have good tests in FirefoxOS, we have to make use of them.
So, I know this is off on a bit of a tangent, but I’m super for testing. I’m always, I feel ike there is this tension between what level of test to write. Because some people are like “unit tests are worthless because if the interface changes then you have to go update all the tests and functional tests are where it’s at.” And other people are like “nooo, you’ve gotta unit test everything and functional tests won’t tell you where the problem is, it’ll only tell you there is problem in your behaviour.” And I would love to write huge amounts of tests in both areas, but sometimes it feels like there is not enough time to do it. I don’t know if that’s a false assumption on my part. How do you deal with testing in time constrained situations I suppose. Do you try to do both functional tests and unit tests? Or if you had to ditch one, where do you focus your testing efforts I suppose is the simple question here.
I guess it depends on the time that you have for the coding part. I usually approach it, I think the wrong way. I write the code then write the tests, when I should probably do the opposite.
I do the same thing.
Yeah, but..
Unless it’s a really hairy API that I’m really trying to figure out, then I’ll end up writing the code first, then the tests.
I think it’s this urge to see something working. Because that’s actually your job to make the patch work, and then you need to make sure it’s well written and it works well and it doesn’t break so you write the tests for it. But, I guess, I don’t know which tests I would choose first. I mean functional tests are done to assure that your code works as suspected, but you can also rely on your personal tests on the device, and your manual tests. So you can probably avoid writing functional tests at first and focus on unit tests that tests only specific functionality of the code, specific parts of the code. I don’t know which one I would choose, it depends on the patch and the time that I have. I also ask “what would the reviewer ask me to write?”
That’s completely fair, completely completely fair.
I mean, we all love tests, and we would all like to write as much tests as possible, but in the end we have a lot of patches to write and we just want the patch to be landed. We need to make the reviewer happy, if he wants this test, I will write this test. That’s it.
I completely understand. So, man, I have way more questions than I thought I would. On a resource constrained device like a low end FirefoxOS phone, like my ZTE Open for instance. I’m always getting out of memory errors with 1.3, you know. So memory management is something developers have not really had to worry about since Internet Explorer was losing circular references back in IE6 and IE7. Now that we have to worry about this stuff again, has this focus on memory management changed the way that you write apps, and if so, how? And, has it changed the way you write normal web apps for a normal browser. Say you are just writing tokbox here.
When you write the web apps, you don’t really need to worry about memory management in terms of it’s hard to leak memory when writing a web application. You trust the browser trying to do the right thing, but yeah, absolutely. Memory constraints, I think affect the way you design your software and the way you write your code. I mean things like lazy loading or cleanup routines are well known, good practices.
What was the second one, I’m sorry?
Cleanup routines, you have to release unused objects or if you are using cache, you have to release them. You have to clean it if you are not using it, it’s common sense writing code right. In FirefoxOS, not only looking for the memory footprint, but also for improved performance. In FirefoxOS, we have a lot of issues with the first paint event, we have to make sure that the launch path is as fast as possible so the user gets feedback as soon as possible, so you have to write your code with that in mind. You have to lazy load stuff, show things as fast as possible. Also, you have to be aware in FirefoxOS, your application can be killed at any point in its life cycle, so that your app should be ready to recover from that situation. That affects the way you write your code.
Has that affected how you do development for other web pages, for non FirefoxOS web pages?
Well, I think it’s also beneficial for web applications running on other platforms, but since FirefoxOS is the low end platform for web applications, it’s the best platform to test your working. You will suffer there.
So you mentioned the cleanup routines. It’s something that I feel is under appreciated in web development. I feel that people have a grasp on lazy loading, but a lot of people still don’t understand that they should clean up their references whenever an object goes away. I haven’t seen very many articles or people talking about why. Yeah, that’s an interesting one, because it’s something I Have been used to for a while as well.
It also depends on the garbage collector. Maybe it’s platform specific also. You thought it’s hard to write your code for a specific implementation of the browser, and you just need to use the profiler in that case. It’s hard to think about the garbage collection when you need to release references, but usually you need to use, to do it, when you don’t need it. Basically, it’s common sense. And also the event listeners and all this stuff that’s taking memory and you are not using it.
Event listeners take up a surprising amount of memory I think. Definitely things to clean up.
When FirefoxOS started, no, Firefox Accounts, I remember sitting in Madrid, and I showed up a day late and you guys had the API to talk between Gaia and Gecko defined, and that has sort of been the bedrock of communication between Firefox Accounts web context in Gaia and the system app, and the rest of everything basically from what I understand. And developers often hate doing design like that, up front, they just like to do it as they go along, but when have you found early API design like that helpful, and have you ever found that can hinder things and make it more difficult?
I don’t like to put labels on these kinds of things. I really, what we did with Firefox Accounts for FirefoxOS was more like, minimimal design up front, rather than a big design up front. We actually proposed different architectures and iterated over them along the work week, trying to find the best approach to the problems we had at that point, but what.. in any case, I guess what approach you take depends on how much time you can spend on the design itself or in the development part itself, and how flexible you are, or the project or the problem, or the problem can be changed later if it’s needed. In general I like to think about the details in advance is quite beneficial in saving a lot of time in refactoring it. So, I think that’s what we did there in Madrid for Firefox Accounts. We put up different options and we tried to evolve these differing options, and we ended up choosing the, what we thought was the best one.
And one that worked well because it kept being used, so.
Yeah, it’s being used.
So the next thing is, the review process. We’ve talked a bit about testing and reviews already. But the review process for Gecko and Gaia is brutal. People inside of Mozilla talk about it quite regularly, just going “ah, this patch took forever, this reviewer is a jerk.” You know. Why do you think a B2G review is so difficult, and what can developers do to smooth out that process?
It’s not only B2G. I think the Gecko source code is already a huge piece of software by itself, with all these specific things about XPCOM and XPCOM pointers and other complex stuff. If you add to that base things like hardware details, network, mobile radio specific stuff, in some cases even operator specific stuff, or external services dependencies like Firefox Accounts, you end up having a very complex system with many pieces involved. And so coding for it, many times requires also a complex review process. So, there are many things to take into account when writing a patch for B2G, like performance, security, coding style, tests, etc. And reviewers have to ensure that all these things are considered and well done. And, I think what, what you can do to smooth out the review process is just to work closely with your reviewer, asking him feedback for when you need it, and asking basically what he wants you to do, and what he considers the best approach to do it, and also explaining well, what’s the intention of your patches in the best possible way, and what are the things that you already considered while writing those patches, right.
I think that’s something that a lot of people don’t take the time to explain is what other approaches have been considered and why they chose a particular one.
Yeah, I think it’s something we commented on a few minutes ago, you just want to see something working, and you just want to land it. You wrote the code and just threw it up to the review process hoping that nobody notices that you were too lazy to explain what you did. But yeah, ideally, you should explain, think that the reviewer is, has no idea of what you intend to do. It’s not enough, or at least he will spend more time reviewing if you help him and you guide him through your code.
That makes sense. It seems like a piece that is critical is knowing who the reviewer or the reviewers are going to be and talking to them ahead of time before you actually potentially submit the patch and say “hey, this is what I’m trying to do, um, what are you going to be looking for whenever I submit this patch?”
Sometimes you already know the reviewer and you already know what he expects you to do, so I think you accommodate your development process and your Bugzilla submission process with what you think the developers, reviewers, expect.
Fair enough, completely fair. We talked about this a little bit already. What do you look for when you are doing a review? A Gaia or Gecko review.
In general where I look first is correctness. I mean, the patch should actually fix the issue it was written for. And of course it shouldn’t have collateral effects. It shouldn’t introduce any regression. And as I said, I try to test the patches myself if I have the time or if the patch is critical enough, to see how they work and to see if they introduce any regression. And also I look that the code is performant and is secure, and also if, I always try to ask for tests if I think they are possible to write for the patch. And I finally look for things like quality of the code in general, and documentation, coding style, contribution, process correctness. If you have to squash your commits for pushing it to Gaia, then well, you have to do it. Or if you have to write the commit message with the reviewer name, or the bug number, then you have to do it because it’s the process for that project.
So here’s actually something, whenever you are reviewing code, say it’s a large patch, would you prefer that patch be broken up into smaller commits that show the developer’s process, or do you like to see one giant thousand line patch potentially?
I prefer it to be split between different commits. I usually actually write the code that way. I do different patches with different numbers for each patch, that way I think you can even ask for review of different reviewers for each different part because sometimes you will write for B2G but it also involves Gonk parts, or Gecko parts, or Gaia parts, and the same reviewer cannot review the whole stack, so you need to split it into different pieces.
And then say, you did have one of these patches that was 3 different commits. Before that got merged, would you squash those into one commit and then merge it?
I usually ask the developer to do it, to squash it, or sometimes they do it themselves.
That makes a lot of sense. So you reviewed one of my large patches which was to integrate FxA into B2G, into the first time experience I believe it was. You placed of, much more of an emphasis on consistency than any review I have had. By far.
I was a pain in the ass then?
No, no, not at all. But how do you think that consistency contributes to overall code quality?
Well it certainly helps with overall code quality that. When I do reviews these kinds of comments as “nit:” which is quite common in Mozilla, meaning that “I would like to see that changed, but you still get my positive review if you don’t change it, but I would really like to see them changed.”
Well, I’ve started marking them with “nit:” because of that, you know, whenever I’m doing reviews. I’ll put “nit: Change the case here” or whatever.
But, if you ended up not doing it, please tell me, so I will do it in a follow up bug or whatever.
Fantastic, here’s one for B2G especially - as a reviewer, how can you ensure that your comments are not taken too personally by the developer? Yeah, that’s the first part of the question, and the second part is, as a developer, how can you be sure that you don’t take it too personally?
For the record, I received quite a few hard revisions myself. And I never take them personally. I mean, I always try to take it, the reviews as positive learning experience, cause I know reviewers usually don’t have a lot of time to, in their life, to do reviews.They also have to write code or a lot of things in their work. So, they just quickly write “needs to be fixed” without spending too much time thinking about the nicest ways to say it. And it’s actually funny because the abscense of comments in a review. I mean, reviewers only say things about negative things in your code, not negative, but things that they consider are not correct. But they don’t usually say that the things that are correct in your code and I know that can be hard at first. But once you start doing it, you understand why they don’t do that. I mean, you have your work to do.
You have other things to do as well.
Yeah, this is actually especially hard for me, being a non-native English speaker, because sometimes I try to express things the nicest way possible but the lack of works make the review comments sound stronger than it was supposed to be. And, what I try to do is use a lot of smileys if possible. And always, I try to avoid the “r-“ flag if I mean, the “r-“ is really bad. I just clear it, use use the “feedback +” or whatever.
So, in the last part of that question is, but you already mentioned this, you try to take it as a learning experience whenever you are developer. Do you take it as a teaching, a potential teaching moment if you are the reviewer as well?
Yeah, for sure. I mean just the simple fact of reviewing a patch is a teaching experience. I mean, you are telling the coder what you think is more correct, but sometimes at least I do a. There is a lack of theory and reasons behind that comments, and it’s because of that, the lack of time to express the reasons to make it even nicer. We should all do that, we should explain the reasons and try to make the process as better as possible.
It’s tough, but you mentioned a moment ago, um, I know our time’s up here in just a moment. So we can do the last questions offline. Trying to put things in a nice way whenever you are trying to do the review. And sometimes it comes out more blunt than you thought it was, or you intended to. Even as a native English speaker, I have that more often than I’d like, that I see a comment that I wrote and think “ah man, that can be read so many bad ways, so I’m just going to edit it or whatnot”
If you can, you cannot edit in Bugzilla and that’s a problem.
It’s not only difficult for, you know, people who speak English as a second language, it’s difficult for native English speakers too.
OK, so there is no hope for me, even if I learn more English.
I think I’ve only met one person who has been able to do it really well consistently, and that was Ben Adida, I don’t know have had a chance to meet him, he was always very good about his comments. I’ve taken up your full hour, and those last three questions are.
We can do it if you have time, I know you are busy, so I don’t want to take up too much of your time.
I have a meeting in half an hour.
OK, then we can go through them, and they are are bout tooling, well, tooling and code quality. What are 5 tools that you can’t live without on FirefoxOS?
Well, I use a lot of the Mozilla Cross Reference Search - mxd and dxr.
What are they? I know what they are, but how do they help you out?
Because it’s like a very powerful grep that will go through all of the Mozilla source tree for Mozilla central or different trees, or even Gaia. So you can search for the keyword you are looking for, and you can click on any function or variable name and you will get another search. You can also see where the function was defined or a variable is being used or defined, so it’s quite useful for seeing the flow through the code. It’s really a powerful tool.
I didn’t know that. DXR does that as well?
Yeah. And I don’t really know the differences between MXR and DXR aside from the UI differences. I think DXR has more flexibility about the queries that you do, like I want to know when, where this function was defined and when it is used. In MXR, it’s like a grep, so everything is mixed.
I’m gonna have to use that more, but I don’t really do any Gaia or Gecko hacking now. What other tools are you using on FirefoxOS?
For FirefoxOS specific development, for the platform, I wrote a script to push Javascript changes in modules for components without needing to rebuild everything. So what I do is take the omnijar from the device, I unzip it, I modify it, I preprocess it, and I put it again to the device. This tool is called OmniPush.
Is it up online?
Yeah, on GitHub. It’s really helpful for me, I mean, if I’m writing Javascript code for Gecko, I just need to use this tool and I have my changes in like 10 seconds on the device.
Instead of rebuilding the whole thing.
Yeah. When I don’t need a device feature, like mobile connectivity, or the SIM card, I use the B2G desktop because it uses a similar way of, I mean, in B2G desktop, the content that is shipped in the OmniJar in the device is just a symbolic link to your source code on your computer, so if you run that in your desktop, in your computer I mean, the B2G desktop, you just need to modify your source code and B2G takes your changes immediately. So that’s quite a fast development process for Javascript. If you modify C++, you have to rebuild it.
That makes sense. And then for normal front end development, break outside of FirefoxOS.
Well, I’m not really, I’m not a front end developer. I started writing front end code in FirefoxOS.
Oh really?
Yeah, I found very useful the developer tools from Firefox. And for FirefoxOS especially, the app manager is really useful. All the style editor and DOM viewer and everything is for front end developers like me, with very very limited experience, is quite useful.
Ah that’s cool, and then, what does code quality mean to you? It can be anything, it doesn’t matter.
I could define it like, with university, what they taught me in university, but I remember a picture of what code quality means. I think it, I tend to think that way also, which is a code has quality has a few “what the f***’s” per minute when you are reading it. So, if you are reading a code and it’s like “what the fuck, what’s this?” then it’s like, that’s not quality, so. If you the read this and are like “what the fuck, I would like do it that way” (less emphasis), then it’s like “well… OK.” I think then there’s a picture somewhere.
I’m gonna have to find this.
I will search for you, and will send it to you if I find it.
And then is there anything else you want to add?
Yes, thank you for doing this, I think this is great. It’s going to be very useful for not only for you. As you said, you have this target of learning from the experience of learning from this experience, that if you share it with a lot of other people on Mozilla Hacks, it’s going to be great to read it and to see what the other people think about code quality, revisions, all this stuff. It’s really cool.
It’s fun for me, and it gives me a reason to talk to people that I don’t always have a normal reason to talk to, you know? That’s one of the cool things about it.
This has been fun man, thank you for your time.
==============
follow on questions
S: Do you have a snippet of code, from you or anybody else, that you think is particularly elegant that others could learn from?
F: I am pretty critical with my own code so I can't really think about a snippet of code of my own that I am particularly proud enough to show :). But if I have to choose a quick example I was quite happy with the result of the last big refactor of the call log database for the Gaia Dialer app [3] or the recent Mobile Identity API implementation [4].
[3] - https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/call_log_db.js
[4] - https://mxr.mozilla.org/mozilla-central/source/services/mobileid/
S: What open source projects would you like to encourage people to participate in, and where can they go to get involved?
F: Firefox OS of course! No, seriously, I believe Firefox OS gives to software engineers the chance to get involved in an amazing open source community with tons of technical challenges from low level to front end code. Having the chance to dig into the guts of a web browser and a mobile operative system in such an open environment is quite a privilege. It may seem hard at first to get involved and jump into the process and the code, but there are already some very nice docs at the MDN [5] and a lot of nice people willing to help on IRC (#b2g and #gaia) [5], the mailing lists (dev-b2g and dev-gaia) [7] or ask.mozilla.org [8].
[5] - https://developer.mozilla.org/en-US/Firefox_OS
[6] - https://wiki.mozilla.org/IRC
[7] - https://lists.mozilla.org/listinfo
[8] - https://ask.mozilla.org/questions/
S: How can people keep up to date about what you are working on?
F: I don't have a blog, but I have my public Github account [7] and my Twitter account [8].
[8] - https://github.com/ferjm
[9] - https://twitter.com/f_jimenez