Foliovision Logo

Archive for the 'WordPress' category

New York Times Online: Ad Revenue Mismanagement = Unemployed Journalists

Tuesday, April 29th, 2008

Over the last month, the internet has been awash with stories of the fabled New York Times slow demise, as indicated by huge losses and impending layoffs. As the new Wall Street Journal hires, the New York Times fires.

The decline in New York Times revenue and readership surprised me somewhat, but I accepted the decline at face value. Given the New York Times atrocious editorial standards throughout the Bush regime, including aiming and abetting war crimes (Judith Miller), the loss in circulation seemed like just desserts.

But today, Comcast's list of the top 50 websites for March came across my desk. Based on unique visitors, guess who's at number 12 with 47 million unique visitors for the month? For refernce, that's just behind Wikipedia, Amazon and ahead of Facebook, CNET, Adobe, CBS and Craigslist: The New York Times Digital.

 

Comcast top 100 websites by unique visitors
Comcast top 50 websites by unique visitors

Which set me to thinking what kind of second rate media (advertising sales) strategy would it take to lose money with the number 12 website.

 

I don't know how reliable the Comcast numbers are so I went and ran some quick checks on Alexa.com.

While the numbers are not as good over at Alexa (the New York Times is number 25 in the United States), the reach is still fabulous. Where the New York Times falls down is in page views. They average only 3 page views per unique visitor.

Contrast those page views with Wikipedia at 5 page views per unique visitor or Google at 7 page views per unique visitor or Facebook with 25 page views per visitor.

 

nytimes vs wikipedia vs amazon vs digg vs facebook
nytimes vs wikipedia vs amazon vs digg vs facebook

Why are the page views so low for what should be a multiple page view experience (who opens a newspaper to read one article)?

 

The silly registration hoops. You can't read NYTimes.com without jumping through hoops. Either you register with them (and they kill off the registrations occasionally, requiring reregistration as I did register once but my login is dead) - or you can't view the site. They've taken to effectively blocking BugMeNot.com which used to be the best way to log in to NYtimes.com in a hurry.

NYtimes registration firewall lockout
NYtimes registration firewall lockout

 

It is possible to bypass the login with a very clever automated NYTimes registration bot which generates a totally anonymous profile in a nanosecond. You can link to stories with a special URL which can be generated with a javascript bookmark.

All of these shenanigans are time consuming and annoying. And guess the results - you arrive at NYtimes.com from a weblog on a permalink. You seem something else interesting and want to go and have a look. Paff - you're locked out. Register or forget it (correction: apparently you do get four or five peeks before you hit the registration firewall).

Once you do register, a good number of the stories still won't be accessible without paying a ludicrous fee ($5 for a newspaper article?).

So now the business model is to start letting journalist go. So less high quality (I think they got rid of Judith Miller, no? and lately they've been letting a lot of Republican cats out of a deep dark bag - so let's be optimistic) original content. Less information for the search engines, less possibility of generating original content.

I don't understand these guys. Their assets are:

  1. brand
  2. original content

What they think are is their third asset - traffic/eyeballs - is only built on the first two. So when they dump a certain amount of the original content, down goes the traffic. The only thing differentiating the NYtimes from all kinds of news and aggregators is their pressroom.

The first attack came on the quality - the brand:

Well, they didn't let Judith Miller go. And her fact-impaired cheerleading for the Iraq war has helped land us in a mess that's going to last at least another 10 years, in my opinion. And kill several thousand more US soldiers, several *hundred thousand* more Iraqi civilians, cost us trillions more dollars, and worse...

The problem the Times has isn't the quantity of reporters, it's the quality. People know they can't rely on truth from the times on important issues, because they *have not* been able to rely on,

Wave two is coming on quantity (number of reporters).

With the traffic, search engine rankings and original content they have, someone in the NYtimes media department is doing a seriously bad job of promoting and monetizing the site.

Years ago Salon.com came up with the model of subscriptions or day passes which require viewing advertising. It's still working for them (and they are looking for New York advertising reps). In the meantime, couldn't somebody clever implement this or come up with something new?

