Showing posts with label Google. Show all posts
Showing posts with label Google. Show all posts

Tuesday, May 4, 2010

To Ruby or Not to Ruby?


Ruby on App Engine Meetup (May 4, 2010) proved that Google App Engine is not all about Python and Java, although at present only the last ones are benchmarked and discussed by google app engine developers (try yourself)

Python is usually fast enough for what you want it to do (and faster than Ruby), while requires a third of the code of an equivalent Java program and is much easier to read. Both Python and Ruby are easy to learn.

Pythonistas think that Ruby syntax is ugly and inheritance distasteful. The philosophy of Ruby is similar to Perl: there is more than one way to do the same thing. This is great for some people, it leads to the creativity and richness of Ruby libraries like Hpricot and Rake. Ruby tries to take the best of Perl, Smalltalk and Lisp but has elements of a C/Java-like syntax. Rubyists are convinced that they have found the most enjoyable interpreted language. Ruby is younger than Python but already has a strong and loyal community and best web tools. Many programmers, however, don't like having too much power to change the syntax and keywords. This can be dangerous if they are not careful.

Arguments on what language is better resemble disagreements between cultures and ethnicities. For a programmer, it's always fun to learn something new that may be useful in the future. For a startup founder, it's always good to know what is fun and a good investment. Right choices of programming languages, web frameworks and platforms will lead to rapid development, the ability to attract talent, and offer a great expansion potential.

The Java language is an old favorite in the enterprise. There will be a large pull of candidates to work on Java projects, but this language won't make your startup the most attractive shop in town. Python and Ruby will.

The Python community has the Django framework while the Ruby language is paired with the Rails framework. DSL Sinatra is also good. What's the difference between the Ruby and Python developer crowds? RoR favors convention over configuration which means that any Rails programmer can drop immediately into any Rails application and have a very good idea of where to get started. Expect rapid development and prototyping and support from community working on updates and plugins. Ruby/Rails developers tend to be expensive but worth it. Complementary Javascript experience is perfect - for dynamic web pages and nice visual effects. PHP developers tend to be a little cheaper than Django and RoR, but watch out for bad coders in this crowd. All hosting providers can deliver a low cost PHP server environment, but there are great platforms for Ruby and Python - such as Heroku (that recently raised $10 million in Series B funding) and Google App Engine that let you develop for free.

The May 4th meetup was not on Ruby vs other languages. It was about Google App Engine.
Most Rubyists in the audience were using Heroku for their applications, some will now try to pioneer Google App Engine - or will they?..

One interesting observation was the "City” versus “the Valley" comparison of preferred languages: Ruby seems to be the City's favorite! Could it be due to cultural differences? Some even think it's as bad as PC vs Mac world - see this short clip.
There were no Java people in the audience and very few programmed in Python or wanted to learn it. Almost no one tried Google App Engine.

Matthew Blain presented BulkLoader, a minimal library providing a unified interface for loading, accessing and events notification for different types of content (Try the Bulk Loader sample at: http://bulkloadersample.appspot.com/)

John Woodell, Sr Web Developer at Google (twitter: @johnwoodell, e-mail woodie at google), gave the main talk -about running Ruby on the App Engine. Sarah Allen wrote a nice blog about this talk: http://www.ultrasaurus.com/sarahblog/2010/05/jruby-on-google-app-engine/. Another blog post summarizes the sources discussed:
http://jruby-appengine.blogspot.com/2010/05/google-app-engine-0012-gems-released.html

Check out his SlideShare Presentation:
App Engine Meetup
A few pointers and links from this talk:
  • Zero Configuration needs. Scalable services via standard APIs. Built-in application management console
  • Schemaless App Engine datastore: No writing to the filesystem. No relational database. No more than 30 seconds per request. Datastore API + DataMapper
  • Most common tasks: backups and cross-app migration.
  • A big Rails advantage is that it values convention over configuration and lets to avoid lengthy configuration of files. Load everything at once then initialize it. This helps to free more time to focus on business logic. Google App Engine does not work like that yet, but this is on roadmap.

Key Ruby App Engine Developers (check also this map):

John Wang - iPhone, Android, and Web Developer at Fresh Blocks in Honolulu, (Twitter: @johntwang Github: jwang) Provided RESTful JSON with Google’s Datastore to iPhone and Android apps.

Joshua Moore, Assurance Manger at Armorize Technologies (Twitter: @codingforrent, GAE blog). Coauthored the rails_dm_datastore gem, gave presentations on using jRuby on GAE. Rails 2.3.5, Datamapper, HAML, helped to find datamapper bugs

Leonardo Gallucci, IT Consultant and Software Integrator (Twitter: @leonardog). Wrote tutorial on getting started with Ruby on Rails on Google App Engine (it runs on GAE).

Vladimir Sizikov (github: vvs) . Developed jruby launcher: http://github.com/vvs/jruby-launcher

Sasaki Takeru, a hacker from Japan (Twitter: @urekat). Showed how to run Rails without Ruby Gems. Rails 2.3.5 01/21

Anagiotis Siatras, a Microsoft .Net/Gae+Rails consultant from Greece (Twitter: @azazeal)
Developed taxster.gr. See his useful Ruby tips at http://azazeal.xelixis.net/


More Links:

Reblog this post [with Zemanta]

Tuesday, March 2, 2010

Organizing the World's information

"My guess is (it will be) about 300 years until computers are as good as, say, your local reference library in doing search,"says Google's first employee and director of technology Craig Silverstein. "But we can make slow and steady progress, and maybe one day we'll get there." (Inside the Wide World of Google CBS News, March 28, 2004). According to CEO Eric Schmidt, people care a lot about information and the possibilities of the unfolding revolution in technology are greater than many of them even realize: “Imagine the scale of the kinds of questions you could ask that you could not ask before.”

The figure is a great compilation of key Google Facts by PingDom. Among the key technical facts not shown here are far-reaching inventions such as Programmable Search Engine (PSE, see patent application) based on the BigTable database (See Research Publication about it in PDF format) and other systems that could help it become more semantic.

The distributed storage system for managing structured data called Bigtable resembles a database sharing implementation strategies with parallel and main-memory databases. Instead of a full relational data model it uses a simple data model with data indexed using row and column names that can be arbitrary strings. A Bigtable is a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp; each value in the map is an uninterpreted array of bytes, although clients often serialize various forms of structured and semi-structured data into these strings, controlling it through careful choices in their schemas.

PSE and other integration technologies may be providing a higher level of semantic analysis.
These techniques could figure out the meaning of content and “fill in the blanks” when an item of information is ambiguous or missing. The idea is to enrich an information object with additional tags so that queries about lineage (where something came from) and likelihood of accuracy (the “correctness” of an information element) can be used to generate a result.

Another new concept is a probabilistic mediated schema automatically created from the data sources. Semantic mappings between the schemas of the data sources are mediated by schemas with probabilities attached to each - to model uncertainty at its core. A deterministic mediated schema created from the probabilistic ones will be exposed to the user who could use the terminology of this mediated schema to interact with the system.

The Semantic Web is emerging to help us get the most out of the world's information. Many interesting applications are already here. Some of them already acquired by major search players - Bing, for example, is based on semantic technology from Powerset that Microsoft purchased in 2008. This blog article is only about one of the players organizing the world's information. Stay tuned for more.


Reblog this post [with Zemanta]
blockquote { margin:1em 20px; background: #dfdfdf; padding: 8px 8px 8px 8px; font-style: italic; }