Please, be forgiving in matter of language mistakes. Thank you in advance for any time spent on this question.
Some time ago I came to idea about web/mobile app focused on delivering live video content mixed with users having interactions with each other in real time while they watch. I think there is no need for more specific description.
So, for my core functionality - streaming video, I decided to go along with Nginx server and plugin nginx-rtmp-module, because it seems to be most feature rich and well documented free solution.
But I have problem with deciding, which solution to pick for real time user interactions wrapped around my streaming server. After long research I left myself with 2 options.
Option 1 - Wordpress + nginx-push-stream-module
I have some experience with Wordpress
Lot of minor functionalities like user management, payment processing, admin panel, Facebook/Twitter integration are working out of the box and save alot of time
I hate writing anything in PHP
Wordpress is far far from being anything close to real time solution
Higher resource usage on server
Option 2 - Nodejs + socket.io
Really fast and real time oriented - core features of my app
I like Javascript and it would be easier to focus only on one language
Good solution in long term perspective
I have to build everything from scratch
Security? I have no idea how to secure my app
I want to build this app by myself and then, if it hits, hope I will get enough funds to make it better. I feel like Option 1 is best, but I'm scared I will soon find myself stuck with limits of this choice.
Please help me with your experience. Thank you for your time.
Related
Ok, so suppose I want to open an online shop, an eCommerce website. I saw that you can do that by simply customizing a wordpress theme in a couple of hours; a domain and a webhosting and you're done, right?
Why should someone hire me and pay me a generous sum of money if he can do it himself? What advantages brings writting code from scratch?
I ask this from the position of a rookie technology learner, developer wanna be, and I am still at the point at choosing my direction.
It's not just that easy. Not everyone is good with computers. You pay a web developer not only for knowing the best way to implement the system but organization of the website, configuring the server the best way etc. Even high end companies don't write from scratch because it's too time consuming. Time = Money and most businesses don't have that kind of budget.
But they do need someone that can fix their store if something goes wrong. Every second the site is down, that's money lost.
I was looking at some larger scale Meteor applications and was wondering why some of the initial sites do not seem to use meteor.
As an example when you go to classcraft and look at the main website you notice it is not using meteor.
Then when you go to their actual application (click signup for example) you can see it uses Meteor.
So they make a clear separation in terms of technology. Can someone explain the reasons? Is it not as efficient / clean to just use Meteor for the whole thing.
Thanks,
Jean
Each company makes their own decisions on how/when/where to use technologies. In the case of meteor, the really strong part of meteor is that it's real-time updating. That means things like messaging systems, getting updates out quickly, etc. good uses for meteor.
It appears as though classcraft has decided they don't need that capability on the home page. There's also some concerns with SEO and meteor that perhaps classcraft didn't want to deal with.
Finally the home page not being built in meteor shields the DB from public view, which is not a huge security advantage, but may be one they considered.
This is all me finding reasons for them as I don't know why they'd make that decision. I don't make that decision for my sites/apps but that doesn't mean others might not see things differently.
I'm the founder of Classcraft. To answer your question, it's because we didn't need everything Meteor had to offer for the front-facing website : reactivity, flexible templates, a database, etc. Meteor is amazing for building apps, but it's overkill for a static website. Also, if the front-facing website was built within the game app, it'd mean that any copy changes or tweaks to the front-facing would cause us to have to redeploy the app, which means some downtime (not much, but still) for our users. Keeping them separate also allows marketing people (who aren't developers) to tinker with it without going into the code base for the game.
We decided to build the front-facing website using middleman. Middleman allows you to generate a precompiled static website, which allows for amazing speed and simple server configuration (it's served from S3, which means it's super fast).
I'm sure the reasons are different for everybody, but that's what it was for us.
Shawn
I did do some googling and searching on this site but did not find exactly what I was looking for.
I'm hoping that someone can point me in the right direction here. I'm an ASP.NET/SQL Server developer and would like to develop a (intially) basic social networking site (gasp). Before I start from scratch with a blank solution in ASP.NET, I'm wondering if there are any frameworks out there ASP.NET specific that would serve as a good starting point. I'm already thinking of using the Google Maps jquery control for my Google Maps integration, as well as the 'sharethis' control for my social networking website sharing integration. Captcha for human authentication... But other than that I'm not sure what I can leverage... Nothing on Google jumped out at me on my search terms.
I'm also wondering if anyone else has done something similar and could share their post mortem/war stories with me.
I'm also open to learning a new platform/language if it would mean saving time - my experience is mostly in ASP.NET, so that is what I plan on using if it makes the most sense. My initial requirements are basic and realistic - profile setup (images, information, etc.), 'group' creation, Google Map integration, calendar controls shared by groups, SMS support, discussion forums among groups, searching for groups, OpenID integration most likely, etc. I am not going to try to build the entire site and then release it, but take baby steps and release pieces of functionality at a time.
Any advice is greatly appreciated for a broad question such as this. Thanks again.
I've found DotNetOpenAuth which seems to be a nice API for handling OpenID for ASP.NET web forms. They also have an ASP.NET MVC version
I also found MS Web Platform. This looks like some good stuff. Anyone ever use it and think it would do well for this sort of app?
I found a library for DotNetNuke called ActiveSocial. It's priced right ($500) and has more than the features I need but lacks some. I wonder if anyone here has ever used AS before. Is DNN easy to extend so I can add Google Maps functionality and such? It doesn't say anywhere on snowcovered (the vendor that sells AS) if AS comes with the source. If it didn't, then I might be screwed because I wouldn't be able to integrate the functionality I want.
I went through this exercise about 15 months ago when I built a SNS for a client. Hoping to find some basic framework for Friends, Chat, Profiles etc I was pretty disappointed.
That said, in retrospect I wish rather than building one that we would have purchased a solution like Community Server. As with most projects I looked at the problem scope with beer, no strike that, ambitious goggles on and the level of work to cover all the edge cases was more than I imagined.
Tread careful my friend, tread careful.
I think this is what you're looking for. Kigg is an open source ASP.NET MVC app that would be a good starting point for what you want. Here is the url: http://www.codeplex.com/Kigg
You can also find a site that is using this here: http://dotnetshoutout.com/
At the very least you will learn the ASP.NET MVC framework which is fantastic.
While not exactly intended to be used for social networking sites, both of these frameworks can help you so you don't have to start from scratch:
DotNetNuke: http://www.dotnetnuke.com/
Umbraco: http://umbraco.org/
Also, for an out of the box solution (no code involved) you could always try this: http://www.ning.com/
Good luck!
We want to build a web application, that is specific to our domain, but also includes forums, blogs, etc in this application. Some integration points to Twitter and Facebook are also required.
There will also be a desktop application that connects to our web application for uploading data and downloading configuration and reports.
The question is, can we extend Drupal to host both the regular modules and our web application? (There will be business entities and their properties and daily data uploaded from the desktop application)
Or can Drupal be integrated with external applications? As an example, users and roles need to be the same and consistent across both. We may also want data from the web application searchable in Drupal.
I know this is a bit vague, but I cannot reveal more. I am very new to content management and I just wanted to know if someone has built this kind of application.
I try to rephrase what you wrote, just for you to check that I got your question right. You basically need to create a web application that:
Implements some of the standard functionality of Drupal
Have some custom functionality that should "blend into" the Drupal one (same users, same permissions, etc...)
Be able to upload/download content (or data) from desktop applications.
If I got you right, the short answer is: yes, you can do that with Drupal.
Now for the extensive one:
- Drupal has literally thousands of modules, so I expect you to get most of the things you want by simply installing the right combination of readily available modules.
- Of course, any custom functionality can easily be implemented in form of a module too (quite standard thing these days).
- The interaction with a desktop application is normally implemented via webservices rather than querying the DB directly. Drupal comes natively with a xmlrpc server and client, but you can scale up to SOAP - if you wish - via a couple of contrib modules.
Some additional thoughts:
If you choose to use Drupal, and you start from scratch, then you have to be aware you and your team will need to dedicate some time and effort to understand how Drupal works. Although - differently than Palantir - I stuck with Drupal, I agree with her/him on the fact that Drupal gets complicated complex right off the bat. This is the trade-off you have to pay in order to have a platform that - rest assured - is very flexible, extremely pluggable and rock-solid (otherwise it wouldn't have been used to redesign the whitehouse, nor Drupal would have got for the second year in a row the "best PHP CMS" award, I suppose).
The good news is: there are some excellent books out there, and I would certainly recommend "Pro Drupal Development" for an in-depth and all-around explanation of the system. Just be sure to get the 2nd edition, as the first deals with the now obsolete 5 seres. That said...
A very good thing about Drupal, at least in my opinion, is that most of the tweaks you might need to do to an existing functionality can be implemented by hooking into the original code from a custom module too. This IMO is the biggest advantage of Drupal: you never have to touch other developers' code to achieve your goals, and this means - for example - that you will be able to keep your core and contrib modules up-to-date without breaking any customisation you might have done.
Drupal is heavy. Compared to other CMS it sucks plenty of processing power and RAM from your server, and - unless you are going to have a very small site - I recommend to deploy it in conjunction with nginx, rather than Apache.
Drupal scales well, thanks to a good mechanism of caching and "throttling up" mechanisms. Strange as it might sound, Drupal scales very well on large traffic websites, so that big increases in traffic do not necessarily imply big increases in resource usage.
The user experience out-of-the-box on a Drupal site is quite poor. There is a massive work being done on this at the moment (here and here (video)), but improvements won't be available until D7 is released [soon, but then you will have to wait for the modules to be ported], so it is advisable to allocate some time to create an administrative theme, if the admins of your website won't be of the technical type.
At the end of the day, my advice is: if your site is going to go big / complex / with complicated business logic and lots of functionality, then Drupal is probably a good candidate. If your site is contrarily a small-scale one with standard functionality plus a few custom bits, maybe Wordpress / Joomla could fit your needs better [not because they are 'less powerful' but because Drupal strengths would be unused in this case, while Wordpress/Joomla simpler architecture would probably represent an advantage in this scenario]
Other options would certainly be frameworks like CakePHP or Django, for example, but that - IMO - is a totally different approach to the matter, I would say.
Short answer: Drupal is well suited to build something like that, especially if you are willing to integrate your app/logic into Drupal as a suite of custom modules. The other way, integrating Drupal into an external application, can also be done, but will give you more friction, as Drupals architecture is pretty much geared towards being a framework in its own right.
Longer answer: I have a pretty much opposite opinion/experience compared to Palantirs. I've been working almost exclusively with Drupal for a year now, in the context of two fairly complex/'enterprisy' projects (after several years of 'on the side' usage for smaller things). While I agree that it imposes some rigid rules (but not limits!), I consider this to be an advantage, as those rules give a clear guidance and provide proven ways on how to do things. The three parts Palantir mentions are good examples for this:
Menu system - Provides a well structured and effective dispatching mechanism that is easy to extend with your own stuff, while giving huge flexibility to tweak/manipulate existing/default paths. (Note that 'menu system' in Drupal denotes the whole topic of managing your URL space, not just the subset of 'visible' menus that is usually associated with the term)
Forms API - A declarative approach to web forms, with a well designed processing workflow and a whole lot of built in security features that you would otherwise have to take care of yourself. Also highly extensible, with straight options to adjust/extend already existing forms on demand, add new validation rules to any field or whole forms, multi step forms, javascript based form adjustments, etc.
Translation system - This is pretty complex, simply because internationalization is fricking hard to do. But it is built in, again giving clear guidance on how to do things in order to work in a generic way (though there are problems with quite some contributed modules that are not using/supporting it the way they should).
I could give more examples for parts where I appreciate the 'rules', but this post is getting long already, and I still have to cover some downsides ;)
So to sum up the positive part - if I where given the rough specs you posted, I'd say 'no problem' and go with Drupal, being confident that it would be a solid foundation for the custom parts, while providing all the 'standards' like forum, blogs, twitter/facebook integration and many, many others in the form of already existing solutions (even though those might need some adaption/tweaking).
Downsides: As always, there are flaws, and some of them are substantial, depending on requirements/circumstances.
Learning curve - Drupal is quite complex, and 'grokking' its concepts takes time. 'Playing with it for a week', as Palantir suggests, will certainly give you a general feeling/broad impression, but it is in no way enough to allow for a serious judgement of its pros and cons, as those will only surface while coding in/for it. So if you are already deeply familiar with an established web development framework, this might be an issue. If you have to learn one anyways, this should be less of a problem.
Database restrictions - As of Drupal 6, database support is MySQL or PostgreSQL only, using a Drupal specific 'abstraction layer' (which obviously isn't one ;)
Drupal 7 will move to PDO, which should (finally) end this questionable state.
Test/Stage/Production migrations - Parts of Drupals 'out of the box' flexibility are due to many things being configurable in the administrative backend, which implies that many important configuration settings are stored in the database. This makes migration of data and/or configuration between several instances pretty difficult/tedious, once you left the (early) stages of development where you can get away with complete dump/restore operations (see e.g. this question & answers)
These are the main ones for me, but you'll probably find more :)
I worked for over a year using drupal extensively, but I ended up abandoning it. Drupal, and other CMS systems out there, have very rigid limits and rules. I'd use Drupal for projects where you have simple requirements and few or no business rules. Drupal gets complicated almost immediately when you want to do complex things (especially pay attention at the menu system, forms, and the translation system if you need to be multilingual).
If your system will really be large, with all the things you mentioned, then I'd rather use a PHP framework to implement your business logic, and integrate external products as they fit (a forum, a blog, a twitter client, etc...).
But the advice is: don't trust anyone :) Download it, and play with it for a week. You'll be able to make your mind and be more confident about your choice!
As Drupal is open source, you can pretty much do as you wish with it. A couple of points though:
Changing Drupal's user/role structure would be tedious and unnecessary. You would need to have your desktop application authenticate from Drupal's MySQL database.
Drupal has hundreds of plugins for just about everything, so Drupal could no doubt run the whole "web" side of things including visitor stats etc. You would just need, again, to connect your desktop application to the correct MySQL tables and show the data as desired.
Don't forget to check other content management systems such as Joomla! (and many others). Each has its pros and cons. www.opensourcecms.com allows you to easily test CMSs and I've used it extensively in the past.
Just be sure to map out all the components first. Every hour planning up front saves many hours of headaches later.
Hi I am currently designing a website for a client - the site will be written in asp.net with a cms built in. My client has come back saying he wants to play mp4s on the site - plus being able to embed some other videos from youtube, vimeo etc.... in his blog - I have managed to convice my client that playing .flv would be better for obvious reasons (which he has agreed is OK). but when I went back to my coder, he said that because of the fact its a dynamic site that it will take 2 days to get this working (in terms of creating the mechanics to allow my client to up load his movies etc.....)
Is this correct - as my client is under the impression that it should be a simple thing to do - while my coder tells me that its not that simple.
I am in the middle of all of this - can you help please!!!!
At the end of the day only the coder you are using knows exactly how much effort is required here. You have to trust them. This almost certainly not trivial. Make sure you and the coder understand exactly what's being asked for here and that neither of you are assuming anything about how the client expects it to work.
Is your client a programmer? Non-programmers should never dictate how long a programming task should take.
If you're cowboy coding without testing "today" would probably suffice, but any sane and professional development shop would never let this happen.
Now let's clarify what your client really told you to do:
Your dev seems to be assuming that he has to support adding/uploading videos from your CMS.
If your dev is going to use a 3rd party API like YouTube, 2 sounds reasonable. If you're going to serve it on your own site, it'd take at least a week's worth of programming to make sure your site can take such a heavy load of streaming data -- it's stupid, not to mention highly irresponsible, to assume it could be worked out in a day.
Now, if you're client is only really talking about embedding videos in blog entries or articles, that's a very trivial task: YouTube, Vimeo and other video sharing sites already supply the HTML embed code that's needed to display a video on a page. In fact that's a zero effort task assuming that your blog entry editor properly parses the embed code, or has an Edit HTML feature.
So, which one is which?
This might be a good occasion to use the <video> tags. It might simplify things at the cost of only supporting users with recent browsers.
Two days is a quite optimistic estimate for all that you've mentioned. Maybe for embedding YouTube videos only, but for upload/storage/streaming of videos on the local server it's a different thing entirely.
But if you don't understand programming yourself, then you have to trust the expert that you've hired to do the job for you, and you have to tell the client that is how long it will take. The fact is that these things aren't trivial to write, there's the front end website management interface that needs creating, and the back end server software that manages what to do with the uploaded file. Never mind integration and making sure it's easy for the client to run a workflow of upload file, incorporate that video inside some content in the CMS, and so on.
I just recently did this, you need to get videoLan http://www.videolan.org/
This streams mostly anything, after you set up a streaming site it's easy!