owenSoft.net - Articles

General Theory on Dreams and why they are always weird (Articles)

2010-03-26 15:05:57

I have always been interested in the inner workings of the brain. Being a programmer, I spend a great deal of time thinking of ways to create different systems of solving problems. This article is about a theory I have about dreams and why human need to have them.

Dreams are a succession of images, thoughts, sounds, or emotions passing through the mind during sleep. The content and purpose of dreams are not fully understood, though they have been a topic of speculation and interest throughout recorded history. The scientific study of dreams is known as oneirology.

Why do we dream?

The consensus is that you dreams because you are asleep and you brain needs something to do in its idle time. Which makes sense because we spend almost half of our lives asleep. "Sleep in humans, other mammals, and a substantial majority of other animals that have been studied (such as some species of fish, birds, ants, and fruit flies), regular sleep is essential for survival."

the nature of dreaming: that it is regular nightly, rather than occasional, phenomenon, and a high-frequency activity within each sleep period occurring at predictable intervals of approximately every 60–90 minutes in all humans throughout the life span.- wp

The Theory

My theory is that dreaming is not simply "busy work" being done while the body is sleeping but I think the brain is actually running a series of comparison tests across the information it has learnt during the day and in the past. The brain not only "thinks" at the point when there is a problem to be solved but actually is making up problems to think about when you are asleep. This is why we dream.

Dreams and learning

The assumption that the brain is running tests on you during your sleep leads me to imply something else about the brain. If my hypotheses that dreams are tests is correct and the fact that a dream is mostly a none physical activity, then it leads me to assume that there would be no benefit to running these tests unless it is a very necessary part of learning.

But then again if you are learning while you are awake why would you need to learn while you are asleep. I think the reason for this is because the brain is not one BIG computer but infact multiple little computers each doing its own thing, constantly changing while you are awake and gathering information. It would seem that it is while you are asleep that the brain gets a chance to run tests on the information that is gathered during the day.

These tests maybe some sort of maintence process. In my own experience my dreams seemed to always be a mishmash unrelated information, people and places. It is as if my brain is comparing scenarios, events, people and things I have learned in unusual ways to see how the "brains" will react to it. I imagine that nightmare occur when the brain runs a comparison on something that is feared by the person. It also seems that these comparison tests/processes are not limited to current previous but can involve anything learnt or experienced in a person's lifetime.

I can only speculate on how the brain determines when a test is successful or when it has failed. Though often times a person will find themselves in a deja-vu situation. "Déjà_vu is the experience of feeling sure that one has witnessed or experienced a new situation previously (an individual feels as though an event has already happened or has happened in the recent past), although the exact circumstances of the previous encounter are uncertain.". Usually a person will only encounter "good" deja-vu scenarios and will seek to avoid any scenario which "feels" wrong or invokes some sort of fear emotion.

A Comparison Engine

Maybe there is no right or wrong, true or false scenario. There is a chance that the brain is in fact not a computer but in fact a complicated comparison engine which is updated during the sleep phase of our live. This might explain why we spend so much time sleeping. And further more explain why we have to sleep so frequently. The brain as a comparison engine would explain why people who are taught the same thing often thing about them in different ways depending on their perspective and previous experiences. This would mean that if there was a way to raise 2 people, teaching them exactly the same information, then technically they should have the same dreams.

Conclusion

This Theory has lead me to speculate that the brain is not simply a big computer, running a single big program but infact a series in independent, parallel, micro programs, all learning and changing at the same time without any sort of uniformed synchronization. There are no consistent rules as to the structure of each program or how it interacts with each other part of the brain. Apart from the parts of the brain which are hardwired for specific tasks, all the other cognitive parts of the brain must then be running at kernel level, at the same time, independently and yet cooperatively casting votes at the same time. In the sleep state the brain allows the normally independent processes to interact which results in dreams. Dreams which help to create bonds and links between thoughts and processes which are normally too busy consuming information while the person is awake. If this is truly the case then computers of the future need not only to think but also to dream.

by owen () Post your comments on this article

Verbal Diarrhea (Articles)

2010-02-12 15:20:04

Ah, some people just don't know when to STFU. Seriously.

This whole John Mayer situation, eerily reminiscent of several Kanye West situations, has me wondering why people just can't think before they speak. Especially when you're someone in the public eye.

In one interview this man:

- Kiss and told about several famous women he slept with

- Used a racial slur

- Admitted his penis was a white supremacist

- Offended women (black, white, yellow and brown) with his stereotypes

- Defamed Kerry Washington...

Do I need to go on? I hope everyone will have an equally long memory for John Mayer's transgressions as they did for Kanye West's.

This is a good assessment of the interview: http://ow.ly/16rBz

by SE (memoirsofadater.blogspot.com) Post your comments on this article

Video Games: Better graphics vs Better Gameplay (Articles)

2009-08-03 17:00:56

In my view the reason we can't have both is because development resources are always limited. Probably only the first party companies (sony, nintendo, microsoft) have infinite resources to spend years and pay the most talented and imaginative people to built their games. Which is why first party games always seem to come out with games that are excellent in all areas.

Now let me list the reasons why normally we can't have excellent graphics and excellent game play on limited resources;

Better graphics means; bigger textures, more processing power needed, more assets, more art, more physics, more motion capture, more sound samples, more video

