Disqus - Friends of Croaky

Re: Going off the Rails - Ben Summers’ Blog

wycats — Thu, 06 Aug 2009 17:08:43 -0000

A lot of what you're talking about is explicitly resolved in Rails 3. For instance, your layout example could be accomplished in Rails 3 by "def layout" on your controller. All we do for you when you do "layout 'foo'" is define a layout method that returns 'foo'.

A lot of the point of the work we're doing at the moment is to sharpen and expose these things, so you can use them without fear. I understand the argument you're making: *I made it myself a year ago*. But I think that a lot of your criticism fails to take into consideration the work we're doing on the Rails 3 internals.

Re: Why Do Rubyists Test So Completely?

wycats — Fri, 14 Aug 2009 12:43:03 -0000

There are a bunch of small issues here. I'll address the post first and Sam second:

"So we write the tests first so the client stays happy. Instead of just hacking away at code until it compiles, we write tests then hack away at code until they pass."

The implication here is that "hacking away at code until it compiles" is an acceptable replacement for writing tests. This is straight-out incorrect. Compiling code does not mean correct code. Java has a huge testing community and a significant testing culture (the ideas for RSpec came out of Java) despite a verifying compiler.

In other words, it's perfectly possible to write code that sends in an integer where an integer is expected, only it's the WRONG integer. An emphasis on testing over compiler verification means that we don't confuse one for the other.

"Any method, at any time, might produce nil. You never know when it might happen. Even instance variables might produce nil. Your code will keep going until this becomes an issue…and it will become an issue"

To be honest, this reminds me of the argument that Alex Payne made a while back that the problem with Ruby was that he constantly needed is_a? checks. When people pressed him (and other Twitter employees on it) it turned out not to be a typesafety issue but some pretty problematic hacks that were in place to work around a bug in Memcached that informed his entire point of view. Similarly, while anything *can* produce nil, it should be fairly obvious what *should* produce nil.

The following method cannot produce nil: def foo(thing) thing.is_a?(String) ? "hello" : "goodbye" end. As a result, you can rely on a call to foo producing a valid result. If you're running into problems where you're getting nil in places that you didn't expect, make sure you know all the code paths in the methods you're calling, and that a nil return isn't possible. If you're worried about instance variables being nil, you can turn on Ruby's warn mode, which will let you know if there's an uninitialized instance variable that's defaulting to nil. Some people consider the nil default to be a feature of Ruby, but since it seems to be causing you some consternation, by all means use the warnings.

"Work has been done to try to statically analyze Ruby. Our very own Jason Morrison did some work in 2006 for the Google Summer of Code to build a type inference engine, then tried to continue the project before abandoning the idea; according to him, the main problem is eval. Another problem he’s mentioned is the way classes are implemented, with the singleton classes and mixins and whatnot"

Dynamic languages, especially ones with open classes, have type inferencing difficulty. You pay for the flexibility of changing things at runtime with the inevitable result: it's hard to confirm things about the code by analyzing it statically. However, as our VM implementors are learning, once an app is booted, there is usually a period of time after which the state of the application is frozen (and this is mostly the case in Rails as well), which makes it possible to analyze the running code. This is not necessarily so useful for IDEs (which might have trouble booting up an entire app every time it needs to do code completion), but would be quite useful for general analysis.

A larger issue for Ruby is that much of the programs input come from an external source, and in the absence of good sanitization, you can end up with all manner of weird results. @foo.update_attributes(params[:person]) is cool, but it means that an arbitrary Hash (or nil), with arbitrary keys are being passed into update_attributes. The right approach is to confirm and sanitize the incoming params before passing them along to update_attributes, which will then make the black box that is ActiveRecord behave more predictably.

Refactoring / Mutation: You hit the nail on the head here, until you go on to say:

"So we test because Ruby provides no better alternative, and because testing is awesome. What if we tested only because we enjoyed it, not because we got anything technical out of it? What if our unit tests never failed except for when we first wrote them? What if regressions were caught by the language implementation instead of by custom code?"

