Re: [Snowdrift-dev] errors trying to build from arch linux

[Bryan Richter]

On 12/13/2017 09:29 PM, Jason Harrer wrote:
> Schwt
> 
> All we need now is confirmation from someone on *bunts/Debian.
> 
> Bryan, you may want to test on MixOS as well.
> 

Just to confirm on this thread, the fix is in master and seems to work
for everybody. Thanks, Jason!




signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Brainstorm for implementing multiple projects

[Bryan Richter]

On 12/13/2017 03:16 PM, Aaron Wolf wrote:

> On 12/13/2017 11:28 AM, Bryan Richter wrote:
>
> 
>
> Two comments:
>
>> Buffers can't exist in a system that has no account balances. The
>> volatility gets pushed to the question of "Does the patron have
>> enough money in their actual bank account."
>
>
> I want it to go through a User Story / consent / design process,
> but sometime we'll discuss this. There's no technical requirement
> of a buffer, it's a UX and system-design question. It relates to
> whether signing up for crowdmatching should actually serve to invite
> and match further new patrons. It may be unnecessary or early
> optimization.  Anyway, it can be dropped from this topic now.

Oof, now I understand! The definition of "buffer" has changed from

*How many more months can I afford my current pledges?*

to

*How many more patrons can join before I get dropped?*

Let's definitely talk about that a lot later -- I already see
problems.

> 
>
> That sounds like what David said too when I talked to him about
> this. He had a moment last weekend to at least look at things and
> think about Snowdrift code stuff. This could be a good place to hand
> off a little coding task(s) to him if you can delineate clearly. He
> understands the issues pretty well and may be able to help or at
> least discuss the implementation…

Great!



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Brainstorm for implementing multiple projects

[Bryan Richter]

On 11/16/2017 12:29 AM, Aaron Wolf wrote:
> On 11/07/2017 04:34 AM, Bryan Richter wrote:
>>
>> Having multiple projects means it becomes more complicated to see if
>> someone has gone over their budget. We'll need to account for that.
>
> We discussed this a while back. I'm going to summarize again here some
> basic (maybe obvious) factors.
>
> 

As you said in the other email on this thread, I think the most
important adjustment to my plan is making sure that a pledge to
project A only affects other pledges to project A. I agree with that
requirement. I'll think through the implementation ramifications and
come up with a modified plan.

>> -  Tasks for enabling multiple projects
>> -  Dev tasks
>> -  Modify tests to assume multiple projects
>> -  Create new Project table (id, handle, donations_received)
>> -  Create new Pledge table,   user <*--*> project
>> -  Deprecate pledge_since
>
> Why deprecate pledge_since? Certainly we don't want to lose the
> information about how long someone has been a patron. Also, my idea (not
> sure it's strictly the best though) to check in order from oldest to
> newest pledge would seem to use some information like this.

I was unclear there. Definitely keeping that info. It's just going to
be part of the Pledge table instead of the Patron table.

> ### concerns
>
> If multiple patrons hit their budgets at the same time (say they pledge
> to the same set of projects), who gets dropped first?

It can't happen at the *same* time - each pledge is atomic. It might
be too fast for human comprehension, but the system will have a notion
of ordering, so it'll use that to drop them.

> If a patron with a dropped pledge decides to drop a different pledge in
> order to reinstate the dropped one, I guess any patrons who also support
> the same two projects would be budget-wise unaffected since they would
> just reduce their level for one and increase for the other.

It would only totally unaffect patrons who are also pledged to both
projects. If someone gets dropped from A and chooses to pledge to B
instead, patrons pledged to B (but not A) could get dropped. But there
is no reason to consider this a special scenario. It's two unrelated
pledge+drops, only tenuously connected because the drop-ee in one
scenario is the pledger in another.

> BUFFER: to keep things from being too volatile, we've had this concept
> for a long time that there should be some buffer remaining in a patron's
> budget in order to add a new pledge. Keep that in mind (and consider
> implementation plans).

Buffers can't exist in a system that has no account balances. The
volatility gets pushed to the question of "Does the patron have enough
money in their actual bank account."

> I'll stop here except to reiterate: what about doing budget calculations
> at the time of pledging? I thought that would be effectively the only
> thing needed. Then the crowdmatch and payment events would be at most
> just extra checks to be triple-sure to respect budgets…

Yeah, doing them at pledge time is probably going to be required.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Go to Definition?

[Bryan Richter]

On 11/14/2017 11:04 AM, Samuel Tay wrote:
> Hasktags generates pretty much all the tags you want relevant to
> your project. If you have git submodules, forks of other projects
> locally, etc. then you can pass these directly via the CLI, e.g.
>
> hasktags -b "src deps/package1 deps/package2 /some/other/location"
>
> Another cool tool built off hasktags is haskdogs, which recursively
> generates tags. Might only be for stack projects, and also might
> only be viable for smaller projects, but I use it locally and it's
> awesome! You'll get jump-to for all of base as well (you get sent to
> some file in your .stack-work directory).
>
> https://hackage.haskell.org/package/hasktags
> https://hackage.haskell.org/package/haskdogs

Thanks, I'm gonna try this out!

haskdogs sounds like it's solving a similar problem to codex. Any
insight to their relative strengths and weaknesses?



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Go to Definition?

[Bryan Richter]

On 11/14/2017 12:02 PM, David Thomas wrote:
> While the general case for TH is intractable, it would probably be
> pretty simple to write a script that can generate tags locations for
> identifiers generated by specific, known cases - particularly
> Persistent.
>
> At work I took a bit of a different approach, and wrote a generator
> that looks at the TH output and writes out code to different modules
> for each model.  This lets the tooling just work.  Probably
> overkill in the context of Snowdrift, though...

Sounds like something Haskell needs in general! I agree that the case
of persistent and routes is much simpler, though.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Go to Definition?

[Bryan Richter]

Hi!

On 11/13/2017 06:30 AM, jake wrote:

> In Haskell code, I'd like the ability to click an identifier and go
> to its definition. How do I do this?

You're not alone in your frustration. I think the only people who have
a really good answer to this question are users of emacs + intero (+
stack).

https://commercialhaskell.github.io/intero/

If you're willing, I'd suggest giving it a try.

Unfortunately for me, I use vim, and I haven't plunged into emacs yet.
I'm also frustrated with a lack of good go-to-definition support.
Here's my solution so far:

1. Use vim. Vanilla vim has:

-  keyword search (# and *) in a single file
-  keyword expansion (^p, ^n) across all loaded files
-  grep integration (:grep)
-  creates a quickfix list, navigable with :cnext and :cprev
-  support for ctags, which *does* provide go-to-defintion for the
   local project (see following)

2. Use fast-tags to generate ctags

-  Works on the local project, with caveats due to Template Haskell:
-  Doesn't support yesod routes (generated with TH)
-  Doesn't support persistent model types (generated with TH)

3. Use all the web search engines

-  For reasons unknown to me, different engines index different parts
   of hackage. I try:
-  Stackage search https://www.stackage.org/
-  Hoogle https://www.haskell.org/hoogle/
-  Hayoo http://hayoo.fh-wedel.de/

4. Use codex https://hackage.haskell.org/package/codex

-  Theoretically, this indexes all of your dependencies, and provides
   ctags go-to-definition for *everything*. I've tried it before, and
   it was quite nice!
-  I don't use it right now, but maybe that's just because I changed
   operating systems and didn't load it back up yet.

> I would like to know what your methods are,
> since mine aren't working too well.  This issue
>  may
> explain some of my problems, but I'd like to hear your solutions.
>
> If you're interested, here's what I've tried:
>
>
> Recently, I have installed IntelliJ and its Haskell plugin: the
> above being my primary motivation -- supposedly, this IDE/plugin
> combo has the feature.  Problem: only rarely does it work.

I don't know anybody who uses IntelliJ + the Haskell plugin. :( I am
not sure what state it is in. It might be a lost cause.

Free/open source Haskell developers almost exclusively do not use
IDEs. Some people *defend* this state of affairs, but I think the only
real reason is that nobody has poured the intense time, money, and
effort into creating one that *works* and is well-integrated with the
compiler.

> To give my actual case:
>
> I was perusing sdb.hs and saw:
>
> -- | Seeing as I use this everywhere toText_ :: FilePath -> Text
> toText_ = format fp
>
> And I though to myself, "Hmm. I wonder where fp is defined? And
> format?" So I use the "Go to Declaration" feature.

Just for reference, here's how I figured out the answer to this
myself. (Off the top of my head, I had no idea what 'fp' was.)

First, I opened the file in vim and did a keyword search with *
(http://vimhelp.appspot.com/pattern.txt.html#star). I found nothing,
so I knew it wasn't a file-local definition. I knew for a fact that I
would not export a name as meaningless as 'fp', so I didn't bother
searching elsewhere in the project. Finally, I looked at the import
list. Luckily, this file has really good imports, and there are only
two possibilities:

import Turtle hiding (need, opt)
import Development.Shake

Since fp is being used by 'format', which I knew was part of Turtle,
I had a strong feeling that fp was part of Turtle, too.

Sure enough, I searched Stackage and there it was, the second hit:

search result:
https://www.stackage.org/lts-9.13/hoogle?q=fp

definition:

https://www.stackage.org/haddock/lts-9.13/turtle-1.3.6/Turtle-Format.html#v:fp


Hope that helps!



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] Brainstorm for implementing multiple projects

[Bryan Richter]

Hi all,

Here are some initial ideas for implementing multiple projects in the
crowdmatch library. (This is not about the website.) Please take some
time to read this and provide any feedback or fresh ideas, since I
dreamed this up on my own, and I could use some second opinions.

Thanks!

---


Having multiple projects means it becomes more complicated to see if
someone has gone over their budget. We'll need to account for that.

Crowdmatching and payment processing both become more complicated,
too. Besides checking budget limits (which will have a life of their
own for the sake of early warnings), crowdmatching will have to group
by project when calculating crowd size.

The existence of a pledge will need to change from being a Maybe field
in the User row to being a Maybe field in the Pledge list. It stays
a Maybe so that one table handles the whole relationship: pledge
status and pending donation.

Here's the plan for handling spending limits: Don't charge more
than the limit, and don't allow a crowdmatch that is greater than
the limit. Note what's left out: we do not consider the pending
balance (if any) when doing a crowdmatch, but only the spending limit
itself. In the possible case that a crowdmatch of, say, $3 causes a
user's balance to be $11, they can pay $10 this month, and $4 next,
and that's fine.

We need is to extend the calculations to be per-project, hitting the
pledge table instead of the user table.

-  Tasks for enabling multiple projects
-  Dev tasks
-  Modify tests to assume multiple projects
-  Create new Project table (id, handle, donations_received)
-  Create new Pledge table,   user <*--*> project
-  Deprecate pledge_since
-  Implement budget limit calculations (below)
-  Deploy tasks
-  Migrate pledges and pending donations
-   insert into pledge (project, user, since, pending_donation)
select 1, u.id, u.pledge_since
from user u
-  Budget calculations
-  During crowdmatch
-  Drop pledge LIFO, recalculate, and repeat until nobody exceeds their 
limit
-  Continue with crowdmatch
-  When patron views a page
-  Change nothing, just show warnings
-  During payment processing
-  Only charge up to the limit, leaving any extra in the patron's 
account.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] Life in the post-October Rest world

[Bryan Richter]

Hi all,

Here's another long email! (When I said my emails would become more
irregular, I guess that could mean *more* frequent...)

This email is about what to do now that I've reset the code base
and starting doing deploys again. In short, let's continue making a
world where more people support FLO software (and other goods). More
specifically, some of you will need to reset your code repository, and
there is plenty of directions for current work. I'll highlight a few
of them, including the valuable task of reincorporating a lot of the
hard work that went into the pre-reset branch.

First, the nitty-gritty. For all three of you so affected, the reset
will probably require a manual reset on your end, too. Make sure you
don't have *anything* you want saved, in particular unrecorded files,
and then run the following set of commands.

git status
# ^ Double check that there are no unsaved changes or files
git checkout master
git fetch origin
git reset --hard origin/master

So, what about new development? Let me start by demonstrating how to
see what, exactly, got left out in the reset.

Current master—the new master—has about half of the "abandoned"
commits from the old master. You can see which ones got cherry-picked
in with the following arcane whispers:

git cherry master master-pre-reset -v | grep ^-

To see which commits have *not* been included, use the following,
almost identical incantation:

git cherry master master-pre-reset -v | grep ^+

You can use that last command for a rough approximation of what got
left out. I don't think we should do any more cherry picking, but we
can use these lists as guides.

One obvious thing left out is Sass. I *think* we can safely add it
back. But I'm not sure. And I want to proceed much more delicately.
For instance, the very first thing that should be done with it is to
rewrite an existing Cassius file as Sass. No improvements, no Susy,
just a rewrite. Don't change defaultLayout, either. At most, create a
sibling function for the page being rewritten.

Another little chunk to bite off is the navigation panel. Start
with: What is its purpose? What user stories do we want to satisfy
with it?

As for me: My current inability to build for production makes it
apparent that we should bake that functionality into our ops stack. I
will start by reading up on Docker+tools and NixOps, which are the top
two contenders in my mind for taming deployment. I know Salt is using
docker-compose for some things, which is why I say 'Docker+tools'.

Also, I gave up on one approach to testing the website without
actually talking to stripe.com, but there are two others to try. I'd
like to use Haskell's new 'backpack' system, so I will read up on
that.

I want to say something about what happened to the pre-reset master.
It was a systematic mistake. We bit off too much both in formulating
governance, formulating development policy, and (re)formulating
software architecture. Some people worked very hard on some of those
things, and got burned. For my part of the failure, I apologize.

