Re: how to send SSL certificate in POST request?

[Michael Ball]

I had to do the same several months ago. You will need to create a java key 
store with the certificate. Once you have a keystore,  here's the clj-http 
docs on how to include it in an http request.

https://github.com/dakrone/clj-http#keystores-trust-stores

(client/post "https://example.com"; {:keystore "/path/to/keystore.ks"
:keystore-type "jks" ; default: jks
:keystore-pass "secretpass"})





I don't know if it's much use to you but here's how I created the keystore 
using openssl first to convert to pkcs12 then the java keytool to build the 
keystore. 

openssl pkcs12 -export -in cert.pem -inkey "private_key.pem" -certfile 
> cert.pem -out keystore.p12
>
 

> keytool -importkeystore -srckeystore keystore.p12 -srcstoretype PKCS12 
> -destkeystore keystore.jks
>
 

> keytool -import -alias ejbca -keystore keystore.jks -file 
> VDPCA-Sandbox.pem -storepass password








On Tuesday, February 21, 2017 at 3:36:41 PM UTC-8, Pierre Masci wrote:
>
> Hi, I am new to Clojure and using clj-http for the first time, to 
> implement a REST client.
> I don't find anywhere how to indicate where my SSL certificate is located.
> Here is what I did:
>
> (ns my-client.core
>   (:require [clj-http.client :as client]
> [clojure.pprint :refer :all]))
>
> (def my-appkey "...")
>
> (defn login [username password appkey]
>   (client/post "https://.../api/certlogin";
>{:headers {"X-Application" appkey
>   "Content-Type" 
> "application/x-www-form-urlencoded"}
> :form-params {"username" username "password" password}}))
>
> (defn -main []
>   (pprint (login "..." "..." my-appkey)))
>
>
> This sends me back a response which indicates that I need to send the SSL 
> certificate.
> When I send the same request with curl and indicate the certificates, it 
> works. This is the successful curl request:
>
> curl -q -k --cert client-2048.crt --key client-2048.key 
> https://.../api/certlogin 
> -d "username=...&password=..." -H "X-Application: ..."
>  
>
>
>

-- 
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: Clojure support for Visual Studio Code

[Michael Ball]

On Tuesday, September 20, 2016 at 1:53:31 AM UTC-7, Andrey Lisin wrote:
>
> 2. I will investigate if it is possible to run repl from within VSCode. On 
> the other hand, this behavior can be unexpected for some users. I believe, 
> many users are willing to connect to a remote repl and need an explicit way 
> to say which repl they want to use. Also note that if you open a Leiningen 
> project and repl is running in console the extension will automatically 
> connect to it.
>

I would say don't waste time on starting the repl from within vscode, and 
it's probably best to not support it at all. I only mentioned because it 
was a bit unclear coming from LightTable on the procedure of how to start 
and connect to a repl.

My preference is to run repl's outside because it's easier to then use 
something like boot-clj to run a repl, to connect to a repl in a local 
docker dev container, and as you mention connect to remote repl's as well.


 

> 3. I added an output channel for evaluation results in the latest 
> extension version. You can try it out. I will investigate other options 
> though.
>
 
Tried it out and it's working 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
--- 
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: Clojure support for Visual Studio Code

[Michael Ball]

>
> On Saturday, September 17, 2016 at 4:32:39 AM UTC+6, Michael Ball wrote:
>>
>>
>> - Explicit docs/instructions on how to start and connect to the repl 
>> would be good. I was able to get it connected but it was unclear if the 
>> repl should be started from within VS code, or from a terminal then only 
>> connect to it from VS code.
>>
>
> The instructions can be found in the "How to Use?" section of readme file. 
> Not sure I understand your point about where the repl should be started. Do 
> you mean you mean you expected repl will be run by VSCode on connect like 
> it happens in Emacs?
>

Yes, in LightTable and Cider generally the repl is started up from within 
the editor, and it was unclear if there was an editor action that would do 
this, or if the repl needed to be started in a terminal, then connected to.



- Docstrings don't seem to work for thread first  (-> xxx)? I also noticed 
>> that it took some time after initial repl connect for the docstrings to 
>> become available, probably some indexing delay because my laptop is 
>> old+slow, initially they showed "Docstring not found". Also the docstring 
>> not found message pops up for all characters on hover of mouse over things 
>> such as parenthesis.
>>
>
> You're right about the thread first docstring. It looks like I need to 
> adjust the regex for finding Clojure words. Will fix it soon.
>
> About docstrings. There shouldn't be snoticable time between pointing a 
> thing and getting its documentation. However, the is a subtly aspect you 
> should be aware of. If you have a namespace definition in the beginning of 
> a file you should eval the file first. Say, you have a file with the 
> following content:
>
> (ns foo)
>
> (println "Hello World")
>
>  When you point println you won't see the docstring. The reason is the 
> extension sends the following message to the repl: "Give me a docstring for 
> the function println from foo namespace." But at the moment repl *know 
> nothing *about foo namespace! So you neen to eval the file. This will 
> result adding foo namespace to the repl and importing everything from 
> clojure.core namespace to it (this is a sideeffect of ns macro). I believe, 
> this is the common behaviour for all solutions based on cider-nrepl (I've 
> checked it is true for Emacs Cider and Vim Fireplace). Though I admit it's 
> not the most intuitive one. So I'm open to suggestions.
>

Ah, you're probably right on the eval. Also was thinking that perhaps 
doc-string could/should be shown on a keystroke instead of mouse-over?


 

> - If I had one feature request it would be for inline results a-la 
>> LightTable. Any plans for something like that?
>>
>
> It's definetly a useful feature and I can add it easily. The only thing 
> I'm not sure about is where to show an evaluation result :) Do you have any 
> ideas. Maybe you've seen the similar feature in other VSCode plugins and 
> know how to do it right?
>

I don't know if there's a really good way to do it right now, but in some 
very timely news just this morning a feature got some attention and we 
hopefully should see it in October. Probably should watch this issue and 
then use whatever they come up with. You could comment on that issue with 
your use case as jrieken requested.

https://github.com/Microsoft/vscode/issues/3220#issuecomment-248040912


You might also have look at LightTable(my personal favorite for inline 
results), and atom proto-repl for ideas on how to add inline results. In 
proto-repl, I have to admit for larger data-structures, the expandable 
data-structure inspector looks pretty nice. 
https://atom.io/packages/proto-repl

-- 
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: Clojure support for Visual Studio Code

[Michael Ball]

Hi Ikuru, did you install VS code from your package manager and install the 
code-oss package? 

I ask because when I first installed VS code on Solus Linux I used the one 
from the package manager which was the "code-oss package". Unfortunately I 
found out later that extensions are not supported in the code-oss version. 

I had to download the .tar.gz version of VS Code package directly 
(https://code.visualstudio.com/download), install manually, then extensions 
worked great.





On Saturday, September 17, 2016 at 5:52:47 PM UTC-7, Ikuru Kanuma wrote:
>
> Thanks for the reply Andrey!
>
> I guess the installation part is then something specific to the ubuntu 
> flavor(I am using ubuntu-mate) I am using/ what ever it could be.
> (I also did try to open the file from the menu, but same story as dragging 
> and dropping).
> Also my vs-code installation is a bit suspicious, so I will look up other 
> trouble shooting resources.
> Thanks anyways!
>
> Regarding the dependency part, I meant that in cider(on emacs)
> I do not have to specify any of those dependencies by my self because it 
> is handled when I start a repl from cider.
> https://github.com/clojure-emacs/cider/pull/1552 and thought it would be 
> a great improvement.
>
>

-- 
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: Clojure support for Visual Studio Code

[Michael Ball]

Ok was just able to try it out briefly on OSX.

- Installation went smoothly, no problems.

- Explicit docs/instructions on how to start and connect to the repl would 
be good. I was able to get it connected but it was unclear if the repl 
should be started from within VS code, or from a terminal then only connect 
to it from VS code.

- The commands in the command pallet could be prefixed with a "clj: " or 
perhaps "clojure: " or something like that. Other plugins I've used(e.g. 
elm) do this so it's easy  to know which commands are associated with the 
extension and which are part of the editor.

