Comments for matteo caprari http://couch.caprazzi.net Thu, 06 Oct 2011 01:42:00 +0000 hourly 1 http://wordpress.org/?v=3.1.3 Comment on Learning Closure. Ajax with goog.net.* by AlexVD http://couch.caprazzi.net/posts/learning-closure-ajax-with-goog-net/comment-page-1/#comment-199 AlexVD Thu, 06 Oct 2011 01:42:00 +0000 http://caprazzi.net/?p=51#comment-199 Thanks for this, it was just what i needed. Thanks for this, it was just what i needed.

]]> Comment on Learning Closure. Ajax with goog.net.* by Darell17 http://couch.caprazzi.net/posts/learning-closure-ajax-with-goog-net/comment-page-1/#comment-198 Darell17 Tue, 04 Oct 2011 07:00:00 +0000 http://caprazzi.net/?p=51#comment-198 Informative post on script! Informative post on script!

]]> Comment on Java bytecode, string concatenation and StringBuilder by Jan Burse http://couch.caprazzi.net/posts/java-bytecode-string-concatenation-and-stringbuilder/comment-page-1/#comment-197 Jan Burse Mon, 05 Sep 2011 03:30:00 +0000 http://caprazzi.net/?p=684#comment-197 Strange that the compiler generates a valueOf(), it should now that the object has type string. Strange that the compiler generates a valueOf(), it should now that the object has type string.

]]> Comment on Learning Closure. Ajax with goog.net.* by Alexander Jeliuc http://couch.caprazzi.net/posts/learning-closure-ajax-with-goog-net/comment-page-1/#comment-196 Alexander Jeliuc Mon, 15 Aug 2011 03:39:00 +0000 http://caprazzi.net/?p=51#comment-196 Thx for post! Thx for post!

]]> Comment on Java bytecode, string concatenation and StringBuilder by Anonymous http://couch.caprazzi.net/posts/java-bytecode-string-concatenation-and-stringbuilder/comment-page-1/#comment-195 Anonymous Thu, 30 Jun 2011 10:26:00 +0000 http://caprazzi.net/?p=684#comment-195 Forax, apparently the option has been there since  Java 6 Update 20. It would be interesting to see if the optimization happens during compile or JIT... EDIT: javac does not accept that option, so it's sure a JIT optimization http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html Forax,
apparently the option has been there since  Java 6 Update 20. It would be interesting to see if the optimization happens during compile or JIT…

EDIT: javac does not accept that option, so it’s sure a JIT optimization

http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

]]> Comment on Java bytecode, string concatenation and StringBuilder by forax http://couch.caprazzi.net/posts/java-bytecode-string-concatenation-and-stringbuilder/comment-page-1/#comment-194 forax Wed, 29 Jun 2011 17:01:00 +0000 http://caprazzi.net/?p=684#comment-194 The is a special VM optimization in JDK7 that recognizes StringBuilder/Buffer pattern and optimize it in order to create only one String if possible (see -XX:+OptimizeStringConcat) The is a special VM optimization in JDK7 that recognizes StringBuilder/Buffer pattern and optimize it in order to create only one String if possible (see -XX:+OptimizeStringConcat)

]]> Comment on Java bytecode, string concatenation and StringBuilder by Anonymous http://couch.caprazzi.net/posts/java-bytecode-string-concatenation-and-stringbuilder/comment-page-1/#comment-193 Anonymous Wed, 29 Jun 2011 11:21:00 +0000 http://caprazzi.net/?p=684#comment-193 Hey Robert, interesting observation: Javadoc for java 1.4 says "String concatenation is implemented through the StringBuffer class and its append method" (http://download.oracle.com/javase/1.4.2/docs/api/java/lang/String.html) While in java 1.5 it's "String concatenation is implemented through the StringBuilder(or StringBuffer) class and its append method" (I've updated the post) It actually makes sense, as StringBuilder has been introduced as a faster (non thread-safe) version of StringBuffer. To answer your question, i think it's likely the JIT compiler finds an opportunity for optimization in a concat loop, but I have no idea on how to go at testing this, other than disabling the JIT and comparing the results. Seems to be good material for an other post! Thanks! Hey Robert,
interesting observation:
Javadoc for java 1.4 says “String concatenation is implemented through
the StringBuffer class and its append method”
(http://download.oracle.com/javase/1.4.2/docs/api/java/lang/String.html)
While in java 1.5 it’s “String concatenation is implemented through
the StringBuilder(or StringBuffer) class and its append method” (I’ve
updated the post)

It actually makes sense, as StringBuilder has been introduced as a
faster (non thread-safe) version of StringBuffer.

To answer your question, i think it’s likely the JIT compiler finds
an opportunity for optimization in a concat loop, but I have no idea
on how to go at testing this, other than disabling the JIT and
comparing the results. Seems to be good material for an other post!

Thanks!

]]> Comment on Java bytecode, string concatenation and StringBuilder by robertmarkbram http://couch.caprazzi.net/posts/java-bytecode-string-concatenation-and-stringbuilder/comment-page-1/#comment-192 robertmarkbram Wed, 29 Jun 2011 11:04:00 +0000 http://caprazzi.net/?p=684#comment-192 Nice post Matteo, The Javadoc for String does say that  + is  implemented through the StringBuffer. I wonder if other JVMs do this too (IBM, Google)? Also, I wonder if the above code gets optimised at all after a few hundred runs? (If there even is any optimisation possible.) Rob :) Nice post Matteo,

