Common Gem Commands in Ruby on Rails

- 41studio
- April 11, 2014
- Uncategorized

Before we go, let’s make sure you have the latest version of RubyGems.

gem update –system

RubyGems is a package management framework for Ruby. This gem is an update for the RubyGems software. You must have an installation of RubyGems before this …

An Introduction To Object-Oriented Programming in Swift

June 19, 2014

In exciting programming language news (how often do you get to say that?) Apple recently released Swift, a compiled language meant to augment Objective-C for development on Desktop and Mobile iOS platforms. While Swift’s primary audience at this (very early) point is iOS developers, the language contains some interesting functionality for program design that will appeal to a wider audience, including Ruby, JavaScript, and PHP developers.

In this post I’ll take a look at three of the program design constructs that Swift provides: Classes, Structures, and Protocols. I’ll discuss how they can contribute to well-designed Object-Oriented (OO) programs in a way that might be interesting to dynamic language programmers, and show how aspects of their design reflect concerns of the platform for which they were developed.

Classes and Structures

The best source of information about Swift so far is The Swift Programming Language, a free e-book provided by Apple. It contains a first pass introduction to the language, a language reference, and a good deal of example code. After introducing the basic facilities of the language - its philosophy, the basic available types and data structures, control flow, closures, and so on - we get to the section on Classes and Structures.

“Classes and structures are general-purpose, flexible constructs that become the building blocks of your program’s code.” [1]

This sounds similar to the functionality of a Class or Module in Ruby. From this list of the features of Classes and Structures, we see even more similarities. Classes and Structures can both:

Define properties to store values
Define methods to provide functionality
Define initializers to set up their initial state
Be extended to expand their functionality beyond a default implementation

This means that Swift provides similar functionality to familiar OO Programming Languages. We can model problems using objects which can encapsulate data and functionality, and build complex relationships between these objects in a modular fashion. Curious readers might have the same reaction to this as I did - if it’s the case that both classes and structures can do the above, which is a reasonable set of functionality to expect from classes, why are there two constructs? What are the differences between them, and why does Swift as a programming language need both?

First, let’s take a look at what Classes can do that Structures cannot. Classes provide functionality for two crucial pieces of OO functionality that Ruby developers, for instance, tend to rely on somewhat heavily:

Inheritance, where one class can inherit the characteristics of another
Type casting, where you can check and interpret the type of a class instance at runtime

Additionally, classes provide the following facilities which are stated in terms familiar to those with experience managing resources and memory manually:

Deinitializers, to enable an instance of a class to free up any resources it has assigned
Reference counting, to allow for more than one reference to a class instance

Stated in other terms, inheritance, type casting, deinitializers, and reference counting make it possible to expressively create designs which employ the full compliment of OO techniques.

From my perspective, Classes and Structures have just the right amount of overlap in functionality, leaving enough room for developers to make reasoned decisions about which construct to employ according to the purpose it may be used for. The differences hinge on how instances of Classes and Structures are represented in memory after they are initialized – structure instances are always passed by value and class instances are always passed by reference. This distinction is something that dynamic language developers typically do not have to spend much time thinking about - on a mobile platform, however, this kind of thinking becomes very important.

Different memory semantics is not the only advantage of having these distinct types, however. Because structures are simpler than classes, and cannot be as heavily modified after declaration, they provide an opportunity to create value objects which represent pieces of data independent from their behavior. This is very useful.

While Classes and Structures cover much of the familiar ground with respect to OO functionality in Ruby or Python, there is one more construct that might not be so familiar that I’d like to point out before we draw any conclusions on Swift’s OO design capabilities.

Protocols

Protocols are an interesting addition to the already rich world of classes and structures. They provide a way to define behavior separately from the classes which implement them:

“A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality”

Similar constructs exist in Java, Go, and other languages, but many dynamic languages do not embrace this design style. Protocols embrace flexible design by encapsulating the necessary data and behavior for a domain idea outside the scope of a Class or Structure definition. This means that a concept can be represented separately from its implementation, allowing for more creative reuse, composition, and more.

To illustrate the usefulness of Protocols, consider the development of a small networked process to record some information from a system over time. You might want to have the system write to a Key-Value store, or to disk, or to STDOUT, depending on a variety of circumstances. In this case, you would simply define a Protocol:

protocol BackEnd {
    func get(Int) -> Int
    func set(Int) -> Bool
}

This protocol requires that anything which implements them must contain at least two instance methods - get, which accepts an Integer and returns an Integer, and set, which accepts an Integer and returns a Boolean value. A class that implements this Protocol might look something like the following:

class RedisBackEnd : BackEnd {
    func get(id: Int) -> Int {
        // Get 'val' from Redis based on 'id'
        let val = getFromRedis(id)
        return val
    }

