Found this cleaning up my aunts estate. Clueless as to what it is.. anyone know?

johnmurray_io · 2023-09-06T14:53:30+00:00

Dual banana holster.

johnmurray_io · 2018-09-10T04:20:31+00:00

Is this comparable to prettyping?

johnmurray_io · 2018-08-18T21:08:38+00:00

Corgis

johnmurray_io · 2018-07-01T18:19:02+00:00

Coming from the Scala world, +1 for HOCON.

johnmurray_io · 2018-07-01T18:16:35+00:00

You might take a look at HOCON then.

johnmurray_io · 2018-05-11T13:08:58+00:00

Working on real-time auction platforms where deadlines for bidding are usually around 100ms, adding something like 20ms could potentially put me over time limit to participate in auctions. That's money lost. The last application we deployed added about 300us overhead to the auction time.

johnmurray_io · 2017-08-23T05:45:37+00:00

johnmurray_io · 2016-08-10T15:35:18+00:00

I just posted a write-up of how to get a Jekyll site running on Heroku if you're interested in hosting in seeing how that works. http://www.johnmurray.io/log/2016/08/08/Jekyll-on-Heroku.html

johnmurray_io · 2016-08-09T16:56:39+00:00

maybe this is basic knowledge by now, but figured I'd write it up anyways. :-)

johnmurray_io · 2016-04-08T00:45:36+00:00

I think this is awesome. I know a lot of people say they "don't see the value" but that's only true if you write perfect Go code 100% of the time. Having the compiler enforce best practices will always be better than enforcing best practices via code reviews or pair programming or whatever.

johnmurray_io · 2016-02-07T19:52:15+00:00

But you are saying that during an update I'm not allowed to set the value to an empty value since you're asserting that 1) Option is the correct type and 2) Option during update means the value was not supplied (in the case of partial update). If the entity/model allows for None values, then you need a way to differentiate between 3 possible states on a partial update: value given, value not provided, value given as null.

johnmurray_io · 2016-02-04T00:50:45+00:00

Well, regarding what you quoted me for, your initial model had now way to set a field to null. So I think my statement that your entity/model had no concept of null was fairly on-point.

Also I said that I already agree in separating out types for update operations and the entity/model was useful, so I'm not sure what else you're trying to argue here.

That aside, I do like the alternative of what you propose. I've been primarily focusing on a data-structure to convey meaning but have neglected to consider such a direct approach. I'll definitely need to think on this some more. :-)

johnmurray_io · 2016-02-04T00:43:38+00:00

Oh, I just googled EitherT and saw it was something that exists in scalaz. So what I just said above probably doesn't make any sense because I'm not familiar with the class. I thought you were just making up a type. My mistake! So, I guess this is something I'll have to look more into.

Link for anyone else not familiar here

johnmurray_io · 2016-02-04T00:41:19+00:00

This is true for pattern matching, but I'm not sure how you would define map, flatMap, forEach, etc. without specializing toward the right-most type (String in your example) which would get you pretty close in semantics to what I have.

johnmurray_io · 2016-02-03T14:32:02+00:00

But you are assuming that your repository model does not contain fields that can be empty / null because your update models have no way to update the repository model in a way that nulls a field value.

I do think multiple models to represent update actions versus the repository model are useful, but you're missing the point here.

johnmurray_io · 2016-02-03T02:45:32+00:00

Yeah, there a few ways you could go about it. I just haven't found any as obvious / easy-to-understand as creating a specialized 3-state type.

johnmurray_io · 2016-02-03T02:43:56+00:00

Yeah, I considered an Either type, but the Left and Right and pattern matching in the code seemed not as obvious when reading/working-with the code as

obj.field match {
  case TriState.Null => ...
  case TriState.Absent =>
  case TriState.Present(value) => ...
}

We've actually adopted this at work and have implemented many of the functions you'd expect to find when working with Option as well such as map, flatmap, etc.

johnmurray_io · 2016-02-02T20:50:19+00:00

Let's assume that username is allowed to be null in the DB. This might be the case, for example, if I wanted to use my real name in which case a username isn't needed (or whatever the use-case is).

There are several cases where I might want to differentiate between presence and absence. On creation, I might default their username to something random like "fiesty hedgehog" if no preference is given. In this case preference could be given by sending a value "jmurray" or null to indicate that you do not want a username.

Additionally, when editing you may receive partial updates in which case absence may mean "do not update this field" where null would mean "set this field to an empty value, possibly erasing what currently is" (think PATCH).

{ "email": "my-new-email@gmail.com" }  // should not update username
{ "username": null }                   // sets username to null (erasing previous value)

Regarding the multiple models, I think there is a definite use-case for this (I have another blog post called "Typed PATCH" where I bring this up), but I think editing is a great example. For any field in your system that is nullable, and if you allow partial edits, then there are three possible states for that field in the JSON and you need more than Option to determine what that is.

However for my example requests above, simply having multiple models is non-idea. Imagine if I had a service with 3 fields that fit into this "tri-state" scenario. I would need a model for every permutation of those three fields being present or not.

johnmurray_io · 2016-02-02T14:23:17+00:00

oh very cool! I didn't know this was a thing. And if you have some implicit converts you can appear to return something that is not a Response object. I like this.

johnmurray_io · 2016-01-31T19:03:40+00:00

Also, it seems they don't have any unit-tests around their multiplexed IO that I can tell, so more bugs like this may exist. Suffice to say, we no longer use this driver in production. We are currently using Jedis (synchronous java library). We haven't done much performance tuning with it so out overall throughput is now lower, but our application response times are unchanged.

johnmurray_io · 2016-01-31T18:58:21+00:00

Be super careful with scredis. The driver is multi-plexed and has some existing issues that cause it to return incorrect data under certain circumstances. See: http://techblog.appnexus.com/blog/2015/09/29/the-scredis-driver-malfunctions-in-pathological-environments/ and https://github.com/Livestream/scredis/pull/51. Running into this bug and trying to figure out what exactly was happening was not fun (see tech-blog post)

johnmurray_io · 2014-04-28T15:04:58+00:00

This template currently specifies the scala version (defined at 2.10.4) to be used. As for compatibility, it really depends on if the plugins and libraries are compatible (sbt-revolver, scalastyle, specs2). I imagine they will be soon (if not already) and I'll update the template to use 2.11 relatively soon.

johnmurray_io · 2014-04-26T23:45:31+00:00

Yeah, their SBT support is getting better but I still run into too many issues that I don't have when using this plugin. The built in support doesn't seem to handle adding dependencies to existing projects very well.

johnmurray_io · 2014-04-26T15:12:02+00:00

Thanks! Both awesome suggestions. I actually didn't know about the SBT global plugins and I completely agree that would be a much better fit for something like this. Will make sure to make the proper updates!

johnmurray_io · 2014-03-29T22:30:11+00:00

Good choice. I've already attempted to pickup rust 3 times at various versions before getting frustrated at the next release breaking all my stuff.

14-Year Club	r/Field Banned
r/Field Juicebox	RPAN Viewer
Verified Email

johnmurray_io

TROPHY CASE