--- Log opened Fri Aug 10 00:00:53 2012
00:19 < SubStack> dominictarr: http://nodejs.org/docs/latest/api/all.html#all_class_writestream
00:20 < SubStack> apparently all new in 0.8
00:20 < dominictarr> SubStack, AWESOME
00:21 < dominictarr> node makes life so easy.
01:57 < SubStack> Raynos: thinking about how to minimally modify yarnify to support sharing css files across bundles
01:57 < SubStack> so for instance I have an overlay.css that I want to use for multiple widgets but I don't want to share anything else
01:58 < SubStack> thinking that perhaps if yarn(element, cssFiles) worked I could just apply the css contents to element
01:58 < SubStack> even if that element came from another yarnify bundle or just a vanilla dom node
02:08 < SubStack> oh sweet seems like it might be simple
02:09 < SubStack> ok neat, didn't break existing code
02:23 < SubStack> then to build the whole thing from scratch I'll just do find -name yarn.sh -exec ./{} \;
02:23 < SubStack> s/\.\///
02:56 < Raynos> SubStack: https://gist.github.com/b8ea64e0526264fe3ec4
02:57 < Raynos> testling has a dependency on schoolbus which doesnt have a browserify dependency when it should
02:58 < SubStack> oh no!
02:59 < SubStack> Raynos:         "browserify" : "~1.13.3",
02:59 < Raynos> wut
02:59 < SubStack> could be npm didn't fetch it
03:00 < joshwnj> Substack: thanks for getting back to me on twitter
03:00 < Raynos> what even is this
03:00 < SubStack> $ npm view testling dependencies | grep browserify browserify: '~1.13.3',
03:00 < SubStack> er wups
03:00 < SubStack> paste didn't multi-line but you get the idea
03:00 < Raynos> SubStack: yeah npm didn't fetch it because it's higher up the chain
03:01 < SubStack> joshwnj: I am about to get burritos but if you ask your question I'll read the scrollback and answer here
03:01 < Raynos> > sh: browserify: not found
03:01 < SubStack> also lots of folks here know plenty about browserify
03:02 < SubStack> Raynos: maybe npm should install bin scripts for every dependency listed in the package.json that exists at a higher location
03:02 < SubStack> into node_modules/.bin
03:03 < SubStack> because npm already updates $PATH to check there
03:16 < joshwnj> SubStack: question about browserify + wreq...
03:17 < joshwnj`> I'm wanting to convince a client (and their frontend team) that they should be using this for everything
03:17 < joshwnj> but wanted to check with you first if there's anything i need to be aware of, eg. any known quirks
03:26 < Raynos> joshwnj: browserify is more stable then wreq
03:30 < Raynos> dominictarr: I'm going to move es.duplex into a seperate node module
03:30 < Raynos> do you want to do it instead and have it under your name?
03:35 < joshwnj`> Raynos: yeah - want to use browserify for production-site js, and wreq for dev (local) js, so we get proper file/line numbers for any console logs or errors
03:35 < joshwnj`> anyone else doing it this way?
03:35 < Raynos> joshwnj: I use { debug: true } for proper file/line numbers
03:36 < Raynos> I use browserify in production
03:38 < joshwnj`> cool. anything to know about? like issues or quirks
03:38 < Raynos> yeah
03:39 < Raynos> the limitations on expressions in require statements
03:39 < Raynos> require("foo" + "bar") wont work
03:39 < joshwnj`> right
03:39 < joshwnj`> i can live with that :)
03:39 < guybrush> joshwnj`: i do it the same way, though not for all stuff
03:39 < guybrush> wreq in dev and bfy in prod
03:40 < joshwnj`> guybrush: nice
03:40 < joshwnj`> Raynos: what do you do in dev? browserify still?
03:41 < Raynos> yes
03:41 < guybrush> tj published this component thing about some hours ago
03:41 < Raynos> with the debug option set to true
03:41 < guybrush> i wonder if the community follows this component-approach
03:42 < Raynos> some do
03:42 < guybrush> personally i hope it will all end up in the package.json :p
03:42 < guybrush> if they (the community) do aggree on the component.json file we are doomed! :DD
03:42 < guybrush> with another registry just for client-side js
03:49 < joshwnj`> yeah package.json clearly already works
03:51 < joshwnj`> Raynos: { debug: true } just does the @ sourceURL thing right? so that won't work in older browsers?
03:52 < Raynos> correct
03:54 < joshwnj`> for this particular project a lot of the team have never used nodejs before (probably don't even have it installed) so that's why wreq is quite appealing
03:55 < Raynos> joshwnj`: oh, good luck
03:55 < joshwnj`> guybrush: ever noticed any differences between running stuff with wreq VS browserify?
03:59 < SubStack> joshwnj`: wreq is more of an experiment than something that has seen a lot of use in production webpages
03:59 < SubStack> a lot of folks are using browserify in the wild though
04:00 < SubStack> guybrush: component.json oh cripes no
04:01 < joshwnj`> SubStack: yeah, great to hear others are using browserify in production
04:02 < joshwnj`> I've got no plans to use wreq in production, but using it as a "dev-mode" replacement for browserify
04:03 < joshwnj`> so as I can instruct the team to only use the subset of functionality that works exactly the same in wreq and browserify, should be right... :) or can you think of something that will give me trouble there?
04:03 < SubStack> browserify --debug does the trick for that
04:04 < guybrush> joshwnj`: currently with wreq you cant require('someNodeModule') which would grap node_modules/someNodeModule - so thats kind of annoying
04:04 < SubStack> wreq isn't actually any better at debug line numbers than browserify
04:04 < guybrush> but you get node require
04:04 < SubStack> it's doing a Function() which is the same as --debug does
04:04 < guybrush> with line number for errors
04:04 < SubStack> because source maps are stupid like that
04:04 < SubStack> // sourceURL=s only work in eval grumble
04:04 < guybrush> i only use it since recently i started to hack on a new project where i need a lot of shared code
04:05 < guybrush> SubStack: component is not bad at all! it so cool tj shares his thoughts and its important to start discussion
04:06 < joshwnj`> SubStack: ok - do you know what range of browsers --debug will work for?
04:06 < guybrush> and lots of ideas to solve the problem, i.e. where tj is right - packages/modules may also contain assets which have to be served in some intelligent way
04:06 < joshwnj`> guybrush: good point about wreq not understanding node_modules, it also doesn't look for index.js if you just do require('someModule')
04:07 < guybrush> yes but i take the effort to play with it, because its just worth it :D
04:08 < guybrush> wreq/browserify hackery >>> requirejs or some other silly things
04:08 < guybrush> (i dont mean requirejs is silly, its great! i just dont like it :p)
04:08 < Raynos> requirejs is silly
04:08 < Raynos> AMD IS SILLY
04:08 < LOUDBOT> THAT'S VERY CLEAR AND MEANINGFUL.
04:09 < joshwnj`> yeah to me, browserify approach is so natural... like with other AMD stuff you have to think "now I'm using AMD", whereas with browserify you just write javascript
04:09 < guybrush> you have node require on the client
04:09 < guybrush> with all its goodness
04:09 < joshwnj`> and it just works(TM)
04:10 < guybrush> packagejson and stuff
04:10 < SubStack> guybrush: I mean another json file thing, I don't like that part of it
04:10 < guybrush> right!
04:10 < guybrush> full ack
04:11 < joshwnj`> SubStack: so... i'm going to keep badgering here because I think wreq is actually a lot more useful in development than browserify... :)
04:12 < joshwnj`> particularly for non-node devs
04:12 < joshwnj`> there's no install, no build, you just drop it in and away you go
04:13 < guybrush> i guess it would be cool to make a bfy-middleware which adds wreq-functionality
04:13 < joshwnj`> so i'm mostly trying to figure out, is there a reason to _not_ push this on my client's team?
04:13 < guybrush> i have already a module-name for that :DDD
04:13 < guybrush> joshwnj`: you dont push wreq on em, you just tell em to use commonjs require
04:14 < guybrush> as long as you are arround to fix small problems its a great way to do client-dev
04:15 < guybrush> but it sure depends on the team i guess
04:15 < joshwnj`> yeah
04:15 < guybrush> some even put jshint into git-hooks!!!
04:15 < joshwnj`> one thing I really love about wreq is that it pretty much disappears into the background
04:15 < joshwnj`> so, the team doesn't need to learn how to do wreq
04:16 < joshwnj`> and it actually simplifies so much about frontend JS dev
04:16 < guybrush> yes its only the require() thing, nothing else actually
04:16 < joshwnj`> no more of this nonsense of putting everything inside global "ABC.someModule.*" namespaces
04:16 < joshwnj`> and then hoping that nobody else used that same name :P
04:17 < guybrush> it actually took me some time to get rid of this namespace everything into one thing in my head
04:17 < guybrush> it took me also some time to grasp the local packages-thing VS global packages
04:17 < joshwnj`> yeah me too
04:18 < joshwnj`> for awhile there i was putting stuff in modules, closures etc
04:18 < joshwnj`> but it's so nice when you realize you can just write a function :)
04:18 < guybrush> true!
04:18 < guybrush> i really know what you mean
04:18 < guybrush> all this backbone things
04:18 < guybrush> and jquery
04:19 < joshwnj`> the whole "battle of the $" between jQuery and prototype
04:19 < joshwnj`> man, glad that one is over :)
04:19 < joshwnj`> but it would have never been an issue if we were doing commonjs require in the browser
04:19 < guybrush> again backbone and jquery are fantastic
04:20 < guybrush> i have it in use a lot, but i _love_ to think about ways to avoid them :DD
04:20 < joshwnj`> SubStack: so cheers to you for making & releasing browserify!! makes me feel like i'm living in the future :)
04:22 < joshwnj`> and thanks Raynos & guybrush for sharing tips and experience
04:22 < guybrush> thats why i am here :>
04:27 < joshwnj`> cheers guys, now gotta go back to work :)
04:28 < Raynos> o/
04:28 < Raynos> guybrush: gh link
04:28 < guybrush> you mean for component?
04:30 < guybrush> http://tjholowaychuk.com/post/27984551477/components
04:35 < SubStack> guybrush: I really hate manifests
04:35 < SubStack> so much
04:35 < guybrush> :D
04:35 < SubStack> just write a tool that generates javascript bundles
04:36 < SubStack> and you're done
04:36 < SubStack> then you don't need anything else
04:36 < guybrush> how do you handle assets
04:36 < SubStack> I've been using yarnify to compile html and css into js files
04:37 < SubStack> I can just do yarnify *.html *.css -o yarn.js
04:37 < guybrush> fonts
04:37 < guybrush> images
04:38 < guybrush> images canbe encoded into css
04:39 < Raynos> guybrush: no your gh account
04:39 < guybrush> it guybrush
04:39 < guybrush> *its
04:40 < guybrush> SubStack: i have to investigate the yarnify approach further, i really like it
04:41 < Raynos> i would use yarnify
04:41 < Raynos> if i can push the build step away
04:41 < Raynos> I use browserify-server
04:41 < Raynos> Write me a yarnify-server and I will be so happy
04:42 < SubStack> Raynos: fs.watch() the files and recompile accordingly
04:42 < SubStack> but really you shouldn't need to do that
04:42 < guybrush> SubStack: that is a problem with a huge codebase
04:42 < Raynos> SubStack: i hate build steps
04:42 < SubStack> with yarnify you make directories and they're completely self-contained
04:42 < Raynos> SubStack: I hate manually recompiling and hitting f5
04:42 < Raynos> whilst debugging a module in the browser
04:44 < guybrush> the compiling-workflow can be made really elegant with makefiles
04:46 < Raynos> still not good enough
05:21 < Raynos> MORE TINY MODULES
05:21 < LOUDBOT> GRAPH Y U NO STRAIGHT
05:24 < SubStack> so tiny
05:24 < SubStack> so right
05:49 < Raynos> route TCP: https://github.com/Raynos/stream-router/blob/master/examples/simple/server.js
05:55 < dools> TINY INSTRUMENTS
05:55 < LOUDBOT> TRIPLE KILL
06:08 < Raynos> Epic refactor: https://github.com/Raynos/multi-channel-mdm/commit/a0877e4606c6e08377c52fcc312e4f7d161fa0bc
06:09 < Raynos> Use small modules on NPM to reduce boilerplate & complexity and make examples pure and simple
06:17 < SubStack> ok so now I'm thinking that yarnify could work very differently but still pretty much have the same api
06:17 < Raynos> if your example code is over 10 lines then you need more tiny modules!
06:18 < guybrush> SubStack: i am excited to hear more about that
06:18 < SubStack> where css the css files get transformed into functions that can be run browser-side to generate output that works with arbitrary prefixes
06:18 < SubStack> then I can make yarnified css files work across bundles
06:18 < guybrush> like stylus?
06:18 < SubStack> unsure how stylus works
06:19 < guybrush> well its like coffee i would say, just for css
06:19 < guybrush> also it adds variables
06:20 < guybrush> and mixins like less and other stuff
06:20 < SubStack> this would be exactly the same as css
06:20 < guybrush> the important thing is, it has a js-api
06:20 < SubStack> so you can use whatever preprocessor you like so long as it compiles to css
06:21 < SubStack> it would just move the prefixing phase from the bundle step to the browser side
06:21 < guybrush> https://github.com/visionmedia/nib/blob/master/lib/nib/image.styl
06:21 < SubStack> but without needing to have a css parser browser-side
06:21 < guybrush> https://github.com/visionmedia/nib/blob/master/lib/nodes/color-image.js
06:21 < SubStack> I could just store the tokens as an array such that all I would need to do would be to chunks.join(prefix)
06:22 < guybrush> so the api of the yarnifyied module provides functions to alter the css?
06:23 < SubStack> no this is a thing that would only be used internally by yarnify
06:23 < SubStack> such that applying css rules to elements would work across bundles
06:24 < guybrush> i dont even know how a eco-system for modules with assets works
06:25 < guybrush> assets are not javascript, so its not like you can throw together some modules and make a website
06:25 < SubStack> you can do exactly that most of the time
06:25 < SubStack> just compile the assets to javascript
06:26 < guybrush> a common problem i have for example
06:26 < guybrush> i use jquery-ui
06:26 < guybrush> twitter-bootstrap
06:26 < guybrush> and a bunch of other things
06:26 < guybrush> the problem is to make them all look like 1 thing
06:26 < guybrush> that is a lot of shimming and stuff
06:26 < guybrush> which is not elegant at all - so i dont see how yarnify solves this problem
06:28 < guybrush> like, i want to use superCoolButtonNpmModule and 10 different widget modules, now i want all those widget modules to use the coolButton
06:28 < SubStack> the approach isn't to make them all look like 1 thing
06:28 < SubStack> the approach is for each one of those things to each look like 1 thing
06:29 < guybrush> hm i have to think about that
06:29 < SubStack> this approach doesn't let you impose your own stylings outside of the api
06:29 < SubStack> except actually what I'm hacking on now might
06:29 < SubStack> but you'll need to use the module's api to make it work
06:30 < guybrush> i think everything which involves the module-author to have to do something in a specific way is not so good
06:31 < guybrush> like component now, what i have seen so far it works with github-urls
06:32 < guybrush> in a component.json file or something i guess and it will provide a way to define assets which then can be used magically
06:32 < guybrush> on the client side
06:50 < Raynos> SubStack: https://github.com/substack/upnode/pull/13
06:50 < Raynos> guybrush: why do you use jquery-ui
06:52 < guybrush> drag&drop works pretty good
06:52 < guybrush> in most browsers
06:52 < guybrush> also selectable
06:56 < guybrush> also, if you have a running thing its often good to not touch it :D
06:58 < Raynos> guybrush: ...
06:58 < Raynos> jquery is a shitty tool
06:58 < Raynos> twitter-bootstrap is ok if your shit at CSS but their JS sucks balls too
06:58 < Raynos> guybrush: Help me out here, how am I supposed to respect you if you use jquery tools
07:03 < guybrush> i dont see why jquery a shitty tool is, and how am i supposed to know what kind of person you respect :D
07:06 < guybrush> its all about opinions in the end, the way i go usually is to respect the opinions of others and question my own
07:07 < guybrush> you want to make a simple website which works in all browsers? i go with jquery, and im not ashamed
07:09 < guybrush> and you know what!
07:09 < guybrush> I LIKE VI MORE THAN EMACS
07:09 < LOUDBOT> ARE YOU READY TO COCK?
07:09 < dools> who doesnt'?
07:10 < dools> there's a reason vi rhymes with jedi
07:10 < dools> and emacs rhymes with ....
07:10 < dools> hmmm
07:10 < dools> brown slacks?
07:10 < guybrush> vi is like a jedi! just different letters
07:11 < guybrush> oh actually i use jedit the most
07:11 < guybrush> jedi is in jedit!!!
07:12 < Raynos> guybrush: https://gist.github.com/1417030
07:12 < Raynos> jquery is mediocre :/
07:12 < guybrush> it works in all browsers
07:12 < guybrush> there are 10000000000000000 people looking for vendor-changes
07:13 < guybrush> and make sure jquery works in all browsers
07:13 < Raynos> ...
07:13 < guybrush> yes the code is not super sexy
07:13 < dools> any of those arguments would be valid if millions of people hadn't managed to produce millions of projects successfully using jquery
07:13 < guybrush> so what
07:13 < Raynos> dools: ... you can say the same about PHP
07:13 < guybrush> and its true
07:13 < guybrush> ...
07:13 < dools> if that post were "these are a set of reasons why jquery is difficult for beginners to learn and doesn't increase productivity" and that those two statements were accurate, then it would be completely valid
07:13 < Raynos> but there's a reason you don't use PHP
07:14 < dools> i most certainly do use php!
07:14 < Raynos> dools: ._.
07:14 < dools> almost exclusively in fact (although if i'm doing client work i usually deign to use django)
07:14 < Raynos> traitor
07:15 < Raynos> this is all besides the point. There is no good reason to use jQuery unless you simply don't know what your doing
07:16 < dools> i don't blame you though. without people who irrationally and deeply despised popular tools for not good reason, we'd never have change
07:16 < Raynos> dont use jquery -> learn to use the DOM effectively, dont use express -> learn to use node effectively
07:16 < dools> writing dom code is a massive pita
07:16 < Raynos> i despise jquery for other reasons
07:16 < Raynos> it spreads ignorance and incompetence
07:17 < dools> no it just spreads slidey little things and fading image galleries
07:17 < Raynos> The only thing thats a pain with dom code is creating elements
07:17 < Raynos> jquery is the main reason why the front end community is 10 years behind
07:17 < Raynos> RANT >:( INCOMING RANT
07:17 < LOUDBOT> INDUCTION! IT'S NOT JUST FOR MAGNETS ANY MORE
07:17 < dools> 10 years behind what!?
07:18 < Raynos> no.
07:18 < Raynos> I dont have time to rant about this
07:19 < Raynos> and it just makes me look irrational
07:19 < Raynos> i still blame jquery for the fact that the majority of javascript developers dont know what they are doing at all
07:20 < dools> i'd say the more logical conclusion is that you blame jquery for there being more people doing javascript development than there would otherwise be
07:20 < dools> (which makes it much cheaper to produce little sliding widgets and fading image galleries)
07:20 < Raynos> no
07:21 < Raynos> i blame jquery for the fact that there are zero client-side JS developers I look up to whilst there are tons of node JS developers I look up to
07:22 < dools> there aren't even that many node.js developers. maybe it's just a smaller community so you find it easier to meet people. it's a smaller community because of a lack of beginners tools making it accessible to the same number of people that jquery is. when those tools exist, the node.js community will be flooded with incompetent mediocrity and you'll just have to hide in a cave
07:24 < Raynos> ;_;
07:25 < Raynos> dools: how do you deal with a sea of mediocrity?
07:25 < Raynos> and node is very accessible
07:25 < Raynos> it's easy :P
07:26 < dools> by focusing on outcomes! i really quite enjoy writing php more than anything else (well, web applications anyway - I actually find that the process control in python is way easier/quicker to use -it's one of the few things that i really prefer to use python for over php). i'm not a computer scientist (studied engineering). I like to think i write pretty good code but the trick is i don't give a shit
07:27 < Raynos> I see
07:27 < Raynos> I can't do that. I have pride in my craft
07:27 < dools> yeah i spent a number of years feeling the same way
07:28 < dools> you know what i actually did was i spent a number of years building a PHP framework which i thought was incredible, but i did it almost completely in a vacuum.
07:28 < dools> it taught me a lot.
07:29 < dools> in particular it taught me not to code in a vacuum :) but more importantly it taught me that no matter how great you think something is when you right it, you won't like it in 5 years, and thusly all code is garbage so you just shouldn't worry about it
07:29 < dools> it's only value is in the outcome it produces
07:30 < guybrush> dools: also the process of producing the output has value
07:30 < guybrush> you gain knowledge
07:31 < guybrush> *of producing outcome
07:32 < guybrush> so if you use the same thing all the time
07:32 < guybrush> you will not learn much new things
07:33 < guybrush> but thats maybe too philosophically :D
07:33 < Raynos> dools: coding in a vacuum is bad, frameworks are bad.
07:33 < guybrush> anyways if you are into git and javascript, you will not use php nowadays
07:33 < Raynos> I know i wont like it in 5 years
07:34 < dools> guybrush: yeah there's personal value in it naturally
07:34 < Raynos> I already know I dont like code I wrote 3 months ago
07:34 < Raynos> dools: you may find this personal progression account useful http://stackoverflow.com/questions/5683916/node-js-express-vs-geddy/5683938#5683938
07:34 < guybrush> Raynos: i have so much code i dont want to publish because i think its just ugly and i would be ashamed...
07:34 < dools> Raynos: i can't read it right now but i will check it out
07:35 < Raynos> guybrush: i have a bunch too. A lot in of production code on this app that just sucks
07:35 < Raynos> but the code I write as open source is reasonably clean
07:35 < dools> guybrush: i'm not really that big a fan of asynchronous coding (and i'm more interested in "cheap" than "good" most of the time) but i certainly enjoy watching node.js and the way i write php has been influenced by the hyper modular approach the community is taking to package management
07:35 < dools> Raynos: i don't think frameworks are bad, but i do think frameworks that become a) monolithic and b) libraries are
07:36 < guybrush> dools: i used php and was impressed by the pear community
07:36 < guybrush> theres lots of reallllly good php out there
07:36 < guybrush> i loved the MDB2 module in pear
07:36 < dools> more to the point there's just lots of php full stop :) even if it's not "good" i stil want the option of using it if it works ;)
07:37 < guybrush> th xml-stuff in php is also excellent i think
07:38 < dools> yep it's pretty good - writing scrapers in php is pretty easy
07:38 < dools> (and doing dom templating ;)
07:38 < guybrush> i was really into xml/xsl some time ago :D
07:38 < dools> which i'm curently obsessed with
07:38 < guybrush> yeees
07:38 < dools> i never got into xsl! i have a friend who was insanely into i
07:38 < dools> t
07:38 < dools> i use xpath a lot though
07:38 < guybrush> i was like thinking about xsl/xml all the time
07:39 < guybrush> but somehow with node id didnt matter anymore lol and all i wanted to think about from now on was async stuff :D
07:40 < dools> haha
07:40 < guybrush> ry's talk made me excited
07:40 < guybrush> with the live irc-demo
07:40 < guybrush> it was like WHAAT! :D
07:55 < SubStack> I had been bitten by thread-based concurrency 3 times previously before messing with node
07:55 < SubStack> in python, in haskell, in ruby
07:55 < SubStack> blocking is such a terrible thing for functions that perform i/o to do
07:56 < SubStack> and then you need to hack around it to do other things at the same time and use special synchronization channels and mutexes to aggregate data from the threads
07:56 < SubStack> so much work
07:56 < SubStack> and thread scheduling is way shittier than process scheduling
07:57 < SubStack> very easy to starve a thread of its cpu slices for thousands of milliseconds if you have another thread crunching down on cpu
07:57 < SubStack> even on multicore systems
07:57 < SubStack> and that just absolutely does not happen with processes ever
07:57 < SubStack> fuck the haskell RTS seriously
07:58 < guybrush> haskell code is so nice to look at, its like art :D
07:59 < guybrush> with all this arrows and colons
08:00 < SubStack> I wasted so much time dicking with the RTS that could have been spared by just splitting the program up into multiple processes that talk to each other over tcp to start with
08:05 < Raynos> dominictarr: https://github.com/Raynos/multi-event#multi-event
08:05 < Raynos> Like mux-demux but event emitters!
08:06 < Raynos> SubStack, dominictarr: https://github.com/Raynos/multi-event/blob/master/lib/proxyStream.js does this pattern look familiar
08:06 < Raynos> it takes a source stream and copies it onto a target, basically make the target behave as if it was that source stream
08:08 < SubStack> yes I've written those before
08:08 < Raynos> is there a module to do that?
08:28 < Raynos> dominictarr: I would appreciate if you could look at https://github.com/Raynos/multi-event/tree/master/examples/boot, it uses remote-events and doesn't work when using a browser connection but works with TCP. this feels like a browser based race condition
09:29 < SubStack> read this: https://plus.google.com/u/0/110981030061712822816/posts/KaSKeg4vQtz
09:29 < SubStack> especially Raynos and dominictarr
09:29 < SubStack> and isaacs of course
09:30 < SubStack> #stackvm is basically a hotbed of radical software leftism on the grounds laid out
09:30 < Raynos> thats very long
09:30 < SubStack> it's a yeggae post, they are long but so worth it
09:31 < SubStack> s/ae/e/
09:31 < SubStack> fleet and seaport are basically software anarcho-marxism
12:54 < dominictarr> "Production systems should never have dangerous or risky back-doors. " there is one conservative thing I'd agree with
12:55 < dominictarr> observe that to be conservative you must have something to be conservative about.
12:55 < dominictarr> but you can be liberal with nothing.
12:57 < SubStack> I approve of back-doors
12:57 < SubStack> really handy to quickly go in and fix brokenness
13:03 < dominictarr> there are backdoors and then there are trapdoors.
13:04 < dominictarr> I mean, you can put a lock on your back door.
13:06 < dominictarr> the thing that irks me about this article is that hes taken a distinction I consider to be moronic and forced in onto something I love.
13:07 < dominictarr> the political spectrum is a lie.
13:08 < dominictarr> forcing people into two camps creates more problems.
13:08 < dominictarr> it's the interplay between careful people and risky people that make things work.
13:08 < dominictarr> either all "liberals" or all "conservatives" would fail.
13:20 < devaholic> dominictarr: or would the continuum just shorten?
13:20 < dominictarr> no, that would make every one the same.
13:21 < dominictarr> I mean, there are people with different approaches.
13:21 < dominictarr> and you need both.
13:21 < devaholic> but concepts of sameness and difference only exist in comparing to other people
13:22 < dominictarr> the problem is organising those groups into opposing camps.
13:22 < dominictarr> like this dude recommends.
13:22 < SubStack> the thing that I dislike most about software engineering as commonly practiced is planning
13:22 < dominictarr> absolutely
13:22 < SubStack> detailed plans are such a waste
13:23 < dominictarr> but if you got a whole bunch of hackers together and was just like "go crazy"
13:23 < SubStack> if you know enough about the problem domain to write detailed plans that will accurately describe the solution then you've failed at not writing reusable libraries
13:23 < dominictarr> you'd get a huge mess.
13:24 < dominictarr> SubStack, your style may seem chaotic. but it's very organised chaos.
13:24 < SubStack> you just need a basic level of infrastructure to make "go crazy" practical
13:24 < SubStack> git and package managers do wonders there
13:24 < dominictarr> absolutely.
13:25 < dominictarr> yeah, there are parts of the software ecosystem where correctness is ESSENTIAL
13:25 < dominictarr> and parts where speed is critical.
13:25 < dominictarr> other parts where flexibility is the most important.
13:26 < dominictarr> even throughout the life time a single project the needs for these things change.
13:27 < dominictarr> now, there may be programmers who excel at each of these areas.
13:28 < dominictarr> but to put it down to politics is stupid.
13:28 < dominictarr> balanced conflict is good.
13:29 < dominictarr> you need to have some one you kicks everyones asses till they write tests, or documentation.
13:30 < dominictarr> and sometimes you need a punk ass motherfucker who will rewrite some critical part of the system in secret and then be like "LOOK WHAT I DID"
13:31 < SubStack> and push it to production before telling anybody
13:32 < dominictarr> they call that "heroic programming" in the literature.
13:32 < dominictarr> some say that no large project can succeed with out heroic programming.
13:33 < dominictarr> I don't know.
13:33 < dominictarr> but it makes for dramatic stories.
13:35 < dominictarr> usually though, that rewrite will depend on other well defined and/or well tested parts of the system.
13:35 < SubStack> pow https://github.com/substack/split-css
13:36 < SubStack> this is like that other css prefixing thing I wrote only better
13:36 < SubStack> reused one of the tests even
13:36 < dominictarr> also, I challenge anyone to find me a "large software system" that didn't start by someone just hacking it together.
13:36 < SubStack> better because it creates simple arrays that I can easily add custom prefixes to browser-side
13:40 < SubStack> dominictarr: I suppose the danger comes in different groups exerting influence outside their narrow domain of expertise
13:40 < SubStack> two groups need to work together by way of some common codebase, one side wins
13:41 < SubStack> too much domination of a particular ideology throughout an organization and those heuristics attain institutional inertia
13:42  * SubStack sleeps
13:46 < dominictarr> this is the problem with Americans who think the opposite of Partisan is Bipartisan. it's not, it's Non-Partisan.
13:51 < dominictarr> my point is that there is a reason that there are different types of people. and although it may be hard to deal with people who are different to your type. you ignore them at your peril.
13:55 < rook2pawn> something i learned last night interacting with some friends: the differences in people are not obvious, yet extreme. very good to understand how people are different
15:58 < isaacs> Raynos: the reason I called your comment trololol is because i was already just finishing up this: https://github.com/isaacs/async-cache
15:58 < isaacs> Raynos: ;)
16:03 < devaholic> isaacs: nice module!
16:10 < devaholic> looks like someone did that web hook service thing, http://browserver.org/
16:10 < devaholic> but its not really working
16:10 < devaholic> cc SubStack Raynos dominictarr maxogden
16:11 < dominictarr> devaholic, whats up?
16:12 < devaholic> didnt mean to interrupt! i just remembered we were talking about that a few days ago
16:13 < dominictarr> oh, yes
16:13 < devaholic> although how exactly the requests are handled is up for debate, though i suppose a node http server would be nice, it doesnt make sense entirely
16:14 < devaholic> gateway timeout
16:23 < devaholic> node style http server in the browser that is
16:59 < chapel> isaacs: nice
16:59 < chapel> Ive been using redis as a lru cache
16:59 < chapel> since it handles that process well
17:00 < chapel> and it makes it easier to scale out
17:00 < chapel> since we run over multiple processes
18:41 < isaacs> chapel: yeah, it's pretty good for that
18:41 < chapel> good stuff :)
18:42 < chapel> are you using it in npm www?
18:42 < isaacs> but if your goal is to prevent a syscall, then it's not really an option
18:42 < isaacs> i will be soon
18:42 < isaacs> i'm using lru-cache all over npm-www
18:42 < isaacs> and redis
18:42 < isaacs> but not async-cache yet
18:48 < chapel> ah nice
19:56 < tanepiper> Yegge :|
21:02 < dominictarr> you can now select text in hipster!
21:07 < niftylettuce> I THINK A BLOG INSIDE A BLOG WHILE WE BLOG WHILE WE BLOG IS HOW WE SHOULD BLOG, DO YOU BLOG?
21:07 < LOUDBOT> I'VE GOT A FEVER AND THE ONLY CURE IS SLAVERY
21:11 < dominictarr> niftylettuce, you are a hipster, I wrote a text editor for you.
21:23 < Raynos> devaholic: That's just a child plays version of seaport-proxy services in a browser
21:27 < devaholic> Raynos: you surely could register each browser with seaport, which would get a subdomain automatically with mountie or my seaproxy
21:36 < Raynos> devaholic: yes. That part already works with seaport-proxy
21:36 < Raynos> the harder problem
21:36 < Raynos> which browserver does not solve either
21:36 < Raynos> is how to make shit not break when the proxy server goes down
21:36 < Raynos> making reconnect work out of the box
21:54 < devaholic> yep just failed requests that need a retry, redispatches from mountie when possible, suddenly slow browsers, etc
22:01 < niftylettuce> SubStack: what do you guys use for cronjob-like events?
22:03 < dominictarr> Raynos, you need a gossip protocol. with multiple proxies.
22:05 < devaholic> also shouldnt a browserver thing be tied to a session instead of a single browser?
22:06 < devaholic> so… if i have three tabs open they all update with the new data and not just one at random
22:07 < Raynos> dominictarr: this might be too crazy for me
22:07 < Raynos> I'm writing a server proxy
22:07 < Raynos> which ill show off tonight
22:07 < Raynos> to remove complexity from seaport-proxy
22:07 < Raynos> Now the question I have
22:07 < Raynos> is if a client (browser) opens a stream to me
22:08 < Raynos> a named stream from mux-demux. And I don't know how to handle that name (404 basically) how do I tell the browser ?
22:08 < Raynos> Right now I'm ending the stream
22:08 < Raynos> Example: https://github.com/Raynos/stream-router/blob/master/index.js#L20
22:09 < dominictarr> Raynos, yeah that is right.
22:09 < Raynos> dominictarr: I want to send the client meta data like 404 or 500
22:10 < dominictarr> it would be could to be able to send that stream an error.
22:10 < dominictarr> stream.error(error)
22:10 < dominictarr> and it gets emitted as 'error' at the other end.
22:10 < Raynos> dominictarr: yes it would
22:10 < Raynos> mux-demux feature request o/
22:11 < Raynos> or should I tell isaacs a TCP server wants to send an error to the remote end (the TCP connection) and this should go into the stream interface
22:11 < Raynos> well any stream server wants to send an error to the remote connection to that stream server
22:12 < dominictarr> Raynos, isaacs would never do that.
22:12 < Raynos> dominictarr: :(
22:12 < dominictarr> It makes sense to add to mux-demux though
22:12 < Raynos> cool
22:12 < dominictarr> since it's already a protocol.
22:12 < Raynos> dominictarr: did you see multi-event ?
22:13 < Raynos> its kind of broken :( i think it's a bug in remote-events
22:14 < dominictarr> it will be easy to add to mux-demux. because each message has a event name type
22:14 < dominictarr> just send another one, like the data, new, pause, resume, end, and close, events.
22:14 < dominictarr> with the right ID of course.
22:15 < dominictarr> Raynos, yeah. I say multi event
22:15 < dominictarr> saw.
22:15 < Raynos> cool
22:16 < dominictarr> the thing I don't like about building up wrappers is we'll end up with too many wrappers that essentially do the same job.
22:16 < dominictarr> but they'll all do it slightly differently.
22:16 < dominictarr> we need to think of a simple consistent way of attaching endpoints to mdm, etc.
22:16 < Raynos> dominictarr: i know what you mean
22:17 < Raynos> dominictarr: wait I dont
22:17 < Raynos> dominictarr: consistent way of attaching endpoints to mdm means?
22:17 < Raynos> well multi-event takes an mdm object
22:17 < Raynos> for example I can use multi-event in the client (browser only) and have the server just deals with streams directly
22:18 < dominictarr> well, here remote-events is the end point. it gets attached to mdm (some .pipe(...) boilerplate involved)
22:19 < dominictarr> multi-event wraps that but only does it for remote-events
22:20 < Raynos> true
22:20 < Raynos> well that can be solved easily
22:21 < Raynos> by allowing you to swap out remote-events
22:21 < dominictarr> yeah, may need more experimentation.
22:21 < dominictarr> have you seen this project: https://github.com/dominictarr/crdt
22:22 < Raynos> dominictarr: https://github.com/Raynos/stream-store#example-with-custom-stream-generators
22:22 < Raynos> dominictarr: I think crdt is super awesome exciting
22:22 < Raynos> but it doesnt have enough docs for me to see whats going on
22:22 < Raynos> nor have I had the chance to play with it
22:23 < dominictarr> I'm gonna bedoing some stuff with it again next week.
22:23 < Raynos> sweet
22:23 < Raynos> I want to focus on my crazy experiments
22:23 < Raynos> something like browserver
22:23 < Raynos> but super sweet
22:24 < dominictarr> I'm gonna do a remote presentation for the dublin node user group, so should be good docs (& examples) then!
22:25 < dominictarr> I just mention it because it's another example of the kind of thing you'd want to plug though mux-demux.
22:25 < Raynos> yeah I know
22:25 < Raynos> I'm plugging a lot of thigns through mux-demux :)
22:26 < Raynos> I'm building stream routers with is
22:26 < Raynos> routing on the uri I pass into meta data over mux-demux
22:29 < dominictarr> stream routers will probably be a part of it.
22:30 < dominictarr> Raynos, what is stream store for?
22:30 < Raynos> dominictarr: https://github.com/Raynos/stream-router
22:30 < Raynos> stream routers are already written
22:31 < Raynos> dominictarr: https://github.com/Raynos/multi-channel-mdm/blob/master/index.js#L9
22:31 < Raynos> stream store is used by multi channel
22:31 < Raynos> which I might rename to channel
22:31 < Raynos> dominictarr: https://github.com/Raynos/redis-stream-store#example
22:32 < Raynos> the idea is that multi channel takes an arbitary stream store, stream-store is the default in memory store if you dont pass in a special one
22:32 < dominictarr> oh, so it's a key value store but with streams?
22:33 < Raynos> "yes"
22:33 < Raynos> its just a key value store
22:33 < Raynos> its just meant to only contain streams but you can put any value in it
22:33 < Raynos> im improving it atm to match the ES6 Map interface
22:34 < dominictarr> Raynos, cool! I have written an file system endpont for it: https://github.com/dominictarr/kv
22:36 < Raynos> dominictarr: https://github.com/Raynos/stream-store/blob/master/index.js#L7 rewritten
22:56 < Raynos> dominictarr: https://gist.github.com/3318760
22:56 < Raynos> what's the correct way to ensure a stream is closed?
23:03 < dominictarr> Raynos, what is the context?
23:03 < Raynos> dominictarr: https://gist.github.com/ce20969bab9c4fac0736
23:03 < Raynos> a client can claim to be a server by opening a named stream
23:04 < Raynos> then other clients can connect to the client that is a "server"
23:04 < Raynos> when that "server" goes down. (the stream ends) I want to close all other client connections to it
23:04 < Raynos> the stream objects are mdm streams from mdm.on("connection", handler)
23:05 < dominictarr> mux-demux does basically what you do here when the underlieing stream closes.
23:05 < dominictarr> iterate over the streams and end them in some way.
23:06 < Raynos> dominictarr: except that doesn't work here. Because I create one MDM object per browser <-> server connection
23:06 < Raynos> oh wait
23:06 < Raynos> you mean I should take a look at mux-demux
23:06 < Raynos> and see how it ends them
23:06 < Raynos> you call end & destroy
23:08 < maxogden> SubStack: http://xdissent.github.com/ievms/
23:33 < Raynos> dominictarr: https://gist.github.com/3ced992657446524dda6
23:35 < SubStack> maxogden: seen it
23:35 < maxogden> kewl
23:35 < dominictarr> Raynos, what is the code that is calling it?
23:36 < dominictarr> something runnable, preferably.
23:37 < Raynos> dominictarr: Ehm I guess I can try
23:37 < dominictarr> didn't we change that so it emitted?
23:37 < dominictarr> maybe you have an old version installed there?
23:38 < Raynos> no i dont
23:38 < Raynos> ill take about 10 minutes to reproduce
23:41 < Raynos> dominictarr: the error still bubbles up but ends https://github.com/Raynos/mux-demux-shoe/blob/master/index.js#L27 because there is nowhere for it to go
23:43 < Raynos> dominictarr: https://gist.github.com/3ced992657446524dda6 raw is easier to read :P
23:43 < dominictarr> shouldn't your application be listening for the error?
23:44 < Raynos> dominictarr: It should but I cant get to the error which is simply a bug in mux-demux-shoe. I should have it emit on the return value of the shoe or something
23:44 < Raynos> but the gist shows an obvouis bug because the new event comes in but its not in the streams list
23:45 < dominictarr> yeah, this looks like the problem with mdm where id didn't emit the error on the outer stream.
23:46 < Raynos> it emits the error on the outer stream, thats my bug
23:46 < Raynos> but its a further bug with mdm
23:47 < dominictarr> you right, that does look like a bud.
23:47 < dominictarr> bug
23:47 < dominictarr> if there was a new event, it should have the stream.
23:47 < Raynos> exactly
23:47 < Raynos> I think I know what this bug is
23:48 < Raynos> its streams from one MDM getting into another MDM
23:48 < Raynos> I'm sharing streams between MDMs
23:48 < dominictarr> how?
23:48 < dominictarr> why don't you just pipe from one to the other?
23:49 < Raynos> reproducing atm
--- Log closed Sat Aug 11 00:00:59 2012