The Javadoc for String does say that  + is  implemented through the StringBuffer. I wonder if other JVMs do this too (IBM, Google)?

Also, I wonder if the above code gets optimised at all after a few hundred runs? (If there even is any optimisation possible.)

Rob :)

]]> Comment on Java bytecode, string concatenation and StringBuilder by Anonymous http://couch.caprazzi.net/posts/java-bytecode-string-concatenation-and-stringbuilder/comment-page-1/#comment-191 Anonymous Wed, 29 Jun 2011 10:34:00 +0000 http://caprazzi.net/?p=684#comment-191 Hi Christian, I've updated the post with your observation. Thanks. Hi Christian,
I’ve updated the post with your observation.

Thanks.

]]> Comment on Java bytecode, string concatenation and StringBuilder by Christian Ullenboom http://couch.caprazzi.net/posts/java-bytecode-string-concatenation-and-stringbuilder/comment-page-1/#comment-190 Christian Ullenboom Wed, 29 Jun 2011 10:11:00 +0000 http://caprazzi.net/?p=684#comment-190 Too add 2 ideas: String has a contact() method which people often forget. And StringBuilder/StringBuffer has a constructor to initialize with a size for the internal buffer to prevent the char array from resizing if the size of segments are known. Too add 2 ideas: String has a contact() method which people often forget. And StringBuilder/StringBuffer has a constructor to initialize with a size for the internal buffer to prevent the char array from resizing if the size of segments are known.

]]> Comment on Java bytecode, string concatenation and StringBuilder by Anonymous http://couch.caprazzi.net/posts/java-bytecode-string-concatenation-and-stringbuilder/comment-page-1/#comment-189 Anonymous Tue, 28 Jun 2011 14:39:00 +0000 http://caprazzi.net/?p=684#comment-189 Anergy, you're right, should be a StringBuilder. Thanks for spotting it. -teo Anergy,
you’re right, should be a StringBuilder. Thanks for spotting it.