If the New York Times media department doesn't hurry up and figure out how to extract revenue from their brand and original content, the next loss will be traffic. From the loss of traffic, there will be no return.

This is not a critique of their tech department who seem to know what they are doing:

  1. high search engine rankings
  2. good internal search
  3. attractive layout
  4. open source contributions

But rather a critique of the business side of operations.

WordPress | 9 comments

SBI (Site Build It) versus Wordpress: How to Structure a Website

Monday, April 28th, 2008

For years, I've been on the Site Build It list. SBI is the creation of the rather annoyingly gushy Ken Evoy who never stops his carnival barker cries about his one-stop-site-creation tool. 

Ken Evoy Pumping Site Sell
Ken Evoy Pumping Site Sell

Evoy's been at it since the bad old days when the internet was a mess and Site Built It! did have the advantage of actually getting a website up in some form - easier than coding html from scratch for the neophyte.

Throughout SBI's history, Evoy has shrieked about his process and his proprietary tools. On the surface, a clear process and proprietary tools are a good idea. Probably worth the price of admission (or so I thought at the time). The issue with the proprietary tools (which otherwise might be a good deal) is that you can only use them a little bit. Come and play for one hour per week, see you next week. Not exactly inviting brainstorming or creativity.

In contrast, the indepdendent expensive (many of which are free) tools Evoy condemns let you use them as much as you like once you find them.

Over the years, I've learned not to expect much from Evoy's newsletters (sometimes for six months at a time, they get relegated to the read later bin). Still it's worth sometimes checking in on somebody who's multiyear obsession has been selling ecommerce sites. Another perspective.

In the last couple of years the internet has changed and it's actually quite easy to put a website up. Just buy a hosting account (a single domain account is $3 to $7 Ken, not the $10 to $15 you cite), click the one step install button and you have vanilla Wordpress (or Mambo or Joomla or whatever else catches your fancy). Or pay nothing and sign up at Wordpress.com and have a better than vanilla Wordpress install with lots of attractive themes ready and waiting for you and an active forum.

The ease of putting up a high quality website - almost all of which look better than Site Build It websites and are easier to post to - is naturally a huge threat to the SBI business. Why pay Ken Evoy $300 per year per website for hosting which should cost $50?

Evoy's latest missive starts yet another hysterical title "Why blogging is a massive mistake!" Exclamation mark is his.

Writing a weblog is not a massive mistake. Handled properly, a weblog does wonders for your website traffic and search engine standing. But taking away the hype, this time Evoy does have a worthwhile point about weblog type sites (Wordpress in particular) - i.e. they date like stale newspaper. I can confirm the tendency from my own sites.

By publishing a weblog, you are effectively creating just a daily news source.

What happens if you publish a very good article which has value as a permanent reference? It stands alone in your weblog. People come, read the single article and leave. There may be other interesting content on your weblog for them to read but the visitor can't be bothered to ferrret it out. If your writing or content is extremely compelling, perhaps some visitors will read a certain amount of your content. But then they will leave. Which quite frankly for an online journal is fine. You're not selling anything.

But for a business, this isn't so good. What you want is to create an information resource for people in your business, which will bring them back again and again. An information structure which invites them to find immediately the other relevant areas of interest.

And Evoy quite correctly points out that this is the built-in model for Site Build It:

Blog posts are created and stored in chronological order. A good blogger will produce a post that is useful today, but who will read it in three months? Even when bloggers go to the extra effort of archiving their posts by "keyword categories," the articles are dated and not rewritten into coherent definitive articles. Usefulness plummets with time.

How does a Theme-Based Content Site differ? Instead of a stack of old newspapers, each resembles a good resource book about its theme, composed of useful, original articles ("Web pages") that cover related topics in some depth. Written in each small-business owners's unique voice, and based upon that person's experience in the field, they are useful resources that visitors return to over and over.

Evoy correctly points out that a photography weblog would just be one in a million, posting the nattering about the latest cameras and software:

