PHP USE?

[elkrillin_88sau]

What is a good start to learn php?

 

I dont know none of html , xml or anything about website programming and design

 

What I have to know first ?

If anybody could give me some good references book to start reading?

[.josh]

if you don't even know html then I would suggest you start with learning html first.  And maybe css and javascript too, depending on what your overall goal is. 

[Viper69]

I would also suggest html and css, before you even think of Php I would also read up on all the accessibility issues on www.w3c.org.

 

Try to make small test pages and when you are feeling confident test your html code at http://validator.w3.org/ and your css at http://jigsaw.w3.org/css-validator/ then when you have the green light so to speak test your site for accessibility against http://wave.webaim.org/.

 

This should keep you busy for a while.

[tibberous]

Accessibility and validation are a waste of time. Just learn enough html to be able to make tables and forms - then worry about learning PHP.

 

Go through this and you'll be about as good as %25 of the people on elance:

 

http://www.webmonkey.com/2010/02/php_tutorial_for_beginners/

 

Biggest thing to learn about PHP is how you can make money with it. If you want to learn PHP, go find someone who wants something programmed and tell them you'll do it for %50 up front. After they paypal you the money, figure out how to do what they want. Now you are:

 

1) learning PHP

2) getting real-world experience

3) able to afford food, coffee and internet

4) maybe getting a reference - or even a repeat client!

 

I was getting paid to program at 15 years old, with a paypal account I had my mom make. I make $72,000 a year and my shit still doesn't validate. At the end of the day, <br> is worth just as much as <br /> , <br /> just takes longer

[Alex]

@tibberous: Pretty much everything you said is either extremely subjective, or just outright bad advice.

 

Biggest thing to learn about PHP is how you can make money with it

Only if that's their goal. Just because it was yours doesn't mean it's everyone's goal.

 

If you want to learn PHP, go find someone who wants something programmed and tell them you'll do it for %50 up front. After they paypal you the money, figure out how to do what they want.

That's a horrible recommendation. It's extremely unprofessional and asking for trouble. If you don't know how to do something you shouldn't be getting paid for it in the first place.

 

If you're only interested in making money, screwing over clients, being dishonest, and not interested in learning proper techniques and being professional, then maybe you should follow that advice.

[Pikachu2000]

I know that was meant to be sarcasm, but I worry that newbies would take it seriously . . .

[Philip]

I know that was meant to be sarcasm, but I worry that newbies would take it seriously . . .

 

+1

[tibberous]

I know that was meant to be sarcasm, but I worry that newbies would take it seriously . . .

 

Not sarcasm. We programmers need to worry more about making money and less about whether or not our code validates, or whether every img on the site has an alt tag, or whether something uses objects or functions.

 

How many roofers do you think spend years working for free and spend hours talking about the theoretically best way to roof? They go out, they get paid and they learn as they do it. It isn't about ripping people off, it's about getting paid for what you are doing. At some point you are going to take a project and get paid, and no matter how long you wait, you won't know everything when you do. You might as well start early.

[Philip]

How many roofers do you think spend years working for free and spend hours talking about the theoretically best way to roof? They go out, they get paid and they learn as they do it. It isn't about ripping people off, it's about getting paid for what you are doing. At some point you are going to take a project and get paid, and no matter how long you wait, you won't know everything when you do. You might as well start early.

 

While there is some truth to that, I really hope when I hire a roofer he doesn't do a half-assed job just to get paid. When I pay somebody, I expect the work to be done right and be high quality. It's the same with web development. When I get a job, I do it right, but I'm still getting paid. Sure it might take a few extra hours to bring it to a higher standard, but you know what... it's worth it. Even if the client doesn't give 2 shits if it validates or if it is the newest and latest coolest thing, I still know. It lets me be proud of my work, and makes me wanna keep doing what I do.

 

Oh, and as far as using objects/functions goes; using them for code re-usability is really to help you out and save you time, so honestly that IS something I'd worry about too.

 

Anyways, I wonder if your roof looks like this:

[xylex]

Go through this and you'll be about as good as %25 of the people on elance

 

....

 

I make $72,000 a year and my shit still doesn't validate. At the end of the day, <br> is worth just as much as <br /> , <br /> just takes longer

 

IBM's often attributed with a claim that a great programmer has 10x the productivity of an average programmer.  Joel Spolsky has an awesome blog entry entitled "Hitting the High Notes" also about the really good programmers vs the average programmers. 

 

