Tag Info

Hot answers tagged

56

Speaking from experience: The downside is that you rely on the Rails framework a bit too much. This is a great and wonderful thing if you are only ever writing simple, greenfield CRUD apps that fall squarely into the Rails "sweet spot"; your productivity will skyrocket. However, the moment you have to do something outside that sweet spot - interact with an ...


40

Background Web development is all about communication. In this case, communication between 2 parties, over the HTTP protocol: The Server - This party is responsible for serving pages. The Client - This party requests pages from the Server, and displays them to the user. On most cases, the client is a web browser. The User - The user uses the Client in ...


30

For your first server-side language, I feel like there can be a couple problems with RoR: You're not just learning a language, you're learning a framework. I would definitely take some time to play around with plain old ruby before jumping into rails. Since it is a framework, and an 'opinionated' one at that, I feel like it would give you a very limited ...


14

I've tried to learn RoR several times and my biggest problem is always trying to get the packages to work correctly and the documentation. The problem with the documentation is that it always seems to be out of date (or very basic). I got the basics from the site but beyond that everything seemed so dated (even the book I bought and ended up returning). ...


14

There are two major issues. The first is easy--you usually don't know what sort of resources are available on the client side. If it requires 1.5GB to process something, can you really push that onto an unknown client browser (IE, Safari, Opera, Firefox, etc.) on an unknown client platform? Will the client appreciate his system dogging when you ...


13

Business logic almost always has to run on a server you control, for security reasons. If by "server" you mean "web server", then I agree, it doesn't need to have almost any business logic. But you almost always need an application server with the business logic, whether that's inside a database or a web server or is separate and called by the web server. ...


13

Back in the 'early days' of the web, people hacked web servers using non-standard APIs in whatever language they had handy. Back then, the NCSA HTTPd was the defacto standard, so you mostly used C, I believe. Certainly, each HTTP server product had it's own C API (Netscape had NSAPI, Microsoft ISAPI, etc). To alleviate this, in 1993 the CGI standard (Common ...


12

If this is your first server-side language, it's as good as any. The thing to do is focus on one, and after you feel you've mastered it, explore others and deduce your own conclusions. I work with RoR and ASP.NET on a daily basis, but strangely enough, I prefer the ASP.NET world, but that has more to do with personal philosophy than it has to do with the ...


12

Presumably the perceived benefit are: you only need to hire developers that know language x rather than x + y (this is probably not really a good idea though if they only know one language) it is easier to move developers between server and client development (this can be quite a good thing). i.e. it makes resource management easier for project ...


11

In layman's words: Here I will talk only about web programming. Client side programming has mostly to do with the user interface, with which the user interacts. In web developing it's the browser, in the user's machine, that runs this code, and is mainly done in javascript, flash, etc. This code must run in a variety of browsers. Its main tasks are: ...


10

Your understanding is correct, if you're from the past. You're pretty much describe as it looked like in 1990s. Yes, many languages can be executed directly by a web server plugin. Right on for PHP, mod_php for Apache is still the most popular way to host it. However, high-traffic sites use more modern approach, using web server only as a proxy for FastCGI ...


9

The big reason why css is seldom generated dynamically (this is also true for javascript) is because they are good candidates for caching. CSS is a very flexible way to style your pages, with the right combination of classes, you can get all of the different parts of all of your different pages styled according to all sorts of cues all Without having to ...


9

What's wrong with plain old garden variety FTP (File Transfer Protocol), or even TFTP (Trivial File Transfer Protocol)? Granted, they're older than your father's memory of his first kiss, but they still work. Now, both FTP and TFTP want the file to be on the server before they serve it to download clients. If what you want is to stream the file from A ...


9

This is a fairly common problem with asynchronous transactions, and falls into several parts. How do both sides know that the transaction request has been successfully received? How do you resend a transaction request that the client believes has not been received properly? How does the server detect repeat requests from the client when the server ...


8

A couple of advantages: Each process has a separate address space. If you run on a 32-bit OS, that can be an advantage because you can load up the server with lots of RAM and even though each process can only access 4GB each, if you've got multiple processes, then they can use up however much RAM you have available. If you're writing for 64-bit (and I ...


8

Assume a worst case scenario. Examine your logs, figure out everything they might have gotten access to, and assume they took a copy of all of it.


8

I consider myself a "server side" developer. Despite being on the "back side" of web development, I think it's extremely helpful to know HTML and CSS fundamentals. I work on typical "web content management systems" (WCMS), such as Drupal, Day CQ, and Liferay, and most business requirements and requests revolve around changing the look and the feel. ...


8

A few possible reasons: The JavaScript library for this already existed, so it required little development time to deploy, as no major changes were required in their code base. It saves processing time on the server from not having to generate the images. It saves bandwidth, as the LaTeX code is much more compact than the rendered images. It avoids ...


8

It's particularly strong at handling a ton of file I/O and I would expect it to handle a ton of network communication well too. It seems particularly popular for socket-driven apps. The important thing to keep in mind is that if your needs aren't met by existing libraries (there are many) you may need to dive into some C which can be bound to JS commands. ...


7

Generally speaking, the language doesn't have a concept of multiple servers. It works in isolation on its server. The fact there are multiple instances is not generally considered at the language level. It is a bit like checkout staff in a super market, they each do their job. They don't need to consider if there are other staff or interact with them. The ...


7

From top of my head: Use of webservices instead of direct access to DB from client. REST instead of SOAP. SOAP seems to be too heavy-weight for mobile communication with backend. REST using JSON is much simpler to set up and consume. Especially if you use different technologies on client and server. Focus on multiple views for webpages. One for desktop and ...


6

As someone who learned Rails recently (as a hobby - never used it for commercial grade development) and had already worked in JEE and ASP.NET, Wayne M's answer rang very true. Anyway, there is a subtle side to this which noone has mentioned yet, but which bothered me a bit with Rails - the strong reliance on convention over configuration. Essentially, if ...


6

I believe your assumption is wrong: in my last project, the application was using server-generated CSS loaded by ajax (because, depending on the location of the map you were looking at, the page was branded with completely different styles). However, usage cases where retrieving extra CSS by ajax would solve the problem are quite rare, this may be why you ...


6

Actually, there are use cases for dynamic CSS. I've worked with three different kinds: Less — Less CSS is basically a CSS language extension that adds "dynamic behavior such as variables, mixins, operations and functions." It also allows "nested rules", which is very convenient. I have used Less mainly to make CSS writing less verbose by ...


6

Let me preface this by saying this is extremely generic and simplified view of what happens. Web server software (like Apache or IIS) does not interpret any code; it doesn't know how to. All it knows how to do is take a request, look it up in some location on the filesystem, and then send the item requested back to the browser. That's all it does - at a ...


6

Designing the client side first with mocking can give you a strong advantage in knowing your website's functionality. You can keep redesigning with minimal waste until you reach a good workflow for your product. However, you should keep a rough sketch of server side requirements for each bit of functionality you'll need from the design so that you don't ...


6

You didn't say which language you're using so I'm going to recommend Node.js, and an ORM for it: Node ORM, everything in node is async, this is no different.


6

Technologies RESTful API using JSON as serialization — Same API is used by native apps, hybrid apps and mobile web apps. Even in the former case client side templates are often used (see excellent example in "Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates") Lightweight, asynchronous (event driven) servers — no more ...


6

It doesn't really matter, neither stack is really better than the other especially at this level. Your best bet is to install whatever is most used in your university's server infrastructure, especially if this is something that is intended to be available and offered to students after you complete your class.



Only top voted, non community-wiki answers of a minimum length are eligible