Thursday, July 10, 2008

MySQL Stored Procedures are EVIL

A lot of developers are taught to use database stored procedures, triggers and database constraints at every possible opportunity, and they cannot understand why an old dinosaur like me should choose to take an opposite view. The reason can be summed up quite simply:

You only know what you have been taught, whereas I know what I have learned.

I was weaned on file systems and databases which did not have any facilities for stored procedures and triggers, so I learned how to build applications without them. When such facilities became available my colleagues and I still never used them for practical reasons:

* It meant learning a new language, and we didn't have the time.
* It meant taking longer to implement and maintain, therefore cost more to develop. This is an important consideration for a software house which can only win business by providing cost-effective solutions.
* There was no advantage in doing so, so why bother?

Our golden rule was:

Use stored procedures and triggers only when it is an absolutely necessity.

This is in total conflict with the attitude of today's wet-behind-the-ears tenderfoot greenhorn who seems to think:

Use stored procedures and triggers at every possible opportunity simply because you can.

Amongst the arguments in favour of stored procedures are:

Stored procedures are not as brittle as dynamic SQL
--------------------------------------------------------------

Some people argue that putting ad-hoc SQL in your business layer (BL) code is not that good. Agreed, but who said that the only alternative is stored procedures? Why not have a DAL that generates the SQL query at runtime based on information passed to it by the BL? It is correct to say that small changes to the database can have severe impacts on the application. However, changes to a relational model will always have an impact on the application that targets that model: add a non-nullable column to a table and you will see what I mean. You can use stored procedures or ad-hoc queries, you have to change the calling code to make sure that column gets a value when a new row is inserted. For Ad-hoc queries, you change the query, and you're set. For stored procedures, you have to change the signature of the stored procedure, since the INSERT/UPDATE procs have to receive a value for the new column. This can break other code targeting the stored procedure as well, which is a severe maintenance issue. A component which generates the SQL on the fly at runtime doesn't suffer from this: it will for example receive an entity which has to be saved to the database, that entity contains the new field, the SQL is generated and the entity is saved. No maintenance problems. With a stored procedure this wouldn't be possible.

Stored procedures are more secure
------------------------------------------

This is a common argument that many people echo without realising that it became defunct when role-based security was made available. A good DBA defines user-roles in the database, and users are added to those roles and rights are defined per role, not per user. This way, it is easy to control which users can insert / update and which users can for example select or delete or have access to views in an easy way.

With a view it is possible to control which data is accessed on a column basis or row basis. This means that if you want user U to select only 2 or so columns from a table, you can give that user access to a view, not the underlying table. The same goes for rows in one or more tables. Create a view which shows those rows, filtering out others. Give access rights to the view, not the table, obviously using user-roles. This way you can limit access to sensitive data without having to compromise your programming model because you have to move to stored procedures.

It is also said that stored procedures are more secure because they prevent SQL injection attacks. This argument is false for the simple reason that it is possible to have a stored procedure which concatenates strings together and therefore open itself up to sql injection attacks (generally seen in systems which use procedures and have to offer some sort of general search routine), while the use of parameterized queries removes this vulnerability as no value can end up as being part of the actually query string.

Stored procedures are more efficient
--------------------------------------------

The execution of SQL statements in stored procedures may have been faster than with dynamic SQL in the early days of database systems, but that advantage has all but disappeared in the current versions. In some cases a stored procedure may even be slower than dynamic SQL, so this argument is as dead as a Dodo.

Performance should not be the first question. My belief is that most of the time you should focus on writing maintainable code. Then use a profiler to identify hot spots and then replace only those hot spots with faster but less clear code. The main reason to do this is because in most systems only a very small proportion of the code is actually performance critical, and it's much easier to improve the performance of well factored maintainable code.

While stored procedures may run faster, they take longer to build, test, debug and maintain, therefore this extra speed comes at a price. If the same function can be performed inside application code at an acceptable speed, what is the advantage of spending more money to make it run faster at a more-than-acceptable speed? It is OK to use stored procedures when you absolutely need a performance gain, but until then they're nothing but premature optimization.

The company has paid for them, so why not use them?
----------------------------------------------------------------

A similar argument is that by not using what the company has paid for, you are effectively wasting the company's money. I'm sorry, but using something because it's there is just not good enough. If I can achieve something inside my application with application code, then I must be given a very good reason to move it out of my application and into the database. Believe it or not there are costs involved in moving logic from one place to another, and those costs must be offset by measurable benefits.

Application code or database code - it's still code, isn't it?
---------------------------------------------------------------------

