*** uncleserg has joined #storyboard | 02:21 | |
*** uncleserg has quit IRC | 02:29 | |
*** SergeyLukjanov has joined #storyboard | 04:35 | |
*** SergeyLukjanov has quit IRC | 04:35 | |
*** SergeyLukjanov has joined #storyboard | 04:37 | |
*** SergeyLukjanov has quit IRC | 05:15 | |
*** SergeyLukjanov has joined #storyboard | 05:16 | |
*** SergeyLukjanov has quit IRC | 05:57 | |
*** SergeyLukjanov has joined #storyboard | 07:49 | |
*** SergeyLukjanov has quit IRC | 08:34 | |
*** SergeyLukjanov has joined #storyboard | 11:10 | |
*** SergeyLukjanov has quit IRC | 11:19 | |
*** drdee has joined #storyboard | 12:20 | |
*** SergeyLukjanov has joined #storyboard | 14:46 | |
*** SergeyLukjanov has quit IRC | 14:53 | |
*** drdee has quit IRC | 15:41 | |
*** djelektronik has joined #storyboard | 15:49 | |
*** djelektronik has quit IRC | 16:01 | |
*** SergeyLukjanov has joined #storyboard | 16:34 | |
*** SergeyLukjanov has quit IRC | 16:34 | |
*** krotscheck has joined #storyboard | 17:34 | |
mordred | krotscheck: any luck on any of the above ^^ sorry, I've been, well road tripping | 18:02 |
---|---|---|
mordred | also, I ate a pig head last night | 18:02 |
krotscheck | I saw. It looked tasty | 18:02 |
krotscheck | Reference project currently on github. | 18:03 |
krotscheck | Trying to figure out how to structure a pecan/wsme and js project. | 18:03 |
mordred | krotscheck: I'd love to think further about how pbr can do more with building/minifying js artifacts at build/sdist time, btw | 18:03 |
krotscheck | And rather frustrated. | 18:03 |
mordred | ah! well ... I can imagine that that probably sucks | 18:04 |
mordred | you want to put the pecan/wsme and the js in the same project? | 18:04 |
krotscheck | It's like starting from scratch without documentation. | 18:04 |
krotscheck | Well, sortof. | 18:04 |
mordred | yup. sounds lke it | 18:04 |
krotscheck | So, the actual client application doesn't really need any API layer. | 18:04 |
krotscheck | With one exception: The google scraper bot. | 18:04 |
mordred | can you explain "The google scraper bot" better assuming I'm stupid? | 18:05 |
krotscheck | For tickets to show up in google when someone searches for it, google's crawler needs to be able to find them | 18:05 |
mordred | ah | 18:05 |
krotscheck | Except google's crawler doesn't have a javascript engine. | 18:05 |
krotscheck | But they've published an API with which we can tell that crawler where to look. | 18:06 |
mordred | so would that just be additional pecan/wsme api calls things non-authenticated? | 18:06 |
krotscheck | Philosophical separation: Client app should know about client app, api should not know about client app | 18:07 |
krotscheck | So the client app needs a really thin API layer that serves up that contant | 18:07 |
krotscheck | content | 18:07 |
krotscheck | Basically, the crawler recognizes that it's a javascript app via a header tag, and then says: Hey- , I'm just going to ask for the HTML using a querystring (?__encoded_url__=/my/hashbang/url | 18:07 |
krotscheck | And it expects scrapable HTML in return. | 18:08 |
mordred | gotcha. so ... | 18:08 |
krotscheck | So the client app needs a thin python layer that does this. | 18:08 |
mordred | why not just put the python layer into the existing api app | 18:09 |
mordred | is it purely that that would mean the api app would need to know something about he client app? | 18:09 |
krotscheck | I'm not entirely happy with the idea of making the API do things that are related to a client. | 18:09 |
mordred | nod | 18:09 |
krotscheck | Yeah, basically. Say we want to build a different javascrpit client that serves as a customer service portal. | 18:09 |
krotscheck | So now we have two clients consuming the same API... which of the two should the API serve up to google? | 18:10 |
mordred | ah | 18:10 |
mordred | so - given the existence of the python app... | 18:10 |
mordred | what would the thin python app be communicating with? | 18:10 |
mordred | would it make rest calls itself back to the api? | 18:11 |
krotscheck | Well, it would make an HTTP call to itself - say, to get /#!/foo/bar, with a virtual browser environment. | 18:11 |
krotscheck | It waits for the JS to render, then dumps the resulting HTML and sends it back. | 18:12 |
mordred | GOTIT | 18:12 |
mordred | that makes sense to me | 18:12 |
krotscheck | The docs is here: https://developers.google.com/webmasters/ajax-crawling/ | 18:13 |
mordred | so that app thing doesn't really need to know specifics about the client app per se - it just need to know which client app to proxy to | 18:13 |
krotscheck | Basically, it just serves up HTML snapshots | 18:13 |
krotscheck | Exactly | 18:13 |
mordred | ok. SO - being mainly stupid and making knee-jerk suggestions ... | 18:14 |
krotscheck | So this could be a super easy library to write and just drop into a project. | 18:14 |
krotscheck | And then reuse it whenever | 18:14 |
mordred | I'd say that we just want a separate repo with a simple pecan/wsme app in it | 18:14 |
krotscheck | I just don't know enough about python yet on how to do that. | 18:14 |
mordred | and part of the "install js client" for production use stuff would be "also install one of these on the server" | 18:15 |
krotscheck | So, explain wsgi to me. | 18:15 |
mordred | to get yourself started, you want to use cookiecutter to make yourself a new repo: | 18:15 |
mordred | https://github.com/openstack-dev/cookiecutter | 18:15 |
mordred | oh god. I have no idea how wsgi works - I generally wave my hands wildly and then run away and hope no one notices | 18:16 |
krotscheck | From my understanding, request comes in to apache, apache checks its virtual hosts cnofig for request routing, then sends that request to the virtualenv of the app, and serves back what's received? | 18:16 |
mordred | yes. that's basically it | 18:16 |
krotscheck | 'cause if that's the case, we can make ajax scrapability into a completely separate project. | 18:16 |
mordred | yes | 18:16 |
mordred | that's what I'm thinking | 18:17 |
krotscheck | And then I don't have to worry about it anymore | 18:17 |
krotscheck | Well. | 18:17 |
krotscheck | Cool | 18:17 |
krotscheck | Ok | 18:17 |
krotscheck | You know, that's an EXCELLENT starter project for me to learn python | 18:17 |
krotscheck | Given that the JS reference project is already done | 18:17 |
mordred | yes. very self-contained | 18:17 |
mordred | oh - point me at the JS reference project? | 18:17 |
krotscheck | https://github.com/krotscheck/storyboard-webclient | 18:18 |
mordred | ironic uses pecan/wsme, btw, so it might be possible to cargo-cult something about how that works | 18:18 |
krotscheck | You're on windows/ | 18:18 |
krotscheck | ? | 18:18 |
mordred | god no | 18:19 |
mordred | ubuntu | 18:19 |
krotscheck | Thank goodness. Does your distro have a recent nodejs build? | 18:19 |
mordred | 0.10.15~dfsg1-4 | 18:20 |
mordred | is that recent? | 18:20 |
krotscheck | Recent enough | 18:20 |
mordred | cool | 18:20 |
krotscheck | Do you want to run it locally or do you just want me to host the client off of github pages for now? | 18:21 |
mordred | oh - I just wanted to poke at it, because I know nothing about js toolchains | 18:21 |
* mordred is currently looking at jshint in your gruntfile and thinking that we should potentially use that to do with js stuff what we use pep8 for for python... | 18:21 | |
krotscheck | Got it. | 18:22 |
krotscheck | Let me forward the install instructions to you | 18:22 |
mordred | neat | 18:23 |
krotscheck | I'm going to go rip out all the python specific stuff now. | 18:23 |
krotscheck | Oh, also, with clarkb I was able to get headless selenium tests running. Super sexy. | 18:23 |
mordred | sweet! | 18:23 |
mordred | I'm hoping that once we learn more about how to do some of these things with storyboard, we can apply the lessons back to horizon too | 18:24 |
krotscheck | And jeblair suggested a way to get nodejs into our project without screwing with devstack-gate | 18:24 |
krotscheck | Oh, dude. Horizon is... | 18:24 |
mordred | oh yeah? what was that? | 18:24 |
mordred | :) | 18:24 |
krotscheck | Well, they just sent a patch that sets the spaces to 2. | 18:25 |
krotscheck | I'm like: Uh, what's wrong with pep8? | 18:25 |
mordred | wait - horizon is moving to 2-space indentation? or just for their js? | 18:27 |
krotscheck | Just for their JS | 18:27 |
krotscheck | Because "of how deeply nested javascript tends to be" | 18:27 |
krotscheck | .... | 18:28 |
mordred | hrm | 18:28 |
mordred | oh - so they're doing jshint tests in horizon/static/horizon/tests/jshint.js | 18:28 |
krotscheck | ... which is _sortof_ true, because it's a functional language and people tend to love to create functions that return functions that return functions... | 18:28 |
* mordred really needs to grok more about what they're doing | 18:29 | |
krotscheck | ...but then you realize that for every nested closure, the JS engines actually create three memory references... | 18:29 |
mordred | haha | 18:29 |
krotscheck | ...for each nested nesting... | 18:29 |
krotscheck | ... and then you realize that maybe prototypical inheritance is the way you want to go. | 18:29 |
krotscheck | blah blah i'm familiar with this language ego ego blah blah | 18:30 |
mordred | you sound lke me talking about mysql :) | 18:30 |
krotscheck | :) | 18:33 |
mordred | how do I run jshint from the command line (I'm starting slowly here) | 18:38 |
mordred | btw - I do not need the ln -s /usr/bin/nodejs /usr/bin/node step on ubuntu saucy | 18:39 |
krotscheck | Oh? | 18:39 |
krotscheck | grunt jshint | 18:39 |
krotscheck | Interesting. | 18:39 |
krotscheck | For some reasno that was necessary on raring | 18:40 |
krotscheck | But then the ubuntu crowd and the node crowd usually don't see eye to eye | 18:40 |
mordred | yah | 18:43 |
mordred | neat! I have done that and it worked | 18:47 |
mordred | and then I messed something up and verified that it was unhappy | 18:47 |
krotscheck | See, now I feel sheeping wasting a couple of days trying to make python and node behave together | 18:50 |
krotscheck | Nice! | 18:50 |
krotscheck | Try grunt server | 18:50 |
krotscheck | Or just go through individual commands in the Gruntfile. | 18:51 |
krotscheck | They should be reasonably well documented. | 18:51 |
mordred | grunt server gave me an error | 19:03 |
mordred | GENERAL USE: $ recess [path] [options] | 19:03 |
mordred | fwiw | 19:04 |
mordred | oh - I seem to have not run bower install first | 19:05 |
mordred | neat. that worked | 19:06 |
mordred | I do not understand all of the tihngs that happened | 19:06 |
mordred | but things happened | 19:06 |
mordred | krotscheck: oh - so, another task to put on the plate potentially ... | 19:08 |
mordred | krotscheck: it looks like there are javascript unittest and/or testing framework things happening | 19:08 |
krotscheck | ...yes? | 19:09 |
krotscheck | You mean in my project, right? | 19:09 |
mordred | yeah | 19:09 |
krotscheck | Right, and those should be streamed, right? | 19:09 |
mordred | yeah - or, I think what probably wants to happen is that we want to teach the thing that runs them how to output subunit | 19:09 |
krotscheck | Well, karma's got reporter plugins we can work with. Clark seemed to be ok with the current junit output though | 19:10 |
mordred | yeah. I think it's fine for right now | 19:10 |
krotscheck | s/work with/extend/ | 19:10 |
mordred | just on down the road it would be neat if we could use testr to drive it - and as testr is a test runner runner, it _should_ all just magically work and stuff | 19:10 |
mordred | (there's a lot going on here that I get to learn now) | 19:11 |
mordred | neat. I have run unittest | 19:12 |
mordred | I like this, it's fun | 19:12 |
krotscheck | try grunt test:functional | 19:12 |
krotscheck | and then grunt test:functional:headless | 19:12 |
mordred | sweet | 19:13 |
mordred | is it possible to run just a single test? or is it always the suite? | 19:13 |
krotscheck | Yes, I don't have that parameterized yet though. | 19:15 |
mordred | also - so 'grunt package' makes all of the files and puts them into /public, yeah? | 19:15 |
krotscheck | Well, your versino does, yes. | 19:15 |
krotscheck | I ripped that out, it'll put it into /dist instead (more in line with js conventinos) | 19:15 |
krotscheck | But anyway | 19:15 |
krotscheck | So, grunt compile creates a fully functional app, except it's not minified | 19:15 |
krotscheck | grunt package takes that app and minifies it | 19:15 |
mordred | so in theory, a way of thinking about this would be that on a build host (wahatever that means) we could run grunt package, and the tar that up and deploying it onto the webserver is just deploying those files, yeah? | 19:16 |
* mordred working on wrapping head around the toolchain - so I might get some of the concepts wrong | 19:16 | |
krotscheck | Yup | 19:16 |
mordred | neat | 19:16 |
krotscheck | That output directory is hostable. | 19:16 |
krotscheck | We'll want to parameterize some configuration elements, like which API host to talk to. | 19:17 |
krotscheck | But that's basically it. | 19:17 |
mordred | yah | 19:17 |
mordred | I _think_ there are really great corrolaries to all of the things we do on the python side ot things | 19:17 |
mordred | of | 19:17 |
mordred | I'm not 100% that we _need_ all of those things, tbh | 19:17 |
krotscheck | I'm curious on how we're going to run the client integration tests, since those'll require a running API. | 19:19 |
krotscheck | I _suspect_ I can add a couple of calls in the gruntfile to set up a virtualenv with an install and just spin that up. | 19:20 |
mordred | yeah. that's an option. or maybe parameterizing it so that the client integration would just expect a running api and we rely on jenkins/zuul to do that for us | 19:21 |
mordred | I'm not sure which will be the thing that will ultimately be more betterer | 19:21 |
mordred | (we'll want to be able to test changes to both things against each other - so we'll want to make sure that zuul can set up the git repos like it does for other integration things) | 19:22 |
mordred | but that would really just mean that even if we had grunt do the venv, we'd want to be able to tell it where to find the git repo with the api stuff | 19:22 |
mordred | ok. gotta run errands. but I'm excited - I feel like I'm learning a lot about things! | 19:24 |
krotscheck | Go go. | 19:24 |
krotscheck | Go forth and eat some cheese for me tonight. | 19:24 |
krotscheck | Say hi to Ben for me :) | 19:24 |
mordred | oh. I'm gonna eat cheese - and will say hey to ben | 19:24 |
*** krotscheck has quit IRC | 20:21 | |
*** krotscheck has joined #storyboard | 21:41 | |
*** krotscheck has quit IRC | 22:03 | |
*** krotscheck has joined #storyboard | 22:05 | |
*** krotscheck has quit IRC | 22:45 | |
*** krotscheck has joined #storyboard | 22:49 | |
mordred | krotscheck: around still? | 23:08 |
krotscheck | Nope. | 23:09 |
krotscheck | I am a turing machine | 23:09 |
krotscheck | What's up? | 23:09 |
krotscheck | (fyi, did a commit --amend on the remote repo with a slightly different project structure now that I didn' tneed the python foo) | 23:09 |
krotscheck | (No functinoal changes though) | 23:09 |
mordred | krotscheck: k. I'll fetch/reset | 23:09 |
mordred | I have questions about accessbility via your js-client approach | 23:10 |
mordred | as in - how does it fare with things such as screen readers or whatnot? | 23:10 |
krotscheck | Depends on the annotations. | 23:10 |
mordred | so, it's possible to write both good and bad apps wrt accessibility? | 23:11 |
krotscheck | ...and how old the screenreader is. | 23:11 |
krotscheck | Indeed. The older screenreaders don't pay attention to DOM changes. | 23:11 |
krotscheck | Or, well, they don't read modified content until they reach it. | 23:12 |
krotscheck | Do we have statistics on launchpad re: screen readers? | 23:13 |
mordred | not to my knowledge - I think just having some conversations about wanting to make sure we understand the ramifications of technology choices | 23:14 |
krotscheck | Point. | 23:14 |
mordred | and that we might, at some point, want to figure out how to get some screen reader testing figured out, to be good humans | 23:14 |
krotscheck | You know, if we've got the API out there to render and cache google-crawlable static versions, I don't think it's a far leap for us to create an entire shadow site that's no javascript static pages. | 23:15 |
krotscheck | That's the brute force, but doable, approach | 23:16 |
krotscheck | More subtle approaches would then be to make one of us sit down with a blindfold and a screenreader. | 23:17 |
krotscheck | One warning though: As I recall, most commercial screen readers are ActiveX based. | 23:19 |
krotscheck | Wait, I'm wrong | 23:20 |
krotscheck | The annoying ones are windows based because they're annoying. Apple's screen reader is baked into the OS. | 23:20 |
mordred | ew. activex | 23:29 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!