Disqus - Latest Comments for cgbystrom

Re: Carl Byström

cgbystrom — Fri, 21 Feb 2014 19:22:47 -0000

I haven't played with this interface for some time. Maybe they have changed how things work on their end. Try launching the Spotify client and try again.

Re: Carl Byström

cgbystrom — Mon, 22 Apr 2013 15:19:22 -0000

Nice find although I get the same scope error.

Re: Carl Byström

cgbystrom — Sun, 21 Apr 2013 16:47:20 -0000

Rune, it probably is possible to adjust the volume as @Valtteri Rauhala pointed out. But the OAuth token you retrieve from Spotify servers does not allow it.

Unless you can get your hands on such token or patch the Spotify player, I guess you're out of luck (given that you want to do it through the HTTP API).

Re: Why Discourse uses Ember.js - Evil Trout's Blog

cgbystrom — Mon, 11 Feb 2013 14:34:08 -0000

For Battlelog (http://battlelog.battlefiel... ), one of the major reasons switching to client-side rendering was improving server-side performance. I don't think that aspect of it is discussed much but rendering string templates is dog slow compared to sending JSON. Despite delegating this to the browser, the perceived snappiness for the end-user improved greatly.

All in all, for *us* it made a lot of sense due to the fact that our site is much more an app than a document.

(accidentally tweeted you before finding the comment section here :)

Re: Netty: To use SLF4J or not, that is the question (Blog.To use SLF4J or not, that is the question)

cgbystrom — Tue, 22 Nov 2011 08:36:18 -0000

Given that Netty today has no required dependencies would make me say that the thin logging approach is the way to go.
Adding more dependencies, even something as mainstream as SLF4j, come with a cost.

As far as I can tell, the Slf4JLoggerFactory do provide support even for SLF4J without requiring runtime dependencies. I used one of the other bundled logger factories to hook up Netty to Log4j.

http://docs.jboss.org/netty...

Re: http://blog.tripbirds.com/post/11430540543

cgbystrom — Fri, 14 Oct 2011 12:18:23 -0000

Is there a high-res picture available?

Re: Jabberwocky

cgbystrom — Thu, 10 Feb 2011 12:31:04 -0000

Playing with ZeroMQ and mongrel2 sounds like a fun project!

Long-poll works with both Apache and nginx, but the latter is way more efficient. But neither of them will handle Web Sockets (although I've heard there are some module for Apache enabling support).
Simplest solution is usually to have the Web Socket listen on a different port (from port 80) and have your application code handle Web Socket connections directly. But the safest bet is always to connect on port 80 since ports might be blocked for various reasons. I've experienced this on past projects where a percentage of users couldn't connect to the designated, non-web-standard port. Effectively taking away the real-time experience from these users.

Doing a graceful degradation of Web Sockets/pubsub in browsers is usually tricky. Some open-source projects like Socket.IO have been trying to solve this, but so far there aren't many server-side implementations. But they are getting there. The reference implementation is in node.js.

But if you want something simpler, check out our service Beaconpush (http://beaconpush.com). We handle the browser compatibility and scaling for you. On top of that we even offer user presence which can be nice. Ruby libraries and a self-hosted version are available too.

Re: http://harry.me/2011/01/27/today-web-development-sucks/

cgbystrom — Tue, 01 Feb 2011 15:32:39 -0000

Agree with you on most points.

However on some points I'm not as convinced. Take the DOM abstraction, it works and is implemented by several SPA frameworks. You can design good looking, "desktop class" applications pretty fast. But problem arises quickly when your graphic designers send you those PSD mockups, full of great looking artwork waiting to come to life.

With a normal DOM approach you've always been able to solve this. With hacking some HTML, tuning CSS and a lot of swearing you pull through.
But with SPA frameworks that favor "components" over low-level, raw DOM elements things usually aren't as straightforward. Very often you need to start picking apart the provided "ready-made components" to get any work done. Ends up being very contra-productive and usually takes way longer to do.

It has happened to me numerous times before with both GWT and Adobe Flex. Nice and shiny, given you don't try changing the layouts too much.
Surely, I'd be one happy camper if this wasn't the case, web development need to move forward. And I hope the goals proclaimed by both Cappuccino and Sproutcore will work in practice some day.

Regarding your other point about routing, departing from the route paradigm will be only be true if what your designing is not a document-centric application. In my world, an SPA can be either document-centric or desktop-like (containing a lot of UI state, as you mention). Think the answer to that is the boring "it depends".

Worth mentioning, many of these issues are stuff we've been trying to resolve with the Planet Framework (http://www.planetframework.com), essentially bridging the gap between client and server.

Re: http://blog.skialbainn.com/post/785931680

cgbystrom — Wed, 01 Sep 2010 12:06:40 -0000

Great, is it ok if I add it to the list of open-source contributions on our page?

Re: http://blog.skialbainn.com/post/785931680

cgbystrom — Sun, 22 Aug 2010 07:00:32 -0000

Nice work! Have you considered posting what you've accomplished on GitHub or similar site?

--
Carl
http://beaconpush.com

Re: Should browsers have an expiration date?

cgbystrom — Mon, 05 Jul 2010 06:11:24 -0000

Google Chrome already does this and it's great. It allows a user to forget what version he/she is running. Chrome is Chrome is Chrome. Doesn't matter what version it is, it's always the latest version.

Re: CentOS and Fedora Packages - MongoDB - 10gen Confluence

cgbystrom — Wed, 02 Jun 2010 07:21:01 -0000

In other words:
yum install mongo-stable-server

(after you added the repo)

Re: URLs are the Uniform Way to Locate Resources

cgbystrom — Mon, 24 May 2010 03:34:49 -0000

Good read.
For those who always seem to mix up URI and URL, here's an explanation http://www.damnhandy.com/20...

Re: Intridea Blog: The Future's Pretty Cool, or Why I Love Ruby

cgbystrom — Wed, 28 Apr 2010 14:06:46 -0000

You may add to that: working package management (RubyGems) and a de facto build tool (Rake).
The famous BDD/Spec syntax that came out of the RSpec hype was also made popular by the Ruby community.

Curiosity is king.

Re: Production Server Sysadmin Essentials

cgbystrom — Sun, 07 Feb 2010 16:19:34 -0000

Nice write-up. Please, do a follow-up!

Re: RubyFoo Slides

cgbystrom — Sat, 03 Oct 2009 06:23:38 -0000

We seem to agree on the processes of the game industry. Always had the firm belief that they, well could improve tremendously by taking a look at how we do it in web development. Continuous integration, testing, frequent deployments and so on.

Have you got more game dev anecdotes to share?

Re: Close to the Problem

cgbystrom — Sun, 03 May 2009 16:50:11 -0000

Sadly enough, nobody ever got fired for choosing Oracle or SAP.
It's a passive choice and when it fails you can just say "Everyone else is doing it".
However, when things fail because you chose LAMP, it's _your_ ass on the line and it's all _your_ fault.

Re: Web Browser as Thick Client

cgbystrom — Thu, 05 Feb 2009 16:51:29 -0000

Persevere http://www.persvr.org/ is pretty cool too, somewhat similar to CouchDB.

However doing the wrong types of applications/sites as "thick clients" scares me. Much of the web's success lies in the fact that pages are well, pages. I want to have proper URLs, link my pages, view the source, have search engines scout my site and so on.
In all this I think we are going to see a "boom" in thick clients just as everything was supposed to be "thin clients" a few years a go (aka web pages). But eventually I think developers will learn and end-users too. Just as it is with any technology, no one (including authors) will "get it" from the start. This is what makes global/social technology like the web so exciting.

The web really is young! :)

Re: Some Thoughts on Logging

cgbystrom — Sun, 25 Jan 2009 09:51:24 -0000

Have a look at Facebook's Scribe http://developers.facebook....
It's their low-level client-server logging framework. Looks quite performant and built upon Thrift, so it's interoperable. Haven't used Scribe myself, but Thrift is truly great. Been using it for over a year and it-just-works.