Coming soon page in Rails 3.1 - ruby-on-rails

I'm developing a website but want a "Coming soon" page to be up for now. How do I structure a "Coming soon" page in my rails app 3.1? What's the best way to go about doing it.
Four options I'm considering are:
Have a static coming soon page in the public directory. Have rails routes point to it and then modify my routes file when I go live.
Have a page served by a controller pointing to www.myproject.com/home. I'll just change the routes file when I'm ready to go live to www.myproject.com
Use LaunchRock.com. Have my domain posted to LaunchRock and then point it to my site when I'm ready.
Use https://github.com/vinsol/Launching-Soon/
Which method is best suited for my Rails project?
Thank you

Any of these have different pros and cons. It's up to you really.
If you're close to launch, you'll have to set up a web-server and Rails anyhow, so either setting up a Rails controller for serving the static pages, or have a static page in your public directory, are probably the best choices then.
Personally I'd not serve the "coming soon" page through other sites/services.
One reason for having some sort of "coming soon" page is for SEO purposes. For that it's best to have full control over your site / page.
I'd go for using a Controller for the static pages, because you can more easily use the same layout as your site, and you can add dynamic content to that page (e.g. a sign-up or a contact form).
See:
http://railscasts.com/episodes/117-semi-static-pages
Option number 6) serve the static page through Rack
http://railscasts.com/episodes/222-rack-in-rails-3

Any of the above, and one more:
5.Have you webserver return a static page for all requests, bypassing rails completely.
Which one you use depends on how much trouble you want to go to, and whether you want some sort of basic app functionality (like announcements).
I suggest you make a list of what features you actually need, or are sure you'll use, and see how that matches with your list.
One thing to take into account is the time-frame. If the 'launching soon' is not going to be that soon then you'll want some way to easily keep people informed.

Put a static page with some copy up today for SEO purposes. Then consider your marketing objectives and think about what kind of features you need (e.g. mailing list signup, window into application data, viral video, etc). Balance the needs of those features against time taken away from actual development.
At the end you ask the right question (emphasis mine):
Which method is best suited for my Rails project?
But you don't give any context. Any of the methods you mentioned could be appropriate, but they are meaningless without understanding the business goals. A technical forum such as this is probably not the best place to ask at this stage.

Related

Mautik hosting best practice

I am new to Mautik and therefore need a guidance on the same.
Where should we setup mautik... on some folder or on sub domain to main site or a separate domain? How does the landing pages and forms gets its URL? Can it be embedded on another site on another domain or is it required to be hosted where mautik is hosted?
Moreover does single installation of mautik can be used for two or more different businesses site... which are not relevant.. and mainly a different customer for a marketing company? Or is it better to install mautik per business?
Can we track interactions from mobile app too using mautik?
First thing, I expect you are talking about Mautic and not Mautik.
You are free to choose whatever type of hosting you want, personally I Like to use independent container(could be lightweight) however I have seen people hosting on shared hosting as well.
If you are hosting on say example.com the landing page url will be example.com/landing-page same goes for all elements of mautic.
Yes forms can be embedded on other websites with a completely different domain. say example-something-else.com, you will need to put your tracking script on other site's head to make it work better. I for example check out this small tutorial https://tutorialsjoint.com/mautic-wordpress-integration/ it shows how you can use it in wordpress.
No it is not required that wherever you want to use mautic form should be on same host or domain.
However I recommend to use subdomain if usually just to save the hassle of buying a new domain and keeping the landing page urls more relevant. https://www.youtube.com/watch?v=K8lWaCabH1w this video shows how tracking works, it'll help you understand little better. Also here's official documentation: https://docs.mautic.org/en/contacts/manage-contacts/contact-monitoring.
You can use use one instance to manage multiple businesses I know people who are doing it but when the number of contacts, segments, campaigns, form, emails, landing pages grow with time it becomes a hassle to keep it clean. You can use category and a specific naming convention to keep them organized. But in a good way i will recommend to keep different instances in long run.
I am not sure about mobile apps but ideally it should be possible using tracking script or tracking pixel, perhaps you will need to turn off CORS restrictions.
I hope it was helpful.
Cheers!
No, you must use a VPS with Devian or Ubuntu, In a shared hosting it can cause problems. If you send many emails.
Landing pages can be made in html and pasted or edited in Mautic.
To use it in more sites you must create a user for each one, with their respective different email.

Is it proper to have a static_pages controller?

Is it proper to have a static_pages controller whose only purpose is to render static pages in large apps? Take the following scenario for instance:
You are developing a social network application and are devising the design of the application. You know you will need to be able to route some pages, like:
a landing page (for non-logged in users) at root route
a homepage/dashboard (for logged-in users) at root route
My question is: would you define a static_pages controller to handle the landing page and, later, when an authentication system is in place, check to see if [a user is] authenticated and replace templates? Or might you go without such a controller, opting to create a users_controller with a :before_action that checks for authentication, and redirects (on failure (read: unauthenticated users)) to the aforementioned landing page?
According to the Rails tutorial by Michael Hartl, the static_pages controller would be the way to go; however, my thinking is that that tutorial is geared at very new users of the framework and, perhaps, thus doesn't use the best of conventions in the name of simplicity.
What would be the preferred way, mainly in something of a large app (like Twitter, for example, or even StackOverflow), to handle such a situation?
Yeah it doesn't really make any sense to have a static controller, unless you have something major happening on those pages, that is specific to those pages. In the end it all comes down to your personal preference in how you feel comfortable structuring your app, but in a professional environment, and in the case of Twitter or StackOverflow, they almost certainly wouldn't have static controllers. You're right in assuming that Hartl's guide is geared toward beginners and is meant to teach the basics, not the finer points and conventions. If you need to authenticate a user on a static page, Rails convention absolutely dictates that you would perform that authentication in a users_controller.