Better Gameplay means; More options, more NPCs, more characters, more objects to interact with, branching paths and story, more actions, better A.I.

Now lets try to combine the 2;

Graphics over gameplay leads to; small maps, Flat A to B stories (most Fps games), limited interactions or Quicktime events, buses crashing into intersections that BLOCK YOUR DAM PATH!(uncharted 2 video) Big open spaces with nothing to do in them (ala Just Cause). Enemies that always spawn at the same place. Switchs.

Gameplay over graphics lead to; Old Games like Mario 1, PacMan, Zelda TTP, Time Splitters. Because really they had no choice but to make the gameplay solid (old and multiplatform games seem to suffer from this). I'm finding it really hard to find examples for this nowadays.

Conclusion

My examples are limited to what I can remember now. Either way what is needed is a balance between graphics and game play. Something like NMH, or FZero Gx (yeah the other racers on the track look shitty but they were 30 of them so it kinda balances out). Most games nowadays are shitty because the graphics department has more power and is therefore using up too much of the systems resources. hence forcing the gameplay/stories to be implemented inadequately.

by owen () Post your comments on this article

Programming: The downsides of Modularity (Articles)

2009-06-04 21:15:37

There is a common misconception that modularity is inherently a good thing. In fact modular systems are not optimized for performance and are often harder to maintain depending on the extent of the modularization. It is similar problem as OOP which as a drastic effect on the program as a whole. Once a modularization technique is chosen it usually affects the entire program permanently crippling it is not properly implemented. Modularity similar to OOP is a useful tool in the appropriate context. One should not start writing a modular program. However one should anticipate the areas of the program which will benefit from being modular.

Lets us look at a simple example 1;

start program

print("-- Add 2 numbers --");

print("Enter first Number:");

firstnumber = readkeyboard();

print("Enter second Number:");

secondnumber = readkeyboard();

result = firstnumber + secondnumber;

print("Result:" + result);

end program

As you can see the Example 1 is pretty simple and efficient. What I'm going to do now is redesign the above program in deferent stages of modularity. What you will notice is that as the program becomes more modular it becomes more complicated and at the same time less efficient.

Lets us look at example 2;

function acceptnumber( screenmessage )

print( screenmessage );

return readkeyboard();

end function

start program

print("-- Add 2 numbers --");

firstnumber = acceptnumber("Enter first Number:");

secondnumber = acceptnumber("Enter second Number:");

result = firstnumber + secondnumber;

print("Result:" + result);

end program

In example 2 we have introduced a function called acceptnumber() which allows us to reduce the amount of lines in the main program by moving the repeat tasks of printing a message on the screen and reading the keyboard from the user.

Lets us look at example 3;

function acceptnumber( screenmessage )

print( screenmessage );

return readkeyboard();

end function

function do_addition( num1, num2 )

return num1 + num2;

end function

start program

print("-- Add 2 numbers --");

firstnumber = acceptnumber("Enter first Number:");

secondnumber = acceptnumber("Enter second Number:");

print("Result:" + do_addition( firstnumber, secondnumber ) );

end program

In example 3 I've moved the code that does the add calculation into its own function called do_addition. do_addition accepts the 2 numbers that need to be added and returns the result. I've also go ahead and gotten rid of the result variable since its not really used for anything important.

Lets us look at example 4;

constants = array ("-- Add 2 numbers --", "Enter first Number:", "Enter second Number:", "Result:", "addition" );

function acceptnumber( screenmessage )

print( screenmessage );

return readkeyboard();

end function

function do_addition( num1, num2 )

return num1 + num2;

end function

function get_data_input(settings)

print(settings);

input1 = acceptnumber(settings);

input2 = acceptnumber(settings);

return array( input1, input2 );

end function

function get_calculation_output(settings, data_array)

if( settings == "addition" ) {

return settings + do_addition( data_array, data_array );

}

return "no work or invalid settings";

end function

start program

data_array = get_data_input(settings);

output_text = get_calculation_output(settings, data_array);

print(output_text);

end program

In the 4th and final example I when all the way and separated the input of data from the output and calculation. You maybe able to see various advantages and disadvantages of this method but it was done to demonstrate my final conclusion.

Conclusion

As you can hopefully see, all four examples do exactly the same thing, except each one becoming increasingly modular, less efficient and more complicated. I could have done a 5th step and implemented it in OOP but by now you should be able to see my point. A program can be simple without being modular and on the other be modular but VERY complicated. A program being modular does not mean that it is simple. And a modular program is not necessarily more readable that a simple program.

by owen () Post your comments on this article

Programming Theory: Throwaway Code (Articles)

2008-11-23 23:55:32

In today's age of new programming languages, frameworks, templates, RAD tools, MVCs and things that pretend not to be MVCs. A new productivity demon has emerged. Marketing is promoting easier and easier ways of rapidly creating stable enterprise applications that basically write the code and make your tea at the same time. At the same time when the adoption rate for the new paradigm is low they seek try desperately to bring over new and old programmers with exciting new buzzwords without offering in really new solutions to old problems. Programmers are spending an incredible amounts of time writing what I have coined as "Throwaway Code". Often referred to as scaffolding though this not directly what I;m referring to in this article. This article is largely about code lifespan, reuse and its general usefulness in future projects.

The "Throwaway Code" that I'm referring to is the code that;

exists for no other reason except because of some lacking feature in your language. aka The missing feature.

