Linux is an awesome development platform for building collaborative environments. It’s easy to get started building productive applications with JBoss, Ruby on Rails, and PHP, just to name a few. Linux gives developers enormous power by making it easy for them to build on the work of others. Linux serves as a stable platform for web servers, databases, and scripting languages. Probably the most famous development platform is the LAMP stack (Linux, Apache, MySQL and PHP/Python/Perl). An alternative is the LAPP stack, which substitutes the open source PostgreSQL database for MySQL.
Just as Ruby on Rails accelerated Ruby development, a new system called Lumenation turbocharges LAMP/LAPP development and makes it easy to create complex AJAX applications in PHP.
Lumenation turns on LAMP and LAPP capabilities such as secure Software as a Service (SaaS) application modules at the flick of a few software switches in PHP. Or, with the push of a few software buttons you can create a graphical desktop in a browser with drag and drop icons.
Lumenation makes creating secure graphical web-based applications so easy that developers will soon forget that they ever had problems building high performance AJAX applications.
Many people that modify scripts don’t consider themselves developers. Lumenation brings the full power of AJAX, PHP, and Linux to these so-called non-technical people that don’t want to get bogged down in development. For developers, Lumenation brings instant role-based security and an instant GUI and menu system immediately accessible from PHP.
The Lumenation Environment is inherently a user role-based environment which allows for excellent control of menus, applications, content, user interfaces (virtual desktops), and data. No other environment provides this much control in so little time. SaaS options can be easily added and managed at a hosted location or onsite. This includes support for single enterprise (an organization with many locations) or multiple enterprise hosting with management on a single server.
A standardized GUI framework is included for all applications and allows each SaaS user to customize the GUI to their individual preferences. Lumenation provides “managed virtual AJAX desktops” -- known as Lumenation’s z-Windows engine -- which can feature Lumenation Interactive Components (IC’s). For example, a quick creation of a dialogue window is provided, but it adheres to the framework controls inherently. It’s a joy to program in this kind of environment.
Lumenation Environment points:
• Access to your current databases for read only or update through Lumenation simultaneously;
• Inherent record locking regardless of the database utilized;
• Extensive User Journaling for portal access, applications, and records accessed;
• Based on the Linux, Apache, PostgreSQL, PHP (LAPP) or LAMP stack
Further, the Lumenation SDK is extensive. It includes pull down driven Application Builder, robust DB Manager, Code Editor, and much more.
The Lumenation Environment by itself provides an excellent portal / intranet solution as well. It is a complete “out-of-the-box” solution for virtually any organization that needs to incorporate a user/user application managed, multi-tasking, browser-based access system for all their applications.
So, imagine this. As a developer starting a new project, most of the tedious programming chores are taken care of automatically. At the same time, you are provided with an extremely rich, user-customizable environment with requires extremely minimal effort on your part.
Check it out. It’s free for download here.
Thursday, June 28, 2007
Wednesday, June 13, 2007
Response to PostgreSQL post
It’s always nice to know people are reading my blog and blogging about it themselves, even if they are disagreeing with what I’ve written. This is an excerpt from Jay Pipes’ blog, he is the Community Relations Manager, North America for MySQL. Naturally, he took issue with my previous post (see comments on last post), but it seems he does agree that different database systems are better suited for some projects than others.
"No piece of software fits every use case. Ask a guy who is 6 foot 6 inches tall whether 'one size fits all' really does. It doesn't. And, likewise, database management systems will never fit all needs. And I don't think they ever should."
Earlier that day, Matt Asay, wrote this in his InfoWorld blog.
“I was just reading a blog post by Lumen Software that declares that "PostgreSQL More Functional for Commercial Open Source SaaS." Highly intriguing, especially given all the traction that MySQL has been getting in this very same market (like its recent win with Bookings.com. Granted, Lumen's post suggests PostreSQL is a better choice for small- to medium-sized businesses utilizing open source SaaS software (and MySQL is perhaps more focused on the Googles of the world?).”
"No piece of software fits every use case. Ask a guy who is 6 foot 6 inches tall whether 'one size fits all' really does. It doesn't. And, likewise, database management systems will never fit all needs. And I don't think they ever should."
Earlier that day, Matt Asay, wrote this in his InfoWorld blog.
“I was just reading a blog post by Lumen Software that declares that "PostgreSQL More Functional for Commercial Open Source SaaS." Highly intriguing, especially given all the traction that MySQL has been getting in this very same market (like its recent win with Bookings.com. Granted, Lumen's post suggests PostreSQL is a better choice for small- to medium-sized businesses utilizing open source SaaS software (and MySQL is perhaps more focused on the Googles of the world?).”
Tuesday, June 5, 2007
PostgreSQL More Functional for Commercial Open Source SaaS
At Lumen Software we selected PostgreSQL as the embedded database for our Lumenation environment and applications four years ago. This means we run on a LAPP stack rather than a LAMP stack. This decision has proven to be the right choice as other options such as MySQL even today do not match PostgreSQL’s capabilities. MySQL has made great strides in functionality in recent years and is NOT a bad solution by any means. However, currently, it still lacks some of the more advanced features we need within the Lumenation environment. PostgreSQL provided the database functionality and performance we were used to from commercial solutions. The limitations in MySQL made it actually a very easy decision to choose PostgreSQL.
Here is a very short list of the missing features in MySQL when we made our decision four years ago:
• No Sub-queries
• No Views
• No Triggers
• No Procedures and Functions (except if developed in C++)
• Record Locking for whole table but not for record only
We have re-evaluated MySQL several times over the years. We attended the MySQL conference last year and heard about many changes MySQL was going make during the coming year, so we just recently assembled the team for another review (early 2007). In summary, we’re sticking with PostgreSQL. Below are the findings of this current evaluation.
• Record locking in MySQL can only be set for the whole table. PostgreSQL however is able to record lock at the record level. This is a crucial factor in commercial, heavy traffic transaction based applications. For example, if a user accesses a record for update, in MySQL all other users will wait until that user has updated their information.
• PostgreSQL has Schemas, Triggers and Checks and MySQL does not. These allow us to create logic at the database level which guarantees data integrity.
• PostgreSQL permits the creation of User Types such INT, REAL, etc., as arrays, arrays of arrays, etc. It also uses it as the Type for a Database Field. Developers are able to store and work in these database objects without conversion to regular data types. This allows developers to work with objects on an application level, read and write directly to the database. This provides better performance and data integrity.
• MySQL provides no Inheritance of tables. This allows us to use an Object Oriented Method while developing a Database Structure. This is used when creating and maintenance databases structures.
• There are no sequences in MySQL, only auto_increment. PostgreSQL supports sequences, and this is a very useful tool if you need to store «Master-Detail» joined data. This is also useful if you need to obtain a unique sequence of numbers and guarantee they are unique.
In general our team felt PostgreSQL was more stable and a better solution for complex applications. MySQL is better suited for less complex web applications. Cost was also a factor. MySQL is not free when used commercially. PostgreSQL is under the BSD license, so it may be distributed freely. Because of this we were also able to create a very easy to use installation process for our clients. And, after all, that’s what it’s all about. Providing the best tools for our customers.
Here is a very short list of the missing features in MySQL when we made our decision four years ago:
• No Sub-queries
• No Views
• No Triggers
• No Procedures and Functions (except if developed in C++)
• Record Locking for whole table but not for record only
We have re-evaluated MySQL several times over the years. We attended the MySQL conference last year and heard about many changes MySQL was going make during the coming year, so we just recently assembled the team for another review (early 2007). In summary, we’re sticking with PostgreSQL. Below are the findings of this current evaluation.
• Record locking in MySQL can only be set for the whole table. PostgreSQL however is able to record lock at the record level. This is a crucial factor in commercial, heavy traffic transaction based applications. For example, if a user accesses a record for update, in MySQL all other users will wait until that user has updated their information.
• PostgreSQL has Schemas, Triggers and Checks and MySQL does not. These allow us to create logic at the database level which guarantees data integrity.
• PostgreSQL permits the creation of User Types such INT, REAL, etc., as arrays, arrays of arrays, etc. It also uses it as the Type for a Database Field. Developers are able to store and work in these database objects without conversion to regular data types. This allows developers to work with objects on an application level, read and write directly to the database. This provides better performance and data integrity.
• MySQL provides no Inheritance of tables. This allows us to use an Object Oriented Method while developing a Database Structure. This is used when creating and maintenance databases structures.
• There are no sequences in MySQL, only auto_increment. PostgreSQL supports sequences, and this is a very useful tool if you need to store «Master-Detail» joined data. This is also useful if you need to obtain a unique sequence of numbers and guarantee they are unique.
In general our team felt PostgreSQL was more stable and a better solution for complex applications. MySQL is better suited for less complex web applications. Cost was also a factor. MySQL is not free when used commercially. PostgreSQL is under the BSD license, so it may be distributed freely. Because of this we were also able to create a very easy to use installation process for our clients. And, after all, that’s what it’s all about. Providing the best tools for our customers.
Subscribe to:
Posts (Atom)