ClarionLive show notes for July 12 2013

Owned by David Harms
Jul 12, 2013

Discussion about color, including some web gems and kuler.adobe.com. Bruce mentioned the importance of turning off shading when using terminal services. 

Code smell of the week - long parameter lists.

Mike's suggestions:

  • If you have more than a few parameters pass a group or a class. If a class, the class constructor can set defaults. 
  • If you need to track omittable state then add extra elements to the group/class to handle that.

Mike explored an alternative to InString which took a group (and later a class) as a parameter. That led to discussion of the relative merits of procedure calls vs method calls. 

Bruce wondered whether the changes had made the code any easier to write; in fact is was slightly more difficult to write, but it was easier to read. Mike pointed out that we spend far more time read any given block of code than we do writing it. 

Word of the day: Dispose

Greg Bailey explained that you need Dispose because Clarion doesn't have automatic garbage collections for objects you instantiate. There are intricacies, however.  

PostgreSQL - Joe Tailleur

Joe didn't get on the mic until almost noon because of some excessive chat beforehand. There was some early discussion of the compelling cost benefit of using PostgreSQL over commercial databases. Then Joe went into config settings, pointing out that PostgreSQL by default is excessively conservative. 

Clarion doesn't close connections when you close the browse - you'l use as many connections as the maximum number of threads you'll have open. Joe has seen as many as ten connections per user, and these are not closed until you exit the app. 

There may be some pooling going on however, perhaps on the ODBC side. 

Joe listed some queries you can use to check your current configuration, including these really important settings:

  • max connections
  • shared buffers
  • work mem
  • maintenance work mem
  • cache size
  • checkpoint segments

When you create a database you may want to set the owner to postgres. You don't want the users to have the rights to alter the database itself. 

Use group-based security so you only have to set rights in one place (or a few places). Then add users to the groups. 

Joe had some good guidelines for configuring security, which is done via the pg_hba,conf file.

The last line in the pg_hba.conf file should be a reject line for all connections that don't meet the prior rules. 

Recommended reading: Secure Hardening PostgreSQL by Scott Mead.

A few years back I was at OSCON and took in a session by Josh Berkus on securing PostgreSQL - some good info there too. 

Joe's driver string:

/BusyHandling=2, /LogonScreen=false

Use a global variable for the owner. Joe has two, one for admin and one for normal users. He builds the connection string following the usual approach (see http://www.connectionstrings.com/postgresql/). 

Joe has gone away from opening a file on the application frame (to keep a connection open). 

You can use domain authentication with pam on Linux (via pg_hba.conf); LDAP is available on Windows servers but it's fussy. 

JP brought up the citext data type, which adds case insensitive text for searching/indexes. You need to add a DLL to PostgreSQL and then you can 

Some discussions about naming issues, and more conversation around the key issues to be dealt with that are unique to PostgreSQL. These seem to mainly come down to case sensitivity, both in the data and in the definitions. Don't enforce any upper case characters in a label or you'll always have to use the label in exactly the same case. To avoid case sensitivity in the data either use a case-insensitive collation (which you can specify when you create a database) or use the citext type for type. JP made a strong argument in favor of citext. 

C9

At the end of the webinar Greg Bailey pointed out that there are five new C9-related posts on the ClarionSharp blog.

 

Â