is tied to a specific framework and will be useless once they find a better way to do it. aka Framework Hacking.

is useless design pattern code. aka Getter Setter

gets boring fast. aka Model Boredom

Now I will explain each of these scenarios.

The missing feature

No programming language is perfect and anybody who says that their programming language is perfect clearly has not written enough code to have a clear understanding of anything. Each language has their strengths and weakness. There are often times that you get stuck with a language such as COBOL and you have to write a million lines of code just to print out a table. When in a different language the same code could be written in 5 lines. There are times when you can hack your way into the language in order to get what you need but this is not always possible because sometimes the feature you require would need to be well supported at the lowest level of the language. You will only notice instances like this if you have experience with other languages but it is important to notice. Time spent casting variables that the compiler has sufficient knowledge about could be spent writing ACTUAL USEFUL NEW CODE. In time the language will implement the feature and your hacked code will be a memory of times gone by.

Framework Hacking

I often look back at STRUTS 1 and wonder how could anybody EVER think that that was a good ideal. Though when you think about it frameworks are written by humans and humans make mistakes from time to time. Point is all that struts 1 code is now useless. Besides the things you learn from it, the code itself is useless out of it struts context. All those lines of code are now replaced by newer, faster and smaller code. Very little of it can be safely ported into something else. So basically that code you spent hours carefully putting together is now trash, throwaway code. Even the sections that you had cleverly custom hacked/coded where all in vain because they were all tightly tied to the framework, solving problems OF the framework rather than problems that evident in the wider scheme of programming. This is another point to note when it comes to frameworks; alot of time is spent hacking at the framework, it cannot really be seen as programming but more like patching holes in a pot. Because if the pot was good at the beginning then your time would be spent writing LOGIC CODE as opposed to writing hacking/scaffolding. Of course

you may say programming is all about hacking away at useless things for hours on end trying to solve a problem. However when your hacking away at scaffolding do you really learn anything? Except maybe the intricacies of a not so perfect framework?

Getter Setter

Now the problem of useless design pattern code seems to be popping up ever so often nowadays especially in OOP. OOP seems to be eating alot of its own dogs food. I tend to see the programmer writing code for no other reason than to make it easier for the tools that they use, so that the tools can generate more code for the programmer to write. I've mentioned this before. Point is depending on where you are in the evolution of a language/framework there is alot of code that you'll be writing "just-because". I remember concatenating strings in C. Although ignorance in bliss, there are things that you really don't need to do. Having to type the same thing 4 or 5 times in the guise of improving maintenance and extensibility is nonsense, its redundancy. There is always a better way to do things. It often evident after the language is replaced with something new. At this point there is a great enlightenment "omg version 3 is so cool". But no one will admit that version 1 sucked all hell - ESPECIALLY when its just out of beta. Its not even about evolution, certain basic programming paradigms are being ignored or hacked around. Singletons anybody? Even auto generated code has crazy drawbacks and redundancies that pop up only during maintenance. If you

Model Boredom

I've only noticed this in one case with one particular language. It seems that with MVC programmers become obsessed with creating a web of models, deleting them entirely and then re-creating them again. As if they are never satisfied with the model OR maybe its just too boring to update OR some new feature comes out that requires a total re-thinking OR maybe they are just get sick of it entirely after a year of playing with it. These model changes are usually not evident because the output is usually not affected. I will have to look into this more but your opinions on this topic are welcome.

Conclusion

Programming is becoming more and more abstracted and as a result much of the code written simply exists as scaffolding. Soon to be replaced by the next big iteration or framework bug fix. In reality it may be nothing new, a right of passage or growing pains. But one thing is for sure; the bigger the API - the greater the chance that 90% of your code will end up in the recycle bin or frozen in time.

by owen () Post your comments on this article

Managing complexity in Software Development (Articles)

2008-09-26 10:56:20

In programming, sooner or later you will come up with a solution to a problem that is somewhat "complex". The said solution may be advantageous to the program in various ways. The thing to note is that you should ensure that his complexity is "contained". Far too often software developers let a complex solution to a simple problem seep in to the body of the program itself. As a result making the entire program unecessarily complex. Miracle solutions are proposed to increase productivity through various catch words that end with "-ibility".

For example the index page of my website is probably the most complex page in the entire website. Yet the website itself is quiet simple. The index page was not quite as complex as it was now. Originally it was a series of IF statements that directed the visitor to a requested page based on various parameters. IF PAGE == ABOUT THEN LOAD ABOUTPAGE. It was really REALLY simple. One day I realised that if I could find a uniformed way of determining the next page then I could replace all the IF statement was a controller or MVC (as they call it now a days). The new solution required careful thought.

As with every line of code or function created there are things to consider;

How is changing this page going to make the other existing pages BETTER.

How is changing this page going to make the other existing pages WORST.

how is changing this page going to affect the quality of code as a whole.

Will changing this page make the other pages more complex or less complex.

These are important points to consider when dealing with complexity. You should always beware of things that may unessarily complicate the entire program offering shortterm benefit but long term headache. If I had suddenly woke up and decided to change the index page to use a random MVC without considering how the actual MVC would affect the complexity of the program itself then I would have made a grave mistake which leads to people discontinuing software a year after it was implemented.

