writing

need to do content generation writing in a separate mode from editing. 'write with the door closed. edit with the door open.' it's too easy to overthink things if i'm trying to argue with a room full of people while i'm putting down my first draft. just get it all out and pretend no one will read it when i write the first draft. then come back to edit while imagining explaining it to someone else.

have faith in your own editing. yes, the first draft will be awful. but, yes, it get better with more work.

liverebel

http://zeroturnaround.com/
automatic continuous deployment, with a plugin hook available for jenkins.

http://www.youtube.com/watch?v=3HI7mv_791k

amazon aws/ec2, picloud

looks like amazon gives you up to a year to try out some free cpu time on their cloud computing nodes.
http://aws.amazon.com/free/terms/

also, their spot instances allow you to bid for time, rather than paying the fixed on-demand rates. looks like the discount is significant, if you can handle the unpredictability. nice example of running a jenkins build slave on spot, too. also refs princeton consultants and their optispotter, which helps smallish ($50mil) hedge funds find hft opportunities.
http://aws.amazon.com/ec2/spot-instances/
http://www.youtube.com/watch?v=-vAAuTs9iu4

picloud still looks like a good way to get started. can do fractional hours, and prices are comparable to ec2 on-demand. they allow you to create an environment on a virtual ubuntu, so you can install whatever you need as if you had a local filesystem.
http://aws.typepad.com/aws/2012/12/picloud-and-princeton-consultants-win-the-first-amazon-ec2-spotathon.html

hotel wifi rip-offs

wow, cool idea i need to try next time i have to: socks proxy through ssh tunnel that persists after your web login wifi connection is terminated.

http://stockrt.github.io/p/navegando-com-seguran%C3%A7a-e-sem-tarifa%C3%A7%C3%A3o-em-caf%C3%A9s-e-hot%C3%A9is/

learning git

sooner or later (probably later) i need to learn something about git. here are some links that i don't have time to read right now:

http://www.youtube.com/watch?v=ZDR433b0HJY
http://betterexplained.com/articles/aha-moments-when-learning-git/
http://kentnguyen.com/development/visualized-git-practices-for-team/
http://haacked.com/archive/2012/03/15/visualize-git-with-seegit.aspx
http://danlynn.org/home/2012/4/30/git-branch-visualization-on-command-line.html
http://think-like-a-git.net/sections/graphs-and-git.html
https://github.com/esc/git-big-picture
http://blog.kfish.org/2010/04/git-lola.html
http://www.syntevo.com/smartgithg/index.html
http://www.sourcetreeapp.com/

git vs. mercurial
http://stackoverflow.com/questions/35837/what-is-the-difference-between-mercurial-and-git
http://mercurial.selenic.com/wiki/GitConcepts
http://jhw.dreamwidth.org/1868.html
http://www.atlassian.com/dvcs/overview/dvcs-options-git-or-mercurial
http://www.wikivs.com/wiki/Git_vs_Mercurial
http://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/

apparently bitbucket hosts free private repos, and the hg-git plugin for mercurial allows you to use a hg client on a git repo.
http://hg-git.github.io/

hg is in python, which is very nice for extensibility, but dulwich is a pure python implementation of git. can't tell for sure, though it does look like it's a little low level.
https://github.com/jelmer/dulwich

delta debugging, automated debugging

i was thinking about unit testing and delta debugging, or differential debugging?, and i thought python's introspection tools could make it possible (and not too hard) to do this automatically. i could make a tool that takes 2 adjacent versions from a repo, runs a test synchronously on both of them (that fails on only one of them), and drops into 2 debuggers at the point where a callable is about to return with 2 different values. that would make it really easy to debug the failure, right at the point where it happens. i could make it smart enough to distinguish between private, internal interfaces (starting with an underscore) which are allowed to change functionality between revisions and external interfaces which should be invariant (except possibly on marked, backwards-compatibility-breaking revisions). i could speed things up by only trapping callables that contain modified lines in the revision diff and only running the tests with coverage on those lines. i could even do interesting things like adding in only some of the diff blocks to preserve correctness and walk backward or forward through revisions -- truly automated debugging! long term vision: maybe combining selective modification with an auto-commit-on-branch with each file save could allow me to tinker and spew out code in an entirely creative mode. the computer then assembles that into something correct and only asks me to clarify when it gets too confused. and all those microrevisions could provide a cleanroom-like estimate of bug introduction and elimination rates, as well as functionality addition rate based on number of paths through external interfaces.

that could also mean that i wouldn't need to write as many unit tests, since the same tool could catch calls and returns to any callable and compare results when they return. all i need to do is have my top level/integration tests and enough unit tests to fill in the coverage gaps. i could detect any changes on the internal interfaces if i wanted to, without necessarily breaking the build each time. any 'unit test' that was derived from the top level would be updated automatically. and if my coverage/diff analysis is reliable enough, i could speed up my continuous integration build a lot without losing any information. (i would have to be very careful about this, though, and track all kinds of external dependencies, etc.)

all of this would be a huge productivity boost since debugging is one of the biggest and most unpredictable time sinks i have. having unit tests is important and writing them often helps the development process, but updating lots of test results due to a small change in a core bit of code is a real pain. also, i don't like choosing between long-running tests or tag-along intermediate result pickle files.

came across some sites that should be useful for debugging, especially automatic debugging:

http://root.cern.ch/drupal/content/cint
http://root.cern.ch/drupal/content/cling
http://root.cern.ch/drupal/content/reflex
http://clang.llvm.org

cffi is the foreign function interface for python, used by pypy.
http://cffi.readthedocs.org/en/release-0.6/

some work people have done on delta debugging
http://delta.tigris.org
http://www.st.cs.uni-saarland.de/dd/ddusage.php3

useful to auto debug python
git bisect run http://lwn.net/Articles/317154
inspect module
http://pymotw.com/2/trace/index.html
http://pymotw.com/2/profile/index.html

also i should use vbench in my continuous integration. i think it was written by the same guy who started pandas. maybe there's a way to get it or multi-mechanize.py to output jmeter format so jenkins/hudson can read and plot it over time.

nadex.com

nadex exchange based in chicago. binary and bull spread options trading, legal for u.s. residents.

spyder and matplotlib

been getting some angry red and blue barf in my spyder console when a python script exits with undisplayed matplotlib figures hanging around. for example,

Traceback (most recent call last):
File "C:\Python27\lib\site-packages\spyderlib\mpl_patch.py", line 79, in
# lambda: self._widgetclosed())
File "C:\Python27\lib\site-packages\matplotlib\backends\backend_qt4.py", line 340, in _widgetclosed
if self.window._destroying: return
AttributeError: FigureManagerQT instance has no attribute 'window'
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\spyderlib\mpl_patch.py", line 79, in
# lambda: self._widgetclosed())
File "C:\Python27\lib\site-packages\matplotlib\backends\backend_qt4.py", line 340, in _widgetclosed
if self.window._destroying: return
AttributeError: FigureManagerQT instance has no attribute 'window'


so i changed lines 78-79 in spyderlib.mpl_patch from

QObject.connect(self.window, SIGNAL('destroyed()'),
lambda: self._widgetclosed())

to

QObject.connect(self.window, SIGNAL('destroyed()'),
lambda: self._widgetclosed() if hasattr(self, 'window') else None)

and now it dies silently, just the way i like it.