Monday, January 25, 2016

NamesSpaces and Base Instincts

PHP 5.3 included a new superstructure called "namespaces" that allows people to divide functions (and consequently the people who write functions) into a hierarchical structure.

Just as titles go before the names of Dukes, Lords and Kings. The namespace syntax goes at the top of the function. When the compiler sees the magical word "namespace" it takes a extra step to parse the file and prepend all of the functions with backslash delimited strings to put each function in its place in the the hierarchy.

If I put the line:

namespace Lord\Kevington;

at the top of my code, the program would add the string "\Lord\Kevington\"  to my programs.

If I put the code:

namespace musings\of\peasants;

At the top of your programs; then the compiler would properly encode your work as the musings\of\peasants. The backslash denotes the different layers in the programmatic hierarchy.

If I had a function called said(). The compiler would automagically change the function name to: \Lord\Kevington\said() before compiling the programs.

It would do the same to the \musings\of\peasants ... but ... sorry, while I am thinking of profound things to put in \Lord\Kevington\Said(), I am just not all that interested in the musings of peasants.

The stated purpose of namespaces is to avoid name collisions. Collisions occur when two programmers use the same function name. The compiler balks when the programmers try to combine their code in a single unit and one of the programmers has to change a function name to make the code work.

Now, PHP is a language designed to produce web pages. Web pages require highly optimized code that is executed in a single call.

A good web program is streamlined and a good web developer knows each and every line of code used in the production of the production of the page.

To be frank, if the framework used to create web pages is having problems with namespace collisions, then the proper course of action is to streamline the framework.

And, to be fair, PHP was one of the last programs to implement namespaces. I suspect that a primary reason that PHP implemented namespaces was simply to be consistent with Java and what is taught at the university.

I took a long and serious look at namespaces when namespaces were released with PHP 5.3..

Since namespaces are simply about the internal organization of code and do not in anyway enhance the experience of visitors to my site, I decided not to implement namespaces.

I've noticed a large number of extremely loud voices on Stackoverflow and GitHub pushing namespaces. So I gave them a good second look over these last several days.

Namespaces seem to be preferred tool by the political animals that programmers should try to keep out of the programming department.

The problem of namespaces is that, since namespaces were designed as a meta-element that underlies all of the code in a program, once one person starts implementing namespaces the namespaces soon take over all code.

Namespace technology is very similar in form to the ideologies developed by Hegel and Marx. The technology works at a root level to divide things up so that things can be captured and controlled by a ruling class.

When people set in to dividing things up at a root level, you can become powerful and force your political enemies into subservience.

People who the little reindeer games called "namespaces" are political enemies.

If you are politically ambitious programmer, you can start simply by including namespaces in your projects. This sets you up to becoming the politically powerful keeper of the keys.

The cool part about the game is that, since it takes place at a root level, once the namespace game is started everybody has to play or get excluded.

Namespace technology is a political tool used by base political element of the IT world to decide who gets included and who gets excluded. Sadly, IT Departments are often the hotbeds of interoffice politics.

The keeper of the namespaces is one of the most powerful hacks in an IT department full of hacks because, the person who designs the namespace hierarchy gets to decide who is included and who is excluded.

Isn't that spiffy?!

Of course, the really, really, really funny thing about namespaces is that the technology doesn't actually solve a problem.

Namespaces are as susceptible to name collisions as are all of the other conventions programmers adopted to avoid name collisions. In fact I can guarantee that name collisions will take place.

Imagine a situation where a large project branches. Two groups begin to develop extremely similar code. Anyone that tries to combine elements of these divergent project will have name collisions taking place at both the namespace level and the code level.

Yes, people will try to solve the conflicts by adding layers to the namespaces hierarchy, but each of these layers simply add to the long term administrative cost of the code.

Anyway, I spent the last several days researching namespaces and deciding if I want to use the insipid technology. I hate the technology, but since its a root technology, I know that those that don't play along with the game get excluded.

My heart screams RESIST, while my brain says you must go along to get along. As for now, I will maintain two versions of my code. One that uses namespaces and one that does not and I'll decide later which project to keep and which to ditch.

I really hate these political drones who want the world separated in political hierarchies. All they do is make work while adding no value.

The really funny part about namespaces is that namespaces themselves create

