From the very useful department: the Gmail superstars option augments the message starring feature with different colors and shapes.
Very useful if like me you keep your (small of course) to-do list in your inbox.
From the very useful department: the Gmail superstars option augments the message starring feature with different colors and shapes.
Very useful if like me you keep your (small of course) to-do list in your inbox.
Check it out yourself – seems like these guys’ Objective J might help (just a bit) in creating rich browser-based applications. The editor reproduces much of Keynote’s lush UI and functionality in a browser, with no apparent performance problems.
My two-slide presentation might not be enough to really judge the application…but that’s a start.
ASF projects need to include the correct attributions for the dependencies that they redistribute, in NOTICE files (see the http example).
Creating those NOTICEs is a pain in a multi-module project like Sling, so considering the lazyness is a virtue principle, I decided yesterday to automate this based on the mvn dependency:resolve output.
The resulting mknotice script has been happily generating the millions (almost) of Sling NOTICE files today, and the output is much better than we we had before.
However, the mvn dependency:resolve is not always sufficient. In our dojo extensions modules, for example, the Dojo stuff is copied by Ant tasks run from Maven (which is supposed to be declarative, but that’s another story), without having a dependency at the Maven level.
Also, our Launchpad webapp copies dependencies that are embedded in the launchpad base module using the Maven dependency plugin, which only has a dependency to the launchpad base module, but not on what’s inside, obviously. Another case where the mknotice script fails to provide complete information.
For now, such cases are handled using local module.notice.txt files, to define additional notice entries.
As is often the case when one starts to quickly write a script to fix something, this has taken me much longer than expected. And the script is slow. And a Maven plugin would be better. But hey, it works ;-)
I tend to use Eclipse only for editing/navigating code and for remote debugging, leaving the heavy lifting of building and executing stuff to the old trusted command line.
In this context, the mvn eclipse:eclipse plugin often generates too much magic for me. When working with Sling, especially, I don’t want any maven or java builders in my Eclipse projects, and for some reason the plugin generates an extra resource path based on the LICENSE, NOTICE and similar files.
If you like to work in the same way (I know many people like go further with their IDEs), here are two scripts that I use to post-process the Eclipse project files after mvn eclipse:eclipse.
This scripts “fixes” all .project and .classpath files under the current directory (uses xsltproc):
#!/bin/bash XSLT=$(dirname $0)/fix-eclipse-maven.xsl TMPF=/tmp/$$.tmp find . -name .project | while read p do echo "Running $(basename $XSLT) on $p..." xsltproc $XSLT $p > $TMPF rm -f $p mv $TMPF $p done EXPR="LICENSE.*DISCLAIMER" find . -name .classpath | while read c do echo "Removing lines containing $EXPR from $c)" grep -v $EXPR $c > $TMPF rm -f $c mv $TMPF $c done
And uses this XSLT transform to get rid of the build commands in .project files:
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > <xsl:template match="*"> <xsl:copy> <xsl:copy-of select="@*"/> <xsl:apply-templates/> </xsl:copy> </xsl:template> <!-- remove all Eclipse buildCommands --> <xsl:template match="buildCommand"/> </xsl:stylesheet>
I’ve been getting at least one, if not several invitations for new social networks every day lately.
So, please don’t feel offended if I ignore them, it is sometimes hard to select between timewasters and…more timewasters ;-)
(seriously: some of this stuff is very useful, but as with any new tool it looks like we’re in the explosion of new offerings phase right now).
Codesearch looks like a very useful tool already, even if not everything is indexed as I write this – robots.txt need to be fixed here and there.
Such tools demonstrate in a nice way how open code has to be good to survive – now everyone can find out even more easily about your suboptimal, politically incorrect or insecure code.
I wasn’t impressed at first when looking at the livescribe smart pen hardware specs (although impressive, that’s in a way just another smart pen), but the demos made the coin drop: synchronizing audio with smart paper notes sounds like the killer app for smart pens, and that pen seems to do it right. Can’t wait to try it!
$ history | awk {'print $2'} | sort | uniq -c | sort -k1 -rn | head 975 cd 755 mvn 623 svn 467 ls 320 find 236 less 209 rm 195 curl 189 java 115 vi
Really? Well my talk at ApacheCon is done and went well, so that’s real at least.
Someone commented that it was good and depressing at the same time. Their company has all the tools in place but doesn’t get any added value, due to using them in the wrong way, or not consistently enough. Good to hear that my talk at least maps to real life ;-)
Moving from the previous talk‘s bare metal approach to a higher level “what are the real issues that we’re solving” approach was a good idea – people are aware of our tools today, we don’t need to explain what they do as much as before.
A journalist called me regarding a post on my french-speaking blog about getting an eBook reader for christmas.
I guess Santa is not reading my blog – I didn’t get an eBook yet. But if you’ve been using one for some time, said journalist would like to talk about your experience – how does that compare with reading on a laptop? Or from a dead tree book?
If you’re willing to be interviewed about that, drop me a line or a comment and I’ll make the necessary connections.