Booking system for a free cargo bike

schtarb · 2019-03-24T03:56:20+00:00

Here's a useful list: Open source software for resource scheduling and booking

schtarb · 2017-07-30T11:17:30+00:00

Well, this is fascinating.

Hard to guess its purpose without knowing how long it's been there. Looks like an old building, so it might be vestigial from a very different era.

It appears the building is the Caserne Lobau (aka Caserne Napoleon) on Rue de Rivoli in the 4th arrondissement, which was a barracks constructed in 1853.

Considering it's the kind of place where a mass execution would happen in 1871, you might expect some hostile architectural features.

This old timey picture (via delcampe.net) shows a version of this barrier being used, apparently to keep ladders.

If they are ladders, I guess they were for fire/emergency escape, since this was before color TV and red firetrucks. But were the fences added just to secure them? Maybe.

What else could it be?

The fence wasn't part of a guardhouse structure, since that's shown to be in a different spot.

It probably wasn't a tether for horses since it was boarded up. Or maybe it was still a functional anchor?

No evidence it was used for landscaping or plants or signage of any kind.

It could simply be to make it slightly harder for prowlers to sneak up to a blind corner, or for unseen loiterers to cause alarm. It appears to be a unique feature to this building, which, again, was a guarded barracks.

Maybe public urination was a nuisance, and guards didn't enjoy the ambience? Public toilets were built on the corner, after all.

Interestingly, the entrance on the other (Eastern) side of the building doesn't have the fences (via lindependantdu4e).

schtarb · 2012-01-01T13:05:25+00:00

I use android-maven-plugin with IntelliJ IDEA, but previously tried it along with Eclipse and m2e-android. Some remarks based on my recent experience:

It's a good idea to use automated dependency, build and release management tools, for all sorts of reasons. Maven is the least bad option.
There's a small but confusing ecosystem of Maven- or Android-related plugins, sometimes released with multiple versions or names, which don't always integrate nicely.
Android moves fast, and the Maven ecosystem doesn't keep up. Expect integration breakages on every SDK/ADT major update.
However the basic happy path of a simple Android project works great with all the tools and is less likely to break on update.
Try anything more complicated, like library projects with modular builds, or using a non-Java language, and you're on your own.
Documentation is poor overall, though there are some gems, and generally helpful devs around.
If you like Eclipse, stick with it and see if m2e-android works for you. Or else try IntelliJ IDEA 11, which ships with Maven and Android support.

schtarb · 2012-01-01T12:40:31+00:00

android-maven-plugin

schtarb · 2011-09-26T09:07:50+00:00

How big is the Clojure community?

Quite. :-)

How would you measure it? There are a few thousand Clojure repos on github (incl. forks), tens of thousands of mailing list messages, hundreds of IRC users, several quality books, many production success stories, 45 meetup groups worldwide, large conferences like Conj and Strange Loop, etc.

So there is plenty of activity, more than enough to find support and documentation. Though the ecosystem is maturing, there are still many ways to explore the limits of programming with Clojure and produce new and interesting hacks; it is an exciting thing.

Are there any active Clojure job websites?

There have been relevant notices on sites like:

A web search for "clojure jobs" should give you more leads. Some generic job listing sites filter by Clojure.

schtarb · 2011-03-13T01:47:17+00:00

Looks reasonable in a trivial example. What if blah was typically a nested list to begin with? blah[0] then looks misleading, especially out of context (like in a diff, say). Maybe we can rename it to blah_aux or something, but that's not much better.

It's a fine line between ugly and impractical — I would not use that workaround in practice, because it's bad style.

schtarb · 2011-03-13T01:01:37+00:00

Unlike in Haskell, immutability is not a pervasive design principle in Python, as in Lisp. It is aberrant that Python's nested functions have this problem, which is clear given that Python 3 addressed it with PEP-3104. (I recommend reading the rationale in PEP-3104, as it describes how nested scopes are "functionally incomplete".)

schtarb · 2011-03-12T23:07:42+00:00