Namespaces and Security

 Note, I haven't examined all of the security ramifications of namespaces. Namespaces allow programmer to create two very similar code bases. (This is not hard to do with the copy command.)

I imagine that one could play some really good jokes on fellow programmers by switching namespaces. What is the difference between:

namespace all;
and
namespace a11;
?
Anything that makes it easy to switch code on a project gives me the willies.

Tuesday, January 19, 2016

Password Program

It is very important for web designers to protect the passwords with which they are entrusted.

A huge security risk happens when hackers break into a site and steal the user database with all of the passwords. If the passwords are poorly secured, hackers can figure out the preferred user name of a person and their preferred password.

(Many users use the same userName/PassWord combination on all sites. If a hacker cracks one password the hacker can go after accounts on different servers. It is wise to use different passwords for every online account. This is especially true of any account involving money.)

Web programs need to encode passwords in ways that make it difficult for the hacker to reassemble the password.

There are some nice industry standard algorithms that do a good job encoding passwords. But hackers have built massive "rainbow tables" that help them discern encoded passwords.

The standard PHP password is called password_hash() . This program tries to thwart hackers by creating a 60 character hash from the password. The PHP manual says they plan to move to a 72 character string shortly.

Storing 72 characters for a password seems absurd to me.

Since I have a small site. I think it will be better to create my own encoding program. The program does some fancy footwork with primes and bits to create a hash that is difficult to unhash. Here is the basic code used in my program. This second link is a form that tests the hash generator.

The program is still weak on handling multi-byte UTF8 characters and was optimized for passwords from 8 to 16 characters.

The reason that I wrote the program was to say that If we are forced to produce horrendously long password hashes, the password programs should output binary strings and not super long strings of characters.

I will change the value of the primes on my production server and intend to rewrite the program in c, just as soon as I learn to program in c. I need to improve the UTF8 support. Right now it uses each character in a multi-byte character, when I should only look at the last character.

The output is a 16 character binary string which is a bit more manageable than a 72 character string.

Off course, storing passwords in a Pain in the Tush. I've actually started using Oauth for authentication. Of course, that means that when a hacker breaks into a Twitter account the hacker can attack all the sites using OAuth.

Saturday, January 16, 2016

Windows 10

Yesterday was a total waste.

When I turned on the computer, the screen told me that Microsoft was desperate to do an update. So I clicked the okay button and went off to do chores. When I came back an hour later; I discovered that MS was knee deep into upgrading me to Windows10. I decided not to abort the operation.

The computer took until 4:30PM to complete the upgrade. A whole day wasted on an upgrade.

To make matters worse. While the upgrade was running, I discovered that something was horribly wrong with my email set up and I couldn't fix the problem because my computer was knee deep in an upgrade.

(Mental note: One of these days I should get  a second computer.)

I wasn't able to debug the email problem until 9PM. At 11:00PM I finally figured out the problem. In the MX record on plusroot.com, I had used the default value for priority which was 0. Apparently this is invalid. The mail worked for the first few days, but the invalid entry propagated and blocked incoming email.

I've concluded that the two most important steps in diagnosing email are (from a Unix terminal):

First use the telnet command to log into the computer to see if you can send an email manually.

telnet example.com 25

If you can send the email, then use the dig command to check the MX record:

dig example.com MX

I am now waiting to see if the changes I made to the MX record propagate through the system correctly.

Tuesday, January 12, 2016

Drinker's Permit

Apparently some states are thinking of lowering the "drinking age."

Personally I think the very existence of a "drinking age" is a net negative as it builds a myth that getting drunk is part of being an adult.

Completely eliminating the drinking age would have the effect of throwing children to wolves as there is subclass of human that seeks to take advantage of the young and inexperienced.

There are people who get kids drunk or stoned to take advantage of them.

The classical liberal approach to governance realizes that there is a freedom paradox.

A free society cannot give people the freedom to violate the liberties of their neighbors.

Alcohol diminishes self control. The wolves who ply children with drugs and alcohol are using chemicals to violate the freedom of the kids they target.

Since alcohol diminishes self control, I think the best approach to the question of drinking is to figure out how to structure the introduction of alcohol so that people gain control over alcohol before alcohol gains control over them.

