Thepalmcivet

via

[m]

stop freaking out. here’s that video of magnetic putty eating metallic things that you didn’t know you needed.

Behold the latest work from animator Jake Fried (previously) who works with layer after layer of ink, gouache, white-out and coffee to create deeply textured and truly psychedelic animated shorts. Fried lives and works in Boston where he is primarily known for his painting, but has recently begun focusing on these experimental animations he refers to has “moving paintings,” many more of which you can see on his website.

Warp Records have made the video for Mount Kimbie‘s ‘Made to Stray’ live.

Taken from the group’s forthcoming second album, Cold Spring Fault Less Youth, its a candy-coloured treat that suits the warm, wiggy feel of the music. It’s directed by Leif Podhajsky and can be watched above; a recent FACT interview with Mount Kimbie’s Dom Maker about signing to Warp and the duo’s new album can be read here. You can find out what the FACT Singles Club thought about ‘Made to Stray’ here.

So Google created Blink, the new rendering engine for Chrome and Opera. What exactly is going on, and what will the consequences be?

Here are some notable sources on Blink that I used for this overview:

• Blink homepage and developer FAQ.
• Chromium feature dashboard, where you can see which new features are going to be added. Can use an interface upgrade; right now it’s hard to read.
• Alex Russell on Blink.
• Jake Archibald on Blink.
• Bruce Lawson on Opera’s adoption of Blink.

In addition to this information, Peter Beverloo was kind enough to send me some more by email.

What is Blink?

Blink is a new rendering engine, which means that it won’t interpret CSS and JavaScript quite the same as WebKit (or Gecko or Trident, for that matter). It will power all browsers that use Chromium, Google’s open source browser.

Blink has been forked from WebKit, which means that right now it’s almost the same as WebKit. Still, WebKit itself is not a singular entity; as my research showed time and again, one WebKit-based browser does not support exactly the same CSS and JavaScript as another. Right now it’s safe to see Blink as a kind-of WebKit.

That will change in the future. From now on, WebKit and Blink will proceed along different paths, with different goals and different supported features. At the moment code sharing between Blink and WebKit is still possible, but over time this will become less easy due to increasing differences between the two.

So Blink is a WebKit version right now, but will move away from WebKit over time, just like any fork does.

Why Blink?

Google wasn’t happy with the lack of progress in the WebKit project. This lack is mostly caused because the actual WebKit rendering engine is intertwined with implementation details that are only important for one platform — and the number of supported platforms is growing, especially in the mobile world.

Therefore Google decided to remove platform-specific code from WebKit, re-vamp the security model, and make a few other changes that will allow for quicker progress in CSS and JavaScript support.

If you have already decided Google is Evil you will not believe this explanation.

Which browsers will use Blink?

Blink has been built on top of Chromium, Google’s open-source browser. Chrome uses Chromium, as does the Yandex browser. Opera will start doing the same from version 14 on. Therefore all these browsers will use Blink in the future.

Chrome 28 will be the first stable release to use Blink; earlier versions will use WebKit. Opera and Yandex will start using Blink whenever they start using Chromium 28.

Currently Chromium is available for Windows, Mac, desktop Linux, and Android. It seems unlikely Google will port it any further, but others could.

An important Chromium component is Skia, the drawing engine. BlackBerry already ported it, which means it’s one step closer to implementing Chromium than other WebKit users. Whether BlackBerry, or anyone else, will actually make the switch is a political question as much as a technical one.

It’s theoretically possible to use Blink without Chromium, but there are so many dependencies that it’s unlikely this will ever happen.

What will change for me as a web developer?

Right now, nothing will change for web developers. The change-over from WebKit to Blink will be imperceptible — even the browser’s UA string will not change in the near future. Sure, you must test your sites in Chrome and Safari, as well as Opera, IE, Firefox, a bunch of mobile WebKits, and so on. But you were already doing that — weren’t you?

