PHP Weekly improvements
phpweekly.com
phpweekly.com
I'm not fond of PHP, but I don't know it as well as Ruby and Python. Still, I like to read about new technologies concerning PHP. I use HN to discover new stuff, but HN is a poor resource concerning PHP. HN has tremendous vocal disdain for PHP. Every PHP thread transforms into "Why I like or dislike PHP" instead of actual discussion regarding new technologies or libraries. What's worse is the debates feel like I've warped 10 years past because there is nothing ever new to them. People complain about the old things of PHP and never talk about the new things.
Put simply, even though I don't know PHP that well I feel like maybe it has potential and can actually do good in the right hands, but HN brainwashes you into thinking PHP is the worst.
It has a very poor track record when it comes to security flaws, for example. It is also rife with inconsistencies and unjustifiable oddities throughout the language itself, and its standard library. Factors like those then promote the development of software that is of an unacceptable quality.
There do happen to be many extremely experienced software developers here at HN, and we won't hesitate to point out the flaws with various technologies, including PHP. This is not a bad thing; it's quite good. It's extremely important to be vocal about low-quality technologies.
These days, there are just so many alternatives that are far superior to PHP in every respect. Even with its new features, PHP is still not an acceptable option. So we shouldn't be looking for positives where there just aren't any, nor should we be surprised when all we find are negatives.
Nonsense. As the most widely deployed platform it has absolutely massive exposure and security flaws are fixed quickly.
Don't confuse poor practices by newbies with platform security and stability.
> It has a very poor track record when it comes to security flaws, for example.
It does not.
> It is also rife with inconsistencies and unjustifiable oddities throughout the language itself
Every language has its warts. What's your point?
> These days, there are just so many alternatives that are far superior to PHP in every respect.
Yeah. Don't blame the tool. Blame the craftsman. And a craftsman who spends quite a bit of time complaining about the tools others use ... well ... you can fill in the rest.
Anyone notice the duplicate topic under Tutorials and Talks "Offline Processing in PHP with Advanced Queuing," just gave me a little chuckle when one of the articles is dealing with duplicated code.
Aside from this, I LOVE PHP. A prospective employer was asking if I would be open to learning RoR. Anyone who is experienced on Rails, could you let me know if it's a similar structure as PHP (which I'm great at)? Thanks.
Syntactically, the languages are not all that similar. It's probably closer to Python.
As much as people abhor PHP in programming communities (and I get that sentiment), I find RoR to be a far, far worse platform to build upon.
PHP is a kludge. You'd be surprised to know that world is made of kludges with a few elegant hacks thrown in and not the other way round.
Performance hacks are always kludges. Can you live without them ?
Honest question, should I waste my time worrying about the "What makes syntax elegant" than working with the existing kludge ? What makes that time well spent ?
Why shouldn't I seek beauty in output and look for a programming language that get's me the output quickly ?
I guess the best tools are ones which help you produce output quickly whilst being conductive to elegance and readability, Ruby's terse syntax and features like blocks are an attempt at this.
It also depends on how big your project will get and how long it will need to be maintained for.
There are plenty of projects I have seen where chunks of extremely bad code have been pumped out to create a 1.0 with a giant list of features. Of course such code becomes increasingly costly to maintain or modify without breaking. In many cases they would have been better off cutting features from the 1.0 (most features are unused anyway) and concentrating on quality.
No. I wouldn't. I'm an electrical engineer by training.
> Performance hacks are always kludges.
Not always. Sometimes they bring out some inner beauty in the code that was previously hidden. But, again, sometimes they don't.
> Honest question, should I waste my time worrying about the "What makes syntax elegant" than working with the existing kludge ?
It depends on your priorities. If you were a poet, would you be more worried about making good poetry or selling more books?
> Why shouldn't I seek beauty in output and look for a programming language that get's me the output quickly ?
Again, it depends on what is your output and how you relate with the fact that the thing generating that output is a horrible mess.
I agree. Electrical, Electronics, Civil, NASA aka Real Engineering will not have more kludges.
Phone Radiation / Drainage Systems have a few "Oh well I'll just leave it here ..."
But what about medicine, law, newspapers ? Are they not part of the real messy world ?
I agree to be a kludge worker and an idealist part time poet :) (pragmatic choice)
My impression was that Ruby is much closer to Perl than Python.
Even though PHP and Ruby (and therefore Rails) have little in common, I think you can still learn the Rails fundamentals quickly. Check out Michael Hartl's excellent Rails Tutorial. Also, Ryan Bates' Railscasts are a fantastic resource.
Php .net is so well doc'd with an example for almost every function/feature that it made it EXTREMELY easy to pick up. Does Ruby have something similar (really hope it's not -> ruby-lang.org, reminds me of w3), not too keen to Michael Hartl's just cause I'd have to buy it.
I much prefer Ruby's documentation to PHP's. Especially when it comes to 3rd party code, I don't have one gem in my current Rails project that isn't very nicely documented. Compare that to the PHP I work on during the day and almost all the 3rd party libs have no documentation.
* The languages are very different, syntactically. Ruby's blocks and enumerators really don't have an analog in PHP, and they'll take some getting used to. There's also some pretty deep philosophical differences in what the two languages mean by "class". That said, they sit at about the same abstraction layer, so line by line the complexity and flow shouldn't be that big of a jump.
* Rails is more like, say, Zend Framework than raw PHP. It enforces an MVC layout on your code and does what looks at first like a lot of magic to figure out which template files correspond to which pages. When you're starting out the rails scaffold generators are your friend.
* Ruby's standard library has a lot less in it than PHPs, so no XML parser or SQL client out of the box. Gems, and bundler in particular, makes it much easier to add third party code, though. You'll spend a lot more time bikeshedding over which third-party library to use, but the competition generally leads to more pleasant APIs in the long run.
* Ruby convention is to have more files and less code per file. A lot of your template files will only end up being three or four lines long. It's honestly easier in the long run, but get an editor that supports that workflow (multiple tabs, fuzzy file open, find-in-project, etc).
* RoR is almost completely independent of Apache for configuration. You get to move all the logic that was in .htaccess into ruby code in your app somewhere, and you get much more freedom over defining what you want your URLs to look like. You'll need to familiarize yourself with a concept called reverse proxying to figure out how this works in production, though.
* Not strictly ruby, but the rails asset pipeline is magic. Once you get used to it you'll never want to do frontend coding without it.
Oh well, another challenge, another achievement. Thanks Vec!
I think CURL is handled in a more abstract way in Rails, but I haven't really gotten to work with Http clients in Rails yet.
Coming from PHP where basically nothing happens unless you make it happen (for better and very often for worse), I found Rails confusing once you got beyond easy Active Record calls and into using gems. There are tons of add-ons that do useful things, but they do a lot of their work behind the scenes assuming adherence to certain conventions—which, I know, is a strength as well as a weakness, I get it. But that increases the difficulty of jumping past the stage of following a tutorial and just installing one persons collection of gems, scripts and other helpers.
If you write Object Oriented PHP and use a framework with strong OOP principals you probably will have no problem learning Rails.
If you've used MVC before, and you understand the role of a Model, View, Controller, data bindings, ORM, etc. then you should have no problem learning Rails.
If all you know is PHP and it's control structures, and you expect your file to be interpreted every time you visit a URL, then you will probably have more difficultly learning Rails.
It would be helpful to know what you love about PHP.
Good variable names and documentation are infinitely more important than new shitty frameworks or do vs "{" vs "\t".
I always hear people say this, but I've used both a fair bit and `rails s` plus port forwarding is an order of magnitude easier than fighting with apache's vhost config.
I suspect you are aware of this, but using URL parameters it is quite easy to make multiple urls map to the same file (i.e. `/foo/?abc=123` and `/foo/?abc=234`).
It cuts both ways, too. CGI-style routing gives a URL to everything, whether you want to or not. Unless you explicitly disable it, visiting /blog/config/database_credentials.ini (or whatever) will happily serve that file to the client. Plus it allows any user to execute the code in any file in your system out of context. Admittedly this will probably either error out or do nothing, but can you guarantee that for every single code file in your whole tree?
I've been using this technique (single url rewrite rule, send everything to index.php, handle routing there) for some time and it's worked quite well for me.
The operating system can cache hundreds of 10 KB PHP files without problem, it doesn't make a difference how many files you have when they are all small and cached.
So, in conclusion, I propose that PHP performance is OK if you use something like php-fpm.
Huh? You can use a lightweight framework like CodeIgniter to immediately remove this problem.
The point is that this is a problem web frameworks don't have to have in the first place. It is relatively easy to fix, if you know how, but it creates boilerplate code and adds potential for security holes for literally no benefit. The ability to heal a self-inflicted wound is a poor substitute substitute for not being injured in the first place.
None of these are necessary if you have properly configured your web server.
A few years ago, I briefly ran a webserver that had both mod_python and mod_php installed at the same time. Everything seemed fine until I tried using md5 from Python and repeatedly got completely wrong values:
>>> md5.md5("hello").hexdigest()
'00000000000000005039985304054aac'
>>> md5.md5("hello").hexdigest()
'00000000000000009ebb1c1ea77b5505'
But I get your point about PHP's deployment story being one of its (arguably few) strong points.
People aren't rushing to make mod_* for other languages because it implies a lot of behavior (by nature of it being served through Apache) which isn't really the best idea for security.
Having a structure that mixes the code files, templates (let's ignore mixing of logic and presentation), and static content all in the same publicly accessible location is just asking for security problems.
You can lock down what's accessible or not based on file extensions, but that's through a config that's not part of the deployment (Apache conf) so it's not as easily controlled in your code, or if it is part of the deployment (htaccess), can be affected or overridden by directives nowhere near your code (Apache conf). It's fun when someone breaks the php loading directives in the Apache config and your code starts showing as plain text. You made sure not to hard-code ANY credentials in your PHP files that are publicly reachable, right? Your config isn't publicly reachable, is it?
The closest you are going to get to something sane here is to approximate what the other frameworks are doing, which is to create a completely different site root, and a directory structure that completely separates your public content from your code, and point Apache at the public dir, not the code root. Unfortunately this does nothing to mitigate the problem of someone breaking any URL rewriting you need going on at the global Apache config, nor does it make it any easier to deal with crazy rewriting rules in Apache.
Apache is great at serving content; Apache isn't the best choice anymore for serving applications.
What is?
For what's best, take your pick of any framework that entirely decouples the application directory structure from the routes and keeps the logic for it all completely internalized. All logic for how URI's are handled should be within the application configuration or code. Something written in the target language will probably provide far more benefits than whatever is lost through Apache.
Whether Apache is in the path to your application is irrelevant, whether Apache does anything except note that a request should be handled by another application and hand the entire request off without change is not.
On Firefox 3 the site appears about 4000 pixels wide.
http://www.phpweekly.com/archive/latest.html
larger, and expand the width of the layout some. If you're going to leverage a simple layout like that in which the text is the sole focus, you might as well go a bit larger font size.