Disqus - Latest Comments for ches

Re: Everything You Ever Wanted to Know About Sealed Traits in Scala - Underscore

ches — Wed, 19 Jul 2017 10:52:34 -0000

The actual Nil definition is a case object, logically since it is a singleton type:


case object Nil extends List[Nothing] { /* … */ }

It would be helpful if the article illustrated this. (Otherwise it's something I refer people to read regularly, thank you).

Re: Stop Merging Master

ches — Wed, 05 Jul 2017 12:23:06 -0000

About repetitive conflicts when rebasing, you need to know about git rerere: https://git-scm.com/blog/20...

You should rarely if ever need to actually use the rerere command, just enable the config setting globally and Git does the work for you.

Re: http://blog.bruchez.name/2011/10/scala-partial-functions-without-phd.html

ches — Sat, 12 Nov 2016 14:17:53 -0000

lift also makes a handy case for using partial application (and teaching or recalling the difference between partial functions and partial application!):


scala> val pets = List("cat", "dog", "frog")
pets: List[String] = List(cat, dog, frog)

scala> val maybePet = pets lift _
maybePet: Int => Option[String] = <function1>

scala> maybePet(0)
res134: Option[String] = Some(cat)

scala> maybePet(42)
res135: Option[String] = None

Great for Map key lookups too, where the convenient apply syntax is unsafe, but after lift _ you have the same syntax but the safety of get.

Re: Python Mixins Continued

ches — Thu, 07 Jul 2016 09:09:41 -0000

Possibly the best example for multiple inheritance modeling a real-world entity ever conceived :-)

The rarity at which these appropriate uses actually arise does make me wish that Python had a truer composition feature in the language.

Re: Currying - Scala Documentation

ches — Sat, 18 Jun 2016 14:55:38 -0000

I've never seen anyone actually implement a builder API in Scala using currying like the example you suggest, the builder pattern and currying are not really analogous or fitting for the same use cases.

Like any other language feature this is one to be applied judiciously with tasteful API design consideration. In real-world Scala code you will seldom come across functions with more than two parameter lists. I think you're creating problems here that don't exist.

Re: Working with Files in NodeMCU on the ESP8266

ches — Wed, 15 Jun 2016 19:34:19 -0000

What Jason means in saying that only one file can be open, is that your Lua code can only have one file handle open and it must be closed before opening another. It does not mean that you can't access files while the runtime is executing init.lua—this would make it pretty impossible to ever use files in your code :-)

In the example file.open("hello/world.txt") the file "object" is stateful, it's now operating on hello/world.txt and you need to do something with that file's contents and then call file.close() before you can try to work with another one. You could read the contents as a string and assign them to a variable, then close the file and read another one to another variable. Just be mindful that memory is precious on these devices and big strings loaded eagerly rather than iterated efficiently can be costly.

Re: VIM configuration for happy Java coding

ches — Sun, 17 Apr 2016 15:59:26 -0000

It integrates perfectly with YouCompleteMe for me, with one line of config:


let g:EclimCompletionMethod = 'omnifunc'

Re: VIM configuration for happy Java coding

ches — Sun, 17 Apr 2016 15:55:47 -0000

Anything using pure VimL will probably be slow for large searches. I tell CtrlP to use The Silver Searcher in filename listing mode:


if executable('ag')
  let g:ctrlp_user_command = 'ag --nocolor -g "" %s'
  let g:ctrlp_use_caching = 0
endif

Re: Strategic Scala Style: Principle of Least Power

ches — Tue, 12 Apr 2016 19:21:00 -0000

Yeah, particularly with the early emphasis on "don't fear refactoring" my expectation was set for Haoyi's entire post to take a perspective of user/application code, not library maintainers—and I think there's an undertone of advocating particularly to that audience that Scala doesn't have to seem so complex. Don't scare them off with a whole new realm of considerations to take into account! ;-)