Let's unpack this a bit. The claim here is that testing would be unnecessary if Ruby was a better language. This is a fatally flawed assumption. You simply cannot prevent regressions in acceptance requirements through compiler verification. Period.

Full stack acceptance testing is the right approach for web applications and cannot be automatically performed via a compiler.

"What changes would you make to Ruby to achieve the goal of never unit testing again?"

Because Java doesn't have unit testing (JUnit), and Objective C doesn't have unit testing (OCUnit), and C doesn't have unit testing (CUnit). I pose a different question to you. What about unit testing makes you so miserable that you want to "never unit test again".

Re: Why Do Rubyists Test So Completely?

wycats — Fri, 14 Aug 2009 13:04:54 -0000

@mike then your closing comment was misleading. You said "What changes would you make to Ruby to achieve the goal of never unit testing again?"

Re: Why Do Rubyists Test So Completely?

wycats — Fri, 14 Aug 2009 13:15:01 -0000

"I agree with this; much of my attack in this article is on unit testing."

Then I think we agree. The approach is Merb was to completely eliminate unit testing of controllers, and replace with what we called "request tests", which tested the full stack. Engine Yard's Cloud product uses this approach exclusively, and it has worked well for them.

Unit testing of models can be useful if you see the model as a separate API that should have validated behavior (I tend to see it that way). Unfortunately, many people look at the model as an extension of the controller, and don't have a clean separation of concerns. That's a serious problem and might be one cause of the problems you've seen.

Re: Why Do Rubyists Test So Completely?

wycats — Fri, 14 Aug 2009 13:26:20 -0000

Sam,

Seriously?

"That you rarely see much of a debate at all over 100% code-coverage in the Ruby community and how deceptive a metric it is, nevermind the serious lack of ROI it takes to achieve it is a sign of something broken in the community in my opinion."

Except that this is totally wrong. Every single talk I've seen that has mentioned code coverage has mentioned that it's a poor metric. And Java has some of the best code coverage tools around. 100% code coverage is silly, but quickly glancing through a coverage report to see ENTIRE CLASSES or methods that are not being exercised by tests is quite useful.

"I'll come out of the closet about this and just say what everyone knows: If the DataMapper community had more of a focus on addressing known, ticketed, reproducible bugs and less on pouring thousands of man-hours into writing specs it would be usable today. Frankly, I would recommend against considering it for your next project in the strongest terms possible."

Bullshit.

The reason the community rallied around test coverage was that addressing known, ticketed, and reproducible bugs was near-impossible with the poor state of the test suite. Virtually every fix to a "known, ticketed and reproducible bug" broke something else.

"It may be excessively harsh or unfair, but it's hard to avoid the impression that few Rubyists understand Composition Over Inheritance."

Your position here appears to be informed by the constraints of Java rather than the specifics of the Ruby implementation. Modules or traits, while resembling inheritance in some cases, can also be used to provide default implementations for interfaces. Because modules do not need to be declared when a class is created, modules themselves can implement interfaces. For instance, a module like ActionController::Layouts can depend on a module that behaves like ActionController::RenderingController, but it need not be that specific module. Because modules can be injected at runtime into any class, they have properties similar to dependency injection and can be isolated from one another reasonably well.

You're also wrong about the Ruby community eschewing interfaces. This is especially apparent in the Rails 3 work. For instance, ActionController in Rails 3 relies on the existence of a ViewContext of come kind. That ViewContext has three requirements: Context.for_controller(controller), Context#render_template(options), and Context#render_partial(options).

ActiveModel, while it also provides some default modules (such as validations), serves as an API that is used by ActionController. It has several requirements: Model.naming, Model#valid?, Model#new_record?, and Model#errors.

"How many of the current community leadership has even read the PoEAA? I'll tell you one person who has: DHH. Rails wouldn't have existed without it."

