thehippy

Testing is probably best done before you write code, it makes you think through the functioning of code. But its just as viable afterwards, though it will seem as extra work at that point. Test Models, Test Forms, Test Classes, Test the UI, Test Controllers Testing models and classes are the easiest, forms and controller testing require a bit more work and UI testing (which I haven't seen done much with webapps) can be the most difficult. But with all things practice will make easier. PHPUnit, Phing, Jenkins, PHP_CodeSniffer (phpcs), phpmd (php mess detector) are all tools I use while testing. Selenium is pretty standard for testing the UI I think. Jenkins is a continuous integration server, which I have configured to pull from my subversion repository and run several tasks against the codebase. Currently it runs my tests, checks the code coverage of my tests, tells me all kinds of good stats, gives me pretty graphs, runs phpcs, phpmd, phplint. Its really a nice reporting feature to automatically do the things I should be doing while I code. While I code I'm always coding tests then writing code to pass tests, committing to subversion after pass and doing that over and over, so sometimes I forget about phpcs or another tool having the CI server catches my ass in all the things I should be doing. I used to have phpcs and phplint checks on my pre-commit hook in subversion, but it was a pain to get working environment to environment. A CI server can automate a great many things and make life simpler, though the setup takes a bit of time. ZendCasts had a few Unit Testing vids, and while he makes use of the Zend Framework, its good introductory testing info. Setting up Jenkins for PHP Prjects Template for Jenkins Jobs for PHP Projects Another useful source of information are the IRC channels on Freenode.net. Nearly all of the bigger PHP projects have a channel there, where they talk about the project and offer help.

Read the following: http://en.wikipedia.org/wiki/Public_key_infrastructure http://en.wikipedia.org/wiki/Digital_certificate http://en.wikipedia.org/wiki/Transport_Layer_Security http://en.wikipedia.org/wiki/Server_Name_Indication

Unit testing often is helpful in debugging, phpunit is great for that. If you want more descriptive debugging check out the xdebug extension (xdebug tutorial), its been around for awhile and is supported by many IDEs and other tools (like phpunit).

Been using NetBeans for awhile but I thought I'd give JetBrains PHPStorm a try. Its a very nice product, quick, excellent code completion and does double duty as a js/css IDE which I find myself using more and more lately. I may actually pay for an IDE, didn't think I'd ever say that. JetBrains made IntelliJ IDEA the Java IDE if anyone is familiar with it, good quality products out of that company.

I think you can take many approaches to finding a framework that you might get into then. The first is to simply find a framework that is lightweight or minimalist enough to suit your programming demeanour, there are plenty around. Agile Toolkit and Simple PHP Framework come to mind off the top of my mind. The second approach you might take is utilizing only the parts of larger projects you need. A great many frameworks are loosely coupled and do not explicitly rely on other components in the framework. Perhaps a third avenue available to you is to make use of a project like PEAR, again utilizing only the classes/modules you need. Rasmus Lerdorf would probably suggest you to go the no-PHP Framework approach. Lastly would be the option to write your own, build up your own toolkit refine and refactor it make it the sharpest tool you have. Give yourself some experience with frameworks, I would think most people interested in them try more than few. I had been perfectly happy using PEAR for years before I tried CodeIgniter which I disliked, so I tried another and another. You can learn for yourself whether its worth it or not to make use of a particular framework.

You could technically start applying now, but are you ready to? Here in Toronto, entry level positions and internships usually require a computer related bachelors degree. Having a degree tells the employer, well this person knows about fundamental programming concepts and has some basic experience with programming. Even with a degree, they will want to see some proof of interest in the subject matter, this will require that you have made or have contributed to the programming of a few PHP applications. Given no formal education, I would suggest you try to attain a certification or two proving your knowledge of the subject matter. Zend Certified Engineer for instance is a certification covering the breadth of the PHP language. Apart from the core PHP subject, search out what related skills employers in your area expect of a PHP developer. Understanding the LAMP environment will help you out a great deal. OOP, Unit Testing, CI, RCS, Agile, TDD and other such words are important jargon to HR people, but you'll want to understand and give yourself experience using such things. Another thing I would emphasize is being able to communicate effectively with other programmers. Pick up a book or ten on PHP, software design, database design, design patterns to expand your knowledge and skill set. And most important of all, don't just read about PHP, use it. So, how long before you're ready? I think it would really depend on your motivation to learn and your confidence in programming in PHP.

Its been my experience store sites tend to get out of control on the coding side of things. I'd head towards an existing application and modify it to your needs. Magneto, osCommerce and zen cart are popular open source shopping cart solutions. They all support an impressive number of payment gateways by default or supported by their communities.

This could be a troll-like question, but given your admitted inexperience with frameworks I'm interested in your answer. What does bloated mean to you? When is a framework useful (or feature rich) and when is it bloated, where is the line drawn?

From my brief read through of the hcard 1.0 specification, yours is not valid because all hcards must have a name or organizational name attribute. Though not required telephone numbers should to be formatted in international standard +15553334444, multiple telephone numbers should have a type attribute, and your address elements should have attributes added. Again I only just briefly went over the specification, refer to it. You can use the hcard creator to make a quick example.

Had to look up what microformats were.... Fairly simple, a specification for formatting data in a standardized way. What are microformats and what can you do with microformats articles explain what they are in enough ways to make it easy to understand. And the specifications for the various microformats listed on that site provide examples, making it all less complicated. A couple things come to mind first about your problem. Are you providing all the data and markup necessary by the specific microformat specification you're using? Is the specification(s) you're using supported by this woorank site?

In your httpd.conf, Line 461 and 462 Unquote the first line and delete the second and then restart Apache.

There isn't a service class for supporting the Google Webmaster Tools (GWT) API specifically. The Google data protocol is supported by Zend Framework with Zend_GData. GWT is based on 'feeds' or resources, whatever you wish to call them. Using a Feed with Google Data Protocol - From Fetching a Feed $gdata = new Zend_Gdata(); $query = new Zend_Gdata_Query( 'http://www.blogger.com/feeds/blogID/posts/default'); $query->setMaxResults(10); $feed = $gdata->getFeed($query); Of course with user specific data you'll need to authenticate before querying.

Can you show us your whole httpd.conf? Remember to enclose it in code tags

hrmmm... Try removing the <ifmodule> argument from the first block in the .htaccess, comment out the second one. Lets try to get more info try enabling Apaches access log and see if that reveals anything <link to MAMP docs> Check the permissions on the .htaccess file, does Apache have sufficient permissions to read it? The error you mentioned is because Apache can't connect to a jrun server (a java application server), its probably not running. Shouldn't have anything to do with the mod_rewrite problem you're having though. This is probably all something very simple and we're both overlooking it.

Is the mod_rewrite module being loaded in the apache configuration? If the line is started with a hash (#), its commented out and disabled, just remove the hash and save the conf you'll have to restart apache afterwards. It'll be something like LoadModule rewrite_module <mod_dir>/mod_rewrite.so If that's not the problem, check the access and error logs apache makes and get back to us.

In addition to thorpe's post I would suggest a solid understanding of database design and at least a basic understanding of database administration.

If all else fails, google is your friend. Try doing some file type specific searches, plain text files can yield a surprising amount. Googling "filetype:txt airports" comes up with some possibilities. Who knows if that kind of data is reliable though.

PHP as you know is an interpreted language and has been around a long time, not only that it grew up in an environment where speed is important. PHP parses files quickly, be as verbose as you want with your code and comment the hell out of it. While in theory the things you mentioned may impact how quickly a file is interpreted the practical result is insignificant. Nearly all production servers have a PHP cache of some kind run from a opcode state throwing arguments of parsing time out the window. I think you may be under the assumption that parsing and interpreting are the same, but the truth is parsing is the reading of a thing and interpreting is the realization. It is true that the PHP parser will read all of your code, but this is mostly just a conformance test of the PHP language, when it comes to interpreting the code it will only execute the things based on your code flow. Say you have and if/then/else, if the condition is met, do a loop, if the condition is not met, do a different loop. If the condition is not met, the code meant for the true condition is never run. So when you ask if unused functions get read, well they get parsed, but if they are never run in code they are never executed. include()'ing files is a slightly dangerous thing if you're not wary and in your case if I understand it is not what you need. Using include() is to slurp up a file and have it inserted at that point in your code as it were more PHP. The better approach is to point the browser towards the file, simply echo or print a link to it and let the browser do the work. Under a caching solution this may be different, but for the most part letting the browser get the file is fine. A nested function is function within a function, not a similar function. As for similar functions convention says we should try mitigate duplicate code as much as possible, but if there is legitimate reason, like an improved optimization or external dependency go with the added function, just make sure to document it its use case. You seem to be overly concerned with performance for someone admittedly new to PHP programming. While not a bad thing, try to focus it a bit on things you can change, that is your code and as such the tools to help you do so. xdebug is a great PHP profiler, google it down and set it up on an install and you'll quickly develop an understanding of where bottlenecks lie in your own code and how to better adapt to them. If you want to learn more about PHP first off code and dive into the online manual, it has lots and lots of comments and examples and opinions. Its really one of the better language resources.

When I'm given a project that I'm unfamiliar at some level that has a real world analogue I go to the real world example to see how they do it. I'm not a fan of reinventing the wheel, I like wheels the way they are. It also gives me a dialogue I can share with my client. With financial information there are standards and practices kept, internationally and nationally, sometimes even by region. So, I'd start there with the standards, give them a solid read and while doing so try to come up with a model that will work in parallel. Read up on the Generally Accepted Accounting Practices (GAAP) and the International Financial Reporting Standards (IFRS) as a good start. You should also be aware of laws in your country and countries your application could be used in. Financial information is very important to people, corporations and more importantly governments and there can be some safe-guarding laws for keeping it electronically. As a PHP programmer I think we tend to get a little more familiar with databases, you'll probably have heard of ACID storage engines and transactional queries and dealing with financial information you'll want to definitely start utilizing them, making sure things are inserted or not, basically doing error-handling at the database. Balances are presentation values, they are the result of other hard values. Generally bookkeeping information you'll find is kept like a log, one you can only add to. It is also the source where nearly all information is extracted from. You put a negative amount (debit) into your record book and you can put a positive amount (credit). Balance is only a summation of values at a time in the log or a range of time, or some other metric.

Convert locations to longitude and latitude like Google Maps does, hell use their API to do so. Determine a suitable radius for your delivery zone by defining it in long and lat, compare with user's co-ordinates if they fit in your zone. Just a note for you, not everyone here is from the same country, mentioning which country you're in and therefore which postal code system you're using would help.

Class and method naming should be part of an overall coding standard [or style], that makes your code readable and maintainable. The PEAR Coding Standard is pretty much the matriarch of all the PHP coding standards, Zend and Doctrine use similar guidelines with a few variations, there are more and I'll leave you to find them on your own. Apart from a coding standard, with consistent naming conventions it makes reflection a bit easier, it makes apidoc's legible and it doesn't make other programmers tear out their own hair while reading your code. I don't know if many programmers do this, but I have a check-in script for my subversion repositories that does a check on my code. The script firstly does a php -l [lint] test to make sure the file is valid php and then I do a style check with php_codesniffer to make sure my code passes the Zend style guidelines. With 5.3 having namespaces and the bigger frameworks making use of them already, naming things have the distinct possibility of becoming very messy, very quickly. Without a followed convention code may start to look like vomit instead of code.

This ends up being a tricky behaviour to create, but if you specifically define the nature of the relationships of what you wish to recommend it becomes easier. If for example you wish to recommend 'rooms' that are similar, define what makes them similar, is it words, the nature of the content, some meta data or metric? I think a simple solution is to give users the ability to add keywords or tags, or else generate keywords yourself from user content. Then list the results however you wish to use them. You could also use keywords to calculate a relevancy score, calculating how many keywords one room shares with another for example. There are other far more complex solutions for understanding and creating relationships involving mathematical networks if you wish to search out those on your own. Understanding how indexes score results may help you out as well, if I remember Apache Lucene's documentation has some info that may be relevant.

Personally I had/have a real bit** of a time with application design and design patterns. As such I've gathered a few books on the subject. Martin Fowler, et al - Patterns of Enterprise Application Architecture This is a great primer and reference but its dry and full of industry jargon as you put it. Part one of the book is all about the how of design patterns, breaking an application down or rather building one up with application design. Its not very practical for PHP though, its full of UML and java examples, but still well worth it. Kevin McArthur - Pro PHP - Patterns, Frameworks, Testing and More (Apress) Just a really decent PHP reference, has a chunk at the beginning dedicated to OOP and design patterns. While it has PHP examples its not really expansive on the subject of design patterns, has just enough to tease you. Jason Sweat - php|architect's Guide to PHP Design Patterns Has a thorough review of design patterns commonly used in PHP with examples. While very good at explaining each design pattern and its usage, I feel its not great at how one should 'put it all together,' [the first part of the Martin Fowler book as an example does this well] but an otherwise very good book. Eric Freeman, et al - Head First Design Patterns [Obligatory O'Reilly Book] No examples in a specific programming language, the examples are done with UML. But the book is incredibly visual given the subject matter, lots of helper diagrams, pictures to help relate concepts. Its very refreshing compared to most design pattern material. P.S. If you have access to a course you can take that covers design patterns, take it. Worst that could happen is that you could catch up on sleep.

When I'm doing this kind of model conceptualization I think of each of the objects as a single instance of. My User model is a single instance of a user, that model has attributes and functionality of manipulating a single User. If I want to manage multiple User's I create an object that would have the attributes and functions that are relevant to managing many User's. So put against your first query about a Post object, yes I would most definitively have that as a separate model as it encapsulates the attributes and functionality of a post. Also User creating Post is a functional reasoning but we're not using a functional paradigm with the program, we're supposed to be thinking in terms of in objectifying ideas. Its a bit of a twist in thinking, but programmers are twisted out of necessity.

As anyone could guess, web application development isn't as expansive as other development platforms and its also a pretty young environment. Extreme Programming (XP) was the early adopted development methodology, superseded by Agile which is pretty prevalent nowadays. Test-Driven Development (TDD) has been taking root over the last year or two in the PHP world, I think mostly due to the adaptability and ease for small team and single developers, which the majority of website development gets done with. To be honest reading your post, I think you're over-thinking the whole process for two reasons the first is, you're admittedly new to web development. Its alright to learn as your go, take it in steps. Secondly and especially for 'a simple dynamic web app,' it should be simple. Code it out how you think it should done, code it out how a couple other methodologies suggest it be done and learn from the experience, you wont lose. So my advice is 'Dive in,' use your experience to try to build your app as you would elsewhere, just with PHP this time. Given that you already have a database schema, and use cases, its up to you but I'd push you towards developing with TDD, writing tests before code is the fundamental concept behind the TDD methodology. Then its a matter of writing code that doesn't fail. Just my $0.02.