Recent Activity
- Home-baked SVN support for Komodo Edit
Komodo Edit (version 5.0.3 5.1.4 at the time of this writing) is my tool of choice for code editing. It is built on top of Mozilla and Scintilla with some Python glue, which gives it great flexibility (Firefox like extensions, custom lexer files etc.)
I am using Komodo Edit for web development, mainly PHP/HTML/Javascript on Ubuntu Intrepid 64bit, and I must say that I’m extremely satisfied with my setup. It is extremely fast and clutter free.
ActiveState has done a lot of work in making this great tool. They also have a commercial product that extends the editor with some pretty neat pieces of functionality (Komodo IDE). I also tried the IDE, but for my specific needs I’m sattisfied with the free version. I’m considering buying a licence for the IDE in the future.
There are a couple of notable differences between the two “dragons”, most important are the ability to handle version control systems and debuggers from within the IDE, but not from within the free edition.
Of course, there are other alternatives like Aptana, which is also a great tool (I’ve been using it for a while), but I don’t like having JRE installed if possible (less dependencies is better). I also like to be a little different, and give other products a fair chance to be used. It’s a matter of personal taste I guess. Other IDE’s offer integrated database editing tools. I use MySQL as the db layer on most of my projects, but I don’t actually need that into my code editor. I use MySQL Administrator, Query Browser and Workbench, and I’m pretty satisfied by those tools. It also allows me to concetrate on the specific part of the application (database design, database debug, code editing) without having all that functionality loaded into my editor all the time.
Now, returning to Komodo Edit, one thing that is not easy to do, is to work with a versioned local copy of a project. You have to keep a terminal window opened all the time, and fire some, let’s say,
svn commit,svn addorsvn updateevery time you modify something.Subversion is widely used as a version control system, and it is available for all kinds of unix/linux flavours, mac, windows etc. We’re going to get rid of the terminal window and customize Komodo to do simple operations like commit or update.
How are going to do that? Well, one of the greatest things that Komodo offers is the possibility to add your own pieces of functionality into it, by using macros, snippets, commands, menus, toolbars etc. We’re going to create a toolbar and a couple of buttons that trigger some subversion commands. We already have subversion installed (we were using it from the command line, remember ?), so there are no other prerequisites required for our task. The advantage is that we rely solely on the official subversion binaries available to our system, which takes the weight of keeping it updated off our backs, as opposed to let’s say when we have our own subversion library and need to keep it updated.
This guide is for Linux only. It should also work in unix/mac os x. It does not work in windows, because windows lacks some system tools like awk or grep.
First, we make the right panel visible, and rightclick on the Samples (5.0.3 5.0.3)) folder, add -> New Custom Toolbar. We name it “my svn tools” and click ok.
Then we rightclick on the newly created toolbar and add -> Custom command, then fill the fields like this:
SVN update
You’ll notice that I also changed the command’s icon (I used the arrow_up icon from the FamFamFam Silk icon set which are offered for free under a CreativeCommons license). You can do that by clicking “Change icon”. You’ll notice the %d in the “Start in” advanced option. That means that the command will be run in the active project’s folder path. Pay much attention to this specific detail when you have more than one project opened.
Now let’s add a new command for svn commit:
SVM commit properties
You will notice that this time we have something different in the Command field:
svn ci -m “%(ask:Commit message:)”
When you commit something, usually you have to write a commit message that describes the nature of the modifications you’ve made to the code (for example a fix for a specific trac ticket); that’s what the -m “message” does. For this, we are using the %(ask:dialog_title:default_value) construct that tells komodo to popup an input dialog with the title replaced with the dialog_title parameter, and the default value replaced with the default_value parameter. The default value is optional. In our case, when we fire that specific command, it will look something like this:
After using this a couple of times, you will notice that the field remembers older values that you entered, pretty much like a browser remembers what you tiped in a specific form input.
Now let’s add the svn cleanup command:
SVN cleanup
That was simple. I used the paitbrush icon.
What we need next is a command that adds newly created files into the versioning system.
I’ve used a code snippet from here. It looks like this:
for i in `svn st | grep ? | awk -F " " '{print $2}'`; do svn add $i; done
SVN add
I used the add icon from the FamFamFam icon set.
So far so good. It’s time to test our work. Go to the View menu -> Toolbars and check “my svn tools”. Your Komodo’s toolbar should look like this:
Toolbar
You will notice that our four commands appeared on the Komodo’s toolbar.
If you did everything right, you should be able to use those commands on any project that is versioned through subversion.
Very important: remember, in order for those commands to work properly, you must set the project you intend to use the tools as Active Project.
This is no a complete solution by far. I intend to dive more deeply into Komodo and it’s extensibility features, and hopefully implement a more complete solution that has let’s say all the important subversion commands.
Here is the exported toolbar package. Download and import it into your Komodo, play with it, modify it, make it look the way you like.
Happy coding !
UPDATE:
Here is how to do svn checkout:
SVN checkout
The command uses the nice little program called Zenity (which makes dialogs). The command used for checkout is:
svn co %(ask:Repository URL:) `echo | zenity --file-selection --directory --title="Checkout SVN"` --username="%(ask:SVN username:anonymous)" --password="%(askpass:SVN password)" | zenity --progress --pulsate --title="SVN Checkout" --text="Please wait for the checkout to complete" --auto-kill --auto-closeYou can download the kpz file from here, and import it into your Komodo. Enjoy !
~1 year on
Hardcoded - Static call versus Singleton call in PHP
Introduction
In the past several months I’ve been working with a rather large application built with symfony. I noticed that symfony makes heavy use of the Singleton pattern (other frameworks, like Zend do that too); everywhere in the code there were pieces like this one:
<?php // ... sfSomething::getInstance(); // ... ?>I know that in more than half of the situations, you can write your code using plain static classes, with some initialize() method, as an alternative to writing singletons. For example, this is a dummy Singleton:
<?php class DummySingleton { private function __construct(){} private function __clone(){} public static function getInstance(){ if(self::$__instance == NULL) self::$__instance = new DummySingleton; return self::$__instance; } public function foo(){ echo 'I am DummySingleton::foo()'; } } ?>Now this is a completely useless class, but it suits our purpose of illustrating the Singleton. Notice the amount of code needed by the Singleton pattern. Except the foo() method, all the code in the class makes sure you have only one instance at any time during the execution.
Now let’s write a static class that does the same thing as the Singleton:
<?php class DummyStatic { static public function foo(){ echo 'I am DummyStatic::foo()'; } } ?>This is much cleaner, as we don’t need the extra code the Singleton needs, and can focus on our task at hand.
Performance comparison
Let’s compare the performance of the two approaches. I’ve written a small test script that looks like this:
<?php /** * A singleton class */ class TestSingleton { // singleton code private static $__instance = NULL; private function __construct(){} private function __clone(){} static public function getInstance(){ if(self::$__instance == NULL) self::$__instance = new TestSingleton; return self::$__instance; } // our actual code public $val = 0; public function test(){ for($i=0;$i<30;$i++) $this->val += $i; } }/** * a plain static class (all members are static) */ class TestStatic { static public $val = 0; static public function test(){ for($i=0;$i<30;$i++) self::$val += $i; } }// how many runs $runs = 500000;// benchmarking Singleton $start = microtime(TRUE); for($i=0;$i<$runs;$i++) TestSingleton::getInstance()->test(); $run1 = microtime(TRUE) - $start;// benchmarking static $start = microtime(TRUE); for($i=0;$i<$runs;$i++) TestStatic::test(); $run2 = microtime(TRUE) - $start; echo '<pre>'; echo 'test singleton: '.number_format($run1, 8)." s\n"; echo 'test static: '.number_format($run2, 8).' s'; ?>
Basicly, I put together the two types of classes. Both have a method called test(), which does some arithmetic operations, just to have something that spends some execution time.
I’ve ran this script for various values for the $runs variable: 100, 1k 10k, 100k, 200k, 300k, 500k and 1M.
Test results
Number of runs Singleton call time (s) Static call time (s) 100 0.004005 0.001511 1,000 0.018872 0.014552 10,000 0.174744 0.141820 100,000 1.643465 1.431564 200,000 3.277334 2.812432 300,000 5.079388 4.419048 500,000 8.086555 6.841494 1,000,000 16.189018 13.696728I have also done some spreadsheet magic, and generated this chart:
As you can see, for a relatively small number of runs (<1k), the Static code is significantly faster than the Singleton, an than it stabilizes arround 15% faster than Singleton, as I expected. This is because every function/method call involves some operations (symbol lookup, stack manipulation etc.), and each call to the Singleton method, in fact, also calls the getInstance() static method.
Conclusion
It may not be that obvious that making extensive use of Singletons has this kind of side effect; however, if your code has more that 100 or 1,000 calls to some getInstance() method of a Singleton class, you might want to consider caching the reference to the object it returns, or even refactoring the code to use only static method calls.
You might say that you need an object because you do stuff in the constructor. That can be easily achieved with some kind of static initialize() method, that should be called once in your code, just before usage. If you have some auto loading mechanism in place, you could call it just after loading the class, for example, if you want to automate the initialization process. But keep in mind that this is not a 100% replacement for Singletons; you need an object if you want to serialize/unserialize it (for caching, some RPC call, etc.).
Update.
Tested with Facebook’s HPHP compiler:
I’ve tested the script using the HPHP compiler, and the results are spectacular. While keeping the same time ratio between the Singleton and Static calls, what stroke me is the huge difference (HPHP is ~ 200 times faster):
<!-- BODY,DIV,TABLE,THEAD,TBODY,TFOOT,TR,TH,TD,P { font-family:"Arial"; font-size:x-small } -->
Number of calls Time spent (Apache) Time spent (HPHP) Apache Singleton call Apache Static call HPHP Singleton call HPHP Static call 100 0.004005 0.001511 0.00001502 0.00000906 1,000 0.018872 0.014552 0.00008988 0.00007486 10,000 0.174744 0.141820 0.00075102 0.00063801 100,000 1.643465 1.431564 0.00829983 0.00795388 200,000 3.277334 2.812432 0.01839614 0.01339102 300,000 5.079388 4.419048 0.02502608 0.01932502 500,000 8.086555 6.841494 0.04114008 0.03280401 1,000,000 16.189018 13.696728 0.07872796 0.06373119Happy coding.
~1 year on
Hardcoded
