Feed aggregator

Devart Team is proud to introduce the new versions of dbExpress drivers with support for the latest version of Embarcadero’s RAD Studio - RAD Studio XE4. This considerable upgrade gives users an opportunity to develop their applications using the cutting-edge IDE for all the supported target-platforms: Win32, Win64 and Mac OS.

Devart dbExpress is a database-independent layer that defines common interface to provide fast access to SQL database servers from Delphi and C++Builder on Windows and Mac OS X for both 32-bit and 64-bit platforms. For each supported server, dbExpress provides a driver as an independent library that implements the common dbExpress interfaces for processing queries and stored procedures. As data-access layer is thin and simple, dbExpress provides high-performance database connectivity and is easy to deploy. Users can use drivers in the same way as the ones supplied by Embarcadero.

The new versions of dbExpress drivers provide the following improvement:

• Support for RAD Studio XE4 is implemented
  

Pricing and Availability

Price of a single license for a dbExpress driver starts at just $99.95.

Users can try out the new versions of the PostgreSQL driver here:

dbExpress driver for PostgreSQL 3.2 [ Download ]

About Devart

Devart is a recognized vendor of database connectivity solutions for Microsoft .NET and Embarcadero Delphi development platforms as well as database management software. Company's solutions support such databases as Oracle, Microsoft SQL Server, MySQL, InterBase, Firebird, PostgreSQL, and SQLite. Along with database oriented software Devart offers productivity tools for Visual Studio developers and security components for Delphi.

For additional information about Devart, visit http://www.devart.com/.

Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter.

Let’s look at the impracticality first. Writing tests requires skill and effort. Everybody on your team is probably not a testing expert. Not only may it be difficult to get started with testing, but you will generate a great amount of code with its load of maintenance. Tests are not immune to their own errors either. I have uncovered a number of incorrect test cases in every project, including PHP itself.

A full coverage can give a fake sense of security, because you won’t second guess your tests and there will be too many to effectively audit them. That doesn’t mean that more tests is bad. It means that you must strike a good balance between the number of tests and the assurance that you are seeking. Look at it as a car insurance that costs more per year than the price on your car. You want to feel safe with the right insurance, but at some point, it’s more trouble than it’s worth. You can easily end up with more test code than software code, so watch out.

My second point is that different software justifies different tests. Software that is meant to be used by other software — such as a programming language, a framework or an API — would require more in-depth testing. I would recommend writing a few tests per function, to make sure that they return expected values. Testing all paths may still not be necessary, because some paths may prove redundant. Let’s take a date parsing function as an example. If you can parse “2013-05-22 13:00″ and “May 22, 2013 1:00pm” correctly, then perhaps testing the permutation “2013-05-22 1:00pm” may be unnecessary. Be smart about your tests: choose quality over quantity.

For consumer software, you may not need to test everything. I recommend to skip obvious tests. For example, it is obvious that when you first instanciate this class, getTotal() will return zero.

class ShoppingCart {
  protected $total = 0;

  function getTotal() {
    return $this->total;
  }
}

Writing overly obvious test cases is like underlining text that is already highlighted. I usually start testing areas that can have impact the business, such as losing data or selling 0.01 quantity of a product.

In the end, there are no exact rules on how much to test. The most important thing to keep in mind is that writing tests for the sake writing tests is futile and costly. Not only that, but your colleagues won’t bother reading or maintaining tests if they are only there for their own sake and provide too little value. Focus on building great software. Tests are a tool to make it better. Just don’t overdo it.

Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter.

Let’s look at the impracticality first. Writing tests requires skill and effort. Everybody on your team is probably not a testing expert. Not only may it be difficult to get started with testing, but you will generate a great amount of code with its load of maintenance. Tests are not immune to their own errors either. I have uncovered a number of incorrect test cases in every project, including PHP itself.

