R is seriously cool. Unfortunately for me, I only use it about once a year, so I can never remember how to do anything; hence the cheatsheet.
users_usergroups <- read.csv(file="dev/users-per-group.csv", sep=",", head=TRUE)
boxplot(users_usergroups$NUM_OF_USERS)
hist(users_usergroups$NUM_OF_USERS)
Back to flipping out…
The Zen of Python teaches us Explicit is better than implicit. BDFL GvR made variable declarations implicit.
Back to flipping out…
Flexjson has been good to me, but every once in a while it jumps up and surprises me. Here’s an example.
abstract class AbstractFoo {
private Float a = 1.1f;
private Float b = 2.2f;
private Float c = 3.3f;
public Float getA() {
return a;
}
public Float getB() {
return b;
}
public Float getC() {
return c;
}
}
import flexjson.JSONSerializer;
public final class Foo extends AbstractFoo {
public static void main(final String[] args) {
final Foo myFoo = new Foo();
final JSONSerializer serializer = new JSONSerializer();
System.out.println(serializer.serialize(myFoo));
}
}
Can you guess what you’re going to get when you compile this and run java Foo? If you guessed:
{"a":1.1,"b":2.2,"c":3.3,"class":"Foo"}
you were wrong. You really get:
Exception in thread "main" flexjson.JSONException: Error trying to serialize path: [ a ]
at flexjson.JSONSerializer$ObjectVisitor.bean(JSONSerializer.java:603)
at flexjson.JSONSerializer$ObjectVisitor.json(JSONSerializer.java:471)
at flexjson.JSONSerializer$ObjectVisitor.visit(JSONSerializer.java:435)
at flexjson.JSONSerializer.serialize(JSONSerializer.java:222)
at Foo.main(Foo.java:7)
Caused by: java.lang.IllegalAccessException: Class flexjson.JSONSerializer$ObjectVisitor can not access a member of class AbstractFoo with modifiers "public"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
at java.lang.reflect.Method.invoke(Method.java:578)
at flexjson.JSONSerializer$ObjectVisitor.bean(JSONSerializer.java:579)
... 4 more
It appears that Flexjson’s serialization algorithm can’t handle a
package- visible, abstract super class. Changing it to public fixes
the problem and you can continue on your merry way.
Back to flipping out…
You may have noticed that my code blocks are suddenly syntax-highlighted. You might think a tech-oriented company like Google would have included something like this by default, but you’d be wrong.
My new syntax highlighting comes courtesy of highlight.js, which is great, although it does have some holes in the English documentation. Unfortunately, I couldn’t find any place it was being hosted for free, so I needed to set up a place of my own from which to serve it. Enter Google App Engine.
App Engine is Google’s entry into the
cloud computing
space; if you write your application according to their guidelines,
Google will run it on their infrastructure. As such, it is
massive overkill for serving up static files, but it’s free and
it has good reporting tools. So I followed the
“Hello, World!” documentation,
added the files for highlight.js, then modified my pp.yaml to add
handler for serving static files.
- url: /
static_dir: highlight
Note that this conflicts with the handler from “Hello, World!”; since I didn’t want to serve up “Hello, World!” anyway, I just deleted the other handler.
According to the documentation for highlight.js, all you should have to do now is add one simple block of Javascript:
<script src="$PATH_TO_HOSTED_JS" type="text/javascript"></script>
<script type="text/javascript">
hljs.initHighlightingOnLoad();
</script>
This is technically accurate: this will cause the markup to be modified to support syntax highlighting. That’s not enough for the highlighting to take place, however; you still need to bring in the CSS for the highlighting style you want to use (my two favorites are Sunburst and IDEA).
<link href="$PATH_TO_HOSTED_CSS" rel="stylesheet"/>
On Blogger, the best place to put this code is in the raw HTML for
your template; that way you don’t have to remember to include it in
individual posts that will have code blocks. One final note: your code
blocks have to be marked up by nesting a code tag inside a pre
tag—if you’ve done something silly like nesting a pre tag inside a
code tag, it won’t work. Here’s an example of the proper style:
<pre><code>
#!/usr/bin/env python
# -*- coding: iso-8859-1 -*-
print "Hello, World!"
</code></pre>
Back to flipping out…
If you’ve heard of Rails but can’t use it for whatever reason–my reason was an incompatible legacy schema–maybe Grails will work for you. Unashamedly inspired by Rails, Grails is written in Groovy and aims to provide the convenience of Rails while adding configurability and leveraging the power of the massive number of libraries written in Java and the other JVM languages (including Ruby, thanks to projects like JRuby). Between what comes with Grails out of the box and the available plugins, it can really take a big chunk of the grunt-work out of webapp development.
One of my favorite plugins so far is the
Acegi plugin. It bolts
Spring Security
onto your Grails project and provides for configuration using the
concise Groovy DSL for Spring. Just
type grails install-plugin acegi to install the plugin, and start
leveraging Spring Security.
One of the nice things about Spring Security is its built-in support for
HTTP Basic
authentication. Just change basicProcessingFilter from false
to true in your SecurityConfig.groovy file and your application
will now look for user credentials in the
HTTP Authorization header.
The only problem is that if no Authorization is sent, the server sends
a
302 Found
response to send the client to a login page. To be
fully compliant with the HTTP Basic spec, it should
be sending a
401 Unauthorized
response with details on the supported authentication
mechanisms. If you’ve read the documentation for the
HttpBasicProcessingFilter—which
you enabled by setting basicProcessingFilter = true earlier—you
might expect Grails to be using
HttpBasicProcessingFilterEntryPoint,
but you’d be wrong. In an effort to be user-friendly for human users, it is instead using an
AuthenticationEntryPoint
that sends the 302. To change to the strict HTTP Basic mechanism, you’ll
need to rewire the AuthenticationEntryPoint Grails is using by adding
the following to your resources.groovy file:
authenticationEntryPoint(org.springframework.security.ui.basicauth.BasicProcessingFilterEntryPoint) {
realmName = 'YOUR REALM GOES HERE'
}
Back to flipping out….
Here’s a quick update from my ongoing study of SICP.
I didn’t have access to a scanner to show the results of my expansion,
but my answer to the recursive or iterative question was: recursive.
The inc function in the definition of + is deferred until the
recursive call to + is complete, so the function has a linearly
recursive shape.
(A (1 10)) ⇒ 1024(A (2 4)) ⇒ 65536(A (3 3)) ⇒ 65536(define (f n) (A 0 n)) ⇒ 2n(define (g n) (A 1 n)) ⇒ 2n(define (g n) (A 2 n)) ⇒ 22n(define (foo n)
(cond ((< n 3) n)
(else (+ (foo (- n 1)) (* 2 (foo (- n 2))) (* 3 (foo (- n 3)))))))
There were a few false starts, but after
Eli Bendersky’s tip
about solving the problem using a for loop, it all began to fall into place.
for Loopfunction fooFor(n) {
var a = 2;
var b = 1;
var c = 0;
var result = n;
for (i = 3; i <= n; i++) {
result = a + 2*b + 3*c;
c = b;
b = a;
a = result;
}
return result;
}
(define (bar n)
(cond ((< n 3) n)
(else (bar-iter 2 1 0 n))))
(define (bar-iter a b c count)
(cond ((= count 2) a)
(else (bar-iter (+ a (* 2 b) (* 3 c)) a b (- count 1)))))
Back to flipping out…
I like the premise behind Maven, I really do. In the real world, though, Maven is an attractive nuisance: it lures developers in with its promises of an easier, consistent build process and quality project documentation, then ambushes them with constant breakage.
My latest brush with Maven breakage came
this weekend when I tried to use the
Archetype
plugin. The archetype plugin creates a new project from an existing
template. Typical archetypes do things like create the necessary
directory structure and download dependencies, and some go as far as
creating source code for a functional skeleton, e.g., the AppFuse
Archetypes.
Sounds great, right? Well, it would be if it worked. Instead, when I
tried to use the archetype plugin, it started downloading dependencies
and broke. It turns out, they released my version of the plugin with
dependencies that don’t exist in the central repositories (specifically,
commons-collections version 3.2 and commons-lang version 2.1). This
is fairly widespread among third- party maven projects, but I didn’t
expect it from something as central as the archetype plugin.
I was irritated, but I wasn’t ready to give up. Luckily for me (I thought), the error message suggested a workaround: manual installation of the dependency into your local repository. It even provided instructions:
mvn install:install-file -DgroupId=commons-lang -DartifactId=commons-lang -Dversion=2.1 -Dpackaging=jar -Dfile=/path/to/file and mvn install:install- file -DgroupId=commons-collections -DartifactId=commons-collections -Dversion=3.2 -Dpackaging=jar -Dfile=/path/to/file.
The straw that programmer’s back came when I tried to follow those directions.
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error installing artifact 'commons-collections:commons-collections:jar': Error installing artifact: /Users/hankgay/.m2/repository/commons-collections/commons-collections/3.2/commons-collections-3.2.jar (No such file or directory)
At this point, I didn’t have the energy to dig any
deeper, but that error message is monumentally
frustrating. Of course
/Users/hankgay/.m2/repository/commons-collections/commons-collections/3.2/commons-collections-3.2.jar
doesn’t exist; the whole point of the command was to create it!
The moral of the story? Maven is the sort of tool that only a masochist could love.
I really wanted to use the maven-archetype-webapp, so I
started futzing about with those dependencies again. Eventually I
fixed the problem by manually mirroring the proper versions from
ibiblio. I hope the
Maven team works on this soon, because these are some pretty absurd
lengths to go to make something work that comes in the box.
Back to flippin’ out…
Today’s post is just a brief overview of Section 1.2, but don’t worry: I’ll be covering the (numerous) exercises soon. Section 1.2 covers a lot of ground in a little space. It introduces the ideas of recursive processes (both linear- and tree-recursive processes, a distinction that was new to me, but blindingly obvious in hindsight) and iterative processes (via tail-recursion), Big O analysis (though it doesn’t call it that), and mentions probabilistic methods in passing. I was a bit surprised at the early introduction of Big O; even though I consider it one of the more important things I learned in school, my intro CS course didn’t cover it until the end of the quarter, and the coverage was hardly in-depth.
This one is actually pretty straightforward: any time you only need to recurse once on each pass of the process, you’ve got linear recursion; if you need to recurse multiple times, you’ve got tree recursion.
SICP calls it order of growth. The basic concept is to analyze your algorithm/process/whatever in terms of one aspect (typically time or space) and determine how that aspect grows with respect to some aspect of the input (typically, the number or size); think limits from math class. For instance, the running time of BubbleSort grows proportionally to the square of the length of the array/list being sorted, so its Big O is O(n2).
The basic idea is that often a tight-enough approximation, which isn’t even all that tight in a lot of cases, is just as good as an exact answer, and a lot cheaper to compute. There’s a lot of ongoing research concerning probabilistic methods right now.
Back to flipping out…
If you’ve ever joined a team that maintains a large legacy database, then you’ve probably wished for something like SchemaSpy. There are a lot of tools that let you get visualizations of a legacy database, but what sets SchemaSpy apart is that it generates HTML output so you can run it once and then view the results in your browser instead of having yet another desktop application open. I like to tell people it’s sort of like Javadoc for databases.
There is one small problem, though, at least if you want to use it on
an Oracle database—the terminology from the SchemaSpy documentation
doesn’t exactly match up with Oracle terminology. Here’s an example
of the command to invoke SchemaSpy against an Oracle db:
java -jar schemaSpy.jar -t orathin -u _username_ -p _password_ -o schemaspy-output -cp _path-to-ojdbc14.jar_ -db _sid_ -host localhost -port 1521 -s _schema-name_
Back to flipping out…
BigMac Programmers. Moral of the story: Don’t do it–don’t be that guy. People hate that guy.
Back to flipping out…