No it's not. Application code is built using a programming language whereas SQL is nothing more than a data manipulation language, and is therefore very limited in its scope. There is absolutely nothing that can be done in a stored procedure that cannot also be done in application code, but the converse is not true.

Amongst the arguments against stored procedures are:

It mangles the 3 Tier structure
-------------------------------------

Instead of having a structure which separates concerns in a tried and trusted way - GUI, business logic and storage - you now have logic intermingling with storage, and logic on multiple tiers within the architecture. This causes potential headaches down the road if that logic has to change.

Stored procedures are a maintenance problem
--------------------------------------------------------

The reason for this is that stored procedures form an API by themselves. Changing an API is not that good, it will break a lot of code in some situations. Adding new functionality or new procedures is the "best" way to extend an existing API. A set of stored procedures is no different. This means that when a table changes, or behaviour of a stored procedure changes and it requires a new parameter, a new stored procedure has to be added. This might sound like a minor problem but it isn't, especially when your system is already large and has run for some time. Every system developed runs the risk of becoming a legacy system that has to be maintained for several years. This takes a lot of time, because the communication between the developer(s) who maintain/write the stored procedures and the developer(s) who write the DAL/BL code has to be intense: a new stored procedure will be saved fine, however it will not be called correctly until the DAL code is altered. When you have Dynamic SQL in your BL at your hands, it's not a problem. You change the code there, create a different filter, whatever you like and whatever fits the functionality to implement.

Microsoft also believes stored procedures are over: it's next generation business framework MBF is based on Objectspaces, which generates SQL on the fly.

Stored procedures take longer to test
--------------------------------------------