I think it would be worthwhile to discuss concepts such as "Drinkers' Education" or a "Drinker's Permit" as ways to mitigate the damages caused by a set "drinking age."

Drinker's Education might take of the form of simply allowing wine and beer tasting events that do not require IDs. The events would have to have a built in safe guard to prevent over consumption. Drinkers' education might also take the simple form of allowing anyone to order a single drink with a meal at a restaurant without ID.

The "Drinkers' Permit" concept falls along the idea that people should learn about alcohol and its dangers and ease into drinking rather than waiting for some magic drinking age event where people drink in excess, lose self control and risk falling into the hands of manipulators.

It ideals of liberty is no some maniacal belief that we should throw children to the wolves hoping that the survivors will come out stronger. It is a realization that a society restrained by self-control is stronger than one depending on state control.

I believe that our drinking age and drug laws have made our society worse. The laws have created and funded a subculture where people where children and manipulated and drawn into addiction by the worst elements of our society.

That drinking laws are destructive does not mean that all alcohol laws are destructive. Imagine a rogue who plies kids with drugs and takes advantage of them. This rogue element is engaged in a base violation of the liberty of the targeted victims.

A person who violates others by plying them with drugs is doing as much if not more damage than a person who breaks your front window then walks off with your TV.

The discussion of eliminating these destructive laws must acknowledge the dangers of substances which diminish self control. A society of drug addicts is not a free society as the addicted are slaves to the pushers of addiction.

The concepts of "drinkers' education" or of a "drinker's permit" would fall into the moderate view favored by the US founders and the classical liberal tradition which promoted moderation and avoidance of paradoxes.

I would prefer the development of structures to promote self promotion before lowering the "drinking age," for lowering the drinking age does little more than change the age of the group that engages in in binge drinking.

Unicast v. Multicast

The next step in my upgrade is to get a handle on the current state of IPV6.

There are fewer IP addresses than people. The world exhausted its supply of IPV4 addresses; so the world needs to do something.

Unfortunately, instead of extending IPV4 by a few magnitudes, the powers that be designed IPV6 to replace IPV4.

The ugly side of this change is that IPV6 was designed from the top down to favor large publishers over small and individual publishers.

IPV4 was built on a unicast model. In this model, client PCs create a connection with the host server and pull down the desired information. The individual (and consequently the individual who owns the client) has greater control.

IPv6 is built around multicasting (aka, broadcasting). The IPv6 will be optimized for large centralized concerns that seek to pump out volumes of information to client minions.

I prefer the unicast model to the broadcast model as it encourages people to be a bit more deliberative in their intake of media. The unicast framework was also somewhat of an equalizers since the cost of getting information off a small local server was basically the same as getting it from a huge firm (Huge firms can realize economies of scale, but are not favored by the network structure itself.).

I hope that internet users resist the multicast features of IPv6. But the powers that be are powerful and they prefer a top-down controlled society to a free society and are adept at getting their way.

Life Wasted on Email

That was a bummer. I've spent the last several days setting up an email server. (grumble, grumble. I hate email).

The reason I am moving to a private server is that I am trying to figure out ways to reduce the amount of spoofed email sent my domain addresses.

I had pretty much stopped sending emails myself. I save all my sent emails. (minus test emails which I do delete). My primary email account shows that, In 2013, I sent 16 emails. In 2014 I sent 8 emails, and In 2015 I sent 1.

What happened to me is as follows: I am developing a number of community sites, which have a decent reputation.

I went with a premium web host run. The owner of the firm had a heart attack and died. His employees bought the firm and ran it into bankruptcy and a criminal spammer bought the assets and used my domains to engage in criminal spamming. The web host has access to the servers. Apparently he sent hundreds of millions of spams using my domains and signed up for every spammy email service available.

The result is that, even eight years after changing web hosts, I am deluged with spam.

I still get over 200,000 bounced emails a year. It is a complete nightmare for a person who doesn't like email to begin with.

I put the email on its own server because I want email quarantined from the rest of my doings and hopefully it will be easier to monitor.

The new email server is only working on my development account. It will be interesting to see how the configuration holds up with I point the production domains at it let the deluge begin.

Of course, I think it silly to have spent so much time and effort on email when I actually don't intend to use it for communication. The main thing I am trying to do is stop the spam that spoofs my domain in the sending address, and their is nothing I can do about that.

