bgror

RPG Buddy: Now on Android »

Created at: 14.05.2011 06:24, source: Hackido, tagged: rpg google android

5 things I hate about Google Buzz »

Created at: 12.02.2010 00:45, source: Hackido, tagged: google

Ready, Set, Go! »

Created at: 09.12.2009 19:00, source: Engine Yard Blog, tagged: Technology go google

Google recently publicly released their new programming language, Go. I’ve known about this for some time, having worked for the big G while it was in development, although not directly involved.

Google has plenty of special purpose languages, but this is the first general purpose language to come out of Mountain View. That fact alone makes it quite interesting. Add to it that some of the original C and UNIX people are involved, and it becomes something that requires investigation.

What’s it for?

Go is a systems programming language. Think of it as a modern C. It’s meant for the same types of programming: operating systems, compilers, infrastructure pieces.

What’s it all about?

To summarize the main golang.org page, Go is: simple, fast, safe, concurrent, open source, and fun.

What’s so different about it?

Go is an object-oriented language, but not in the style that most programmers these days think of OO. Go doesn’t have implementation inheritance (more on that later). Also, you don’t define methods inside a class as in many OO languages. Instead, you add methods to types in a way somewhat reminiscent of CLOS . For example:

func (file *File) Read(b []byte) (number_bytes_read int, err os.Error) { ... }
  if file == nil {
    return -1, os.EINVAL
  }
  r, e := syscall.Read(file.fd, b);
  if e != 0 {
    err = os.Errno(e);
  }
  return int(r), err
}

Here we have a function Read that’s being attached to the type *File. Read takes a single parameter, b, which is an array of byte and it returns an int named number_bytes_read and an Error named err. There are three things to note here. Read, is (1) being attached to an existing type (a pointer type at that), and (2) returns multiple values which (3) are named. Even if the return value names aren’t used, they are superb for documenting what the returned values mean.

Points of Note

Fast compilation

Go compiles fast. Really fast. This means no long waits for builds. More importantly, it means a tighter test-code development cycle.

Less typing… and less typing

Here’s the basic way to declare a variable (a string in this case):


var s string = "";


If the type can unambiguously be inferred, you can do:


var s = "";


and using the initializing declaration operator, you can simplify even more:


s := "";


I say shiny: this is pretty sweet. Minimal boilerplate and type inference.

Arrays and Slices

Arrays are, of course, built-in to the syntax. Arrays are fixed size linear collections of data. They work pretty much as expected except that they don’t support the pointer arithmetic tricks that C programmers take for granted. So, you get an actual pointer to an array, not just a pointer to something that happens to be the first thing in the array.

Slices are the idiomatic way to work with sequences of data in Go. They wrap arrays to give a more powerful way to work. Slices are too big of a topic to explore in this post, but basically they provide a dynamic window onto an array.

Arrays have a size as an integral aspect of the type, thus [3]int is a different type than [5]int. Slices have a size as part of their data.

You create a slice of an array by specifying the initial and one past the final index. For example:

a := [4]int{1, 2, 3, 4};
s := a[1:3];

s[0] == 2
s[1] == 3

Here s has a size of 2 (3 – 1) and type []int.

Here’s a function that takes a slice as its parameter:

func F(buf []byte)

You can tell this is a slice because there is no size inside the brackets.You could call the above function with an explicit slice:

var a [5]byte;
F(a[2:4]);

but you can also implicitly pass a slice that covers a complete array:

var a [5]byte;
F(a);

Strings and Maps are built-in

Something that’s nice to see is that strings are built into the language and standard library as in C (but unlike C++). The proliferation of string libraries in C++ caused great confusion and frustration in C++’s early days.

What’s even nicer to see is that hashes are built-in. Having the basic and extremely useful types built-in to the language make it possibly to optimize them quite aggressively. This way. programmers don’t have to worry about choosing a slow string or hash library.

Maps are very flexible, here’s an example from Effective Go:

