D For A Web Developer

Wed Apr 30 13:38:34 PDT 2014

On Wednesday, 30 April 2014 at 19:53:53 UTC, Jacob Carlborg wrote:
> I don't really agree with that. Although I'm not a fan of store 
> procedures/functions in the database. But I don't mind foreign 
> key constraints. We used that at my previous work. Via a gem :)

Yeah, foreign keys are really an absolute must. So are uniqueness 
constraints. Rails can kinda do these, but in its own reinvented 
ways that don't actually hit the DB (at least not without add on 
gems)

I also find myself really missing outer joins and views.

> I think most Rails application are run single threaded. But 
> with multiple processes instead.

That doesn't change the race condition because the database is 
still shared across those processes. With a regular SQL query, 
the database guarantees consistent, atomic operations in the DB 
engine itself, but with active record pattern, you give that 
up... while still having the shared data.

It was a thing like this that recently took a bitcoin exchange 
down. Literally the textbook example of concurrency, but most 
these modern newfangled frameworks get it wrong.

> Using a random D module for this doesn't feel very comfortable, 
> no offense. No documentation, no way to find examples and so on.

Yeah, I wrote these for myself and put them on the web just in 
case somebody else finds them useful, but it is really a 
take-it-or-leave-it thing to me. Even in my book when I talked 
about some of these libs, I focused on lessons learned when 
writing them more than the actual usage - my thought is then 
maybe people can do their own thing instead of downloading my 
stuff and using it straight up.

> ActiveRecord will hide all the ugliness of SQL.

It also hides all the beauty of it :(

> Properly escape values

If you're escaping values, unless you're writing some low level 
database library, you're almost certainly doing it wrong.

I agree that using raw SQL with something like the PHP4 method of 
string concatenation is a huge pain and awful, as well as 
inefficient and insecure. But that's also the wrong way to do it 
and any non-crippled database API or library offers ways to 
separate the sql code and data cleanly and easily.

> Are you using some kind of proxy for this or are you pushing 
> back the view layer to the model?

CSS is the view in that scenario. The HTML the object returns is 
just its fields wrapped up in tags and classes. Works really 
well, for my last big job, the designer worked almost exclusively 
in CSS and we got a lot of stuff done.

> I'm not sure I understand this piping.

It calls functions on the variable. So like {$foo|capitalize} 
would be kinda like <%= capitalize(foo) %>. The plural example 
uses arguments to the function too so we can customize the words 
if it is plural or no.

> What do you mean with "intertwined code"?

<html><% some ruby here %></html>

I hate that stuff, especially when the view starts doing implicit 
database queries! Defeats the whole point of MVC separation if 
you ask me.

> You can also do a catch all route:
>
> match "*path" => "home#page_not_found"

Aye, web.d calls a method called catchAll for those too.

> I don't mind it but sometimes I just want to get some work 
> done. I mean, I've started out (or planed to) with some project 
> in D but then I needed to create all the support libraries and 
> tools so I've almost forgot what I was going to do in the first 
> place.

meh, with my libs, they might not be accessible to others, being 
poorly documented and all, but I know them and have used them for 
almost everything that's come up over the years. So for me, 
getting work done means spending an hour using D instead of days 
searching the web for some gem that won't even work right anyway.