Re: How to integrate front-end designers into Clojure/Ring/Jetty workflow?

[Erik Bakstad]

Another tip, I have extracted the support for nesting html templates using 
enlive from http://clojurescriptone.com. What that gives you is the support 
for "sandboxing" all the templates under a given url i.e templates/* so 
that the designers can work with HTML-only but in a DRY fashion.

What I mean by that is that you don't have to repeat including resources 
like CSS, scripts, headers/footers etc. in all your templates.

It's a ring middleware: https://github.com/ebaxt/enlive-partials

kl. 00:28:02 UTC+1 fredag 11. januar 2013 skrev larry google groups 
følgende:
>
>
> So, I am working on a web app that is buillt with Clojure/Ring/Jetty 
> and, importantly, Enlive. My directory structure is like this: 
>
> /resources 
> /public 
> /css 
> /js 
> /img 
> /templates 
>
> /src 
> /discovery 
> core.clj 
>
>
> The great thing about Enlive is that the templates are pure HTML. This 
> makes it easier for graphic designers and frontenders to work with 
> them directly. I am working with a designer and frontend developer, 
> who  have absolute power over the stuff going into the /resources 
> folder. 
>
> I have 2 questions: 
>
> 1.) In my routes, I am using (wrap-resource) instead of (wrap-file). 
> Is there any way to enable live updates, so that if the designer 
> changes the images in /resources/public/img, they can then see the 
> changed images when looking at the app in their browser? Right now I 
> have to recompile the app and restart it for change to be visible to 
> the designer. 
>
> 2.) I notice that if a change is made in /resources, but no change is 
> made anywhere else, then if I run "lein compile" nothing happens. Is 
> there a way to force lein to compile? 
>
> I have little insight about how to build a multiperson workflow while 
> doing Clojure development. One thought I had: I could automate the re- 
> build of the app, and give the designer an easy way to trigger that 
> rebuild (click a button in Jenkins -- easy enough because we rely on 
> Jenkins for all of our builds, and the interface is simple enough for 
> non-programmers to handle). But I would like to hear what other people 
> do. 
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure web server benchmarks

[Peter Taoussanis]

>
> This is very interesting. Have you tried running the Ring Jetty adapter 
> with a larger thread pool? It's set lower than the default so as not to 
> overload cloud hosts like Heroku.
>

You mean the :max-threads? No, I left it at the default (50, if I recall 
correctly?). I'll try bump it next time I run the benchmarks (probably next 
week). I'm just on a dual core though, so I wouldn't expect any major 
changes. As it is, I think the standard Jetty adapter performs remarkably 
well.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Leiningen profiles for dev and prod dbs and other settings

[Phil Hagelberg]

Jonathon McKitrick writes:

> I just read about leiningen profiles, and I'm trying to figure out how to 
> access those settings within my code for db selection.
>
> What are the canonical ways to do this?

Two ways: one is to use .clj data files on the classpath and take
advantage of the fact that different profiles put different resources
directories on the classpath. This is the approach taken by Carica
(https://github.com/sonian/carica) and works great if you have complex
config with nested values.

The other approach is to use environment variables; the best tool for
that is Environ: https://github.com/weavejester/environ

-Phil


pgp6PTnriGgt5.pgp
Description: PGP signature

ANN: fipp - Fast Idiomatic Pretty-Printer

[Brandon Bloom]

Hi all,

I decided to create a new pretty printer in the spirit of "Data All The 
Things!" And it's fast too!

Fipp, the Fast Idiomatic Pretty-Printer for Clojure, is a pretty printer 
with linear runtime and bounded space requirements. Unlike clojure.pprint's 
side-effectual API, Fipp is configured by pretty print documents that are 
similar to Hiccup HTML templates. It's based on some fancy pants research 
pretty printers from the Haskell world.

You can see my implementation and lots more notes 
at https://github.com/brandonbloom/fipp

Let me know what you guys think.

Cheers,
Brandon

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Tim Cross]

A good thought/discussion provoking post, thanks.

I find myself between two camps here. On one side and coming from the 
position of both learning Clojure and coming back to web development after 
a long period of mainly working on large backend database apps, the 
suggestion of a nicely bundled and complete clojure web framework is 
appealing. 

On the other hand, having been required to become familiar with some 
frameworks, such as spring, being forced to search through large quantities 
of documentation and then finding 80% of what it offered was not relevant 
to what I needed for my application, I'm far less enthusiastic regarding 
complete frameworks. 

I think there may be two different requirements here which need addressing. 
The first is for those, often new to clojure, who would like to get up and 
running fast. They have a new idea to start developing and don't want to 
spend hours evaluating lots of different, but outwardly similar libraries - 
especially as they may not yet have the knowledge to easily make such 
decisions. The second requirement is for more experienced or knowledgable 
devs or those who have a well defined design who just need to know which 
specific libraries to use. I suspect that as you gain web dev experience 
with clojure, you will move more twards the second group. If this is the 
case, complete frameworks are likely to be of only limited benefit while 
you become familiar and experienced. This may asiist adoption to some 
degree. However, as individuals become more experenced and accustomed to a 
more clojure style philosophy of fewer and more specific libraries for a 
task, they will likely move away from the framework. Unfortunately, this 
may have a detremental impact on the maintenance of such a framework as it 
may be difficult to attract or retain interest as experience grows. 

I think possibly the best way to assist adoption and also provide valuable 
content for more experienced developers are things like case studies, 
examples and reviews which cover the various libraries and their use. 
Example dependency templates etc may also be useful. Blogs such as yours, 
where you document your experiences and give examples are very valuable. 
Articles like the hooroku one or Andrew Brehaut's one are extremely useful 
and valuable. Possibly what would be very valuable would be one 
consolidated place where all this valuable information could be found. 
Someone interested in clojure and web development could just go to a single 
place and find a majority of the good articles, case studies, overviews and 
evaluation of web dev relevant libraries and techniques/idioms for Clojure. 
Ideally, this would just be part of another well know Clojure documentation 
site. 

Tim



On Saturday, January 12, 2013 3:52:05 AM UTC+11, Paul Umbers wrote:
>
> I've been experimenting with Clojure web services recently, and posting 
> the work on GitHub  and my 
> blog
> .
>
> When putting this test app together, it occurred to me that most other 
> languages have a full-stack API available which makes life easier when it 
> comes to making decisions about which libraries/APIs/frameworks to use. It 
> also reduces the possibility of "impedance mismatch" between the libraries. 
> For Java, you can use Spring (or any one of a dozen or more other popular 
> frameworks), for Scala there's Typesafe, and so on. Clojure has Compojure, 
> Ring, several logging, validation and database libraries, and they can be 
> used together but they don't constitute a coordinated full stack - and that 
> creates issues.
>
> For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and 
> not the latest version of Ring (1.1.6) which has significantly better util 
> functions available - but I can't use them until Compojure catches up. By 
> the time you add logging, validation, data access, etc the odds of a 
> mismatch between these libraries goes up dramatically.
>
> This is a concern, because these mismatches must be worked around in *my*code 
> and are likely to break as the libraries are upgraded in future 
> versions. So, I'm having to spend my time maintaining what are essentially 
> "patches" for third-party libraries just so that they work together.
>
> Now, it may not be the best decision to try to put together a true 
> full-stack framework from scratch, but is it worth choosing a bunch of 
> existing frameworks and coordinating their releases - in much the same way 
> as Eclipse coordinates plugin releases for major releases - so that putting 
> together a full-stack app becomes easier?
>
> Projects taking part in the "meta-project" will work together to harmonize 
> their functionality & APIs, and coordinate their development cycles & 
> releases so that the meta-framework remains consistent and easily usable.
>
> Is this another barrier to adoption the Clojure community can remove? Is 
> this even a

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Sean Corfield]

You could just do:

lein new fw1 myapp
cd myapp
lein run

assuming you have nothing running on port 8080 already - otherwise:

PORT=8123 lein run

Noir also has a simple Leiningen template (although Noir is deprecated now):

lein new noir noirapp
cd noirapp
lein run

(same caveat applies regarding ports)

On Fri, Jan 11, 2013 at 2:56 PM, Eric MacAdie  wrote:
> Thanks for the info. I will look this over, and perhaps finally build my
> world-changing Clojure app. Or maybe just "Hello World."
>
> - Eric MacAdie
>
>
> On Fri, Jan 11, 2013 at 3:58 PM, Marko Topolnik 
> wrote:
>>
>> There's a pretty good page at heroku. There's also this classic page:
>> aging, but still very relevant.
>>
>>
>> On Friday, January 11, 2013 10:33:15 PM UTC+1, Eric MacAdie wrote:
>>>
>>> Is there a page that gives "Clojure web recipes"? It would be great for
>>> beginners if you could have one place that says "To make a web app, you need
>>> X, Y and Z, and here are libraries that fulfil each of these needs."
>>>
>>> - Eric MacAdie
>>>
>>> On Fri, Jan 11, 2013 at 12:25 PM, Sean Corfield 
>>> wrote:

 I think there's a philosophical bent in the Clojure community toward
 small, composable libraries, rather than monolithic pre-built
 combinations - across all domains. This has come up in discussions
 before, mostly around the "full-stack web framework" issue, and the
 consensus each time seems to be we're better served by doing a
 mix'n'match from the available libraries.

 Scala is aimed much more squarely at the enterprise world of Java,
 which in turn is much more inclined toward the full-stack approach.

 FWIW, I ported my mature, popular, convention-based MVC framework FW/1
 from CFML to Clojure and even tho' it's nowhere near full-stack, in
 the Clojure world it's already far beyond the norm of small,
 composable libraries, as it "bundles" Ring and Enlive and has its own
 route processing. In the CFML world, FW/1 was a reaction to the large,
 full-stack frameworks inspired by Spring, Rails etc, and those CFML
 frameworks have routing, security, DI/AOP, ORM, environment control,
 logging, test generation and all sorts of things built in... hundreds
 of files, tens of thousands of lines of code, massive documentation
 and so on. Even FW/1 (for CFML) has routing, some DI and environment
 control all built in! FW/1 for Clojure has no DI nor environment
 control (although that probably will get added at some point). I'm
 somewhat allergic to ORM, favoring thin, simple data mappers instead
 :)

 Sean

 On Fri, Jan 11, 2013 at 10:08 AM, Paul Umbers 
 wrote:
 > My oopsie. You're right, it is 1.2.0. I was looking at the current
 > head of
 > master, which I guess is 1.2.0-SNAPSHOT.
 >
 > As long as all projects stick to semantic versioning (a lot do), that
 > problem is not so great.
 >
 > The other problem though is that of which libraries to choose for a
 > particular function. I understand the choice is pretty wide, and
 > that's a
 > good thing to some extent, but it means anyone new to Clojure has to
 > evaluate and choose almost every library they could use - which takes
 > time &
 > effort. If I want to build a web app/service with Java I know I can
 > just go
 > to Spring and it will have pretty much everything I need - tested &
 > compatible. The choice almost becomes a no-brainer. I don't have that
 > same
 > ease of use with Clojure - if someone asked me to build a web app or
 > service
 > now (commercially, so I'm on the Client's clock) I would have to
 > factor in a
 > significant amount of time to choose, test & evaluate frameworks.
 >
 > I guess that kind of ease-of-use comes from maturity, and Clojure is
 > still
 > relatively immature compared with Java. But then Scala is roughly the
 > same
 > age and they have TypeSafe which, as a full-stack, has a more certain
 > "feel"
 > to it than having to cherry-pick individual Clojure libraries (albeit
 > those
 > that have become de facto standards).
 >
 > Still, clients pay me to know this stuff, and that was one of the
 > reasons
 > for doing the project - to learn what works, what doesn't and how to
 > go
 > about it.
 >
 >
 > On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote:
 >>
 >> On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote:
 >>>
 >>> For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5
 >>> and
 >>> not the latest version of Ring (1.1.6) which has significantly
 >>> better util
 >>> functions available - but I can't use them until Compojure catches
 >>> up.
 >>
 >> Ring 1.1.6 doesn't have any new functions - it's just a patch
 >> release.
 >> You're thinking of Ring 1.2.0-SNAPSHOT, which shou

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Matt]

Though the Clojure community has traditionally gone with smaller libraries 
rather than large frameworks, there is a full-stack web framework for 
Clojure called Conjure: https://github.com/macourtney/Conjure


On Friday, January 11, 2013 11:52:05 AM UTC-5, Paul Umbers wrote:
>
> I've been experimenting with Clojure web services recently, and posting 
> the work on GitHub  and my 
> blog
> .
>
> When putting this test app together, it occurred to me that most other 
> languages have a full-stack API available which makes life easier when it 
> comes to making decisions about which libraries/APIs/frameworks to use. It 
> also reduces the possibility of "impedance mismatch" between the libraries. 
> For Java, you can use Spring (or any one of a dozen or more other popular 
> frameworks), for Scala there's Typesafe, and so on. Clojure has Compojure, 
> Ring, several logging, validation and database libraries, and they can be 
> used together but they don't constitute a coordinated full stack - and that 
> creates issues.
>
> For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and 
> not the latest version of Ring (1.1.6) which has significantly better util 
> functions available - but I can't use them until Compojure catches up. By 
> the time you add logging, validation, data access, etc the odds of a 
> mismatch between these libraries goes up dramatically.
>
> This is a concern, because these mismatches must be worked around in *my*code 
> and are likely to break as the libraries are upgraded in future 
> versions. So, I'm having to spend my time maintaining what are essentially 
> "patches" for third-party libraries just so that they work together.
>
> Now, it may not be the best decision to try to put together a true 
> full-stack framework from scratch, but is it worth choosing a bunch of 
> existing frameworks and coordinating their releases - in much the same way 
> as Eclipse coordinates plugin releases for major releases - so that putting 
> together a full-stack app becomes easier?
>
> Projects taking part in the "meta-project" will work together to harmonize 
> their functionality & APIs, and coordinate their development cycles & 
> releases so that the meta-framework remains consistent and easily usable.
>
> Is this another barrier to adoption the Clojure community can remove? Is 
> this even a barrier? Am I missing something?
>
> Thoughts?
>
> [Also posted to http://www.reddit.com/r/Clojure]
>  

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: bouncer, validation library for clojure

[Leonardo Borges]

Leonardo Borges
www.leonardoborges.com
On Jan 11, 2013 3:44 PM, "faenvie"  wrote:

>
> i took a look at it. bouncers DSL seems smart inside and out.
> Has an excellent Documentation too. Thanks for sharing it.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Paul Umbers]

On Friday, 11 January 2013 12:17:35 UTC-7, Herwig Hochleitner wrote:
>
>
> There is, however, value in curated sets of independent libriaries that 
> work well together. Also in having declarative syntax available for common 
> tasks.
> Still IMO, Clojure's web story is still somewhat lacking on those. More 
> specifically in in environment integration, since ring does a great job for 
> binding application components.
>
>
I would have to agree with this, because it's exactly the kind of thing I 
was thinking of in the original post. Eclipse is made up of a core 
application and a large set of plugins. While the individual plugin 
developers are free to develop as they see fit, they have all chosen to 
join together to produce at least one stable, consistent release per year 
where everything just works together nicely (well, OK, maybe not so nicely 
with Juno). I know the Clojure philosophy is, as Sean mentioned above, to 
build from small composable libraries, but to foster increased adoption in 
enterprise environments there's something to be said for a quick, easy 
start.

I think maybe a combination approach of curated library versions (that work 
well together) and a comprehensive set of templates would go a long way 
towards easing adoption.

I get the feeling we're almost there with Leiningen templates and the more 
mature libraries (like Compojure/Ring), and it would just take some buy-in 
and coordinated effort making it happen.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Eric MacAdie]

Thanks for the info. I will look this over, and perhaps finally build my
world-changing Clojure app. Or maybe just "Hello World."

- Eric MacAdie

On Fri, Jan 11, 2013 at 3:58 PM, Marko Topolnik wrote:

> There's a pretty good page at 
> heroku.
> There's also this classic 
> page:
> aging, but still very relevant.
>
>
> On Friday, January 11, 2013 10:33:15 PM UTC+1, Eric MacAdie wrote:
>
>> Is there a page that gives "Clojure web recipes"? It would be great for
>> beginners if you could have one place that says "To make a web app, you
>> need X, Y and Z, and here are libraries that fulfil each of these needs."
>>
>> - Eric MacAdie
>>
>> On Fri, Jan 11, 2013 at 12:25 PM, Sean Corfield wrote:
>>
>>> I think there's a philosophical bent in the Clojure community toward
>>> small, composable libraries, rather than monolithic pre-built
>>> combinations - across all domains. This has come up in discussions
>>> before, mostly around the "full-stack web framework" issue, and the
>>> consensus each time seems to be we're better served by doing a
>>> mix'n'match from the available libraries.
>>>
>>> Scala is aimed much more squarely at the enterprise world of Java,
>>> which in turn is much more inclined toward the full-stack approach.
>>>
>>> FWIW, I ported my mature, popular, convention-based MVC framework FW/1
>>> from CFML to Clojure and even tho' it's nowhere near full-stack, in
>>> the Clojure world it's already far beyond the norm of small,
>>> composable libraries, as it "bundles" Ring and Enlive and has its own
>>> route processing. In the CFML world, FW/1 was a reaction to the large,
>>> full-stack frameworks inspired by Spring, Rails etc, and those CFML
>>> frameworks have routing, security, DI/AOP, ORM, environment control,
>>> logging, test generation and all sorts of things built in... hundreds
>>> of files, tens of thousands of lines of code, massive documentation
>>> and so on. Even FW/1 (for CFML) has routing, some DI and environment
>>> control all built in! FW/1 for Clojure has no DI nor environment
>>> control (although that probably will get added at some point). I'm
>>> somewhat allergic to ORM, favoring thin, simple data mappers instead
>>> :)
>>>
>>> Sean
>>>
>>> On Fri, Jan 11, 2013 at 10:08 AM, Paul Umbers 
>>> wrote:
>>> > My oopsie. You're right, it is 1.2.0. I was looking at the current
>>> head of
>>> > master, which I guess is 1.2.0-SNAPSHOT.
>>> >
>>> > As long as all projects stick to semantic versioning (a lot do), that
>>> > problem is not so great.
>>> >
>>> > The other problem though is that of which libraries to choose for a
>>> > particular function. I understand the choice is pretty wide, and
>>> that's a
>>> > good thing to some extent, but it means anyone new to Clojure has to
>>> > evaluate and choose almost every library they could use - which takes
>>> time &
>>> > effort. If I want to build a web app/service with Java I know I can
>>> just go
>>> > to Spring and it will have pretty much everything I need - tested &
>>> > compatible. The choice almost becomes a no-brainer. I don't have that
>>> same
>>> > ease of use with Clojure - if someone asked me to build a web app or
>>> service
>>> > now (commercially, so I'm on the Client's clock) I would have to
>>> factor in a
>>> > significant amount of time to choose, test & evaluate frameworks.
>>> >
>>> > I guess that kind of ease-of-use comes from maturity, and Clojure is
>>> still
>>> > relatively immature compared with Java. But then Scala is roughly the
>>> same
>>> > age and they have TypeSafe which, as a full-stack, has a more certain
>>> "feel"
>>> > to it than having to cherry-pick individual Clojure libraries (albeit
>>> those
>>> > that have become de facto standards).
>>> >
>>> > Still, clients pay me to know this stuff, and that was one of the
>>> reasons
>>> > for doing the project - to learn what works, what doesn't and how to go
>>> > about it.
>>> >
>>> >
>>> > On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote:
>>> >>
>>> >> On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote:
>>> >>>
>>> >>> For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5
>>> and
>>> >>> not the latest version of Ring (1.1.6) which has significantly
>>> better util
>>> >>> functions available - but I can't use them until Compojure catches
>>> up.
>>> >>
>>> >> Ring 1.1.6 doesn't have any new functions - it's just a patch release.
>>> >> You're thinking of Ring 1.2.0-SNAPSHOT, which should be released
>>> within the
>>> >> next month, and will go into beta soon.
>>> >>
>>> >> Both Ring and Compojure use semantic versioning (http://semver.org/),
>>> so
>>> >> Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that
>>> you can
>>> >> quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so
>>> desire.
>>> >>
>>> >> Semantic versioning solves a lot of the problems you desc

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Marko Topolnik]

There's a pretty good page at 
heroku. 
There's also this classic page: 
aging, but still very relevant.

On Friday, January 11, 2013 10:33:15 PM UTC+1, Eric MacAdie wrote:
>
> Is there a page that gives "Clojure web recipes"? It would be great for 
> beginners if you could have one place that says "To make a web app, you 
> need X, Y and Z, and here are libraries that fulfil each of these needs."
>
> - Eric MacAdie
>
> On Fri, Jan 11, 2013 at 12:25 PM, Sean Corfield 
> 
> > wrote:
>
>> I think there's a philosophical bent in the Clojure community toward
>> small, composable libraries, rather than monolithic pre-built
>> combinations - across all domains. This has come up in discussions
>> before, mostly around the "full-stack web framework" issue, and the
>> consensus each time seems to be we're better served by doing a
>> mix'n'match from the available libraries.
>>
>> Scala is aimed much more squarely at the enterprise world of Java,
>> which in turn is much more inclined toward the full-stack approach.
>>
>> FWIW, I ported my mature, popular, convention-based MVC framework FW/1
>> from CFML to Clojure and even tho' it's nowhere near full-stack, in
>> the Clojure world it's already far beyond the norm of small,
>> composable libraries, as it "bundles" Ring and Enlive and has its own
>> route processing. In the CFML world, FW/1 was a reaction to the large,
>> full-stack frameworks inspired by Spring, Rails etc, and those CFML
>> frameworks have routing, security, DI/AOP, ORM, environment control,
>> logging, test generation and all sorts of things built in... hundreds
>> of files, tens of thousands of lines of code, massive documentation
>> and so on. Even FW/1 (for CFML) has routing, some DI and environment
>> control all built in! FW/1 for Clojure has no DI nor environment
>> control (although that probably will get added at some point). I'm
>> somewhat allergic to ORM, favoring thin, simple data mappers instead
>> :)
>>
>> Sean
>>
>> On Fri, Jan 11, 2013 at 10:08 AM, Paul Umbers 
>> > 
>> wrote:
>> > My oopsie. You're right, it is 1.2.0. I was looking at the current head 
>> of
>> > master, which I guess is 1.2.0-SNAPSHOT.
>> >
>> > As long as all projects stick to semantic versioning (a lot do), that
>> > problem is not so great.
>> >
>> > The other problem though is that of which libraries to choose for a
>> > particular function. I understand the choice is pretty wide, and that's 
>> a
>> > good thing to some extent, but it means anyone new to Clojure has to
>> > evaluate and choose almost every library they could use - which takes 
>> time &
>> > effort. If I want to build a web app/service with Java I know I can 
>> just go
>> > to Spring and it will have pretty much everything I need - tested &
>> > compatible. The choice almost becomes a no-brainer. I don't have that 
>> same
>> > ease of use with Clojure - if someone asked me to build a web app or 
>> service
>> > now (commercially, so I'm on the Client's clock) I would have to factor 
>> in a
>> > significant amount of time to choose, test & evaluate frameworks.
>> >
>> > I guess that kind of ease-of-use comes from maturity, and Clojure is 
>> still
>> > relatively immature compared with Java. But then Scala is roughly the 
>> same
>> > age and they have TypeSafe which, as a full-stack, has a more certain 
>> "feel"
>> > to it than having to cherry-pick individual Clojure libraries (albeit 
>> those
>> > that have become de facto standards).
>> >
>> > Still, clients pay me to know this stuff, and that was one of the 
>> reasons
>> > for doing the project - to learn what works, what doesn't and how to go
>> > about it.
>> >
>> >
>> > On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote:
>> >>
>> >> On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote:
>> >>>
>> >>> For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 
>> and
>> >>> not the latest version of Ring (1.1.6) which has significantly better 
>> util
>> >>> functions available - but I can't use them until Compojure catches up.
>> >>
>> >> Ring 1.1.6 doesn't have any new functions - it's just a patch release.
>> >> You're thinking of Ring 1.2.0-SNAPSHOT, which should be released 
>> within the
>> >> next month, and will go into beta soon.
>> >>
>> >> Both Ring and Compojure use semantic versioning (http://semver.org/), 
>> so
>> >> Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you 
>> can
>> >> quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so 
>> desire.
>> >>
>> >> Semantic versioning solves a lot of the problems you describe, because 
>> if
>> >> a library depends on version 1.0, you know it will work with version 
>> 1.1,
>> >> 1.2, and so forth. Only major versions, such as a leap from 1.5 to 
>> 2.0, have
>> >> breaking changes.
>> >>
>> >> - James
>> >
>> > --
>> > You received this message because

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Eric MacAdie]

Is there a page that gives "Clojure web recipes"? It would be great for
beginners if you could have one place that says "To make a web app, you
need X, Y and Z, and here are libraries that fulfil each of these needs."

- Eric MacAdie

On Fri, Jan 11, 2013 at 12:25 PM, Sean Corfield wrote:

> I think there's a philosophical bent in the Clojure community toward
> small, composable libraries, rather than monolithic pre-built
> combinations - across all domains. This has come up in discussions
> before, mostly around the "full-stack web framework" issue, and the
> consensus each time seems to be we're better served by doing a
> mix'n'match from the available libraries.
>
> Scala is aimed much more squarely at the enterprise world of Java,
> which in turn is much more inclined toward the full-stack approach.
>
> FWIW, I ported my mature, popular, convention-based MVC framework FW/1
> from CFML to Clojure and even tho' it's nowhere near full-stack, in
> the Clojure world it's already far beyond the norm of small,
> composable libraries, as it "bundles" Ring and Enlive and has its own
> route processing. In the CFML world, FW/1 was a reaction to the large,
> full-stack frameworks inspired by Spring, Rails etc, and those CFML
> frameworks have routing, security, DI/AOP, ORM, environment control,
> logging, test generation and all sorts of things built in... hundreds
> of files, tens of thousands of lines of code, massive documentation
> and so on. Even FW/1 (for CFML) has routing, some DI and environment
> control all built in! FW/1 for Clojure has no DI nor environment
> control (although that probably will get added at some point). I'm
> somewhat allergic to ORM, favoring thin, simple data mappers instead
> :)
>
> Sean
>
> On Fri, Jan 11, 2013 at 10:08 AM, Paul Umbers 
> wrote:
> > My oopsie. You're right, it is 1.2.0. I was looking at the current head
> of
> > master, which I guess is 1.2.0-SNAPSHOT.
> >
> > As long as all projects stick to semantic versioning (a lot do), that
> > problem is not so great.
> >
> > The other problem though is that of which libraries to choose for a
> > particular function. I understand the choice is pretty wide, and that's a
> > good thing to some extent, but it means anyone new to Clojure has to
> > evaluate and choose almost every library they could use - which takes
> time &
> > effort. If I want to build a web app/service with Java I know I can just
> go
> > to Spring and it will have pretty much everything I need - tested &
> > compatible. The choice almost becomes a no-brainer. I don't have that
> same
> > ease of use with Clojure - if someone asked me to build a web app or
> service
> > now (commercially, so I'm on the Client's clock) I would have to factor
> in a
> > significant amount of time to choose, test & evaluate frameworks.
> >
> > I guess that kind of ease-of-use comes from maturity, and Clojure is
> still
> > relatively immature compared with Java. But then Scala is roughly the
> same
> > age and they have TypeSafe which, as a full-stack, has a more certain
> "feel"
> > to it than having to cherry-pick individual Clojure libraries (albeit
> those
> > that have become de facto standards).
> >
> > Still, clients pay me to know this stuff, and that was one of the reasons
> > for doing the project - to learn what works, what doesn't and how to go
> > about it.
> >
> >
> > On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote:
> >>
> >> On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote:
> >>>
> >>> For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and
> >>> not the latest version of Ring (1.1.6) which has significantly better
> util
> >>> functions available - but I can't use them until Compojure catches up.
> >>
> >> Ring 1.1.6 doesn't have any new functions - it's just a patch release.
> >> You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within
> the
> >> next month, and will go into beta soon.
> >>
> >> Both Ring and Compojure use semantic versioning (http://semver.org/),
> so
> >> Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you
> can
> >> quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so
> desire.
> >>
> >> Semantic versioning solves a lot of the problems you describe, because
> if
> >> a library depends on version 1.0, you know it will work with version
> 1.1,
> >> 1.2, and so forth. Only major versions, such as a leap from 1.5 to 2.0,
> have
> >> breaking changes.
> >>
> >> - James
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
>
>
>
> --
> Sean A Corfield -- (904

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Marko Topolnik]

> I'm somewhat allergic to ORM, favoring thin, simple data mappers instead :)
>

You are not alone: ORM, together with the idea of a "persistent state 
manager" is a beautifully paved road---to hell. In the prototype phase it 
gives the impression of an ideal solution: code looks just like it's 
operating on plain memory objects. What could ideally be milliseconds, ORM 
turns them into tenths of a second, and this doesn't get anyone worried. 
Then, when you have the whole project committed to ORM and start working on 
some really tough requirements---and only those are the ones that *truly* add 
value to your product, tasks that could take a tenth of a second turn into 
show-stopping pauses of ten seconds and more.

Now, if you are using a full-stack framework like Rails, you are pretty 
much stuck with its ORM solution, like it or not; with Clojure's 
mix-and-match approach, you just find what you are more comfortable with.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Leiningen profiles for dev and prod dbs and other settings

[Jonathon McKitrick]

Perhaps this is better done with .env files?

On Friday, January 11, 2013 3:49:06 PM UTC-5, Jonathon McKitrick wrote:
>
> I just read about leiningen profiles, and I'm trying to figure out how to 
> access those settings within my code for db selection.
>
> What are the canonical ways to do this?
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Dmitri]

I think a lot of the issues can be addressed via a good template which sets 
up all the boiler plate, demonstrates idiomatic usage, and defaults to some 
common libraries. I'm actively working on filling this gap with the 
Luminus, 
which aims to make it easy to get rolling, and sets up all the basic things 
like sessions, static resources, packaging, etc.

On Friday, January 11, 2013 11:52:05 AM UTC-5, Paul Umbers wrote:
>
> I've been experimenting with Clojure web services recently, and posting 
> the work on GitHub  and my 
> blog
> .
>
> When putting this test app together, it occurred to me that most other 
> languages have a full-stack API available which makes life easier when it 
> comes to making decisions about which libraries/APIs/frameworks to use. It 
> also reduces the possibility of "impedance mismatch" between the libraries. 
> For Java, you can use Spring (or any one of a dozen or more other popular 
> frameworks), for Scala there's Typesafe, and so on. Clojure has Compojure, 
> Ring, several logging, validation and database libraries, and they can be 
> used together but they don't constitute a coordinated full stack - and that 
> creates issues.
>
> For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and 
> not the latest version of Ring (1.1.6) which has significantly better util 
> functions available - but I can't use them until Compojure catches up. By 
> the time you add logging, validation, data access, etc the odds of a 
> mismatch between these libraries goes up dramatically.
>
> This is a concern, because these mismatches must be worked around in *my*code 
> and are likely to break as the libraries are upgraded in future 
> versions. So, I'm having to spend my time maintaining what are essentially 
> "patches" for third-party libraries just so that they work together.
>
> Now, it may not be the best decision to try to put together a true 
> full-stack framework from scratch, but is it worth choosing a bunch of 
> existing frameworks and coordinating their releases - in much the same way 
> as Eclipse coordinates plugin releases for major releases - so that putting 
> together a full-stack app becomes easier?
>
> Projects taking part in the "meta-project" will work together to harmonize 
> their functionality & APIs, and coordinate their development cycles & 
> releases so that the meta-framework remains consistent and easily usable.
>
> Is this another barrier to adoption the Clojure community can remove? Is 
> this even a barrier? Am I missing something?
>
> Thoughts?
>
> [Also posted to http://www.reddit.com/r/Clojure]
>  

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Leiningen profiles for dev and prod dbs and other settings

[Jonathon McKitrick]

I just read about leiningen profiles, and I'm trying to figure out how to 
access those settings within my code for db selection.

What are the canonical ways to do this?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: clojurescript browser repl and static files

[Brent Millare]

Hmm I just realized, send-and-close doesn't quite handle the binary data 
case very well atm. I'd probably need to fix that first.

On Friday, January 11, 2013 2:50:31 PM UTC-5, David Nolen wrote:
>
> No reason beyond not having received a patch for it :)
>
>
> On Fri, Jan 11, 2013 at 2:21 PM, Brent Millare 
> 
> > wrote:
>
>> I noticed in the code in clojurescript, src/clj/cljs/repl/browser.clj, 
>> `send-static` has the cases for handling files other than .html such as 
>> css, jpg, .png etc, but the dispatching `(server/dispatch-on ...)` limits 
>> this and only accepts .js and .html. Any reason for this? Any chance of 
>> changing this? 
>>
>> -- 
>> 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
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: clojurescript browser repl and static files

[David Nolen]

No reason beyond not having received a patch for it :)


On Fri, Jan 11, 2013 at 2:21 PM, Brent Millare wrote:

> I noticed in the code in clojurescript, src/clj/cljs/repl/browser.clj,
> `send-static` has the cases for handling files other than .html such as
> css, jpg, .png etc, but the dispatching `(server/dispatch-on ...)` limits
> this and only accepts .js and .html. Any reason for this? Any chance of
> changing this?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

clojurescript browser repl and static files

[Brent Millare]

I noticed in the code in clojurescript, src/clj/cljs/repl/browser.clj, 
`send-static` has the cases for handling files other than .html such as 
css, jpg, .png etc, but the dispatching `(server/dispatch-on ...)` limits 
this and only accepts .js and .html. Any reason for this? Any chance of 
changing this?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Herwig Hochleitner]

IMO there is little value in big dependency hair-balls and gui tools
leakily abstracting devop taks.

There is, however, value in curated sets of independent libriaries that
work well together. Also in having declarative syntax available for common
tasks.
Still IMO, Clojure's web story is still somewhat lacking on those. More
specifically in in environment integration, since ring does a great job for
binding application components.

Lately I'm trying to push all code that deals with environment and project
configuration into leiningen plugins.
I think together with project templates, that can be a great way to get
more of the convenience of your classic framework.

kind regards

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Sean Corfield]

I think there's a philosophical bent in the Clojure community toward
small, composable libraries, rather than monolithic pre-built
combinations - across all domains. This has come up in discussions
before, mostly around the "full-stack web framework" issue, and the
consensus each time seems to be we're better served by doing a
mix'n'match from the available libraries.

Scala is aimed much more squarely at the enterprise world of Java,
which in turn is much more inclined toward the full-stack approach.

FWIW, I ported my mature, popular, convention-based MVC framework FW/1
from CFML to Clojure and even tho' it's nowhere near full-stack, in
the Clojure world it's already far beyond the norm of small,
composable libraries, as it "bundles" Ring and Enlive and has its own
route processing. In the CFML world, FW/1 was a reaction to the large,
full-stack frameworks inspired by Spring, Rails etc, and those CFML
frameworks have routing, security, DI/AOP, ORM, environment control,
logging, test generation and all sorts of things built in... hundreds
of files, tens of thousands of lines of code, massive documentation
and so on. Even FW/1 (for CFML) has routing, some DI and environment
control all built in! FW/1 for Clojure has no DI nor environment
control (although that probably will get added at some point). I'm
somewhat allergic to ORM, favoring thin, simple data mappers instead
:)

Sean

On Fri, Jan 11, 2013 at 10:08 AM, Paul Umbers  wrote:
> My oopsie. You're right, it is 1.2.0. I was looking at the current head of
> master, which I guess is 1.2.0-SNAPSHOT.
>
> As long as all projects stick to semantic versioning (a lot do), that
> problem is not so great.
>
> The other problem though is that of which libraries to choose for a
> particular function. I understand the choice is pretty wide, and that's a
> good thing to some extent, but it means anyone new to Clojure has to
> evaluate and choose almost every library they could use - which takes time &
> effort. If I want to build a web app/service with Java I know I can just go
> to Spring and it will have pretty much everything I need - tested &
> compatible. The choice almost becomes a no-brainer. I don't have that same
> ease of use with Clojure - if someone asked me to build a web app or service
> now (commercially, so I'm on the Client's clock) I would have to factor in a
> significant amount of time to choose, test & evaluate frameworks.
>
> I guess that kind of ease-of-use comes from maturity, and Clojure is still
> relatively immature compared with Java. But then Scala is roughly the same
> age and they have TypeSafe which, as a full-stack, has a more certain "feel"
> to it than having to cherry-pick individual Clojure libraries (albeit those
> that have become de facto standards).
>
> Still, clients pay me to know this stuff, and that was one of the reasons
> for doing the project - to learn what works, what doesn't and how to go
> about it.
>
>
> On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote:
>>
>> On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote:
>>>
>>> For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and
>>> not the latest version of Ring (1.1.6) which has significantly better util
>>> functions available - but I can't use them until Compojure catches up.
>>
>> Ring 1.1.6 doesn't have any new functions - it's just a patch release.
>> You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within the
>> next month, and will go into beta soon.
>>
>> Both Ring and Compojure use semantic versioning (http://semver.org/), so
>> Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you can
>> quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so desire.
>>
>> Semantic versioning solves a lot of the problems you describe, because if
>> a library depends on version 1.0, you know it will work with version 1.1,
>> 1.2, and so forth. Only major versions, such as a leap from 1.5 to 2.0, have
>> breaking changes.
>>
>> - James
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr.

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[Paul Umbers]

My oopsie. You're right, it is 1.2.0. I was looking at the current head of 
master, which I guess is 1.2.0-SNAPSHOT.

As long as all projects stick to semantic versioning (a lot do), that 
problem is not so great.

The other problem though is that of which libraries to choose for a 
particular function. I understand the choice is pretty wide, and that's a 
good thing to some extent, but it means anyone new to Clojure has to 
evaluate and choose almost every library they could use - which takes time 
& effort. If I want to build a web app/service with Java I know I can just 
go to Spring and it will have pretty much everything I need - tested & 
compatible. The choice almost becomes a no-brainer. I don't have that same 
ease of use with Clojure - if someone asked me to build a web app or 
service now (commercially, so I'm on the Client's clock) I would have to 
factor in a significant amount of time to choose, test & evaluate 
frameworks.

I guess that kind of ease-of-use comes from maturity, and Clojure is still 
relatively immature compared with Java. But then Scala is roughly the same 
age and they have TypeSafe which, as a full-stack, has a more certain 
"feel" to it than having to cherry-pick individual Clojure libraries 
(albeit those that have become de facto standards).

Still, clients pay me to know this stuff, and that was one of the reasons 
for doing the project - to learn what works, what doesn't and how to go 
about it.

On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote:
>
> On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote:
>
>> For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and 
>> not the latest version of Ring (1.1.6) which has significantly better util 
>> functions available - but I can't use them until Compojure catches up.
>>
> Ring 1.1.6 doesn't have any new functions - it's just a patch release. 
> You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within the 
> next month, and will go into beta soon.
>
> Both Ring and Compojure use semantic versioning (http://semver.org/), so 
> Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you can 
> quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so desire.
>
> Semantic versioning solves a lot of the problems you describe, because if 
> a library depends on version 1.0, you know it will work with version 1.1, 
> 1.2, and so forth. Only major versions, such as a leap from 1.5 to 2.0, 
> have breaking changes.
>
> - James
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Full stack Clojure web/REST framework - is there any mileage in it?

[James Reeves]

On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote:

> For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and 
> not the latest version of Ring (1.1.6) which has significantly better util 
> functions available - but I can't use them until Compojure catches up.
>
Ring 1.1.6 doesn't have any new functions - it's just a patch release. 
You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within the 
next month, and will go into beta soon.

Both Ring and Compojure use semantic versioning (http://semver.org/), so 
Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you can 
quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so desire.

Semantic versioning solves a lot of the problems you describe, because if a 
library depends on version 1.0, you know it will work with version 1.1, 
1.2, and so forth. Only major versions, such as a leap from 1.5 to 2.0, 
have breaking changes.

- James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Numerical Clojure - discussion open!

[Marek Šrank]

The url is https://groups.google.com/forum/#!forum/numerical-clojure

Marek

On Friday, January 11, 2013 10:41:58 AM UTC+1, Shantanu Kumar wrote:
>
> Hi Mike, 
>
> Could you please share the discussion group URL? 
>
> Shantanu 
>
> On Jan 11, 9:12 am, Mikera  wrote: 
> > Hello everybody, 
> > 
> > I've created a new discussion group "Numerical Clojure" for anyone 
> > interested in doing serious numerical computing in Clojure. 
> > 
> > The vision is to build a numerics capability / set of libraries in 
> Clojure 
> > somewhat inspired by what the Python community has done with NumPy, but 
> > also building on the many natural strengths that Clojure should have in 
> > this space (e.g. the wealth of JVM libraries, symbolic metaprogramming, 
> > high level abstraction capabilities etc.) 
> > 
> > An initial focus is on creating a "core.matrix" API for vector / matrix 
> > maths. There's a working prototype of this on GitHub: 
> > -https://github.com/mikera/matrix-api 
> > 
> > Anyone interested in this topic, please join the group and contribute 
> your 
> > ideas! 
> > 
> > Best regards, 
> > 
> >Mike. 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Full stack Clojure web/REST framework - is there any mileage in it?

[Paul Umbers]

I've been experimenting with Clojure web services recently, and posting the 
work on GitHub  and my 
blog
.

When putting this test app together, it occurred to me that most other 
languages have a full-stack API available which makes life easier when it 
comes to making decisions about which libraries/APIs/frameworks to use. It 
also reduces the possibility of "impedance mismatch" between the libraries. 
For Java, you can use Spring (or any one of a dozen or more other popular 
frameworks), for Scala there's Typesafe, and so on. Clojure has Compojure, 
Ring, several logging, validation and database libraries, and they can be 
used together but they don't constitute a coordinated full stack - and that 
creates issues.

For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not 
the latest version of Ring (1.1.6) which has significantly better util 
functions available - but I can't use them until Compojure catches up. By 
the time you add logging, validation, data access, etc the odds of a 
mismatch between these libraries goes up dramatically.

This is a concern, because these mismatches must be worked around in *my*code 
and are likely to break as the libraries are upgraded in future 
versions. So, I'm having to spend my time maintaining what are essentially 
"patches" for third-party libraries just so that they work together.

Now, it may not be the best decision to try to put together a true 
full-stack framework from scratch, but is it worth choosing a bunch of 
existing frameworks and coordinating their releases - in much the same way 
as Eclipse coordinates plugin releases for major releases - so that putting 
together a full-stack app becomes easier?

Projects taking part in the "meta-project" will work together to harmonize 
their functionality & APIs, and coordinate their development cycles & 
releases so that the meta-framework remains consistent and easily usable.

Is this another barrier to adoption the Clojure community can remove? Is 
this even a barrier? Am I missing something?

Thoughts?

[Also posted to http://www.reddit.com/r/Clojure]
 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: Clojure/West sessions

[Alex Miller]

Most of the miniKanren Confo sessions are now also included at the end 
(http://clojurewest.org/sessions#confo).

On Friday, January 11, 2013 7:53:39 AM UTC-6, Alex Miller wrote:
>
> I have posted almost all of the Clojure/West sessions at 
> http://clojurewest.org/sessions. 
>
> Still missing:
> ** Rich Hickey's abstract - I assume he's written a browser or an 
> operating system or something :) :)
> ** abstracts for the miniKanren Confo (Byrd/Friedman, David Nolen, Nada 
> Amin, Ryan Senior, Adam Foltzer, and Gabriel Pickard will be presenting) 
> ** abstracts about Pedestal, Relevance's new open source project. I've 
> gotten a sneak preview and you're going to be hearing a lot more about 
> this. Killer stuff.
>
> Registration is available at http://regonline.com/clojurewest2013
> Sponsorship info is at http://clojurewest.org/sponsorship-prospectus
>
> Alex
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure user group in Budapest just launched

[Balint Erdi]

Great, just sent the pull request. 


On Friday, January 11, 2013 at 4:03 PM, Michael Klishin wrote:

> 2013/1/11 Balint Erdi mailto:balint.e...@gmail.com)>
> > Delighted to announce that the Budapest Clojure Group has just launched:
> > 
> > http://www.meetup.com/Budapest-Clojure-User-Group/
> Balint,
> 
> Please consider adding it to the User Groups page on http://clojure-doc.org.
> All it takes is a pull request on GitHub that edits [1].
> 
> 1. 
> https://github.com/clojuredocs/cds/blob/master/articles/ecosystem/user_groups.md
>  
> -- 
> MK
> 
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com 
> (mailto:clojure@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+unsubscr...@googlegroups.com 
> (mailto:clojure+unsubscr...@googlegroups.com)
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Clojure user group in Budapest just launched

[Balint Erdi]

Hey,

Delighted to announce that the Budapest Clojure Group has just launched:

http://www.meetup.com/Budapest-Clojure-User-Group/

The official language is English so consider joining/attending if you're 
from a relatively close city but don't speak Hungarian (Bratislava & Vienna 
come to mind).

One city closer to world domination!

Balint
http://twitter.com/baaz

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to integrate front-end designers into Clojure/Ring/Jetty workflow?

[larry google groups]

Thanks! Those are great ideas.


On 10 Sty, 21:11, Sean Corfield  wrote:
> My first thought is: don't bother compiling the code, just run it
> "live" from source (and maybe provide a way to easily reload the
> templates (such as a URL parameter).
>
> What I've done in my FW/1 framework (convention-based MVC, built on
> Ring and Enlive) is to have a mode that auto-reloads templates on
> every request (a development mode) or you can just specify a URL
> parameter to force the templates to be reloaded.
>
> If you're interested in looking at FW/1 for Clojure (it's a port of a
> seasoned and very popular CFML framework that I originally created
> back in 2009), the repo is:https://github.com/seancorfield/fw1-clj
>
> There's a FW/1 Leiningen template so it should be as simple as:
> * lein new fw1 myapp
> * cd myapp
> * lein run
>
> Then just edit controllers (and add a separate model if you want),
> edit your views, and add ?reload=secret to the URL to force a reload.
>
> For more background, the original CFML version is 
> here:https://github.com/seancorfield/fw1with some overview information
> here:http://fw1.riaforge.org(including mailing list link).
>
> Sean
>
> On Thu, Jan 10, 2013 at 3:28 PM, larry google groups
>
>
>
>
>
>
>
>
>
>  wrote:
>
> > So, I am working on a web app that is buillt with Clojure/Ring/Jetty
> > and, importantly, Enlive. My directory structure is like this:
>
> > /resources
> >     /public
> >         /css
> >         /js
> >         /img
> >     /templates
>
> > /src
> >     /discovery
> >         core.clj
>
> > The great thing about Enlive is that the templates are pure HTML. This
> > makes it easier for graphic designers and frontenders to work with
> > them directly. I am working with a designer and frontend developer,
> > who  have absolute power over the stuff going into the /resources
> > folder.
>
> > I have 2 questions:
>
> > 1.) In my routes, I am using (wrap-resource) instead of (wrap-file).
> > Is there any way to enable live updates, so that if the designer
> > changes the images in /resources/public/img, they can then see the
> > changed images when looking at the app in their browser? Right now I
> > have to recompile the app and restart it for change to be visible to
> > the designer.
>
> > 2.) I notice that if a change is made in /resources, but no change is
> > made anywhere else, then if I run "lein compile" nothing happens. Is
> > there a way to force lein to compile?
>
> > I have little insight about how to build a multiperson workflow while
> > doing Clojure development. One thought I had: I could automate the re-
> > build of the app, and give the designer an easy way to trigger that
> > rebuild (click a button in Jenkins -- easy enough because we rely on
> > Jenkins for all of our builds, and the interface is simple enough for
> > non-programmers to handle). But I would like to hear what other people
> > do.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View --http://corfield.org/
> World Singles, LLC. --http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure web server benchmarks

[James Reeves]

This is very interesting. Have you tried running the Ring Jetty adapter
with a larger thread pool? It's set lower than the default so as not to
overload cloud hosts like Heroku.

- James


On 5 January 2013 15:52, Peter Taoussanis  wrote:

> Hi all,
>
> Quick post to mention that I've put up some rough benchmarks for a number
> of Clojure web servers:
> https://github.com/ptaoussanis/clojure-web-server-benchmarks.
>
> Getting semi-reliable numbers was a real PITA, and I'm sure there's still
> plenty of room left for improvement (suggestions welcome!). Usual
> disclaimers apply: the numbers vary by hardware, by OS, by concurrency, and
> by the response size (among other things). The servers also vary
> considerably in their feature sets. Not to mention that your web server is
> seldom going to be the bottleneck when generating dynamic content. Tl;dr:
> this is all very difficult to generalize: you'll need to bench in your own
> environment with your own workloads to get an accurate picture.
>
> Anyway I think the numbers are interesting (and pretty impressive
> all-round). Nginx can almost certainly be tweaked faster (ideas?), but I
> wouldn't have expected something like the standard Ring Jetty adapter even
> to be playing in the same ballpark - so that's nice.
>
> I'll try keep this updated as servers are updated. And as I've mentioned
> on the GitHub page, pull-requests welcome for anything I may have missed,
> including other servers or mis-configurations, etc. Hopefully with some
> tweaking we can converge on some reasonably accurate/useful common-case
> numbers.
>
> Cheers!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

ANN: Clojure/West sessions

[Alex Miller]

I have posted almost all of the Clojure/West sessions at
http://clojurewest.org/sessions.

Still missing:
** Rich Hickey's abstract - I assume he's written a browser or an operating
system or something :) :)
** abstracts for the miniKanren Confo (Byrd/Friedman, David Nolen, Nada
Amin, Ryan Senior, Adam Foltzer, and Gabriel Pickard will be presenting)
** abstracts about Pedestal, Relevance's new open source project. I've
gotten a sneak preview and you're going to be hearing a lot more about
this. Killer stuff.

Registration is available at http://regonline.com/clojurewest2013
Sponsorship info is at http://clojurewest.org/sponsorship-prospectus

Alex

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Numerical Clojure - discussion open!

[Alex Ott]

Why not to reuse existing Incanter group?

On Fri, Jan 11, 2013 at 5:12 AM, Mikera  wrote:
> Hello everybody,
>
> I've created a new discussion group "Numerical Clojure" for anyone
> interested in doing serious numerical computing in Clojure.
>
> The vision is to build a numerics capability / set of libraries in Clojure
> somewhat inspired by what the Python community has done with NumPy, but also
> building on the many natural strengths that Clojure should have in this
> space (e.g. the wealth of JVM libraries, symbolic metaprogramming, high
> level abstraction capabilities etc.)
>
> An initial focus is on creating a "core.matrix" API for vector / matrix
> maths. There's a working prototype of this on GitHub:
> - https://github.com/mikera/matrix-api
>
> Anyone interested in this topic, please join the group and contribute your
> ideas!
>
> Best regards,
>
>Mike.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
With best wishes,Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Numerical Clojure - discussion open!

[Shantanu Kumar]

Hi Mike,

Could you please share the discussion group URL?

Shantanu

On Jan 11, 9:12 am, Mikera  wrote:
> Hello everybody,
>
> I've created a new discussion group "Numerical Clojure" for anyone
> interested in doing serious numerical computing in Clojure.
>
> The vision is to build a numerics capability / set of libraries in Clojure
> somewhat inspired by what the Python community has done with NumPy, but
> also building on the many natural strengths that Clojure should have in
> this space (e.g. the wealth of JVM libraries, symbolic metaprogramming,
> high level abstraction capabilities etc.)
>
> An initial focus is on creating a "core.matrix" API for vector / matrix
> maths. There's a working prototype of this on GitHub:
> -https://github.com/mikera/matrix-api
>
> Anyone interested in this topic, please join the group and contribute your
> ideas!
>
> Best regards,
>
>    Mike.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: "core.matrix" proposal

[Konrad Hinsen]

Mikera writes:

 > BTW, I started my own attempt at something similar a while ago, but
 > never found the time to get it to a usable state:
 >
 >https://code.google.com/p/clj-multiarray/
 >
 > Konrad.
 > 
 > Very interesting, thanks! I like the use of protocols to construct the 
 > specialised array
 > types in particular.
 > 
 > Would you be willing and interested to work on merging this into the 
 > "core.matrix" code
 > base? I had started on a simple NDArray implementation myself but your code 
 > is clearly
 > much further along than mine.

Sure! I won't be able to work much on this over the next few weeks, but feel 
free
to take over any code that looks good to you.

See you on Numerical Clojure...

Konrad.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en