-teo

]]> Comment on Java bytecode, string concatenation and StringBuilder by Anergy http://couch.caprazzi.net/posts/java-bytecode-string-concatenation-and-stringbuilder/comment-page-1/#comment-184 Anergy Tue, 28 Jun 2011 09:54:22 +0000 http://caprazzi.net/?p=684#comment-184 StringBuffer is wrong probably in second last code sample. StringBuffer is wrong probably in second last code sample.

]]> Comment on Evaluating relative speed of java digest (hashing) algorithms by John Laur http://couch.caprazzi.net/posts/evaluating-relative-speed-of-java-digest-hashing-algorithms/comment-page-1/#comment-180 John Laur Thu, 23 Jun 2011 21:14:53 +0000 http://caprazzi.net/?p=672#comment-180 Personally I recommend using PBKDF2 with HMAC_SHA512, 10000 iterations, and 8 bytes of salt. There are various libraries for PBKDF2, but most do not allow you to choose a hash other than HMAC_SHA1 (it is both the default and the best choice of the algos in the official standard RFC2898; using HMAC_SHA512 is technically bending the rules). http://www.ietf.org/rfc/rfc2898.txt contains the standard. The only real tuning is the # of iterations which should be as high as your application can tolerate without ever going under 4000 or so. So if you are going for interoperability you can still go with HMAC_SHA1 and feel pretty good about it. This is the algorithm that is used to generate DK's for WPA2, so until you hear WPA2 is broken PBKDF2 with HMAC_SHA1 is still a safe bet. To find an implementation example, just google for PBKDF2 + Your Language of Choice. I found a java one here http://www.rtner.de/software/PBKDF2.html and there is a javascript one here: http://anandam.name/pbkdf2/pbkdf2.js.txt if that is your use case. Or there are OpenSSL bindings for most languages, and OpenSSL has the function PKCS5_PBKDF2_HMAC_SHA1 Most of these can be adapted to use a different hashing algorithm. Be sure you are not truncating the output of the hash function if possible as PBKDF2 allows for it to be of arbitrary length. HMAC_SHA1 is 20 bytes; HMAC_SHA512 is 64. Store the PBKDF2 parameters with the salt and hash - obscurity here is unnecessary. I use a format like: $PBKDF2$HMACSHA512:10000:mV8wcrQOkeg=$od7tWGZOH4JxwNyXFDPY4DgSYmTbtWO5zgoX1LgufC036F/OuRethvnJ8PaJP56pqUCXV1ClBPHt/fCMroaE1A== $$hashfunction:iterations:base64(salt)$base64(hash) The above is the resultant enoding for the DK derived from "toomanysecrets" with a full 64 byte hash. Any hash of this format can be stored in a char(128) or similar. This hash takes about 0.15s of CPU time to compute with the implementation I used on decent hardware. This is about 6 hashes/second. By comparison your straight SHA512 was operating at about 32,000 hashes/second. Personally I recommend using PBKDF2 with HMAC_SHA512, 10000 iterations, and 8 bytes of salt. There are various libraries for PBKDF2, but most do not allow you to choose a hash other than HMAC_SHA1 (it is both the default and the best choice of the algos in the official standard RFC2898; using HMAC_SHA512 is technically bending the rules). http://www.ietf.org/rfc/rfc2898.txt contains the standard. The only real tuning is the # of iterations which should be as high as your application can tolerate without ever going under 4000 or so.

So if you are going for interoperability you can still go with HMAC_SHA1 and feel pretty good about it. This is the algorithm that is used to generate DK’s for WPA2, so until you hear WPA2 is broken PBKDF2 with HMAC_SHA1 is still a safe bet.

To find an implementation example, just google for PBKDF2 + Your Language of Choice. I found a java one here http://www.rtner.de/software/PBKDF2.html and there is a javascript one here: http://anandam.name/pbkdf2/pbkdf2.js.txt if that is your use case.

Or there are OpenSSL bindings for most languages, and OpenSSL has the function PKCS5_PBKDF2_HMAC_SHA1

Most of these can be adapted to use a different hashing algorithm. Be sure you are not truncating the output of the hash function if possible as PBKDF2 allows for it to be of arbitrary length. HMAC_SHA1 is 20 bytes; HMAC_SHA512 is 64. Store the PBKDF2 parameters with the salt and hash – obscurity here is unnecessary. I use a format like:

$PBKDF2$HMACSHA512:10000:mV8wcrQOkeg=$od7tWGZOH4JxwNyXFDPY4DgSYmTbtWO5zgoX1LgufC036F/OuRethvnJ8PaJP56pqUCXV1ClBPHt/fCMroaE1A==

$$hashfunction:iterations:base64(salt)$base64(hash)

