The Find a Home project is an effort by a group within Code for San Jose to provide mobile and web applications that make finding affordable housing in the Bay Area not only easy but also moderately fun.
The California Bay Area is currently going through a housing epidemic; rapidly increasing demand for housing is outpacing supply, which is leading to a massive increase in housing costs. To help alleviate the burden of this effect, Bay Area counties restrict rent growth and have land owners set aside rent controlled housing for those who make less than a predetermined amount - with the amount correlating strongly with the median income for the rent controlled area.
While this is good and all, finding that selection of housing is somewhat difficult. While the rest of the housing market is benefited by fancy webapps like Zillow, Padmapper, etc., the rent controlled units are shuffled into a Government contracted website called Social Serve that is not really well known and hard to use.
Since fancy webapps like Zillow and Padmapper lack rent controlled listings and Social Serve is not on par with with said fancy webapps, Find a Home's goal is to provide a web and mobile application that serves the community - all while being really, really good looking.
There is a staging server that lives here. Due to the rapid pace of development, it may be broken at any time so keep that in mind - sorry.
Both the mobile and web applications will be powered by a Rails based API that serves up rental listings within Santa Clara county, with the initial listings being crawled from the Social Serve website. The API conforms to the JSON:API standard and will use Swagger to both document the API and provide SDK generation for various languages.
The frontend will be in Ember.js.
Both the frontend and backend will be served via Caddyserver with SSL handled by Let's Encrypt.
The mobile application is being built with React Native.
I'll update this repo with a CONTRIBUTIONS.md soon!
Dependencies:
| Dependency | Version |
|---|---|
| Ruby | v2.3 |
| Node | v6 |
| Postgres | v9 |
| Redis | v3 |
How you install those dependencies depends on your operating system. For Ruby and Node, I highly recommend rvm and nvm, respectively. They're both shell based installers for their languages and will allow you to easily switch between installed language versions.
For Postgres and Redis, brew install should provide you up to date versions for both databases. If you're using Linux, then use your distribution's package manager.
Steps to start the API and frontend:
- Git clone the sucka'
bundle installrake ember:installbundle exec rails db:setupbundle exec rails s- Navigate to
localhost:3000to see the index.
This will start the app but there won't be any data in it. To get a simple data set run: rails db:seed
There is a docker-compose.yml file at the root of this project. If you have docker and docker-compose installed and properly setup then getting a working app is relatively easy with a cp .env.sample .env && docker-compose up.
There is .env.sample file that contains empty environment variable declarations. This file is pulled into docker containers via docker-compose in an effort to manage secrets without having to check them into a repository.
Steps to start the listing collection process:
- Set an environment variable named
FINDAHOME_USE_PROXIEStofalse.
The listing collection mechanism is entirely contained within Sidekiq driven jobs. That means that you'll need to have a running instance of Sidekiq.
- Run
bundle exec sidekiqin another tab while the Rails server is running. - Run
bundle exec rake search_job:enqueueto start the listing collection process.
Go to localhost:3000/sidekiq to see the listing jobs being processed.
CAUTION: Following the above steps may trigger rate limiting by Social Serve. You'll start to see jobs fail in the Sidekiq UI because the fetch listing requests will start to forward to a page that asks a user to enter a captcha in order to prove that they're not a robot. If you enter the captcha then you'll be good to go for another N requests. If you're testing the listing collection code then I encourage you to kill Sidekiq (CTRL+C in the terminal window running it) after five or ten collections.
The requests it sends out are stagged by one minute - i.e, one request per minute - in order to be respectful towards the site maintainers. In order to maintain that respect, try to limit how often you run the listing collection jobs. Hopefully, I'll have data seeding done soon so that all local development doesn't depend on running a few jobs. The listing data will persist in postgres.
Sorry for the setup being so complicated! I plan on making everything easier to install and manage in the future!