Loading…
Kickstarter
Crowdfunding platform that helps creators raise funding for creative projects from a community of backers.
- 10 posts summarised
- latest
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
From their blog
Latest articles
Supporting Open Source: Our Donations for 2018
Kickstarter describes its 2018 effort to support the open-source ecosystem through financial contributions aligned with its PBC charter and stated values. After surveying engineers for nominations, the company split its yearly donation budget among two open-source projects, Babel and Webpack, and four organizations supporting learning or coding skills: Advent of Code, Rails Girls Summer of Code, Code Nation, and Code Cooperative. Babel converts ECMAScript 2015+ into backwards-compatible JavaScript, while Webpack bundles JavaScript used at Kickstarter. The other recipients support collaborative problem-solving, participation by women and non-binary individuals, technology pathways for students in under-resourced high schools, and technology education for formerly incarcerated people. The post also notes an engineer’s weekly Code Nation mentoring and invites engineers to join the team and help choose future recipients.
Fabric for Open Source Android
Open-source Android applications must remain buildable for contributors without exposing the credentials used by third-party services. Kickstarter’s Android application added Crashlytics through Fabric for crash reporting and real-time analytics, but integrating it required protecting the Fabric API key and secret from public source control. The post presents two normal SDK configuration paths—manifest metadata or fabric.properties—then uses a generated properties file, an example fallback, and Gradle logic to supply values from environment variables when available. Contributors without access to the secret repository receive an example apiKey value of 0, allowing the Fabric SDK to compile without the invalid null-key error, while the project’s real credentials remain outside the open-source codebase.
A Guide to Mindful Communication in Code Reviews
Code reviews are presented as both technical work and communication, teaching, and learning. The guide defines mindful communication as listening and speaking with compassion, kindness, and self-awareness, then applies that perspective to reviewers and authors. It recommends self-checking before commenting, asking open questions instead of assuming, omitting linter-detectable nits, signaling what can wait, giving example code and documentation, and ending substantial feedback with “What do you think?” Reviewers are encouraged to approve unless major problems exist, while large changes and architectural decisions should receive broader discussion. Authors should link relevant documentation, assume good intent unless feedback is hostile, keep diffs focused, and seek feedback early; these practices take time but can become a learnable habit that varies by team.
Event Sourcing made Simple
Event Sourcing stores application changes as immutable events, providing a history that can explain how current data came to be. The post introduces four components: Events record changes, Calculators update Aggregates from those events, and Reactors trigger side effects or create further events. Kickstarter implemented a minimal framework for d.rip using regular Active Record aggregates, a regular SQL database, synchronous atomic updates, and roughly 200 lines of home-made code. The approach supports replaying history to reconstruct past state, repair calculator bugs, backfill new aggregate fields, optimize read models, and forward events to analytics platforms, while presenting naming and mutation-to-event decomposition as important challenges.
Namespacing Actions for Redux
Kickstarter’s front-end team encountered a Redux action-namespacing problem when multiple instances of the same functional React component responded to actions intended for only one instance. They rejected local state because the application used functional components and redux-loop, which routes state updates and side effects through reducers, and they sought programmatic namespacing compatible with combineReducers and a low-surface-area component API. The team compared nested reducers, higher-order reducers, and a closure-based module pattern; the latter met the stated constraints with namespaced actions, wrapper components, reducers, and a namespace returned by a factory that defaults to a UUID. Namespaces must be preserved when reducers trigger further actions, including redux-loop results, and complex composition can lose the required binding. The approach has worked for most reusable and compound components, while possible performance costs from many reducers remain a future concern.
FRP at Kickstarter and Kotlin
Kickstarter’s open-source iOS and Android apps use Functional Reactive Programming (FRP) patterns to keep views simple and move mutation and complex logic into thoroughly tested ViewModels. The post describes how this discipline helped a developer ramp up quickly on the Android codebase after working on Kickstarter’s backend and payments teams. It also introduces the Android team’s interest in Kotlin, a JetBrains language that runs on the JVM, while noting that dependency concerns had prevented conversion of core functionality. For a 2017 Functional Swift Conference talk in Berlin, the author used Kotlin to add a simple Android screen following the team’s established FRP patterns, presenting the implementation as live coding and an introduction to FRP and Kotlin.
Upgrading Kickstarter to Rails 5
Kickstarter upgraded its main Rails application to Rails 5, alongside payments app Rosie, to support site security and performance while moving a nine-year-old legacy codebase forward. The team planned a three-month project, upgraded Ruby 2.2.5 to 2.4.x, classified release-note changes, resolved dependency conflicts, used Rails’ upgrade script, and moved through twelve documented steps. Work included merging Rails 4.2-compatible fixes, repairing nearly 4,000 CI test failures from a roughly 70 percent coverage baseline, removing deprecations, smoke-testing major flows, backporting more than thirty pull requests, and preparing reviewers and deployment contingencies. The upgrade met its timeline without rollbacks or major downtime, although untested bugs increased Zendesk tickets and exposed issues involving ActionController::Parameters, tracking events, and mobile applications. A retrospective emphasized planning, documentation, cross-team communication, and broader native-team participation for future upgrades.
Functional Swift Conference 2017 — Brooklyn
Kickstarter hosted the fourth Functional Swift Conference on April 15th, marking the third time the event had been held at its office. The all-day gathering brought together 10 speakers, including four Kickstarter engineers, and 90 attendees to discuss what functional programming can contribute to better Swift code. Sessions covered recursive enums and KD-trees, testing side-effects, domain-specific languages with GraphQL, algebraic laws, monoids, predicates, sorting functions, applicative functors, parsing, and type inference. Examples included using value types and recursive data structures to describe complicated objects and live-coding an applicative parsing API that generates its own documentation. The closing type-system talk examined why inference is hard and described the Swift compiler team’s use of graph theory to address inference problems practically.
Why you should co-locate your Xcode tests
Xcode projects with unit tests commonly separate implementation and test files into two directories, often mirroring the source structure in the tests directory. The post argues that this arrangement creates maintenance overhead, slows navigation, obscures how well-tested a codebase is when browsed or reviewed, and can leave tests with lower coding standards. It proposes co-locating each unit-test file beside its implementation file while retaining the test target association, accepting more files per directory in exchange for clearer relationships and easier movement between code and tests. The same SwiftLint configuration is used for implementation and test code, treating tests as first-class code. Tests without a single-file correspondence, including integration or UI tests, should remain in separate directories and may warrant separate targets; the authors say their codebase has adopted the style.
Always Be Learning
Kickstarter’s Data team describes how pair learning fits into its broader “always be learning” culture, alongside monthly reading groups open to all employees. Two team members worked through Hadley Wickham’s Advanced R by reading one chapter every two weeks, then meeting for an hour and a half to discuss the material and complete exercises. They found that a steady pace, applying concepts to Kickstarter data, explaining ideas aloud, and documenting lessons in an internal R guide supported sustained learning; the guide includes a demonstration of R’s lazy evaluation. The pair considered the format easier to schedule and harder to neglect than larger groups, while acknowledging fewer perspectives and inclusion challenges, and concluded that it strengthened job-related skills and intellectual curiosity.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.