Not that you're wrong of course, and I suppose there are large enterprise code bases out there, with subsystems maintained by multiple teams, where they do begin to feel some costs of binary incompatibility and they grow to have a more careful attitude about it by necessity. Your insights are certainly helpful to any in that position or getting into widely depended-upon open source projects. Hopefully an open source library maintainer has accepted and embraced this new facet of complexity that they have to preside over when enlisting for duty :-)

Case classes are probably one of the clearest points of departure on these grounds: library maintainers think, "run away!", and application developers think, "this is one of my favorite features of Scala"!

Re: Tmux and Vim, get married. | Garrett Dawson | thedrearlight

ches — Mon, 07 Mar 2016 04:16:28 -0000

Indeed, I used to have issues with the Homebrew build but for awhile that has no longer been the case, so nowadays I install this way too.

Re: The Power of Scala vs. Java | Toptal

ches — Sat, 28 Feb 2015 14:54:33 -0000

Shouldn't have fed the troll. Live long and prosper, my bitter, bridge-dwelling friend.

Re: The Power of Scala vs. Java | Toptal

ches — Fri, 27 Feb 2015 19:21:22 -0000

My, these kinds of posts sure do bring out the get-off-my-lawn haters. A Real Man should never need anything more than x86 assembly, right?

Really though, if you're not too big on associating behavior with data in the way OOP has come to be imagined, you'd like algebraic data types, which Scala's case classes can serve as.

Re: Spray error "could not find implicit value for evidence parameter of type spray.httpx.marshalling.Marshaller[scala.concurrent.Future[_]]"

ches — Tue, 23 Dec 2014 09:34:24 -0000

I've run into this, as well as another confusing case where Spray needs an ExecutionContext and the error doesn't make that at all obvious: using the onComplete/onSuccess/onFailure directives.

I'd paste an example route definition but Disqus seems to like to eat my indentation when pasting code. Suffice to say, you could call a database query that returns a Future, or perhaps an ask, pass that to onSuccess, and get a lovely error like this:


[error] /Users/ches/src/scala/my-app/src/main/scala/EventService.scala:48: type mismatch;
[error]  found   : scala.concurrent.Future[String]
[error]  required: spray.routing.directives.OnSuccessFutureMagnet
[error]           onSuccess(results) { results =>
[error]                     ^
[error] one error found
[error] (compile:compile) Compilation failed

Not even any implicit serializer resolution involved, that's just a Future[String].

In my case I was trying to decouple a route definition completely from actors in order to test the request dispatch logic in isolation, without involving all the noise of communication by actor handlers in the tests. I had the route definition in a trait by itself with some abstract methods that would be implemented by an actor that mixed in the trait, so there was definitely no dispatcher already being brought into implicit scope to do other Akka things. The solution, without wanting to couple my trait to a self-type of self: => Actor and then be able to import context.dispatcher, was to bring some other ExecutionContext into scope in the trait. Ugh.

Re: Rebuilding my vim setup from scratch – Blog – isotope|eleven

ches — Sat, 06 Dec 2014 02:04:11 -0000

You might like foldmethod=marker in lieu of your "end" comments. A gross idea for shared projects with people using a mix of editors, but it's pretty rare that anyone not using Vim is going to be editing your vimrc :-) A good example IMO is here: https://github.com/bling/do...

Re: The problem of managing schemas

ches — Wed, 05 Nov 2014 03:22:05 -0000

That is basically how Avro works.

Re: The Power of Scala vs. Java | Toptal

ches — Sat, 01 Nov 2014 22:56:17 -0000

No, certainly there is nothing wrong with developing new client-side skills if you're seeing projects and opportunities that interest you, and it might be a refreshing change if you've worked in Java a lot. I was just hoping to point out a few areas where I feel Scala does have potentially compelling value—I probably got carried away :-)

I think I'm biased, because I've been working with dynamic languages lately, and it feels like a lot of dust is stirred up on front-end tech right now. So statically-typed backend is actually appealing to me personally as an area to focus while it settles a bit ;-)

