Dérico Filho

Introduction

Everybody is aware of the important role PHP has been playing in the formation of young programmers. But I do believe few people really understand the dimension of the imminent disaster in course relating to the quality of the programmers that adopts it, and, curiously, never let it go - even when other languages are better suited to the goal of an application.

This book shall serve as funny consolation to those who see the mistakes made by unprepared PHP programmers. The critic is not against PHP. Indeed, I am myself a proud PHP programmer and I like it very much. The critic is about the programmer that write a true letter-soup on his resume so as to fool the recruiter, it happens the he or she is successful because often the recruiter is a psychologist proudly ignorant on computer sciences, therefore incapable to sort out the good candidate from the bad one.

It can be proved. Examples of this manual can be perfectly swapped from PHP to any language of choice. Yet you shall notice the pattern persists. The PHP, and perhaps Ruby nowadays, is a language powered by a very easy syntax and it enables the beginner achieve encouraging result very quickly.

Is it a demerit of this language? No. The point is if the programmer were someone with a good formation, surely would take advantage of the simplicity that each one of these languages bring. Please, before filling up my mailbox with enraged messages about my critics to PHP, keep in mind that this book is about the programmer in first place.

Family Portrait.

The perfectly idiot PHP programmer begins his bright career by the age of 15, when, by seeing website and portals, he is yet incapable to understand the difference between HTML and PHP. He starts googling and suddenly find two kinds of text: tutorials and forums.

These couple of results are perfect match: in one he effectively learns to create a web page - which, obviously does not tell one thing from another - and the other one, he is capable to talk about his doubts to other people who walked the path he is on.

Then, eventually he publishes his Home Page. He has access too to his first anti-pattern: Spaghetti Code.

By the age of 18, the idiot is not satisfied, he wants more. He come up with the idea to create a web site using some sort of database. Again he googles and finds out that 99% of PHP programmers use MySQL.

He promptedly creates applications using database, and also he learns to use the join command in tables. He join tables loudly and proudly, with no concern about such things as index or normalization. He puts in the database everything he wishes, text, numbers, images, files, well… almost everything in the Database. He discovers his second anti-pattern: In Database we trust.

The idiot, so far, only uses functions and, vaguely, very very vaguely some concepts of structured programming. Yet he doesn’t understand, and perhaps he will never understand, what is parameter passing by reference or by copy. When he needs to insert the content of a file into another, he uses the include command. When he needs access the Database, he includes the connection file in all other files. The idiot, notwithstanding the fact he has been using PHP for a long time, did not read the manual yet, and the idea set up PHP to include the files for him has not passed through his mind.

By the age of 25, he has accumulated a “large experience” and “knows a lot” about PHP, in his resume he mentions PHP and MySQL as advanced knowledge of his and highlights them. Actually, after few years programming, he is able to do things quicker than before, because he has now a library of code templates that he reuses in almost everything he does. He discovers then his third anti-pattern: Copy’n'Paste programming.

In this moment he is either graduated or graduation from Computer Science college. He might have studied IT systems or Web development. Anyway, he did not study in them advanced knowledge in programming logic, a mathematics base or network knowledge that enables him understand better how things functions within the computer.

By the age of 30, the perfect idiot is aiming for a low or medium management role. Perhaps he has heard of eXtremme Programming, Bazaar and Cathedral or Scrum. As programmer he discover the marvellous world of Object-Oriented Programming and DRY (Do not Repeat Yourself). He might have had contact with a more hostile programming language like C or Java. He also has had access to Rail-like frameworks. His life changes completely after this discovery.

At some point, the idiot thinks seriously about move in to RubyOnRails, which is much more practical and dynamic than PHP, he is not worried about scalable applications yet.

But he has feelings, and misses a lot the PHP way of doing things. He googles for something like RoR but written in PHP. He encounters a plethora of frameworks: Zend Framework, Code Igniter, PHPonTrax and CakePHP. “How great!”, he thinks, “The best of both world available to me!”. When the idiot goes to the circus he always enjoys the One Trick Pony.

However he is not familiarised with the theoretical foundations of these frameworks, and soon he feels limited on some aspects. For the first time he has contact with some of these patterns, for instance: MVC or Active Record.

By the age of 35, he is promoted to “Chief Programmer”. He is studying the Master degree. Already have a vast knowledge in programming and software engineering. At this point he decided to leap ahead in his career, and the role he has been aiming for 5 years is his at last. Depending upon his personality he might or might not be willing to pass his knowledge ahead. Oh yes, in the forums he read or asked, but the possibility to answer few questions appears only recently.

Although the idiot should prosper after his age of 35, I should stop here, because the main point of this family portrait is: the idiot is not concerned about good programming, he is concerned about getting things done, no matter how. Reinventing the wheel is not a problem to him. Is it good? I don’t know, great hackers usually studies the wheel, even reinvent it in order to better understand it. The idiot reinvent the wheels because simply never he has imagined that such a thing as a wheel could be invented before. Or even worse, he reinvents the wheel and on some perverted way he concluded that the best wheel is squared.

