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!
Related
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
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.
I have been planning a little side project of mine for a while now. Since the beginning I had planed on writing a CRUD application from scratch myself. Now after having a little more experience with web programming I think I would save myself a ton of time by using a CMS but being unfamiliar with these systems I do not know if I can do what I need to.
Users will create a profile.
Users will upload images.
Some users will be selling their products, others will be buying them. I will take a percentage. Think ebay without bidding.
Many javascript and php features such as image rotators and an app so users can crop their photos.
Will be integrating Facebook API.
Main reason I am considering a CMS is not to save time, but to make a safer website. I am not experienced with eCommerce and do not want to put my users at risk. Everything else mentioned I can and have done.
Use CMS like Drupal or just start from scratch?
Most of the CMS have the basic functionality you've mentioned in 1,2 and 5.
You'll have to write your own extensions for 3 and 4, or search for existing one that fits you.
Writing an extension for CMS will take less time than writing entire CMS from scratch.
If you want safe and stable code, then it's better to use existing CMS.
I agree with w3b4 that an open source CMS will save you time and give you major security and support advantages.
My experience of open source CMSs only extends to WordPress. I am sure you could make it do all the things you want with a bit of work, but my gut feel is that it might not be the best platform to start out with if you main requirement is buying and selling.
However before you strike it off your list, check out the wp-ecommerce plugin and its various add-ons. This product has developed a lot in recent years and might offer what you need out of the box.
I need to develop a newspaper site in Drupal, I've already played around with Drupal a little, and I think I know which modules would best suit my purposes. Naturally, one of the modules I'll be needing to use most is Views, but I have a couple of questions:
Because this is a content-intensive site, I was wondering if using 5-6 views on each page to generate node teaser + thumbnail lists would impact performance adversely?
I am a designer with significant front-end development experience. Like I said I've played around with Drupal quite a bit and other than running into a few hurdles which I eventually overcame, for the most part I was able to get it to do what I needed it to. Having said that, does one also need strong programming skills to fully develop a site in Drupal?
Thank you very much for your help!
Jane
Views offers caching and Drupal also has block caching, which should help you improve performance. The SQL that Views generates is never as good as handwritten SQL, but if you make simple Views, the SQL is actually quite good and not a performance problem (unless you have millions of page views).
If you can create the features you need, with modules from Drupal.org, you don't need strong developer skills. But you do need to know some PHP to make a Drupal theme which is what controls the layout of the site. It will also be a great help, in understanding the Drupal theming system, but not a requirement.
First off, check out openpublishapp.com for a Drupal distro that is made for publishers from the ground up, it's pretty hot.
To answer your questions:
1) As far as performance and views goes, having 5-6 views on a page is a normal requirement for a drupal news site and the performance issues are usually handled by views/panel cache, and using a page cache like Varnish in front of a web server, Object caches like Memcached (for the DB) and opcode caches like APC...if you don't want to learn all that off the bat you should still be fine if your traffic isn't too intense (but go sign up at getpantheon.com for awesome hosting with all of that and the kitchen sink, and check out groups.drupal.org/pantheon)
2) If the functionality exists by way of core/contrib modules, to fully develop a site for the most part one only needs to understand enough PHP to theme, and often with starter themes like Fusion, and some of the others you hardly even need that, just an understanding of how they work and are extended (which is well documented). That said, if you want functionality that doesn't exist, you'll have to code it, or have someone code it for which strong programming skills are desired, but not necessarily required :)
Even I recommend the use of the OPENPUBLISH - https://www.acquia.com/solutions/publishing
On top of to this you can make an efficient usage of
1. APC - PHP byte-code caching
2. Drupal Caching - block/template/view level caching
3. Boost - Caching module which doesn’t need any external tools
4. Varnish - HTTP accelerator
5. Memcache - Data intensive content.
Apart from this you will also need to think effectively on deciding on DEPLOYMENT ARCHITECTURE of the site - preferably Acquia or Amazon environment.
Learning curve may vary depending on your current skills in PHP or Drupal. Usage of already established distribution like OPENPUBLISH may help you to minimize the dependability on too much custom coding.
I am considering creating a website with the complexity of Facebook that should be able to scale into the millions of users. My question is: Is there any reason not to use Adobe Flex for such large project apart from the obvious point of requiring everyone to have Flash installed and not having to rely on Adobe? In my view Adobe Flex would reduce the server load for Facebook, because more of the work could me done on the client side. Do you agree?
Of course Facebook could have been implemented in Flash. But then the question is would it have succeeded? There are reasons big web companies like Google, Facebook and Yahoo only use Flash as sparingly as possible.
The thing I would fear most is alienating users. The Flash plugin isn't the best piece of software out there. It is slow and likely to crash once in a while. If your app gets bigger you might get some loading times that might not be acceptable to your users. Also in my opinion full Flash sites just don't feel right because they behave differently from HTML websites. All great websites like Google, Flickr, Stackoverflow or Facebook feel very light and slick which is very elegant makes up for great usability.
And then HTML and JavaScript are a lot more flexible. Do you want your website to be available on smartphonse? The iPhone has no Flash and even with phones that do you have the problem that users will very likely hate a full Flash site since those phones don't necessarily scale Flash as nicely as they scale HTML and Flash draws battery like crazy. If someone comes up with another revolution like smartphones you can be sure it supports HTML and JavaScript but you can't be so sure about Flash.
Then the question is how would you gain any efficiency? Of course you can write your UI with Flex and just call very lightweight webservices like you would use them for AJAX and you can even cache some of the content of the site locally so that you don't transmit more data as necessary for user interaction (the UI is transmitted only once). But you can also do that with JavaScript. You can write your UI in HTML and JavaScript, load it once and then just pull the naked JSON data from the servers and render it using JavaScript. You can also fetch lots of this data in advance to get the number of requests down. But still such an approach has its cons. Did you ever notice that when you type an answer on stackoverflow and someone else submits an answer you get notified while typing your answer. Such real time features are very cool and you might want this at some point in time which means more server interaction.
But whatever you do your servers still have to scale if your site grows. Even if you minimize the number of GET requests that hit your servers they will still grow a lot when your site gets popular and you will need a lot of servers to handle you will just improve your users/servers ratio.
The most interesting point though is that Flex is much easier to program than AJAX (think about browser incompatibilities for instance) and still AJAX was not only invented but the whole world messes with all those problems that come with it instead of using Flex. I think this tells a lot about of the value of the result you get when creating a full website in Flash.
Go to facebook and do view source...do you see all that JavaScript? That all runs client side
Johannes is right to point out the difference for server vs. client. The server side stuff is what needs to scale.
As an example, the Microsoft Silverlight team has assembled a facebook client app in silverlight (using the Facebook public API). My point is, using todays technologies, it is entirely possible to write a web application targeting many different kinds of client technologies: classic web browsers (HTML/javascript), 'rich internet applications' (flex, silverlight), ...
See also the myriad of Twitter clients out there.
The company I work for has a large app in Flash that is used by Governments. It is very hard to maintain and does fail sometimes. The problem is all of the .fla and .as files that have to be altered just to make a small change. Yes, the app could have been built better but even so, it is still harder to maintain than an HTML/JavaScript front end.
While I love writing Flash/Flex apps, I believe they should complement a site and not be the site.
Using a good JavaScript framework like jQuery takes the Browser compatibility question out of the picture (for the most part) and allows a lot of functionality.
Flex is the GUI for the client. You still need server-side storage and that's what has to scale. The user interface could be in Flex, while most of your users won't like such interfaces.
You will have to do a custom version of your site for the iPad/iPhone.
There are other ways of moving load to the client side. Javascript will give you porting headaches, but less than moving away from the entire architecture like Flex.
OTOH when you get a million users you'll have the resources to reimplement your site.
I don't think you would see a performance advantage with a site like Facebook, because the content is highly dynamic, comes from many different places, and is created by many independent entities. Flash (and therefore Flex) is better for monolithic apps from a single source that don't need to change very often.
The default in Flash is to build everything into a single .swf file that holds everything. It is possible to break out of this default behavior, of course. You can make web service calls, pull in external components via the SWC mechanism, load static content via HTTP, etc. Nevertheless, it's not the default pattern, which affects how Flash development libraries and tools work. Besides, the more of this you do, the less of the "run everything we possibly can on the client side" benefit you get. It gets soaked up in HTTP connection overhead.
The default on the plain old standards-based web is to store all assets separately and assemble them dynamically at the client. This is one reason the web is slow -- again, all that HTTP connection overhead -- but also why it is flexible and dynamic. It mates well with a site like Facebook which requires constant evolution by a lot of independent developers.
I say this having developed a Flex app, which I am happy with. Only one person -- me -- has to maintain it, and it's naturally a monolithic app. It plays right into Flex's strengths.