But I think the organization is stronger for it. I absolutely cherish
the real-world experience I get in collaborating with all of the
highly-skilled, passionate volunteers in this project. I hope that
being part of this project continues to reward all of us in that way.

Peace,

-Bryan
aka chreekat

p.s. Please pretend I didn't say anything about replacing Yesod in my
previous email. :) I may harbor dreams of such a thing, but I don't
think it is realistic in any short time frame.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Weekly dev status, 2017-09-11

[Bryan Richter]

On 09/11/2017 05:56 PM, Stephen Michel wrote:
> On Mon, Sep 11, 2017 at 10:50 AM, Bryan Richter wrote:
>> On 09/11/2017 03:16 PM, Stephen Michel wrote:
>>>
>>>
>>>  When we reach alpha, maybe it's time to run our first crowdmatch?
>>>  It'll be below our normal minimum, thus we'll be paying much more in
>>>  stripe fees than we'd like, but the point would be to find pain
>>>  points in the process, not recieve significant sums of money.
>>
>> My answer to your question is both "yes" and "no". Yes we should do
>> the first crowdmatch before October 1. But we won't charge any fees.
>>
>> Recall that there are two processes: crowdmatching and payment
>> processing. A crowdmatch transaction updates the amount that a
>> patron "owes" to a project. Separately, we use Stripe to settle up
>> between patrons and projects. This is just another way of saying that
>> donations roll over to the next month if the amount owed isn't enough
>> to minimize fees.
>>
>> This raises an important point: the significance of these numbers needs
>> to be made clear on the website: current pledge value, current amount
>> "owed", and total amount paid to the project to date.
>>
>> Now, should we do special-case payment processing that ignores our
>> promise about maximum fees? I definitely think not. :) Right now we'd
>> be talking about a 30 cent charge on a 6 cent donation. Bleh
> 
> Ah, let me update my verbiage: I meant to propose that we run a crowdmatch for
> all months that people have been pledging with real credit card numbers, then
> run a payout on that total. So it'd be more like a 35 cent charge on a 45 cent
> donation (for me anyway, newly pledged patrons will be closer to what you
> said).

Well, I don't have the machinery to create retroactive crowdmatch
transactions. We have all the data (pledge histories) to do such a
thing, but I don't know it's worth it. Better to move forward.

> With 67 patrons that's just under $25 in fees. So, let's not do that, but
> maybe let's trigger a payout for just a handful of accounts (those of team
> members), to verify that it will work in The Real World (tm), rather than
> running into issues later that might affect people with less stake in the
> project. :)

I don't have the machinery for doing that, either. :) Not a bad idea,
though.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Weekly dev status, 2017-09-11

[Bryan Richter]

On 09/11/2017 03:16 PM, Stephen Michel wrote:
> 
> 
> On September 11, 2017 5:19:29 AM EDT, Bryan Richter <br...@snowdrift.coop> 
> wrote:
>> == Last week.
>>
>> Code changes: some updates and fixes to the snowdrift project page,
>> thanks to Iko.
>>
>> == This month.
>>
>> My goal for this month is to finish the website and crowdmatch
>> mechanism for Alpha. Maybe a bit optimistic. :) But we seem close.
>> The mechanism is functional; it just needs testing. The website is
>> functional; it just needs testing. What is mainly missing is a little
>> bit of practice: practice restoring backups, practice analyzing logs,
>> practice deploying breaking changes -- that sort of thing.
>>
>> There's a lot more we *could* do, but there always will be.
>>
>> == This week.
>>
>> - Start practicing and figuring out where things are the most broken
>>  or flimsy.
>>
>> - Do some system administration work. Hard drives are filling up, and
>>  not much is documented.
>>
>> - Coordinate with other components of the project. Make sure we have
>>  the bones of a post-Alpha plan.
>>
>> - Encourage people to prod the website and report UI problems.
>>
>> == "What can I do?"
>>
>> - Write tests! Or ask me how. It needs documenting, anyway.
>>
>> - Get the haskell-stripe packages back into Stackage.
>>  https://github.com/dmjio/stripe/issues/76
>>
>> - Ask questions about open issues.
>>  https://git.snowdrift.coop/sd/snowdrift/issues
>>
>> Thanks!
> 
> When we reach alpha, maybe it's time to run our first crowdmatch?
> It'll be below our normal minimum, thus we'll be paying much more in
> stripe fees than we'd like, but the point would be to find pain
> points in the process, not recieve significant sums of money.

My answer to your question is both "yes" and "no". Yes we should do
the first crowdmatch before October 1. But we won't charge any fees.

Recall that there are two processes: crowdmatching and payment
processing. A crowdmatch transaction updates the amount that a
patron "owes" to a project. Separately, we use Stripe to settle up
between patrons and projects. This is just another way of saying that
donations roll over to the next month if the amount owed isn't enough
to minimize fees.

This raises an important point: the significance of these numbers needs
to be made clear on the website: current pledge value, current amount
"owed", and total amount paid to the project to date.

Now, should we do special-case payment processing that ignores our
promise about maximum fees? I definitely think not. :) Right now we'd
be talking about a 30 cent charge on a 6 cent donation. Bleh.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Attacked by Space Bug

[Bryan Richter]

> On 09/11/2017 08:00 AM, Peter Harpending wrote:
>> On Sep 10, 2017 11:27 PM, "jake" wrote:
>> 
>> Hello, I'm Jake. I'm brand new here. In summary, I want "real
>> world" Haskell experience. (Long version sent to
>> commun...@snowdrift.coop .)
>> 
>> I tried to build the test platform, but encountered a classic
>> bug: the space bug.
>> 
>> Easy to replicate: make a directory with a space in its name,
>> such as "foo bar". In my case, it was "Backup One". Navigate
>> (cd) your terminal to this place. Follow the build instructions
>> in BUILD.md, starting with the "git clone..." line.
>> 
>> Well, something in the build script does not handle that space.
>> 
>> Using my example with "Backup One", it expects a Unix socket to
>> be at:
>> 
>> /run/media/jthomas/Backup/.s.PGSQL.5432 
>> 
>> Notice the "/Backup/" part should be "/Backup One/".
>> 
>> Furthermore, navigating to jthomas reveals that there is no
>> "Backup" directory. So that file really does not exist.
>> (Sometimes these things make the directories that they think
>> should exist. Not in this case.)
>> 
>> 
>> Cheers, Jake
> Welcome. I'm Peter. 
> 
> If you want to get involved, this would be a good bug for you to
> fix. It's relatively simple, and you already understand the issue.
> 
> This would be a low priority issue for us as most developers don't
> put spaces in file names, so this is unlikely to cause serious
> issues
> 

Hi Jake, welcome!

Congrats, you ran into a "real world" bug. :) I created an issue to
track it: https://git.snowdrift.coop/sd/snowdrift/issues/66 .

Like Peter says, it's probably a good place to make a fix.
Unfortunately it's likely a Bash bug, not a Haskell bug. Probably
some variable in build.sh needs quoting.

Build bugs are actually always important, so if you don't have a chance
to get to this, I'll do it this week some time.

Thanks!

-Bryan



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] Weekly dev status, 2017-09-11

[Bryan Richter]

== Last week.

Code changes: some updates and fixes to the snowdrift project page,
thanks to Iko.

== This month.

My goal for this month is to finish the website and crowdmatch
mechanism for Alpha. Maybe a bit optimistic. :) But we seem close.
The mechanism is functional; it just needs testing. The website is
functional; it just needs testing. What is mainly missing is a little
bit of practice: practice restoring backups, practice analyzing logs,
practice deploying breaking changes -- that sort of thing.

There's a lot more we *could* do, but there always will be.

== This week.

- Start practicing and figuring out where things are the most broken
  or flimsy.

- Do some system administration work. Hard drives are filling up, and
  not much is documented.

- Coordinate with other components of the project. Make sure we have
  the bones of a post-Alpha plan.

- Encourage people to prod the website and report UI problems.

== "What can I do?"

- Write tests! Or ask me how. It needs documenting, anyway.

- Get the haskell-stripe packages back into Stackage.
  https://github.com/dmjio/stripe/issues/76

- Ask questions about open issues.
  https://git.snowdrift.coop/sd/snowdrift/issues

Thanks!



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] Weekly dev update, 2017-09-03

[Bryan Richter]

Weekly update, 2017-09-03
=

Code developments
-

- Page styling is now implemented with Sass. See

https://git.snowdrift.coop/sd/snowdrift/blob/master/BUILD.md#adding-and-updating-sass-files
  for some usage notes.
- CI is up and running: https://git.snowdrift.coop/sd/snowdrift/pipelines .
- Most of the original prototype
  (https://snowdrift.sylphs.net/prototypes/alpha/) is now actually
implemented
  in master.
- build.sh got tweaked, and builds work on macOS, NixOS, and Arch now
(as well
  as Debian-based systems, which are a breeze).

Meta developments
-

- Some triaging has happened for issues; sort by 'label priority' as
seen here:

https://git.snowdrift.coop/sd/snowdrift/issues?sort=label_priority=opened
- Or look, I started toying with Gitlab's issue boards:
  https://git.snowdrift.coop/sd/snowdrift/boards
- Instructions for manually testing Stripe integration have been added to
  BUILD.sh.

Current and upcoming work
-

- In my opinion, the following work is needed to reach "alpha":

1. Next items on the board:
   https://git.snowdrift.coop/sd/snowdrift/boards
2. Throw a lot of tests at the mechanism

- However, I think we need to talk about what "alpha" means. I.e., what
are our
  goals, really? I think it's been long enough that we should touch base
on this
  topic again.

- That's not just for devs, so I'll ask that over at the discuss mailing
  list. (Join if you want to follow along:
  https://lists.snowdrift.coop/mailman/listinfo/discuss)

- We still need improvements to miminize needless rebuilds.
- stack v1.5 might help.

- Logging and monitoring is the most important (and nonexistent) piece
of our
  architecture. I'm going to look at influxdb and grafana; other suggestions
  welcome.




-Bryan



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Anyone knowledgeable on spam filtering?

[Bryan Richter]

On 09/02/2017 02:58 AM, Stephen Michel wrote:
> I do my hosting through hcoop.net. They commit the same folly we do
> (running our own mail server), but at least have SpamAssassin set up.
> Maybe we could send our email through them? If we're interested in that,
> I could be the liaison and handle email configuration.

The problem has gone way down recently. I did set up postgrey, which
seemed to help a lot.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] connecting model data to the front end with splices

[Bryan Richter]

I've heard some questions and concerns about front end development
waiting on back end variables. I can understand why these questions
might arise. The final version of a page's template must use #{..}
splices that get read and compiled to Haskell. The values referred to
in those splices need to really exist for the website to compile, run,
and show values from the database. So, the front end depends on the
back end.

But here's the thing: the back end depends on the front end, too! In
fact, the back end has a *more important* dependency. While the front
end depends on values existing, the back end depends *knowing what
values need to exist*.

The front end is where the requirements flow from. It is closer to the
user, closer to the purpose of the website. The back end only exists
to serve the website's needs.

So, rather than holding up the front end to wait on back end
variables, I think it is much better to use {{placeholderValues}} if
the real values aren't available yet. Then, any new back end values
will definitely be serving a purpose, and won't be a useless waste of
time and resources.

So, don't be afraid to design new pages when the back end values don't
exist yet. Doing so will be better for the project, anyway.

-b


signature.asc
Description: PGP signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Shakespeare splice support for SASS

[Bryan Richter]

On Tue, Jul 25, 2017 at 01:30:10AM +0300, fr33domlover wrote:

> Hello people,
>
>
>
> I made a patch for shakespeare-sass which makes it support
> splices like the other shakespeare languages. I'd like to explain
> why and how because it's not easy to understand from my still
> ugly-and-undocumented code.



> Before running the SASS compiler, I'll run a preprocessor that
> encodes those special characters in the splices using just
> alphanumeric ASCII characters, so that the SASS compiler doesn't
> touch them, and after compilcation I'll run a postprocessor that
> decodes the splices back to the original form! And *then* treat the
> result as a Lucius source.
>
> Ikomi tried this today and it seems to work!
>

This doesn't actually look too bad! I mean, yes, it's a hack, but for
this piece I'd rather use something hacky and build a proper solution
later. Shakespeare is *full* of hacks like this, anyway.

In fact, I just spent a few hours trying to make a less-hacky version
of this change. Unfortunately, there is no clear "correct" way to do
it, and each language within Shakespeare (Cassius, Julius, Text, ...)
does it differently. Plus, the TH compile-time errors are horrendous
and hard to trigger reliably.

That is to say, I think your patch can't possibly make things worse.
;)

Over on #34
(https://git.snowdrift.coop/sd/snowdrift/issues/34#note_1297) there
has been more discussion about Sass concerns. More hacks incoming...



signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] Use appStripe as stripe client in handlers

[Bryan Richter]

On Tue, Jul 11, 2017 at 06:57:03PM -0700, Bryan Richter wrote:
> Much of this patch makes sense to me. I'm pretty sure I know where the
> type errors are originating from, too.

I looked at this yesterday, and I realized what really needs to happen
is we get rid of StripeI. It is completely superfluous; I never want
to test at that level.

We should get rid of StripeI, but still make the stripe runner (e.g.
Web.Stripe.stripe) an API parameter.

