Disqus - Latest Comments for softprops

Re: AWS Lambda — compare coldstart time with different languages, memory and code sizes

softprops — Sat, 12 May 2018 15:42:09 -0000

There's a typo in "Python has ridiculously low codstart time" I think that's supposed to be "Python has ridiculously low coldstart time"

Re: Karol Kuczmarski's Blog – Unfolding a Stream of paginated items

softprops — Wed, 31 Jan 2018 08:57:19 -0000

Nice write up. Unfold has been my go-to for pagination in API clients. Here a few more examples. One for GitHub https://github.com/softprop... and one for Travis ci https://github.com/softprop...

Re: Neon: Node + Rust = 💖

softprops — Thu, 24 Dec 2015 23:37:23 -0000

Very nice post

Re: sbt-logo proposal

softprops — Sat, 24 Aug 2013 09:37:54 -0000

Awesome start. Few suggestions. How about not tilting the b. I think it looks cleaner upright. Sbt builds more than scala so I'd steer clear of a scala build tool. How about posting the svg src on github and managing this there?

Re: Scala: the flying sandwich parts

softprops — Fri, 21 Jun 2013 10:06:25 -0000

I'm loving it.

Re: testing sbt plugins

softprops — Thu, 02 May 2013 12:17:23 -0000

I just found myself coming back here after 2 years. Still priceless!

Re: Play Framework: LESS vs. Sass Recompilation Performance

softprops — Fri, 14 Dec 2012 20:26:06 -0000

User's can hook into sbt's automatic recompilation handling, using it's `~` feature. In the Occam's razor theme, I didn't make assumptions about the want for auto recompiling. I left that up to the build tool. There is really nothing framework specific about it. You can configure the source dir and target so potentially you could have compilation artifacts copied to where play expects them.

I'm curious. Is the sass plugin using jruby as the sass interpreter for its ruby compiler in the same way rhino is used as the interpreter for the less js compiler?

Re: Play Framework: LESS vs. Sass Recompilation Performance

softprops — Fri, 14 Dec 2012 19:48:30 -0000

Nice post! You mentioned using an sbt plugin instead. Have you checked out my less plugin https://github.com/softprop... ? It's been pretty battle tested. What I like about your post is what I keep preaching. Frameworks do many things poorly as a result of trying too many things. Compiling less (or any other source) is really the realm of build tools/processes and not an application web framework. I'm interested in applying your tests to my plugin (which also uses rhino). I've made a number of edits to the less compiler's js source itself to make it easier to use from rhino. I really wish for more people to apply http://en.wikipedia.org/wik... in the word of scala when releasing software. Those that don't make me sad.

Re: sbt plugins roundup

softprops — Wed, 11 Apr 2012 15:05:17 -0000

I can't believe you didn't mention the assembly plugin. Probably one of the most practical, simple, and useful sbt plugins for app packaging.

Re: Killing the “U” in CRUD: making databases immutable

softprops — Tue, 28 Feb 2012 09:59:20 -0000

One answer to the versioning issue is the idea of vector clocks, http://en.wikipedia.org/wik.... Riak uses them to determine causality and the versioning of distributed objects http://wiki.basho.com/Vecto....

Victor Klang gave a very interesting talk on event driven architectures that may have some relevance to this post.. You can find the video here, http://nescala.org/2011/#eda

Re: treehugger.scala pamflet

softprops — Mon, 16 Jan 2012 11:39:00 -0000

YES! so awesome

Re: revisiting implicits without import tax

softprops — Sat, 31 Dec 2011 16:59:19 -0000

Whoa. awesome (and highly in depth) post. I'm going to have to read this at least one or two more times to soak it all in. Keep it up.

Re: SIP-12 - Uncluttering Scala’s syntax for control structures. -

softprops — Thu, 29 Dec 2011 01:07:34 -0000

Along those lines, I'm heavily in favor of an `unless` keyword.

unless truth // do something

verses the current

if(!truth) // do something

Re: SIP-12 - Uncluttering Scala’s syntax for control structures. -

softprops — Fri, 14 Oct 2011 10:26:29 -0000

This suggestion is probably way beyond the scope of the proposed improvement, but I would love to see support for an `unless` control structure which, IMHO, is more readable that the usage of !cond for conditional expressions.

unless cond then expression else expression

Or even after the expression

expression unless cond else expression

Re: Heroku | Scala on Heroku

softprops — Mon, 03 Oct 2011 22:22:27 -0000

For anyone interested I had and sbt plugin [1] to get scala projects up and running not long after they announced java support [2]. Heroku recently changing there procfile runtime env [3] which broke it but I'll be updating it with this newly added first class support for scala. My plugin almost completely removes the need for the ruby client in favor of using the heroku api directory which removes the need to context switch which developing/deploying.

