Related
I would like to create a website (non commercial) for fun. After lot of thought, have decided to go ahead with Rails & Java (in the backend). The main challenge I am facing is with the UI - am not an expert - can work on Html/Css/Javascripts however it would take me much much longer and this is my bottleneck.
I am leaning towards Dreamweaver to build the UI. My question is - will using a tool like Dreamweaver really help me - an armature in UI to create a small web site or am I better off diving deep into CSS/JQuery-UI and then start coding...
In my opinion, drop dreamweaver. You should go look at Bootstrap. It's a very easy to use framework that will assist you in creating your own website from scratch. It's amazingly simple to use and has many jQuery plugins pre-packaged and ready to use.
I second Henry. But if you're new to frontend design; also something to note is the power of tools like chrome inspector to pick it all apart. It's a great way to quickly develop, but also by simply exploring, you'll find yourself learning it all very quickly.. But there's still a lot to learn.
Plus if you're looking into rails, dreamweaver just doesn't fit into the workflow. But then again, I can't imagine dreamweaver fitting into any workflow.
A partner has a website that needs to be rebuild from scratch as it simply can't cope with the large number of visitors (currently build using SilverStripe). The site should be able to deal with 5 million or more members using 20+ languages.
We were considering using CodeIgniter or YII because from research both appear to be excellent performers. However several people advised that we should consider the latest version of Joomla for this. For small websites we are happy to use Joomla but for a heavy load website our feeling says that we have to stay away from that. We are however not able to find any comparison between both from a performance point of view but we do require good arguments why Joomla would or would not at all be a good candidate for this. One comparison can be found here: http://vschart.com/compare/yii/vs/joomla/vs/codeigniter however this doens't tell me what to expect when the number of visitors is really high.
Can some advise how Joomla compares to CodeIngitor or YII considering that the site will receive a very high number of vistors and will use a 20+ languages (for silverstripe we build a translator module as the build in CMS was not usefull when using so many translators).
When you're dealing with a site of that scale, it's probably best not to shift to Joomla. Joomla can handle a fair bit, but I'd suggest that it would be far easier to have a Joomla site that large when the site has been adapting as the traffic increases.
Part of what makes your question hard to answer is that we don't know much about what your current site does.
Is it mainly a CMS? If so, Drupal may be a decent fit for you.
Is it a custom web application? It sounds like it could be, based on the number of translations you're handling.
Is it somewhere in-between? This could also be what you're dealing with.
If you're looking at either of the bottom two options, yes, shifting away from SilverStripe (but not to Joomla) sounds like it might be a good thing.
Given the volume of traffic you're dealing with, it sounds like you probably already have a revenue stream and a development team. In that case, it might be worth having a few of your developers play with CodeIgniter and Yii and see what they think.
I wrote up a detailed answer to a question about what type of framework to choose a while ago, which you can look over here:
https://stackoverflow.com/questions/10095906/yii-or-zend-or-other-frameworks-under-the-following-requirements/10115678#10115678
I'm a Yii fan, having checked out a bunch of other frameworks. Regardless of which framework you use, I'd like to offer one piece of advice that I've found key on all projects I've worked on.
You want to work with objects, not data arrays
The reason for the above is that your models (and the objects they produce) can end up having your business logic built into them. Doing this makes life far, far easier in the long run. A great book on the subject, aimed at manager's and quite high-level (there is no code, although there might be a few lines of psuedo-code), is Object Technology: A Manager's Guide. I'd highly recommend it.
Framework thoughts
CakePHP
I started dabbling with CakePHP until I found out it didn't hand back objects (just arrays), at which point I ran screaming.
CodeIgniter
Looking at what CodeIgniter has for database model support, I think you would quickly hit its limitations with a site of your size, so would recommend against it. And having EllisLabs deciding to leave CodeIgniter behind (see their website for more details) is not a good sign. The signs say stay away.
Of the PHP frameworks out there, these are the ones I hear the most things about:
Symfony 2
Yii (disclosure: I work with this one daily)
Laravel
Symfony
From what I can see of it, has been a huge stimulus to the PHP community and many best practices have come out of that community. Unit testing, Composer, pushes for PSR-1/2, the ideal of modularity of code (some of their core code is ending up in Drupal 8) are all great things that have spurred the PHP community into writing code that's better than spaghetti code. With that said, it feels kind of heavy and enterprise-y and looked to have a pretty heavy learning curve.
Yii
When I was looking for a framework, I had a lot of legacy code that needed migration. Yii's way of handling things, although opinionated at times, has done a lot for me as far as exposing me to good practices that are used heavily on the web. Highly recommended as well.
Laravel
When I was looking for a framework (2+ years ago), Laravel didn't exist. It's apparently quite slick and cutting edge (haven't looked at it yet, I've been busy landing new work regularly in the Yii world), but I am interested in dabbling with it. That said, here's a thoughtful article about Laravel and couple of considerations that I've wondered about.
The main developer, Taylor Ortwell, seemed to be a dominant force. That's a great thing while he's making money doing this and enjoying it. Not sure what would happen to the framework if he decided to do something else.
The speed of development on the framework is an awesome thing and means that all sorts of creative juices are flowing. It's a great place to go look at cool new things. That said, you're going to want your developers to be able to easily find information about the framework they're working with, which in 3-6 months may be severely out of date in the Laravel community. The Ruby on Rails community has the same type of good/bad problem when I've looked around over there; there is so much information about the new stuff that sometimes it's hard to find information about the version of the framework you're dealing with.
That said, there are lots of cool choices out there :-) I should probably wrap up, as this has gone on far longer than I'd intended. Let us know what you end up deciding and how it ends up going.
How big is the site really? Bigger than joomla.org?
Are you talking about big in terms of the amount of content in the database or in terms of the number of visitors.
Joomla really does not have problems with scale unless you are on an older version of MySQL in which case it slows down.
It depends on what kind of application you want.
If you want a CMS, Joomla is the way to go. Because this is what it was build for.
If you are about to create a real "custom" application Yii/Codeigniter is the way to go. (This is what yii was build for)
Regarding performance, from my expericnece Yii is a lot faster, because it comes with way less overhead. You can build the application just as you need it.
Well it's like compare green and salty. Really joomla is CMS, and Yii and CI are frameworks. If you considering make highload on joomla - it's not your job.
If you have high frontend load - maybe watch on js frameworks? Yii+backbone.js or ext.js for frontend is awesome, since you'll move alot to clientside.
CI is dead. I honestly like it, but its dead already. No extensions, no namespaces in future, nothing.
I can say + of Yii:
*faster then CI;
*have great documentation and wiki articles;
*have great and active community and developers;
What else i can add? Active record is good for small databases, but not usable for highloads. Also as i said on yii you can easily make js framework+yii composition. Yii have good caching system. Long time support of stable versions.
I personally manage highload now, but its more backend/api/database. 150+ thousands database records daily, 300+ thousands requests to api, 50 milions records data table. It works like a clock for more then 2 months already.
Choose what you like, or write on native php if its really big system - best choice from practice.
Joomla is an award-winning content management system (CMS), which
enables you to build Web sites and powerful online applications. Many
aspects, including its ease-of-use and extensibility, have made Joomla
the most popular Web site software available. Best of all, Joomla is
an open source solution that is freely available to everyone.
CodeIgniter is an Application Development Framework - a toolkit - for
people who build web sites using PHP. Its goal is to enable you to
develop projects much faster than you could if you were writing code
from scratch, by providing a rich set of libraries for commonly needed
tasks, as well as a simple interface and logical structure to access
these libraries. CodeIgniter lets you creatively focus on your project
by minimizing the amount of code needed for a given task.
Yii is a free, open-source Web application development framework
written in PHP5 that promotes clean, DRY design and encourages rapid
development. It works to streamline your application development and
helps to ensure an extremely efficient, extensible, and maintainable
end product.
Joomla can't compare with CodeIgniter / Yii. But, If you need any CMS for your project, you can use Joomla (or maybe Wordpress). If you want to create any web application, then you need to decide for any PHP Framework. I use CodeIgniter for years, and I like it. They have a huge community, and the best user guide. Yii also has a great community and a lot of features. So, you can decide depending on you demand.
I'm looking for a simple Ruby framework for a non-web project. I'm very familiar with Rails, so when I write pure Ruby I miss:
The different environments (development, test, production)
The console rails c
And many other utilities provided by rake or rails
I know I can require ActiveSupport and friends, but it's not what I need. It's mostly the development framework that I miss.
One thing I investigated is to do my project as a gem (even if I don't need a gem at the end). Using jeweler for instance provides versioning. I'm sure there are better ways but I can't find any. What would you use ?
Alright, that is somewhat of a three-part question. A threstion, or triesti... actually that doesn't work. Threstion it is then.
One thing to understand about Rails is that it isn't magical. It's code, written by mortal humans who have faults (such as oversized-egos) but who are also incredibly damn smart. Therefore, we can understand it after perhaps a little bit of studying their work.
1. Rails environments are lovely
The code behind the Rails environment management is actually quite simple. You have a default environment which is set to development by this line in railties/lib/rails/commands/server.rb. You could do much the same thing in your application. Run a bit of initialization code that defines YourAwesomeThing.environment = ENV["AWESOME_ENV"] || "development". Then it's a matter of requiring config/environments/#{YourAwesomeThing.environment}.rb where you need it. Then it's a matter of having configuration in those files that modify how your library works depending on the environment.
I couldn't find the line that does that in 3-1-stable (it's gone walkies), so here's one that I think does it in the 3-0-stable branch..
As for the lovely methods such as Rails.env.production?, they are provided by the ActiveSupport::StringInquirer class.
2. Rails console is the Second Coming
I think rails console is amazing. I don't want to create a new file just to manually test some code like I would have done back in the Black Days of PHP. I can jump into the console and try it out there and then type exit when I'm done. Amazing. I think Rails developers don't appreciate the console nearly enough.
Anyway, this is just an irb session that has the Rails environment loaded before it! I'll restate it again: Rails is not magical. If you typed irb and then inside that irb session typed require 'config/environment' you would get (at least as far as I am aware...) an identical thing to the Rails console!
This is due to the magic that goes on in the initialization part of Rails which is almost magic, but not and I've explained it in the Initialization Guide Which Will Be Finished And Updated For Rails 3.1 Real Soon I Promise Cross My Heart And Hope to Die If Only I Had The Time!
You could probably learn a lot by reading that text seemingly of a similar length to a book written by George R. R. Martin or Robert Jordan. I definitely learned a lot writing it!
3. The Others
This is where I falter. What other utilities do you need from Rake / Rails? It's all there, you just need to pick out the parts you need which is actually quite simple... but I can't tell you how to do that unless you go ahead and paint those targets.
Anyway, this is the kind of question that is exciting for me to answer. Thanks for giving me that bit of entertainment :)
Edit
I just noticed the BONUS fourth question at the end of your question. What would be the point of versioning your project? Why not use a version control system such as Git to do this and just git tag versions as you see fit? I think that would make the most sense.
First of all, Rails goal as a web framework is to let you mostly forget about the low-level details of a web based application (interacting with a web server, a database, etc.) and provide you with high-level abstractions which allow you to concentrate yourself on the actual job: Getting your application done.
There is such a huge diversity of non-web applications, that it is simply impossible to have a framework that "makes them all".
It is useful to understand what a framework is, and why and when you should use it.
Let's say you would have to build a dog house. You would buy some wood, nails and a hammer to build it the way you want from scratch, or you could go to Walmart and buy a DIY doghouse kit.
You will get a manual with detailed instructions on how to build your dog's "dream doghouse", and you will get it faster done than when making it from scratch, but you will be limited to the wood that comes with it and may be forced to use their nails or screws, and in some cases you would also need to buy a special screw driver.
The DIY kit is your framework. Some smart guys already provided you with the basic tools of making your doghouse, you only had to figure out (or not, if you had a manual) how to do it given their "framework".
Now, let's say you would build a skyscraper. The materials, tools and conventions (the framework) used would probably not be the same as they would when building a doghouse, and it would be over-kill to use a "skyscraper framework" to build a doghouse.
You wouldn't write Twitter client with the same set of tools and conventions as you would when writing a banking application with a billion concurrent users.
Rails is just one framework which provides you with a set of many, many good (and useful) conventions to write a web application, but that doesn't necessarily mean that it's the ultimate way to go. You can choose another framework, and maybe you will like the conventions for writing your application even more than the ones provided by Rails; or you could write all from scratch which would not limit you to what is provided by a specific framework and maybe make it even better.
To answer your question: Think of what you want to write and don't let yourself be narrowed down by the set of tools and conventions provided by a framework, as they will surely be if you choose this path.
Buy yourself some books about Design Patterns and read some great software, and then you may understand why the authors did not choose an application framework. Indeed, they've developed their own conventions and defined the behavior of what it should do; and once again, the "Rails way" isn't the only way, which doesn't make it the bad way. :)
I would appreciate constructive criticism as I really tried to provide a good answer.
Have you looked at Monkeybars? It's a Rails-inspired MVC framework that runs on top of JRuby and Swing to build desktop applications. I like it a lot.
I am looking into developing a commercial application using PHP. Since I have experience in CodeIgniter and it has been working well for me, I decided to use it. Now, if ever my application comes to a point that it needs to grow and have to have custom modifications in the platform, is it possible to modify the CodeIgniter source code to the point that it's far from the original?
I'd strongly recommend not modifying the source code as this is the back bone of the application will make updating to futures releases of codeigniter impossible.
Instead you should be creating your own classes/libraries that extend the core bases. This is best practice.
The codeigniter users guide has some fantastic information regarding this, http://codeigniter.com/user_guide/general/creating_libraries.html
Good luck.
Don't modify it, extend it. Ellislab is good about releasing bug fixes and patches, and the last thing you want is to have to re-engineer all the updates into your new hybrid everytime they release updated source code. Plus, different features and bug fixes are released at different paces for the core and reactor, so unless you plan to lock your framework in at the current version, extending is the way to go.
The good news is CI is built for and encourages extensions of the source. The system folder and the application folder separation are a clear indication of how you should segregate your enhancements from the base libraries.
CodeIgniter is written in PHP. You can completely rewrite the framework anyway you like. So the answer is "yes".
There are many big websites that were written in a different language or build on a framework when they started and have been rewritten many times since. I think a lot of developers (mostly freelancers) are over-thinking when starting out. When I start a project, then I try to get it done and get it out in the web asap. If a website starts taking of - and most of the times start making you money - then you can always take the time to rewrite it.
I think it is a lot more important to spend time when you plan and design your database and tables. I think it is a lot harder to redo parts of your database later on then it is to rewrite the code that uses the data.
Just my 2 cents.
If you have used CI, then you should know that being a PHP framework that all of the source-code is there in the download, furthermore opening the system and application folders and looking through there will tell you a lot. Yes all of the source is there in plain English (plain programming English) and not only is it in plain English but has been extensively documented inside and out (literally that is in the source and in the user-guide). CI gained initial fame from that simple fact, that all code is extensively and meticulously documented.
Beyond all that, the question itself raises concerns that maybe you should study CI a bit further before writing commercial applications using it. Ci is a powerful and very easy to use PHP framework, but it is not a WYSIWYG. In my opinion, a coder should know his tools inside and out in order to be able to create a solid secure and trusted application. The first measure of which is to read the user manual, you should know at the very least everything in it, and since there are 12 sections in it that cover everything from extending CI libraries to creating your own libraries, and everything in between I would say you need to spend a little more time with it.
I want to say though, I am not being rude or trying to shame you in any way I am simply saying that you should learn the framework a bit more before venturing into a commercial application using it.
In the early days of PHP people realized how amazingly easy it was to use and how fast you could write an application with it. At the time the major options where very difficult for new and hobby programmers to use or involved expensive software to run, PHP was free, easy to learn and most of all ran on a free OS. It also took hardly any setup to get going, you could download PHP and essentially be programming in minutes. All of these factors lead to the almost destruction of the language.
Entry level programmers were destroying it with bits of code taken from other applications, never knowing (or caring) what the code actually did beyond the simple fact that it did what they wanted at the time, never considering or even investigating if the code might be harmful. Because of this practice PHP applications that had grown to Goliath sized websites, taking thousands of hits an hour were:
beginning to crash
being hacked to reveal sensitive customer/client data
generally crumbling all around the web
All because since the language was so easy to use that people had taken advantage of it and failed to take time to learn it. PHP was becoming a joke to other professional programmers and wasn't even thought of as a viable application language by many who had dubbed it "the copy and paste" language.
So my advice to you, please take the time to know your tools inside and out, what makes them tick, if they have any gotchas and where they are vulnerable. I understand that in order to learn a language to a professional level you have to build with it so I suggest that you take it slow with CI stick to the core for now. Trust me when I say that even in its purest form CI is an amazing and powerful tool that in the right hands can create awesome powerful web application, but in the uneducated/inexperienced hands it can create havoc and destruction.
So (stepping off of the soap box) I simply ask that if you are serious about creating commercial applications period that you take your time and learn your tools/language become as close to an expert on them as possible. I gurentee that if you do that you will always have work when you need it and you will spend less hours beating your head against the table or worse explaining to a client why their site is down.
I truly wish you good luck, just slow down and learn your trade and you will do just fine.
Yes, Codeigniter is an open source framework. However, I would advise against modifying the core of Codeigniter, as most files can be extended and rewritten safely without modifying the core files which will cause you headaches if you ever decide to update.
To extend a core class by default you would do this in Codeigniter. We'll extended the parser class for this example, but this applies to all classes pretty much. This link in the comprehensive user guide will give you all the information you need to extended and overload methods inside of a Codeigniter core class: http://codeigniter.com/user_guide/general/core_classes.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
So, I've got an idea for a website. I can start off using any platform and frameworks I want, but there are almost too many options.
OS Platform:
Windows, *nix
Web Framework:
Rails, ASP.NET, ASP.NET MVC, Django, Zend, Cake, others
Hosting:
EC2, Dedicated Server, Shared Hosting, VPS, App Engine, Azure, others
Persistence:
S3, MySql, PostreSql, Sql Server, SimpleDB, CouchDB, others
How do you avoid decision paralysis and get started?
Firstly, your familiarity with a framework's language should dictate which framework you choose. Don't add the burden of learning another language on top of learning a framework.
Next, have a look at the remaining frameworks. Do they have good documentation? What about the community. (A good community can go a long way to making up any shortcomings of a given technology.) Does the framework solve the problems that you need solved?
Finally, just dive in and try something! Pick the one that makes the most sense to you and start writing code. Don't do too much hand-wringing over your decision. If it becomes obvious that you made the wrong choice, it should be obvious quite early. Learn from what you've accomplished so far and consider restarting with a different technology. (Just don't get several weeks down the road before you make this decision!)
I'm sure you don't like all of those technologies equally. Pick a framework that you like and get to work.
It depends on what your app is going to be doing. A handful of the technologies you listed are direct competitors (like Django vs. Rails), but some are completely different ways to do things (like MySQL vs. S3).
Questions to answer before you begin:
Will the app need to be horizontally partitioned in the near term? If so, using EC2, Google App Engine or Azure would be a good option.
Will your app fit into the constraints of Google App Engine? If so, it requires a lot less hassle on your part than running on bare metal (whether real or virtual).
What's your preferred web framework? If you want an MS framework, you'll need to run on a host that supports that.
What will your persistence and data access patterns look like? This will determine whether to use a database or something more exotic.
If you are running on EC2, the other AWS services are more appealing. Similarly, if you are using GAE, you have only one option for persistence. If you are using Rails, may as well start with MySQL.
In answer to your question of how to reduce the number of options, the answer is to realize that many of the options are related, so you don't have as many choices to make as it first appears.
Some advice that was once given to me is, pick what your friends (or colleagues) are using. Having people around you that you can share ideas and the learning experience with is invaluable.
If you want to learn something new: I'd just go with your gut and get started. If it sucks then switch to something more familiar.
If you don't have much time: Go with what you know and forget about the other options. Just start coding.
Optimize for happiness. Pick the one that you like the most. Or the one that intrigues you the most.
I've worked in Microsoft shops, in Ruby on Rails, and in homegrown shops having Apache, Jetty, even Mason.
All frameworks have their warts, their idiosyncracies that will keep you up until 3 AM, and their "tribal knowledge" vagaries that will be completely unexportable to other frameworks. (The last point is sometimes by design, the whole "platform entrenchment" business strategy)
Listen to what the supporters of the frameworks say about the problems with the other frameworks (Google: X framework vs Y framework). Pick the framework that has the loudest supporters. If they are equally loud, make the decision with a dice roll.
With me it's simple.
I only know MS stack and see no point in "checking out" all of those you mentioned.
No, actually I once tried to use JSF before excluding it from my list permanently.
Use what you are experienced in and where you can be more productive. The objective is to get your site up and running. Go for it.
One of the biggest factors in determining which platform/framework to use is your budget. You have to factor in the cost of licensing, software required to develop/maintain your website and other miscellaneous costs.
I suggest you begin with a scorecard of your own construction. Perhaps you can find different ones on the web, but if you do, modify them to meet YOUR needs. There should be a scorecard for each level in the stack (as you've described). Each scorecard should share some aspects to grade with other scorecards but each will also have their unique aspects.
Once constructed, weight each aspect graded according to your needs.
Once you've chosen the weights, pick the scales for grades.
At this point promise yourself you wont mess with the weights or the scale and then start collecting data on your options for each level in the stack.
You may also want to put a time limit on the collection period.
Make your decision based on the outcome of the scorecard.
The beauty of this approach is that the effort is made in constructing the scorecard, not in circular arguments of options. The effort in making the scorecard is vendor agnostic and focuses on the desired result, not the options. Thus you can avoid paralysis.
One more thing, my best scorecards have included sections addressing the availability of resources and other human related things. Don't make the mistake of just looking at the technology.
good luck.
Go for personal preferences.
One decision at a time:
Firts I would begin with type of language:
Script: PHP, Python,
Serious: Java, .Net
The language will restrict your OS, plattform and will give you hints for the dataabse decission. The database load is also important. And, Do you want logic in the DDBB? how much data?
Last advice. Try combinations well tested. LAMP, WAMP, Windows with SQL Server and .NET.
Evaluate each platform and technology for quality of tools for your needs. For example, if you are cost sensitive, you would value free operating systems and tools higher than costly ones. If you need performance, you would value tools which provide high performance higher than ones that don't.
It entirely depends on your situation. I spent several months evaluating stuff for a new commercial web site last year, and it was very easy to feel paralized. In the end it was talking to several people who'd done similar things, and of course reading a lot of stuff online and from Amazon. I chose Java, since our team had a lot of experience in it, and it has good performance and extensive supporting technologies. Oracle is our database but we used a persistence manager to make it easy to change later on. We used a half-dozen very good libraries to eliminate much of the boring and repetitive coding (Restlet, iBatis, Freemarker, XStream, jQuery, SLF4J). We used Glassfish as our web server.
Yours sounds like a small project with only you to work on it. In that case, pick a complete framework instead of a smorgasbord like we did. Pick something fun to work with, and something with good "return on resume". Look very hard at Ruby on Rails, Django (kind of a Python on Rails), and Groovy on Grails (a Rails-wannabe for the Java world). In your shoes I'd pick Ruby on Rails because there's a large and growing community and a good number of books and tutorials. Plus, Ruby looks like a worthwhile language to learn. For your database, just pick one. These frameworks make it easy to change your mind later. Pick MySQL unless you have another you like better.
And as other posters said, just do it! ;-)
Like others said, pick something you and your employees are familiar with. I highly doubt you are close to being industry ready with all those techs.
OS Platform: Windows, *nix
Shouldn't matter except for Windows licensing costs, and that is probably the least of your expenses.
Web Framework: Rails, ASP.NET, ASP.NET MVC, Django, Zend, Cake, others
Dependent on your favorite language
Hosting: EC2, Dedicated Server, Shared Hosting, VPS, App Engine, Azure, others
You should design your product to be movable, so you can scale among these. If you know for sure you are going big, then just start off with EC2. App Engine is extremely limiting, ex. they don't let you form outbound connections.
Persistence: S3, MySql, PostreSql, Sql Server, SimpleDB, CouchDB, others
You need to do the research yourself whether or not your product requires an RDBMS or a simple key/value store, and what features each of these have.
Just go for it! Your platform choice really is not all that important as long as you make a reasonable choice (Ruby + Rails, Python + Django, PHP + Cake/CodeIgniter). Any of these can be used to build successful sites. If your site really takes off, you'll be able to scale it fine.