Hacking #scalasbt with @gkossakowski on @WarszawScaLa meetup in @javeo_eu

It’s amazing how much I could learn hacking with so many clever Scala developers in one room during 2,5-hour meetup of @WarszawScaLa. Today was the day of #Scalania 22 during which Grzegorz Kossakowski @gkossakowski from Typesafe explained the changes needed to get rid of blank lines found in *.sbt build files in sbt. Thanks so much @javeo_eu for the food and venue. Many thanks Grzegorz for leading the meetup. Thanks the other Scala developers for the atmosphere.

Scalania 22  with Grzegorz

As the result of the Scala hackathon we created a change that’s the following snippet (that ultimately may become part of sbt.EvaluateConfigurations object):

def splitExpressions(lines: Seq[String]): (Seq[(String, Int)], Seq[(String, LineRange)]) =
{
  import scala.reflect.runtime._
  val cm = universe.runtimeMirror(getClass.getClassLoader)
  import scala.tools.reflect.ToolBox
  val tb = cm.mkToolBox(scala.tools.reflect.mkSilentFrontEnd(), "-Yrangepos")
  val buildSbt = lines.mkString
  val parsed = tb.parse(buildSbt)
  val b = parsed.asInstanceOf[scala language=".reflect.internal.Trees#Block"][/scala]
  val t = b.stats :+ b.expr
  // val s = t.flatMap(e => buildSbt.substring(e.pos.start, e.pos.end)).mkString
  (Seq.empty, Seq.empty)
}

It’s surely going to take more time to polish the changes until it’s merged to sbt however the meetup showed us how much we can hack together when the topic under discussion is well-presented and the meeting led by highly-skilled developers. Kudos to Grzegorz for leading the meetup! I can’t wait to the next Scala shackathons.

Languages , , Leave a comment

@gkossakowski on @WarszawScaLa about how to patch #scalasbt

What a fabulous @WarszawScaLa meetup! Grzegorz Kossakowski @gkossakowski has explained us the reasons behind the empty lines in build.sbt files in sbt and how to fix them with Scala’s parser!

It’s not the first time when we hosted a meetup with Grzegorz in which I was enormously enlightened by his understanding of the internals of Scala. With his changes to the incremental compiler for sbt he had so much exposure to sbt that having him on our meetups makes them so fruitful. We’re receiving answers from the top-notch Scala hacker!

This time we were discussing the (in)famous blank lines: why, what do they do and can we make them a happy memory of the past? As the result we’re going to host a mini Scala hackathon in two weeks in which we’re going to hack the changes needed for the issue to go away (or at the very least an action plan to address the issue). That’s going to be our first Scala hack-a-thon in the group that should give us experience in hosting larger ones for other challenging issues in Scala tools. We’re not going to be limited to sbt only (yet that’s where we’ve got quite impressive bunch of people who know about sbt quite enough - @gkossakowski from Typesafe, @lpiepiora, @jozwikandrzej and @jaceklaskowski). I know about people’s wishes to hack the other well-known tools like Akka, Spray, Play to name a few.

I’m sure I’m going to say what the Scala community in Warszawa, Poland is saying – with Grzegorz we’re going to make the change in Scala! And it’s going to be soon. Stay tuned!

Thanks @javeo_eu for offering us the space for the meetups, Grzegorz for the efforts to shorten the time to dig deeper into Scala, and the Scala community in Poland for the environment to have such ideas flourish! I’m deeply indebted to you for being part of the group. Thanks!

See you in two weeks during the mini-Scala-thon. That’s gonna be hacking fun! Follow us on @WarszawScaLa twitter to get notified about our meetups or join the WarszawScaLa User Group meetup.

Languages , Leave a comment

@WarszawaJUG meetup about #Java8 and later celebrating #Scala 2.11

The idea of a series of 5-minute talks about #Java8 worked so well today during @WarszawaJUG meetup.

It all started at 18:15 and finished at 20:00 for me as there was another get-together to celebrate the release of #Scala 2.11. I’d known that the short talks worked well in the past and was curious how much I could learn about the latest release of Java 8 from the speakers. The diversity was one of the many reasons I attended the meetup and am going to do so more often when the flash-talks are organised.