How would a blog be presented? A stream of disjointed photography tips would be organized by "date of post." And posts on any given topic (ex., "portrait lighting") would be separated by time (weeks or months apart), each covering only a certain aspect of the topic. On the other hand...

Definitely not the right one to pull someone into your website. Evoy contrasts the above weblog site with this siloed sitemap for a static site:

site build it silo site
site build it silo site

This time Evoy's absolutely right. Someone looking for information on photography lighting would gradually be led through the whole of your website, would bookmark it and come back as a reference. All of this assumes of course that your content is top-notch (and Ken, let's be frank, there's not too many people capable of creating top-notch content, on or off the SBI rolls). But with a static site structure at least you stand a fighting chance of retaining your visitor and becoming a reference.

In any case this is a huge insight. Pages instead of posts something I've been playing around with in the static pages section in Foliovision. Our client sites are also largely hierarchical with the weblog performing weblog functions (added value).

What I've been doing is making a static page instead of a post and then publishing a small announcement on the weblog section.

Unfortunately some of the news outlets which republish my content will not link to static pages or to articles which are more than 24 hours old (a pain in the neck, as after publishing a major article I like to come back to it 12 hours later to proof it and add or correct illustrations).

Going forward, I am going to build up the static pages sections very actively. When I first publish a post, it will go into the weblog, but within a few days. There is one small issue which is comments. We enable comments on pages so visitors will still be able to comment on the static page. But often some of the comments come in right away (on the weblog version).

  1. Do I leave the comments on the weblog post or move them to the static page?
  2. If I choose to move the comments to the static page, there is no mechanism to do so inside Wordpress. We'd have to build a plugin.

BTW, this sort of question is what you are paying Evoy to solve for you with either no solution (in this case) or his solution. For an inside the box thinker (or someone with very little design sensibility and/or minimal interest in technology), SBI solves a lot of problems. For an existing six-figure business, there are better ways to bring your business online than SBI DIYism. I do agree with Ken that business owners should have better things to do with their time than spend it troubleshooting websites or optimising their sites for Google.


If you're interested in having a closer look at the Site Build It system and way of thinking, Ken Evoy offers a number of free ebooks on writing for the web, selling services and montization. SBI's claim ithat the free ebooks are better than a lot of the pay ebooks out on internet marketing is more or less true. Given the rubbish sold as ebooks that's not necessarily saying a whole lot. The link above bundles several of them into a single zip file for your convenience.

Personally, Ken's writing style drives me up the wall (he's been described as rah-rah), but the bulk of the information is good. I just can't read past his marketing speech. The formatting is bizarre as well. I wish the guy would hire a graphic designer at some point. Why does he write Sidebar and then not make the sidebar a sidebar but whack it right into the middle of the text?

Some other references

Internet Marketing, WordPress | 2 comments

Keeping Wordpress Overhead Down: How to Catch and Disable Greedy Plugins

Sunday, February 3rd, 2008

I've been wondering about Wordpress plugin overhead for some time. How does one keep track of how much processor time and overhead any given plugin requires?

We run fairly streamlined Wordpress installs at Foliovision with about 30 active plugins per site. A lot of them are one-trick ponies developed in-house so we know the code isn't creating a huge load.

But anyone who has been working on Macintosh computers from the old days (System 7, 8 & 9) knows very well that every extensions (and some people were running 50 of them) slows down your compuer and increases the chances of a system conflict. There were whole expensive utilities devoted to keeping extensions and control panels under control. Any one else remember long hours spent with Conflict Catcher?

conflict catcher screenshot
conflict catcher screenshot

Here's what WPdesigner.com has to say on his own plugin issues:

With the WP Download Monitor plugin, the front page of my blog had to operate with 136 queries on every page load. After uninstalling that plugin, the front page needed only 10 queries to work. 136 versus 10 and all I have to do is give up tracking the downloads, hmmm.. oh what, oh what should I do? I deactivated / uninstalled it, of course.

So some plugins are clearly worse than others. I hope I didn't publish that post recommending Lucia's LinkyLove for DoFollow. In the comments to the post above David Airey notes.

