How to increase my "advanced" knowledge of PHP further? (quickly) [closed]

Solution 1:

Everyone who wants to be a PHP programmer, always takes only the first word and completely ignores the second.

While "programming" is WAY more important than "PHP", to be a PHP professional, one should be a programmer in the first place.

So, I'd vote for the last one - reading books. Not on PHP, but on the programming in general. Grady Booch's, Martin Fowler's and even the old Donald Knuth's ones.
It would be also be nice to take a look at some other languages, like Java or Python. Not to switch to them, but to learn from them.

Solution 2:

I prefer my own library of functions rather than having a framework

You refer to a 'library of functions' and 'a' framework' as distinct concepts (good!) so why not try and up the ante a bit and turn that library of functions into a framework? Mind you this is a great way to learn but not the best way to have marketable skills ;)

It's also a great way to learn wrong so before you start you have to do some research.

The "must have" features

There are certain features almost all frameworks have, and there's a reason for that. Research them; find out why they are present and what their variations are; choose which implementations you'd prefer to include in your framework.

Object Oriented (this is key to why you'd write a framework as opposed to just using your library of functions)
Use of Patterns (check out and start asking yourself why so many frameworks use Application Controller as opposed to Front Controller... and are there some platforms which use Page Controllers?
Basic MVC structure
Clean URLs

Features of non-PHP platforms you want to understand and emulate

If you like Ruby perhaps you'd want to a means by which to include modules in classes?
If you like Asp.NET maybe you'd want to try creating Server Controls in a PHP environment?
Upset that forgiveness is the default with HTML? Why not validate output server side

I have no idea what interests you so I'll stop there.

Publish it!

This part is important, because Nathan is right: your work has to be seen, challenged, critiqued and corrected by other people. Don't leave that lamp under a bushel - it needs to be seen; put it on Google code or sourceforge or something, and if people are going to bother looking at it seriously you need to take it seriously; you need to maintain unit tests and regression tests; you need to use version control; you need to comment it well, with a big /* header comment */ at the top of each file and useful doc-generating comments for each class and member thereof.

Summary

If you do all this, you can learn (at a high level) about other platforms. You can definitely "ding 40" as a PHP developer. You can learn about unit testing; about regression testing. You can learn about documenting effectively.

Guaranteed your framework will come out "idiosyncratic and probably sucky", but you can learn a lot from writing it. Just keep in mind that the framework isn't a product; it's a journey... of sorts.

Solution 3:

Look into hidden features of PHP and PHP's predefined interfaces
Learn different languages. Learn languages that have a steeper learning curve than PHP. Any time I point out advantages of other languages over PHP, I am accused of PHP bashing, mostly be people who quite obviously never really mastered another high level language. But I'm gonna take the risk. I suggest Ruby, Python, Pearl and haXe (as a strictly typed counterpart). Once you did it, try applying your new knowledge to PHP. Or just move away from PHP, in case you don't wanna go back (which I think isn't unlikely to happen).
Learn to deal with critisizm. Your reaction to Nathan's post showed quite clearly you can't deal with it yet. He is absolutely right.
- Looking at my first PHP framework now, I have to say it was quite shitty. At the time I thought it was great (and it still is better than a lot of production code that I've already seen deployed). Still, it had many flaws. Unless you're a total genius, your first frameworks will just look awfully if you look back at them a few years later (assuming you evolve).
- Actually, any framework you will create will look worse as time progresses (assuming you don't stop evolving). For this reason you might just as well use available frameworks and focus more on application development. If the framework you use has limitations, consider contributing rather than writing yet another PHP framework.
- The point in time to choose writing your own frameworks (not just for fun/learning, but for production deployment) is when your requirements surpass what other frameworks out there offer and not when you just don't like the idea of working with one. It's a common mistake, which I have done myself. But now I can say, I've learnt from it. But if you ask for advice (which I unfortunately didn't do at the time) you will get answers like these.
- You learn a lot from working with code you did not write yourself. Not only do you pick up concepts promoted by frameworks others put a lot of thought into, but you also learn to be productive, flexible, able to work in a team and to get the job done (while obtaining reasonably good results).
- I suppose you can't really think you're better than every team of a PHP open source project out there, otherwise you would ask. Get over the stubborn instinctive need to reinvent the wheel any young developer has and grow up to tackle problems noone has tackled yet.
Learn, what the difference is, between a component library and a framework. Since you think you can replace a framework with "your own library of functions", you probably haven't understood, what the point of frameworks is. Have a look at dependency inversion, inversion of control and dependency injection.
Learn about software design. Look at OO principles like SOLID and GRASP.
Try different paradigms. AOP, functional programming. Enhance your OO skills using languages with stronger object orientation, such as Ruby, Objective-C or Smalltalk.
Look at PHP frameworks such as Flow3, Symfony, PHP igniter and CakePHP. I've already pointed out why I think you should do so.
As pointed out in another comment of mine, you should consider other storages than RDBMs. SQL and OOP really don't go well together. Have a look at OODBMS, different database abstraction layers, key-value-stores, document stores such as CouchDB and MongoDB, distributes caching servers as memcache etc.

Solution 4:

Here are a few thoughts:

Try different things. Learn a new language. Some times in the process of learning that other language, actually makes you better on both.
Contribute to an open-source project.
~~High scalability and PHP/MySQL are not friends . There are technologies today that are build just for that. node.js and Redis to name a couple.~~
Answer questions in SO. Other people's problems can make you think outside the box and you improve on the process of trying to help, and you also do something nice to someone.
[ will try to add here if I think of anything else I just woke up drinking coffee :D ]

Solution 5:

Learn to do what you already know ... in a different way. Examples:

in a different language
on a different platform
in parallel/distributed
through a framework (yes, you decided that they "aren't for you" - maybe try a different one, they are sometimes very different from each other)