I'm not sure who you mean by "community leadership", but I think most of the Rails core team has. I know I have. And yes, DHH has. What's your point exactly? Sounds like a baseless ad hominem attack on nameless individuals.

"The number of packages involved in actually using your library for anything useful is not a "more is better" situation. Proposing that simply breaking things up into their own Assemblies has any relation to de-coupling at all is eye-roll worthy."

Who exactly is making this argument? In Merb, we broke things up purely to ensure that they would run separately, not to technically decouple them. For the most part, Rails is distributed as a single package. Things like making ActionController depend on an ActionView interface, allowing the replacement of the normal template lookup mechanism (again, using an interface), and defining an ActiveModel interface are the arguments for decoupling. And guess what... we're doing them.

Are you making an argument against Rails 2? Merb? I'd suggest taking a look at the work we've been doing for over nine months and then decide whether we understand OO, not the work people did years ago.

"Isn't it about time we as a community leave behind dogma and fads and get back to evidence based techniques, do a little more standing on the shoulders of giants as opposed to reinventing wheels and start moving forward again as a community with an emphasis on the Science of Computer Science?"

The sad thing is that once upon a time you actually correctly convinced me of these arguments. Instead of reveling in that victory, which has significantly informed our work on Rails 3, you continue to bash against nameless, faceless Rubyists and old code. I call bullshit.

Re: Why Do Rubyists Test So Completely?

wycats — Fri, 14 Aug 2009 15:00:22 -0000

@Richard Herold about what?

Re: Why Do Rubyists Test So Completely?

wycats — Fri, 14 Aug 2009 16:28:19 -0000

"I want us to write tests only for design and not for regressions, and I wonder what parts of Ruby are keeping us from that."

Again, this is kind of malarky. Regressions are regressions in acceptance criteria, and acceptance tests are *not* something that verifying compilers can achieve. Am I completely misunderstanding what you're saying? If so, you're being very unclear and possibly hyperbolic.

Re: Why Do Rubyists Test So Completely?

wycats — Fri, 14 Aug 2009 16:41:48 -0000

@mike you keep saying "tests" when you mean "verifying unit tests". I think that's a large part of the confusion. I consider cucumber to be "regression tests" so saying "I want to have zero regression tests, I just want to run cucumber" is a very weird construction to me.

Re: Why Do Rubyists Test So Completely?

wycats — Fri, 14 Aug 2009 17:45:19 -0000

@mjankowski Right! The parts of your app that you need to unit test are likely to be libraries that should stand on their own and which have sensible boundaries. You'd want to test this code just like you'd want to test Rails.

The rest of the application regresses ONLY when some acceptance criteria regresses, and testing via an acceptance tests framework like Cucumber is the right way to do it. My personal bias is toward many more acceptance tests and few unit tests, but there's more than one way to do it, depending on where your personal boundaries and comfort level lives.

Re: Three implicit contexts in Ruby - 世界線航跡蔵

wycats — Mon, 16 Nov 2009 15:01:38 -0000

@yugui Thank you for the correction! I have updated my original post to reflect these corrections.

Re: Let's not add_bundler_dependencies anymore - Jeff Kreeftmeijer

wycats — Mon, 27 Sep 2010 15:40:03 -0000

We do deprecate it: http://github.com/carlhuda/... :D

Re: Making Ember.js Easier

wycats — Fri, 22 Mar 2013 13:01:54 -0000

Yes. That's what it means :D

Re: Explaining Away the Web's Magic

wycats — Tue, 11 Jun 2013 01:54:50 -0000

This is a really great explanation of how the Extensible Web Manifesto sees things playing out. Let's do it!

Re: Why Angularjs Beat Out Emberjs In Our Stack

wycats — Thu, 22 Aug 2013 15:47:06 -0000

I can see that you experienced frustration with Ember. As someone who has given training to groups of totally new Ember developers, I have felt that frustration acutely as we worked on the framework.