Consider giving React at least a shallow look after you become familiar with Angular, though. And a functional language if you can ever find the time. Not as mainstream, but they'll definitely give you some new ways of looking at problems even in your day-to-day environment.

Re: The Power of Scala vs. Java | Toptal

ches — Sat, 01 Nov 2014 16:56:10 -0000

I was trying to be helpful, to you if you genuinely didn't understand, or to other readers. You're welcome :-P

Re: The Power of Scala vs. Java | Toptal

ches — Sat, 01 Nov 2014 16:42:25 -0000

I wouldn't. These JS frameworks are evolutionary steps. As new standards like Web Components, EcmaScript 6, etc. continue to evolve, the frameworks are likely still going to change significantly or be surpassed by whole new approaches other than today's data binding. Angular 2.0 already has major API changes from prior versions.

And let's not forget that programming in plain JavaScript sucks :-) Languages trans-piling to efficient JavaScript "assembly" is rapidly becoming realistic. If the afore-linked article on React and Om is intriguing but you're far less likely to get into Clojure than Scala, take note that Scala.js has progressed quickly, Scala(.js) should be able to exploit the same symbiotic advantages of immutable collections in tandem with React that ClojureScript/Om does, and that Scala.js integration with React is well underway.

As for the "server side is so much thinner"—that's the middle tier, not the entire server-side. I don't imagine Apache Spark will run atop HTML5 local storage anytime soon :-) Get a taste of Akka—which you can also use in Java BTW—and think about the types of things that can be productively built with it (like, say, Spark), and it might seem there's still a lot of fun to be had on the backend.

Re: The Power of Scala vs. Java | Toptal

ches — Sat, 01 Nov 2014 15:32:23 -0000

One chance to start winning people over though might be test suites... that's a sometimes-cited means of slipping in some Scala to let people see benefits and become familiar without riling up management much, since it's not production code. After all, Scala 2.11 is just a jar that will work in your Java 6 projects... at least until 2.12 that will require Java 8 :-)

Re: The Power of Scala vs. Java | Toptal

ches — Sat, 01 Nov 2014 15:14:15 -0000

The point is that you don't need to preemptively add JavaBean-style boilerplate code like getFoo and setFoo methods when you don't yet have any need for custom logic in them, only as a defensive measure so that you don't break callers if you do need to add logic to them in the future.

By declaring a public property on a Scala class, the compiler is effectively generating a getter (and setter if it's a var) for you anyway—it is not direct field access: methods that take no arguments can be called without parentheses in Scala, and there is special support for def fieldname_= to allow assignment syntax. So the key point the author is making is that you can later add logic to that property access as a refactoring that's completely internal to the class, no name change that breaks callers.

In short, idiomatic Scala adheres to the Uniform Access Principle; Java does not.

Re: Introductory Guide to Akka (with code samples) | Toptal

ches — Sun, 03 Aug 2014 02:41:14 -0000

It may add a little too much cognitive overhead for an introductory article as another concept to explain, but using become to switch WordCounterActor's behavior could arguably clean up the logic of the running var.

Re: 5 Reasons to Use Protocol Buffers Instead of JSON For Your Next Service

ches — Fri, 04 Jul 2014 07:30:59 -0000

Sure, but after the flexibility of JSON has allowed you to bang out a bunch of microservices rapidly and without much discipline along the way, have fun when your organization realizes that you now have services built by different teams, using different stacks, each with its own ideas about what a good ad hoc API schema should look like, probably influenced by library conveniences of those different stacks, etc. Next, mix in deployment of versioned releases for those APIs with said ad hoc schema. Good times ensue.

Or you could have a declarative schema and protocol definitions and generate server and client code from them, instead of reinventing the wheel day-in-day-out just to schlep data across a network when you could instead be focusing work on your application's real value-adds. Elevate the design thinking to good protocols, not their implementation details.

Some things ought to be solved problems by now. SOAP was an overwrought solution. We shouldn't rush to throw the baby out with the bathwater "because agile!" when we see new attempts to solve old problems better.

Re: 5 Reasons to Use Protocol Buffers Instead of JSON For Your Next Service

ches — Fri, 04 Jul 2014 07:11:00 -0000

Given that it ought to be friendlier to dynamic languages, it's a shame the Ruby world doesn't have better supporting libraries for Avro yet, only the low-level implementation maintained in the Apache Avro repo as far as I know. I broke ground on some code to try to map Avro de/serialization to nice Ruby objects wrapped with Virtus, and haven't been able to touch it for awhile. I have some free time now so I'm trying to get back to it and publish it. Would love to hear from anyone interested in such a thing :-) I have some more ideas for RPC to hash out after that...