I found the real culprit - the LinkLove plugin for DoFollow comments.

By de-activating it I’ve dropped the queries from 117 to 24 on my blog post with 46 comments.

Lucia's LinkyLove plays complicated games rewarding commenters for more comments with better links. A pox on this sort of brownie point system. I will get DoFollow turned on and will rely on Akismet and common sense to keep the spammers off. Everybody else is welcome to followed links.

Ironically enough David's post recommending Lucia's LinkyLove still stands and is ranked high - that is not taking very good care of one's visitors. Perhaps he just forgot. Even more ironically, Lucia publishes another plugin to track CPU greedy plugins. I don't recommend this plugin, as it is ugly and is less useful than adding a simple PHP tag to your footer to track both database queries and CPU time.

<!--<?php echo $wpdb->num_queries; ?> <?php _e('queries'); ?>. <?php timer_stop(1); ?> <?php _e('seconds'); ?>.-->

At this point you can load any page on your weblog and check the number of database queries and the CPU time just by viewing source. If you are really on a roll, you can remove the html comment markup from around the PHP tag and you will be able to see the load times and database queries without checking source. So will your visitors, but for a half an hour of quick testing it really doesn't matter.

Here's the PHP code alone:

<?php echo $wpdb->num_queries; ?> <?php _e('queries'); ?>. <?php timer_stop(1); ?> <?php _e('seconds'); ?>.

So with 30 Wordpress plugins running, what's the damage on Foliovision.com and client sites? 

wordpress database queries cpu time
wordpress database queries cpu time

On Foliovision.com, 37 queries. 0.465 seconds for the home page and 30 queries. 0.506 seconds for a single post. The client sites are mostly in the same thirtyish queries neighbourhood. Clearly in there are a couple of plugins which are borderline greedy. I'll have Peter do some tests on Monday. For comparision, with over 41 plugins, Saman's install requires over 1.6 seconds to generate a page.

Generally I am happy about this result. It means the base FolioPress suite is quite efficient. Efficiency in coding is very important to me. Alas, the big three in OS have quite forgotten about efficiency: MS Windows, Apple OS X and KDE are all horribly inefficient: I have to run a quad processor to get decent performance out of Apple. Absurd. But malicious inefficiency in coding is a subject for another post.

How important is it to avoid greedy Wordpress plugins? If you get little or no traffic or you are on a dedicated server, it's probably not all that important. But if you are on shared hosting and you ever get Dugg, Slashdotted or listed at Yahoo, watch out. Your hosting may be disabled for a week due to the one or two errant plugins.

Here's a small case study of a plugin gone bad: Comment relish issues #1, #2 & #3. This one has a happy ending as the plugin was eventually repaired and made useable.

 

WordPress | 3 comments

Wordpress plugin review: FAQ-Tastic

Wednesday, January 16th, 2008

I've just deployed a FAQ page onto one of the client websites using the Wordpress FAQ-Tastic plugin onto one of our client. I took some notes on the deployment and have written up a long FAQ-Tastic review. FAQ-Tastic  was written by John Godley for Knowledge Constructs.

FAQ Tastic dicey default layout
FAQ Tastic's default layout

Executive Summary

While not without issues, if you are thinking of using your FAQ page as a live resource you should definitely consider FAQ-Tastic. There's a lot of power under the hood. Don't miss the full FAQ-Tastic review with deployment notes.

WordPress | No comments

Photoshop CS3 Droplet: Save as GIF

Thursday, January 10th, 2008
Photoshop CS3 to GIF Droplet
Photoshop CS3 Save to GIF Droplet
(Mac OS X version)

If you use Photoshop CS3 and post screenshots to the web, this little droplet will save you a lot of trouble. For some reason it is impossible to convert ImageReady or previous Photoshop versions Droplets to Photoshop CS3.

