slablet: Stylish CSS layout for iPad and more:

If you like Sench Touch, the HTML5 mobile framework we recently covered in Episode 0.3.0, but long for a more declarative, markup-driven approach, then keep an eye on Slablet from Fellowship Technologies.

Slablet, as defined by Urban Dictionary:

(n.) - a slang word for a computer tablet such as the iPad or other branded tablet devices

Unlike Sencha’s JavaScript-centric approach, Slablet opts for a more unobtrusive implementation. Content is created in HTML, styled with CSS, and driven by jQuery. The project uses iScroll to provide overflow:scroll in its fixed height elements.

Fellowship has provided a few nice looking demos.

If you’re wanting to start developing split-pane interfaces for the iPad, give Slablet a look.

[Source on GitHub]

Episode 0.3.2 - 960.gs with Nathan Smith:

Adam and Wynn caught up with Nathan Smith from 960 Grid System to talk about web development and CSS grid frameworks.

Download MP3

Items mentioned in the show:

• 960 Grid System - Nathan’s awesome CSS grid framework
• 960’s awesome templates help you plan your layouts
• Wynn’s new monitor setup is just plain obscene
• 960’s fluid support from Stephen Bau
• Episode 0.2.8 where John Resig talks about mobile web dev
• Episode 18 of the yayQuery podcast
• Wynn asks why Google’s AJAX API library doesn’t include the CSS frameworks
• Nathan and Wynn are fans of Jason Santa Maria’s layout-per-post blog
• For the non-soccer fans, a little background for Nathan’s midfielder analogy.
• We don’t need to link to Sass do we?
• Taco Town from SNL
• jQuery Cookbook, to which Nathan contributed lucky Chapter 13
• Nathan is a big Drupal fan
• Rebecca Murphy organizer of the awesome TXJS conference
• Textile vs. Markdown

kinisoftware creado un video en español que explicando como preparar un entorno de desarrollo de Grails que utilizando Git y SpringSource.

kinisoftware gracias!

A couple weeks ago we finally released Devise 1.1 which is fully-compatible with Rails 3! Not only that, we’ve been working with Rails 3 since the first betas and several features were added along the way! Let’s take a look at those, some architectural changes and see how Devise 1.1 and Rails 3 will change how you handle authentication.

Pretty URLs with Metal

A common complaint in Devise 1.0 (for Rails 2.3) was, in order to know which message to show to the user when sign in failed, we had to pass a parameter in the URL as in /users/sign_in?unauthenticated=true while one would expect us to simply use flash messages. This happened because the redirection was done not from inside a controller, but a Rack application set up in Warden (a Rack authentication framework Devise relies on) and we could not access flash messages from it.

However, since Rails 3 moved several responsibilities to the Rack layer, including flash messages, we can easily access flash messages from any Rack application, allowing us to remove the parameter from the URL! Even more, Rails 3 provides small, fast, bare bone controllers through ActionController::Metal, which we used in Devise to clean and speed up the code considerably.

Locking goodness

The lockable module in Devise also went through a major overhaul. Previously, it already supported :unlock_strategy as option, allowing you to specify if the user could be automatically unlocked after a time period, through an e-mail token or both. Now, it also supports :none as option, meaning that all unlocking should be done manually.

Even more, there is a new option called :lock_strategy, that allows you to specify whether the lock happens only manually or after an amount of invalid sign in attempts.

HTTP Authentication on by default

In Devise 2.3, you may remember that we had a module called :http_authenticable along with :database_authenticatable and :token_authenticatable. While all three worked great, it was confusing that all HTTP authentication features were built on top of the database authentication and it was not possible to do HTTP authentication using a token unless we created a forth module called :http_token_authenticatable. We quickly noticed this could be improved by providing a better design and better abstract Devise authentication strategies.

And that is what happened in Devise 1.1. Now both database and token authentication work through HTTP with no extra work and the http authenticatable module was deprecated. Besides, if you are creating a new strategy on your own, you get both authentication through parameters (form) and HTTP with no extra work!

Routing customizations

