IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Some additions based on recent experience
Here are some things to add based on my recent experience. And just to be clear, these things are not really the fault of the company I'm working for. The sites I'm working on right now have been handed back and forth between multiple companies over the years, and look to have been first carved sometime around the time Netscape 3 was state of the art.

(1)Make liberal use of PHP include files. By itself putting all the real code behind two or three levels of files that do nothing but include other files helps to make things obscure.

But when combined with using different files that have the same name that get mapped based on relative paths that vary depending on how you navigate through the application. Then you can take things to the next level.

(2)Make use of multilingual systems, that being say english and french not PHP and ASP. For example, why say this
<tr>\n  <td>Main Menu</td>\n</tr>

when you can say
<tr>\n  <td><? echo(REF_TITLE); ?></td>\n</tr>

And really, I'm not kidding, I've got pages of this crud to wade through in a system that only has one language to begin with. There is one include file called english.PHP that is included everywhere and defines all these constants. The effect is just to make the HTML even less readable.

(3)Table nesting is fun. To be sure your include files are protected against things set from above be sure that every include file defines it's own table. Don't go overboard though, any programmer that sees HTML code that starts
<table>\n  <tr>\n    <td>\n      <table>\n        <tr>\n          <td>\n            <table>\n              <tr>\n                <td>

knows you are cheating.

On the other hand, putting the column headings and the actual data in seperate tables is fair play. Why, I have no idea, but it obviously is.

(4)PHP can do all sorts of things for you automatically. Be sure to turn all those things on, making it impossible to actually secure the web site.

(5)You can negate all the concerns about backing up code and how to transport it to the live site by doing your development on the live site. Really, it's fun, sorta like an extreme web development sport.

(6)Never get rid of old files. You might need to reference something in there some day. Just chance their names slighly and litter them all over the site.

Jay
New Okay, where are you sitting?
Because you've got to be working here.
===

Implicitly condoning stupidity since 2001.
New I18N is a lot easier put in at the beginning...
... then it is after you realize it needs to be internationalized.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Depends on if your providing real I18N or not
The multilanguage support for this site is nothing more then putting much of the text into a seperate file indexed by language. That could be done just as easy afterwards as at the start. And the site doesn't include the code to actually switch text files based on language preferences nor does any of the rest of the code support it.

For one thing it uses a javascript popup menu which has a seperate configuration file that specifes the popup locations in pixels. Changing the text would throw it off completly.

A lof the HTML has implicit sizing assumptions that would likely break in another language. The tables for one follow what I mentioned in another item, with the headers in one table and the actual data in another. If you run into any data that excedes the size assumptions of the columns, the headers and data won't match up any more.

Real I18N support requires real planning, and this site certainly had little to none of that.

Jay
New Todays additions, mysql version.
(1) Code to the absolute mininum spec. Your website might be hooked up to mysql 1.0 at some point, so don't make use of any fancy features like joins and such. Just do all the complex data manipulation in your application code rather then on the database server.

(2)Many languages have a way you can escape keywords and special characters. Take advantage of that to embed them into the code. It won't stop a determined programmer but it's like leaving caltrops for them to stumble over, it slows them down.

One simple way is to create database tables with column names that are key words. If your using 1 from above, this won't get in your way at all, but will annoy anybody that comes after you if they want to add some SQL code.

(3)Index are overrated, particularly unique ones. Putting some sort of unique index on all tables just makes it easier to trap errors that you might be able to gloss over overwise.

(4)Personalize function names. JayPrint, DisplayBob and myFileOut are fine, particularly when you use the same prefix or suffix all over the place so it just makes function names longer and slighly more obscure. The fun comes when somebody else comes along and has to modify JayPrint, do they change the name or leave the now incorrect one?

This can be double effective when combined with mysql, where you can obscure the difference between mysql's database functions and the ones you created by starting all the functions you write with 'my'.

Jay
Expand Edited by JayMehaffey June 29, 2004, 06:35:56 PM EDT
New No, seriously, where are you sitting?
(1) Code to the absolute mininum spec. Your website might be hooked up to mysql 1.0 at some point, so don't make use of any fancy features like joins and such. Just do all the complex data manipulation in your application code rather then on the database server.
You have more control of it that way. Who are these nameless database developers to think they can write an optimizer that is smarter than hand-tuning the join logic in program code?

(2)Many languages have a way you can escape keywords and special characters. Take advantage of that to embed them into the code. It won't stop a determined programmer but it's like leaving caltrops for them to stumble over, it slows them down.
For extra credit, look ahead at the specs for the next major revision of your programming language. Note some nifty new functions that will be available and implement them. Use the same name, but not the same order of parameters.

One simple way is to create database tables with column names that are key words. If your using 1 from above, this won't get in your way at all, but will annoy anybody that comes after you if they want to add some SQL code.
Name a column 'date'. This can cause hours of joy. Or a table called 'user'. That's fun too.