Re: Enterprise | WIRED

ches — Sun, 15 Jun 2014 22:04:40 -0000

I'm not sure if I'm mistaking your point completely, but it sounds as though you've run on a bit of a tangent, springing from the article's minor subtext of Google's increased focus on their cloud offerings, to lament resource pricing of public cloud services in general.

Kubernetes and Mesos can be deployed on commodity metal in your own data center, so... along with Docker these are some of the very evolving free tools making it easier to build private or hybrid clouds with portability at the service & application tier. If that was in fact your point, well yes, I think you've restated a central point of the article :-P

Still, I believe this is more significant for adoption of cloud/PaaS/etc. in the enterprise than it is to early-stage startups—public IaaS has been revolutionary for startups largely because it allows them to avoid CapEx (hardware) by shifting to OpEx. It doesn't make sense for startups that have yet to "prove ROI" to turn around and give up that exchange, and expend engineering time and effort racking servers and cobbling OpenStack together instead of developing their product.

These tools are exciting developments for growing companies, in part because they will help to bridge the gap between different hosting environments and make migration or hybrid more tractable. Kubernetes and Mesos help them to optimize costs by squeezing more utilization out of a stabler pool of provisioned resources. Such consolidation makes it easier to employ reserved instances which make AWS pricing considerably more attractive, for example.

Re: The big thing Foursquare left out of Swarm: Check-in points. I’ll miss them

ches — Fri, 16 May 2014 15:14:59 -0000

I don't think we can say for certain yet that badges are gone for good—we're still looking at an early transitional release of Swarm, and there's really very little about badges that *need* to be tied to points which are explicitly quantified for users. Milestone achievements like visiting diverse types of places and special events can exist without scoreboards (and I hope they will).

I'm a long-time, big fan of Foursquare, and I've been a little apprehensive about the scope of the changes in the pipeline, but I'm feeling that they're pretty on-the-money so far. Personally I haven't cared about the points in years, and I concur that they have become quite arbitrary. I do like to find out what friends are up to, and I constantly use Foursquare to discover new places. Discovery is a much bigger pie than the social points game for which the novelty wore off years ago for many people (I hear from friends that they "don't care about playing anymore"—they're stuck in the thinking that Foursquare was all about scores, when it's so much more than that). Yelp is looking weak on the flanks these days and 4sq is positioning its forces to hit 'em there, improving their agility by decoupling social and discovery features.

Foursquare has been a remarkably (perhaps almost fatally) user-centric company, they have exerted substantial effort building software tools and human resources for community management. I don't get any sense that that attitude has changed, and that is what gives me confidence that they can pull this off on both fronts: they can build a profitable business on discovery that sustains the existence of the service for everyone, and they can do it without alienating many loyal fans of the social side (I'm less optimistic about, say, Twitter's recent actions, as an analog...). I can absolutely buy the thesis that many people will never want to use both aspects of Foursquare. Integrating two apps cohesively for people who do is going to be a hard challenge. But if anyone has shown the kind of dedicated focus on experience to deliver and refine this, I think 4sq has.

If I were an investor in Foursquare, I'd be looking to increase my position right now. As a loyal user, I'm feeling excited too.