I'm assuming you're U.S. based, which means you're below average for a software engineer's salary, which would seem to line up well with your ideologies.  Learning on the job is one thing, but how much can you really learn with an attitude of hack away until it works so the check clears? 

 

I'm sure that a lot of people here are willing to put in the time and effort to learn what it takes to make it to the top of the developer skill curve, which requires a lot more work and patience than what you're suggesting.  Not to mention the disservice you're doing to the industry with the trainwrecks of hack code you're leaving behind for us to clean up as you bounce from client to client or job to job.

[tibberous]

LOL - love the pic.

 

I just think the problem come down to programmers, especially new programmers:

- 'learning' for way to long, without getting real-world experience. You learn a lot of stuff with big projects, like how to organize code and move data around. Tutorials only do so much.

- not realizing the difference between 'theoretically' better and 'actually' better. Your image would be 'theoretically' better if you had an alt tag. 'Theoretically' I could be blind and using a screen reader, or on Lynx. That doesn't mean I'm saying to half-ass everything. Security is VERY important, error handling and input validation are VERY important (maybe not so much for the admin area)

- not worrying about money! If you want to program for a job, you have to get shit done and get paid for it. I know so many freelancers that #$%^ themselves every project because they underbid it, then spend forever worrying about crap like validation and adding support for users without ajax. Ajax won't even be a requirement! They'll add it because it is cool.

 

Being able to rationally decide what is and isn't worth the time it takes to do it is one of the hardest things in programming. You won't learn it in college, and some people never learn it. I learned it because I've had 6 projects on my plate, and no money - and realized that if I charged a little more, I could get the same amount of money and only have 4 projects, and if I didn't worry about all of the 'best-practices' crap, I could actually get those 4 projects finished, and my clients would actually be happier, because they got their project done faster.

 

[Philip]

- 'learning' for way to long, without getting real-world experience. You learn a lot of stuff with big projects, like how to organize code and move data around. Tutorials only do so much.

 

Sure, that's definitely a good point. I am a strong believer that people learning need to practice while they learn. On client projects? Depends on the person, but I'll typically have new team members try to do something then I'll look over it and give feedback. This takes more time, but I know they are more likely to do better on the next one.

 

- not realizing the difference between 'theoretically' better and 'actually' better. Your image would be 'theoretically' better if you had an alt tag. 'Theoretically' I could be blind and using a screen reader, or on Lynx. That doesn't mean I'm saying to half-ass everything. Security is VERY important, error handling and input validation are VERY important (maybe not so much for the admin area)

Currently I'm a design usability consultant, and mmmm this doesn't sit well with me. However, I'm not going to really bother with this point. It's becoming clear you do both backend and frontend for your clients... is that correct? If so, then yeah I can understand alt attributes being the highest priority. However, most projects I've worked on we've had a team for the backend, and a team for the frontend (design/html/css) who DID worry about it. But again, for a one person team... mmm I suppose.

 

- not worrying about money! If you want to program for a job, you have to get shit done and get paid for it. I know so many freelancers that #$%^ themselves every project because they underbid it, then spend forever worrying about crap like validation and adding support for users without ajax. Ajax won't even be a requirement! They'll add it because it is cool.

Yeah, I still do this on occasion, and then kick myself later for it (underbidding.) That just comes with time to learn how much one's time really is worth.

[tibberous]

I'm assuming you're U.S. based, which means you're below average for a software engineer's salary, which would seem to line up well with your ideologies.  Learning on the job is one thing, but how much can you really learn with an attitude of hack away until it works so the check clears? 

 

- I'm a PHP programmer, not a software engineer. For my area, I'm paid high-average. Maybe somewhere like Maryland you'll get a 100k as a PHP programmer, but it is pretty hard, esp. when your 24.

 

I'm sure that a lot of people here are willing to put in the time and effort to learn what it takes to make it to the top of the developer skill curve, which requires a lot more work and patience than what you're suggesting.  Not to mention the disservice you're doing to the industry with the trainwrecks of hack code you're leaving behind for us to clean up as you bounce from client to client or job to job.

 

- I've been with the same company for three years. We run about $600,000 through our sites, handle millions of visitors, and have never been hacked. I've never had to rewrite anything larger than a function. The code is awesome - it doesn't use objects, or validate, or run on the latest-and-greatest framework, but it is secure and easy to work with, and has a nice admin, and shows up perfectly on every browser, in HTML 4.1 transitional Time is a resource. It is stupid to say there is a right or wrong way to allocate it in every situation, especially while talking about being more productive.