Hello All,

A minor release of dbdesigner2cake is available. Those who are using the release 1.0.5 or previous are recommended to upgrade to 1.0.6.

These issues were addressed:
- Changed the website on the license text from cirello.org/dbdesigner2cake to dbdesigner2cake.cirello.org
- Now it forces the PrimaryKey according to the XML
- strtolower’d table’s names.
- avoid a special condition on which a hasMany/belongsTo table would be somehow linked to a HABTM table. (workaround)
- Corrected few typos.

Well, as I usually finish such release notes:

You are welcome to download the 1.0.6 version at
http://dbdesigner2cake.cirello.org/download.html

Bye

Dérico at Pio XII, Dérico at New School. Dérico, with open heart. Marina, with closed heart. Hearts meet where people go. Marina and Dérico at Classroom. Marina and Dérico with joy. Sun rises and Moon shines. Religious people at Campos, Manga with joy and destruction. Dérico and Tamara, with open heart. Tamara, with massaged hair. Dérico and Tamara at Classroom. Dérico and Marina, with games. Dérico, with wide arms, Tamara with closed fists.

Sun rises and Moon shines. Excersing people at Ball. Soft touch with feeling. Sun rises and Moon hides.

And Moon rose as the Sun did. Dérico and Tamara at Harsh Grounds. Thunder in the skyes, and flood on the rivers shores. Water drops from skies, and tears from fears.

Marina and Dérico behind the wall. Tamara and Dérico at the great hall. Hearts beats where couple go, but broken fades away.

Marina, Dérico and Tamara at Gather. The real world toss glorious people. Sun rises and Moon shines. Marina meets where hearts go. Tamara meets where hearts go. Dérico goes where money is. People go to the place the must be.

Sun rises and Moon shines. Sun rises… Moon Shines.

Marina goes where hearts are. Tamara goes where hearts are. Dérico, Marina and Tamara at Cathedral. In Cathedral, uneasy hearts pray. Those who pray for will are rewarded with justice. And justice is done once.

Marina, with love, at Cathedral. Tamara, with love, at Cathedral. Dérico at home. Dérico and Nelson at home.

Dérico, with heart closed. Dérico, in the ocean. Dérico and Nelson at Anhembi. Dérico and Ed at Anglia. Gather at Paulistania, Dérico at Anglia - with joy.

Dérico steps back, with hearts open, at Nowhere with Nopeople.

People by the Fire - tears from fears. Still tongue makes a happy living. People by round table, at Net.

This is an open letter to Raymond about his essay named “How to Become a Hacker”.

Hi Raymond,

I have read your howto about becoming a hacker. First off, according to your definitions of hacker, I am not a hacker - and also I do not consider myself as hacker. Therefore, as not being a hacker I do not know how great is my allowance to send this letter to you. I do not want to challenge your ideas, nor I have desire to enhance your thoughts.

However, I feel I should share a thought I had: “Rails-like framework considered harmful in early stages”.

RubyOnRails, CakePHP, DJango and many more. Are they wonderful tools that does a lot of auto-magic for us? Yes, they are indeed. They offer us DRY, MVC and force unto us OO thinking.

I think this auto-magic is a double-handed feature of them, because as it facilitates for us the day-by-day dirty work, they also hide from usrelevant knowledge on how things are done. Therefore, beginners tend trying fit their needs into the framework boundaries. “Well, I need ABC feature to use in this XYZ system I am developing - let me check if there is a component that does it for me. Alas! There is not, what am I going to do?”, perhaps a lazy beginner would say. Develop the ABC feature may not ever come across his mind. (”It is reinventing the wheel” some would say, but trying to reproduce things is a very good way to gain knowledge).

Understanding the laying logic beneath the whole magic is very significant - it is a very special kind of logic, because it enlighten us about the real limits of what things can or cannot be done and how they could or should be done.

Concluding, I would like to ask you to put in this essay of yours the following paragraph by the end of the second one in “1. Learn to Program” session:

“[…]you have to know what the components actually do. The same goes for the Rails-like framework (RubyOnRails, CakePHP, DJango &c), although they are magical on getting things done, they hide from you significant knowledge of how they perform their magic. Now I think it is probably best to learn C[…]”

I have written a web log post further developing this point of view of mine. I pray you read, if you will, at

http://blog.cirello.org/2007/09/24/imho-cakephp-made-php-bondage-and-discipline/

Yours sincerely,

Dérico Filho

Embedded Video

Blogged with Flock

Tags: WilliamKamkwamba Windmill

I’ve seen this one in blog.TED.com. Dean Kamen’s received a visit of a very senior government officer requesting him to invent an artificial arm according to few very simple specifications: he wanted the returing troopers of war, which had losen their arms, be able to pick a berry, and feel it size, weight and texture.

As a consequence of a SuperTech behaviour, and its ability to enhance human body, I check it both as SuperTech and HumanTech technology.

See more on: IEEE.org

Hi,

