4 notes
Scala services at Tumblr (but you knew that already)

Scala services at Tumblr (but you knew that already)



4 notes

A panel of professional Scala users the ny-scala meetup

(Source: vimeo.com)



16 notes



8 notes



20 notes

The gist of it

Because you can’t put the Tabasco back into the bottle:

As my team navigated these waters, they would occasionally ask things like: “So this one guy says the only way to do this is with a bijective map on a semi-algebra, whatever the hell that is, and this other guy says to use a library which doesn’t have docs and didn’t exist until last week and that he wrote. The first guy and the second guy seem to hate each other. What’s the Scala way of sending an HTTP request to a server?” We had some patchwork code where idioms which had been heartily recommended and then hotly criticized on Stack Overflow threads were tried out, but at some point a best practice emerged: ignore the community entirely.

I feel I have a small part in this drama. That is, there is a Scala library for sending HTTP requests to a server that doesn’t use bijective maps (unless this is something one can do by accident) and that did exist last week, and last year, and the year before.

I understand why using Dispatch is out of the question for some people and I have no quarrel with them, or their reasons. But it is a part of the Scala HTTP story.

It goes back to my first open source project, in Java. I did some minor HTTP client work in it and was attracted by the idea of doing it far more expressively in Scala. This became Dispatch. I rewrote it about three times in the first year, and then again a while later. In that span I learned Scala, which was also the point.

My attitude with open source was that you should write whatever you want. You are working for yourself; anything that others get is gravy.

So I wrote an uncompromising interface for the way I wanted to code HTTP interaction, figuring that it would please some fellow travelers. And indeed, it has. The open praise for Dispatch is as effusive as it is rare. This was the plan all along.

What I wasn’t counting on was how much it would weigh down on me, again over the years, to have my humble offering relentlessly (and pointlessly, by the way) castigated by a rotating cast of characters. That part has sucked.

And I can’t help wondering, over the years and as Dispatch’s profile has increased (mostly by virtue of being “the maintained” Scala HTTP library), how things would have worked out if I hadn’t participated. Surely someone else would have filled the gap. But then, people have written alternatives–they just haven’t stood by them. No one can say if, in the absence of Dispatch, a more widely palatable HTTP interface would have been both written and maintained.

My hunch is, probably not. There are not that many fleshed out and maintained libraries in our community, in total. Because we are still small. Without one for HTTP everyone would just get by, the same way that many people using Scala get by without using a Scala HTTP library as it is.

If I were to do it all over again, knowing what I know now about software communities, I would do it differently. I would make a more conventional API because that would have been of greater benefit to the community. Whether that’s because most people are wrong, or I’m wrong, is beside the point. But it would be a little sad, because then some of us wouldn’t have had exactly the interface we wanted.

This commenter, reacting to a gloating post that embeds Coda’s leaked letter, explains Dispatch’s oddness as well as I ever have:

… the farthest we get from the world of conventional languages is using the Dispatch library to make HTTP calls as a client. This particular library takes advantage of Scala’s lack of operators, and ability to use operator-like method names to write some interesting things that would be.a.chain.of.dot.invocations.in most other OO languages.

I particularly like his way of referring to Scala’s “operator overloading” (necessary scare quotes, as it is nothing of the kind) because the why and the how of the language feature are right there.

Anyway, I suspect the actual state of HTTP libraries on Scala was never the point. Just ask yourself the same question for other programming languages.

What’s the Python (2.x) way of sending HTTP requests to a server? There are several different interfaces in the core library alone. Usually when coding something I’ll start with the highest level, easiest one, only to discover later that it can’t do the particular weird (or not so weird) thing I need, and I have to switch to a lower level one. This involves a little bit of rewriting because the interfaces are pretty different.

Or dare we ask: What’s the Java way of sending an HTTP request to a server? Back in the HttpClient 3 days most in-the-know people would have answered with that library. But then something funny happened. For version 4 they decided to do a total rewrite to address some fundamental issues in the library and also to better adhere to their ideals of software design. Problem was, it resulted in much more client code than the previous version, and a lot of users decided never to migrate. Correctness by some standard was achieved, but the user base became disenchanted and drifted away. (Sound familiar?)

So I don’t think the point could be that Scala is uniquely devoid of one-size-fits-all solutions, or uniquely subject to disagreement over the best idioms. Every language struggles with these, to varying degrees. Surely no one coming from Java has forgotten, already, the “over-architecting” that is widely derided outside of Java. Surely if the worst thing a troll can compare Scala to is J2EE, that tells us something. And let’s not get started on the upside-down church of IoC, which surprisingly held sway over a good chuck of the world’s most stolid software development shops.

The real difference from Scala is, if you ask in a forum what is the Python or Java way of sending a request to a server, you may get different answers but you won’t get people savaging each other or the choices presented. Usually. Within those languages, which also happen to be a lot older than Scala, there are pools of consensus around evidently useful libraries and people aren’t in the habit of declaring any of them as strictly invalid. It must be nice.

~~~

But I have not really reacted to the letter as much as contextualized it. Around myself, rather selfishly. This is what people do in blogs.

What I think is that Coda’s team’s earlier withdrawal from the Scala community–a decision to ignore it entirely–guaranteed its eventual withdrawal from the thing the community was about. Scala.

