Am 01.05.2014 01:05, schrieb Ary Borenszweig:
> On 4/30/14, 10:38 AM, Adam D. Ruppe wrote:
>> On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
>> Digitalmars-d wrote:
>
>> Of course, I doubt the gap will ever be closed, since Ruby's awfulness
>> isn't dependent on my experience level. It's not like it will ever get
>> static typing even if I used it all the time.
>
> Nah, that will never happen. But you can get very close (
> http://crystal-lang.org/ ), although you loose some dynamism at runtime...
>

Nice to see Crystal still alive.

On Wednesday, 30 April 2014 at 20:36:15 UTC, Andrei Alexandrescu wrote:
> On 4/30/14, 12:25 PM, Dicebot wrote:
>> On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
>>> On 2014-04-30 11:43, Dicebot wrote:
>>>
>>>> This is common complaint I still fail to understand. I have never ever
>>>> wanted to run a single unit test, why would one need it? If running all
>>>> module tests at once creates problems than either module is too big or
>>>> unit tests are not really unit tests.
>>>
>>> Why would I run more tests than I have to?
>>
>> Because you hardly notice difference between 0.1 and 0.5 seconds
>
> *cough* std.datetime *cough* :o)

Pretty much everyone agrees that std.datetime needs to be split into smaller module which was one of my original points.

> One good example is networking tests - if I worked on an airplane I'd love to not test tests that need connectivity with a simple regex.

Again, networking (as well as any other I/O) has no place in unit tests. Never. Supporting such kind of tests natively means designing completely new system not changing existing one.

For most simple example, you can't run non-unit tests in parallel without explicit annotations from programmer (your other thread).

On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:

> This cannot be a good idea. If the block says unittest then it contains
> unit tests, not integration tests or system tests, just unit tests.

Then we need to come up with a separate framework for doing all other kinds of tests.

-- 
/Jacob Carlborg

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

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

Rails unique constraints do hit the DB, but they can be painfully slow. It's usually faster to let the DB handle it and handle the exception in Ruby.

> I also find myself really missing outer joins and views.

For outer joins:

1. You can always use raw SQL, also in combination with ActiveRecord

Post.joins(:comments).joins("outer join foos on foos.post_id = posts.id").where(title: "bar")

2. My preferred choice, using Squeel [1] (another gem). With Squeel the above would look like this:

Post.joins(:comments).joins{ foos.outer }.where(title: "bar")

It also supports queries like this:

Post.where{ |q| q.id >= 3 }

For views you can use raw SQL in the migration to create the view. Then it behaves just like a regular table. ActiveRecord won't know the difference.

At my previous work we used the SchemaPlus [3] gem. It supports foreign keys, views and indexes.

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

I'm not sure I understand. ActiveRecord does regular SQL queries. The example you wrote:

account = BankAccount.find(1)
account.balance -= 10
account.save!

Are you referring to if one process executes line 1 and another line 2?

> 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 don't know how other libraries do it these days but last time I didn't use ActiveRecord it looked something like this:

query("select * from foo where name = ?", "foobar");

BTW, this is still how you need to do it in ActiveRecord when needing something more than the equal operator. It was quite similar in Rails 2 as well. Rails 3 and later makes it a bit better. Very ugly. All values are far to the right and the query is to the left. It's get a quick overview of which values go where.

Therefore I prefer Squeel as soon I need to do something more advanced than the equal operator:

Foo.where{ |q| q.size >= 4 }

You can also use SQL functions:

Foo.where{ |q| q.created_at == q.getdate() }

> 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 never get that working. The HTML always need to change when the design changes.

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

Ah, I see.


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

That's useful for looping and if-statements. I also sometimes but a variable there at the top. In Haml:

- @posts.each do |post|
  %h3= post.title
  .body= post.body

  - if current_url == post_url(post)
    = post.title

  - else
    = link_to post.title, post

This would of course be better handled with a partial and a view helper.

Yeah, I agree that it's ugly with database queries in the view. But it's very easy to end up with something like this, instead of the above:

- Post.all.each do |post|

Queries in the view can be good, it depends on how you look at it. If you write the query in the controller and then access the result in the view, the query will be executed in the view because since Rails 3 queries are lazy. The advantage of this is the you can stream out the response [2].

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

For me it's the same with Rails. I know Rails and know a lot of useful gems.

[1] https://github.com/activerecord-hackery/squeel
[2] http://asciicasts.com/episodes/266-http-streaming
[3] https://github.com/lomba/schema_plus

-- 
/Jacob Carlborg

On 2014-04-30 22:36, Nick Sabalausky wrote:

> Aren't you talking about databases? Single-threading won't save you from
> races there unless the DBMS itself is single-threaded (which would be a
> pretty undesirable DBMS).

Are you referring to if one process executes line 1 while another executes line 2? I don't see how ActiveRecord make this any worse.

