PNGCrusher is a handy utility for those of us who often struggle to keep images lean and mean. I have witnessed first hand a png image of size 2.7 KB getting compressed to 151 bytes! (~95%) by PNGCrusher. Excited? Here's how you can get it and use it:-
To get it, click http://downloads.sourceforge.net/project/pmt/pngcrush-executables/1.7.9/pngcrush-1.7.9-win32.zip
PNGCrusher is a command line executable. So, if you'd like to use it from explorer's context menu, follow these steps:-
1) Extract pngcrush-1.7.9-win32.zip
2) Copy pngcrush.exe to windows\system32 folder or to a folder that is in the system path
3) Open Control Panel and choose Folder Options. Select the File Types tab, and scroll down to the ‘PNG’ entry. Click on ‘Advanced’, then click on ‘New…’.
4) In ‘Action’, type Crush, and in ‘Application used to perform action’, type the following:
pngcrush.exe -e _crushed.png "%1"
That's it. Have fun.
Thursday, October 28, 2010
Wednesday, October 20, 2010
A must read for every web developer
This post is a collection of useful links that I frequently use. Hope you find them useful too. Feel free to post you favorite links and I'll add them to this post.
Tips
1. Best Practices for Speeding Up Your Website
2. URL Rewriting
3. Compressing PNG Files
4. How to create ICO Files in Photoshop?
5. Create valid SSL certificate recognized by most browsers @ www.startssl.com
Frameworks
1. My very own Wingsource Project
Currently under development. Check SVN repository to find all the exciting stuff, Samik and I are working on
2. Enabling security in a web application using SpringSecurity
The article is slightly outdated (it's written for SpringSecurity 2.0.4; the latest one is v3.0.4) but, still useful to get started with SpringSecurity.
3. Jquery - My favorite Javascript Framework
Tips
1. Best Practices for Speeding Up Your Website
2. URL Rewriting
3. Compressing PNG Files
4. How to create ICO Files in Photoshop?
5. Create valid SSL certificate recognized by most browsers @ www.startssl.com
Frameworks
1. My very own Wingsource Project
Currently under development. Check SVN repository to find all the exciting stuff, Samik and I are working on
2. Enabling security in a web application using SpringSecurity
The article is slightly outdated (it's written for SpringSecurity 2.0.4; the latest one is v3.0.4) but, still useful to get started with SpringSecurity.
3. Jquery - My favorite Javascript Framework
Tuesday, March 23, 2010
Friday, June 12, 2009
iGoogle like interface using Apache Shindig + JQuery
Shindig is a very useful Apache project currently in incubation. It provides a gadget server, social data server and javascript gadgets.* and opensocial.* APIs.
My team at Wipro has been working on Apache Shindig since July 2008 and, we have successfully put together a framework that allows rapid development of Social Enterprise applications. This framework is called WiproWeb2Works and, provides among other things, a fully functional igoogle-like container for gadgets. We have in fact put a reference implementation of WiproWeb2Works framework - Festa on the Web for any one to get a feel of a "portal" application based on Apache Shindig. I'd encourage you to register (free!) and try it out today.
In my honest opinion, Shindig is the best way to jumpstart development of a Web 2.0 content mashup/social application. While this is great news for those of us that want to quickly create slick applications, there are some rough edges though that need to be ironed out to make it production ready.
Shindig provides a sample container right out of the box. This container is as elementary as a "hello world" application that you try in Chapter 1 of any book. It hardly demonstrates the power of Shindig or the potential it holds for building an app that looks & feels like iGoogle.
In the remainder sections, I'd focus on the Container development in particular and, share tips & tricks to help you learn from our mistakes and, build apps that are better and faster than portal apps.
There are plenty of articles out there on building websites that look like igoogle. Here are 2 of my favorites -
(1) A JQuery based iGoogle interface by James Padolsey
(2) A Dojo based iGoogle interface by Matthew Russell
In the first article, James has provided a fully functional browser compatible source code on implementing an interface with drag & drop niceties. In the second article, Matthew shares his experience of implementing a shindig container using dojo.
To be continued...
My team at Wipro has been working on Apache Shindig since July 2008 and, we have successfully put together a framework that allows rapid development of Social Enterprise applications. This framework is called WiproWeb2Works and, provides among other things, a fully functional igoogle-like container for gadgets. We have in fact put a reference implementation of WiproWeb2Works framework - Festa on the Web for any one to get a feel of a "portal" application based on Apache Shindig. I'd encourage you to register (free!) and try it out today.
In my honest opinion, Shindig is the best way to jumpstart development of a Web 2.0 content mashup/social application. While this is great news for those of us that want to quickly create slick applications, there are some rough edges though that need to be ironed out to make it production ready.
Shindig provides a sample container right out of the box. This container is as elementary as a "hello world" application that you try in Chapter 1 of any book. It hardly demonstrates the power of Shindig or the potential it holds for building an app that looks & feels like iGoogle.
There are plenty of articles out there on building websites that look like igoogle. Here are 2 of my favorites -
(1) A JQuery based iGoogle interface by James Padolsey
(2) A Dojo based iGoogle interface by Matthew Russell
In the first article, James has provided a fully functional browser compatible source code on implementing an interface with drag & drop niceties. In the second article, Matthew shares his experience of implementing a shindig container using dojo.
To be continued...
Thursday, May 21, 2009
Enable security in Tomcat
I finally figured a way to enable Security Manager on Tomcat 6.0 (windows) . The documentation at Apache Tomcat's official website is incorrect and, needs revision.
Please follow these steps to enable security on your Tomcat server:-
1) Right click on the tomcat monitor icon

2) Open the Configure dialog.
3) Click on the Java tab
4) Add 2 system properties - java.security.manager and java.security.policy that points to the policy file. I'm pointing to the default catalina.policy file that ships with tomcat distribution.
5) Add the 2 properties to java options
6) Click OK.
7) Stop Service
8) Start Service
9) Tomcat is now running with security enabled.
Thanks for reading this post. Please leave comments/suggestions to let me know if it worked for you.
Please follow these steps to enable security on your Tomcat server:-
1) Right click on the tomcat monitor icon
2) Open the Configure dialog.
7) Stop Service
8) Start Service
9) Tomcat is now running with security enabled.
Thanks for reading this post. Please leave comments/suggestions to let me know if it worked for you.
Labels:
catalina.policy,
JAAS,
security,
SecurityManager,
Tomcat
Saturday, March 28, 2009
Ant Task for YUICompressor
Here is a macro I wrote to look for javascript files recursively in a source folder, compress every one of them using YUICompressor and copy the compressed javascript files to target folder. The usage of the task cannot get any simpler than this:-
< target name="compress" >
<yuicompress src="uncompressed_folder" target="target_folder"/>
</target>
Here is the macro definition for yuicompress. Just place it before the yuicompress task in buildfile.xml
<property description="YUICompressor" name="YUICompressor" value="./build/yuicompressor/yuicompressor-2.4.2.jar" />
<macrodef name="yuicompress">
<attribute name="src"/>
<attribute name="target"/>
<sequential>
<echo message="Compressing files at @{src}" />
<!-- create target folder if it doesn't exist already -->
<mkdir dir="@{target}"/>
<!-- Create directories recursively first.
Exclude javascript files as they will be put by YUICompressor later on -->
<copy todir="@{target}">
<fileset dir="@{src}">
<exclude name="**/*.js"/>
</fileset>
</copy>
<!-- Compress js files recursively -->
<apply executable="java" parallel="false" verbose="true" dest="@{target}">
<fileset dir="@{src}">
<include name="**/*.js"/>
</fileset>
<arg line="-jar" />
<arg path="${YUICompressor}" />
<arg value="--charset" />
<arg value="ANSI" />
<arg value="-o" />
<targetfile />
<mapper type="glob" from="*.js" to="*.js" />
</apply>
<echo message="Files compressed and copied to @{target}" />
</sequential>
</macrodef>
Reminder: Remember to replace YUICompressor's location marked in red above
Please leave a comment if you found it useful.
< target name="compress" >
<yuicompress src="uncompressed_folder" target="target_folder"/>
</target>
Here is the macro definition for yuicompress. Just place it before the yuicompress task in buildfile.xml
<property description="YUICompressor" name="YUICompressor" value="./build/yuicompressor/yuicompressor-2.4.2.jar" />
<macrodef name="yuicompress">
<attribute name="src"/>
<attribute name="target"/>
<sequential>
<echo message="Compressing files at @{src}" />
<!-- create target folder if it doesn't exist already -->
<mkdir dir="@{target}"/>
<!-- Create directories recursively first.
Exclude javascript files as they will be put by YUICompressor later on -->
<copy todir="@{target}">
<fileset dir="@{src}">
<exclude name="**/*.js"/>
</fileset>
</copy>
<!-- Compress js files recursively -->
<apply executable="java" parallel="false" verbose="true" dest="@{target}">
<fileset dir="@{src}">
<include name="**/*.js"/>
</fileset>
<arg line="-jar" />
<arg path="${YUICompressor}" />
<arg value="--charset" />
<arg value="ANSI" />
<arg value="-o" />
<targetfile />
<mapper type="glob" from="*.js" to="*.js" />
</apply>
<echo message="Files compressed and copied to @{target}" />
</sequential>
</macrodef>
Reminder: Remember to replace YUICompressor's location marked in red above
Please leave a comment if you found it useful.
Wednesday, December 31, 2008
Deploying Shindig in a non root context
Shindig is configured, by default, to be accessed in ROOT context. While this is ok for development purposes, it is not desirable in a production setting where main applications may already be running in ROOT context OR in cases where a web server acts as a HTTP Reverse Proxy for an Appserver.
This post describes the steps I followed to make Shindig gadget and opensocial containers work on my Tomcat Server in a non-Root Context. Thanks a ton to Kevin Brown for providing valuable pointers in this email chain.
The following steps would enable deployment of Shindig in a non Root context on Tomcat and other AppServers.
1) Build shindig using steps provided at http://incubator.apache.org/shindig/#tab-building
2) Copy shindig/java/server/target/shindig-server-1.1-SNAPSHOT.war to a temporary folder (say c:\temp)
3) cd c:\temp
4) unzip shindig-server-1.1-SNAPSHOT.war to c:\temp\shindig folder
5) cd shindig/WEB-INF/classes/containers/default
6) Open container.js in a text editor. Since the default setting assumes shindig to be in the root context, it is necessary to modify all URLs for opensocial calls to work correctly. After updating all URLs, save changes and close container.js.
(There are some properties in shindig still that are pending migration to container.js, hence step#7 to 10. Thanks Carmen and Gerald for this suggestion)
7) Extract shindig.properties from shindig/WEB-INF/lib/shindig-common-1.1-SNAPSHOT.jar to shindig/WEB-INF/classes folder
8) Remove shindig.properties from shindig/WEB-INF/lib/shindig-common-1.1-SNAPSHOT.jar
9) cd shindig/WEB-INF/classes
10) Open shindig.properties in a text editor. Since the default setting assumes shindig to be in the root context, it is necessary to modify all URLs for gadget/concat calls to work correctly.
11) Fix Shindig's sample opensocial container "samplecontainer"
(a) cd c:/temp/shindig/gadgets/files/samplecontainer
(b) Open samplecontainer.js in a text editor
(c) Append Shindig's context name in the URL assigned to the variable "socialDataPath" (line# 44)
(d) Append Shindig's context name in the URI passed to sendRequestToServer() within requestGadgetMetaData function (line# 192)
(e) save & close samplecontainer.js
(f) cd examples
(g) Open all gadget xmls and, update URL of images (for ex:- bubble.gif, nophoto.if etc.)
(h) Also, make the changes mentioned in steps b-g for samplecontainer provided under c:/temp/shindig/WEB-INF/classes/gadgets/files/samplecontainer
12) Zip the contents of shindig folder and rename the zip file as shindig.war or any other name based on your preference.
13) This war file would now work on Tomcat or any other app server in a non-root context
This post describes the steps I followed to make Shindig gadget and opensocial containers work on my Tomcat Server in a non-Root Context. Thanks a ton to Kevin Brown for providing valuable pointers in this email chain.
The following steps would enable deployment of Shindig in a non Root context on Tomcat and other AppServers.
1) Build shindig using steps provided at http://incubator.apache.org/shindig/#tab-building
2) Copy shindig/java/server/target/shindig-server-1.1-SNAPSHOT.war to a temporary folder (say c:\temp)
3) cd c:\temp
4) unzip shindig-server-1.1-SNAPSHOT.war to c:\temp\shindig folder
5) cd shindig/WEB-INF/classes/containers/default
6) Open container.js in a text editor. Since the default setting assumes shindig to be in the root context, it is necessary to modify all URLs for opensocial calls to work correctly. After updating all URLs, save changes and close container.js.
(There are some properties in shindig still that are pending migration to container.js, hence step#7 to 10. Thanks Carmen and Gerald for this suggestion)
7) Extract shindig.properties from shindig/WEB-INF/lib/shindig-common-1.1-SNAPSHOT.jar to shindig/WEB-INF/classes folder
8) Remove shindig.properties from shindig/WEB-INF/lib/shindig-common-1.1-SNAPSHOT.jar
9) cd shindig/WEB-INF/classes
10) Open shindig.properties in a text editor. Since the default setting assumes shindig to be in the root context, it is necessary to modify all URLs for gadget/concat calls to work correctly.
11) Fix Shindig's sample opensocial container "samplecontainer"
(a) cd c:/temp/shindig/gadgets/files/samplecontainer
(b) Open samplecontainer.js in a text editor
(c) Append Shindig's context name in the URL assigned to the variable "socialDataPath" (line# 44)
(d) Append Shindig's context name in the URI passed to sendRequestToServer() within requestGadgetMetaData function (line# 192)
(e) save & close samplecontainer.js
(f) cd examples
(g) Open all gadget xmls and, update URL of images (for ex:- bubble.gif, nophoto.if etc.)
(h) Also, make the changes mentioned in steps b-g for samplecontainer provided under c:/temp/shindig/WEB-INF/classes/gadgets/files/samplecontainer
12) Zip the contents of shindig folder and rename the zip file as shindig.war or any other name based on your preference.
13) This war file would now work on Tomcat or any other app server in a non-root context
Labels:
deploy,
gadget,
non root,
opensocial,
samplecontainer,
shindig
Subscribe to:
Posts (Atom)