#dat

pkafei: but if you wanted to send 2 csv files in an email it would use multipart encoding to combine them (i think thats how it works)

ogd: but one csv file would not require multipart-encoding?

pkafei: theoretically it could

pkafei: multipart is like a zip or a tar

pkafei: where are you getting this data?

ogd: so in the case of a zip file- part 1 would be downloading the file and part 2 would include unzipping the file

ogd: from my local machine

pkafei: where is the multipart data coming from?

pkafei: yea with multipart you can either unpack it as a stream as it is downloaded or download it all first and unzip the whole thing at once

odg: I have a sneaking suspicion that I am in fact not dealing with multipart data

pkafei: haha

pkafei: odds are if you are reading a .csv file it probably isnt

ogd: I'm just in the process of writing a Python wrapper to stream csv files to dat

odg: at this point my script opens the file but does not post it into a dat datastore

ogd: so the result is I create a new key with no data

odg: I'm going to keep hacking away at this problem- if I have any issues I will ask karissa for help

pkafei: ah it sounds like you maybe arent sending the data in the http body correctly on the upload

erikg: alright merged, woot!

ogd: hurray!

so glad to have --tsv output

it's all the rage in bioinformatics

lol

erikg: Yay!

[dat] maxogden pushed 1 new commit to master: http://git.io/AmhD0A

dat/master f43fe91 Max Ogden: 6.9.0

woot

finnp: had a discussion with ryanj last night about dat on openshift

finnp: have you tried the button in the readme here? http://github.com/maxogden/dat-server

finnp: two main issues are: deployment is slow because we have a lot of `npm install` that needs to happen

finnp: so one hack to make it faster is to make a branch where we check in the node_modules to git, and use that as a sort of stable deploy branch

finnp: try the deploy out and you'll see what i mean in regards to the slowness

finnp: another issue is that they dont have a way to set env vars from the web, you have to do it via CLI

ryanj: yo!

hi!

finnp: a workaround for the env var issue is to turn dat into a cartridge

ryanj: finnp is our intern in berlin, ryanj works on openshift

finnp: cartridges are like heroku addons. and they can create their own random credentials that show up in the users admin page

finnp: so in that case dat would be like an external database service that gets added to the app

finnp: but that means we would have to do something like package only the dat-editor frontend as a standalone server and configure it to talk to the external dat

ogd: ok, interesting i am just creating an account

ryanj: hej!

finnp: feel free to ping me if you have any openshift Qs. I'm interested in helping build a cart if its sounds useful

finnp: i had another idea which was to have smoething in the dat admin ui itself where you could set your admin pass on first run

finnp: but we'd have to like salt and hash the pw and store it on disk somewhere

substack: do you have a module for monkeypatching console.* methods for the purposes of intercepting to transmit during headless testing in remote browsers?

substack: also im writing a module for running tape tests in atom-shell, and need a good pun involving atoms and tape

ogd: i think that having it in the dat admin (cli and ui) is a good idea.

ogd: and storing it on disk wouldn't be the worst idea.

karissa: yea as long as we get the crypto right around storing hashed pws

on OpenShift those details usually end up in the system ENV

plain text

ryanj: yea thats how we do it now

ryanj: thanks

ogd: I don't have a module for it but there's console-browserify

it doesn't seem pluggable though

substack: https://github.com/maxogden/console-patch

nifty

ogd: if you need to serialize those results over xhr/websockets you can use https://www.npmjs.org/package/object-inspect in the patch function

it also handles dom elements gracefully because dom elements otherwise have evil circular refs where the resulting reference is !== some previous values

so if you try to stringify them your whole program dies

substack: nice

ogd: mh deploying a simple hello world on openshift already needs 2.5 minutes, npm install adds like 1 minute to that

finnp: ah ok

ryanj: Is it normal that deploying on openshift needs at least 2 minutes for a simple node app?

finnp: the initial app create is usually on the slow side. Waiting for DNS to propogate takes some time

Also, the free apps run on slower hardware

ryanj: okay. it would be cool if the web "Create Application" workflow would show some progress logs instead of a spinner

finnp: totally agree

We're already rewriting the build system, so hopefully the UX will improve soon

ish

ryanj: okay awesome. is the web frontend open source as well?

finnp: it sure is

it's written in ruby though

I was about to go though and attempt to create a PR for adding ENV vars

ryanj: that would be great!

ryanj: it could be cool if you could do this in such a way that you could set defaults through the url

yeah, that was going to be my initial solution.

ryanj: great :)

Maybe import all querystring params that start with "env_" or something?

Once that is working, I could add a form that shows which vars were imported, giving the user a chance to edit/review/approve

before creating the app

Maybe I should search for querystring params that are in all caps, instead of looking for an "env_" prefix to strip

ryanj: i think looking for "env[name]" query parameters would be nicer. caps sensitive url would be weird

that works for me. They were already using [] in the url anyway

ryanj: yap.

ryanj: i think the ui should allow people to also add their own env vars at that point. so it would be like a 2-column table with input fields and a possibility to add new rows

substack: ahh it would be nice if object-inspect output valid JSON