better community docs: getting started
Stuart Halloway
Aaron Cohen
I am working through a few of the pages on clojure.org with two goals:(1) remove or fix anything that is outdated or incorrect
Stuart Halloway
I really like how minimal that is now.I am working through a few of the pages on clojure.org with two goals:(1) remove or fix anything that is outdated or incorrectA quick suggestion: shouldn't the Copyright date be updated too?
Phil Hagelberg
> As a first pass, I have trimmed http://clojure.org/getting_started, and quite
> clearly linked out to http://dev.clojure.org/display/doc/Getting+Started for
> advice on tools, IDEs, etc.
That's a huge improvement; glad to see it finally getting some attention.
I have heard that the single-dot syntax is deprecated for use outside
macro writing. So this sample should probably be replaced:
(. javax.swing.JOptionPane (showMessageDialog nil "Hello World"))
The modern equivalent would be:
(javax.swing.JOptionPane/showMessageDialog nil "Hello World")
-Phil
Alan Malloy
> Stuart Halloway <stuart.hallo...@gmail.com> writes:
> > As a first pass, I have trimmedhttp://clojure.org/getting_started, and quite
> > advice on tools, IDEs, etc.
>
> That's a huge improvement; glad to see it finally getting some attention.
>
> I have heard that the single-dot syntax is deprecated for use outside
> macro writing. So this sample should probably be replaced:
>
> (. javax.swing.JOptionPane (showMessageDialog nil "Hello World"))
>
> The modern equivalent would be:
>
> (javax.swing.JOptionPane/showMessageDialog nil "Hello World")
arg methods: (. foo (x)) vs (. foo x) - iirc (.x foo) can have trouble
deciding which one to expand into.
Sean Corfield
<stuart....@gmail.com> wrote:
> I am working through a few of the pages on clojure.org with two goals:
> (1) remove or fix anything that is outdated or incorrect
> (2) move to the community site (dev.clojure.org) things that should be
> maintained by the community.
> As a first pass, I have trimmed http://clojure.org/getting_started, and
> quite clearly linked out
> to http://dev.clojure.org/display/doc/Getting+Started for advice on tools,
> IDEs, etc.
Thank you!
A question about the packaging of the "Developer Releases" on the
downloads page: in the 1.2.1 ZIP, there's clojure.jar exactly as
mentioned on the getting_started page; in the 1.3.0 Beta 1 ZIP,
there's clojure-1.3.0-beta1.jar and clojure-1.3.0-beta1-slim.jar - is
that just an artifact of the interim builds? (and is the assumption
that folks reading getting_started aren't likely to try non-stable
releases?)
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Stuart Halloway
I am working through a few of the pages on clojure.org with two goals:(1) remove or fix anything that is outdated or incorrect(2) move to the community site (dev.clojure.org) things that should bemaintained by the community.As a first pass, I have trimmed http://clojure.org/getting_started, andquite clearly linked outto http://dev.clojure.org/display/doc/Getting+Started for advice on tools,IDEs, etc.
Thank you!
A question about the packaging of the "Developer Releases" on the
downloads page: in the 1.2.1 ZIP, there's clojure.jar exactly as
mentioned on the getting_started page; in the 1.3.0 Beta 1 ZIP,
there's clojure-1.3.0-beta1.jar and clojure-1.3.0-beta1-slim.jar - is
that just an artifact of the interim builds? (and is the assumption
that folks reading getting_started aren't likely to try non-stable
releases?)
Sergey Didenko
1) It's misleading that some links in the left pane are underlined ("API", "Recent changes", "Libraries", "Community") while others are not.
2) It's better to have dates for the news. May be in small font no avoid clutter. It is not obvious that "ClojureScript" happened recently. (Spelling out the month, or using month abbreviations, not numbers.)
3) The most voted Clojure question on stackoverflow is http://stackoverflow.com/questions/1314732/scala-vs-groovy-vs-clojure, so it would be good to have short comparison(s) at least with Scala, preferably in the form of the bulleted list. May be inline or on a separate page.
4) Other highly voted Clojure questions are related to "tutorials, books", "advantages of Lisp", "web programming" and "real world usage" so it would be good to have these topics linked from the main pane.
5) The main pane of the main page is good and a quite concise introductional text but it lacks scannabillity. It would be good to rewrite it to use more bulleted lists.
6) There should be mentioning that Clojure has commercial support
7) It's not obvious that "Rationale" and "On State and Identity" is clickable because they look like unclickable category headers without items. What can be done? May be make the left pane links blue? Or at least put the most important links in the separate category?
8) It's quite bad that visited links have the same color as unvisited.
9) "Contrib Libraries" link is not clear. It's better to be renamed. I have just realized that it comes from the word "contribute" . That is after 1.5 years of Clojure experience. ( :) don't call me stupid, it's usability)
10) "Dev" link is not clear. When should I use it? What is good for?
11) After 1.5 years of using clojure.org I have just realized there is a search bar in the right upper corner. Probably it would be better to make it stand out of the navigation - the closest link pane. Also it's better to make it wider.
12) It's quite bad that the right upper link pane looks like a banner. What about making it as a horizontal menu and visually distinct the search leaving it in the right upper area?
"Group items in the navigation area so that similar items are next to each other."
Just quoting http://www.useit.com/homepageusability/guidelines.html :
14) "Include a tag line that explicitly summarizes what the site or company does."
15) "Don't include "homepage" in the title. This adds verbiage without value."
16) "Communicating Information About Your Company" - there should be at least the link to clojure.com, may be named "Who We Are/ Commercial Support"
nchurch
> The community getting started page could be much better. In particular, people have opined that there should be a clear, no-choices-
> to-make path "For Newbies" section.Help welcome!
How do people want to see Getting Started on dev.clojure organized?
Right now there are 12 (!) headings right under Getting Started. How
about reducing it to four:
1) Getting Clojure
2) Editing Clojure
3) Using Clojure
4) Tools
This is the order in which newcomers need to do things.
Under 1) would be a guide for setting up Lein with the Lein REPL. At
the end would be a list of links for alternative options.
Under 2) would be a guide for setting up Emacs (immediately divided
into Mac, Windows, Linux). At the end would be a list of alternative
options: Eclipse, Netbeans, IntelliJ, etc.
Under 3), guides to setting up web programming (+ ClojureScript now?),
Incanter, and any other killer apps---but not an infinite list by any
means. Less common applications again would be relegated to links
(which may link within dev.clojure of course).
Under 4), anything that doesn't fit under the first three: build tools
and debuggers with a standard option for each, and once again
alternative choices at the end. (Lein has of course already been
covered.)
The basic idea is to make some choices, and tuck all the extra
information out of the top level. Perhaps there could also be a link
at the top for an index to everything, as well.
If we really wanted to be radically open, we could include with each
option some of the data from the recent State of Clojure survey,
describing what proportion of the community actually use the option in
question. This is exactly the kind of thing newcomers want to know,
and have trouble finding. Perhaps it is impolitic to be so open about
it, but....
I don't know how complicated this would be to do, but is there any way
to make a kind of community scratch space for the documentation? It
would be nice to try out and work on reorganized and rewritten
documentation before it is linked to directly from clojure.org. Just
a thought.
N.
Ken Wesson
>
>> The community getting started page could be much better. In particular, people have opined that there should be a clear, no-choices-
>> to-make path "For Newbies" section.Help welcome!
>
> I just got edit privileges on dev.clojure and am eager work on it.
> How do people want to see Getting Started on dev.clojure organized?
> Right now there are 12 (!) headings right under Getting Started. How
> about reducing it to four:
>
> 1) Getting Clojure
> 2) Editing Clojure
> 3) Using Clojure
> 4) Tools
>
> This is the order in which newcomers need to do things.
>
> Under 1) would be a guide for setting up Lein with the Lein REPL. At
> the end would be a list of links for alternative options.
> Under 2) would be a guide for setting up Emacs (immediately divided
> into Mac, Windows, Linux). At the end would be a list of alternative
> options: Eclipse, Netbeans, IntelliJ, etc.
No.
No, no, no, no, no!
That will kill 90% of the people that try it as potential future
Clojurians. They'll install emacs, try to use it, throw keyboards out
windows and mice through monitors, say "What? Huh? WTF is this shit!?
AAAAAAGH!" and then run out of standard curse words and resort to
"sweet crobdonker!". And then go play around in Java or C++ and curse
your name every morning until their dying day.
How about making the main suggestion be clooj instead, with emacs,
eclipse, netbeans in the list of alternative options? :)
> Under 3), guides to setting up web programming (+ ClojureScript now?),
> Incanter, and any other killer apps---but not an infinite list by any
> means. Less common applications again would be relegated to links
> (which may link within dev.clojure of course).
Maybe start with helloworld? :)
--
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.
László Török
+1, as I went through the same process. Emacs should be the option for the brave ones who already wrote their first helloworld.clj.
sent from my mobile device
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
Ambrose Bonnaire-Sergeant
How about making the main suggestion be clooj instead, with emacs,
eclipse, netbeans in the list of alternative options? :)
pmbauer
Sean Corfield
>> Under 2) would be a guide for setting up Emacs (immediately divided
>> into Mac, Windows, Linux). At the end would be a list of alternative
>> options: Eclipse, Netbeans, IntelliJ, etc.
>
> No.
>
> No, no, no, no, no!
>
> That will kill 90% of the people that try it as potential future
> Clojurians. They'll install emacs, try to use it, throw keyboards out
> windows and mice through monitors, say "What? Huh? WTF is this shit!?
For once I'm in complete agreement with Ken - trying to push Emacs as
the recommended editor for Clojure would be a disaster!
We need to be very clear that pretty much whatever IDE / editor you
use today can be used for Clojure.
Having the Getting Clojure section focus on Leiningen to handle
dependencies, run a REPL and run Clojure scripts (with a -main
function) is a great way to get people started.
I do not think we should attempt a recommended IDE (not even Clooj).
We should offer a path for all existing IDEs / editors. If you're an
Eclipse user, try CCW. If you're an existing Emacs user, here's how to
configure it for Clojure. If you're a TextMate user, here's the
Clojure bundle. And so on. Use an editor not listed here? Try Clooj
(i.e., use this as a simple catch-all if we haven't covered what you
already used today).
Sean
pmbauer
I do not think we should attempt a recommended IDE (not even Clooj).
We should offer a path for all existing IDEs / editors.
Use an editor not listed here? Try Clooj
(i.e., use this as a simple catch-all if we haven't covered what you
already used today).
Ken Wesson
This URL is somewhat unfortunate. For some reason, both
https://github.com/downloads/arthuredelstein/clooj/
and
https://github.com/downloads/arthuredelstein/
give 404 pages, so it's not possible to use ".. walking" to get to the
"parent node" -- i.e., Edelstein's Clooj page as a whole, and then
Edelstein's everything-including-Clooj page. That's poor URL design,
but it's probably not Edelstein's fault, but rather github's.
I'd argue that this is another reason for having separate sites for
projects, sites hosted away from places like sourceforge and github
(but linking to those); a generic web host will let you use a better
URL structure so people who, say, only see your download link posted
somewhere and want to read more before committing to downloading
anything can just chop the last segment off your URL and read away.
Ambrose Bonnaire-Sergeant
cljneo
Mark Derricutt
Sean Corfield
> But think of the casual dev wanting to know what Clojure and a typical
> Clojure toolchain can do for her ASAP.
I find it hard to imagine a "casual dev" that doesn't already have a
preferred editor - but I'm certainly not averse to promoting Clooj to
folks who don't have a strong IDE predilection.
> Most Java devs have never used a repl-aware edit buffer, something most of
> us take for granted.
Most Java devs have a strong affinity for a specific IDE tho'...
> That's why I would give Clooj some prominence rather than burying it at the
> bottom of the decision tree.
Well, then put it at the top with the tag line "If you don't have a
strong affinity for a specific IDE or editor, why not try Clooj which
is a simple, lightweight editor focused on Clojure? Otherwise see the
options below for adding Clojure support to your favorite IDE..."
Mark Derricutt
Michael Wood
> On Sun, Jul 24, 2011 at 11:51 PM, pmbauer <paul.mich...@gmail.com> wrote:
>> That's why I would give Clooj some prominence rather than burying it at the
>> bottom of the decision tree.
>
> Well, then put it at the top with the tag line "If you don't have a
> strong affinity for a specific IDE or editor, why not try Clooj which
> is a simple, lightweight editor focused on Clojure? Otherwise see the
> options below for adding Clojure support to your favorite IDE..."
+1
--
Michael Wood <esio...@gmail.com>
abp
Mark Derricutt
Lee Spector
+1 with a little more justification from one perspective:
As a relative newbie (to Clojure and especially the Java ecosystem, but not to Lisp) and as a teacher (I have been and plan to continue teaching Clojure to undergrads) I have pretty strong opinions on this.
What I hope for in a "getting started" page/process is something that will allow people with little/no experience with any existing programming environment to install and begin to use a Clojure environment that is "not toy" in the sense that it includes both a reasonable Lisp code editor (minimally: bracket matching and language-aware auto-reindenting) and a reasonable way to grow a project to include multiple files and libraries without learning a lot about classpaths and miscellaneous other Java tools (which probably means leiningen or cake).
All of the existing full IDEs involve a lot of complexity that is bewildering to newcomers, either in installation/configuration, in use, in dealing with libraries/classpaths in the community-normed way, or in some combination of these.
Until very recently I thought that the way forward on this was to push one or more of the existing IDEs in more newbie-friendly directions, e.g. by getting CCW to play more nicely with leiningen, or to provide more newbie-friendly installation/configuration scripts/instructions for emacs-based environments. And several people in the community have recently made contributions recently that helped with these things in significant ways. I thank them all! But from my perspective there was not yet a really complete, satisfying solution.
Now along comes clooj. This has, to my mind, really leapfrogged over all of the other approaches in its potential to provide a really smooth entry ramp into Clojure coding for total novices -- AND (and this conjunction is quite important for me personally) also for seasoned non-Java-ecosystem programmers who want to use Clojure for serious work without mastering Java ecosystem tools. It provides trivial download/installation, a simple but sufficient editing environment and, I think (although I haven't yet worked with this) smooth integration with a leiningen-based or cake-based workflow.
Related issues are being discussed on the clooj mailing list (cl...@googlegroups.com), and I think that with a few more enhancements to the environment and especially to the getting started instructions (focusing on integrated clooj+lein/cake workflow, and providing simple instructions for 1: hello world, 2: including and using a library, and 3: building an application) this will be a really excellent environment for newcomers.
Assuming that clooj+lein/cake continues to improve as rapidly as it has over the last week, I too would advocate this being the first item listed on a Clojure getting started page.
-Lee
nchurch
> eclipse, netbeans in the list of alternative options? :)
on July 25th! Things move at lightspeed around here....
The one thing I want to say about Emacs is that at some point we might
want to tell newcomers that it is as close to a standard dev
environment for experienced Clojure programmers as there is (along
with all the necessary warnings about its difficulties). I've been
using Emacs for such a long time I've forgotten how horrible it can be
though----hence my apparent missrec...
(If Aquamacs consistently worked with Clojure, Emacs would not be as
bad of a problem on Mac at least. Some people do seem to get it
working----Rich Hickey, for instance. But I trust he has better
things to do with his time than write Getting Started guides for
Aquamacs.)
I just found out that I don't have permission on dev.clojure to move
pages (which would be needed to reorganize docs obviously). Does
anyone around here have that permission and want to do it, or shall I
go about and try to get the permission? Maybe someone with more
experience and having been on dev.clojure longer would be preferred,
but I feel pretty confident I can do \this at least.... = )
Other than not recommending Emacs, do people think that the overall
organization I suggested is a good idea? I should reiterate that
other information needs to be accessible; for now I'd just like to see
us not presenting people with twelve options as their first view of
Getting Started, all in link form (after at least two clickthroughs
from clojure.org, typically). Of course people are capable of
digesting the information in the current form, but it takes more time
and mindshare----and why should it?
Sergey Didenko
Sean Corfield
> Other than not recommending Emacs, do people think that the overall
> organization I suggested is a good idea?
Yes.
> for now I'd just like to see
> us not presenting people with twelve options as their first view of
> Getting Started, all in link form
Agreed.
Bill Robertson
I think the "clear no options getting started path" should include a
tutorial and focus on the repl and using a *generic* text editor. A
downloadable archive file (zip and tar) that included things like
jline, clojure jars, and some scripts (.sh *and* .bat) to just start
it would allow somebody to party right away.
This package should include a basic tutorial on how to use the repl,
including
* The basics of the repl -> simple expressions, functions, simple Java
interaction
* a repl cheat sheet
* Any nifty (extra) features bundled with it, e.g: how to javadoc
* Explain why a repl is beneficial
* Some higher level strategies for benefiting from the repl
Then include zero or more tutorials on clojure itself with the
package. Zero might be best, and just put the basic tutorials online.
This package should be stable. Don't change it willy-nilly. Don't fix
it unless its broken. Don't upgrade for the sake of upgrading. If
people want to move on to Emacs and swank or slime or whatever, or an
ide or start using a build tool, then they will seek those out, but
right now that's all a lot of noise that gets in the way of starting
with the language because there's so much flux in the state of
tooling, which is not a bad thing for the experienced, but it leads to
tail chasing on the part of noob.
If its stable, then other people can write other tutorials/guides that
build off of it w/o worrying about them becoming obsolete.
I think I could put together a zip that had a basic environment, but I
know I don't know enough to know what else belongs in it.
Thanks,
Bill
On Jul 22, 5:22 pm, Stuart Halloway <stuart.hallo...@gmail.com> wrote:
> I am working through a few of the pages on clojure.org with two goals:
>
> (1) remove or fix anything that is outdated or incorrect
>
> (2) move to the community site (dev.clojure.org) things that should be maintained by the community.
>
>
> The community getting started page could be much better. In particular, people have opined that there should be a clear, no-choices-to-make path "For Newbies" section.Help welcome!
>
> Stu
>
> Stuart Halloway
> Clojure/corehttp://clojure.com
Stefan Kamphausen
may I humbly suggest to come up with the most common user stories and put links to pages for those users right after the introductory paragraph. The typical scenarios will probably combine a few things, e.g. setting up maven and CCW. Further down the page the links to the detailed topics may be put.
Suggestions for user stories
* You just heard about Clojure and want to try a few things without getting into real projects. Maybe you bought a book on Clojure and want to follow along the examples
Leads to
- Some very easy setup, maybe lein repl or clojure.main with JLine or a more one-clickish setup (mind the people with low bandwith though)
- An intro to REPL
- I'd love to point the readers of our book to that options for the second edition ;-)
* You are a Java programmer and use Eclipse and Maven for your current projects. You'd like to setup this environment to be able to create stand-alone Clojure projects to test this new programming language. Later you will be able to combine Clojure and Java yourself.
Leads to
- Counterclockwise
- ... (I am not from that groups, don't know what to put there)
* You are just the Java programmer from the previous item, but you prefer Netbeans or IntelliJ?
- Link to Enclojure-Intro
- Link to La Clojure setup
* You come from older Lisps and use Emacs and SLIME. You view Clojure as an interesting new Lisp, but want to try it even more, because it may allow you to create Java programms with fewer LoC
Leads to:
- Leiningingen, swank-clojure, gotchas with SLIME installation and finally, M-x slime-connect.
- Some explanations on what Maven is all about, how ~/.m2 is a local repo, the CLASSPATH story and the like
... all that being said, I think the current starting page on dev.clojure.org is rather good. :-)
Regards,
Stefan
uMany
But I want to help translating to Spanish.
If you tell me where can I find instructions to do it I will with
pleasure.
By the way, I've been fighting with Emacs/Clojure and everything else.
It has been frustrating but I've learn a lot and I like to learn. So
for me, I don't give up. I wont give up. I just want to program in
Clojure no matter what just because I like it.
Manuel
nchurch
http://dev.clojure.org/display/doc/getting+started+with+Clooj
If this looks good to people, I'll try to get permission to reorganize
the Getting Started docs a little.
Laurent PETIT
Ken Wesson
> Sorry to make things look different than the apparent consensus of the
> participants to this thread, but isn't it a little bit too prematurate to
> put that pressure on Clooj ?
> I understand the desire to have Clooj for "filling the gap".
> But my question is : is it ready yet ?
From what I've heard, the only thing missing I'd consider really
important is a way to auto-reindent one or more lines. (Others might
consider syntax highlighting to be crucial as well; I don't know.)
Lee Spector
On Jul 29, 2011, at 5:39 PM, Ken Wesson wrote:
> On Fri, Jul 29, 2011 at 5:33 PM, Laurent PETIT <lauren...@gmail.com> wrote:
>> Sorry to make things look different than the apparent consensus of the
>> participants to this thread, but isn't it a little bit too prematurate to
>> put that pressure on Clooj ?
>> I understand the desire to have Clooj for "filling the gap".
>> But my question is : is it ready yet ?
>
> From what I've heard, the only thing missing I'd consider really
> important is a way to auto-reindent one or more lines. (Others might
> consider syntax highlighting to be crucial as well; I don't know.)
Considering how very young it is, it's probably not realistic to consider it ready quite yet.
That said, I'm a clooj cheerleader because I think that it, when combined with lein or cake, hits the ease/completeness sweet spot in a way that no other tool currently does.
THAT said, I've just begun to try to work in it seriously, and I just sent three messages raising new issues to the clooj list.
*THAT* said, the improvements have been coming fast, and particularly if others pitch in I think it could be "real good" "real soon".
-Lee
Stefan Kamphausen
IMHO there are three types of people coming to Clojure
- Java Programmers
- Old-school lispers
- all the other, who just want to try (and possibly follow the examples in a tutorial or book)
To me it seems important to get the common misunderstandings and problems out of the way for groups 1 and 2. The Java-programmers will need more help to get going with REPL-oriented programming an to integrate Clojure in their (existing) Java-programs, whereas the old-school lispers (OSPs? ;-) need a hand getting around in the Java ecosystem (mvn, jar, war, classpath, etc).
Kind regards,
Stefan
nchurch
> But my question is : is it ready yet ?
fine. I added a sentence about its newness just so people would be
aware of it...if the author prefers no tutorial so far, then of course
it should be taken down.
Laurent PETIT
As a quick and simple way to get a REPL and edit code it seems to work
> But my question is : is it ready yet ?
fine. I added a sentence about its newness just so people would be
aware of it...
if the author prefers no tutorial so far, then of course
it should be taken down.
--
Devin Walters
inc
IMHO there are three types of people coming to Clojure
- Java Programmers
- Old-school lispers
- all the other, who just want to try (and possibly follow the examples in a tutorial or book)
For the first two groups the obstacles and interest can probably be sorted out and the third groups just needs some basic setup, which may be presented using Clooj (or lein repl or a virtual machine download or even just clojure.main, or ...).
To me it seems important to get the common misunderstandings and problems out of the way for groups 1 and 2. The Java-programmers will need more help to get going with REPL-oriented programming an to integrate Clojure in their (existing) Java-programs, whereas the old-school lispers (OSPs? ;-) need a hand getting around in the Java ecosystem (mvn, jar, war, classpath, etc).
Kind regards,
Stefan
Stefan Kamphausen
On Thursday, August 4, 2011 5:14:19 AM UTC+2, Devin Walters (devn) wrote:
On Jul 29, 2011, at 7:30 PM, Stefan Kamphausen wrote:inc
IMHO there are three types of people coming to Clojure
- Java Programmers
- Old-school lispers
- all the other, who just want to try (and possibly follow the examples in a tutorial or book)
[...]
To me it seems important to get the common misunderstandings and problems out of the way for groups 1 and 2. The Java-programmers will need more help to get going with REPL-oriented programming an to integrate Clojure in their (existing) Java-programs, whereas the old-school lispers (OSPs? ;-) need a hand getting around in the Java ecosystem (mvn, jar, war, classpath, etc).
The "other" category you mentioned needs just as much help with REPL-oriented programming. A solid editor-agnostic screencast on this style of development would do quite a bit of good, I think. The rhythm can be a bit fast for beginners when they don't see how you hit a hotkey to re-evaluate a form in your source in the REPL, for instance.
Alas, if only one had more time...
I still remember the first SLIME screencast which was a real eye-opener [1]. It's just, that as a beginner you want to see how the more experienced really work. I had the luck an pleasure to spend a few days with Edi Weitz when I finally started with CL after years of Elisp. A screencast would be the next closest thing, I guess.
Cheers,
Stefan
Footnotes:
[1] slime.mov by Marco Barringer; seems to be mostly gone from the usual places.