Installation and Usage Instructions:

  1. download the zip
  2. decompress
  3. move to the folder of your choice (I have a special folder for Photoshop and Image Ready droplets)
  4. title your images for upload (spaces are okay - PS3 will convert them to hyphens)
  5. drop your images on the droplet
  6. your web ready GIF's will appear in your desktop folder

For equally unknown reasons is also extremely difficult to create a droplet which will actually open your image and resave it as you would like right in the folder where it lies.

Even my version here will save the GIF file to your desktop, rather than the folder where the original lies (my preference). Desktop isn't bad, as you can then upload the image and archive the extra desktop files every couple of days in a date named folder in a desktop archive folder.

Current advice on the Photoshop forum is to use the Image Processor or to move to Fireworks (a program I and many other Photoshop users have never opened up, let alone want to leave running constantly in the background). Image Processor is a nice piece of kit, but it's suited to bigger jobs, whole folders. What I need is something to convert my screenshots from .png to .gif or .jpeg for posting to the web. Nothing against PNG - it's a great format, but my web server will be very full very fast with the 500 KB files it generates. Moreover, much as I like images, there's no reason for anyone to have to wait that long to download screenshots.

So I need a droplet just to take the PNG and save it as GIF. This is that droplet.

BTW, you should never convert your screenshots to jpeg, except a very high quality compression algorithm. The only reason to prefer jpeg to GIF for screenshots - which are usually mainly text - is if they include photos.

References:

WordPress | 5 comments

Why Wordpress? - the Tumblr Question

Saturday, January 5th, 2008

I just read the strangest apologia for a new service: Uh, why’s the official Tumblr blog on WordPress?

Simply - all the CMSy stuff it comes with. Blogs are an awesome platform. WordPress lets our entire staff contribute to the same blog, maintain tags and slugs, save and give feedback on drafts, upload and store media, back and forward publish posts, group our archive by month, lets our audience comment, lists trackbacks, et cetera, et cetera. It’s awesome! Blogs rock! But we knew this. WordPress is the perfect way for a business like ours to communicate with our audience.

Sounds good to me. David Karp goes on to write about the advantages of Tumblr: "posting with zero obligations, little or no comment". Great for wisecracking, difficult for communicating.

Read the rest of this entry »

WordPress | 1 comment

Why Foliopress WSYIWYG will be PHP5 Only

Thursday, January 3rd, 2008

One of the beta testers for Foliopress WYSIWYG has just complained that Foliopress WYSIWYG is not compatible with PHP4. Apparently PHP5 is still only 6% of the installed PHP base across all webhosts.

That figure should be enough to strike terror into any developer. But that number will change very soon as PHP4 has hit the end of the line.

PHP4 incompatibility started off not as a deliberate decision. Generally I like wider compatibility.

But on serious consideration, I'm not worried about Foliopress WYSIWYG being PHP5 only.

Why not?

  • Our own webhost no longer supports PHP4 (they will put up with it on legacy projects, but strongly discourage it).
  • foliopress kfm posting images right click
    One click image posting from Foliopress WYSIWYG
    via updated KFM right click: this image and caption
    were posted with a single click
    One of the core components in Foliopress WYSIWYG is Kae Verens's brilliant KFM (Kae's File Manager) which we have turned into an advanced image manager (see illustration right). Kae is no longer supporting PHP4 in future development: "PHP4 is a hindrance. My own project has already announced a similar plan - we will no longer be catering to PHP4 after the present release."
  • PHP5 has been available for 3 years now and is thoroughly tested and is at version 5.2.5
  • PHP5 has a lot of improved functionality over PHP4.
  • PHP4 will start to disappear like dry brush this year. In six months there will no longer be PHP4 legacy issues as anybody keeping their online applications up to date will have moved on to PHP5 for one reason or another.
  • Foliopress WYSIWYG target user profile: our users will be running PHP5 for the most part. If not now, in two months. Anyone who cares enough to change the default text editor in their Wordpress or Drupal install is likely the kind of person to be running PHP5 and not PHP4.

Sometimes releasing new software is great. One isn't hindered by legacy issues. We are looking to the future - Foliopress WYSIWYG will be PHP5 only. In any case, Foliopress WYSIWYG is good enough that it's worth upgrading in a heartbeat to PHP5.