> 
> Throw rocks at me if I don't get to this in the next 24 hours or so...
> 
> On Tue, Jul 11, 2017 at 06:16:58AM +0300, fr33domlover wrote:
> > From: fr33domlover <fr33domlo...@riseup.net>
> > 
> > This is a new version of the patch, it uses runStripe in appStripe. It
> > avoids the StripeClient mess but still has a type error due to
> > StripeRunner being having the 'forall io' thing. The errors can be fixed
> > using type annotations probably, but using those in every single place
> > 'snowstripe' is used would be ridiculous.
> > 
> > Honestly idk much about Rank N types. I read about it and did some web
> > search. And I still don't understand how to properly fix this type error
> > thing. I think the error is simpler now but idk how to *elegantly* fix it.
> > ---
> >  crowdmatch/crowdmatch.cabal|  3 ++-
> >  crowdmatch/src/Crowdmatch.hs   |  7 +++
> >  website/src/AppDataTypes.hs|  8 
> >  website/src/Application.hs |  7 ++-
> >  website/src/Handler/PaymentInfo.hs | 11 ++-
> >  website/src/Handler/Util.hs|  9 +
> >  6 files changed, 22 insertions(+), 23 deletions(-)
> > 
> > diff --git a/crowdmatch/crowdmatch.cabal b/crowdmatch/crowdmatch.cabal
> > index d378766..2c602f1 100644
> > --- a/crowdmatch/crowdmatch.cabal
> > +++ b/crowdmatch/crowdmatch.cabal
> > @@ -28,7 +28,8 @@ library
> >  hs-source-dirs: src
> >  default-language: Haskell2010
> >  build-depends:
> > -base >=4.8 && <4.9
> > +  aeson
> > +, base >=4.8 && <4.9
> >  , bytestring >= 0.10.6.0
> >  , errors
> >  , lens
> > diff --git a/crowdmatch/src/Crowdmatch.hs b/crowdmatch/src/Crowdmatch.hs
> > index fe61387..a857c2a 100644
> > --- a/crowdmatch/src/Crowdmatch.hs
> > +++ b/crowdmatch/src/Crowdmatch.hs
> > @@ -58,10 +58,12 @@ import Control.Error (ExceptT(..), runExceptT, note)
> >  import Control.Lens ((^.), from, view, Iso', iso)
> >  import Control.Monad (void)
> >  import Control.Monad.IO.Class (MonadIO, liftIO)
> > +import Data.Aeson (FromJSON)
> >  import Data.Function (on)
> >  import Data.Int (Int32)
> >  import Data.Ratio
> >  import Data.Time (UTCTime, getCurrentTime, utctDay)
> > +import Data.Typeable (Typeable)
> >  import Database.Persist
> >  import Database.Persist.Sql (SqlPersistT)
> >  import System.IO
> > @@ -73,6 +75,7 @@ import Web.Stripe.Customer
> >  , createCustomer
> >  , deleteCustomer)
> >  import Web.Stripe.Error (StripeError)
> > +import Web.Stripe.StripeRequest (StripeRequest, StripeReturn)
> >  
> >  import Crowdmatch.Model hiding (Patron(..))
> >  import qualified Crowdmatch.Model as Model
> > @@ -87,6 +90,10 @@ import qualified Crowdmatch.Skeleton as Skeleton
> >  -- | A method that runs 'SqlPersistT' values in your environment.
> >  type SqlRunner io env = forall a. SqlPersistT io a -> env a
> >  
> > +type StripeClient = forall a.
> > +(Typeable (StripeReturn a), FromJSON (StripeReturn a)) =>
> > +StripeConfig -> StripeRequest a -> IO (Either StripeError 
> > (StripeReturn a))
> > +
> >  -- | A method that runs 'StripeI' instructions in IO. A default that uses
> >  -- 'stripe' is provided by 'runStripe'.
> >  type StripeRunner = forall io.
> > diff --git a/website/src/AppDataTypes.hs b/website/src/AppDataTypes.hs
> > index 39ea400..50d2526 100644
> > --- a/website/src/AppDataTypes.hs
> > +++ b/website/src/AppDataTypes.hs
> > @@ -16,6 +16,7 @@ import Yesod.Core.Types (Logger)
> >  import Yesod.GitRev
> >  
> >  import AuthSite
> > +import Crowdmatch
> >  import Settings
> >  
> >  -- | The God-object available to every Handler. This is the site's
> > @@ -30,10 +31,9 @@ data App = App
> >  , appAuth:: AuthSite
> >-- | The function for doing stripe API calls. Swapped out for a mock
> >-- thing in tests.
> > -, appStripe  :: forall a. (Typeable (StripeReturn a), FromJSON 
> > (StripeReturn a

Re: [Snowdrift-dev] [PATCH] Use appStripe as stripe client in handlers

[Bryan Richter]

Much of this patch makes sense to me. I'm pretty sure I know where the
type errors are originating from, too.

Throw rocks at me if I don't get to this in the next 24 hours or so...

On Tue, Jul 11, 2017 at 06:16:58AM +0300, fr33domlover wrote:
> From: fr33domlover 
> 
> This is a new version of the patch, it uses runStripe in appStripe. It
> avoids the StripeClient mess but still has a type error due to
> StripeRunner being having the 'forall io' thing. The errors can be fixed
> using type annotations probably, but using those in every single place
> 'snowstripe' is used would be ridiculous.
> 
> Honestly idk much about Rank N types. I read about it and did some web
> search. And I still don't understand how to properly fix this type error
> thing. I think the error is simpler now but idk how to *elegantly* fix it.
> ---
>  crowdmatch/crowdmatch.cabal|  3 ++-
>  crowdmatch/src/Crowdmatch.hs   |  7 +++
>  website/src/AppDataTypes.hs|  8 
>  website/src/Application.hs |  7 ++-
>  website/src/Handler/PaymentInfo.hs | 11 ++-
>  website/src/Handler/Util.hs|  9 +
>  6 files changed, 22 insertions(+), 23 deletions(-)
> 
> diff --git a/crowdmatch/crowdmatch.cabal b/crowdmatch/crowdmatch.cabal
> index d378766..2c602f1 100644
> --- a/crowdmatch/crowdmatch.cabal
> +++ b/crowdmatch/crowdmatch.cabal
> @@ -28,7 +28,8 @@ library
>  hs-source-dirs: src
>  default-language: Haskell2010
>  build-depends:
> -base >=4.8 && <4.9
> +  aeson
> +, base >=4.8 && <4.9
>  , bytestring >= 0.10.6.0
>  , errors
>  , lens
> diff --git a/crowdmatch/src/Crowdmatch.hs b/crowdmatch/src/Crowdmatch.hs
> index fe61387..a857c2a 100644
> --- a/crowdmatch/src/Crowdmatch.hs
> +++ b/crowdmatch/src/Crowdmatch.hs
> @@ -58,10 +58,12 @@ import Control.Error (ExceptT(..), runExceptT, note)
>  import Control.Lens ((^.), from, view, Iso', iso)
>  import Control.Monad (void)
>  import Control.Monad.IO.Class (MonadIO, liftIO)
> +import Data.Aeson (FromJSON)
>  import Data.Function (on)
>  import Data.Int (Int32)
>  import Data.Ratio
>  import Data.Time (UTCTime, getCurrentTime, utctDay)
> +import Data.Typeable (Typeable)
>  import Database.Persist
>  import Database.Persist.Sql (SqlPersistT)
>  import System.IO
> @@ -73,6 +75,7 @@ import Web.Stripe.Customer
>  , createCustomer
>  , deleteCustomer)
>  import Web.Stripe.Error (StripeError)
> +import Web.Stripe.StripeRequest (StripeRequest, StripeReturn)
>  
>  import Crowdmatch.Model hiding (Patron(..))
>  import qualified Crowdmatch.Model as Model
> @@ -87,6 +90,10 @@ import qualified Crowdmatch.Skeleton as Skeleton
>  -- | A method that runs 'SqlPersistT' values in your environment.
>  type SqlRunner io env = forall a. SqlPersistT io a -> env a
>  
> +type StripeClient = forall a.
> +(Typeable (StripeReturn a), FromJSON (StripeReturn a)) =>
> +StripeConfig -> StripeRequest a -> IO (Either StripeError (StripeReturn 
> a))
> +
>  -- | A method that runs 'StripeI' instructions in IO. A default that uses
>  -- 'stripe' is provided by 'runStripe'.
>  type StripeRunner = forall io.
> diff --git a/website/src/AppDataTypes.hs b/website/src/AppDataTypes.hs
> index 39ea400..50d2526 100644
> --- a/website/src/AppDataTypes.hs
> +++ b/website/src/AppDataTypes.hs
> @@ -16,6 +16,7 @@ import Yesod.Core.Types (Logger)
>  import Yesod.GitRev
>  
>  import AuthSite
> +import Crowdmatch
>  import Settings
>  
>  -- | The God-object available to every Handler. This is the site's
> @@ -30,10 +31,9 @@ data App = App
>  , appAuth:: AuthSite
>-- | The function for doing stripe API calls. Swapped out for a mock
>-- thing in tests.
> -, appStripe  :: forall a. (Typeable (StripeReturn a), FromJSON 
> (StripeReturn a))
> - => StripeConfig
> - -> StripeRequest a
> - -> IO (Either StripeError (StripeReturn a))
> +, appStripe  :: StripeConfig
> + -> forall a. StripeI a
> + -> HandlerT App IO (Either StripeError a)
>  }
>  
>  -- This function generates the route types, and also generates the
> diff --git a/website/src/Application.hs b/website/src/Application.hs
> index 761d3f8..b6b20db 100644
> --- a/website/src/Application.hs
> +++ b/website/src/Application.hs
> @@ -33,6 +33,7 @@ import Web.Stripe
>  import Web.Stripe.Error
>  import qualified Yesod.GitRev as G
>  
> +import Crowdmatch
>  import Handler
>  import Handler.Dashboard
>  import Handler.Discourse
> @@ -61,11 +62,7 @@ makeFoundation appSettings = do
>  (if appMutableStatic appSettings then staticDevel else static)
>  (appStaticDir appSettings)
>  
> -let appStripe :: (Typeable (StripeReturn a), FromJSON (StripeReturn a))
> -  => StripeConfig
> -  -> StripeRequest a
> -  -> IO (Either 

Re: [Snowdrift-dev] [PATCH] Use appStripe as stripe client in handlers

[Bryan Richter]

To whom it may concern:

fr33domlover and I know this doesn't compile.. it was submitted for
discussion.

Now, on with the discussing:

On Tue, Jul 11, 2017 at 03:57:31AM +0300, fr33domlover wrote:
> From: fr33domlover 
> 
> ---
>  crowdmatch/crowdmatch.cabal|  3 ++-
>  crowdmatch/src/Crowdmatch.hs   | 32 +++-
>  website/src/AppDataTypes.hs|  6 ++
>  website/src/Handler/PaymentInfo.hs | 11 ++-
>  website/src/Handler/Util.hs| 14 ++
>  5 files changed, 39 insertions(+), 27 deletions(-)
> 
> diff --git a/crowdmatch/crowdmatch.cabal b/crowdmatch/crowdmatch.cabal
> index d378766..2c602f1 100644
> --- a/crowdmatch/crowdmatch.cabal
> +++ b/crowdmatch/crowdmatch.cabal
> @@ -28,7 +28,8 @@ library
>  hs-source-dirs: src
>  default-language: Haskell2010
>  build-depends:
> -base >=4.8 && <4.9
> +  aeson
> +, base >=4.8 && <4.9
>  , bytestring >= 0.10.6.0
>  , errors
>  , lens
> diff --git a/crowdmatch/src/Crowdmatch.hs b/crowdmatch/src/Crowdmatch.hs
> index fe61387..ad0489c 100644
> --- a/crowdmatch/src/Crowdmatch.hs
> +++ b/crowdmatch/src/Crowdmatch.hs
> @@ -14,7 +14,9 @@ module Crowdmatch (
>  , SqlRunner
>  
>  -- * Interface with stripe
> +, StripeClient
>  , StripeRunner
> +, runStripeWith
>  , runStripe
>  
>  -- * Store/delete payment tokens
> @@ -58,10 +60,12 @@ import Control.Error (ExceptT(..), runExceptT, note)
>  import Control.Lens ((^.), from, view, Iso', iso)
>  import Control.Monad (void)
>  import Control.Monad.IO.Class (MonadIO, liftIO)
> +import Data.Aeson (FromJSON)
>  import Data.Function (on)
>  import Data.Int (Int32)
>  import Data.Ratio
>  import Data.Time (UTCTime, getCurrentTime, utctDay)
> +import Data.Typeable (Typeable)
>  import Database.Persist
>  import Database.Persist.Sql (SqlPersistT)
>  import System.IO
> @@ -73,6 +77,7 @@ import Web.Stripe.Customer
>  , createCustomer
>  , deleteCustomer)
>  import Web.Stripe.Error (StripeError)
> +import Web.Stripe.StripeRequest (StripeRequest, StripeReturn)
>  
>  import Crowdmatch.Model hiding (Patron(..))
>  import qualified Crowdmatch.Model as Model
> @@ -87,6 +92,10 @@ import qualified Crowdmatch.Skeleton as Skeleton
>  -- | A method that runs 'SqlPersistT' values in your environment.
>  type SqlRunner io env = forall a. SqlPersistT io a -> env a
>  
> +type StripeClient = forall a.
> +(Typeable (StripeReturn a), FromJSON (StripeReturn a)) =>
> +StripeConfig -> StripeRequest a -> IO (Either StripeError (StripeReturn 
> a))
> +

I had lots of pain trying to use (or avoid using) the type signatures
around my mock stripe functions. I have a suspicion that this one, in
particular, is not something we want or need.

>  -- | A method that runs 'StripeI' instructions in IO. A default that uses
>  -- 'stripe' is provided by 'runStripe'.
>  type StripeRunner = forall io.
> @@ -441,20 +450,19 @@ data StripeI a where
>  ChargeCustomerI :: CustomerId -> Cents -> StripeI Charge
>  BalanceTransactionI :: TransactionId -> StripeI BalanceTransaction
>  
> --- | A default stripe runner
> -runStripe
> +runStripeWith
>  :: MonadIO io
> -=> StripeConfig -> StripeI a -> io (Either StripeError a)
> -runStripe c = \case
> +=> StripeClient -> StripeConfig -> StripeI a -> io (Either StripeError a)
> +runStripeWith strp c = \case

We definitely don't want this. At best, we may want a better name than
'runStripe'. It is intended to be a default StripeI runner that
actually uses the real 'stripe'.

StripeI is already the abstraction -- abstracting over its runner
shouldn't be necessary. (See more comments below, at the definition of
'snowstripe'.)

>  CreateCustomerI cardToken ->
> -liftIO (stripe c (createCustomer -&- cardToken))
> +liftIO (strp c (createCustomer -&- cardToken))
>  UpdateCustomerI cardToken cust ->
> -liftIO (stripe c (updateCustomer cust -&- cardToken))
> +liftIO (strp c (updateCustomer cust -&- cardToken))
>  DeleteCustomerI cust ->
> -void <$> liftIO (stripe c (deleteCustomer cust))
> +void <$> liftIO (strp c (deleteCustomer cust))
>  ChargeCustomerI cust cents ->
>  liftIO
> -. stripe c
> +. strp c
>  . (-&- cust)
>  -- Supported upstream as of 2016-10-06, but not in our resolver 
> yet
>  -- . (-&- ExpandParams ["balance_transaction"])
> @@ -462,7 +470,13 @@ runStripe c = \case
>  . view chargeCents
>  $ cents
>  BalanceTransactionI transId ->
> -liftIO (stripe c (getBalanceTransaction transId))
> +liftIO (strp c (getBalanceTransaction transId))
> +
> +-- | A default stripe runner
> +runStripe
> +:: MonadIO io
> +=> StripeConfig -> StripeI a -> io (Either StripeError a)
> +runStripe = runStripeWith 

Re: [Snowdrift-dev] [PATCH] Add a real Stripe runner to crowdmatch test module, using test key

[Bryan Richter]

On Tue, Jul 11, 2017 at 01:43:49AM +0300, fr33domlover wrote:
> From: fr33domlover 
> 
> The runner isn't being used, I just added it there so that we can start
> writing tests with it. May wish to move it to a TestImport module once
> we split crowdmatch tests into multiple modules.



FYI I think this is a fine approach, but let's not merge it until it's
actually being used by something.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] Override Stripe secret key in test settings

[Bryan Richter]

On Tue, Jul 11, 2017 at 01:05:28AM +0300, fr33domlover wrote:
> From: fr33domlover 
> 
> ---
>  website/config/test-settings.yml | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/website/config/test-settings.yml 
> b/website/config/test-settings.yml
> index b2d43ca..ded169e 100644
> --- a/website/config/test-settings.yml
> +++ b/website/config/test-settings.yml
> @@ -6,8 +6,17 @@ database:
># something like:
>#
>#   database: "_env:PGDATABASE:Snowdrift_LOWER_test"
> +  #
> +  # Note that at the time of writing, settings loading in the Snowdrift test
> +  # suite ignores the environment (the Yesod scaffolding template does the
> +  # same) anyway.
>database: snowdrift_test
>  
>  # All I want to see is test results, usually.
>  detailed-logging: false
>  should-log-all: false
> +
> +# Make sure we don't accidentally use the real key in tests. Note that while 
> an
> +# alternative env variable is specified here, if the test suite settings 
> loader
> +# ignores the environment, it won't notice the variable.
> +stripe-secret-key: "_env:STRIPE_SECRET_TEST_KEY:set_test_key_here"
> -- 
> 1.9.1

Hmm.. I think this is unnecessary. The tests should be using
the same environment variable that everything does; namely,
"STRIPE_SECRET_KEY". The difference is that in the test _environment_,
the _environment variable_ will be set to the test key. :)