One change I rather like is Blink’s approach of vendor prefixes, which mirrors Firefox’s. It has copied all currently-existing -webkit- prefixes from WebKit, but will not add any new ones and will gradually remove the old ones when it becomes safe to do so. Instead of prefixes it will use flags: if you want to enable an experimental feature, set the appropriate flag in about:flags. (Incidentally, this means that experimental CSS features that would be prefixed are not available to the average user, who won’t set any flags.)

What about interoperable implementations?

It is W3C’s stated policy that two interoperable implementations are required for any new standard. I worried about this when Presto died and the number of rendering engines was brought down to three.

Now the number of rendering engines goes back up to four, and any WebKit feature is automagically supported by two interoperable implementations: WebKit and Blink.

Is Google Evil?

But ... but ... isn’t this a cynical move? Isn’t the openness stuff all a sham? Doesn’t Google simply want to deny a modern rendering engine to Apple and lock other Chromium-using browser vendors in?

If you wish to believe the Chrome team is acting cynically here I can’t stop you. I don’t believe it myself, though.

Sure, there is a political compoment to all of this. Google would like other browser vendors to switch from WebKit to Blink, and may exert some pressure.

Also, Google’s engineers will no longer contribute to WebKit, and other WebKit users will start to feel the pinch in another few months. Still, it’s theoretically possible that Apple and BlackBerry and Samsung and the rest take over where Google left off. And if they don’t ... what does that say about whom?

Besides, Google gave us a tool to measure its evilness: the compatibility section of the Blink homepage. Basically, a feature will be added if there’s strong browser support, or a nearly-finished spec, or moderate browser support PLUS a working draft.

This policy is eminently checkable: as soon as we see features appear that are not in other browsers and also not specified, we know that Google has gone over to the dark side. In the absence of such features we should conclude that Google’s evilness is not proven.

What about fragmentation?

As to the idea that Blink will increase fragmentation on the web: I don’t see that happening.

Chrome’s current WebKit implementation is different from everybody else’s (including Android WebKit’s), and the new rendering engine doesn’t change that.

Blink-based browsers will be more alike than WebKit-based browsers. Use of Chromium is a de-facto requirement for using Blink, and that standardises a lot of additional tasks such as networking and drawing.

In the WebKit-based browsers these tasks were up to specific components that individual browser vendors had to write (and that were partly in WebKit itself). A lot of differences between WebKits come from this source, and Blink will be much less vulnerable. Besides, Google has a vested interest in keeping the various Chromium ports aligned.

So I expect Chrome and Opera to converge significantly, which will actually decrease fragmentation. And if more browser vendors switch to Blink, fragmentation will decrease even more.

Less fragmentation means more unification, which implies quasi-dictatorial powers, no matter how enlightened, for one company or group. The problem is that Google critics seem to want neither, and that’s impossible. You can’t simultaneously oppose fragmentation and unification. You must choose one of the two to rail against.

Blink

So all in all I’m positive about this change. It’s likely that Blink will indeed speed up progress, as the Chrome team claims, it will not increase fragmentation, and little will change for web developers in the short run. What’s not to like?

One thing, though: the Blink team has a moral obligation to implement text-decoration: blink.

Here are some more notes and links.

Sketch group The Birthday Boys has been making waves in Los Angeles for years, earning some famous fans along the way. Probably the most notable among them are Ben Stiller and Bob Odenkirk, who are executive producing a new TV show from the group for IFC.

The deal didn’t come together without some demands from The Birthday Boys, as Odenkirk spells out in the video below.

The 10 half-hour episodes will debut in October on IFC. 

Label: Not On Label (Ceephax Acid Crew Self-Released)

Tracklist
1. Cooling Ponds (Drowning) (4:52)
2. National Grid (2:46)
3. Winterlo (4:37)
4. Natural Spectrum (2:56)
5. Memory Lake (3:13)
6. Camelot Science (5:47)
7. Transcontinental Power Lines (6:22)
8. Cro Magnox (5:05)
9. Quincy’s Classic (5:43)
10. Imperial Lounge (Maximillion) (4:19)
11. Voyage Of Excellox (2:01)
12. Cobra Mist (Pylon Emotions) (2:19)
13. Flight Of The Condor (7:45)
14. Reactor (3:00)
15. Newhaven Lights (6:35)
16. Forest Zone 303 (4:36)
17. Voyage Of Excellox (Original) (1:54)
18. Cobra Mist (Sidstation Version) (1:39)

