#elixir-lang - 29 April 2019
« Back 1 day Forward 1 day »
[14:00:11] qqwy: @dysfun / @OliverMT there is no real reason to do so, since you can easily import it into your own code if you really need it
[14:00:23] qqwy: (which will make your code indeed fail with a compilation error on older OTP releases)
[14:01:44] qqwy: (although the order of arguments will probably be the opposite of what you'd expect in Elixir)
[14:19:23] drewolson: i don't get the "harder to unit test" point in this article -- https://habr.com/en/post/449522/
[14:19:46] drewolson: if anything i've found elixir easier to unit test, as even OTP modules can be tested as "just functions"
[15:12:23] LostKobrakai: @josevalim I just read over the docs for `mix release` and they're insanely well written.
[18:29:56] nageV_: drewolson: +1. he says "unit tests are less helpful ... [because] almost all Elixir functions are clean, which makes unit tests simpler". huh?
[18:34:09] nageV_: as a TDD practitioner, I feel tests are more than just a safety net for complex code: they're a design tool :)
[18:35:03] nageV_: that is to say: all code warrants tests, not just complex code. and Elixir making tests simpler is a Good Thing :)
[18:38:01] dysfun: when i was writing idris, i never bothered with tests, so does all code warrant tests?
[18:43:23] nageV_: it does if you're following Test Driven Development :) https://twitter.com/unclebobmartin/status/1030819434510745601
[18:48:06] drewolson: dysfun: also, idris is fascinating and i love that its creator describes it as "pacman complete"
[18:48:30] dysfun: drewolson: these days he follows it up with "probably. not sure, trademark issues"
[18:48:57] starbelly: the problem with how most people write tests is they write tests to see them pass, and thus there may as well be no tests.
[18:50:12] starbelly: I mean, I try to unit tests for all the things, then light weight integration... but if I can't write a good test in N time, then it's probably not worth doing. I'd rather have a lack of tests vs a bunch of shitty tests that deceive everyone.
[18:51:35] starbelly: property tests exemplify how hard writing _good_ tests actually is IMO... of course you can write shitty property tests too
[18:52:53] dysfun: i mean, i'm working on a thing right now where we don't have much option but to do that
[18:53:08] starbelly: ACTION definitely not saying don't write tests, rather focus on writing good tests
[18:54:03] jnoon2: in an umbrella project, im running mix test inside one app. that app uses modules from other "apps". im getting module SomeOtherApp.Lib is not available. im probably just missing some config to tell the app it depends on the other?
[18:54:04] starbelly: right, and that usually takes more time than most people/companies want to spend on tests :(
[18:54:25] dysfun: heh, so one of the projects i work on has only controller tests, because there was limited time for tests and they're the best bang for buck
[18:55:26] dysfun: they're not thorough tests, but for the time that was presumably allocated, they're good bang for buck
[18:56:21] starbelly: dysfun: I suppose... I dunno, I've seen plenty of bad controller tests where if a unit test had been written for well one small unit, it would have caught problems that the controller tests did not.
[19:01:43] starbelly: well, a re-write is usually a bad idea, at least a complete re-write, though the person was probably just trying to do the right thing, and if so, would not call them an idiot
[19:07:22] dysfun: but certainly rewriting under time pressure has limited advisability, even if it's to elixir
[19:09:09] dysfun: at a previous job, we moved to elixir, but we didn't just instantly rewrite, we had a transition strategy
[19:18:41] serafeim__: i am using VS code with the vscode-elixir plugin. when I edit an elixir file I see something like "@spec call(Plug.Conn.t(), any()) :: Plug.Conn.t()" over my methods. can anybody explain what is this ?
[19:20:48] serafeim_: is this typing defined somewhere? how does vscode-elixir know that this actually *is* a Plug ?
[19:25:14] serafeim_: i.e how does it know that the first parameter of the call method (conn) is a Plug.Conn? Couldn't that be anything ?
[19:30:25] serafeim_: now, right over the init and call methods visual studio writes the @spec stuff I mentioned earlier
[19:34:17] serafeim_: lol so it knows that conn is a Plug.Conn because I pass it to Plug.Conn.get_session ?
[19:37:28] benwilson512: serafeim_: yes, that's the type that Plug.Conn.get_session says it requires, so it's saying that in order for your call function to succeed, you need to pass it a conn
[19:47:18] serafeim_: i mean where does the VS-code plugin find this information? i.e that the parameter is a Plug.Conn?
[19:51:51] benwilson512: and yeah it's using the typespec here: https://github.com/elixir-plug/plug/blob/v1.8.0/lib/plug/conn.ex#L1399
[20:13:15] serafeim_: this code works fine: <%= @user.permissions |> Enum.map(& &1.name) |> Enum.join %>
[20:13:30] serafeim_: this code <%= @user.permissions |> Enum.map (& &1.name) |> Enum.join %> throws an error. *notice the space in Enum.map.
[20:14:03] serafeim_: the error is: protocol Enumerable not implemented for #Function<0.55029995/1 in AsampleWeb.PageView."index.html"/1>, only anonymous functions of arity 2 are enumerable.
[20:27:32] benwilson512: serafeim_: because it's parsed as `@user.permissions |> Enum.map((& &1.name) |> Enum.join)`
[23:07:22] ariedler: I was wondering if I could optimize the stream version as well, but lets just do the list version for now lol
[23:23:09] ariedler: sms: the whole mapset unique thing is freaking magical, no idea how it does it so fast
[23:35:38] ariedler: so what I thought was because uniq_list (underlying implementation for List.uniq) was not using tail optimization the memory was being bloated
[23:36:03] ariedler: but i switched it to use tail optimization, and I get no performance improvement
[23:39:55] ariedler: I would be surprised if the ordering cost that much; but it seems like that is the case