The above is the resultant enoding for the DK derived from “toomanysecrets” with a full 64 byte hash. Any hash of this format can be stored in a char(128) or similar. This hash takes about 0.15s of CPU time to compute with the implementation I used on decent hardware. This is about 6 hashes/second. By comparison your straight SHA512 was operating at about 32,000 hashes/second.

]]> Comment on Evaluating relative speed of java digest (hashing) algorithms by Java bytecode, string concatenation and StringBuilder | matteo caprari http://couch.caprazzi.net/posts/evaluating-relative-speed-of-java-digest-hashing-algorithms/comment-page-1/#comment-179 Java bytecode, string concatenation and StringBuilder | matteo caprari Thu, 23 Jun 2011 09:09:01 +0000 http://caprazzi.net/?p=672#comment-179 [...] matteo caprari Skip to content Home ← Evaluating relative speed of java digest (hashing) algorithms [...] [...] matteo caprari Skip to content Home ← Evaluating relative speed of java digest (hashing) algorithms [...]

]]> Comment on Evaluating relative speed of java digest (hashing) algorithms by Matteo Caprari http://couch.caprazzi.net/posts/evaluating-relative-speed-of-java-digest-hashing-algorithms/comment-page-1/#comment-178 Matteo Caprari Thu, 23 Jun 2011 08:52:32 +0000 http://caprazzi.net/?p=672#comment-178 Hi John! Oh boy, the things that one doesn't know! Do you have a link to share for an acceptable way of implementing password hashing? I'd like to extend the post with some timings. Thanks for commenting :) Hi John!
Oh boy, the things that one doesn’t know!
Do you have a link to share for an acceptable way of implementing password hashing? I’d like to extend the post with some timings.

Thanks for commenting :)

]]> Comment on Evaluating relative speed of java digest (hashing) algorithms by John Laur http://couch.caprazzi.net/posts/evaluating-relative-speed-of-java-digest-hashing-algorithms/comment-page-1/#comment-177 John Laur Wed, 22 Jun 2011 17:44:32 +0000 http://caprazzi.net/?p=672#comment-177 Matteo, Hello! I wanted to drop in to mention (if only for the sake of others who might read this) that for the specific use case of hashing passwords or decrypting a shared key for a stream cypher (passprhase) or similar situations, a salt+hash is actually a poor thing to do. The unfortunate effects of 30 years of fallout caused by seeing UNIX crypt() protect our most sensitive root passwords has unfortunately led many web developers into the trap of believing that salt+good hash is a reasonable storage mechanism. Consider the password breaches caused by recent exploits at Gawker, Sony, et al. -- all of this data stored salted and hashed passwords, but by the time news broke and actual data began leaking into the wild, most if not all the stored hashes had been broken. Hashing functions are designed with two goals: 1) be as fast as possible and 2) minimize hash collisions. Salting prevents a precomputed (rainbow table) attack, but when a single modern GPU can roll through billions to trillions of possibilities per second in a brute-force attack, the "strength" of the hash is all but irrelevant. "Better" hashes are only needed to reduce the likelyhood of hash collision or eliminate flaws or weaknesses in earlier algorithms. So it is in fact the speed of the algorithm which creates and verifies a hash, or rather the lack of it, that makes the most difference with regards to security. So unless one wants to perform a very deep dive into cryptographic theroy, the best approach is usually to code to a standard. The current most widely used method is to use PBKDF2 (RFC 2898) to produce and store a derived key instead of a simple hash. PBKDF2 allows the selection of a few parameters, mainly the salt length, the hash algorithm, and the number of iterations. I believe 64-bit salts, 2000 iterations, and HMAC_SHA256 are around the currently accepted minimums for "strong." Of course the password requirements themselves must be decently designed to survive a dictionary attack or brute force attach which are still possible (though many orders of magnitude slower) . If one wants to experiment, there are some alternatives which can be equally good if not better such as bcrypt and scrypt. But as they have not been subjected to as widespread use or scrutiny, often they are not great choices for projects that need to be autited, understood by many people, or need to be somewhat future-proof or portable. No matter what, it is all very interesting reading! Matteo,

Hello!

