Today we’re releasing Scientist 1.0 to help you rewrite critical code with confidence.
Anyone who has worked on a large enough codebase knows that technical debt is an inescapable reality: The more rapidly an application grows in size and complexity, the more technical debt is accrued. With GitHub’s growth over the last 7 years, we have found plenty of nooks and crannies in our codebase that are inevitably below our very best engineering standards. But we’ve also found effective and efficient ways of paying down that technical debt, even in the most active parts of our systems.
At GitHub we place an emphasis on stability, availability, and performance. A large component of ensuring we excel in these areas is deploying services on bare-metal hardware. This allows us to tailor hardware configurations to our specific needs, guarantee a certain performance profile, and own the availability of our systems from end to end.
Looking through our exception tracker the other day, I ran across a notice from our slow-query logger that caught my eye. I saw a
SELECT … WHERE … LIKE query with lots of percent signs in the
LIKE clause. It was pretty obvious that this term was user-provided and my first thought was SQL injection.
Careful use of concurrency is particularly important when writing responsive desktop applications. Typically, complex operations are executed on background threads. This results in an app that remains responsive to user input, while still performing complex tasks.