(3)Index are overrated, particularly unique ones. Putting some sort of unique index on all tables just makes it easier to trap errors that you might be able to gloss over overwise.
Geez, that's what code is for. Sure, you probably don't ever want to entries in the 'user' table with the same username. But hey, you can't anticipate everything you may want to do in the future.

(4)Personalize function names. JayPrint, DisplayBob and myFileOut are fine, particularly when you use the same prefix or suffix all over the place so it just makes function names longer and slighly more obscure. The fun comes when somebody else comes along and has to modify JayPrint, do they change the name or leave the now incorrect one?
This is also good for directories. When developing on that live environment in a parallel directory, don't just leave your development code around when you're done: point the other live code into it! That way the directory that looks like it ought to be live is obsolete, and the 'bob_admin' directory is actually in production. Much fun when someone naively deletes the 'bob_admin' directory.

This can be double effective when combined with mysql, where you can obscure the difference between mysql's database functions and the ones you created by starting all the functions you write with 'my'.
All private methods must be prefixed with 'my'. Even though php4 doesn't support true private methods yet. So when you decide something that's prefixed 'my' really should have been public just start using it.
===

Implicitly condoning stupidity since 2001.
New Re: No, seriously, where are you sitting?
Name a column 'date'.

I've now run into applications pulling that trick in Access, SQL and mysql. A rather sad trifecta.

Jay
New Don't do that!
I've now run into applications pulling that trick in Access, SQL and mysql.
SQL is a standard database language. SQL Server, if that's what you meant, is a proprietary Microsoft product. Don't give them the term. They've already taken "the internet".
===

Implicitly condoning stupidity since 2001.
New Namespaces, fellas.
...they do work when used correctly. In other words, if your flavor of SQL won't let you name a column whatever you like, its implementation details are getting in the way of your design.

Reason #2147 for maintaining schema outside of the databases themselves.
New Dude, MySQL is not Oracle
===

Implicitly condoning stupidity since 2001.
New Dude, Where's My Cobb?
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Not true
Namespaces, fellas.
...they do work when used correctly. In other words, if your flavor of SQL won't let you name a column whatever you like, its implementation details are getting in the way of your design.

That can't be true, because obviously there was no design to begin with.

And yes, there are ways to work around it. But why make extra work for yourself? I would much rather insure all column names are not key words and include no spaces upfront.

Jay
New Wandering into madness edition
(1) If a feature of the language is being removed or disabled, reimplement it yourself, never question why it was removed. For example, start all pages with.
\n<?\n  foreach ($_POST as $key => $value) {\n    $$key = $value;\n  }\n?>\n

(3) Numbers not names. Why use MENU_FILE_SAVE and MENU_EDIT_CUT when you can use MENU_1_1 and MENU_3_8? Double fun when the menu is reorganized but you don't change your names. To make sure that nobody can mess up your system later, be sure to name everything possible using the fixed numbers.
\nswitch ($main_action) {\ncase '1':\n  switch ($sub_action) {\n    case '1':\n      include '/1/1.inc'\n      break;\n    case '3':\n      include '/1/3.inc'\n      break;\n  }\ncase '3':\n  switch ($sub_action) {\n    case '1':\n      include '/3/1.inc';\n      break;\n    case '8':\n      include '/3/8.inc';\n      break;\n  }\n}\n

(2) Reinventing wheels is fun. Don't be quick to make use of existing, robust solutions, instead implement your own quirky, limited one. For instance, rather then forcing your web site to have a big path tree or using your web servers remapping capacity you can build you entire app with one PHP file by using a query string value to keep track of the users logical location and passing it back to yourself continously.

(3) Consistancy is for the timid. If the language supports many ways of doing something, rotate between them. If it only supports two or three, use one 99% of the time but slip the other in odd spots.
\necho 'This ' . $is . ' a ' . $boring . ' way to do it';\necho "This $is a $boring way to $do it";\necho 'But this ' . $is . ' a fun ' . $way . " to $do it";\n


Jay
     I seem to recall this being shown before... - (folkert) - (14)
         "marypoppins = ( superman + starship ) / god;" :-) -NT - (Another Scott)
         Some additions based on recent experience - (JayMehaffey) - (12)
             Okay, where are you sitting? - (drewk)
             I18N is a lot easier put in at the beginning... - (admin) - (1)
                 Depends on if your providing real I18N or not - (JayMehaffey)
             Todays additions, mysql version. - (JayMehaffey) - (7)
                 No, seriously, where are you sitting? - (drewk) - (6)
                     Re: No, seriously, where are you sitting? - (JayMehaffey) - (5)
                         Don't do that! - (drewk)
                         Namespaces, fellas. - (FuManChu) - (3)
                             Dude, MySQL is not Oracle -NT - (drewk) - (1)
                                 Dude, Where's My Cobb? -NT - (admin)
                             Not true - (JayMehaffey)
             Wandering into madness edition - (JayMehaffey)

public class Lrpdism implements GenericSaying
56 ms