D For A Web Developer

[Jacob Carlborg via Digitalmars-d]

On 2014-04-30 17:04, Adam D. Ruppe wrote:

> I like implementing things myself :P
>
> That's the question I dread most at meetings now: "is there a gem for
> this?" idk, in the time it takes to search for and evaluate third party
> code, I could have just written it myself. Especially since libraries
> almost always need some kind of customization for our specific case anyway!

I don't agree with this.

> A big difference though is the compiler helps you a lot in D. In Ruby,
> for example, the main reason we use the unit tests (so far) is to help
> ensure consistency after refactoring something. It catchings things like
> a renaming we missed, or a removed method still in use.

Then you're not using unit tests correctly ;)

> In D, you just recompile and those things are found almost instantly
> without needing to actually run any code.

Yeah, sometimes it would be nice with static typing.

> They deliberately avoid the most important parts of a relational database:
>
> http://guides.rubyonrails.org/migrations.html
>
> "The Active Record way claims that intelligence belongs in your models,
> not in the database. As such, features such as triggers or foreign key
> constraints, which push some of that intelligence back into the
> database, are not heavily used."

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 :)

> ORM is something I only like in very small quantities, but ActiveRecord
> uses it for *everything*, well, except for the things it doesn't even
> support.
>
> The problem here is one of encapsulation and of correctness. If
> something bypasses the model - which is required for tasks the library
> doesn't even support and also likely to happen if there's a second app
> using the data - all kinds of stuff can get in there that is bad.
>
> You also have problems like race conditions:
>
> account = BankAccount.find(1)
> account.balance -= 10
> account.save!

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

> What if two of those run concurrently? I searched the web quickly for
> this and haven't found a good answer yet...
>
> Then, with referential integrity, the docs suggest DIY or getting some
> third party gem, because their godawful library doesn't really support
> it. The best it does is offer you a square wheel with the dependent
> thing. Stupid stupid stupid.

All libraries have positive and negative sides.

> idk, I use my database.d which has a little bit of overlap with what
> active record does, but since I generally see ORM as being a nasty
> anti-pattern and horribly leaky abstraction, I didn't go far with it.

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

> There's really nothing to fear with writing SQL, except the cases where
> the language sucks.

ActiveRecord will hide all the ugliness of SQL. Properly escape values, 
to type conversions, time zone conversions and so on. It's also database 
independent.

> (UPDATE and INSERT being so different, and the
> solutions being different for the various vendors, ugh. That's why I
> made my DataObject, it gathers the changes together then issues one of
> those commands. It can also be gotten from a query, making it a kind of
> simple active record:
>
> auto obj = mysql.queryDataObject("select * from foo limit 1").front;
> obj.whatever = "something";
> obj.commitChanges(); // calls UPDATE foo SET whatever='something' WHERE
> id = ?
>
> which also works on joined queries on MySQL btw and offers easy support
> for multiple primary keys or ones not named "id" (as an argument to
> commitChanges), something active record as far as i can tell doesn't
> even try to do, but it doesn't try to fetch child objects or anything
> like that.
>
> I have considered adding child object fetching, but I don't really see
> the need, it is easy to write a method that does that if you want to.)
>
>> I prefer HAML (similar to Jade in vibe.d) but I don't think it's that
>> bad. What do you use?
>
> The ruby thing looks like this <span class="foo"><%= @some_value %></span>.
>
> For my D stuff, I have two options:
>
> 1) create the HTML right in D using dom.d. I like to use this for
> objects that know how to format themselves and output strictly semantic
> XML/HTML. The visual styling is then done with CSS. This works better
> than you might expect!

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

> 2) web.d also has a fairly simple replacement system too:
>
> <span class="foo">{$some_value}</span>
>
> it also supports inserting partials
>
> <div html-from="{$dynamic_html}"></div> or <include partial="foo" />,
> though the include thing takes a wee bit of helper code from the app
> because it needs to find the html somewhere.

Well, that's the same as in Rails. The HAML version would be:

<div html-from="#{@dynamic_html}"></div> or = render "foo". In Rails the 
partial is just a template prefixed with an underscore. It fill find it 
relative to the controller's view directory.

> And the variable replacement can be piped: {$some_count|plural user
> users} for example, which is kinda cool.

I'm not sure I understand this piping.

> It does NOT support intertwined code. Other things are done with
> attributes, such as class="if-logged-in" or <ul from="data_thing" />
> (infinitely extensible with the server-side DOM).

What do you mean with "intertwined code"?

> It looks like this
>
>    root "home#index"
>
>    get "/users/login", to: "users#login"
>
>    namespace :admin do
>      resources :users do
>        resources :children
>      end
>    end
>
>
> and so on. It isn't awful (especially now that I get what they mean by
> "resources"), but my web.d rarely uses explicit routing at all, it
> figures it out automatically by the names, protection level, and types
> of child members.

In Rails that would be:

match ":controller(/:action(/:id))"

So "/foo/bar/1" would route to "bar" action in the FooController with 
"1" assigned as the "id" parameter in "params". Only works with public 
methods. I really hate this. It quickly becomes a big mess.

You can also do a catch all route:

match "*path" => "home#page_not_found"

> Responding with json, xml, and html Just Work with web.d, it figures it
> out from the static type of the function return value.

In my experience it's rarely so easy. Most of the time I need to do some 
customization of the format anyway so the built-in formatting isn't 
suitable.

> Yes, obviously that's some of it, but there's other things that I don't
> expect to change, especially things like runtime errors for what the D
> compiler would catch.

Yes, sure.

> i love that, different strokes i guess.

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.

I want to use Sass, CoffeeScript and HAML. But I don't want to write 
three compilers just to do some web development.

-- 
/Jacob Carlborg