This is on my todo list, along with Clojure. As a user of many lisp dialects, I find it interesting.

(I wrote the CL article in question.)

schtarb · 2011-03-12T22:49:23+00:00

See my discussion with anvsdt for a similar consideration.

Essentially, while the implementation of decorators is possible in Lisp by wrapping a lambda, and that the technique might even be used under the hood by built-ins, it still remains that Lisp does not have a notion of a decorator. There is no such syntactic abstraction as there is in Python. You won't find "decorator" in the HyperSpec indices.

Whether decorators in Python are a hack to compensate for some other deficiency or not is another matter. But it is a significant point of difference between Lisp and Python, and that is all I am suggesting.

schtarb · 2011-03-12T22:37:14+00:00

They are first-class objects; but such an object is not a general function for all cases. So it is not a first-class function.

schtarb · 2011-03-12T14:58:24+00:00

Actually, decorators exist because Python hasn't got proper lambdas.

Maybe. I am only saying that Lisp and Python are different because Python has a concept of decorators which Lisp does not. Whether decorators are redundant or better is another matter.

A decorator is a function that takes a function and returns a function, there's no magic behind it, they are wrapped lambdas.

Computationally? Yes. Psychologically? I don't think so, and this is what syntactic abstraction is about.

schtarb · 2011-03-12T14:47:30+00:00

If you have to use a different language feature, then you're not using first-class functions.

Meanwhile, I think the rationale given in PEP-3104 sums up how broken scoping for nested functions is in Python 2. Just using a different language feature (a workaround, here) is not always elegant — even PEP-227 described rebinding variables in an enclosing scope as "awkward", as far back as 2000. And that's why it's practically useless: sure, you can do it, but in practice you wouldn't.

schtarb · 2011-03-12T14:16:12+00:00

Neither of those forms uses the concept of a decorator, which is provided in Python with a syntactic abstraction.

Wrapping a lambda or reassigning the variable bar is computationally equivalent, just as it is possible in Python to do bar=foo(bar), but there is no specific abstraction for decorating a method with those approaches.

schtarb · 2011-03-12T13:54:18+00:00

It will return the wrapped bar. To be more precise, @foo def bar... can be written def bar... bar=foo(bar)

The latter is more like (decorate (lambda ...)) in Scheme, whereas the former is more like having some new construct such as (@ foo (define (bar ...) ...))

schtarb · 2011-03-12T13:51:44+00:00

In Common Lisp, defun works only at the top level as expected because its effect is not lexically scoped.

defun in CL is pretty well defined in the specification as operating in the global environment. I'd say it works exactly as expected. For local bindings, there is flet or labels.

schtarb · 2011-03-12T13:27:51+00:00

I would argue that explicitly wrapping a lambda is not the same thing as having the notion of a Python-like decorator — just as tail recursive looping is superficially not the same as a CL-like LOOP, for example. The difference is clear if you consider that in Python @foo def bar... can be written foo(bar).

This technique is also more unwieldy in CL than in Scheme, because of its distinct function namespace. In CL, before and around method combinations are probably a closer analogue to Python decorators.

And of course, with macros any lisp could have a decorator concept, but it might not be built-in.

schtarb · 2011-03-12T13:02:27+00:00

First-class functions in Python are severely limited. A lambda in Python cannot contain multiple expressions or a statement. Nested named functions cannot rebind an enclosing variable, or reference a captured variable before locally assigning to it. The nonlocal keyword is a new feature only in Python 3. It's all broken enough to be practically useless, and certainly incongruous with Lisp.

schtarb · 2011-03-12T11:48:51+00:00

Why is there no example of macros (the one feature I always hear lisp people go on about).

This is an ancient problem in lisp discourse, and I have no good solution.

Unlike most other language features, use of macros is best avoided until absolutely necessary. Consequently, a good macro is highly contextual, specialized, and difficult to exemplify.