> Or does the ORM above automatically lock the row/table behind-the-scenes?

It does saves in transactions but I don't think it locks.

-- 
/Jacob Carlborg

On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
> On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
>> On 2014-04-30 11:43, Dicebot wrote:
>>
>>> This is common complaint I still fail to understand. I have never ever
>>> wanted to run a single unit test, why would one need it? If running all
>>> module tests at once creates problems than either module is too big or
>>> unit tests are not really unit tests.
>>
>> Why would I run more tests than I have to?
>
> Because you hardly notice difference between 0.1 and 0.5 seconds

The compilation time is often more of a problem than the runtime.

On Wednesday, 30 April 2014 at 15:04:53 UTC, Adam D. Ruppe wrote:
> On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
>> I think one of the great things about Rails and Ruby is all the libraries and plugins that are available. If I want to do something, in RoR there's a big chance there's already a library for that. In D, there's a big chance I need to implement it myself.
>
> 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!
>
> There's a few exceptions where something is hard to write, but most things just aren't that hard.

I agree with this, but with a caveat:

The valuable work in a 3rd party lib is more often the design than the body of the implementation. Designing a good API and general design for a library requires experience and perspective that I don't have in most problem spaces, but a quick bit of reading and the internals are often trivial to reproduce.


I think this is particularly relevant in D; Implementation is made easy, but the flexibility available makes the design stage especially important. That is not to say that it's harder to make good designs with D, more that it's feasible to make *even better* designs if you have the expertise and time.

On 5/1/14, 6:58 AM, Jacob Carlborg wrote:
> On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
>
>> This cannot be a good idea. If the block says unittest then it contains
>> unit tests, not integration tests or system tests, just unit tests.
>
> Then we need to come up with a separate framework for doing all other
> kinds of tests.
>

Yes. And then you need two different commands to check if the system works. And if you want, for example, coverage analysis I wonder how you'd do that... That can't be good.

On Wednesday, 30 April 2014 at 17:17:02 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 30 April 2014 at 16:56:11 UTC, Nick Sabalausky wrote:
>> Sounds pretty much exactly what I'd expect from just about any PHP-based application. :/
>
> Modern PHP isn't so bad. I can write acceptable code in PHP. Though, I only do so when there is no other option, since it is the least desirable option next to Perl. The good thing about PHP is that default installs tend to have good C libraries. I think it would have died without that.
>
> So, if PHP is ok then it must be the PHP programmers that are to blame. I shudder to think what happens with a niche community if they pick it as the next fad… It could destroy any upcoming programming community with spaghetti-hell. Are you sure you want to market D as a web platform?
>

This hasn't happened to Ruby (or Rails for that matter), which is definitely marketed as a web platform. Most of the Ruby code that I've seen is of exceptionally high quality. That's true not only regarding the code itself, but also for the interfaces it provides (in the case of libraries), which are usually well thought out. For PHP, on the other hand...

I believe this has a lot to do with the language. Apparently it's harder to write bad code in some languages than in others.

>> familiarity with the other stuff than I do. Ugh, but SQL can be such a pain, especially with all the vendor differences, and when compared to accomplishing something in whatever language I'm invoking SQL from.
>
> You can implement it in the ORB or wherever unit that provides transactions. I was more pointing to what I find useful conceptually in terms of layers:
>
> 1. user input on the client
> 2. validate on client
> 3. post using ajax
> 4. server unwraps the data and blindly inserts it into the database
> 5. if transaction fails, notify client, goto 1
> 6. done.

IMO the client shouldn't do any validation, unless you can really, really trust it. That's why I like to do things the following way:

1. user input on the client
2. post using ajax
3. server validates and stores the data
4a. if transaction or data is invalid fails, send errors to the client
4b. if everything's ok, tell the client to redirect to the next page
5. on the client, add error CSS classes to the relevant fields, or execute the redirect

I've created a gem that does almost all of that transparently. I just need to mark the form with "remote: true", and adhere to a few simple naming conventions (which Rails' form generators do automatically).

On Thursday, 1 May 2014 at 10:44:42 UTC, Jacob Carlborg wrote:
> On 2014-04-30 22:38, Adam D. Ruppe wrote:
>> I also find myself really missing outer joins and views.
>
> For outer joins:
>
> 1. You can always use raw SQL, also in combination with ActiveRecord
>
> Post.joins(:comments).joins("outer join foos on foos.post_id = posts.id").where(title: "bar")
>
> 2. My preferred choice, using Squeel [1] (another gem). With Squeel the above would look like this:
>
> Post.joins(:comments).joins{ foos.outer }.where(title: "bar")

You can also use the built-in `includes()`, which does a LEFT OUTER JOIN:

    Post.includes(:comments).where(comments: {title: "bar"})

(It also eager-loads the comments, but this is usually desired anyway, because an OUTER JOIN doesn't make sense if you're not going to use the joined records.)