
Clojure at a Real Estate Portal - dodders
http://www.pitheringabout.com/?p=1069
======
hackbinary
If anyone is interested, he's talking about onthemarket.com.

[https://www.onthemarket.com/](https://www.onthemarket.com/)

Not sure why he just didn't say it, that information is available elsewhere
anyway.

[https://juxt.pro/](https://juxt.pro/)

[http://blog.juxt.pro/posts/otm.html](http://blog.juxt.pro/posts/otm.html)

------
dmichulke
I use an eerily similar stack with clojure, ring/compojure, http-kit,
java.jdbc + c3p0, timbre and I have to say it's fantastic.

I created a kind of a template with how to organize namespaces around that and
how to address and automatically parse the URL/form parameters depending on
the URL and send a "missing param" or "malformed param" back in the appropiate
cases. It also deals with optional params

The app basically only abstracts away the HTTP Server stuff and calls the
appropriate call in an API namespace (where someone else could hook in if he
wants to use his own server).

Also, I now save all DDL in a separate resources/SQL folder and parse it if I
need to rewrite the DB from clojure (e.g., at initialization after deploy). In
the folder there is a schema.sql in which all other DDL is called via \ir.

Checking whether the current version is the most up to date I still do
manually (so if I add an index to some table in the DB, I add checking for
this index via postgres native tables in the migrated? function) but this will
be automated as well some time in the future.

The reason why I use org.clojure/java.jdbc is because I can use all native
postgres features (arrays, jsonb, tsvector, ...) without using the very weird
java.sql constructors. This is also one of the major points against any
current library.

~~~
yenda
you should replace c3p0 by hikaricp
[https://github.com/brettwooldridge/HikariCP](https://github.com/brettwooldridge/HikariCP)

------
pwm
Semi off-topic, but might helps others as well: What should an experienced OO
dev read to better understand how dynamic FP languages, like Clojure,
alleviate the aforementioned cons of OO in the architecture of large-scale
agile projects? In other words: I know from experience what's the downside of
OO, but I don't know how dynamic FP languages would help without sacrificing
the benefits of OO?

~~~
cies
> the benefits of OO?

For me understanding the greatness of FP was build on the understanding that
there are no "benefits of OO".

Once I realized that the "abstractions of classes and inheritance" and
"encapsulations of state in objects" (and other OO-paradigm pillars) where
harmful, I started truly researching the alternatives.

I could go back to C --imperative, state-all-over-the-place, self-managed
memory-- but it seemed like an impossible step in web development.

Quickly I found promise in languages like Clojure and Haskell. High-level
enough for web development, yet faster them my trusted Ruby code, and
seemingly more maintainable.

The main benefit of OO I know experience is it's popularity. Going from Java
to Ruby is a lot easier then from Ruby to Clojure or Haskell. The good news:
many OO languages are incorporating FP'isms, and allowing a functional
approach to solve problems, this helps FP like myself newcomers quite a bit.

TL;DR: I came to the realisation that the benefits of OO where mainly
theoretical and did not hold in practice. Main 'real' benefit of OO is its
popularity.

~~~
cynicalkane
Alan Kay claimed that the big ideas of OO were polymprhism and encapsulation,
which not only are first-class features of Clojure but one of its main selling
points, via protocols. Haskell type classes support behavior inheritance and
subclassing, with monad subclasses being the preferred way to encapsulate
state.

When people talk about how their favorite FP language is not OO, it raises my
hair a bit and wonder what kind of code this person produces. A Clojure
programmer will throw out some multi-level map reduce that abstracts over
arbitrary sequences and then jam an ordered tree map into it, and claim it's
not OO. And I'm like, what do you think polymorphism and encapsulation are?

~~~
cies
Thanks for your reply.

I guess my wording is not entirely accurate. I meant OO-class-based-
inheritance and OO-class-based-encasulation-of-state.

> I'm like, what do you think polymorphism and encapsulation are?

Well, when writing Haskell I'm not dealing with object instantiation, OO-
classes and OO-subclassing. I have no problem with encapsulation per se; it is
an important tool of creating abstractions needed to reach any kind of
productivity. It is more that the OO-style of encapsulation is no longer
something that I believe works in the long run. In popular Haskell terms "it
does not compose" or more lay-men terms "its likely facilitates creating a lot
of maintenance burden".

~~~
vectorjohn
> Well, when writing Haskell I'm not dealing with object instantiation, OO-
> classes and OO-subclassing.

I think what the person you're replying to is saying is you actually are. You
don't literally write "Foo x = new Foo()" but that's just a syntactic feature
of some language. Haskell has types and classes and sub classes. You just
don't write them the same way.

~~~
cies
I upvoted you, but I strongly disagree with that I actually am using those in
Haskell (knowing that you did not say that but merely point out what was
said).

In the theoretical sense OO and FP share some concept like encapsulation and
polymorphism. But a class in C++/Java/Ruby is whole other thing then type-
classes in Haskell.

------
pka
How did you handle refactorings? Like, changing userAddress's "type" from
Address to Maybe Address?

This is what scares me the most in Clojure and all other dynamic languages -
that early on in the project, I'd make an unfortunate decision which I
wouldn't be able to go back on once the project goes over 2-3kloc... without
introducing hundreds of potential runtime errors, that is.

~~~
mateuszf
One way is to use regression unit testing, though Clojure community is not
very into testing.

~~~
jonpither
That last part is complete rubbish.

~~~
mateuszf
That's just what I've heard - sorry if it's incorrect.

~~~
dkersten
The Clojure community is very big on testing, but not all of it is automated
(eg testing on the REPL). Automated testing is popular too though, to the
point where Clojure has a number of testing libraries (clojure.test,
test.check, test.generative, expectations, speclj, midje).

~~~
GFK_of_xmaspast
If the testing isn't automated, I'm not sure it should really count.

~~~
dkersten
Sure it does. It depends on the purpose of your tests and the cost/benefit.

Do you really think that just because you have automated tests, that your
software is defect free? Tests (outside of generative/property-based testing,
which is still under-utilised) aren't very good at finding bugs outside of
regressions. Having said that, most Clojure code worth talking about does have
automated tests.

In my ideal world, I would use expected-case Unit Tests to test the
contract/requirements/interface. Regression tests to prevent fixed bugs from
reappearing and generative tests to try and find bugs. I would write the
expected-case tests before the code, use REPL testing while developing and
finally write property tests after (once my code has evolved so that I
understand the properties) and regression tests only as I fix bugs after the
fact.

------
donjigweed
The "Clojurians don't like testing" meme probably has more to do with Rich
Hickey's famous "guard rail programming" [1] comment than anything else. Of
course, even at the time, the joke within the community was, "Yes, __Rich
Hickey __doesn 't need to write tests....you do!"

[1] [http://www.infoq.com/presentations/Simple-Made-
Easy](http://www.infoq.com/presentations/Simple-Made-Easy) (15:30)

~~~
sheepmullet
> The "Clojurians don't like testing" meme probably has more to do with Rich
> Hickey's famous "guard rail programming" [1] comment than anything else.

And Rich Hickey isn't against testing. He was having a jab at test driven
_design_.

------
khgvljhkb
Thanks for the write-up! Juxt seems like a cool bunch - I'm not London-based
(Berlin) but would not hesitate one minute given the chance to join them.

~~~
jonpither
Hey, send us a mail to say hi at info@juxt.pro :-)