    func set(val: Int) -> Bool {
        // Store 'val' in Redis here
        let boolFromRedis = storeInRedis(val)
        return boolFromRedis
    }
}

You could imagine similar classes for the other backends I mentioned above. This is a very convenient solution for swapping out backends when you need to run your process in different locations and under different circumstances - simply implement new ones as needed, and pass them in wherever a Backend is needed.

Defining a Protocol and implementing it is really the tip of the iceberg, however - things can get very subtle and complex. Protocols can be treated as types, and intricate hierarchies can be created with them. While it is interesting to look through the Swift book to see these examples, I don’t believe they are the real selling points of protocols. Used simply and in combination with classes and structures, protocols provide a missing piece of the design puzzle that often vexes programmers in dynamic languages.

Conclusion

Swift is a very interesting programming language that at first blush appears to have all of the necessary components to build expressive OO programs. In addition to classes, structures, and protocols, Ruby developers might also want to look into Extensions which offer mixin-like capabilities.

Whether you prefer inheritance, composition, or even a more esoteric SmallTalk style flavor of OO, it seems that Swift will be able to support you. What kinds of domains have you modeled in Ruby that you’d like to try in Swift? Do you notice any shortcomings? If you were to try to translate a program from Ruby, Python, or JavaScript to swift, do you think it would be easy? Would it change the way you think about program design? I’d love to hear more - to the comments!

Works Cited

[1] Apple Inc. “The Swift Programming Language.” iBooks.

[…]

Ruby 2.1.9 Released

March 30, 2016

Ruby 2.1.9 has been released.

This release includes many bug fixes. See ChangeLog for details.

As announced before, this is the last normal release of the Ruby 2.1 series. After this release we will never backport any bug fixes to 2.1 except security fixes. We recommend that you start planning to upgrade to Ruby 2.3 or 2.2.

By the way, we are planning to release Ruby 2.1.10 in a few days. Ruby 2.1.10 will not include any changes from 2.1.9, except for its version number. You do not have to use it on production, but you should test it because it has a two-digit version number.

Download

https://cache.ruby-lang.org/pub/ruby/2.1/ruby-2.1.9.tar.bz2

SIZE:   12016421 bytes
SHA1:   39524185b580a3390a3b5019819c8b28d3249766
SHA256: 4f21376aa11e09b499c3254bbd839e68e053c0d18e28d61c428a32347269036e
SHA512: a86422132e4c64007a84a91696f4557bdcbc8716fbfe1962f1eef3754ee7f994f4de0b5b7e7231c25057515767040d5c4af33339750b6db15744662e9bd24f38

https://cache.ruby-lang.org/pub/ruby/2.1/ruby-2.1.9.tar.gz

SIZE:   15166126 bytes
SHA1:   dd68afc652fe542f83a9a709a74f4da2662054bf
SHA256: 034cb9c50676d2c09b3b6cf5c8003585acea05008d9a29fa737c54d52c1eb70c
SHA512: 1e03aa720e932f019c4651c355e8ef35b87fdf69b054c9d39a319467d2a8e5bfe4995cbacd9add36b832c77761a47c9d1040f00e856ad5888d69ec7221455e35

https://cache.ruby-lang.org/pub/ruby/2.1/ruby-2.1.9.tar.xz

SIZE:   9395648 bytes
SHA1:   5e89efa5189c3def8ee8de18ce750a7e4a20ac32
SHA256: 39f203f7498aed2456fb500147fada5adcbf102d89d4f6aca773ebcadd8ea82a
SHA512: 1f331a8910fd7a9ab9c41bf56aef12041dd413ad49c696f6df2c9a7ec3a3d5cdf383f2a3d30949ea37b8ecb39f50355e526412b36ed4e07b60733d9db4d2bd14

https://cache.ruby-lang.org/pub/ruby/2.1/ruby-2.1.9.zip

SIZE:   16696728 bytes
SHA1:   4aa288b65fbf12692ac53577adc561c9a0f6a6ca
SHA256: 8610fdb1836d493c19600cfed4828083f85197096c0aea3f73fa1ed532cbb5a7
SHA512: a212b6a58637f6bf4f456d7ecc7bbd8ceaa0c3f16cb844b872eb62eaf261b5874fdb79705241d05a356fcdc1d3fdd8a94fcd8e6ca62190e9f544c8f45a9f41af

Release Comment

Thanks to everyone who helped with this release.

The maintenance of Ruby 2.1, including this release, is based on the “Agreement for the Ruby stable version” of the Ruby Association.

Posted by usa on 30 Mar 2016

[…]

The Ruby Rails Aggregator