var timeZone = map[string] int {
  "UTC":  0*60*60,
  "EST": -5*60*60,
  "CST": -6*60*60,
  "MST": -7*60*60,
  "PST": -8*60*60,
}

func offset(tz string) int {
  if seconds, ok := timeZone[tz]; ok {
    return seconds
  }
  log.Stderr("unknown time zone", tz);
  return 0;
}

Note the multiple return values where the second is an indicator as to whether a valid value was found.

Interfaces

Interfaces are just a collection of function signatures. Here’s an example of interface use taken from the IO library:

type Reader interface {
  Read(p []byte) (n int, err os.Error);>
}

type Writer interface {
  Write(p []byte) (n int, err os.Error);
}

This is nothing too earth shattering if you’re familiar with Java. If you’re used to Ruby, this is something a little different: actually having to codify the protocols to which your objects conform (see Jim Weirich’s RubyConf 2009 talk for a discussion of this).

Making the connection between interfaces and the types that implement them is just the opposite. It’s implicit—as it is in Ruby et.al.— not explicit, as it is in Java. For example here is something that can be used whenever a Reader is expected:

type limitedReader struct {
  r Reader;
  n int64;
}

func (l *limitedReader) Read(p []byte) (n int, err os.Error) { ... }

This example also shows declaring a variable (a struct member in this case) of an interface type.

One nice thing about the way interfaces are done in Go is that if you define an interface that declares some methods of an existing type, you have implicitly performed an Extract Interface refactoring. None of the types implementing those methods have to be touched: they can now be implicitly and automatically used wherever you use the new interface.

One nice feature is the ability to make composite interfaces:

type ReadSeeker interface {
  Reader;
  Seeker;
}

Here, the ReadSeeker interface encompasses everything in both the Reader and Seeker interfaces. Anything that implements the methods declared in Reader and Seeker can be used wherever Reader, Seeker, or ReadSeeker is used.

No Implementation Inheritance

It is the lack of implementation inheritance that seems odd. Most of us are used to considering it as a necessary part of an OO language. In his 1996 talk “What is Object-Oriented Programming?” Bjarne Stroustrup (creator of C++) went so far as to say:

Consider a language having some form of method lookup without having an inheritance mechanism. Could that language be said to support object-oriented programming? I think not.

It’s interesting to note, however, that Alan Kay (arguably the father and namer of OO) didn’t originally consider inheritance necessary as part of the language (in “The Early History of Smalltalk“):

I just decided to leave inheritance out as a feature in Smalltalk-72, knowing that we could simulate it back using Smalltalk’s LISPlike flexibility. The biggest contributor to these AI ideas was Larry Tesler who used what is now called “slot inheritance” extensively in his various versions of early desktop publishing systems. Nowadays, this would be called a “delegation-style” inheritance scheme.

Inheritance was jumped on when OO hit the scene back in the 80s. We saw it used far too much and too freely. Over the years the thinking shifted to a more sensible approach of composition rather than inheritance. This is what Kay was referring to back in ‘72.

Garbage Collection

Go has a rudimentary mark-sweep garbage collector, but there are plans to improve that. One of the boons of having garbage collection is that you completely sidestep entire classes of memory related bugs. It also means you don’t have to write the code to deal with memory management. In the context of Go being a language that embraces parallelism, garbage collection means that you can avoid worrying about cleaning up allocated memory.

Concurrency

In today’s world of multi-core processors, concurrent programming is becoming increasingly relevant. The Go authors recognized this and designed Go for use in writing concurrent programs. Go embodies a different philosophy of concurrency than most systems languages:

Do not communicate by sharing memory; instead, share memory by communicating.

Go offers two primitives to accomplish this sharing by communication: goroutines and channels.

Goroutines

Goroutines are functions executing in parallel with other goroutines. The Go runtime manages parallelizing all of the goroutines using operating system primitives. They are light-weight and easy to use.

go doSomething(); // Do something, but do not wait for it to complete

You can even pass an anonymous function literal:

go func() {
  time.Sleep(5);
  fmt.Prinln("Hello World");
}();

Channels

With goroutines, executing functions in parallel is easy. However we still need a mechanism for communicating between them. That’s what channels are for. Channels provide a synchronized, type-safe way to communicate values from one goroutine to another.

ch := make(chan int); // unbuffered channel of integers

go func() {
  result := 0;
  for i := 0; i < 1000000; i++ {
    result += i;
  }
  ch <- result;
}();

/* Do something else for a while */

sum := <-ch;
fmt.Println(sum);

The above example shows how channels can be used to communicate between two goroutines, and it also shows how they can be synchronized. The binary send operation will block until another goroutine receives the value, and the unary receive operation will block until another goroutine sends a value. So a channel can be used as a simple way to synchronize a goroutine.

ch := make(chan bool);
go func() {
  /* do some stuff */
  ch <- true;
}();
<-ch; // strobe the channel to synchronize

What’s not there?

Some things are absent from Go (at least for now), including generics, exceptions, and assertions. Generics and exceptions might be added in the future, when an acceptably clean and efficient design is devised. Keep in mind that Go is meant for system programming. Efficiency is important, and language features such as generics and exceptions have non-trivial runtime performance implications. Go is not a kitchen sink language—it is designed for a fairly specific use.

Conclusions

Go is extremely easy to dive into. There are a minimal number of fundamental language concepts and the syntax is clean and designed to be clear and unambiguous.

Go is still experimental and still a little rough around the edges. For example, if a function has a return value, and it returns from every branch of execution, it will still complain if it doesn’t return from the end of the function.

That said, Go allows you to do Pascal style return values where you give the result a name, assign to it, and use it in computation. However, you still have to put the return keyword at the end.

The only typing is duck typing. To Rubyists, this is a great thing.

As Carl Lerche comments, “It’s not production quality yet, but there’s enough that it’s interesting to explore.”

Deploying JRuby on Google App Engine »

Created at: 23.09.2009 18:44, source: igvita.com, tagged: Architecture ruby gae google jruby rails

Following the Java support announcement for Google App Engine back in April there was a small flurry of excitement about the possibility of JRuby on GAE. However, while the notion was appealing, the execution was lacking - you had to do backflips to get JRuby, servlets, and XML configs all properly bundled. Compared to the aesthetically pleasing experience of running a Sinatra, Rack, or even a Rails app with Phusion, it is no wonder that most of us promptly forgot about GAE.

Having said that, the auto-scale, load-balancing, geographic redundancy, BigTable datastore, XMPP, memcached and the newer cron and taskqueue services, are definitely all reasons to revisit the platform. John Woodell and Ryan Brown, both Google employees, have been doing terrific work on helping to lower the entry barrier. In fact, while the documentation still needs a lot of work and polish, the deployment story and the API's are basically there - it now takes just a few keystrokes to get your Ruby app on GAE!

Migrating to Google App Engine

The first thing you'll notice with App Engine is that most of your Ruby/Rails applications won't run on the platform out of the box. GAE offers a lot of great benefits, such as free load-balancing and access to the BigTable datastore amongst many other things, but it does so by abstracting or removing some of the interfaces we're all used to: there is no filesystem, BigTable is not a relational database, cron jobs are HTTP calls, and so on. While an inconvenience at first, the functionality is still there but it does require some extra work on behalf of the developer. For example, while ActiveRecord does not work at the moment, there is a DataMapper adapter that can meet all of your needs. Likewise, your code cannot make arbitrary outbound HTTP connections, but you can patch net/http to use the URLFetch API.

The net positive of all of these changes is that your application can then be uniformly scaled across the GAE infrastructure. By default, you receive a free quota for up to (roughly) five million requests, and beyond that a credit card is required. Best of all, you no longer have to think about hardware, databases, or any other supporting services. BigTable guarantees uniform access time for your queries irrespective of the size of the dataset (at a cost of higher overall latency), and CPU, memcached, and XMPP load is automatically spread within the GAE cluster. And if you're feeling adventurous, you could try deploying a distributed file system (GaeVFS), or even build your own GAE hosting environment from scratch with AppScale.

