40 signs you really are a lousy PHP programmer 

Disclaimer: This collection was published a few years ago on my blog, it was met with heavy criticism about featuring micro-optimiziations which have little to no effect at all compared to other things you can do which was then and is still today very true :)

As this was copied & published on a few hundred blogs in the aftermath here again the original list exactly as I published it many years ago.

I will follow up shortly with an article on more effective methods. Until then …

This is something I prefer to call my “programming list of shame”. Although having a formal university education with courses on software engineering, enterprise software architecture & database design I have been guilty of every single one of those things at one time or another. This is completely subjective & Eclipse oriented.

You are a lousy PHP programmer if you

  1. don’t comment your code properly with something like phpDoc
  2. don’t see the need and/or benefits of a good programming IDE like Zend Studio or Eclipse PDT
  3. have never used some form of version control like Subclipse
  4. don’t adopt some coding & naming standards and general conventions and stick to to them at least throughout the project
  5. don’t use a consistent methodology
  6. don’t escape and/or validate properly input or sql queries
  7. don’t plan your application thoroughly before starting to code
  8. don’t use test-driven development
  9. don’t program & test with error reporting on
  10. don’t see the benefits of a debugger
  11. don’t refactor your code
  12. don’t keep the different layers seperated using something like MVC
  13. don’t know what these stand for: KISS, DRY, MVC, OOP, REST
  14. don’t return content but echo or print it from your functions or classes
  15. have never seen the advantage of unit tests or testing in general
  16. return HTML, not data, strings, or objects.
  17. hard code messages and configuration parameters
  18. don’t optimize your sql queries
  19. don’t use __autoload
  20. don’t allow intelligent error handling
  21. use $_GET instead of $_POST for any destructive actions
  22. don’t know how to use regular expressions
  23. you’ve never heard of sql injection or cross-site scripting
  24. don’t allow simple configuration, can be parameters passed to a class’s constructor, set/get methods called later, or constants defined at a runtime.
  25. don’t understand the benefits and limitations of Object Oriented Programming
  26. misuse OOP / everything you write , no matter how small is OOP
  27. you think reusable software equals/requires your code to be OOP
  28. don’t choose intelligent defaults
  29. don’t have one single configuration file
  30. don’t want the file contents to be seen, but give it a .inc extension instead of .php
  31. don’t use a database abstraction layer
  32. don’t keep it DRY, Don’t repeat yourself. If you have to copy and paste or duplicate something your design may be off.
  33. don’t make a function/class/method do just one thing and don’t make them interact.
  34. don’t try to take advantage of OOP specific features like abstract/interface classes, inheritage polymorphism & access modifiers.
  35. don’t optimize your application design with established design patterns
  36. don’t allow your user to define a base directory if you have multiple files and/or directories
  37. pollute the global namespace, one option is to prefix the functions in your library with a common string
  38. don’t allow a table prefix when using database tables
  39. use a separate template engine
  40. don’t take a look at established php frameworks for inspiration, most of them have advanced web dev concepts and good code

Advanced CSS snippets collection 

Not one week passes by where I have the recurring pleasure of meeting someone who thinks frontend development comes easy and he could teach himself CSS in a day or two. Especially print designers seem to have a pretty rough time understanding why the pixel-perfect design they’ve created with their DTP tools seems to be taking forever to get right in the web.

If you feel like CSS comes easy to you or you know someone who thinks that way – how about you let him explain to you what these few CSS snippets do?

If you have cool css snippets feel free to post them in the comments. These are excerpts form deviantART and Adobe

	div.stream div.tt-w:not(:-moz-any-link)::after {
	    display:inline-block;
	    width:205px;
	    content:" ";
	    width:205px;
	    height:1px;
	    overflow:hidden;
	}
	div.stream div.tt-a:not(:-moz-any-link) {
	    display:inline-block;
	    width:205px;
	}
	div.stream div.tt-tv150>div.tt-w {
	    width:194px !important;
	}
	div.stream div.tt-tv150 div.tt-w:not(:-moz-any-link),
	div.stream div.tt-a div.tt-w:not(:-moz-any-link) span.shadow::after {
	    width:187px !important;
	    overflow:hidden;
	}
	div.stream div.tt-tv150 div.tt-w:not(:safari) {
	    width:194px !important;
	}
	.price {
	/*\*/white-space: nowrap; /**/
	_height: 1em;
	min-height: 1em;
	}
	/*\*//*/ span.price, /**/
	span[className~=price],
	a[className~=price] { display: inline-block; }
	htc-method: "$getFirstChild >$addClassToNode[p1-top-first-child]";
	_behavior: url(/lib/com.adobe/evaluateCss.htc);
	}
	.p1-top {
	htc-method: "$getFirstChild >$addClassToNode[p1-top-first-child]";
	_behavior: url(/lib/com.adobe/evaluateCss.htc);
	}
	.p2-top {
	htc-method: "$getFirstChild >$addClassToNode[p2-top-first-child]";
	_behavior: url(/lib/com.adobe/evaluateCss.htc);
	}
	.p1-top>*:first-child,
	.p2-top>*:first-child,
	div.frame>*:first-child {
	margin: 0 -8px .5em;
	padding: 6px 8px;
	font-size: .917em;
	font-weight: bold;
	line-height: normal;
	text-transform: uppercase;
	color: #111111;
	}
 
	*[className~=frame] { padding: 0; }
	*[className~=frame]>* { padding: 0 8px; }
	.top-acc {
	background-color: #DDDDDD;
	margin-left:0;
	margin-right:0;
	padding-left:20px;
	padding-top:12px;
	padding-right:10px;
	padding-bottom: 6px;
	}
	html:not([lang*=""])*.comma>li:after { /* Netscape 6 - 7 */
	content: ",";
	margin-right: 1ex;
	}
 
	.comma  li+li:after, 
	.comma  dd:after {
	content: ",";
	margin-right: 1ex;
	}
 
	*:first-child+html .comma li a,
	*:first-child+html .comma dd a  {
	htc-method: "$addTextToNode[\\u201a ,after]"; 
	padding-right: 0.5ex;
	}
	html:not([lang*=""])*.dash>li:after {
	content: "-";
	margin-right: 1ex;
	}
	.pullout-left > * > .inputGroup {
	display: table;
	margin-bottom: 0;
	}