[KevinM1]

- not realizing the difference between 'theoretically' better and 'actually' better. Your image would be 'theoretically' better if you had an alt tag. 'Theoretically' I could be blind and using a screen reader, or on Lynx. That doesn't mean I'm saying to half-ass everything. Security is VERY important, error handling and input validation are VERY important (maybe not so much for the admin area)

Currently I'm a design usability consultant, and mmmm this doesn't sit well with me.

 

As a disabled developer, I concur.  There's no real good reason not to make your sites as accessible as possible.  Those considerations should be included in the estimates/allotted time for the project.

[isedeasy]

Judging by your site you should really brush up on your html/css, even if you only deal with back end stuff it's quite shocking...

[.josh]

There is no such thing as learning everything and then going from there.  Technology changes and grows. "Best Practices" in turn change.  To expect anybody to come to the table 100% knowledgeable about a subject is both foolish and unrealistic.  If you are not learning something new every day while working, then you are not growing, you are not leveling up. 

 

Every project is a potential learning experience. However, that doesn't mean that you can or should come to the table empty handed.  As an example... part of my job is implementing tracking code for clients. Mostly we use Yahoo Web Analytics or Omniture Site Catalyst.  However, we also have used others like Google Analytics and WebTrends.  But there are countless other tracking tools out there. 

 

Nobody expects me to magically know all of the tools out there.  But they do expect me to understand Web Analytics in general, and they do expect me to understand the core technologies behind implementing it (such as javascript - most have their own "frameworks" and namespaces and methods for doing stuff, but it mostly all boils down to javascript). 

 

So if we get a new project that involves some new tracking tool, nobody expects me to automatically know that tracking tool.  But they do expect me to understand how tracking works in general (according to current industry standards and philosophies) and the core technologies (like the programming language(s)) behind it, so that I can quickly pick up a user/implementation manual and figure out how to implement it. 

 

I have countless stories of clients who have a hard time getting tracking code implemented according to specification, because they don't even understand basic javascript syntax.  Or maybe they do, but they fail to understand the logic behind the code.  Or the logic behind their own site's "flow".  Starting a project without understanding these things practically guarantees at best, a lot of unnecessary extra work and headache, but many times, winds up in failure, with people more or less trying to just kinda shove the project  under the rug and forget about it. 

 

This is just an example based on my own job, but applies to any web dev job you do - or any job at all, really.  The point I'm trying to make is that it is okay to take on projects where you need to figure out the problem and figure out how to solve it.  That's part of what you are being paid to do - solve a problem.  It's like detective work.  Detectives don't take on new murder cases automatically knowing who the murderer was, the motive, weapon, etc...they ask questions, look for clues, piece together the puzzle.  This if FINE. 

 

But what is NOT fine is taking on a project where you don't even know the basic tools required.  You would never ask an artist to paint you a picture if he's never had experience or has no knowledge of how to paint.  He may be great at charcoal or pencils but that's not the same as painting.  Or with the detective.  If I were looking to hire a detective and I was talking to him and he didn't know anything about fingerprinting or forensics or even what a magnifying glass is (tribute to Sherlock Holmes ), I'd be running out the door as quick as possible to find someone else.

 

Tibberous, that is the general attitude you are conveying, or at least, the general attitude that people are perceiving from you - that you are taking on projects even though you don't even know the basic tools and core technologies required. 

 

And you also seem to be giving the message of "I'm charging sports car prices for pintos."  In general, I do agree with you about the idea of giving something to a client that just works.  In my experience, most clients are clueless about what it takes to make something "work." All they care about is that it does what it is supposed to be doing as far as what they need it for. 

 

Example: Client needs a "contact us" form.  They want a user to be able to enter in their email address and leave a message, have it sent to or integrated with their own email system or some other system like SalesForce.  They don't know or don't care about the details, and that's why they hired you. 

 

