This application demonstrates the requested functionality completely. However in order for this to be completely production ready, there is more work to be done. I didn't do it for a few reasns main one being I'm not getting paid for this. This more of a proof of concept level implementation. Here are some ways this can be made production-ready, depending on the non-fuctional requirenments that would be gathered from feedback from steakholders in real production environment.
- Use Redis for Caching Cache should be handled by Redis instead of SQLite. Redis can automatically manage the 30-minute expiration time and offers other performance and scalability benefits. I initially attempted to implement Redis but switched to SQLite (Plan B) because integrating Redis was taking too long. I went with second-best solution to meet the "deadline".
- Cron Job for Expired Cache Entries Since I sent with SQLite, there is a problem. By default, it doesn't delete expired cache entries. That would be a problem if the service is used in anything more than a POC capacity. One way to handle this is to create a cron job that deletes all expired entries. Though just using
- Environment-Specific Configuration
Values like the cache expiration time and the weather service API key should be stored in environment variables (e.g.,
.envfile or a secrets manager). This ensures sensitive data isn’t hard-coded and makes configuration more flexible. - Environment-Specific Settings The app currently uses the same configuration for all environments. For production readiness, different configurations should be defined for development, testing, production, and any other environments used.
- Code Comments and API Documentation I aim for my code to be self-explanatory for anyone familiar with Rails. I avoid comments that merely restate the obvious or duplicate knowledge already available in the Rails documentation. However, I would include comments for non-obvious logic or areas not covered by Rails documentation. Additionally, the app should include API documentation (e.g., Swagger or OpenAPI specs) to simplify integration with other teams.
- Scalability and Asynchronous Requests This implementation assumes that downstream services can handle the traffic from this service synchronously. In production, that may not be the case. I would make requests to downstream services asynchronous, possibly using message queues like RabbitMQ, depending on the requirements and trade-offs. This would ensure that the app can scale gracefully under higher loads.
- Trust Assumptions and Security This service trusts its users and downstream services. It assumes users won’t input sensitive data (e.g., nuclear secrets or PII) into the address field to be sent to third parties. Likewise, it assumes downstream services won’t send back malicious or inappropriate data. In production, these assumptions must be validated or mitigated. Input validation, sanitization, and monitoring are essential to ensure security and avoid vulnerabilities like SQL injection or XSS.
- Error Handling for Downstream Services This service assumes downstream services are always available and reliable. In production, these scenarios must be handled carefully, with retries, dead-letter queues, and fallback mechanisms.
- Testing Coverage Ensure comprehensive unit and integration tests exist for all critical functionalities, including edge cases.
• Must be done in Ruby on Rails • Accept an address as input • Retrieve forecast data for the given address. This should include, at minimum, the current temperature (Bonus points - Retrieve high/low and/or extended forecast) • Display the requested forecast details to the user • Cache the forecast details for 30 minutes for all subsequent requests by zip codes. Display indicator if result is pulled from cache. Assumptions: • This project is open to interpretation • Functionality is a priority over form • If you get stuck, complete as much as you can Submission: • Use a public source code repository (GitHub, etc) to store your code • Send us the link to your completed code
The [company Coding Assessment Exercise is attached. Please return as a single GitHub Link with the Code, ReadMe file, and Unit Tests in it. Please remember – it’s not just whether or not the code works that they will be focused on seeing – it’s all the rest of what goes into good Senior Software Engineering daily practices for Enterprise Production Level Code – such as specifically: • Unit Tests (#1 on the list of things people forget to include – so please remember, treat this as if it were true production level code, do not treat it just as an exercise), • Detailed Comments/Documentation within the code, also have a README file • Include *Decomposition* of the Objects in the Documentation • Design Patterns (if/where applicable) • Scalability Considerations (if applicable) • Naming Conventions (name things as you would name them in enterprise-scale production code environments) • Encapsulation, (don’t have 1 Method doing 55 things) • Code Re-Use, (don’t over-engineer the solution, but don’t under-engineer it either) • and any other industry Best Practices. Using ChatGPT, Copilot, or any other AI tools to complete the assignment or to use during your interview is not allowed.