/*\*/
* html #top img,
* html div.bubbleview img/**/ {
    filter:expression(
            this.napalmLoaded
            ? "" :
            (
                this.src.substr(this.src.length-4)==".png"
                ?
                (
                    (!this.complete)
                    ? "" :
                        this.runtimeStyle.filter=
                        ("progid:DXImageTransform.Microsoft.AlphaImageLoader(src='"+this.src+"')")+
                        (this.onbeforeprint="this.runtimeStyle.filter='';this.src='"+this.src+"'").substr(0,0)+
                        String(this.napalmLoaded=true).substr(0,0)+
                        (this.src="http://st.deviantart.com/minish/main/blank.png").substr(0,0)
                )
                :
                this.runtimeStyle.filter=""
            )
        );
}

Random observations about art VS design 

A potpourri of wise statements from all over the web on the difference between art and design.

  • Art raises questions, design gives answers.
  • Artists create something to appreciate, Designers create something to use.
  • Design is about solving problems, Art is about creating them.
  • Design is art without the bullshit.
  • Art is about creating things to communicate while design is about creating things to solve problems.
  • Art is “the products of human creativity” a definition of design is “the opposite of purposelessness or randomness.”
  • Design is the skeleton of what can become art if applied to figurative realism.
  • Design makes you think or do something, art makes you feel something.
  • In art, red is never “wrong”, In design, red can be wrong, and the wrongness can be described in both technical and conceptual terms, and sometimes even measured.
  • The product of design is an abstract (high level) artefact. The art is a concrete (in contrast to abstract) artefact. The process of realising both artefacts (abstract vs. concrete) can/and is the same in many cases.
  • Art is some guy using a medium to change how you see the world, whereas design is changing how we live in it.
  • Design is not art. Design is a strategic approach to effective communication through a visual interface.
  • The litmus test. When people enjoy Art, they say “I like that”. When people enjoy Design, they say “That works well”. This is not by accident. Good Design is something that works well.
  • The main difference between Design and Art is that Design has more constraints (budget, time, problem to be solved, etc.) while Art is only constrained by the artist’s talent and chosen medium.
  • Art hides. Art has a meaning, and it hides it, on purpose. Art delivers a message, and that message is hidden, on purpose. It is an art to create art. Art is unusable, by definition.
  • Design reveals. Design reveals meaning, design reveals a message, design reveals function. Bad design does the opposite: It obscures, it hides. The reason why that almost never makes bad design art is that the subject is supposed to be revealed.
  • Genuinely honest art is created without the market in mind – you are simply creating. Design is created with the market in mind– and the medium does not matter. If you’re a musician or painter, and purposefully crafting your work in order to sell, you’ve become a designer.
  • Art and design are interchangeable agents of language that speak differently within different contexts.
  • At their root, art and design are inseperable components within a creative endeavor. Where they are placed determines their function within society.
  • “Design is first and foremost an intellectual process. Contrary to popular belief, designers are not artists. They employ artistic methods to visualize thinking and process, but, unlike artists, they work to solve a client’s problem, not present their own view of the world. If a design project, however, is to be considered successful – and that would be the true measure of quality – it will not only solve the problem at hand, but also add an aesthetic dimension beyond the pragmatic issues.
  • I consider design not to be a series of “creative” one-offs, but an integrated process, from planning the appropriate communications strategy to designing functional and beautiful objects as well as – for example – implementing electronic stationery on clients’ systems.
  • What clients say and what designers hear are too often very different things. Design is a powerful tool to help clarify the problem. It is only when a common understanding has been established between client and designer that effective results can be achieved.
  • Artists do not work for an audience. They work for themselves. When designers work we should not have to worry about what our favorite color is, or whether or not it looks “nice”. Our aesthetics opinions really do not matter, we have to solve a problem, seperating ourselves from what the culture tells us what is “in”.
  • Design quality needs an integrated approach: look more closely than expected, ask many questions, think laterally, get involved in things you shouldn’t, do more than you are supposed to and have fun doing it. Problem solving is one thing, aesthetic pleasure another. Combine the two, make the engineer sketch like an artist and make the artist analyze like an engineer, and you are half-way there.” -Erik Spiekermann Berlin, March 2005