We built Devise to be a full stack solution with customization in mind. In Devise 1.1, the customization abilities from Devise were taken to the next level. Now the devise_for method in routes accepts to extra options: :skip and :controllers. The first one allows you to skip the routes generation for a given controller/module in case you want to define them on your own, while the second allows you to change the router to point to a given controller in your application, like Users::ConfirmationsController instead of Devise’s internal controller.

Talking about Devise’s internal controller, Devise 1.1 namespaced all controllers classes, so now we have Devise::ConfirmationsController instead of ConfirmationsController.

Another limitation removed from Devise in this new version is related to URLs customizations. In prior versions, Devise used the URL to retrieve which scope is being accessed. That said, if you were accessing “/users/sign_in”, Devise had to inspect this URL and find the “/users” bit to specify the current scope is “users”. The same happened to “/admin/sign_in”.

This had a huge impact in URL customization, because if you wanted to have an URL like “/some_prefix/users/sign_in”, you had to tell Devise you were appending a prefix. Things could get even uglier if you wanted to prepend dynamic prefixes like “/:locale”.

In Devise 1.1, we use the new contraints API and Rack capabilities from the new router to specify which scope to use. So, instead of inspecting the URL, Devise retrieves the user from the request’s env hash as request.env["devise.mapping"].

For all the routes generated by devise_for, Devise automatically sets this value in the env hash. However, if you are creating your own routes, you need to set it manually using the constraints API:

constraints lambda { |r| r.env["devise.mapping"] = Devise.mappings[:user] } do
  # Add a custom sign in route for user sign in
  get "/sign_in", :to => "devise/sessions"
end

Of course, since this is rather a common pattern, we encapsulated it in a nice API:

devise_scope :user do
  # Add a custom sign in route for user sign in
  get "/sign_in", :to => "devise/sessions"
end

You can simply give a block to devise_for as well and get the same result:

devise_for :users do
  # Add a custom sign in route for user sign in
  get "/sign_in", :to => "devise/sessions"
end

All the routes specified in the block have higher priority than the ones generated by devise_for.

Awesomeness pack

The last feature we want to discuss is also a routing customization, but we decided to leave it up for last because it shows all the potential coming with Rails 3 and Devise 1.1.

In Devise 1.1, we added the ability to require authentication for a given url in the router, besides the existing before filters in controllers. This allow us to easily require authentication for third party rack application without a need to hack into them. Kisko Labs posted an interesting case where you can use Devise to require authentication to a Resque application in very few lines of code:

authenticate :admin do
  mount Resque::Server.new, :at => "/resque"
end

Devise simply uses the constraints API discussed above, allowing the request to continue only if the user is already authenticated. Otherwise, it redirects the admin to the sign page managed by Devise inside your Rails application. Indeed, when you have Rack, Rails 3 and Devise 1.1 playing along, great things can be accomplished quite easily!

There are several other features, bug fixes and deprecations included in this release, we invite you to check the CHANGELOG and take a look at them!

And we are happy to say this is not all, there is much more to come in Devise 1.2, including OAuth2 support which is already added in the master branch. Enjoy!

iOSDevCamp 2010 is being held at the PayPal headquarters in San Jose, California this weekend.

What is it? Straight from the horse's mouth:

iOSDevCamp (previously know as iPhoneDevCamp and iPadDevCamp) is an annual not-for-profit gathering to develop applications for iOS, including iPhone, iPad, and iPod touch, using both the native SDK and web standards.

I'll be there Saturday — say hi if you're attending!

Engine Yard has a long history with open source software. We have supported many big name projects over the years including Merb, Ruby 1.8.6, Rubinius, JRuby, and Rails. In addition to these larger projects, we also strive to open source internal technology that benefits the community as a whole. These projects are usually less well known, but we'd like to fix that.

Today we are announcing that the Engine Yard command line client is fully open sourced.

First, we have developed a new deployment tool that runs on the instance that is being deployed to. This code runs when you deploy from the command line, and will soon be the default for deploying from the dashboard. The code is available at engineyard-serverside.