I listened to a talk about java.time by Tomasz Nurkiewicz, JSR 356 Java API for WebSocket by Andrzej Golawski, the latest changes in Map by Michal Lewandowski, Java 8 on Android by Krzysztof Siejkowski, java.util.stream by Pawel Szklarz, Optional by Piotr Trzpil, HashMap’s performance improvements in Java 8 by Tomasz Nurkiewicz and JSR 352 Batch Applications by Krzysztof Miksa.

I’m deeply sorry for asking so many questions, but the topics were so interesting that I couldn’t resist learning more.

The number of the flash-talks would attract many hard-core, full-blown Java conferences, but it would not be able to attend all of them when they’re 30- or 45-minute presentations given time constraints. With 5 minutes each I’d an excellent introduction to the many latest additions in Java 8 and Java EE 7. That’s what I liked the most about the meetup.

I enjoyed hanging out with people during and after the meetup. There were many people from Java EE 7, Java 8, Android and Scala camps. Many people share their interests between the areas and it’s no surprise to have seen so many people in the room as the topics were very well selected to attract attention. Being able to listen to the superb speaker line-up talking about the many interesting things in Java space is rarely possible. And all in my town! I could simply not miss the meetup!

After the meetup, I hung out with around 20 people who celebrated the release of Scala 2.11 as well as to continue talking about future project ideas with what we could learn during the meeting. Very lovely atmosphere. Wish you were with us. It’s the meeting I surely never forget that gave me a fast-paced introduction to Java 8. Thanks.

Languages , , Leave a comment

Getting into Akka (and other Scala open source projects) by sbt

sbt once simple is Scala now (and simple, too?)

Once I reached a certain level of confidence in my understanding of sbt, I’ve looked around for open source projects that use sbt as their build tool in order to get more insight on how much we could help each other. I’ve found quite a few projects that made me sad how far their builds are from what I’ve been learning about sbt for the past months. That is not to say it’s these projects’ fault. Quite the contrary, sbt was once meant to be simple (I kept hearing it here and there for quite some time before I jumped on the sbt bandwagon), however expectations seemed to have been too high on both sides.

It should come as no surprise that people are bashing sbt for its name that once meant to have reflected simplicity (as in “simple build tool”), but finally got touted as THE “Scala build tool” to better reflect its focus on Scala as the build language (that might be a reason for losing sight of simplicity during the “transformation” to Scala as the language is far from simple for some). I think it needs to change and begs for more effort from the sbt community.

As Josh Suereth has said during his talk about sbt.next – “Lot of investments going on in the documentation.” That’s quite too often a sparse resource.

Once burnt, twice shy?

Given how much sbt has changed with 0.13 and the plans ahead, it’s now the sbt community’s turn to take the stage and do the due diligence which is to help these open source projects getting better in their use of sbt (that should ultimately help both sides – the sbt community as a whole with more appreciation from the projects for how much their builds got easier with sbt). sbt 0.12.x and previous releases should be deemed highly poisonous with sbt 0.13.x the recipe.

Let’s treat it a call for action for the sbt community (or we’re going to end up as endangered species very soon with our hope and love for sbt). I think it’s about time!

Akka and the sbt build

Konrad Malawski has recently joined the Akka team (that with Grzegorz Kossakowski gives two Poles in Typesafe! Woohoo!), and I decided to celebrate the (not-so-small) change in Konrad’s career by embracing Akka in my tooling. I’m sure Konrad will like it (don’t you?)

I usually get myself engaged in an open source project by the sources (starting with compilation and reviewing the docs) and books (if they’re available). Akka was no exception and since I’m interested in sbt I couldn’t resist doing both – reviewing the Akka sources with their sbt build as the first gig. I’ve also got three books about Akka on my shelf - Akka Concurrency, Effective Akka, and Developing an Akka Edge - and there are quite a few coming (to the press or my shelf) - Akka in Action and Akka Essentials (let me know if I’ve missed any).

To make the story short – there’s room for improvement in Akka build- and documentation-wise (which again should come as no surprise as it’s a sort of fate of open source projects that usually focus on the code with community and documentation as a second thought). I know far too many people who’d like to get into Scala and one of the big open source projects, and think with Konrad aboard, Akka might be a good fit (and since there’s the sbt build they’ll learn the tool, too).

See you on GitHub!