eZ Publish is a Content Management System and Content Management Framework translated into 26 languagues and their variations coded in PHP and it stores its information on a Relational Database Management System, such MySQL and PostgreSQL.

I would like write a bit more on MySQL and eZ Publish integration about a very specific yet important point: tables storage engines.

Among many there are two that are broadly used: MyISAM and InnoDB. Both are great and each has its own advantages and disadvantages.

MyISAM engine is the MySQL version of the old IBM’s ISAM engine used in its early versions. It was designed to be fast and it is used as an engine of choice up to MySQL 5. InnoDB engine on the other hand was created by Innobase that was buyed by Oracle. It has been replacing MyISAM as engine of choice from MySQL 5 up to the latest.

It is possible to summarise the differences between them in these points:

- InnoDB has support for transaction queries. It means that eZ Publish may access the database, change its data and store (or discard) the modifications all at once in the end of process. MyISAM tables simply cannot operate like this. It is particulary importante in routines that consistency is pretty critical. All data changed is logged apart.

- When an InnoDB tables crashes, it recovers replaying the log. Therefore, the time to fix the table is always very short because it does not have to search for corrupted data. MyISAM on the other hand, has to scan the table each time it crashes, the larger ammount of data the longe it will take to check and recover it.

- MyISAM is quicker than InnoDB in many situations, because it does not have to store and keep log of changes while another command is processing reading. MyISAM either reads a table or writes to table, and these operations are not concurrent. However if you have a eZ Published site with a lot of changes, all of them happening together, you will problems with performance. Each time a MyISAM table is changed, the table cache is discarded - and it cannot be read until the write is done.

- MyISAM supports FULL TEXT index. When a Text field is created and indexed in MySQL, just a tiny part of it is stored in the index, and therefore it may return results lacking registers that should match a filter rule. FULL TEXT index prevents that, it creates a hash of all the words in the index so it returns consistently the expected result.

Thus what is it the best choice when developing with an eZ Publish object? The answer is quite easy and straightforward. The rule of thumb is: if your eZ Publish site reads much more than it needs to be updated, use MyISAM engine. Otherwise use InnoDB engine. Even if the proportion is 50% / 50% keep InnoDB as choice, on eventual crash it will recover quicker and very consistently.

This article is offered by WebDeal Hosting.

Hi,

Few days ago while talking to a friend of mine, Tammy, I remembered a discussion we had when we were in high school. It was an essay we had to write about human biological evolution, what Human would be in 100,000 years. My friend took a Super Tech approach and I took a Limit Tech approach.

Here it follows:

Tammy: - Well, we can say for sure that humans will be taller. Because each generation children are taller than the parents.

I: - I don’t agree with you, because you know, there will be a strong food shortage and this lack of nutrition will lead to smaller humans.

Tammy: - No way, my brother is taller than my father… I am taller than my mother. We’ll be very very tall.

I: - Gosh, I envy you. I am smaller than my father, my mother and my sister…

Tammy: - And you eat a lot, so the food has nothing to do with height.

I: - Hold you horses, Tammy. I eat a lot indeed, but your theory is not working as well. I am not taller than anyone of my family. It seems we have a point here, wouldn’t you say?

Actually we were both right and wrong. Indeed genetics and nutrition are responsible for proper human growth. Countries with ethnicities of tall people, such Scandinavians, are taller than others, such Brazilians - that is the genetic part of the argument. But also proper nutrition, people starving in Africa are usually shorter than other Africans better fed.

The whole point of our discussion is: the next 100,000 years will be of superabundance, on which people would get taller each generation; or scarcity, on which people would shorten each generation?

I strongly believe that none shall completely fulfil. Humans will not have a superabundance available for everyone nor there will be a complete lack of resources. By the year of 2007 we see each country, depending upon the size and its own vision of future, choosing one line of development over another. I see European and Chinese people shorten, because they’ll have problem with fields to raise crops, and Brazilians and Canadians getting taller due to their relatively small population and huge room for dwelling and sowing.

I think the greatest challenge about future, resources and technologies is create a coherent and unique way of developing things. Super Tech behaviour has already shown to us that it is able to provide cohesion to the world: be bigger, stronger and better. It is proselytist.

On the other hand, Limit Tech and Local Tech are not able to produce such results - not because they have weak theoretical base, but by definition they are not expansion-driven behaviours.

Human Tech, also fails on this point, because each Human Being is different and this will make the whole idea of cohesion dreadful. “I do not want to lose my individuality”.

Nature Tech produces cohesion, but it is not proselytist - mainly because humans nowadays are dissidents of Mother Nature protection. Man decided to take its own future by hand, and yet it is learning how to deal with it.

I ask myself: Is Super Tech the only conceivable future? Will not the others fade away because they cannot spread their importance to others? Will man-kind be able to choose Limit Tech or Local Tech rather than Super Tech?

This cohesion is very important, not only to understand what shall happen in 5 ou 50 years, but also of how Homo Sapiens Sapiens will develop along the ages: like a short parasite or a medium-size nature-balanced creature.