Disqus - Latest Comments for dgebhardt

Re: Understanding Ember.Object :: Cerebris

Dan Gebhardt — Thu, 29 Jun 2017 08:34:37 -0000

@Nikos That day is coming very soon. We (on the Ember Core Team) are working on this goal, and there are very few blockers left to just being able to use ES classes.

Re: Ember.js - Introducing Zoey

Dan Gebhardt — Mon, 04 Apr 2016 14:44:18 -0000

I agree that we need to be careful and respectful when navigating this territory. It should be noted that, between his name and the shape of his glasses, Tomster is also associated with traditional gender signifiers. I believe that the gender signifiers for both Zoey and Tomster are tasteful, discrete, and balanced. And ultimately, both characters are intended to signify a balanced and welcoming community. I think they do their jobs well!

Re: The "Development Drawbacks" of JavaScript Web Applications

Dan Gebhardt — Wed, 20 Jan 2016 09:20:00 -0000

My central argument is to embrace the use of JavaScript in the browser to provide a superior UX.

I'm not opposed to using transpiled languages like TypeScript, if that is your preference. However, I would caution you to choose very carefully, since many transpiled languages have their own warts and are much more likely to have longevity issues.

My personal preference is to use Babel to write ES6+ and rely on linters to enforce coding style consistency and best practices.

Re: Building a modern bridge between Ember and Rails 5 with JSON API

Dan Gebhardt — Sun, 16 Aug 2015 15:20:11 -0000

Hey Ian - thanks much!

Re: Building a modern bridge between Ember and Rails 5 with JSON API

Dan Gebhardt — Sun, 16 Aug 2015 15:19:45 -0000

No pressure to switch to jsonapi-resources. If AMS is working well for you, then by all means keep going with it! Of course, one of the benefits to working with json-api is that different client and server implementations can be tried out independently.

If someone is starting fresh and evaluating jsonapi-resources vs. AMS, it's important to understand the basic architectural differences. jsonapi-resources is very resource-centric, much like json-api itself, so there's a lot of centralized logic in resource classes. This decision was made because json-api requests often involve concerns that cut across multiple types of resources (e.g. compound documents). On the other hand, AMS spreads responsibility more evenly across multiple layers, including the new serializer layer. You might find AMS easier to incrementally adopt in a standard Rails app, but your code may be more verbose and less DRY than if you had used jsonapi-resources (especially as you implement json-api more completely).

Re: Building a modern bridge between Ember and Rails 5 with JSON API

Dan Gebhardt — Thu, 13 Aug 2015 17:34:41 -0000

Great post, Frank! It's gratifying to see such straightforward (but non-trivial!) tutorials being written after working so long on the json-api spec and much of the tooling on both sides.

I'm glad to see AMS coming into compliance with json-api. An alternative is jsonapi-resources, which handles the full scope of json-api, including serialization and deserialization, as well as pagination, compound docs, sorting, partial fieldsets, etc. If you hit some limits with AMS, check it out:

https://github.com/cerebris...

Re: Cerebris :: JSON API 1.0

Dan Gebhardt — Tue, 23 Jun 2015 08:01:38 -0000

JSONAPI::Resources doesn't perform any parameter filtering above and beyond what is provided by Rails. Rails allows you to mark params as sensitive so that they will be excluded from logs (which is why they're showing up as [FILTERED]). See section 13.1 Parameters Filtering in http://guides.rubyonrails.o... for more info.

Re: Cerebris :: JSON API 1.0

Dan Gebhardt — Tue, 23 Jun 2015 07:56:01 -0000

I'm looking forward to seeing API doc tools develop that are specifically aware of JSON API. API docs could leverage the spec itself by pointing to relevant sections.

This has been a frequently requested feature in JSONAPI::Resources, although I think a more general tool that could work with any JSON API implementation would be more appropriate.

Re: Beginning Ember.js on Rails: Part 1 :: Cerebris

Dan Gebhardt — Tue, 23 Jun 2015 07:45:44 -0000

Hi Sina - The Ember guides (on emberjs.com) are now pretty complete and well written. You may also want to check out Chris Ball's site: http://fromrailstoember.com/

Re: Cerebris :: JSON API 1.0

Dan Gebhardt — Fri, 05 Jun 2015 15:46:32 -0000

I'd like to follow this up with some getting started style posts that walk through developing a full stack application with JSON API.

You could also explore the READMEs of libraries such as JSONAPI::Resources or Endpoints for guidance.

I do know of at least one other post being written about the spec at the moment, although I'm sure others are on their way. If you follow me (@dgeb) or @jsonapi on Twitter, I'm sure you'll see some links tweeted soon.

Re: Cerebris :: JSON API 1.0

Dan Gebhardt — Fri, 05 Jun 2015 15:37:14 -0000