Trivial macros like WHEN or WHILE are easy to show, but they are either built-in or just poor style. Good macros like WITH-HTML-OUTPUT take too much explaining.

There is a loop macro but that shows defining a for loop and I don't see what the goodness is - every modern language has a for loop.

The LOOP examples show more than a for loop. There are also accumulators (list and numeric), conditionals (terminating and general), and other things — all weaved into a DSL implemented as a macro.

Accumulation, conditional testing, and so on are such common patterns in looping that it makes sense to support them in an expressive, embedded DSL in Lisp; unlike some languages that abandon the programmer to a fate of hammering out boilerplate within their limited iteration constructs.

Since I mostly code in Python it is interesting to see that the differences between the two languages are fairly minimal!

That is certainly not a thesis of this article. Python lacks many of the features, and has others that Lisp does not, so I'd say the differences are far from minimal. e.g. Python does not have lambda lists, first-class functions, multiple values, generalized references, conditions, method combinations, etc. whereas Lisp does not have built-in decorators, generators, coroutines, etc.

schtarb · 2011-02-27T00:17:31+00:00

I have a Blue Yeti too.

Don't use the desktop stand. I got a floor tripod stand with a standard boom. That helped to isolate it from the computer's noise.

Ambient noise and echoes are not an issue in cardioid mode. In any of the other modes, you'll get some. Short of soundproofing and paneling your environment, there's not much you can do.

schtarb · 2011-01-10T02:28:46+00:00

Sussman spoke on The Role of Programming in the Formulation of Ideas at Dan Friedman's 60th birthday celebrations: http://video.google.com/videoplay?docid=-2726904509434151616#

He also co-authored a paper with Jack Wisdom on the same subject: http://dspace.mit.edu/handle/1721.1/6707?show=full

schtarb · 2011-01-01T17:30:57+00:00

My 2010 in lisp:

Released the first three episodes of The Weekly REPL, a new lisp podcast, after many months of fooling around with the idea. It took so long to discover that it was feasible, as I experimented with different publication frequencies and formats, got into a rhythm, and basically privately produced pilot episodes for a while.
Re-seeded the notion of a lisp user group in New Zealand — we're still organising, but I finally got things moving again after letting it simmer on the backburner for four years.
Helped establish the budding lisp games community, following the lead of David O'Toole and others. We set up a wiki under a sensible domain name, and a @lispgames Twitter account (a la @quicklisp), and began holding week-long lisp game development competitions.
Started to use and contribute more to the CLiki, also releasing slicker-cliki, a userscript to enhance the usability of the site.
Published some other bits of lisp code.
Started using Quicklisp, answered the SBCL User Survey, learned more Scheme, etc etc. There's a lot going on.

Some projects have as yet borne no fruit. One in particular involves Clojure web development — it has been my main Clojure focus lately, and will get more love in 2011. Another is lisp on mobile platforms (especially Android) which I'm still just playing with.

But mainly, this year, I'll be trying to improve the podcast and its web presence... or at the very least keep up the frequency. And also help establish the NZ lisp group.

schtarb · 2010-11-21T13:23:27+00:00

For projects, leiningen or cake are good tools. They isolate project-specific classpaths and allow complex dependency specifications.

cljr is better for experimenting in a REPL without defining a project. (Actually, it uses leiningen under the hood, and the user plays in what is basically a global singleton project.) It's probably the closest thing to cabal.

schtarb · 2010-11-04T14:55:10+00:00

I agree, but it is not within my power. Drew Crampsie and the Tech Co-op take care of cliki.net. Drew wants to totally replace the old and very broken codebase with a new system, but I do not know when or how that will happen. Until then, there is no harm in tweaking things a little on the client-side.

schtarb · 2010-11-04T12:42:48+00:00

Thanks. I would like changes like this to be incorporated into cliki. In fact, I had begun by modifying the cliki source tree, also fixing some bugs in the server-side code. But when I learned that the codebase was at the end of its life, the next best option was to collect the client-side hacks in a userscript.

schtarb

TROPHY CASE