Help me out!

Next steps

Hi, I've been developing web sites for around 14 years. IMO you need to learn about the following to move on:

1. Domain names and DNS
2. FTP Servers
3. Hosting Control Panels (DirectAdmin, CPanel, Plesk)
4. PHP and MySQL
5. Open source platforms including WordPress, Drupal (or my personal prefrence SilverStripe) and finally (after a while) Magento for ecommerce. If you learn how to build "themes" for these using HTML, etc. you will be able to build alot of powerful, feature rich sites for your clients.

Hope that gives you a starting point at least for things to google and read up on.

 

php and mysql. then you can move on to content management systems.

 

Good advice here, particularly #1 and #2. You'll eventually want to get at least a working knowledge of mySQL and php but that isn't an immediate concern.

It sounds like you've got most of the hard stuff figured out, you'll probably need to adjust some things once you start looking at crossbrowser issues but you're most of the way there. Good luck!

 

I would concentrate on a language and SQL. mySQL is a good place to start and is supported by most web hosting companies.

PHP is as good a language as any, lots of online references and is installed I believe on the Mac. If not, installing it is not hard.

DNS and domain names, not so sure about that. Unless you are thinking of diving deeper in to networking all you need to know is you need one (which I'm pretty sure you already know that) and that it has to be managed.

FTP? Depending on the software you are using FTP may not be too necessary but having a good FTP client cannot hurt. What you need to know here is in a lot of cases you may need to enable passive FTP to get around networking/connectivity issues. Other than that the web has a bunch of information when things go wrong.

How strong is your CSS knowledge? My recommendation is to get really familiar with CSS3.

Now for the $64K question and I'm surprised no one has talked about it yet. Well, there are several "its" here. One are class libraries for JavaScript. Then there is pattern/model development, such as Model/View Model/Controller aka MVC. Again, web searches will help there. One important thing to remember is to keep the code separate based on where it lives and what it does. The model (aka your HTML) should talk to your View Model (most likely JavaScript) and the View Model talks to the controller (most likely PHP). The View knows about the View Model but the View Model should not have direct links back to the View and the Controller should never communicate directly to the View.

Now PHP, with a lot of its power, can be embedded directly in to HTML code (give it a PHP extension and you're off) but that can cause all sorts of maintenance issues down the road. By keeping the the view logic separate and apart from the controller logic it will be easier to to replace backends should you need to. As long as the interfaces used in the MVC are documented and maintained changing say from mySQL to Microsoft SQL or Oracle SQL is a matter of writing a new controller which the same interface and plugging it in. Input and output should be consistent.

There is so much but that is how I would start.

Take care,

 

maybe i misunderstood you, but i have some issues with this description of MVC.

my understanding is that in an MVC setup:

1. the html is the view layer ( i prefer to handle views with a templating engine like smarty )

2. javascript is also part of the view since its focus is presentation

3. the controller is in php and is responsible for grabbing data from the model and passing it on to the view for rendering. this is also where the control flow goes.

4. the model is also in php in the form of classes. all the logic behind how data is processed and stored goes here. all your database stuff should go here as well.

in php when you make a request, the request goes to the appropriate controller (a php file), which gets all the data you need from the model (by including classes) and then passes that data ( via variables, arrays, objects ) to the view (via a templating engine) to be parsed into html. once all that work is done, the controller delivers the html page to the user's browser.

at least, this is my preferred way of developing in php. ive seen a lot of code that crams all this stuff into a single php file, which is a total nightmare if you're working on a project with even a small degree of complexity.

 

We are agreed that HTML is the view. We are also agreed that in this case PHP is the controller. Where we disagree is the view model.

Depending on how one writes the JavaScript it could be the view or it could be the view model. I prefer to write my JavaScript so it does not know directly about the view. Anything the view model needs is passed in as arguments to function calls.

Because PHP is parsed on the server it makes it harder for me to see it as a view model language.

The way we practice MVC at work is the view knows about the view model. The view model knows about the controller. The controller knows NOTHING about the view model or the view and the view model knows NOTHING about the view. All communication is done via properties or as arguments to a function up the chain and coming back down as results,strings, objects,etc.

At work we don't use PHP. We are in Flex (FlexBuilder and ActionScript) but it is very close to what I've described above.

I agree the code should be split along the lines of where it belongs. Yes there will also be some PHP processing statements in the view as it populates things. And there could also be some JavaScript. But coming at this from my perspective I would work to keep it pretty clean with only enough PHP to create tables or forms from data provided by the controller.

 

Your understanding of MVC is flawed. The model has nothing to do with presentation. It is, as Jamesbot said, the classes behind your PHP controllers.

The ten-second explanation:
The model is the business logic
The view is the part the users see
The controller connects models to views.

...

To the OP, if you're starting out, you might want to consider Python or Ruby instead of PHP. PHP has a bunch of problems, but it has a large amount of momentum in the form of existing sites / developers. One of the next-generation web languages are much better for learning "how" to program, and professionaly, it's definitely the direction the wind is starting to blow.

 

+1 for this

that said, in my opinion php 5 is a decent web language if used "correctly". but it takes time to get there, and once you do, its likely you'll want to move on to something more expressive ( and fun ).

 

to publish a website on the internet, you will need the following things:

1. a domain name ( provided by a registrar )
2. a dns record for you domain ( sometimes registrars also provide dns services, otherwise you will need to tell your registrar what nameservers to use )
3. a server with a static ip address ( either from a hosting provider, or something you set up yourself )

with hosting providers, the cheaper ones will give you a document root and an ftp account. usually they'll give you a database too. these are pretty easy to set up and they almost always have a guide.

if you want your own server (vm) you can use one of the many excellent cloud hosting providers out there ( i like linode.com ). they'll give you a server and a shell account and you can install whatever software you like. i prefer this approach, but there will be a steeper learning curve depending on your level of skill in working with linux.

Consider the following design topics:

Responsive & Adaptive Web Design
Working with twitter-bootstrap ( http://twitter.github.com/bootstrap/ )
Working with less ( http://lesscss.org )

Also if you're still working in textedit, may i suggest giving coda or textmate a try?

 

MVC is a way of thinking.

MVC is a design pattern but ultimately way of thinking.

@bpaluzzi I commend you for trying to explain MVC in 10 seconds but saying that the Model contains the business logic is incorrect. I had to register on this site just to help set the record straight.

The 5 second MVC Design Pattern definition is this:

The model stores your data.
The view reads your data.
The controller manipulates your data.

Technically speaking, your database would be your model.
The browser would be your view.
Your server controls would be your controller.

JavaScript CAN be either controller logic or view logic, depending on it's purpose.

A view CAN listen directly to changes in the model, if your code is architect-ed that way.

We good?

 

Sorry, but that's incorrect. While the data store is certainly something that would be contained in the model, that's due to the fact that persistent storage is PART of the business logic.

I'd advise you to read the Krasner and Pope SmallTalk/MVC doc, where it defines that model as "The model of an application is the domain-specific software simulation or implementation of the application's central structure."
http://www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf

 

there is no spoon

@bpaluzzi okay, I can understand what you're saying about persistant storage being "part" of business logic...but are you also saying that business logic includes both data and controller code? I thought business logic was referring to logic that manipulates data. Am I mistaken in this? What's the deals @bpaluzzi? I'm open to learning something new. School me oh wise one

 

MVC is a bit weird, because there are a bunch of ways to break it down -- they can all pretty much be reduced down to two main types: thin controller / fat model, and fat controller / thick model. The "thickness" of the controller determines how much logical code is in there:

in a thin controller schema, the controller tends to be very "functional", for example:
-handling requests from the view (via GET or POST, in a web application, for example) which are then converted into calls to the business logic layer in the model
-the "brains" behind view-specific functionality (for example, setting up meta data for a webpage)

in this type of a setup, all of the business logic is contained within your model classes - for example, you'd have a Widget class, with a "processOrder()" function. the view draws a button, which is clicked + initiates a POST back to the server. the controller interprets the POST request, creates your Widget object, and calls Widget->processOrder(). All of the logic for what "process order" is can be abstracted away within the model class -- the controller just acts as the wiring, without any specific domain knowledge.


In a "thick controller" setup, your model acts simply as the data store. It's the business logic in so far as the schema for the database determines the relationships present within your data -- a Blog contains many Posts, which each contain zero or many Articles, which are related to an Author, etc. The controller handles all of the manipulation of this data. This type of set-up generally works where the business logic is simple CRUD operations -- the HTTP request types map almost exactly to operations on your model (POST->UPDATE, GET->SELECT, etc.), so there's not much point to wire the view's request to a full class/object backend. The controller class can just pass that right along to the backend. A straightforward blog / CMS can be a great example where this type of pattern works well.

There is, of course, a whole degree of gray in between these extremes. Martin Fowler brings up the point that in a lot of cases, the separation between view and controller is unnecessary (this would be more for a fat model set-up, where you're fundamentally separating two big chunks: business logic and presentation logic). In a lot of cases, this is what you see in medium-sized PHP projects -- the controller logic lives in the actual PHP files being loaded via .htaccess, while the "view" is reduced to a template by something like Smarty or Zend.

MVC is such a nebulous term that you'd be hard pressed to find a "wrong" way to do it -- there are certainly anti-patterns out there, or ways that will make it more difficult, but in general, any logical treatment given to separation of concerns is going to help make your code better.

Back to your original point -- I was perhaps too harsh on calling it "incorrect" -- it's a valid way to set up an MVC project, but not the only way. It's an implementation, instead of the whole view of the theory.

Wow, this is REALLY scattershot and confusing, so sorry if I opened up more questions than answers here. I'm cooking dinner and waiting for my oven to pre-heat, so I banged out something quickly.

For some more references, the Krasner + Pope is fantastic -- that's the first rigorous academic treatment of the MVC framework that had been kicking around XEROX PARC since the 70s. "Patterns of Enterprise Application Architecture" by Fowler is also good.

 

thin vs thick

@bpaluzzi Didn't know that there were techniques where you'd have a thick model and thin controller. I was taught that the model is solely the data store, and whenever data changed, the model would broadcast a corresponding event.

You're saying that is one way but not the only way. Apparently I can store complex functions in the model, as well. This makes sense. It is simply a matter of location (whether to put these setter functions in the model, or the controller).

You're also saying that there are some practices where the abstracted controller class(es) are removed entirely, and that one can simply place setter functions within the view. So you're saying that one doesn't need 3 singletons, you can actually have 2?

Pretty cool if you ask me. Thanks for the break down. I'm' sure others will learn from this conversation, as I have.

 

Okay, I know what my issue was/is. I was describing MVVM that we use at the office which is stacked where MVVM stands for Model/View/View Model.

I would disagree about CSS being the only view item. CSS cannot do anything without HTML so I would consider HTML/CSS to be the view.

 

In general, unless you're _really_ good with HTML / CSS, I don't accept files from 3rd parties. This is fairly common with developers, as there are very few developers that can't do HTML/CSS now, and if you're a person that only knows HTML/CSS, without any back-end programming knowledge, you'll often structure your front-end in a way that is not conducive to "wiring it up".

If you're an absolute front-end rock-star, or if it's a HUGE project, then splitting it up can work, but even then it's difficult if the front-end guy doesn't know the basics of back-end work.

----------

Interesting. I've heard of MVVM before, but never seen it in place. Are you a .NET shop, by any chance?

Who said anything about CSS being the only view item?

 

You're definitely thinking in the right manner. I do have a couple of suggestions that you may want to consider before/while proceeding.

First, the business:

It is up to your clients to determine what is too costly for them, not you or any of us. You are a service provider. You should have in your financial calculations what the market value is of the services you provide. Where some clients would choke on a particular number, another client would pay double times 5. This takes a little experience and negotiation skills. None of us know your business plan. Maybe it would make sense to take a short-term hit for a long-term gain? Maybe not! When you're just starting it helps to be flexible but I always encourage people to never ever ever ever ever ever ever sell themselves short. You got bills just like everyone else. You know what the cost of living is for you (and so do your clients). So again, don't worry about if it's too costly for them. Just do it. If it's too costly for them, you may need to adjust at both ends: Find ways to be bring the costs down, and find more profitable clients.

Second, the product:

It sounds like you need a formal education in web programming. I'd suggest treehouse, lynda.com, code academy, or actual school (egads, I know! But that's what helped me!

You have familiarity with the web browser; however, you need to understand the role of the web server and database (the other 2/3rds of what makes the internet work). You get those down, then learn some IT project management skills, then you'll be able to effectively portion off pieces of your project to the appropriate service providers in a way that can be cost effective.

You're thinking is correct in involving others but you need to know how to effectively build an adhoc project team or you're going to blow your budget. I'd say that the most important thing in building web teams is having a fairly knowledgeable understanding of "all" pieces that are required. This is for 2 reasons.

1. You know what your team needs. This way, if a team member is unable to deliver, you know how to fix the situation, either by hiring out again or providing the remedy yourself in an efficient manner.

2. You can speak everyone's language, and therefore understand everyone's needs, and how to successfully connect one piece of the project to the other. In your case, static front-end skins, to server programming.

Hope this reply helps you in some way. Keep at it! Again, you're asking all the right questions.

 

At work we are a C# (for middle tier and back-end), Flex, ActionScript, ASP, ASP.Net, JavaScript, HTML, CSS, etc. shop.

At the house I am PHP, HTML, CSS, JavaScript. etc.

I thought it had been said in the thread, maybe not by you but by someone. Could be I just mis-read that. My apologies.

 

That makes sense -- I've only seen MVVM in discussions of the .NET stack. 95% of the open source stack work I've seen has been some form of MVC, with varying degrees of controller thickness.