Frameworks, Languages, Tools , , Leave a comment

Comments about sbt 1.0 – The Interactive Build Tool by Josh Suereth

There’s a bunch of video recordings from the NE Scala 2014 and I couldn’t resist to comment on Sbt 1.0 – The Interactive Build Tool by Josh Suereth. It’s 23 minutes about what’s coming in sbt 1.0 and the future of sbt.next.

Josh is an excellent speaker and he’s the product owner of sbt at Typesafe so he’s leading the team who develops sbt. All in all, who else could have presented the vision of the team about sbt than Josh?! You gotta watch the video since it’s very concise.

The video starts with a wide smile of Josh when he’s asking about people’s feelings towards sbt. He started his journey with sbt as a hater (!)

What’s the good about sbt – tilde ‘~’ (triggered builds) and plus ‘+’ (cross-versioned builds).

2:11 “We’re already an IDE…almost.”

Features of sbt (as pointed out by Josh during the presentation):

  • diverse plugin ecosystem.
  • the core of sbt is a type safe key-value map…which is really pluggable (when you think about it) and plugins benefited from it.
  • we use Scala as the build language that’s the main reason we (= sbt) exist in the Scala ecosystem. Josh smiles :-)
  • the default build which is an open source standard of how you should make an open source project and you can customise as needed

What’s bad about sbt – unsurprisingly the Number One is…Ivy – still the best conceptual model for dependencies – it beats the hell out of Maven – Josh wouldn’t go to Aether. Replacing Ivy is not an sbt 1.0 thing. The sbt team acknowledged that this is a problem. And pretty poor documentation. It’s still terse. Lot of investments going on in the documentation.

“The one thing people loved more than XML of Ant was the symbolic paths. So we got it right.”

“We improved the build format in sbt 0.13”

5:32 “The first API was all these applicative functors on tasks. We didn’t call it that because it still wasn’t cool. I think it’s ok here to call them applicative functors. I hope. Is it cool?” Josh smiles.

6:00 “The only thing that I’m noticing that’s kind of concern people don’t realise that this is still asynchronous. If you declare a dependency on key it’s not computed right where you wrote it – it’s actually computed asynchronously somewhere else.”

6:16 “We did a lot with Ivy – a lot of little stuff that you probably don’t notice besides I don’t have to delete the Ivy cache all the time, but only once in a while.”

6:33 “With 0.13 you’re seeing some new interesting stuff come out such as .previous to define incremental tasks.”

6:41 “Let’s talk about vision ’cause I don’t have much time on anything else.”

“We’re returning sbt into a server” and “We’re trying to clean up how plugins get implemented”.

And there’s more in the video, but you gotta watch it yourself to really appreciate what’s already available and coming up in 0.13.2 as well as 1.0. Have fun watching it!

Tools 2 Comments

Final thoughts on #ScalarConf = #Scala conference in Central #Europe

tl;dr It was the very first Scala-only conference in Poland. The conference was a massive success and with so many friends in one place and the good technical content with the incredible speaker’s line-up I wish it’d lasted longer for me. Kudos to the conference team, the speakers and the audience!

It’s hereby to thank SoftwareMill - the company that ran the conference for letting me sip the knowledge out of the best in the market in a very friendly and truly international atmosphere. I spoke to people from Netherlands, Italy (hey, @LuigiNoto), UK (hey, @propensive) and US (hey, @travisbrown and @xeno_by). I could talk to people I only had met on twitter or StackOverflow and managed to talk to so many Scalanians I barely had time to attend the talks.

I learnt a lot and got specially curious about pursuing my understanding of Scala macros that were today presented to implement…F#-like type providers. I really enjoyed the talk and am convinced to spend some time with them. Thanks Travis and Eugene for the excellent talk! I hope the talks were recorded so I can enjoy the presentation of yours few times more.

Jon Pretty is an mind-blowing speaker and when he speaks there’s so much fun as wisdom. He started his talk about Scala’s type system with few slides about yourself that themselves could’ve been the main theme. That was fun! Then, all of a sudden, he jumped in to Taylor series, addition, multiplication and derivative to explain Scala’s type constructors. That was the part where people were pretty much silent sitting in their chairs with open mouth while trying to swallow the enormous pill of math-heavy material. The comparison of Scala’s type constructors to an algebra with addition and multiplication was as much fun as mind-blowing. I heard a lot of “wows” everywhere! Thanks Jon for the excellent talk. I again wish the presentation was recorded so I can watch it again and again. See you soon on the Warszawa Scala User Group meetup!

