I attended React Norway 2019, an event targeted towards sharing the latest techniques and best practices in the
React community. This was my first non north-american conference that I attend.
Looking back, I enjoyed the conference a lot. The event was well organized,
had a good line-up of speakers, and was in a beautiful venue.
Unfortunately, there doesn’t seem to be any video recordings of the talk for this year’s conference.
I decided to share my notes in case someone else finds them useful.
The Taskcluster team is experimenting with GraphQL.
For the “What” and “Why”, I invite you to read my
where I write about the motivation and benefits to using GraphQL.
This short post will discuss the server component of GraphQL and how it’s being used.
Taskcluster, a set of microservices designed to run automated builds and tests, has been
open source since the very beginning.
It is not Mozilla-specific and in principle, can be reused in other organizations.
However, the current implementation is not designed to be easily redeployable.
We hardcode a bunch of stuff and have our own configs included in the source files.
A new feature was added to the bottom panel of a selected job. When the build system of the job is not buildbot,
there is now a hyperlink on the machine name that takes you to the worker explorer within Taskcluster to drill down
into a specific machine and see details like its most recent tasks.
Commit early and commit often. Microcommits with good commit messages are easy to review and as a consequence,
will receive better code reviews. When it’s time to integrate a pull-request, sometimes squashing commits is recommended
to do in order to streamline the git history.
For the past 3 months, I’ve been working on a new tool - long awaited - now known
as the Provisioner Explorer. This
is my first time as a Mozillian to own a complete project, coding both the
front and back ends.
The current Treeherder logviewer is great, but It has a number of deficiencies. There is no way to scroll freely in the log without being blocked by the loading view, slowing down productivity. Not to forget, attempting to load a 100M+ log was out of the question. Taskcluster was having similar issues and so during Mozlondon we discussed about a possibility of having a shared project/tool that could solve both of our issues.
While I was working on the Unified Log Viewer, a project initiated by Eli Perelman, I came to realize how a single threaded environment can easily be impacted. For the sake of understanding, an example that explains the meat of the problem without necessarily diving into the specifics of the code will be used.
The Unified Log Viewer is a new project initiated by Eli Perelman, with the ultimate goal of eventually replacing Treeherder current log viewer. I interviewed Mozillians this summer asking them about their workflow and I received multiple complaints regarding the current log viewer. See interview results here. For example, the browser would crash when presented with a very big log file and users are not able to jump to a line number in the log.
The new log viewer project is currently being hosted on Taskcluster Github. We are always open for the public contributions. Send us a pull-request.
Whenever a Mozilla employee or contributor pushes a build to a server, they go to the Treeherder interface to see and inspect the results of their build. The TaskCluster team decided to come up with a “developer-focused” interface, Push Inspector, a complete rework of Task Group Inspector. Push Inspector is a great way to inspect your builds in real time.
Whenever a Mozilla employee or contributor pushes a build to a server, they go to the Treeherder interface to see and inspect the results of their build. The TaskCluster team decided to come up with a “developer-focused” interface and was later called Task Group Inspector.