I wanted to drop in to mention (if only for the sake of others who might read this) that for the specific use case of hashing passwords or decrypting a shared key for a stream cypher (passprhase) or similar situations, a salt+hash is actually a poor thing to do. The unfortunate effects of 30 years of fallout caused by seeing UNIX crypt() protect our most sensitive root passwords has unfortunately led many web developers into the trap of believing that salt+good hash is a reasonable storage mechanism. Consider the password breaches caused by recent exploits at Gawker, Sony, et al. — all of this data stored salted and hashed passwords, but by the time news broke and actual data began leaking into the wild, most if not all the stored hashes had been broken.

Hashing functions are designed with two goals: 1) be as fast as possible and 2) minimize hash collisions. Salting prevents a precomputed (rainbow table) attack, but when a single modern GPU can roll through billions to trillions of possibilities per second in a brute-force attack, the “strength” of the hash is all but irrelevant. “Better” hashes are only needed to reduce the likelyhood of hash collision or eliminate flaws or weaknesses in earlier algorithms.

So it is in fact the speed of the algorithm which creates and verifies a hash, or rather the lack of it, that makes the most difference with regards to security. So unless one wants to perform a very deep dive into cryptographic theroy, the best approach is usually to code to a standard. The current most widely used method is to use PBKDF2 (RFC 2898) to produce and store a derived key instead of a simple hash. PBKDF2 allows the selection of a few parameters, mainly the salt length, the hash algorithm, and the number of iterations. I believe 64-bit salts, 2000 iterations, and HMAC_SHA256 are around the currently accepted minimums for “strong.” Of course the password requirements themselves must be decently designed to survive a dictionary attack or brute force attach which are still possible (though many orders of magnitude slower) .

If one wants to experiment, there are some alternatives which can be equally good if not better such as bcrypt and scrypt. But as they have not been subjected to as widespread use or scrutiny, often they are not great choices for projects that need to be autited, understood by many people, or need to be somewhat future-proof or portable.

No matter what, it is all very interesting reading!

]]> Comment on Where are generics stored in java compiled classes? by Bruno Windels http://couch.caprazzi.net/posts/where-are-generics-stored-in-java-compiled-classes/comment-page-1/#comment-174 Bruno Windels Fri, 01 Apr 2011 21:47:11 +0000 http://caprazzi.net/?p=614#comment-174 There is also a pretty good description of the signature attribute in spec pdf of JSR14, The JSR that describes the implementation of generics in Java. http://www.jcp.org/aboutJava/communityprocess/review/jsr014/ Great article! There is also a pretty good description of the signature attribute in spec pdf of JSR14, The JSR that describes the implementation of generics in Java.

http://www.jcp.org/aboutJava/communityprocess/review/jsr014/

Great article!

]]> Comment on Where are generics stored in java compiled classes? by Where are generics stored in java compiled classes? | matteo caprari | java http://couch.caprazzi.net/posts/where-are-generics-stored-in-java-compiled-classes/comment-page-1/#comment-144 Where are generics stored in java compiled classes? | matteo caprari | java Thu, 24 Feb 2011 19:13:47 +0000 http://caprazzi.net/?p=614#comment-144 [...] więcej: Where are generics stored in java compiled classes? | matteo caprari cast-instructions, compiler-, generics-were, idea, learning-some, other-things, see-how, [...] [...] więcej: Where are generics stored in java compiled classes? | matteo caprari cast-instructions, compiler-, generics-were, idea, learning-some, other-things, see-how, [...]

]]> Comment on generating SVG charts with couchdb by Matteo Caprari http://couch.caprazzi.net/posts/charting-data-with-couchdb/comment-page-1/#comment-134 Matteo Caprari Sat, 08 May 2010 22:51:46 +0000 http://caprazzi.net/posts/charting-data-with-couchdb/#comment-134 @JeroenPulles E4X seems sexy, but have yet to dive into it. Thanks for the hint. @JeroenPulles E4X seems sexy, but have yet to dive into it. Thanks for the hint.

]]> Comment on generating SVG charts with couchdb by Jeroen Pulles http://couch.caprazzi.net/posts/charting-data-with-couchdb/comment-page-1/#comment-133 Jeroen Pulles Thu, 29 Apr 2010 11:40:46 +0000 http://caprazzi.net/posts/charting-data-with-couchdb/#comment-133 that should have been: var r = <rect x={x} y={10 * offset} />; that should have been:
var r = <rect x={x} y={10 * offset} />;

]]> Comment on generating SVG charts with couchdb by Jeroen Pulles http://couch.caprazzi.net/posts/charting-data-with-couchdb/comment-page-1/#comment-132 Jeroen Pulles Thu, 29 Apr 2010 11:34:12 +0000 http://caprazzi.net/posts/charting-data-with-couchdb/#comment-132 Super, just what I needed. Your javascript backend probably also supports E4X, which makes working with XML much easier: var r = ; r.@width = 100; r.toXMLString(); Super, just what I needed. Your javascript backend probably also supports E4X, which makes working with XML much easier:

var r = ;

r.@width = 100;

r.toXMLString();

]]> Comment on openid authentication handler for couchdb by Ed http://couch.caprazzi.net/posts/openid-authentication-handler-for-couchdb/comment-page-1/#comment-131 Ed Mon, 29 Mar 2010 03:36:24 +0000 http://caprazzi.net/?p=496#comment-131 Hi Matteo, This looks very interesting.. But can you give some specifics on which version of couchdb this has been tested with.. I have tried it with trunk (0.12) and 0.11.0 with no luck.. I keep getting the following error: {"error":"unknown_error","reason":"function_clause"} which I think may be related to my defaults/local.ini so posting you ini file would also be usefull.. Thanks Hi Matteo,

This looks very interesting.. But can you give some specifics on which version of couchdb this has been tested with.. I have tried it with trunk (0.12) and 0.11.0 with no luck.. I keep getting the following error: {“error”:”unknown_error”,”reason”:”function_clause”} which I think may be related to my defaults/local.ini so posting you ini file would also be usefull..

Thanks

]]> Comment on Learning Closure: managing dependencies and compiling by Apphacker http://couch.caprazzi.net/posts/learning-closure-managing-dependencies-and-compiling/comment-page-1/#comment-47 Apphacker Mon, 28 Dec 2009 23:48:39 +0000 http://caprazzi.net/?p=154#comment-47 I found your explanation a little incomplete and unworkable. I filled in some holes on my own post: http://blog.apphackers.com/2009/12/28/howto-how-to-use-goog-require-and-goog-provide-for-your-own-code/ I found your explanation a little incomplete and unworkable. I filled in some holes on my own post:

http://blog.apphackers.com/2009/12/28/howto-how-to-use-goog-require-and-goog-provide-for-your-own-code/

]]> Comment on CYZ_RGB alpha – blinkm alternative firmware by Anton Eliasson http://couch.caprazzi.net/posts/cyz_rgb-alpha-blinkm-alternative-firmware/comment-page-1/#comment-39 Anton Eliasson Mon, 21 Dec 2009 23:17:28 +0000 http://caprazzi.net/?p=3#comment-39 I would like to report a small bug in the firmware (rev 289). usiTwi/UsiTwiMaster.h must be renamed to usiTwiMaster.h (lowercase u) or otherwise it won't compile on Linux, since it's case-sensitive. Unfortunately I don't know subversion well enough to correct this myself so I'm leaving it to you. You should also be aware that there's an error in the BlinkM datasheet, rev 20081101. In the schematic on page 40, pin 2 & 3 on the attiny45 are swapped (red & green leds). I've already mailed them about this so hopefully it will be corrected in the next revision of the datasheet. Good luck with the project. Regards, Anton Eliasson I would like to report a small bug in the firmware (rev 289).
usiTwi/UsiTwiMaster.h must be renamed to usiTwiMaster.h (lowercase u) or otherwise it won’t compile on Linux, since it’s case-sensitive. Unfortunately I don’t know subversion well enough to correct this myself so I’m leaving it to you. You should also be aware that there’s an error in the BlinkM datasheet, rev 20081101. In the schematic on page 40, pin 2 & 3 on the attiny45 are swapped (red & green leds). I’ve already mailed them about this so hopefully it will be corrected in the next revision of the datasheet. Good luck with the project.