These settings.yml files should really go away, incidentally.
Everything should just be environment variables. Settings.hs needs a
rewrite. (I think we'll eventually replace *all* the Yesod scaffolding
bits and pieces.)

I haven't really looked into it, though... there may be complications.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] my weekend dev progress and next steps

[Bryan Richter]

On Mon, Jul 10, 2017 at 09:34:56PM +0200, tuxayo wrote:
> Hi, thanks for these news :) !
> 
> On 2017-07-10 02:28, Bryan Richter wrote:
> > Other steps and potential work are here:
> > 
> > https://git.snowdrift.coop/groups/sd/issues=label_priority

Oops, missed a #!%$ sigil. ;)

Try:

https://git.snowdrift.coop/groups/sd/issues?=label_priority


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] my weekend dev progress and next steps

[Bryan Richter]

Hi all,

I'm really glad Snowdrift got mentioned on the reditwittersphere
recently - lots of new people around! Having people around, doing
work and asking questions, has helped me get focused and energized.

I got two solid days of programming in this weekend. I've merged the
ability to process payments, which completes all the mechanism code
for "alpha". I also opened an MR for moving to lts-8.21 (ghc 8.0.2):
https://git.snowdrift.coop/sd/snowdrift/merge_requests/48/commits

I went ahead and implemented this MR myself, duplicating the work of
mtncoder and I think others as well. Doing it this way was the fastest
way for me to understand all the little gotchas. There were actually
more than a few.

I'll merge that tomorrow, so please look at it and provide feedback
(before the merge would be best, but commenting after merge is also
very valuable). Thanks!

Next steps:

1. MORE TESTS

I don't trust the mechanism code yet.

A. There are zero tests integrating with Stripe's API.

B. There are zero web browser integration tests (using selenium)

C. Writing unit tests takes creativity, and more brains are better
   than one.

D. Test implementation is kind of ugly.

i. Tasty is now the top-level runner, but mostly it just calls
   to high-level HSpec suites. That's an annoying level of
   indirection.

ii. In some cases, the preconditions for a test may be
   implemented with library methods, which means the test is
   not isolated enough. For example, anything setting up the
   database should be using raw Persistent functions (like
   "insert"), not library methods. (By "library" I mean the
   library under test.)

E. Stripe error handling isn't tested. Getting them tested will
   probably improve the API, purifying some functions.

2. alpha-ui merge

This branch probably has lots of conflicts now. Let's work with
the designers to break the work apart, and redo individual pages
one at a time.

Other steps and potential work are here:

https://git.snowdrift.coop/groups/sd/issues=label_priority

and here:

https://tree.taiga.io/project/snowdrift-dev/kanban (look for the "Dev
Ready" column, and talk to designers if you have questions).

Peace,
-Bryan


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] crowdmatch: Use (SqlPersistT env) monad to allow combining queries

[Bryan Richter]

On Sun, Jul 09, 2017 at 04:56:29AM +0300, fr33domlover wrote:
> 
> Before this commit, crowdmatch actions run database queries separately
> inside them like a black box. That means in practice many applications
> of `runDB`, one per query, so a transaction per query. This is an
> unnecessary waste, and doesn't gain much (or anything at all, as this
> commit's changes my demonstrate).

Nice.

I'm finishing up make-payments right now, which will conflict with
this change, but once that's done (today) I will likely apply this
patch on top!


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] weeder: a neat tool to try out

[Bryan Richter]

https://hackage.haskell.org/package/weeder

Maybe someone wants to give it a spin on Snowdrift and see what it reports?


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] Advice for starting a project

[Bryan Richter]

On Mon, May 08, 2017 at 07:29:17PM -0700, Alyssa Rosenzweig wrote:
> As per a discussion with wolftune.
> ---
>  community/team-engagement.page | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/community/team-engagement.page b/community/team-engagement.page
> index 804fac9..890d1a6 100644
> --- a/community/team-engagement.page
> +++ b/community/team-engagement.page
> @@ -56,6 +56,16 @@ Organizations need some meetings, and when run well, they 
> can produce powerful r
>  * To set major priorities, especially for the long term
>  * To conduct project post-mortems in order to reflect on what succeeded and 
> what needs improvement
>  
> +## Starting a project
> +
> +* Be social. Talk to your friends about your project. Talk to their friends 
> about it. Talk about it in public IRC channels. Post about it on Reddit. It's 
> okay if it's not "ready" yet -- just get the word out and find people 
> interested.
> +* Get people involved. See the rest of this document for help here.
> +* Make it a community effort. It isn't *your* project; it's *our* project. 
> Let your new contributors have a say in the direction.
> +* If they've earned it, give people titles. Titles are fun and motivating, 
> and they don't cost you anything. Don't give them out recklessly, but if 
> people start accumulating real responsibilities, let them now! Titles are an 
> honour in FLO projects.
> +* Ask for help. Even if you do all the work for the project itself, reaching 
> out to advisors can be helpful in finding direction. Maybe someone in 
> `#snowdrift` can help bounce ideas off.
> +* If you can, a co-founder is even better.
> +* Open it out of your circle. It's one thing to build a project that appeals 
> to enthusiasts. It's another to make it appeal to non-enthusiasts. You'll 
> never please everybody, but you can always broaden your project's domain.
> +
>  ## Resources
>  
>  * [OpenHatch](http://openhatch.org) helps new volunteers get involved in FLO 
> software development
> -- 
> 2.11.0

Thanks. I see this has been merged already, but definitely feel welcome
to submit patches like this. :)


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] Taiga backups

[Bryan Richter]

Now that there are a multiplicity of Taiga projects, automating the Taiga
backups has become high severity. I don't have the time to click through all the
projects and have all the dumps emailed to me. :)

The best long-term solution is to use the Taiga API to streamline the process. I
think there used to be an issue about that, but I can't find it.

A good short-to-long term solution is to put somebody else in charge of Taiga
backups.

I'm still backing up the website database (though I've missed a few weeks). That
should also be automated...


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] ghci & Snowdrift.coop

[Bryan Richter]

On Fri, Jan 27, 2017 at 09:15:11PM -0600, Jason Harrer wrote:
> Hello, all -
> 
> During my adventures of troubleshooting the discourse-sso branch, I tried
> to access GHCi using both "./build.sh ghci" and "stack ghci".  Neither of
> them fully loaded the website as I anticipated, which made my debugging and
> type investigations much harder.  I ultimately fumbled through it,
> especially with singpolyma's help (thanks again, btw!), but it flustered me
> to have the issues.
> 
> So, I'm trying to look into why we're having issues with it.  It appears
> that there are cabal settings for run-persist & crowdmatch that are causing
> these to not compile when utilizing GHCi:
> 



I kind of gave up on using ghci with Snowdrift. The combination of stack, Yesod,
and ghci just caused all sorts of trouble.

For instance, a lot of the "warnings" that ghci prints at the beginning are
nonsense.

If it helps at all, the crowdmatch utility is fairly independent from the
website. It just uses the same database.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] Fwd: [GitLab, Inc.] Re: comment on issues via email?

[Bryan Richter]

FYI, Gitlab supports comment-via-email for Issues and presumably MRs as well.
However, it isn't possible to turn the feature on for hosted instances. There is
an issue tracking that capability:

https://gitlab.com/gitlab-com/githost/issues/45

I went ahead and gave it a thumbs up. :)

- Forwarded message from "Chris Wilson (GitLab Support)" 
<supp...@gitlab.com> -

Date: Thu, 19 Jan 2017 19:36:29 +
From: "Chris Wilson (GitLab Support)" <supp...@gitlab.com>
To: Bryan Richter <br...@snowdrift.coop>
Subject: [GitLab, Inc.] Re: comment on issues via email?

##- Please type your reply above this line -##

Your request (56886) has been updated. To add additional comments, reply to 
this email.
--

Chris Wilson, Jan 19, 14:36 EST

Hi Bryan,

We are currently unable to implement this manually as custom configuration 
options are overwritten on reconfigure. 

There's a feature request @ https://gitlab.com/gitlab-com/githost/issues/45 
which we are using to track the progress to add reply-by-email support.

Apologies for the inconvenience 

Thanks,

Chris Wilson
GitLab, Inc.

----------

Bryan Richter, Jan 18, 13:47 EST

Great, thanks for your response.

Gitlab manages our installation for us. Is it possible to have someone
set this up?

Attachment(s):
signature.asc - 
https://support.gitlab.com/attachments/token/JeR2ajL7pNZRE1Bpgr87aJUxC/?name=signature.asc

--

Abubakar Siddiq Ango, Jan 17, 17:12 EST

Hi Bryan,

Thanks for contacting GitLab Support.

You will have to enable incoming email in your gitlab.rb file, please see 
https://docs.gitlab.com/ce/administration/reply_by_email.html for more 
information. Kindly reply to this email if you have further questions.

Best Regards,
Abubakar Siddiq Ango
GitLab BV
https://about.gitlab.com

----------

Bryan Richter, Jan 17, 16:09 EST

Hi, I'm curious if there is support for commenting on issues via email
(say, by replying to the notification email). It does not seem to be
functional on our instance at git.snowdrift.coop, but I do not know if
that is due to missing features or missing configuration.

Thanks!

Attachment(s):
signature.asc - 
https://support.gitlab.com/attachments/token/OAZhM1rItsKONM3wCdiNCHW2O/?name=signature.asc


This email is a service from GitLab, Inc..









[J5YXD8-6D24]

- End forwarded message -


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] Crowdmatch mechanism ready to merge