Business logic in stored procedures is more work to test than the corresponding logic in the application. Referential integrity will often force you to setup a lot of other data just to be able to insert the data you need for a test (unless you're working in a legacy database without any foreign key constraints). Stored procedures are inherently procedural in nature, and hence harder to create isolated tests and prone to code duplication. Another consideration, and this matters a great deal in a sizable application, is that any automated test that hits the database is slower than a test that runs inside of the application. Slow tests lead to longer feedback cycles.

BL in stored procedures does not scale
----------------------------------------------

If all the business logic is held in the database instead of the application then the database becomes the bottleneck. Once the load starts increasing the performance starts dropping. With business logic in the application it is easy to scale up simply by adding another processor or two, but that option is not readily available if all that logic is held in the database.

If you have a system with 100's of distributed databases it is far more difficult to keep all those stored procedures and triggers synchronized than it is to keep the application code synchronized.

Stored procedures are not customisable
-----------------------------------------------

This is a big issue if you want an application where the customer can insert their own business logic, or where different logic is required by different customers. Achieving this with application code is a piece of cake, but with database logic it is a can of worms.

Database triggers are hidden from the application
------------------------------------------------------------

A big problem with database triggers is that the application does not know that they exist, therefore does not know whether they have run or not. This became a serious issue in one application (not written by me) which I was maintaining. A new DBA who was not aware of the existence of all these triggers did something which deactivated every trigger on the main database. The triggers were still there, they had not been deleted, but they had been turned off so did not fire and do what they were supposed to do. This mistake took several hours to spot and several days to fix.

Version Control
-------------------

It is easy to control all changes to application code by running it through a proper version control system, but those facilities do not exist for stored procedures and triggers. How much damage could be caused if a stored procedure were to get out of sync with the application code? How easy is it to check that the application is running with the correct versions? How much more difficult would it be if the application you were supporting was running on a remote site with nothing more than a dial-up connection?

This is a reason why some teams avoid stored procedures like the plague - it eliminates an area of potentially disastrous screw-ups.

Vendor lock-in
------------------

You may think that this is not a problem if you build and maintain the applications for a single company where a change in database vendor is highly unlikely, but what happens should the company decide that their DBMS is no longer flavour of the month and they want to change to a different DBMS? This may be due to several factors, such as spiraling costs or poor performance, but when it happens you will find that a lot of code will have to be rewritten. Porting the data will be one exercise, but porting the stored procedures and triggers will be something else entirely. Now, if all that logic were held inside the application, how much simpler would it be?

Believe it or not there are people out there who write applications which are database-independent for the simple reason that the applications may be used by many different companies, and those many companies may not all use the same DBMS. Those that do use the same DBMS may not be using the same version, and stored procedures written for one version may not be compatible with another.

As far as I am concerned the use of stored procedures, database triggers and foreign key restraints is OPTIONAL, not MANDATORY, therefore I am free to exercise my option not to use them. That is my choice, and the software that I produce does not suffer in any way, therefore it cannot be defined as the wrong choice.

The web application framework that I have built using PHP does not use stored procedures, database triggers or foreign key constraints, yet it does not suffer from any lack of functionality. This is possible simply because I can do everything I want inside my application where it is instantly accessible and customisable. To those of you who instantly jump to the (wrong) conclusion that this must mean that I have to write a huge amount of duplicated SQL statements my answer is simple - I don't write any SQL statements at all, they are all generated dynamically at runtime. This is all due to the framework being built using the 3 Tier Architecture which has a clear separation of concerns:

* There is a separate object in the Business Layer for each database table. This is where all business rules are applied as data passes from the Presentation Layer (UI), through the Business Layer to the Data Access Layer, and back again. The Business Layer does not have any direct communication with the database - this is all handled by the Data Access Layer.
* There is a single object in the Data Access Layer known as the Data Access Object (DAO). The DAO receives a request from the Business Layer and dynamically constructs and executes the SQL query string to satisfy that request. This implementation means that I can easily switch to another DBMS simply by switching to another DAO, and without having to change a single line of code in any Business Layer object.
* Referential integrity is also handled by standard code within the framework and requires no additional coding from any developer whatsoever. It uses information which is exported from the Data Dictionary which tells it what to do with every relationship, and the standard code in the framework simply performs the relevant processing. The advantage of this approach is that it is easy to amend or even turn off any of these rules at runtime, which makes the application infinitely more flexible.
* All changes made to the database can be logged without using a single database trigger. How? By adding extra code into the DAO to write all relevant details out to the AUDIT database. This functionality is totally transparent to all the objects in the Business Layer, and they do not need any extra code to make it work.

Monday, May 12, 2008

Send Your Name to the Moon Aboard LRO!

NASA invites people of all ages to join the lunar exploration journey with an opportunity to send their names to the moon aboard the Lunar Reconnaissance Orbiter, or LRO, spacecraft.

The Send Your Name to the Moon Web site enables everyone to participate in the lunar adventure and place their names in orbit around the moon for years to come. Participants can submit their information at http://lro.jhuapl.edu/NameToMoon/, print a certificate and have their name entered into a database. The database will be placed on a microchip that will be integrated onto the spacecraft. The deadline for submitting names is June 27, 2008.

"Everyone who sends their name to the moon, like I'm doing, becomes part of the next wave of lunar explorers," said Cathy Peddie, deputy project manager for LRO at NASA's Goddard Space Flight Center in Greenbelt, Md. "The LRO mission is the first step in NASA's plans to return humans to the moon by 2020, and your name can reach there first. How cool is that?"

The orbiter, comprised of six instruments and one technology demonstration, will provide the most comprehensive data set ever returned from the moon. The mission will focus on the selection of safe landing sites and identification of lunar resources. It also will study how the lunar radiation environment could affect humans.

LRO will also create a comprehensive atlas of the moon's features and resources that will be needed as NASA designs and builds a planned lunar outpost. The mission will support future human exploration while providing a foundation for upcoming science missions. LRO is scheduled for launch in late 2008.

The Lunar Reconnaissance Orbiter is being built at Goddard. The mission also will be managed at the center for NASA's Explorations Systems Mission Directorate in Washington.

Send Your Name to the Moon is a collaborative effort among NASA, the Planetary Society in Pasadena, Calif., and the Johns Hopkins Applied Physics Laboratory in Laurel, Md.

Sign up to send your name to the moon. Names will be collected and placed onboard the LRO spacecraft for its historic mission bringing NASA back to the moon. You will also receive a certificate showcasing your support of the mission.

The deadline is June 27, 2008 for the submission of names.

LRO's objectives are to find safe landing sites, locate potential resources, characterize the radiation environment, and demonstrate new technology.

Send your name to the Moon!

Wednesday, March 26, 2008

It's My Birthday

That's all I really have to say. Should have taken the day off work, but I have too much to do. I am now 27. Which is scary close to 28, which becomes very close to 30...

Tuesday, March 11, 2008

Work Quickly to Convert Mortgage Leads

If you're in the highly competitive mortgage lending business you know the importance of gaining mortgage leads.

But getting leads is only the start. Whether you generate leads yourself or buy mortgage leads online you need to act quickly and decisively to have the best possible chance of converting leads into actual money-in-the-bank business. With high quality leads and hard work on your part you should be able convert around 10% of your leads into loan sales.

Act Quickly, Even if You Can't Make Contact Personally

Fast action on all your leads is crucial. Potential mortgage borrowers will not wait around for you to contact them and there are other brokers out there anxious to have their business. If you find you simply do not have enough time to contact your leads promptly consider hiring an agent to make calls for you.

This agent does not have to be a trained professional.

While having a trained agent make the initial contact with your leads is certainly desirable it is better to make contact with the lead quickly, even if this means using the services of untrained family members or students. Have your agent simply make a friendly call and set up a time for you to get back to them. This will establish your interest in providing mortgage funds, get your name into the leads memory banks and help you to prioritize your telephone schedule. If you wait two or three days to make any contact on a hot lead, chances are another mortgage broker will have closed the sale.

Be Sure to Follow Up

Once you have established a time to call back to your lead, make sure you are prompt. Mortgage lending is about personal service and a potential borrower will not appreciate being kept waiting for your call. If you do not make the sale on your first personal contact with the lead be sure to call again. The borrower may not find the terms he or she is looking for right away.

And Then Follow Up Again

If you do not close the sale with a potential client don't strike them off your list. Anyone who is interested in Real Estate is a potential client. Follow up a month after initial contact and then again after six months. Conditions may have changed for this potential borrower putting him or her back into the Real Estate market. Or they may have friends or family that are looking for a mortgage.

To convert mortgage leads effectively you need to make contact quickly and often. The few minutes it takes to make a call could make your mortgage lending business a lucrative one.

How to Generate More Mortgage Leads

When people are considering the purchase of a home or property it's likely that the first person they will contact is a Real Estate agent and this makes realtors a prime source to help you generate mortgage leads.

As a mortgage broker you have expertise that is needed by all the parties concerned in a property sale. The buyer needs you to help find the right funding package, the seller needs your advice on what he or she can do to assist the buyer and help the deal to go through and the realtor needs you help tie up all the financial loose ends that the deal depends on.

You can capitalize on your expertise and generate more mortgage leads by cultivating relationships with Real Estate agents and buyers and sellers that they are in contact with.

Consider Moving Your Office

If you are in a position to do so think about moving your office to a location very near to a successful Real Estate office. If you are friendly with the agents in that office and you are near by it's likely the agents will point customers in your direction when mortgage availability questions arise.

Offer Free Help

Not all realtors keep abreast of all the new mortgage options being offered and many realtors do not think creatively when it comes down to the nuts and bolts of finance. As a mortgage broker you do both of those things. Offer your services to the agents in several Real Estate offices. Let the agents know that they can call you anytime for free advice on ways and means to help them make the deal go through.

You can take this one step further by offering to attend open house events to answer any and all of the questions potential buyers may have regarding mortgage options. Be sure to have plenty of business cards on hand.

As a mortgage broker you are an intrinsic part of most property sales and closely tied to the work of the Real Estate agent. Take advantage of this relationship by offering your services to realtors and helping them to make more sales and you are bound to generate far more mortgage leads.

Use The Internet To Gather Mortgage Leads

If you're in the business of brokering mortgage loans you need to find methods of developing leads.

Buying leads is fast but the leads you purchase may not be fresh and they may not be accurate. For many brokers the preferred method of gaining mortgage leads is to generate their own.

One way to do this is to develop relationships with Realtors. Another effective method is to use the power of the Internet to generate a steady stream of mortgage leads.

Offer Valuable Information on a Website

More and more people are looking to the Internet for information when they are considering a property purchase. Build a website that offers information on the intricacies of mortgage lending. Explain insider terms and alternative financing methods. Use the expertise you have developed to give readers data they cannot easily get elsewhere. The more information you offer the more traffic you will attract so join forces with other mortgage brokers and Realtors to bring more content to your website.

On every page of the site have your phone number and email address so leads can easily contact you for personalized mortgage information. On every page have a link to a form where the reader can submit details that will allow you to contact them.

Keep the website simple and professional looking. Avoid bright colors and anything that flashes or moves. Your site should indicate that you are a sober professional that is willing and able to help with any mortgage financing questions.

You may need to advertise to build traffic to your site. Consider small ads in local real estate guides and newspapers. Consider radio advertising. These advertising methods are inexpensive and effective.

One way or another you will need develop your mortgage leads. A well done web site with valuable content can bring you a steady stream of fresh leads for years into the future.

Santa Barbara Real Estate Gets Wish Granted From the FHA

After a fair amount of backlash and letter writing, the government this week raised the mortgage limits for loans guaranteed by the Federal Housing Administration in several high cost California counties, including Santa Barbara CA. The maximum amount of $729,750 will now be allowed for the Santa Barbara area and only time will tell what effect this will have on the housing market here. For many residents here in the Santa Barbara area where the average price of a single family home is over $ 1 Million, this will allow homeowners with high-rate sub-prime mortgages to refinance into federally insured loans. Additionally, it will allow buyers that are out there to obtain better loans for the lower end market.

Overall the market here in Santa Barbara has seen a significant increase in activity during the first 2 months of 2008, with pending sales abound across the board. I have talked with many lenders and Realtors in the last several weeks and the assumption is that this stimulus package will only increase activity in the market.

The Washington AP stated, "The package also includes a temporary increase in the cap on mortgages that the government-sponsored mortgage companies Fannie Mae (NYSE:FNM) and Freddie Mac (NYSE:FRE) can buy or guarantee from $417,000 to $729,750. The idea is to stoke investor demand for securities made up of more expensive mortgages -- so-called jumbo loans -- backed by Fannie and Freddie, the two biggest mortgage financers in the country. That would drive interest rates lower and spur home buying and refinancing."

Other California high cost counties that received the maximum level for FHA loans are Alameda, Contra Costa, Los Angeles, Marin, Monterey, Napa, Orange, San Benito, San Francisco, San Mateo, Santa Clara, Santa Cruz and Ventura.

How to Save On Your Private Mortgage Insurance (PMI)

Private mortgage insurance (PMI) is usually required when a prospective home buyer doesn't have a large enough down payment (typically less than 20 percent) to put down on a home. These premiums can cost anywhere from one hundred to a few hundred dollars per month. However, there is a way to save money on your private mortgage insurance, so keep reading to learn how.

1. Cancel your private mortgage insurance (PMI) as soon as you can.

Most PMI's can be canceled once you've put enough equity into your home to equal 20 percent of the loan amount, or the home has appreciated enough in value to bring up the value of your initial investment.

This cancellation won't happen automatically though; you need to actually call up your bank and get the ball rolling. To cancel your PMI, you'll need to prove the current market value of your home and that you've paid at least 20 percent of the equity initially borrowed to purchase the home.

To do this, have all your mortgage payments filed away and bring a summary of recent property listings from your area that show the current market value for a standard home similar to yours.

2. Look to government subsidies.

The Federal Housing Administration (FHA) offers what's called an FHA Home Loan. These aren't actual loans, but rather they provide insurance for home buyers who have low down payments, as low as 3 percent of the home's market value.

Instead of you having to pay for private mortgage insurance, the FHA Home Loan program insures the loan, meaning you can save on your insurance and even secure a better interest rate. Not all lenders participate in the FHA program, so look for one in your area. Also, FHA home loans are subject to caps that differ depending on your county or region.

3. Are you a veteran?

Through the Department of Veterans' Affairs home buying program, you may be eligible for mortgage insurance coverage through the VA. They'll insure a purchased home, up to 100 percent financing, and save you the cost of private mortgage insurance (PMI). There are limits though on the price of the home, and this will fluctuate depending on your region or county.

4. Consult with a broker.

Before you opt for your bank or lending institution's standard PMI, ask if you can obtain your own private mortgage insurance. You can sometimes find lower rates from a private insurer rather than going directly through your bank.

Barclays Launches A New Mortgage Products

Barclays and ABSA has launched a new mortgage product that will allow UK citizens to buy property overseas and non-UK citizens to buy property in the United Kingdom.

ABSA is the largest mortgage provider is South Africa. Together with Barclays the make the perfect team in providing expert mortgage advice and offer the best mortgage products for Barclays and ABSA costumers.

There are some aspects that affects the mortgage applicants like the foreign exchange control rate when they decide to purchase a property in a foreign country. For example, if a UK resident wants to purchase a property in a foreign country, they can only do so if Barclays or ABSA is present in that specific country. They will also need to comply with the exchange control rulings which states how much money you are allowed to take abroad. UK residents or any other resident, where Barclays is present can qualify for loans up to 50% of the total loan value in South Africa.

Barclays international mortgages will introduce you to experts who will give you the necessary advice on tax implications, exchange control regulation, legal contracting across borders, credit lending policies and economic outlook on interest rates and exchange rates.

For international investors, whether they decide to buy a home in South Africa, a holiday home or just invest, will be given the necessary expert advice and guidance from ABSA international mortgage. They will also be given tools, designed and developed to best meet their needs.

South African residents who wish to purchase a home in the UK or any other territory where Barclays is present will be assured to be assisted by a reputable financial institute that has an established pedigree in financing international purchases.

Barclays and ABSA joined together are now your perfect solution for to international mortgages.

Foreign National Mortgages Are Easy To Qualify For In The US

If you're one of many foreign nationals looking to pick up residential properties in the United States dirt cheap you are more than likely going to need a foreign national mortgage to help you purchase those US properties. The good news is that it is fairly easy for a foreign national to get approved for a foreign national mortgage in the US. Lenders will usually only go up to a loan to value of 65% on foreign national mortgages, so you will have to put a large down payment on the property. That means if the home is selling for $200,000, you would need a $70,000 down payment. If you have US credit and verifiable work income in the US the loan to value could be higher because you may be able to qualify for a Fannie Mae conventional mortgage although most foreign nationals use the stated income program at 65% LTV. A stated income foreign national mortgage means that they will not verify your income. They will also not verify your assets if this is the only property that you own in the US.

Interest rates on a foreign national mortgage are going to be a little higher than a Fannie Mae mortgage because it is a riskier loan for the lender to make. Think about it, you reside in a different country. The mortgage lenders offer 30 yr fixed rates and 3 & 5 yr adjustable rate mortgages if you think that you will not be holding onto the property that long.

If you are a foreign national and you purchase a home for cash in the US, you will have to wait at least a year to refinance and take out any equity that you may have. That is why foreign nationals are better off purchasing the homes with a foreign national mortgage instead of paying cash. I receive calls all the time from foreign nationals that paid cash for a US property a couple of months ago and now want to get that cash back out. I have to say, sorry, we can't do it. You'll have to wait a year from the date that you purchased the US property to pull out any cash.

It will take about 2 to 3 weeks to close on your foreign national mortgage once you submit your information to a mortgage broker so be sure and fax your signed sales contract to your mortgage broker as soon as you get it otherwise you could delay the closing.

Balloon Mortgages - What You Need to Know

This article will go over the basics of balloon mortgages - explaining how they work, the benefits and drawbacks of balloon financing and how you can apply for one. Keep reading to learn more.

What are balloon mortgages?

Balloon financing is intended to be short-term financing, but the initial monthly payments work like a fixed-rate mortgage. Basically, a balloon mortgage has a short term loan agreement, from just a short year to a more typical term of five or seven years, but the total amount borrowed reflects a longer term loan.

In such an agreement, the remaining balance is due at the end of this short term. So, while the regular payments would typically match that of a fixed-rate mortgage, the remaining balance is due as the final payment, meaning the last payment is your "balloon" payment. Balloon financing is popular for people dealing with commercial or investment real estate properties, but not usually residential properties.

How do you apply for one?

First, ask at the financial institution to see if they offer balloon financing options. If so, you can proceed with the application. If you're familiar with the loan application process, you'll find that applying for a balloon mortgage is similar - you'll need to provide the same documents and sign similar forms as in other borrowing situations.

What do I need to know when applying for a balloon agreement?

Before you sign anything, make sure you have a clear understanding of exactly when the balance is due and how much your final, balloon payment will be. You will pay part of your balance in payments over the course of your term, but once that term is up you will be required to pay the remainder in full.

Can I refinance at the end of the loan?

This is a question you should ask your lender before you agree to any terms. Typically, there is an option to refinance your final payment, provided there have been no late payments or liens against the property. Check with your lending institution to find out what conditions you must meet in order to retain your refinancing options.

Do I need to prepare for a worst-case scenario?

Before agreeing to a balloon mortgage, you need to analyze all the worst-case scenarios to make sure you can handle them. Whether it's losing your job, not being able to find a buyer on an investment property or a general downturn in the economy, will you still be able to maintain the payments (including the balloon payment) on the property? If not, you may want to consider other financing options.

I've gone over every detail and I feel confident - what now?

The next step is to file for the loan. Again, be sure you understand all the requirements and never be afraid to ask questions. Once you're ready, you can sign the application form with confidence and proceed with your financing.

It is not uncommon for enthusiastic buyers to enter a balloon agreement with undue confidence in their ability to repay the final payment at the end of the loan term. So weigh the balloon option with a sober mindset before signing a contract.

Wednesday, March 05, 2008

Let's Prepare for PHP 6

As you may be aware the core PHP group of developers all met in Paris on November the 11th and 12th 2005. The minutes from the meeting are fascinating reading, but there is a lot to go through. So I've gone through all of the points raised and chewed them over from a developers point of view. Your comments as always are welcome.



Before I get started however I'd just like to make one thing very clear: what you read here (or in the original minutes) are in no way the 'fully 100% decided' end results / changes that we'll see in PHP6. They will most likely all be discussed further (on internals and wider), but even so we can take the information presented in the minutes as being the PHP teams most 'current' way of thinking about any given subject.



Unicode



Unicode support at present can be set on a per request basis. This equates to PHP having to store both Unicode and non-Unicode variants of class, method and function names in the symbol tables. In short - it uses up more resources. Their decision is to make the Unicode setting server wide, not request wide. Turning Unicode off where not required can help performance and they quote some string functions as being up to 300% slower and whole applications 25% slower as a result. The decision to move it to the php.ini in my mind does take the control away from the user, and puts it into the hands of the Web Host.



If you compile PHP yourself or are responsible for this on your servers then you may be interested to know that PHP 6 will require the ICU libs (regardless if Unicode is turned on or off). The build system will bail out if the required ICU libs cannot be found. In a nutshell, you'll have another thing to install if you want to compile PHP.



Register Globals to go



Say goodbye folks, this one is finally going. It will no longer be an ini file setting, and if found it will raise an E_CORE_ERROR, pointing you to the documentation on why it's "bad". This means that PHP6 will finally break all PHP3 era scripts (or any script using reg globals) with no recourse at all but to re-code it. That's a bold move, but a needed one.



Magic Quotes to go



The magic quotes feature of PHP will be going, and as with register globals it's going to raise an E_CORE_ERROR if the setting is found anywhere. This will affect magic_quotes, magic_quotes_sybase and magic_quotes_gpc.



Safe Mode to go



This may please developers who have web hosts that insist upon safe mode! But it will now go totally, again raising an E_CORE_ERROR if found. The reason is that apparently they felt it gave the 'wrong signal', implying that it made PHP secure, when infact it didn't at all. open_basedir will (thankfully) be kept.



'var' to alias 'public'



PHP4 used 'var' within classes. PHP5 (in its OO move) caused this to raise a warning under E_STRICT. This warning will be removed in PHP6 and instead 'var' will mean the same thing as 'public'. This is a nice move but I if anyone has updated their scripts to work under E_STRICT in PHP5 it will be a redundant one for them.



Return by Reference will error



Both '$foo =& new StdClass()' and 'function &foo' will now raise an E_STRICT error.



zend.ze1 compatbility mode to go



ze1 always tried to retain old PHP4 behaviour, but apparently it "doesn't work 100%" anyway, so it will be removed totally and throw an E_CORE_ERROR if detected.



Freetype 1 and GD 1 support to go



Support for both of these (very very old) libs will be removed.



dl() moves to SAPI only



Each SAPI will register the use of this function as required, only the CLI and embed SAPIs will do this from now on. It will not be available elsewhere.



FastCGI always on



The FastCGI code will be cleaned up and always enabled for the CGI SAPI, it will not be able to be disabled.



Register Long Arrays to go



Remember the HTTP_*_VARS globals from yesteryear? Well if you're not already using $_GET, $_POST, etc - start doing so now, because the option to enable long arrays is going (and will throw an E_CORE_ERROR).



Extension Movements



The XMLReader and XMLWriter extensions will move into the core distribution and will be on by default.



The ereg extension will move to PECL (and thus be removed from PHP). This means that PCRE will not be allowed to be disabled. This will make way for the new regular expression extension based on ICU.



The extremely useful Fileinfo exntesion will move into the core distribution and enabled by default.



PHP Engine Additions



64 bit integers
A new 64 bit integer will be added (int64). There will be no int32 (it is assumed unless you specify int64)



Goto
No 'goto' command will be added, but the break keyword will be extended with a static label - so you could do 'break foo' and it'll jump to the label foo: in your code.



ifsetor()
It looks like we won't be seeing this one, which is a shame. But instead the ?: operator will have the 'middle parameter' requirement dropped, which means you'd be able to do something like this: "$foo = $_GET['foo'] ?: 42;" (i.e. if foo is true, $foo will equal 42). This should save some code, but I personally don't think it is as 'readable' as ifsetor would have been.



foreach multi-dim arrays
This is a nice change - you'll be able to foreach through array lists, i.e. "foreach( $a as $k => list($a, $b))".



{} vs []
You can currently use both {} and [] to access string indexes. But the {} notation will raise an E_STRICT in PHP5.1 and will be gone totally in PHP6. Also the [] version will gain substr and array_slice functionality directly - so you could do "[2,]" to access characters 2 to the end, etc. Very handy.



OO changes



Static Binding
A new keyword will be created to allow for late static binding - static::static2(), this will perform runtime evaluation of statics.



Namespaces
It looks like this one is still undecided - if they do implement namespaces it will be using their style only. My advice? Don't hold your breath!



Type-hinted Return Values
Although they decided against allowing type-hinted properties (becaue it's "not the PHP way") they will add support for type-hinted return values, but have yet to decide on a syntax for this. Even so, it will be a nice addition.



Calling dynamic functions as static will E_FATAL
At the moment you can call both static and dynamic methods, whether they are static or not. Calling a dynamic function with the static call syntax will raise an E_FATAL.



Additions to PHP



APC to be in the core distribution
The opcode cache APC will be included in the core distribution of PHP as standard, it will not however be turned on by default (but having it there saves the compilation of yet another thing on your server, and web hosts are more likely to allow it to be enabled)



Hardened PHP patch
This patch implements a bunch of extra security checks in PHP. They went over it and the following changes will now take place within PHP: Protection against HTTP Response Splitting will be included. allow_url_fopen will be split into two: allow_url_fopen and allow_url_include. allow_url_fopen will be enabled by default. allow_url_include will be disabled by default.



E_STRICT merges into E_ALL
Wow, this is quite a serious one! E_STRICT level messages will be added to E_ALL by default. This shows a marked move by the PHP team to educate developers on 'best practises' and displaying language-level warnings in a "Hey, you're doing it the wrong way".



Farewell <%
They will remove support for the ASP style tags, but the PHP short-code tag will remain (<?) - so to those on php general who reckon the short-tag is 'depreceated' - hah! ;-)



Conclusion



PHP6 is taking an interesting move in my mind - it's as if the PHP developers want to now educate developers about the right way to code something, and remove those lingering issues with "Well you SHOULD be doing it this way, but you can still do it the old way". This will not be the case any longer. Removing totally the likes of register globals, magic quotes, long arrays, {} string indexes and call-time-pass-by-references will force developers to clean up their code.



It will also break a crapload of scripts beyond repair that doesn't involve some serious re-writing. Is this a bad thing? I don't think so myself, but I see it making the adoption of PHP6 even slower than that of PHP5, which is a real shame. However they have to leap this hurdle at some point, and once they've done it progression to future versions should be swifter.

Monday, March 03, 2008

IT Critic - I work more than 40 hours per week.

IT professionals benefit from technology since it gives them a job. But it becomes their life when they must support that technology 24/7. Because of technology we can never leave work. We have lost our evenings, weekends, and vacations. Is it a vacation to be in constant contact with the office? Pagers in the restaurant, cell phones on the beach, laptops in hotels? While HR professionals advise corporations on the need to balance work and life outside of the office, their admonitions are ignored. Most corporate Web sites have a section telling how the company values their employees and encourages them to relax outside of work. But, unless these corporations allow their workers to "disconnect" when they leave work, this is only so much fluff. I challenge corporate executives: People are not meant to work 24/7. People are not computers. Allow your employees to disconnect. Insist on it.

Monday, January 28, 2008

MySQL 5.1 Supported Storage Engines

MySQL 5.1 supports the following storage engines:

* MyISAM — The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.

* InnoDB — Used for transaction processing applications, and sports a number of features including ACID transaction support and foreign keys. InnoDB is included by default in all MySQL 5.1 binary distributions. In source distributions, you can enable or disable either engine by configuring MySQL as you like.

* Memory — Stores all data in RAM for extremely fast access in environments that require quick lookups of reference and other like data. This engine was formerly known as the HEAP engine.

* Merge — Allows a MySQL DBA or developer to logically group a series of identical MyISAM tables and reference them as one object. Good for VLDB environments such as data warehousing.

* Archive — Provides the perfect solution for storing and retrieving large amounts of seldom-referenced historical, archived, or security audit information.

* Federated — Offers the ability to link separate MySQL servers to create one logical database from many physical servers. Very good for distributed or data mart environments.

* NDB — The Clustered database engine that is particularly suited for applications with high performance lookup needs that also require the highest possible degree of uptime and availability.

* CSV — The CSV storage engine stores data in text files using comma-separated values format. You can use the CSV engine to easily exchange data between other software and applications that can import and export in CSV format.

* Blackhole — The Blackhole storage engine accepts but does not store data and retrievals always return an empty set. The functionality can be used in distributed database design where data is automatically replicated, but not stored locally.

* Example — The Example storage engine is “stub” engine that does nothing. You can create tables with this engine, but no data can be stored in them or retrieved from them. The purpose of this engine is to serve as an example in the MySQL source code that illustrates how to begin writing new storage engines. As such, it is primarily of interest to developers.