Web font armageddon – may the type gods be with us 

A little CSS snippet is about to change the face of the web as we know it. May the type gods be with us and lead our humble ways …

@font-face {
  font-family: "Your typeface";
  src: url("type/filename.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename.woff") format("woff"),
    url("type/filename.otf") format("opentype"),
    url("type/filename.svg#filename") format("svg");
  }
@font-face {
  font-family: "Your italic typeface";
  src: url("type/filename-ital.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename-ital.woff") format("woff"),
    url("type/filename-ital.otf") format("opentype"),
    url("type/filename-ital.svg#filename-ital") format("svg");
  }
h2 { font-family: "Your typeface", Georgia, serif; }
h2 em { font-family: "Your italic typeface", Georgia, serif; }
em { font-style: italic; }

PHP Evolution Philosophy 

I do not think much of a man who is not wiser today than he was yesterday. – Abraham Lincoln

Sometimes, reflecting on mistakes from the past – you wish you knew then what you know now. Here are a few of my PHP developer truths, learned the hard way by being young, stubborn and most of the times an arrogant prick, refusing to accept that others may actually know better.

  1. If you don’t know OOP and OOP design patterns, you’re not playing the same game.
  2. Code doesn’t exist unless it’s checked into a version control system. Use version control for everything you do. Any version control, SVN, Git, even CVS, master it and use it.
  3. Choose an IDE or any text editor, learn to master it and stick to it. If you have found one you like and feel comfortable with, never waste time reading about the perfect IDE again. It’s not the tool but how you use it.
  4. No matter how smart you think you are and no matter how readable you think your code is, commenting your code ought to be self-evident. Code alone only tells me what actually it does, not what it was supposed to do.
  5. The users aren’t idiots, you are. All user input without exception should be treated as if it had the plague. Quarantine it, sanitize it and stri it to the bones. PHP has an excellent and comprehensive array of filtering functions.
  6. Realizing something is “good enough” will be a major jump in your value as a programmer.
  7. Premature optimization is not the root of all evil, lack of proper planning is the root of all evil.
  8. Useful and clean high-level abstractions are significantly more important than performance.
  9. Programming actually has little to do with language and everything to do with algorithm.
  10. You should never test your own software, testing is about trying to uncover developer mistakes, find holes in their assumptions, and flaws in their logic, you simply cannot be objective about your own code.
  11. 90% of the project is completed in 10% of the time, unfortunately the remaining 10% is completed in 90% of the scheduled time.
  12. Tools, Methodologies, Patterns, Frameworks, etc. are no substitute for a properly trained programmer.

Typoscript snippet – intelligent HTML template layout 

From working with other CMS like Joomla, Drupal and WordPress I’m used to have a certain logic to my template. Assuming a basic three column layout (left sidebar, main content, right sidebar) this is one approach which I will continue to refine in a later article – to only show an area if there is actual published content in this assigned to it.

So, consequently, you don’t have to manually assign a different layout to pages, post, articles, … but only fill the areas with content and the template will automatically adapt.

This snippet will only wrap an area if there is a published content element assigned to it.

temp.LEFTCONTENT < styles.content.getLeft
temp.LEFTCONTENT.stdWrap {
	wrap = <div id="left"> |</div>
	required = 1
}
 
temp.MAINCONTENT < styles.content.get
temp.MAINCONTENT.stdWrap {
	wrap = <div id="main"> | </div>
	required = 1
}
 
temp.RIGHTCONTENT < styles.content.getRight
temp.RIGHTCONTENT.stdWrap {
	wrap = <div id="right"> | </div>
	required = 1
}

Assign the temp objects to available subparts in your HTML template file.

page.10 = TEMPLATE
page.10 {
 
	workOnSubpart = document
 
	subparts.leftcontent < temp.LEFTCONTENT
	subparts.maincontent < temp.MAINCONTENT
	subparts.rightcontent < temp.RIGHTCONTENT
 
}

More on styling these resulting areas soon …

Typo3 Typoscript snippet Basic configuration 

I develop a lot of HTML Typoscript templates for Typo3, without Templavoila or any other fancy extensions. With the release of Typo3 4.5 and the introduction of Backend Layouts there have been a lot of improvements which make Templavoila obsolete in many scenarios.

I will post a few Typoscript snippets I use in a lot of projects over the next few weeks.

Basic configuration stuff

config {
  language = de
  locale_all = de_DE
  doctype = html5
  htmlTag_setParams = lang="de
  prologue = none
  metaCharset = utf-8
  htmlTag_langKey = de-DE
  linkVars = L
  sys_language_uid = 1
  spamProtectEmailAddresses = 1
  spamProtectEmailAddresses_atSubst =  (at) 
}

What this does is to set the language to german, define language url parameters for a multi language setup and try to protect standard email addresses.

 

More to come soon …