Comments

This is an Icelandic waterfall called Litlanesfoss and the naturally occurring rock formation is columnar jointed basalt.

The columns form due to stress as the lava cools. The lava contracts as it cools, forming cracks. Once the crack develops it continues to grow. The growth is perpendicular to the surface of the flow. Entablature is probably the result of cooling caused by fresh lava being covered by water. The flood basalts probably damned rivers. When the rivers returned the water seeped down the cracks in the cooling lava and caused rapid cooling from the surface downward. The division of colonnade and entablature is the result of slow cooling from the base upward and rapid cooling from the top downward.

One of the coolest things I have ever seen. Looks totally fake, like they built it for Fractal Falls in Polygon Gorge at Disneyland or something. Giants Causeway in Northern Ireland looks amazing as well. Check out several similar formations from around the world.

Disclaimer: this is a story about Ruby web frameworks, and I have commit bit to Rails

Ruby has a long tail of web frameworks. There’s the big dogs, Rails and Sinatra, there’s some smaller frameworks with a devoted following like Padrino or Camping, and then there’s a ton of other frameworks like Ramaze, Merb, Cuba, or Renee.

Now, we have another: Scorched. Here’s what it has to say about itself:

Scorched is a true evolutionary enhancement of Sinatra, with more power, focus, and less clutter.

This looks to be true. Here’s a Hello World in Scorched:

require 'scorched'
class App < Scorched::Controller
  get '/' do
    'hello world'
  end
end
run App

Here it is in Sinatra:

require 'sinatra/base'
class App < Sinatra::Base
  get '/' do
    'Hello world!'
  end
end
run App

Sooooo yeah. What’s different about it then? It takes on a very anti-”full stack” philosophy:

unlike other lightweight web frameworks that attempt to hide Rack in the background, Scorched makes no such attempts, very rarely providing functionality that overlaps with what’s already provided by Rack. In fact, familiarity with Rack is somewhat of a pre-requisite to mastering Scorched.

You can do this kind of thing with Scorched, which somehow makes it feel even more low-level than Sinatra, yet higher-level than Rack:

map pattern: '/', priority: -99, conditions: {methods: ['POST', 'PUT', 'DELETE']}, target: proc { |env|
  [200, {}, 'Bugger off']
}

The documentation is pretty, and seems very full.

Scorched is also sponsored by Phusion, who make the popular Passenger app server.

You can get the code on GitHub, of course!

One more note: it was pointed out to me on Twitter that Scorched requires Ruby 2.0 only, and that’s true:

Scorched requires Ruby 2.0 as it makes use of a couple of new features. By the time Scorched hits v1.0, there should be little reason not to be running Ruby 2.0.

The post Scorched: a new Ruby web framework appeared first on The Changelog.

Have a chat with the most awkward chatbot around.

Photographer Martin Rietze recently traveled to Japan where he had the incredible opportunity (or near grave misfortune?) of photographing the Sakurajima Valcano in southern Kyushu as it spewed forth smoke, fire, and lava bombs. If that wasn’t enough the hellish volcano also caused a lightning show that lasted over 20 seconds giving the photographer ample time to flee for his life take these stunning photographs. You can see many more images from the series right here. Of note, the photographer’s grit and fearlessness landed the top photo a feature on NASA’s Astronomy Picture of the Day earlier this week. (via spoon & tamago)

Taken from an anthology entitled Prince of Darkness, 1946

The illustrations are details from The Temptation of St Anthony, an etching by Jacques Callot, 1630

via Front Free Endpaper

A grouper is examined by three kittens at Marineland in Florida, 1938.
Photograph by Luis Marden, National Geographic

Nudity detection with JavaScript and HTMLCanvas.

nude.js is a JavaScript implementation of a nudity scanner based on approaches from research papers. HTMLCanvas makes it possible to analyse image data and return whether it’s nude or not.