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.
We've been working on various projects using ActiveResource for a couple years now. It seems that ActiveResource is great to use if you are using Rails on both the client and server sides.
Problems with ActiveResource
We're using Scala on the server side and constantly running up against "Oh, ActiveResource doesn't want the API to <do this standard thing>" or "ActiveResource does <this weird thing>" so we have to change the server to support the demands of the client. This has all been discussed before, I know.
Another problem is that many gems and libraries require ActiveRecord. I can't count the number of gems we've run into that "require" your model to use ActiveRecord even though they don't actually use the actual AR functionality. It seems this is mostly because that's the easy path for gem development. "I'm using ActiveRecord, and can't imagine anyone not using it, so I'll just require that rather than figure out the more general way" (note, I've done this myself, so I'm not simply complaining)
So, if we use ActiveResource, we have to break the server to make it work, and we can't use a large portion of what makes Rails great.
REST Adapter?
All of this brought us to ask the question "Why does ActiveResource exist at all?" I mean, why would you have this secondary data storage path? Why isn't ActiveResource just a REST adapter? With a REST adapter, you can have all the good things in all the gems, and don't have to fight with ActiveResource's finicky nature. You just build your model the same way you build any model.
So I started exploring building one. It actually doesn't seem difficult at all. A few hours work and you could have the basic functionality built up. There are examples elsewhere using REST and SOAP, so it's doable.
So the question comes back. If it's so easy, why the hell hasn't this been done before?
Not simply a datastore?
I've come up with what I wonder is the answer. While building up a scaffold for this, I quickly ran into an issue. REST is very good at doing two things: 1) Act on this object, and 2) Act on all objects. In fact, that's pretty much the limit of the REST standard.
And so I started to wonder if scope is the reason there's no REST adapter. The ActiveRecord subsystem seems to need more than just "get one" and "get all." It's based on querying the datastore as much as anything.
The Actual Question
So, the actual question: Is there no ActiveRecord REST adapter simply because REST defines no standardized way to say "give me all of the cars where the car is in the same parking lot as these drivers and the drivers have a key."
That's right.
Unlike databases which have SQL as a standard way to express conditions, there is no standard in REST to support all the ActiveRecord functions, such as joins, group, and having.
How many hours work do you think it would take to do correlated queries or sub-queries?
I'm not being casually dismissive here. This concept touches on some personal projects I've considered, with some of the same issues I've been thinking through.
ActiveRecord supports all of SQL, which is way more powerful than most people use or need. Basically every part of an SQL statement has an ActiveRecord method which takes a string to fill in that section of the SQL.
You'd want to limit the client to the part of ActiveRecord people actually use. You'd still need IS NULL, and IS NOT NULL. You'd need comparisons such as less than and greater than. You'd want to support OR statements, for "field1 IS NULL OR field1 = ''".
To do all the comparison stuff, like where(["updated_at > ?", cutoff]) you would need a RESTful server more robust than existing web services. The server would have to use your gem, or be built with guidelines for implementing all the functionality.
So, in the end why? You're implementing a limited database API, going over the network with string URLs instead of binary packets, to a database engine that you are implementing.
On the other hand, if there was a standard for this, there might be good benefit to such an implementation.
If there was an implementation which one could install on a RESTful web server, which, while maybe not as powerful as SQL, could do indexed queries, post index processing of simple non-indexable expressions to qualify records return, and sort, (even if passing this to an SQL database do all the work), one could enable this on a server, and products, like Crystal Reports could be developed to use the standard for a report client.
Going through the web server API layer, could provide a way to enforce restrictions on what database operations could be performed to provide more security than fully opening up database access. Also, logic could be added to the web service to audit and do processing on events resulting from the CRUD operations (essentially triggers). Yes, database products supply security policies, triggers, and stored procedures to do these things, but with the product we are discussing, one could do it more easily in ruby, than using the database functions.
One could also have pseudo data, which is calculated from ruby code but acts like database records, along side the general DB RESTful access. Sure, databases can do this which store procedures, and some support writing stored procedures in Java, but this would be better because it would be easier to implement and could be written in ruby.
Related
I'm fixing the usability/documentation for the mean stack. I'm starting with Mean.JS. Can someone give me the salient reasons why the authors of the MEAN stack use MongoDB as the database? There are other databases to choose, but MongoDB is used for some reason.
I realize there are questions already covering databases, but I'm wondering specifically why it was used in the MEAN stack scenario.
It think the primary reason is that MongoDB uses the same language Javascript (ECMA Script) for methods and functions API, rather than a separate language (like SQL). Thus MongoDB is a good no SQL database option, and it works much more efficiently as a database for the rest of the stack.
As others have pointed out, there are many other reasons, like that it is the most popular NoSQL database at this point. It has a decent shell and you can write Javascript in it. It is Open Source and well documented.
It is also really easy to setup, and scales fairly well, although not as good as some other NoSQL databases.
It also uses BSON, which is similar to JSON, which is similar to a Javascript object. So it is just plain easy to learn and easy to use this particular database with the rest of a Javascript stack.
There's some pretty good reasons here: http://blog.mongodb.org/post/49262866911/the-mean-stack-mongodb-expressjs-angularjs-and
A Glimpse Into Four Key Components - How MEAN Stack Adds New Dimensions To New-Age Web Applications
All four components of MEAN Stack are popular in the app development space. It offers a platform that enables an effortless development work process. Let’s know about every component and its unique features.
MongoDB – Independent database framework
For any web app building, data storage and management are essential. MongoDB is a popular database with NoSQL document to allow this purpose. The primary use case of this framework is to enable data storage and management of every web application development.(Read More)
I'm developing a brand new project in Scala. It's just an application for a bunch of CRUD operations, however, because of some eccentric requirements, Play2 or Lift does not fit the bill, so I'm going to develop the application from the ground up. This means that Anorm or ScalaQuery becomes less obvious choices for database integration, and leaves me with the question: is it time to try something new?
My past technology stacks mostly included Java and PostgreSQL and I have experience with both ORM and plain SQL. Are NoSQL database management systems like MongoDB a good replacement for a typical RDBMS or are they special case application data stores? Also, how does the choice of database effect the greater Scala system design (if at all)? For example, the fact that you are using a JSON-like interface to talk to the database, and JSON between the web and a REST service, does not mean that much if everything in the middle becomes Scala objects, or does it?
I'm basically asking for someone's experience on moving from relational to object/document type databases, using Scala in particular. I know that good RDBMS integration is promised in the upcoming release of SLICK. So, if a company like TypeSafe decides to make a RDBMS integration part of the TypeSafe stack, then will I be swimming upstream by integrating to MongoDB using Casbah for example?
Apologies if this question appears a bit vague. I do hope that someone with the right insights or experience will be able to help though.
Update:
Apologies for not adding links to SLICK (it being fairly new). Here goes:
Quick overview
Project home
Update 2:
My personal first win for a technology is usually developer productivity - this translates to lightweight and simple: quick to learn, easy to maintain, no magic
I am currently in a similar situation, and since I have some experience with web development and SQL databases, I took it as an opportunity to work with MongoDB, Cashbah (and Scalatra). My experience is still very limited and the project and the amount of data I am working with is pretty small, but here are a few observations I've made.
For the few sets of data I have, performance does not seem to motivate either SQL or NoSQL. However, performance in the presence of huge amounts of data is often listed as a reason for using NoSQL, e.g., by Wikipedia
My documents (entries in the database) arise from benchmarking test suits, and mainly have a static structure, and I am optimistic that I could store them in a fixed-schema SQL database. However, a few substructures are not static, e.g., new test cases are added, new statistics are tracked, others are removed. This was my main motivation for trying a schema-free NoSQL database. Also, because I had the feeling that the document approach of MongoDB makes it much more obvious which data belongs together (i.e., to a document), in contrast to entries in a relational database, where the data would be distributed over various tables and rows, and where a full "document" would need to be reconstructed by joins.
Tools such as Lift-Json or Rogue allow you to work with regular Scala objects in a type-safe, although the data is regularly (de-)serialised as (from) JSON. However, this naturally works best if the structure of your data is mainly static, otherwise, you you are left with using strings to access your data (e.g., for expanding the results of a query using Cashbah).
If you are mainly concerned about a coherent representation of data on server and client side, languages such as Opa or Haxe might be of interest, since they compile to code that can executed on both sides. See this page for "multitarget" or "tierless" languages.
Got too long for a comment. Was just trying to relate my short experience with Scala (about 6 months now, since about when Play2 came out--it's quickly become my go to language).
I've enjoyed using Salat/Casbah with MongoDB in my last few projects; most have been in Play2, but the latest was without a webapp framework. It definitely hasn't felt like swimming upstream.
I would say that there are particular use cases for which I wouldn't use mongo, but it works nicely as a general purpose object data store, especially if you expect to query by id or index and don't need transactions (and will need minimal ad-hoc aggregation type stuff).
Expect to require a separate set of servers dedicated to mongodb (or to use a service dedicated to mongodb), but I guess that's normal for most serious database apps.
I've also used Play2/Anorm, which was surprisingly enjoyable to use for some ad-hoc query dashboard-style report pages. I started trying to go the Squeryl route, but Anorm seemed easier to use for one-off aggregation queries. Haven't looked at SLICK, but it sounds interesting.
It's really hard to say without knowing what problems you would like the app to solve.
I've personally found my productivity increased using NoSQL DBs via REST/JSON. Though bear in mind most NoSQL DBs offer REST interfaces which preclude the need for much middleware, Scala or otherwise, unless you intend to write a webapp with a UI.
If this is a learning exercise, I recommend you try multiple things out, as each NoSQL DB has something different to offer to your toolkit, and have personally found CouchDB, Riak, Neo4j, and MongoDb all with various pluses and drawbacks and good for different purposes.
Hope this helps, good luck.
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'm coding in PHP since a long time. And since a few days I've been looking for a job in web development.
Apparently they're looking for people who either knows ZEND or Symfony. I don't know either one (although I did work a bit on CodeIgniter).
And I really wanted to get into node.js these days.
So I'm asking you guys, what should I privilege to get a job? I have a feeling Node.js is going to become something really important and demanded, so I'd better get into it before others do...
What do you think? Are there other things out there I should learn? I really don't want to get into RoR since I do PHP.
I know this is a highly contested topic, but node.js is more of a buzzword than anything and it will not be a skill established companies are looking for. Many people have realized that javascript is far too nuanced to efficiently write large-scale applications, and that doesn't change once it's server-side. If you want job prospects, learn a statically-typed, managed language like Java or C#. These are not trendy, and for that reason a lot of people will tell me I'm wrong.
Agree, Node.js and jQuery are going to be the big winners here; for client side development anyway. Also, ensure you're well versed in CSS (especially CSS3) and are familiar with HTML(5) and how all of these work together to make beautiful web apps.
As far as server side development goes, you're really free to choose whatever, after all, it's rare the client ever sees the actual code that makes a WebService run. If you can make a reliable WebService in PHP, sure. C#? Why not? RoR? Java? Python? The more you know, the more marketable you are, and you get exposed to a lot more code. Personally, just because I'm forced into the big business world, C# is what I use almost exclusively, but only because I use it everyday.
If you get super adventurous, go for some understanding of SQL as well. And network setup etc. But that could be out of the scope of a web developer.
I would agree with the Node.js suggestion but would also learn the jQuery and jQuery mobile libraries for JavaScript.
They offer a huge amount of functions to ease web development along with support for HTML5 functionality. The other nice thing about this is you can write mobile web apps using jQuery mobile and support all platforms (iOS, Android, WP) with one app. It won't be native but it can still be a great looking app with a huge amount of functionality.
EDIT: Definitely agree with everything Breland says and in addition I'd like to emphasize that SQLite on the client-side would be something good to learn. It's a really nice feature where you can create a client-side database if you want to persist data that is a too big for a cookie or you can go with a real database.
Unfortunately AFAIK it's only supported on webkit browsers right now (Safari, Chrome, Android, iOS) but it could be good to learn how to use this and also an ORM like persistencejs which is a jQuery plugin that creates an ORM for SQLite and can work on the client or server-side.
These days, a "Web Developer" means something else than what it used to 3 or 4 years ago. That skill set is further split into disciplines now, mainly front-end and back-end. The path you go with will likely be based on what you've been comfortable doing as a PHP developer.
If you've been building PHP apps the "traditional" way and controlling all aspects of your MVC apps through PHP then learning modern PHP frameworks that make that approach easier would be an easy next step.
If you've been building PHP backends that expose business logic through an API or service layer, you can stick to the backend track and learn to do the same in Ruby on Rails (using something like rails-api) or Node.js if you wish. If you go the node.js route, picking up CoffeeScript will make writing your JavaScript a little more comfortable but it's another syntax you'll have to learn.
If you've done both 1 and 2 above and you like client side development, learn modern Javascript web development. Don't worry too much about which framework to side with yet, just learn the modern way of building large JS apps. A book I recommend for that is JavaScript Web Applications by Alex McCaw (http://shop.oreilly.com/product/0636920018421.do). It did wonders to help me shed my dislike of JavaScript which came from working with the language many moons ago.
My advice would be to learn both sides of the fence and master one or two frameworks on each side. That will make you what's now called a "full stack" developer, which is just a term used to identify those who are effective at client and backend dev thereby making them highly desirable in the marketplace.
Good luck.
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.
On my first job interview, I was asked why did I build my own CMS? Why not to use one of existing CMS, Wordpress, Joomla, Drupal...? At first, I was stunned. I couldn't immediately recall all of my reasons for building my own CMS, but this was definitely one of the main reasons: It's my code and if I want to change something in that CMS (which I often have to do, because each website I build needs CMS with different functions) it's not a big problem. For some time I've been using Wordpress and one of the main things that distracted me from using it was discovering bugs in code that wasn't written by me and this bugs were often, especially if I made some changes to CMS or added a plugin...
Here, I can find these 8 reasons why NOT to build own CMS:
It won’t meet users’ needs
It’s too much work
It won’t be a standard solution
It won’t be extendible fast enough
It won’t be tested well enough
It won’t be easily changeable
It won’t add any value
Create content, not functionality
Quote from the same page:
So the main question to ask yourself
is: ‘Why am I really trying to
re-solve a problem that has already
been solved before?’
Well, I definitely agree that it's hard to invent CMS that hasn't been already invented, but on other hand, I think every CMS is (or should be) individual... it maybe won't have a million of functions, it will have 3 functions but their usage will be clear (to a user) and do all that one site needs to have. I think also that it is not good to give to a client a CMS with a lot of functions that are never used and it looks probably more professional when website and CMS together look like one product.
I would also like to comment some quote parts:
"It’s too much work" - I agree, but when using existing CMS and customizing it to website needs and can sometimes be very hard job or mission impossible.
"It won’t be easily changeable" - I disagree with this one.
What is your opinion on this one, why did you develop or didn't develop your own CMS?
Ile
This is an interesting question that applies to most development, not just when building a CMS.
In general, I would say that it's a bad idea to reinvent the wheel (and most of your 8 arguments are correct in most cases), but there are exceptions. The first one that comes to mind is one from Joel Spolsky, In Defense of Not-Invented-Here Syndrome:
If it's a core business function -- do
it yourself, no matter what.
The point is, if you're making your money directly from building content management systems, you should not take one from someone else and tweak it until it fits you. You'd rather be in full control over your own product.
Edit:
Also, don't forget that the urge to reinvent things stems (among other things) from a fundamental law of programming:
It's easier to write code than it is to read it
This does not mean that we should take the road that appears to be easier but it explains why we fall for it. Take the challenge and actually read some code, rather than write it, from time to time.
I would build a CMS because it can be fun and a great learning experience.
However, any open source CMS can be customized to any client's need. The biggest problem is that you have to understand how that CMS works in order to be able to change it well.
Either way you would be faced with quite a big task, but I must agree with those who say that you shouldn't start from scratch (unless you are doing it to learn some new technology) exactly for the reasons stated in your question... As they say, don't reinvent the wheel unless you want to learn about wheels.
I've found it works when the context of the project is larger than just a 'content site'. I've worked on a number of real estate sites where the bulk of the content is coming in from data feeds, or already existing in databases that have had their structure set up long before you were involved. Really, we only had a handful of BS 'content' pages that made up the site that were rarely updated. What they really needed was a simple interface to data entry. It was far easier to build some one off components than try and shoehorn an existing system on top of an out of the box CMS.
Like others mentioned though, you must consider overall requirements. Is there workflow involved? Dynamic navigation? Then I'd start leaning more towards out of the box CMS's, but many times people say they need a CMS, when they really just need a WYSIWIG interface to a database. But sometimes not...
It seems to me that the biggest reason NOT to build your own CMS (besides security issues) is lack of support and upgrade path. I consider it a disservice to clients to put them on a custom CMS and then have to rely on you only support and updates. Even worse is having them pay for the development of the custom CMS - they are paying you to reinvent the wheel no matter how simple the site requirements are.
There are plenty of CMS options out there that will allow you to add your own custom extensions if your requirements are beyond what is built in.
The best reason (possibly only) to build a custom CMS is to learn a language well. Building a CMS is a great way to learn web development, but it's not a great way to service your clients.
As a team leader that is always being pushed to do more with less, I too ask the question "why would you write your own?" There are more CMS packages out there than there are programming languages and I find it difficult to believe that you cannot find one that meets most (if not all) customer, business and cost requirements.
If you find that code changes are needed, opt for an open source solution, make your changes and share as needed or desired.
I do know that many times a CMS systems is NOT what is needed. Many customers need a Content Editing System. What I mean is that someone technical puts a site in place and the customer adds/edits/removes pages. The pages are already well designed and formatted. In these cases, I can see where it may be quicker to design & implement something from scratch rather than chopping down a CMS with access rights or removing/hiding functionality.
Unless you're building one for the experience, there's only one real reason for building your own: It's cheaper and/or easier than using one on the market that meets your requirements.
If you were going to start building web sites as a consulting business on the side -- keeping your day job -- and you also had a toddler and a wife, what frameworks/tools would you pick to save you typing?
Any language.
I'm looking for a productivity superstar stack that won't tie my hands too much when I have to update the site 6 months later, or "evolve" the data model once in production.
It needs to allow me to say "yes" to the client: community features, CMS, security, moderation, AJAX, ...
I would suggest Django. Super simple to get something up and running really quick. You are using Python which has a large library to go with it. For me Ruby on Rails would be a close second.
I'd probably look at DotNetNuke. Its easy to set up (a lot of hosts will do it for you) and easy to use and put together a custom site that business's will be able to maintain in the future.
Its fairly easy to create custom modules that are specific to a business and hundreds of modules for sale (or free) that can be integrated into DNN for special uses.
Take a look at Microsoft's Sharepoint server if you'd like a pre-made framework with many options for plugging in your own code. Sharepoint is kind of a world unto itself but it is a very powerful environment.
Update: I'm surprised to have been voted down on this one. Keep in mind that the questioner specifically requested frameworks that included a CMS. Sharepoint meets this criteria - unlike straight .NET or other web development frameworks.
If you are going to vote the entry down, I think you owe it to the person who asked the question to explain why you don't think he should not even explore it as an option. You could be right - collective wisdom is what voting on SO is all about. But without an explanation, we don't know why you think you are right.
My answers are going to revolve around the .NET stack.
Use Master pages and CSS templates. This makes it so much easier to pop in a new look and feel for your customer.
For sure I'd include the Dynamic Data framework in the .NET world.
Hosting might become an issue for your customer. Questions around managing email addresses, procedures on how to quickly update the website to include the new contact phone number (different for each customer, I'd assume) Consider getting a reseller account on your favorite webhost, and dole out webhosting accounts as appropriate. There are lots of issues around this point. It may turn out to be a nice source of recurring revenue.
Build yourself a few patterns including a database wrapper which would handle all your data calls (i.e. a dll which wraps all your data calls, sets up your ADO.NET objects, runs your sproc calls, and picks up the connstring from app.config or something similar.)
This goes a long way to maintainability as well.
I would recomend going with anything MVC in a language you can undertand! Theres a couple of CMS's in python, php and ruby using that design and well... that allows you to be ready for combat for Ajax and expanding anything very fast.
This is definitely not a question that can be answered.
I prefer asp.net webforms because I think it allows for extremely rapid web app development, but I am sure you will receive recommendations for:
asp.net mvc
Ruby on Rails
PHP and some framework
Python and some framework such as Django
I believe PHP has the most pre-built apps that you can use, though asp.net also has the things you are looking for.
All of these platforms and frameworks can do what you want.
Choose between Rails and Django. They both have different strengths. I like Rails better in general, but Django's admin interface can save you a lot of time when you need it.
There's another factor to take into consideration here: what are you the most familiar with? I believe that some studies have found upwards of a 30% loss of productivity when trying to learn a new language/framework.
Sometimes, there's nothing wrong with just sticking to what you know. But if you're interested in what languages/frameworks to learn, I'll refer you to the other posts because the above was the only thing I really have to add.
I recommend looking into Grails. It uses Groovy which is similiar to Java (so if you know this already you're good to go). Groovy runs on the JVM so you can still use all the great libraries already available for Java. Yet, since it's a dynamic language with a lot of the similar bells and whistles like Ruby you can use closures and that kind of neat stuff when you need/want to. And you're not slowed down by Java's traditonal slow compile-deploy-test development cycle.
Grails is already setup with Hibernate and Spring. You can create CRUD application in practically no-time (pretty much like Rails applications), and at the same time drill down and be able to control every little details since it's built on such proven and well-supported technologies. In addition there's literally hundreds of plugins available that helps you easily set up things like mailing lists, security, AJAX components and so on.
Otherwise, if you want to set up a community site and don't want to code a single line you could always check out ning.com.