Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 04 2018 12:19

    catmando on noreset

    initial commit refactoring now (compare)

  • Oct 01 2018 13:19

    barriehadfield on edge

    Hyperloop point to master for JS (compare)

  • Oct 01 2018 13:08

    barriehadfield on edge

    Hyperloop 0.99.1 (compare)

  • Sep 08 2018 00:40

    catmando on edge

    got tests passing again Gemfiles point to released gems (compare)

  • Sep 07 2018 23:03
    catmando closed #20
  • Sep 07 2018 23:03
    catmando closed #19
  • Sep 07 2018 23:03

    catmando on edge

    closes #19 closes #20 Merge branch 'edge' of github.c… resolved gemspec merge conflict (compare)

  • Sep 07 2018 22:49
    catmando opened #20
  • Sep 02 2018 08:34

    barriehadfield on edge

    Update README.md (compare)

  • Sep 02 2018 08:33

    barriehadfield on edge

    Update README.md (compare)

  • Aug 31 2018 09:31
    mpantel commented #12
  • Aug 28 2018 07:15
    mpantel commented #12
  • Aug 22 2018 08:00
    mpantel commented #12
  • Aug 19 2018 21:12

    johansmitsnl on edge

    Move the libv8 to running depen… Remove webdriver Remove empty helper (compare)

  • Aug 19 2018 21:06

    johansmitsnl on edge

    (compare)

  • Aug 19 2018 21:02

    johansmitsnl on edge

    Download and install the chrome… (compare)

  • Aug 19 2018 20:51

    johansmitsnl on edge

    Remove the find for the webdriv… (compare)

  • Aug 19 2018 20:51

    johansmitsnl on edge

    Include the database schema (compare)

  • Aug 19 2018 20:46

    johansmitsnl on edge

    Use find to locate the webdriver Don't set the path directly (compare)

  • Aug 19 2018 20:42

    johansmitsnl on edge

    Update the gemfile.lock (compare)

Mitch VanDuyn
@catmando
(true)
Hyperstack gets out of your way, and lets you focus on the hard part.
Barrie Hadfield
@barriehadfield
good discussion for next week on the call
Mitch VanDuyn
@catmando
@/all btw I am torn on what part III should cover. I think I want to go over the specs (they are in the repo). After part II the specs are still very simple. Then part IV will add some features (like scoping, editing todos, etc).
If you do the specs later they become too complicated to make a 5 minute read.
Barrie Hadfield
@barriehadfield
I think adding a framework like (Material or Semantic) is important
Mitch VanDuyn
@catmando
maybe that is part IV
part III -> specs (should be good for the hard core rails crowd)
Barrie Hadfield
@barriehadfield
ha ha - for me its always part 1
Mitch VanDuyn
@catmando
part IV -> use Material or Semantic (you gotta tell me which, or in fact, why don't you write that one!)
part V -> adding more features
part VI -> devise
part VII -> marketing your app so that you make $1M overnight
Barrie Hadfield
@barriehadfield
part IV - I would love to write
Mitch VanDuyn
@catmando
part VIII -> learn to be a race car driver like DHH
Barrie Hadfield
@barriehadfield
part VII - will follow carefully
Mitch VanDuyn
@catmando
part IX -> learn to be a pilot like catmando
Barrie Hadfield
@barriehadfield
Mitch VanDuyn
@catmando
part X -> buy a yacht
part XI -> find true love
wow all this because you use hyperstack!
Barrie Hadfield
@barriehadfield
:-)
Mitch VanDuyn
@catmando
you can start on part IV now (code will not change) the repo assumes there will be a branch for each part (i.e part-4) so you can build it out now, as the test code wont change.
Barrie Hadfield
@barriehadfield
am in Kiev today
Mitch VanDuyn
@catmando
and perhaps as the cleaning up the UI won't actually change the tests we can flip the order
cool
I am figuring a post a week is about right
Barrie Hadfield
@barriehadfield
I have been thinking quite a bit about Devise and client-side (secure) routing
was goign to update the Devise tutorial I wrote last year
Paul Richardson
@iamprich
@ScottDuke Hey! I dockerized a decent sized Hyperstack app a few weeks ago. It was similar to dockerizing a standard Rails app from what I remember.
Barrie Hadfield
@barriehadfield

@catmando re Devise, what I have been wondering about is if there is a way to keep the Admin JS completely separate from the User JS app. In the past I have done:

Rails.application.routes.draw do
    authenticate :member do
      mount Hyperstack::Engine => '/hyperstack'
      get '/(*other)', to: 'hyperstack#main_frame'
    end
  end

So, a not-logged in user does not even get to the Hyperstack API or the JS app (they stay in HTML pages with normal Rails routes). I have been thinking that depending on the user (admin/normal) they get a different main component which has its own client side routing - just thinking...

So I am thinking that the whole Admin section can be in one JS package and the rest of the app in another and rails view templates will only bring in the admin section if the user is Admin
This would get past the problem of Admin type code being a part of the client code.
Mitch VanDuyn
@catmando
that is a couple of different ideas.
Barrie Hadfield
@barriehadfield
yes, I am thinking aloud
Mitch VanDuyn
@catmando
having two different SPAs for user vs admin is perfectly reasonable
not 100% sure but you would just do something like this:
get '/admin/(*other)', to: 'hyperstack#admin'
get '/(*other)', to: 'hyperstack#app'
(cause rails runs the first route it hits)
catprint actually has a bunch of smaller SPAs
the possible problem with a static login page, is just user experience.
Barrie Hadfield
@barriehadfield
I like the idea of the public parts of a site being in simple HTML so they load fast, get indexed, etc. The SPA(s) then hide behind the authentication (ie mount Hyperstack::Engine => '/hyperstack’ never even happens for a public user)
the possible problem with a static login page, is just user experience.
Same style sheet and bits of JS niceness will overcome that
Mitch VanDuyn
@catmando
I know the easiest way to get into devise (for example) is take that route (no pun intended) but it certainly can be done to get things wired up to use hyperstack ControllerOps (or even tweak a rails controller to deliver some JS) in the long run its going to give a better experience.
Same style sheet and bits of JS niceness will overcome that
of course, but you still have this reload going on.
which is unnecessary
from hyperstacks standpoint all that happens when you login, is that new channels are created.
Of course if you are adapting an existing site then keep you current login strategy, at least until you have more important pieces working.