Re: Ragtime w/ Korma
Verify with clojure.java.jdbc would by my first approach, but it's not clear to me how you can know migratus and Korma aren't touching two different instantiations of the H2 in memory database using c.j.j. I don't know anything about H2. I'm a PostgreSQL user. On Tuesday, January 14, 2014 7:50:07 AM UTC-8, Arlandis Lawrence wrote: The errors I'm getting indicate that the tables don't exist. Table itinerary not found; SQL statement: DELETE FROM itinerary [42102-164] org.h2.jdbc.JdbcSQLException: Table itinerary not found; SQL statement: DELETE FROM itinerary [42102-164] at org.h2.message.DbException.getJdbcSQLException(DbException.java:329) at org.h2.message.DbException.get(DbException.java:169) at org.h2.message.DbException.get(DbException.java:146) at org.h2.command.Parser.readTableOrView(Parser.java:4753) at org.h2.command.Parser.readTableOrView(Parser.java:4731) at org.h2.command.Parser.readSimpleTableFilter(Parser.java:709) at org.h2.command.Parser.parseDelete(Parser.java:731) at org.h2.command.Parser.parsePrepared(Parser.java:336) at org.h2.command.Parser.parse(Parser.java:279) at org.h2.command.Parser.parse(Parser.java:251) at org.h2.command.Parser.prepareCommand(Parser.java:217) at org.h2.engine.Session.prepareLocal(Session.java:415) at org.h2.engine.Session.prepareCommand(Session.java:364) at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1121) at org.h2.jdbc.JdbcPreparedStatement.init(JdbcPreparedStatement.java:71) at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:267) at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:213) ... 4 stack levels elided ... at korma.db$exec_sql.invoke(db.clj:206) at korma.db$do_query$fn__2578.invoke(db.clj:227) ... 1 stack levels elided ... at korma.db$do_query.invoke(db.clj:226) at korma.core$exec.invoke(core.clj:474) I've verified that using postgres instead of h2 works and that the migrations actually occur in the h2 in-memory database, but for some reason korma doesn't see the tables. I suspect that korma is actually connecting to a different database, or is connecting after the original in-memory database has closed (I used the DB_CLOSE_DELAY=-1 argument to try and mitigate this). Do you have any tips for examining the in-memory database manually in h2 or verifying that the databases I'm connecting to are the same? On Monday, January 13, 2014 4:35:30 PM UTC-6, Christopher Allen wrote: Try it without H2 and check the contents of the database manually. Korma cooperating doesn't mean a lot if the tables don't actually exist. Error messages should be provided in future. On Monday, January 13, 2014 1:44:28 PM UTC-8, Arlandis Lawrence wrote: I'm trying to use H2's in-memory database feature for running specs, so I'm using Ragtime to run migrations before the test. Problem is, I can't get Korma to cooperate. Could someone take a look at this gist and see if it makes sense? https://gist.github.com/arlandism/8408370 -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Managing role-based permissions in Ring apps
I might follow up with a more thorough reply, but I had to drop Friend for the same reason I had to drop Liberator. Customizing the assumptions/defaults the libraries made was too default. Relatively simple content negotiation involved trying to do insane monkey-patches of Liberator's protocols or vendoring and rewriting of the library. Whereas, plain ole' Ring middleware: https://github.com/bitemyapp/berossus/blob/master/src/berossus/rocks/your/data/middleware.clj#L44-L51 has worked out just dandy. I don't mind leveraging other peoples' code at all, but Liberator and Friend fall apart fairly quickly if you step outside their view of the universe even a little bit. On Monday, January 13, 2014 12:16:56 PM UTC-8, Alexandr Kurilin wrote: Disclaimer: I think what Friend is trying to do is super important and cemerick rocks. However, I found Friend to be really difficult to grok the first time I took a stab at it many months ago, perhaps I'm more capable of getting into it now. My concern was that it is so broadly encompassing and there are too few examples of how to use it in scenarios similar to the ones I face every day. For example, I ended up rolling my own cookie-based role auth middleware (relying on Ring's cookie store) in about 15 lines of clj, significantly simpler for a basic scenario. By the way, it would be really neat if someone added a Friend chapter to the upcoming Clojure Cookbook. I created an issue for it over 6 months ago and nobody's taken it up so far, so I can't tell if most of the community has given up on the library or if it's just too much of a hassle to explain to others. On Sun, Jan 12, 2014 at 11:40 PM, Stefan Kamphausen ska...@gmail.comjavascript: wrote: On Monday, January 13, 2014 3:53:43 AM UTC+1, Sam Ritchie wrote: cemerick's Friend library is the way to do this: https://github.com/cemerick/friend I'm writing up a post on how to combine Friend with Liberator, for easy ACL management for RESTful APIs. Take a look and let us know what you think! Can't wait to read that post. :) stefan -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Alexandr Kurilin 206.687.8740 | @alex_kurilin https://twitter.com/alex_kurilin | bloghttp://www.kurilin.net -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Managing role-based permissions in Ring apps
To clarify, that was an example of content negotiation middleware, not ACL. If I were to tackle this, I would try to find or implement a pure ACL (not aware of web apps per se) library and then hook it up via Ring middleware. On Monday, January 13, 2014 12:45:23 PM UTC-8, Christopher Allen wrote: I might follow up with a more thorough reply, but I had to drop Friend for the same reason I had to drop Liberator. Customizing the assumptions/defaults the libraries made was too default. Relatively simple content negotiation involved trying to do insane monkey-patches of Liberator's protocols or vendoring and rewriting of the library. Whereas, plain ole' Ring middleware: https://github.com/bitemyapp/berossus/blob/master/src/berossus/rocks/your/data/middleware.clj#L44-L51 has worked out just dandy. I don't mind leveraging other peoples' code at all, but Liberator and Friend fall apart fairly quickly if you step outside their view of the universe even a little bit. On Monday, January 13, 2014 12:16:56 PM UTC-8, Alexandr Kurilin wrote: Disclaimer: I think what Friend is trying to do is super important and cemerick rocks. However, I found Friend to be really difficult to grok the first time I took a stab at it many months ago, perhaps I'm more capable of getting into it now. My concern was that it is so broadly encompassing and there are too few examples of how to use it in scenarios similar to the ones I face every day. For example, I ended up rolling my own cookie-based role auth middleware (relying on Ring's cookie store) in about 15 lines of clj, significantly simpler for a basic scenario. By the way, it would be really neat if someone added a Friend chapter to the upcoming Clojure Cookbook. I created an issue for it over 6 months ago and nobody's taken it up so far, so I can't tell if most of the community has given up on the library or if it's just too much of a hassle to explain to others. On Sun, Jan 12, 2014 at 11:40 PM, Stefan Kamphausen ska...@gmail.comwrote: On Monday, January 13, 2014 3:53:43 AM UTC+1, Sam Ritchie wrote: cemerick's Friend library is the way to do this: https://github.com/cemerick/friend I'm writing up a post on how to combine Friend with Liberator, for easy ACL management for RESTful APIs. Take a look and let us know what you think! Can't wait to read that post. :) stefan -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Alexandr Kurilin 206.687.8740 | @alex_kurilin https://twitter.com/alex_kurilin | bloghttp://www.kurilin.net -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to handle configuration in Clojure?
github.com/weavejester/environ/ + environment variables. 12-factor it that way, proxy the environment variables via a config namespace so that configuration values are programmatically generated in case something needs to intervene. On Monday, January 13, 2014 5:50:54 AM UTC-8, James Trunk wrote: I've been investigating how to handle configuration in a Clojure application/library, and have discovered two main candidates: dynamics vars and argument passing. The downsides to dynamic vars seem to be: hiddenness, thread safety, and more complex tests (binding before each test). The downside to argument passing is noise in the code (especially when you're just passing the config through). Longer and more descriptive names for the config (i.e. not ctx or cfg) make this noise even more painful. Are there any alternatives that I've missed? What is the current best practice for handling configuration? Cheers, 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to handle configuration in Clojure?
Example here: https://github.com/bitemyapp/berossus/blob/master/src/berossus/rocks/your/data/config.clj On Monday, January 13, 2014 1:57:06 PM UTC-8, Christopher Allen wrote: github.com/weavejester/environ/ + environment variables. 12-factor it that way, proxy the environment variables via a config namespace so that configuration values are programmatically generated in case something needs to intervene. On Monday, January 13, 2014 5:50:54 AM UTC-8, James Trunk wrote: I've been investigating how to handle configuration in a Clojure application/library, and have discovered two main candidates: dynamics vars and argument passing. The downsides to dynamic vars seem to be: hiddenness, thread safety, and more complex tests (binding before each test). The downside to argument passing is noise in the code (especially when you're just passing the config through). Longer and more descriptive names for the config (i.e. not ctx or cfg) make this noise even more painful. Are there any alternatives that I've missed? What is the current best practice for handling configuration? Cheers, 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Ragtime w/ Korma
Try it without H2 and check the contents of the database manually. Korma cooperating doesn't mean a lot if the tables don't actually exist. Error messages should be provided in future. On Monday, January 13, 2014 1:44:28 PM UTC-8, Arlandis Lawrence wrote: I'm trying to use H2's in-memory database feature for running specs, so I'm using Ragtime to run migrations before the test. Problem is, I can't get Korma to cooperate. Could someone take a look at this gist and see if it makes sense? https://gist.github.com/arlandism/8408370 -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] Brambling: Datomic (Schema) Migration library/toolkit for Clojure
https://github.com/bitemyapp/brambling/ This is a very early point in time for the library, (alpha), but it has already been useful at work so I figured I would get it out there to see what bits people did and didn't care about. Why this exists: As with any historical database you have to migrate the transaction log in addition to the current state of the universe. Conveniently, Datomic makes querying at arbitrary points of time rather easily. Less conveniently, there's no map/reduce sugar for performing migrations so I needed to put together a toolkit to handle reducing over the origin tx-log, carrying over entity identities consistently (old - tempid - new), and translating the transactions with the new schema being first at the head of the destination. There are some pretty serious limitations (incremental migrations principally) but I don't think they're showstoppers, and like I said, this has already been useful for migrating production data. Let me know if you have any questions! --- Chris -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: SQL to logic rule mapping
If you just want to build up and apply constraints, Korma can do that. If you want something closer to Datalog with unification, then a Datalog to SQL bridge is the most practical of largely impractical choices. On Tuesday, October 29, 2013 9:35:45 AM UTC-7, ArturoH wrote: I am interested in writing a better SQL mapping tool for clojure. Because I am not convinced that simple SQL composition is effective, for various reasons. I rather have some kind of logic construct that I could use to generate SQL from. My main concern is to eliminate the hard boundary between the RDBMS and the rest of the code. Any given logic construct would a candidate to be translated into SQL or executed inside the JVM. One option that I have been considering is a production rule system. The most popular are based on the rete algorithm. I know there are a few open source productions systems out there, but I think translating into SQL from an established rule language may be too complicated. At this point I plan to use the language extensions proposed by Anurag Acharya, that eliminate sequential guards and adds collection support. The reason is that I want to process the rules in parallel, and I want to be as close to SQL as possible. Clojure pure functions could also be called from within a production rule. The use case I have in mind is regular IT apps, not necessarily complex decision systems. I just find myself writing too much code, and often an SQL a clojure procedure and a function in the GUI will have some aspect of the same business rule embedded in the code. A layered approach helps to alleviate the problem, but it still persists. More support for declarative code may be the answer. But other than SQL or LINQ and other minor examples, there is little support for declarative code for average IT systems. Anyone has any ideas/opinions? I would appreciate any feedback. Arturo Hernandez -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: What non-deprecated Clojure Web libraries to use?
You can use Korma with Stuart Sierra's workflow just fine. On Sunday, October 27, 2013 5:07:02 PM UTC-7, Manuel Paccagnella wrote: Il giorno lunedì 28 ottobre 2013 00:30:06 UTC+1, Alexander Hudek ha scritto: http://www.luminusweb.net/ gives a reasonable starting setup. The only thing I would recommend doing differently is to use clojure/java.jdbc or honeysql instead of korma for an sql dsl. I agree. Korma is quite interesting as a DSL, but currently useshttps://github.com/korma/Korma/blob/master/src/korma/db.clj#L75Vars under the hood to manage connections and this doesn’t play well with dynamic workflows as the onehttp://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloadedby Stuart Sierra. Personally I’ve used just clojure.java.jdbchttps://github.com/clojure/java.jdbc( here http://manuelp.herokuapp.com/posts/7 is a micro-tutorial that I’ve written for it) that is going under an API overhaul to make connections management more explicit and functional. If you need an SQL generation library you could look at Honey SQL https://github.com/jkk/honeysql. Hope it helps, Manuel PS: You could also take a look at the new book Web Development in Clojurehttp://pragprog.com/book/dswdcloj/web-development-with-clojureby the author of Luminus http://www.luminusweb.net/. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Show the latest version of the library on your Github README page
Thank you for this! What could be done to make the text highlightable/copyable? On Tuesday, October 8, 2013 6:25:07 AM UTC-7, Alexander Yakushev wrote: Have you ever felt annoyed to update the README after you released a new version of your project? Have your users ever struggled to make the older version work because you forgot to update that README? Suffer no more, because Clojars has just the right medicine for you. From now on, you can append */latest-version.svg* to your artefact's link, which will resolve to an image that shows the latest version of your project. Then you can embed this image in your README, or Wiki, or wherever else you like. A couple examples: https://clojars.org/leiningen/latest-version.svg https://clojars.org/com.palletops/pallet-cli/latest-version.svg The only downside of using this feature is that the user can't just select and copy the dependency line anymore. Although Webkit-based browsers support text selection in SVGs (and Firefox's support for one is on the way) it works only when opening the single image, but not when the image is embedded into the page. But I hope it can be worked around somehow in future. Thanks to Nelson Morris and Phil Hagelberg for pushing this out! -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: *db* binding with jetty
Most web apps will either have a top-level def'd var that points to the database or they'll use a middleware to chain it into the request map. Which you do depends on your DB library. On Monday, September 23, 2013 1:23:50 PM UTC-7, Brian Craft wrote: My question is more about how to pass something to the app without sticking it in a global. This might be a noir question. Handlers are called without any passed context. I'm not sure if that's peculiar to noir, or something inherited from ring. So, the only way I know to get context to the app is to merge it into the request context with middleware. (defn db-middleware [db app] (fn [req] (app (assoc req :db db where db could be the connection pool, or db credentials, or whatever else is required to make a connection. On Monday, September 23, 2013 12:35:26 PM UTC-7, Sean Corfield wrote: Take a look at http://clojure-doc.org/articles/ecosystem/java_jdbc/connection_pooling.html You would want to set up a connection pool and pass that into your app as part of its context. Does that help? Sean On Mon, Sep 23, 2013 at 11:25 AM, Brian Craft craft...@gmail.com wrote: Trying to get a small app off the ground with noir/jdbc/jetty (jdbc 0.2.2, I think), I'm getting a No valid DB connection selected error. I suspect this is because I start it something like (with-connection mydb (server/start)) which creates a thread-local binding of *db* in jdbc, then starts jetty in a different thread, with no binding for *db*. Does that sound correct? If so, I'm not sure how to work around it. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] quickie- autotest plugin for clojure.test
Link: https://github.com/jakepearson/quickie Is it possible to see *some* of the stack trace so you can debug? Also you should include a screenshot of what the library looks like in action. :) On Friday, September 13, 2013 10:57:35 AM UTC-7, Jake Pearson wrote: Hi, Quickie is a leiningen plugin to autotest clojure.test tests. There don't seem to be any active projects for clojure.test, so a couple of people at my office wrote one. Please let me know if you have any problems or ideas: - Uses the builtin clojure.test test runner so you don't need to rewrite your tests - Tools.namespace will unload and reload namespaces as needed to keep process in sync - Runs every time a clojure file in your project changes - Uses (Clansi)[https://github.com/ams-clj/clansi] to show a red or green bar to know if you tests are passing - Filters out exception stacktraces to remove cruft thanks, Jake -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: clojure web framework
Well for creation itself, http://www.luminusweb.net/ represents best practices with Ring, Compojure, and the usual attendant libraries. For deployment, I'd say something like Fabric or Ansible is going to be the simplest way to start. On Friday, September 13, 2013 10:45:10 AM UTC-7, Jon Barker wrote: anybody know the easiest way to create web applications and deploy to amazon web services? (either EC2 or elastic beanstalk) Thanks, Jon -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: The Eclipse Public License is not a good license
I agree with Corfield and approaching things that seem wrong from a spirit of curiosity, rather than defaulting to criticism is a better way to improve understanding. You miss wonderful opportunities to learn when you approach things like that. On Wednesday, September 11, 2013 10:54:36 AM UTC-7, Sean Corfield wrote: Perhaps a more productive way to approach this issue would have been to ask if the group could point you to a discussion of why Clojure is under the EPL instead of starting from a point of criticism, and challenging the care with which the license was selected? Searching the archives would have turned up some _long_ threads about this where it would have been clear that the license is not going to change - as well as explaining why it is the way it is. For example: https://groups.google.com/forum/#!topic/clojure/bpnKr88rvt8 (from 2008) Sean On Wed, Sep 11, 2013 at 6:41 AM, Kalinni Gorzkis musicde...@gmail.com javascript: wrote: I think that Clojure should switch to a better license with similar spirit like Apache 2.0, BSD, or MIT. While the EPL doesn't have the evil copyleft requirement of GPL, and therefore allows and encourages commercial uses of the code, it has a requirement that makes it incompatible with the GPL: If you create modified versions of EPL-covered software, you must slap your name (or any other identity) on it. In my humble opinion, this restriction isn't justified. (All, or most, creators of modified versions will do that anyway). It may have been chosen uncarefully. Other permissive licenses better fulfill Rich Hickey's spirit. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Functional purity and globals in Clojure
I do a hybrid in Bulwark. github.com/bitemyapp/bulwark/ Defaults to accepting a closure of a config map for nice testing and hygiene, with a fallback to a global atom map for configuration for muggles. Works well for me. On Tuesday, September 10, 2013 12:19:35 AM UTC-7, Alexandr Kurilin wrote: I'm trying to determine how to best deal with the concept of globals in Clojure. Say I have a map of configuration values for my Ring app, populate at app startup from disk or env, and I need to reference the contents of this map from all over the project. Assuming MVC, models and controllers all would be interested in its contents. I just want to clarify that the question is not so much about configuration as it is about dealing with state that many different components in an application might be all interested in. This is an issue that seems to arise very often. I'm seeing a couple of options here: - Pass the configs map along with each Ring request with some middleware, and then down every subsequent function call that might eventually need it. It's a bit of a hassle since now you're passing more data, potentially increasing the # of parameters, or forcing you to use a parameter map everywhere where you might have passed along just 1 primitive. Nonetheless, this is as pure as it gets. - Def the configs map in a namespace somewhere and refer to it from wherever, just like global state. The trick is now that now you're no longer certain what e.g. your model functions are expecting there to be in the system and testing becomes trickier. Now you have to either lein test with a separate set of configurations (which doesn't actually give you much per-test granularity) or use with-redefs everywhere to make sure the right test config state is being used. - Something in the middle where perhaps you agree to never directly reference the configs map from your models (again, thinking MVC here) and instead only ever access it from controllers, and pass the necessary options along down to the model functions. This way you can test both controllers and models in isolation in purity. Ultimately I want to contain the chaos of having to know internal implementation details of my functions at different layers and want them to be easily testable in isolation. It does seem like the first option is the most straightforward, but I'd be curious to find out what those of you who have deal with the problem for a while would recommend. Purity all the way, or are there patterns that can give you the best of both worlds? Or what else? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] Blackwater 0.0.8
https://github.com/bitemyapp/blackwater Single-line SQL query formatting, separate Korma and c.j.j namespaces, ability to use a custom fn with set-logger! now as well. Any additional feature requests/changes should continue to hit the Github issues. Cheers all. --- Chris -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How do you configure your Ring apps?
I use environ as well. I don't use config files and don't think they're a great idea. Instead I use a simple config.clj that pulls stuff from environ into one big get-config map. I use (or (env :env-var) fallback-value) for each variable. On Saturday, September 7, 2013 4:53:25 PM UTC-7, Alexandr Kurilin wrote: I'm curious to find out how you folks decided to organize configuration for your Ring applications, assuming you also use configuration management like Puppet/Ansiblet etc to deploy them. So far I've been using a combination of daemontools' envdir (through runit) + weavejester's environ https://github.com/weavejester/environfor things like db address, db password, cookie secret keys, logging level etc. Each one is an individual file in root-only folder that runit envdirs from. I honestly can't decide whether a single configuration file (YAML, EDN, whatever) would be more appropriate for this scenario or if I should go ahead and continue keeping each configuration value in its own file and use env to load them. What are people's thoughts on this? Any reason why one or the other would be better, or is there an even better option out there I'm not considering? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Building a CRUD based web application using datomic
Thanks so much for this, I'll use it to teach people. :) On Saturday, September 7, 2013 3:42:33 PM UTC-7, Mamun wrote: Hi Building a CRUD based web application using datomic. It might help some one who are just start using datomic to build CRUD based web application. URL: https://github.com/Mamun/clojure-web-app.git Application feature- Web Authentication CRUD view for domain object Pagination for list view Upload data, display graph chart log as data Application lib- Datomic, Compojure, Enlive, Clojure-Script, Friends, incanter Interactive development both clojure and clojure-script using https://github.com/Mamun/emacs-live-clojure-workflow BR, Mamun -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Introducing a new SQL migration library for clojure / jdbc
This looks pretty nice, I might try this out instead of using my standby Migratus. Thanks for sharing! On Saturday, September 7, 2013 1:08:40 PM UTC-7, Chris Kuttruff wrote: Alexandr, Thanks so much for the feedback; really glad others are finding this useful as well. I've just published a 0.2.0 version with support for multiple environments (Just use an ENV=test type flag when invoking the plugin command, and have a corresponding :database-test config in your project.clj). Also added support for rollinback mult. migrations (eg: lein clj-sql-up rollback 3) I've pushed the new version to clojars and updated the README, etc on github (https://github.com/ckuttruff/clj-sql-up) Thanks again; please let me know if you have any issues or would like to see other functionality included, -Chris On Saturday, September 7, 2013 12:27:21 AM UTC-7, Alexandr Kurilin wrote: This is great, thanks for making it. There was nothing quite like that I could find back when I started on our web app, so I ended using standalone_migrationshttps://github.com/thuss/standalone-migrations, which is essentially ActiveRecord's Migration module extracted for standalone use. Right now it has the advantage over clj-sql-up of supporting multiple environments, but it does unfortunately force you to have ruby support a Gemfile etc, which isn't as awesome as doing everything through clojure. I'll be following clj-sql-up's progress :) On Saturday, July 20, 2013 6:35:29 PM UTC-7, Plinio Balduino wrote: Thank you, Chris I think it will be very useful for my next project. Regards Plínio On Sat, Jul 20, 2013 at 7:19 PM, Chris Kuttruff kutt...@gmail.comwrote: When starting a project to create a clojure blog with ring/compojure/hiccup, I quickly found myself looking for an SQL migration library to use. There are some interesting projects out there, but I found myself wanting the following features: - A standard up/down migration method setup (so I could execute multiple migrate/rollback statements within a clojure file) - The ability to execute arbitrary SQL (including creation of triggers/stored procedures) - A generic structure to support as many databases as possible - A simple create method (to generate migration files) I have used other migration setups (eg: rails), and was looking for something similar in terms of features and simplicity of usage. The following leiningen plugin is my attempt to accomplish the aforementioned objectives as simply as possible: https://github.com/ckuttruff/clj-sql-up I am new to clojure / leiningen, so any suggestions / feedback would be much appreciated. It's still very much a work in progress; I plan to add many more tests, clean up some of the repetition/inelegance, and make various aspects more generic. Thanks for your time and consideration; I hope this library can be of use to others. -Chris -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Blackwater 0.0.5 released (SQL query logging)
You can use it in production, but I'd override the ansi boolean to shut off the special characters for coloration. Set *use-ansi* to false in the clansi namespace. I said not to use it in production because I assumed most people weren't doing `stdout log_file` in prod, but if you are, go for it. On Saturday, September 7, 2013 12:14:47 AM UTC-7, Alexandr Kurilin wrote: This is awesome, thanks for making it, will try to integrate it asap. I'm not a Korma user, so it'll be good to see how well it plays with clojure jdbc. Just to confirm, is the recommendation to use this only at development time? It's been a while since Rails and I don't recall if they turn off SQL logging in production mode. On Friday, August 30, 2013 9:46:43 AM UTC-7, Christopher Allen wrote: https://github.com/bitemyapp/blackwater/ Clojure library for logging SQL queries and the time they took for Korma and clojure.java.jdbc. I like having a 'canary in the coal mine' while developing locally so that I can see the queries getting executed and the time they took to run, similar to Rails query logging. The library stands alone although this imports specific (recent) versions of c.j.j and Korma, exclude and replace as you need to. Some users to help me shake this out beyond how I use it (I'm primarily a Korma guy) would be very useful, Github Issues and PRs very welcome! Thanks everybody. I've got another library to announce once a friend helps me do some testing with it. --- Chris -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] Blackwater 0.0.5 released (SQL query logging)
https://github.com/bitemyapp/blackwater/ Clojure library for logging SQL queries and the time they took for Korma and clojure.java.jdbc. I like having a 'canary in the coal mine' while developing locally so that I can see the queries getting executed and the time they took to run, similar to Rails query logging. The library stands alone although this imports specific (recent) versions of c.j.j and Korma, exclude and replace as you need to. Some users to help me shake this out beyond how I use it (I'm primarily a Korma guy) would be very useful, Github Issues and PRs very welcome! Thanks everybody. I've got another library to announce once a friend helps me do some testing with it. --- Chris -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