All things must be considered in light of the shortterm and the longterm when developing software. A piece of software that starts out complex will not get simpler as you develop it.Keep the simple parts simple It will only get more complicated until it collapses under the wieght of its own complexity. In the same light something very simple can be complicated by a misplaced bottle neck in the system that was implemented on a "whim". Implementing features on a "whim" or ad hoc without considering its benefits is the fastest way to complicate what was once a simple program. Keep your eye on the important parts of the program to ensure that it remains simple and that any complex algorithms and concepts are "Functionalized" away from the program's core purpose.

In the case of my index page (which loads all the other pages) it may seem to be against what I just said - a very complicated concept deep within the core of the application. The thing to note is that the index page itself is a FUNCTION. What it does is completely independent of the program. It can easily be replaced because the other pages are not affected by it, nor thou or both shall go with him. hmmm. It is a function. An important function but a function none the less. The other pages on the site are unaware of its existance and so are not affected by any low level changes that I make to it. The sub pages behave as if they are in a vacuum, unaffected by the index page. It is not a typical MVC that seeks to solve a problem by controlling/limiting structure rather than providing a genuine solution to the structure problem.

What I could have done and what most people do is make the index into a class. And then enslave other pages into a "house of cards" situation. Now instead of isolating the solution to a problem of IF statements - the programmer ends up complicating the entire program in order to simplify it. I am not saying that wide spread refractoring is not necessary. I am saying that the inplementing complex solutions to a problem should not be allowed to complicate the program as a whole. Find a way to solve the problem without creating thousands of little problems/new workflows in the progress. Alot of this is explained to more dept in software engineering anti-patterns

Now for the code.

Here I will list elements that add complexity when writing programs;

IF THEN ELSE Statements: Avoid having a catch all "else" statement. Usually it leads to logic bugs and poor clean up.

Avoid unecessary class implementations: There is nothing more annoying than having to do a "new" every single time you want to use a base class. Its pointless. If you only need one instance at a time why is it a class? Make a single function that manages itself. Always ensure that you know the ;why" behind everything you program so that you can better make it when it needs to change.

Avoid giving yourself future work or more per-module work: Now I understand that some people like the whole "house of cards" thing but really now. It is easy to copy development documents off the internet and pass then off as your own but hard to implement something that you have no expirence in using.

Avoid doing the same thing over and over with slight per-module changes: This is a another sign of a train wreak waiting to happen. Sooner or later you are going to have to refactor all those slight changes and you will realize that 3 lines at the top of every module was simply there to make you feel productive but added nothing to the program.

Avoid tight coupling of you classes. This often occurs by using checked exceptions to force calling processes to handle them. Hence causing every calling program to be tied to a useless/decorative exception tree of choas.

Avoid eating you own dog food: I cannot stress this enough.

Avoid fragmenting processes: There are times when you may be tempted to create a function for the purpose of simplifing a process. This usually happens when you have so much code that its difficult to really keep track of what is going on. In such a case avoid creating singleton functions that look like functions but are infact big GOTO statements. These singleton functions usually have to be called in a specific order and a specific custom object has to passed to them. Its better to just keep it all in one function with good documentation. Ten random singleton functions are neither helpful nor do make the program easier to read/manage.

Avoid classes with too many setup functions: Some may think its a good idea but classes should manage as much of its internal processes as possible. Avoid;

c = new calc class;

c.setid(10);

c.setname('test');

c.getdata();

c.getresultset();

ans = c.calculate();

Its better to create a function called ans = calculate_test(10, 'test'); Not only do you have less lines of code (per call) but the test calculation process is encapsulated.

Avoid try-catch-throw logic: if a function is boolean it should return true or false. It shouldn't throw random exceptions to the calling function. Try-catchs are often used as a lazy form of IF-ELSE. Situations like this should be avoided for the same reason as mention before.

Avoid bandaid errors, hiding errors and non-specific error messages. A system is not secure if its errors need to be a secret. Having clear error messages allows for quickly identifying problems during the development and testing phase and evening during the life of the system. Searching through log files for errors that could have been easily displayed to the user is a waste of time. Critical errors can be missed that are hidden for years in log files and catch statements. The last thing you want is someone to be calling you in the middle of the night about some program that you wrote 5 years ago. Assume All errors are fatal!

Assume all errors are fatal. Often times errors are ignored or logged at lower levels of the program and the program is allowed to continue. This is often done to prevent the program from crashing. PROGRAMS CRASH its what they do when something is wrong. It is more important in program processes to identify WHEN a error occurs as opposed to the order. Log files are good are error order but poor for edge case event errors.

Conclusion

If your going down the wrong road it never too late to turn back. A poorly written program is only good as long as no one knows about it. You can throw as much RAM or HARDWARE at it as you want. Sooner or later it will get replaced by a off the shelf software that is probably JUST AS BAD OR WORST THAN your custom developed software. And the software you wrote will be just another skeleton in your closet. The main difference will be that the off the shelf software has learned to manage its complexity, increase flexibility while meeting user requirements.

Often times there is nothing you can do but to just run with what you have, make as much documentation as you can and pray for the future developers.

by owen () Post your comments on this article

Hardwiring: programming the design (tech) (Articles)

2008-03-24 20:22:45

There is a tendancy to write your use case directly into the low level design of the code. This pattern should be avoided as much as possible because it results in extensive "recoding" whenever high level design changes are made to the program. The highlevel design is not caved in stone and will most likely change as the system evolves but its core design rearly changes. It is important for the programmer to identify this core design.