Hello World with GAE

The tooling support for getting your application on GAE is now almost fully automated. Ryan Brown's appengine-api's gem has full coverage of all the essential services, and the google-appengine gem provides a number of essential tools to help you with the generation, setup, and deployment of your applications. A simple "Hello World" Rack application is as simple as:

> rack-gae.rb

# install GAE tools (no JRuby required)
# > sudo gem install google-appengine
 
# create a rackup file: config.ru
require 'appengine-rack'
 
AppEngine::Rack.configure_app(
    :application => "your-app-id",
    :version => 1)
 
run lambda { Rack::Response.new("Hello World!") }
 
# start development server on local server
# > dev_appserver.rb .
 
# deploy application to GAE
# > appcfg.rb update .
 

All the configuration and deployment logic is done on your behalf by the dev_appserver and appcfg executables: packaging JRuby, creating the XML configs, authentication, etc. Deploying a Rails application, takes just a few more steps. Once the app is live, login into your GAE dashboard to scan the logs, query BigTable, or track your quotas - no need for mucking around with any system utilities!

Developing for App Engine

In theory, GAE has all the potential to become a popular deployment platform for Ruby applications (not to mention a nice market for custom Google Apps modules). The lacking resources at this point are the blog posts, developers, and the overall Ruby community mindshare around App Engine. John Woodell and Ryan Brown have done a fantastic job of lowering the entry barriers, but we're still missing the real-life production deployments that would weed out the API bugs and inconsistencies, as well as, build the overall trust in the platform.

Curious to give it a try, I took an evening to try and port a small, but non-trivial app to App Engine. Having settled on watercoolr (webhooks pubsub), I swapped out SQLite for BigTable and a few keystrokes later, I had a public watercoolr service (http://watercoolr.appspot.com) in production. No configuration, no need to worry about overloading the database. Feel free to use it for your own HTTP pubsub needs! GAE is an exciting platform, check out the examples, articles, and make sure to give it a try.

HTTParty goes foreign »

Created at: 16.03.2009 09:05, source: Robby on Rails, tagged: Ruby on Rails ruby programming google translation api httparty http REST language

Just a quick post to get share something I was tinkering with this evening.

I came across this post by Gerald Bauer, which shows you how to use the Google Translation API with Ruby via Net::HTTP. I thought I’d play with the service with HTTParty.

class GoogleApi
  include HTTParty
  base_uri 'ajax.googleapis.com'

  def self.translate(string="", to="", from="en")
    get("/ajax/services/language/translate", :query => {:langpair => "#{from}|#{to}", :q => string, :v => 1.0})
  end
end

A few examples from playing with it.

>> GoogleApi.translate('bonjour', 'en', 'fr')
=> "{\"responseData\": {\"translatedText\":\"hello\"}, \"responseDetails\": null, \"responseStatus\": 200}"

>> GoogleApi.translate('Red wine', 'fr')
=> "{\"responseData\": {\"translatedText\":\"Vin rouge\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"

>> GoogleApi.translate('Where is the bathroom?', 'es')
=> "{\"responseData\": {\"translatedText\":\"\302\277D\303\263nde est\303\241 el ba\303\261o?\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"

>> GoogleApi.translate('Good morning', 'it')
=> "{\"responseData\": {\"translatedText\":\"Buon giorno\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"

What a party!

>> GoogleApi.translate('party', 'it')
=> "{\"responseData\": {\"translatedText\":\"festa\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"
>> GoogleApi.translate('party', 'es')
=> "{\"responseData\": {\"translatedText\":\"fiesta\",\"detectedSourceLanguage\":\"en\"}, \"responseDetails\": null, \"responseStatus\": 200}"

Look how easy that was. :-)

For a previous post on using this gem, read The HTTParty has just begun.