On Tue, Oct 3, 2017 at 11:38 AM, Bryan Richter <br...@snowdrift.coop> wrote:

> Hi all,
> [This will be my last "regular" update for a while, since my personal
> schedule is becoming correspondingly less regular.]
> Well, September didn't go as well as planned. :/ I had it all blocked
> out to work on Snowdrift, and I got pretty much nowhere. There were a
> few contributing factors, but I'm not sure how much I will talk about
> them in this email. More pressing are the following news items.
> First, at 10am this morning (UTC+2) I ran the first crowdmatch
> event[1].  So far there is no outward evidence of this fact, because
> crowdmatch history isn't shown on the website! But I can fix that
> quickly. We'll manually send out some email notices later today, I
> hope, depending on team availability.


> Second, after much wringing of hands and wracking of brains, I find
> that I have to reset the code repo back to a deployable state. I
> regret to relate that that is a rather long time ago in the code
> history. To be more blunt, I'm going to take out Sass and pretty much
> everything else that isn't already on the live website.

> Practically, this means a forced update to master will be coming soon.
> In human terms, it means I'm a terrible person. :( Ok, so that's
> hyperbole, but I definitely want to say that a different programmer --
> a better one, for instance -- would be able to work with the current
> version of master. But the version of Snowdrift that *I* can work
> on has to be one that can be deployed on the daily, and it has to
> be implemented more incrementally than what I allowed to happen in
> the last few months.  So, I definitely feel bad about this, but I need
> to do it.
> Once the reset is done, I can add the crowdmatch history as I
> mentioned above, and then hopefully the project team can agree on
> smaller, incremental changes that move us forward.

This concerns me a lot, as folks *have* been performing smaller, more
incremental changes; it's just that the site wasn't ready to have all the
changes, and so deployment has been delayed as the master branch continued
to receive and merge updates.  This was the whole reason I had initially
requested a separate branch for the ui on the main site: So the main code
wouldn't get to the point where it was undeployable.  Once again, we are
back to the point where a lot of stuff that we've worked on for a long time
will end up getting removed, and we have to go back and try to reconcile.
This set us back at least a month the last time we had to do this.

The other question I have is, how long will it take you to perform this
reversion, and once it is complete, how long do you estimate it will take
you to finish up the crowdmatch lib?  I don't mean to sound rude, but you
even said so yourself:  "my personal schedule is becoming correspondingly
less regular."  We all understand and can appreciate the term "volunteer",
as we all are one devoting our free time where we can, but our ability to
reach the alpha milestone has been hinging upon this crowdmatch lib for a
VERY long time now, and if you're not going to be able to find the time to
commit to doing all of these big changes to finish up crowdmatch, then all
this is going to do is to put Snowdrift.coop in a position where we can't
move forward.  Again.

Is there someone who can help you write the crowdmatch lib?  I know
freeman42x has been asking to be able to help with something very Haskelly,
so this may be right up his alley.  If not, perhaps I can take a stab at
it.  I know my Haskell skills aren't up to par with yours and my solution
may not utilize Haskell to the fullest extent, but if I can help simply get
something that works and then someone else can clean it up later, we could
at least move forward.

> The final thing I've realized from this month's slog is that Yesod has
> got to go. This, again, is as much a personal decision as a technical
> one: I clearly am not within Yesod's target market. But it's me or
> Yesod, so do-ocratically speaking, Yesod is on its way out.

Although I personally have given up on Yesod myself after years of trying
to understand the behemoth, I do wish to express some additional points to
consider in this move, particularly in terms of the design team and front
end programming.  I'm not necessarily trying to talk you out of it, however
I do want to point out some major hurdles we're going to need to work
through if we do move.

Firstly, we have created the entire site using Shakespeare, which is the
primary HTML/CSS/JS language templates for Yesod, as well as
shakespeare-sass, which we modified to have Yesod treat our sass templates
the same way as it does all the other templates.  Yes, it is true that
Shakespeare is its own library, however what made Shakespeare so appealing
and so usable is the function widgetFile, which would take all of the
various template files for the same page and combine them into a single
page to be displayed.  It would take the JS from a Julius file and insert
it into the HTML within a script tag as appropriate, and it would take our
sass and css templates and insert them into style tags as appropriate.

Unfortunately, widgetFile isn't part of the shakespeare package, but is one
of the functions generated by TH via Yesod directly.  It has various
functions for pulling in template files, however they are individual
template files (e.g. shakespeareFile "templates/main.hamlet",
shakespeareFile "templates/main.cassius", etc.) and not any sort of
combinator for those files to generate the one HTML file to feed to the
server, which is why I didn't use Shakespeare when I started my own
website.  Because of this, we would either have to create our own
widgetFile functionality somehow OR switch to something completely
different than Shakespeare, which would be a major learning curve to the
design team.  I personally have been trying other libs out, and thus far, I
haven't found anything quite as robust nor intuitive as Shakespeare.  Most
other packages focus on bringing the HTML/CSS/JS world directly into
Haskell code (e.g. blaze-html & lucid), which, although not inherently a
bad choice, would require our design team to become more familiar with
Haskell, especially to understand $ and do notation.

Secondly, the workflow for both design and dev has very heavily relied on
yesod-bin to automatically recompile the website when changes were made &
detected.  By moving away from Yesod, folks will need to get used to
recompiling whenever they make changes.  I suppose we could design a little
program that does the same thing for whatever we do as well to meet that
need, but I think that'd be more of a distraction from all the other work
that will need to occur.

> But that won't happen just yet! I am going to simply abandon the path I
> was attempting (namely, abstracting over Web.Stripe.stripe as a field
> in the App datatype) and move forward with necessary functionality on
> the website. Fast and loose. Less perfection[2], in order
> to hit a feature milestone.
> That's all for now. Thanks for reading. Feedback appreciated.
> Peace,
> -Bryan
> aka chreekat
> p.s. I'm going to Stockholm tomorrow, then to Gothenburg the following
> week, and then I'll be leaving the Schengen zone thereafter. Not sure
> where to, yet.
> [1]: Recall that I use the term 'crowdmatch event' to refer to a
> process that tallies up the patrons of a project and calculates their
> monthly donation. This just changes some values in the database. In
> a completely separate process, a 'payments event' is where pending
> donations are turned into real money transfers. We still don't know
> when the first of those will happen. (By current patron numbers, it
> would be some time in 2020, but I suspect it will be a lot sooner than
> that!)
> [2]: As much as I've heard and read about perfect being the enemy of
> the good, it's clearly something that I still have to learn the hard
> way. An esoteric understanding is not sufficient in my case.
> _______________________________________________
> Dev mailing list
> Dev@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/dev
Dev mailing list

Reply via email to