Here are a few questions I’ve been thinking about:
How should I express data or API?
How should the data be represented in Java or Scala?
How do I convert the data into wire formats such as JSON?
How do I evolve the data without breaking binary compatibility?
limitation of case class
The sealed trait and case class is the idiomatic way to represent datatypes in Scala, but it’s impossible to add fields in binary compatible way. Take for example a simple case class Greeting, and see how it would expand into a class and a companion object:
Gigahorse 0.2.0 is now released. The new change is that it abstracts over two backends. @alexdupre contributed migration from AHC 1.9 to AHC 2.0, which is based on Netty 4 in #12.
In addition, there’s now an experimental Akka HTTP support that I added. #15
Gigahorse 0.1.0 is now released. It is an HTTP client for Scala with Async Http Client underneath. Please see Gigahorse docs for the details. Here’s an example snippet to get the feel of the library.
scala>import gigahorse._
scala>import scala.concurrent._, duration._scala>Gigahorse.withHttp(Gigahorse.config){ http =>val r =Gigahorse.url("http://api.duckduckgo.com").get. addQueryString("q"->"1 + 1","format"->"json")val f = http.run(r,Gigahorse.asString andThen {_.take(60)})Await.result(f,120.seconds)}
There’s a “pattern” that I’ve been thinking about, which arises in some situation while persisting/serializing objects.
To motivate this, consider the following case class:
scala>caseclassUser(name:String, parents:List[User])defined classUserscala>val alice =User("Alice",Nil)alice:User=User(Alice,List())scala>val bob =User("Bob", alice ::Nil)bob:User=User(Bob,List(User(Alice,List())))scala>val charles =User("Charles", bob ::Nil)charles:User=User(Charles,List(User(Bob,List(User(Alice,List())))))scala>val users =List(alice, bob, charles)users:List[User]=List(User(Alice,List()),User(Bob,List(User(Alice,List()))),User(Charles,List(User(Bob,List(User(Alice,List()))))))
The important part is that it contains parents field, which contains a list of other users.
Now let’s say you want to turn users list of users into JSON.
This is part 3 on the topic of sjson-new. See also part 1 and part 2.
Within the sbt code base there are a few places where the persisted data is in the order of hundreds of megabytes that I suspect it becomes a performance bottleneck, especially on machines without an SSD drive.
Naturally, my first instinct was to start reading up on the encoding of Google Protocol Buffers to implement my own custom binary format.
Two months ago, I wrote about sjson-new. I was working on that again over the weekend, so here’s the update.
In the earlier post, I’ve introduced the family tree of JSON libraries in Scala ecosystem, the notion of backend independent, typeclass based JSON codec library. I concluded that we need some easy way of defining a custom codec for it to be usable.
roll your own shapeless
In between the April post and the last weekend, there were flatMap(Oslo) 2016 and Scala Days New York 2016. Unfortunately I wasn’t able to attend flatMap, but I was able to catch Daniel Spiewak’s “Roll Your Own Shapeless” talk in New York. The full flatMap version is available on vimeo, so I recommend you check it out.
I made a new Github organization called foundweekends for people who like coding in the weekends. If you want to join, or have project ideas ping me on twitter or come talk to us on Gitter.
One of the fun way of thinking about software projects is literary analysis. Instead of the actual source code, think of who wrote it when and why (what problem does it solve), and how it’s written (what influenced it).
Within the Scala ecosystem, not too many genre are as rich as the JSON libraries.
In December 2008, the first edition of Programming in Scala came out, which used JSON as an example in the context of parser combinator, and showed that JSON parser can be written in 10 lines of code:
This is a continuation from the sbt 1.0 roadmap that I wrote recently. In this post, I’m going to introduce a new implementation of sbt server. Please post on sbt-dev mailing list for feedback.
The motivation for sbt server is better IDE integration.
A build is a giant, mutable, shared, state, device. It’s called disk! The build works with disk. You cannot get away from disk.
The disk on your machine is fundamentally a stateful thing, and sbt can execute the tasks in parallel only because it has the full control of the effects. Any time you are running both sbt and an IDE, or you’re running multiple instances of sbt against the same build, sbt cannot guarantee the state of the build.
There’s been some discussions around sbt 1.0 lately, so here is a writeup to discuss it. This document is intended to be a mid-term mission statement. A refocus to get something out. Please post on sbt-dev mailing list for feedback.
For me (and for many of the 27 organizers, I imagine) ScalaMatsuri is a lifestyle. It’s true that there was a successful two-day conference in Tokyo with 550 participants. But for us the organizers, the preparation has been going on since February 28th, for 11 months. Despite the fact that my contribution was small, planning ScalaMatsuri 2016 was by far the most amount of involvement I’ve committed to. Through the course of planning months, there were many discussions over Slack, Hangouts, and occasionally even face-to-face. The fun part was coming up with the ideas together, and seeing them materialize. Sometimes, I was the one coming up with radical ideas that were being executed by someone else, while other times, it was the opposite case and I was getting my hands dirty.
For a flexible language like Scala, it’s useful to think of subset of the programming language, like your own personal Good Parts, and opinionated style guides.
setup
To try -Yno-lub, you can drop in the following sbt plugin to project/ynolub.sbt:
addSbtPlugin("com.eed3si9n"%"sbt-ynolub"%"0.2.0")
lub
When Scala’s type inferencer finds type A and type B to unify, it tries to calculate the lub (least upper bounds) of two types with regards to <:<. This process is sometimes called lubbing. Here are some of the examples:
On my way back from Uppsala, my mind wandered to a conversation I had with a collegue about the intuition of monads, which I pretty much butchered at the time. As I was mulling this over, it dawned on me.
monads are fractals
The above is a fractal called Sierpinski triangle, the only fractal I can remember to draw. Fractals are self-similar structure like the above triangle, in which the parts are similar to the whole (in this case exactly half the scale as parent triangle).
Monads are fractals. Given a monadic data structure, its values can be composed to form another value of the data structure. This is why it’s useful to programming, and this is why it occurrs in many situations.
Two days of #ScalaMatsuri ended as a huge success. But for the next year, I’m leaving ourselves a few homeworks to work on. As the title suggests, the next goal that we should aim for is universal access. In Scala language, universal access principle indicates the fact that both methods and fields can be accessed interchangeably from outside.
For a conference, I mean universal access to mean being more inclusive to various groups of people:
This year was the second Scala conference in Japan. We’ve changed the name to ScalaMatsuri, which means Scala festival in Japanese. 300 tickets sold out. With invited guests and free tickets for sponsors, there may have been even more people. The venue was at CyberAgent, which runs blog service and online ad services.
Day 1 kicked off with Martin’s (@ordersky) ‘Evolution of Scala.’ Many people were looking forward to see Martin, so I think it was full house from the get go. During all sessions that I attended, I was busy typing live text translation using my closed-captioning both from English to Japanese, and from Japanese to English along with other members @cbirchall, @cdepillabout, @okapies, and @oe_uia.
Personally, I don’t mind using SublimeText, which is my editor of choice for a while. But I’m also curious about commandline editors since many people taut their ability to code over the network. You could forward X or remote in using some other way and still use Sublime, but let’s see how if goes.
I started working on this Vim setup when I got a new MBP recently. Figured, I can try something new. So, this post is more of a personal memo written by a total newbie, which is what blogs are all about. caveat emptor. In general though, the configuration is mostly inspired by yuroyoro-san’s blog post from a couple years ago.
The need for regular expressions is real. Whenver I need to transform a set of text files it usually ends up with fumbling through the documentation of find command, zsh, and StackOverflow Perl questions. I would rather use Scala instead of muddling through Perl. It’s really the matter of my familiarity than anything else.
For example, I now have over a hundred reStructuredText files that I want to convert into markdown. I first tried pandoc, and it looked mostly ok. As I was going through the details, however, I noticed that many of the code literals were not converting over as formatted. This is because they were formatted using either single ticks or using Interpreted Text. Preprocessing the text with a series of regex replacements should work.
Woke up early yesterday, so I started skimming @xuwei_k’s override blog post. The topic was so intriguing, I got out of the bed and started translating it as the curious case of putting override modifier when overriding an abstract method in Scala. In there he describes the conundrum of providing the default instances to typeclasses by using Scalaz codebase as an example.
Here’s a simplified representation of the problem:
First, a quote from Programming in Scala, 2nd ed. p. 192:
Scala requires [override] modifier for all members that override a concrete member in a parent class. The modifier is optional if a member implements an abstract member with the same name.
In this post, we’ll discuss this “The modififier is optional.” Since overriding an existing method with implementation requires override modifier, and failure to do so would result to a compiler error, there’s not much to talk about for that case. We’ll focus on whether one should put override modifier or not in the case of overring an abtract method. I don’t think there’s going to be any difference in Scala version, but let’s assume the latest stable 2.10.3.
In this post, I will discuss the execution semantics and task sequencing in sbt 0.13. First we will cover the background, and then I will introduce a new experimental plugin sbt-sequential that adds sequential tasks.
background
Mark said:
The sbt model is to have your side effects be local to your task so that as long as dependencies are satisfied, the task can be executed whenever. The win is parallel by default and enabling faster builds in practice.
Purely object-oriented programming is defined to be:
programming with objects.
What’s an object?
It is an atom that can hold references to other objects, receive predefined list of messages, and send messages to other objects and itself; and nothing else. A message consists of a name and a list of reference to objects.
This is it. The wording is mine, but the idea is from Alan Kay (2003), the guy who coined the term object-oriented programming. Anything else is either not directly tied to oop or an implementation detail.
JavaScript existed since 1995 long before ‘JavaScript: The Good Parts’ (2008), jQuery (2006), and V8 (2008) happened. The interesting thing about Douglas Crockford’s ‘The Good Parts’ is that unlike the other additive work, it’s a book about subtracting features from the language.
I’ve been thinking about exploring a subset of Scala in a wonderland setting without the “real world” constraints such as Java familiarity and interoperability. If using Scala as an alternative Java is acceptable, why not try using it as an alternative functional programming language? Another point of this thought experiment is to see some of the duplicate constructs can be reduced. In this article, I’m not interested in finding out the idiomatic way, or calling something good or bad. I’m calling this The Flying Sandwich Parts (TFSP).
scopt is a little command line options parsing library.
Today, I’m releasing scopt 3.0. If you’re not interested in the implementation details, skip to the readme.
Around March 4th, 2010, I became a committer to scopt, a fork of Aaron Harnly’s scala-options that was written in 2008. I think I wanted to make a few changes around the usage text, key=value options, and argument list. Since then I’ve been fielding all the bug reports, including the request to publish the jar on scala-tools.org. On March 18, 2012, I forked the project again to scopt/scopt and released scopt 2.0.0 that added immutable parser.
Dispatch has been the de facto library to get to the Internet from Scala. To keep in step with the recent move towards non-blocking IO, @n8han rewrote the library as Reboot based on Async Http Client. This became Dispatch 0.9. Then Dispatch 0.10 came out to replace its own Promise type with the standarized SIP-14 Future.
As with Dispatch Classic, Reboot lets you write plugins to wrap around web APIs. In this post we’ll port a plugin from Classic to explore how it works.
This is a translation of 「モナドはメタファーではない」に関する補足 by Kenji Yoshida (@xuwei_k), one of the most active Scala bloggers in Japan covering wide range of topics from Play to Scalaz.
Daniel Spiewak’s Monads Are Not Metaphors was written about two and a half years ago, but seeing how its Japanese translation is still being tweeted and being bookmarked by 250 users on Hantena, its popularity doesn’t seem to cease. I just remembered something to note about the example code used in the post, which could be an unstylish critique, but I’m going to jot it down here. It’s an unstylish critique, because I’ll be digging into the part where the author likely knew from the beginning but omitted it intentionally for the sake of illustration. Also I’ll be using Scalaz in this post.
It’s been a month now, but on March 1, 2013 I flew to Japan to attend “Scala Conference in Japan 2013.” That’s the name of the conference.
from a podcast
One day (June 2, 2012), I was listening to Scala Types recorded at Scala Days 2012, and someone (turns out it’s @timperrett) said “I would love to see Scala Days in Asia. We had two in Europe now. It would be wicked to have it in China or Japan, or somewhere like that.” I relayed this info on twitter saying there’s an opportunity for the Scala community in Japan to invite the conference.
During the months of December, tech-savvy geeks in Japan take turns to post themed blog articles, known as the “Advent Calendar”. For last year’s Scala Advent Calendar 2011 I translated Eric Torreborre’s post covering The Essence of Iterator Pattern. It was somewhat of a calculated move, knowing Japanese fondness for functional programming articles. Another selfish motive was that some of the concept would seep in to my thickness as I was translating the post word by word. In hindsight, both goals were achieved handsomely thanks to the quality of both Jeremy Gibbons, Bruno Oliveira and Eric’s work. This seeped in knowledge was probably the secret sauce behind the learning Scalaz series that I worked on this year.
Unlike XML-based build tools sbt’s build definitions are written in Scala (for both .sbt and .scala). This means that once one gets over the hurdle of learning sbt’s concepts and operators, it doesn’t take much for build users to start writing sbt plugins.
I’ve ported a few from sbt 0.7 before, but I’ve also been writing some original ones recently that I’d like to share.
sbt-dirty-money
sbt-dirty-money is a plugin to clean Ivy cache somewhat selectively (anything that includes organization and name under ~/.ivy2/cache). It was such a simplistic 25-line implementation, but clean-cache and clean-local tasks continue to be useful for me.
treehugger is a library to write Scala source code programmatically. It’s also an implementation of Scala AST based on Reflection API, now available from github eed3si9n/treehugger.
Edit:
I’ve expanded this into a complete guide using awesome n8han/pamflet.
Scala the language is one of the most elegant, expressive, consistent, and pragmatic languages. From pattern matching to the uniform access principle, it got so many things right. And Scala the ecosystem and Scala the community only makes it better.
In Scala 2.9.1, locally declared implicits are preferred over imported ones. The problem is that the spec does not cover such behavior. My original hypothesis was that either I did not understand the spec correctly, or the spec was wrong. Based on the assumptions, I set out to explore the implicits resolution precedence last week. Like MythBusters say, the best kind of result is when you get something totally unexpected. It turns out that both of the hypotheses were wrong.
Northeast Scala Symposium 2012 is coming up in a few months, but I want to revisit a talk from this year’s nescala to wrap up 2011. One after the other, nescala had amazingly high quality of talks. You can check them all out here. With Daniel’s Functional Data Structure and Jonas’s Akka each having an hour-long key notes, the symposium left an impression on me that actors and FP are two major forces within Scala community. (Paul declaring that sending messages to actors is not referentially transparent was a hint too, I guess) There were also earlier signs of how the year turned out, like Mark’s sbt 0.9 presentation and Nermin’s Scala performance consideration. One talk that stood out in terms of immediate impact to change my code was Josh’s talk: Implicits without the import tax: How to make clean APIs with implicits.
When the original version was published on 06/19/2011, the motive for writing this guide was to aid the effort of moving people over to sbt 0.10 from 0.7, inspired by Mark’s sbt 0.10 demos that I was able to see live (first at northeast scala, and second at scala days 2011). At the time, the plugins were considered to be a major roadblock to the migration, since build users can’t move to 0.10 without the plugins. So my strategy was to port the plugins myself if they weren’t there, ask questions on the mailing list when I get stuck, and write up the results. I’ve gotten many positive feedbacks, and it’s helped people get on to 0.10. However, as it turns out, my understanding of sbt 0.10 wasn’t always complete, and downright wrong and misleading at times. I take responsibility of my writing. Instead of leaving old contents in, I’ve decided to push it into github, make a new version and move on. The most up-to-date knowledge of writing plugins is compiled in Plugins Best Practices written mostly by Brian and Josh, and a tiny section by me.
Let’s talk about testing. Once you write a plugin, it turns into a long-term thing. To keep adding new features (or to keep fixing bugs), writing tests makes sense. But how does one go about testing a plugin to a build tool? We fly, of course.
scripted test framework
sbt comes with scripted test framework, which let’s you script a build scenario. It was written to test sbt itself on complex scenarios such as change detection and partial compilation:
I wish there was a common super trait for various future implementations in the standard library, so I can express the concept without tying the code to a specific platform stack. I am not sure if there are others who feel the same, but I think it would be useful for library authors. That’s my motivation of writing sff4s.
what is future?
You’ve probably come across the notion before but let’s go over it quickly. A future value (also known as promise) represents an incomplete calculation.
I’ve tried other IDEs for Scala, but always ended up going back to TextMate. As I am getting on the IntelliJ IDEA wagon, I’ve made a Twilight theme to make the ride smoother.
.sbt build definition
sbt is a build tool for Scala and Java projects that aims to do the basics well.
sbt is a build tool for Scala and Java projects that aims to do the basics well.
.sbt build definition
sbt is a build tool for Scala and Java projects that aims to do the basics well.
sbt is a build tool for Scala and Java projects that aims to do the basics well.
.sbt build definition
sbt is a build tool for Scala and Java projects that aims to do the basics well.
sbt is a build tool for Scala and Java projects that aims to do the basics well.