The other presentations I could attend were Adam Warski about spray.io, Grzegorz Kubiak about Akka on Raspberry Pi, and Lukasz Kuczera with Scalaz—The Good, The Bad and The Ugly, a little bit of Tomek Nurkiewicz‘s The dark side of Scala, Konrad Malawski‘s Event sourcing with Akka-persistence and Grzegorz Kossakowski‘s Lambda implementation in Scala 2.11 and Java 8. I really hope they were all recorded as I’m gonna miss them otherwise.

I enjoyed the 30-minute chunks per presentation, that they were grouped to form 3-presentation one-by-one series and the breaks where I could talk to so many people who seem to fell in love with Scala in one place. The venue was enough to accommodate all the people and the location was in a lovely part of Warsaw - Mokotów Field – with green fields and trees (as if to remind us that Scala could bring many more green-field projects soon). A single track for the presentations and their variety turned Saturday into a long-lasting awesome experience that inspired me to learn Scala in ways I had not imagined would ever be possible.

Thanks all for the atmosphere and the topics! I really enjoyed the Scalar conference and am going to attend it next time.

Conferences 1 Comment

Go in Action from Manning and go installed

I’ve been hearing about the Go programming language here and there and when I’ve seen the freely available chapter from the upcoming book Go in Action from Manning I thought I’d give it a go. It’s an introductory material to Go and the why’s one could pick the language for the next project. What I liked about the chapter — yes, you’re reading it right, about the chapter not the language — were the questions to answer before picking a language, which in this case is Go. If a language wants to stand out it either has to offer a perfect implementation of an already-available-somewhere-but-not-so-elegantly-implemented feature or find its niche and hence face new challenges that lead to new criteria for a language. I have never considered quite a few before, and they do point out useful language features. It could only be for the additional features of how to select a language for a project that the chapter is worth your time.

The free chapter 1 “Introducting Go” is available at http://www.manning.com/ketelsen/ – a very useful and highly recommended reading! It seems so complete that I found no place to improve (except elaborating on Go’s features which I think is going to be a part of the other chapters). I thought it’s only about Go’s features without showing an example program, but section 1.3 “Hello, Go” does that — it offers the feel of Go by seeing a sample in action. It’s the hello.go from the website http://golang.org/, though.

