More Scala

I’ve been doing a ton of reading on Scala and jotting down some observations on what I’ve learned. Some of it is simple but not immediately obvious; some of it is those places where the reading left a desire for more information. Hopefully this will save some time for others trying to pick this up. If not, at least it will be a reference for me.

Some notes from going through Scala School

  • The relationship between partial application and currying is still not totally clear to me; it seems like you curry to create a series of functions then partially apply them in sequence to achieve the full result.
  • The differences between methods and functions are unclear; the tutorial assures me that’s okay but I don’t like it. It seems that functions are strictly things that inherit from function.
  • Type aliases seem like a great way to build new types that imply a collection of existing types.
    • type SocketFactory = SocketAddress => Socket
  • I need a better understanding of objects in scala. Not the normal OO object, the Scala object seems to be closer to the singleton pattern or a static.
  • Guard matching syntax seems interesting, e.g.,
    • case i if i == 1 => “one”
    • I wonder what syntax you can use in that expression. Hopefully function calls are legal.
  • Tuple Accessors are 1 base not 0 based.
  • Destructuring bindings to decompose tuples is awesome, they let you break down tuples quickly and neatly.
    • val (char, digit) = tuple
  • I’m a big fan of GetOrElse on Option, very concise and clear.
  • Partial functions are another idea I haven’t seen before.
    • It is a function that knows it can only produce results for a subset of inputs.
    • They’re the underlying implementation in case statements which allows case statements to be used like functions!
    • Not sure what else I could do with them.
  • I think I’ve figured out F-bounded polymorphism, essentially you define that the generic type must implement the type you are defining. This is so that you can constrain the generic type to pass it into the base class.
  • Structural types look like duck typing but uses reflection so we should avoid using them. 😦
  • Manifests are compiler generated code to counter type erasure. I wonder how much code bloat this causes.
  • Found the DecorateAsJava trait, nice usage of implicit conversions to make interop with java easier.
  • Spies seem like a nice feature of the testing framework. Seems like you could build inconsistent behavior in an object like a list that says it has some number of objects but doesn’t have an entry at that point.
  • The section on traits did not make the mixin functionality clear. You can mixin a trait as part of the constructor of an object not just as part of the class declaration! That’s not quite C# extension methods but close enough for some usages.
    • Found implicit classes elsewhere that can be used almost exactly like extension methods.

Notes from Scala Exercises

  • The operator, ie fat arrow =>, shows as one character in some of the examples which is confusing.
    • Similar problems with the skinny arrow ->
  • Backticks in pattern matching allow matching against other variables.
    • def patternEquals(i: Int, j: Int) = j match {
       case `i` ⇒ true
       case _ ⇒ false
      }
  • There seems to be usages of implicits that work like extension methods, but you need more syntax.
    • class KoanIntWrapper(val original: Int) {
       def isOdd = original % 2 != 0
      }

      implicit def thisMethodNameIsIrrelevant(value: Int) = new KoanIntWrapper(value)
  • The section on for expressions did not really help my understanding.
    • val xValues = 1 to 4
      val yValues = 1 to 2
      val coordinates = for {
       x ← xValues
       y ← yValues
      } yield (x, y)
    • In this example it isn’t clear why the two lists are evaluated in any particular order.
  • Scala Fiddle was a great help for running some of the examples and being able to try some variations.
  • I’m not sure how I feel about the conversion between methods and operators where certain kinds of methods can be used as prefix/infix/unary operators. Having seen a C++ codebase with off operator implementations I realize the pain it can cause; maybe since you can name them however you want they’ll read better.

I ended up going through the Play Framework Tutorial as well since it’s part of the stack I’ll be using.

  • Looks a lot like ASP.Net MVC.
  • Session data signed to prevent tampering.
  • @With annotation and allowing composition of actions.
  • Twirl temples look a lot like razor templates except that you add dynamic elements in Scala not C#.
  • Play seems like it just composites together best practices from various other JVM libraries bringing together JPA, Twirl, Jackson, Akka, Guice, and logback.
  • The WithApplication class seems like a way to make building testable controllers easier.
  • Similarly with WithServer class will help test some fully remote calls.

Overall I’m feeling pretty psyched. At this point I feel pretty comfortable reading the sample code. The exercises were more about reading it and understanding it rather than writing your own code.

Since the language is so big I’m not sure which parts are where I should be focusing. I feel like I need to start building something with it at this point to understand how to decompose a class into traits. I’m not sure the Project Euler problems will supply the appropriate domain to try and build these more complex inheritance hierarchies. I’m also not certain if I’ll be building good Scala code or just mashing together different styles in a way that wouldn’t scale. Maybe Scalastyle can help with that, but the rules don’t seem to be the kind of thing I’m looking for.

I’m going to forge ahead with this list of Scala problems since I hope that being able to contrast my solutions with the provided ones will give me some level of feedback on what I’m doing. Then probably move into the Project Euler problems afterwards.

Starting Scala

I’m starting a new job soon which is going to be entirely Scala programming. I’m trying to dig in a little bit and get started with a leg up. I’m going to outline my basic plan here and post updates as time goes on. I’ve done a tiny bit of Scala before when learning some about Spark. I’ve done some Java work in the past as well so the ecosystem is a little bit familiar. So I’m not coming in from nothing.