Regards,
Anton Eliasson

]]> Comment on generating SVG charts with couchdb by Matteo Caprari http://couch.caprazzi.net/posts/charting-data-with-couchdb/comment-page-1/#comment-30 Matteo Caprari Mon, 14 Dec 2009 16:42:02 +0000 http://caprazzi.net/posts/charting-data-with-couchdb/#comment-30 Glad to hear that. If you feel like sharing your charting stuff, drop a line :) Glad to hear that.

If you feel like sharing your charting stuff, drop a line :)

]]> Comment on generating SVG charts with couchdb by Per Ejeklint http://couch.caprazzi.net/posts/charting-data-with-couchdb/comment-page-1/#comment-29 Per Ejeklint Mon, 14 Dec 2009 15:14:11 +0000 http://caprazzi.net/posts/charting-data-with-couchdb/#comment-29 Hey, great post! And the timing couldn't be better, I'm putting together some charting myself (using the sweet gRaphaël library) and the view function you wrote was just what was missing. Thanks! Hey, great post! And the timing couldn’t be better, I’m putting together some charting myself (using the sweet gRaphaël library) and the view function you wrote was just what was missing. Thanks!

]]> Comment on generating SVG charts with couchdb by Pete Hodgson http://couch.caprazzi.net/posts/charting-data-with-couchdb/comment-page-1/#comment-24 Pete Hodgson Sat, 12 Dec 2009 02:11:12 +0000 http://caprazzi.net/posts/charting-data-with-couchdb/#comment-24 Really interesting post for a new couchdb user like myself. This clearly demonstrates a nice use case for group_level. It was also fun to see such an elegant use of SVG to render the data. Really interesting post for a new couchdb user like myself. This clearly demonstrates a nice use case for group_level. It was also fun to see such an elegant use of SVG to render the data.

]]> Comment on generating SVG charts with couchdb by Adam Kocoloski http://couch.caprazzi.net/posts/charting-data-with-couchdb/comment-page-1/#comment-23 Adam Kocoloski Thu, 10 Dec 2009 22:22:23 +0000 http://caprazzi.net/posts/charting-data-with-couchdb/#comment-23 Hey, cool stuff! I was wondering about this just the other day. Hey, cool stuff! I was wondering about this just the other day.

]]> Comment on generating SVG charts with couchdb by cirpo http://couch.caprazzi.net/posts/charting-data-with-couchdb/comment-page-1/#comment-22 cirpo Thu, 10 Dec 2009 21:52:32 +0000 http://caprazzi.net/posts/charting-data-with-couchdb/#comment-22 awesome! Thanks for sharing! I have nothing specific to say about your post because i'm not into couchdb yet, but it looks very promising. I'll surely give it a try during christmas holiday. cirpo ...Waiting for your next post... :D awesome!
Thanks for sharing! I have nothing specific to say about your post because i’m not into couchdb yet, but it looks very promising.
I’ll surely give it a try during christmas holiday.