Other Discussion: PHP4/PHP5 Compatibility Decisions

 

WordPress | 2 comments

Trouble with DD Add Signature Plugin

Saturday, December 29th, 2007

Just when you think you've got technology under control, some small gnat comes along to bit you. I had just added and styled the nice registration form for people interested in Foliopress WYSIWYG and SEO Images to the previous post :

For immediate notification of the release of Foliopress WYSIWYG and Foliopress SEO Images, just fill in the form below and I will send you an email as soon as it is available for download.

and then I began seeing double. That is to say two me:

 

dd add sig error
dd add signature plugin error

That nice headshot with the articles is created by Alastair Dagon Design's Add Signature Plugin. What's seems to be causing the doublevision is the inclusion of a form inside a post. I tried moving the form into a Sniplet (where it should have been in the first place, quite frankly and reuseable). I've cured a few Wordpress malfunctions by pulling code outside a post and into a Sniplet - but that was pre-Foliopress WYSIWYG. Most of the Wordpress Editors damage or modify code so a Sniplet can stop them from getting a chance to break code. But this time the Sniplet trick didn't work.

I couldn't find the issue in the plugin itself:

wp-content/plugins/dd-add-sig.php

Nor does the issue seem to be in our template index.php file, although there seems to be room for such an issue there.

Read the rest of this entry »

WordPress | 1 comment

Site Renovation Day

Friday, December 28th, 2007

Spent most of the day working on Foliopress WYSIWYG together with Peter Baran.

Our solution for the Wordpress WYSIWYG and image handling nightmare is coming along quite brilliantly well. This is what the basic toolbar looks like.

Foliopress WYSIWYG toolbar preview
Foliopress WYSIWYG toolbar preview

Foliopress WYSIWYG offers true What You See is What You Get Editing for Wordpress.

  • It is backwards compatible with legacy code (hello Xstandard/TinyMCE)
  • It doesn't break complex forms (hello TinyMCE/Xstandard)
  • It doesn't discard whole posts (hello Xstandard)
  • It doesn't go haywire and create more and more nested P tags (hello WYSIWYG Pro)
  • It doesn't look like hell in the Wordpress interface (hello normal FCK)
  • It doesn't make uploading images a never ending and hopeless struggle (hello Wordpress uploader)
  • It doesn't make your clients hopping mad and lead them to breaking everything (Plaintext/RAW html)
  • Your drafts look like exactly like your posts will, without having to waste time with a preview function (hello Xstandard)
  • You have unlimited standard undo from the keyboard (hello Xstandard)
  • Very easy to configure (including site WYSIWYG) (hello Xstandard, TinyMCE, FCK)

In short, Foliopress WYSIWYG is what you always wished the Wordpress Editor would do. I'm using it now and can't believe no one created and editor like this earlier.

Read the rest of this entry »

WordPress | 3 comments

Price of Antitrust: $4 billion and climbing

Tuesday, December 25th, 2007

Does software crime pay?

On paper, it looks like it does. And very well.

Over at roughlydrafted.com, Daniel Eran Dilger gives a short history of how Microsoft, embraced, extended and extinguished through the eighties and nineties. In the end it turns, out Microsoft has paid more than $4.2 billion in antitrust and patent infringements, not counting the impending EU (European Union) settlement.

Read the rest of this entry »

WordPress | No comments

One Click Editing for WordPress

Wednesday, December 12th, 2007

I've just added a new page to the How to Hack a WordPress Theme for Non-Programmers section.

front end editing wordpress
front end editing for wordpress

The article covers how to get those cool edit buttons on to both pages and posts by changing just a single php file in your template:

Front Editing for WordPress.

WordPress | No comments

Xray Eyes for CSS

Sunday, December 9th, 2007

Just discovered an amazing bookmarklet from Aussie company Western Civilization, one of the original creators of CSS editing software. StyleMaster was always a little bit buggy processor intensive, expensive and complicated for me so I learned how to code CSS from scratch. I still think that's the best way to write CSS.

