El festival de música y arte digital 3D Animation Rocks (3DAR) comenzará este viernes con la participación de bandas de rock como Superlasciva y Fantasmagoria en el porteño Centro Cultural Borges.

El 3 DAR es un ciclo que reúne bandas en vivo, tecnología y arte digital en el que se ofrecerá un festival de rock y arte visual, karaoke virtual, Teatro Electrónico Siggraph 2010, conferencias, exhibición de arte digital, exposición de escuelas y universidades (Cortos y Feria) y el primer campeonato nacional de Guitar Hero.

El festival de rock que contará con la presencia de 15 bandas consagradas del circuito under acompañadas por contenidos visuales realizados por artistas independientes, alumnos de las universidades y escuelas de arte electrónico, video, cine y animación tendrá lugar en el auditorio Astor Piazzolla.

El ciclo tendrá un segmento denominado “Teatro Electrónico Siggraph” en el que se proyectará la selección de los mejores cortos del Festival Internacional de Animacion 3D SIGGRAPH 2010.

Se realizarán conferencias en la que especialistas de las áreas de producción de contenidos digitales, música y tecnología abordarán temas como la producción de una película de visión 3D, la producción de efectos especiales, animación 3D con sensores y sobre la historia del rock argentino.

También habrá una exhibición de arte digital con muestras de arte contemporáneo de artistas digitales y un karaoke virtual como entretenimiento de canto y animación para el público durante los intervalos.

La programación de las bandas en el Auditorio Astor Piazzolla es la siguiente:

El viernes 20 comenzará el ciclo con una charla apertura 3D Animation Rocks a las 19 y luego se presentarán [mgo], Lache, Silentio y Fantasmagoria.

El sábado 21 a partir de las 15 estarán presentes Des21, Bigger, Tal Banda, Robot Zonda, Hyperknox, Eruca Sativa y Utopians.

Cronograma completo en 3danimationrocks.com/cronograma

Fuente: Télam / Revista Ñ

Hands up if you've ever seen Ubuntu-based Linux Mint's rather slick menu? Keep you hands up if you've ever wanted to install it in Ubuntu? Wow. That's a lot of hands!

Thankfully KdotJ over on the Ubuntu Forums has made the entire process stupidly simple with clear steps and concise instructions.

From installing it to tweaking it you'll find everything you need to add some minty freshness to your desktop over @ this link

Detección de rostros en imágenes utilizando PHP:

Clase PHP para detectar rostros en imágenes. Visto en blogfreakz.com