[Bryan Richter]

https://git.snowdrift.coop/sd/snowdrift/merge_requests/25

STATUS
==

What this currently does:

- Enables configuring payment info
- Enables registering/unregistering a pledge.
- Tracks a history of pledges and unpledges.

What this does not do:

- It does not reintegrate the prototyped utilities that do the
  crowdmatch event and that trigger payment transfers.
- Pledge/Unpledge history is not displayed

This is enough to launch! It is not enough to actually do crowdmatching,
but we will have another two weeks to finish that, which is enough.

COMING NEXT
===

I am pausing here to reintegrate all this code, and to turn my
attention to the production branch in order to prepare for the swap.

Later today, I will merge this and deploy it to
https://dev.snowdrift.coop.

Once it is deployed later today, I strongly encourage you to create an
account, input fake payment info, and "pledge".

Since this is only using Stripe's testing api, you can put in the
following fake details to register a credit card:

FAKE CARD INFO TO USE ON DEV.SNOWDRIFT.COOP
---

Card no 4242 4242 4242 4242
Expiration: any time in the future
Security number: any 3 digits
Zip code: any N digits

I'm not sure how many digits are needed for zip code, and I'm not sure
how this works for non-US addresses. Please try it and let me know.

==

That took a while. Thanks for waiting. There's still a ton to do, code
and otherwise. Good luck to us all.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] code feedback please!

[Bryan Richter]

Hi everyone,

The crowdmatch mechanism code is still a work in progress, and I want
to talk about what I've done so far to get some feedback. This email
has become rather long! Feel free to skim it to find parts that sound
interesting. This was written for my benefit as much as yours, and in
the hope that I get some feedback. Anything at all, like "Well hurry up
and do it already", is very welcome.

It is also written for posterity and for your amusement. :)

The new code is on a branch called split-mechanism. A giant comparison
can be viewed, but it's longer than this email(!)[1] and I'm going to
call out specific items instead. This will be a technical discussion,
but not too nutty. I will talk about how I structured the crowdmatch
mechanism code, how I've designed it to be used, how I've designed it
to be testable, and how some quirks popped up during my headlong crash
through coding it. Please reply with feedback ABOUT ANY PART OF THIS! :D

### Table of Contents:

1.   A separate module for the crowdmatch mechanism
2.   API for the library
2.a.   Client code requirements
2.b.   Usage example
2.c.   Exported actions
3.   Database management
3.a.   Migrations
3.b.   The test database
3.c.   run-persist library
4.   Implementation to allow property testing
5.   Implementation to allow more-than-one Stripe
6.   Difference between MechAction and StripeI
7.   What's left to do

Appendix A: Questions

### 1. A separate module for the crowdmatch mechanism

Although there is only one foreseeable client to this code, namely the
Snowdrift website, I went ahead and structured it as a standalone
library. It is in a directory called 'crowdmatch'. I did this so it can
be tested independently. It will be a lot more stable than the website
eventually, too, which is a good decider for whether something should
be independent or not.

### 2. API for the library

The crowdmatch library puts certain constraints on client code because
it requires a database. Then, it does what any API does: provides
actions and data types.

### 2.a. Client code requirements

A client of this library must be using Postgres via Persistent.
The only way to be agnostic about databases would be to completely
reimplement a database. That's nuts. The library will just use Postgres,
and thus requires client code to use it as well.

The library also needs to do IO to talk to Stripe. Rather than rely
on monad transformers or mtl-style classes to manage these different
layers, I use plain old functions. Each API method needs to be passed
a handler for running database actions. Will this be a pain in the
ass? Probably not. It's also the easiest style to change FROM, should
that become necessary.

The library maintains its own notion of what a "Patron" is. To
interface with the website, I created ToMechPatron and FromMechPatron
type classes. These are easy to define for the User type. Thus, it's
easy to create a relationship between "website Users" and "crowdmatch
Patrons".

### 2.b. Usage example

Here's a usage example that covers these parts so far.

Given:

fetchPatron
:: (ToMechPatron usr, MonadIO io, MonadIO env)
=> SqlRunner io env
-> usr
-> env Patron

You can run:

someHandler = do
Entity uid user <- requireAuth
patron <- Crowdmatch.fetchPatron runDB uid
...

See how 'runDB' is passed in as the database runner.

### 2.c. Exported actions

There are about ten operations that will be exported, as well as a
handful of data types. I am starting with fetching, storing, and
deleting two items: payment-method tokens and pledges. The payment
tokens are what Stripe gives us in lieu of credit card info. Pledges are
what you think they are: the record of a donor pledged to a project.

Next in the API are two super important methods (prototyped but not
implemented yet): 'runCrowdmatch' and 'processPayments'.

The first looks at all pledged patrons and calculates an outstanding
donation balance. After a crowdmatch event, each pledged patron will
then "owe" a certain amount to the project. That all happens in the
database in a single transaction.

Later, at our leisure, we can run 'processPayments'. That method
inspects outstanding balances and sends payment commands via
Stripe. This is where fee limits take effect.

The website won't trigger the crowdmatch event or payment processing.
Instead I'll have two simple utilities that do that stuff. I'll just
run them manually at first.

This section was longer than I intended, but that's probably good.
It's one of the more important. Feedback on the API is highly welcome.

API to date:
https://git.snowdrift.coop/sd/snowdrift/blob/split-mechanism/crowdmatch/src/Crowdmatch.hs#L24

### 3. Database management

Since this library requires a database, it requires database
management. Like I said, it uses Persistent, and has its own 'Model'
module that works like the website's Model, where the database 

Re: [Snowdrift-dev] Issues with Snowdrift.coop's Production Branch

[Bryan Richter]

On Thu, Oct 20, 2016 at 08:47:00AM -0500, Jason Harrer wrote:
> On Wed, Oct 19, 2016 at 8:03 PM, Bryan Richter <br...@snowdrift.coop> wrote:
> 
> > Moving this to the Dev mailing list (Jason, are you on it?)
> >
> > Jason wrote:
> > >
> > > Hi, Bryan -
> > >
> > > As you requested, I was working on the code to put up a banner for
> > > when a member logs in but their e-mail is not yet verified.  Also, as
> > > you requested, I created this code on top of the production branch and
> > > not the master branch.
> > >
> > >- When attempting to log in as admin, I put in the username & password
> > >(both "admin") and clicked submit, but then I got back to the main
> > screen,
> > >where the button still said "Log In" instead of my name and
> > libravatar.
> >
> > This could be due to an empty database. To use the old site, you would
> > have to use the old methods for setting up the template data. Remember
> > to run `./sdb.hs init`.
> >
> 
> I'm pretty sure I tried that, but just to be sure, I just cleaned and
> re-initialized the database:
> 

> 
> This does look different than what I recall from the past, but I believe
> there was additional work on sdb.hs since last I used it, so I'm going to
> go out on a limb and assume that the output has been intentionally changed.

Correct.

> After the clean and init, I have the same issue logging in as admin.  Now,
> I'm not sure if the database names were changed or not (I'm struggling
> trying to read through sdb.hs a bit), so going off of what I know, I went
> to look at the snowdrift_development database directly using psql:
> 
> [jazzyeagle@JazzyPuter snowdrift]$ psql --username=postgres
> snowdrift_development
> psql: FATAL:  database "snowdrift_development" does not exist

What changed is how you access the database. On the production branch,
I recommend running the following before doing any other development:

# Bash-specific
source <(./sdb.hs env)

That sets up environment variables in your shell so that psql and
friends connect to the right database.

> The token for verifying e-mail addresses is what I'm talking about,
> yes.  I know some users on the mailing list use a CLI e-mail client,
> and my apologies, but with Bryan's limited availability to debug,
> screenshots are probably the best way to express what I'm seeing.
> 
> Here's the first registration screen:
> [image: Inline image 1]
> After clicking submit:
> [image: Inline image 2]
> Clicking Submit on this second screen keeps bringing me right back to the
> same screen.

Don't put in an email address at first, maybe? Just guessing.

> At this point, I'm wondering why exactly I was asked to create this branch
> based off the production branch?  Do you think it'd be ok to work on this
> code using the master branch, or is there some reason why I need to do it
> on production?

Unfortunately, yes, it has to be done in production, because the plan
is:

1. Set up this alert on snowdrift.coop (production branch)
2. Wait
3. Migrate users to the new schema
4. Deploy the master branch to snowdrift.coop.

If we changed master instead, the cart would be before the horse. :)


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] Fwd: Issues with Snowdrift.coop's Production Branch

[Bryan Richter]

Moving this to the Dev mailing list (Jason, are you on it?)

Jason wrote:
>
> Hi, Bryan -
>
> As you requested, I was working on the code to put up a banner for
> when a member logs in but their e-mail is not yet verified.  Also, as
> you requested, I created this code on top of the production branch and
> not the master branch.
>
>- When attempting to log in as admin, I put in the username & password
>(both "admin") and clicked submit, but then I got back to the main screen,
>where the button still said "Log In" instead of my name and libravatar.

This could be due to an empty database. To use the old site, you would
have to use the old methods for setting up the template data. Remember
to run `./sdb.hs init`.

Try reading through the docs that are in that version of the site:
https://git.snowdrift.coop/sd/snowdrift/blob/production/BUILD.md

>- Trying to create a new user, I did not get the token needed for
>confirmation (nor was there a field to enter it).

The production site doesn't have tokens for confirming users, does it?
For verifying email addresses, yes, but not for creating a new user.

If that's what you meant, then: I don't actually know if the
production site has any way of testing that verification flow. The new
site does. The old site might just assume that your local computer has
a daemon delivering local, UNIX-y mail.

If you have any idea what I'm talking about, then if you set your email
address to "your-user@localhost", you should get those messages.

Otherwise, manually connect to the development database and toggle the
email_verified column to see the different effects.

>- Clicking the pledge button simply refreshed the page.

Pledging is broken/intentionally disabled in production right now.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] Merge: Adding Stripe

[Bryan Richter]

Feedback appreciated:

https://git.snowdrift.coop/sd/snowdrift/merge_requests/20/diffs


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Hello

[Bryan Richter]

On August 22, 2016 2:10:22 AM GMT+01:00, Tim Lim wrote:
> Hello everyone! Just wanted to say hi -- My name is Tim and I've been
> wanting to work on actual software written in Haskell ever since I
> learned a little bit of it in a programming languages class last year.
> I'll mostly be poking around the codebase and reading guides for now,
> but if anyone can recommend good places to start or starter projects
> to work on I'd really appreciate it!
> 

Hi! I'm chreekat aka Bryan, the lead developer. I'm away from my computer this 
week so hopefully other people can provide useful pointers, but I just wanted 
to say welcome.

-- 
Sorry it's ugly -- I sent it from my phone.
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] adding the mechanism

[Bryan Richter]

I'm ready for the mechanism to get added to the code now. Here's what
I want.

1. Let's not create a separate Cabal package, after all. Based on the
success (so far) of AuthSite.hs, I think it's enough abstraction to
have distinct tests and a good module interface.

2. All actions should be recorded with timestamps into an Event table.

3. The API for the module should be event-based. The conceptual model
is "reactive", meaning that the outputs are a time-dependent value of
the inputs.

Inputs:
1. Patron joins the crowd at time t
2. Patron leaves the crowd at time t
3. Patron makes a donation at time t

Outputs:
1. Number of patrons in the crowd at time t
2. Current pledge value at time t
3. Patron X's crowd membership at time t
4. List of Events that occurred before time t

Behind the scenes we'll just bash it into place by separately
inserting a row in the Event table for each modification made to other
data. Eventually it would be Rad to actually build something reactive
in the database layer, but that's not on the critical path.

Separately from the mechanism, we need to interface with
$PAYMENT_PROVIDER. Internally, we've sort of been talking as if that's
Stripe. I think we should just make that official and start reading
their API and figuring out what the UX is and what the business rules
are.

I'll be (out of the country)^2 for the next week so I won't be working
on this personally just yet. :)


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Mechanism

[Bryan Richter]

On Tue, Aug 09, 2016 at 01:35:55PM -0600, Peter Harpending wrote:
> Hi, everyone,
> 
> I wrote a mechanism library a few months ago, which I don't believe
> was ever merged into the main code tree. Then, I had summer classes,
> and several deaths in my family, so I haven't been paying much
> attention to the mailing lists/IRC. I'd like to start contributing
> again, preferably in small doses.
> 
> Would someone mind catching me up on what I've missed and/or give me
> suggestions for things to do between now and the new semester?

Well, I moved to Finland for the summer, for starters. :)

I finished writing an auth subsite, which you can now find at
website/src/AuthSite.hs. That's merged to master and deployed to
dev.snowdrift.coop.

The next milestone is deploying master to the main website. There's a
bunch of user stories with the tag "master-to-production":

https://tree.taiga.io/project/snowdrift/search?text=master-to-production

The purpose of that milestone is to heal the painful gap between the
master branch and the production branch. I want continuous deployment
back.

The summary of work to be done is that we need to preserve important
legacy URIs and migrate the user table. We're really close to
finishing the former. I was about to start the latter.

MVP is getting more and more concrete. We still need a dashboard UI, a
project-page UI, and a payment-history UI. These are higher-priority
than the actual backend mechanism, since (a) they define its
parameters and (b) they're a lot harder to design. There has been
discussion on all these fronts on the design mailing list. I am hoping
we can focus on one of them and knock it out in the next 1.5 weeks.

I'm still not very happy with our task management "solution". People
have to sign up for too many services [queue Aaron reiterating his
desire for a single sign-on, single solution website]. But I'm also
feeling more comfortable with Taiga. I started using sprints as a
way to help focus effort. I think it's helping.

