Talks
Speakers
Events
Topics
Search
Sign in
Search
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
search talks for
⏎
Suggest modification to this talk
Title
Description
RailsConf 2017: A Survey of Surprisingly Difficult Things by Alex Boster Many seemingly simple "real-world" things end up being much more complicated than anticipated, especially if it's a developer's first time dealing with that particular thing. Classic examples include money and currency, time, addresses, human names, and so on. We will survey a number of these common areas and the state of best practices, or lack thereof, for handling them in Rails.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In his presentation at RailsConf 2017, Alex Boster explores the intricate complexities surrounding seemingly simple real-world concepts that developers frequently encounter. He emphasizes that commonplace tasks like handling time, currency, and human names can reveal unexpected difficulties if not managed carefully. Boster outlines the following key points throughout his talk: - **Time Management**: Boster explains that while timestamps may seem straightforward, time zones complicate matters significantly. He highlights issues such as differences in daylight savings time and the many time zones that exist globally. Boster advises developers to store time values in UTC and use Rails’ time zone-aware methods to avoid confusion. - **Date Handling**: The speaker contrasts dates with times, stressing the importance of only using date formats when the specific time of day is not relevant. Mismanagement in this area can lead to errors in applications. - **Human Names**: Boster discusses the fallacies developers often have regarding names, such as the assumption that names are fixed and unchanging, or that all names can be represented using ASCII characters. He advises against over-validating names, advocating instead for a more flexible approach to accommodate diverse naming conventions. - **Physical Addresses**: Address modeling is addressed next, where Boster notes the significant variation in address formats even within the United States. He cautions against relying strictly on conventional validation methods and suggests using services like those provided by the US Postal Service to standardize data where possible. - **Financial Data**: Currency management is another crucial topic. Boster recommends using integers for all monetary calculations instead of floats to avoid rounding issues and inaccuracies in financial representations, particularly when interfacing with JavaScript. - **Email Validation**: He also touches on the pitfalls of over-validating email addresses and the importance of accepting diverse formats that may not align with strict validation rules. - **Internationalization**: Though he does not delve deeply into this topic, Boster encourages developers to think about internationalization from the onset by storing hard-coded strings in locale files, which can ease future translations. - **Recurrence in Events**: Lastly, Boster notes the complexities of modeling recurring events in software applications and the potential for error when handling such features. In conclusion, Boster's main takeaways revolve around the need for awareness of the global and cultural diversity inherent in software design. He urges developers not to make assumptions based on their own experiences, adopt inclusive coding practices, and remain vigilant in thoroughly understanding these deceptively complex elements.
Suggest modifications
Cancel