For example an extreme case can be seen when the previous programmers wrote a screen for the 10 department types that are in the system - assuming that there would only be 10. As you can see hardcoding or hardwiring your use case rules into your code is not a good thing. The programmer wrote the code on the "business logic" instead of the "system layer".

It is important to notice that there is a system below the business logic. This system is what keeps the application simple and stable. The programer should seek to find the best way to rewrite the highlevel business logic into a stable sub system.

Take for instance the previous example: you can imagine that the programer got a use-case with 5 rows and 2 column of 10 items. The programmer looked at the first line of the use case and started coding right away (and in truth and in fact probably coded it in half the time that I would take to code it). The end result will work and will have the same output but the difference between the 2 approachs to the problem is night and day. Further down in the project the need MAY arise to add a new type of department. You should notice that the business logic in the use cases DOES NOT BREAK but the code that was written to implement the use case fails and the blame goes on the programmer even though the programmer did what the use case said should be done.

Another example: bank type. You notice that the use cases specify particular actions that occur on certain types of banks. And these types of banks are hard coded into the system. Business logic constants are bad design. This implementation is done like so:

BANK_TYPE1 = 1

SELECT * FROM BANKS, BANK_TYPE WHERE BANK.TYPE_ID = BANK_TYPE.ID AND TYPE =

IF BANK.TYPE == BANK_TYPE1 THEN

DO BUSNIESS LOGIC

END IF

The shortfall of this type of programming is the SAME as the 10 item example above. If for instance a new bank type is added that implements the same business logic as that of BANK_TYPE1 then the code will have to be CAREFULLY altered to facilitate the change to the design. Here is the new code:

BANK_TYPE1 = 1

BANK_TYPE_TWO = 3

SELECT * FROM BANKS, BANK_TYPE WHERE BANK.TYPE_ID = BANK_TYPE.ID AND TYPE = or TYPE =

IF BANK.TYPE == BANK_TYPE1 THEN

RETURN (BANK_TYPE1) BUSNIESS_LOGIC1()

END IF

IF BANK.TYPE == BANK_TYPE_TWO THEN

RETURN (BANK_TYPE_TWO) BUSNIESS_LOGIC1()

END IF

In the best case senario the same programmer will be able to remember how the program works and change all the places that need to be changed to fix the problem.

The solution to this problem requires a system level design change that will protect the code (the programmer) from changes/enhancements to the design. There are many ways that this can be done and the best way often takes more time and therefore the benefits of such an change must be evaluated during development by the programmer.

---

The point here is that it that the use cases are not low level designs. The progammer should ( whenever possible ) try to abstract the effects that changes have on the code which is written, by writing it in a way such that it is flexible enough to absorb business logic/design changes that may occur in the future.

by owen () Post your comments on this article

How to tell if you are an IT person (Articles)

2007-11-25 19:47:55

Mesha this is for you. I will try to keep this simple and to the point because some of us like to argue and some of us don't. I will start out by listing the qualifications that either by themselves or combined will result is a person who can call themselves a techie or an IT person. This article is written because I've realized that now in Jamaica since it seems that people have started to call themselves "IT persons" without fully clearing the bits or understanding what it actually means. By IT I mean "Information Technology" or Computer Science or whatever related field you choose. So here now I start with a list.

You are and IT person IF;

You like lists.

You like to play games for long hours, develop habits easily and have at some point in your life completed a mario brothers game. Though not necessarily beat the game but have tried on multiple occasions. This is however not limited to video games but anything involving a winner and a loser such as card games and games of luck or skill. You should be able to play many games at least 3 - not just one that somebody taught you. And be up for playing ANYTHING that looks like a game that you can win. Games can include mind games, board games, random text messaging. Solitaire is not a game.

IT people like to solve problems and hate doing the same thing twice. If an activity doesn't solve some kinda problem that will save somebody "work", time or money then more than likely you are a "packer". If you've done it before and are still doing it without improvement then you can't see the rabbit.

If you are disgusted by the behaviour of IT people and think that they are lazy, selfish and inconsiderate then you are most definitely not an IT person.

Having an IT degree or qualification or working with computers or teaching does not automatically give you the right to call yourself and IT person. You merely "associate" with IT people but you haven't crossed that line where you start avoiding people and not returning calls.

Working at an IT company doesn't not make you and IT person.

If you ever reach to a state where your too busy to brainstorm a solution to a problem or have a concept in your head that is called "work" such as can be compared to farming, manual labour or mining coal - then more than likely you are in it for the money are not an IT person but rather a slave to the money. Go and follow your dreams. No matter how far down the wrong road you've travelled - its never too late to turn back.

IT people do not like to use powerpoint or write lengthy essays. If you like to write multipage essays then chances are you are not an IT person.

Most IT people that I know like what they do, it might not seem that way but its true. On the other hand if you would rather be flying around the world, teaching kindergarden, or staring in a rock band then chances are you are not an IT person.

If your monitor is set to 800x600 then I really don't know what world your living in.

If you are confused or fail to see why I would list these things are behavioral patterns of IT people then chances are you cannot relate and are NOT AN IT PERSON.

This list that I have compiled more than likely is not complete and millions of ways could be found to argue around it. Whether depending on whether you are a woman or a man or your from the country or whatever - it doesn't really matter because most people either are who they say they are or are pretending to be a doctor. To each his own.