This evening, I'll be triaging the issues and user stories and
building the next two sprints. 19:00 UTC, jitsi.

Speaking of continuous deployment, something that would be great for a
volunteer to work on is continuous integration. Gitlab has all kinds
of support built in. I've been ignoring the promotional emails they
send about it. But since we have a dedicated instance, there should be
nothing preventing us from setting it up.

If you want to help with that, try setting up a clone and
experimenting with it first.

Thanks for the continued interest in helping. I really appreciate it.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Taiga: request for issue comment permission

[Bryan Richter]

On Wed, Aug 03, 2016 at 11:23:39PM +0200, tuxayo wrote:
> On 03/08/2016 08:22, Bryan Richter wrote:
> > Unfortunately, Taiga doesn't let me add people by their account
> > handle. I sent an invite to your email address instead.
> > 
> > So there are two problems: (1) You can't send a request directly
> > from the site; you have to send a separate email instead. (2) We
> > can't invite people based on their usernames.
> 
> Thanks, I received the invitation :)
> 
> > They have a Taiga issue for (1). Go here and vote up this issue if
> > this bothers you like it bothers me:
> > https://tree.taiga.io/project/taiga/issue/3735
> > 
> > There is a separate github issue about (2):
> > https://github.com/taigaio/taiga-front/issues/903
> > 
> > (If that's not ironic, I don't know what is.)
> 
> What is also ironic is that more people are participating in the
> GitHub issue than in Taiga's because non project members can't
> comment on Taiga issues.
> 
> Isn't that also a problem for us?

Absolutely, yes. We have the problem either way, however, as long as
we are avoiding Github on ideological grounds.

> I guess the benefits of Taiga issues compared to GitLab issues
> outweigh that limitation right?

People would still have to sign up for our personal Gitlab instance.

The original plan was to do *everything* on the Snowdrift website, but
that plan was too ambitious. Now we are in a bit of limbo. :( Let's
get launched and see what we can do to improve things afterwards.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Taiga: request for issue comment permission

[Bryan Richter]

On Tue, Aug 02, 2016 at 11:59:14PM +0200, Victor/tuxayo wrote:
> Hi,
> 
> I tried IS-400 and would like to share progress. And Taiga seems the
> most appropriate place to do so. Therefore I need the comment permission
> on the issues.
> 
> Taiga account handle: tuxayo

Unfortunately, Taiga doesn't let me add people by their account
handle. I sent an invite to your email address instead.

So there are two problems: (1) You can't send a request directly from the
site; you have to send a separate email instead. (2) We can't invite
people based on their usernames.

They have a Taiga issue for (1). Go here and vote up this issue if
this bothers you like it bothers me:
https://tree.taiga.io/project/taiga/issue/3735

There is a separate github issue about (2):
https://github.com/taigaio/taiga-front/issues/903

(If that's not ironic, I don't know what is.)


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] hlint on commit

[Bryan Richter]

On Sat, Jul 23, 2016 at 03:11:36PM -0700, Aaron Wolf wrote:
> 
> I have vim set up to automatically run hlint whenever I save a file
> (via syntastic I believe), but I don't know how to make that use the
> -XQausiQuotes argument.
> 

:help syntastic

That'll probably get you headed in the right direction.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] /p/snowdrift

[Bryan Richter]

On Wed, May 18, 2016 at 12:39:32PM -0600, Peter Harpending wrote:
> On Wed, May 18, 2016 at 02:23:01PM -0400, Stephen Michel wrote:
> > I don't understand exactly why it's a corner case. Under the current system,
> > wouldn't /p/snowdrift/ eventually be coded the exact same way as any other
> > project, so new projects would be prevented from using `snowdrift` as a slug
> > in the same way that they'd be prevented from taking the slug of any other
> > existing project?
> 
> N.B. I'm using the coqdoc convention of putting code in [square braces].
> 
> No. As it's implemented now,[SnowdriftProject] is in its own data type, 
> defined
> in config/models.

No it isn't. :)

There is now no SnowdriftProject type, nor should there ever be.

Stephen is right; this is not an issue yet. The "/p/snowdrift" route
will go away, replaced by "/p/#ProjectSlug", and the snowdrift project
will be the obvious owner of the ProjectSlug that corresponds to the
route "/p/snowdrift".


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] Make Snowdrift project wiki search redirect to the gitit wiki

[Bryan Richter]

On Tue, May 17, 2016 at 12:25:08PM -0600, Peter Harpending wrote:
> On Tue, May 17, 2016 at 09:12:30PM +0300, fr33domlo...@riseup.net wrote:
> > From: fr33domlover 
> > 
> > ---
> >  website/Snowdrift.cabal | 1 +
> >  website/config/routes   | 1 +
> >  website/src/Handler.hs  | 4 
> >  3 files changed, 6 insertions(+)
> > 
> > diff --git a/website/Snowdrift.cabal b/website/Snowdrift.cabal
> > index 5cf461c..0994000 100644
> > --- a/website/Snowdrift.cabal
> > +++ b/website/Snowdrift.cabal
> > @@ -61,6 +61,7 @@ library
> >  MultiParamTypeClasses
> >  GeneralizedNewtypeDeriving
> >  RecordWildCards
> > +ViewPatterns
> >  
> >  -- build-depends {{{2
> >  build-depends:
> > diff --git a/website/config/routes b/website/config/routes
> > index e2f9d0d..510423c 100644
> > --- a/website/config/routes
> > +++ b/website/config/routes
> > @@ -20,3 +20,4 @@
> >  /merchandise MerchandiseR GET
> >  
> >  /p/snowdrift SnowdriftProjectR GET
> > +/p/snowdrift/w/#Text SnowdriftWikiSearchR GET
> > diff --git a/website/src/Handler.hs b/website/src/Handler.hs
> > index 9506a50..d1c3f1d 100644
> > --- a/website/src/Handler.hs
> > +++ b/website/src/Handler.hs
> > @@ -72,3 +72,7 @@ getMerchandiseR = $(widget "page/merchandise" 
> > "getMerchandiseR")
> >  -- For MVP, there is one, hard-coded project: Snowdrift
> >  getSnowdriftProjectR :: Handler Html
> >  getSnowdriftProjectR = $(widget "page/snowdrift-project" "Snowdrift.coop 
> > Project")
> > +
> > +getSnowdriftWikiSearchR :: Text -> Handler Html
> > +getSnowdriftWikiSearchR slug =
> > +redirect $ "https://wiki.snowdrift.coop/_search?patterns=; <> slug
> > -- 
> > 1.9.1
> 
> I don't have colorized diffs in my email client, so take my input with a grain
> of salt.  That said, it looks fine, and this is a good feature to add. My only
> question is: why do we need ViewPatterns? I'm not necessarily opposed to it, 
> I'm
> just curious.

The default scaffolding uses them. I removed them as "unused" when I
set up the new scaffolded code. It was a bit hasty. :)


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] What are the folders to purge to fix or prevent build issues?

[Bryan Richter]

On Sat, May 07, 2016 at 02:15:22PM +0200, Victor/tuxayo wrote:
> On 06/05/2016 19:44, Aaron Wolf wrote:
> > While this stuff about purging is documented at the Stack docs and
> > otherwise, I could see adding to BUILD a statement referencing that the
> > total list of things to possibly purge includes `sdb.hs clean` and
> > purging .stack-work and then ~/.stack and, of course, the project
> > directory itself (and, I guess finally: whatever system things were
> > installed). I'm not sure that's needed, but it's nice to have a full
> > list of "things affected by building and running this"…
> 
> What about adding this as a "Manual rebuild" sub section? Just after
> "Updating static files":
> https://git.snowdrift.coop/sd/snowdrift/blob/master/BUILD.md#updating-static-files

There's a "manual rebuild" section right *before*
updating-static-files. :) You could add some content to that section,
however (and maybe that's what you meant).


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] What are the folders to purge to fix or prevent build issues?

[Bryan Richter]

On Fri, May 06, 2016 at 01:09:10PM +0200, Victor Grousset wrote:
> On 04/05/2016 19:48, Aaron Wolf wrote:
> > There are no other directories to purge unless you already ran the site
> > and have database stuff to deal with. To clean out database stuff, it's
> > better to use the sdb.hs tool rather than manually clean things though.
> > 
> > although it shouldn't cause any troubles if you stopped in the middle of
> > a build or anything. Purging shouldn't be needed…
> 
> Few month ago I also crashed during a build(I still haven't fixed my
> stability issues...) and had to purge at least .stack-work to be able to
> build.
> 
> 
> > $PROJECT_ROOT/.stack-work should always be purged first when purging
> > 
> > ~/.stack should never need purging per se, but for cleanliness or to be
> > just certain, it can be purged, but it should be purged along with or
> > after the purge of $PROJECT_ROOT/.stack-work
> 
> Thanks for all the info, is there a wiki page or a file in the
> repository where I could document that?
> (a dev FAQ or something)

Perhaps we should wait to see if it is frequently asked. :)

We can put in a link to http://haskellstack.org in the docs, if we
haven't already. Honestly I'm not sure where it should go, however. I
have trouble keeping BUILD/README/CONTRIBUTING straight. Aaron?


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Code reboot going into master

[Bryan Richter]

On Sat, Mar 19, 2016 at 06:12:39PM +0200, fr33domlover wrote:
>
> On Fri, 18 Mar 2016 15:01:12 -0700 Bryan Richter wrote:
> > 
> > We *could* keep going, and update the basic scaffold code to the
> > latest version coming out of the yesod-scaffold library, but I'm
> > not sure it is of the highest priority.
> 
> I started a yesod app recently using the same template, so I'm
> familiar with the recent scaffolding. I already examined the
> differences. If you like, I can make a patch, but there are a few
> issues:

In general, there will be a high bar for success for such a patch,
since it could possibly impact progress on higher priority items.
However, I think it is possible to do.

> 1. The new scaffolding uses a new config module, there is no "yesod
> exec snowdrift Development" anymore. If you want dev mode, you
> either "stack build --flag Snowdrift:dev" or specify "dev: true" in
> stack.yml or "default: True" in Snowdrift.cabal . It's fine, just
> saying this thing will change a bit.

Right, that would be a welcome change.

> 2. All that custom runYDB and runSDB and runSYDB - do we even want
> it? Yesod has just the simple runDB, I'm not sure we need these
> extra functions just for event notifications. Anyway this doesn't
> intefere with the scaffold, just adds on top.

Yeah, I think more of those are about to go away. In fact, they will
probably all go away, back to the scaffolding default. That work would
be appreciated.

> 3. There are other custom things, like the auth plugins in
> Foundation.hs . Need to see (assuming they're in the reboot too) if
> we want them or we want to reset them to the default scaffolding's
> version

They're in the reboot, it's true, but there are some tasks to do to
clean up the situation. Our auth needs are still custom. The default
scaffold will not work. That will be the next thing to work on after
making sure everything is in good shape for the web developers (css
framework and templates framework).

> 4. What about the `/u/username` thing? Do we want it for the reboot,
> should it be taken into account in any way?

I think this is a separate question; one that I do not know the answer
to. Waiting on product requirements...

Thanks!


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Mechanism implementation

[Bryan Richter]

On Tue, Mar 15, 2016 at 12:50:00AM -0600, Peter Harpending wrote:
> I need to go to bed, but tomorrow, I'll try to work on gluing the
> mechanism to the rest of Snowdrift.

I would hold off on doing this, or at least run your plan past me
first. It involves core architecture decisions.

Thanks!


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Mechanism implementation

[Bryan Richter]

On Tue, Mar 15, 2016 at 09:13:53AM -0600, Peter Harpending wrote:
> On 03/15/2016 12:50 AM, Peter Harpending wrote:
> > code that requires one to use the feature, so I vote that
> 
> Silly me, I forgot to mention how I vote. I vote that we leave it for
> now, because it's unlikely to cause any problems. We can always remove
> it if it does.

I feel like it already has caused problems; namely, questions and
confusion. It also creates additional maintenance and testing burden.
All these problems compound with time. I feel strongly that unused
features must be removed. (This is the same exact thing Snowdrift is
grappling with as a whole.)

We can always reach into git history and bring it back if we need it.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] A note on Yesod Forms and Widgets

[Bryan Richter]

On Tue, Mar 15, 2016 at 09:23:44PM -0700, Aaron Wolf wrote:
> On 03/15/2016 09:20 PM, Bryan Richter wrote:
> > On Tue, Mar 15, 2016 at 09:13:49PM -0700, Aaron Wolf wrote:
> >>
> >> Are you saying that correct use of Yesod Forms will always generate
> >> the html  element?
> > 
> > I think I may be misunderstanding your question, but I would say the
> > precise opposite is true.
> > 
> > Yesod Forms do not generate  elements. If a developer is using a
> > Form, they must add the  element themselves.
> > 
> > Conversely, if a programmer is *defining* a custom, monadic Form, they
> > should *not* include a  element.
> > 
> 
> Okay, I think I understand that html can have what is effectively forms
> in that there are inputs and fields and no  is actually there in
> the markup. Is that okay? Or should forms always be in html  blocks?

In a valid HTML document, any form elements like  *must* be
nested within a . We will never send HTML to the browser where
that isn't the case.

But, the Widget that a Form provides is not an HTML document. It is a
*snippet* of HTML.

In other words, the Widget that a Form provides can potentially be
misused. It can be misused because you *could* place it somewhere
*besides* within a , and you would be creating malformed HTML.

However, there is never a reason to do that. One should always place a
Form's Widget underneath a . The consequences will often be
obvious bugs.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] A note on Yesod Forms and Widgets

