Re: [Snowdrift-dev] Mechanism
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] Mechanism implementation
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
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] Mechanism implementation
On 03/14/2016 05:10 PM, Bryan Richter wrote: > 1. I'm not sure the Eq instances of MechPatron and MechProject are > sound. As defined, `==` is the moral equivalent of checking that the > two values cannot both exist in the database at the same time > (database uniqueness), but that's not quite the same thing as being > the same value. So, I think I redid this between when you wrote this review and now. Now, the `Eq` instance makes sure the external keys are equivalent. instance Eq MechPatron where m1 == m2 = mechPatronExternalKey m1 == mechPatronExternalKey m2 instance Ord MechPatron where compare = comparing mechPatronExternalKey instance Eq MechProject where m1 == m2 = mechProjectExternalKey m1 == mechProjectExternalKey m2 instance Ord MechProject where compare = comparing mechProjectExternalKey The reason I wanted to do this is so that `compare` would return `EQ` iff `(==)` would return `True`. I can't remember why I wanted to sort them? I think I wanted to put them in a `Set` (from the `containers` package), and to do any nontrivial `Set` operations, the inner type must be an instance of `Ord`. `HashSet` or whatever from `unordered-containers` doesn't require the inner type to have an `Ord` instance, however is does require a `Hashable` instance, which might actually not be that bad. Sets in mathematics do not require the concept of ordering, so `containers` seems like an affront to basic mathematical decency. It's almost as bad as there existing a `w : Word` such that `w + 1 = 0`. Mathematical decency aside, I'll look in to this. > 3. I don't think the concept of a suspended patron is necessary yet. > I could be misremembering, but I'm pretty sure one is either a patron > or one is not. This is me attempting (poorly) to think ahead. The concept of a pledge being suspended because of insufficient funds is necessary (or we could just delete the pledges, but that seems sort of mean). Moreover, I can imagine that Patrons would want to prioritize the projects, so if they can only afford projects X, Y, and Z, they can exclude project W temporarily if they want. > 5. > >> he = it > > I get it, but it provides very little compared to the damage it > could cause. What damage is that? Other than quasi-feminist stuff? Would it be better if I wrote `he = specify`? > 6. The stuff I wrote for doing tests against a database was intended > to be abstracted out into a standalone library. I'll still do that. > I guess you had to rewrite it to be able to use HSpec, though, so > *shrug* > FWIW, your tests are still there, in the `chreekat` directory. I sort of ported them over to HSpec, and then figured out a rather novel way to abuse the concept of property-based testing. ___ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
