Posts Tagged ‘database’

Getting the CRUD out

Friday, March 18th, 2011

The topic of one of GORGES recent internal Friday Tech Talks was “Yii CRUD: Tips and Tricks.”  I proposed this because I was curious to hear war stories from other developers about the problems and solutions they ran into when building “CRUD” – principally in the Yii framework, which has become one of our favorite tools at GORGES for creating complex web applications.

CRUD stands for Create, Read, Update and Delete (or, for some folks, Create, Retrieve, Update and Destroy). It refers to the basic operations that any data-centered application needs to make it run – creating new objects or records, viewing them, editing them, and getting rid of them. The code that performs these operations tends to get pretty repetitive after a while, so for a seasoned developer it can become the part of the application that you most want to “get out of the way” so you can focus on the more interesting bits, like complex business logic and nifty Javascript widgets. It is also often predominant in the administrative side of an application, where there is typically less budget for fancy design and interactivity than on the public side – but it still needs to work effectively. Thus, when developers refer to it as “crud”, they don’t always have the acronym in mind.

Here are some of the comments I heard from our team on how to create CRUD efficiently, in order to deliver quality, maintainable, cost-effective applications to our clients:

1. Don’t build it at all, if you can help it - For simpler web applications, or ones that are more content-oriented, a “full stack” framework like Yii or Ruby on Rails can be overkill – a platform such as Drupal can take care of most of the housekeeping operations, with coding (or configuration) only required for the more “custom” features of the application.

2. Use code generators – Yii and most other advanced web frameworks include tools for generating “skeleton” code for CRUD operations. Most developers felt that these are a good starting point, especially when first learning a framework, but after a while it becomes more efficient to write from scratch, with judicious use of copy and paste from existing similar code (but beware the Rule of Three).

3. Modularize your MVC components – Even though the Model-View-Controller idiom forces the developer to think in modular terms to some extent, it is still possible to write overly repetitive code within that idiom, and violate the DRY principle. Frameworks such as Yii provide a great foundation for building a web app, but the larger and more complex an application is, the more it makes sense to build on that foundation by using inheritance, polymorphism, and other object-oriented techniques in the CRUD (as well as in the non-CRUD components).

4. Build widgets where appropriate – This is just a specific example of modularization; Yii provides a widget API for building components that can be reused in different areas of an application. There are many standard widgets available, for components such as date pickers, but again, in some cases custom-building just the widget you need for a given application makes sense to keep everything “DRY”.

5. Use advanced languages - Just like application frameworks, many of the standard web development languages provide a great basis, but leave plenty of room for additional optimization. Two tools that our team is very excited about are HAML and SASS, which provide more efficient and elegant syntax for generating XHTML and CSS, respectively, than coding directly to each language. I won’t go into technical details here, but both tools allow the developer to create more robust solutions with fewer keystrokes.

These techniques and the fact that GORGES has structured ways of building staff efficiency, illustrate how GORGES developers are constantly looking for better ways to deliver quality web applications – avoiding CRUD!

Ted Caldwell is an Application Developer and Senior Software Architect for GORGES. Ted's work encompasses all aspects of web application development, including requirements analysis, database and software design, programming, project management, and system administration. Ted focuses on delivering practical, cost-effective technology solutions for GORGES clients, using a variety of custom and off-the-shelf software tools and frameworks.

When to Optimize Code for Performance

Monday, May 4th, 2009

Question:  When should a web developer optimize?

Answer:  When you have to improve the performance.

Of course writing bad or inefficient code is not a good way to develop code.  But spending time optimizing code before you know there is a problem can be a waste of time.  I value legible and readable code over unnecessarily-optimized code anyday.

If a web page or certain feature is too slow, then diagnosing exactly where to optimize is appropriate.  Here are some things to consider and test:

Is the bottleneck in the code or within a database call?
Perhaps the database needs to be indexed or normalized.
How many SQL calls are being performed?
Caching the database calls may solve this issue.
Is a database the best solution for storing all your information?
LDAP or memcache are two other options that may work best depending on what you are trying to do.
Are your files and images just too big?
Be sure the images are appropriately compressed, and that server-side compression for text files (HTML, CSS, JavaScript, XML) is activated.
Could any of the heavy logic code be pre-computed?
I recall one project (Straight Line Performance Solutions) where I pre-computed a big table of possible values from a complicated statistical function, and just looked up an approximate number quickly instead of spending 5-10 seconds computing the exact value.
Are you using a bloated CMS (content management system)?
If you are and the web pages are static, then a page-caching system will work wonders.
Is the server limited by bandwidth, RAM, or CPU?
Monitor server performance indicators to see if  there is too much disk thrashing.  Hardware is relatively cheap nowadays, and may be a better solution than spending days unsuccessfully tweaking code.
Does the page feel like it loads fast enough?
Perception is everything to a web user.  Some non-essential web page items could be changed to load a few seconds after the visible part of the web page is loaded and refreshed.  For example, there’s no reason to preload all images in a Javascript-based slide show.
Is there just too much traffic to your site?
Wow – what a great problem to have!  Maybe it’s time to scale your web application to multiple servers or host your application in the cloud.  There are sometimes session-management issues when using multiple web servers, but some real smart folks have figured most of this out for the major languages and popular frameworks.

There are only some ideas of what to look for – and I’m sure I missed a bunch of simple ones.  As you can see, I recommend spending time diagnosing the real problem before jumping in and optimizing code right away.

I’d rather have a correct program than a fast incorrect one.  Optimizing code when needed is better than having to debug faulty code.

worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.
©2012 GORGES - All rights reserved
where programming meets design and lives happily ever after