The second component is the engineyard gem itself, a client library for our dashboard API. It is primarily used for managing custom recipes and deployment, but it will continue to expand over time. This code is available at engineyard.

The Engine Yard CLI was announced last month and we have a complete overview on the blog. This new deployment system separates the deployment of your code, and the configuration of your cluster. This allows code to be deployed without any fear of incompatible configuration, and allows configuration changes to your server when the time is right for you. We provide even more flexibility through simple hooks into the deployment process, allowing you to completely override the way deployments happen. You can read about these and other features in greater detail in our recently revamped documentation site

Please feel free to send pull requests and file any bugs or feature requests using Github Issues.

Today Facebook announced “Facebook Places” or “The Third Place,” a new feature that allows its 500MM users to check into a location just about anywhere.

Starting today, you can immediately tell people about your favorite spot with Facebook Places. You can share where you are and the friends you’re with in real time from your mobile device.

Highlights

At each location, Places lets you see your friends and other Facebook members (even if they’re not your friends), who are nearby, a feature called “People Here Now.”

Friends

You can tag your friends when you check in to a place. You have to allow proxy check-ins to have them post to your profile, but they’ll still post on the Place page.

What does this mean for businesses?

• Share where you are

• See where your friend are

• Find new places to go

• Will be integrated into Facebook Pages

• Reporting Places (Report, Abusive, Permanently closed, Duplicate)

Mobile Device Support

• New Facebook iPhone app with Facebook Places support is coming tonight
• Android, Blackberry and all other Facebook app enabled phones will be Places enabled in the coming months
• Places should work fine on any modern mobile browser

Developers and API

• Places available with a read API

• Write & Search API are in private beta

Places Partners

• Gowalla, Foursquare, Brightkite, Booyah, Yelp etc will integrate it instead of getting killed by the 500 pound gorilla

• Foursquare is a “partner”, but has nothing to announce concerning integration. “This basically validates that we’re on to something” with check-ins, says Holger Luedorft from Foursquare. Foursquare says they’ll continue to work on their platform and look forward to leveraging the Facebook Places API.

• Yelp and Keith Lee from Booyah, made a new app in three weeks using the Places API, called InCrowd. It will be available for the iPhone within the next few weeks.

General Usage

• Places will be U.S. only for now. Facebook will be rolling out slowly – starting tomorrow.

Reactions and Privacy

• As expected, the ACLU has its hands all over Facebook Pages concerning privacy implications.

• Default for check-ins is “friends-only.” You can remove any tag or check-in. You can opt out of being tagged in others’ check-ins.

Your thoughts

How do you Places will be received by the rest of the world? Will you stop using Foursquare or GoWalla in favor of Facebook Places. Let us know in the comments.

Updates

Stay tuned, we’ll keep you posted with any new updates to Facebook Places right here.

Moore's Law marches on, the transistor counts are continuing to increase at the predicted rate and will continue to do so for the foreseeable future. However, what has changed is where these transistors are going: instead of a single core, they are appearing in multi-core designs, which place a much higher premium on hardware and software parallelism. This is hardly news, I know. However, before we get back to arguing about the "correct" parallelism & concurrency abstractions (threads, events, actors, channels, and so on) for our software and runtimes, it is helpful to step back and take a closer look at the actual hardware and where it is heading.

Single Core Architecture & Optimizations

The conceptual architecture of a single core system is deceivingly simple: single CPU, which is connected to a block of memory and a collection of other I/O devices. Turns out, simple is not practical. Even with modern architectures, the latency of a main memory reference (~100ns roundtrip) is prohibitively high, which combined with highly unpredictable control flow has led CPU manufacturers to introduce multi-level caches directly onto the chip: Level 1 (L1) cache reference: ~0.5 ns; Level 2 (L2) cache reference: ~7ns, and so on.

