I started coding recently, and this community has helped me a lot understanding many things which I was not aware of. However, many reputed coders instructed me of some patterns, the way I have to code and the way I shouldn't write codes. Although I accepted their suggestion with gratitude, there was many thing I couldn't understand.
I want your point of view to understand the few questions which has been running over my mind from the past few days.
MySQL
Why is it that many coders gave me thumbs down whenever I used the * in the select statement? Why did they suggest using entityname.tablename even if sometimes I want almost all the data from a table?
Is it okay if my code make a frequent trip to the database on a single page say about 5-8 request? To be more precise in a page I would want to update the value, insert the value, count the rows, sum up the values, and so on.
I once made almost all the select statement as a single query and one of the reputed user of this community suggested me not to do it that way instead suggested me to use a user defined function. (BTW, user defined function helped me a lot to clean my code and understand the error more quickly). What is your take on this?
Frameworks
When I started learning PHP I knew little about programming and more about web, although I had learned the popular computer languages like C, C++, .NET, Java etc. in my college. It was just the formal and theoretical subject which I learned and when I knew I wanted to be a web developer internet was my best friend and the community helped me out.
Now when I have started my journey of learning programming I have set some goals and aims myself, I want to be a Pro PHP Developer, I want to Master the HTML, JS, CSS, MySQL etc. My question here is
IS FRAMEWORK EVIL FOR LEARNERS LIKE ME?
MySQL
Using * is fine. When you start getting really complicated with MySQL queries - joining and comparing tables - then you want to look at using entityname.tablename just to keep yourself from getting confused.
The next question is too subjective. It depends on your server and the efficiency of your script. It also depends on how many people will be using the script. Obviously, as with anything, the less you use it the better. If you can do one sql query instead of 5 then do that, but if you're only going to have a couple of hundred people viewing your blog then I wouldn't worry too much. Its the same with functions. Obviously its much better to put everything into functions. This helps in the long run because you will only have to edit your script in one place to make changes. Lets put it this way - if you're copying and pasting code then you should be using functions. But then if your script is only 1 file, 200 lines long, then I wouldn't worry if you don't want to.
Frameworks
Frameworks are difficult to gauge the usefulness of. Obviously learning things like Zend or Mage are powerful frameworks that will help you to create much more efficient and complex web projects. However, for learners it may confuse you. I would say definitely not to try and learn them until you get your head completely around PHP. Hopefully then you will have a great enough understanding that you won't have a problem if you come across these. You miss the main point of a language if you learn a framework. For instance - you won't learn javascript if you just learn jquery. You'll learn a bit, but you'll never completely understand it.
Thats my take, but its a very subjective question.
Decent arguments to dislike select all in SQL: http://www.joelango.com/2007/04/30/why-you-should-never-use-select-star/
About number of queries: this is an issue of performance. The rule of thumb is to optimize when performance actually becomes a problem. If you are running a site that serves thousands of requests a minute you may need to start worrying. Otherwise, it just doesn't make a difference.
About frameworks: if you want to learn PHP at its foundation then avoid frameworks for now. Otherwise, if you really want to jump in and get things done, starting with a framework should be fine. For example, I don't know JavaScript itself but I work fine with JQuery (a JavaScript library/framework).
like Thomas Clayson says the use of * is fine for simple queries, but when you have complex join statements you should specify the fields and give the tables a name (like someTable as a) and use a.someField in order to organize your query.
When it comes to learning a specific language, frameworks are just tools to help developers get the job done in less time (including maintance, worst thing ever jaja) but if you are a starter what you really should look is to learn is what programming paradigm does the language support (object orientation, procedual or functional) and focus or learning those paradigm and the specific commands of the language because for example if you preffer object orientation class will always be class, function and procedures will always have the same squelet but the implementation differs in each language so if you learn the paradigm it will be easy to learn any language.
That my humble opinion hope will help, regards
While I agree with Thomas re: frameworks, I have to disagree, or at least expand, on what he says about MySQL.
While there is technically nothing wrong, in most cases, for using * in SELECT requests, expanding the column names makes the statement easier to understand and more self-documenting for other developers that might be in your code. They can look at the query and see what properties the row object should have. Aside from that, * is also slightly less efficient during the query. It's really nothing to worry about unless you only need a fraction of the columns available.
As for the multiple queries, it depends. If running 10 SELECT for specific items is faster than running 1 SELECT for multiple items and parsing them out, then run the 10 SELECTs. It's far better to run multiple small and fast queries than one large and slow query. Obviously, each application will be different.
On using * in a SELECT statement: While it is perfectly valid syntax, it is often recommended against for two reasons. One, speed; two: code quality. With *, it is not evident which rows you are requesting (and getting) and in which order; if the database is ALTERed and rows are added, you are getting these as well, and if the order of rows is changed, the results will be quite unexpected.
If you specify the rows you want, that results in safer and faster code.
That being said, you can still use * for convenience and some testing.
But for production code, please consider specifying the rows.
Making separate DB calls with SQL statements will slow down the processing a lot, since every one of these has to be sent, received, compiled and interpreted, results sent back - just to receive them again in another call.
stored procedures (or "user defined functions") are more efficient, and also much safer against attacks like injection. If you can make them without sacrificing flexibility or other aspects you need, do so.
But don't do that while you're still finding your way - Premature optimization is the root of all evil, says He.
Frameworks are quite useful, but indeed not a good idea for Learners / Beginners. They lead you to skip important parts of what you should be learning and limit your thinking. To judge the advantages and shortcomings of frameworks, to chose frameworks, and to overcome their flaws, you should have a solid knowledge of the basics first.
So learn your basics, and once you have a firm grip on them, you can start to use frameworks.
Related
So I have recently taken over maintenance of an in-house Content Management System, and database optimization is not really my area of expertise.
Anyway a couple of things fell out to my eye when I was looking over the code.
The php code is a little bit "spaghetti with meatballs" with little to no comments.
But the biggest thing: As far as I can tell, the original programmer decided to forgo table joins entirely in the database code (both implicit and explicit).
For example here is the process to display a page column:
Fetch element list from the database
For each element call a subroutine to check display permissions and if successful, call another subroutine to fetch the element's html data.
Each of the subroutines effectively calls a separate query for each element. And the permissions step, I believe, involves querying two separate tables.
Performance isn't really a problem at the moment, and I wasn't asked to look into this. Although the page requests are a bit slow in my opinion.
Is it worth trying to rewrite the SQL stuff? I am thinking that the increase in maintainability will be worth it in the end, and that it will make things easier for me should scalability become an issue in the future.
Or is it not really as bad as I think? Maybe I am just overreacting. An expert opinion would be appreciated.
Refactoring is an important part of development process. Ignoring this fact means more problems in the future. The part of the problem is that not many managers understand the importance of continuous refactoring.
I'd recommend you to read "Refactoring to Patterns" by Joshua Kerievsky that has many good examples of how to safely change existing code by implementing new design approaches.
As of your question about SQL queries, it may or may not be the first thing you need to change.
If its about making your job in the future easier, I would start refactoring the spaghetti code before fixing the queries. Once you have a nice design, it should also be more straight forward how to integrate (and maybe even eleminate) some of those manual joins.
I think it would be worth rewriting while you have the time to do so. You don’t want to put it off until it becomes a problem. I say, let the database do what it does best. In this case, table joins would certainly perform better than multiple queries in a loop.
Your question is a bit too generic to give a good answer to and you haven't provided enough information to make educated guesses either, for your particular situtaion.
Things to take in to account:
Will the system grow over time? And how?
If there will be more users online, more preassure on the system - then there's cause for alarm. Systems with bad design does not scale well.
Bad code is one thing, but bad database- and general system design is worse. I think the key might be your comment about "next few years". If you intend to stick with the sytem for that long - then a serious look at the basics is a good idea. If your system might be up for replacement by something else (inhouse CMS's tend to be replaced) then you can patch along while shopping for the right thing.
But as your question stands - rewrite some of the questions, make sure your DB is normalized and refactor your code. Tell your boss it's the right thing to do if you're going to stick with the system.
This is my first time posting something like this. I'm a complete n00b at programming/php. I was trying to grasp all the tutorials out there and wanted to create a sort of framework to base projects off of for web db/applications. I came up with a few files for crud operations that I know must really be horrible code. I was wondering if I could get some advice in advancing this 'framework' to the next level. I'm not great at OO, but I understand the concepts, so I went more functional instead. I'm aware that the songs are gross, I don't need help recognizing that.
I would like some help on the database calls. I understand I should be using PDO (to help with injection), but I'm not sure how to convert this code to that structure. I also realize that at the least I should be using mysqli functions. Again, n00b.
I am also aware of validating and sanitizing data, but again, being so new to this, I don't know where to begin. Especially if I wish to keep it tight and small. The comments are funny from a programmers aspect, but hey, you work with what you got. I'm trying to grasp MVC and be able to tie in AJAX and templates/skins, but the crux of it is to work with databases.
I do like how there is one config file that works with all the other files, and how that results in small files for index, read and delete. The others get a little longer. Not that including files is makes me cool or anything.
I think I fail horribly at understanding MVC and structuring the project so that maintaining it and adapting it is easier. I also realize that there is a lot of html in those php files which is a no-no too. How do I fill in the gaps from what I do know (I know what every line of every file is doing) to what I should know.
The code can be found here (probably not sourceforge worthy, but I want to help others learn as I do).
https://sourceforge.net/projects/eleete/files/
Building such a thing takes a good amount of time, before you go doing so I would suggest looking into open source CMSs such as Wordpress to see if they would suit you better than putting in hours of work creating something yourself, the reason I say this is because to begin with you may think it won't be too hard to create one for yourself, but as you get into it you will realize there are many avenues that need to be explored in terms of security and features.
However, if you still want to build something the most important thing is to be creating reusable, and easily understandable code. For example if you want to create db entries for things like pages, you'll want to create functions to do so, to which you can pass variables such as titles etc. A good way to begin is to create functions for collecting data from your db, for example siteinfo() could be a function that returns an array full of site info. To make sure every file has access to such functions you will need a global file like functions.php for example which you will need to include in each of your other files.
Remember, building a framework is hard work, but if you do it properly and thouraghly you should increase your productivity a good amount - this is something you need to consider when building it, make sure you're not doing things in a roundabout way. Make it simple, make it reusable, and make it powerful.
First off, welcome to the community! I hope you find here people who are excited to bring your more into the programming fold. It's an exciting place to be.
I get the impression you're biting off quite a bit. I fear you're also under the assumption you can write the perfect program from the get-go, which is a flat-out myth no matter how long you've been in the industry.
As to the former observation, my recommendation would be to pick a simple problem and try to solve it. My favorite recommendation here are simple card games - blackjack, for instance. Dice games like craps also make for short, achievable, and interesting programs. The intent of these projects will be not to build a code framework as much as your skills in dissecting problems and turning them into a solution the computer can understand and solve for you- your code.
Starting small will keep you from getting overwhelmed early. Starting fun will keep you motivated through the inevitable snags that will tempt you to throw your computer out of a closed window.
All that said, we're still here to help! Specific questions to specific problems tend to get the best feedback here, as well as questions that demonstrate you've done at least some homework on your own in terms of trying to solve it. The Stack Overflow community will be happy to give you a hand up, but not a handout. Good luck!
You're going to be much better off using a clean, simple framework. As you're so new with this stuff, I'd recommend CodeIgniter for sheer simplicity and speed. It helps enforce the MVC framework you're not totally familiar with yet, has all the built-ins you're likely looking for, and has a decent community. Being a Zend guy, I should probably suggest that, but it's definitely not the easiest to get started with.
MVC and OO are concepts you really should learn well out of the gate before going forward. This tutorial rocks. There are dozens of MVC primers out there, but in essence it boils down to separating your data layer, view layer, and the like.
PDO is not necessary to be safe, you just need to escape your sql with Mysql_escape_string or the like. I'm actually not a fan of PDO due to the monkey wrenches it throws into debugging.
Since you're new, I'd also recommend Xdebug on your server for troubleshooting. It cuts down debug time immensely.
In my experience, unless you've had to fix the shortfalls in someone else's attempt at a framework, you won't really understand how to build one yourself.
One of the key qualities of any sort of API or framework is the concept of abstraction. In a nutshell, as you find yourself repeating code, look for where the repetition could be abstracted away. The trick about this when you're building a framework is to do it in an extensible, usable fashion so that you have pieces that build on each other. In other words, abstractions can hide other abstractions. For example, It's all very well to abstract away the job of assembling an SQL UPDATE statement from a list of fields, but why does the application page have to check the list of fields is correct? Put that behind another layer that can be taught what the valid fields are for a certain object.
Another key quality that comes up at this point is refactoring. The phrase "be prepared to throw the first one away" is sometimes bandied about in programming circles. What it really means is that you should always be open to the idea of re-writing code because you've thought of a better way to do it. Even if you have to rebuild the code that calls it.
I know there already are a lot of posts floating on the web regarding this topic.
However, many people tend to focus on different things when talking about it. My main goal is to create a scalable web application that is easy to maintain. Speed to develop and maintain is far more appreciated BY ME than raw performance (or i could have used Java instead).
This is because i have noticed that when a project grows in code size, you must have maintainable code. When I first wrote my application in the procedural way, and without any framework it became a nightmare only after 1 month. I was totally lost in the jungle of spaghetti code lines. I didn't have any structure at all, even though i fought so badly to implement one.
Then I realized that I have to have structure and code the right way. I started to use CodeIgniter. That really gave me structure and maintainable code. A lot of users say that frameworks are slowing things down, but I think they missed the picture. The code must be maintainable and easy to understand.
Framework + OOP + MVC made my web application so structured so that adding features was not a problem anymore.
When i create a model, I tend to think that it is representing a data object. Maybe a form or even a table/database. So I thought about ORM (doctrine). Maybe this would be yet another great implementation into my web application giving it more structure so I could focus on the features and not repeating myself.
However, I have never used any ORM before and I have only learned the basics of it, why it's good to use and so on.
So now Im asking all of you guys that just like me are striving for maintainable code and know how important that is, is ORM (doctrine) a must have for maintainable code just like framework+mvc+oop?
I want more life experience advices than "raw sql is faster" advices, cause if i would only care about raw performance, i should have dropped framework+mvc+oop in the first place and kept living in a coding nightmare.
It feels like it fits so good into a MVC framework where the models are the tables.
Right now i've got like 150 sql queries in one file doing easy things like getting a entry by id, getting entry by name, getting entry by email, getting entry by X and so on. i thought that ORM could reduce these lines, or else im pretty sure that this will grow to 1000 sql lines in the future. And if i change in one column, i have to change all of them! what a nightmare again just thinking about it. And maybe this could also give me nice models that fits to the MVC pattern.
Is ORM the right way to go for structure and maintainable code?
Ajsie,
My vote is for an ORM. I use NHibernate. It's not perfect and there is a sizable learning curve. But the code is much more maintainable, much more OOP. Its almost impossible to create an application using OOP without an ORM unless you like a lot of duplicate code. It will definitely eliminate probably the vast majority of your SQL code.
And here's the other thing. If you're are going to build an OOP system, you'll end up writing your own O/R Mapper anyway. You'll need to call dynamic SQL or stored procs, get the data as a reader or dataset, convert that to an object, wire up relationships to other objects, turn object modifications into sql inserts/updates, etc. What you write will be slower and more buggy than NHibernate or something that's been in the market for a long while.
Your only other choice really is to build a very data centric, procedural application. Yes it may perform faster in some areas. I agree that performance IS important. But what matters is that its FAST ENOUGH. If you save a few milliseconds here and there doing procedural code, your users will not notice the performance increase. But you 'll notice the crappy code.
The biggest performance bottle-necks in an ORM are in the right way to pre-fetch and lazy-load objects. This gets into the n-query problems with ORMs. However, these are easily solved. You just have to performance tune your object queries and limit the number of calls to the database, tell it when to use joins, etc. NHibernate also supports a rich caching mechanism so you don't hit the database at all at times.
I also disagree with those that say performance is about users and maintenance is about coders. If your code is not easily maintained, it will be buggy and slow to add features. Your users will care about that.
I wont say every application should have an ORM, but I think most will benefit. Also don't be afraid to use native SQL or stored procedures with an ORM every now and then where necessary. If you have to do batch updates to millions of records or write a very complex report (hopefully against a separate, denormalized reporting database) then straight SQL is the way to go. Use ORMs for the OOP, transactional, business logic and C.R.U.D. stuff, and use SQL for the exceptions and edge cases.
I'd recommend reading Jeffrey Palermo's stuff on NHibernate and Onion Architecture. Also, take his agile boot camp or other classes to learn O/R Mapping, NHibernate and OOP. Thats what we use: NHibernate, MVC, TDD, Dependency Injection.
A lot of users say that frameworks are
slowing things down, but I think they
missed the big picture. The code MUST
BE MAINTAINABLE and EASY TO
UNDERSTAND.
A well-structured, highly-maintainable system is worthless if its performance is Teh Suck!
Maintability is something which benefits the coders who construct an application. Raw performance benefits the real people who use the app for their work (or whatever). So, whose concerns ought to be paramount: those who build the system or those who pay for it?
I know it's not as simple as that, because the customer will eventually pay for a poorly structured system - perhaps more bugs, certainly more time to fix them, more time to implement enhancements to the application. As is usually the case, everything is a trade-off.
I've started developing like you, without orm tools.
Then i worked for companies where software development was more industrialized, and they all use some kind of orm mapping tool (with more or less features). The development is far easier, faster, produce more maintainable code, etc.
But i've also seen the drawbacks of these tools : very slow performance. But it was mostly misuses of the tool (hibernate in that case).
Orm tool are very complex tool, so it is easy to misuse them, but if you have experience with them, you should be able to get nearly the same performances as with raw sql. I would have three advices for you :
If performance is not critical, use an orm tool (choose a good one, i am not developing with php, so i can't give you a name)
Be sure for each feature you add, to check the sql that the orm tool produce and send to the database (thanks to a logging facility for example). Think if it is the way you would have written your queries. Most of the inefficiencies of orm tools come from unwanted data that are gathered from the db, unique request split in multiple ones, etc. Slowness rarely comes from the tool in itself
Do not use the tool for everything. Choose wisely when not to use it (you reduce maintainability each time you do raw db access), but sometimes, it isn't just worst trying to make the orm tool do something it was not developed for.
Edit:
Orm tool are most useful with very complex model : many relationships between entities. Which is most of the time encountered in configuration part of the application, or in complex business part of the application.
So it is less useful if you have only few entities, and if there is less chance they get changed (refactored).
The limit between few entities and many is not clear. I would say more that 50 differents Types (sql tables, without join tables) is many, and less than 10 is few.
I don't know what was used to build stackoverflow but it must have been very carefully performance tested before.
If you want to build a web site that will get such a heavy load, and if you don't have experience with that, try to get someone in your team that have already worked on such sites (performance testing with a real set of data and a representative number of concurrent users is not an easy and fast task to implement). Having someone that have experience with it will greatly speed up the process.
Its very important to have a maintainabilty that is high. Ive developed large scaled web application with lowlevel super high preformance. The big disadvantage was maintaining the system, that is, developing new features. If you'r to slow developing the customers will look for other systems/applications.. Its a trade of. Most of the orms has features if you need to do optmized queries direct to sql. The orm itself isnt the bottleneck. Ill say its more about a good db design.
I think you missed the picture. Performance is everyday for your users, they care not at all about maintainability. You are being ethnocentric, you are concerned only for your personal concerns and not those of the the people who pay for the system. It isn't all about your convenience.
Perhaps you should sit down with the users and watch them use your system for day or two. Then you should sit down at a PC that is the same power as the ones they use (not a dev machine) and spend an entire week doing nothing but using your system all day long. Then you might understand their point.
Please allow my intro to properly define the scope of my question:
I'm still very new to the programming world. This all started for me when I had an idea for a software program, but no programming experience. I ended up going the outsourcing route to get the program, and after almost a year, we do have it live and functioning.
This specific program is written with php and is 100% web-based. We're using lots of ajax, jQuery, etc.
Now a year into it, I have been learning and learning wherever I can (lots of learning here!!!) I'm mainly focusing on Java now to build up to Objective-C and the iPhone fun (probably like 99% of all other newbie programmers out there).
I'm really learning so much, and one of the biggest things I'm learning about is proper commenting and scalability.
I'm seeing now that this job we just finished is very sorely lacking in both those areas. I am wanting to add and build upon this program, and not only do I not have much experience, but I'm seeing that it's really hard for me to even get an idea about the functions without these comments...
So my question is-what is the best course of action to begin to pick up the pieces on this program? A full re-write is out of the question, and I don't think is needed.
I'm sure this is not the first time some newbie programmer, software developer has been down this path...what do others do here?
Is it common for a programmer to come into a project very far along and then "clean up" the mess in order to make things move forward productively?
If this is the wrong place for this question (and I understand it may well be) can someone point me to where this would be more appropriate?
Thanks!
Joel
We call it "refactoring" and it's an important part of programming.
First, you must have a rock-solid set of automated tests. Usually we have unit tests that we run with a unit testing framework.
http://www.testingtv.com/2009/09/24/test-driven-development-with-refactoring/
Then you can make changes and run the tests to confirm that nothing was broken by your changes.
In some cases, you have to "reverse engineer" the tests around the existing programs. This is not very difficult: you have to focus on the interfaces that are "external" or "major" or "significant".
Since you're reverse-engineering, it's hard -- at first -- to determine what should be tested (because it's an important external feature,) and what should not be tested (because it's an implementation detail.)
I'm really learning so much, and one of the biggest things I'm learning about is proper commenting and scalability.
First, I'm curious what you've learned about "proper commenting" as this varies drastically. For some, it's documenting every class and function. For others, it may be documenting every line of code or no code at all.
After having gone through some of the different phases above, I'm with Uncle Bob Martin who, in Clean Code, says that you document decisions, not what the code does. The code itself should be readable and not need documentation. By adding comments describing behavior, you've created duplication that will eventually become out of sync. Rather, the code should document itself. Using well-named functions and variables help describe exactly what the other intended. I'd highly recommend Clean Code for a full discussion of these concepts.
As for scalability, it's usually something that you want to build in. Scalability might be a function of good design, or a proper design for the requirements, but poor design will make scalability a nightmare.
I'm seeing now that this job we just finished is very sorely lacking in both those areas. I am wanting to add and build upon this program, and not only do I not have much experience, but I'm seeing that it's really hard for me to even get an idea about the functions without these comments...
I see this as an indicator of one of two things:
That the code isn't well written. Yeah, that's highly subjective. -OR-
That you don't yet fully understand everything you need to. -OR-
A little bit of both.
Writing good, intention-revealing code is hard and takes years of practice.
So my question is-what is the best course of action to begin to pick up the pieces on this program? A full re-write is out of the question, and I don't think is needed.
As other posters have mentioned, Refactoring. Refactoring is the process of changing code to improve readability and usability without changing functionality. Get a good book on refactoring, or start reading everything you can online. It's now a critical skill.
Is it common for a programmer to come into a project very far along and then "clean up" the mess in order to make things move forward productively?
Unfortunately it is. It takes a lot of diligence to avoid falling into this trap. Try to make your code a little bit better every day.
I don't know about this being the wrong place or not, but I'll answer as I can:
Is it common for a programmer to come into a project very far along and then "clean up" the mess in order to make things move forward productively?
Yes, in my experience this is very common. I have been doing contract work for over 10 years, and I can't count the number of times I've had to come in and clean up something hastily put together to either make it scale or to be able to add functionality onto it. This is especially common when you outsource the programming to another company, the incentive there is to get it working and out of the door as quickly as possible.
So my question is-what is the best course of action to begin to pick up the pieces on this program? A full re-write is out of the question, and I don't think is needed.
I don't know that there is a "good" answer to this question, the only thing I can tell you is to take it one method at a time and document what they do as you figure them out. If you still have access to the people that initially wrote the program you can ask them if they could give you documentation on the system, but if that was not included as part of the original work spec I doubt they are going to have any.
I'm really learning so much, and one of the biggest things I'm learning about is proper commenting and scalability.
As you have found on your own, proper commenting is important, I'm not convinced on the importance of building scalability in from the beginning, going by the YAGNI principle. I think that as any program grows it is going to go through growing pains, whether that is scalability or functionality. Could someone have built twitter from the start with the kind of scalability in mind that it currently needs? Possibly, but there is the very real possibility that it would flop.
Is it common for a programmer to come into a project very far along and then "clean up" the mess in order to make things move forward productively?
It's definitely common for pretty much EVERY programmer :)
Having said that, remember the IIABTFI principle. If It Ain't Broke, Don't Fix It.
Understanding how the program works and what the pieces are is useful.
Trying to improve it without a specific goal and a business purpose in mind is not.
The big question is how well is the program currently running meeting the needs of those that use it? While it may not be the best looking code, it does work which may mean that you end up doing 101 refactoring exercises around it to get enough of the basics down to make other changes.
While you may be able to ask the original writers of the program, this can be a possible sore spot if they think it is awesome and you think it is crap, for example. It is an idea and one that should be carefully analyzed a bit before one goes and ends up burning bridges because they think you can't appreciate their genius in what was done.
Often this aren't done in an optimal way and so as one learns better ways to do things, things are done in better ways. There is a limit to that of course, but I'd start with the idea that you have some refactoring lessons to help get the basics of the app under your belt and then start putting in enhancements and other stuff to see what was really done in the end.
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 8 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I would like to be a PHP/MySQL programmer
What are the technologies that I must know?
Like:
Frameworks
IDEs
Template Engines
Ajax and CSS Frameworks
Please tell me the minimum requirements that I must know, and tell me your favourite things in the previous list?
Thanks
First off, there is no must know about learning PHP and MySQL... You go into it not knowing anything, and you'll come out of it knowing a bunch. If there was a must know, then nobody would be able to get into PHP and MySQL development. I personally think you are at a slight advantage going into this without knowing everything about it. It'll give you a fresh perspective and a think outside of the box attitude :)
As far as the object oriented stuff in this thread, it's true. But, as others have said, it's completely up to the programmer (you) to decide how to write your code. You can use object oriented practices, make a spaghetti code junction, or just right a bunch of functions, or whatever. Either way, as everyone else has been saying, it's up to you :)
IRC channel:
Don't really need this, but I find it helpful... See you in here :)
irc.freenode.net #php
Manual:
The manual is your friend and probably the only thing you should know before diving in.
http://www.php.net/manual/en/
http://dev.mysql.com/doc/refman/5.0/en/apis-php.html
Frameworks:
Make sure it's an MVC framework :)
http://www.cakephp.org/
http://www.phpmvc.net/
http://www.codeigniter.com/
http://www.symfony.com/
http://www.laravel.com
http://www.yiiframework.com/
IDE:
Whatever suits you best :)
http://www.eclipse.org/
http://www.vim.org/
http://www.zend.com/en/products/studio/
http://php.netbeans.org/
https://www.jetbrains.com/phpstorm/
Template engines:
PHP is a good template engine
Model view controller frameworks help with this
twig.sensiolabs.org
http://www.smarty.net/
Ajax:
http://jquery.com/
http://www.mootools.net/
http://developer.yahoo.com/yui/
http://www.prototypejs.org/
http://www.extjs.com/
http://code.google.com/webtoolkit/
https://angularjs.org/
CSS:
http://www.yaml.de/en/home.html
http://code.google.com/p/blueprintcss/
http://developer.yahoo.com/yui/reset/
Definitely not an exhaustive list, and things change constantly... But, it's a start :)
Have fun!
Chrelad
Security is an important topic every web programmer should study before being allowed to post code that can be accessed publicly on the internet.
Examples of security issues:
Injection flaws
Cross-site scripting flaws
Cross-site request forgery
There are more security issues that you should know and keep in mind as you write PHP applications. The website http://www.owasp.org contains lots of useful information to help.
PHP was my first language, which I learned on the side while working as an office junior in my first job over 10 years ago. Here is some things from my experience:
Download the PHP manual, print it off, and start reading from page one. Keep going till you're at the end. Skim over the bits you probably won't need (like using KADM5 or Hyperwave) but always read the introductions so you know what PHP is capable of (this will save you trying to re-invent the wheel). The PHP documentation blows the docs of pretty-much every other language I've worked with since out of the water.
Next step; set up PHP. Manually. Don't use XAMPP or anything else, do it yourself. It always helps to know how your environment is set up.
Don't bother with an IDE at the beginning. Getting to know a language means getting up-close-and-personal. IDEs obscure things in an attempt to help you GetThingsDone which works great when you know what you're doing and know your target environment, but when you're starting out they just get in the way and hide what's important.
Don't bother with frameworks at the beginning, either. Again, they're there to help you GetThingsDone which only works when you know what you're doing in the first place. Start with the basics, otherwise you'll be learning the framework and not PHP.
PHP is essentially an advanced templating engine. Don't fall into the trap of over-hyped "PHP templating engines". They're just doing what PHP already does, doubling-up on the work and running twice as slow as PHP does. Stick with inline html/php to start with. Again, this'll help you get to understand what PHP is, how it works, and when to use it.
As with AJAX and CSS... they're nothing to do with PHP, but with the output you produce from PHP (and with AJAX getting input in). Don't load your plate with too much to eat at once. Start with plain PHP+HTML, and do your CSS by hand. Then, when you're happy, mix in a little javascript.
The best thing you can do with any language is learn the environment you're going to be working in, because programming is (relatively) similar across all of them. They all have loops, data structures, input/output, etc, but they all work just that little differently.
Don't believe the hype. I'm moving from PHP to Python at the moment and I could've just jumped on the Django band-wagon to GetThingsDone, but I know that if I came across a problem I wouldn't know where to begin to fix it. So I'm taking my own advice and starting from the beginning; reading the manual, setting up an test system, parsing simple files, getting input/output, getting it linked in with a web server... all part of getting to know my new environment.
What should every PHP programmer know ?
You need to know a language that is not PHP. I'm not saying you shouldn't develop your sites in PHP, it's actually really good for that, but you really need to know at least one other language to get some perspective.
Why? PHP is broken and full of bad design and misfeatures. You can write excellent code in PHP, but you're never going to be able to spot the bad design and failures of PHP itself if you don't know any better.
I'd suggest python, ruby, or C#
PS: If you don't think this is a helpful suggestion, then by all means downmod this answer, but if you are downmodding because you feel insulted by my claim that PHP is broken and badly designed, don't shoot the messenger, I'm just telling the truth!
First of all, that PHP itself IS a templating system
Security.
Just like Lucas Oman said - it is up to you in PHP to write the code well; and it does not coddle you. If you don't understand why you need to confirm a logout, or why you can't just validate in javascript, or why register_globals is bad - your app will be vulnerable in some form or another.
You need to learn the following (I would suggest in this order):
Basic Object-Oriented Principles (such as inheritance, polymorphism, and encapsulation)
The PHP language itself. Specifically, PHP 5.
Database Design Principles such as tables, keys, relationships, normalization, etc.
SQL - Structured (or Standard never can remember which) Query Language. Specifically learn the basics of select, insert, update, and delete queries.
Good design principles and coding practices (you can find posts here on StackOverflow for one) such as dividing presentation and business logic.
A Framework, Any Framework - this will help you become introduced to more advanced concepts of object-oriented design patterns and allow you to follow tutorials that will encourage good design and coding practices.
Object-Oriented Design Patterns like MVC, Database Abstraction Models and the like
Advanced SQL and other database stuff like triggers, stored procedures, and other functions.
Ignore the mysql_* functions. Not only do they provide no straightforward method of writing secure code, they actually go out of their way to make it painful and tedious if you try. Use mysqli or PDO instead (and you've got no excuse now - PHP 4 was end-of-life'd months ago).
All good answers, but there is something important missing: If you want to seriously get into PHP, then you should be aware that there are a lot of PHP programmers out there who are lazy, inept, ignorant, misguided and unfortunately get their code released to the public. The history of PHP means that it supports some questionable features (not just things like register_globals but also smaller things like automatic initialization) and people still use them. You don't want to.
I would say the most important thing is to learn how the whole process of building a page with PHP works - in that requests come from a client (web browser), hit the web server, get passed through to PHP, which then generates the response that is sent back. A solid understanding of this will ground you in
why you can't send headers after output has started
how sessions and cookies work
how each page should be built in a stateless manner (i.e. deliver whatever the request asks for, don't remember what happened last time, or guess what the user is doing)
The difference between HTML, PHP, JavaScript and CSS, and more importantly, what each is used for primarily and where the responsibility of each lies.
Once you've got that down, then you should be quite comfortable with writing any app. But unless you've got that down, you'll start mixing things as I've seen many rookies do before now.
That every value everywhere has to be encoded appropriately. echo $some_variable_that_seems_innocent is evil nine times out of ten.
Use htmlspecialchars() in HTML/XML, prepared statements or at least addslashes() when building SQL queries, json_encode() when inserting values into scripts, rawurlencode() when appending URL components, escapeshellargs() when constructing shell commands, etc.
If you insert text in URL that's part of a script in XHTML document, you'll need to encode data three times.
Although this isn't a technology, I think it's very important that you understand that, when using PHP, it is completely on you to write good code. PHP is capable of it, but it does not encourage it. You are completely responsible for writing code that is well designed and, if you choose, follows OO principles. You will have no help from the language.
Use a great IDE (like Eclipse for example) that let you debug and have some code completion. This will save you some time.
PHP have a lot of programmer and is very popular = a lot of thing is already done for you, before writing some code, doing a google search is always a good idea.
You should use some of the Framework if you start from scratch. This will answer all your question about AJax, template engines... because most of them come with these packages.
Here is some post about how to start choosing a framework: SO 1, SO2, Here is a list of PHP Framework.
You can develop PHP on Windows, Linux or Mac.
Getting a web server setup
To run PHP and MySQL locally on your computer you will need to install Apache webserver with php module and MySQL database server. ie. a LAMP webserver (Linux Apache MySQL PHP).
In the past, I would recommend installing Ubuntu. These days, there are a few solutions available that will give you one click installation webserver without using linux.
For Windows:
http://www.wampserver.com
For OSX:
http://www.mamp.info
After having a LAMP webserver use w3schools.com tutorials to start.
I would say a basic one would be HTML. ;)
No Php framework expert.As templating which make the system much complex then as it.
Understand business logic requirement and think the cons/pro.Hoping for SA to think all for you is not good programmer.
No ajax.I dealing with large of data,rendering to one js file about 4000 k data is very bad.
Start from notepad or VI
After learn php about 1 to 2 years,try learn other language like c# or c++ to improve your php application.
Php is addicted language rather then other language.You type it works.Other language,you type It's Compile It's Hang up.
7.For complexity application,php is the best to me rather then other language,because you think,you write it works.
You should know how to use effectively at least one Debugger/IDE. It is amazing what you can learn from your code by stepping through it and watching it run. It both makes it much simpler to track down bugs, and improves the quality of your code. I believe you should never commit code to a project that you haven't seen execute.
The PHP Language
Go to PHP.net and read through all of the documentation. When you are done, you won't know everything you need to know about php, but you will know where to look.
Be careful of code snippets you find on the web. Often they contain sql in html, which is bad practice, as well as security vulnerabilities such as sql injection. I've seen few that use prepared statements, which is good for security.
Personally, I found the book "Build your own database driven website using PHP and MySQL" extremely helpful.
Other than that, the one thing I found hardest to get used to with PHP is how relaxed it is, compared with any other language I've ever used. By that I mean no types, flexibility about syntax and punctuation. Personally I think that's a good thing, but I also know that it probably encourages pretty bad behavior.
Here's one other tip I have: try to use something like the DRY principle -- i.e., you'll find yourself writing the same little (or big) bits of code over and over again -- make them into functions as early as you can in the process of coding, and life will be a lot easier later on.