I'm not in that much of a hurry to join since right now I am mostly
focusing my time on job search, networking, studying and work on the
company I created.
But in a few weeks, I might be willing to help more

On Wed, Oct 4, 2017 at 1:53 PM Jason Harrer <jazzyeagl...@gmail.com> wrote:

> 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.
> Yay!!
>> 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
> Dev@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/dev
Dev mailing list

Reply via email to