But the modern web is getting so complicated that we really need a better way to look at web pages to be able to figure out how they are put together.

Well WestCiv has really hit the ball out of the park with this one. They have a cross browser compatible javascript bookmarklet that will let you click and see all the CSS and structure for any element on a page. The bookmarklet, appropriately enough, is called Xray.

Read the rest of this entry »

WordPress | 2 comments

How to Comment Code in WordPress Templates

Sunday, December 9th, 2007

I've spent a lot of the weekend working on a Vancouver real estate website which we converted to WordPress last year.

(Don't feel too sorry for me, the rest of the weekend I spent with my girlfriend.)

There were a bunch of issues in the PHP code which I couldn't solve myself so I had to leave my efforts there for the designer.

I was unable to comment it out with html comments (what I usually do). PHP comments wouldn't work either, so I put some serious research into how to comment PHP properly.

It turns out there is a simple but very effective trick:

<?php /*
comment
*/ ?>

I recommend reading the full article on How to Comment Code in WordPress templates if commenting WordPress templates is something you need it do occasionally. It will save you a lot of time.

I am sure much of this applies to our friends over in Mambo/Joomla and Drupal land.

A tip of the hat to My Digital Life for his article - Comments and Comment Blocks in PHP.

WordPress | No comments

Coding Languages, a developer’s new girlfriend

Thursday, November 29th, 2007

Why all this fascination with Ruby on Rails?

The success of 37signals...these guys have built some cool stuff in very small teams.

But in general I believe that a lot of the coding developers (as opposed to user interface developers such as myself) like trying new languages like some men like trying fresh girlfriends.

Each time a new language comes along they think this might be the one.

For those of us just trying to produce working applications efficiently for clients, switching languages is a waste of time and money.

i.e. we will switch but only if the incentives are enormous or our current technology has badly dated.

Many developers are choosing to remain in PHP. CakePHP is PHP's answer to the Rails framework on Ruby.

Dominican developer Kevin Lloyd has written a succinct list of the reasons to choose CakePHP over RoR:

  1. laziness
  2. speed
  3. shared host support
  4. cost

The big debate about Ruby on Rails versus PHP was set off by Alex Payne of Twitter's complaint about the speed of RoR in an interview:

All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise....there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow. It’s great that people are hard at work on faster implementations of the language, but right now, it’s tough. If you’re looking to deploy a big web application and you’re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.

Kevin adds:

I don’t do Web Development for my health or for fun. I design web applications for clients. A lot of my work involves redesign of already existing sites. How do I say to a client: Hey, although your current web host that you’ve prepaid a year for is sufficient for 90% or the stuff you can throw at it, I’m using this new technology and you need to shell out some more $$$ for a host that can handle it.

That's our situation as well. We love web development but it is a means to an end. User interface, front end, user convenience. Of course reliability and security are very important to us as well, but that is more a question of coding practice than coding language.

Read the rest of this entry »

WordPress | 3 comments

PHP Speed and Security: The Code Optimization Phase

Wednesday, November 7th, 2007

We've been having quite a few issues with speed and server load, something which we'd never had to worry about in the past. We've been building more and more web apps and fewer and fewer simple websites.

We are also facing mod security restrictions on our webhost (the quite brilliant Cartika). Cartika is strapped down pretty tightly, but that makes sense. They also let us know right away if a website of ours is facing security attacks or if it is being scraped every day.

Apparently not all PHP is created equal and it is time to batten down the hatches.

Once we get to functionality we will have to put a full-fledged optimisation phase in the development cycle: the Code Optimization Phase.

In that phase we will specifically target PHP speed and security (as functionality will already be completely in place).

I will start by asking all Foliovision developers to read the article 40 Tips for optimizing your php Code. The top twenty or so are below.

Read the rest of this entry »

WordPress | 5 comments

You are currently browsing the Foliovision archives for the 'WordPress' category.

Recent Posts

Recent Comments:

Template = sidebar.php