Pyxley: Python Powered Dashboards
multithreaded.stitchfix.com
Pyxley: Python Powered Dashboards
1–10 of 47 posts
Re: Pyxley: Python Powered Dashboards
#2looks cool. shiny is very neat, but has the limitation of having R behind it and debugging ain't fun. I very much look forward to testing pyxley!
Re: Pyxley: Python Powered Dashboards
#3link to examples is 404, a possibly correct link https://github.com/stitchfix/pyxley/tree/master/examples
Re: Pyxley: Python Powered Dashboards
#4link to examples is 404, a possibly correct link https://github.com/stitchfix/pyxley/tree/master/examples
Fixed! Thanks for the catch.
Re: Pyxley: Python Powered Dashboards
#5looks great. but i can't help but think it would save everyone a lot of time -- maybe not up-front, but in the long-run -- if we wrote these frameworks in c and just wrote language bindings for r, python, ruby, etc. why are we rebuilding good frameworks over again just because they're not written in our preferred language?
Re: Pyxley: Python Powered Dashboards
#6Will work great until you try to render 50,000 points and your browser crashes because it's build on d3.
Re: Pyxley: Python Powered Dashboards
#7looks great. but i can't help but think it would save everyone a lot of time -- maybe not up-front, but in the long-run -- if we wrote these frameworks in c and just wrote language bindings for r, python, ruby, etc. why are we rebuilding good frameworks over again just because they're not written in our preferred language?
Good idea! What's stopping you?
Re: Pyxley: Python Powered Dashboards
#8I've been looking for something to do this (below) in python at least on backend.
Big screen on wall with 6 or so boxes. Each box displaying data which updates in real time. Such as
- scrolling list of source control commits
- graph of busy/idle slaves
- single big number, pending builds
- graph of open ticket counts
- etc
Re: Pyxley: Python Powered Dashboards
#9looks great. but i can't help but think it would save everyone a lot of time -- maybe not up-front, but in the long-run -- if we wrote these frameworks in c and just wrote language bindings for r, python, ruby, etc. why are we rebuilding good frameworks over again just because they're not written in our preferred language?
There is a big divide between interpreted and compiled resources though.
If you have the original source in an interpreted language, it supports your ARM raspberry pi or chromebook just as well. With the C variation you need to build / package / install.
I've kinda just come to accept that code re-use cross language has never been good except with the unix pipe.
Re: Pyxley: Python Powered Dashboards
#10looks great. but i can't help but think it would save everyone a lot of time -- maybe not up-front, but in the long-run -- if we wrote these frameworks in c and just wrote language bindings for r, python, ruby, etc. why are we rebuilding good frameworks over again just because they're not written in our preferred language?
There is a big divide between interpreted and compiled resources though. If you have the original source in an interpreted language, it supports your ARM raspberry pi or chromebook just as well. With the C variation you need to build / package / install. I've kinda just come to accept that code re-use cross language has never been good except with the unix pipe.
haven't linux package managers (e.g. emerge, aptitude, yum, etc.) basically solved the packaging problem?