by owen () Post your comments on this article

Quick: How to setup and run php-apache on win2k sp4 (Articles)

2007-07-01 15:17:15

Friday, May 18, 2007, 7:15:29 PM

"for people who have installed something before"

goto (link)

download the last "PHP x.x.x installer" it should be about 22 mb by now. Php has 2 streams; a 4.x stream and a 5.x stream. Check which version your web host will give you access to. If your only going to play with it on your machine then just go for the lastest version. But remember that if you start using features of 5 you might have a little difficulty running it on 4.

Downloading the Apache HTTP Server

Go to (link) and download the "HTTP Server". Which also has 2 streams but the instructions above still apply.

Start installing

Install the Http Server

Install Php

Run the php Installer. It might ask you to setup a server for ex appache and select the folder which contains the configuration files ( C:Program FilesApache Software FoundationApache2.2htdocs )

Do not enable all the php modules, pick the ones that you know you want because sometimes the modules have external requirements that may prevent you from starting,

Got to Start//Programs//Apache and then search the option to restart your http server.

Installation Done

Goto

C:Program Files/Apache Software Foundation/Apache2.2/htdocs

create a text file

call it "p.php"

Edit it with a text editor (preferable editplus from (link) )

add this code to the file;

phpinfo();

save the file.

OPen you browser and goto;

(link)

You should see a long purple table with the php logo. Your good to go. Setup was successful. That directory is now your webserver, so can only run php programs from the for now.

More stuff to do

(link)

►Another problem is that people many times use OLD PHP script that uses 'short tags'. That is when the PHP declarative starts with

Other

You might also want to install a database such as Mysql

If you run the Mysql 5 install do not enable "strict mode". Its really really really strict.

Might also want to get phpmyadmin

by owen () Post your comments on this article

Gene find triggers baldness hope (Articles)

2007-05-22 06:51:01

Hair loss in humans might be reversible, suggest scientists who have helped create new hair cells on the skin of mice.

It was thought hair follicles, once damaged, could never be replaced.

But a University of Pennsylvania, US, team, writing in the journal Nature, says hair growth can actually be encouraged using a single gene.

by mad bull (www.madbull4.net/) Post your comments on this article

The System Layer (Tech) (Articles)

2007-04-23 21:34:18

In this day and age of highly complex business applications, which encompass a wide array of solutions to real world problems, it is essential to note the importance of application logic. Application logic or The System Layer is the track on which the business logic of any system must be built so that it travels at a constant, steady and predictable pace. Applications built on business logic are roll-a-coasters of terror. It is often easy for a software developer to take the "customer is always right" approach to programming software. And in so doing build applications that are based entirely on the business logic of the client. This is a common pitfall which although creates wonderful entity relationship diagrams requires an extensive knowledge of the client business logic to maintain, upgrade and optimize. You end up in a situation where the application becomes a exquisite dish that must be prepared by a Tibetan monk.

In a client environment where business logic is often mapped to physical tasks that can range from a very simple process to a complex maze of activities, sustainable applications need to be built on a simple, predictable backbone aka a System Layer. The system layer is akin to how a computer works with 1s and 0s or in genetics with DNA. If you want to build an application you are essentially putting together some 1s and 0s. You use 1s and 0s because its a standard, easy to use and relatively simple setup that the computer and other people already understand. 1s and 0s are a part of what I refer to as "the system layer" - the basic rules on which software is built. The system layer aims to provide a layer of simplicity to an otherwise complex application. Keep the application simple at its base and complex in specific branches.

Maybe I am being a bit extreme when I chose to use 1s and 0s as an example. Say for instance a file in an operating system. A file at its basic level has no business logic - it can be anything at anytime and the operating system would not careless. This "carefree" attitude is why operating systems are the most widely used type of software. In operating systems "business logic" is often implemented at the GUI level. The act of forcing users to create files that consist of names and extensions is enforced In the "file-browser" but never are the core level. Operating systems provide a system layer in which your application can operate efficiently - you are a "client" of the operating system. The operating system can maintain its efficiency by maintaining a stable System Layer. Building an application on business logic is like building the whole operating system again, but your files are not just files - they are whatever the business logic dictates. This creates a situation in which a rabbit is never really a rabbit unless you know that it is a rabbit. And in most cases the people who "know" and the people who "want to know" aren't the same people - in said scenario a rabbit might swim or fly depending on a status, type table, or season.

Application Logic or A System Layer aims to improve stability, predictability, extensibility and maintainability of software application by creating a simple set of fundamental rules upon which business logic is implemented. All Files have a name, meta data and content. RABBITS DONOT FLY UNLESS TOLD TO FLY. Developing a system layer does require research and thought; you must be willing to stick with it FOREVER, through thick and thin, rain or storm. Bypassing the system layer even a little would be blasphemous. Unless such a time a rises that a piece of business logic should totally destroy your tracks. Well built tracks last forever, roads develop potholes. Keep it simple, open and efficient at its base and finding problems will be easier, isolated and less magical in other areas of the system.

by owen () Post your comments on this article

The Sweetest Taboo (Explanation of blog post) (Articles)

2007-01-14 21:06:00