[Bryan Richter]

On Tue, Mar 15, 2016 at 09:13:49PM -0700, Aaron Wolf wrote:
> 
> Are you saying that correct use of Yesod Forms will always generate
> the html  element?

I think I may be misunderstanding your question, but I would say the
precise opposite is true.

Yesod Forms do not generate  elements. If a developer is using a
Form, they must add the  element themselves.

Conversely, if a programmer is *defining* a custom, monadic Form, they
should *not* include a  element.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] A note on Yesod Forms and Widgets

[Bryan Richter]

I think there is some confusion about how Widgets are used for Yesod
Forms.

Yesod Forms (I'll just use capital 'F' when I mean a "Yesod Form")
hare pretty fancy. Some might say... TOO fancy. They take care of a
lot of things:

1. Defining the Haskell data that comes out of them
2. Defining what the body of the  looks like
3. Defining how to validate the data they should accept

One thing they explicitly do NOT do is generate a . That's
because they are used in a lot of different ways (because of how
fancy they are).

If a web designer wants to include a Form in a template, they must
write it like this:


  ^{formFooBar}

In other words, they have to explicitly include a  element.

Conversely, someone creating a custom Form should NOT add a 
element to the Form's Widget.

In the example code above, "formFooBar" is a Widget that comes from
the Form. Note that like all Widgets, it is created in Haskell-land.
Perhaps some day it can be generated automatically based on its name,
but for now it is not, and a Haskeller has to provide it to the web
designer. (Of course, the Haskeller and the web designer could be the
same person...)



signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] sw architecture drawing

[Bryan Richter]

I took a first pass at drawing the software architecture:

http://flurry.snowdrift.coop:2040/shared/pnv4YSuKmLQtfG6ZYHcBSeVng5TfRFwNtnRxL1vYVn_

I must stress that this is inaccurate and includes some wishful
thinking. It is also incomplete. I think there are some components
that will arise, like the Thing, from the swamp of existing code.

However, it's a starting point. We can begin to talk about the
%-completeness of various components.

Any feedback?



signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] DB admin code

[Bryan Richter]

On Wed, Mar 09, 2016 at 08:58:51PM +0200, fr33domlover wrote:
> I found this in Keter, maybe we can (re)use it somehow instead of hacking our
> own?
> 
> http://haddock.stackage.org/lts-5.6/keter-1.4.3.1/Keter-Plugin-Postgres.html#v:setupDBInfo

The whole point of sdb.hs was to avoid using sudo. Plus, the
functionality would have to be pulled out into a standalone library to
benefit from sharing. I'm not sure the effort would be worthwhile.

Good catch though.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] User nicknames as public user IDs: Change UserR route

[Bryan Richter]

On Tue, Mar 08, 2016 at 04:39:11AM +0200, fr33domlover wrote:
> On Mon, 7 Mar 2016 16:39:11 -0800
> Bryan Richter <br...@snowdrift.coop> wrote:
> 
> > Can I pass the tasks on to someone else who can take the time to
> > figure out the best way to use OpenProject?
> 
> Personally I'm not exactly excited about taking that role, unless OP
> can be used conveniently from the terminal / text-based web browser
> / email client, but regardless - do we have a documented workflow
> for using it? Maybe you can push tasks to some TODO file / etherpad
> / email. So far I like the use of the dev ML and IRC for that: You
> mention a task, a dev picks it up and sends a patch or MR.

I like the idea of the ML too, though only for pushing notifications
and discussing tasks. It's not gonna cut it for tracking them. Design,
development, *and* users need to be able to track tasks.

Sadly, I just checked, and OpenProject flatly does not work without
Javascript. That is unfortunate. I still suspect OpenProject will
become THE tool for tracking tasks.

> The same applies to me and any other volunteer here: When someone
> has some idea / proposal / problem / suggestion, where do they put
> it? OP or mailing list or Snowdrift wiki?

Everyone is always welcome to send suggestions to the mailing list,
and somebody will take care of triaging it. In the shortest of terms,
that could even just mean I add it to my large list of tasks.

Eventually, everything will end up in OpenProject, however.

The "Snowdrift wiki" is one of the things being removed, by the way.



signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] User nicknames as public user IDs: Change UserR route

[Bryan Richter]

On Mon, Mar 07, 2016 at 02:39:07PM -0800, Aaron Wolf wrote:
> In this case, I'm fine with moving forward but only if it's otherwise
> clean progress.

Ok, if design is fine with it (which was expected) we come to a bigger
problem.

Right now I'm working to strip out unnecessary features and prototype
code. So far, that has resulted in 9,000 lines of code removed.

9,000.

Yes, that is more than what's left. It's also as many as a good-sized
novel.

https://github.com/snowdriftcoop/snowdrift/compare/master...chreekat:reboot?expand=1

IMO this project is dead and we don't know it yet. We HAVE to continue
stripping out unusable code in order to resuscitate it.

Doing so, of course, massively conflicts with the changes you (fr33)
are making; changes that are hard to make precisely because there's so
much dead weight. This causes me — and presumably you — some tension.

> I definitely want to see *all* the stuff connected to work packages in
> OP when it's not just minor typo fixes etc. And to that end, I hope the
> dev team will already work to add stuff to OP and add more concrete
> tasks to the existing user stories to make the already entered items
> complete.

I still can't make heads or tails of OpenProject. I don't think I can
take on the project manager role of managing that tool. And it
*should* be managed, by some one person or another. I guess that's
a different topic.

To be more *on* topic, the act of stripping out dead code is creating
some new tasks. I definitely want to share them and all that.
OpenProject is the tool to do it with. Can I pass the tasks on to
someone else who can take the time to figure out the best way to use
OpenProject?

(Apologies for cross posting to discuss@, but there's some larger
topics here and I want to include more people.)


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] User nicknames as public user IDs: Change UserR route

[Bryan Richter]

Before I comment on this patch, I think we should make sure that
Snowdrift.coop at large is ok with this change, and that that "ok" is
made real by adding the feature to OpenProject.

I want to get in the habit of doing feature-work that is in
OpenProject, and only that is in OpenProject. From the designer/owner
side, that ensures they get a chance to approve and prioritize work,
and from the developer side, it means we have a clear understanding of
new development we're responsible for. I think both aspects are
equally important.

Still, this is probably a good thing, so I've pushed this commit to a
new branch to ease collaboration.

https://git.gnu.io/snowdrift/snowdrift/tree/user-nicknames

On Mon, Mar 07, 2016 at 02:13:07PM +0200, fr33domlover wrote:
> From: fr33domlover 
> 
> Making UserR take a Text that refers to a whole new User field is a big
> change. Many handlers and templates need to be updated. Therefore please
> read below carefully to understand my plan and what exactly this commit
> does.
> 
> The GOAL is to move all UserId-based routes to use UserHandle instead,
> which is Text. That "handle" references a new 'userNick` field in the
> User table. But since this is a huge change, this commit does a smaller
> change. The rest will come in the next patches. What this commit does
> is:
> 
> 1. Update the UserR route and add a deprecated UserByIdR route
> 2. Add the 'userNick' field to account creation and account update forms
> 3. Require a pattern for the 'userNick' field to avoid all-digit
>nicknames and other potential issues
> 4. Fix all handlers and templates to pass the 'userNick' to 'UserR'
>instead of the 'userId'. That includes inserting 'get404' calls in
>several places just to get the User value, and other helpers that
>will be removed later. They are used just so that the code builds and
>works after applying this patch.
> 
> The next patch(es) will update all the other handlers and probably
> change some of the helper functions to work with the new 'userNick'
> field.
> 
> Before this gets committed, some input/review from dev and desig teams
> will be great. But don't be pedantic, as the next commits will change
> many things and will remove some of the ugly parts used here
> temporarily.
> 
> I suggest we make this change in 2 steps because it's so big:
> 
> 1. Change the routes and UI as needed, and do whatever is needed to make the
>code build again
> 2. When done, refactor and add helpers and put all the chaos back to order
> ---
>  config/models|   7 +
>  config/routes|   3 +-
>  src/Foundation.hs|  24 +++-
>  src/Handler/NewDesign.hs |  19 ++-
>  src/Handler/Project.hs   |  20 +--
>  src/Handler/User/Comment.hs  |   1 +
>  src/Handler/User/Delete.hs   |   3 +-
>  src/Handler/User/Edit.hs |   7 +-
>  src/Handler/User/NewDiscussion.hs|   1 +
>  src/Handler/User/Notifications.hs|   3 +-
>  src/Handler/User/ProjectNotifications.hs |   3 +-
>  src/Handler/User/SelectProject.hs|   3 +-
>  src/Handler/User/User.hs |   3 +-
>  src/Handler/User/Utils.hs|   2 +-
>  src/Handler/Who.hs   |  10 +-
>  src/Model/Transaction.hs |   2 +-
>  src/Model/User.hs|   7 +-
>  src/Model/User/Internal.hs   |  18 +--
>  src/View/SnowdriftEvent.hs   |  22 +--
>  src/View/User.hs |  37 -
>  templates/application.hamlet |   2 +-
>  templates/auth/create-user-form.hamlet   |  12 +-
>  templates/comment.hamlet |   7 +-
>  templates/default/navbar.hamlet  |  35 ++---
>  templates/invite.hamlet  |   8 +-
>  templates/navbar.hamlet  |   8 +-
>  templates/project_patrons.hamlet |   2 +-
>  templates/project_transactions.hamlet|   2 +-
>  templates/sponsors.hamlet| 226 
> +++
>  templates/tag.hamlet |   2 +-
>  templates/user.hamlet|   2 +-
>  templates/user_discuss.hamlet|   2 +-
>  templates/user_discussion_wrapper.hamlet |   2 +-
>  templates/user_tickets.hamlet|   2 +-
>  templates/users.hamlet   |   2 +-
>  templates/who.hamlet |   4 +-
>  templates/wiki_history.hamlet|   2 +-
>  tests/TestImport.hs  |   2 +-
>  38 files changed, 295 insertions(+), 222 deletions(-)
> 
> diff --git a/config/models b/config/models
> index a592753..bf64b14 100644
> --- a/config/models
> +++ b/config/models
> @@ -16,6 +16,12 @@ Transaction
>  
>  User
>  ident Text
> +-- ^ Private login name, never shown in UI, may be an email address in 
> the
> +--   case of Persona logins.
> +

Re: [Snowdrift-dev] Updating to work with github-0.14 (in LTS)

[Bryan Richter]

On Sun, Mar 06, 2016 at 12:09:07PM +0200, fr33domlover wrote:
> On Wed, 2 Mar 2016 13:31:59 -0800
> Bryan Richter <br...@snowdrift.coop> wrote:
> 
> > The github package is in LTS now, but it changed its interface to use
> > better types (Text, Vector, and vanilla UTCTime). I spent a bit of
> > time trying to upgrade the code, but decided to pass on it for now. If
> > someone else wants to update the code to work with github-0.14, so we
> > can drop github-0.13.2 from the list of extra-deps in stack.yaml, that
> > would be great.
> > 
> > -B
> 
> I sent a patch. It's not perfect (e.g. contains a TODO comment which suggests
> some further polishing) but handles all the module and type changes.

Applied. Thanks!


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] Add new route /u/

[Bryan Richter]

On Mon, Mar 07, 2016 at 03:30:00AM +0200, fr33domlover wrote:
> On Tue, 1 Mar 2016 16:27:41 -0800 Bryan Richter wrote:
> 
> > ** Tech action items
> > 
> > - UserHandle should be redefined to Text
> > - The existing route should be renamed getUserByIdR and should use
> >   UserId instead of UserHandle
> > - The new route should get the original name UserR
> 
> One thing I noticed when I started working on the code is that
> UserHandle is confusing. I checked what that type is used for. And
> it's used exactly for one thing: The type of the path piece in the
> routes file.

... So far. :) It was only just created. I did so to provide a layer
of abstraction. I'd rather have it than a bare Int or Text.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] Bug: Ticket page: Help link goes 404

[Bryan Richter]

On Tue, Feb 16, 2016 at 08:42:28AM -0800, Aaron Wolf wrote:
> On 02/16/2016 03:23 AM, Victor (tuxayo) wrote:
> > Hi,
> > 
> > To report another problem I wanted to create a ticket.
> > But I forgot how to do it.
> > And on the ticket page:
> > https://snowdrift.coop/p/snowdrift/t
> > The link "More details at the Snowdrift.coop tickets wiki page. "
> > Goes 404.
> > 
> > Since I still don't know how to create a ticket, I'm reporting this here.
> > 
> > Cheers,
> > 
> 
> Thanks, I just pushed a fix. It will go live as soon as Bryan deploys.

Deployed!


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Dev] New design launch: walkthrough of remaining steps

[Bryan Richter]

I've merged together all the groundwork that mray, jazzyeagle, and I
have accomplished the last couple weeks:

https://git.gnu.io/chreekat/snowdrift/merge_requests/1

At this point, I don't think it's ready to go live at *all*.

What I would like to do is walk through the pages and discuss what
*minimum* work must be done in order to go live. I expect all the
pages to have flaws, and I expect some pages to remain unwritten, but
I want to reach consensus about what gaps and flaws are acceptable.

I think this would be done best in real-time, so I propose we schedule
some video chats to do this.

There are thirty three pages to walk through, so I don't expect to do
them all at once.

I suspect the people most likely to be involved are jazzyeagle,
wolftune, mray, and myself. Anyone else is of course welcome to
participate.

I suggest kicking things off at 1pm PST (21:00 UTC) today.