- code completion is working just fine.

- Docstrings don't seem to work for thread first  (-> xxx)? I also noticed 
that it took some time after initial repl connect for the docstrings to 
become available, probably some indexing delay because my laptop is 
old+slow, initially they showed "Docstring not found". Also the docstring 
not found message pops up for all characters on hover of mouse over things 
such as parenthesis.

- I found a command to eval the entire file which worked good. Is there a 
way to send selected expressions to a repl yet?

- If I had one feature request it would be for inline results a-la 
LightTable. Any plans for something like that?


Overall this is a great start, thank you very much for getting the ball 
rolling and building this extension!




On Thursday, September 15, 2016 at 10:03:40 AM UTC-7, Michael Ball wrote:
>
> This looks great, will definitely try it out this weekend!
>
>
> On Thursday, September 15, 2016 at 4:17:38 AM UTC-7, Andrey Lisin wrote:
>>
>> Hey guys,
>>
>> I've been working on Clojure support for Visual Studio Code text editor 
>> for a while. The first version is very close to the point when it can be 
>> published to Visual Studio Code marketplace, but I would like to test it a 
>> bit more before. Maybe there are Visual Studio Code uses here who can try 
>> the extension and give feedback.
>>
>> Features extension supports:
>>
>> - code completion
>> - interaction with REPL
>> - go to definition
>> - documentation hints
>>
>> The extension can be obtained from its GitHub page (
>> https://github.com/avli/clojureVSCode/releases). Download the vsix file 
>> and drag-and-drop it to the Visual Studio Code. The extension relies on 
>> cider-nrepl, so don't forget to add it to the dependencies list. To connect 
>> to nREPL use "Connect to nREPL" command from the command palette. More 
>> information is available on the extension's GitHub page.
>>
>> Hope it be useful for someone.
>>
>>

-- 
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: Clojure support for Visual Studio Code

[Michael Ball]

This looks great, will definitely try it out this weekend!


On Thursday, September 15, 2016 at 4:17:38 AM UTC-7, Andrey Lisin wrote:
>
> Hey guys,
>
> I've been working on Clojure support for Visual Studio Code text editor 
> for a while. The first version is very close to the point when it can be 
> published to Visual Studio Code marketplace, but I would like to test it a 
> bit more before. Maybe there are Visual Studio Code uses here who can try 
> the extension and give feedback.
>
> Features extension supports:
>
> - code completion
> - interaction with REPL
> - go to definition
> - documentation hints
>
> The extension can be obtained from its GitHub page (
> https://github.com/avli/clojureVSCode/releases). Download the vsix file 
> and drag-and-drop it to the Visual Studio Code. The extension relies on 
> cider-nrepl, so don't forget to add it to the dependencies list. To connect 
> to nREPL use "Connect to nREPL" command from the command palette. More 
> information is available on the extension's GitHub page.
>
> Hope it be useful for someone.
>
>

-- 
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: Avoiding nested ifs...

[Michael Ball]

I use a little short circuited threading macro to deal with this. Here's a 
gist with the macro named short-> and how I would write out your first 2 
validation steps.

https://gist.github.com/mikeball/10cc64fe97c119671918fb2d1d8b4118



The new spec stuff looks really interesting, haven't had a chance to look 
into it yet.




On Thursday, May 26, 2016 at 7:50:24 AM UTC-7, John Szakmeister wrote:
>
> I'm very much a fan of bailing out early in imperative 
> programming as it helps to avoid a bunch of nested if conditions 
> that are to follow and read.  This typically comes up when 
> checking arguments to ensure that they're valid (in range, of 
> acceptable values, etc).  One of the major stumbling blocks 
> I've had when writing Clojure is to find a good way to keep code 
> concise, but readable. 
>
> For instance, take a snippet like this: 
>
> def verify_position(pos, type): 
> # It's acceptable to have a None value--it just means don't 
> # change the position for the axis. 
> if pos is None: 
> return True 
>
> # Anything outside our limits is invalid. 
> if (pos > 90) or (pos < 0): 
> return False 
>
> if type == 'switched' and pos not in (0, 90): 
> # Switched axes only allow 0 and 90, and nothing in 
> # between. 
> return False 
>
> if type == 'dual': 
> # We can't control the value on this axis, so anything 
> # other than None is invalid. 
> return False 
>
> return True 
>
>
> I find this very readable in that along the way, I can start 
> throwing things off the raft: after the first condition, I don't 
> need to worry about None being present.  After the second, I 
> know the value is within limits, etc.  I have a hard time 
> translating the above into (what I believe) is readable Clojure. 
> Here's my stab at it: 
>
> (defn verify-pos [pos axis-type] 
>   (if (nil? pos) 
> ;; nil means don't move the axis. 
> true 
> (case axis-type 
>   ;; Only 0 and 90 are allowed on a switched axis. 
>   "switched" (or (= pos 0) 
>  (= pos 90)) 
>
>   ;; Any non-nil value is disallowed on dual. 
>   "dual" false 
>
>   ;; Otherwise, make sure we're within a valid range. 
>   (and (<= pos 90) 
>(>= pos 0) 
>
> Now, this was a rather simple example, but you can see some of 
> the nesting starting.  Add in another condition like 
> nil?--something that is somewhat global across the different 
> types--and you get another level of nesting in there. 
>
> I can break it up more: 
>
> (defn verify-range [pos axis-type] 
>   (case axis-type 
> ;; Only 0 and 90 are allowed on a switched axis. 
> "switched" (or (= pos 0) 
>(= pos 90)) 
> ;; Any non-nil value is disallowed on dual. 
> "dual" false 
> ;; Otherwise, make sure we're within a valid range. 
> (and (<= pos 90) 
>  (>= pos 0 
>
> (defn verify-pos [pos axis-type] 
>   (or (nil? pos) 
>   (verify-range pos axis-type))) 
>
> And this is a bit better, but you run up against another issue: 
> coming up with good names for each part of the whole so that you 
> can combine them.  And, coming up with names that don't sound so 
> similar that folks have to dig into the implementation to know 
> which one is the correct one (I feel the above break up has this 
> problem). 
>
> In some cases, the error checking logic is really 
> complicated--because the thing being controlled has complex 
> restrictions that are out of my control--and the nesting of if 
> conditionals is maddening.  Having to come up with names for 
> each of them would be more than twice as frustrating, as the 
> individual bits don't lend themselves to good names. 
>
> Then there's the issue of combining the verification and the 
> actual work into a useful function, where you need to verify and 
> then act on it: 
>
> (defn set-position [pos type] 
>   (if (verify-pos pos type) 
> (send-position-to-equip pos) 
> (do-something-for-invalid-input))) 
>
> Again, this is a simple example, but more complicated cases have 
> more to check, and therefore more nesting of if statements, 
> where the early bail technique leaves the flow pretty readable. 
> I also realize pre- and post- conditions might be useful, but I 
> don't feel they're appropriate when validating user 
> input--especially not assertion errors, which we generally think 
> of programming errors, not user input errors. 
>
> I realize some of this may be me and shaping my mind more to 
> functional programming, though I do feel like I have a decent 
> grasp of it.  I've been dabbling in Clojure for several years, 
> and have more recently incorporated ClojureScript into a project 
> for our web front-end.  However, I feel like I might be missing 
> an important strategy for this kind of problem, and I'm hoping 
> that one of you can point me in a good direction.  And please 
> don't get hung up on this e

Re: Porting Clojure to Native Platforms

[Michael Ball]

Not JVM based but I've been wondering about ClojureCLR on top of the new 
CoreCLR might be a potential path for native. There's a native compiler in 
the works (a brief mention a couple weeks ago in the standup 
https://youtu.be/cfxuJsZIK4A?t=1h13m32s). 

I have to say with the MIT license, tail call support, native compilation, 
and the open development CoreCLR could have a bright future as a host 
platform, even though it's not nearly as widely used as the JVM today.







On Monday, April 25, 2016 at 12:47:21 PM UTC-7, JvJ wrote:
>
>
>
> I've been wondering lately about getting Clojure to compile to native 
> code, and so I've been doing some looking around.
>
> There are a few projects that are on the right track, such as TinyClojure 
>  and Ferret 
> , 
> but they are incomplete and don't seem to be under active development any 
> more.
>
> I'm wondering about the requirements, how much work it would take, and 
> whether or not it would be worth it.  My current thinking is of a 
> Clojure->C/C++ compiler.
>
> So far, I have a few topics for discussion that I'm unclear about that 
> might be necessary for this kind of project:
>
>- Can the Immutable Persistent Data Structures be implemented with a 
>reference-counting scheme rather than a garbage collector?  This may 
>improve performance.
>- In a similar vein, can the allocation strategy be controlled for 
>these structures in such a way as to optimize cache locality?
>- Can we take advantage of tail-call optimization in existing C++ 
>compilers?
>- It wouldn't have to depend on an existing runtime environment like 
>JVM or JavaScript.
>   - Could this reduce reliance on reflection and increase performance?
>   - Could a new, clojure-optimized runtime be created that improves 
>   performance?
>- Could certain anonymous functions be optimized or inlined in a way 
>that improves performance over JVM/JS implementations?
>- Is there a way to compile C++ code at runtime?  This would be 
>essential for the REPL and for Macros.
>
>
> Let me know if anyone has any thoughts on the matter.
>
> Thanks
>

-- 
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: [ANN] Ticket - an encrypted ticket/cookie library

[Michael Ball]

I haven't, but definitely will look into macaroon for ideas.


On Thursday, February 11, 2016 at 11:44:42 AM UTC-8, Ghadi Shayban wrote:
>
> Btw, ever looked at Macaroons?  Apparently Google uses them internally.
>
> http://research.google.com/pubs/pub41892.html
> http://hackingdistributed.com/2014/05/21/my-first-macaroon/
>
> Ghadi
>
> On Thursday, February 11, 2016 at 1:29:56 PM UTC-5, Michael Ball wrote:
>>
>> Thanks! Yes I looked at JWE, but it just seemed a bit heavy for the need 
>> to only store a simple identifier. Interoperability isn't a concern, as 
>> tickets rarely if ever shared. I just wanted a simple self contained and 
>> easy to use way to package and retrieve identifiers with appropriately 
>> chosen encryption and signing algorithms for the common web-app case.
>>
>>
>> On Thursday, February 11, 2016 at 1:36:53 AM UTC-8, Andrey Antukh wrote:
>>>
>>> Hi Michael!
>>>
>>> Firstly: nice work!
>>>
>>> Do you know about JWE? It does just the same thing but in a 
>>> standarized/interoperable way: 
>>> https://funcool.github.io/buddy-sign/latest/#introduction
>>>
>>> Andrey
>>>
>>> On Thu, Feb 11, 2016 at 8:21 AM, Michael Ball  wrote:
>>>
>>>> Ticket helps create and read encrypted tickets/cookies with expiration 
>>>> dates packaged inside. Feedback and security reviews are welcomed.
>>>>
>>>> https://github.com/mikeball/ticket
>>>>
>>>> Mike
>>>>
>>>> -- 
>>>> 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.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Andrey Antukh - Андрей Антух - 
>>> http://www.niwi.nz
>>> https://github.com/niwinz
>>>
>>

-- 
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: [ANN] Ticket - an encrypted ticket/cookie library

[Michael Ball]

Thanks! Yes I looked at JWE, but it just seemed a bit heavy for the need to 
only store a simple identifier. Interoperability isn't a concern, as 
tickets rarely if ever shared. I just wanted a simple self contained and 
easy to use way to package and retrieve identifiers with appropriately 
chosen encryption and signing algorithms for the common web-app case.


On Thursday, February 11, 2016 at 1:36:53 AM UTC-8, Andrey Antukh wrote:
>
> Hi Michael!
>
> Firstly: nice work!
>
> Do you know about JWE? It does just the same thing but in a 
> standarized/interoperable way: 
> https://funcool.github.io/buddy-sign/latest/#introduction
>
> Andrey
>
> On Thu, Feb 11, 2016 at 8:21 AM, Michael Ball  > wrote:
>
>> Ticket helps create and read encrypted tickets/cookies with expiration 
>> dates packaged inside. Feedback and security reviews are welcomed.
>>
>> https://github.com/mikeball/ticket
>>
>> Mike
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> Andrey Antukh - Андрей Антух - >
> http://www.niwi.nz
> https://github.com/niwinz
>

-- 
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.

[ANN] Ticket - an encrypted ticket/cookie library

[Michael Ball]

Ticket helps create and read encrypted tickets/cookies with expiration 
dates packaged inside. Feedback and security reviews are welcomed.

https://github.com/mikeball/ticket

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
--- 
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.

[ANN] Foundation 0.1.0 - postgresql data access

[Michael Ball]

Foundation is a data access library focused on full support of postgres 
features and ease of use. Presently it supports common datatypes, execution 
of multiple statements, template queries with dynamic sections, a 
lightweight dsl for insert/update/deletes, and more. 

https://github.com/mikeball/foundation

Feedback is welcomed.

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
--- 
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: State Change Listener in Clojure on a Database

[Michael Ball]

I've had this working a few months ago using 
http://impossibl.github.io/pgjdbc-ng/. Here's the clojure used.

https://gist.github.com/mikeball/ba04dd5479f51c00205f

I don't have time to test this now, but it should get you started.













On Monday, October 19, 2015 at 8:06:01 AM UTC-7, Adrian Cooley wrote:
>
> Hi all,
>
> I'm new to Clojure and I've been exploring the possibility of using it to 
> handle a large list of Users stored in a Postgresql Database. I can see 
> that there are some great sql libraries for clojure to query a Postgresql 
> database and this is fine. However, I was wondering if there are any useful 
> Clojure features or libraries that could allow me to 'listen' for changes 
> to a Users Table in the Database. A use case scenario to describe what I 
> want would be as follows: Say someone registers their details on a website 
> and their details are persisted to the Database. I then want some process 
> to pick up that a new user is now in the database and send this user 
> information to a client that has registered to listen for new users. Is 
> something like this possible in Clojure where it can handle listening to 
> state changes and trigger a notification? Thanks in advance to anyone who 
> chimes in with advice,
>
> Regards,
> Adrian.
>

-- 
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: Rich Hickey quote on immutability

[Michael Ball]

It might be his Clojure/West 2012 presentation on Datomic near the very end.

"Choose immutability and see where it takes you."

http://www.infoq.com/presentations/The-Design-of-Datomic





On Monday, April 1, 2013 9:33:37 AM UTC-7, Alf wrote:
>
> Hey everyone!
>
> I am doing presentation on Clojure and immutability, and I am looking for 
> a quote. I think I remember Rich saying something along the lines of:
>
> "Try going immutable and see where it takes you".
>
> Anyone remember where (or if at all), he said this? And of course, what 
> the exact quote is?
>
> Cheers,
> Alf
>  

-- 
-- 
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.