In any case, I'm super to happy to hear about the official support. It's great for the overall community.

*tips hat at heroku guys and gals*

[1]: https://github.com/softprop...
[2]: https://twitter.com/#!/soft...
[3]: mvn is no longer on the execution path the $REPO env var was removed?

Re: testing sbt plugins

softprops — Sat, 17 Sep 2011 16:03:11 -0000

Thanks for tying this all together. This has been a big hole in the docs for a while. Priceless.

Re: Yes, Virginia, Scala is Learnable

softprops — Mon, 05 Sep 2011 20:07:22 -0000

apologies for where disqus escapes syntax :)

Re: Yes, Virginia, Scala is Learnable

softprops — Mon, 05 Sep 2011 20:03:39 -0000

I'm going to disagree with you on a few points. Dispatch is a library but it's also a _dsl_, a dsl for describing http requests and processing responses.

Let's look at an example GET http request

http://foo.com/path?bar=baz....

Since we are talking about what a java developer might find easy to learn, we might as well describe this request this in a format typical to what java-style programmers are used to.

val request = new HttpRequest()
request.setHost("foo.com")
request.setMethod(Method.GET)
request.addParameter("bar", "baz")
request.addParameter("boom", "zoom")

That's a lot of work to describe a simple http request! There went half your day's productivity.What scala affords us is _expressiveness_ in that we are able to design dsl's that mimic certain domains, not (yet) possible in java.Dispatch takes advantage of that to its fullest.

val request = :/("foo.com") / "path" <<? Map("bar"->"baz", "boom"->"zoom")

In my opinion, this looks a lot closer to the actual domain than the java-style equivalent, even if the java-style format is explicitly naming everything.So how does Dispatch get away with all of these wacky symbolic methods? Consistency and convention!

< Appends to the request

> Pulls things out of the response

<:< appends headers

>:> gets headers out

Now what about sbt? How are you going to ever learn all of these wacky symbolic operators for binding functions to setting keys in your build? You guessed it, consistency and convention.

= expressions that end in this mean you are defining something

< indicates your key has a dependency

+ indicates you are appending one of something

++ indicates you are appending two or more of something

Can you guess what <++= means? It's defining a key by appending two or more of a given type, whilst declaring that its definition depends on other keys. How do I know this from just looking at the symbolic method? I understand the conventions and know that the api is consistent.

I might say, how does one, besides relying on tab-completion, come to learn an fully alpha lexical api? You learn the naming conventions and at least hope the api developer is consistent. I've seen plenty of cases in scala where alpha lexical apis have missed usages of camel case, snake case, and camel snake_? case conventions in their code. Does that make them any more readable/learnable than the equivalent symbolic method api (that is actually designed around the domain it's describing)? Probably not?

In either case, you are going to have to read the docs to learn the api. If I were to choose, I'd rather go home early than staying late just so I can put in time to type all of the unnecessary characters. Was that not a benefit of using Scala over Java, as well?

In my opinion once you learn a dsl for a specific domain, you become more efficient in solving problems in those domains. The only difference with Scala here is that it permits the author a greater ability to express, with valid Scala syntax, the problem than the equivalent Java counter part.

Most of the the whole symbolic method argument comes down to subjective and opinionated arguments. Yes math, one domain, defines a set of symbols that express ideas, but that doesn't mean we should be limited to a world is where math is the only dsl that's socially acceptable to express.

Re: sff4s: simple future facade for Scala

softprops — Sun, 28 Aug 2011 22:10:42 -0000

yes, yes, and yes. This is what I've been wanting. A generic interface for multiple backends for concurrent programming in scala. /me tips hat at you.

Re: http://j2labs.tumblr.com/post/6843058096

softprops — Thu, 28 Jul 2011 02:22:26 -0000

Ha! I recently added something almost exactly like this to the Meetup api's jython code which logs to a special file that later gets parsed and aggregated in graphite. Decorators, what _would_ we do without them?

Re: an unofficial guide to sbt 0.10 v2.0

softprops — Sun, 19 Jun 2011 21:11:28 -0000

Fantastic write up

Re: Adding sound to the game

softprops — Thu, 26 May 2011 21:01:07 -0000

sweet!

Re: Particly Android Game - Making of

softprops — Wed, 18 May 2011 09:52:31 -0000

This game keeps getting more awesome

Re: The Man with 1000+ Instant Cameras

softprops — Fri, 13 May 2011 09:44:08 -0000

amazing

Re: http://j2labs.tumblr.com/post/4600391346

softprops — Thu, 14 Apr 2011 01:08:18 -0000

scala> 0.1 + 0.2
res0: Double = 0.30000000000000004