I also suggest we use fr33domlover's instance of WeKan to track tasks
for this milestone, which I am calling the "framework launch" for lack
of a better term. I created a board:

http://board.rel4tion.org/b/DDXqDfzNPeqfRGYTM/framework-launch

Note that it's unsecured, so don't reuse a password to sign up. But if
you want to maybe tackle some of the tasks we come up with, please do
create an account. I'm not suggesting we start using this full time
yet, but I think it's a good thing to try out for this one push.

tl;dr: Meeting today 21:00 UTC to discuss remaining work for the
framework launch. https://beta.meet.jit.si/snowdrift


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Dev] Current dev work

[Bryan Richter]

Hi all,

There have been a few video chats recently, and I wanted to briefly
summarize some of the discussion to make sure everyone is included.

* We set a psuedo-random goal of having an "alpha" release
  before the SCALE conference[1] on January 21–26.

* We have been clarifying the goal for that release on an
  Etherpad document, https://v.etherpad.org/p/snowdrift. The goal
  takes the form of a prioritized list of pages. The goal needs a lot
  more clarification. Each page still has entirely ad-hoc
  specifications. While there are many questions to answer, I think an
  important one is "Which pages should a particular page link to?". We
  will iterate the design and begin to document these specifications
  as tests.

* Robert (mray) has been creating a design framework[2] for the
  site, replacing the existing ad-hoc, Bootstrap-ish style. It looks
  awesome. :)

* Robert has also been creating new versions[3] of important pages
  using his design framework. He is creating non-interactive versions
  with html and css.

* Jason (JazzyEagle) has taken the lead on wiring up Robert's new
  creations to the data model. There will be a lot of work in this
  area that can be done in parallel. It'll be a great place for anyone
  to help out and make contributions.

* I (Bryan, chreekat) will create fresh skeleton versions of each page
  on the Etherpad document in the next two days. This will be the base
  on which we will iterate the design and specifications of the pages
  in question. These new skeleton pages will go live (!!) asap, so we
  can be agile and stuff. :P But no, seriously, the idea is to show
  visible progress (even if it looks ugly) and provide a sandbox in
  which to work towards alpha.

* I mentioned Jason's area as being one where others can contribute.
  Well, my hope is that Robert's area is also one where others can
  contribute. Part of the reason I want to knock out the skeleton
  version of everything is so that people can say "Oh I'll do that
  page" and build some html/css without having to touch any Haskell at
  all.

Ok dang that's all for now. I got some skeletons to shake out. But if
any of this has sparked any thoughts, concerns or questions, please
fire back an email. :)

[1]: SCALE.
 https://www.socallinuxexpo.org/scale/14x
[2]: Design framework.
 https://github.com/mray/Snowdrift-Design/
[3]: New pages.
 https://git.gnu.io/mray/snowdrift/commits/new-home-and-intro



signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] More test speedup?

[Bryan Richter]

On Tue, Aug 18, 2015 at 12:24:30PM -0700, Curtis Gagliardi wrote:
 I meant to follow up earlier, but for the record I couldn't figure how
 to apply these changes to the tests.  From what I remember his speedups
 came from flushing and closing stdin, while we never even create a
 handle for stdin in withExecutable.   We also don't wait for all of
 stdout, we just kill the process as soon as we get what we want, so I
 don't think waitForProcess would help us.  I experimented with these
 things and couldn't get any speedup, but I don't understand the
 underlying problems that Gabriel fixed to say for sure I was doing
 solved the problems he had.

Well, I think your time spent was productive, so thanks! We might need
to approach this a different way.

Let me provide more details to (what I think is) the problem. Haskell
and the operating system are interacting poorly: buffered console
output is taking too long to get piped back to the test, or doesn't
pipe at all until a miracle occurs. Flushing the stream and closing
the handle are two ways to invoke such a miracle. Without them, the
test twiddles its thumbs for a while. With a 4-second killswitch, I
occasionally get tests that fail because the output *still* hasn't
come through in those four seconds.

Ideally those tests would each take milliseconds (not 1-4 seconds) and
we wouldn't have nondeterministic false negatives.

We could also look at modifying the executables (SnowdriftEmailDaemon
and SnowdriftProcessPayments) and see if we couldn't make them more
test-friendly.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] Bake on Gitlab

[Bryan Richter]

On Mon, Aug 10, 2015 at 11:29:36AM +0300, Nikita Karetnikov wrote:
 FYI, I renamed the project to snowdrift-ci because I'm no longer
 planning to use Bake:
 
 https://github.com/ndmitchell/bake/issues/15#issuecomment-129343416

I have a lot of concerns about this. I am concerned about starting yet
another in-house project that solves problems that have existing
solutions. (FLO solutions, even.) I also haven't seen any concrete
reasons why Bake can't be used.

Over all of this, though, I am concerned that we are spreading
ourselves way too thin. Github + Travis does exactly... *exactly*...
what we need. Can we please make one tiny concession to our present
reality and switch to using it?

Will anyone on this list be forced to stop contributing if we make
Github our primary source location?


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Dev] More test speedup?

[Bryan Richter]

I have a suspicion we might speed up tests with this one trick. From
Gabriel Gonzalez on twitter: I finally fixed the silly delays running
external commands...

His original tweet (with some discussion):
https://twitter.com/GabrielG439/status/624405459370311681

His inspiration:
http://lpaste.net/136737

The change he made to turtle:
https://github.com/Gabriel439/Haskell-Turtle-Library/commit/4f907f177a0fe174e97ee09711d95f015a2346cf

We might want to make a similar change to `withExecutable` in
tests/TestImport.hs. Someone want to try it?


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] Concerns regarding the mechanism

[Bryan Richter]

On Sat, Aug 01, 2015 at 03:08:47AM +0300, Nikita Karetnikov wrote:
  Oh, wow. Thanks for the tip. I will probably do that. Even after
  spending a few hours on this esqueleto, it will still save me time to
  switch.
 
  Just gotta figure out how to share database connection information...
 
 Is it really that bad?  If it's a major slowdown, just go ahead, but
 paste what you've tried.  Also, I'd suggest moving a subselect into a
 separate Haskell function, even with strings.

Here's what is happening so far:

-- | Find underfunded patrons.
-- This function is used after something may have broken the invariant that
-- all funded pledges are covered by the patron's account balance. It 
returns
-- pertinent information about each underfunded pledge.
--
underfundedUsers :: (MonadIO m, Functor m)
 = ProjectId
 - SqlPersistT m [Underfunded]
underfundedUsers projId = do
-- the inner query
totalOutlays - fmap processOutlayRows $
select $
from $ \(pl `InnerJoin` pr `InnerJoin` u `InnerJoin` ac) - do
on_ $ ac ^. AccountId ==. u ^. UserAccount
on_ $ u ^. UserId ==. pl ^. PledgeUser
on_ $ pr ^. ProjectId ==. pl ^. PledgeProject
where_ $ pl ^. PledgeFundedShares . val 0
groupBy $ (u ^. UserId)
return (u ^. UserId
   ,sum_ (($*.) (pr ^. ProjectShareValue)
(pl ^. PledgeFundedShares))
   )
let process' = processIntermediateRows totalOutlays
intemediate - fmap process' $
select $
from $ \(pl `InnerJoin` u `InnerJoin` ac `InnerJoin` pr) - do
on_ $ pr ^. ProjectId ==. pl ^. PledgeProject
on_ $ ac ^. AccountId ==. u ^. UserAccount
on_ $ u ^. UserId ==. pl ^. PledgeUser
return (u ^. UserId
   ,ac ^. AccountBalance
   ,pl ^. PledgeFundedShares
   ,pr ^. ProjectId
   ,pr ^. ProjectShareValue
   ,ac ^. AccountId)
  where
-- | Just cleans up types and removes rows that returned Nothing
-- for the sum. (There actually shouldn't be any because of the inner
-- join, but whatevs.)
processOutlayRows :: [(Value UserId, Value (Maybe Milray))]
  - Map UserId Milray
processOutlayRows = M.fromList
  . catMaybes
  . map sequence -- 'lift' the Maybe
  . unwrapValues

-- | Primarily calculates the available balance for each pledge.
-- That is defined, for each pledge, as the difference between the
-- patron's total balance and the sum of the outlay going to the
-- patron's *other* pledges.
processIntermediateRows :: Map UserId Milray
- [(Value UserId
,Value Milray
,Value Int64
,Value ProjectId
,Value Milray
,Value AccountId)]
- [Underfunded]
processIntermediateRows totalOutlays =
map ( (\(u, a, p, v) - Underfunded u a p v))
. map getAvailable
. unwrapValues
)
  where
getAvailable (UserId, Milray, Int64, ProjectId, Milray, AccountId) =
-- XXX TODO
undefined

 Note that with esqueleto, if you change the schema, you'll get a compile
 time warning.  While with strings, it'll happen at runtime.

True, but I have to accept that risk right now. Tests will help.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] Bake on Gitlab

[Bryan Richter]

On Thu, Jul 30, 2015 at 07:38:45PM +0300, Nikita Karetnikov wrote:
 So I'm looking into Bake integration with Gitlab.  Here's the rough
 plan:
 
 1. Setup web hooks as described here:

 https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/web_hooks/web_hooks.md
 
 2. Parse that on the Bake side.
 
 3. Give Bake push access to master.

Let's take a step back and start with the goals and purpose. Then we
can be sure the plan fulfills them. Here's my proposal:

Gitlab merge requests are a tool we use for code review. That will
always be a manual process, by definition. The review team manually
reads the code, interacts with the contributor, and ultimately accepts
or rejects the patch.

There are some mechanical steps to a good code review, however,
and CI can perform those automatically. The purpose of doing these
things automatically is to provide quick, automatic feedback to a
contributor, as well as to save time and effort from the review
team.  The two primary mechanical tasks are (1) merging the patch
with master, (2) compiling the merged code, (3) testing it, and (4)
reporting on any errors in the first three steps. The goal for bake,
then, is to automate these tasks.

---

I think to satisfy these goals, we *don't* want bake pushing to
master. That should be a manual step. What bake should do instead is
report, by adding comments or tags to the merge request.

 It'd be ideal if Bake could test merge requests, but there are
 some challenges.  There's only one object type for merge requests,
 which can be in multiple states: open, updated, merged, closed.  So
 there doesn't seem to be a way to clearly indicate: test this!

Whether bake does too many builds (e.g. for closed or merged requests)
is not a dealbreaker, but obviously it would be nice to inspect the
web hook payload and only run for open or updated requests.

I take it there is no way to control bake's behavior? It sounds like
that migt be necessary for both how Gitlab interact with bake, and how
bake interacts with Gitlab. If it is not possible, I can think of a
couple possible solutions:

1.  Add hooks on bake's side!
2.  Add a proxy between Gitlab and bake.
3.  Others?

 ...
 Then, the workflow becomes: a user pushes to a feature branch on the
 main repo, Bake takes that as ready for merge and tests; merges if
 appropriate.  Is it possible with Gitlab?

Yes, that would be possible, but I think it would not meet the goal of
automating the mechanical aspects of a code review. I think we want to
test, then review, then merge, in that order.

I'm happy that you're working on this, by the way. I think it would be
a great addition to our workflow.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] Concerns regarding the mechanism

[Bryan Richter]

On Fri, Jul 31, 2015 at 02:41:41PM -0700, Curtis Gagliardi wrote:
 I'd probably drop down to postgres-simple and run that query as is.  I
 don't think the lack of typing needs to be a deal breaker if it's going
 to be easier to write and easier to test.  

Oh, wow. Thanks for the tip. I will probably do that. Even after
spending a few hours on this esqueleto, it will still save me time to
switch.

Just gotta figure out how to share database connection information...


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] GitLab CI

[Bryan Richter]

On Thu, Jul 09, 2015 at 10:40:39PM -0700, Aaron Wolf wrote:
 So, we've been chatting about Continuous Integration… I didn't know
 before about this: https://about.gitlab.com/gitlab-ci/ — fully FLO CI
 designed for GitLab… is there a chance we could use that?

The free version seems to only work for projects on gitlab.com. I can
sign in, but since I have no projects on gitlab.com I can't do
anything.

This is analagous to having free* Travis CI on Github, which is also no
use to us.

Travis! -- needs Github
Gitlab CI! -- needs Gitlab

You see the pattern.

*IF* the person running git.gnu.io set up a local instance of Gitlab
CI, we could use that. Or they could set up any other CI system. Or we
could set one up ourselves.

If we're going to set up one ourselves, it makes sense to use bake,
contributing any necessary features back to the project as they arise.
I say that with no greater rationale than it is also written in
Haskell. Really, if *anyone* makes *any* CI available to our project,
that would be rad.

The hard requirements are:

1. Is triggered by HTTP POST requests.
2. For merge requests, it checks out master, merges the request
branch, runs tests, and reports results.
3. It logs each attempt somewhere accessible.

Ideally, the reporting would be *right in the merge request*, as it is
with Travis on Github. It's actually possible this could be done
without modifying Gitlab, if the CI system could write comments on the
MR's discussion.

* Only free as in beer, of course: Testing your open source project
  is 1% free. Seriously. Always.


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Dev] vim foldmarkers in Snowdrift.cabal

[Bryan Richter]

Would there be any complaints if I added vim foldmarkers to
Snowdrift.cabal? They make it a *lot* easier to navigate, at the
expense of a small amount of extra whitenoise that is presumably
useless to non-vimmers (unless emacs has folding compatibility).

The change:

https://git.gnu.io/chreekat/snowdrift/commit/7a4cce442469977af57cd864c9963ada247e4ec5

(I also reorganized things a smidge.)


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev