As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
Back when I was learning HTML, I loved how easy it to build pages and arrange everything just the way I wanted using tables.
Then I moved to CSS and learned that you could quickly swap designs without recoding your page. With just a few CSS changes your HTML designs could go from one theme to another and any element could become any other! With CSS I could design spans that looked like images!
Moving from HTML to CSS expanded my concept of design by implementing what I would later learn is modularizing things - just like MVC.
I am now a very competent PHP programmer who is thinking about Ruby. Most of the stuff I pull up on google is PHP vs Ruby rants which don't truly help anything. They are two different languages and take their style from different points. PHP looks like C++ strlen($string) while Ruby looks like server-side JavaScript. str.len()
I want to know the top 3 things about ruby that could really open my eyes as a programmer and justify the time I know it will take to pickup and master a new language.
Please, no mention of abstract things
like language maturity, or obvious
library's like AR which exist in both
languages.
MVC is now used in almost every web
programming language so it doesn't
count either. It is also not
sufficiant in and of it's self to
cover everything. MVCLLCC
(Model/View/Controller/Library/Locale/Cache/Config)
is more accurate.
:UPDATE:
Apparently there isn't too much new in Ruby compared to the other languages I use. Blocks appear to be nothing more than functions with a different name. procs seem to be blocks with callbacks which would be like a hooks system. MVC, AR, and everything else is already in the other languages.
However, I believe the most exciting thing I have seen is that you can open up classes at runtime and add new methods! This is a very important concept and really removes some hurdles that PHP has. No longer do you need extend child classes just to add a few methods to a parent class.
Well, you cut out a few of the things that make Ruby really fun, so I think any remaining list is going to be somewhat arbitrary. Here's why I think Ruby is nicer to work with than PHP:
Consistency: In Ruby, everything is an object -- even numbers. You call a method on an object the same way -- there aren't really any "special cases". Moreover, the standard library (and most 3rd-party libraries) have consistent naming schemes and styles. The PHP library has grown...organically, and as such, the names, use of underscores, etc., is chaotic.
Functional-style programming: Ruby borrows a lot of constructs from functional languages like Lisp. This is a pretty arbitrary reason, but I like functional programming, so having easy access to functions like the map and fold* methods from Lisp and Haskell is a plus for me. It also makes heavy use of blocks (aka "closures") which not only open up some very nice programming styles, but also allows you to write some very general code that can be used in a very specific manner, depending on your needs.
True OOP: Ruby's OO model is borrowed heavily from Smalltalk, and uses the message-passing style rather than the method-calling style. This lets you do pretty cool things like implement your own handlers for missing methods. Ruby is also dynamic in nature, and thus lets you define methods -- and even entire classes -- on the fly, at runtime. You can also "open" classes up and provide your own methods, which can save yourself the hassle of, e.g., extending the String class just to add a rot13 method.
RubyGems: RubyGems is a package manager for Ruby gems (third-party Ruby modules). It makes installing, managing, and removing third-party modules (and their dependencies) a breeze. (I threw this one in as a bonus reason.)
Lambdas (blocks).
Mixins.
Heavy use of the above two concepts in the standard library.
I would also nominate continuations (callcc), but they seem to be relatively obscure (which is a pity), and are gone in 1.9.
Top 3 things about Ruby that I enjoy:
Blocks and procs
Metaprogramming
Enumerable module (tons of awesome Array goodies)
Its hard to stop at 3 but maybe others can add more.
Best thing is try some code out for yourself. Good luck and have fun.
Here's at least one reason that applies to me (maybe you too): The way ruby handles object-oriented programming has "freed" my mind a lot in terms of how I think about coding and architecture. Everything is an object with ruby...
Ruby is fun to read and write
Blocks are even more fun
RUBY IS JUST PURE FUN
I'd say give it a try. I was once a PHP coder too and then switched to Ruby and never looked back. The only downside is the documentation which is clearly better in PHP (I would even say PHP has one of the best)
Here are the three things I really like.
I am not going to speak about the language itself but of what I like in the ruby world in general.
Tests
A lot of frameworks are available. If find them simple. Far easier than anything I have tried in JAVA.
The ruby community is very test-centric and you can find very good screencasts and tutorial to get you started.
It has changed the way I code.
Rails
I believe I started (seems so long ago :)). With Html+tables then CSS then PHP etc.
2 years ago I discovered Rails. And I really think It is an amazing framework.
From my point of view it is the best by far if you do Web Development.
I am curious so I have looked at other things like django, CakePHP, Zend etc but I have never find something as good as rails. Of course it is a matter of taste but I strongly advise you to try it.
Rails is not only an MVC. It is an easy to use MVC.
Ruby != Rails.
But Ruby gained an huge increase in popularity with Rails
Readable syntax
exit unless "restaurant".include? "aura"
You can try to take this interactive online tutorial (15 minutes) to see if you like the syntax.
Ruby is a general-purpose scripting language which has been incorporated into web design, and PHP is a language created for use in web design. (that's not a pro or con for either, merely a point of clarification)
If you already have experience scripting with using Ruby, it's easy to take the next step and incorporate it into your web design (as a corollary, it's also easier to pull Ruby code out of your web design and test it as a standalone script)
For many people/projects, the differences aren't monumental enough to warrant starting over with a new system. I'm somewhat of a Ruby evangelist but I would have to say if you already know PHP well, you will likely do better to stick with what you know. Certainly do not completely re-write a working PHP web application from scratch in Ruby without a lot of thought. This is a source of frustration for a lot of people (as you have probably read in your aforementioned rants) that can unfairly leave a bad taste in your mouth about a language or framework
Ruby is relatively new.
Therefore most tutorials using Ruby are using the latest best practices.
It does a lot of things differently to other languages, so it's a language you either love or hate. I personally am not a fan of it, and I'm sure a Ruby fan will come along soon and give a long list of advantages. And shortly after that, this question will be closed as subjective.
Ruby block is totally awesome!
You can create a DSL ontop of it and improves code readability which you can not achieve with anonymous function. One trivial example is like this:
def it(expect)
yield expect
end
it 'should do as I want it to be' do |this|
puts this
end
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have heard a lot about PHP frameworks like ZEND, CodeIgniter,CakePhp etc and i am also well aware of some advantages of using it i.e. increased productivity,reduced errors etc but doesn't php framework make coding a complex process ? Doesn't coding without framework provides more flexibility ? Some people say you don't need any additional framework, as PHP is itself a framework.
So why there is so much usage of PHP framework ? Are frameworks really necessary in PHP?
This is a broad question and I think an important one. I am in the camp of NOT using frameworks unless absolutely necessary. The question is, when is it necessary?
First off, the thing that I think gave me this strange, allergic reaction to frameworks is that inexperienced coders want to use them for EVERYTHING, even tiny sites.... and it's bizarre. Maybe its through some need to make their resumes bigger by saying they've used codeigniter- but in my experience that doesn't make a damn bit of a difference. Hiring managers want SKILLSETS, not somebody that can read API documentation- which anyone can do. If you have working knowledge about program architecture and OOP principles, you're hired. If you don't, but you're a codeigniter ninja, .... eeehhhh.... ok?
Frameworks have their uses but I think when your mom wants to make a website for her bake sale then you can just slap a page together using a much lighter weight system. I don't sit in the camp of belief that you should include code "in case you need it". Over time, I have developed my own framework that is absolutely tiny, which is why every single web site or application I have ever built has ranked in the top 2% (though usually top 1%) of page load times in the world by google.
This is not to say they are bad- just don't go running off to use a framework because you want to put it on your resume- you're actually shooting yourself in the foot in the long run. Why? Because you won't spend time using the language itself, you'll spend time using the language of the framework. Take jQuery for instance- I avoided it for YEARS because it wasn't JAVASCRIPT. People scoffed at it- but now, when I go to a technical interview and I get asked (inevitably): "What is your experience level with jQuery", and I say "not much", and they for a second look surprised, but then I follow it up with "but I just wrote dependency injection via inversion of control in native JS yesterday"- I get hired ON THE SPOT.
Frameworks are great. Just ask yourself if you really need them. Particularly the question is: are the benefits of coding it yourself outweighed by the time benefits (don't forget about the learning curve of the platform) of the framework or not? On the one hand (non-framework approach), you learn a lot, and perhaps you take more time because you're working out your own kinks- but you learned a ton about the language itself (PHP in this case). On the other hand, you learned a new framework and maybe got a site up quicker that most likely is slower.
Wordpress is a great example of an overused framework in my opinion. Back in my freelancing days I used to take on gigs that needed me to "revamp a wordpress site"- only to find a site that could barely load because somebody plugged in every plugin they could find and made what was a stupid simple site into a tank with ungreased treads. It's OVERKILL in that case.
With my experience in CTO and Tech Lead positions, when somebody puts Wordpress and jQuery as primary points on their resume, to me that says "I don't know a thing about OOP and how to use these languages if required" which, in the real world (and I work on huge projects like windows 8 and other projects of that magnitude) - is OFTEN the case. Microsoft expressly forbids the usage of jQuery in their metro app system for MS released products because they want to show off their system dependency free.
Other companies, however, DO use frameworks. I just got off a project using Foundation and it was AWESOME- but that's because the architect of the project fully researched the framework and we used it RIGHT. The result was a fully responsive pristine code base that went from full monitor glory down to triscuit-sized smartphone screen awesomeness.
IN SHORT:
Frameworks, when used right, can be awesome- particularly for large projects (and I'm talking enterprise large). For smaller projects they aren't necessarily bad- but when they are used without thinking about their implementations, its like using a hatchet for a scalpel.
Just my 2 cents.
Doesn't php framework make coding a complex process?
It depends what you want to do. If all you're doing is creating a basic contact form for a site that is all static HTML, then yes using a framework would make it a more complex process. On the other hand if you're building a large scale app then using a framework would not necessarily make it more complex.
Doesn't coding without framework provides more flexibility ?
This depends on the framework itself, they aren't all the same. Some frameworks such as Slim or Codeigniter are very trimmed down and don't get in the way too much and so don't really impact on flexibility, some are more complex such as Symfony2/Zend.
Some people say you don't need any additional framework, as PHP is itself a framework.
They are right, you technically don't need a framework, you can do anything with plain PHP that you can do with a framework. Frameworks have really evolved from developers personal archives of functions and helper code. PHP can be relatively low level in that it doesn't have a ready made function to do everything you need. Before frameworks, developers tended to have their own set of helper code that would be reused on many projects. Frameworks are still essentially that, except they are collaborative projects that hundreds or thousands of developers contribute to.
One other benefit of frameworks is if you have several developers, and one has developed an application and you want another developer to contribute to it or take over it, then if the developer is familiar with the framework that was used he can get up to speed on the app much quicker than if it was written in plain PHP. Without the framework, the new developer would have to decipher the previous developers system before they even start to look at adding any new functionality.
Are they necessary in PHP?
No they are not, sure it is possible to code anything without frameworks. But it's more work, this is like: Why am I using C when I can do all the same by writing assembler?
So why there is so much usage of PHP framework?
The benefits of using frameworks is, that you can use many predefined things. For example, in most PHP frameworks you can use MVC Pattern. Sure you could also build your own MVC structure with flat PHP, but that is like re-inventing the wheel everytime again. Only thing is, if you have very specific requirements, you may can/should not use a framework, but in most cases the requirements are not that specific.
The point with MVC is only one of a lot benefits. Depending on the framework you want to use, there are specific benefits.
So, it is just like you said. By using a framework you can save time, because you don't have to re-invent everything that already exists.
You can see a framwork as a tool, that helps you to develop better and faster.
Edit: Like Ayesh K mentioned in his comment, it is also a benefits, that a framework is developed by many experts, so it normally is better code, following the principle: 'Four eyes see more than two'.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I was reading the article "PHP Sucks, But It Doesn't Matter" by Jeff Atwood.
In the comments he writes:
That said, I absolutely think it's important for PHP devs to be aware of the architectural limitations of PHP, and understand the alternatives.
What are those limitations and how do they compare with other scripting / weakly typed languages?
Also, what are the alternatives in those conditions where limitations need to be avoided?
There are basically two real limitations I see:
PHP is a fully synchronous language. This has impact on which things you can easily implement in PHP and which not. For example implementing a Long Polling driven chat application isn't trivial, because PHP would need block one process per chatter. I'm not saying it's impossible, you can hack around this limitation using some PHP Daemon library. I'm just saying that this is one of the cases where other languages, like JavaScript, are more appropriate (NodeJS).
PHP is slow. Please don't understand this an an offense. It's a fact that PHP - as implemented by Zend - is slow compared to other scripting languages. This typically is no problem when building websites, but you obviously can't do certain things: Implementing a ray tracer in PHP is definitely a bad idea - whereas in JavaScript you could do this.
But apart from that, I think that PHP is pretty multi-purpose. You can use it for nearly anything - and I do ;)
Take a look at the date. The article was written in 2008.
It means, that if you'll see the PHP5.3 advantages, you'll find there many things, like closures and namespaces, which were in other languages before. Some of them is already affected the architecture of famous frameworks, like Symfony.
And that list will never be complete.
Meanwhile, I meet a lot of people who think that "weak typing" language is an architectural problem itself.
Then, some people think that inline regex syntax is good thing in, for example, JavaScript, but others think, that "different language" must be written down in string constants there, as in PHP. Etc.
I'll take a stab at this without getting too into the nitty gritty:
The initial design of PHP as a collection of functions still shows through.
Object-oriented patterns that have been implemented in the latest PHP 5 releases are still half-baked and lack multiple inheritance (or "mixins"), proper module support, and are designed to be backwards compatible with the CoF (collection of functions) design.
Method overriding and callbacks are not supportive natively.
Closures. They are there, but they are very weak.
Errors vs Exceptions — methods are inconsistent in which they use (thanks again to CoF design), and error-handling is half-baked.
I'm sure I'm stepping on someone's toes here and I'll get any angry mob, but I'm also sure that I still didn't hit everything. It's largely subjective, but it's easy to see what is to dislike when you stack PHP up next to Ruby or Python.
I don't find it odd anymore that all of "PHP SUCKS" articles are coming from developers accustomed to established Microsoft technologies.
What I do find odd are statements that indicate that PHP is a spaghetti code. It's completely up to the author of the code whether the code will be spaghetti or if it'll use certain design rules when approaching the problem.
The reason a lot of PHP code out there is spaghetti code is because examples and tutorials are such that they don't teach beginners the good coding practices. Also, people are quick to grasp examples like hello world or connecting to MySQL, doing a query and looping over the result - but that's it, that's where ALL tutorials stop. I still haven't found a tutorial that covers the following:
what is a framework and what it helps with
what are data structures and data types (explained in a way a normal human can understand)
what is an array, what are array dimensions, how do arrays work, what are arrays useful for
what is object oriented code, why object oriented code, how does PHP do it, what is considered good, why are there patterns out there and so on
As you can see, a beginner programmer won't be bothered to learn all of those points outlined above, I know that because I was a beginner too and did all the mistakes beginners do. However, even if someone doesn't know how to program, they can still create useful applications.
Many popular scripts were written by people who knew WHAT they want to achieve, however they did not know HOW to properly design the environment (framework) in which they'll deploy their php code.
That's why we see scripts that become incredibly popular due to the ease of their use as a regular user which are hard to extend looking at it as a developer, using weird function names, odd coding conventions and no commenting.
Also, what's ridiculous is saying PHP is slow which is absolute nonsense. When I come across such statement, I want to shoot myself in the head for reading such a blog entry.
One has to know several things before making such a statement:
PHP is a scripting language, that means the interpreter is invoked every time someone requests a PHP page which takes A LOT of CPU power. That has been addressed by using bytecode caching mechanisms such as APC which stores the copy of pre-interpreted piece of the script in memory. The results are impressive, and I kid you not - execution for some of my scripts goes from 20 milliseconds to 1 microsecond, where some benefit "only" 5 times. That's on a system that serves 1 thousand concurrent users. Now, if someone wants to tell me that 1 microsecond is slow (or 5 milliseconds) - I'll take that as bullshit.
PHP is not the only thing involved in serving a web page. There's also underlying server (Apache) which has its own issues, there's MySQL which runs queries - and who says all queries are optimal? There's the network, there's the hard disk, there's the CPU, there are tons of other processes. Configure Apache with PHP-FPM, optimize MySQL to perform good on 8 core machine with 16 gigs of ram, use APC, use Memcache - and voila, you're getting an incredibly fast, scalable system capable of serving an incredible amount of traffic.
Languages that PHP is being compared to are often "compiled" into the bytecode and then executed by
You can extend PHP yourself. Assuming a PHP function is slow, NOTHING prevents anyone from creating a .so in C that is able to do the job faster and then hooking everything up trough extension in PHP. Not that I know what would such job be that would require that, but such a thing IS possible.
Sadly, and I say sadly because I respect certain programmers and admire their work (and I'm by no means a PHP fanboy) but it hurts me when I see uneducated, inexperienced and subjective comments about a tool which spreads misinformation.
As for why big websites use PHP - because it's fast. Because they laid proper foundations before starting the projects. Because it's free, extensible and scalable. Because it follows C syntax. Because you can extend it when you need it to be faster. Because it runs on a free operating system. Because it's easy to use.
PHP is improving everyday. It is open source and used all around the world. That said, when you have a problem, it is most probable that you will find your solution or get help faster than any other language.
The very reason of this article, I believe it is simple. If you (or in that matter any other programmer) used to code in C++, Java etc.. they had a lot of possibilities such as OOP coding and PHP was limited in the beginning.
It is a good thing that PHP has many built-in functions / methods / classes so you don't have to spend hours to code some function / class / method which PHP already has.
You don't have to (and you shouldn't) try to memorize all these functions. It is useless to memorize all of them (which one is doing what, how to use it etc). Imagine you are working on some project which took you 4-5 months to finish (yeah big one (: ) You are not going to use all these functions in all the projects and eventually you will forget what they were doing since you don't use them often.
The point is, you should know the syntax of PHP. When you need to do something, check first if PHP already has what you want to do in its library. Check the manual to see how to use it. This way, you will also LEARN (NOT MEMORIEZE) the ones you use often and this information will be hard to forget.
PHP or any other programming language is just like a normal language which we humans use daily to communicate with each other. If you don't use it, you will forget.
PHP 5.3 and above brought many features. Static feature is one of the biggest feature for me. It made my life so much easier that I can't even begin to describe.
Since PHP is that famous and open source web scripting language, Facebook developer team created HipHop.
What HipHop does is, takes the data from PHP and sends it to C++. C++ does all the process and sends back results to PHP for outputting.
The whole idea of HipHop was to make Facebook use less servers & improve the page display times.
Now you tell me if this seems limited and / or slow to you?
i dont think there is anything like 'architectural limitation' for php. developer knowledge limitation might be the reason. read this http://www.quora.com/What-is-Facebooks-architecture . most of the time, non-world-class developer does not know how they could use php to its full capabilities.
I would assume he is referring to the fact the the OOP portions of PHP are not the greatest compared to languages that are purely object oriented.
Architecture Limitations in Addition to nikic's answer
Writing extensions for PHP is a PITA. Not as bad as with Perl or Java, but not as easy as it could be. The ease of extensibility champion is still TCL which hails from the early 90's. Nearly any C function taking char* can be made into a TCL extension.
Embedding PHP in other systems. mod_php, gtk.php.net shows it can be done, but Guile and TCL are much easier to embed.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
As a web developer, is it worth me learning the programming language C? Will I ever need to use it? I am currently using PHP and Ruby on Rails.
The unending pain of getting C programs to actually work reliably will teach you a lot about why PHP is a more civilized way to write software.
And yes, you'll use it eventually.
Some day you'll run across a problem ill-suited to PHP or Ruby. You'll be able to fall back to C and look like a hero because you know something more than other folks.
Not really. If anything, learn C because it is fun, and a great language to help you learn more about system internals. Working on web development is very high-level, and you won't get much chance to really get in-depth with the system. Using C can help you better understand how instructions are executed at a low level, how memory management works, and how to create a lot of the things that PHP / Ruby have built in.
Joel Spolsky urges computer science students to learn C:
"Advice for Computer Science College Students" (January 2005)
Learning Latin has it's benefits for understanding the structure of modern derived languages; so in that vein, I say why not?
I've found it very useful knowing C as a web developer. For example, one web app I've written includes a photo gallery. It stores the photos outside of the webroot so that it can check the user's permissions before showing the actual images.
Eventually, I discovered that the overhead for displaying a page full of image thumbnails was incredibly high using the web app in PHP. So, I rewrote the actual photo display code in C as a cgi program, which reduced the overhead to almost nothing.
I don't think learning ANY new language is ever a "bad" idea. Specifically to C, it can only give you a better understanding of how the languages you are using run "underneath the hood".
As others have stated you may not use C, but there are still a number of important concepts relevant to computers and computer science. Some insights can be gained from such classic texts as C Programming Language, by Kernighan and Ritchie.
This includes
Example of very good documentation and writing style in explaining a language in a brief document. You'll find that the complete language is explained in a book not much more than 100 pages. Compare this with some of the tombs of books sold today which position themselves as teaching a language and yet are often more than rehashed API manuals.
Understanding pointers, memory management, arrays and character indexes. All good information which aligns with core computer subjects; albeit low level, but a worthy piece of information for an professional programmer.
Its an easy quick reference book. Again you won't break an arm lifting it and yet gain a lot of knowledge from it.
In general C is useful for those occasions when you really do have to get closer to the machine or need to extend a language through use of a C-API.
Firstly, you have to define "web developer." Are you building websites or web-based software? While both of these tasks easily can fall under the category of "web development," they are somewhat different in terms of the skills set you need to be successful at it.
You're more likely to run into background processing and file/operating system interaction with software than "just" a website, and thus increasing the probability of using a low-level language like C.
Having said that, will you ever use it? Unlikely. High-level languages have been introduced by the dozens to tackle web development. From a web development point of view, if you're having to resort to C, it's most likely because you don't have the necessary skills in more suitable languages. Remember the massive amount of sites and software solutions of varying sizes that run fine on PHP and Rails.
Is it worth learning? Maybe. If you feel like you need hardcore programming skills to complement your web development skills and you have time to spare; go for it. If not, don't. You're probably better off getting really good at Ruby/Rails instead.
Speaking from my own experience, insofar as going from Python to C (and back again, woo!): Yes - learn it.
If you haven't already, learn fundamental, low level data structures; learn them well.
Learn what really makes an HTTP post tick, maybe write some low level debugging tools for yourself and others. It's amazing at how "under the hood" you can get in web development, when you can write an apache module. (Huzzah, bucket brigade!)
Learn the in's and out's of setjmp/longjmp, and perhaps come out with a better understanding of exception handling - that is, how it really works under the hood - in higher level languages.
You might never find yourself writing a line of C code for web development, but if you learn the language well, you'll be giving yourself an edge, all the same. Just be sure not to cut your toes off with it. (:
You'll probably never have to use it, so if you just aim at "usability" just forget it. However, learning C is a good way to get a grasp on the fundamentals of programing. You'll probably gain a much deeper understanding of PHP and RoR for free.
Bug generally, if you feel confident in your languages, no -- it's not worth the price ;).
Although I don't use C anymore, I find it useful to be able to talk to other programmers in their language. You may not have the expertise to solve a particular problem yourself, but you can talk intelligently to someone who can.
The same goes the other way, of course.
And, as pointed out above, C is the foundation of just about every other language that has come after it.
Learning a new language is always a pleasant experience and have a positive impact on the way you program.
Are you going to use C in web development. The answer is, most likely, no. Unless you are going to code a PHP extension or a custom web server.
Its always good to learn a new language , since you are already using Ruby and Rails framework . Knowledge about C programming will come handy when you are trying to learn in depth about Ruby scripting language , Since Matz Ruby Interpreter or MRI is written in C . And also most of the Web servers are written in C and C++ programming language .
Once you have an Idea how Web Servers works , you have an edge in creating a scalable applications , and will also able to analyze plus and minus of the Web Servers above which you are deploying your application.
"Be Jack of all you can be Master at any programming language and at any point of time in your Career" ....:)
Learning more languages is always a good idea. C is great, because a ton of languages are officially or unofficially based on it, and knowing what happens at a lower level can only help.
OTOH, to really advance your knowledge, I'd suggest learning a language that is as drastically different from what you know as possible - Erlang, LISP, Haskell, Smalltalk...
I'll put it this way. C is nuts. It was written in a time before people thought in entirely object-oriented ways. It will frustrate the crap out of you. Its hard to understand AFTER learning things the way you know them now.
But it is immensely helpful in understanding how everything else runs. Its a great language to help you transition to other languages because most modern languages inherit from or are built on it (syntax, data constructs, etc).
Moreover, both Ruby/Rails and PHP are based heavily in C. A lot of supporting libraries are written in C for those languages. Its crazy fast because it's compiled and is quite a bit lower-level, has a much smaller API than either PHP or Ruby/Rails.
I would definitely recommend learning it, even if its just for the fun of learning a new language. My prof always told me: "If you can give me a manual and a project worth working on, and I'll learn any language." So if you can find those two things, go for it!
I say, I say, I say:
Yes... but just a bit.
Just least some very basics: strings, pointer manipulation...
Even if you never actually use it, you'll get much better understanding about performance issues in higher lever languages. Consider strings we're working with all the time:
links are hard by Joel Spolsky
If you learn there is a great chance of achieving success, otherwise there will be no doubt.
Learning languages is never a bad thing. But as a web developer I think your time would be better spent honing on another technology. I've delved in Rails, and Java, but think if I really wanted to learn something new as a web developer, I'd be all over Django, google app engine, javascript, silverlight, flash ... and a handful of other technologies before I even thought about c.
In my opinion, for someone who writes software that runs on a computer, learning C is like learning Latin or Greek for a scholar of anthropology or literary science.
A significant body of the work that has been achieved in software development today has been done in C and that is what you really want to learn: it's not so much about writing your software in C, it's about being able to understand. Both what is possible and what has been done. Were everything comes from and also why we are moving more and more away from C in many areas.
Happy Segfaults! ;-)
The opportunity cost of learning C is high - you can learn something practical instead.
If you are a web developer and wish to continue to be one, it would probably make more sense for you to learn something more applicable to your field: Ruby and figure out how Ruby On Rails works, Python and how Django works, C# and how the MSFT MVC works. Or Flex. Or JavaScript and mooTools/JQuery.
While you can get a lot of basic computer science concepts out of learning C, you will probably never have to touch it. When/if you do, you'll learn it then.
If you wish to learn computer science ( not just slightly lower-level programming ), you can try Project Euler or some algorithms, operating systems, etc literature.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am mainly looking for good development practices specially when working in conjunction with mysql. I searched through the questions but could not find any related questions. I would appreciate if some one share their practices and wisdom gained through experience.
Apart from some coding standards, I am also looking for design standards and common architectural practices.
Background: I started my career with Java, and over the years I moved to C#/.NET space. I have been practicing architect for over 3 years now. Just added this to give some idea to people.
I would suggest that you familiarize yourself with the history of PHP, I know that doing so has given me a much greater appreciation of what PHP is today and where it has come from.
In short, PHP was written by Rasmus Lerdorf to provide simple wrapper functions for the C code that was actually doing the heavy-lifting so that he could have a simpler language / syntax for writing templates that needed to behave dynamically. The growth of PHP and the community which surrounds it is best described as organic. And much like other things that grow organically, its more than a little messy, asymmetrical, and downright non-congruent.
Once you understand PHP and its community, you need to embrace PHP for everything that it is and everything that it is not. This idea was best presented by Terry Chay in his article PHP without PHP. He's specifically talking about the concept of funky caching, but he captures the concept of coding for PHP as if it were PHP and not (insert favorite language here) better than anyone I've ever seen. In other words, don't try to make PHP into Java, C#, Ruby, etc because if you do you'll fail and you'll hate your life.
Take a look at
How is PHP Done the Right Way?.
I must say that you must first, last, and always avoid the tendency of most beginning PHP developers to use the spaghetti-code anti-pattern. In other words, if you find that you're writing code that contains sql queries, manipulation of data, validation of data, and html output all in a single php script, then you're doing it wrong.
In order to avoid this, it will be helpful to learn something about the nature of web-oriented design patterns. This of course precludes a familiarity with object-oriented programming. But once you've learned the basics of object-oriented programming in PHP, study the MVC design pattern. You don't have to implement this exactly but using the basic ideas of Model-View-Controller will allow you to avoid the blob script problem that most newbies tend to create.
On this point, I would strongly recommend that you take any code snippets you find on the web with a grain of salt. And even if you find it in a book you'll have to consider how old the book is. PHP as a language has advanced quite a long ways and you can't just take code samples at face value because, depending on their age, they may be using workarounds that were valid in 3.x or 4.x but simply are no longer necessary with newer features.
One great thing to do is to study the various frameworks out there. Evaluate what you like and what you don't. Maybe even work up each of the quickstarts that are provided with the framework documentation so that you can start to get an idea of what you like and don't like. And I would strongly recommend that you review the code from the frameworks as well as several other open-source projects so that you can get a feel for how others do things in PHP. Again, take it all with a grain of salt because every PHP developer has their own pet peeves and nuances and none of us is right all the time. In fact, most of the time with PHP there are going to be several pretty good ways to do something.
If you want to get a better understanding of the patterns that are being implemented by the frameworks and are commonly thrown around in the common vernacular on SO, I would suggest that you read Fowler and GoF. They'll teach all about the basic design patterns you'll use in your development efforts.
Specifically watch for the following:
Function files that contain LOTS of functions. This is most likely representative of a need to either put functions directly in the scripts that need them or it may also indicate an opportunity to create some more generic functions that can be made to fulfill the roles of a couple of highly specific functions. Of course, if you're building cohesive, well-encapsulated classes you shouldn't run into this problem.
The do everything class. This is a blob anti-pattern and is really nasty. In this case you need to identify where cohesion and encapsulation are breaking down and use those points as opportunities to break up the class into several smaller, more maintainable classes.
SQL queries that don't use parameterized queries or at least escaped parameters. Very, very, very bad.
Any instance where validation is not being performed or is only performed client-side. When developing for the web, the only way to keep your site and your users safe is to assume that everyone else is a black hat.
A sudden obsessive desire to use a template engine. PHP is a templating language. Make certain that you have clear reasons for adding another layer onto your website before using a template engine.
For further reading please look at the following:
PHP Application Design Patterns
Defend PHP -- useful to give you an idea of the most common criticisms.
Security of strip_tags and mysqlirealescapestring
What should Every PHP Programmer Know
How to Structure an ORM
Best Way to Organize Class Hierarchy
Main Components / Layers of PHP App
Why use Framework for PHP
Recommended Security Training for PHP
Use a coding standard.
Use unit testing. PHPUnit and SimpleTest are the major xUnit systems in PHP.
Be object oriented.
Use version control. Any version control, just use it.
If applicable, use a framework. Zend, CodeIgniter, Symfony, and CakePHP are the major ones.
If no framework, at least use an ORM. Propel and Doctrine are the major ones.
Document. Heavily. Use PHPdoc or similar.
There are a wealth of tools out there for PHP. Please use them, and write good maintainable code. You'll make everyone happier.
Use PDO or mysqli. Using one of these will give you prepared statements, which are safer and more efficient. I can't believe how many examples and tutorials I see using the ancient mysql interfaces. PDO would also make it much easier to switch to a different database system, should you decide to try postgres for instance.
You might look into using Doctrine (http://www.doctrine-project.org). It has a bit of it's own learning curve, but provides very convenient functionality. The handiest parts, for me, are the table creation/test data loading functions. Personally, I prefer to write my own SQL and execute it with PDO, and not use an ORM much in production.
Mainly, learn about SQL and MySQL. http://www.kitebird.com/mysql-book/ this book is excellent. The PHP aspect isn't very intense; PDO takes care of most of it.
Zend Framework's "Coding Standards for PHP" is good starting point. Check also this post.
Your from a Java background, and much of the OO stuff in PHP is very Javaesque. This means many of the design patterns you (hopefully) learnt in Java also apply (to a lesser extent) in PHP. An example for database access would be the DataMapper pattern.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I almost never hear the word CakePHP without hearing the word Rails shortly afterwards. Are these two frameworks mainly similar based on how they adhere to the MVC model or do they have other significant similarities/differences?
One of the main attractions of Rails for me is how easy it is to do Ajax. Would that also be true of CakePHP?
CakePHP is like a cheap, bastardized ripoff of Rails. It tries to be like Rails without doing any of the stuff that makes Rails great. It kinda feels similar, I guess.
CakePHP has an Ajax helper that does something similar to the Ajax-related helper methods in Rails, so yes, in some way, it's also true.
But CakePHP is really an exercise in futility: its authors wrote it so they wouldn't have to learn Ruby, even though learning Ruby and Rails together is probably easier than figuring out the monstrous mess that is CakePHP.
(This, coming from somebody who does CakePHP at his day job.)
Since y'all asked, my biggest complaint about CakePHP is how it manages to totally butcher the conveniences of object-oriented programming: sure, it implements the Active Record pattern just as much as Rails does, but it makes you pass around data structures.
I feel like any logical person would implement an ORM using faulting and dynamic loading of properties in to objects, which is exactly what ActiveRecord (the Rails library) does. The whole idea of setting a member variable called $recursive to determine which relationships to load is just plain flawed.
Being based on PHP is pretty fatal, too; you can't do anything with global state, you have to depend on mod_rewrite, you pay the startup penalty on every request. Sure, there's optimizations for any environment you're using, but still. People say Ruby is slow, but my own Rails apps run faster than their CakePHP equivalents, last I checked. I admit to being without data on this.
Worst of all, the bugs in CakePHP just about kill it for me. I could tell any number of stories about
the time we spent two days figuring out why CakePHP refused to connect to the right database host
the time half of our pages went blank because of the memory ceiling from using too many components
the amount of code that lives in our AppController because every component load costs several megabytes of memory
the black art of massaging data structures to make XML output work correctly
how we traced down the blank <javascript> tag that shows up at the end of every page
Cake is laid out much like Rails and obviously takes a lot of inspiration & ideas from it. Cake is a nice introduction to MVC frameworks and rails seems pretty straightforward coming from cake experience.
Ajax is super easy with Cake using the JS helper. In fact everything is super easy. Its a great framework, especially for distributed apps (eg cms's) or any other situation where the ease of hosting a php app is a benefit.
I would see the main advantages of rails being Ruby (and therefore the better OO implementation of rails etc) and the community. Gems (much fewer / less comprehensive cake plugins), training materials online, books (eloquent ruby anyone?) meetup groups etc.
I haven't worked with CakePHP, but my impression of it isn't too good. If you're after a Railslike framework for PHP, I think you may be better off looking into Symfony. It's probably a bit more complicated to get started with, but the whole project seems much better organised than CakePHP.
Of course, take with a grain of salt, since these things are quite subjective.