Update some more posts.

1 files changed, 78 insertions, 0 deletions

diff --git a/_posts/2008-10-29-collaboration-in-development.markdown b/_posts/2008-10-29-collaboration-in-development.markdown
new file mode 100644
index 0000000..e048c71
--- /dev/null
+++ b/_posts/2008-10-29-collaboration-in-development.markdown
@@ -0,0 +1,78 @@
+---
+layout: post
+title: Collaboration in development
+tags: [ development ]
+published: true
+---
+
+I usually write after something big approaches me. This could be no bigger:
+_collaboration is not considered when developing_. Well, at least not lately.
+Here's what happened:
+
+[Roger Byrne](http://styl.eti.me) asked me to check a plugin and help him in a
+submission form. Roger said to me that the Javascript inside the wordpress
+instalation he already had was obtrusive and he needed to render the form with
+<abbr title="Cascading Style Sheets">CSS</abbr> only. So I did it; I delivered.
+He asked me why the form wasn't submitting. I didn't know because I didn't make
+the plugin. In either way, the plugin was kind of a mess. Between lack of
+standards and lack of a plugin workflow, me and Roger didn't figure out what
+was happening.
+
+So what do I mean with all of this? Again, collaboration is not considered when
+developing. Developers assume their code is flawless and it will work. However,
+they don't take a look at crucial guidelines of development: (Note: I'm
+thinking of plugins as I write this, but any situation is perfectly suitable.)
+
+Logical separation
+------------------
+
+Logic, content, generated content (different than just content), presentation
+and behaviour all set apart. Logic goes to one <acronym title="PHP: Hypertext
+Preprocessing">PHP</acronym> file, content goes to one markup file,
+presentation in a <acronym title="Cascading Style Sheets">CSS</acronym> file,
+special behaviour in a <acronym title="Javascript">JS</acronym> file. Generated
+content can be either part of the CSS or the JS, depends on what's its purpose.
+
+Concerning classes…
+-------------------
+
+_Concerning markup, please don't drown it in classes!_ Keep it with an
+all-around div with an id, most likely you won't need more, you'll most likely
+style the children elements from that single id. Also, don't flood it with
+unnecessary div's, it hardens its understanding and ... it really might be just
+clutter. Are they for IE? Use a [script](http://code.google.com/p/ie7-js/)
+instead. The client doesn't have Javascript? Get [Firefox](http://firefox.com).
+If neither, then you don't need any div's at all.
+
+Meta-information for each feature and a short glance at the top; easy to read
+and above all, summarize every major feature, so a thrown in developer knows
+what a certain code does.
+
+Comments,
+---------
+
+In the right place. Don't just write a comment line before every single line.
+Only some guidelines. One practice I really like is split the logic of a
+function into blocks like this:
+
+{% highlight php %}
+<?php 
+# Semantic block 1 {
+  $this->do_something();
+# }
+# Semantic block 2 {
+  $this->object->do_something();
+# }
+?>{% endhighlight %}
+
+Some text editors like [Textmate](http://macromates.com) have the
+ability to fold these kinds of blocks, which is a great visual aid in
+developing and first-hand comprehension.
+
+End of story
+------------
+
+_Use web standards, separate each component, take advantage of semantics
+in comments and talk it easy._ Better than a developer is one that
+knows how to explain what he's done. I'm sure Roger will appreciate it as well
+as me.