Re: Project structure when using reader conditionals
I've attempted to catalog my craziness here, https://blog.eventgonegood.com/2015/12/26/project-structure/ On Thu, Dec 31, 2015 at 2:49 PM, Alan Moore wrote: > +1 > > On Dec 31, 2015, at 12:20 PM, Frank Castellucci > wrote: > > Clean... very nice. > > On Wednesday, December 30, 2015 at 8:54:24 AM UTC-5, James Reeves wrote: >> >> My directory structure looks like: >> >> src/foo/client/bar.cljs >> src/foo/common/bar.cljc >> src/foo/server/bar.clj >> >> So I divide code by purpose, but they're all in the same source directory. >> >> - James >> >> On 30 December 2015 at 00:56, Alan Moore wrote: >> >>> Yes it would be handy for small projects but IMO larger applications >>> should be broken up into client and server code. Some might argue for >>> breaking up client and server into separate projects altogether but that >>> begs the question about what to do with the .cljc files that are shared >>> (e.g. put them in shared library(ies)?) Again, this probably depends on >>> codebase size, granularity of your deployment and other considerations >>> beyond just the compiler. >>> >>> For now I'm sticking with keeping the .cljc files in the src/clj tree. >>> I'd like to hear what others are doing as well. >>> >>> Did you ask this on the clojurians slack channel? It seems a lot of the >>> more chatty/Q&A traffic for this list has gone over there. >>> >>> Alan >>> >>> >>> On Friday, December 25, 2015 at 1:00:58 PM UTC-8, Dru Sellers wrote: >>>> >>>> Is it fair to say that the accepted pattern now (with reader >>>> conditionals) is to have a single src/ directory and then letting the file >>>> extension (cljs,clj,cljc) do the heavy lifting rather than having a >>>> directory for each? >>>> >>>> that would be handy if so. >>>> >>>> -d >>>> >>>> >>>> On Friday, May 29, 2015 at 3:10:30 PM UTC-5, Daniel Compton wrote: >>>>> >>>>> When porting a library to reader conditionals, I found that I only >>>>> needed one source directory for all my cljc and .clj files. Cljsbuild just >>>>> picks up the ones it needs and leaves the .clj ones. >>>>> >>>>> So in some cases it may not be necessary to have a clj/, cljs/, and >>>>> cljc/ folder, although in applications this structure might make more >>>>> sense. >>>>> On Fri, 29 May 2015 at 10:31 pm Robin Heggelund Hansen < >>>>> skinn...@gmail.com> wrote: >>>>> >>>>>> No, it doesn't. I update with `lein ancient update :all` and >>>>>> committed without checking if it worked. It's fixed locally :) >>>>>> >>>>>> >>>>>> fredag 29. mai 2015 12.01.32 UTC+2 skrev Colin Yates følgende: >>>>>> >>>>>>> Thanks Robin, that was helpful. I notice that you are using garden >>>>>>> 1.2.6 - that throws a CNF for garden.core and the garden page recommends >>>>>>> not using it - does it work for you? >>>>>>> >>>>>> On 29 May 2015, at 10:49, Robin Heggelund Hansen >>>>>>> wrote: >>>>>>> >>>>>>> Take a look at my project.clj file. >>>>>>> >>>>>>> >>>>>>> https://github.com/Skinney/oslo-programmene/blob/development/project.clj >>>>>>> >>>>>>> fredag 29. mai 2015 11.17.25 UTC+2 skrev Colin Yates følgende: >>>>>>>> >>>>>>>> In the vein of "there are no stupid questions" :), how does one >>>>>>>> structure a combined clj and cljs project that uses reader >>>>>>>> conditionals? At >>>>>>>> the moment I am using cljx and have: >>>>>>>> - src/clj for clojure files >>>>>>>> - src/cljs for clojurescript files >>>>>>>> - src/cljx for cljx >>>>>>>> - target/cljx/clj for clojure files compiled (transpiled?) from >>>>>>>> cljx >>>>>>>> - target/cljx/cljs for clojurescript files compiled (transpiled?) >>>>>>>> from clix >>>>>>>> >>>>>>>> On the source path in cljsbuild for example
Re: Project structure when using reader conditionals
I was also playing around with a few different models. I was looking at something like client and server but probably over thinking it from my static type days: These would just have needed bootstrapping code src/apps/app1 - client app src/apps/app2 - client app src/apps/app3 - server app src/features//bar.cljc src/features//bar.cljc etc -d On Wed, Dec 30, 2015 at 7:53 AM, James Reeves wrote: > My directory structure looks like: > > src/foo/client/bar.cljs > src/foo/common/bar.cljc > src/foo/server/bar.clj > > So I divide code by purpose, but they're all in the same source directory. > > - James > > On 30 December 2015 at 00:56, Alan Moore > wrote: > >> Yes it would be handy for small projects but IMO larger applications >> should be broken up into client and server code. Some might argue for >> breaking up client and server into separate projects altogether but that >> begs the question about what to do with the .cljc files that are shared >> (e.g. put them in shared library(ies)?) Again, this probably depends on >> codebase size, granularity of your deployment and other considerations >> beyond just the compiler. >> >> For now I'm sticking with keeping the .cljc files in the src/clj tree. >> I'd like to hear what others are doing as well. >> >> Did you ask this on the clojurians slack channel? It seems a lot of the >> more chatty/Q&A traffic for this list has gone over there. >> >> Alan >> >> >> On Friday, December 25, 2015 at 1:00:58 PM UTC-8, Dru Sellers wrote: >>> >>> Is it fair to say that the accepted pattern now (with reader >>> conditionals) is to have a single src/ directory and then letting the file >>> extension (cljs,clj,cljc) do the heavy lifting rather than having a >>> directory for each? >>> >>> that would be handy if so. >>> >>> -d >>> >>> >>> On Friday, May 29, 2015 at 3:10:30 PM UTC-5, Daniel Compton wrote: >>>> >>>> When porting a library to reader conditionals, I found that I only >>>> needed one source directory for all my cljc and .clj files. Cljsbuild just >>>> picks up the ones it needs and leaves the .clj ones. >>>> >>>> So in some cases it may not be necessary to have a clj/, cljs/, and >>>> cljc/ folder, although in applications this structure might make more >>>> sense. >>>> On Fri, 29 May 2015 at 10:31 pm Robin Heggelund Hansen < >>>> skinn...@gmail.com> wrote: >>>> >>>>> No, it doesn't. I update with `lein ancient update :all` and committed >>>>> without checking if it worked. It's fixed locally :) >>>>> >>>>> >>>>> fredag 29. mai 2015 12.01.32 UTC+2 skrev Colin Yates følgende: >>>>> >>>>>> Thanks Robin, that was helpful. I notice that you are using garden >>>>>> 1.2.6 - that throws a CNF for garden.core and the garden page recommends >>>>>> not using it - does it work for you? >>>>>> >>>>> On 29 May 2015, at 10:49, Robin Heggelund Hansen >>>>>> wrote: >>>>>> >>>>>> Take a look at my project.clj file. >>>>>> >>>>>> >>>>>> https://github.com/Skinney/oslo-programmene/blob/development/project.clj >>>>>> >>>>>> fredag 29. mai 2015 11.17.25 UTC+2 skrev Colin Yates følgende: >>>>>>> >>>>>>> In the vein of "there are no stupid questions" :), how does one >>>>>>> structure a combined clj and cljs project that uses reader >>>>>>> conditionals? At >>>>>>> the moment I am using cljx and have: >>>>>>> - src/clj for clojure files >>>>>>> - src/cljs for clojurescript files >>>>>>> - src/cljx for cljx >>>>>>> - target/cljx/clj for clojure files compiled (transpiled?) from cljx >>>>>>> - target/cljx/cljs for clojurescript files compiled (transpiled?) >>>>>>> from clix >>>>>>> >>>>>>> On the source path in cljsbuild for example I have src/cljs and >>>>>>> /target/cljx/cljs >>>>>>> >>>>>>> To remove cljx and use reader conditionals is it sufficient to: >>>>>>> - replace src/cljx with src/cljc >>>>>>> - remove target/cljx from cljsbuild source path
Re: Project structure when using reader conditionals
Is it fair to say that the accepted pattern now (with reader conditionals) is to have a single src/ directory and then letting the file extension (cljs,clj,cljc) do the heavy lifting rather than having a directory for each? that would be handy if so. -d On Friday, May 29, 2015 at 3:10:30 PM UTC-5, Daniel Compton wrote: > > When porting a library to reader conditionals, I found that I only needed > one source directory for all my cljc and .clj files. Cljsbuild just picks > up the ones it needs and leaves the .clj ones. > > So in some cases it may not be necessary to have a clj/, cljs/, and cljc/ > folder, although in applications this structure might make more sense. > On Fri, 29 May 2015 at 10:31 pm Robin Heggelund Hansen > wrote: > >> No, it doesn't. I update with `lein ancient update :all` and committed >> without checking if it worked. It's fixed locally :) >> >> >> fredag 29. mai 2015 12.01.32 UTC+2 skrev Colin Yates følgende: >> >>> Thanks Robin, that was helpful. I notice that you are using garden 1.2.6 >>> - that throws a CNF for garden.core and the garden page recommends not >>> using it - does it work for you? >>> >> On 29 May 2015, at 10:49, Robin Heggelund Hansen >>> wrote: >>> >>> Take a look at my project.clj file. >>> >>> https://github.com/Skinney/oslo-programmene/blob/development/project.clj >>> >>> fredag 29. mai 2015 11.17.25 UTC+2 skrev Colin Yates følgende: In the vein of "there are no stupid questions" :), how does one structure a combined clj and cljs project that uses reader conditionals? At the moment I am using cljx and have: - src/clj for clojure files - src/cljs for clojurescript files - src/cljx for cljx - target/cljx/clj for clojure files compiled (transpiled?) from cljx - target/cljx/cljs for clojurescript files compiled (transpiled?) from clix On the source path in cljsbuild for example I have src/cljs and /target/cljx/cljs To remove cljx and use reader conditionals is it sufficient to: - replace src/cljx with src/cljc - remove target/cljx from cljsbuild source path - add src/cljc to cljsbuild source path - add src/cljc to leiningen source path Thanks! >>> >>> -- >>> 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/d/optout. >>> >>> -- >> 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/d/optout. >> > -- 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/d/optout.
Docs for the lein :project/dev :env keys
I'm looking at duct ( https://github.com/weavejester/duct/blob/master/lein-template/resources/leiningen/new/duct/base/project.clj#L63) and I'm pretty sure I understand what is going on there, but I haven't been able to find any documentation on what is all possible with this key. My guess is that :project will modify the project based on the profile selected. so :project/dev is about changing the project when the profile :dev is active and then in this case we are setting the environment variable of PORT to 3000. Looking at https://github.com/weavejester/environ/blob/master/lein-environ/src/lein_environ/plugin.clj#L10 it seems the :env key is a part of lein-environ rather than a part of lein itself. Is this a correct understanding? -d -- 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/d/optout.
protocol names - community standards
I am creating a protocol for my entity management and I was going to use the name 'find' but that is a well known core lib function as is 'get'. I was curious if it is common practice to still use those methods or if the collective group have settled on other names for the common 'crud' type methods I'm building something akin to: (defprotocol Database (get [id] "Get the row at id") (find [query] "find the row") (delete [id] "etc") (save [data] "etc") ;etc ) Thanks! -d -- 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/d/optout.
Re: http-kit for duct
It was indeed that easy. Thank for writing component in such a nice way !! -d On Sat, Jun 13, 2015 at 6:22 PM, James Reeves wrote: > It shouldn't be hard to write your own version. You could almost just take > the Jetty component source > <https://github.com/weavejester/ring-jetty-component/blob/master/src/ring/component/jetty.clj> > and > substitute "jetty" with "http-kit". > - James > On 13 June 2015 at 23:51, Dru Sellers wrote: >> Is there any interest in an http-kit version of duct? Or have everyone >> just written their own version? >> >> -d >> >> -- >> 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/d/optout. >> > -- > 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 a topic in the Google > Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/TLYsy4bSOzk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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/d/optout.
Re: http-kit for duct
Nevermind. Jetty comes with the sample server. On Saturday, June 13, 2015 at 5:51:00 PM UTC-5, Dru Sellers wrote: > > Is there any interest in an http-kit version of duct? Or have everyone > just written their own version? > > -d > -- 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/d/optout.
http-kit for duct
Is there any interest in an http-kit version of duct? Or have everyone just written their own version? -d -- 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/d/optout.
Re: Actually using component.
I really am dense at times. :(
I was confusing the 'component' for the system map in this
line:
https://github.com/weavejester/duct/blob/master/duct/src/duct/component/endpoint.clj#L6
#PalmToFace
-d
On Tuesday, June 9, 2015 at 5:57:48 PM UTC-5, James Reeves wrote:
>
> On 9 June 2015 at 23:16, Dru Sellers >
> wrote:
>
>> @James do you only have one component that has all of your routes? or do
>> you have each component supply its own routes? If you imagine a component
>> providing its own routes, I'd love to see a duct example with two routes
>> set up.
>>
>> I believe that would be multiple endpoint components.
>>
>> Looking at
>> https://github.com/weavejester/duct/blob/master/duct/src/duct/component/endpoint.clj#L7
>>
>> I'm guessing that duct only expects one endpoint-component - is that
>> correct?
>>
>
> No, you can have as many endpoint components as you want.
>
> Duct has a handler component that looks for endpoint components in its
> dependencies, and combines their routes together using
> compojure.core/routes.
>
> One of the ideas in Duct is to group routes together by purpose, to
> achieve the modularity of micro-service architecture without the overhead.
>
> For example, let's say you have endpoints foo, bar and baz. Then your
> system builder in Duct would look like:
>
> (defn new-system [config]
> (let [config (meta-merge base-config config)]
> (-> (component/system-map
> :http (jetty-server (:http config))
> :app (handler-component (:app config))
> :foo (endpoint-component foo-endpoint)
> :bar (endpoint-component bar-endpoint)
> :baz (endpoint-component baz-endpoint))
> (component/system-using
> {:http [:app]
> :app [:foo :bar :baz]}
>
> - 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/d/optout.
Re: Actually using component.
@James do you only have one component that has all of your routes? or do
you have each component supply its own routes? If you imagine a component
providing its own routes, I'd love to see a duct example with two routes
set up.
I believe that would be multiple endpoint components.
Looking
at
https://github.com/weavejester/duct/blob/master/duct/src/duct/component/endpoint.clj#L7
I'm guessing that duct only expects one endpoint-component - is that
correct?
-d
On Monday, June 8, 2015 at 8:36:36 PM UTC-5, James Reeves wrote:
>
> My recommendation is to use a closure. So I'd write your example as:
>
> (defn username-endpoint [{:keys [db]}]
> (routes
>(GET "/:username" [username]
> (let [user (users/get-user db username)]
>(str "Hello " (:name user) "")
>
> So you pass your configuration map into the endpoint function, which
> returns a handler.
>
> You can then wrap this in a component:
>
> (defrecord EndpointComponent [build-routes]
> component/Lifecycle
> (start [component]
> (if (:routes component)
> component
> (assoc component :routes (build-routes component
> (stop [component]
> (dissoc component :routes)))
>
> Incidentally, the above code is taken directly from Duct
> <https://github.com/weavejester/duct>, a template and small supporting
> library I've written for building component-based web apps.
>
> I've also written a blog article
> <https://www.booleanknot.com/blog/2015/05/22/structuring-clojure-web-apps.html>
> around
> general best practice for this type of style.
>
> - James
>
>
> On 8 June 2015 at 22:51, Dru Sellers >
> wrote:
>
>> So, I guess I am a bit lost, how does someone actually use component? I
>> have an application all set up with it and it seems to be working as I
>> would expect but Stuart seems to be steering me in a different direction.
>>
>> https://github.com/stuartsierra/component/pull/35
>>
>> https://github.com/stuartsierra/component/issues/34
>>
>> So I'll try and paint a full picture.
>> https://gist.github.com/drusellers/8109dce4b9fb19c14ebb
>>
>> I know compojure and component / reloaded may not play well, but I'm
>> trying to figure out how to best use the system var. Am I close, I'd love
>> to give back a decent PR to the README.md of the component repo to help
>> others as they come along.
>>
>> -d
>>
>> --
>> 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/d/optout.
>>
>
>
--
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/d/optout.
Actually using component.
So, I guess I am a bit lost, how does someone actually use component? I have an application all set up with it and it seems to be working as I would expect but Stuart seems to be steering me in a different direction. https://github.com/stuartsierra/component/pull/35 https://github.com/stuartsierra/component/issues/34 So I'll try and paint a full picture. https://gist.github.com/drusellers/8109dce4b9fb19c14ebb I know compojure and component / reloaded may not play well, but I'm trying to figure out how to best use the system var. Am I close, I'd love to give back a decent PR to the README.md of the component repo to help others as they come along. -d -- 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/d/optout.
Re: Is there a cheet sheet for some of the pure symbolic functions like #'
perfect, thank you. On Fri, Jun 5, 2015 at 3:07 PM, Laurens Van Houtven <_...@lvh.io> wrote: > Hi Dru, > > > I think you're looking for: http://clojure.org/reader > > > hth > lvh > > On Fri, Jun 5, 2015 at 3:05 PM, Dru Sellers wrote: > >> Trying to google what #' means is tricky to say the least. >> >> Is there a good name for these that I can google to read up on them? >> >> Thank you. >> >> -d >> >> -- >> 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/d/optout. >> > > -- > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/aKIa_kbSB2Q/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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/d/optout.
Is there a cheet sheet for some of the pure symbolic functions like #'
Trying to google what #' means is tricky to say the least. Is there a good name for these that I can google to read up on them? Thank you. -d -- 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/d/optout.
Re: OO Programmer trying to move to Clojure: Namespace Organization
Yeah, it wouldn't surprise me if I'm over thinking it too much. But in the model of 'shu-ha-ri' I am still very much in the shu stage so i'm looking for concrete stuff to imitate. :) Thank you everyone for the ideas and thoughts, -d On Saturday, February 7, 2015 at 10:23:43 AM UTC-6, Dru Sellers wrote: > > Greetings, > > I am trying to convert my mind from OO (C#) to one more functionally > friendly. I am increasingly comfortable with simple applications in > clojure, but as I start to build more complex applications, I start to fall > down about how to structure my application. I don't want to just shove OO > ideas into the functional nature of Clojure. I'm looking for any help > someone can provide to help shimmy my brain into the right mental patterns. > > Background: Long time C# developer who leans heavily on IoC / DI / > Interfaces / Testing / Object Encapsulation. > > Specific Questions: Namespace Organization > > Now I know this is almost entirely personal preference, but I'm playing > with a namespace model that looks like this and I'd love some feed back. > Tear it about, bust that red pen out and help me to better think of things > in clojure way. I only have my C# / OO background to lean on and need some > fresh brain juice. :) > > I currently organize my projects like this. a spin off of 'duct' > https://github.com/weavejester/duct but i'm looking for a bit more detail. > > Context: Project name is going to be "ford", feature is going to be a > simple log of text > > > ~/ > src/ > ford/ - the project > log/ - the feature name > http.clj - contains clojure routes at 'http/routes' - orchestrate > the business calls > model.clj - contains my 'defrecords' / yesql / db calls > core.clj - the "business" calls > > > I def have a preference for shorter files rather than longer files > I also tend to have a heavy use of 'ceremony' - right now I need a lot of > structure because I'm still learning to think in terms of clojure. and I > spend a lot of time still reading it rather than thinking about it. > > Again, thank you. > > -d > -- 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/d/optout.
Re: OO Programmer trying to move to Clojure: Encapsulation
Thank you everyone for all of the helpful ideas.
I def like the Component library and I will have to sit down and figure out
how to best work that into my application while it is still young.
All of the links have been consumed and I am starting to absorb more and
more. Thank you for taking the time to share your thoughts and ideas with
me.
-d
On Saturday, February 7, 2015 at 10:07:45 AM UTC-6, Dru Sellers wrote:
>
> Greetings,
>
> I am trying to convert my mind from OO (C#) to one more functionally
> friendly. I am increasingly comfortable with simple applications in
> clojure, but as I start to build more complex applications, I start to fall
> down about how to structure my application. I don't want to just shove OO
> ideas into the functional nature of Clojure. I'm looking for any help
> someone can provide to help shimmy my brain into the right mental patterns.
>
> Background: Long time C# developer who leans heavily on IoC / DI /
> Interfaces / Testing / Object Encapsulation.
>
>
> *Specific Question: Object Encapsulation*
> I feel like my function parameter lists are much "wider" than they would
> be in C#. This is due to the "lack" of a constructor. So if I previously
> had a C# class that looked like:
>
>
> public class AccountRepository : IAccountRepository
> {
> IDatabaseConnection _connection;
>
> public AccountRepository(IDatabaseConnection connection)
> {
> _connection = connection;
> }
>
> public void Save(Account account)
> {
> _connection.Execute("UPDATE accounts SET coupon=@coupon WHERE id=@id",
> { coupon = account.Coupon, id=account.Id});
> }
> }
>
> In the above I have encapsulated the "_connection", the other methods
> don't have to deal with it. In Clojure (especially if you are following
> Sierra's Component pattern) you end up with
>
> (defn save [db account]
> (update db (:coupon account) (:id account))
> )
>
> I end up having to pass this 'db' around all over the place. I think that
> this is just something I'll have to get used to more than anything. Am I
> missing anything?
>
> Thank you for your time.
>
> -d
>
--
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/d/optout.
OO Programmer trying to move to Clojure: Encapsulation
Greetings,
I am trying to convert my mind from OO (C#) to one more functionally
friendly. I am increasingly comfortable with simple applications in
clojure, but as I start to build more complex applications, I start to fall
down about how to structure my application. I don't want to just shove OO
ideas into the functional nature of Clojure. I'm looking for any help
someone can provide to help shimmy my brain into the right mental patterns.
Background: Long time C# developer who leans heavily on IoC / DI /
Interfaces / Testing / Object Encapsulation.
*Specific Question: Object Encapsulation*
I feel like my function parameter lists are much "wider" than they would be
in C#. This is due to the "lack" of a constructor. So if I previously had a
C# class that looked like:
public class AccountRepository : IAccountRepository
{
IDatabaseConnection _connection;
public AccountRepository(IDatabaseConnection connection)
{
_connection = connection;
}
public void Save(Account account)
{
_connection.Execute("UPDATE accounts SET coupon=@coupon WHERE id=@id",
{ coupon = account.Coupon, id=account.Id});
}
}
In the above I have encapsulated the "_connection", the other methods don't
have to deal with it. In Clojure (especially if you are following Sierra's
Component pattern) you end up with
(defn save [db account]
(update db (:coupon account) (:id account))
)
I end up having to pass this 'db' around all over the place. I think that
this is just something I'll have to get used to more than anything. Am I
missing anything?
Thank you for your time.
-d
--
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/d/optout.
OO Programmer trying to move to Clojure: Namespace Organization
Greetings, I am trying to convert my mind from OO (C#) to one more functionally friendly. I am increasingly comfortable with simple applications in clojure, but as I start to build more complex applications, I start to fall down about how to structure my application. I don't want to just shove OO ideas into the functional nature of Clojure. I'm looking for any help someone can provide to help shimmy my brain into the right mental patterns. Background: Long time C# developer who leans heavily on IoC / DI / Interfaces / Testing / Object Encapsulation. Specific Questions: Namespace Organization Now I know this is almost entirely personal preference, but I'm playing with a namespace model that looks like this and I'd love some feed back. Tear it about, bust that red pen out and help me to better think of things in clojure way. I only have my C# / OO background to lean on and need some fresh brain juice. :) I currently organize my projects like this. a spin off of 'duct' https://github.com/weavejester/duct but i'm looking for a bit more detail. Context: Project name is going to be "ford", feature is going to be a simple log of text ~/ src/ ford/ - the project log/ - the feature name http.clj - contains clojure routes at 'http/routes' - orchestrate the business calls model.clj - contains my 'defrecords' / yesql / db calls core.clj - the "business" calls I def have a preference for shorter files rather than longer files I also tend to have a heavy use of 'ceremony' - right now I need a lot of structure because I'm still learning to think in terms of clojure. and I spend a lot of time still reading it rather than thinking about it. Again, thank you. -d -- 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/d/optout.