That frustration, and the ways in which Angular shines for early developers, have been at the forefront of my mind as I worked on Ember for at least six months. I've been gratified that as we have improved things, much of the frustration that we saw in earlier trainings has been eliminated. Members of the Ember community have likewise said that many of the improvements have simplified their code and their ability to explain it to others.

We care a lot about this, and won't stop simplifying things that don't need to be complicated. Our focus from the beginning has been on laying a foundation for large application that doesn't crumble as you grow, but we never wanted to front-load complexity to achieve that. I think that the recent work, and the work we have planned next, will continue to eliminate front-loaded complexity without compromising the long-term.

Some things we're working on:

* More usage of HTML directly (<img src="{{foo}}"> rather than bindAttr)
* Elimination of the <script> placeholder tags
* Improvements to the Ember extension, which make it easier to get a mental picture of your app as well as quickly see what naming Ember expects
* Official tooling based on JavaScript modules
* Elimination of .get and .set for apps that can rely on IE9+
* Improvements to Ember Data to make it much more usable as a primitive model cache

All of these improvements are things that came directly from critiques like yours. Tom and I, together with the rest of the core team, take ease-of-use criticisms very seriously. Just because we defend Ember in public in comment threads like this, don't think that the critiques don't keep us up at night. We know we need to do better.

For what it's worth, I think your decision to have an Angular app per page of your application was a pragmatic choice that eliminated one of the biggest deficiencies of Angular, poor support for nested routing and UI. I personally prefer applications that are snappy across all aspects of navigation, but again, the choice you made was a totally pragmatic and reasonable choice.

Re: Why Angularjs Beat Out Emberjs In Our Stack

wycats — Thu, 22 Aug 2013 15:52:13 -0000

For what it's worth, Angular absolutely does have a concept that is similar to Ember's outlets: ng-view. You can see the documentation here: http://docs.angularjs.org/a.... Angular does not support nesting them, which can become an issue as your UI becomes nested (with navigation links, master-detail, etc.)

I think you have been able to avoid needing this feature not because of how Angular implements controllers, but because you use an Angular app for each page of your application, and handle routing through your backend. This is a totally reasonable and pragmatic approach, but it doesn't mean that Angular's top-level-only ng-view, or Ember's nested {{outlet}}s are unnecessary.

Re: Why Angularjs Beat Out Emberjs In Our Stack

wycats — Thu, 22 Aug 2013 16:03:51 -0000

@Todd Persen Totally agree about your criticisms of both Ember Data's documentation and the lack of documentation of alternative approaches.

This is something that many members of the core team have been sprinting on over the past month. I think we've done a good job of reducing a lot of the deficiencies that people were frustrated with six months ago, and data-related documentation is one of the highest priority ones at the moment.

Nothing stands still. Ember today is far more accessible than Ember six months ago, and Ember in six months will be far more accessible than Ember today. Keep popping your head in from time to time. You may see something you like one day.

It might interest you to know that our training course actually doesn't use Ember Data at all: you can just return a $.getJSON (or any other JS promise) from the model hook in routes, and Ember will take care of waiting for the request to finish and making the resulting JSON the model for your template.

Re: Why Angularjs Beat Out Emberjs In Our Stack

wycats — Thu, 22 Aug 2013 16:47:00 -0000

Ember's perspective is that routing, and in particular, nested routing that drives bested UI, is a critical feature for building web applications. We've spoken at some length about how important URL-driven applications are to the web.

In contrast, Angular recently announced that they didn't consider routing to be common enough for core, and are removing it so the core team can focus on more common use cases.

While it's great that there is a community-based solution, robust routing really is a core feature of JavaScript frameworks, and having routing in core makes it possible for it to drive how all applications are built.

Errplane made a pragmatic decision to avoid client-side routing by having an angular app per URL. If you don't think that routing should be a core feature of a web framework, or have an application per URL, this banner Ember feature may not sell you.

Re: Riding Rails: Senny and Godfrey to Rails core, Yehuda to alumni

