@bhauman: Just saw your Strangeloop talk and you said you don’t get much feedback, so I wanted to tell you I’ve been using devcards over the weekend and they’re awesome! I’m using them to help me build some admin tools and components of a new app in the platform. Also lately I’ve been thinking about how I can make my documentation interactive and more visible…this pretty much solves that problem for me. I can really see this speeding up the on-boarding of new devs. They can start with the devcards and then make their way into the code. Being able to change the code and see how it affects the app will really aid in learning. I’m thinking about ways to improve the cards. I’m sure you’ve consider this but the first thing that comes to mind is adding some UI controls that wrap the options map. If I get around to it then I’ll submit a PR :simple_smile: Anyways dude, really appreciate your contributions to this and figwheel! Cheers3👍
@bhauman: just watched the talk too, great job man! I liked your explanation that devcards are essentially “a lab for your visual tests”, Maybe you could think about a new project name so this clicks in more heads. Maybe piggy-back on figwheel’s fame and call it figlabs or something with labs in it (devlabs maybe?). The card metaphor is important, but only one way how to express and exercise your components visually. IMO essential is having that experimental labs space, where you can place a lot of things in different states and see them in parallel with live reloading support. This “labs” metaphor would stress experimental and informal nature of devcards. Frankly, when I first saw devcards, I dismissed the idea, because I thought it is too much “side work" without a clear benefit. I simply didn’t get it. Like someone who hears about benefits of unit tests, but does not quite get it, because he has never experienced benefits of it and his current codebase is so entangled that there is no way it to even think about it. I thought it was too formal approach and needed a lot of preparation and self-discipline. We need to make devcards informal and fun to start with.
@sir-pinecone: thanks! I'm glad you like them. Yes I have been thinking about adding these controls. I'm a bit uncertain about committing to them until we see how folks are using this. But its definitely on the radar... Thanks again!
@darwin: Thanks man! IMHO the problem is more that this idea is kinda new, and that it isn't any one thing or practice. It is a lab space and you can do as you will. I'm not sure that a name change will do it. You may be right though. I will reflect on it a bit. David sees it as TestCards. I think that different perspectives are going to bring different approaches and the thing that is going to turn the light on for different folks is going to be well ... different.
@darwin: The major problem is that folks really don't even understand how important hot reloading is yet. I'm hoping we'll see the same thing happen with devcards that happened with figwheel where one person shares it with another and it will spread organically because people find value in it. Again you have to experience it and play with it a bit.
@darwin: It would be really great if some folks wrote some more blog posts about how they are using it. That would probably help more than anything else.
@darwin: I really appreciate the feedback and the fact that you are using it. I saw some great examples of devcards and figwheel in use at Strange Loop.
I’m still at beginning, I’m planing to share my devcards on github pages branch so people can see it in action, but I need to build more and document/polish it a bit.
@darwin: no pressure at all ... would love to see what you are doing though. Did you see the program execution talk linked above? I've heard good things, I'm going to watch it today.
@bhauman: yes, saw it yesterday, very impressive, kinda Bret Victor “wow” talk, still have to go through his references: http://janpaulposma.nl/visualising-program-execution/
that’s possible future direction I would like to go with plastic, if/when I get basic editing right, I would like not to support other languages and environments, but integrate it/build into it cljs-related tools and intelligence for frontend webdev
(just another inspirational idea for plastic)
I'm going to continue to harp on my theme that making it easier to use devcards as a publishing platform for tutorials, developer docs, etc. will help spread awareness and adoption, more than promoting its use as a testing platform.
Or maybe I should have said "in addition to" its use as a testing platform.
Research/Development/Testing/Publishing (all with interactive hot loading)
@meow: this will need to be looked at but there is a problem of infinite configurability, because this is a compiled web app not just static docs, folks will need to include assets etc
@meow: the path to being able to do this in a turn key manner is not straight forward at all
@meow: its similar to the deploy story for a cljs app, how do you do that in a turn key manner? Such that everyone's needs are satisfied?
Maybe all I need is a wiki page (or a devcard) that shows a viable approach to publishing simple cards on github pages.
@meow: have you used github pages before? The process is no different than deploying a cljs app to github pages.
For example, I'd love to publish the card I have that has the fractals. But I haven't done it because I've got so many other things I'm working on that I simply don't want to have to figure this out.
Call me lazy.
No, I haven't deployed anything to gh pages yet.
@meow: I'm not suggesting that you should know how to do this already ... I think I'm just saying that there are a lot of things that I have to do to get devcards to the viable stage and that adding a deploy system is a huge beast and it feels overwhelming
Maybe its also the fact that nobody else has done it, other than you, that makes me continue to put this on a back burner.
@meow: github pages has good docs and it is the very best publishing platform that I know of.
Ok, well, I guess one of these days I'll make this a priority and attempt to do it.
@meow: once you have a deploy system, you are likely to want something like continuos deploys system, to see different revisions of your cards as code evolved... another beast :simple_smile:
I guess, there will be a need for travis for devcards in future :simple_smile:
I just want a tutorial that shows how to publish devcards to gh-pages.
I guess its easy, and I just need to do it, is what I'm hearing.
it is pretty easy, just a git commit script which commits your resources dir with compiled cljs sources to another branch of your repo
I want to do it myself next week maybe, for plastic
At the same time I'm hearing that it is a huge overwhelming beast...
The fact that others aren't doing it and there are no public examples of how to do it makes me think that it won't be easy.
Maybe that's an irrational concern, but it makes it easy to keep dropping this in my priority list in favor of other tasks.
I've created gh-pages sites, just have never populated it with anything.
you don’t even need a script, you can generate your static site into some folder which is already setup as a git repo with gh-pages branch as working copy and commit ad-hoc
you don’t have to use jekyll or their auto-generator, github page is just a static html site in gh-pages branch of your repo
this is an example of my static site hosted on github pages (old project): https://github.com/darwin/cmx.io
the script responsible for generation has nothing gh-pages specific I just created http://cmx.io subfolder in my repo, added it into .gitignores, initialized http://cmx.io repo with gh-pages branch there and used this script to build the static site there: https://github.com/darwin/cmx.js/blob/master/rakefile
Nice. I guess I'll figure out how to do something similar with boot.
gh-pages is easy, don’t be afraid of the task
just prepare your build script to output whole site into some separate directory and publish that directory to gh-pages with git manually
later you can automate that all