Can you create a working application in 15 minutes?

I believe that yes indeed you can do that. The questions are: How?
What are the downsides?.

The how is pretty much using right tools for the job. For most of my
projects it means this:

-Ruby 1.9.2
-RVM
-Ruby on rails 3.1 +
-Bundler
-Devise
-MySQL
-jQuery
-Twitter Bootstrap
-ActiveAdmin
-Airbrake
-SendGrid
-Capistrano
-Ubuntu on a remote server

Introduction

Back in June 2010, I published a blog post detailing how to perform Ajax file uploads from your HTML forms. The result worked pretty well, but there was still some room for browser vendors to make things even simpler for us.

Turns out, they have. The specific improvement that made this possible is the FormData interface, first introduced in Safari 5, and later in Chrome 7 and Firefox 4.

They're called sprints because they're fast.

Agile development is designed for quality and flexibility. The fact that it's also highly efficient is a bonus. There's a huge variance in developer efficiency, even among capable and motivated people, and the combination of Rails and a strong process means that we really get things done.

Sprint planning

On the surface, planning out and committing to a one-week sprint is about giving the product owner - the client - some certainty about what they'll be able to ship. But as a developer, it provides a powerful focus.

About a month ago we had a hack day at New Bamboo, a day where all the bambinos were free to work on any kind of project they wanted to. I decided to experiment with the HTML5 Audio Data Api, and canvas.fm, (code) is the outcome of that experiment.

Canvas.fm is a small app that allows you to listen to music available on SoundCloud. Whilst the audio is playing it draws a visualisation of the current song using HTML5 canvas. It uses a server component, powered by Node.js, to convert SoundCloud's streaming MP3 audio into the OGG format - which Firefox supports.

Note from translator:

This is a translation of an article from "PublicKey" - Enterprise IT x Cloud Computing x Web Technology / Blog.

Mr Junichi Niino kindly allowed me to translate his original article from Japanese to English.

Also, special thanks to @knowtheory for editing my translation.

Title: "I am looking forward to accelerating Ruby's progress" - Q&A with Matz regarding joining Heroku as a chief architect.

What is the problem?

Using the location hash to keep track of current page state and enable back button navigation is more and more common with large, full featured, client side JavaScript apps. Whilst the behaviour this gives is definitely an improvement to the user experience, implementing this with the location hash has some shortcomings.

Thankfully, as with everything else on the web, HTML5 is here to solve all your problems, with two methods and an event, pushState, replaceState & onpopstate.

• Introduction
• Step 1: How to read Japanese characters
• Step 2: Japanese and OO
• Step 3: Japanese and functional
• Step 4: Writing Japanese programming language in Ruby
• Summary
• Ruby Advent Calendar

Introduction

Have you ever thought about learning Japanese, but it looks too difficult to learn?
Surprisingly, Japanese and Ruby share some common features and concepts. This is a shortcut version of my presentation called "Japanese and Ruby" which I presented at LRUG.

From Matz On Pusher

Contents

• At previous post
• "RubyKaigi must end (for now)"
• So, what can we do?
• Summary

At previous post.

At previous post, I went through the following Ruby divides I noticed during RubyKaigi 2010.

• Japanese / English = Ruby core ML and many variable documentations are written in Japanese and non Japanese developers are hard to access such information.
• Committers / Users = There seems divides between C dvelopers (C Ruby committers ), Java developers (JRuby community), and the rest (Ruby users).
• Before / After Rails = Japanese Ruby scene is very unique from the rest of the world(aka Galapagos). Some part are very advanced, but others are missing important aspect of Rails culture (eg: github, rubygems).
• Hobby / Enterprise = The ratio of Japanese Rubyists who uses Ruby at day job seems low.

Ruby divide at RubyKaigi 2010 and what can you do as a Rubyist? (Part 1)

Introduction

It is almost 2 weeks since RubyKaigi finished. For full details of the conference, check out Jake Scruggs' near real time report.

Ruby Kaigi was one of the most memorable conferences I have ever attended. There were countless efforts by volunteer staff to make the conference as enjoyable as possible. I met lots of interesting people and enjoyed every conversation in the conference hall, hallways, and Izakaya . All the topics discussed there were very thought provoking.

In a couple of our internal apps, we use a UI design paradigm that we affectionately call an "awesome bar". I really like these, and I think they make many types of applications much more useful and intuitive. While they have generally been hard to create in web apps, the introduction of canvas and inline SVG has made them a synch to put together. I see a lot of great examples of canvas and SVG that are absolutely mind-bending to look at, but very few examples which enhance the traditional applications and websites we use on a day-to-day basis. I won't claim to have invented these, but I was reminded of how cool they are recently when I read this post: [http://blog.asmartbear.com/creativity-over-optimization.html](http://blog.asmartbear.com/creativity-over-optimization.html). I will give a brief explanation of what these are with some examples, why I think they rock, and some sample code. ## What are awesome bars? To give a quick introduction of what these are I have made a screencast of the awesome bar from our nifty scheduling application called Mandays. You will see that the horizontal bar at the bottom is a miniature representation of the grid at the top, and when you draw in it, the awesome bar at the bottom updates itself. You can then use the awesome bar to navigate your timeline.