So you have a choice: You can spend 10 minutes throwing up a form with no validation, crappy html that doesn't validate and styling looks fucked in some browsers, not even doing the finer things like spending time trying to figure out the client's target audience, the major browsers they use, the demographics, etc... (for instance, you probably do not want to be designing some new age flashy site if the client's target users are old people...), IOW, give them something cheap that gets the job done...

 

...Or you can take the extra time and effort and give them something of high quality.  Take the time to adhere to current best practices.  Take the time to integrate it with whatever system they use instead of saying "I can dump the info at some email address and that's it".  Take the time to get to know their target audience before designing the form/page.  Etc... 

 

There is nothing wrong with doing it the first way, as long as you are advertising and selling it as such, instead of trying to make out like it is the 2nd.  Because trying to sell a pinto as if it were a sports car is not ethical.  It hurts other web devs who have to maintain or touch the code later for whatever reason.  It hurts yourself because you lying about a product and eventually it will catch up to you.  It hurts the client because you are ripping them off.  It doesn't matter that they don't know either way, doesn't matter that they don't know anything about html validation etc....  That doesn't make it right.  They hired YOU because YOU are supposed to know and steer them in the right direction.  They hired YOU because they trust you know what to do and you're going to do it. 

 

If you want to tell the customer "Look, you don't *need* xyz so if you want a 'base model' something quick and dirty that works, I'll bust it out, charge you this much..." and then offer the better model as an upsell...that's FINE.  As long as you are very clear to the customer about what they are getting, this is FINE.  But don't try to sell customers pintos with sports car labels on them and use "they don't know what's under the hood anyways" as an excuse.  That's shady and a good way to have black balls thrown at you. 

 

If that is not what you do...then I suggest you try hard to re-explain yourself, because these are the impressions you are conveying in your posts.

[tibberous]

@Crayon Violent

 

I'm not saying to make shitty websites. Our login area has brute-force protection / logging. All of the page includes have direct-access protection. Any form that adds a record uses a key - so you can't create multiple records by refreshing the page. The credit cards are stored in a different database that can't be accessed by the main sql user - so if someone got a hold of our sql backups, or was able to run sql querys, the card numbers would be safe. EVERYTHING is validated. Even OUR admin is protected against SQL injections. I spent a crazy amount of time making it perfect -- but that's because I own part of the company, and am on salary.

 

What I'm saying is not to go nuts worrying about 'best practices', or paradigms, or validation. The only people who know whether the code is good or bad are developers. If you like tables for layout, use tables! If you like functions more than objects, use functions!

 

But more than anything, decide what is appropriate for the project you are working on. If I was in the market for a site, I'd be worried about how it looked, if it worked and how much it cost; and you'll find most clients are the same way. The plumber down the road doesn't need xhtml strict (hell, do it in tables, so when the 70 year old woman down the road pulls it up on her Web TV, it won't look all chopped up )

[tibberous]

But what is NOT fine is taking on a project where you don't even know the basic tools required

 

Between Google and forums, anyone should be able to figure out small projects. The big issue though is security - it's one thing to piss with something until it works, it's another to make sure it can't be hacked.

[.josh]

You think the end-all-be-all is whether or not your code gets hacked?  First and foremost, how do you think hacks happen? They happen because people make shitty code with no foresight to the future.  And even then, preventing your code from being hacked is not the end-all-be-all.  I can provide static sparsely marked up html and pawn it off as state-of-the-art hack-proof code, but that doesn't equate it to being the piece of shit that it is, hardly useful for anything, not scalable, not expandable.

 

You are an amateur.

 

What you are condoning is the same principle as going to someone still in dentist school to get your teeth worked on.  He doesn't know what he's doing and he's learning.  Would you go and pay to have your teeth fixed by him?  Or how about someone still in school to be a heart surgeon.  Would you pay, would you trust someone to do open heart surgery on you, going along reading from book as he's slicing you?  Or how about offering to drive someone somewhere, be their taxi when you don't know how to drive, saying you'll figure it out as you go? 

 

Between Google and forums, anyone should be able to figure out small projects. The big issue though is security - it's one thing to piss with something until it works, it's another to make sure it can't be hacked.

 

You are an amateur, and I feel sorry for the clients you swindle.  Would you tell that to your client?  "Hey yeah, I have no idea how to do what you want, but I'm sure with some googling and begging for help off some free forums I can sort it out for you...now about my payment..." Would you tell that to your client? Didn't think so.  You are worse than amateur.  You're a cheat, a swindler, a used car salesman at a tote-the-note lot.  I feel dirty just posting in this thread, must go watch copious amounts of gay sheep porn just to feel cleaner, you're that filthy.

 

 

[requinix]