However, even that is not enough. To keep the CPU busy, most manufacturers have also introduced some cache prefetching and management schemes (ex: Intel's SmartCache), as well as invested billions of dollars into branch prediction, instruction pipelining, and other tricks to squeeze every ounce of performance. After all, if the CPU has a separate floating point and an integer unit, then there is no reason why two threads of execution could not simultaneously run on the same chip - see SMT. Remember Intel's Hyperthreading? As another point of reference, Sun's Niagara chips are designed to run four execution threads per core.

But wait, how did threads get in here? Turns out, threads are a way to expose the potential (and desired) hardware parallelism to the rest of the system. Put another way, threads are a low-level hardware and operating system feature, which we need to take full advantage of the underlying capabilities of our hardware.

Architecting for the Multi-core World

Since the manufacturers could no longer continue scaling the single core (power, density, communication), the designs have shifted to the next logical architecture: multiple cores on a single chip. After all, hardware parallelism existed all along, so the conceptual shift wasn't that large - shared memory, multiple cores, more concurrent threads of execution. Only one gotcha, remember those L1, L2 caches we introduced earlier? Turns out, they may well be the Achilles' heel for multi-core.

If you were to design a multi-core chip, would you allow your cores to share the L1, or L2 cache, or should they all be independent? Unfortunately, there is one answer to this question. Shared caches can allow higher utilization, which may lead to power savings (ex: great for laptops), as well as higher hit rates in certain scenarios. However, that same shared cache can easily create resource contention if one is not careful (DMA is a known offender). Intel's Core Duo and Xeon processors use a shared L2, whereas AMD's Optetron, Athlon, and Intel's Pentium D opted out for independent L1's and L2's. Even more interestingly, Intel's recent Itanium 2 gives each core an independent L1, L2, and an L3 cache! Different workloads benefit from different layouts.

As Phil Karlton once famously said: "There are only two hard things in Computer Science: cache invalidation and naming things," and as someone cleverly added later, "and off by one errors". Turns out, cache coherency is a major problem for all multi-core systems: if we prefetch the same block of data into an L1, L2, or L3 of each core, and one of the cores happens to make a modification to its cache, then we have a problem - the data is now in an inconsistent state across the different cores. We can't afford to go back to main memory to verify if the data is valid on each reference (as that would defeat the purpose of the cache), and a shared mutex is the very anti-pattern of independent caches!

To address this problem, hardware designers have iterated over a number of data invalidation and propagation schemes, but the key point is simple: the cores share a bus or an interconnect over which messages are propagated to keep all of the caches in sync (coherent), and therein lies the problem. While, the numbers vary, the overall consensus is that after approximately 32 cores on a single chip, the amount of required communication to support the shared memory model leads to diminished performance. Put another way, shared memory systems have limited scalability.

Turtles all the way down: Distributed Memory

So if cache coherence puts an upper bound on the number of cores we can support within the shared memory model, then lets drop the shared memory requirement! What if, instead of a monolithic view of the memory, each core instead had its own, albeit much smaller main memory? Distributed memory model has the advantage of avoiding all of the cache coherency problems we listed above. However, it is also easy to imagine a number of workloads where the distributed memory will underperform the shared memory model.

There doesn't appear to be any consensus in the industry yet, but if one had to guess, then a hybrid model seems likely: push the shared memory model as far as you can, and then stamp it out multiple times on a chip, with a distributed memory interconnect - it is cache and interconnect turtles all the way down. In other words, while message passing may be a choice today, in the future, it may well be a requirement if we want to extract the full capabilities of the hardware.

Turtles all the way up: Web Architecture

Most interesting of all, we can find the exact same architecture patterns and their associated problems in the web world. We start with a single machine running the app server and the database (CPU and main memory), which we later split into separate instances (multiple app servers share a remote DB, aka 'multi-core'), and eventually we shard the database (distributed memory) to achieve the required throughput. The similarity of the challenges and the approaches seems hardly like a coincidence. It is turtles all the way down, and it is turtles all the way up.

Threads, Events & Message Passing

As software developers, we are all intimately familiar with the shared memory model and the good news is: it is not going anywhere. However, as the core counts continue to increase, it is also very likely that we will quickly hit diminishing returns with the existing shared memory model. So, while we may disagree on whether threads are a correct application level API (see process calculi variants), they are also not going anywhere - either the VM, the language designer, or you yourself will have to deal with them.

With that in mind, the more interesting question to explore is not which abstraction is "correct" or "more performant" (one can always craft an optimized workload), but rather how do we make all of these paradigms work together, in a context of a simple programming model? We need threads, we need events, and we need message passing - it is not a question of which is better.

Yuki (Yugui) Sonoda has just announced the release of the stable version of Ruby 1.9.2!

Ruby 1.9.2 has been released. This is the newest release of Ruby 1.9 series. Ruby 1.9.2 is mostly compatible with 1.9.1, except the following changes:

• Many new methods
• New socket API (IPv6 support)
• New encodings
• Random class that supports various random number generators
• Time is reimplemented. There is no longer the year 2038 problem.
• some regexp enhancements
• $: no longer includes the current directory.
• dl is reimplemented on top of libffi.
• new psych library that wraps libyaml. You can use the library instead of syck.

Yuki Sonoda

Ruby 1.9.2 passes 99% of RubySpec and, if you haven't already given it a go, offers worthwhile performance increases over Ruby 1.9.1 and significant performance improvements over the 1.8.x series.

Intriguingly, Ruby 1.9.2 is only considered to have full, verified support on Debian Linux on 32 bit Intel architectures, with support for OS X 10.5 and 10.6, FreeBSD, Windows, and Solaris considered "best effort." Linux distributions other than Debian are listed in the lower "perhaps" category for support, so running your own tests is more essential than ever before moving to 1.9.2 in production.

Installing

As always, the source can be picked up from the official sources at ruby-lang.org:

http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p0.tar.gz
http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p0.tar.bz2
http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p0.zip

Or, you can use RVM, which has already been updated to support the release:

rvm update --head && rvm reload && rvm install 1.9.2 && rvm 1.9.2 --default

For the third straight year in a row, senior-level Intrideans will be at the Lonestar Ruby Conference, on Thursday, August 26th, teaching students about Ruby. Students attending the Ruby Intrigue class will work with our Director of Mobile Development, Brendan Lim, our Director of Development, Adam Bair, and our Director of Research and Development, Pradeep Elankumaran.

In a small class setting, students will work on writing a web crawler, an Asteroids clone, and an SMS server. The instructors will also discuss coding practices and methodologies along the way. In keeping with tradition, we have three instructors to ensure a laid-back and collaborative atmosphere. Students will walk away with three different hand-crafted applications, an overwhelming feeling of accomplishment, and a spiffy t-shirt designed by our creative mastermind, David Potsiadlo.

Lonestar Ruby Conference is part of the Lonestar Ruby Foundation, which aims to educate the public about the Ruby Language. The conference, held in Austin, Texas, is in its fourth year and continues to boast a strong lineup of presenters and teachers. This year's lineup includes Blake Mizerany, the creator of Sinatra, Tom Preston-Wernor, co-founder of Github, Gregg Pollack, James Edward Gray II, and many other prominent members of our community.

Registration is still open for the conference and for the Ruby Intrigue class. If you're local to the area, or if you want to spend some time learning about Ruby in the "live music capital of the world", be sure to sign up today!

http://labs.headlondon.com/2010/07/skinny-daemons/ (or on Ruby Inside)

[W]e’ve been having a lot of fun writing a series of small, self-contained web apps .. When we’re building these kinds of applications, which are often meant as low-ceremony apps targeted at a very specific purpose, or as service utilities, a lot of the time we don’t want to go through the hassle associated with a “normal” web app.

Dave Hrycyszyn

In Skinny Daemons, Dave Hrycyszyn presents a practical walkthrough of how he builds what he calls "skinny daemons" - small, HTTP based daemons to perform single tasks that are then packaged up into gems for easy installation (across multiple servers, for example). It's a practical demonstration and holds your hand the whole way. Useful stuff.

An example of a skinny daemon is enigmamachine, a video processor Web service using ffmpeg to convert videos to profiles of your choice.

Lets do this meetup thing.

The Facts:

Benders Bar 806 S Van Ness Ave (between 19th& 20th St) Thursday, August 19th 2010 8:30pm