wycats — Sun, 07 Sep 2014 20:24:14 -0000

Just wanted to say thanks to everyone for their kind words. Always remember: keep working at the edge of your capability and your capabilities will grow without bound. Never rest.

On a separate note, Skylight makes heavy use of ActiveSupport::Notifications, and I'm planning on working with Carl and the rest of the team to put together some proposals for improvements to the system for Rails 5 that will make it more generally useful and more efficient, based on our real-world experience attempting to build a low-overhead instrumentation system for Rails.

Re: Handlebars Version Compatibility

wycats — Sun, 19 Oct 2014 15:43:49 -0000

It doesn't affect the public Ember templating API. Handlebars 2.0 is largely a reorganization of the public Handlebars API to make it more module-friendly, and since you work through the Ember API, we can shim it.

It also has some useful bug fixes that will let us improve Ember going forward (notably allowing namespaced components).

Re: Inside FastBoot: Faking the DOM in Node

wycats — Fri, 09 Jan 2015 15:16:33 -0000

Hey il1019:

We tried to talk about this a bit in the blog post, but the core point is that simple-dom is a reasonable representation of the DOM *as a data structure*, not a full implementation of the DOM's APIs.

We focused on adding the small subset of the real DOM's API that can be used to manipulate the data structure (so things like 'firstChild', 'nextSibling', 'nodeType', 'nodeName'). We didn't implement APIs that need to be implemented slowly (as accessors) or which are merely adding sugar on top of already-possible operations (getElementsBy*, querySelectorAll, etc.).

We think jsdom is an awesome project, and if we needed a full-fidelity DOM we would definitely use it. In this case, we were motivated by getting the best performance (and the ability to optimize for the subset of features we need) and relatively small file size.

For some context, the way HTMLBars works internally is that we parse the HTML (on the server) and then create a function that uses the DOM API to put together a fragment that can be inserted into the page. It uses very simple, very low-level APIs to do this work. In the browser, this simply creates a regular DOM. On the server, we emulate those same operations so that we can use the same *templates* but flatten the output into a string.

It's approximately equivalent to building a virtual-dom abstraction, but it uses a subset of the browser's API rather than inventing a new API. Since the Virtual DOM by definition needs to work with the DOM as a data structure, we figured why not use a subset of the DOM as an API too.

Re: Inside FastBoot: Faking the DOM in Node

wycats — Sun, 08 Feb 2015 02:50:51 -0000

> What if a developer uses libs that rely on real DOM to be present. The server side rendering would crash then, right? Or do you want to make any restrictions what can be used and what not?

As long as the DOM work is restricted to `didInsertElement` hooks, everything will just work. Ember's conventional structure makes it easy for us to get everyone on the same page about what it means to write a FastBoot-compatible app, and importantly, FastBoot-compatible add-ons.

Re: Ember.js 2.1 Beta Released

wycats — Tue, 18 Aug 2015 23:22:43 -0000

`get` and `each-in` snuck into 2.0. The rest of this stuff is new in 2.1.

Re: Unpopular Developer 5: Stop Unit Testing Your Scaffold Controllers

Mike Burns — Wed, 12 Aug 2009 12:53:15 -0000

Croaky: Since the list produced by the Post.alphabetical stub is empty, the views will not choke.

If you want an object in that list I recommend Factory.stub(:post).

Re: Unpopular Developer 5: Stop Unit Testing Your Scaffold Controllers

Mike Burns — Wed, 12 Aug 2009 13:01:37 -0000

Croaky, yes. Factory.stub(:post) will create a Post-like object that never hits the database. Fast, cheap, and gets the job done.

Re: Unpopular Developer 5: Stop Unit Testing Your Scaffold Controllers

Mike Burns — Wed, 12 Aug 2009 13:07:41 -0000

Tammer, I claim this makes sense even when not using inherited_resources. Messing up the RESTful scaffold just isn't something we do anymore.