asmala

As an entrepreneur/freelancer, I don't have a lot of firsthand experience with Finnish labor laws, but my impression is that in practice such limitations apply mostly to manual laborers in bigger corporations.

Going by the book, the labor laws also allow for paid overtime (up to 2x salary), but that is limited no more 138h per 4 month period, or approximately 8h per week. And even then the employee can decline.

But that's if we go by the book...

Many of my friends working in specialist jobs across various industries regularly work overtime, often without compensation. I guess they could technically decline but if your plan is career progression that might not be a smart move outside unionized workforces.

An excellent point. Definitely something we should all keep in mind when promoting cutting edge tech choices.

That said, I don't think the matter is quite that straightforward where I come from; I would imagine Clojure dev head count in the whole of Finland is in the low double digits. If I were making business decisions involving future staffing, I would not feel confident I could replace the (hypothetical) only in-house Clojure dev in this job market.

Indeed, the developer base around Clojure and core libraries seems to have reached a critical mass so the continuity in that front is no longer a real concern.

However, I think the question was about projects built with Clojure, i.e. how to ensure that future developers in the company I work for will be able to continue where I left off? The global Clojure talent pool, while growing, is still on the small side (e.g. compared to even Ruby).

I tend to disagree. Unified solutions exist on the level of the core language and libs for both lazy evaluation and (pragmatic) functional purity, and the recent discussion around logic programming and pattern dispatch implementation is a beautiful example of how some really smart people are working together towards a common solution, instead of everyone rolling their own.

Heh, seems like you beat me to the punch by 2min both here and there.

My thoughts exactly. I posted a comment to that effect.

I feel the pain too. MuMaMo doesn't quite cut it for HTML + ERB.

That said, I never run into this when working with Clojure, since both the major templating solutions (Hiccup and Enlive) use only one language per file (Clojure and HTML, respectively) and I can keep my JS cleanly separate, barring the occasional Google Analytics snippet.

Correct on all accounts. You will still need to query the database at least for the parent object being rendered. The time saved is shaved off from the rendering time.

The general gist of it is that you store HTML snippets (e.g. a todo, a list containing, or a project containing lists) in some quick storage medium (in this case Memcached). Each snippet is stored under and accessed by a key that uniquely identifies the version saved (object type + ID + update timestamp). When a new version is cached, the old version stays in the cache, unused, until it is eventially dropped out by Memcached.

Now all you need to do is to ensure that whenever an object or its children change, you update their timestamp (the "touch" part), and if you make a changes to the code, you increment the version key for said cache piece. This way new requests will not hit old cached content.

Actually, to a large extent you can have access to the browser environment. See e.g. the ClojureScript One video and guide: http://www.clojurescriptone.com/.

The short answer is yes, ClojureScript has similar interop features for vanilla JS as Clojure for the JVM has for Java.

However, given that ClojureScript uses the Google Closure compiler to optimize production code, there are a few gotchas to be aware of. This article does a great job at explaining the details:

• http://lukevanderhart.com/2011/09/30/using-javascript-and-cl...

I can only present anecdotal evidence here but I do most of my freelance web dev work in Rails but turn to WordPress for web sites. I'm definitely more conversant in Ruby than PHP, but I think the ecosystem of the WordPress platform, plugins, and developer mindshare is a big deal for the projects' futures.

That said, I don't see myself using Wordless. Aside from my personal gripes with HAML, I have some concerns about breaking WordPress and PHP conventions. Will future developers be able to continue my work? Will plugins work as expected? How about page templates?

I did use SASS for a couple of themes and that worked out well enough, but I doubt I'll use it for future projects. Idiomatic code and tools are a bigger productivity boost both for myself and others.

EDIT: I can see a sweet spot for this in teams that work primarily with Ruby/Rails but want to leverage WordPress on a site they maintain in the long term.

Despite the down-votes, I think you're actually making a thought-provoking point here. As an EU citizen (Finnish) I, too, get the impression that the EU is an opaque entity making decisions that dispute national sovereignty of its member nations.

That said, I do mostly disagree with you in this particular case. As other commenters have pointed out, judiciary bodies are usually selected rather than elected (at least that is the case here in Finland). And I have not seen a single referendum on national legislation either, nor do I feel particularly satisfied with the level of accountability in the government.

So perhaps the shortcomings you raise are endemic in democracy globally, rather than ailments unique to EU?

Interesting and provocative question. I suppose that there's no way of objectively knowing if the changes are beneficial or even safe. (Come to think of it, how would we even define beneficial?)

That said, I find your caution perhaps unwarranted. Many other circumstances are known to cause changes in brain-structure, e.g. growing up bilingual, but I think it would be rather unwarranted to warn against childhood language learning on the basis of this.

Personally I am content with the proof of my own experience; the changes I see in my own psyche and mental performance are entirely positive.

The parent comment doesn't directly mention a directive, but the press release makes a reference to a directive according to which:

"[National] authorities must not adopt measures which would require an internet service provider to carry out general monitoring of the information that it transmits on its network."

Who'da thunk? Color me impressed.

Judging by the Court press release[1], it would seem that the unreasonable cost of filtering all P2P traffic for copyrighted material (yes, they actually asked for that) weighed heavily in the Belgian case. This would likely not be much of a factor when it comes to filtering a single domain, as mentioned in the UK case you linked to.

Still, the injunction by the EU court could well shift the balance even in cases where blocking is more technically feasible. Fingers crossed.

[1]: http://curia.europa.eu/jcms/upload/docs/application/pdf/2011...

This is, for once, an amazingly common sense decision, striking a good balance between IP protection, sensible business environment for the ISP, and personal freedom.

From the official press release[1]:

"The Court finds that, in adopting the injunction requiring Scarlet to install such a filtering system, the national court would not be respecting the requirement that a fair balance be struck between the right to intellectual property, on the one hand, and the freedom to conduct business, the right to protection of personal data and the right to receive or impart information, on the other."

I understand this isn't exactly revolutionary but amidst ACTA, SOPA, bailouts, and similar lunacy, this is a breath of fresh air and a glimmer of hope.

[1]: http://curia.europa.eu/jcms/upload/docs/application/pdf/2011...

EDIT: Formatting.

Your reasoning makes sense. There's a fair amount of recent research (see "meditation" via Google Scholar) indicating that meditation does indeed reduce cortisol levels and hence that could be one pathway for its effects.

That said, mounting scientific evidence indicates that meditation also changes our brain structure in ways that have AFAIK not been observed with exercise.

For me my own experience would seem to confirm this. The benefits I observe from meditation are both qualitatively and quantitatively different from what I gain from exercise (both aerobic and heavy weights).

Hmm, interesting. I can definitely see how age-related changes in the endocrine system could cause certain improvements that are similar to the effects of meditation. And being as it is that I'm still 29, that could be a factor.

But if I'm reading you correctly, you seem to imply that all the benefits mentioned could be explained away by age-related hormonal changes. I find that hard to believe based on the strong correlation I experience between active meditation practice and greatly increased mental ability. It is particularly noteworthy that I'm able to observe a clear decline in my capability to stay equanimous and focused whenever I have had longer periods away from practice, which should not be the case if we were dealing with mere age-related endocrine changes.

Did you do Ruby prior to Clojure? It's interesting to see you making the jump to Ruby right as I'm heading down the opposite direction on the Polyglot Interstate.

I jumped on the Ruby ride in mid-2007 and the libraries lacked polish; Rails had performance issues, RSpec its hiccups, and Cucumber was quite a frustrating experience, yet there seemed to be so much potential there that I staid on.

Now Clojure seems to be going through similar evolution. Libraries and frameworks like Enlive, Pinot, and core.logic display immense promise but the full stack feels still a bit wobbly.

But it is as you say; different situations and people need different tools. I still do most of my web dev client work with Ruby but I'm itching to try out Clojure for more complex data processing and, when the libraries mature, full-stack web development.

EDIT: Oh, and I'm with you on the stack traces... Good thing there's an update due in Clojure 1.4.

In that case Daniel Ingram's book Mastering the Core Teachings on the Buddha might be a good place to start.

I think it's also important not to throw away the baby with the bath water; just because the techniques are explained in an archaic language and seemingly inseparable from a traditionalist cultural tradition, doesn't mean they do not produce results. Still probably a good idea to start with something easily approachable so you can start to discern what's effective and what's just cultural cargo culting.

I think this understanding of meditation is somewhat mistaken. The techniques of single-pointed focusing are there to help us learn how to keep our minds still, not to narrow down our field of awareness (although one might do so during a practice session).

In fact, in most Buddhist traditions, the development of stillness (shamatha) goes hand-in-hand with the development of a widening awareness (vipashyana). Modern traditions like the mindfulness movement also seem to incorporate this tandem approach.

I think we need to differentiate between different types of wandering here. I think we can agree that letting our minds roam looking for creative solutions and creative questions is a good think. But it's less useful to have our minds stuck in a loop ("Peanut butter or jam? PB or J?" ad infinitum).

Anecdotal evidence based on four years of active meditation would in my case seem to indicate that the jittery loopiness lessens while the capacity for creative wandering increases.

I would conjencture that our minds are over-stimulated and hence unable settle down to make room for the truly novel.

The book is written by a Western MD and focuses heavily on results. It leans on the classical maps of the path of meditation from Burmese Theravada, a tradition that is about as stripped down and non-theistic as it gets. That said, the maps and some of the terms used may appear somewhat archaic to a modern reader.

Great, I was wondering what would be an idiomatic way of solving this in Clojure.

Given the addition of core.logic into Clojure 1.3.0, one could even skip the implementation of cKanren. Although to be honest I'm not altogether sure how core.logic measures up to cKanren.

Thanks for the analysis. Sounds interesting.

Yes, I'm less interested in quick scaffolding, be it via code generation or ready components, but clean reusable view components does sound appealing.

Rails helpers are great for some things but more complex cases like custom form builders can get ugly (no, formtastic is not always the answer). Will give Hobo a look next time.

I'm genuinely curious to know what is the sweet spot for these admin interfaces and Hobo for that matter?

I find prototyping plenty fast with vanilla Rails, a few backend plugins, and Twitter Bootstrap. And on the far end of the scale, my experience is that larger projects require an amount of customization that does not easily fit into the auto-admin paradigm.

I think you're absolutely right that functional programming is particularly suited for things like mathematics. But you can also enjoy many of the benefits of a functional approach by moving most of the complexity into purely functional, well, functions and leaving the state-modifying code fairly simple. For a good pragmatic example of this approach, check out the snake game in Programming Clojure v2 from Pragmatic Programmers.

Coming from Ruby this approach was a bit mind-boggling at first, but even with my fairly limited Clojure exposure (or should that be expojure?) I've come to appreciate how easy pure functions are to test and to reason about.

I've started using Clojure after many years of Ruby and I have to say the parentheses are a non-issue. Emacs and many IDEs automatically balance the parens for you (see e.g. paredit). Once your eyes learn to ignore the bracket soup, the code starts looking an awful lot like Python (cmp. Emacs Lisp indention with Python semantic indention).

Both Safari and Chrome seem to open the file fine for me. Tags in the source code indicate that it was at least partly made with Inkscape.