Purely technical feature comparison seems good for shortlisting options.
How about making a selection criteria that the solution has been proven
itself as a primary platform by one of the communities we admire.
Possible benefits:
* Subtle features inherent in platforms will have played a role
I'm interested to see any discussion regarding this point. No doubt
translating spec data into more friendly formats has been discussed.
Getting the data right is clojure's problem. That's the concrete
foundation and building blocks required for tooling. Seems like Rich has
done spectacular
the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/jcVnjk1MOWY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For mor
> Do you find it frustrating that there's no way to turn on instrumentation
> of function outputs for manual testing?
Yes.
In particular when I'm refactoring code and want to know when I'm returning
something surprising.
I haven't yet had much success with spec generators for CLJS / UI
nt to change only one of them (probably foreign-key). I
> wouldn't want him to need to define a new record with all the conventions
> (foreign-key, private-key) in such case. Or did I get it wrong?
>
> On Thursday, March 31, 2016 at 2:59:56 AM UTC+2, Oliver George wrote:
>>
&
I look forward to pre/post conditions becoming more helpful. Truss is a
good example of how things can improve. I think part of the challenge is
not making the code too messy.
Here's a proof of concept of how metadata in the pre/post/assert expression
could be used to craft nice messages:
(d
an-a-table-name).
>
>
>
> @Oliver George: your example with SupervisorId, AnalystId would work now,
> but have in mind that postgreSQL by default lowercases column names, so I'd
> still recommend supervisor_id and analyst_id.
>
> Cheers,
> Krzysiek
>
> On Tuesday, Ma
Hi All
This is a little script to producing nicer errors from asserts and pre/post
conditions in your clojure code. Examples below, gist includes a readme
with some notes. I think the pre/post conditions are the biggest win.
Can anyone tell me how to do a similar "assert patch" technique for
gt; about the idea.
>
> Cheers,
> Krzysiek
>
> On Tue, Mar 1, 2016 at 6:03 AM, Oliver George > wrote:
>
>> Awesome, thanks.
>>
>> I did a little research last night looking for techniques for turning
>> recursive queries into efficient SQL queries.
n't have a
> clear idea about how to do it well yet.
>
> Cheers,
> Krzysiek
>
> On Monday, February 29, 2016 at 12:54:31 PM UTC+8, Oliver George wrote:
>>
>> Oops, one more.
>>
>> There was also a Users table (Id, Username, ...)
>>
>>
Oops, one more.
There was also a Users table (Id, Username, ...)
I didn't see a way to handle join from Races to Users based on SupervisorId
and AnalystId.
On Monday, 29 February 2016 15:52:48 UTC+11, Oliver George wrote:
>
> Thanks for the details.
>
> I did a little exp
7;t find similar
> libraries in clojure. I mentioned ActiveRecord in README mostly because of
> the wording in types of relations, but even ActiveRecord is very far from
> Relational Mapper (it's much bigger, and has features that go way beyond
> simple relational mapping).
&g
Seems pretty nice to me. Like a light weight version of the Django's
migrate and queryset features which build on model definitions.
It seems like this would allow me to define a database schema (tables,
relations and fields) as data and use it to both create the database and
run select/inser
Thanks David. That worked a treat.
For anyone curious, I've added my working code below.
;;
(ns drag
(:require [goog.math :as math]
[goog.fx :as fx]
[goog.fx.Dragger :as Dragger]
[goog.dom :as dom]
[goog.style :as styl
14 matches
Mail list logo