I feel dirty just posting in this thread, must go watch copious amounts of gay sheep porn just to feel cleaner, you're that filthy.

There's a comparison between him and gay sheep? Hey now: that's offensive. To the sheep.

[Philip]

I feel dirty just posting in this thread, must go watch copious amounts of gay sheep porn just to feel cleaner, you're that filthy.

There's a comparison between him and gay sheep? Hey now: that's offensive. To the sheep.

 

Actually, that's a pretty common thing for CV to watch, so I think it might actually be a compliment... o.O

[tibberous]

PHP isn't open heart surgery. No one dies if a website doesn't validate. I'm not saying to take $5,000 down on an auction site, but there are tons of little $50-500 dollar jobs floating around that anyone could do with a few days of research. In the beginning, all anyone does is Google, get a book or ask on forums - there isn't anything wrong with getting paid to work. Worst case, you bite off a little too much - you bust ass for a few extra days, end up making $3/hr, and get a lot better at PHP!

 

Did you even read the post I made above that one? I've been programming for 11 years, so your 'amateur' insult falls a little flat.

 

The reason I said security is the biggest problem for on-the-job learning is because it is the one thing that a new programmer won't know to lookout for. If someone says they want a contact form, it's easy to write one and test it to make sure it works. Security problems present themselves later - if the developer and client don't know anything about security, no one will know there is a problem until the site gets hacked.

 

I would love to know what everyone here has accomplished that puts them in a position to insult me - doesn't seem like anyone here is very profit focused.

[.josh]

I would love to know what everyone here has accomplished that puts them in a position to insult me - doesn't seem like anyone here is very profit focused.

 

But that's the point: you are profit focused, not code focused.  Like watching your favorite band going from producing art to starting to suck because they sold out, started focusing on making a buck instead of art. 

[xylex]

The credit cards are stored in a different database that can't be accessed by the main sql user - so if someone got a hold of our sql backups, or was able to run sql querys, the card numbers would be safe.

 

Sounds like you're way below the minimum PCI standards that are required to be storing credit card numbers, like being strong encrypted, stored on a separate server, firewalled from your public server, lockbox storage of your decryption key etc.  The PCI standards that were written by people who are far more accomplished than you, and the standards that you'd know about and the reasons they were there if you "wasted your time" learning about security theory and best practices and took the time to implement them. 

 

As numerous people have pointed out, security isn't the only thing that goes into what make good software, but if that's what you're so focused on, it sounds like you don't even have the right intrusion detection pieces in place to know even if you're being hacked right now. 

 

Knowing and understand practices like this is why taking the time to learn the fundamentals and best practices and almost always following them is what separates the average and below average programmers from the really good ones.  Which is why all these well respected forum members are encourage someone like the OP, who's asking how to learn to PHP, to take baby steps through the basics to build a strong base is the best approach.  It's also why they are so discouraging of your approach of constantly diving in over your head and hacking away, an approach that will never make you better than mediocre.

[shlumph]

Accessibility and validation are a waste of time.

Absolutely not. A website should be accessible from all of the modern web browsers; including mobile browsers. Many companies even provide a different skin just for mobile browsers. It's very important that a web developer/designer can program accessible websites.

 

From a developer standpoint, data integrity is one of the most important concepts. Therefor data validation is absolutely necessary. If you're talking about client side validation (JS), then that isn't completely necessary, but it's something every modern website should have for user friendliness.

 

Just learn enough html to be able to make tables and forms - then worry about learning PHP.

Yeah, it wouldn't hurt to start dipping in PHP after being able to create forms. However learning how to design tableless layouts and controlling CSS are also important.

 

Go through this and you'll be about as good as %25 of the people on elance:

 

http://www.webmonkey.com/2010/02/php_tutorial_for_beginners/

Unfortunately.

 

Biggest thing to learn about PHP is how you can make money with it.

What about application design, and knowing how to build scalable websites? Or is that included in "making money with it" since they are two highly desirable skills?

 

If you want to learn PHP, go find someone who wants something programmed and tell them you'll do it for %50 up front. After they paypal you the money, figure out how to do what they want.

Beginners should probably know how to do what the client wants. After gaining experience, the developer should be comfortable knowing what they are capable of, and figuring out how to do some things down the road is inevitable.

 

I was getting paid to program at 15 years old, with a paypal account I had my mom make.

Great

 

I make $72,000 a year and my shit still doesn't validate.

I sure hope you're not talking about form/data validation.