This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-14
Channels
- # 100-days-of-code (4)
- # announcements (1)
- # beginners (63)
- # boot (22)
- # braveandtrue (104)
- # calva (3)
- # cider (12)
- # cljs-dev (53)
- # cljsjs (3)
- # cljsrn (1)
- # clojure (180)
- # clojure-dev (14)
- # clojure-italy (4)
- # clojure-nl (11)
- # clojure-spec (15)
- # clojure-uk (60)
- # clojure-ukraine (1)
- # clojurescript (118)
- # clojutre (3)
- # core-async (12)
- # core-logic (17)
- # cursive (19)
- # datomic (45)
- # devcards (4)
- # emacs (7)
- # figwheel-main (218)
- # fulcro (27)
- # funcool (3)
- # graphql (1)
- # jobs (4)
- # leiningen (57)
- # off-topic (71)
- # pedestal (2)
- # portkey (17)
- # re-frame (5)
- # reitit (4)
- # remote-jobs (2)
- # ring (11)
- # rum (2)
- # shadow-cljs (14)
- # specter (11)
- # sql (34)
- # tools-deps (23)
@jayzawrotny do note, heroku dynos don’t have persistent storage. If you are processing user uploads you need to store them in S3. Other than that, it’s pretty easy to convert a Django app to run on heroku. Files are also easy, just need a little bit of research on storage back ends.
👆 Yep, that’s what I tried to communicate yesterday with https://12factor.net/ link. Dynos actually do have a filesystem where you can store files but Heroku might rotate your dyno any time so in practice it’s good only for /tmp kind of things. For persistent storage you need to use something else.
Ah right, been reading that. We store our uploaded assets on s3 anyway so we should be good.
Though a potential roadblock may be our use of logical decoding in Postgres which a key part of our app depends on. Not sure if Heroku Postgres supports it.
Alright. It's naming time. What to call a static blog engine that lives 100% in the browser?
Isn't it what Klipse does?
The idea is sort of like a combination of bengine, maria.cloud and the github api to make a static blog generator that runs and saves itself into a github repo
oh yeah that's nice!
Yeah, I'm going to try to keep it simple and easy to fork and others can hopefully improve on it.
@U050PJ2EU I called mine next press
I'm trying to use pieces of re-view (from the maker of maria.cloud) for rendering code from a text area into neighboring view. And I'm using hiccup forms, ala the bengine static blog method, in those text areas to generate views.
So hiccup instead of markdown. Though, it'll probably make sense to add a MD editor for all the straight text, and only use the hiccup editor for structural layout.
So the text area is probably going to be collapsed, I'm thinking, and you can expand it by clicking on it.
Well, the niche I've landed upon, because I've got a self-hosted instance built in, I think I'm going to leave everything up to the user.
Yeah, and half the sell of this thing is the fun factor. It seems like it's be a pretty good first project for learning cljs - hacking on your own blog, in cljs, over github, without installing anything.
Well, regardless of how ready it is, I'm pushing something out before the end of the weekend.
I don't have any routing in there yet. Just a single page. That page has a view component and an edit component. All the logic that renders the view is in the edit component. All the github api logic lives in that component. So the site just about builds itself and a user should be able to change anything about it.
One ish I'm running into now is that I want to have editable components within the view component - so another level deeper. And reactions aren't firing to update my sub views.
If I can't figure that piece out I'm just going to ship something simpler and punt it. I'm sure other folks can come up with way prettier interfaces.
that sounds hard but I don’t have a really solid idea of what you are talking about, but I do get the gist
Pretty much a maria.cloud edit component on the left (https://www.maria.cloud/cells) that spits out yet another customized maria.cloud instance on the right (which can in turn have its left editor and right viewer)