Main points of the chapter and hence Go — some are exact copies of the sentences from the book:

  • Computers evolved yet programming languages not much
  • even your mobile phone is now smartphone with more cores than computers few years back
  • software developed by multiple teams spread around the globe
  • sharing code in Go is a built-in feature (whatever it means — I dunno)
  • use all cores with ease in Go
  • compilation in Go is lightning fast — you might not notice it at all
  • every programming language comes with a bunch of tradeoffs
  • static vs dynamic languages — a choice to make when picking a programming language
  • dynamic language suited for scripting
  • can’t verify the data in code is what’s on input
  • more code in dynamic language needs more tests (to verify correctness)
  • static languages give type safety yet can frustrate with repetition
  • productivity killer = code, compile, test…lather, rinse, repeat
  • deploying compiled code is a breeze
  • we can do better with the benefits of dynamic and interpreted languages with the speed and safety of static and compiled languages
  • passing thought to concurrency?
  • Ruby and Python use Global Interpreter Lock to ensure thread-safety and mitigate race-conditions => reducing performance due to one thread of execution
  • Java has concurrency primitives and often require tons of boilerplate for concurrent applications
  • We need a language with concurrency as a first-class citizen
  • a compelling feature of a language = how much done without using external libraries
  • hard to do much beyond simple text manipulation
  • Go a language with all the heavy lifting done?
  • developers make uncomfortable choice between rapid development and performance
  • fast execution vs rapid development? Can we have both? Go?
  • Go is a high performance language with development fast
  • Go has a concise syntax with very few keywords — not much to remember
  • Built-in concurrency features of Go — software scales to use resources available — one of the strongest feature of Go
  • Go uses a simple and effective type system
  • Go has a modern garbage collector — no need to manage memory yourself
  • Go uses a mart compiler and simplified dependency resolution algorithms
  • Go compiler look at the libraries you directly include
  • Many Go apps compile under a second
  • Entire Go source tree compiles under twenty secs
  • Goroutines are like threads but use less memory and less code to implement
  • Channels are typed memory queues to send messages between gorountines
  • Go facilities a model with data being sent to goroutines
  • Goroutines are functions that run concurrently
  • Many goroutines execute on a single thread
  • Writing a web server with web requests handled simultaneously? Use Go’s goroutines and net/http library
  • inbound requests processed on goroutine
  • Go runtime schedules execution of goroutines from a configurable pool of threads
  • Less development effort to achieve more
  • Goroutines run on one or more system threads
  • Keyword go to launch a function as a goroutine
  • It’s not uncommon to spawn tens of thousands of goroutines
  • Channels as a pipeline to enable safe data exchange between goroutines
  • channels as a shared memory access
  • channels enforce a single goroutine modify shared data
  • goroutine has exclusive control of data it receives on channel
  • Flexible hierarchy-free type system in Go
  • Simplicity of Go’s type system
  • Go developers embed types for re-use in Composition design pattern
  • Your types in Go are composed of smaller types
  • You don’t need to declare you implement interface in Go — let the compiler figure that out from the code
  • Many interfaces in Go’s standard library are very small with only a few functions
  • Go has built-in types like int or string and user-defined ones.
  • Go’s user-defined types look and operate similarly to C’s struct
  • Types may declare methods
  • inheritance vs composition
  • Go interfaces model small behaviours
  • Interfaces express capabilities of type
  • Duck typing when a type offers specific set of capabilities without specifying interface implemented
  • if it quacks like a duck, then it can be a duck
  • In Go, when type has methods of interface without specifying it explicitly, it can be used anywhere the interface’s expected
  • Go’s interface typically represents a single action
  • Most common interface – io.Reader
  • Go’s interfaces are smaller and single-action mostly
  • Go makes interfaces fun, elegant, and flexible
  • Go programs are packages
  • import enables external code
  • fmt package to format and print data
  • main() function is an entry point of application
  • You can use Go right from the browser – Go Playground at http://play.golang.org
  • Go developers use Go Playground to share code ideas, test theories or debug their code
  • Go Playground to solicit help
  • Project Kiev

After having reading the book, I installed the Go binary distribution for Mac OS X from https://code.google.com/p/go/downloads/list. It takes few seconds to install.

jacek:~/sandbox/golang
$ cat hello.go
package main

import "fmt"

func main() {
  fmt.Printf("hello, world\n")
}

jacek:~/sandbox/golang
$ go run hello.go
hello, world
Languages 1 Comment

WarszawScaLa UG coding session = Scalania 13 in Javart

I’ve been publishing my sentiments on the coding sessions called scalania under WarszawScaLa User Group on my Polish blog, but the ideas that are inspired by or spring out of them are worth spreading to wider audience and hence this one is here, in English (hoping that new ones come up or current ones got improved here and there).

20140305_201337The coding session took place in Javart – a Polish software house that supports the Scala community in Warsaw, Poland offering their venue and food, drinks as well as access to Internet during the meetings. I’m so happy the group found so pleasant home for the sessions.

We’re streaming meetups on Google Hangouts on Air and there are usually few remote attendees in a session.

What I liked about today’s meeting was that the number of participants (8 people) made it a nice collaborative environment where we spent most of our time on two presentations about Lift and Scala as an alternative to bash, and discussing the future plans. We’re going to have a 1-day-long hackathon soon (!) There was too few coding challenges today, but since the people who made it to the meetup today were almost from the day 1 we could discuss where we’re heading and what we want to achieve in the future.

Before we closed the session, we did two exercises from S-99: Ninety-Nine Scala Problems - P03 and P13. It took as few minutes to solve them even though we did them during the past sessions.

