ManWithComputer
The Internet, IP
Male, 37
I've worked at multiple Internet startups of different shapes, sizes and ambitions. Now I'm the CTO (Chief Technical Officer) of another small company with big dreams. I look nothing like the picture above.
If you copy and paste your homework question in here, I will answer with something that will, at best, get you an F on your project, and at worst, will get you kicked out of school. You have been warned.
Basically, because other people exist. Other people are either going to extend your code someday, or you'll be using code that other people wrote. And if you redefine "cout" or "fin," things will get as confused as if you redefined a common natural-language word like "dog" or "red."
This is actually a very perceptive question. In short, if your heart lies specifically in website programming, a programming degree is probably better.
Computer science, properly speaking, is the branch of mathematics that deals with the theoretical underpinnings of computation. Computer programming is a practical, not so much a theoretical, discipline: how do you get a computer to do what you want to do? You could say that computer science is to computer programming as physics is to mechanical engineering. As a mechanical engineer you'd better know some physics, but your interest is mostly going to be in practical applications.
One secret of web programming is that, from a theoretical point of view, it's really simple. A browser somewhere makes a request to your site; based on that, you get some data out of a database; and then you wrap the bits of information you got in some HTML and send it back. What makes it trickier is being able to do that tens or hundreds of thousands of times per second, 24 hours a day, on all sorts of different browsers. But the algorithmic aspects are largely well understood and already taken care of.
Do your own homework.
Generally you don't, but your question gives me an opportunity to explain a few interesting aspects of software engineering, so here we go anyway.
Engineers (software and otherwise) talk about the concept of "coupling." This means, roughly, "If I change Part A of this thing, how much if any do I have to change Parts B, C, D, et cetera?"
Good design usually calls for "loose coupling," which means that you can change one part mostly or totally independently of all other parts. In other words, Part A is a "black box" to Part B: Part B knows that it can get Part A to do something, but it doesn't have to know or care how Part A does that thing exactly, so you can replace Part A with something completely different, and as long as it continues to do the same task that Part A did, everyone's still happy with it.
When you see the opposite, "tight coupling," that means parts work together more closely, and it's a bigger pain to change one, because you have to change many others. Once in a while this is done for performance reasons, but usually it means that the design or implementation is bad.
So as programmers we like to make chunks of code that don't overlap, that only do one thing, and that offer certain services to other chunks of code ("expose an API") without actually committing ourselves to doing those services in a particular way. These high-level chunks of code are generically called "modules" although there are plenty of other terms too, for different contexts.
In particular, if you have an application with a complex UI, you would have one or more modules that did nothing but the UI: a module to put things in windows onscreen, to know what to do if someone clicks here or types there, and so on. But there would be more modules that handle things behind the scenes. Imagine for instance a mapping app where you could either type in an address, or say the address into the mic. These would be two separate modules, as piece of text in a window is a very different thing than a pattern of sounds, but the meaning of the address "123 Elm Street" is the same in both cases, so both of these UI modules would talk to one common module in the "backend," which means basically all the code that does something that the user doesn't see directly.
And this brings us, finally, to an answer of sorts to your question: if you can get your hands on the source code to the original application (which if the application is proprietary good luck with that), and if the UI is loosely coupled to the backend, and if you know how to program in whatever language the application is written in, then you replace the UI modules with modules appropriate to a phone or tablet.
The rest is just details. Thousands and thousands of details.
iPhone & iPad Technician
Is Apple is still the young and hip brand or have mom and dad spoiled it?SWAT Team Commander (Retired)
How do you decide whether to try and kill a hostage taker?Firefighter
What's the worst you've been burned in a fire?Not a clue, have never touched GameMaker.
I can't. The last time I drew a flowchart was...possibly never. They're not much used anymore.
You should only do this by IPs if the site is going to be used exclusively from their internal network. Otherwise, for a number of reasons, it's not a reliable technique.
If that's not the case, I'd see about implementing single-sign on with their site.
-OR-
Login with Facebook(max 20 characters - letters, numbers, and underscores only. Note that your username is private, and you have the option to choose an alias when asking questions or hosting a Q&A.)
(A valid e-mail address is required. Your e-mail will not be shared with anyone.)
(min 5 characters)
By checking this box, you acknowledge that you have read and agree to Jobstr.com’s Terms and Privacy Policy.
-OR-
Register with Facebook(Don't worry: you'll be able to choose an alias when asking questions or hosting a Q&A.)