| Time |
S |
Nick |
Message |
| 00:57 |
|
pdurbin |
https://travis-ci.org/OSSIA/OSSIA/jobs/55010038 from https://github.com/OSSIA/OSSIA/blob/master/.travis.yml seems to be a good example of testing on Mac OS X from Travis |
| 00:57 |
|
pdurbin |
more at http://docs.travis-ci.com/user/workers/os-x-infrastructure/ |
| 00:59 |
|
pdurbin |
ah but "We are not currently accepting multi-OS requests" according to http://docs.travis-ci.com/user/multi-os/ . interesting |
| 01:10 |
|
sivoais |
yeah... I would really like OS X testing for PDL. However, it would be useful to run my own CI anyway |
| 01:24 |
|
pdurbin |
sivoais: run your own? what would you use? Travis? Jenkins? |
| 01:36 |
|
sivoais |
pdurbin: probably Jenkins. I hear good things about that |
| 01:37 |
|
pdurbin |
sivoais: remind me to let you know when I'm done with these slides: http://bl.ocks.org/pdurbin/03a76a26bd325af0b17e |
| 02:06 |
|
sivoais |
ok! :-) |
| 02:18 |
|
pdurbin |
:) |
| 03:03 |
|
pdurbin |
sivoais: added some screenshots: http://bl.ocks.org/pdurbin/raw/03a76a26bd325af0b17e |
| 03:06 |
|
* sivoais |
looks |
| 03:07 |
|
sivoais |
cool. I think I will need Jenkins at my lab too |
| 13:53 |
|
pdurbin |
interesting question posed at http://www.se-radio.net/2015/04/episode-224-sven-johann-and-eberhard-wolff-on-technical-debt/ |
| 13:54 |
|
pdurbin |
... would your rather work on a code base with a great artitecture and no tests or a code base with a not so great architecture and lots of tests? |
| 14:02 |
|
aditsu |
great architecture, instant choice! |
| 14:02 |
|
aditsu |
tests schmests |
| 14:04 |
|
pdurbin |
heh. one of the two guys on the podcast agrees with you :) |
| 14:13 |
|
pdurbin |
aditsu: even if you are new to the project? if you didn't write any of the code? |
| 14:13 |
|
aditsu |
sure, I thought that was assumed |
| 14:14 |
|
pdurbin |
just checking :) |
| 14:14 |
|
aditsu |
if really needed, tests can be added later, but changing the architecture is much harder |
| 14:15 |
|
pdurbin |
yeah |
| 14:15 |
|
pdurbin |
I just like tests, I guess. |
| 14:15 |
|
aditsu |
and working with a "not so great architecture" is just demoralizing |
| 14:16 |
|
pdurbin |
I guess you should look at the code before taking a new job. :) |
| 14:21 |
|
pdurbin |
"knowledge island" |
| 14:21 |
|
pdurbin |
like a bus number |
| 14:34 |
|
aditsu |
huh? |
| 14:35 |
|
pdurbin |
if only one person knows about a subsystem in the code |
| 17:55 |
|
pdurbin |
prologic: have you read this already? http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/ |
| 17:55 |
|
pdurbin |
mentioned at http://www.talkpythontome.com/episodes/show/5/sqlalchemy-and-data-access-in-python |
| 20:44 |
|
prologic |
pdurbin, hmm not I haven't |
| 20:44 |
|
prologic |
but "Python is very, very slow compared to your Database" |
| 20:44 |
|
prologic |
that's when I stopped reading :) |
| 21:52 |
|
pdurbin |
prologic: that's the sqlalchemy guy! have some respect :) |
| 23:17 |
|
prologic |
I just hate reading articles like that |
| 23:17 |
|
prologic |
honestly |
| 23:18 |
|
prologic |
it's basically negative up front |
| 23:18 |
|
prologic |
Python is really not that slow |
| 23:18 |
|
prologic |
your CODE might be! |
| 23:19 |
|
prologic |
far too often I think us dynamic zealot programmers fall into the habit and trap of just stitching crap together without even thinking about performance or how it might be used |
| 23:19 |
|
prologic |
take for example Django |
| 23:19 |
|
prologic |
whilst it's great "mega" framework that does a lot of things |
| 23:20 |
|
prologic |
web apps developed with it can be a bit slower than say web apps written with very specific high performance code in something like oh I dunno circuits.web? or asyncio or even plain 'ol wsgi |
| 23:20 |
|
prologic |
we fall into the trap with dynamic languages of adding abstraction on top of abstraction and layers upon layers |
| 23:21 |
|
prologic |
function and object lookup/creation and exception handling are generally expensive operations |
| 23:21 |
|
prologic |
don't believe me? :) I can show you some benchmarks to make my point :) |
| 23:21 |
|
prologic |
and let's face it; ofc your database is going to be faster |
| 23:22 |
|
prologic |
it's written in C/C++ most likely |
| 23:22 |
|
prologic |
and written with very specific high performance code |
| 23:22 |
|
prologic |
perhaps I'll have another read of the article tonight at home :) |
| 23:50 |
|
pdurbin |
prologic: you make some good points |
| 23:50 |
|
pdurbin |
and it sounds like you made it farther than I did :) |
| 23:50 |
|
pdurbin |
of course I *did* just listen to him talk for an hour :) |
| 23:56 |
|
prologic |
yeah well |
| 23:56 |
|
prologic |
whilst I may have respect for the guy |
| 23:56 |
|
prologic |
SQLAlchemy is an abstraction layer that's quite complex with many parts |
| 23:56 |
|
prologic |
it adds a layer of abstraction ove ryour database |
| 23:56 |
|
prologic |
and yes this costs in terms of performance |
| 23:57 |
|
prologic |
albeit using an implementation of Python such as PyPy **will* help speed things up dramatically because it can compile into machine code all of the "hotspots" |
| 23:57 |
|
prologic |
but my points above are stillv ery valid |
| 23:58 |
|
prologic |
I find a lot of programmers that use dynamic languages such as Python, Ruby, PHP, etc are often very lazy (in that order of least lazy to most lazy) |
| 23:58 |
|
prologic |
or s/lazy/sloppy |
