Countdown timer to "This Is It!"

The Stock Market is Crazy

Ok, someone try to explain this to me in plain English:

Ceragon Networks reported it's quarterly earnings today.

Earnings were 4.9$ million, 83%(!!!) more than the year ago quarter. It matched estimates by analysts.

Revenue for the quarter rose by 40%, matching estimates by analysts.

Revenue for all of 2007 rose by 49%, beating estimates by analysts.

The company still believes it can grow at a rate of 25-30% each quarter.

Amazing numbers. Wonderful numbers.

And yet - the stock fell 17% in a single day. At some point, it fell more than 20%.

The stock market is crazy sometimes...

* Oded is a Ceragon Networks stock holder.

Apple Event in Israel

On October 28, 2007, I attended the official launch of Leopard in Israel in Stoa, Ga’ash.

The event was hosted by iDigital, Apple’s brand new official representative in Israel, replacing the much unbeloved Yeda computers.

The event was truly impressive, and gave some insight as to where Apple is headed in Israel.

iDigital’s general manager, Mr. Eran Tor, promised improved support and customer service, “At a level that people have come to expect from Apple in other countries such as the UK or Spain”.

Below are some photos from the event. Sorry about the quality, they were all taken with my iPhone.

iDigital’s website

Writing Your First Ruby App

Ok, enough chit chat. let’s get started with our first real Ruby tutorial.

We are going to start our own weblog application. It makes sense, considering it is missing from this site :)

First things first: make sure you have ruby, rails, and mysqladmin in your PATH environment variable.
Under Windows, it is:

My Computer --> Right Click --> Properties --> Advanced --> Environment variables.

Under Mac OS X, you need to edit .bash-login under your home directory. For me, it looks like this:

export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/usr/local/mysql-5.0.37-osx10.4-i686/bin:$PATH"

Second, pick a place on your home directory to store all your projects. I picked ~/Development/Projects/Ruby.

Now we’ll create our application skeleton. Open terminal, cd to your project directory, and type the following:

rails weblog

You should see a bunch of stuff being created. This is the rails framework working for you.

Now, let’s create our database. You can use the mysql GUI to do this, but that’s not geeky enough for us, is it... so in the command prompt, type the following:

mysqladmin -u root create weblog_development

notice the database name - it is exactly like our application’s name, ending with the “_development”. This is something you’ll see a lot in Ruby - it is called the “Convention over configuration” methodology. It means that a lot of things will just work together, if only you’ll agree to some pre-defined “rules”. one of these rules is that the database’ name is like the application’s name, ending with the development phase - it can be either development, testing, or production. You can see the configuration details under config/database.yml.

The next thing we need to do is to migrate our database according to the application. We didn’t do anything just yet - we didn’t even write one line of code! But rails is doing a lot of things for us, and one of these things is to manage the database changes. In order to do it, it needs to setup a special table in our database, called schema_info. This table manages our changes to the database. It allows us to “commit” and “rollback” any changes that we do to the database during development. It is directly connected to our code, as we’ll see later on. For a Java developer like myself, this is a huge leap forward.

So, in order to initialize our database for use with rails, we’ll write the following:

cd weblog

followed by:

rake db:migrate

You can now open up the MySQL query browser and check the database weblog_development. See that table called “schema_info”? It was just created for you automatically.

Next task: create our model. In Ruby on Rails, models are directly connected to their database counterparts. This means that if we create a model class named “Person”, it will have a database table called “people”. That’s right, rails knows that many persons = people. Pretty neat, ha? Of course, usually it will just be something like class=”Paper” and a table=”papers”.

Now let’s create our model for a log entry:

ruby script/generate model log_entry

Look at the files that rails created for us. Especially pay attention to 001_create_log_entries.rb. Again, log_entries, not log_entry. I know it’s silly, but it’s still cool by my book :).

So what do we have inside that 001_create_log_entries.rb class? Well, this is our first change to the database. We want to create a new table in the database, called log_entries. And that’s exactly what the class contains:

class CreateLogEntries < ActiveRecord::Migration

def self.up

create_table :log_entries do |t|

end

end

def self.down

drop_table :log_entries

end

end

Not much here, is it? We’ll want to update this class to create the log_entries table.

class CreateLogEntries < ActiveRecord::Migration

def self.up

create_table :log_entries do |t|

t.column :title, :string

t.column :content, :text

t.column :author, :string

t.column :creating_date, :date

end

end

def self.down

drop_table :log_entries

end

end

The update basically tells the migration tool to generate a model containing the fields ‘title’ of type string, ‘content’ of type text, ‘author’ of type string and ‘creation_date’ of type date. Notice the form of writing: This one class will map the database to our newly created model. Notice the two methods we have here: self.up will be called when we build our database. self.down will be called when we rollback our changes.

Now let’s migrate the database to version 001. Once again:

rake db:migrate

Sweet. What just happened? Refresh your database and have a look. you should have a new table called “log_entries”, containing the fields title, content, author and creation_date.

Next: time to create our controller. The controller is the mediator between the view (the web page) and the model (which represents the database). We’ll call our controller ‘manager’. To create the controller, all we do is this:

ruby script/generate controller manager

Great. So now we have our model and we have our controller. What about our view? Well, we can write it, but we can also generate it using the scaffold command. Scaffold is an easy way to create some sort of a mockup version of our Webpage just to have something we can see on the page. We’ll create the view from our controller. Open manager_controller.rb and change it to look like this:

class ManagerController < ApplicationController

scaffold :log_entry

end

This is it. We are done. We now have a working ruby application with a view, a controller and a model. Just think how much stuff you didn’t do. To start your app, run the server script:

ruby script/server

Now point your browser to http://localhost:3000/manager. You should see your app. Try creating some entries, editing entries and deleting entries.

Installing Ruby on Rails on Mac OS X

As it turns out, installing Ruby on Rails on Mac OS X (Tiger) is not your usual drag n’ drop.

While some pre-built installer packages exist (see locomotive), the folks at rubyonrails.org recommend building it yourself. Besides, it’s always fun to learn new stuff.

I came across an excellent guide, that just worked perfectly, with no hassles whatsoever. It also goes through the process of installing additional software packages, such as MySQL native binaries, and subversion.

See it at hivelogic.com.

Two things need to be changed as of the time of writing thing entry:
Instead of using RubyGems version 0.9.0, which didn’t work for me, I used version 0.9.4. You can download it here. The second issue is with SubVersion's, um, version. Instead of 1.4.3, type 1.4.5, which is currently the latest version.

If you're using Mac OS X Leopard, Ruby on Rails is already an integral part of the operating system, so there's no real need for all of this setup.

Sony DSC-H1 Shots

I've been playing around quite a bit with my H1 after reading the excellent H1 White Paper, And it does feel more fun to take pictures, not to mention getting the occasional good shot (Well, i'm still learning).

Here's a couple of my attempts:

I started out with trying a few night shots. At first I was sure it'll be really dark so I set the exposure time to 30 seconds. Boy was I surprised! take a look at this:

Kinda looks like a day shot isn't it? It was actually completly dark, that street light was very very weak that I barely noticed it before the shot.

Then I was trying it with diferent settings and got these results, which was nice if it wasn't so noisy (I set ISO to 200):

So then I decided to just give it a nice aperture and have the rest pretty standard. I think it turned out a little better:



The next day I was trying some daytime shots (All using the histogram), and was able to get from this:



To this:



To this:

Some pictures from United States

Here are some new pics from my new Sony DSC-H1 Digital Camera, taken in Florida & New York. 



















Taken at full telephoto from a pier.




Same picture as above, only up close: