text:
On Scala
This is one of a series of posts on languages, you can read more about that here.
I've been messing around with Scala for a while. For no particular reason I let it slide but have come back to it with increased interest in the last few years. Scala's blending of programming paradigms in a single language is impressive. It has the most powerful type system of the 'mainstream' JVM languages [1]. It's fun to write code in and is a good language for leaning into the functional plus static typing paradigm. As much as I like the language, I usually qualify recommending it outright, due to some noticeable externalities and the very need to adopt new paradigms. And so, Scala is the language I find myself most conflicted over - the part of me that likes programming loves it, the part of me that goes oncall wants to see more work done on the engineering.
What's to like?
Herein a drive by of some parts of the language that I like and have found useful. For a broader overview a good place to start is scala-lang.org's Learning Scala page material, which also has an excellent overview of features.
Scala has a repl. Every language should have a repl -
dehora:~[macbook]$ scala
Welcome to Scala version 2.9.2 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_09).
Type in expressions to have them evaluated.
Type :help for more information.
scala> println("hello, world!")
hello, world!
The repl enables method discovery (hit tab after the dot operator).
Like Go (and Groovy) Scala makes semi-colons optional. Also like Go, declaration order is reversed compared to C/C++/Java. The type comes after the variable/method name allowing you to say "a of type int", "foo returning int". You can define something as a val (cannot be modified), a var (can be modified) or a def (a method/function) - val/var declarations in classes result in getters and setters being implicitly created (the private[this] variant can be used to force direct field access). Using vals is preferred for thread safety and comprehension reasons. Scala supports type inference, which removes a lot of boilerplate relative to Java. Strings in Scala are immutable and can be multilined using triple quotes and support interpolation using a $ notation (as of 2.10). Scala strings can be enhanced with StringOps, which provides a raft of extra methods compared to java.lang.String.
In Scala each value is an object. The root class is Any. Scala doesn't have predefined primitives as per C++ and Java; these are modelled as a sub-class of Any called AnyVal, everything else is a sub-class called AnyRef, which maps to Java's Object class. Because numbers are objects their arithmetic operations are methods - 1 + 2 is the same as 1+(2) (but not 1.+(2) which will give a you a double instead of an int ;). As a result, the keywords 'true' and 'false' are objects - true.equals(false) is a legal statement. Technically because we're dealing with methods this is not operator overloading, but the term is often used. Since Scala allows symbolic methods for binary/unary operations, you are free to define something like def +(that:Thing):Thing for your class. You are also free (with some restrictions) to define methods with unicode and ascii symbols -
def ||(dowop:ThatThing):ThatThing = ...
def ψ(dowop:ThatThing):ThatThing = ...
And so it goes - for example, list operators such as '::' (append) and ':::' (prepend) are just methods. Scala can be understood as strongly object oriented when compared to Python or Java and notably gets two things right in its approach - don't have primitives, and, preserve precedence rules.
Classes and construction in Scala are noticeably different to Java, but also better in more or less every respect. Classes in Scala have a different syntax to Java, thanks to the constructor signature being part of the class definition -
class Song(songName: String, songLength:Double, songArtist:String) {
private val name = songName
var length = songLength
val artist = songArtist
Constructor arguments can be assigned, and are also visible through the class. A var field can be re-assigned, vals cannot, protected fields are available to sub classes. Private members are not accessible outside the class with the exception of a companion object (more on those soon). Default and named arguments are available on constructors and methods.
Scala also has objects, which are singleton instances rather than a template declaration; they are also where main() methods are declared. Objects with the same name as a classes and placed the same file are called companion objects. It's common enough to see such object and class pairs in Scala. Companions can access each other's private methods and fields. Companion objects enable the use of the apply() method, which pretty much eliminate the factory and constructor chaining gymnastics seen in Java. An apply call is dispatched to via construction - roughly, new Song(name) goes to Song.apply(name). There's also unapply(), which enable extractor objects that work with pattern matching - 'case Song(f)' will dispatch to Song.unapply(f), which will return whether the argument is matched. Companion objects are a clean way to package up declaration and creation concerns.
Scala's case classes remove the need to declare fields, accessors, copy contructors, equals/hasCode pairs. Case classes are about as concise as Groovy POGOs, with the advantages of not maintaining type safety and providing private scope for fields - they're a huge win compared to JavaBeans or POJOs.
case class Song(name: String, length:Double, artist:String)
val s1 = Song("Align", 3.56, "Mowgli")
res72: String = Align
val s2 = s1.copy(length=3.57)
res73: Double = 3.57
res75: Boolean = false
val s3 = s1.copy()
s3: Song = Song(Align,3.56,Mowgli)
s3 == s1
res77: Boolean = true
res78: Int = -882114443
Case classes integrate well with pattern matching (more below) and can be treated as functions (note that s1 above didn't require a 'new').
Scala traits allow multiple inheritance of implementations using a well defined ordering. Traits also support default implementations unlike C++ virtual voids or Java interfaces, and which are similiar in style to static methods in Java (strictly speaking Scala doesn't have statics). In conjunction with the sealed modifier you can define a 'sealed trait' and case class subtypes as a neat way to declare abstract data types such as trees and grammars, and which can be dispatched over using pattern matching. While I would be happy to see inheritance removed from the language, Scala traits are a practical way to avoid the diamond problem.
At least it's an ethos
Scala's Option allows you to wrap a value as being either Some or None. An Option[T] is a container for a value of type T. If the value is not null it's a Some, otherwise it's a None. This pushes null handling into the type system making it a compile time concern -
val a = Some("a")
a: Option[String] = Some(a)
val nope = None
nope: Option[String] = None
Using Option construction delegates None/Some selection, giving you None for a null or a Some for a non-null -
val whoKnows = Option(null)
whoKnows: Option[String] = None
val mightCouldBe = Option("aliens looking fer gold")
mightCouldBe: Option[String] = Some(aliens looking fer gold)
Options are one of the things I like most in Scala. For many of us, null is simply reality, and it can be hard to imagine life without it, but if you can appreciate why returning an empty list is better than returning a null, or why null shouldn't ever be mapped to the domain, I think you'll come to like Options. Options are handy for expressing the three valued logic (there, not there, empty) that is common when dealing with maps and caches. Code working with data stores may gain robustness benefits using Some/None in conjunction with pattern matching or higher functions. Options can be treated as collections, so foreach is available against them and collection functions like filter deal with them. Subjectively I prefer Scala's Option to Groovy's elvis and Clojure's nil largely because you can drive Option into API signatures. Option is also a gateway concept for monads.
Scala pattern matching allows you dispatch against a structure or the type of objects instead of reasoning about an instance. Pattern matching in Scala is powerful and shouldn't be compared to case/switch blocks in Java/C. You can match a populated list using a 'head :: tail' pattern; match against regexes; match against or an XPath-like option if you are working with XML, and so on. Pattern matching also helps with expressing business logic, such as doing something with an Account when it has a certain age or is from a certain location. Case classes are designed with pattern matching in mind (if you are familiar with and like Linda tuplespace style matching, chances are you'll like pattern matching over case classes). You can get compiler warnings on non-exhaustive matches in conjunction with the sealed modifier, helping to address problems with switch block fall-through and visitor pattern code (incidently, Yaron Minksy has a great talk that touches on this subject in the context of OCaml). I'm not entirely sure, but as far as I can tell pattern matching eliminates the visitor pattern and so the need for replace conditional with visitor/polymorphism workarounds. That's nice because that helps decouple structure from processing, avoiding some of the gnarlier maintenance issues with orthodox OO.
If pattern matching is a bit low level for handling input, you can try parser combinators. You define an object (or a set of classes) that is the 'parser combinator' (Scala provides some helpers you can sub-class), and each method in the object becomes a parser that returns Success, Failure or Error. You then call parseAll with the root parser and the input. Here's the stupidest example I could think of -
import scala.util.parsing.combinator.RegexParsers
object EpicNameParser extends RegexParsers {
val name: Parser[String] = """[a-zA-Z]*""".r
// bind object to a handy val
val enp = EpicNameParser
enp.parseAll(enp.name, "Donny")
res26: enp.ParseResult[String] = [1.6] parsed: Donny
enp.parseAll(enp.name, "Walter")
res27: enp.ParseResult[String] = [1.7] parsed: Walter
enp.parseAll(enp.name, "The Dude")
res28: enp.ParseResult[String] =
[1.5] failure: string matching regex `\z' expected but `D' found
The Dude
This probably won't be the fastest way to do things performance-wise, but it's concise. Pattern matching opens up possibilties for dealing with conditionals and clean code; it's also the basis for actor receive loops.
Strange enlightenments are vouchsafed to those who seek the higher places
Scala has a rich set of collections. As well as Lists, Vectors, Sets, Maps and the generic Sequence (Seq), Scala has a Tuple that can take mixed types. The classes Pair and Triple are aliases for arity 2 and arity 3 tuples. Scala has both mutable and immutable collections that are collection analog to var and val fields. The community idiom seems to be to prefer immutable collections until you need to drop into mutability or j.u.c for performance reasons. Arrays in Scala map to Java arrays, but can be generic, and can also be treated as a Sequence.
As you might expect from a functional language, working with lists, maps and collections is nice. Scala's for loops (for comprehensions) work like Python's list comprehensions but have a syntax that allows more expressiveness. I like forcomps, but it's possible you'll move towards map/flatmap/foreach/filter methods that are available on collections as idiomatic for simpler loops (for is implemented using these methods). The foreach method accepts closures (similar to each/do in Ruby), and also functions. You can apply functions over members using map(), eg 'Seq(1, 2).map({ n=> "num:"+n })'. The flatMap method is similar but instead, accepts a function that returns a sequence for each element it finds, and then flattens all those sequences' members into a single list. This interacts nicely with Options, since an Option is a sequence -
def stoi(s: String): Option[Int] = {
try {
} catch {
case _ => None
Once you have a function you can apply it to collection using map(), using the syntax '{ element => function(n)}' -
Seq("1", "2", "foo").map({n => stoi(n)})
res34: Seq[Option[Int]] = List(Some(1), Some(2), None)
As we can see, map() produces 'List(Some(1), Some(2), None)', ie, a list of lists. The flatMap() method on the other hand collapses the inner lists and removes the members that are None (since None's length is 0) leaving just the Some members (since Some's length is 1) -
Seq("1", "2", "foo").flatMap({n => stoi(n)})
res37: Seq[Int] = List(1, 2)
Collections also provide a filter() method that chains nicely with map() - easy composition of functions is a feature of Scala. For gathering up results you get fold and reduce (foldLeft and foldRight, reduceLeft, reduceRight). For example you can use foldLeft to trap the largest int in a list or sum a list -
List(5, 0, 9, 6).foldLeft(-1)({ (i, j) => i.max(j) })
res24: Int = 9
List(5, 0, 9, 6).foldLeft(0)({ (i, j) => i + j })
res48: Int = 20
Although reduceLeft might be a more direct way to go about both -
List(5, 0, 9, 6).reduceLeft({ (i, j) => i.max(j) })
res38: Int = 9
List(5, 0, 9, 6).reduceLeft({ (i, j) => i + j })
res49: Int = 20
Reduces are something of a special case of folds. Folds can gather up elements and may return a different type whereas reduces return a single value of the list type. For example, you can't say this -
List(5, 0, 9, 6).reduceLeft({ (i, j) => "" + (i + j) })
but you can say this -
List(5, 0, 9, 6).foldLeft("")({ (i, j) => "" + (i + j) })
longList.foldLeft("")({ (i, j) => "" + (i + j) })
longList.foldRight("")({ (i, j) => "" + (i + j) })
res51: java.lang.String = 5096
Methods like fold/reduce generally handle nulls without blowing up -
val x:String = null;
List("a", x).reduceLeft({ (i, j) => "" + (i + j) })
res60: String = anull
Monads are coming
Functional programming is unavoidable in Scala. Scala is a functional language in the sense that you can program with functions and not just class methods, and functions are treated like values and so can be assigned and passed around as arguments. This is where Scala stops being a better Java, in the sense Groovy is, and becomes its own language. Functions in Scala can be declared using val -
scala> val timestwo = (i:Int) => i * 2
and can take variables from scope -
scala> val ten = 10
ten: Int = 10
scala> val mul = (i:Int) => i * ten
scala> mul(3)
res2: Int = 30
You can also create functions that accept other functions and/or return functions (aka higher order functions) -
def theSquareMullet(i:Int) = i * i
def theHoffSquareMullet({ mullet: => Int }) = mullet * mullet
The expression 'mullet: => Int' represents any function (or value) that returns an Int. All of these are valid -
scala> theSquareMullet(10)
res7: Int = 100
scala> theSquareMullet(theHoffSquareMullet(10))
res8: Int = 100
scala> theHoffSquareMullet(theHoffSquareMullet(10))
res9: Int = 10000
Functions can be anonymous, you can see some examples in the section on collections above. Functions can be nested and multiple values can be returned from a function/method -
def theSquareAndTheMullet(i:Int) = (i * i, i)
val (f, f1) = theSquareAndTheMullet(2)
f: Int = 4
f1: Int = 2
val bolth = theSquareAndTheMullet(2)
bolth: (Int, Int) = (4,2)
scala> bolth._1
res9: Int = 4
res10: Int = 2
The slight downside being the syntax for unpacking a discrete val isn't that pleasing (and are default limited to size 22 if you're going to return the world). On the upside accessing a tuple out of bounds is a compile time error and a tuple preserve each member's type.
Endofunctor's Game
The type system is powerful. Like functional programming support, the type system marks Scala its own language instead of a better Java. Scala has generics, like Java, and supports type variance, +T (covariant), -T (contravariant), :> (sub type, or Java 'extends'), <: (super type, or Java 'super'). Classes can be parameterised like Java, but unlike Java so can types via what's called a type alias. These allow you genericise members independently of the class signature -
abstract class Holder {
type T // alias
val held: T
def IntHolder(i: Int): Holder = {
new Holder {
type T = Int
val held = i
One nice feature is the compound type, which allows you to declare for example, that a method argument is composed of multiple types -
def allTheThings(thing:ThatThing with ThatOtherThing):ThatThing = {...}
I can't do justice to Scala's type system in a single post. I doubt I know enough to appreciate what it can do - diving into it is very much a red pill thing. What I will say is the type system is Scala is deeply impressive in what can be achieved. The type system allows things that are either impractical or impossible in Java and gives good ways to scrap your boilerplate.
What's not to like
Onto some things that bother me about Scala.
Here are eighteen ways to say, roughly, add one to each member of a list creating a new list, remove any members in the new list that aren't greater than one creating another new list, and show that final list as a string -
List(0, 1) map { _ + 1 } filter { _ > 1 } toString
List(0, 1) map { _ + 1 } filter { _ > 1 } toString()
List(0, 1) map ( _ + 1) filter (_ > 1) toString()
List(0, 1) map ( _ + 1) filter (_ > 1) toString
List(0, 1) map ({ _ + 1 }) filter ({ _ > 1 }) toString
List(0, 1) map ({ _ + 1 }) filter ({ _ > 1 }) toString()
List(0, 1) map ({ n => n + 1 }) filter ({n => n > 1 }) toString()
List(0, 1) map ({ n => n + 1 }) filter ({n => n > 1 }) toString
List(0, 1) map (n => n + 1) filter (n => n > 1) toString()
List(0, 1) map (n => n + 1) filter (n => n > 1) toString
List(0, 1).map( _ + 1 ).filter( _ > 1 ).toString()
List(0, 1).map( _ + 1 ).filter( _ > 1 ).toString
List(0, 1).map({ _ + 1 }).filter({ _ > 1 }).toString()
List(0, 1).map({ _ + 1 }).filter({ _ > 1 }).toString
List(0, 1).map({ n => n + 1 }).filter({n => n > 1 }).toString()
List(0, 1).map({ n => n + 1 }).filter({n => n > 1 }).toString
List(0, 1).map(n => n + 1).filter(n => n > 1).toString()
List(0, 1).map(n => n + 1).filter(n => n > 1).toString
Scala provides syntactic flexibility. This flexibility is not limited to methods. Two ways to express for-comprehensions; three collections libraries (four if you count Java's); methods foo and foo() are not the same; XML assignment demands whitespace around '='; careful placement of suffix invocations such that they are not treated as infix. Closure captures can be tricky. In Scala '_' means everything and anything - there's no real way to avoid it in practice (imports, existential types, exceptions and closures). In particular, implicit conversions strike me as tricky to reason about. Scala generics have other bounds, 'view' and 'context' that allow you work with types beyond traditional hierarchies, where implicit conversions are made available.
Symbolic methods on top of the features above provide the base capability for DSLs. DSL support in a language is not an obvious win to my mind. Even a relatively restrained library like Gatling offers enough variation to catch you out and a symbol heavy project like SBT can be hard work. Scala's not unique in this - I have a similar beef with Ruby and Groovy.
Maintainable, comprehensible Scala requires restraint, in the form of disciplined practice and style guides. That you don't have to use all the features isn't sufficient to wave the problem away. If you are maintaining code, you don't get to ignore all the variation teams have added over time (I do not see the concept of Scala levels helping much). Dependency on open source amplifies the matter. Scala has a simple core with orthogonal concepts (the language spec is pretty readable as these things go). However that says nothing about the interaction of features, which is where complexity and comprehension resides. I'm not trying to conflate understanding of functional and type-centric constructs with complexity - simple things can be hard, but that doesn't make them complex.
As a systems grunt, I spend a lot of time with running code, sifting through stacktraces, heapdumps, bytecode, metrics, logs and other runtime detritus. You learn from bitter experience that correctness capabilities provided by a type system do not always trump having comprehensible runtime behaviour (the same can be said for the outcomes enabled by dynamic languages). Scala generates plenty of classes; as a result Scala stacktraces can be a bit of a bear, although better than Groovy or Clojure's. An artifact of Scala's integration with Java is that you can't catch checked exceptions, you catch all and extract the type with a case statement. Compilation is slow and becomes dead slow with the optimise flag. The expressivity of the language results in an abstraction gap when it comes to reasoning about runtime cost. Option, a great feature, incurs the cost of wrapper classes. Scala introduces a fair bit of boxing overhead. For comprehensions have overhead such that you may need to swap with a while/do loop. Closures naturally have overhead (at least until the JVM can optimise them). To ensure unboxed class fields, you need to qualify them with [this]. Immutable collections may need to be replaced with mutable or j.u.c, to deal with memory overhead, or performance (sometimes there are wins, like Scala's HashSet). The foldRight method will happily blow up when foldLeft wouldn't. Some serious runtime bugs get kicked down the road. That said, you can build high performance systems in Scala.
My least favourite aspect of Scala is probably backwards compatibility. Scala has broken compatibility three, maybe four times, in five years. This does not seem to be considered a problem by the community. I understand how this frees things up for the future, but the effort needed to bring all the dependencies forward yourself or wait until the maintainers rebuild is an area where the language does not strike me as remotely scalable. Cross-compilation support is available in in SBT, but is something of a workaround.
If a grand unified theory of programming language existed, its implementation would be called Scala. But enough of the modh coinníollach. Scala is neither a better Java/C# nor a worse Haskell/OCaml; it is its own language, and the most advanced on the JVM today. How much you are willing to invest in and work with functional and type-centric constructs will have a bearing on how much value you can get out of the language. And I find I need to weigh up three externalities - runtime comprehension, maintaining a clear reader-comes-first codebase, and dealing with language/binary incompatibility.
I feel it's inevitable that functional programming plus Hindley/Milner/Damas flavor static typing will become a dominant paradigm. If that's right, what are today considered exotic constructs like closures, function passing, higher order functions, pattern matching and sophisticated type systems are going to be mainstream. It also means the more mathematical abstractions, such as monads and functors will be common understanding, certainly by the 2020s (they are closer than you think!). As such spending time with Scala (and Rust/Haskell/OCaml) is a worthwhile investment. There will still be places for dynamically typed and close to the metal languages, but orthodox OO as practised today, is a dead end. Scala is this paradigm's breakout language and the one mostly likely to drag us half-way to Haskell.
Complexity is a criticism that is frequently levelled at Scala, one which gets pushback from the community. It's a sore spot, as there is no shortage of FUD. My take is that Scala's complexity is typically justified for the broad set of applications and paradigms it can encompass.
Scala has a relatively small number of books. Unfortunately since the language is moving quickly a number of them are out of date, as good as they may be.
Scala for the Impatient, Cay Horstmann. This is probably the closest thing to an up to date text; as of mid-2013 it's the go to introductory book on the language. Written by a professional writer who's covered many languages in previously, and it shows.
Scala in Depth, Josh Sureth. Targeted at people familiar with Scala but looking for idiom. It covers Scala 2.9 and by definition is out of date, however a lot of available open source is still targeting 2.9, so it remains relevant at least up to 2014.
Programming In Scala 2nd Edition, Martin Odersky, Lex Spoon, Bill Venners. This has been the standard reference for the last number of years and a very good book. It's out of date by virtue of covering Scala 2.8, but worth picking up to understand the language's core, especially if you see it discounted.
Programming Scala, Alex Payne, Dean Wampler. Part textbook, part evangelism, I credit this book with getting me interested in Scala again. Sadly, it's too out of date to recommend by way of targeting 2.7 and giving mention of 2.8 features, which hadn't been released at the time.
Akka Concurrency, Derek Wyatt. Not strictly a Scala book, but a fun read on programming with Akka, actors, and for concurrency in general with Scala. It targets Akka/Scala 2.10.
Functional Programming in Scala, Paul Chiusano, Rúnar Bjarnason. Not out until Sept 2013. Teaches functional programming using Scala, as opposed to being a book about Scala. I have high hopes for this one, there's a gap in the market for a pragmatic book on functional programming.
Scala's flexibility is such that idiomatic Scala isn't always obvious. I've found these two guides helpful -


text:
Next Episode of Sesame Street is
Sesame Street is a widely recognized and perpetually daring experiment in educational children's programming. This show has taken popular-culture and turned it upside-down. The fast-paced advertisements that had parents of the new era worrying for their children were the basis for the original format of this show. The show has often satirized pop culture, and made itself easier for parents to watch along too. And thus, the positive impact this show has had on modern society is beyond another. No show is more recognized the world over by as many generations and walks of life. Shown in its original format or with changes to reflect a regional education focus, Sesame Street is now seen in over 140 countries. The show that Entertainment Weekly named the "20th Best Ever Show" has changed the education scene to focus on "entertainment". This has turned out to be a valuable theory that not only...
Michele Mariana(Cecille)
Eugene Byrd(Jelani)
Lily Tomlin(Ernestine)
Sarah Jones(Mr. Noodle's Other Sister, Miss. Noodle)
Nicole Sullivan(The Letter A)
Larry Block(Tom)
Nitya Vidyasagar(Leela)
Jessica Stone(Jasper)
Lillias White(Lillian)
Ismael Cruz Cordova(Armando "Mando")
Bill Irwin(Mr. Noodle)
Kristin Chenoweth(Mr. Noodle's Sister, Ms. Noodle)
Looks like something went completely wrong!
But don't worry - it can happen to the best of us,
- and it just happened to you.
Please try again later or contact us.

subset: commoncrawl


text:
Karen Raisch-Siegel is the executive director of LifeWorks of Southwest General in Middleburg Heights, OH. LifeWorks is a 64,000-square-foot fitness center owned and operated by Southwest General Health Center. Karen earned her master's degree in exercise physiology. She is a certified first responder with the state of Ohio and a certified group exercise instructor. Karen has been working in the fitness industry for the last 18 years. She has served as a fitness instructor, personal trainer, group exercise instructor and program director. Karen is responsible for more than 100 employees and 5,000 members. However, she still enjoys making time to teach her arthritis, aerobics and Pilates classes.
Retention, retention, retention. That is the name of the game if you want to stay profitable. But what's a club to do when it's surrounded by competitors? The answer: position, position, position.
As the executive director for a medically integrated facility located in northeastern Ohio, I have experience in dealing with retention issues, especially because all types of fitness facilities surround my facility. What makes it a bit more challenging for us, though, is that we have four recreation centers within a three-mile radius. Two of those recreation centers are top notch.
Although we are still working on positioning our facility better in the marketplace, we have always offered programming and member appreciation events as our retention programs. We currently offer the following:
- Free, fun fitness incentive programs. Members lost 1,800 pounds with our Biggest Loser program in the first quarter of 2007.
- Facility-wide incentive programs. The Big 100 program gave away a deluxe gym bag each day for 100 days leading into 2007.
- Member-appreciation events. The Crazy 8 program celebrated eight years of fitness with a customized water bottle giveaway, a scratch-off ticket when you checked in and complimentary breakfast, lunch and dinner.
- Local and international group trips.
- Programming such as line dancing, belly dancing, Reiki and Pilates.
- Free food the first Wednesday of each month.
What did we learn from this, and what can you learn from our trials? We, as facility operators, need to do more.
These examples are important elements of retention. However, these programs are not reaching out to all members in a valuable way. We have to ask ourselves, "What do we do for the non-charter member who has been committed to our facility for three to eight years?" We also have to ask, "What about that member who comes in, works out and leaves without speaking a word to anyone?"
Programs that aren't inclusive or aren't measurable are really missing the boat when it comes to retention.
A true retention program recognizes members for the time they have committed to a facility and reaches out to that quiet member who goes unnoticed. Fun social events should still be offered, but not without a way to measure them.
Here are five tips for creating a solid retention program:
1. Keep it simple and fun. Make sure that the program is achievable and simple to manage.
2. Measure members' progress. Folks like to see their names posted on a board so that they can easily monitor their progress against everyone else.
3. Set a goal. There needs to be an end result. Is the goal attendance, weight loss or amount of time?
4. Offer a reward. The reward needs to be something they will value, but something not too great in value that will make the other participants feel cheated. Good options are a light lunch for all winners or personal training sessions.
5. Follow through. Recognize all of the participants who achieved their goals, and post the names of the winners.


text:
Key Content
- WFP: WFP Angola Country Brief, August 2019
- UNICEF: UNICEF Angola Humanitarian Situation Report July 2019
- UNHCR: Government & UNHCR cooperation on health to affected populations: Case of Lunda Norte, Angola
Appeals & Response Plans
- UNHCR: The Democratic Republic of Congo Regional Refugee Response Plan (RRRP) January 2019 - December 2020
Useful Links
Alerts/ Disasters
Most read reports
- Govt. Angola: DRC refugees repatriation postponed sine die. 22 Sep 2019
- Govt. Angola: Over two kilometers cleared of landmines. 22 Sep 2019
- WFP: WFP Angola Country Brief, August 2019. 18 Sep 2019
- Govt. Angola: Over 200,000 children benefit from polio vaccine. 13 Jul 2019
- Govt. Angola: Lunda Norte: Voluntary repatriation of refugees ends. 12 Sep 2019
By Dr Marc Biot, Dr Isabelle Defourny, Marcel Langenbach, Kenneth Lavelle, Bertrand Perrochet and Teresa Sancristoval, Directors of Operations
In a complex and fast-changing world, we remain focused and resolute in pursuit of our goal – to provide the most appropriate, effective medicine in the harshest of environments. As well as responding to vital needs, our aid is born of a desire to show solidarity with people who are suffering, whether as a result of conflict, neglect or disease.


text:
800-334-6259 | Contact Us
No Hub Fittings for Acid Waste Drainage PipingFast installation, low labor costs, pre-grooved mechanical fittings for acid waste pipe. No special tools, heat or hot water needed.
Learn more>>>
Rionfuse CF Polypropylene for Acid Waste Piping
Electrofusion pipe joining system for acid waste piping requires no clamps, and permits fusing of both sides of coupling at the same time, reducing labor costs.
Learn more>>>
Socket Fusion for Acid Waste Piping
Socket fusion system for acid waste pipe drainage. Durable, strong, hermetically sealed system for severe usage applications.
Learn more>>>
Access our entire BIM library at BIMobject® Cloud Solution
Careers / Investors / Submit Product Ideas / Terms of Use / Privacy Policy / CA Supply Chain Disclosure / Site Map
© 2019 Orion Fittings
A Watts Water Technologies Company. All Rights Reserved.


text:
District 10 Spring Meeting will be held at the St. Croix Casino Turtle Lake Event Center on Saturday April 29, 2017 in Turtle Lake, Wi. 54889.
This will be sponsored by Amery VFW Post 7929.
08:00 – 09:00 hrs – Registration with Coffee & Donuts
09:00 – 12:00 hrs meeting (nominations and elections)
Buffet $14.99 – includes 2 entrée: Roasted Pork Loin, or Chicken St. Croix (tender chicken breast topped with ham, bacon &swiss cheese), Baked Potato, Corn, salad bar, dessert bar, and dinner rolls. We need at least 50 people to eat and meeting room is free. Please RSVP to Eldon Sanders – cell: 612-419-5969, or email email@example.com
there will be a Cootie Scratch
We will also be having our spring election for 2017-2018 year. Please bring your nominations for all positions!
If the comrade being nominated can not attend this meeting he must send a letter so stating that he will take the position and sign it to the District Commander. Please plan on your Post attending!!
District Commander: Steve Rhodes – phone: 715-617-7406
Full – St. Croix Casino Turtle Lake, 777 U.S. Highway 8 & 63, Turtle Lake, Wi. 54889. Fri. night $79 + tax 2 adults 715-986-4000 ext. 8105 1-800-782-9987
Full – Country Lodge of Turtle Lake, 636 Highway 8 & 63, Turtle Lake, Wi. 54889. Fri. night $109 includes tax 2 Adults 715-986-2070 or 866-986-2070.
other motels in the area : (Have not contacted any of these as availability or cost)
Forest Inn Motel, 1045 Riverplace Drive, Amery, Wi. 54001 Telephone: 715-268-4100 approx. 16 miles from Turtle Lake
Holiday Inn Express, 2190 U. S. Hwy 8, St. Croix Falls, toll free 1-800-422-4097 approx. 24 miles from Turtle Lake
Cumberland Inn & Suites, 1650 Elm Street, Cumberland Wi., phone: 715-822-5655, approx. 13 miles away
Blacksmith Shop Motel, 1879 W. Bone Lake Drive, Balsam Lake Wi. phone: 715-857-6481 approx. 17 miles away
More information will be added as we get closer to the date.


text:
A decade ago there were only two kinds of lodgings on Nantucket. For those who could afford them there were (and still are) a few grand, wallet-bruising seaside hotels. For everyone else there were scores of smaller, less expensive 19th-century inns. These bed-and-breakfasts almost uniformly embraced an authentic whaling-era aesthetic, which included period details both charming (canopy beds, lace curtains, antique furniture) and less so (thin walls, musty smells, and shared hallway bathrooms).
Over the past few years, however, younger, trendier travelers have discovered the island. To cater to these visitors several innkeepers have upped their game. Since last summer more than a half-dozen properties have undergone complete redesigns, replacing doilies with Jonathan Adler textiles, breakfast nooks with slick cafes, and tour brochures with in-room iPads.
The fact that all of these properties are located downtown — a designated historic district with stringent building and renovation codes — means that proprietors have had to jump through a few logistical hoops in order to relaunch. (For example, all exterior building-design elements, such as light fixtures and windows, must meet standards of historical accuracy to be approved by the island's Historic District Commission.) But those who have weathered the process have few complaints.
"The historic appeal is what makes Nantucket special," says Lauri Benk, who co-owns two newly reopened inns. "But these days you need to have an interior designer — and it can't be grandma."
Here are some newly chic, reasonably priced boutique accommodations:
Lauri and Paul Benk didn't set out to become Nantucket innkeepers. But when they visited the island in 2006 and saw the available lodging options, Lauri says, "we realized there was a need here." In 2012 the New Jersey-based couple opened their first property, the Centerboard Inn, in an 1886 sea captain's home — replacing the formerly dark-wood interiors with crisp white wainscoting, seagrass rugs, airy fabrics, and sculptural light fixtures. This June, the Benks launched their second venture, the Regatta Inn, across the street in a Federal-style building. Its eight guest rooms feature Matouk and Frette linens, vivid textiles from Serena & Lily, and modern marble-and-glass baths with rainfall showers. Downstairs the charming breakfast room (pictured below), serving fresh-pressed juice and baked goods, evokes a European cafe.
REGATTA INN 78 Centre St., 508-901-5748, www.theregattainn.com;
CENTERBOARD INN 8 Chester St., 508-228-9696, www.centerboardinn.com; both inns from $159
When Lark Hotels (a group comprising several boutique properties in New England) decided to turn this 1883 former sea captain's house into a 20-room hotel, they called in Boston designer Rachel Reider to transform the interiors. Reider managed to keep many of the house's distinctive details — hardwood parquet floors, ornate stairway banisters — while otherwise doing a complete style overhaul. The hotel, which debuted in late June, now features bold new custom upholstery and wallpaper in beachy stripes and prints (pictured at right); sleek, tiled en-suite bathrooms; and high-tech amenities (Apple TV, iPads, and iPod docks). Between the Main House and the more casual surf-motel-style Guest House is a firepit-warmed, BYOB courtyard lounge with a bar of make-your-own cocktail mixers.
76 MAIN 76 Main St., 508-228-2533, www.76main.comfrom $199
This 11-room property opened in June 2012 as an annex to one of Nantucket's first style-conscious inns, the Veranda House, which introduced coastal-chic interiors in its turn-of-the-century guesthouse in 2008. Reider, who took on the Veranda House as her first island project, was invited back to renovate Chapman House and given free rein, as she says, "to go bolder and funkier." Her interiors incorporate some unusual elements (at least for Nantucket): graphic black-and-white patterned wallpaper, scarlet nailhead-studded headboards, and chandeliers made from turquoise beads. If a fabulous retired Broadway star decided to settle on the island, she might do it here.
CHAPMAN HOUSE 3 Step Lane, 508-228-0695, www.theverandahouse.com/chapman-house, from $129
The Nantucket Hotel + Resort
The oldest hotel property on the island, this sprawling manse has been hosting guests, in one incarnation or another, since 1891. When owners Mark and Gwenn Snider took it over last year, they decided the grande dame needed some serious work done — and not just a facelift. By the time they unveiled the refurbished hotel in June of 2012, they had gut-renovated to create 30 bright, clean-lined rooms and suites with Murphy beds and kitchenettes; wide hallways hung with black-and-white island photography; an understatedly elegant bar and bistro; and one of downtown's only state-of-the-art fitness centers. Newly added this year are two stand-alone, two-bedroom cottages, plus an ocean-view penthouse suite.
THE NANTUCKET HOTEL + RESORT 77 Easton St., 508-228-4747, www.thenantuckethotel.com, from $225.
The Inn at White Elephant Village
A younger, hipper sister to the well-known White Elephant (which sits just across the street overlooking Nantucket Harbor), this 20-room inn debuted in July in what was formerly a century-old guest house. It shares a futuristic lobby, a large cabana-ringed pool, and an exercise room with a cluster of adjacent rental villas (the nominal "Village"). Guest rooms are spare but luxurious with ecru-toned fabrics, paneled ceilings, and ceramic bath tile that resembles pickled wood. Designer (and islander) Kathleen Hay, who did the interiors, says, "it's modern, but not overly so. People who come to Nantucket still want a certain amount of comfort — they want to sit on couches that feel squishy."
THE INN AT WHITE ELEPHANT VILLAGE 19 North Water St., 508-228-1500, www.whiteelephantvillage.com, from $195.
The Gatehouse
Unique among Nantucket's crop of new inns — and almost unheard of in the downtown historic district — this 19-room property was newly built in 2013. It shares a block with a cluster of sister inns (collectively known as the Roberts Collection), but is the only one boasting modern design, central air conditioning, soundproofed windows, and an underground parking garage. Pam Roehm, who manages the Gatehouse with partner Gerry White, says there are still plenty of island visitors "who want the traditional stuff, the four-poster beds and the antiques." But, she says of the inn's plush, spacious rooms, with their high-thread-count linens and walk-in glass-cube showers, "the younger folks will like this."
THE GATEHOUSE 11 India St., 800-872-6830, www.therobertscollection.com/gate, from $225.
Sarah Gold can be reached at email@example.com.


text:
We are a bootstrapped web start up. We have a LAMP web application that we expect relatively low to mid traffic because users need an account to log in. Our current approach is to colocate two servers, a web and mysql database server. We are planning to use Ubuntu Server 9.04.
We have shopped around for dedicated servers but the price range from $900 to $1500 per month, therefore we are exploring the colocation approach. We are considering purchasing two Mac Minis (2.0GHz Intel Core 2 Duo 2 Gb RAM) because we are familiar with the machines are the prices are relatively inexpensive.
What are the pros and cons of using these 'non-server' grade machines? We would install Ubuntu Sever and attach firewire external hard drives.
Any advice on how to set up 'good-and-economic' web/database servers is welcomed.


text:
We'll sell your home for as low as $2995!
We advertise your home.
We show your home to buyers.
We arrange for other agents to show your home.
We arrange all inspections.
We pre-qualify Buyers.
"America's Leading Discount Real Estate Company"®
Free Buyers "Hotsheet" Call or email us today to be added to our mailing list. The Hotsheet lists all of the homes we have for sale. It shows prices, addresses, special terms and more!
Are There Any Up-Front Fees or Hidden Charges?
Answer: NO! You pay if we sell your home. If we don't sell your home, you owe NOTHING!
How Can You Charge So Much Less?
Answer: We discovered that by charging less, more sellers choose our company. This gives us the opportunity to offer more homes for sale, which of course helps to attract more buyers. We can afford to make less per sale since we sell so many more homes. In other words,VOLUME! Everyone benefits.
Does Assist2Sell Show My Home To Buyer?
Answer:YES! We have licensed agents available every day ready to show your home to interested buyers
Do Other Agents Show My Home?
Answer: YES! We cooperate with all real estate professionals. Agents from other offices frequently show and sell Assist2Sell listings.
Do You Work With Buyers?
Answer:YES! Our agents provide full service for buyers as well as sellers. In addition to our own fine selection of homes, we can also assist buyer in viewing homes for sale through the MLS and new homes offered by local builders. The best part for buyers is that they get this professional assistance at no cost.
How Do I Know What My Home Is Worth?
Answer: We help you! We prepare a free comprehensive Comparative Market Analysis(CMA) using the same technique as appraisers. This will assist YOU in determining the correct price for your home. This approach takes into consideration the current competition of similar homes. We also review sales for the past year or so to compare market times and selling prices. If you would like a free CMA, please call or email us today.
(804) 794-6789 or firstname.lastname@example.com


text:
Cloud on a chip: Sometimes the best hypervisor is none at all
Déjà vu all over again
Cloud We have come a long way, from data processing to systems to servers, and maybe so far we are essentially getting back to where we started.
Centralized systems begat distributed servers, and now we are in the middle of begetting a hybrid kind of computing that looks like distributed iron but, thanks to virtualization and sophisticated workload management tools, behaves like what is essentially a software-based mainframe and what is usually these days called a cloud.
But just because there is now an abstraction layer that runs on a server and across servers to make it look like a giant pool of CPUs, memory, I/O, and storage does not mean there are not serious problems confronting the server business.
Moore's Law, the ever-shrinking transistor that enables more components to be crammed onto a piece of silicon or for them to run faster, hasn't hit a wall but it did have to take a detour because there was no way we were going to be able to make a 10 GHz chip that could be cooled.
And so, all server processor makers have been cookie-cutting cores onto dies, essentially putting a multi-core server, including everything but memory and disk, onto the chip.
This has been a boon for the server business in the past several years, but the problem is this: Not all workloads can run across large number of processor cores, so moving from four to eight to a dozen or sixteen cores is not necessarily going to result in more work getting done for any particular job.
Putting the hype into hypervisor
And while it is perhaps heresy to say this in the hypervisor-crazed early days of cloud computing, the fact is that there are many some workloads that run best very close to the iron, without having a hypervisor layer burning up resources.
And for these kinds of workloads - simple web applications, dedicated hosting, simple media streaming, and parallel supercomputing workloads - maybe the best thing to do would be to move a whole cloud of servers down onto the chip, including a network that links multiple and independent computing elements together much as a local area network links together free-standing servers into a cluster.
Jim Held, an Intel Fellow and director of Terascale Computing Research at the chip giant, is examining ring interconnects (like those that will be used in the forthcoming "Sandy Bridge" and "Westmere-EX" Xeon and "Poulson" Itanium processors) as well as various topologies for linking together CPU components, with an eye toward increasing the efficiency of processing and keeping the complexity of the chip down as much as possible.
On the cloud front, one of the more interesting projects that Held is working on is called the Single-chip Cloud Computer, or SCC for short.
The SCC chip is experimental, and Held is very clear that its existence is in no way an indication that this will be the future architecture of Atom, Xeon, or Itanium processors. But the odds favor it, for reasons outlined above.
'Integrate in the right way'
The first wave of consolidation on chips was to move elements of a motherboard - such as memory controllers, cache memory, auxiliary processors like floating point units, network controllers - into the chip.
The next wave will be to take elements of distinct systems - multiple computing elements and the networking that links them together - and squeeze them down to the same bits of silicon, perhaps stacking them up with main and flash memory into three-dimensional arrays.
"Integration is our forte," boasts Held. "But we need to integrate in the right way."
For now, with the SCC, Intel is working in two dimensions. The experimental chip is based on a fairly simple 32-bit Pentium P54C core. Two of these cores are put on a single tile, which includes an L2 cache memory for each core and a message passing buffer between the cores and a router linking these core pairs to others on the die.
In the case of the SCC chip, there are 24 core pair tiles. The chip has four banks of six tiles, each with its own DDR3 memory controller.
The SCC chip links the two core clusters on the die in a 6x4 2D mesh that runs at 2 GHz, which is twice the speed of the clocks on the cores. The memories on the die are not cache coherent, which means that they cannot look like one giant virtual chip to an operating system or a hypervisor.
This is not a big deal for parallel applications. If you want to run an application on a large cluster of parallel computers, all of that cache coherency electronics is legs on a snake.
Why would you want to aggregate the cores into a single system image, which takes CPU overhead, and then carve it up into smaller compute slices using a hypervisor? For a lot of workloads, having a cloud on a chip, or networks of interconnected clouds on a chip, will make a lot more sense. ®


text:
Fri, 21 April 2006
Democrats say Iowa lacks diversity, so we should lose our first in the nation position for presidential politics. What about universal tagging of farm animals? Dr. Stanley Greenspan talks about "Engaging Autism" . Then, Tim Hamilton says it ain't Arabs and Ethanol driving up gas prices. Guess who?
Direct download: mickelson-2006-04-21.mp3
Category:podcasts -- posted at: 9:07am CDT


text:
Practical - Index > Urban Wildlife > Wild Animals
Invasive Species Could be a Good Thing
printer friendly, larger print version
Some Researchers Wonder if Invasive Species Could be a Good Thing
Daily Grist, September 10, 2008
Could invasive species' bad reputation be undeserved? Bucking conventional wisdom, new research suggests that if exotic species aren't predators of natives, competition by nonnative species can actually improve biodiversity. A recent study in the Proceedings of the National Academy of Sciences notes that just three of New Zealand's 2,065 native plants have gone extinct, despite introduction of 22,000 nonnative plant species. "The overall pattern almost always is that there's some net increase in diversity," says researcher James Brown. "That seems to be because these communities of species don't completely fill all the niches. The exotics can fit in there." Critics point out that historical movement by invasive species pales in comparison to the estimated 7,000 species now schlepped to a new place by humans every day. "If you pour on more species, you don't just increase the probability that one is going to arrive that's going to have a high impact," says researcher Anthon y Riccardi. "You also get the possibility of some species that triggers a change in the rules of existence."
Fair Use Notice and Disclaimer
Send questions or comments about this web site to Ann Berlin, [email protected]


text:
Book Cover
V&A Illustration Awards 2013: Published Category - Book Cover
Book Cover Illustration Award Winner
Pietari Posti (represented by Début Art)
Cover for Swallows and Amazons by Arthur Ransome
Published by Vintage, London, 2012
Exploring the great outdoors is a central theme in Arthur Ransome's 'Swallows and Amazons' series of books, and Posti celebrates this gloriously in his illustrations, using a bold graphic treatment to give a 1930s spirit to the covers without them feeling outdated. The limited colour palette of bright orange and fresh blues helps unite the series while giving enough scope to make each cover unique.
Posti gained a degree in graphic design from Lahti University in Finland before moving to Barcelona where he works as an illustrator.
The Judges loved the strong use of colour and shape in Posti's work and the way this created a dynamic visual theme throughout the series of books.
Shortlisted entrants
- Matt Broughton for Dr No (Vintage)
- Alexis Deacon for Soonchild (Walker Books)
- Mick Wiggins for The Boy in the Striped Pyjamas (Vintage)
The V&A Illustration Awards is supported by the Enid Linder Foundation