As a closing assignment, I asked the attendees to explain the goal(s) of the method aggregate[B](z: B)(seqop: (B, A) ⇒ B, combop: (B, B) ⇒ B): B from the List type. I asked people not to read the scaladoc or googling for the answer, but rather guess the purpose of aggregate from the signature. We spent almost half an hour in Scala REPL to have a few working examples yet we couldn’t figure out why and where we’d need the method. It’s our home work and googling is strictly prohibited. It’s gonna be a mental challenge for me to have a complete understanding of the purpose of the aggregate method. Did you know the method before? What were the use cases? Please advise.

We’re meeting up in Javart and streaming online via Google Hangouts in two weeks and if you could drop by and explain the aggregate method WarszawScaLa UG would appreciate. Understanding of the method is not needed to attend the session, though. Feel invited.

Languages , Leave a comment

What a pleasant experience – reading Pro Git book in Readmill on Samsung Galaxy S3

I keep trying out different approaches to absorb knowledge. I’m on GitHub to learn git and get skilled in a new way of software development which I call social development with people and projects I would’ve never been part of otherwise. Same for StackOverflow or twitter - yes, you’re reading it right – twitter – that can be as inspiring and offering an unabridged wealth of (implicit “linked”) knowledge when used appropriately as time devastating and without purpose.

I must admit I couldn’t have gotten used to one thing that seem so prevalent – using the many different kinds of devices to read books, articles or simply browsing the web. I seemed to have lived with paper books for so long that I couldn’t have stopped reading them on paper. It was part of me. Even when I had ebooks I couldn’t simply read them in that format, but was printing them out and was walking with paper sheets – the books – everywhere. It was very tiresome.

It has all changed once I bought my first smartphone – Samsung Galaxy S2. Then few months with Apple iPad 2 and I promised myself that with Samsung Galaxy S3 I’m gonna give book reading on a smartphone a serious try. And so I did. Something clicked. I was testing different ebook readers and got curious about Readmill on Android.

That’s not much git in my team in Citi. I wish we moved to git already, but it’s something we will do one day. There’re few attempts to work it around and practical knowledge of git is in growing demand.

There’s the Pro Git book, written by Scott Chacon and published by Apress available in Readmill. I couldn’t resist giving it a read. The reading went so well that I think I nailed it down. I may have become a ebooks-reading-on-smartphone convert.

The book was one of the very few books I’ve read recently that so easily introduced me to the topic of using Git as a common end user as well as showing its internals so I could feel more comfortable with the tool later on. Narrative was engaging and it was hard to get bored or overwhelmed with details. The book seems to have showed all I needed to become git power user. Highly recommended reading!

“Next book?” you asked? Functional Programming in Scala by Paul Chiusano and Rúnar Bjarnason from Manning has just been updated in chapters 1-15 with more updates to 7-15 soon. That’s what’s on my reading plate now.

Tools Leave a comment

project and projects commands in sbt

While reviewing the source code of sbt, I stumbled upon sbt.CommandStrings. I’d swear I’d been looking at the class so many times yet it was only today when I noticed how powerful the commands – projects and project – are. Even the official documentation of sbt is almost silent on the commands.

I simply couldn’t resist let the #scala twitterland know how mind-boggling the news was to me.

tweet-about-sbt-project-command_2014-01-06_2203

So to let you gain a little wisdom about sbt, I’ll let their detailed help speak for themselves.

[root]> help project
project

  Displays the name of the current project.

project name

  Changes to the project with the provided name.
  This command fails if there is no project with the given name.

project {uri}

  Changes to the root project in the build defined by `uri`.
  `uri` must have already been declared as part of the build, such as with Project.dependsOn.

project {uri}name

  Changes to the project `name` in the build defined by `uri`.
  `uri` must have already been declared as part of the build, such as with Project.dependsOn.

project /

  Changes to the initial project.

project ..

  Changes to the parent project of the current project.
  If there is no parent project, the current project is unchanged.

  Use n+1 dots to change to the nth parent.
  For example, 'project ....' is equivalent to three consecutive 'project ..' commands.

[root]> help projects
projects
  List the names of available builds and the projects defined in those builds.

projects add <URI>+
  Adds the builds at the provided URIs to this session.
  These builds may be selected using the project command.
  Alternatively, tasks from these builds may be run using the explicit syntax {URI}project/task

projects remove <URI>+
  Removes extra builds from this session.
  Builds explicitly listed in the build definition are not affected by this command.

Questions? Comments? See you on StackOverflow.

Languages, Tools , Leave a comment