This is a sorta explaination of the post "The Sweetest taboo" since people didn't really get it. You should read that first before venturing off into this. Most of my posts - well all have 3 paragraphs which often times do not interact. Avoid trying to make sense of it as a whole. Sometimes I will make the effort and write a full essay but those times are rare and far between. Took a couple hours but I've managed to link every reference I could find. I'd like to thank Youtube.com, my mother and all the people who didn't annoy me. The notes are * emphased or highlighted in yellow on my site.

The explanation

The sweetest taboo *reference song The sweetest taboo by Sade Adu

*Taboo is noun meaning a social or religious custom prohibiting or restricting a particular practice or forbidding association with a particular person, place, or thing. Its also from one of my favorite artists Sade Adu. Its off an album called Promise by Sade. The "Best of Sade Album" was stolen from a roommate in New York in 2001 - I loved it so much. The album defined my entire trip. I was in the Bronx with my grandmother. Then the whole 9/11 thing happened and I came home a week later. Watched it live because the other public channels stopped working when they too out the tower.

submitted on 07th Jan 2007 to Logbook *first post of 2007

submitted by owen * I are di one

Its been sometime since we last spoke. *reference to a song called "Cupid's Chokehold" by the GymClassHeroes. In which the protagonist writes to his mother about his love life. Very good song and video.

When I was a young boy my momma said to me "There's only one girl in the world for you and she probably lives in Tahiti ". *From a song by Wreckless Eric called Whole Wide World which I found a review & mp3 from the Stranger Than Fiction - Original SoundTrack. Stranger Than Fiction is a movie I watched the week before about a Tax auditor who is hearing his life being narrated by a voice in the sky. Good movie.

Luckily, being as I am, I do not think of it much, illusions of grandeur are not entertained. Only fools rush in. *reference "Can't help falling in love" by UB40 It is hard to resist like spiked christmas sorrel. It had so much alcohol in it that it didn't even taste like sorrel. Being red was its only alibi. I poured it half full and attempted to over-power the spirits with ice water like an exorcist. *reference to year's week post Love is lame Little did it do. *Stranger Than Fiction I won't be your father figure, put your tiny hands in mine. *reference song "Father Figure" by George Michaels

* The entire second paragraph is about my taboo. Which ties into the title of the post. The title of the post usually has nothing to do with the content but this one seemed fitting.

As I look down in to her eyes and stare. In deep thought about nothing I look fixedly with my eyes wide open until she starts to giggle profusely [] *Something that is profuse is poured out or given freely, often to the point of exaggeration or excess. like a school girl at a fair. A fair that has a bounce-a-bout, merry-go-round and cotton candy. * Refers to Brooks park in Mandeville Jamaica, where I grew up as a child. You could only get cotton candy at fairs back them A confused look rolls over her face - trying to fathom my thoughts. *apparently I confuse people often At which point I break my silence and move towards her lips, thats all I wanted, its a little bit more than it seems. *reference to a song "More Than It Seems" mp3 by Citizen Cope Sad eyes turn the other way. * reference "Sad Eyes" by the Bee Gees Let me show you how much I care. *reference "The reasons Unknown" by The Killers As I watch the clock, time slowly drifts *water on, it becomes hard to concentrate. Something in the way she moves. * reference "Something" by the Beatles 1969 Sometimes I find myself lost in the glow of her shiny nose like a meteor drawn dangerously into the earth's path, emitting light as a result of being heated. As the separation anxiety *SNES video game with Venom and Spiderman begins to sink in *water, nothing is quite the same but if it makes you happy why are you so sad? *reference song "If it makes you happy" by Sheryll Crow It may take sometime to recover. This has been the worst December ever. *really Love me for who I am. *stop trying to figure me out, I'm not weird

It has been a stressful new year. Not counting the people who have been murdered so far. *25 in a week Being murdered I imagine would be more than stressfull. I was just getting accustomed to 2006 when it came to a hard, bitter and infuriating end. No Mavado watch. *christmas present mission influenced by Tash to get myself a watch from a girl for christmas by any means necessary - failed Children killing children while the students rape their teachers. We can't carry these sins on our back, we gonna swim to the ocean floor, crash to the other shore. *water *reference "Swim" by Madonna off the Ray Of light Album All we need is love * Beatles and snow * Snow falling in Jamaica would reduce the crime rate - its a theory, I pray for it nightly.

Conclusion

There you have it, took a while to compile but its done. Won't be doing that again.

by owen () Post your comments on this article

The Voting Bathroom Analogy (Articles)

2006-11-09 16:13:43

Voting is like washing your hands in the bathroom, there is no "instant" benefit to it and the "I told you so" that you get is often not a direct fault of not washing you hands but is a fault of going to the bathroom. It would help if you could avoid the bathroom all-together but most people are born into the bathroom. Being born into a bathroom offers you advantages which you get because people wash their hands. Some people just like to wash their hands because it makes them feel good, others wash because they get a bad taste in their mouth when they lick their fingers and some don't wash at all and choose to live like rebels.

The existence of the bathroom is never really-actually-clearly-significantly defined to those that do not benefit from it. Worst yet only the people that benefit from the regular use of the bathroom and posses the knowledge of it can efficiently use the bathroom for social gain. So encouraging others to wash their hands is therefore crucial to these people. The more people that wash allow the bathroom operates to be in a better position to create social gain from the bathroom. Because the people who understand the bathroom the most are often the people who built it, they are ever present.