You’ve been seeing it for a while now with Google’s Reader, Gmail, and most recently, on Facebook. Probably, you, too, would like to write RESTful evented JavaScript applications. Well, fellow developers, meet Sammy.js, a tiny JavaScript framework built on top of jQuery. Sammy utilizes the URL hash (#) to allow you to create single page AJAX applications that respond to your browser’s back button. Interested?

In this article, I’ll be providing a short overview of the framework, and then a brief demonstration of what it’s like working with Sammy.js, with the hope of enticing you enough to consider it for your projects.

---

Setting the Stage

“Sammy.js is light both in size (<20kb) and footprint. Pull it into your already started applications.”

Sammy.js is being put together by Aaron Quint, a web developer out of Brooklyn, NY. Its API is modeled on the popular ruby framework, Sinatra, and is great for both simple and complex applications. It’s easy to get into, and can be pulled into your existing projects. It’s not an all or nothing proposition; so let’s take a look.

Sammy.js allows you to write single page apps, much like Gmail. You can maintain the state of your app with the url, without having to refresh or change the page. There are other MVC JavaScript frameworks, like SproutCore, which tend to be all encompassing. But with Sammy, you have a light (~20kb) framework, capable of invoking several instances simultaneously (ie. running multiple apps in the same document).

---

Opening Act

Installing Sammy.js is pretty straightforward. Head on over to the download page, grab a copy and move, sammy-0.5.4.min.js to where you store your project’s libraries (typically /js for me). For the purpose of this article, I will be using version 0.5.4, but you may be inclined to try sammy-latest.min.js. You’ll also need a copy of jQuery, at least v. 1.4.1. As with most jQuery plugins, order is important: jQuery, before Sammy.js, before your JavaScript. I tend to put my JavaScript at the bottom of the page, because it blocks other items from loading in parallel, giving the impression of a slower loading page. So far we have:

    <!DOCTYPE html>
    <html lang="en">
    <head>
    	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    	<title>Sammy.js Example</title>
    </head>
    <body>

        <div id="content"></div>

        <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
        <script type="text/javascript" src="js/sammy-0.5.4.min.js"></script>
        <script type="text/javascript">

            // your script goes here

        </script>

    </body>
    </html>

Now to start coding our app. To keep things simple, I’m working inline, which isn’t the best practice. Adding a Sammy.js application is as simple as assigning it to a variable, which I’m calling ratPack. On our page we’ve defined a div with the id “content” upon which our application will be acting. We indicate this as follows:

    var ratPack = $.sammy(function() {

        this.element_selector = '#content';

        // routes will go here

    });

The importance of the element selector is that we can have multiple instances of Sammy.js running in our document, affecting different elements.

---

Main Attraction

Sammy.js uses the path, as defined in the URL hash, and the common HTTP methods (get, post, put, delete) to determine a callback function to invoke. These are typically known as “routes”. Some examples from around the web would be:

As an example, we’ll sketch up a mailbox application. Let’s first setup the default route of our app, which will land on #/inbox.

    this.get('#/inbox', function(context) {
        context.app.swap('');
        context.$element().append('<h1>inbox</h1>');
    });

Here, you can make the callback function do whatever you’d like. Since I’m displaying an inbox, I’d probably want to make an ajax call and retrieve a list of messages. However, for the sake of simplicity, I’m just going to return a h1 tag. The context.app.swap('') tells Sammy to replace what’s in my content div, rather than just appending to it.

In order to get this working in the browser, we’ll want to run the app using jQuery’s document ready function and pass it to our starting URL, as defined in the above route.

    $(function() {
      ratPack.run('#/inbox');
    });

And that’s it. We should now be able to load our document in a browser, the app should launch and navigate us to our inbox.

Next, we can create another route to handle labeled messages:

    this.get('#/label/:name', function(context) {
        context.app.swap('');
        context.$element().append('<h1>' + this.params['name'] + '</h1>');
    });

Sammy uses the colon var syntax (:var) to return parameters for us to filter our messages. Again, I’m just displaying the name of the label.

To this point, we’ve only been using the “get” HTTP method. Say we were to create a form and route it to #/compose:

    this.get('#/compose', function(context) {
        context.app.swap('');
        context.$element().append('<h1>say hello to?</h1>'
          + '<form action="#/compose" method="post">'
          + '<input type="text" name="to" />'
          + '<input type="submit" name="submit" />'
          + '</form>');
    });

Now we can setup a route to accept the posted data and have Sammy parse it for us.

this.post('#/compose', function(context) {
    context.app.swap('');
    var to = this.params['to'];
    context.$element().append('<h1>hi ' + to + '</h1>');
});

That’s the basics. A simple API, powerful enough for projects both big and small. If you are following along with the code, we can add some navigation for ease of clicking.

    <div id="nav">
        <ul>
            <li><a href="#/inbox">inbox</a></li>
            <li><a href="#/compose">compose</a></li>
            <li><a href="#/label/drafts">drafts</a></li>
        </ul>
    </div>

---

Encore

Of course, Sammy.js has a lot more to offer than simply defining routes in the app. More advanced users can explore custom events and namespaces, for event-driven applications. Aaron is trying to keep the core of Sammy.js as tight as possible, but it also comes with a lot of plugins. There’s a title plugin, that allows you to easily set the document’s title for different routes. There are several templating systems, including haml and mustache. There’s a nice-looking form builder and Sammy.Store, “an abstract adapter class that wraps the multitude of in browser data storage into a single common set of methods for storing and retreiving data.”

I hope you’ve enjoyed this quick look at Sammy.js and are ready to consider using it in your applications. Let’s hear your thoughts on Sammy.js in the comments!

If you want to build web apps, you might want to think about using HTML5. HTML5 is the new hotness when it comes to app development, and it has the potential to change the way software is made and sold. It also activates the millions of people out there who know how to make web pages, and never thought their skill set could be used for something else. But before jumping into development, there are some things you should know about HTML5. In this tutorial, I’ll teach you the basics!

What is HTML5?

HTML5 is a W3C spec in the making.

It started at WHATWG, and is the future gold standard for HTML. If you have been around for awhile, you many know that XHTML 2 was the next major version, but that fell apart. The reasons are varied, but one main point of contention was that few websites use perfect syntax, and XHTML 2 was going to enforce perfect syntax. It has also always been extremely hard to say exactly what perfect syntax is. When the browser vendors realized how hard it was going to be to make the switch to XHTML 2, things just broke down.

At that point a bunch of people broke away from the W3C and started the WHATWG. These guys wanted to rethink not just HTML, but the whole standards making process. They started work on a new HTML5 standard. They operated from the principal that there is no perfect, and it’s not their job to tell the world how to do HTML. Instead they focused on looking at what was happening in the real world of HTML.

They also took the time to codify some conventions that sprung up in the community. That is where a lot of the new elements in the HTML5 spec (like the progress bar, video, and audio tags) came from. People have been making due, and they just wanted to make specific pieces of markup to help people do what they have already been doing.

Besides just markup, the WHATWG started creating some new JavaScript APIs. This is where HTML5 started to look “app”-like. They created standards for offline data storage, and an offline application cache, so that whole apps could be stored offline. They also started new working groups around widgets and device access (for using devices like cameras and accelerometers).

An interesting side note to the whole standards process is this: for awhile the differences in rendering engines were so great that one approach to be cross-browser compliant was to sniff which browser the user was on and deliver a different experience based on that.

The WHATWG and others always thought that browser sniffing wasn’t such a good idea. What is commonly recommend now is progressive enhancement. In a nutshell, progressive enhancement is this. Instead of just deciding that one browser would get experience Y and another would get experience Z, why not detect advanced feature support and build up to a great experience? If, at any point, the browser doesn’t support advanced feature X, the user would just get the default experience.

The Last Numbered Spec

This leads to another point about the HTML5 spec: it will probably be the last numbered spec. In the future, instead of revving HTML versions, like HTML6, the W3C will just maintain the latest version of HTML, and there will be a gold standards spec. Web developers can use progressive enhancement to handle the fragmentation, while waiting for browser vendors to catch-up to the spec.

So What are HTML5 Apps?

With HTML5 defined, what is an HTML5 app?

Essentially, a HTML5 app uses all the shiny, new pieces of the HTML5 draft to create an app-like experience.

This means storing data offline, being functional, and acting like a real app instead of just being content for perusal. You probably use web apps now, like Gmail. Gmail actually has an HTML5 version; if you visit Gmail on an iPhone or iPad, you can check it out.

---

Why Should I Use HTML5?

Why would I want to use HTML5 instead of Objective-C, Flash, Silverlight, or some other kind of device-specific environment? First, there are a couple reason not to use HTML5.

1. If I was making the latest, greatest 3D shoot-em-up, I would not use HTML5. It just doesn’t have the rich graphics libraries needed to make intense games like those; however, they are working on standards to allow 3D graphics programs into the browser.
2. If you need to use the camera on devices, or local files system, HTML5 would not be the best choice. There are workarounds, using a native wrapper, which I will discuss shortly, and there are also some standards coming that will help with that.

While there are specific cases for not using HTML5, many apps that get produced today for iOS and Android could work just as easily in HTML5. Besides just technically being able to do it, there are other good reasons to use HTML5.

You Already Know How to Use It

Right now, if you are a web developer, you have all the tools you need to get into this. HTML5 app development is only little more then changing how you think about webpages. In some instances you can just add a few lines to your HTML, and add some stuff on your server and you will have a full, working, offline HTML5 app.

The more we work with standards, the more useful they become.

Besides, web developers already understand cross-browser problems. While there will be more cross-browser issues than ever, web developers have a distinct advantage over other kinds of developers, because they already have this in their pocket. The other part of cross-browser development is standards. The more we work with standards, the more useful they become. Web developers have led the charge in some respect, and now it’s paying off. Instead of having to learn a whole other non-standards-compliant add-on, you can simply rely on what standards bodies have been working towards.

Finally, when it comes to writing code, it can be difficult to see that you might also be doing something political.

When you look at how a handset manufacturer handles itself, and how it chooses to lock in its developers, by choosing to work outside that system you are supporting the notion of freedom.

It’s a small notion, but it matters, because in the long run we want our handset developers to be open, and let us hack on them as much as we want.

---

How can I use HTML5?

Actually using HTML5 isn’t that hard. It can range from a couple lines of code, to writing a whole new app. Here are a few ways to get started.

---

1. Create a Mobile Friendly Website

Many websites are only a few tweaks away from a friendlier mobile experience. The first thing to do is take a look at the viewport.

<html>
    <head>
        <meta name="viewport" content="user-scalable=no, width=device-width"/>
    </head>

The viewport meta tag is not a standard yet, but it is a widely accepted convention. Many mobile browsers use this tag to setup certain aspects of web page rendering.

More info on viewport, check out the following documentation:

• Apple Docs
• Opera
• Fennec: Firefox Mobile

Besides just the viewport, make sure that your webpages are flexible; for example, use dynamic widths, instead of static widths. Mobile devices are all shapes and sizes, just like browser windows. Designing with the idea of flexibility in mind will automatically make your web pages more mobile-friendly.

The Doctype

A great little tidbit about the next version of HTML5 is this: the doctype went the way of the dodo. It still has to be there, because of many reasons, but it’s been shriveled to mean almost nothing.

<!DOCTYPE html>

This is awesome. No longer do we have to copy and paste a long string of text, because who can remember that thing, anyway?

---

2. Take Your Website Offline

Some browsers now implement the application cache. The application cache allows you to tell the browser in advance what resources a web page will need offline. The browser will then download those files for offline usage. When the client goes offline the browser will refer to those cached resources.

The application cache isn’t something that you can do by just changing your markup, though. You will need the ability to change the content-type headers on the server. To do that in Apache, you can either put this in a configuration file, or in a .htaccess file.

AddType text/cache-manifest manifest

Once you do that, you can add the following markup to your html element in your webpage. You can call your manifest anything you want, but make sure it’s at the root of your site, and it ends with a .manifest.

<html manifest="my.manifest">

Then, you can create your manifest file. Simply list all the pieces you will need while you are offline. You can’t put cross-domain files here and you won’t want to list anything that changes often. Here is an example manifest file.

CACHE MANIFEST

# Version 1

my.html
my.css
my.js
my.png

When you have this all setup, check it out in a browser that supports the application cache.

If you need to update a resource, just change the manifest file. Even adding a comment will prompt the browser to update the application cache.

The application cache is notoriously hard to debug. This book has some good methods for checking your application cache status.

---

3. Make Your Videos Accessible Everywhere

If you host video content on your site, and use a flash player to play it, you’re missing out on an opportunity to display video to people using the iOS devices and phones that don’t support flash (which is most phones).

HTML5 has two new tags that make displaying multimedia easier: audio and video. Here is an example video tag.

<video src="myvideo.mp4" controls />

Now, if you want to support as many browsers as possible, you will need to encode your content in a couple different formats. Then, list them like so.

<video poster="myvideo.jpg" controls>
    <source src="myvideo.m4v" type="video/mp4" />
    <source src="myvideo.ogg" type="video/ogg" />
    <embed src="/to/my/video/player"></embed>
</video>

This makes sure that your content can be seen in Firefox, Safari, Chrome, and mobile phones. Finally, for browsers that don’t support the video tag, you can still fallback to a flash player. When a browser doesn’t support a tag, it will usually just not deal with it, and continue recursing till it finds a tag it does know. In this fashion, if you put the embed or object inside the video tag, a browser like IE will use the object. However, a browser that supports the video tag will ignore the embedded flash.

---

Conclusion: Start Using HTML5 Tags Today

Tags like header, footer, nav, aside, article, and section are nice because they are semantic. They inform webpage consumers a little bit about your intentions for your content. It’s nice to use them. In the future, they will be more helpful than they are now, but there is nothing to stop you from using them today.

Some browsers, like IE, will “freak out” if you use these new tags, but don’t worry. IE does support adding tag types to the DOM, you just need to inform IE about them. To fix this, Remy Sharp created the HTML5 Shiv. If you include this in the head of your webpage, in an IE conditional comment, your page will render just fine.

Now you are using semantically useful HTML!

---

Bonus: Sell your Apps in an App Store

Yes, right now, you can take your HTML5 apps and sell them on the mobile app stores. Two projects are helping people develop “native” mobile apps, using nothing more then HTML, JavaScript, and CSS. Check these out:

• PhoneGap
• Titanium

Alternatively, our very own CodeCanyon, within the next month, will be launching a new category for HTML5 apps. In this category, we’ll be selling everything from advanced and custom video players, to libraries, to presentation apps.

To prepare for the category, we’ve launched a competition with $7000 worth of prizes. You have two weeks left to enter, if that interests you!

---

Wrapping Up

There should be nothing stopping you from exploring HTML5, and if you wanted to be ahead of the game, you should be building HTML5 apps right now. Thanks for reading!

---

About the Author

Alex Kessinger is a front-end web developer who currently works for Yahoo!