Archive for July, 2006

Howto: configure iTalk behind a firewall

Sunday, July 30th, 2006

I have recently been asked what steps I took to get iTalk running successfully behind a firewall. This howto guide will walk the user through the process of configuring their various devices to acheive a “crisp and clean” telephone service.

*1. Configure network settings on the VOIP(Voice over Internet Protocol) device*

I am using the Netgear TA612V Broadband Telephone Adapter – a simple device that has a single ethernet port and two regular telephone ports. First, this must be set to use a static IP address. This will allow the firewall to forward the appropriate packets to this device.

On the Netgear device, this is set on the “Basic Settings” page. You may also need to set your dns servers and default gateway here. i set my IP address to 192.168.5.2 with my default gateway set to 192.168.5.1 – you’ll need to set the appropriate address for your network.

*2. Configure port forwarding on the firewall*

You need to setup your firewall to send any packets that arrive at a certain port number through to your VOIP device. As it shows in the screen grab below, I am forwarding ports 5060 and 30000 through to the VOIP adapter at address 192.168.5.2. The “both” indicates that this is forwarding both TCP and UDP packets.

!/images/8.jpg!

*3. Configure VOIP settings*

On the Netgear device, there is a “VOIP settings” page. The settings for other devices should be fairly similar. I have the following service settings:

!/images/9.jpg (Service Settings)!

and theses settings for line 1:

!/images/10.jpg (Line 1 settings)!

As you can see from the settings above, I’m in the Wellington free calling area. You will need to apply the appropriate settings for whatever calling area you are in. The “SIP proxy settings are available here on the iTalk website”:http://www.slingshot.co.nz/DesktopDefault.aspx?tabindex=999&tabid=21&subnav=34&leftpane=hide&rightpane=hide

Also, you need need to use the appropriate telephone and user numbers, etc. Note that I am using a 644 prefix, which is for the Wellington region. If you’re in Christchurch for example, you’ll need to use 643.

*Hardware*

I am using the Netgear 612V Broadband Telephone Adapter. It’s not the best one around, but it seems to work OK. Apparently iTalk are planning on selling a VOIP adapter in the near future, and I suggest people wait until it is available. That way you’ll be able to get support from iTalk themselves. Other options include getting something from Dick Smith with a 14 day right of return.

A lot of VOIP adapters can be plugged directly into your cable or DSL modem, and the plug your other computers into it. I think this is the preferable way getting connected, as you don’t need to worry about firewalls and port forwarding.

*Conclusion*

Well that’s about all you need to do. The iTalk service works fairly well for me. There are a few quirks:

* Message waiting – I seem to have the message waiting indicator stuck on. This is both the small icon that is displayed on my DECT phone and the beep-beep-beep you hear before the standard dial-tone kicks in. I am hoping it’s an issue with the recent rollout of the Wellington service, and someone will fix it in time.
* Calls to Germany are pretty poor quality. Although it doesn’t cut out, there is lots of line noise. Both to land lines and mobile phones. But the good news is that I can use Skype to call Germany for cheaper. The iTalk rate is 5c a minute to landlines and 40c a minute to mobiles. Skype undercuts those rates by about 30%.

Write Your Specs Screen Shots

Thursday, July 27th, 2006

!/images/5.png (document view)!
!/images/6.png (edit document)!
!/images/4.png (projects)!

Ruby on Rails for your next Web App?

Sunday, July 23rd, 2006

I have written a “paper”:white-paper-10-reasons-for-ruby-on-rails outlining some of the pros and cons of developing your next web app using the Ruby on Rails framework.

10 Reasons why – Ruby on Rails

Sunday, July 23rd, 2006

Your development team has been frustrating you, projects start and four weeks later the development team is still developing the framework, your budget is running out. You want productivity but just don’t know how to get it. Is there an answer? One of your developers keeps mentioning this great framework called ‘Ruby on Rails’. Is this the answer? This article discusses the positives and the negatives in moving to this new technology.

1. Ruby on Rails provides a consistent approach to building web applications with an out of the box architecture. Traditionally starting a new web application is a fairly heavy weight process, you typically need to survey and choose your various software components to solve the common architectural problems of persistence, logging, build scripts, application configuration, web tier components and workflow. With the Rails framework these decisions are already made for you, so you can get on to understanding the business problem and quickly build a working system. You become productive in minutes not weeks or months.

2. In a Rails application, a pragmatic philosophy of convention over configuration is taken, this is apparent in all layers of the architecture with the highest productivity gains noticeable in the relationship between the model and the database. Once the developer understands the rules and constraints, Rails magically connects your view to your controller and model, and your model to the database. You don’t need generators or specialised tools to manage this, it all just works.