A full coverage can give a fake sense of security, because you won’t second guess your tests and there will be too many to effectively audit them. That doesn’t mean that more tests is bad. It means that you must strike a good balance between the number of tests and the assurance that you are seeking. Look at it as a car insurance that costs more per year than the price on your car. You want to feel safe with the right insurance, but at some point, it’s more trouble than it’s worth. You can easily end up with more test code than software code, so watch out.

My second point is that different software justifies different tests. Software that is meant to be used by other software — such as a programming language, a framework or an API — would require more in-depth testing. I would recommend writing a few tests per function, to make sure that they return expected values. Testing all paths may still not be necessary, because some paths may prove redundant. Let’s take a date parsing function as an example. If you can parse “2013-05-22 13:00″ and “May 22, 2013 1:00pm” correctly, then perhaps testing the permutation “2013-05-22 1:00pm” may be unnecessary. Be smart about your tests: choose quality over quantity.

For consumer software, you may not need to test everything. I recommend to skip obvious tests. For example, it is obvious that when you first instanciate this class, getTotal() will return zero.

class ShoppingCart {
  protected $total = 0;

  function getTotal() {
    return $this->total;
  }
}

Writing overly obvious test cases is like underlining text that is already highlighted. I usually start testing areas that can have impact the business, such as losing data or selling 0.01 quantity of a product.

In the end, there are no exact rules on how much to test. The most important thing to keep in mind is that writing tests for the sake writing tests is futile and costly. Not only that, but your colleagues won’t bother reading or maintaining tests if they are only there for their own sake and provide too little value. Focus on building great software. Tests are a tool to make it better. Just don’t overdo it.

Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter.

Let’s look at the impracticality first. Writing tests requires skill and effort. Everybody on your team is probably not a testing expert. Not only may it be difficult to get started with testing, but you will generate a great amount of code with its load of maintenance. Tests are not immune to their own errors either. I have uncovered a number of incorrect test cases in every project, including PHP itself.

A full coverage can give a fake sense of security, because you won’t second guess your tests and there will be too many to effectively audit them. That doesn’t mean that more tests is bad. It means that you must strike a good balance between the number of tests and the assurance that you are seeking. Look at it as a car insurance that costs more per year than the price on your car. You want to feel safe with the right insurance, but at some point, it’s more trouble than it’s worth. You can easily end up with more test code than software code, so watch out.

My second point is that different software justifies different tests. Software that is meant to be used by other software — such as a programming language, a framework or an API — would require more in-depth testing. I would recommend writing a few tests per function, to make sure that they return expected values. Testing all paths may still not be necessary, because some paths may prove redundant. Let’s take a date parsing function as an example. If you can parse “2013-05-22 13:00″ and “May 22, 2013 1:00pm” correctly, then perhaps testing the permutation “2013-05-22 1:00pm” may be unnecessary. Be smart about your tests: choose quality over quantity.

For consumer software, you may not need to test everything. I recommend to skip obvious tests. For example, it is obvious that when you first instanciate this class, getTotal() will return zero.

class ShoppingCart {
  protected $total = 0;

  function getTotal() {
    return $this->total;
  }
}

Writing overly obvious test cases is like underlining text that is already highlighted. I usually start testing areas that can have impact the business, such as losing data or selling 0.01 quantity of a product.

In the end, there are no exact rules on how much to test. The most important thing to keep in mind is that writing tests for the sake writing tests is futile and costly. Not only that, but your colleagues won’t bother reading or maintaining tests if they are only there for their own sake and provide too little value. Focus on building great software. Tests are a tool to make it better. Just don’t overdo it.

I really like the generators feature that's arriving in PHP 5.5, and since we're now into release candidate releases, it's actually not that far away. I've been speaking on this topic and I thought I'd share my trivially simple code example from my slides.

The generators use the yield keyword to feed values out as they are iterated over. In code, they really look a lot like a function (or method):

<?php
function getValues() {
    // totally trivial example
    yield "Apple";
    yield "Ball";
    yield "Cat";
}

The main difference is that this "function" will retain its state and yield the next value when it is used again.

It's not obvious from the calling code that a generator is in use - and that's a feature IMO. Here's an example that uses the generator declared above:

<?php
$stuff = getValues();

foreach($stuff as $thing) {
    echo $thing . "\n";
}

Each time the foreach tries to fetch the next item from $stuff, the getValues() generator gets called, and runs until a yield statement causes a value to be emitted.

There's nothing in these examples that makes a generator a better choice than, say, returning an array, so why are generators even useful? For the most part, they will be great for either formulaic or very large datasets. If you wanted to perform some task on all prime numbers up to ten digits long, you could certainly generate a list and iterate over it. However, that list could be quite large, and the generator could calculate and supply the next value on an as-needed basis.

The other use is for data sets which are large in comparison to the size of the memory available to PHP. A generator could fetch data in a loop, or read incrementally from a stream, and only have that one piece of data hanging around in PHP's memory at any one time.

Generators are just one more in a long string of understated features coming in to the newer versions of PHP, but it's one that will make your data-heavy applications run light and quick - I can't thank the PHP core team enough for bringing us this feature!

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane

I really like the generators feature that's arriving in PHP 5.5, and since we're now into release candidate releases, it's actually not that far away. I've been speaking on this topic and I thought I'd share my trivially simple code example from my slides.

The generators use the yield keyword to feed values out as they are iterated over. In code, they really look a lot like a function (or method):

<?php
function getValues() {
    // totally trivial example
    yield "Apple";
    yield "Ball";
    yield "Cat";
}

The main difference is that this "function" will retain its state and yield the next value when it is used again.

It's not obvious from the calling code that a generator is in use - and that's a feature IMO. Here's an example that uses the generator declared above:

<?php
$stuff = getValues();

foreach($stuff as $thing) {
    echo $thing . "\n";
}

Each time the foreach tries to fetch the next item from $stuff, the getValues() generator gets called, and runs until a yield statement causes a value to be emitted.

There's nothing in these examples that makes a generator a better choice than, say, returning an array, so why are generators even useful? For the most part, they will be great for either formulaic or very large datasets. If you wanted to perform some task on all prime numbers up to ten digits long, you could certainly generate a list and iterate over it. However, that list could be quite large, and the generator could calculate and supply the next value on an as-needed basis.

The other use is for data sets which are large in comparison to the size of the memory available to PHP. A generator could fetch data in a loop, or read incrementally from a stream, and only have that one piece of data hanging around in PHP's memory at any one time.

Generators are just one more in a long string of understated features coming in to the newer versions of PHP, but it's one that will make your data-heavy applications run light and quick - I can't thank the PHP core team enough for bringing us this feature!

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane

I really like the generators feature that's arriving in PHP 5.5, and since we're now into release candidate releases, it's actually not that far away. I've been speaking on this topic and I thought I'd share my trivially simple code example from my slides.

The generators use the yield keyword to feed values out as they are iterated over. In code, they really look a lot like a function (or method):

<?php
function getValues() {
    // totally trivial example
    yield "Apple";
    yield "Ball";
    yield "Cat";
}

The main difference is that this "function" will retain its state and yield the next value when it is used again.

It's not obvious from the calling code that a generator is in use - and that's a feature IMO. Here's an example that uses the generator declared above:

<?php
$stuff = getValues();

foreach($stuff as $thing) {
    echo $thing . "\n";
}

Each time the foreach tries to fetch the next item from $stuff, the getValues() generator gets called, and runs until a yield statement causes a value to be emitted.

There's nothing in these examples that makes a generator a better choice than, say, returning an array, so why are generators even useful? For the most part, they will be great for either formulaic or very large datasets. If you wanted to perform some task on all prime numbers up to ten digits long, you could certainly generate a list and iterate over it. However, that list could be quite large, and the generator could calculate and supply the next value on an as-needed basis.

The other use is for data sets which are large in comparison to the size of the memory available to PHP. A generator could fetch data in a loop, or read incrementally from a stream, and only have that one piece of data hanging around in PHP's memory at any one time.

Generators are just one more in a long string of understated features coming in to the newer versions of PHP, but it's one that will make your data-heavy applications run light and quick - I can't thank the PHP core team enough for bringing us this feature!

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane

Over on Reddit.com recently a discussion was kicked off asking people what framework they used for REST - their tool of choice for making API creation simple.

Several different options were mentioned in the comments including:

• Flight
• Silex
• Symfony2
• phalcon
• Laravel
• CakePHP

Do you have a favorite you use for your REST APIs? share it here!

Over on Reddit.com recently a discussion was kicked off asking people what framework they used for REST - their tool of choice for making API creation simple.

Several different options were mentioned in the comments including:

• Flight
• Silex
• Symfony2
• phalcon
• Laravel
• CakePHP

Do you have a favorite you use for your REST APIs? share it here!

Over on Reddit.com recently a discussion was kicked off asking people what framework they used for REST - their tool of choice for making API creation simple.

Several different options were mentioned in the comments including:

• Flight
• Silex
• Symfony2
• phalcon
• Laravel
• CakePHP

Do you have a favorite you use for your REST APIs? share it here!

PHPMaster.com has posted the second part of their look at the Openbiz Cubi framework (part one here), this time focusing on the code - mostly XML - that you'll need to create your own custom module.

They include the SQL you'll need to run to create a new table for the "Customer" module they're going to help you build. With that in place, they walk you through the command to execute to make the module skeleton, the locations of the XML files to work with and the contents of each. Included in the module are things like a data object, a module description file and the form object. He finishes up the post with a look at the overall flow of the Cubi execution so you know where each piece falls.

PHPMaster.com has posted the second part of their look at the Openbiz Cubi framework (part one here), this time focusing on the code - mostly XML - that you'll need to create your own custom module.

They include the SQL you'll need to run to create a new table for the "Customer" module they're going to help you build. With that in place, they walk you through the command to execute to make the module skeleton, the locations of the XML files to work with and the contents of each. Included in the module are things like a data object, a module description file and the form object. He finishes up the post with a look at the overall flow of the Cubi execution so you know where each piece falls.

PHPMaster.com has posted the second part of their look at the Openbiz Cubi framework (part one here), this time focusing on the code - mostly XML - that you'll need to create your own custom module.

They include the SQL you'll need to run to create a new table for the "Customer" module they're going to help you build. With that in place, they walk you through the command to execute to make the module skeleton, the locations of the XML files to work with and the contents of each. Included in the module are things like a data object, a module description file and the form object. He finishes up the post with a look at the overall flow of the Cubi execution so you know where each piece falls.

In this new post to the PHPClasses.org blog Manuel Lemos talks some about the recent introduction of PHP into Google's App Engine offerings.

He looks at the App Engine PHP offering and looks at whether or not its a good platform to use for hosting your application. He points out some advantages and disadvantages (including no local file system access and no remote resource access). He also includes five reasons why the "web platform war is over" and why PHP has come out victorious:

• Google Knows Because They Crawl the Whole Web
• Google Does Not Influence Web Developers so much
• Wordpress is the Dominant Blog Platform (not Blogger)
• Programming Does Not Have to Be Beautiful
• PHP Detractors Have the Wrong Focus

He admits, though, that PHP may not be dominant forever - it's not perfect, but there will always be a need for something that does what it can do (and does it well).

In this new post to the PHPClasses.org blog Manuel Lemos talks some about the recent introduction of PHP into Google's App Engine offerings.

He looks at the App Engine PHP offering and looks at whether or not its a good platform to use for hosting your application. He points out some advantages and disadvantages (including no local file system access and no remote resource access). He also includes five reasons why the "web platform war is over" and why PHP has come out victorious:

• Google Knows Because They Crawl the Whole Web
• Google Does Not Influence Web Developers so much
• Wordpress is the Dominant Blog Platform (not Blogger)
• Programming Does Not Have to Be Beautiful
• PHP Detractors Have the Wrong Focus

He admits, though, that PHP may not be dominant forever - it's not perfect, but there will always be a need for something that does what it can do (and does it well).