Goals.

This is a rewrite to move to newer versions of PHP; use newer language features; write structure to current features in a cleaner fashion; move to a composer based system; and be able to import better tools. This does drop some features that proved unuseful; but nothing new is added until the current system is completed. Most of available time in the earlier version went on content; to improve my writing ability.
My first version (iceline v1) was written as a learning project; it was supposed to assist getting me a job. Started in 2009 I couldn't show previous use of PHP5. I was really professionally happy to be able to use interfaces and Exceptions again. This is not a relevant objective anymore. That this new build happens to be a public example of PHP7; I don't feel is as important, as I can claim use of many languages by now. Iceline v2 was to make the CMS more useful. My current requirements is just that I need render the content, or get a translator to host my content in another framework. Although my usecase does resemble Wordpress; I don't wish to use this. Alternatively I could have written this in Node, but didn't.

A second objective for iceline v3 is to manage in-browser code better. The amount of JS has increased in the last several years. There are features that are written in JS on purpose so they could be taken for other projects. The newer code structure would make it trivial to add the features to the PHP rendering stack. I researched AMD js-classloader, I'm not sure this is the right solution for here. I will merge and compress the JS, which will help. As I am on a shared host; there is little point in focussing on page render speed, on this site. I am writing about it instead, see php-performance, [XXX].

I could pretend that I wrote a business focussed project plan, but I didn't for my personal time project. I guessed it would be “about a month”, without any detail in my plan, and it was. At that point, I was working 1/2 days for an employer, I did 8h/d work on this project after this. When I work like this, I use alot of unit-tests to avoid fatigue errors. By the time this month was done, I had organised a few interviews, for my next role.

On TDD and Testing.

For this project, does this completed outcome have a reasonable test coverage? I think YES, all the risky code is covered. For this project, have I used real TDD? No, as I was reusing functions; and my previous tests where against my previous class API. Many of the tests where injected onto “alpha grade” code, as I can use a skel-gen. If I had to handtype everything I wouldn't make the investment. This is pragmatism.
The test suite is using the standard phpunit, which most value for locating typos. I am leaving all of the performance tests till after all features are complete. Due to having a spec before I start (the previous system), the newer code is many less operating lines long, so I expect it will be faster. This is a very inward looking statement; and comparison to Wordpress, a node app etc would be more useful investment.

TL;DR Section for recruiters

I don't sell myself as “a programmer”, this is not very employable. However for recruiters, who can't read code very well; this project demonstrates:

  • Normal use of OO.
  • Unit tests.
  • PHP7 features, including type validation.
  • Use of Symfony features.
  • Writing reasonable performance PHP.
  • Class responsibility factoring.
  • Correct use of DI.
  • Design patterns include Adaptors, Facades, Factories, Pipelines, Collections, MVC
  • Code like this is not the most valuable impact I can have on projects.

iceline Bundle

RSS. Share: Share this resource on your twitter account. Share this resource on your linked-in account. G+

iceline Bundle

RSS. Share: Share this resource on your linked-in account. Share this resource on your twitter account. G+ ­ Follow edited