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