Multisite application in Rails (like shopify.com)

I would like create web app like shopify.com.
User can pickup subdomain(or domain), theme and have own store.
How can I do this?
Create main application, deploy it automatically like new standalone version and update it via git?
I'm using Rails 3.
Thanks for your advice.
Based on replies:
When I choose to use only one application (without multiple instances) and give user his subdomain, it will looks like their own website. But everything will be in one database (It's good idea?). And how can I have multiple themes in Rails app?
Take a look at LocomotiveCMS, specifically the routing system. Locomotive actually hosts multiple sites inside a single rails application. It does this by inspecting the request URL when it comes in and setting the current_site variable with the site which is set up to handle the domain. Then the current_site is actually just an object which contains all the pages, contents, settings, etc. for the specific site being served up.
So to answer your question, I think a good solution is to give your rails app the ability to serve up multiple sites based on the domain. It's not that hard, and it seems less fragile to me than trying to automatically deploy new instances of an app.
So far I have understood, you want to let your users have their own subdomain, different theme but the functionality would be same right. Users just need to have a feel of something of their own.
Well definitely, you need to have a single application that supports multiple subdomains.
A quick googling gave me [ http://37signals.com/svn/posts/1512-how-to-do-basecamp-style-subdomains-in-rails ]. May be you can get some insights from here.
For example if your service is http://www.myfi.com, a brief idea can be:
When a customer is registering, you should let him choose his subdomain. And the newly created account will be associated with this subdomain with a url. Say, http://customer1.myfi.com.
You should register for domain *.myfi.com so that anyone in the world hit with anysubdomain.myfi.com, it comes in your application.
Then from the url part, you should identify the subdomain (customer1) that is being used, and need to set that in session.
Now when someone will try to login, you must verify the account in the context of that subdomain's account.
In fact, all following actions need to be handled in the context of the subdomain's account.
Just tried the gather a glimpse of the implementation here. If you have confusion about something specific, share that also.
Edit:
Whenever you are thinking about multiple theme, you must have simple design which is completely driven by css and js. The app/view files should contain only content and HTML nodes with class names or ids.
Generally a UI designer can put more helpful ideas about how to make such theming mechanism. But all I can feel is, based on the chosen theme by customer, you have to load different css and js.
Actually the strategies can be indefinitely sophisticated and scalable, but its always wise to start with something easy. Then ideas will automatically evolve into better ones.

What is the best conceptual approach, in Rails, to managing content areas in what is otherwise a web application?

(A while back I read this great post: http://aaronlongwell.com/2009/06/the-ruby-on-rails-cms-dilemma.html, discussing the "Rails CMS Dilemma". It describes conceptual approaches to managing content in websites vs web apps. I'm still a beginner with Rails, but had a bit of a PHP background, and I still have trouble wrapping my brain around this.
A lot of what I run into is customers who want a website that is not 100% website, and not 100% web app... That is, perhaps there are several pages of business-to-public facing content, but then there are application elements, and the whole overall look is supposed to be cohesive. This was always fairly simple in PHP, as you just kind of dropped your app code into the PHP "script", etc (though I know there are plenty of cons to this platform and approach).
So I am wondering, what is the best approach in Rails for doing this?
Say you have an application with user authentication and some sort of CRUD stuff going on, where users collaborate on projects or something. Well, what is the optimal approach for managing the text/images of the "How This Site Works" and "Our Company" pages, which people may also want to view? Is it just simply having a pages controller and several text fields, with an admin panel on the back end that lets you edit those fields? Or is it perhaps a common approach to start off with something like Refinery, and then build on top of it for the non-content-driven areas of a site?
Sorry if this is a dumb question. It's just that I've read Hartl's book and others, and they never address this practical low-level stuff for a beginner... Sure, I can build a Twitter feed now, but what Twitter's "About" page (http://twitter.com/about)? I can't just throw text into a view and give that to a client... They want a super easy way to see the site tree, edit content areas, AND administrate/run their Twitter feed or whatever.
Thanks for your help.
I think you're looking for a CMS that runs as a plugin in your Rails application. If that's the case, I'd suggest that you try http://github.com/twg/comfortable-mexican-sofa

Order / Priority of development in Symfony

So I've decided after much debate and research to use symfony on my next project. To sum the project up, it is an LMS (Yes, I know there are pre-built ones such as moodle but they do not have what my particular company requires). There are many modules and issues to take into consideration. My question is in what order should one start with Symfony?
Note, the database is already made and populated with data.
The Doctrine ORM?
User Authentication?
Creating the Core modules? (Courses, Enrollment, Grades)
Page security (i.e. installing the rules for who can access what page)?
Checking out the Jobeet tutorial is good advice.
If the database is already built, I would probably do something like this:
Ensure you have a plan of what "objects" and functionality the site is to have (eg. list of courses, course detail page, course search, etc). You should be able to visualise the site and have some design mockups ready. It would also help to know whether it's going to be multi-language or not.
Generate Doctrine models & form classes on the back of your db
Create home page placeholder (probably a module) and a logged-in home page placeholder (probably a module) + basic layouts for further tweaking later.
Create signup & authentication processes (so you have the core functionality of adding users, signing them in and signing them out). Use sfDoctrineGuardPlugin.
Now, start creating core modules one by one according to your plan. As you progress, you'll notice what bits make sense as partials/components and where an additional module might make sense. Add new routing rules as you go along.
Finally, add any little bits, cleanup your template HTML/CSS, JS files, etc
... this way you have a work-in-progress site that you can play around with as you go along.
If I were you, I would try to follow this tutorial : http://www.symfony-project.org/jobeet/1_4/Doctrine/en/ You can certainly match each step of the tutorial with a feature your website has.

Resources