3. Unlike other productive web scripting languages, Ruby is a fully featured object-oriented language. Ruby also adds additional power with mix-ins modules which contain independent code to inject into your classes, blocks and closures simplifying client code behaviour. Its dynamic nature gives it power beyond static languages such as .NET and java, and the benefits are apparent by how the Rails framework has been put together itself.

4. Unlike other web templating technologies, the templating technology built into Rails can be used to generate web pages, emails, xml documents or any text document that requires dynamic content.

5. Rails includes a well thought out object relationship mapping tool, ActiveRecord, which provides your answer to database persistence. Your model is seamlessly persisted to the database. Transactions, inheritance models, validation, and caching have all been thought out and are production ready. With Rails you become a lot closer to the structure of the database than traditional object-oriented development methodologies. This is a good thing as over time as the database will no doubt end up being your project’s most valuable asset.

6. Rails includes support for a variety of web technologies. Every web application needs email integration at some point and Rails provides an out of the box smart solution, and as with other Rails technologies it gives you the complete package down to configuration in development, test and production environments. Ruby on Rails also supports web services, the integration with Rails due to the dynamic nature of Ruby is simply, clean and seamless. If you are moving into the Web 2.0 space, Rails provides a rich abstracted interface to implementing AJAX operations.

7. Generally software projects do not mature if at all to the point of having a solid foundation to perform database migrations and rollbacks between environments and across development systems. However with the Rails framework you will be delighted with the implementation of database migrations for applying and rolling back database changes. You enter your update and rollback scripts in Ruby, Rails understands the current version and can move forwards or backwards to any database version.

8. For development productivity, the shorter the gap between the change and test cycle the better. In Rails, changes are reflexed immediately within the runtime environment so developers can quickly iterate between fix and test cycles without any expensive redeploys. Ruby code is also easily testable. Methods and objects can be replaced at runtime so software components can easily be tested without resorting to external tools or generators.

9. Getting started with Rails is easy as generators will propel you along. An experienced Rails developer will also become aware of numerous idioms available within the Rails framework that shared the amount of code a developer need write. Overall less code to write means lower complexity, higher productivity and less bugs.

10. Ruby has been around for a long time, the Rails framework which has deservedly propelled Ruby into the spotlight has hit version 2.3 and is not only production ready but now well supported in the community and a stack of resource available on the web. Ruby and the Rails framework is open source and well supported by a clever team of contributors.

*So what are some of the cons?*

1. If you take time to follow the Ruby examples and tutorials it may give you a false sense of productivity. They typically follow the formula of creating a database model, configuring a connection to the database and joining it up to the model controller and view by use of the generators. This is all very simple involving a dozen or so lines of code. In the real world however you will be working at higher level of complexity and will need to understand multiple facets of Ruby and the Rails framework to be productive in churning out business functionality. You will need to invest in getting up to speed with the language and framework. As Ruby is a dynamic language, more automated testing is required. Your developers will need to become more disciplined and rigorous in creating unit tests as part of their development process.

2. If the type of development you are doing is glueing together existing systems or building back end systems, be aware that Rails is optimized for building web applications, your host system or enterprise database may not have the integration module you require for Ruby UPDATE (2010) – however JRuby is now maturing and can plug the gap by leveraging legacy java libraries and provide a lower cost to more enjoyable path to legacy integration. DSL’s can be engineered to remove the laborious code java developers are use to writing.

After considering the pros and cons, my advice would be that if your business or application has tight timelines, you want a more powerful web application for your buck with alone with inbuilt tools which remove the pain and setup cost of an IT project to seriously suggest considering investment into the Ruby on Rails framework.

Koz’s speaking engagements

Friday, July 14th, 2006

*A quote from Michael Koziarski:*
??After being on stage for 5 minutes at webstock, I’ve come to realise that I’m rather unusual — I actually like public speaking. Especially about “Rails”:http://www.rubyonrails.org/. So I’ll be speaking at a few places in Wellington NZ over the next 6 weeks, if you’re interested in Rails you should come along??

First up, Koz is speaking at “WellRailed’s 25th July meeting”:http://groups.google.com/group/WellRailed/browse_thread/thread/da4c1003d4489f56 where he’ll be covering what’s coming in rails 1.2, and talking about what cool new things were talked about at RailsConf.

Then on the 24th of August, he’ll be talking at a “Web Standards NZ”:http://www.webstandards.net.nz/ meeting, giving a more detailed introduction to Rails, and hopefully answering a bunch of your questions.

If there’s anything you’d like to see covered at either event, drop a comment here and we’ll do our best.