cirpo …Waiting for your next post… :D

]]> Comment on Learning Closure. Ajax with goog.net.* by Google Closure: 糟糕的JavaScript – ALuan http://couch.caprazzi.net/posts/learning-closure-ajax-with-goog-net/comment-page-1/#comment-11 Google Closure: 糟糕的JavaScript – ALuan Mon, 30 Nov 2009 15:54:14 +0000 http://caprazzi.net/?p=51#comment-11 [...] Learning Closure with goog.net [...] [...] Learning Closure with goog.net [...]

]]> Comment on Learning Closure. Ajax with goog.net.* by Google Closure: 糟糕的JavaScript – JS More http://couch.caprazzi.net/posts/learning-closure-ajax-with-goog-net/comment-page-1/#comment-9 Google Closure: 糟糕的JavaScript – JS More Fri, 27 Nov 2009 09:48:06 +0000 http://caprazzi.net/?p=51#comment-9 [...] Learning Closure with goog.net [...] [...] Learning Closure with goog.net [...]

]]> Comment on CYZ_RGB alpha 2 – feature complete by Enkel http://couch.caprazzi.net/posts/cyz_rgb-alpha-2-feature-complete/comment-page-1/#comment-7 Enkel Mon, 23 Nov 2009 23:32:48 +0000 http://caprazzi.net/?p=5#comment-7 Hi Matteo, I'm having some trouble using your firmware. I've built the board using an attiny45v and uploaded the firmware on the chip. Then the red LED goes on and nothing happens. I've tried to use the examples on the blinkM page (the blinkMTester for Arduino actually), but it doesn't work at all. I've tried it with pull up resistors and also without, but neither way I get any reply from the blink. Do you have any test software for Arduino that I can use to check the function of the device? Thank you in advance, E. Hi Matteo, I’m having some trouble using your firmware. I’ve built the board using an attiny45v and uploaded the firmware on the chip.
Then the red LED goes on and nothing happens. I’ve tried to use the examples on the blinkM page (the blinkMTester for Arduino actually), but it doesn’t work at all.
I’ve tried it with pull up resistors and also without, but neither way I get any reply from the blink.
Do you have any test software for Arduino that I can use to check the function of the device?
Thank you in advance,
E.

]]> Comment on Learning Closure. Ajax with goog.net.* by Getting Closure: Don’t just use it, don’t just abuse it on Dion Almaer's Blog http://couch.caprazzi.net/posts/learning-closure-ajax-with-goog-net/comment-page-1/#comment-5 Getting Closure: Don’t just use it, don’t just abuse it on Dion Almaer's Blog Mon, 23 Nov 2009 16:03:01 +0000 http://caprazzi.net/?p=51#comment-5 [...] Learning Closure with goog.net [...] [...] Learning Closure with goog.net [...]

]]> Comment on Learning Closure. Ajax with goog.net.* by cirpo http://couch.caprazzi.net/posts/learning-closure-ajax-with-goog-net/comment-page-1/#comment-4 cirpo Thu, 12 Nov 2009 09:51:14 +0000 http://caprazzi.net/?p=51#comment-4 http://www.sitepoint.com/blogs/2009/11/12/google-closure-how-not-to-write-javascript/ http://www.sitepoint.com/blogs/2009/11/12/google-closure-how-not-to-write-javascript/

]]> Comment on book: forms that work by Caroline Jarrett http://couch.caprazzi.net/posts/book-forms-that-work/comment-page-1/#comment-3 Caroline Jarrett Sat, 24 Oct 2009 14:23:48 +0000 http://caprazzi.net/?p=16#comment-3 Glad to hear that you find our book useful.<br /><br />Best regards<br />Caroline Jarrett Glad to hear that you find our book useful.

Best regards
Caroline Jarrett

]]> Comment on CYZ_RGB alpha – blinkm alternative firmware by bbeagle http://couch.caprazzi.net/posts/cyz_rgb-alpha-blinkm-alternative-firmware/comment-page-1/#comment-2 bbeagle Tue, 09 Jun 2009 00:02:59 +0000 http://caprazzi.net/?p=3#comment-2 I am building a prototype version of the an RGB LED controller (just to play around with) similar to the BlinkM to try your version of the code. I downloaded your source to try and build it myself. I have not looked at your code yet, and I am not a great AVR coder myself, but if I see anything I can help with I will let you know. I think I may need the "fuse" settings to program the code into a blank ATtiny45 or ATtiny85. Can you add the fuse setting to you source .zip file.<br />Unlike the PIC controllers, the fuse settings are not in the source files I believe and I do not think they are in the makefile either.<br /><br />Thanks for your work<br />Darrell I am building a prototype version of the an RGB LED controller (just to play around with) similar to the BlinkM to try your version of the code. I downloaded your source to try and build it myself. I have not looked at your code yet, and I am not a great AVR coder myself, but if I see anything I can help with I will let you know. I think I may need the "fuse" settings to program the code into a blank ATtiny45 or ATtiny85. Can you add the fuse setting to you source .zip file.
Unlike the PIC controllers, the fuse settings are not in the source files I believe and I do not think they are in the makefile either.

Thanks for your work
Darrell

]]>