The place I’m going to be working uses Macs so getting off of Windows seems like the right way to get started. I had previously used Eclipse when working on JVM based languages. The last time I had used Eclipse though it seemed like more had changed than was the same as I remembered. So I’m going to take a different tack this time and try IntelliJ. So the overall development environment is going to be an Ubuntu VM and use IntlliJ on it.

I plan to start with Scala School to make sure I’ve got all the basics down. Once I feel I’ve got that put together I’ll try Scala Exercises for some more guided exercises. Then I’m going to do some of the Project Euler problems I had done in F# since I understand the problems and can focus on learning the idiomatic Scala way of doing things.

I figure this should get me up to speed on Scala pretty quickly. We’ll see how well it goes.

ChatOps and ChatZero

Inbox Zero was always a concept I never fully understood the need for before I moved to a big company. You get some email every day and you read it, what’s the problem? Now that I’ve been in a big organization for a while, I think I understand the problem better: you eventually end up on email lists that are about things that are only tangential to what you do. I’m on one particular email list about communications from partners we integrate with; I’m not involved in those integrations at all, but can’t unsubscribe from the list. Inbox Zero both helps you stay focused on doing real work and makes sure you don’t miss anything important.

Chat and ChatOps has been replacing email usage across the industry, since it is an easier way to collaborate in real time and the chat histories make it easier to share information asynchronously. As ChatOps has picked up in my office I will get to the office and see there are hundreds of new messages spread across the roughly 20 channels I’m in. I used to read all of them every morning, but some of the channels had been getting chatty, which made it harder to keep up. I first dealt with this by muting or leaving channels that I was less interested in, though apparently leaving channels in Slack is considered bad etiquette in some circles. This hasn’t helped, since I keep getting involved in more and more channels, no matter how many I drop.

I had started skimming some of the channels I am in rather than really reading all of it. This helped keep up with the increased flow, but deciding which channels to skim was hard. I recently listened to Arrested DevOps talk about ChatOps, which was an interesting because they came from multiple different backgrounds and chat usage styles. They made a couple of suggestions, one of which was counterintuitive but has been working great for me since I’ve implemented it – make more channels, especially short-term channels for intense conversation. More channels helps keep the content of each channel more focused so instead of having four semi-related conversations in one channel, you have four channels each with one conversation. With each of those breakout conversations being linked as it moves out you can either go read it or skip it freely. One of the other great but more obvious suggestions was the use of dedicated update channels for notifications from automated systems.

The switch to chat from an email based system has been a great experience overall in my opinion, but it will take a while for all of the productive patterns of how to use chat to get established. The great part is that the Chat system is open and pluggable and not centrally controlled. This ability to innovate on how the platform works brings about hubot and all of the other bots and integrations that make ChatOps an amazing tool.

Agile Signalling

It seems like agile has become a signal in software development, particularly Scrum. Everyone feels the need to say that they’re up on how “things are done,” and being allegedly “agile” seems to be how they’ve decided to show it. From an executive perspective, to remain competitive in the hiring market, you must be “agile.” And indeed, the teams may be working in sprints and doing all of the prescribed activities, but they aren’t actual building software any differently than they were before they called themselves an “agile” organization.

I don’t mean here that an organization has truly implemented waterscrumfall where you have an agile cycle in the middle of a waterfall process, which I’ve never seen in person. Instead, you’ve taken how you worked before and rephrased everything in agile terminology without embracing agile theory. You don’t have releasable software at the end of an iteration; you still have a two-year roadmap where dates are promises inside and outside of the organization. You are still producing reams of documentation about software that may never exist. For every principle on the agile manifesto there are a myriad of ways that principle can be half-assed.

Scrum has a bad reputation in relation to half-assed implementations. I think part of it is the ubiquity of scrum offerings and commercially-available training where the sales pitch overpromises the results. Scrum is more accessible since, at first glance, it can just be interpreted as doing the same things you are doing now, just in smaller pieces. If the scrum implementation isn’t achieving it shows up in the retrospective. The team identifies their impediments but if they can’t deal with them it becomes an exercise in futility. If the organization doesn’t want to help resolve the impediments then the team’s morale can easily collapse.

Among the twelve principles of agile, I think there is one in particular that, if you follow it, best represents doing the right things (and can’t be half-assed cheaply). I think that the principle “Business people and developers must work together daily throughout the project” is the definitive signal of being truly agile in spirit. The daily interaction is a specific measurable objective that can be monitored.

From the developer’s point of view, this gets you answers to questions when you need to clarify intent. This helps the developers to understand why the product should be doing something and produce additional insights into what the product could do. This insight can be invaluable to the business people since it produces ideas of how the software can better meet objectives  through solutions that are not apparent to those looking at the problem from the outside. Even this benefit can be dwarfed from the morale benefit of everyone trusting everyone else to do their best.

Without the organization being wholly aligned in embracing agile theory, the business stakeholders would never have the incentive to put in the time investment to provide this level of involvement. The business stakeholders wouldn’t be inclined to put that sort of investment into the process practice if they don’t see the value. If they see the value of this one principle, they will hopefully understand the rest of the intertwined processes of the agile manifesto.

The signal that the strong businessperson-developer interaction sends is that the whole of agile practices are valued. Compare that to the signal of someone stating “we’re agile,” which just indicates that the speaker thinks you want to hear them say that. Usually those that say those things are doing some agile things, but the difference between a half-assed agile implementation and a  true one is the difference between night and day when you are working in it. By looking for the strong signal that the business stakeholder involvement represents, hopefully you can find those that are truly agile and weed out those who are just posing. It is true here that actions signal louder than words.