As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am migrating a site built in Coldfusion (no framework) to a coldfusion framework. Right now it looks like a choice between ColdBox and CFWheels.
The database is MS SQL.
I was wondering if anyone has migrated an existing site over to either of these frameworks and if they could recommend one framework over another?
I'm in the process of doing basically exactly what you describe - porting an older CF app that was written without any real framework to a cleaner CF codebase (also using SQL Server, BTW). We are using CF Wheels as the framework for this effort. We chose wheels because of a number of factors - we prefer the style of the framework, since it is similar to several other highly regarded application frameworks (Ruby on Rails, ASP.NET MVC, CodeIgniter, etc...). Also, the ORM layer wheels provides is quite nice, and will allow us to refactor much duplicated and verbose code.
I can't really comment much on ColdBox, since I haven't used it. Prior to Wheels, we were heavily into Fusebox. We were using Fusebox in a very structured MVC-oriented fashion, but as the Fusebox core lost momentum, we found that Wheels offered a similar organization to Fusebox (for how we were doing things) but in a nicer, more modern package, with lots of bells and whistles. So that is now our go-to framework.
I might be wrong here 'cause I've never really used CFWheels.
As far as I know CFWheels is a different kind of framework because it is very RoR-like. ColdBox is a more traditional MVC-like framework.
If you're not looking at redoing the persistence layer, maybe ColdBox or even the simpler FW/1 would be easier to migrate to.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
In the old, pre-Ruby & Rails days o' the web, one typically used PHP when they needed to add server-side functionality that HTML or CSS could not provide. Nowadays, we have a ton of options for creating super-dynamic websites and applications. I recently discovered that you can just use .erb files on a web server to get the same functionality as throwing PHP files in there in order to make things more dynamic.
I am building my first from-the-ground-up website, which will actually be my own personal website. I'm a huge Ruby nerd, and definitely want to invest in the technologies I'm most learned and familiar with. I want to build with a focus on simplicity, speed, and power in mind. I love Rails, and have had the most training in it, so I am, for the time being (for version 1.0 of my beloved sexy website), excluding Sinatra or other frameworks from my list of choices.
Now, here's the question, which is admittedly a bit ambiguous: when is it appropriate to go from using regular old .erb files to using a full-blown Rails framework? The website won't be processing any users or anything, and will mostly be a portfolio for my art, music, and technology works. I'll be doing a blog with Jekyll, additionally, so that level of dynamic content will be handled separately.
Strait ERB files are great to set up a simple template system. Jekyll is a more robust way to build a simple static site using templates. It's great for a personal site that doesn't have dynamic content, it doesn't work when you have users storing new content constantly to a database, which then needs to be rendered on the fly to a new page. Rails is based on the idea that you need a database, if you don't need it skip Rails and save yourself loading time, hosting costs, and sysadmin headaches.
Also check out https://github.com/laurilehmijoki/jekyll-s3 you can host your site on S3 for dirt cheap.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which database should I use with node.js? I'm condering MySQL and MONGO DB.
The correct answer is: it depends.
Like many other programming languages node has various adapters for databases. Ture, some are better than others, but they are all changing and evolving so fast that any statement here would be outdated soon. Even if you select one database, you will find at least two or three adapters with different qualities.
In the end it does not really matter what is a good fit for Node, but what is a good fit for your project. Trying to squeeze a relational problem into a NoSQL storage will do you no good.
The node community provides you with lots of possibilities. Take a look at the Node Toolbox to find some solutions for CouchDB, MongoDB, Redis, Database abstraction layers, MySQL, … As always you need a bit of common sense to choose the right module. Look at commit history, how many maintainers, activity, last commit timestamp, issue queue, etc. You will surely find a solution for a database that you are comfortable with.
I personally find it rather overwhelming when I have to learn more than one technology at once. So if you are new to node, I would rather stick to a database you know for your first project.
Every one has different requirements for completion so it really depends on what you are trying to do. Like Joseph said MongoDB and Node.js works really well together but for certain use case, MySQL could probably be a better choice. Also, you might want to considered the database you are the most comfortable with. Personnaly, I would recommand MongoDB but I think it's a matter of preference.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a strange feeling when it comes about code first migration technology. First of all this is a concept which got its origins in technologies as Ruby on Rails. Not that I do have something against it, please do not get me wrong. What I am not sure about is that if the usage of Code First Migration is a good approach when it comes to high scalable enterprise applications which can include reporting, etc. Basically I am referring at situations where the database design, optimization plays a critical part in the general performance (denormalization, indexing, sharding, etc). My feeling is that Code First Migration brings a major overhead. Am I right, am I wrong? I would really like to hear your opinions.
You're wrong.
EF Migrations has nothing to do with the way your database is designed. It is only a one-time process that merely generates scripts against two versions of the database schema and figures out how to migrate from one to other automatically.
Migrations does not run when the app runs, it doesn't have any overhead or affect performance of the app. It only works with the existing schemas as EF itself generates them. In fact, this process is so generic, it isn't even specific to EF, Migrations can be used to migrate between any two schemas, whether they use EF or not.
As such, it has nothing to do with how the database performs.
The schema is controlled by EF itself, and is dependent upon how you map the database. Yes, it's true that if you just let EF do all the work you might end up with a less than optimal schema, but you can fully control how it generates this by using Fluent Mappings.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to spend the summer getting into web development. I have some basic C++ and Java background. I was told by some people to master HTML & CSS first then Javascript. Then someone else told me that I should go with Grails while another person told me Ruby on Rails. I've always been interested in web development but never had the time to fully learn it and now I have some free time and I'm hoping to hone my skills.
The problem is there are so many platforms and languages that it's quite confusing. I want to eventually create a website and then embark on a tech startup. I'm quite confused. Please help. I know I need to master HTML, CSS but what do you recommend?
Thanks.
I personally use Grails and JavaScript for developing web apps. I like Grails very much, as I used to work with Java and Grails adds many cool features to the old Java and makes it easier to use. But I wouldn't learn Grails now because its future is uncertain. Ruby is a better candidate, but I don't know this language at all.
IMHO Javascript is a must. If you know it well, I guess you can use it both for client side and server side (Node.js). And I think JS will be use much more in the future, so learning it is a good start.
In conclusion, I recommend Javascript.
Cheers,
Lojza
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I'm starting a web application and I'm hesitating if it is worth to use Oracle in order to have a better performance / scalability. Thanks
Oracle requires significantly more infrastructure and specialized staff to be maintained than MySql for example. It offers, arguably, more in return. But since you are talking about scalability / performance, bear in mind that Wikipedia, Flicker, Facebook (and many of the most visited sites in the world today) run under MySQL...
So, put your focus on designing well your database instead of trying to find out which platform to use. Every single one of them has many strengths today, and are ready for production and demanding environments.
I, myself, would never ever even consider using Oracle from the start in a new Web Application. I would only jump to that more expensive RDBMS if really needed.
It can also pay off to use a ORM tool that will give you database independence, so changing the RDBMS will not be a big issue at all.
Oracle can be very fast, but you have to spend millions of dollars for licences, hardware and dba-consulting hours. PostgreSQL is fast, has no licence costs and offers (almost) the same rich functionality as Oracle. PostgreSQL speed depends on your hardware and configuration as well, but you don't have to invest all your money right now to get started.
MySQL is populair, but has limited functionality and isn't as strict as you would expect from a DBMS.
Write you application to be database generic. That way you can move to whatever database works the best for a given installation. That's relatively easy to do in most web environments these days.