The importance of the bathroom is not understated but is known to almost half the population. The inner workings of the bathroom are important but the importance cannot be conveyed to the people who willingly or ignorantly do not was their hands. Lets say that everybody starts to wash their hands; in such a case it would be apparent that the ill effects of not washing you hands would totally disappear. If it is not possible for everybody to wash their hands and in fact doesn't matter if everybody washes their hands then the purpose of washing your hands becomes irrelevant. The proper use of the bathroom seems to be more important. Therefore, if the bathroom in used correctly then why wash your hands?

The answer to the question is multifaceted. Apparently either nobody trusts the bathroom or the bathroom is setup in such away that you have to make a choice. The choices are always limited. Limiting the choices seems to be a trend that existed since the beginning of the bathroom itself. Polar choices are setup, choices are often re-shuffled upon each entrance to the bathroom, the choices are or may appear to be different but you still wash your hands the same way. The choices are often make to seem obvious but have little to do with the actual outcome in the worst cases.

by owen () Post your comments on this article

The Bleach Incident (Articles)

2006-02-09 19:41:56

NK says: hi

NK says: you there ?

owen says: sup?

NK says: I was hospitalized for 2 days... for the first time in Canada

NK says: that too... with an Ambulance pickup

NK says: yesterday, I came out of Hos...

owen says: :O

owen says: man, what happened?

NK says: I was inhaled strong and punget... smell of bleach / Javex

NK says: which I was not aware .... when I was doing some cleaning in the bathroom

NK says: unfortunately, because of winter all the doors and windows were closed...

NK says: and I fell short of breath....

owen says: oh,

NK says: had to run of the house for air.... in - 12 centigrade..., snow

NK says: for 30 - 40 min.

NK says: and finally ran into Hypothermia

NK says: next door neighbour called the ambulance

NK says: to rescue the situation

owen says: man you almost killed you self!

NK says: I guess....

NK says: yes

NK says: it was very unfortuante situation

owen says: you doing better now?

NK says: Yeah... I am

NK says: I still feel fragile...

NK says: Luckily,... I have healthcard...

owen says: you'll be back up to strength in a couple a days

NK says: and did not incur and bills

NK says: yes, you are right

NK says: that would be fair enough time , i guess

owen says: just rest

NK says: I want you to post a message on your site - saying that some smart people have to be alert all the time

NK says: no matter who they are...

NK says: Lot of intelectual do know certain circumstances...

owen says: what doesn't kill you makes you stronger

NK says: absolutely

NK says: post message and hep people by alerting.... once in a life time

NK says: i think you can do that....

NK says: a simple bleach can put us ... dangerous situation

owen says: true

by owen () Post your comments on this article

How to build a heirarcy with one query (Articles)

2005-11-19 19:41:26

Generating a tree list / heirarcy without a hundred queries is a problem that I have had since way back in 2002 when I started building the forum. Running a query for every node in the tree seemed malign to all things database. Even doing it once and caching the result was not something I would consider a 'good fix'.

I discovered how to solve this problem back in August of 2004 using 'by reference' pointers. Using this method a very large tree can be generated using one query, an array, recursion, and some programming kung-fu. There is a down fall to this method however i.e. the query has to bring back all the nodes in the tree or else you will end up with missing sections. A enchanced version is implemented in the sitemap of this website.

The technique involves a table which has 3 or more columns; id, name, parent. The 'parent' column would be a reference to an id in the same table. I created the table this way because it makes for simpler queries. Firstly you run your query and get all your records from the table (downside!).

select * from sitemap

The second step is to loop through each record while placing each item into a array using the id column as the array key. The section step is to check the parent value and to add a child array to the parent node. Then whenever a node which has a parent appears a reference is added to that parent node's child node.

The following code is written in php a C like language. It should be easily portable to most other language.

$os->execsql2(" select * from sitemap ", 'CACHE');

$struct=array();

while( $row = $os->fetch_array() ) {

if( !isset( $struct[$row] ) ) {

$struct[$row]=array( 'id'=>$row, 'name'=>$row, 'parent'=>$row, 'data'=>$row );

} else {

$struct[$row]=$row;

}

if( $row != 0 ) {

if( !isset($struct[$row]) ) $struct[$row]=array('id'=>'undefined','name'=>'undefined',

'parent'=>'undefined', 'data'=>'undefined');

if( !isset($struct[$row]) )

$struct[$row] = array();

$struct[$row][$row]= &$struct[$row];

}

I could do a part 2 of this article but anyway. Print the results involves looping through nodes which have parent set to 0. Then printing the child nodes if any. You need 2 functions;

function write_select_struct( $struct, $name ) {

print('');

}

function write_option_struct($a, $path) {

print('

$path .= $a . ' » ' ;

print $path . '';

//$a

if( isset($a) ) {

foreach ( $a as $key => $value)

{ write_option_struct( $value, $path ); }

}

Finally you simple call the function;

write_select_struct( $struct, 'category_id' );

which prints out you tree in a drop down list which can be modified into a tanle list or whatever you please.

The original program was implemented in 86 lines total. Thats it. Watch your memory.

DisAdvantages

In most cases you have to load the entire list in order to biuld the tree. So very large lists are personally discouraged if you are using it in real time.

Missing Parent keys will create undefined links in the tree.

Multiple functions are annoying.

The function that initially builds the list is kinda cryptic

Advantages

Simple, quick and manageable meaning that once you understand how the code works you can use in varied situations with fewer special attacks.

by owen () Post your comments on this article