Your proposed solution sounds like an ad-hoc RPC style protocol that isn't consistent with REST constraints. Your client and server implementations will need to be hard-coded with shared serialization strategies and protocol usage patterns, since your solution provides neither. These are the very conventions that JSON API provides to provide a shared understanding between clients and servers.

However, if this works for you and your clients, then go for it. There are thousands of valid media types, and we are by no means suggesting that JSON API is "the only way".

By the way, I should correct a few points:

* JSON API doesn't require an inflector - resource `type` can be singular or plural. It just needs to be consistent.

* JSON API will eventually allow extensions, such as the bulk extension mentioned above, that will allow for multiple operations to be performed in a single request.

Re: Real-time Data for an Ember.js Application using WebSockets

Dan Gebhardt — Thu, 21 Aug 2014 10:11:42 -0000

Sounds great, Bill!

Because of the SocketIO dependency, I would prefer to keep this outside of the core repo, but would love if you'd help maintain it as a repo under the orbitjs org. See my comment on this PR for a localForage source - https://github.com/orbitjs/...

If you want to chat, there's a new #orbitjs channel on freenode :)

Re: Real-time Data for an Ember.js Application using WebSockets

Dan Gebhardt — Wed, 20 Aug 2014 07:04:08 -0000

Bill - thanks so much for sharing your work with Orbit!

Believe it or not, I have yet to blog about Orbit myself. I've been putting it off while I work on the code itself and a proper site with docs and guides (coming soon: orbitjs.com).

Nice work with the SocketSource, which really fills a hole in Orbit's list of available sources. I've been planning to set up a template project for sources to make it easy to test/build/distribute them individually. Please let me know if you're interested in extracting your source into a separate repo for easier maintenance and sharing.

Re: Ember.js -

Dan Gebhardt — Tue, 14 Jan 2014 12:56:32 -0000

Well handled everyone. Thanks especially to Edward and Robert!

Re: Beginning Ember.js on Rails: Part 1 :: Cerebris

Dan Gebhardt — Mon, 25 Nov 2013 13:05:09 -0000

[Posting a duplicate reply to your other question about routes]

Sorry - this example was written before the Ember router existed in any form. I have a more up to date example project (https://github.com/dgeb/emb... that I plan to bring fully up to date and use as the basis for a new series of posts.

Re: Beginning Ember.js on Rails: Part 2 :: Cerebris

Dan Gebhardt — Mon, 25 Nov 2013 13:03:04 -0000

Re: The "Development Drawbacks" of JavaScript Web Applications

Dan Gebhardt — Sat, 17 Aug 2013 22:18:11 -0000

I think that's a fair assessment, Ansikt. There are undeniably design and UX patterns that influence applications with a similar purpose, regardless of the technology used to create them.

Re: "Single Page Applications"

Dan Gebhardt — Thu, 01 Aug 2013 21:34:16 -0000

That is a tricky distinction to make and will probably get trickier as these lines inevitably blur further.

Re: "Single Page Applications"

Dan Gebhardt — Wed, 31 Jul 2013 17:37:39 -0000

Haha... another interesting distinction. That could work, but does a "web" browser become just a browser when it's offline? ;)

Re: "Single Page Applications"

Dan Gebhardt — Wed, 31 Jul 2013 17:27:53 -0000

That's a good distinction to make... thanks!

Re: "Single Page Applications"

Dan Gebhardt — Wed, 31 Jul 2013 16:58:17 -0000

Wise guy, eh?

Re: Beginning Ember.js on Rails: Part 3 :: Cerebris

Dan Gebhardt — Mon, 01 Jul 2013 08:45:12 -0000

Using Ember is about much more than including ajax features. Once loaded, your application can dynamically respond to many user actions without making roundtrips to the server. If you're still interested, check out the guides at emberjs.com to see all of the capabilities that Ember provides.

Re: Beginning Ember.js on Rails: Part 3 :: Cerebris

Dan Gebhardt — Mon, 01 Jul 2013 08:40:28 -0000

Thanks, Philip. Glad you found it useful!

Re: Beginning Ember.js on Rails: Part 3 :: Cerebris

Dan Gebhardt — Mon, 01 Jul 2013 08:39:31 -0000

Thanks Justin. I have to say that I haven't been doing much with ember-rest lately, but it is simple enough code that I wouldn't hesitate using it if it really meets your needs. It's a very thin wrapper over jQuery's ajax methods and might save you some work vs a manual approach.

With that said, I've been working with ember-data quite a bit myself lately and have found that it's maturing well. If you're looking for something simpler than ember-data and more ambitious than ember-rest, check out Erik Bryn's ember-model.

Re: Beginning Ember.js on Rails: Part 1 :: Cerebris

Dan Gebhardt — Mon, 01 Jul 2013 08:29:50 -0000

Deployment is a complex topic with quite a few options. If you're new to deploying Rails apps, you may want to try a service such as Heroku (heroku.com) to get started quickly.