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
