Closed niryariv closed 10 years ago
alonisser
commented
10 years ago just checked heroku about multiple apps. seems that you can unlimited number of apps on the free tier (with 750 hours dyno) but you need a verified account for that. https://devcenter.heroku.com/articles/account-verification
florpor
commented
10 years ago Got the client working the way I thought. A bit messier then i guessed, but now adding a new site for a city (just client) is only adding a new html file. Main site (default is Jerusalem): http://florpor.github.io/opentaba-client/ Beer Sheva site: http://florpor.github.io/opentaba-client/cities/beer.sheva/ (doesn't have to be that far down the file tree, just thought it seems organized)
Code is in the last 2 commits here: https://github.com/florpor/opentaba-client/commits/gh-pages
niryariv
commented
10 years ago Nice stuff there Mor!
To your questions:
In any case I think it wouldn't require more than a single Heroku instance to service all the sites. I think that's a good candidate for the Heroku pinging setup.
But in any case, I think your approach is probably better - eventually we can have some cities.json that contains the basic info per each city, and index.html will figure out which city to show according to the URL, so we'll have one client repo.
alonisser
commented
10 years ago Wow! looks great. Just to make sure I understand: what you purpose is different from what Nir suggested the last time about the URL scheme. Instead of using beersheba.opentaba.info , you suggest using opentaba.info/cities/Jerusalem? I remember that @niryariv said something about the hash sign needed in such case, making the url ugly and unintuitive opentaba.info#/info or something like that.
I think we should take over address-to-gush and begin refactoring it as well.
@florpor please notice that if you change or add functions to app.js write a suitable unittest , or atleast document clearly what the function is doing, what it expects to receive as params , output etc' , so I could write a suitable test.
florpor
commented
10 years ago @niryariv i know there can be an inifnite amount of public repos for each user, but i meant we don't want a seperate repo for each city (or a seperate user of course) because that would be hell to maintain. about the scraping - i think it did run but i still don't have any data. i'll show you tomorrow.
@alonisser what i did goes towards what @niryariv suggested. i just made it so we can have all of the city sites on one actual site without duplicating anything for each one besides a small "config" file. they each have an actual index.html so no '#' is needed, and the subdomain will point to the city's folder. btw i thought about it today and i don't know why i did it like this.. we should really have just one index.html and a city index json which will load according to the address like @niryariv said. i'll try to put something together for tomorrow. about app.js - i didn't really add any functions (yet) and it's all experimental so far. will you show me tomorrow how to work with the unit tests?
alonisser
commented
10 years ago @florpor Sure
From: florpor [mailto:notifications@github.com] Sent: Sunday, October 06, 2013 9:11 PM To: niryariv/opentaba-server Cc: Alonisser Subject: Re: [opentaba-server] install opentaba.info test site on the city of your choice and document the process (#28)
@niryariv https://github.com/niryariv i know there can be an inifnite amount of public repos for each user, but i meant we don't want a seperate repo for each city (or a seperate user of course) because that would be hell to maintain. about the scraping - i think it did run but i still don't have any data. i'll show you tomorrow.
@alonisser https://github.com/alonisser what i did goes towards what @niryariv https://github.com/niryariv suggested. i just made it so we can have all of the city sites on one actual site without duplicating anything for each one besides a small "config" file. they each have an actual index.html so no '#' is needed, and the subdomain will point to the city's folder. btw i thought about it today and i don't know why i did it like this.. we should really have just one index.html and a city index json which will load according to the address like @niryariv https://github.com/niryariv said. i'll try to put something together for tomorrow. about app.js - i didn't really add any functions (yet) and it's all experimental so far. will you show me tomorrow how to work with the unit tests?
— Reply to this email directly or view it on GitHub https://github.com/niryariv/opentaba-server/issues/28#issuecomment-25773130 . https://github.com/notifications/beacon/87Gqod6yPkp9j83LwZDSKtzY9CasxEwIbjyDuY5P2hi2Qfr29SsrZZglfMFOoIsg.gif
The server is real easy, just branch (or copy), change the gushim.py and deploy with one env variable. Besides account creation it can probably be done in a small script. Just one thing I don't understand - the server seems to be running well, is there anything I need to do to trigger the scraping? I don't really understand who's supposed to queue the gushim for scraping..? Is anyone running scrape.py at any time? And about the address-db app - where is its code? Did anyone seed it with information or is it polling an external source (Jerusalem worked but other cities didn't). If it's ours how is it on storage limits and will we need to create more of these?
The client is not as easy - github pages allows one site per user (http://.github.io) and one site per project using the gh-pages branch (http://.github.io/). I guess we don't want tens of users/projects, so to keep it simple a good way I think is to store everything in one site, then when adding a new city create a new folder with a small index.html and using the object tag include the parent index.html and a small js with the parameters for the city (heroku address, hebrew name, center point). We will then have clean sub domain addresses and the ability to deploy elsewhere with just one city. The main index could be a default city (mmm Jerusalem?) What do you think?
@niryariv @alonisser