Britecharts, Eventbrite’s D3 based charting library, has grown with additional charts contributed by the community. It is now a mature library, but it still lacks some charts used in today’s standard DataViz suites. We want to add these charts, and that means we will experience some growing pains. We wondered, how we could make that process easier? Continue reading
When dealing with a large Python code base managed by multiple teams, you often find that you need to be able to package and release this code independently. Most best-practices guides for releasing Python packages focus on public packages, and do not cover complex dependencies. In this post I’ll focus on how we, at Eventbrite, release our internal Python packages and avoid dependency hell while doing so. This first part will cover defining packages and their dependencies, while the second part will cover building and distributing Python wheels internally.
The usual workflow when developing interactive data visualizations with D3.js is based on the significant number of examples that the D3 community provides. They are broad and useful, but they are still not ideal. Most of the time, they require a lot of effort to integrate into your code and to make them production-ready.
In a previous series of posts about Leveling Up D3, I talked about a different way of building D3.js charts, using the Reusable API, building our components via TDD and improving them with events and refactorings. Following those ideas, and with the help of Eventbrite’s design team, we have been working on our chart library, and now we want to share it with you. It’s called Britecharts.
To me, it really doesn’t matter the size of the project that I am coding, it could be for my current job, a freelance one or my personal apps: I always use Git.
I think that habit is like a cane to walk the road to perfection. That’s why I do not just use Git but also always follow some best practices that I have learned.
- Use branches for features, AB tests, fixes, etc.
- Commit often.
- Use clear commit messages.
- Always use pull requests.
- Keep master releasable.
DOM reflow is the drawing or redrawing the layout of all or part of the DOM. This is an expensive process, but unfortunately easily triggered. This could cause a noticeable performance degradation of a web app that requires a lot of user interactivity i.e. drag & drop and WYSIWYG editors. If you are developing a highly interactive web app, then you will most likely at some point trigger a DOM reflow.
Eventbrite’s switch to ReactJS is one answer to the poor performing native DOM. ReactJS creates its own virtual DOM, which optimizes which parts of the web page needs to be re-rendered.
This is the first of a three part series. We will begin by tackling two fundamental concepts that exist in HTML and CSS, which may help you reason out solutions to tricky scenarios that exist in the Wild Wild West that is front-end development.
Block Formatting Context
Block formatting context is a fundamental component to how elements in web pages are rendered. It describes how they stack and interact with each other resulting in the final visual output of the webpage.
Horizontally & Vertically Centering an Element
You’d think this would be a straightforward task, but surprisingly this is not as simple as the name implies. Vertical alignment in particular is tricky because CSS’s vertical-align style only works for table-cells and inline-block elements. I ran across this problem when designing the DatePicker used in the Eventbrite Design System (EDS). The DatePicker is a calendar where each row is a week, and each day in the week is the shape of a square. The numbers representing that day of the week needed to be vertically and horizontally centered.
As a developer, my understanding and respect for software testing has been slow coming because in my previous work I have been an engineer and a consultant, and in these roles it wasn’t yet obvious how important testing really is. But over the past year I have finally gained an appropriate respect and appreciation for testing; and it’s even improving the way I write code. In this post I will explain where I’ve come from and how far I’ve traveled in my testing practices. I’ll then list out some of the more important principles I’ve picked up along the way.
Engineers are cowboys … and cowboys don’t need no stinkin’ tests.
I got my start as an Aerospace engineer. And as an engineer, if you do any programming at all, testing is probably not part of it. Why? Because engineers are cowboy coders. As engineering students, we are taught just enough to implement whatever algorithm we have in mind, make some pretty graphs, and then we graduate.
It wasn’t much better at my first job. I had shown an interest in software development and so, in one particular project, I was given the task or reworking and improving the project codebase. We were developing autonomous aircraft control algorithms and it soon became apparent that after months of work, no one had thought to run the simulation using different starting conditions. After finally trying different starting conditions we found that our control system was generally better at crashing the plane rather than flying it. This should have been the biggest hint in my early career that testing might be important. But it would still be quite a while before I learned that lesson.