I suggest that this is true in general. People who don’t socialize with any of their co-workers will leave a job. People who don’t make friends in a new town will move “back home”. We’re social animals and we can’t function otherwise.

We’re also practical animals, and going it alone on a software platform doesn’t make a whole hell of a lot of sense.

I agree with some of Coda’s feelings about the community. I have never really participated in any of the general Scala mailing lists, if that gives you any idea. But it’s nothing particular to Scala; I’ve seen the same behavior on any technical list that gets large enough. Actually, I saw the same behavior in high school, except it was dumb people beating up smart people (mostly). On technical lists it’s the really smart people beating up the smart people. It’s the same urge to dominate, or simply to exalt oneself.

Building a healthy community in Scala is harder because the language draws in people from the top tier of software and computer science. It’s a personality match made in hell (even though we’re all such fabulous individuals), and we see the predictable results every day. We can try to carve out little safe spaces, but ultimately, the internet defies segmentation. You can’t avoid finding what is wrong on the internet, and you can’t sleep until you said so. (And then, you still can’t sleep, because you are QAing your arguments in your head–or maybe that’s just me.)

ny-scala

I’ve decided to devote my time to a local, face-to-face Scala community which I see as the best antidote to this poison. Some of the nastiest nerds become lambs when they meet in person. And the really cool thing is, the civility carries into the virtual realm. (Did I just say “virtual realm”? It’s getting late here.) If you see people often enough, and know that you’ll see them again pretty soon, calling them a retard on some forum becomes decidedly less gratifying.

Coda was kind enough not to advise others what language to use and I’ll return the favor. I have no idea what his team should do and it’s none of my business. But for everyone, and any technology, participating in the community is a prerequisite to long term success. If things are not working out people-wise, things are not going to work out period.

We’re doing our best to make this thing better. Care to join?



12 notes



18 notes
“The format is simple. We’ll occupy Meetup HQ and hack on programming projects related to the movement, whether they be our own creations, improvements to Occupy Together’s global hub and directory or banding together to knock out a task for the NYCGA or FLO/Internet Working group.”

Occupy Together Meetup - New York, NY | Oct 14, 2011 - Meetup



15 notes



9 notes



3 notes

Community Coding Workshop in Scala

This past month we had our most successful NY Scala Meetup yet. And we didn’t have any fancy speakers or mind blowing presentations. We didn’t even have talks at all.

Instead, we built something. In the course of two hours we built a working image processing service with a web front-end. It stores images in MongoDB and transforms them using its own interface to Image Magick or with the Java image manipulation primitives.

In preparation for the meetup, we asked development team leaders to volunteer on the event planning page and made them into “event hosts”. Then we created the repository in our group’s github organization and put in some stub code for the different teams.

The idea with the stub code was to have a starting point for each of the different teams. There was one source module for each team, and interfaces between the different modules were already defined. This allowed teams to start working right away and test their changes against the stub code in the other modules.

It was up to the leaders to figure out how to run their teams based on the particular tasks and Scala experience of the team members. They all came up with different, successful methods.

The Mongo team had the best setup for instruction, with their own projector in the front of the room. This allowed everyone to see the changes that Brendan McAdams was making as he talked about them.

The Image Magick team had many different people pushing code. Jorge Ortiz led them to produce an impressive abstraction for working with the external process, given the extreme time constraints.

Chris League’s team slayed the BufferedImage dragon as he directed them from a relaxed position. (Just kidding, Chris! Correct me in the comments.)

The API team had a lot of people with web API experience and ideas about the best interface to build; Chris Lewis worked them through the options for realizing those interfaces in Unfiltered.

And finally, Doug Tangren’s web front end team made everything actually work in a browser. For the first half hour or so he taught them the fundamentals of Unfiltered, then they raced to integrate everything with the API team.

After the allotted time expired (and maybe a few minutes more), we had demos. Each team lead explained what they had produced and whatever interesting Scala-isms they had encountered on the way.

While different groups were demoing, Doug was working furiously off stage to get all the different parts working together. It was getting late, the pizza was cold, the beer was… beer. Jorge and I started ad libbing about god knows what Scala topic. I was prepared to say that just having the parts work separately was a real accomplishment.

But at the last minute Doug made that face people make when something compiles and actually works too, so we plugged him into the projector and celebrated making something that works, together.

When we say this was the most successful meetup, it’s not just that we got a great feeling while we were there. The reviews posted to the site were excellent, and moving. It says a lot about what people are looking for in Scala, and programing in general.

This meetup really reignited my enthusiasm for the language and this community. … There is nothing more empowering then being able to build something in a new language.

I am really happy with events like this because having a semi structured group project or goal is one of the best ways to learn as a beginner.

Outstanding meetup. Smart, friendly people who were very willing to share their time.

We’ll be doing more of these, no doubt about it. But what we most hope to do by sharing this experience is encourage others to do the same thing. If you have a Scala meetup group, do this. It’s easier than you think.

If you don’t have a meetup group, start one. You will get members. People want to learn Scala, they just don’t know where to begin. Give them some space and a little direction–they will teach each other more than they could learn from a hundred dread monad blog posts.

Page 1 of 4

}