Okay, here's the situation. I've had a bluehost account for several years and am happy enough with it I'm unwilling to move without a really good reason. However, I'm finding more and more that the best solution to the main use for one of my domains is to have a fairly simple rails app running to cover that.
The rails app could easily be front-ended by two forms on the landing page, each with a couple of follow-up pages, but I want the URL always to show "mysite.com" rather than "myapp.heroku.com". I also want to continue to use my email addresses with this site. I don't expect the app to see heavy usage, and am unlikely to go over the 750 hr/mo free time on heroku.
I currently use Rails 3, and would likely have trouble stepping back to rails 2 in my thinking. I'm also not very good at programming in rails, or anything else for that matter, so I'd like not to confuse myself any more than necessary.
So what's my solution here? Transfer the whole domain to Heroku? Embed partials of the app in the landing page? Can I keep email addresses working with Heroku? Can I transfer just the www.mysite.com to heroku, but have everything else involved with the domain hit bluehost?
I'm open to advice.
Heroku doesn't provide any email hosting/sending itself - so you either bring your own or use one of the Heroku addons like SendGrid for sending mail from your application.
Of course, you can just leave you email etc with Bluehost provided that you can modify the DNS and change your www record to be a CNAME to proxy.heroku.com (after you've added the custom domain addon to your Heroku application)
I just did this with blue host and heroku where I hosted my app on heroku and wanted to keep email on blue host. I am using DNS Made easy so your mileage may vary but I had to create an A record pointing to the ip address 69.89.31.63, you name the A record mail.yourdomain.com
and then create an mx record pointing to 69.89.31.63. I am on the cedar stack.
Related
I'm new to coding, quite obviously. I created a web design using HTML in Adobe brackets. How do I create my own website from here? Like getting a domain or host. Not sure if those are even the right words to use
Welcome to the wonderful world of web development! Congrats on making your first HTML site.
I am not sure how much you know about the topic, so I will try to explain the basics of getting a site "online".
Websites essentially allow you to access other people's HTML documents in a file directory. You have probably noticed some URLs in the form "www.example.com/file.html". This means that to get your site online, you will need a computer to "host" your HTML files from. Since you probably don't want to leave your computer on 24/7, you will need to use a web hosting service. There are loads of web hosting companies that offer similar services, but they all have the same goal essentially - providing the means for people to remotely access your files. My hosting service of choice is Digital Ocean because they offer a decent price on a small web server. Through your web server (which is essentially a computer running Linux in a warehouse somewhere), you can install web server software (like Apache) which will allow you place your html files into a special directory which will can be accessed from a web browser (something like /var/www/html). Once your files are uploaded to your server, you can access your website through your server's IP address (some esoteric number in the form of http://xxx.xxx.xxx.xxx).
Of course, you don't access websites through an IP address (at least most humans don't). This is where a "domain name" comes in. The web provides a nifty feature (DNS) which allows you to map a domain name to an IP address. So you can go to your favorite domain purchasing website (something like GoDaddy, which you have probably heard of) and purchase an open domain name of choice. Once you purchase the domain (something like DragonFire09.com), you can map this domain name to your web server's IP address.
These are the two main steps to getting a site online! I hope this provides some insight. Note that getting a website online costs money because you need to pay for a hosting service and a domain, however its a great experience because along the way you will get your hands dirty with Linux and other parts of the web stack.
Of course, you can always create files locally and test them through your own web browser free of charge.
Good luck!
The question is pretty clear I think, but I will elaborate on why I'm asking it.
I created a little blog engine based on OneNote. Basically, the blog configuration asks for an access to OneNote. Then the user chooses a section under which the blog posts are stored.
There is a cron script that will use all these informations to automatically get new pages, fetch the medias and cache every, and finally display the posts.
I chose OneNote because I own three Windows 8 computers and a Windows Phone, so OneNote was an easy choice, as I didn't want to get an other application to manage my blog.
There is still a lot to do (as always with softwares...), but I want to make this more or less an open source project, so that other people can install it on their websites and link it directely to OneNote.
The only "big" obstacle for this now is that authentication in the OneNote API needs to register the application on the Live Connect, and specify a redirect domain. So every user wishing to use this blog engine on their server will have to register their own application... That will look complicated just for a blog, especially if you're not tech-savvy.
Is there a way to "skip" or work around this requirement, even if it requires the user to make the section public (as it is for a blog, this doesn't seem too much to ask) ?
Thank you in advance,
Cheers
Sounds like an awesome project! When you get it released be sure to let us know at #OneNoteDev.
Unfortunately, at this time there's no way to circumvent the requirement for Live Connect OAuth configuration. You could offer a hosted variant so only you need to worry about the LiveID configuration.
Presently, we host our java/j2ee web application with a third party hosting company.
Application URL is like abc-xyz.com
This primary domain abc-xyz.com is going to expire in couple of months. Client doesn't want to use this domain anymore and wants to register completely a new domain. In order to accomodate primary domain change, what needs to be done? Thank you.
This is a very broad subject.
If your client is willing to pay for the service why not just let the hosting company move the contents to the new domain. As far as what to do with the web application it really depends on where and how paths have been declared.
Some developers use static paths. I have seen some sites store the domain name in a text file and reference it through out the site, so a path would look like this where
x='new domain name'
<img src="x/images/yourpic.png">
However using static paths can be very frustrating. It is better to use relative paths in respect to the root of the domain. So the above would look like this instead:
<img src="../images/yourpic.png">
Another thing to consider are the paths to the datasources. If you are running something like cold fusion the datasource is set in the cold fusion administrator so moving a site can be as simple as moving the tables and pages then ensuring that the datasources are set correctly. In php developers typically will set a connect function for all database connections in one file.
This may or may not answer your question but the bottom line is that it really depends on how the site is structured and what type of platform is being used.
I am building a Spring Web Application hosted on Elastic Beanstalk. I use S3 to store user uploaded images which works great. What I don't understand is how fetching images from S3 to the client work. I found three alternatives.
1.Get the image in a controller and send it to the client. Like this:
S3Object object = amazonS3Client.getObject("bucketname", "path/to/image");
2.Open up all images and reach it directly by an URL in the client. Something like this:
<img src="http://aws.amazon.com/bucket/path/to/image.jpg">
3.Use signed download URLs that only working for a certain time. Like this:
GeneratePresignedUrlRequest request = new GeneratePresignedUrlRequest("bucketname", "path/to/image");
String url = conn.generatePresignedUrl(request)
Im not sure which approach to go for. Routing it through the web server seems unnecessary, since it loads the server. Open the URLs to anyone might higher requests and costs since anyone can use the images. And the third way is new to me, haven't really seen anyone practising this which makes me insecure if this is really the way to go.
So, how is this usually done?
And how is this used in the development environment versus production environment. I guess its not changing? Or is it common to use spring profiles to change the location of static content while developing and only use S3 for production?
If your hosting Javascript, CSS on S3, is it then most common to go for approach 2 and open them up for everyone?
For me it depends upon the requirements you have for access control for images uploaded by a user.
If the images are non-sensitive i.e. it wouldn't really matter if someone else got hold of another user's images, then I would go for approach 2.
If on the other hand it would be a disaster if someone managed to get hold of another user's images, then I would go for approach 3 (or some other form of expiring token access to the images).
The last time I did this I went for approach 2 because the images were non-sensitive. To try and prevent people from discovering images, we did apply a hashing function to the name of the image, but again I wasn't massively concerned about this. In either case, a well defined bucket structure that can be easily worked out by the application when constructing the URL for an image is useful. So for you, perhaps consider something like:
s3:bucket_name/images/users/<hashed_and_salted_user_name>/<user_images>
As for you request regarding dev vs prod environments, then matching a bucket name to the Spring profile is the approach we used. So for example:
s3:bucket_name/prod/images/users/user/foo.jpg
s3:bucket_name/dev/images/users/user/foo.jpg
As you can probably guess we had Spring profiles named "prod" and "dev". The code for building image URLs took into account the name of the current Spring profile when creating the URL. Gives a nice separation between environments.
In terms of CSS and Javascript, then I tend to host obfuscated/minified versions in the production S3 buckets, and full versions in the dev/test buckets (mainly for performance rather that trying to hide code). In addition I'd use some sort versioning/naming structure in how you host CSS/Javascript in S3 so that you can determine what "version" of resources your app is using. So for example:
s3:bucket_name/css/app-1.css
s3:bucket_name/css/app-2.css
The version of the CSS/Javascript resources is updated each time you push a new version into production.
By going down this path you kinda look at S3 as the final resting place for a piece of Javascript/CSS when it is ready to go into the wide world of production. Once there, you know it will never change. If CSS/Javascript does change, then the user has to fetch a new resource from S3 as the version will be incremented. You can hook this into your build process so that your main app is always referencing the latest version of CSS/Javascript. I found this has two useful functions:
Makes it very easy to determine which version of a resource your application is running with
Makes it very easy to cache resources (either with browser or something like CloudFront) as you know they will never change
Hope that helps.
I am developing a login and account system for use with an existing website, this will run on a subdomain under the main site url.
I would like to use a subdomain that is generic enough so it isn't tied to an account system but not off-putting to users.
I was thinking of www2 but I am concerned people will see this and think its not "legitimate".
Thanks
Some more context.
The new site is currently used for the login and account system but I will eventually migrate the whole website to the new system, this means the services and pages served by the subdomain will very a lot so it can't be specific to one thing.
Try something generic in the interest / knowledge domain of the existing website. What does the existing website do or provide? This can help you determine a proper subdomain.
Some generic examples:
info.domain.com
account.domain.com
auth.domain.com
app.domain.com
to.domain.com
Providing a better subdomain is going to require some more context.