(Note, I have my domains marked up with http://www.openspf.org tags. My current web host says they have not detected spam actually coming from my account. I am hoping that by hosting my own account that I will be able to say definitively that no spam comes from my site.

Tuesday, January 05, 2016

Privacy Policy

Web Developers are forced into posting privacy statements on their sites.

Personally, I find the pre-occupation with privacy statements amusing as the people who are selling user information are better at writing the statements than those who are not.

Unfortunately, I am not independently wealthy and need advertisers so I can pay my web hosting fees. One can make the argument that anyone who uses advertisers is selling user information; thus committing a crime against privacy.

But, as a small web site, I have neither direct access nor receive direct payment for the user information.

The reverse is actually true. So, let's say I was a successful affiliate marketer and ran a great campaign that resulted in hundreds of sales.

The advertisers will take the information that they gather about my campaign and figure out how to cut me out of the picture. Marketing is an ugly business.

Anyway, I hate writing privacy statements. Since I am in directly in the business of selling user information, I usually just fill the statements with silly jokes.

But, this time I decided to do something different.

Last month I wrote a program to view the web code on my site; So, I rigged my privacy policy  so that it shows the code I use to log hits and shows all of the information I've collected on the visitor's IP address. Here is the Source Code for Log_Hit().

I repeat. I have to track information on my site to monitor performance and to defend against DDOS attacks. In a DDOS attack, I have to start blocking the attacking IPs.

Small web sites don't have enough data to violate your privacy. It's the big players that you have to worry about. Unfortunately, the privacy rights advocates are forcing small sites to apologize for cookies and intrusive large companies that the small sites simply cannot control.

Monday, January 04, 2016

Applying the Concepts from "Coaching" to Sports

This was a funny conversation.

A large number of people with new age ideals have started calling themselves "coaches."

The name coach has a nice ring that reminds people of school sports.

We now have business coaches, life coaches, food coaches, etc., and I wish the best for everyone playing this game.

So, I was listening to to some people talking about how to apply the principles of life coaching to sports. I see nothing wrong with this.

The conversation had several declarative statements about the what a coach does, and I made the comment that there is already a position in sports called a "coach," and that, when applying principles from life coaching to sports, one should be wary of their terms.

A life coach is an advisory role. A team coach is an authoritative title. An actual sports coach calls the shots and decides who plays, etc..

The two people who were talking about applying life coaching to sports launched in on me as if I were the worst person on the planet.

If not for the people yelling at me, the conversation was quite hilarious. I think one could do a great comedy sketch with a fluffy life-coach at odds with a hardened sports coach.

It might not work. Folks on the left are not capable of laughing at themselves.

Friday, January 01, 2016

Rolling Back Time

Would it be nice if life had a rollback command?

If we found our day was unproductive, we could just issue the command and do the day again.

This was an unproductive day. So, I wrote a function to wrap the PDO database connection and decided to add support for the transaction processing features.

Transaction processing works as follows. You start a transaction. Run commands to insert and update tables. If something goes wrong; you can rollback the whole transaction.

I've worked on projects that made heavy use of transaction processing and have come to see transaction processing as a crutch for bad design.

Rather than using transactions, I used status variables and events tables. Let's say I have a piece of problematic code such as a call to an external credit card processor. I want a complete trace of information through the problematic code. If the transaction crashes, I can determined where it crashed and figure out why.

Anyway, I wasted the day testing the transaction features of different databases and have simply concluded that I don't even want any form of transaction processing in my code, and I would prefer not even seeing it on the server.

I just wish I could rollback this day and live it over on a more fruitful endeavor.

This page shows my SQL Wrapper code as it currently stands. The link shows a Test Script which calls the code. The test establishes connections to multiple databases including a remote DB.

I need to amend this post. I've reduced my need for transactions down to one simple operation: Updating a sequence. Updating a sequence requires two SQL statements: an UPDATE seq = seq+1; and SELECT seq;. One has to wrap those two statements in a transaction; otherwise there is a possibility of two transactions getting the same seq. I usually get the sequence with a stored procedure.

I wish Database manufactures would include a seq++ operation. An inline increment is one of the easiest pieces of code to write. Since people love the ++ operator, I am surprised that it doesn't exist already.